Suggestions Thread for v2.0

[nuclearslurpee]

Seems like a flat buff doesn't really have any of the nuance you claim it does.

I'm not sure how you get that from what I've said. 

[jatzi]

Idk if this is the best place to suggest stuff anymore for 2. 2 but it'd be a nice little QoL feature to have populated systems be highlighted when you go to select a system to view on the left side of the screen.  The big drop down box.  After awhile it'll grow to be quite the list and it can be hard sometimes to quickly pick out the systems you might want to look at

[mike2R]

Idk if this is the best place to suggest stuff anymore for 2. 2 but it'd be a nice little QoL feature to have populated systems be highlighted when you go to select a system to view on the left side of the screen.  The big drop down box.  After awhile it'll grow to be quite the list and it can be hard sometimes to quickly pick out the systems you might want to look at

That would be useful.  What I normally do is rename important systems to have a space at the front, which sorts them at the top of the list (and generally give Sol two spaces to put it right at the top).

[lumporr]

Idk if this is the best place to suggest stuff anymore for 2. 2 but it'd be a nice little QoL feature to have populated systems be highlighted when you go to select a system to view on the left side of the screen.  The big drop down box.  After awhile it'll grow to be quite the list and it can be hard sometimes to quickly pick out the systems you might want to look at

That would be useful.  What I normally do is rename important systems to have a space at the front, which sorts them at the top of the list (and generally give Sol two spaces to put it right at the top).

Another option is to have a System naming convention that organizes the list somewhat. I generally do [Number of jumps from Sol][Letter of first jump in branch]-[System Name], so it goes 0-Sol, or 1A-Alpha Centauri, or 1B-Barnard's Star, or 2A-Proxima Centauri for a system down the Alpha Centauri line. That way, all the close stuff is at the top, all the far stuff is at the bottom, branches are grouped together, and systems you haven't gotten around to taking a look at and renaming are at the very bottom. That being said, it would be nice to have populated systems highlighted in green or something, especially since I don't always want to use my naming convention.

[Jorgen_CAB]

Idk if this is the best place to suggest stuff anymore for 2. 2 but it'd be a nice little QoL feature to have populated systems be highlighted when you go to select a system to view on the left side of the screen.  The big drop down box.  After awhile it'll grow to be quite the list and it can be hard sometimes to quickly pick out the systems you might want to look at

That would be useful.  What I normally do is rename important systems to have a space at the front, which sorts them at the top of the list (and generally give Sol two spaces to put it right at the top).

Another option is to have a System naming convention that organizes the list somewhat. I generally do [Number of jumps from Sol][Letter of first jump in branch]-[System Name], so it goes 0-Sol, or 1A-Alpha Centauri, or 1B-Barnard's Star, or 2A-Proxima Centauri for a system down the Alpha Centauri line. That way, all the close stuff is at the top, all the far stuff is at the bottom, branches are grouped together, and systems you haven't gotten around to taking a look at and renaming are at the very bottom. That being said, it would be nice to have populated systems highlighted in green or something, especially since I don't always want to use my naming convention.

I do something very similar to this and even a bit further. I use some form of coordinate system so I know where a system is (roughly) on the galaxy map and then systems are sorted in the lost appropriately.

I base it on my sectors and the have a coordinate system going from there based on if the planet is up, down, left or right from the sector seat system.



This also makes each system very easy to find on the Galaxy map and makes everything easier to find in general. Adding a space or more before systems also sort important system to the top of the list which helps.

[serger]

It would be cool to have a checkbox for every racial name scheme designating if it's a scheme for a hereditary elite officers - for example, primarchs and their descendants in WH4K - so they'll have both "prominent" stats from the birth and their own naming schemes (the player will have an option to dilute this elites with any desirable percent of usual blockhead offspring by adding the same name scheme with a modified title and then add it without elite checkbox).

[mike2R]

Idk if this is the best place to suggest stuff anymore for 2. 2 but it'd be a nice little QoL feature to have populated systems be highlighted when you go to select a system to view on the left side of the screen.  The big drop down box.  After awhile it'll grow to be quite the list and it can be hard sometimes to quickly pick out the systems you might want to look at

That would be useful.  What I normally do is rename important systems to have a space at the front, which sorts them at the top of the list (and generally give Sol two spaces to put it right at the top).

