NSV13 icon indicating copy to clipboard operation
NSV13 copied to clipboard

[Experimental] Gas Miners are dead, long live Gas Miners

Open DeltaFire15 opened this issue 2 years ago • 22 comments

About The Pull Request

Prefix: Will require config modifications by people with access due to the starmap being a config thing now, which I'd like to mirror onto this PR's config afterwards to support possible downstreams or localtesters. See further down for the details. Also is an experimental PR due to doing some pretty significant changes to gas acquision, adding an option inbetween "gas miners - infinite gas" and "no gas miners - one tank hit and you have to buy 100 cans to resupply"

Onto the main course, this PR takes gas miners and creates a version of them which instead harvests system gas resources. Systems can come with specific traits that can modify them, which are either set by code / config in case of pregenerated systems, or randomly set in the case of unmapped space.

Gas resources here are ~~arbitrary numbers~~ a combination of "how accessible is this easily by the mining equipment on a warship", "how much is there" and "are we actually allowed to take this much from e.g. a habitable world". Some system types also modify resources somewhat.

How much exactly is in a system is initially hidden and can be viewed via the astrometrics console by either scanning the system, or being in it at the moment. Gas is displayed in moles aswell as in a bar with color depending on class (0-100 moles is one bar class, then 100 to 1000, 1000 to 10000, and so on, up to class V which is a lot of gas) Additionally, ships being destroyed tends to leave gas clouds in a system which can later be harvested, depending on the ship's salvage rating which can be anywhere inbetween 0 for a Fighter to very high for bigger ships.

All ships have been remapped to either replace gas miners with system gas miners or to add them in positions that did not have a miner yet. (except the testship) This includes the Shrike, where I was somewhat unsure due to how it's "wings" are setup for atmos, feel free to just suggest (or just commit) how you'd like that one to be.

bz and vapor miners exist codewise like the basetype, however neither of the two resources currently gets generated by default nor are any mapped.

Here the config thing: For mapped space, there have been some few additions to the hardcoded aspect, but configwise it'd be nice for someone to sit down and think what which system may have, maybe based on the hardcode-backup version, maybe not. Just keep in mind that the approximate amount the gasses will be in preset systems currently will be very simillar every round. Generally, rare gasses (especially plasma) shouldn't be too common in safe space which is why in the hardcoded version Sebacien is the only place with a Plasma-Gas Giant (which maybe could be seen as why that cluster was initially settled). Also be aware that bitfield defines don't work for the config so you'll have to check what each bitfield define amounts to as number and have that in the config. (Might code something more helpful for that to interpret something more readable later, but thats it for now)

Also fixes some unmapped space system type picking so we might be starting to (very rarely) see black holes again, and raidoactive systems should be rarer. Also fixes a random bounty thing

Revision III update: General intent of the PR remains the same, however I've contemplated implementation a little. Basically, gas resources of a system are now condensed into a "gas harvesting point" point of interest in system, which a ship has to maneuver close to and lockon the initiate harvesting. Other things that add additional resources to a system (such as ships exploding) now add a gas cloud to the system. Todo for the PR has also changed, including some different things with a more concise final goal. Placing of resources on the initial map / in systems will also have to be revisited, as the starmap has changed a lot in the time since this had its first code written and some then-true assumptions are that no more.

POIs: ~~- [ ] Handle config aspect so premapped systems aren't just empty when tested.~~ ~~- [ ] Make sure things definitely work.~~ ~~- [ ] Balance?? This is probably where number crunching reactor and distro moles comes into play. Or just testing.~~ ~~- [ ] (Maybe) Add gas miner controller console instead of them just working by themselves.~~ ~~- [ ] (Maybe) Add constructible gas miner with lower throughput.~~ ~~- [ ] (Maybe) Add additional tidbit info to the astrometrics readout for some specific sources (e.g. gas / plasma giant or habitable)~~

  • [x] Scream at tgui, persistently.

