STEINNI
39 lines
3.0 KiB
Plaintext
39 lines
3.0 KiB
Plaintext
In SPARC, the app menu is created from app/assets/json/global/app-menu-map.json
|
|
Each entry defines a route.
|
|
A "high level" route is then configured in app/config/baseRoutes.json that delegates a group of URLs to a controller.
|
|
Then, a controller, in its associated .json file defines in its "routes" section the sub-route managed by the controller,
|
|
and the method to be called inside that controller.
|
|
|
|
In SPARC, models inherit from the core and from WindozModel a mecanism that gets the URL from app/assets/json/global/services.json
|
|
That configuration file associates actions grouped in sections to API urls and http method.
|
|
Sections are identified by an URL-prefix (only used as label), and correspond to API "services".
|
|
The server-side of this API is served by the node daemon in p42api.
|
|
p42api has a folder 'api' with one file / module per API service, they are all declared in and imported by api/index.js.
|
|
Each module defines a mapping object, that contains all the complete urls served, http-method, and local handling method.
|
|
|
|
We are now focusing on P42 God Daemons (in folder p42GodDaemons).
|
|
Every daemon in there is connected to several Redis. At least one Arena redis, and one System Redis.
|
|
PUB/SUB channels are prefixed accordingly, following the configuration token "chansNamespace"
|
|
and anything outside the configured combination Redis host & port + chansNamespace is illegal.
|
|
In the future, there might be several different Redis (in mesh) serving the same chansNamespace.
|
|
|
|
GPS Daemon is the global positionning system of the arena.
|
|
It holds the current position of every agent in the arena.
|
|
Agents change their 3D speed vector whenever they want by informing GPS (via the agentVectorChangeChannel)
|
|
A typical agent event looks like
|
|
{ "eventType": "change", "payload": { "newVector": { "x": 5, "y": -2.34, "z": 0 } }, "sender": "agent42" }
|
|
On every speed vector change, GPS computes the 4D worldline of the agent,
|
|
and scans all other worldlines to find those intersecting, or approaching less than a configurable distance.
|
|
Each collision/ near-miss is then registered.
|
|
As time passes, GPS fires events towards concerned agents based on this register.
|
|
On every speed vector change, this register is searched and all entries containing the agent changing its speed are deleted.
|
|
To speed-up and limit the intersection computations, we will take an approach using rectangular 4-prisms :
|
|
Each pair of wordlines to test for collision / near-miss is enclosed in a 4-prism of a certain configurable time-height (thus how far in the future we test),
|
|
and we just test for intersecting prisms.
|
|
Only if the prisms intersect do we compute the real minimal-distance and its time, that we keep in the register.
|
|
Comparing a pair of worldlines should be a separated method and the looping through all agents in a separated method as well.
|
|
The reason for this remark is to take provision for a future where I might want to paralellize this (instead of looping through), in a GPU.
|
|
|
|
|
|
|
|
{ "eventType": "remove", "payload": { }, "sender": "agent42" } |