benloh
commented
3 years ago A few notes/reminders:
- [ ] Assign id when instances are created. But also save the ids to the session's instance definitions so when the definitions change we can keep track of them.
- [ ] Model scripts in
gs_packages/gem-srv/src/app/data/*.jsneed to be updated to remove the instance id.
In GitLab by @daveseah on Mar 17, 2021, 13:57
Note: Agents will be called Characters in the future. Just not in the current codebase yet.
Agents were considered the important data unit of simulation data, as each character is a bag of properties that are operated on by the simulation. For mapping agents one-to-one with derived data objects, each agent's id was copied to the new object. So, for an agent with id
A123, a VisualObject is created with the same idA123. Likewise, the DisplayObject used in display lists share the same id. This pattern is used throughout STEP for any dataset that needs to be "synchronized" with the set of instantiated Characters.As we get into the management of actual sets of instances in the model, it's becoming apparent that the important unit has changed. It's no longer the Characters in the simulation, but the definitions of those characters that are used to create them in the first place. Therefore, we need to move the canonical id code from the Agent class to something else. This code actually lives in the
SMObjectbase class, which defines the common interface used for all the student-scriptable simulation objects and their properties.WORKING NOTES
As an Instance Definition is not really a scriptable element that will be handled by the simulation engine, I think we'll probably move canonical ID to its own module, and Agents will initiatialize with the id passed to it.
In general, I'd like to avoid data structures that bake IDs into the saved definitions because this creates a lot of messy cleanup problems for database and UI operations that have to add/delete/rewrite ids; this was always a pain in the ass and resulted in fragile code. The pattern we're using for most system modules is to generate the ids on-the-fly based on their ordinal position in a defining list. I think this is much cleaner.
In the case where a unique student-usable id is needed, this is NOT the canonical ID, but a logical name or id that should be added to the data structure. This is a distinct ID, and student-facing UI operations should not be modifying the canonical id directly. This has always been part of the agent design, providing both an id and a name property for that reason.