MASON-INTEREST-L Archives

August 2012

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show HTML 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:
Thu, 9 Aug 2012 08:22:18 +0200
Reply-To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Content-Transfer-Encoding:
8bit
Subject:
From:
Luís de Sousa <[log in to unmask]>
Content-Type:
text/plain; charset=ISO-8859-1
In-Reply-To:
MIME-Version:
1.0
Comments:
To: Tony Bigbee <[log in to unmask]> cc: Sean Luke <[log in to unmask]>
Parts/Attachments:
text/plain (53 lines)
Thank you Tony, I can't confirm it right now, but this must certainly
be the mistake we are looking for.

Regards,

Luís

On 9 August 2012 05:14, Tony Bigbee <[log in to unmask]> wrote:
> 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