- Joined
- Dec 19, 2015
- Messages
- 48
- Reaction score
- 21
I know that a lot of this stuff is probably already in the pipe, but I had some thoughts on how to make carrier management fairly intuitive.
The basis of this is on two blocks: Carrier Rail, and carrier Rail Attachment. Some of the functions might be workable into existing rail blocks instead, but here we go.
The Carrier rail functions pretty much like a normal rail except that it always holds the docked entity in place unless it receives either A: A logic signal or B: A launch order from the fleet settings.
In addition, it can slave a pickup point. This way, when a ship is ordered to join a fleet/carrier, it already knows which pickup point to use, or will randomly pick one otherwise. Once the pickup itself has been used the rail will go into a 'wait mode' and then its normal 'docked mode' once there is an entity on it. This way if all the carrier rails slaved to a pickup point are in wait or docked mode, the pickup will deactivate itself, disallowing the recovery system from becoming jammed, even if there are craft moving on it that have not reached their carrier rail.
The carrier rail attachment simply signifies the explicit rail attach a ship should use to attach to the carrier. When executing carrier_recall or similar orders, it won't attempt to dock with other rails, and possibly disable them so it can't (Allowing docking of ships with other kinds of ports correctly)
EDIT: I now realize that having pickups slaved by carrier rails simply not accept non-carrier rail attachments would be the cleaner solution.
As well, both blocks would be able to slave storages. Not only allowing the usual transfer mechanics, but allowing a ship executing a mining command to know when its storage is full or over a certain percentage, and to automatically return. The carrier rail itself could then check the attached rails cargo flag, and if empty and the fleet is still mining, re-launch automatically.
Other possibilities include both types of rail being able to cycle through say, numbers 1-10. This way a ship with an attacher 2 in a fleet will only attempt to dock to a carrier rail 2 or its slaved pickups, allowing mixed docking types with greater ease. And for example, setting fleet options such that only rails 1,3 and 4 will launch for combat, and 2 for mining.
Another possibility is setting carrier attachers to an F or fleetship mode, and then assigning the fleet itself a 'home base' in the form of a station. When ordered to return home, they will know where to go and, through the mechanics described above, which Fleet-linked carrier rails and pickup points to use on the station. A new order could then either simply detach the attacher, or cause it to signal the rail its docked to to allow it to pass.
Working into mining, this way a carrier with mining drones could know to return home to dock and be unloaded when full as well, even if its sector/area/patrol path isn't finished, then to launch and continue as a standalone ship would.
Putting in stops such that say, a carrier will only itself dock if all of its currently known carried entities are themselves docked, would allow for concepts such as fighters carrying small 'add/option/funnel' drones to be implemented without undue fuss as well.
The idea itself is admittedly a little rough, but I feel a system like this could allow complex carrier gameplay, while being a fairly intuitive and straightforward extension of the existing rail mechanics.
EDIT: More brainstorming <.<
Another thought is for carrier rails to have a ship design associated with them, so only ships of said design would/could dock there. Advantage here being shipyards could then possibly be set to 'supply fleet,' producing craft for empty carrier rails. (and allowing ships to be ordered directly form the fleet menu, but that's a whole other can of worms.)
The basis of this is on two blocks: Carrier Rail, and carrier Rail Attachment. Some of the functions might be workable into existing rail blocks instead, but here we go.
The Carrier rail functions pretty much like a normal rail except that it always holds the docked entity in place unless it receives either A: A logic signal or B: A launch order from the fleet settings.
In addition, it can slave a pickup point. This way, when a ship is ordered to join a fleet/carrier, it already knows which pickup point to use, or will randomly pick one otherwise. Once the pickup itself has been used the rail will go into a 'wait mode' and then its normal 'docked mode' once there is an entity on it. This way if all the carrier rails slaved to a pickup point are in wait or docked mode, the pickup will deactivate itself, disallowing the recovery system from becoming jammed, even if there are craft moving on it that have not reached their carrier rail.
The carrier rail attachment simply signifies the explicit rail attach a ship should use to attach to the carrier. When executing carrier_recall or similar orders, it won't attempt to dock with other rails, and possibly disable them so it can't (Allowing docking of ships with other kinds of ports correctly)
EDIT: I now realize that having pickups slaved by carrier rails simply not accept non-carrier rail attachments would be the cleaner solution.
As well, both blocks would be able to slave storages. Not only allowing the usual transfer mechanics, but allowing a ship executing a mining command to know when its storage is full or over a certain percentage, and to automatically return. The carrier rail itself could then check the attached rails cargo flag, and if empty and the fleet is still mining, re-launch automatically.
Other possibilities include both types of rail being able to cycle through say, numbers 1-10. This way a ship with an attacher 2 in a fleet will only attempt to dock to a carrier rail 2 or its slaved pickups, allowing mixed docking types with greater ease. And for example, setting fleet options such that only rails 1,3 and 4 will launch for combat, and 2 for mining.
Another possibility is setting carrier attachers to an F or fleetship mode, and then assigning the fleet itself a 'home base' in the form of a station. When ordered to return home, they will know where to go and, through the mechanics described above, which Fleet-linked carrier rails and pickup points to use on the station. A new order could then either simply detach the attacher, or cause it to signal the rail its docked to to allow it to pass.
Working into mining, this way a carrier with mining drones could know to return home to dock and be unloaded when full as well, even if its sector/area/patrol path isn't finished, then to launch and continue as a standalone ship would.
Putting in stops such that say, a carrier will only itself dock if all of its currently known carried entities are themselves docked, would allow for concepts such as fighters carrying small 'add/option/funnel' drones to be implemented without undue fuss as well.
The idea itself is admittedly a little rough, but I feel a system like this could allow complex carrier gameplay, while being a fairly intuitive and straightforward extension of the existing rail mechanics.
EDIT: More brainstorming <.<
Another thought is for carrier rails to have a ship design associated with them, so only ships of said design would/could dock there. Advantage here being shipyards could then possibly be set to 'supply fleet,' producing craft for empty carrier rails. (and allowing ships to be ordered directly form the fleet menu, but that's a whole other can of worms.)
Last edited: