Official Suggestion Thread for 5.20 or later

[sloanjh]

Not sure if this has come up but a "R&R" order for locations capable of providing such to ships - the ship sits there until the crew months hits 0. 

Emphatically seconded.

John

[MehMuffin]

This might have come up before, but I have a few missile design thing's I'd like to have added. It would be really cool to see secondary and primary warheads and the like, so we could have staggered missile detonations, and ejectable warheads that would maintain momentum, and a few more parameters for stage change. Specifically, I'd like to be able to make it so that my missiles will eject their warheads ahead of them if they are targeted by anything so that either the second stage can detach before it's too late or if we're very close to the target the warheads can simply be separated, so that they lose all guidance but keep going even if the body of the missile is destroyed. Finally, if we could deploy a part of a missile before the rest of it hit, it would be neat, moreover, if a missile could launch a sort of "breaching charge" ahead of it, say a size 4 warhead, that would detonate, and then the main, say size 9, warhead would detonate at the center of its crater to maximize armor penetration .

[ardem]

This might have come up before, but I have a few missile design thing's I'd like to have added. It would be really cool to see secondary and primary warheads and the like, so we could have staggered missile detonations, and ejectable warheads that would maintain momentum, and a few more parameters for stage change. Specifically, I'd like to be able to make it so that my missiles will eject their warheads ahead of them if they are targeted by anything so that either the second stage can detach before it's too late or if we're very close to the target the warheads can simply be separated, so that they lose all guidance but keep going even if the body of the missile is destroyed. Finally, if we could deploy a part of a missile before the rest of it hit, it would be neat, moreover, if a missile could launch a sort of "breaching charge" ahead of it, say a size 4 warhead, that would detonate, and then the main, say size 9, warhead would detonate at the center of its crater to maximize armor penetration .

This is a personal view point not a dismissive of your post. All ideas are valid, but I have some concerns over the logic translation.

The main problem around this game is not modelled on Newtonian, which means these warhead would miss as the spaceships, which zip around without inertia. meaning every warhead would be a miss.

As for the breaching charge since spaceships move so fast and also without inetia, the charges need to be very close together to hit the same spot. But since all warheads are nuclear this would knock out the other missiles, actually the only way I thought salvos would work if all are synced to detonate at the same time.

In a Newtonian game these ideas would be valid and work with the game system however with the current model I don't think my head could wrap around it.

[chrislocke2000]

Being a great fan of fighters it would be great to have a way to upgrade my fighters in the same way that I can my ships. As it stands if I want to improve the sensors on a fighter due to improved tech I have to basically retire all my old fighters, build completley new ones and then train those crews all over again. This typically leaves me with a pile of carriers with great fleet training skills and bonus stuffed full of rookie pilots whilst my best guys are left to rot on a planet somewhere as a reserve.

Perhaps could be done as a fighter engineering deck rather than a hanger deck and then use the normal refit mechanic as per shipyards.

[Person012345]

I am pretty sure it is not so.
every technology has a RP cost. every lab generates a flat amount of RP, influenced by research rate tech and scientist bonus. every 5-day the generated RP are substracted from the needed RP. Once RP needed is 0 - you got your tech(+- 5 days).

It is so because of how it's linear. Note he said that the time gained decreases. If you have 1 lab and it will take you 100 days to research a tech, adding 1 lab nets you a 50 day reduction, down to 50 days. Now you have 2 labs working on it and it takes you 50 days to complete. Now, adding another 2 full labs will only get you a reduction of 25 days. Of course, once you get below 5 days (assuming 5 day construction cycle) then adding more labs does nothing.

That doesn't mean it's less efficient though, he's wrong for insinuating that. If you have 4 labs, and 4 projects, each of which takes 1 lab 100 days to complete, you can either spread out the 4 labs, one to each project, in which case the 4 projects will all take 100 days to complete, and will complete at the same time, or you can dump all 4 labs on one project to complete it in 25 days, then do that 3 more times, and all the projects are still completed in 100 days. Or you can give 2 projects 2 labs each and everything will still take 100 days to complete.

[bean]

In the aftermath of posting my BSPDC-1 design (see Bureau of Ship Design) I've been pondering the PPV rating.  The design is a bunch of 15cm C1 mesons in a PDC, for the cheapest possible source of PPV.  I don't normally try to game the system like that, but it was a reaction to the fact that PPV does not scale at all with tech level, and at the tech level I was at, stuff was really expensive. 
People would rather be defended by a ship with 5 10cm C1 IR lasers and nuke thermal drives than one with 4 10cm C3 UV lasers and, say, ion drives.  One easy way to mitigate this problem (and I know that some of the problem is intentional, as the general public doesn't understand warfare all that well) is to add the power requirement to the PPV value.  Power requirement is a reasonably accurate indicator of actual beam firepower (except for gauss cannons, but I'm trying to keep this simple and (hopefully) easy to implement).  I'm still trying to think of a similar metric for missiles.  It would probably be based on rate of fire (time-averaged throw weight?) to aid higher-tech systems some.

