Suggestions Thread for v2.4.0

[Kiero]

Ability to delete prototypes tech (P) from Ship Design Window.

You can either set them to be obsolete or if you create a research project for them you can then delete them from the research tab.

That is the reason behind the suggestion.

[nuclearslurpee]

Ability to delete prototypes tech (P) from Ship Design Window.

You can either set them to be obsolete or if you create a research project for them you can then delete them from the research tab.

That is the reason behind the suggestion.

Prototypes can also be deleted in the Research window if you check the radio button for Completed projects.

However this is an annoying and unintuitive way to do it, so I would rather have a way to get rid of prototypes from the ship design window without having to mark as Obsolete and clutter the components list in the DB or when inspecting obsolete components.

[Kiero]

Since Genetic Modification Centres are now working, it might be useful to define the Species of Commanders and Ground Formations?

Genetic Wars.... 

[paolot]

Don't know if already suggested.
In the Galactic Map, it would be nice to see where the ground units are.
Thanks!

[Oafsalot]

I'm sure this one has been brought up a few times by now -

We need a way to search and locate Systems on the Galactic map. I have 150 systems, it can sometimes take a while to track down a system by name alone. Often I have to take several passes at the galaxy to find one system. Maybe also interface with the Mineral Survey Window and snap to a system on double click.

[pedter]

I'm sure this one has been brought up a few times by now -

We need a way to search and locate Systems on the Galactic map. I have 150 systems, it can sometimes take a while to track down a system by name alone. Often I have to take several passes at the galaxy to find one system. Maybe also interface with the Mineral Survey Window and snap to a system on double click.

361 systems and climbing reporting in; I'll echo this suggestion but also add my own: bringing back zooming in/out on the galaxy map (it existed for VB6) would be amazing.

[Droll]

I'm sure this one has been brought up a few times by now -

We need a way to search and locate Systems on the Galactic map. I have 150 systems, it can sometimes take a while to track down a system by name alone. Often I have to take several passes at the galaxy to find one system. Maybe also interface with the Mineral Survey Window and snap to a system on double click.

361 systems and climbing reporting in; I'll echo this suggestion but also add my own: bringing back zooming in/out on the galaxy map (it existed for VB6) would be amazing.

This would also be worthwhile for the "Autoroute" checkbox on the ship movement screen. It would be nice to be able to just type the name of the system I want the fleet to go to.

[vorpal+5]

A display option where civilian ships are shown only as blue dots, no writing at all, so we still get a feeling of a live universe, without much clutter.

[pedter]

I'm sure this one has been brought up a few times by now -

We need a way to search and locate Systems on the Galactic map. I have 150 systems, it can sometimes take a while to track down a system by name alone. Often I have to take several passes at the galaxy to find one system. Maybe also interface with the Mineral Survey Window and snap to a system on double click.

361 systems and climbing reporting in; I'll echo this suggestion but also add my own: bringing back zooming in/out on the galaxy map (it existed for VB6) would be amazing.

This would also be worthwhile for the "Autoroute" checkbox on the ship movement screen. It would be nice to be able to just type the name of the system I want the fleet to go to.

You can actually sort of do this already: if you check "autoroute" then click into the box with the list of systems (it needs to be the section in focus) and start typing, the list jumps to the first system that matches the order of the characters you type. It's not a search box so has no real feedback for the user (nor does it announce that it can do so in the first place)

More importantly, adding a suggestion: autoroute currently selects the shortest route by jumps instead of the shortest route by distance and travel time; this results in some hilariously bad autoroutes. I have a black hole in my main pipeline that if I manually add two extra jumps to enter the black hole via a different jump point I can shave dozens of billions of kilometers (6-8 weeks at 5,000km/s) off the distance and travel time. Exhibit A:

Earth to Beta Antliae in-gate:
Autoroute: 5 jumps, 48.9bkm, 113 days at 5,000km/s
Manually via Proxima Centauri: 7 jumps, 25.0bkm, 58 days at 5,000km/s
Changes: +2 jumps, -23.9bkm, -55 days (-48.7% distance and travel time)

[nuclearslurpee]

More importantly, adding a suggestion: autoroute currently selects the shortest route by jumps instead of the shortest route by distance and travel time; this results in some hilariously bad autoroutes. I have a black hole in my main pipeline that if I manually add two extra jumps to enter the black hole via a different jump point I can shave dozens of billions of kilometers (6-8 weeks at 5,000km/s) off the distance and travel time. Exhibit A:

Steve has said in the past he won't change this as it adds too much complication for his tastes (pathfinding for one thing, but also dealing with things like Lagrange points). In I think v1.13 or 2.0, he did add the ability to restrict jump points so they won't be used for auto-routing because of these situations.

[Sparkles546]

A target population option on the colony page where you set whether it's a source of colonist or not, or whether it stays stable.  Idea is when you select "destination of colonists", you can put in a target amount which when reached automatically swaps the status over to stable.  Could also put this box under the "source of colonists" option, with the number being a minimum population that when the colony reaches will swap the selection to stable again.  Would help avoid the issue of accidentally emptying earth or your bigger colonies when settling new planets with big population caps.

[nuclearslurpee]

Several suggestions related to the logistical Hub modules:

1) Reduce costs and sizes of Refuelling Hub and Ordnance Transfer Hub.