Another option is to have a System naming convention that organizes the list somewhat. I generally do [Number of jumps from Sol][Letter of first jump in branch]-[System Name], so it goes 0-Sol, or 1A-Alpha Centauri, or 1B-Barnard's Star, or 2A-Proxima Centauri for a system down the Alpha Centauri line. That way, all the close stuff is at the top, all the far stuff is at the bottom, branches are grouped together, and systems you haven't gotten around to taking a look at and renaming are at the very bottom. That being said, it would be nice to have populated systems highlighted in green or something, especially since I don't always want to use my naming convention.

I do something very similar to this and even a bit further. I use some form of coordinate system so I know where a system is (roughly) on the galaxy map and then systems are sorted in the lost appropriately.

I base it on my sectors and the have a coordinate system going from there based on if the planet is up, down, left or right from the sector seat system.

This also makes each system very easy to find on the Galaxy map and makes everything easier to find in general. Adding a space or more before systems also sort important system to the top of the list which helps.

I did try prefix naming at one point, but the system I used was rather unwieldy and ended up looking ugly.  That looks a lot cleaner.

One thing that has worked quite well is naming systems with their first letter based on how far they are from Sol.  One jump away starts with an 'A', 2 jumps is a 'B'.  And then using a different naming scheme for major branches - so everything through one of Sol's wormholes is named after European cities, and another is Space Marine chapters or whatever.  The combination of the two systems makes it pretty easy to figure out where a system is based on its name.

[Voltbot]

I was thinking lately about a possible active stealth system.

The idea is to make ship system, that allows ship to completely disappear from sensors (not only active) for some time. During that time cloaked ship cannot engage enemies (eg. no detection, no boarding and no shooting). It could also have a timer (eg. Game would force this ship to decloak after some time), some recharge time (which might use powerplants from the ship, making it less effective in combat for some time) and/or giving the ship jumpshock after exiting.

It would make JP assault and commerce raiding more viable.
This idea is actually quite common in different games, so I wouldn't be surprised if someone already suggested it, but I'm to lazy to read all pages of this thread.

[nuclearslurpee]

I was thinking lately about a possible active stealth system.

The idea is to make ship system, that allows ship to completely disappear from sensors (not only active) for some time. During that time cloaked ship cannot engage enemies (eg. no detection, no boarding and no shooting). It could also have a timer (eg. Game would force this ship to decloak after some time), some recharge time (which might use powerplants from the ship, making it less effective in combat for some time) and/or giving the ship jumpshock after exiting.

It would make JP assault and commerce raiding more viable.
This idea is actually quite common in different games, so I wouldn't be surprised if someone already suggested it, but I'm to lazy to read all pages of this thread.

You run into a couple of problems with that.

One is from the lore/"realism" side of things. Outside of soft/fantasy sci-fi, stealth is not really possible in space as there is no way to hide the significant radiation a ship puts out even if it is not running active sensors, due to the fact that space has next to zero density (=no signal attenuation) and temperature (=no thermal background). Now, in principle you can hand-wave this as soft sci-fi always does, but given the fact that Aurora already has "hard" stealth (i.e., reduced radar cross section) as well as thermal signature reduction, it doesn't seem to fit the lore well to introduce some "soft" mechanism for total stealth - in theory you can of course come up with some explanation, but it would seem to clash with the tone the rest of the game has established.

The other issue is game balance, not in terms of minimax or being blatantly OP but rather from the game design perspective. If we introduce a mechanic which can render JP assault and defense basically moot, that's bypassing a significant core element of the game's design. Commerce raiding is one thing; sneaking a million tons of heavily-armed warships past a thick JP defense to lay waste to an enemy's vulnerable core systems is another. We have to think beyond just this mechanic, for example what kind of counterplay will a player (or NPR!) have against this tactic? An enemy who can show up anywhere, anytime, in great force is a big step up from the Raiders, which at least follow a predictable pattern of escalation that allows counterplay. Should we add anti-stealth tech? If so, how do we implement this in a way that doesn't trivialize stealth or create an arms race of must-have-X-to-counter-Y like how ECM prior to 2.2 has worked? And importantly, how can the NPRs handle this? It's easy to say "if this tactic is too exploitative, the player can just not use it", but then why add a new mechanic to the game if the player will just not use it because the NPR can't handle it?

