better default agent props & speed & position numeric, not strings

2026-06-21 12:08:25 +00:00
parent 54db203e86
commit 06a7868882
5 changed files with 106 additions and 9 deletions
@@ -36,4 +36,62 @@ The reason for this remark is to take provision for a future where I might want



-{ "eventType": "remove", "payload": { }, "sender": "agent42" }
+We need to think about how we start a new simulation from GPS point of view :
+As we are in a distributed context, here is the workflow I'm thinking of :
+1. Some orchestrator process will put all agents data in the arena Redis store.
+2. Then it will start all agents processes, in a special mode "onYourMarks" where they can initialize, time is frozen to zero, any non initialization computation is forbidden.
+3. When each agent is initialized, it fires an arena event "readyToStart"
+4. When the orchestrator has accounted for all agents, it fires an "arenaStart" event, that unleashes all agents.
+
+Now where is GPS in all of this :
+GPS should behave like an agent: listen for "onYourMarks" event, initialize, send "readToStart" when done, and start time-ticking when it received a "bigBang" event.
+Contrary to agents, GPS daemon itself is supposed to be running already.
+So the initialization is mainly doing a first agents scan to fill its registry. (with an unvalued T0 and collision-ticks not running). Scanning all agents means going into redis store to get their vector (its only after this step than GPS become the positions authority)
+Upon receiving "bigBang", T0 is valued, and the collisionsTicks starts.
+That's the general idea. 
+Please check if you don't see incoherence, gap or edge case.
+
+
+
+5. GPS time communicated to agents is simulation time, thus with T(bigBang) = 0
+Therefore,  when the orchestrator send a "bigBang" event, GPS starts general scan 
+and does the pre-compute with all positions at T=0
+For eventual time-elapsed computations internal to GPS, it can keep a reference, say bigBangEpoch to epoch (miliseconds)
+at the moment he receives the "bigBang" event.
+From then on, current Simulation time is now() - bigBangEpoch
+
+
+Next step: the embrio of simOrchestrator.
+Can you create a second GodDaemon called like that, aside GPS, that uses the same config, the same general pattern, adapted start & stop scripts, 
+
+
+
+
+
+
+So, the first thing you must understand, is that all busses, thus all meshes and all redisConnexions can carry both types of messages :
+1. Request-reply:  action request (possibly with reqid) requestor to provider. After action completion (or rejection), the provider answers the requestor (private chan replacing {uuid} with sender) with a reply (on the same reqid if present). 
+The payload must contain "action", with an imperative form.
+Action must be verified to arrive on a specific chan, and the sender be allowed by access-rights.
+
+2. Events broadcasting: not a request, just a message for anybody interested (so no "rejection" per se, but eventual ignore). No answer, but eventual local processing which might or not endup firing other event(s). 
+The payload must contain "eventType", with a generally a past tense. (like "he guys, I UPDATED my color")
+Event routing combines chan & eventType (for example, and "updated" eventType could appear on a agentColor chan, and on a agentHealth chan, with different meanings and thus handling)
+
+These two types can happen anywhere, it is not a "per mesh drift".
+Probably, most Actions will concentrate in the SYSTEM mesh, because the management by the front-end and API is mostly user driven (user action becomes a request on the system bus).
+Probably, the ARENA will be mostly event-driven, because agents have no overview of the arena (so to who ask for what?)
+
+Nevertheless, there will be many cases where this is not true:
+GODs emitting events that other gods or even the Front-End should be aware of.
+The observer feeding the GUI on arena changes in an event-driven way.
+Agent in the Arena requesting a service from a known god. (like "Hey GPS, give me my latest vector")
+And maybe even someday clever agents that provide actions to other agents in their proximity for example.
+
+"Action" folder was originally meant for...actions !
+
+Now we need to find a clean, elegant, universal (across daemons & across meshes) 
+way of coexist both actions and events.
+
+Describe a proposal that stays close to what we have, but separates events from actions.
+