Currently, the costs and sizes of the Hub modules are ridiculously out of proportion to their benefits. The Refuelling Hub is 200 times as large, and 240 times as costly, as the basic 50,000 LPH Refuelling System, and the Ordnance Transfer Hub is similarly out of proportion with respect to the Ordnance Transfer System. Unless players are regularly trying to refuel or reload ~200 ships at once, there is no way these systems are worth their costs outside of a very narrow use case where a very large fleet must be refueled in a very big hurry, and even then it is probably more cost-effective to have a fleet of numerous small-to-medium tankers with regular Refuelling/Ordnance Transfer Systems.

If the size is desired to remain the same to limit these modules to space stations only (but why?), then the cost should still be reduced to make these kinds of stations economically feasible.

I currently reduce the size and cost of both Hubs by a factor of 10 and this at least makes them usable, if not necessarily economical.

2) Introduce a Cargo Shuttle Hub component.

This is a minor thing, but it would be neat to have a hub module for MSP transfer/resupply to match refueling and reloading. Could also be useful at DSPs for inter-ship cargo transfer hub stations.

3) Allow "Refuel at Refuelling Hub" conditional orders to function with Refuelling Systems.

The main motivation here is to enable smoother automation of survey ships. Survey ships are, I would guess, the primary users of the refueling conditional orders, and they usually operate individually, so it is silly that we cannot simply position a tanker at a suitable position in space to handle this. If suggestion (1) is taken the problem becomes less drastic, but it is still IMO very silly and even requiring a 10,000 ton module for tankers that are ~45,000 tons is not practical.

4) Allow Hubs to function like their associated smaller systems and transfer materials to colonies.

Per this comment. Again, it is a rather silly limitation, albeit easy enough to work around for the cost of +10 BP and +500 tons on an already large vessel, so admittedly this one is not very urgent.

[bean]

Drawing on my recent analysis of the missile changes, I think there's some room to tweak how the new EW system (which I like quite a lot on the whole) works.  Specifically, as of right now, if the levels of systems are equal, one or the other is completely useless, and that seems kind of weird.  For beams, sensors and missile hit probability, there is no difference between having ECM at the same level as the ECCM and having no ECM at all, which somewhat disincentivizes the use of ECM.  For decoys of both kinds, there's no difference between having ECCM at the same level as the ECM and having no ECCM, which seems even weirder.  Level 5 decoys are just as effective against a level 5 ECCM as level 10 decoys are against a system without any ECCM?  If nothing else, this strongly disincentivizes putting ECCM on AMMs, because you are wasting space if the target either has no decoys or has decoys of equal or greater level.

My basic suggestion is to have equal levels fall in the middle of effectiveness.  Say, give jammers a +1 to effective level, so an even ECM vs ECCM shows 80% of normal performance.  It's an edge to ECM, but not an overwhelming one.  For decoys, instead of capping effectiveness if ECM has an edge, why not let it keep having a bigger edge?  Or if that's too much, change the benchmark for full performance from equal levels to a level or two of ECM overmatch.  So maybe if you're shooting 5 ECM decoys vs 5 ECCM, each decoy looks like size 3 instead of size 5.

[nuclearslurpee]

My basic suggestion is to have equal levels fall in the middle of effectiveness.  Say, give jammers a +1 to effective level, so an even ECM vs ECCM shows 80% of normal performance.  It's an edge to ECM, but not an overwhelming one.  For decoys, instead of capping effectiveness if ECM has an edge, why not let it keep having a bigger edge?  Or if that's too much, change the benchmark for full performance from equal levels to a level or two of ECM overmatch.  So maybe if you're shooting 5 ECM decoys vs 5 ECCM, each decoy looks like size 3 instead of size 5.

I do generally agree that the ECM/ECCM calculations could use a bit more nuance. I also think how to achieve that nuance is trickier than it seems. One simple change could be to leverage research costs to generate a "pseudo-balance" in ECM vs ECCM at the strategic level.

To wit: currently, ECCM costs twice as much as ECM for a given level, e.g., ECM-1 (2) costs 2500 (5000) RP while ECCM-1 (2) costs 5000 (10000) RP. While this doesn't solve all of the mathematical consistency issues discussed above and in previous suggestions, it does in principle create a strategic-level situation in which there is an advantage to having ECM since the ECCM of the same level is more expensive to research.

The catch is that this doesn't currently work out in practice, because we have three tech lines for ECM but only one for ECCM (not counting some of the techs in the Missile category, which alter some of the numbers but don't change the main point I'm making). So developing a complete set of level-1 (2) ECM capabilities costs 7500 (15000) RP which is more than the total RP cost for the same level of ECCM, so ECCM actually becomes more economical than ECM of the same level - which I don't think is the desired result.

So a suggestion to maintain a strategic balance where ECM is valuable is to have one corresponding ECCM line per ECM line. So Missile Jammer ECM is countered by a Missile ECCM line, Sensor Jammer ECM is countered by a Sensor ECCM line, and Fire Control Jammer ECM is countered by a Fire Control ECCM line.

Again, this doesn't address the mathematical consistency issues, but it may be a simpler change which creates much of the desired effect in practice. Then Steve and the good math nerds of this forum can hash out the other problems at a leisurely pace.

[vorpal+5]

A request: when producing ground units, instead of having a hidden counter that the game uses to determine what numeral to use, expose it as an edit field. For example, if I build 16 construction brigades but then update them to a better model, the game will restart at 1st while I want it to continue to 17th. With an edit field, we could change that.