These are not insurmountable problems, but I do think trying to solve these problems in Aurora specifically may be more work than it is worth, both for Steve and also for keeping the general philosophy and spirit of Aurora. In other words: total stealth may be a good idea in and of itself (I should hope it is, if many other games have done it!), but that doesn't mean it is a good idea for Aurora in particular.

[Jorgen_CAB]

In terms of stealth I think that Steve once said that ships drives are not really using normal space to propel the ship but is taking advantage of some other substance not really in this plane of existance. He also said that this could be used to also formulate some true cloaking abilities or submarine like effects in space where ships can move through and submerge more fully into this subspace.

So... from a lore perspective stealth should be able to work, the question is how it will work.

Personally I would like to have a mechanic that can take ships undetected through jump points and back, but it need to be sufficiently expensive and unpractical you can't reasonably base an entire fleet doctrine around it. Much in the same way you can't use an entire submarine fleet in the real world as that just is not practical.

[Scandinavian]

Maybe they don't need to be undetected.

We already have a way to get into an unfriendly system through a lightly defended jump point: Squadron jumping through and then peeling off like a bat out of Hell. (Maybe we should have a "move directly away from target" command, so we can set up to move away in the same direction as the squadron jump offset immediately.) The trick to raiding is getting back out again without getting got, because you have to move all the way up to the jump point to exit the system.

But what if you didn't? What if you could squadron jump with an offset from the outbound JP as well? If the JP has a deep, layered defense then it won't help, of course, but... that's probably fine. It means the defenders have to be separated out to a range where they are not in easy beam support range of each other.

To further help the raiders get out, you could imagine a "jump homing beacon" ship component; a military component that you put on a ship that sits on the destination jump point, and which multiplies the outbound offset limit by 1 + [multiplier]*MAX(1, [component size]/[size of jumping vessel]).

So if you have a 5 thousand ton raider with a jump drive capable of 250 thousand km squadron jump offset, then it would squadron jump in the normal way, run away from the jump point picket, murder some merchant shipping, and come back toward the jump point. If you now have a jump tender sitting on the home side of the jump point with a 5000 ton multiplier 3 jump beacon, the raider could evacuate from a JP offset of 1 million km. With a 2500 ton beacon sitting on the other side, it'd have to get to within 500 thousand km, and with no return beacon, it would have to get to 250 thousand km.

It won't help your raiders if the jump point picket has some missile ships with a fifty million km range and sensor coverage and enough weight of fire to just swat your raider out of the sky sitting 25 million m away from the JP. But in that case the defender has made a strategic decision to expend part of the resources available for the JP picket to protect against raiders rather than build a brick wall for your battle fleet to beat itself silly against when it tries to force the JP in force. Which still is a way for your raider doctrine to impose costs on the JP defense doctrine of the other side.

[IronRagnar]

Hey, i don't know if this was suggested before or not but could we have a button to remove an awarded medal?

[Jorgen_CAB]

Maybe they don't need to be undetected.

We already have a way to get into an unfriendly system through a lightly defended jump point: Squadron jumping through and then peeling off like a bat out of Hell. (Maybe we should have a "move directly away from target" command, so we can set up to move away in the same direction as the squadron jump offset immediately.) The trick to raiding is getting back out again without getting got, because you have to move all the way up to the jump point to exit the system.

But what if you didn't? What if you could squadron jump with an offset from the outbound JP as well? If the JP has a deep, layered defense then it won't help, of course, but... that's probably fine. It means the defenders have to be separated out to a range where they are not in easy beam support range of each other.

To further help the raiders get out, you could imagine a "jump homing beacon" ship component; a military component that you put on a ship that sits on the destination jump point, and which multiplies the outbound offset limit by 1 + [multiplier]*MAX(1, [component size]/[size of jumping vessel]).

So if you have a 5 thousand ton raider with a jump drive capable of 250 thousand km squadron jump offset, then it would squadron jump in the normal way, run away from the jump point picket, murder some merchant shipping, and come back toward the jump point. If you now have a jump tender sitting on the home side of the jump point with a 5000 ton multiplier 3 jump beacon, the raider could evacuate from a JP offset of 1 million km. With a 2500 ton beacon sitting on the other side, it'd have to get to within 500 thousand km, and with no return beacon, it would have to get to 250 thousand km.

It won't help your raiders if the jump point picket has some missile ships with a fifty million km range and sensor coverage and enough weight of fire to just swat your raider out of the sky sitting 25 million m away from the JP. But in that case the defender has made a strategic decision to expend part of the resources available for the JP picket to protect against raiders rather than build a brick wall for your battle fleet to beat itself silly against when it tries to force the JP in force. Which still is a way for your raider doctrine to impose costs on the JP defense doctrine of the other side.

In my opinion this don't work well as a mechanic since it is too easy to counter it with just having some missiles which every JP defence should have in some form or another.

The point is they can get in undetected and you don't know about it, it also will force a more spread out defence network as an enemy raider can appear anywhere.

Such a system just have to be very expensive to use, especially while moving. It might require some very special drives that once used in this mode is using up 100 times the amount of fuel and can only move at half speed. So you can't use the cloak all the time or you will not really be able to go anywhere.

It also would be good to break up the meta of throwing tons of missiles at an opponent with box launchers. An opponent might have a cloak and can just disappear and make their entire missile swarm completely wasted and now you are vulnerable for a counter attack. It also would make beam weapons very important too. Although there might need to be an initiation time for engaging the cloak so missiles are not entirely useless.

[xenoscepter]

 --- Some random ideas I had:

 --- Regarding missile changes, the removal of missile agility ruffled quite a few feathers it seems, but I've given it a lot of thought and I think... after playtesting, that an avenue to reinstate it, IF NEEDED, could be as such:

 --- Missile Agility is rebranded to Missile Guidance. It has the same tech line as agility. Mechanically, the rebranded agility scales up with the missile, and the tech line, rather than giving more agility per msp dedicated to it, governs the agility cap. So bigger missiles would have more innate agility, but not more than the cap. Meanwhile, smaller missiles would need to add msp into guidance, and would still end up being capped by the tech. So, basically, if Missile Guidance Cap, the replacement for Missile Agility per MSP, was 16, a missile could never have more than 16 regardless of size or MSP invested, and bigger missiles would have more agility to start with, thus needing less MSP to get the same agility.

 --- Regarding beam ships:

 --- It struck me that a form of "Capacitor Bank" might be a helpful thing for diversify beam ship designs. Basically, this component would derive it's efficiency from the Capacitor tech. It would then incur a power requirement, like a beam weapon would, and would charge like a beam weapon too. The capacitor would discharge as part of the beam weapon firing phase, just like a beam weapon would, however, it would distribute it's available energy evenly across all beam weapons that are firing. This would work more or less identically to how power plants distribute their power, following the same priorities. The caveat is that these aren't power plants, but capacitors, and so count as extra capacitors for the purposes of weapon RoF.

 --- So for example, a weapon has 25 capacitors, and a RoF of 10s. A single capacitor bank of 25 would give it a 5s RoF instead. Another example, Three weapons with 10 capacitor and a 20s RoF with a single 15 capacitor bank would instead have a 15s RoF each. I'll do an effort post later, in it's own thread. Questions or thoughts are welcome in the meanwhile.

[Steve Walmsley (OP)]

--- Some random ideas I had:

 --- Regarding missile changes, the removal of missile agility ruffled quite a few feathers it seems, but I've given it a lot of thought and I think... after playtesting, that an avenue to reinstate it, IF NEEDED, could be as such:

 --- Missile Agility is rebranded to Missile Guidance. It has the same tech line as agility. Mechanically, the rebranded agility scales up with the missile, and the tech line, rather than giving more agility per msp dedicated to it, governs the agility cap. So bigger missiles would have more innate agility, but not more than the cap. Meanwhile, smaller missiles would need to add msp into guidance, and would still end up being capped by the tech. So, basically, if Missile Guidance Cap, the replacement for Missile Agility per MSP, was 16, a missile could never have more than 16 regardless of size or MSP invested, and bigger missiles would have more agility to start with, thus needing less MSP to get the same agility.

I already added something on those lines:
http://aurora2.pentarch.org/index.php?topic=13090.msg164114#msg164114