Revision III:

  • [x] Modify harvesting to be gas-cloud / harvesting-point based.
  • [ ] Option to display gas resources for a specific asteroid / cloud. (for asteroids, requires mining dradis upgrade tiers. Also paused 'till tracking PR merge)
  • [x] Acquire cloud sprite. (currently uses smoke sprite which seems decent enough, could probably vary size depending on gas amount)
  • [x] Clouds count into the available resources for a system on astrometrics.
  • [x] Handle lockon / dropping lockons.
  • [x] Ships create clouds on destruction.
  • [ ] Asteroids create clouds if detonated with mining charges. ~~- [ ] Torpedo with simillar effect to mining charges but less efficiency.~~ sorry miners get to have all the fun.
  • [ ] Option to analyze gas resources while on an asteroid.
  • [ ] Gas miner that can be constructed, but only outputs to linked canisters. Works on sabres, hint hint.
  • [ ] Bigger canister that can only be filled from can miners
  • [ ] !Investigate gas generation in general as the current one has issues with the starmap reworks over the years.
  • [ ] Admin starsystem panel option to create clouds

Why It's Good For The Game

Gas as a resource is a pretty critical aspect in NSV, whether for all NSV specific engines, atmos' wacky reactions or simply repressuring damaged parts of the ship. Currently, this tends to be rather binary, with ships that have gas miners living in excess while those that don't suffering effectively permanent damage from having a gas tank hit due to the currently extreme requirements to resupply. This should add a middle ground, although polishing will be in order.

Changelog

:cl: balance: Gas miners now take gas from systems instead of generating it from nothing. add: Science's astrometrics console can view gas resources in scanned systems or the one you are in. add: Ships will now leave behind harvestable gas clouds when destroyed. add: The ship's pilot can now handle lockons for gas harvesting sources, which requires proximity. fix: Unmapped space's system types should now be picked more reasonably than whatever that old method was. fix: Bounties no longer have a 1/13th chance to fail generating. fix: Roundend stats for overmap objectives should no longer fail to show under certain conditions. fix: spawn_anomaly now always returns the anomaly it created instead of in only half of cases. /:cl:

DeltaFire15 avatar Sep 20 '22 17:09 DeltaFire15

This pull request has conflicts, please resolve those before we can evaluate the pull request.

github-actions[bot] avatar Sep 20 '22 21:09 github-actions[bot]

Yo, what about actually just mining gas? With shaft miners.

Karmic-Skink avatar Sep 20 '22 22:09 Karmic-Skink

Yo, what about actually just mining gas? With shaft miners.

Firstly, I have my concerns with transportation / throughput unless one gave them like 100 times larger canisters which'd be a bit wacky if damaged or for general use. Many things on NSV guzzle gas and simply sustaining that would probably be quite a bit of tedium. Secondly, i like the aspect of science being able to scan for resources and to guide engineering / command to systems where there may be sufficient supplies which may be closer than an already known source, which may be quite a bit harder to implement if done via asteroids.

However, I could imagine something added onto this aspect which does involves miners, namely landing on asteroids containing gasses and placing blast charges on them which when detonating add the asteroid's gas resources to the system, for when there's absolutely no decent supplies around or a boost really is needed.

DeltaFire15 avatar Sep 21 '22 00:09 DeltaFire15

Okay so my main concern with this, like everything NSV13/SS13, is basically about why is this not actually just a player's job? Why have automated gas miners plugging away in the background, when we can make it potentially an interesting thing for players to do? This is a good step in making it a player driven mechanic, but why not go whole hog?

Firstly, I have my concerns with transportation / throughput unless one gave them like 100 times larger canisters which'd be a bit wacky if damaged or for general use. Many things on NSV guzzle gas and simply sustaining that would probably be quite a bit of tedium

I'd recommend using an internal tank component on a Sabre rather than using standard canisters and using some sort of extraction port/hose to pump it into distro/scrubber networks. Perhaps this needs to be a subvariant of the mining sabre even?

Secondly, i like the aspect of science being able to scan for resources and to guide engineering / command to systems where there may be sufficient supplies which may be closer than an already known source, which may be quite a bit harder to implement if done via asteroids.

These aren't mutually exclusive options, "ice asteroids" are only one solution, and not what I had in mind tbh. Space vacuums (Sabres) being piloted by miners is more what I had in mind, as it still would use and respect this proposed system.

Additionally, I kinda think "Astrometrics" belonging to Science (and Science even still existing in its current state) is very extremely meh, as per previous internal discussions about separation of Science tasks, I'd give "Astrometrics" to the bridge as a downtime activity as they currently have very little to do when not in overmap combat.

However, I could imagine something added onto this aspect which does involves miners, namely landing on asteroids containing gasses and placing blast charges on them which when detonating add the asteroid's gas resources to the system, for when there's absolutely no decent supplies around or a boost really is needed.

Blast charges etc is what I believe we should do for just base line mining, our current ultra /TG/ speedzone mining kinda doesn't suit the feel we want.

Also re:Shrike tanks, yeah you put gas miners inside the tanks that hold the gases that are collected from the SM (ie wrong spot). Shrike is essentially already using the air breathing crew and SM crystal as a gas miner.

Karmic-Skink avatar Sep 21 '22 07:09 Karmic-Skink

Is that just an idea you'd like to share, or are you opposed to this PR because you think there could be an even better way, @Karmic-Skink ? Now on to ideasguying from my side: I think it would be cool if gas mining were an active process for the bridge crew, requiring them to fly to a location in the system and press a button. This would mesh well with Karmic's idea of giving the bridge crew more downtime task(s) and the intended moving of the astronometrics computer to the bridge.

Kenionatus avatar Sep 21 '22 08:09 Kenionatus

Firstly, I have my concerns with transportation / throughput unless one gave them like 100 times larger canisters which'd be a bit wacky if damaged or for general use. Many things on NSV guzzle gas and simply sustaining that would probably be quite a bit of tedium

I'd recommend using an internal tank component on a Sabre rather than using standard canisters and using some sort of extraction port/hose to pump it into distro/scrubber networks. Perhaps this needs to be a subvariant of the mining sabre even?

Requiring someone to shaft mine to pick up gasses for the ship will make nobody want to do this. It's honestly more likely the round will stagnate or have the shuttle called on a lowpop round unless someone has already taken shaft miner in place of a more critical role. And hasn't died yet.

Keep gas mining passive per system. Adding some system info on gasses to the astrometrics console would help the bridge staff with route planning.

IndusRobot avatar Sep 21 '22 12:09 IndusRobot

Firstly, I have my concerns with transportation / throughput unless one gave them like 100 times larger canisters which'd be a bit wacky if damaged or for general use. Many things on NSV guzzle gas and simply sustaining that would probably be quite a bit of tedium

I'd recommend using an internal tank component on a Sabre rather than using standard canisters and using some sort of extraction port/hose to pump it into distro/scrubber networks. Perhaps this needs to be a subvariant of the mining sabre even?

Requiring someone to shaft mine to pick up gasses for the ship will make nobody want to do this. It's honestly more likely the round will stagnate or have the shuttle called on a lowpop round unless someone has already taken shaft miner in place of a more critical role. And hasn't died yet.

Keep gas mining passive per system. Adding some system info on gasses to the astrometrics console would help the bridge staff with route planning.

Criticising and rendering judgement on gameplay elements that haven't even been implemented, let alone fully drafted/prototype is ultimately extremely foolish.

We have no idea at this stage whether or not someone can come up with compelling gameplay regarding this feature, or any feature for that matter. What is important however, is the exploration of it becoming actual gameplay elements rather than a passive system, hence the existence of this PR in the first place.

As you have openly stated that you are no longer interested in continuing to support NSV13 development through coding and mapping, please keep statements like these off of Github. Thank you.

Karmic-Skink avatar Sep 21 '22 12:09 Karmic-Skink

Is that just an idea you'd like to share, or are you opposed to this PR because you think there could be an even better way, @Karmic-Skink ? Now on to ideasguying from my side: I think it would be cool if gas mining were an active process for the bridge crew, requiring them to fly to a location in the system and press a button. This would mesh well with Karmic's idea of giving the bridge crew more downtime task(s) and the intended moving of the astronometrics computer to the bridge.

I didn't explicitly say I was against it; I'm advocating for this+

Towards the start of the year when we initiated plans (before I fell off the face of the planet due to work) to overhaul all of mining, gas mining was indeed part of this plan, and we had concluded that explorations into actual gameplay mechanics that players performed was ideal, rather than being passive.

So no, this isn't exactly ideasguying, this is attempting to explore plans discussed by leads.

Karmic-Skink avatar Sep 22 '22 00:09 Karmic-Skink

These two miners shouldn't be there as they are already being mined from the CO2 SM interaction. The nitrogen however isn't being generated.

Gotcha, those two miners have been removed.

Additionally, I kinda think "Astrometrics" belonging to Science (and Science even still existing in its current state) is very extremely meh, as per previous internal discussions about separation of Science tasks, I'd give "Astrometrics" to the bridge as a downtime activity as they currently have very little to do when not in overmap combat.

I like the concept of astrometrics encouraging interaction between bridge and science (and possibly others), since science usually tends to be mostly self-contained excluding yelling at miners, which also are on science comms. If science is removed as a department (or fundamentally changed), handing the console to bridge would be something to do, but currently science being the ones to scan things makes sense imo. Although considering it a possible downtime activity for bridge instead of science makes sense too.

These aren't mutually exclusive options, "ice asteroids" are only one solution, and not what I had in mind tbh. Space vacuums (Sabres) being piloted by miners is more what I had in mind, as it still would use and respect this proposed system.

I prefer the main ship having a direct option to collect gasses over sabres being the middleman.. If sabres could still jump independantly, it'd be nice to have so they could go on supply runs, but since they're tethered these days not so much (They could stay behind a while with the main ship moving on I guess, but meeh) Miners being able to support gas mining via. blasting ice rocks or similar is something I'd like for the future though, as opposed to sabres being always neccessary for it.

DeltaFire15 avatar Oct 11 '22 15:10 DeltaFire15

Base features of this should be good-ish enough to gauge player reactions, though as said the starmap config needs aforementioned adjustment for it to be more interesting than veery system starting empty. Also testing (and generally) SHOULD be on a map that contains a unmapped space (aka brazil) cluster since that is where randomness comes into play.

DeltaFire15 avatar Oct 11 '22 15:10 DeltaFire15

I prefer the main ship having a direct option to collect gasses over sabres being the middleman.. If sabres could still jump independantly, it'd be nice to have so they could go on supply runs, but since they're tethered these days not so much (They could stay behind a while with the main ship moving on I guess, but meeh) Miners being able to support gas mining via. blasting ice rocks or similar is something I'd like for the future though, as opposed to sabres being always neccessary for it.

Thoughts on having the bridge bagels having to directly pilot the ship onto "space gas" pockets then? Gas is gathered at an ultra-slow rate as per system type (and generated gas tables) unless the ship is sitting on one of the pockets?

Kinda like Elite Dangerous etc?

Karmic-Skink avatar Oct 12 '22 08:10 Karmic-Skink

Thoughts on having the bridge bagels having to directly pilot the ship onto "space gas" pockets then? Gas is gathered at an ultra-slow rate as per system type (and generated gas tables) unless the ship is sitting on one of the pockets?

Kinda like Elite Dangerous etc?

Mh, that is something I thought about, would have to think of a good way to handle that without more "check every tick" like collisions are. And would need sprites since it'd need to be visible. But generally nothing I'd be opposed to.

DeltaFire15 avatar Oct 13 '22 19:10 DeltaFire15

would have to think of a good way to handle that without more "check every tick" like collisions are.

How about some kind of "start" button. Then you only need to check for overlap with a gas cloud once. Alternative would be to have a component added to gas cloud that listens for the signal when something enters the gas cloud (if that works for overmap objects)

Kenionatus avatar Oct 13 '22 21:10 Kenionatus

Basically, we want to encourage gameplay wherever possible.

Karmic-Skink avatar Oct 17 '22 07:10 Karmic-Skink

This pull request has conflicts, please resolve those before we can evaluate the pull request.

github-actions[bot] avatar Nov 01 '22 22:11 github-actions[bot]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

github-actions[bot] avatar Jan 25 '23 07:01 github-actions[bot]

How different are clouds to regular streams of gas?

williamcll avatar Jul 31 '23 00:07 williamcll

How different are clouds to regular streams of gas?

Hm? Basically, you have to seek out places with gasses (or make your own) instead of any ship with miners having an infinite free supply. Some locations can be very difficult to exhaust, but require coordination to navigate to for a resupply, which adds interdepartmental coordination between engi and bridge (and sci because you can see supply in all scanned systems as opposed to only the own) The access point exists to add a little more to it than having access anywhere insystem. Some more deeper things do not yet exist, since this version was intended to first run a test to see how well it does at replacing infinite miners with an useful alternative. Except I kind of died thinking about balancing & seeding of flexible resources in a static galaxy (which is the final neccessary step pre preliminary test) so it has been sitting here in stasis collecting merge conflicts.

DeltaFire15 avatar Aug 04 '23 11:08 DeltaFire15

How different are clouds to regular streams of gas?

Hm? Basically, you have to seek out places with gasses (or make your own) instead of any ship with miners having an infinite free supply. Some locations can be very difficult to exhaust, but require coordination to navigate to for a resupply, which adds interdepartmental coordination between engi and bridge (and sci because you can see supply in all scanned systems as opposed to only the own) The access point exists to add a little more to it than having access anywhere insystem. Some more deeper things do not yet exist, since this version was intended to first run a test to see how well it does at replacing infinite miners with an useful alternative. Except I kind of died thinking about balancing & seeding of flexible resources in a static galaxy (which is the final neccessary step pre preliminary test) so it has been sitting here in stasis collecting merge conflicts.

So is it like old bee Gas harvesting on lavaland? Where I bring a canister and a RPED to a roid to siphon on tile plasma?

williamcll avatar Aug 05 '23 05:08 williamcll

all space turfs should have the system's gas as its atmos at like 0.5kpa or something

Addust avatar Aug 18 '23 15:08 Addust

all space turfs should have the system's gas as its atmos at like 0.5kpa or something

No. Only exception where I could justify it existing would be gas nebulae, and there it'd still be a major overhead in atmos by space no longer being a "zero" mixture and also needing to be adjusted on jump.

DeltaFire15 avatar Aug 18 '23 16:08 DeltaFire15

all space turfs should have the system's gas as its atmos at like 0.5kpa or something

No. Only exception where I could justify it existing would be gas nebulae, and there it'd still be a major overhead in atmos by space no longer being a "zero" mixture and also needing to be adjusted on jump.

make all space turfs refer to the same atmos list thingymajig

Addust avatar Sep 01 '23 21:09 Addust

One day I'll get to pick this up again, but for now there is no reason for it to be cluttering open PRs. Thus, into cryosleep it goes. Sleep well.

DeltaFire15 avatar May 14 '24 05:05 DeltaFire15