Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EmodiedEntity init is called before successful place #206

Open
dcat52 opened this issue Mar 3, 2022 · 2 comments
Open

EmodiedEntity init is called before successful place #206

dcat52 opened this issue Mar 3, 2022 · 2 comments

Comments

@dcat52
Copy link

dcat52 commented Mar 3, 2022

When placing agents (EmbodiedEntities) is it reasonable to restructure the code so that things happen in the following order:

  1. Entity initiated (to be able to have object shape)
  2. Entity attempted to be placed
  3. Collision Check (to see if the place is valid)
  4. If collision exists, remove entity and return to step 1.
  5. Execute Entity init function.

Currently, steps 1-4 exist in that order but step 5 occurs as a part of step 1.

Benefits of this:

  • Logging statements within the init function do not output for agents that were removed (Ex: when logging the agent IDs, it looks like multiple agents with the same IDs are created).
  • Actions agents perform in init that interact with nearby agents do not occur and then the agent is removed (Ex: transmitting data in the init as if the agents had been nearby for some time [TBD if transmitted messages in init are queued for the first step]).

Negative effects of this:

  • Agents with actuators that affect the dimensions of the entity are actuated prior to collision check (Ex. agent defaults to arm extended based on initial location, this would be good for collision checks [TBD if this entity movements affect collision checks]).

Other considerations of this:

  • Perhaps a configurationInit would fix the cons and then the later general init would solve this. This would potentially break existing experiments using this logic.
  • If the 2nd comment in the pros occurs, that should be considered a bug. But that could probably be fixed separately too.
  • If the 2nd comment in the pros doesn't occur or is fixed, documentation of this ordering may be sufficient of a solution.
@dcat52
Copy link
Author

dcat52 commented Mar 3, 2022

@ilpincy
Copy link
Owner

ilpincy commented Mar 31, 2022

This looks like a good suggestion, but I need to check its consequences a bit more closely. Thanks for the detailed analysis, I'll get back to you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants