NSV13
NSV13 copied to clipboard
[MDB IGNORE] Ftl drive rework
Big thanks to @IndusRobot for fixing/improving the FTL pylon sprites
Mapping Credits
- @IndusRobot: Aetherwhisp
- @Absolutely-Steph: Galactica Tycoon Vago Atlas Eclipse
About The Pull Request
FTL drives are now a lot more complex than a magic computer with a funny dial. The drive now consists of three different main components
FTL silo/refinery
This large refinery converts plasma directly into nucleium, conversion efficiency is determined by the amount of power currently being input into the silo. Make sure you manage the internal pressure, containment failure is devastating. This is a more convenient alternative to using the storm drive for FTL fuel production, albeit at a lower efficiency. It's generally preferable to use a storm drive over this
FTL pylon
Has fast spinny gyros that is spooled with nucleium and a moderate amount of power, drive manifolds can have multiple connected pylons, each one increasing the total FTL charge speed. Pylons have a retractable shield which increases their durability and power efficiency at the cost of heat and nucleium Once the pylon is fully spun up, it will no will gradually (but exponentially) require more power to keep spooled, when the shield is down it's power gain increases less but it's nucleium consumption begins to increase. so make sure to only have these spun up when you need them.
FTL drive
The heart of it all, powered by the drive manifolds. This also acts as the drive pylon control computer.
Why It's Good For The Game
The current FTL computer is boring and a dent in engineer masochism.
Changelog
:cl: TheFakeElon, IndusRobot, Absolutely-Steph add: Adds a new FTL drive and it's respective components code: cleans up legacy FTL drive file code: Adds a new advanced looping sound handler code: Adds an index2phonetic/greek proc /:cl:
- [x] FTL Silo
- [x] FTL Pylon
- [x] FTL Manifold
- [x]
Frameshifted Plasma - [x] New manifold UI
- [x] Silo UI
- [x] Test everything
- [ ] Make legacy compatibility not bodge ((optional))
- [x] Clean up unused procs/vars
Are construction steps planned for repairs/possible replacement? If you'd like, I could setup some cheap circuit and build steps for you
Construction is coming :), either through circuits or cargo
The silo defeats the point of having to manage engine mixes to produce Nucleium.
We did not ask for this.
Also logically the silo doesn't make sense as plasma to nucleium is a power positive process.
The silo defeats the point of having to manage engine mixes to produce Nucleium. We did not ask for this.
I'm pretty sure "we" did ask for this, it was in the original design doc.
Originally, it served as a converter between Nucleim and the new bluespace gas. But after the first PR went up and you decreed the removal of the gas specified in the doc, It was repurposed to to act as an alternative to the stormdrive. Which in hindsight is something that it should have been capable of from the very start. Forcing people to use the stormdrive for something overmap gameplay critical as FTL navigation is a frankly terrible idea.
Overmap gameplay will grind to a halt if:
A) There are no staffed engineers who know the Stormdrive meta B) The Stormdrive (or more specifically, Nucleium production) is disabled due to a mistake or incompetency C) The Stormdrive is sabotaged etc.
While it's possible to repair/remedy the situation in some of these instances, it's probably not going to be interesting for the engineer(s) and it's definitely not going to be for everyone else. The Stormdrive is not only a single point of failure, it is a single point that is almost designed to fail.
The silo defeats the point of having to manage engine mixes to produce Nucleium. We did not ask for this.
I'm pretty sure "we" did ask for this, it was in the original design doc.
Originally, it served as a converter between Nucleim and the new bluespace gas. But after the first PR went up and you decreed the removal of the gas specified in the doc, It was repurposed to to act as an alternative to the stormdrive. Which in hindsight is something that it should have been capable of from the very start. Forcing people to use the stormdrive for something overmap gameplay critical as FTL navigation is a frankly terrible idea.
Overmap gameplay will grind to a halt if:
A) There are no staffed engineers who know the Stormdrive meta B) The Stormdrive (or more specifically, Nucleium production) is disabled due to a mistake or incompetency C) The Stormdrive is sabotaged etc.
While it's possible to repair/remedy the situation in some of these instances, it's probably not going to be interesting for the engineer(s) and it's definitely not going to be for everyone else. The Stormdrive is not only a single point of failure, it is a single point that is almost designed to fail.
Interesting narrative you spin.
To address these points:
Ω: NSV Reactors already are critical to gameplay.
A: Engineers requiring how to setup both the AGCNR and Stormdrive is a pretty required step for most rounds, outside of Eclipse, which is why we have wiki pages and guides on how to do so. As for an actual "META", most ships barely use 4MW of power which is incredibly easily obtainable by both reactors, while also producing nuclieum. There is no need for any sort of "META" setup to achieve this.
B: Is this any different to power production being lost due to the same reasons? If there is no power, then your silo doesn't work anyway. And ultimately, if a crew chooses not to keep a ready surplus of nucleium in some sort of storage tank, then it is quite literally a skill issue. We do like having some skill issue gates in NSV13.
C: Again, if the reactor is sabotaged, you won't have power for the silo or the device itself.
If I recall the original intent was to have a manifold, have pylons, and feed it nucleium so it tied to engineering more instead of dumping nucleium into space. Partially also to reuse existing gases. Then it seems silos were created alongside some frameshifted plasma which wasn't part of the original plan.
So what if an engine doesn't produce enough nucleium? That's okay, if we test and discover there's a problem with getting enough nucleium into the drive, we can easily change this. Double it even. There's multiple angles to handle nucleium
@IndusRobot the original plan was to have a manifold powered by pylons that use frameshifted plasma (at the time it was called bluespace gas) which was created by refining nucleium. I'll post the doc when I get home
So what if an engine doesn't produce enough nucleium?
Other gameplay critical systems such as grid power have many different methods of supply. No matter how much nucleium the stormdrive produces it is still the single point of failure.
@Karmic-Skink
Is this any different to power production being lost due to the same reasons
Yep! it is very different. Similar to what I said above, power has pacgens, solars, stormdrive, SM, RMBK, teslas, the list goes on. Nucleium has the stormdrive
Again, if the reactor is sabotaged, you won't have power for the silo or the device itself.
There are other ways to produce power aside from the stormdrive
@IndusRobot the original plan was to have a manifold powered by pylons that use frameshifted plasma (at the time it was called bluespace gas) which was created by refining nucleium. I'll post the doc when I get home
So what if an engine doesn't produce enough nucleium?
Other gameplay critical systems such as grid power have many different methods of supply. No matter how much nucleium the stormdrive produces it is still the single point of failure.
@Karmic-Skink
Is this any different to power production being lost due to the same reasons
Yep! it is very different. Similar to what I said above, power has pacgens, solars, stormdrive, SM, RMBK, teslas, the list goes on. Nucleium has the stormdrive
Again, if the reactor is sabotaged, you won't have power for the silo or the device itself.
There are other ways to produce power aside from the stormdrive
The original plan did not have any additional gases. I started on the original plan, I would definitely know.
Also every single map outside of Eclipse has a source of generating Nucleium. This is the intended state of play. For whatever reason, you seem to not understand that the AGCNR also does this.
This pull request has conflicts, please resolve those before we can evaluate the pull request.
PR seems to have resolved all issues except conflicts now
🎉
This pull request has conflicts, please resolve those before we can evaluate the pull request.
Alright, maptainer time.
As of expected completion I need to know two things.
- If I am making a new map what do I need to do to make this system work.
- If I am adapting this system to an existing map what do I need to make the new system work?
@Vasily2013 You shouldn't need to do much, It's pretty modular. The pylons need to have a connected cable and a piped input (for nucleium) and output (for hot plasma, probably venting into space). Other than that the only real requirement is the pylons being within 10 tiles of the FTL manifold, this is a define atm so you can change it if need be.
There's an FTL drive debugging map template included with this PR so you can look at that if you need a reference for the functional gist of things, otherwise feel free to DM me if you have any further questions!
This pull request has conflicts, please resolve those before we can evaluate the pull request.
Thing's I've noticed while making the maps for this:
-
Static sprite(FTL Core) has some extra pixels at the left hand side, causes perceived pixel shift when switching to animated sprite.
-
Weird behaviour with the pylon sprites when switching between shield modes, probably not being updated correctly.
-
some errors with looping sounds:
Runtime in _looping_sound.dm,44: bad index proc name: play (/datum/looping_sound/advanced/play) src: /datum/looping_sound/advanced/... (/datum/looping_sound/advanced/ftl_drive) call stack: /datum/looping_sound/advanced/... (/datum/looping_sound/advanced/ftl_drive): play('nsv13/sound/machines/FTL/main_...') /datum/looping_sound/advanced/... (/datum/looping_sound/advanced/ftl_drive): on stop() /datum/looping_sound/advanced/... (/datum/looping_sound/advanced/ftl_drive): on stop() /datum/looping_sound/advanced/... (/datum/looping_sound/advanced/ftl_drive): stop(null) /datum/looping_sound/advanced/... (/datum/looping_sound/advanced/ftl_drive): interrupt(null) the Thirring Drive manifold (/obj/machinery/computer/ship/ftl_core): depower(0)
also the pylon sprite is supposed to be a pole esque thing standing out of the ground, but it has a 1x2 hitbox, so that's a bit annoying.
Should be ready for testmerge
This pull request has conflicts, please resolve those before we can evaluate the pull request.
Initial test of my merged copy:
- The hitbox for the drive on the Atlas blocks the door in from the north
- The nucleium can on the Atlas is empty to start
- When I tried to jump but started powering down the pylons before entering hyperspace, space updated to show the hyperspace background and all objects cleared from the dradis, but I never exited my "jump". SSstar_system still thought I was in my starting system, because I was able to begin another jump to a neighboring system which was successful.
Initial test of my merged copy:
- The hitbox for the drive on the Atlas blocks the door in from the north
We could also just not put it on Atlas, it's a very small ship and this thing is very big. Otherwise I'd say just rebuild engineering from the ground up with the larger FTL machine in mind.
Initial test of my merged copy:
- The hitbox for the drive on the Atlas blocks the door in from the north
We could also just not put it on Atlas, it's a very small ship and this thing is very big. Otherwise I'd say just rebuild engineering from the ground up with the larger FTL machine in mind.
That's true yeah, I don't think we originally intended to run this on the Atlas. Although since it's our most played ship and a neat new mechanic, I could be convinced otherwise.
Additional issues: Aetherwhisp FTL isn't on an engine grid, but instead on a low-powered one. Also the AGCNR APC is not linked to any powergrid due to messy wiring to its west.
Galactica FTL has a pipe missing around the reactor chambers so it won't get fueled. Additionally, it's questionable for it to have its own storage chamber since that just means it steals it from the device that shouldn't be mentioned (it's linked to that one's net) and well, there already is a storage tank. Should just both use the same net or at least have the tank as optional buffer.
With the new mapping to make room for the FTL setups, it seems updated wiring was a bit of an after thought. Tycoon specifically has half of the engineering bay unpowered due to no wiring to the APC See image below
Easy fix in-round, but also shouldn't be a fix in-round
The output 45 jump (end of the round, forced jump regardless of spool status) doesn't work if the pylons are off.
That last commit likely broke the Eclipse further with access changes.
- It looks like it got removed from the Atlas and not the Eclipse?
- Sabres (utility fighters) are unable to jump back to the main ship - it seemed like the system contents did not unpack correctly after the sabre left the asteroid it was parked on
- On round 4882, the crew went into additional objectives, hit the mandatory recall time while in combat, but then when the autorecall tried to jump them back after they left combat they ended up starting the jump over and over. (The sound played but they never actually jumped)
@TheFakeElon can you take a look at this?
The output 45 jump (end of the round, forced jump regardless of spool status) doesn't work if the pylons are off.
This pull request has conflicts, please resolve those before we can evaluate the pull request.