Server Development
Posts: 578
Joined: Tue Mar 25, 2014 6:47 pm
Sat Dec 12, 2015 9:02 am
Anomaly Management Notes
placeholder till i get all my shit together to put on here.
NOTE: i am classifying any non-normal, non-static space object (WH) or site (DED) as an "Anomaly", and they will be treated as such.
Anomaly Management System (AMS)
Dungeon Management System (DMS)
WormHole Management System (WMS)
Asteroid Belt Management System (BMS)
AMS will create and maintain all anomaly types in a system, as needed per system class. it will decide the type, location, and amount.
this Data will be stored in the DB, to be retrieved by the Scanning System, with the exception of WH data, which is maintained by the WMS.
when AMS creates a wormhole type, control will be turned over to the WMS, whom will then create the WH, and be responsible for it's maintaince and care.
the WH itself will be created and spawned right then, and it's timer started.
the WH system (w-space) will belong to the SystemManager, just as any other solar system.
the DMS will control creation and management of dungeons in an anomaly, using the type stated by the AMS.
each anomaly site will be created by the DMS upon first warp-in. at this time, the site will be considered "visited" and status stored in the db.
once found, sites are subject to being moved by those in charge. in role-play terms, once the pirates are found, they'll move to a new location.
this movement time is determined by site size, site rating (DED or my internal), system sec, and some other factors i havent decided on yet.
sites that have pirates left and are able to move (will make notes on this later), will take everything they can.
each site will have a chance to have its' own asteroid belt. if so, this belt will be created, controlled and maintained by the BMS.
for all intents and purposes, any group of 3+ roids will be considered an asteroid belt, owned and managed by the BMS.
if a belt is created inside a site that 'moved' the belt will remain and become a gravimetric site, subject to the rules that govern grav sites.
each system will have it's own AMS, BMS, and DMS. these systems will be in charge of their respective items within the containing system, and will
have need for common data and intercommunication between the managers.
the WMS will be a single entity, in charge of managing ALL wormholes in the universe, their connecting WH, the WH location in its' respective system,
it's timer and other variables, as well as all data relating to the WH in the DB. the singleton status here is necessary due to the need for common data
with regards to WH creation, destruction and their common interconnections.
// if probe, get current positions, move as needed (actually, just simulate by removing from bubble, time on distance, show on player's scanner, but NOT creating new bubbles, or adding to existing bubbles after movement....this means probes will NOT be shown on overview after initial creation. they CAN be scanned, but for all intents and purposes, are NOT space entities. this is subject to change later.)
// query possible items within scan range, return result. rinse, repeat as needed.
/* will have to write...
* an anomaly handling class/system, ...started - system/AnomalyMgr.cpp
* an asteroid belt handling class/system, ...started - system/BeltMgr.cpp
* a dungeon creation/managing class, ...started - dungeon/DungeonMgr.cpp
* a wormhole class/system, ...started - system/WormholeMgr.cpp
* a way for these systems to communicate between them, as wormhole is singleton, and others will have their own iteration in each active system.
* whatever else i find we need as i get to it.
*/
//NOTE for now, scanning is returning hard-coded data for appearance and bugfinding.
NOTE: i am classifying any non-normal, non-static space object (WH) or site (DED) as an "Anomaly", and they will be treated as such.
Anomaly Management System (AMS)
Dungeon Management System (DMS)
WormHole Management System (WMS)
Asteroid Belt Management System (BMS)
AMS will create and maintain all anomaly types in a system, as needed per system class. it will decide the type, location, and amount.
this Data will be stored in the DB, to be retrieved by the Scanning System, with the exception of WH data, which is maintained by the WMS.
when AMS creates a wormhole type, control will be turned over to the WMS, whom will then create the WH, and be responsible for it's maintaince and care.
the WH itself will be created and spawned right then, and it's timer started.
the WH system (w-space) will belong to the SystemManager, just as any other solar system.
the DMS will control creation and management of dungeons in an anomaly, using the type stated by the AMS.
each anomaly site will be created by the DMS upon first warp-in. at this time, the site will be considered "visited" and status stored in the db.
once found, sites are subject to being moved by those in charge. in role-play terms, once the pirates are found, they'll move to a new location.
this movement time is determined by site size, site rating (DED or my internal), system sec, and some other factors i havent decided on yet.
sites that have pirates left and are able to move (will make notes on this later), will take everything they can.
each site will have a chance to have its' own asteroid belt. if so, this belt will be created, controlled and maintained by the BMS.
for all intents and purposes, any group of 3+ roids will be considered an asteroid belt, owned and managed by the BMS.
if a belt is created inside a site that 'moved' the belt will remain and become a gravimetric site, subject to the rules that govern grav sites.
each system will have it's own AMS, BMS, and DMS. these systems will be in charge of their respective items within the containing system, and will
have need for common data and intercommunication between the managers.
the WMS will be a single entity, in charge of managing ALL wormholes in the universe, their connecting WH, the WH location in its' respective system,
it's timer and other variables, as well as all data relating to the WH in the DB. the singleton status here is necessary due to the need for common data
with regards to WH creation, destruction and their common interconnections.
// if probe, get current positions, move as needed (actually, just simulate by removing from bubble, time on distance, show on player's scanner, but NOT creating new bubbles, or adding to existing bubbles after movement....this means probes will NOT be shown on overview after initial creation. they CAN be scanned, but for all intents and purposes, are NOT space entities. this is subject to change later.)
// query possible items within scan range, return result. rinse, repeat as needed.
/* will have to write...
* an anomaly handling class/system, ...started - system/AnomalyMgr.cpp
* an asteroid belt handling class/system, ...started - system/BeltMgr.cpp
* a dungeon creation/managing class, ...started - dungeon/DungeonMgr.cpp
* a wormhole class/system, ...started - system/WormholeMgr.cpp
* a way for these systems to communicate between them, as wormhole is singleton, and others will have their own iteration in each active system.
* whatever else i find we need as i get to it.
*/
//NOTE for now, scanning is returning hard-coded data for appearance and bugfinding.