MASON-INTEREST-L Archives

August 2012

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Wed, 8 Aug 2012 21:14:09 -0600
Reply-To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Content-Transfer-Encoding:
8bit
Subject:
From:
Tony Bigbee <[log in to unmask]>
Content-Type:
text/plain; charset=UTF-8
In-Reply-To:
MIME-Version:
1.0
Comments:
To: Luís de Sousa <[log in to unmask]> cc: Sean Luke <[log in to unmask]>
Parts/Attachments:
text/plain (45 lines)
Luís,

One issue I found (and I stopped looking at this point) in
Wanderer.step is that even though you remove the object from the grid
in your in your if block, you always set the location again within the
step method.
Calling stop() does not exit your step method that contains this code,
and execution proceeds to the domain.setObject... line and to the end
of step().
One way to fix is to add a return in the if block.

if (energy <= perishTreshold) {
	domain.remove(this);
	this.stop();
        return;  //added
}
		
int nextX = randCoord(location.x, sim.random);
int nextY = randCoord(location.y, sim.random);
		
domain.setObjectLocation(this,nextX,nextY);  //<--this is always
called regardless of whether the if condition is satisfied unless a
return is added within the if block

On Wed, Aug 8, 2012 at 12:23 PM, Luís de Sousa
<[log in to unmask]> wrote:
> Thank you folks for your help. Here in attachment you'll find two
> compressed files, one with the Eclipse project (use File->Import) and
> another with the plain java files.
>
> Don't try to find much logic in it, it is a very stripped down version
> of another simulation, just for illustration.
>
> Thank you once more,
>
> Luís
>
> On 7 August 2012 23:33, Sean Luke <[log in to unmask]> wrote:
>> field.remove(foo) will definitely remove foo from the field, and the Field Portrayal will definitely stop calling draw() on its corresponding SimplePortrayal.  So if you're having a problem at this point either there's a bug in your code or a bug in ours.  To determine this, I will need you to send me (directly) a tarball containing an ideally simple example of the bug happening, including source code, so we can poke around.
>>
>> The only other thing I can think of is that you are using the same SimplePortrayal for multiple objects in the field -- that's typical -- but are storing some kind of state or information in the SimplePortrayal which is somehow carrying over -- that's unlikely.  Or you have the object being added to the field somehow or it's part of some other field which is being drawn.
>>
>> Sean
>>

ATOM RSS1 RSS2