[ardem]

It is so because of how it's linear. Note he said that the time gained decreases. If you have 1 lab and it will take you 100 days to research a tech, adding 1 lab nets you a 50 day reduction, down to 50 days. Now you have 2 labs working on it and it takes you 50 days to complete. Now, adding another 2 full labs will only get you a reduction of 25 days. Of course, once you get below 5 days (assuming 5 day construction cycle) then adding more labs does nothing.

That doesn't mean it's less efficient though, he's wrong for insinuating that. If you have 4 labs, and 4 projects, each of which takes 1 lab 100 days to complete, you can either spread out the 4 labs, one to each project, in which case the 4 projects will all take 100 days to complete, and will complete at the same time, or you can dump all 4 labs on one project to complete it in 25 days, then do that 3 more times, and all the projects are still completed in 100 days. Or you can give 2 projects 2 labs each and everything will still take 100 days to complete.

This is a good point, perhaps research point should be given on a sliding scale downwards, after say 5 or 10 labs the scale are not as efficient and should not produce as much RP. This makes a lot of sense, sometime research is about time and not matter how much you try and crash a project you can never achieve zero point time frame.

[bean]

This is a good point, perhaps research point should be given on a sliding scale downwards, after say 5 or 10 labs the scale are not as efficient and should not produce as much RP. This makes a lot of sense, sometime research is about time and not matter how much you try and crash a project you can never achieve zero point time frame.

To a certain extent, this behavior is already modeled by the limits on labs for one scientist.  Think of that as the maximum number of labs they can successfully manage.  I'd say to leave it, as the gameplay benefits are minimal.
If we're going to introduce that level of complication, then I also feel obliged to point out that it's not simply a matter of diminishing returns.  After a certain point, cutting the budget of a research project makes it less efficient as well as slower, and it costs more to do the project than it would have if properly supported.

[Jumpp]

In the Combat Assignments Overview window, in the Firing Controls for Selected Fire Controls section, there are two buttons: "Open Fire" and "Cease Fire."  It'd be cool if there was a third button, "Fire Once."  In that mode, the weapons on that control would fire a single time and then return to the Cease Fire state automatically.

[ardem]

+1

[Jumpp]

So I build pre-fab PDCs and ship them off to outlying colonies for assembly.  It often turns out that I need some extremely tiny stashes of minerals to do the final assembly.  A recent bill of materials came to 117.3 duranium, 0.5 corbomite, 0.1 boronide, and 5.6 mercassium.

This isn't much, but often those outlying colonies don't have a lot.  I can, of course, ship them those minerals without much trouble.  A click here, a click there...okay, a couple dozen clicks later, it's set up.  To move about 130 minerals.

You know what I wish?  I wish the guys who'd made those gigantic pre-fab chunks had thought to include the minerals I'm gonna need in a little crate that'd easily fit inside the packaging somewhere, like the tiny little bottle of glue that sometimes comes with furniture that you have to assemble yourself.

So my suggestion: It only adds tedium, and not any gameplay value, to make players manage the assembly minerals.  How about instead billing those minerals up front, when the chunks are pre-fabricated, and then letting the assembly run without mineral cost?

[Conscript Gary]

A way to tell construction brigades to stop excavating ruins would be useful when they've dug too greedily and too deep.

[sloanjh]

You know what I wish?  I wish the guys who'd made those gigantic pre-fab chunks had thought to include the minerals I'm gonna need in a little crate that'd easily fit inside the packaging somewhere, like the tiny little bottle of glue that sometimes comes with furniture that you have to assemble yourself.

So my suggestion: It only adds tedium, and not any gameplay value, to make players manage the assembly minerals.  How about instead billing those minerals up front, when the chunks are pre-fabricated, and then letting the assembly run without mineral cost?

Seconded, with the addition that it's probably not worth it to account for the added size of the additional minerals in the shipping requirements.

John

[Paul M]

In the sensors display change the colour of the circle generated by a passive detection of an enemy active sensor.  Right now it is the same red as the circle of your thermal emission.  This would make things considerably less confusing.  It would also be nice to see a broken line where your intel suggests your ships would be spotted by the current sensors your passives are detecting.  This would make things also much more clear if you have been spotted or not.  I also would not mind a message to the effect you are picking up targeting scans...so you know if fire control is locking you up.

I would also like to see the ranges in the fuel page be correct for the ship in question as it stands those ranges are just plain wrong.  But being able to see how far a ship can move with the fuel it has left would help a lot in planning.

[bean]

Two things I'd like to see are compact versions of damage control and cargo handling systems.  The compact cargo handling in particular is for use on shuttles and small craft, which currently can't load from the ground all that well.