Random placement when adding new characters not far enough apart for algae?

[benloh]

In GitLab by @jdanish on May 28, 2021, 12:30

1. In the pilot, press setup.
2. Click to add a fish. Add another. There is clear separation so it is easy to see them.
3. Click to add an algae - it appears near the center.
4. Add multiple additional algae. They are so close it appears as if a bold font is used, but that's it.

Can we change the spacing to be a bit further?

[benloh]

Do you still want to keep it centralized? Or do you want them to just appear anywhere on the screen?

[benloh]

In GitLab by @jdanish on May 28, 2021, 14:47

Centralized but just spread a bit further would be great.

[benloh]

mentioned in commit 097264b4ffce1a204acd61bed95b8e30ab05b7fd

[benloh]

mentioned in commit 21b23c0422c84934fefef68a9518a4d210592e27

[benloh]

@jdanish This is actually a feature not a bug.

If an agent has a # PROGRAM INIT script defined, we run that. If there is no INIT script, we then insert a auto-placement-near-center initScript when creating a new instance via the "ADD CHARACTER" "+" button.

We can't just willy nilly always insert the auto-placement script because that would potentially override any positioning that is handled by # PROGRAM INIT.

In the pilot script, Algae has an # PROGRAM INIT script. This is why Fish has proper spread, but Algae doesn't. When you "+" add a character, we run the # PROGRAM INIT and do not insert a placement script. You'll notice if you look at the instance editor for the newly created Algae, they do not have a position set.

The solution is to add an autoplacement method to # PROGRAM INIT. I just added a new Movement method:

---

setRandomStartPosition method

Sets a random position for an agent within a rectangle centered around 0,0.

Syntax

featCall Movement setRandomStartPosition <width> <height>

where <width> and <height> define a rectangle centered on 0,0. For example featCall Movement setRandomStartPosition 100 100 will randomly place the agent somewhere within 50 units of 0,0.

---

I've also updated the SpringPIlot script with this call.

A few caveats:

• It requires removing the position calls from the instances definition in the project file.
• One annoying side effect of this is that the algae are randomly moved with each "SAVE" of the setup.

This is implemented as part of dev-bl/color: 097264b4ffce1a204acd61bed95b8e30ab05b7fd

[benloh]

added 45m of time spent

[benloh]

@jdanish Please confirm that this solution works and close.

[benloh]

In GitLab by @jdanish on Jun 3, 2021, 10:48

Aha! I see - I had assumed that since I didn't move within init, it would default. I guess I was t thinking that there would be a default and then the #on init could simply override it by replacing it, so if it didn't, no big deal. But I see how that might also be problematic? Either way, once I share the rounds info (later today) we should probably have a bigger talk about overriding things to make sure it is really clear?

[benloh]

In GitLab by @jdanish on Jun 3, 2021, 10:51

I just tested and this works better, but the problem is that I might want to add a bunch of algae and then move them (what happened in the pilot) and then have them start where I put them. This call is moving them again each setup, which is a different intention. Does that make sense?

The fish, on the other hand, palaces random so that you can see they are separate, but you can then move them and that is now their permanent position.

I think from a user perspective I was hoping they'd both work the same, and figured since I removed the code to place the algae, they should have worked the same. I see why that was an error, but that was the logic. Thoughts?

[benloh]

In GitLab by @jdanish on Jun 3, 2021, 11:05

mentioned in commit c4d2fbb5cc1002ec019fb810a0fb4e3133aa8ca0

[benloh]

Actually, if you want Fish-like behavior, the simple solution is to move the # PROGRAM INIT lines out of Algae. Just put them in # PROGRAM DEFINE. The calls that are currently in Algae's INIT don't HAVE to be there.

I already adjusted the spread so it's within 100 of 0,0 instead of the original 50.

I think we had talked at one point of running # PROGRAM INIT followed by the instance initScript as a compromise, but that actually doesn't solve this situation because when instances are inserted via "+" we only add a position script if # PROGRAM INIT is not set.

Like you said, I think we might need to revisit this whole issue once we work through how moths rounds will work. The current UI is really centered around the idea of individually adding and editing instances as opposed to bulk adds where better management of init scripts might be needed.

[benloh]

In GitLab by @jdanish on Jun 3, 2021, 13:00

This was actually for individual adding. Right now, the breakdown is the following:

1. Click to add algae (it appears)
2. Click to edit algae
3. Change energyLevel from 100 to 50
4. Save
5. Algae looks like 100
6. Press start
7. Algae now shows that it is 50

The problem is that in an ideal world, either after changing the energy level, or at the least pressing "save" the algae would change to show that it is now 50 and not 100. That's what we had imagined the init function did ... Anyhow, maybe the round ideas make it clearer. We hope?!

[benloh]

In GitLab by @jdanish on Jun 3, 2021, 13:00

Note: pilot now works fine given your suggestion, so this is more about future expectations.

[benloh]

Alright, this is really helpful. A lot of the issue has to do with inter-run phase loops and figuring out what should and should not update. We need to find the balance between providing enough updates so that things like POZYX locations update and runtime updates like energyLevel going down with each tick not updating. We might end up with more pragmas coming out of this.

[benloh]

Spent 0.25h on 6/3 workarounds

[benloh]

added 15m of time spent