Aurora 4x

VB6 Aurora => Aurora Suggestions => Topic started by: Erik L on December 09, 2015, 12:50:03 PM

Title: Semi-Official 7.x Suggestion Thread
Post by: Erik L on December 09, 2015, 12:50:03 PM
Have at it.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: 83athom on December 09, 2015, 02:06:46 PM
Conditional orders/conditions. Condition; No Orders, Cannot Complete Primary/Secondary Order. Order; Land at Mothership, Transit Nearest Unexplored JP (Nearest unex JP with JG).

*Moved from v6.X suggestion thread.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: AL on December 09, 2015, 05:49:13 PM
Since larger compressed fuel storage systems have recently been added, what about also adding smaller versions (ie small, tiny compressed fuel storage) for use on fighters?
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: mtm84 on December 09, 2015, 06:14:49 PM
Option to randomly select a name from a list instead of going in list order.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: MarcAFK on December 11, 2015, 12:57:44 AM
Theres many suggestions in the old thread I would love implemented, however the first new one is related to the system image pack I'm working on. I would like asteroid and comet images to be randomly selected from a pool like the other types, perhaps anything named ast1, ast2, ast3, etc.
And then theres a problem with the default images for the solar system, most glaringly obvious is I don't see an image for the moon and also that titan uses the same image as mars, several other planets use incorrect images, or even lower quality correct images than others already in the pack. And finally there's inconsistent use of what I think the default naming scheme is.
I have noticed that in random systems moons listed as chunk use the aXX.jpg, and non ideal terrestrial bodies and dwarf planets use the bXX.jpeg series, but in the solar system many terrestrial planets use the aXX images. This is a problem because in real life the 'chunk' bodies are generally either lumpy rock and ice bodies that haven't managed to become spherical or generally if they're larger than 1000 kilometers like the larger dwarf and terrestrial bodies theyre spherical, this applies to asteroids too, just take a look at vesta or ceres. So when my image pack puts pictures of asteroids and small moons as aXX.jpg several larger bodies in sol end up with images of smaller bodies. also i should note that there is no visual difference between 'chunk' moons and asteroids so perhaps asteroids should use thalle aXX.jpg series anyway.
Actually I notice a wide diameter range between chunk bodies and asteroids, perhaps any of these under 1000 kilometers should use the astXX.jpg lumpy images and the larger ones should use the aXX.jpg which would be the rounder but still dead grey bodies.


 I suppose I'm suggesting a complete overhaul of the images for the solar system so that at least the large terrestrial bodies everyone colonize will have the correct images, and that everything else could just have generic placeholder images.
I'm prepared to make such a pack myself if it will be integrated into a future version. Or at least I could suggest how the current images could be used more effectively.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Thundercraft on December 11, 2015, 01:59:23 AM
...I suppose I'm suggesting a complete overhaul of the images for the solar system so that at least the large terrestrial bodies everyone colonize will have the correct images, and that everything else could just have generic placeholder images.

I second the notion. The solar system, at least, should have correct images. Back in 2013 when I took a look at it, I hesitated to try making my own planet image pack because the system Aurora uses to select planet images seemed too confusing.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: MarcAFK on December 11, 2015, 02:17:52 AM
I second the notion. The solar system, at least, should have correct images. Back in 2013 when I took a look at it, I hesitated to try making my own planet image pack because the system Aurora uses to select planet images seemed too confusing.
I seem to have gotten a handle on it, most systems randomly choose certain images for certain body types, but sol seems to have default images for bodies, which is often wrong or arbitrary. The only hesitation I have for suggesting an official overhaul is the fact that my image pack essentially steals images without proper licensing. I currently lack a stable enough internet connection to perform proper research, I know that nasa itself doesn't copyright images, but there are a dozen other places these pictures come from such as the ESA, etc, which may have different requirements and at minimum I need to write down the actual origin of each image and provide proper credit.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Jumpp on December 15, 2015, 09:02:19 AM
Suggestion: A button that causes the ships in a TG to redistribute ammunition among themselves such that all ships of the same class have got the same stuff.

For instance:
Cruiser 1: 40 Harpoon Mk2s, 40 Sparrow Mk2s (all antiship)
Cruiser 2: 40 Harpoon Mk2s, 40 Sparrow Mk1s
Cruiser 3: 40 Harpoon Mk1s, 40 Sparrow Mk1s
Cruiser 4: 1 Harpoon Mk1
Frigate 1: 100 Nike Mk1s (antimissiles)
Frigate 2: 800 Nike Mk1s

Then I push the magic redistribute-within-each-class button:
Cruiser 1: 20 Harpoon Mk2s, 11 Harpoon Mk1s, 10 Sparrow Mk2s, 20 Sparrow Mk1s
Cruisers 2-4: 20 Harpoon Mk2s, 10 Harpoon Mk1s, 10 Sparrow Mk2s, 20 Sparrow Mk1s
Frigates: 450 Nike Mk1s

States very like the first one above are common in my games. This is what I see when I have a fleet reload from a site that's got a mishmash of up-to-date and out-of-date ammo, and not enough of any of it. The Frigates, in this story, were both fully loaded, but the first one has expended most of its ammo while the other hasn't fired a shot.

You'd want to evenly distribute the ammo among the AMM frigates so that half your guns aren't offline. (In a perfect world, they'd load-balance their outgoing fire such that one didn't deplete way ahead of the others, but that could be complex and read/write intensive and this is a good workaround.) And you'd want to evenly distribute the ammo among the ASM cruisers so you can put together large coherent salvos.

You wouldn't always want this. Depends on the details of your fleet doctrine and the condition of your supply chain. But I often find myself doing this sort of tedious operation by hand. Automating it would be really nice.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Erik L on December 15, 2015, 04:42:12 PM
A check box in the Research tab that automatically allocates the maximum research labs to the selected scientist (while honoring the amount available)
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: swarm_sadist on December 19, 2015, 02:48:09 PM
I'm pretty sure I asked for this before but here it goes.

Automation of player factions. Being able to turn a player faction into an NPR while you work on another player faction means that multi-nation starts don't become so confusing. Alternatively, just automating certain parts would be good enough, like civilian contracts or research goals.

Also, an auto assign civilian administrators checkbox.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: db48x on December 19, 2015, 09:32:55 PM
Quote from: Erik Luken link=topic=8107. msg83464#msg83464 date=1450219332
A check box in the Research tab that automatically allocates the maximum research labs to the selected scientist (while honoring the amount available)

It could even just assign as many as are available if the amount typed in is larger than the number of available labs, rather than showing an error dialog and then doing nothing.

My suggestion is that the unrest notifications shouldn't break automatic turns unless the unrest rises past a threshold, perhaps just 1%.  That would help for the usual case where the civlian lines alternately add colonists and infrastructure to a planet, causing the unrest to rise and fall my tiny amounts.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: MarcAFK on December 19, 2015, 11:09:55 PM
Perhaps 10%, it would take a while to build up that far and if you're ignoring the event log that long it's your own fault.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: sloanjh on December 20, 2015, 08:20:45 AM
Perhaps 10%, it would take a while to build up that far and if you're ignoring the event log that long it's your own fault.

+1

John
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Garfunkel on December 20, 2015, 09:02:15 AM
Yes, no auto-break until unrest at 10%.

Add water to terraforming possibilities, so wasteland planets can be modified to have an hydrosphere.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Steve Walmsley on December 20, 2015, 09:29:54 AM
Since larger compressed fuel storage systems have recently been added, what about also adding smaller versions (ie small, tiny compressed fuel storage) for use on fighters?

Small and Tiny added for v7.1
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Steve Walmsley on December 20, 2015, 10:55:08 AM
Option to randomly select a name from a list instead of going in list order.

The Class, Ship and Shipyard windows now have a Select Name option in addition to the normal Rename. Select Name opens a window with a LOT of names from which you can choose.

There are two sections. In the first you select a Theme and see all the Class and System names. In the second you can see all ship names from each ship name category. Whichever name you click last is shown at the bottom. When you press Select, your ship or class is renamed accordingly.

(http://www.pentarch.org/steve/Screenshots/SelectName2.PNG)
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Steve Walmsley on December 20, 2015, 11:25:57 AM
In terms of the image packs - that is something I haven't looked at in a long time. If someone has a list of the correct images for each planet, I can update the database accordingly.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Steve Walmsley on December 20, 2015, 11:36:42 AM
A check box in the Research tab that automatically allocates the maximum research labs to the selected scientist (while honoring the amount available)

Added for v7.1

It will be set to maximum for scientist or maximum available, whichever is lower.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Steve Walmsley on December 20, 2015, 11:41:09 AM
My suggestion is that the unrest notifications shouldn't break automatic turns unless the unrest rises past a threshold, perhaps just 1%.  That would help for the usual case where the civlian lines alternately add colonists and infrastructure to a planet, causing the unrest to rise and fall my tiny amounts.

At the moment, unrest doesn't end automatic turns. I've just checked the DB and it is flagged as a 'No Interrupt' event.

Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: db48x on December 20, 2015, 03:08:46 PM
Quote from: Steve Walmsley link=topic=8107. msg83654#msg83654 date=1450633269
At the moment, unrest doesn't end automatic turns.  I've just checked the DB and it is flagged as a 'No Interrupt' event.

I guess it's something else then :)
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: MarcAFK on December 20, 2015, 04:39:47 PM
In terms of the image packs - that is something I haven't looked at in a long time. If someone has a list of the correct images for each planet, I can update the database accordingly.
The best I can do is images of every object over 1000 km diameter that's been visited by a probe, will that do? XD
 Though for OCD I intended to include more of the smaller moons which had good pictures too, I'll get right on that.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: db48x on December 23, 2015, 09:55:12 AM
Could the Technology Report window show unresearched racial techs as well?

Also, I think the realistic promotions feature ought to consider unfilled positions when assigning promotion points. For example, brigadiers who could command a division which currently has no commander should get extra points (or perhaps should just be promoted outright) so that eventually that position can be filled.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Erik L on December 23, 2015, 02:47:03 PM
It'd be nice if you could designate a common system as neutral, regardless of other relations between races.

I.E. Sol is neutral with 6 empires on it. Outside of Sol, relations are as normal, war/peace/etc. In Sol, peace is maintained.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: mtm84 on December 24, 2015, 02:17:37 AM
Minor thing, would it be possible to display the total amount of PPV in a task group, maybe in the History/Officers/Misc tab with the fleet tonnage?
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: backstab on December 24, 2015, 02:15:51 PM
I'd like to see the ability to name colonies.  I have a power on a planet that has taken multiple colonies from various other nations and it is getting hard to determine which prior colony is which.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Tree on December 26, 2015, 09:28:15 AM
It would be nice to have the current date somewhere in the Player Race Production Overview window (ctrl+F8), and the "Queue Yes/No" row in all the tabs, not just imminent events.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Zincat on December 26, 2015, 12:27:55 PM
For those of us who actually cart teams around, it would be extremely nice to have a "pick up all teams" and "drop off all teams" commands in the task force window.

Because you know, manually clicking 10 times or so pick pup, pick up, pick up, pick up... pick up and then drop off, drop off, drop off, drop off".... is horrible XD
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: db48x on December 26, 2015, 01:40:21 PM
Indeed. I've always thought that it would make more sense if we gave the teams automatic survey orders the same way we can give a survey tg an automatic order to survey things. If we could give our courier ships automatic orders to pick up teams and ferry them to their destinations, it would simplify things greatly.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: MarcAFK on December 27, 2015, 09:15:31 PM
Are conventional tech NPRs still unable to advance to transnewtonian? Is it possible to add an option allowing them to advance, or maybe add a spacemaster command to do so.
I do appreciate the idea behind low tech races that are stuck in the dark ages, and in fact my next game relies on them being unable to advance. However it would be good if they can upgrade at some point, even if it's using SM mode.
Specifically it might be useful when running a conventional level game to have NPRs that start on a similar footing and advance in a similar way to players.
Also in relation to this, maybe new slightly downgraded from level 1 techs could be introduced to allow low tech races to actually have conventional militaries and sprawl through their own system.
Specifically smaller versions of ICBMs with speed greater than 1 for ships, low tech sensors, rail guns, microwaves, maybe an advanced conventional engine that has greater thrust to weight.
Maybe even low tech infrastructure. Give them something to do while stuck at low tech.
Related to this, I recall that at least one of the production settings for creating a new empire doesn't actually change how productive the empire is. I believe wealth alters income, but production efficiency just changes starting industry without altering per factory production.
It would be nice to have options that change industrial output, research, population growth, per capita income, mining production. Etc for find grained control of races.
I'm specifically hoping for a way of changing research percentage so I can make a game drag on for decade at low tech levels, I can do it in a way using only human controlled empires,  but of course NPRs wouldn't follow my self imposed restriction.
In relation to this too,  assuming these options are added and would also be available on the create new empire screen that pops up when you make a new empire, how about an option to allow that empire to be sited on a homeworld in a new randomly generated system rather than on a soecific body. You can already add specifically crafted empires to certain worlds, or have completely random NPRs, why not a combination? Although the same thing is achievable by merely spawning a new system, adding the NPR then uh... Forget the system exists?
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Sematary on December 27, 2015, 11:02:58 PM
I am a fan of Marc's ideas. I really like the idea of being able to finely control the nations more. For a real world example look at China vs the US, China has close to 4x the population but not 4x the wealth, or industry, or research capability. Right now a higher population empire will be stronger than a lower population and there is no real way to simulate less advanced nations like the Third World or anything.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: MagusXIX on December 27, 2015, 11:52:36 PM
Is anyone else annoyed by constant interrupts due to civilian construction, or is that just me? Interrupts when there's a *new* mining colony are fine, but I don't need to be interrupted for every new civilian ship or when there are extra mining complexes added to an already existing colony.

Low priority, sure, but annoying enough to post here.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: MarcAFK on December 28, 2015, 12:00:22 AM
Perhaps something else to add to the don't interrupt list. That list is getting pretty
Big compared to the first version played. It's pretty smooth going these days.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: metalax on December 28, 2015, 07:47:43 AM
These three were brought up in an Aurora discussion on another forum.

Tech-line to increase the efficiency of crew quarters.

Tech-line to improve the effect of Engineering Spaces at reducing the incremental failure rate.

Tech-line to reduce the maintenance supply cost of each repair, effectively increasing the efficiency of each supply point.

The primary reason for these changes is that it seems abnormal that practically every other area of technology has the potential to advance over the course of a game, but these are stuck at the level they are at at the game start. More, as tech for other components increase, typically also increasing their size, there is less and less mission payload available to each ship of the same size due to increasing maintenance and crew requirements.


An option in game setup to disable all missile tech for player and NPR empires for that game. Possibly leave it in for Precursors and Invaders to make them truly challenging threats. This would enable beam slugging matches to really be an option and make planetary invasion to deal with hostile worlds more of a requirement instead of just bombing them into submission(Mesons could still be used if you really wanted to destroy a world from orbit).
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Rich.h on December 28, 2015, 08:20:30 AM
In light of a thread asking about how folks organise the galaxy map I think an overlay feature would be nice. So on the galaxy map you have a filter you can apply that will show up squares and/or hexagons. This way you could have a visual way of setting up sections of space like quadrants etc.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Steve Walmsley on December 28, 2015, 09:07:19 AM
An option in game setup to disable all missile tech for player and NPR empires for that game. Possibly leave it in for Precursors and Invaders to make them truly challenging threats. This would enable beam slugging matches to really be an option and make planetary invasion to deal with hostile worlds more of a requirement instead of just bombing them into submission(Mesons could still be used if you really wanted to destroy a world from orbit).

You need to be a little careful here. With beams only, as soon as one race has higher speed and longer ranged beam weapons, he can't lose.

This is one of the reasons I restrict beam ranges (in addition to the light-speed issue). As they have unlimited ammo, they can easily destroy any opponent with shorter-ranged weapons. Even if the opponent is faster he may still be in trouble unless he can get in range reasonably quickly.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: metalax on December 28, 2015, 02:10:15 PM
You need to be a little careful here. With beams only, as soon as one race has higher speed and longer ranged beam weapons, he can't lose.

This is one of the reasons I restrict beam ranges (in addition to the light-speed issue). As they have unlimited ammo, they can easily destroy any opponent with shorter-ranged weapons. Even if the opponent is faster he may still be in trouble unless he can get in range reasonably quickly.

While mainly true, at least in the case of two ships fighting with no other consideration, this isn't quite as clear cut as it first appears.

For example, assume equal research points between two empires, with the first having a 1-2 tech level advantage in engines and beam fire control range. Due to how research costs increase greatly for each tech level that leaves the second empire with a load of research points. Say those points were put into ECM and shield regeneration techs. In order for the first empire to take advantage of it's longer range, it has to be maintaining long range and so will have low damage and low accuracy. The improved shields and ECM of the second empire mean that the first is now unable to drain the shields of the seconds ships before they reach the firsts colonies and land troops/use a meson bombardment.

A second example, assume a similar setup to above but this time the second empire puts its extra research into boosting its industrial/shipyard capabilities, and designs ships that utilize a higher percentage of tonnage for engines in order to beat the first empires speed. While it will prove expensive in resources and crew the second empire could then overwhelm the first through using sheer numbers to get into range.

A different alternative would be to use tactics such as luring the attacking ships by withdrawing those under attack while sending out flanking forces to envelop the faster ships. Alternatively bait the faster ships to follow through a jump point where a network of ships is set up to catch them whichever range they jump in at.

In the case where two empires do not have an equal level of research, it generally will make sense that the disadvantaged side will have a harder and harder job matching the superior until the gap is wide enough that it simply can't be bridged.

Basically, I believe that having the option offers the opportunity for interesting conflicts and scenarios. Can it be gamed against the AI? Certainly, but so can the current system.

N.B. Italics aren't emphasis, merely a counter to the forums overzealous anti-scripting. I I hope that gets sorted out soon, it was a pain finding out what was causing the 403 errors.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Zincat on December 29, 2015, 07:20:03 AM
I would like to request some changes in the civilian shipping companies ship generation algorithm.

Basically, in this game I had yesterday/today, my shipping line started launching ships but no matter how much I funded it, it would still launch only colony ships. No freighters at all. Before I threw the game because of alien interference too early on, this was the situation:

Earth main colony
Mars, 230 infrastructure brought by me and 1.5 million colonists (so there was a demand for infrastructure here)
Multiple orders of installations and infrastructure to be moved from earth to mars. I think it was 200 infra, 1 mass driver, 10 mines and 10 construction factories which I requested to be moved.

The shipping line had over 20000 funds, given by me. And after 8 years, it had 9 colony ships, 3 space liners and 0 freighters. That is very bad in my opinion, because for colony growth I generally rely on the civilian infrastructure trade goods instead of building it manually (a must in conventional starts! You can't really afford to build infrastructure early on).

I do not know how the algorithm works, but with demands both from civilians and from myself, shouldn't it have built at least a few freighters? Perhaps a more balanced approach is needed ... Not to  mention that the colony ships were not doing anything at all so I don't understand why it was building them so much.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: MagusXIX on December 29, 2015, 07:59:54 AM
Zincat, I've noticed in my games that civilians don't construct certain designs until after I've already designed my own version.  It seems you only need to *design* the ship type you want them to build, and that you do not need to actually build it yourself.  I had the opposite problem as you in my last game, where my civies were only building freighters.  The moment I designed my own colony ship (after I got fed up with waiting for them to build one) they cranked out a bunch of their own.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Zincat on December 29, 2015, 08:05:06 AM
Zincat, I've noticed in my games that civilians don't construct certain designs until after I've already designed my own version.  It seems you only need to *design* the ship type you want them to build, and that you do not need to actually build it yourself.  I had the opposite problem as you in my last game, where my civies were only building freighters.  The moment I designed my own colony ship (after I got fed up with waiting for them to build one) they cranked out a bunch of their own.

But I did obviously have a freighter, I used it to ferry the first infra I built to Mars... and it still did not help >_>
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Steve Walmsley on December 29, 2015, 09:02:36 AM
I would like to request some changes in the civilian shipping companies ship generation algorithm.

Basically, in this game I had yesterday/today, my shipping line started launching ships but no matter how much I funded it, it would still launch only colony ships. No freighters at all.

I was starting to think there was a problem with the civilian ship generation because my shipping lines seem to be building nothing but freighters!

Colony ships are more likely if the shipping line has plenty of wealth. However, in normal circumstances freighters are more likely because the shipping line may not have enough wealth to afford colony ships when they check for a ship to build. In other words, subsidising makes colony ships more likely while normal operation makes freighters more likely.

Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: MagusXIX on December 29, 2015, 09:09:32 AM
Would it be feasible to add some if checks to civilian ship creation?  Before a shipping line decides what to build it should run a check, something like ...

if there are no civilian (shiptype)
  build (shiptype)

That way there will always at least be one of each type.  It'd help relieve some early game frustration and it seems pretty logical to me.  Do we know what the odds of never getting a civilian FT/CS/FH over a reasonable length of time (say ... 5 years) are?
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Steve Walmsley on December 29, 2015, 01:14:29 PM
Would it be feasible to add some if checks to civilian ship creation?  Before a shipping line decides what to build it should run a check, something like ...

if there are no civilian (shiptype)
  build (shiptype)

That way there will always at least be one of each type.  It'd help relieve some early game frustration and it seems pretty logical to me.  Do we know what the odds of never getting a civilian FT/CS/FH over a reasonable length of time (say ... 5 years) are?

Yes that sounds sensible. In fact, a more complex version of that is what the NPRs do :)
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Haji on December 30, 2015, 06:08:42 AM
I'm not sure making the shipping line build everything is a good idea. I once tried to create a campaign where the 'main' power was very small and forced to get most of its funding from trade. The problem is that the shipping lines were launching approximately 50% colony ships which were useless as I had too small population to do any colonization. Most money was in fact coming from luxury liners which were built in great numbers in the beginning and then just stopped. Freighters were providing good amount of money but in the end too few of them were being built.
I don't know how difficult it would be to code this (or how much impact it would have on performance) but once shipping lines have some vessels they should be running checks what provides money and what does not, so if there is no colonization going on they would not build colony ships. Other than that I had very few issues with the lines building only one type of vessel.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: db48x on December 30, 2015, 01:18:52 PM
Is there any reason the habitability of a planet doesn't factor in anything other than the atmosphere and gravity of a planet? It'd make sense to have an extra cost when there's no hydrosphere, for instance.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Ostia on December 30, 2015, 06:18:19 PM
I am either missing the option or we are lacking a "Transfer Survivors/POWs/Cargo to other Ship" button.

Keep my survivors on my tiny S&R shuttle when their MS has 10k cryo space is meh.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Zincat on December 31, 2015, 04:34:22 AM
Thanks a lot for the changes to civilian shipping lines, Steve. I think I'll ask another thing if I can.

I like to live in interesting neighborhoods. Unfortunately my first 7.1 game is so... terribly... terribly... empty.

21 systems, 0 NPRs, 0 ruins, 0 anomalies,   0 swarms   just a single precursor controlled system far away . There's almost no reason at all, except for minerals, to leave home! I know I can change the NPR by adjusting the NPR generation chance, but all the rest I cannot.

I was wondering, I don't know how your system generation algorithm works. However, could we have a paramenter to choose at start to influence the other things? Say, a number in the 1-5 or 1-10 scale or whatever to set in the beginning that multiplies the generation chances of ruins, anomalies,   swarms and precursors ? So if we want a universe in which those things are, say, 5 times more common, we can.


Also, could it be that the emptiness now is due to the NPR not generating other NPRs because of the bug in 7.1 which you corrected? This one  http://aurora2.pentarch.org/index.php?topic=8144.msg83925#msg83925

EDIT: a specification. Because of how the map came out, those 21 systems are basically anything in a radius of 5 jumps. If I want to hope finding anything at all of interest, I must hope for systems 5-6 jumps away or more. Unfortunately, a lot of arms turned out to be dead ends, or looping back...
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Steve Walmsley on December 31, 2015, 08:50:46 AM
I've added the ruin chance to the game and game setup windows. It is normally 20% for any terrestrial world, terrestrial moon or small terrestrial moon with gravity > 0.4G and temperature between 200K and 360K (about -73C to +87C).

Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Erik L on December 31, 2015, 09:17:31 AM
Programmable mines.

Such as "Fire at first hostile contact", "Wait 60 seconds on hostile contact, if still there then fire", etc.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Zincat on December 31, 2015, 01:31:53 PM
I've added the ruin chance to the game and game setup windows. It is normally 20% for any terrestrial world, terrestrial moon or small terrestrial moon with gravity > 0.4G and temperature between 200K and 360K (about -73C to +87C).

Thank you a lot Steve :) That really helps
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: CharonJr on December 31, 2015, 02:32:26 PM
A button to award a medal to all officers of a taskforce would be nice, just had to look up/award 40 single officers to give them a campaign ribbon.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: MagusXIX on January 01, 2016, 05:26:55 AM
When a character who has an assignment dies, there should be an interrupt.  Oftentimes a colony governor or team member will die, leaving the colony ungoverned or the team short a member and I won't notice until way too late.  Maybe it could work like unused research labs: "The colony at Venus does not have a governor." or "Geological Survey Team does not have 5 members."  The general problem being that some personnel deaths are important enough to warrant an interrupt so that the player knows that something needs to be fixed, while the majority of officer deaths (particularly unassigned officers) aren't worth noting.  This applies mostly to assignments that aren't automatically replaced by the auto-assign system.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Zincat on January 01, 2016, 05:37:22 AM
When a character who has an assignment dies, there should be an interrupt.  Oftentimes a colony governor or team member will die, leaving the colony ungoverned or the team short a member and I won't notice until way too late.  Maybe it could work like unused research labs: "The colony at Venus does not have a governor." or "Geological Survey Team does not have 5 members."  The general problem being that some personnel deaths are important enough to warrant an interrupt so that the player knows that something needs to be fixed, while the majority of officer deaths (particularly unassigned officers) aren't worth noting.  This applies mostly to assignments that aren't automatically replaced by the auto-assign system.

I say yes only to important assignments. That is:
- Governors
- Diplomatic /xenobiology/espionage teams
- Task force commanders

Anything else most assuredly does not deserve an interrupt. I have around 100 geosurvey teams around the galaxy later in the game, I couldn't care less if one officer dies or not...
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Ostia on January 01, 2016, 08:24:36 AM
Request:

Can the Build and Load Time Box moved to the right side of the Class Design Screen? They disappear when using Reduced Height Windows., which makes Freighter/Troop  Design a bit hard.
The same goes for the Show Civilian Designs Box.

Quoting my own request from 6.43, because it still annoys me. Or alternatively put them into the (Brief) Class Summary.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: alex_brunius on January 02, 2016, 10:39:23 AM
Programmable mines.

Such as "Fire at first hostile contact", "Wait 60 seconds on hostile contact, if still there then fire", etc.

The only command I need is "don't fire if more then X missiles is already en-route to target", similar to the automated AMM launches. Or a logic that spreads out launches on all ships in a task-force evenly.

Would make mines tons of useful and lethal.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: illrede on January 02, 2016, 12:42:19 PM
Request:

"Stable" and "Source of Colonists" being unlocked for all population levels on Civilian Colonization Status, not kicking in only when population hits 25 million.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Steve Walmsley on January 02, 2016, 12:52:48 PM
Request:

"Stable" and "Source of Colonists" being unlocked for all population levels on Civilian Colonization Status, not kicking in only when population hits 25 million.

The 25m pop level is so the civilians have some independence. If you could set stable and source for all colonies, the civilians would effectively just be your ships.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: illrede on January 02, 2016, 01:45:56 PM
The 25m pop level is so the civilians have some independence. If you could set stable and source for all colonies, the civilians would effectively just be your ships.

The matter that I ran into was with population sites utilizing UI; they just kept unloading colonists and there was no feasible way to keep them from dying.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Steve Walmsley on January 02, 2016, 02:07:37 PM
The matter that I ran into was with population sites utilizing UI; they just kept unloading colonists and there was no feasible way to keep them from dying.

Sounds like a bug. I'll take a look.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: alex_brunius on January 02, 2016, 06:09:04 PM
It would be pretty cool to see some crude WW2 inspired weapons for the Carrier bombers, and for us that loves to make Spaceships heavily inspired by WW2 designs (like destroyers that can close range and launch torpedoes).

External Mount:
- Works similar to a box launcher but more crude and volatile.
- Can be researched directly for 500 RP and mount either normal missiles, or the two weapon systems below. If they are hit then whatever is loaded also automatically explodes.
- Has x0.20 size multiplier instead of x0.15 for boxlaunchers.

Inertial Bomb:
- This weapon can be launched from missile launchers or External Mounts, and inherits the vehicles speed, so it will naturally have low hit chances and be fairly useless on agile targets.
- Ranged is capped at Missile agility tech * 2000km ( starting tech of 32 agility per MSP = 64000 km range )
- Very cheap to make compared to missiles ( 1/10:th cost ), makes it the ideal weapon to hit stationary targets with.
- Designed similar to missiles and use upgrades for missile warhead, but without possibility to add guidance or engine ( the guidance systems on the ship launch it automatically at the target ).
- Is impossible to intercept (with PD or AMMs) after launched, only chance is to shoot down the bombers!
- Same hit-chance calculation as missiles have.

Transnewtonian Torpedo:
- This weapon can be launched from missile launchers or External Mounts.
- Designed just like missiles and use upgrades for missile warhead, but it's can only use Missile engines without engine multiplier (making them slow)
- Double chance of shock damage, makes it the ideal weapon to hit slow, big and heavily armored targets with.
- Cheaper then missiles to make  (1/5:th cost )
- Ranged is capped at Missile agility tech * 2000km ( starting tech of 32 agility per MSP = 64000 km range )
- Is impossible to intercept (with PD or AMMs) after launched, only chance is to shoot down the vehicle launching platform!
- Same hit-chance calculation as missiles have.



Both of these weapons are also great at finishing off crippled and stationary targets or going after the enemies commercial targets with.
Gameplay wise they are aimed at making fighters work better early game too ( before you can afford to pour 22000 RP into unlocking the box launchers, and an almost equal amount to get decent engine power multiplier ).
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Rich.h on January 02, 2016, 06:28:17 PM
While I am not fond of the above idea, they did make me wonder if something is possible in Aurora. We already have shock damage, but is it possible to have shock damage that extends over a large area? If that is possible how about a space depth charge? A missile you target at a WP when it detonates it creates a large shockwave that while not doing vast amounts of damage, it will at least suddenly show up on the system map as an energy impact. Thereby revealing sneaky snips you may not have detected?
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Bremen on January 03, 2016, 02:14:24 PM
I actually think the idea of a bomb type weapon that uses the launching vehicle's speed is pretty intriguing, but I'm not sure if it fits with the lore idea of inertialess drives.

Give it a range of speed x 5 and maybe have it work like missiles fired within 5 seconds of their range (normal beam PD can't shoot it down, but I believe CIWS still can) and it would open interesting tactical possibilities as a single shot and then reload version of a beam fighter. It would still have the problem beam based fighters have where it's almost impossible to get through AMM defenses, though.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Zincat on January 03, 2016, 03:05:58 PM
To be honest, I'm not too fond of the ideas Alex posted. No offense meant, I just think they don't fit well to the mood of the game and would be hard to balance too.

Some don't fit well the "physics" of the game too, considering the trans-newtonian laws the game works by...
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: swarm_sadist on January 03, 2016, 06:03:00 PM
I know this has been suggested before but have the sensors and reactors in missile design combined, so that having .5 Missile Size worth of Sensors doesn't produce another .264 something of reactor.

Having more FC options would be nice as well, such as delayed active sensors, fire and forget options, and search and destroy options. We can sort of do this with waypoints and sensor missiles, but the missile has to reach the waypoint first. It would be much easier if the missile locked on to any emissions it encounters along the way.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: rcj33 on January 03, 2016, 07:43:39 PM
How about adding research for increased-size missile launchers and lasers with faster refire rates? I know that they wouldn't have much mechanical benefit (the only really practical use would be for making useful AMM launchers at low TLs) but having powerful fast-firing weapons would be cool for RP. Plus I think they could be stuck into the existing tech lines for reduced-size missile launchers and lasers, kind of how genetic engineering techs work now.
Yes i know you can just put two weapons on a ship, fire one, and then assign the second to the FC when the first is halfway done cycling, but I really hate to do that kind of micro.

Also missile batteries would be nice (just turrets without rotation gear, but shooting missiles) and an option to "clone" non-racial components like ECM so that you wouldn't always find "your" stuff in alien wrecks.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: alex_brunius on January 03, 2016, 09:40:51 PM
I actually think the idea of a bomb type weapon that uses the launching vehicle's speed is pretty intriguing, but I'm not sure if it fits with the lore idea of inertialess drives.

Give it a range of speed x 5 and maybe have it work like missiles fired within 5 seconds of their range (normal beam PD can't shoot it down, but I believe CIWS still can) and it would open interesting tactical possibilities as a single shot and then reload version of a beam fighter. It would still have the problem beam based fighters have where it's almost impossible to get through AMM defenses, though.

That was pretty much my idea. That these can work as early game weapons for making Carrier fighters/bombers somewhat potent before TL4-5, but after that they are marginalized and not really used anymore in face of potent AMM defenses, heavier dual purpose PD turrets with good tracking and sensors spotting strikes further away from target. It would neatly model the historical transition from WW2 tech to coldwar and modern carrier ops.


Cheaper weapons like Torpedoes would still be useful later on to give the a cheap punch to destroyers as well as more stealth like submarines operating behind the lines against enemy merchant shipping or in surprise attacks on less defended stationary targets.

And bombs could be a good means of finishing off enemy Orbitals or PDC defenses without a fortune worth of missiles once their offensive capacity is reduced sufficiently.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Zincat on January 04, 2016, 05:20:20 AM
I know it has been asked before. But we could really use some way to move to distant companions stars. There's so many of them, 1000+ billion km away from the main star. And they often have planets. It's just so... irritating, seeing them but not being able to reach them.


I understand you removed hyperdrive, and probably has no plan to use it ever again. But as it is, all those planets are useless...
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Zed 6 on January 04, 2016, 07:58:05 AM
2nd the motion to be able to move to distant companion stars. either a return to hyperdrive or some other method. These stars are very useful.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Rich.h on January 04, 2016, 09:25:05 AM
Or a mechanic for adding in a LP even if were only in SM.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Laiders on January 04, 2016, 10:24:32 AM
One simple suggestion that has occured to me from some Reddit discussions is the implementation of conditional orders based on how full a cargo hold is and, maybe, even what it is full of.  This would allow players more flexibility in setting up intra and inter system freighting routes.  It would also allow players to not get interrupted by 'loading failed.  Cargo hold is full' messages all the time if they are going a freighter heavy style of play. 
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: linkxsc on January 05, 2016, 12:40:31 PM
^ Seems reasonable enough.

What occurred to me as a suggestion just a bit ago.
As we now have the ability to "halt" production of civilian shipping lines. A nice addition.

Perhaps instead of a halt we could set an upper limit on tonnage that the Civilians are allowed to operate, and of what type.
So I could allow them 100,000t worth of freighters, 30,000t of colony ships, and 0t of fuel harvesters.
From there they pick their designs and can build up to less than that number in tonnage. If I lower the number while I they have more tonnage, it remains at that level until ships begin needing to be scrapped, after they're back below the allotted tonnage, they're allowed to start making new ships again.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: sublight on January 05, 2016, 01:40:41 PM
... We can sort of do this with waypoints and sensor missiles, but the missile has to reach the waypoint first. It would be much easier if the missile locked on to any emissions it encounters along the way.

We can already do this: just delete the target waypoint after the missile is fired and the missiles will switch to 'searching for new target' mode while continuing to fly toward the lost waypoint's location.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Dfuzzed on January 06, 2016, 03:06:30 AM
The abillity to set min and max rank requirements on ship classes.  Right now captains are commanding 20k ton ships and officers above R3 are commanding a single fighter, as all military classes require at least an R3 officer .  The admiral might be an excellent fighter pilot, but it just feels weird from a rp perspective.

Maybe make the TF commander automatically the commander of the flag ship said TF is based on.  Right now the TF commander is based on the flag ship of said TF but is not the commanding officer of said flag ship, you have to assign a different commander.

I think this would go well with another suggestion I read here in the suggestion forum: hxxp: aurora2. pentarch. org/index. php?topic=8005. 0
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: DIT_grue on January 06, 2016, 04:10:16 AM
The abillity to set min and max rank requirements on ship classes.  Right now captains are commanding 20k ton ships and officers above R3 are commanding a single fighter, as all military classes require at least an R3 officer .  The admiral might be an excellent fighter pilot, but it just feels weird from a rp perspective.

Maybe make the TF commander automatically the commander of the flag ship said TF is based on.  Right now the TF commander is based on the flag ship of said TF but is not the commanding officer of said flag ship, you have to assign a different commander.

I think this would go well with another suggestion I read here in the suggestion forum: hxxp: aurora2. pentarch. org/index. php?topic=8005. 0

Minimum rank required is set on the DAC / Rank / Info tab of the Ship Design window.

This is in line with reality - you don't want your admirals distracted by running a ship, that's what their flag captain is for.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Dfuzzed on January 06, 2016, 04:20:24 AM
Quote from: DIT_grue link=topic=8107. msg84604#msg84604 date=1452075016
Minimum rank required is set on the DAC / Rank / Info tab of the Ship Design window.

This is in line with reality - you don't want your admirals distracted by running a ship, that's what their flag captain is for.

Yes I am a massive idiot.  I came here to edit my post as I found it myself just a moment ago.  ;D
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Sheb on January 06, 2016, 04:29:26 AM
A "Maximum Rank" thing might be nice though. It IS weird to have your admiral run a shuttle.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: MarcAFK on January 06, 2016, 05:07:43 AM
A "Maximum Rank" thing might be nice though. It IS weird to have your admiral run a shuttle.
Or a lord who jumps into a fighter. *cough*
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: AL on January 06, 2016, 05:51:52 AM
In one of my previous games I had a bunch of super-obsolete 1kt OWP's which I just used as training posts for officers. Problem is I forgot about the officers after I assigned them there, so a fair few years down the line I found that about half of my highest ranking officers in the whole navy were commanding 1kt rustbuckets without even the most rudimentary propulsion systems. Well, at least I had plenty of officers ready to be assigned to my new super-capital ships...
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: swarm_sadist on January 07, 2016, 10:59:10 PM
Small suggestions:

1. Can we have in the fuel report window a % of maintenance clock/maintenance life, as well as crew clock/intended deployment time?

2. When in task group order screen, when the expected order(s) given take the task group outside it's range, display the box with the estimate time and range as yellow or red.

Slightly bigger suggestion:
A ferry move command for moving task groups consisting of multiple ships with different ranges/fuel amounts, where the combined fuel capacity of the entire task group is used and shared between all the ships evenly, so they all run out of fuel at the same time (and hopefully have the longest combined range without micro-ing fuel management).
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: MarcAFK on January 07, 2016, 11:57:47 PM
It's been suggested that automatic officer assignment isn't ideal, with fighters getting assigned unskilled officers before larger capital ships which perhaps should get officers first.
I'm suggesting the following for auto assignment,
First, sort officers by skill level, whatever an officer is most skilled in causes him to be assigned to the largest vessel that would take advantage of that skill, if such a vessel doesn't exist which needs an officer, then his next highest skill is used instead. And so on through the officers.
I'm sure the current system already does something like this.
But my suggestion is this, once all the skilled officers have found assignments the leftovers are sorted by how high their crew training rating is, ships are then sorted into military and commercial vessels, and also by tonnage.
Then from the heaviest military ship down the officers are assigned, after military ships are crewed commercial ships are crewed next.
I didn't mention the minimum rank required though, I guess the highest rank officers should be applied to the highest rank ships first, then only when running out of ships requiring ranks over 1 would the leftovers be assigned as I suggested.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Thundercraft on January 08, 2016, 11:10:52 AM
I actually think the idea of a bomb type weapon that uses the launching vehicle's speed is pretty intriguing, but I'm not sure if it fits with the lore idea of inertialess drives.

Give it a range of speed x 5 and maybe have it work like missiles fired within 5 seconds of their range...
That was pretty much my idea. That these can work as early game weapons for making Carrier fighters/bombers somewhat potent before TL4-5, but after that they are marginalized and not really used anymore...
+1
I like the idea.

I know it has been asked before. But we could really use some way to move to distant companions stars. There's so many of them, 1000+ billion km away from the main star. And they often have planets. It's just so... irritating, seeing them but not being able to reach them...
2nd the motion to be able to move to distant companion stars. either a return to hyperdrive or some other method...
Or a mechanic for adding in a LP even if were only in SM.

Yes. Would be nice if distant companion stars had an LP to connect them to the main star.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: siath on January 08, 2016, 04:40:20 PM
Conditional Orders for Survey Teams to automate this process a bit. 

An option to keep teams fully staffed or staffed to a set number of people. 

An option to all the automatic replacement of governors and HQ leaders.   I miss them dying or retiring all the time.

Option for survey teams to not mark a place as a colony? Maybe a special mark showing it has been surveyed by a team (ST)?
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: CharonJr on January 09, 2016, 10:32:50 AM
It would be nice if naval officers could be sorted by "tonnage destroyed" in order to help with finding "aces" and giving them a medal.
Title: Bigger is Always Better
Post by: Yitzi on January 10, 2016, 03:34:28 AM
Perhaps we could get more spinal mounted guns? Maybe stacked ones, too.  I'm thinking spinal mounts of just about every gun (railguns and gauss cannons).  If you remember Halo, their ships have massive spinally mounted gauss guns.  I really want to replicate that.
Title: Re: Bigger is Always Better
Post by: Rich.h on January 10, 2016, 03:42:25 AM
Perhaps we could get more spinal mounted guns? Maybe stacked ones, too.  I'm thinking spinal mounts of just about every gun (railguns and gauss cannons).  If you remember Halo, their ships have massive spinally mounted gauss guns.  I really want to replicate that.

Having multiples kind of defeats the point of them, they are designed to be a big gun with an engine and a ship build around it. To have more than one would be just two ships strapped together. Gun of different sizes can already be made so we already have the variety.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: MarcAFK on January 10, 2016, 08:25:25 AM
A research line allowing twin, triple, quad spinals? Please? :(
Or maybe double, triple, quad sized spinals?
Oh boy, 500 mm spinal carronade of doom XD
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Aloriel on January 10, 2016, 09:09:28 AM
I would like to see separate message categories for "officer retires" and "officer dies", or one merged category for both of these messages: "Officer lost"

In the present system, to catch both of those type of messages, you have to have both "officer health" and "officer update" messages unhidden. When you have several hundred officers, officer update can be incredibly spammy, and officer health contains a somewhat deceptive message about long term illnesses that sometimes force a retirement, but usually don't.

Adding this separate category would help us catch when one of our officers has left service for any reason.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Erik L on January 10, 2016, 04:36:00 PM
A Shore Leave command similar to the Overhaul. Should reduce the crew clock.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: 22367rh on January 11, 2016, 02:14:50 PM
Would it be possible to add the option to open multiple system viewer (F3) screens (such that we could load one for each solar system if so desired).

Would not need the top action bar or the time incrementation sections in these new versions.
Also the display settings could be moved out to a single "Sub-Viewer" options section that'd apply the same options to all the instances of the viewer.

The reason for requesting this is that I have 2 monitors, my primary for Aurora is a 1920x1080 but I have a 3840x2160 that I'd like to use to supervise other solar systems without having to cycle the main viewer.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Tssha on January 12, 2016, 11:06:25 PM
Could ships undergoing refit be persuaded not to try executing their default orders? It's a bit annoying having to clear default orders, then forgetting to reset them later, just because they finished their overhaul before their refit completed and they keep interrupting your turns to tell you they can't find any new survey targets in Sol.

I mean, it's not like they're going anywhere until the refit is completed. ;)
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: alex_brunius on January 13, 2016, 04:50:18 AM
Could ships undergoing refit be persuaded not to try executing their default orders? It's a bit annoying having to clear default orders, then forgetting to reset them later, just because they finished their overhaul before their refit completed and they keep interrupting your turns to tell you they can't find any new survey targets in Sol.

I mean, it's not like they're going anywhere until the refit is completed. ;)

Could be very useful to have it work at least for overhauls, now that the new maintenance/hangar/overhaul rules which allow you to conduct these in deep space for survey and front-line needs.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: 83athom on January 13, 2016, 08:05:27 AM
A research line allowing twin, triple, quad spinals? Please? :(
Or maybe double, triple, quad sized spinals?
Oh boy, 500 mm spinal carronade of doom XD
I am for the research for twin/triple spinals. And like how Rich.h said " To have more than one would be just two ships strapped together." I have seen many sci-fi ships that are just that, 2 ships slapped together. Although, that said, you could make a module ship and do just that. A main ship piece and 2 weapons modules each with a few turrets, missiles, and a spinal weapon. Oh, and on the Carronade part; normal research gives you 500mm for it already and goes all the way to 800mm, an advanced spinal version would take it to 1200mm. The 800mm does 168 damage and almost reaches the max beam range, for example.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: MarcAFK on January 13, 2016, 08:50:20 AM
I am for the research for twin/triple spinals. And like how Rich.h said " To have more than one would be just two ships strapped together." I have seen many sci-fi ships that are just that, 2 ships slapped together. Although, that said, you could make a module ship and do just that. A main ship piece and 2 weapons modules each with a few turrets, missiles, and a spinal weapon. Oh, and on the Carronade part; normal research gives you 500mm for it already and goes all the way to 800mm, an advanced spinal version would take it to 1200mm. The 800mm does 168 damage and almost reaches the max beam range, for example.
Oh my bad, 3200 millimetre then:
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: swarm_sadist on January 13, 2016, 08:10:47 PM
Spaceports do not affect the load time of troops into troop transports. Not sure if this is a bug or WAI but it would be nice if they did.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: linkxsc on January 13, 2016, 08:12:43 PM
Turrets. They're nice, they can give ships a better tracking speed than they would have otherwise had... But they're expensive to maintain, drive max repair amounts through the roof. And can be sometimes quite Annoying to build reactors with.

1 give us the ability to build a reactor into a turret. Thus making the turret fully contained. Also this would make it so that armoring turrets is a better deal because that extra armor will help protect the reactor. Perhaps even have it as a drop down, where you can pick reactor tech, it scales the reactor to the size needed to power the guns. And then the size of the reactor can be adjusted by playing with the "boost" settings on the reactor.
High boost tiny reactor in the turret, fine. if that turret gets hit by a laser that penetrates all of its armor though, BOOOM.
This would make it so that it is possible to cause something akin to a magazine explosion when shooting turrets... but also perhaps make turrets a little easier to deal with as they'll be all you need.


Ofcourse the obligatory "Also, Railgun and Plasma Carronade turrets also please"
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: alex_brunius on January 14, 2016, 06:40:58 AM
Ofcourse the obligatory "Also, Railgun and Plasma Carronade turrets also please"

Railguns can't be turreted in fast tracking turrets because of balancing reasons. They would make Gauss obsolete as point defense with their cheap volume of fire.

I would still like to see them inside a turret without speed/gear boost possible, for protection, management and RP reasons.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: rcj33 on January 15, 2016, 12:09:09 AM
twin, triple, quad spinals

twin/triple spinals

Well, it's not quite what you were asking for, but I discovered something related tonight:

(http://i.imgur.com/iImEKsF.png)

Um... Steve, could you make the x4 button do x5 instead?   ;D
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: linkxsc on January 15, 2016, 10:07:54 AM
Railguns can't be turreted in fast tracking turrets because of balancing reasons. They would make Gauss obsolete as point defense with their cheap volume of fire.

I would still like to see them inside a turret without speed/gear boost possible, for protection, management and RP reasons.
....How. Perhaps at lower tech levels yes turreted RGs would beat out GCs, but they can already do that without turrets. With their demand for a reactor and such would make GCs pull ahead fairly quickly.
Hell noone gripes about lasers and mesons out performing GCs until ROF 3. And worst comes to worst GCs would get like a 50% tracking gear penalty. Due to forces involved with firing the RG or something.

Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Bremen on January 24, 2016, 01:46:12 PM
....How. Perhaps at lower tech levels yes turreted RGs would beat out GCs, but they can already do that without turrets. With their demand for a reactor and such would make GCs pull ahead fairly quickly.
Hell noone gripes about lasers and mesons out performing GCs until ROF 3. And worst comes to worst GCs would get like a 50% tracking gear penalty. Due to forces involved with firing the RG or something.

A 100% accurate gauss cannon is 6 HS, a 10cm railgun is 3 HS. Even assuming 1 HS for a reactor (and realistically it's probably more like .2 HS for 3 power), gauss cannons don't pull even until Rate of Fire 6, which is extremely expensive. With more realistic reactor sizes it doesn't pull ahead until RoF 8, and that's literally the last rate of fire tech in the tech tree.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on January 25, 2016, 09:43:34 PM
Some ideas:
Have extremely high thresholds of damage mitigated by atmosphere be converted to air-burst nuclear detonations, without radiation (but perhaps still with dust)? Would cause a bit of destruction to whatever population, structures, PDCs, etc that it would hit.
For balance purposes, we'd be talking an entire 20 damage stopped by atmosphere being the equivalent of a size 1 warhead, for instance, with mitigations below this point being considered inconsequential. To allow medium tech levels who are determined to siege a planet with carronades or lasers, but will need to do it slow and steadily. Might give a much more kinetically satisfying image than just zapping their PDCs down with mesons.

Plasma Carronade Tech: Spinal Mount. Uses the spinal mount from lasers to make your big carronades even bigger, nastier, and more explody at whatever it hits. Essentially would work the same as it does for the lasers, increasing base damage (and max range as a result), with slower reload speed per capacitor capacity.

Plasma Carronade Containment Tech: Works sorta like the wavelength on lasers or velocities on kinetics, except is less effective per tech level (probably just slants the curve a little bit rather than outright increment each damage-level's scope). Each level of this tech increases the size and reload time of the carronade it's applied to.

New Ship Component: Capacitor banks. Function as generators, except the energy they have is 5 times (more or less depending on tech or balance, might be a new tech or an already existing tech in the game) greater than a power plant of the same size, and the power drawn from them is exhausted when used by a weapon. For instance, a weapon that uses 5 power attached to a capacitor with 20 will fire 4 times before becoming exhausted. Capacitors can be recharged in hangar space, but the parent ship needs excess power plant capacity of at least the max charge of the capacitor, and the rate of charge would be determined by capacitor recharge rate tech. Capacitors are also dangerous to use on ships expecting to be hit, I'm guessing that they'd often be HTK 0-1 with internal explosion size equal to half of the stored charge if it detonates within.

Solar Harvesting: A particularly substantially high tech level upgrade of the sorium harvesters, with this addition, stars can sometimes be sources of sorium (rarely), and can be surveyed much like gas giants and will tend to have much lower accessibility, but similarly high stocks if any. Possibility of solar cooling if the star in question is being sucked of all it's sorium?
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Erik L on January 26, 2016, 03:29:28 PM
Not sure if I've posted this prior...

A window or something that shows all known ruins.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: 83athom on January 26, 2016, 04:01:06 PM
Not sure if I've posted this prior...

A window or something that shows all known ruins.
That's already a feature man.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Erik L on January 26, 2016, 04:05:55 PM
That's already a feature man.
I barely use the system display.

I'll amend my suggestion. As above but outside the system display :p
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: swarm_sadist on January 26, 2016, 04:45:41 PM
I barely use the system display.

I'll amend my suggestion. As above but outside the system display :p
Addendum: A toggle to show all anomalies detected.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: linkxsc on January 26, 2016, 10:06:10 PM
So heres 1
Started messing around with genetic modification. Its not impossible to made a species however that earth (or other of your colonies) are completly uninhabitable.
You might work around this sometimes by setting up your gene mod operations on planets that are within the tolerance range of the new species... but I think habitats would be easier.

Make it so you can target a habitat (or task group of them) to send members of a new species to (as a holding, until they can be shipped off to their final actual colony)
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on January 26, 2016, 11:07:53 PM
So heres 1
Started messing around with genetic modification. Its not impossible to made a species however that earth (or other of your colonies) are completly uninhabitable.
You might work around this sometimes by setting up your gene mod operations on planets that are within the tolerance range of the new species... but I think habitats would be easier.

Make it so you can target a habitat (or task group of them) to send members of a new species to (as a holding, until they can be shipped off to their final actual colony)
You can already do this by transferring infrastructure to the colony that is formed by the new species. The infrastructure will support them, and you can just use normal colony vessels (cryo storage) to move them from one world to the next.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: jem on January 27, 2016, 06:15:46 AM
Making Automated fire work on a fc level instead of a ship level.  So that I can tell an individual fc to automaticly open fire on targets without messing with what all the other fc's are doing.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: 83athom on January 27, 2016, 07:01:52 AM
Or a separate button for us who have tons of FC per ship. Also, fix the Auto-fire button so it doesn't reset the FC setting to everything under one FC (2 if you have missiles and beams on one ship).
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Erik L on January 27, 2016, 04:04:25 PM
Q-Ships.

Ships built like Civilian, but mounting military systems.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on January 27, 2016, 04:58:01 PM
Q-Ships.

Ships built like Civilian, but mounting military systems.
Hmm, how do you suppose this be approached? Have military tonnage be taken into account for maintenance, as opposed to total tonnage, for instance? It is tricky to figure.

Oh, yeah, suggestion from me! Perhaps we could make the "structural shell" ship designs also buildable from manufacturing industry, like orbital habitats currently are? Primarily because they have no engine, armor, or weapons capable, I suppose.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Erik L on January 27, 2016, 05:42:58 PM
Hmm, how do you suppose this be approached? Have military tonnage be taken into account for maintenance, as opposed to total tonnage, for instance? It is tricky to figure.

Oh, yeah, suggestion from me! Perhaps we could make the "structural shell" ship designs also buildable from manufacturing industry, like orbital habitats currently are? Primarily because they have no engine, armor, or weapons capable, I suppose.

That's one way to do it. Ideally it would be identical to an equivalent freighter/colony ship from a sensor perspective. At least until the weapons run out and it starts to shoot.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: jem on January 28, 2016, 05:35:18 AM
Not having the game stop on intelligence update or life-pod rescue, in both cases because it becomes quite annoying to have the game stop every 3 days to tell you that alien xyz have no electronic hardening or that you rescued 56 aliens.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: swarm_sadist on January 28, 2016, 10:39:00 AM
I actually like having minute by minute intelligence updates. I just wish that the strategic intelligence window actually worked, or had some sort of notepad or sticky note system.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: jem on January 29, 2016, 02:16:15 PM
An order to unload all ship components. 

And a notification that your salvage ships are full of stuff.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Sirce on January 30, 2016, 09:53:46 PM
One nice adjustment I would like to see is the event message for scientist that improve their skill have a shorthand for what field they are in.

Current: Through experience as a project leader, Scientist Steve Wamsley has increase his Research Bonus to 30%

Suggested (using Construction and Production for example): Through experience as a project leader, CP Scientist Steve Wamsely has increase his Research Bonus to 30%.

This will be nice to have for events update.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Steve Walmsley on January 31, 2016, 06:04:54 AM
One nice adjustment I would like to see is the event message for scientist that improve their skill have a shorthand for what field they are in.

Current: Through experience as a project leader, Scientist Steve Wamsley has increase his Research Bonus to 30%

Suggested (using Construction and Production for example): Through experience as a project leader, CP Scientist Steve Wamsely has increase his Research Bonus to 30%.

This will be nice to have for events update.

Added for v7.2
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Drgong on January 31, 2016, 03:20:22 PM
I would like to by able to flag some officers to be saved (as a hall of heros or such) after their retirement or death.   
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: MarcAFK on February 02, 2016, 01:01:20 AM
Added for v7.2
Through experience as a project leader scientist steve walmsley has increased his game design rating to 30%
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Erik L on February 02, 2016, 11:21:42 AM
Suppression of inability to complete conditional orders while the TG is in refit or overhaul.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Erik L on February 02, 2016, 12:52:27 PM
The ability to turn a colony into a ruin. This would take all of the existing infrastructure, missiles, ship components, facilities and mineral stockpiles and convert them into abandoned installations. Probably at 25-35% total volume.

This is in relation to this idea on reddit. https://www.reddit.com/r/aurora/comments/43u2sk/my_idea_for_a_campaign_feasible/
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Drgong on February 02, 2016, 02:46:12 PM
some ideas off the top of my head that would be nice.   Some ideas will be silly.

1.   The ability to flag some people to be saved for viewing even after they died.    Not all of them, just ones that you flag by a click or by awarding a specific medal.
2.   Random slow generation ship arrives into system.   Might be good tech, might be out of date, but they will try to settle with say, 1 million population on a planet.
3.   Random chance for a "Fleet of ships" race that travels from system to system with a large fleet mining it out and moving on.   (Most likely this is a bad idea as it would bog the system down, but it still a cool idea)
 
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: 83athom on February 02, 2016, 04:30:41 PM
2.   Random slow generation ship arrives into system.   Might be good tech, might be out of date, but they will try to settle with say, 1 million population on a planet.
Wouldn't really fit with the feel of the game.
3.   Random chance for a "Fleet of ships" race that travels from system to system with a large fleet mining it out and moving on.   (Most likely this is a bad idea as it would bog the system down, but it still a cool idea)
So the Swarm which is already in the game.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TheDeadlyShoe on February 03, 2016, 09:56:37 AM
Research/Engineering split.

I've been hesitant to suggest something like this because it sounds complicated, but maybe it is not so bad in practice.

Basically: Remove techs that progress basic technology (like new power plant tech, or EM sensor level) from the current research list and add them to a new list for theoretical research.

Theoretical research would use a fixed pool of RPs that is not determined by research labs, only by other factors like scientist skill or anomaly multipliers.   Alternatively, only a fixed number of labs can be used for theoretical research at any one time - 5? 10?.   The RP cost of theoretical research would not escalate to the same degree as the RP cost of regular research ("Engineering"), because there is no expectation of an increasing # of research labs.  A simple way to implement this would be to generate theoretical RPs automatically, and the player simply insta-buys theoretical projects when they can afford the cost. Mechanically, this is very similar, although perhaps it is not as strong for narrative purposes.

The idea is that even smaller empires can keep up in basic technology.  Right now, larger is always better; more wealth, more RPs, more technology.  With a science/engineering split, both the small empire and the large empire might have the same level of basic technology. However, the larger empire would still have a large advantage in engineering; it would be far easier for them to build large sensors, large engines, powerful jump drives, etc.

There are numerous basic techs that would still make sense as remaining in engineering, like colony cost multiplier or engine multiplier.

Missile Agility Bonus
Random thought:  Missiles get a small % bonus to agility based on the number of missiles the engine has.    This would cap out somewhere (8x?), but it would mean missiles arn't literally always better off with a single engine like they are now.  There is a RP premium for researching single engines for missiles, but it is so small as to be a nonfactor IMO.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Erik L on February 03, 2016, 09:59:37 AM
Research/Engineering split.

I've been hesitant to suggest something like this because it sounds complicated, but maybe it is not so bad in practice.

Basically: Remove techs that progress basic technology (like new power plant tech, or EM sensor level) from the current research list and add them to a new list for theoretical research.

Theoretical research would use a fixed pool of RPs that is not determined by research labs, only by other factors like scientist skill or anomaly multipliers.   Alternatively, only a fixed number of labs can be used for theoretical research at any one time - 5? 10?.   The RP cost of theoretical research would not escalate to the same degree as the RP cost of regular research ("Engineering"), because there is no expectation of an increasing # of research labs.  A simple way to implement this would be to generate theoretical RPs automatically, and the player simply insta-buys theoretical projects when they can afford the cost. Mechanically, this is very similar, although perhaps it is not as strong for narrative purposes.

The idea is that even smaller empires can keep up in basic technology.  Right now, larger is always better; more wealth, more RPs, more technology.  With a science/engineering split, both the small empire and the large empire might have the same level of basic technology. However, the larger empire would still have a large advantage in engineering; it would be far easier for them to build large sensors, large engines, powerful jump drives, etc.

There are numerous basic techs that would still make sense as remaining in engineering, like colony cost multiplier or engine multiplier.

Missile Agility Bonus
Random thought:  Missiles get a small % bonus to agility based on the number of missiles the engine has.    This would cap out somewhere (8x?), but it would mean missiles arn't literally always better off with a single engine like they are now.  There is a RP premium for researching single engines for missiles, but it is so small as to be a nonfactor IMO.

How would this affect those of us who don't research components, just the requisite tech? I almost always play with SM mode and instant research my ship comps.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on February 03, 2016, 11:43:16 AM
Suggestion for new Railgun tech: Ablation Sabot
Each level of this does all of the following to the railgun mount:
Increases damage.
Slightly widens the damage profile (each level is an increase, with max level being about as wide or wider than missile profile)
Decreases shots per-volley (1 less for each level, down to 1 shot per volley at max level)
Ignores a certain amount of atmosphere for damage calculations. Each level means more atmosphere is ignored for damage reduction calculations. Not sure if it should be a flat amount or percentage amount.
Title: Re: Semi-Official 7.0 Suggestion Thread - Suggestion for Interrupt tuning
Post by: Havan_IronOak on February 03, 2016, 05:56:35 PM
Being a rookie I could be WAY off, but these seem like simple changes to implement...

Remove the interrupt when a ground-based geo-survey team levels up a member.  - It's nice to know but doesn't always require immediate action.
Add an interrupt when a ground-based geo-survey team completes a survey. - They start spamming messages. Might as well pause the game and allow the player to deal with it.

If I'm missing something on either of these, please forgive. :-[  ...but I'd love to know what I'm missing  ???
Title: Re: Semi-Official 7.0 Suggestion Thread - Suggestion for Interrupt tuning
Post by: 83athom on February 03, 2016, 06:32:29 PM
Remove the interrupt when a ground-based geo-survey team levels up a member.  - It's nice to know but doesn't always require immediate action.
Add an interrupt when a ground-based geo-survey team completes a survey. - They start spamming messages. Might as well pause the game and allow the player to deal with it.
The first doesn't interrupt. Its the fact that the rating of a team changed that causes the interrupt. To the second; That's already a thing.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Havan_IronOak on February 03, 2016, 11:48:51 PM
I would like to by able to flag some officers to be saved (as a hall of heros or such) after their retirement or death.   

I kinda like this too. Or perhaps they could be added to the naming list. The US navy has a Spruance Class and ship called the Reagan.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Stardust on February 04, 2016, 09:36:24 AM
Introduce a method for influencing the specialty of scientists graduating from the academies.

Some ideas:

- Have the number of research labs assigned to a specific branch of technology influence the specialists graduating from the academies.

- Add an adjustable starting salary for each branch of technology that encourages budding scientists and affects research expenditures.

- Allow construction of different types of academies or even the ability to design academies as a research project.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on February 04, 2016, 10:35:29 AM
This is something I posted in the thread on battleship guns, but I thought it deserved to be posted here, too.
All of this gives me an idea for a way to potentially make this system more realistic without making Steve tear his hair out.  At the moment, it's assumed that any ship with only civilian systems has no maintenance problems with 1 engineering space, even if it's 200,000 tons, and any ship with any military systems has maintenance problems, even if it's only a size-2 sensor, and this affects everything on the ship.
What if we changed the rules a bit?  Instead of the current test, give a two-pronged test of military status.  First, all ships get a computed AFR, and a ship cannot be civilian if the AFR is over a certain value.  I don't know exactly what this value should be, as I don't have Aurora open, but as a rule of thumb, it's a value that can be done with a typical 5-cargo bay cargo ship and 1 engineering space.  Larger ships will need more engineering spaces to count as civilian.
Second, the ship can't be more than, say, 5% military systems by size.  This should make it pretty much impossible to build an efficient warship and have it count as 'civilian', while still allowing you to mount a bit of self-defense armament on your fleet tenders.
Another thing that might be helpful would be to drop the 25-HS limit on civilian engines while maintaining the power multiplier regulations.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Erik L on February 04, 2016, 10:49:31 AM
A way to create interrupts. Mainly for things like awarding a medal when criteria are met. Or the ability to auto-award medals.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Havan_IronOak on February 05, 2016, 12:03:22 AM
I suggest that creating a requirement that geo-survey teams be created out of the people on a given colony would be a great improvement to this mechanic.

Of course this would include needing standing orders for ships to pick up Geo-survey teams that need pickup wherever they happen to be, move to the nearest colony still needing a ground survey and drop them off.

The current workaround method (forming a team wherever a ground survey is needed and then disbanding it when done - all from the colony screen  is incredibly "fiddley")
 Just as a test today (while working on something that didn't require my full attention) I decided to see what I could learn about how this mechanic worked.

I selected every stellar body in the SOL bigger than 500 diameter and did the manually form and disband strategy.
I also included every body where a complete orbital geo-survey had found minerals)
I also selected a bunch of smaller bodies as well to bring the total up to 150 bodies in all
Using 5 day auto advance and stopping every time a team finished, I ground surveyed 72 bodies before I got my first success.  I'm well over 100 and so far only 2 successes. I will finish this experiment tomorrow when I'm stuck again. I'm now juggling 5 Geo-survey teams. :)

I was stuck with nothing to do in my between task down-times and my computer was available so I ran this experiment. Even as a secondary background task between Real Life interruptions it  felt really really monotonous. I just don't see many people using this feature in its current form when gaming.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Havan_IronOak on February 05, 2016, 03:37:00 PM
Another suggestion I have is that history be displayed more consistently.  That requires some explanation...

The log displays events with the most recent on the bottom. I'm guessing that there's reason that that method was chosen and while it's traditional in Western cultures to assume things are presented in top-down order, its quite easy to make the adjustment.

However, thing get a bit confusing when one looks at the Officer History section of the Commanders Window. There older entries seem to be at the top except that when two entries have the same date, the newer entry appears first.

If I look at the entries for my current governor of 9 Metis I see
a) 7th October 2026: Promoted to Civilian Administrator
b) 17th November 2026: Assigned to Governor of Andromache
c) 22nd April 2035: Assigned to Governor of 9 Metis
d) 22nd April 2035: Relieved from Governorship of Andromache. Remaining on the planet and awaiting new orders.

This is a bit misleading until one realizes that the entries should be read
a) 7th October 2026: Promoted to Civilian Administrator
b) 17th November 2026: Assigned to Governor of Andromache
d) 22nd April 2035: Relieved from Governorship of Andromache. Remaining on the planet and awaiting new orders.
c) 22nd April 2035: Assigned to Governor of 9 Metis

Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Havan_IronOak on February 05, 2016, 03:51:08 PM
Not that Terra-forming isn't great already but...

How about bringing radiation into play? Perhaps a Trans-Newtonian gas that blocks radiation while making an atmosphere "sticky". Terra-forming Mars in Real life would not work as depicted here because Mars no longer has a molten core and doesn't produce enough of a magnetic field to stop the stellar winds from blowing away what little atmosphere Mars has.

Sorry, it's just the "astronomy geek" coming out in me.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on February 05, 2016, 07:15:18 PM
Not that Terra-forming isn't great already but...

How about bringing radiation into play? Perhaps a Trans-Newtonian gas that blocks radiation while making an atmosphere "sticky". Terra-forming Mars in Real life would not work as depicted here because Mars no longer has a molten core and doesn't produce enough of a magnetic field to stop the stellar winds from blowing away what little atmosphere Mars has.

Sorry, it's just the "astronomy geek" coming out in me.
That's an effect which works on geological timescales, not the sort of timescales you see in Aurora.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: jiduthie on February 06, 2016, 03:36:20 AM
...the ability to auto-award medals.

This would be very useful to me in my current campaign. I'm in the habit of awarding low promotion score medals("battle badges") to every officer involved in a major battle. That way I can go back and look at an officer's history and tell the engagements in which she's been involved. An option to award a medal to every officer in a system/task force/task group (whichever is easiest) would be much appreciated. Medals based on tonnage destroyed and/or an "Aces of the Deep" style leader board would be icing on the cake. Even being able to sort officers by tonnage destroyed would be great.

I would also love to see medal names and possibly dates displayed at the bottom of the "Ratings and Bonuses" box of the Commanders screen. I think it would make sense given that medals add bonuses. I also like to award 'merit-based' medals in a certain order and it can be a pain to hunt the history box to see if a given medal has already been awarded.

I'd also really like a .06HS fuel tank. The current 'Crew Quarters - Fighter' uses .04HS but on ships small enough to make use of it, it just ends up resulting in a 497 ton fighter. There's nothing else that that'll fit in there, so I always end up replacing it with 'Crew Quarters - Tiny' to make it an even 500 tons despite the fact that it doubles my crew and the spare berths/deployment time adds nothing appreciable to my vessel's capabilities.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: El Pip on February 06, 2016, 04:38:28 AM
I'd also really like a .06HS fuel tank. The current 'Crew Quarters - Fighter' uses .04HS but on ships small enough to make use of it, it just ends up resulting in a 497 ton fighter. There's nothing else that that'll fit in there, so I always end up replacing it with 'Crew Quarters - Tiny' to make it an even 500 tons despite the fact that it doubles my crew and the spare berths/deployment time adds nothing appreciable to my vessel's capabilities.
I'm glad it's not just me who is doing that sort of thing. Having to go and manually put in a bigger crew quarters to get a neat fighter size always seems a waste, but I find the odd sizes bother me. The option to make use of that spare 3 tons would be great.

I also completely agree with the medal award ideas. I'd like to award everyone a medal after a battle, but the thought of trying to find 20 FAC officers out of a huge list is sometimes just too much to face. Giving a medal to everyone in a task force/fleet/whatever would solve that.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Havan_IronOak on February 06, 2016, 09:51:47 PM
I'd suggest that you add one (or more) sort options to the colony list  in the Population and Production window.  I'm not sure of the current order but an alpha presentation order would be great when the list gets long. Of course that could be within whatever order is already there.

The Group by Function checkbox is helpful but even that's not enough for really long lists of colonies within an system (Particularly important during the ground based survey phase)
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Havan_IronOak on February 07, 2016, 03:58:11 AM
The Colony Summary Window (Opened by using F2) shows Colony Summary as the title when one uses the Icon button at the top of the System Map screen. Yet the title that appears in the window says "Population and Production.

It would simplify things for the uninitiated if the two titles were consistent.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Havan_IronOak on February 07, 2016, 12:37:57 PM
When creating teams it would be helpful if we could filter the list of qualifying members to exclude scientists actively engaged in research but potentially see other assigned candidates.  When forming a geo-survey team I'll gladly pull a rock guy off commanding a freighter. Others can do that just as well.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Thineboot on February 08, 2016, 01:07:51 AM
Add "Shore leave" under Task Groups > Special Orders > Default Orders, maybe with some percentages lower than 100% morale.     
And under Task Groups > Task Group Orders when it's a populated colony with at least some recreational facilities.     

Respectively an order the reduce the Crew (mths) to a proper amount.   


As far as I can see there is no Order to raise moral without checking frequently.      There is an event "Shore Leave"  :)




Edit: While there is an event you can't force a task group to stay at a colony unless you're resetting conditional orders. 
Please add under
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on February 08, 2016, 09:54:01 AM
Could we get an option to auto-assign officers that don't have crew training ratings?  It's a good way to train them to get crew training ratings, which is why I like to do it, but it's a hassle, particularly in big games.

Also, big games tend to see an overabundance of senior officers.  I know I could theoretically divide up my fleet into more Fleets, but that would mess with crew training rather badly as ships get rotated between them.  Some form of 'squadrons' which could absorb the mid-range officers would be nice.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Havan_IronOak on February 08, 2016, 10:17:53 AM
There is a hide CMC option on the Populated systems list. That can be very useful in the mid and late game.

In the early game what I'd love to see would be an option to alternatively hide/show colonies with staff and/or assets on them. I seem to always be looking for my Geo-survey teams or tying to pick a place to next send them. Being able to see only those colonies with teams or to omit colonies with teams on them would make navigating the list much easier.

It also seems that an optional alpha sort would be a useful option.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: 83athom on February 08, 2016, 10:47:15 AM
In the early game what I'd love to see would be an option to alternatively hide/show colonies with staff and/or assets on them. I seem to always be looking for my Geo-survey teams or tying to pick a place to next send them. Being able to see only those colonies with teams or to omit colonies with teams on them would make navigating the list much easier.
Here is a tip, abandon the colonies that you are done with (surveyed and without team). It doesn't delete the materials or your knowledge of whats on it, only installations and teams on the surface. When you want to put mines back on them, it will recreate the colony automatically.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Havan_IronOak on February 08, 2016, 10:40:49 PM
When a Geo-survey team completes its task, one can bring up the colony quickly by clicking on the Event Log text message then right clicking on the colony in question (the system map is centered on the colony on which they're stationed.) (Assuming that one has not opted to disable the jump to event feature)

If one accidentally assigns a Geo-survey team to body that's not been orbitally surveyed yet, that method doesn't work. Clicking on the Event Log text message that the team cannot begin operations doesn't re-center the map. It probably should.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TheDeadlyShoe on February 09, 2016, 06:05:08 PM
Quote
How would this affect those of us who don't research components, just the requisite tech? I almost always play with SM mode and instant research my ship comps.

Engineering wouldn't just be components, as I imagine it. It would include unlock technologies like orbital habitats, and multiplier techs like engine mults.  Capacitors maybe.

Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: jiduthie on February 10, 2016, 12:09:48 AM
Currently the buttons for renaming alien classes aren't created in the intelligence window when using reduced height windows. The options for renaming individual ships exist and there's space for the extra buttons just to the left of that.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on February 10, 2016, 09:38:07 AM
Could we have missile armor scale with size somehow?  It seems a bit bizarre that the same amount of armor provides the same protection to a size 20 missile as a size 1 missile.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: 83athom on February 10, 2016, 09:52:26 AM
Could we have missile armor scale with size somehow?  It seems a bit bizarre that the same amount of armor provides the same protection to a size 20 missile as a size 1 missile.
Because that is's the total weight of armor on the missile. 1 MSP is 1/20th of a HS (50 tons) so is 2.5 tons. 2.5 tons of armor should provide the same protection as 2.5 tons of armor. A better way to RP it is like a dome shaped piece of armor on the front of the missile instead of a coating around the whole missile.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Rich.h on February 10, 2016, 09:54:28 AM
In the task groups screen it would be nice on the naval organisation tab to have an export to txt button. Quite often I tend to use the same style of organisation structure for my games and at present the only real option is to keep a running txt file with a copy made by hand.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: 83athom on February 10, 2016, 10:00:59 AM
A mine fire control. On the design with it, have it replace the "Open fire" buttons with "Drop Ordinance" and it would not need a target to function. It would also give the design some orders like; "Lay mines on path" when selecting a destination in the order window which would lay mines along the path between the start point to your destination, maybe add a box for a separation time between drops (in hundreds of seconds). "Create mine field/ring" it would make a ring of mines around the selected destination at a 30 degree separation at the distance set by the "Minimum distance to target" (maybe additional orders/selection for degree separation, like how you select ground forces/team to load/unload). Of course if the design doesn't have enough mines/runs out, it could give an interrupt saying "*Task group* doesn't have enough ordinance to complete current order"
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Psawhn on February 10, 2016, 07:45:21 PM
Quote from: Sirce
One nice adjustment I would like to see is the event message for scientist that improve their skill have a shorthand for what field they are in. 

Current: Through experience as a project leader, Scientist Steve Wamsley has increase his Research Bonus to 30%

Suggested (using Construction and Production for example): Through experience as a project leader, CP Scientist Steve Wamsely has increase his Research Bonus to 30%. 

This will be nice to have for events update.
Quote from: Steve Walmsley link=topic=8107. msg85576#msg85576 date=1454241894
Added for v7. 2

Would it be easy to change all officer updates to gender-neutral language? It's just peculiar to see obviously feminine names be attributed with "his. "

"Through experience as a project leader, the Research Bonus of PP Scientist Elena Ivanova has increased to 30%. "

"Although not currently assigned to a project, the Research Bonus of LG Scientist Janine Richards has increased to 20% via hard studying. " or ". . . LG Scientist Janine Richards has studied hard and now has an increased Research Bonus of 20%. "

"Through training or experience, the Mining Bonus of Civilian Administrator Nathaniel Sisto has increased to 45%. "
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Thineboot on February 11, 2016, 03:02:17 AM

Accidentally stumbled upon


Through experience as a project leader, Scientist ___ ___ has increased his Research Bonus to __%


Ok, that's normal but when he gained Bonus he had 0 research labs because of temporary push another project.
After testing this behavior it seems Scientists only need to be pretend to work on a project.
Maybe I'm wrong and they raise even without this, maybe it's working as intended.
Please check it and if necessary add a proper query.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Havan_IronOak on February 11, 2016, 04:03:07 AM
In the Mining Tab of the Population and Production window There is an average shown of all availabilities which looks to be calculated as the sum of all non-zero availabilities/ # of non-zero availabilities.  While that stat  has some merit another one might be even more useful. That is the sum of all non-zero availabilities / 11.

Assume that your home world has 5 resources all with huge quantities but at .2 availability The screen would currently show an average of .2

Now assume that an asteroid has supplies of only two elements (probably in lesser quantities)  but with an availability of .4 for each The screen would show an average of .4

Using the revised calculation the home planet would show .09 while the asteroid would show .07

Since moving a single automated mine from the home world would decrease overall mining production there is some validity to the second method of calculation.
Perhaps one or both could be displayed in the header area or in side by side cells?
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Rich.h on February 11, 2016, 04:57:44 AM
Accidentally stumbled upon


Through experience as a project leader, Scientist ___ ___ has increased his Research Bonus to __%


Ok, that's normal but when he gained Bonus he had 0 research labs because of temporary push another project.
After testing this behavior it seems Scientists only need to be pretend to work on a project.
Maybe I'm wrong and they raise even without this, maybe it's working as intended.
Please check it and if necessary add a proper query.

That is normal it was added in to help with micromanagement issues, you used to always have to assign someone to a project to get experience. This led to essentially exploiting the system by giving a scientist one lab and a project so they could get better, the main reason being otherwise you would get your main scientist retire or die and suddenly have no one able to field more than 5 or 10 labs in a project. This way you still get a drop in admin rating but it is not quite so severe so the desire to do silly 1 lab projects is taken away.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TheDeadlyShoe on February 11, 2016, 01:12:52 PM
Quote
Could we have missile armor scale with size somehow?  It seems a bit bizarre that the same amount of armor provides the same protection to a size 20 missile as a size 1 missile.
My impression is that Steve is really unhappy with missiles having armor/HTK at all;  on a per-ton basis it doesnt make alot of sense even as is.  Ofc, you can handwave it as 'surviving near misses'.

I did start sketching out an idea where missiles would have an ecm/decoy 'htk' at one point.  Like, a missile salvo of ten missiles where the individual missiles have 1 point of decoys would have 2 'htk'; an incoming attack would roll against that sorta like how missiles work now. The difference is that a 'miss' would reduce the Decoy value by 1 point, so the salvo would now have 19/10 or 1.9 'htk'. 
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Thineboot on February 12, 2016, 09:56:08 AM
Please add a "Double Click" on "Select Team" in "Task Group Orders" to add move.
At the moment you can only "Add Move" (click or shortcut).


Same for "Select Ground Unit" aso.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Kirkegaard on February 12, 2016, 11:17:22 AM
I have two minor suggestion for improving the "Geological Survey Report"

1) Add an "Ignore colonies" option. Since it would be rather nice to remove already existing colonies from the search and should be rather easy to do.

2) Add an all or totals to the list of minerals. So you can search for total number of all minerals.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Cargus10 on February 12, 2016, 02:25:16 PM
OK, maybe this has been mentioned before, but there's a lot of board messages out there :)

1.  Automation

- A separate tech area under C&P
- reduces crew requirements for ships
- eventually reduces population requirements for everything.
- need at least 1 level for Automated Mines

2.  Crew Replenishment

- Have  a "personnel" module ant gets filled from population.
- when ordered to "rotate crews", can take a low-morale crew off a ship, and replace with a new, rested crew.
- if done on military ships, crew grade should suffer considerably.
- regular shore leave should also lower crew grade slightly (retirees, awols, etc. )
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: jiduthie on February 13, 2016, 03:14:50 AM
A check box for "don't interrupt on completion" order would be handy for tankers or freighters that are stationed on a pop for quick runs to nearby planets/moons. Sometimes I purposely leave a single freighter or tanker on a population and I'm not particularly worried if he's not doing anything productive at any given increment.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Mor on February 13, 2016, 04:38:01 AM
In the Technology Report window. Please add a default "category" All, which will be useful early on or for those who don't employ many simulations designs. Those who do will still be able to pick a specific mask.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on February 14, 2016, 01:02:02 AM
Cryological spaces on PDCs, with the explicit use as a "fallout shelter" for civilians. Would likewise take largely the same amount of time to load and unload as normal cryo ships do, though, so you'd best load them if you know you're going to have a large risk of oncoming planetary bombardment.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Rich.h on February 14, 2016, 05:26:32 AM
It would be nice if when boarding ships you could get POW's, I was under the false impression this happened already but it seems not to be the case, but if you board a ship and get "61 survivors for interrogations" then the ship should have 61 POW's on board.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: firsal on February 14, 2016, 07:55:24 AM
Hi all! I'm a long time lurker on these forums, and i absolutely love this game.  Seeing that ground combat has received some attention lately (i lost my smeg when i saw the post detailing titans), I'd like to throw in a succession of my own :D

Artillery has been a major part of warfare for most of human history and i find it weird that these types of units are not properly represented in game.  While one could disregard the issue by assuming that artillery is already a part of existing unit types, such an assumption is totally unrealistic as modern-day heavy artillery are usually organised into battalions at the very lowest level.

What I'm proposing is that Steve will add a new type of unit, the Artillery Battalion, which will have the following characteristics:

-can be researched for 5000RP. 
-50%-75% of race combat power on the attack, zero defence
-instead of attacking like other ground units, it bombards them.  This bombardment attack can be directed at opposite units like a regular attack, but the Artillery battalion does not take any damage from the engagement.

Seeing that Steve has implemented a bombardment mechanic for Titans, i do not think that it would take much work to add this unit type in (although i may be mistaken since I'm not a programmer)

Also, sorry for my bad grammar and lack of capitalised i's  ;D i typed this all up on my mobile
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: swarm_sadist on February 15, 2016, 01:11:24 AM
Looking at the above thread, can we get a combat intensity setting for ground combat (similar to MOO3)?

Low intensity fighting when you don't want the titan's artillery blasting a hole where the enemy (or your) factories are. High intensity fighting for all out assaults without a care for damaged factories, or scorched earth tactics when fighting on your own soil.

MOO3 and Galactic Civ also had special bonuses you could select such as Chemical Weapons, Bio Weapons, Nuclear Weapons, Rods from God and so forth, although I'm not sure that would mesh well with Aurora.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: drejr on February 15, 2016, 01:31:23 AM
Low-intensity titan warfare?  ???

The one thing I would like to see in ground combat is NPRs who aren't purely reactive. I have no idea how difficult it would be to program an NPR to perform invasions, but even if they could attack ground forces on their planet it may make combat drops an essential tool for planetary assault as well as boarding.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TheDeadlyShoe on February 15, 2016, 04:39:51 AM
Inertial Locks

An Inertial Lock is a planetary facility capable of instantly negating the Transnewtonian pseudovelocity imparted by small TN-era ship drives within a suborbital radius of a planet, most notably the drive of any practical missile design.  Larger drives, even those of fighters, are immune to the effect.

Any missile salvo that intercepts a population or ground force on a body protected by an Inertial Lock would have an additional flight time added to it, similar to ICBM flight time mechanics.  Speed would be the sole determinant of this flight time.  Even a moderately capable point defense array would thus be capable of destroying a far disproportionate # of incoming missiles. Although such missiles speed would have dropped to essentially that of a sitting duck, the inertial lock's interference would make missile ECM far more capable than normal.

Inertial locks would be permanent installations owing to the immense complexity of the fine tuning process adapting it to a local geomagnetic field.  The primary cost would be in Boronide for the massive power requirements.  They could be destroyed as normal as a side effect of ground combat, but the easiest way of defeating them would be attaining total ground superiority.  Alternatively, they could be PDC-mounted

It would be relatively easy to slot Inertial Locks into existing gameplay, but interaction with NPRs is a little more problematic.  Since NPRs do not build PDCs, they would not benefit much from Inertial Locks once any orbiting space stations are destroyed.  They would work well with any conflict between two player races, but to work for NPRs it requires either PDCs or some other means for ground forces to contest a beam-armed opponent in orbit.

Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Black--Snow on February 15, 2016, 05:32:54 AM
Programmable actions would be nice.  Just little scripts we can put in place of the pre-set "Default actions" and "Condition actions" (If I say, wanted the ship to refuel at a specific planet)
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: swarm_sadist on February 15, 2016, 11:12:34 AM
Inertial Locks
Off-Topic: show

An Inertial Lock is a planetary facility capable of instantly negating the Transnewtonian pseudovelocity imparted by small TN-era ship drives within a suborbital radius of a planet, most notably the drive of any practical missile design.  Larger drives, even those of fighters, are immune to the effect.

Any missile salvo that intercepts a population or ground force on a body protected by an Inertial Lock would have an additional flight time added to it, similar to ICBM flight time mechanics.  Speed would be the sole determinant of this flight time.  Even a moderately capable point defense array would thus be capable of destroying a far disproportionate # of incoming missiles. Although such missiles speed would have dropped to essentially that of a sitting duck, the inertial lock's interference would make missile ECM far more capable than normal.

Inertial locks would be permanent installations owing to the immense complexity of the fine tuning process adapting it to a local geomagnetic field.  The primary cost would be in Boronide for the massive power requirements.  They could be destroyed as normal as a side effect of ground combat, but the easiest way of defeating them would be attaining total ground superiority.  Alternatively, they could be PDC-mounted

It would be relatively easy to slot Inertial Locks into existing gameplay, but interaction with NPRs is a little more problematic.  Since NPRs do not build PDCs, they would not benefit much from Inertial Locks once any orbiting space stations are destroyed.  They would work well with any conflict between two player races, but to work for NPRs it requires either PDCs or some other means for ground forces to contest a beam-armed opponent in orbit.

Wouldn't that affect the missiles coming from the planet as well? That would just mean that meson PDCs are the way to go for both the player and the NPR (even though NPR don't build PDCs, which means that they would start having to). My 2 cents is that planetary shields would be a better use of resources because you would still be able to hit the enemy yourself.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on February 15, 2016, 11:34:58 AM
Wouldn't that affect the missiles coming from the planet as well? That would just mean that meson PDCs are the way to go for both the player and the NPR (even though NPR don't build PDCs, which means that they would start having to). My 2 cents is that planetary shields would be a better use of resources because you would still be able to hit the enemy yourself.
Throw in some technobabble about 'the outgoing missiles are synchronized with the inertial lock'.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TheDeadlyShoe on February 15, 2016, 11:49:17 AM
Mesons already dominate thick-atmosphere orbital battles; there's no real way to change that without changing either mesons or the atmospheric penalty.  Hell, even without an atmosphere 10cm mesons are ridiculously good at slugging+ are good PD.  It's not like PDCs can pick their range.

Note that even if both sides have to play fair with the Inertial Lock, it doesn't stop defensive missile fire. PDCs could still fire up and out, but the flight delay would limit missile response times and range.  Basically, take five minutes off the flight time of a missile, applied right at the start - you'd still be plenty effective, if a bit vulnerable to baiting tactics.  The major fault for missile silos would be that any anti-missile asset within range of the atmosphere could gun down outgoing missiles with the same ease that defenses gun down incoming ones. Oh, and most AMM designs would likely flame out on the way up.  NBD if their targets also hit the field, but bad for covering orbital assets or hitting enemy ships. 

IMO, the trouble with a linear defense like a planetary shield is that it's just more hitpoints to be smashed flat by a superior attack fleet.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Sematary on February 15, 2016, 01:15:50 PM
Mesons already dominate thick-atmosphere orbital battles; there's no real way to change that without changing either mesons or the atmospheric penalty.  Hell, even without an atmosphere 10cm mesons are ridiculously good at slugging+ are good PD.  It's not like PDCs can pick their range.

Note that even if both sides have to play fair with the Inertial Lock, it doesn't stop defensive missile fire. PDCs could still fire up and out, but the flight delay would limit missile response times and range.  Basically, take five minutes off the flight time of a missile, applied right at the start - you'd still be plenty effective, if a bit vulnerable to baiting tactics.  The major fault for missile silos would be that any anti-missile asset within range of the atmosphere could gun down outgoing missiles with the same ease that defenses gun down incoming ones. Oh, and most AMM designs would likely flame out on the way up.  NBD if their targets also hit the field, but bad for covering orbital assets or hitting enemy ships. 

IMO, the trouble with a linear defense like a planetary shield is that it's just more hitpoints to be smashed flat by a superior attack fleet.

What I am hearing right now is "Masons are really effective in planetary defense, beam weapons are pretty well useless, and AMMs are the only things that offer a real option to Masons in planetary defense, so you know what would be cool? Nerf all missiles when it comes to planetary defense so Masons get to be even more effective and AMMs get nerfed to the point where they can't really compete with the old Mason strength, and beam weapons stay just as useless."

I don't see that as a great idea. I am all for Aurora being a mix of realism and great story telling but when we go off into fantasy land for great story telling I can't really justify giving fewer viable options instead of giving more. Its a cool idea and all but the effect I see coming from that is all PDCs would be mason based and nothing else. To me that just takes away story potential rather than adding it and its not a change being made to fit realism or anything so I can't really see a pro from either an RP side or a game play side.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Thineboot on February 15, 2016, 04:12:31 PM

It could even just assign as many as are available if the amount typed in is larger than the number of available labs, rather than showing an error dialog and then doing nothing.
Please add automatically assign new research lab to (1) top project as long as possible without stopping auto turns (simple, just code) or (2) add a checkbox to projects so we can designate a specific project. Still log the event but speed up the game.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on February 15, 2016, 05:54:07 PM
What I am hearing right now is "Masons are really effective in planetary defense, beam weapons are pretty well useless, and AMMs are the only things that offer a real option to Masons in planetary defense, so you know what would be cool? Nerf all missiles when it comes to planetary defense so Masons get to be even more effective and AMMs get nerfed to the point where they can't really compete with the old Mason strength, and beam weapons stay just as useless."

I don't see that as a great idea. I am all for Aurora being a mix of realism and great story telling but when we go off into fantasy land for great story telling I can't really justify giving fewer viable options instead of giving more. Its a cool idea and all but the effect I see coming from that is all PDCs would be mason based and nothing else. To me that just takes away story potential rather than adding it and its not a change being made to fit realism or anything so I can't really see a pro from either an RP side or a game play side.
You could still launch missiles from orbital space stations, at least.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TheDeadlyShoe on February 15, 2016, 08:48:39 PM
What I am hearing right now is "Masons are really effective in planetary defense, beam weapons are pretty well useless, and AMMs are the only things that offer a real option to Masons in planetary defense, so you know what would be cool? Nerf all missiles when it comes to planetary defense so Masons get to be even more effective and AMMs get nerfed to the point where they can't really compete with the old Mason strength, and beam weapons stay just as useless."

I don't see that as a great idea. I am all for Aurora being a mix of realism and great story telling but when we go off into fantasy land for great story telling I can't really justify giving fewer viable options instead of giving more. Its a cool idea and all but the effect I see coming from that is all PDCs would be mason based and nothing else. To me that just takes away story potential rather than adding it and its not a change being made to fit realism or anything so I can't really see a pro from either an RP side or a game play side.
If you're trying to use beam weapons in a heavy atmosphere, you have to use them from orbitals *anyway*. Everything apart from mesons is literally useless in PDC combat right now.  If I had a magic wand, or could mod things, I'd just remove mesons from the game entirely - or at least remove them from the standard research list and make them a secret tech. I never use mesons in my own games. They always have and always will be the 100x best weapon for orbital combat as is.   If you have a suggestion for fixing that I'd love to hear it.

The point of the inertial lock is to introduce some nonlinear gameplay, similar to jump points.  Ground targets become very well protected from missile bombardment with even a minimally useable point defense, and on a shared homeworld game you can't launch a missile ground strike without the other guys getting to respond.   PDC hangar bays with warships or fighters become very attractive, since they are well protected from missile fire and can launch dedicated beam warships if the enemy comes into close range.

And there's no reason an inertial lock would have to effect defenders.  That's purely up to how its implemented. Also no reason you can't use orbitals.

Note that the game changes radically if a point defense capable ground unit that can't be meson'd exists. "Inertial Lock" synergizes very well with any change of that nature to ground combat, and actually makes such units practical considering the ludicrous quantity or ludicrous OPness that would be needed to meaningfully contest a significant fleet.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Bobondacob on February 15, 2016, 08:55:54 PM
Why not independently scalable windows? That would enable us to have multiple windows on screen at once.  (As in a split or quad screen)  It would be a ***** to code, but hey; it's useful. 
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: db48x on February 15, 2016, 09:02:32 PM
Why not independently scalable windows? That would enable us to have multiple windows on screen at once.  (As in a split or quad screen)  It would be a ***** to code, but hey; it's useful.

It would be nice, indeed. VB6 just isn't up to the task though; not without ages and ages of boring, nay mind-numbing work.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Mor on February 16, 2016, 01:28:40 PM
Inertial Locks

An Inertial Lock is a planetary facility capable of instantly negating the Transnewtonian pseudovelocity imparted by small TN-era ship drives within a suborbital radius of a planet, most notably the drive of any practical missile design.  Larger drives, even those of fighters, are immune to the effect.

Any missile salvo that intercepts a population or ground force on a body protected by an Inertial Lock would have an additional flight time added to it, similar to ICBM flight time mechanics.  Speed would be the sole determinant of this flight time.  Even a moderately capable point defense array would thus be capable of destroying a far disproportionate # of incoming missiles. Although such missiles speed would have dropped to essentially that of a sitting duck, the inertial lock's interference would make missile ECM far more capable than normal.

Inertial locks would be permanent installations owing to the immense complexity of the fine tuning process adapting it to a local geomagnetic field.  The primary cost would be in Boronide for the massive power requirements.  They could be destroyed as normal as a side effect of ground combat, but the easiest way of defeating them would be attaining total ground superiority.  Alternatively, they could be PDC-mounted

It would be relatively easy to slot Inertial Locks into existing gameplay, but interaction with NPRs is a little more problematic.  Since NPRs do not build PDCs, they would not benefit much from Inertial Locks once any orbiting space stations are destroyed.  They would work well with any conflict between two player races, but to work for NPRs it requires either PDCs or some other means for ground forces to contest a beam-armed opponent in orbit.

This is an interesting idea, basically you want TN capabilities inhibitor, that slow down objects within its range (like blackholes). something like that can be of interest not only on planets.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: xeryon on February 16, 2016, 02:23:20 PM
Something super simple and I cannot believe it hasn't been mentioned before:  Queue for GFTC. 

I want to load up producing 10 garrison battalions and forget about it.  Similar to the construction queue or research queue now.  I know it isn't exactly tedious to input a new build order once every 6 months or so but I usually forget what my build goal was by that point and I have to shuffle through mental and physical notes to remember.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TMaekler on February 17, 2016, 06:44:29 AM
An option table where you can choose which events will stop the auto turn would be nice.

Adding delay time (the implemented one does not seem to function) in cycle orders or set specific timepoints as to when orders are to be carried out.

When setting up a new game and want to start NonTN and without Research Labs you basically break the game. An optional NonTN-Research Lab (with e.g. 50 RP or something similar) would be nice.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: db48x on February 19, 2016, 12:18:50 AM
I'd like to see a list of ship classes grouped by class type. If I've designed all of the classes myself I can generally remember their names, but in a new game with Aurora generating ships for me it's much more difficult.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TheDeadlyShoe on February 19, 2016, 12:31:57 AM
if you're talking about in the Class Design screen, you can sort by hull name, size, or cost as well as the default alphabetical.

radio buttons on the bottom rite

Another trick is to use prefixes.  For a while I would name all civilian ships using X Y or Z prefixes, like the "X200 Hauler"

Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: db48x on February 19, 2016, 06:53:48 AM
if you're talking about in the Class Design screen, you can sort by hull name, size, or cost as well as the default alphabetical.

radio buttons on the bottom rite

Another trick is to use prefixes.  For a while I would name all civilian ships using X Y or Z prefixes, like the "X200 Hauler"

True. I do occasionally use these, but it'd be more helpful to see at a glance which ships are in which class. When you want to compare all the ships in a class you can sort by class name, but then you still probably have to hunt around in the list to find them.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Havan_IronOak on February 20, 2016, 06:15:48 AM
Three suggestions regarding colonies...

1) The order in which "Other Colonies" are listed appears to be kinda random. Couldn't this be alphabetical or some other order that makes sense?

2) Abandoning Colonies requires a double confirmation. I appreciate that to a degree but couldn't the logic check to see if anything is in danger of being abandoned and then ask only if the check turned up anything of value?

I recently tested the results of geo-survey teams and left the colonies on my list as a way to keep track of just how many I'd done.
BTW... the results returned were 8 increases for 400 surveys.
I'm now abandoning the colonies that are complete dry wells and I've only myself to blame for the multiple confirms on deletes.
But I'm also seeing that the bottom 5 colonies on the list seem to change in a weird way when I abandon one.
You can see this thread for details
http://aurora2.pentarch.org/index.php?topic=8309.msg86902#msg86902

3) How about a Sg, Mg  or even a different single value in the first column of the System Overview (F9) in order to make it easy to keep track of which bodies have had ground based surveys?
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TMaekler on February 20, 2016, 09:43:31 AM
In SM Mode it is not possible to just unsurvey a single system body, only the whole star system. Would love to see the single object option as well  8)
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on February 22, 2016, 03:20:14 AM
I've seen some suggestions people have made about commercial ships holding military space and a lot of people contesting it and whatnot, so I'll toss in some two-cents:
How about a ship module that is individually design-able, considered a "commercial" design, but is designed from Class-design and researched? Call it a Mission-module, and have it work like such;

-A mission module can consist of military weaponry, power plants, etc, though it cannot hold any engines, shields, armor, crew quarters, spinally mounted weaponry, or many large civilian components (cargo holds, orbital habitats, etc). It's components are considered "internal" to the parent ship.

-A portion of the module's tonnage (either static based on tech level, or a percentage) is "attachement tonnage", just overhead for this strange piece of hardware.

-A mission module has to be assigned it's own engineering spaces separate from the parent ship, as well as crew and the likes. It uses the parent ship's deployment time and shares maintenance supplies with such, but has it's own isolated maintenance clock and component failures, much like a naval ship. The failures do not affect the commercial components, though.

-A mission module can be independently targeted from it's parent ship, and sensor data will report it's tonnage within the ship, while still being detectable at the same active range bands of the overall ship. All damage is applied to the parent ship's armor, then either randomly or specifically to the module, depending on whether the whole ship or just the module was targeted. All internal explosions propagate randomly and indiscriminately between the two.

-A mission module has it's own independent "destroy condition" similar to how larger ships roll for destruction. When a mission module is destroyed, all of it's internal components are considered destroyed, though the commercial ship stays intact for this particular check. If damage is dealt to a destroyed mission module internal-component, it rerolls to another random component in the module or the entire ship, depending on targeting. If the whole module is destroyed when it's components are checked, the entire ship is rolled instead. The HTK "20 failed rolls" ship death check will still apply if the module is hit by a ship-encompassing roll.


Anyhow, that's all the ideas I have for now. Wouldn't say they're great, but at least interesting. What do you think, Steve?
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TheDeadlyShoe on February 22, 2016, 03:25:24 AM
you can already do that with tractor beams ^____^
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on February 22, 2016, 03:27:44 AM
you can already do that with tractor beams ^____^
Oof, I was worried they'd seem a bit similar!
I guess the main difference I was looking for was stuff not getting knocked off the parent ship when the tractor was broken. That and shared armor. I do suppose they are a bit awfully similar though... Might be easier to just implement a "sturdy" tractor beam that is larger but can take more abuse before tractor is broken.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Sheb on February 22, 2016, 09:18:06 AM
Actually, that's a nice idea: allow tractor beam to be armoured like magazines can be.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on February 22, 2016, 11:19:53 AM
When you think about it carefully, mines don't make much sense.  Why is it that a mine on a world with two Accessibility 1 minerals produces twice as much overall as a mine on a world with one Accessibility 1 mineral?  If each mine represents a certain amount of mining equipment, then it should be able to extract a certain amount of Accessibility 1 minerals over a given time period, regardless of how many individual minerals are involved.
To give the smallest change from the current system, we can assign each mine 11 'points'.  These points are to be split evenly between each mineral on a body, and the mining rate is equal to the current one, multiplied by how many points are assigned to each mineral.  This would make mining bodies with one or two minerals much more economical.  If this seems like it would solve the mineral shortage problems too well, set the rate as the square root of points assigned instead. 
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: drejr on February 22, 2016, 11:33:30 AM
NPRs should build escort fighters or at the very least equip their fighters with sensors so fighter vs. fighter combat isn't a complete turkey shoot.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TheDeadlyShoe on February 22, 2016, 11:34:17 AM
When you think about it carefully, mines don't make much sense.  Why is it that a mine on a world with two Accessibility 1 minerals produces twice as much overall as a mine on a world with one Accessibility 1 mineral?
i think its to avoid a situation where say a planet with 1.0 duranium and 1.0 neutronium is worse for producing Duranium than a 0.7 Duranium planet....  without having to fiddle with assigning mines to specific resources.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on February 22, 2016, 12:22:52 PM
i think its to avoid a situation where say a planet with 1.0 duranium and 1.0 neutronium is worse for producing Duranium than a 0.7 Duranium planet....  without having to fiddle with assigning mines to specific resources.
But why shouldn't it work that way?  You're also getting neutronium in that case.  It's not even that weird.  For the sake of simplicity, the mine expends equal effort on all resources on the body, which is less weird than the current situation, where the mine appears to be able to clone itself if and only if there are other minerals about.  Or maybe each mineral has its own special extraction equipment/process, and there's no crossover between them.  But in that case, why does the number of workers stay the same regardless of the number of minerals being produced?  I can't come up with a good in-universe explanation for the current mine rules.
Note that in no circumstance does this proposed rule make the amount of minerals being produced go down relative to the current rules.  And you're getting more total minerals from each mine on the planet with higher accessibility.  If Duranium is all you're after, then it looks a tiny bit weird, but less so than the current situation.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on February 22, 2016, 12:35:56 PM
But why shouldn't it work that way?  You're also getting neutronium in that case.  It's not even that weird.  For the sake of simplicity, the mine expends equal effort on all resources on the body, which is less weird than the current situation, where the mine appears to be able to clone itself if and only if there are other minerals about.  Or maybe each mineral has its own special extraction equipment/process, and there's no crossover between them.  But in that case, why does the number of workers stay the same regardless of the number of minerals being produced?  I can't come up with a good in-universe explanation for the current mine rules.
Note that in no circumstance does this proposed rule make the amount of minerals being produced go down relative to the current rules.  And you're getting more total minerals from each mine on the planet with higher accessibility.  If Duranium is all you're after, then it looks a tiny bit weird, but less so than the current situation.
Maybe it could be assumed that the material in which you're extracting trans-newtonian materials is all the same stuff, and the main differences between the mineral stores of planets is what ratio of this strata actually contains the minerals, on top of difficulty in accessing due to depth, etc. So the same amount of mines will harvest the same amount of material, but the percentage of that material being useful depends on how much of it is the trans newtonian stuff, capped out at the extreme instance a planet having all accessibility: 1 minerals available.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on February 22, 2016, 12:48:14 PM
Maybe it could be assumed that the material in which you're extracting trans-newtonian materials is all the same stuff, and the main differences between the mineral stores of planets is what ratio of this strata actually contains the minerals, on top of difficulty in accessing due to depth, etc. So the same amount of mines will harvest the same amount of material, but the percentage of that material being useful depends on how much of it is the trans newtonian stuff, capped out at the extreme instance a planet having all accessibility: 1 minerals available.
I did think about that, but even that's not very logical.  If we assume that there's a giant cylinder of TN minerals that they eat from the top down, why the cap of accessibility 1?  That means the maximum concentration possible for any mineral is at most 9%, or at least 9% of the maximum possible concentration of TN minerals.  Why?  It makes very little physical sense, and even less when you consider how minerals run out at different rates.  If I have 100,000 tons of Accessibility 1 Gallicite and 10,000,000 tons of Accessibility 0.5 Duranium, it's awfully convenient that all of the Gallicite is concentrated in the top 0.5% of the column that's mostly Duranium.  If some sort of overall accessibility cap was implemented, and accessibility either couldn't sum to greater than 1 or could go above 1 and had to sum to less than 11, I would have less problem with this.  Also, I'm pretty sure this explanation doesn't resemble actual geology. 
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Nyvis on February 22, 2016, 12:54:07 PM
I would really like to see a "wait until shore leave is completed" order. Right now, sending my explorer ships back for shore leave means either removing their auto-order or being interrupted every time, wait for shore leave to finish, and then remember to put the order back on. It would be very helpful to have an order making them stay here until morale is back up.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on February 22, 2016, 12:55:50 PM
I would really like to see a "wait until shore leave is completed" order. Right now, sending my explorer ships back for shore leave means either removing their auto-order or being interrupted every time, wait for shore leave to finish, and then remember to put the order back on. It would be very helpful to have an order making them stay here until morale is back up.
I send them in for an overhaul to solve this problem.  But it would be nice to have this as an option.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on February 22, 2016, 02:40:40 PM
I did think about that, but even that's not very logical.  If we assume that there's a giant cylinder of TN minerals that they eat from the top down, why the cap of accessibility 1?  That means the maximum concentration possible for any mineral is at most 9%, or at least 9% of the maximum possible concentration of TN minerals.  Why?  It makes very little physical sense, and even less when you consider how minerals run out at different rates.  If I have 100,000 tons of Accessibility 1 Gallicite and 10,000,000 tons of Accessibility 0.5 Duranium, it's awfully convenient that all of the Gallicite is concentrated in the top 0.5% of the column that's mostly Duranium.  If some sort of overall accessibility cap was implemented, and accessibility either couldn't sum to greater than 1 or could go above 1 and had to sum to less than 11, I would have less problem with this.  Also, I'm pretty sure this explanation doesn't resemble actual geology.
Well, it's worth assuming that trans-newtonian minerals are not part of actual geology, at least not the same geology that's governed by newtonian physics that we know of. Whether the stuff is actually physical as we recognize it or phantasmagorical in some manner depends on individual interpretations. Beyond this point, while the idea seems cool, you might be looking too far into it.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: theredone7 on February 22, 2016, 03:02:46 PM
I apologise if this has been mentioned before, I did a search but couldn't find anything.

One thing that bugs me about Aurora 4X is that a world, once completely habitable can have a pretty much infinite number of people and installations.   I'd like to see this capped depending on the size of the body, the landmass and how well the colony is doing financially.   The more the colony can produce, the more people and installations it should be able to support.   Financial Centres will assist with this.   A new colony should take more time to build their economic strength too, as a growing colony is more likely to be demanding goods than supplying them.   This should somewhat limit the installations they can have.   Once the colony reaches the point where it has a relatively well sized supply and demand economy, it should become a state (or if a capital, a homeworld) where such limitations should change accordingly.

It would also be good to specify how many land masses and/or islands a world has which could have positive and/or negative bonuses to production and/or colonisation.   For example, a water world with 90% water might have 400000 small islands, which may not be able to support a large number of people (e. g.  10000-25000 each).   Or a continent which may support 2-3 billion people.

This could also change the terraforming system, where a world has a variable temperature range (favourable at the poles/equator or unfavourable at the poles/equator, or a variant).   Landmasses may be partly or entirely in a favourable location for life, this could be calculated by having a temperature range for the world that changes based on latitude.

I could also go further in stating that certain minerals may only be available in certain landmasses, and installations would be placed on a landmass other than those which would reside in orbit around the world.  But I think I've asked for a lot already, and I would be incredibly happy with the above if they were implemented.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: 83athom on February 22, 2016, 03:10:53 PM
Not a good suggestion. "What does an open ended game that lets you have the freedom to do anything need? RESTRICTIONS, YES!"  (Erik, wee need a facepalm emote)
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: El Pip on February 22, 2016, 03:16:24 PM
I did think about that, but even that's not very logical.  If we assume that there's a giant cylinder of TN minerals that they eat from the top down, why the cap of accessibility 1?  That means the maximum concentration possible for any mineral is at most 9%, or at least 9% of the maximum possible concentration of TN minerals.  Why?  It makes very little physical sense, and even less when you consider how minerals run out at different rates.  If I have 100,000 tons of Accessibility 1 Gallicite and 10,000,000 tons of Accessibility 0.5 Duranium, it's awfully convenient that all of the Gallicite is concentrated in the top 0.5% of the column that's mostly Duranium.  If some sort of overall accessibility cap was implemented, and accessibility either couldn't sum to greater than 1 or could go above 1 and had to sum to less than 11, I would have less problem with this.  Also, I'm pretty sure this explanation doesn't resemble actual geology.
The giant cylinder part may not be right, but getting many minerals associated together and being mined at the same time is very like actual mining. Very rarely will a metal mine just produce one thing, it's almost always multi-product, often half a dozen or more. They're not always obviously related by their physical properties, the same mine can produce gold, copper, molybendium, lead and platinum from the same ore body.

If you imagine the TN deposits as being utterly separate and unrelated to each other, then I agree the current setup does seem odd. But if you imagine a planet's TN deposits as being a number of intermingled deposits, each one containing a variable grade of multiple TN ores, then I think the current system is close enough.

I see it working as your miners start on the best ore bodies, the one with the most amount of ores occurring together. When they are used up, they have to move to harder to work deposits (lower accessibility) with less concurrent ores (some minerals run out).
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: theredone7 on February 22, 2016, 03:24:07 PM
Quote from: 83athom link=topic=8107. msg87103#msg87103 date=1456175453
Not a good suggestion.  "What does an open ended game that lets you have the freedom to do anything need? RESTRICTIONS, YES!"  (Erik, wee need a facepalm emote)

I can understand your opposition, but you could have just stopped at your first sentence, as I find your response quite rude.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on February 22, 2016, 03:54:54 PM
The giant cylinder part may not be right, but getting many minerals associated together and being mined at the same time is very like actual mining. Very rarely will a metal mine just produce one thing, it's almost always multi-product, often half a dozen or more. They're not always obviously related by their physical properties, the same mine can produce gold, copper, molybendium, lead and platinum from the same ore body.

If you imagine the TN deposits as being utterly separate and unrelated to each other, then I agree the current setup does seem odd. But if you imagine a planet's TN deposits as being a number of intermingled deposits, each one containing a variable grade of multiple TN ores, then I think the current system is close enough.

I see it working as your miners start on the best ore bodies, the one with the most amount of ores occurring together. When they are used up, they have to move to harder to work deposits (lower accessibility) with less concurrent ores (some minerals run out).
I'm aware that minerals may be mixed together in real life.  But in Aurora, each mineral is treated totally separately.  Why is all of the Gallicite mixed in with only 0.5% of the Duranium?  For that matter, when geology teams make discoveries, it's always, IIRC, of a single mineral at a time.  If the minerals behaved more like they were linked, I wouldn't have much trouble accepting this line of reasoning.
I agree that assuming each mineral is completely separate is probably a bad idea, which is why I'm leaning towards the idea of using a square root.  Mining on a body with a single mineral would be limited to about 3.3x the rate on a body with all 11 minerals, which would make work on those bodies with a few high-prevalence low-accessibility minerals significantly more attractive without breaking the game completely.  You'd get more in total from a body with more minerals, and it smooths out a lot of the weird spikes you'd otherwise see.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Black on February 22, 2016, 05:05:49 PM
Would it be possible to add No PDC filter to Individual Unit Details Window?
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Sematary on February 22, 2016, 07:50:20 PM
I'm aware that minerals may be mixed together in real life.  But in Aurora, each mineral is treated totally separately.  Why is all of the Gallicite mixed in with only 0.5% of the Duranium?  For that matter, when geology teams make discoveries, it's always, IIRC, of a single mineral at a time.  If the minerals behaved more like they were linked, I wouldn't have much trouble accepting this line of reasoning.
I agree that assuming each mineral is completely separate is probably a bad idea, which is why I'm leaning towards the idea of using a square root.  Mining on a body with a single mineral would be limited to about 3.3x the rate on a body with all 11 minerals, which would make work on those bodies with a few high-prevalence low-accessibility minerals significantly more attractive without breaking the game completely.  You'd get more in total from a body with more minerals, and it smooths out a lot of the weird spikes you'd otherwise see.
In real life platinum is treated totally separately from gold, from silver, from iron, etc. I don't see people going out and getting gold iron rings for example. As for geology teams, we will assume you are recalling correctly since I don't remember either, and say as they map the planet they collect samples from all over and then spend most of their time in some sort of mobile lab that they analyze the material and due to the analyzing process and the way the human brain works they focus on one mineral at a time.

 Also, why are you assuming accessibility 1 is equal to 1%? You have used that in a couple of the previous posts you have made on this topic, and I think its weird since accessibility does not necessarily have anything at all to do with percentages. For all we know accessibility 1 is equal to 9.09% of the total composition of the world and if all 11 minerals are present that encompasses the entire make up of the world.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on February 22, 2016, 11:26:59 PM
In real life platinum is treated totally separately from gold, from silver, from iron, etc. I don't see people going out and getting gold iron rings for example. As for geology teams, we will assume you are recalling correctly since I don't remember either, and say as they map the planet they collect samples from all over and then spend most of their time in some sort of mobile lab that they analyze the material and due to the analyzing process and the way the human brain works they focus on one mineral at a time.
That's my point.  At the very least, we can be reasonably certain the deposits the geology teams find are individual, as there aren't other minerals added at the same time.

Quote
Also, why are you assuming accessibility 1 is equal to 1%? You have used that in a couple of the previous posts you have made on this topic, and I think its weird since accessibility does not necessarily have anything at all to do with percentages. For all we know accessibility 1 is equal to 9.09% of the total composition of the world and if all 11 minerals are present that encompasses the entire make up of the world.
I'm not.  I acknowledged that it could be as high as 9% but there's no logical reason why you couldn't have 18% Duranium in a given vein.  The 0.5% number is based on my 'giant cylinder of minerals' analogy, and referred to the fraction of the deposit of the first mineral that had the second mineral in it.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: DIT_grue on February 23, 2016, 12:25:32 AM
For that matter, when geology teams make discoveries, it's always, IIRC, of a single mineral at a time.

That's the old mechanic. Since the changes, they only get one ground survey of a body; when they complete it, they reroll the same mineral generation algorithm for it as occured at system generation (though at reduced probability) and incorporate any improvements.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: db48x on February 23, 2016, 12:46:02 AM
One thing that bugs me about Aurora 4X is that a world, once completely habitable can have a pretty much infinite number of people and installations.

What is Earth's population cap? The laws of physics don't seem to cause one; people don't suddenly become infertile once the population hits X billion. Perhaps there is a point where everyone feels too crowded, but most of the Earth is effectively empty; we're not anywhere near it today. The real limits are set by the fraction of land which can be used for agriculture, the amount of agriculture which can be accomplished without using arable land, and the number of calories you can get for a given set of inputs. Technology has given us such great improvements to the latter that we're actually not using all of the arable land that we could be, and we still have more food than we can eat. I think this is a situation where the trans-newtonian technologies that the game introduces have pushed the limits so high as to be entirely unknown.

The rest of your suggestion is asking for more simulation here and less abstraction, so I don't think a cap of any kind would be the right way to satisfy you. I think terraforming could be more interesting if it took into account more factors about the planet though, such as the hydrology.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on February 23, 2016, 12:53:16 AM
What is Earth's population cap? The laws of physics don't seem to cause one; people don't suddenly become infertile once the population hits X billion. Perhaps there is a point where everyone feels too crowded, but most of the Earth is effectively empty; we're not anywhere near it today. The real limits are set by the fraction of land which can be used for agriculture, the amount of agriculture which can be accomplished without using arable land, and the number of calories you can get for a given set of inputs. Technology has given us such great improvements to the latter that we're actually not using all of the arable land that we could be, and we still have more food than we can eat. I think this is a situation where the trans-newtonian technologies that the game introduces have pushed the limits so high as to be entirely unknown.

The rest of your suggestion is asking for more simulation here and less abstraction, so I don't think a cap of any kind would be the right way to satisfy you. I think terraforming could be more interesting if it took into account more factors about the planet though, such as the hydrology.
Indeed. We don't even begin to cover the more nutter things.
To elaborate?
TN powered hydroponic subterranean and layered farms.
Total urbanization of the planet.
Subterranean urbanization combined with high towers.
Etc.
The extreme form of this that comes to mind is the Warhammer 40k Hive Worlds.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TheDeadlyShoe on February 23, 2016, 01:06:34 AM
i think that sort of thing would be well suited to a major overhaul of how races work, actually.  The 'Carnivorous or Utopian race that has comparatively low populations before they feel crowded'  is practically a scifi trope by now, as is the 'Herd/hive race with huge crowding'.  There is, in fact, already a soft cap since population growth slows as population increases; it's just absurdly high in practical terms for an Aurora player.

I think wealth gain from pop should scale down with pop rather than being flat, in the same way that pop growth and manufacturing jobs do.   I would scale down my wealth gain from pop on the fly if i could...

One way to implement a soft cap would be to have a native 'carrying capacity'of a planet. Once exceeded, TN infrastructure is required to keep increasing population.  Any reasonable carrying capacity would be very very high in practical Aurora terms though, so.... *shrug*  probably pointless.

Quote
Indeed. We don't even begin to cover the more nutter things.
In Aurora terms a lot of that can/should require Infrastructure
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Nyvis on February 23, 2016, 09:23:45 AM
What is Earth's population cap? The laws of physics don't seem to cause one; people don't suddenly become infertile once the population hits X billion. Perhaps there is a point where everyone feels too crowded, but most of the Earth is effectively empty; we're not anywhere near it today. The real limits are set by the fraction of land which can be used for agriculture, the amount of agriculture which can be accomplished without using arable land, and the number of calories you can get for a given set of inputs. Technology has given us such great improvements to the latter that we're actually not using all of the arable land that we could be, and we still have more food than we can eat. I think this is a situation where the trans-newtonian technologies that the game introduces have pushed the limits so high as to be entirely unknown.

The rest of your suggestion is asking for more simulation here and less abstraction, so I don't think a cap of any kind would be the right way to satisfy you. I think terraforming could be more interesting if it took into account more factors about the planet though, such as the hydrology.

Yep. Rather than a hard cap, having to take care of the hydrology (too many or not enough water = problem) and ecosystem (do I need to import species from earth? Is the local ecosystem compatible for humans, if life already existed), etc... Would be more interesting.
Rather than having a fixed population size depending on these factors, you could have a reduction to efficiency for the planet if those points are not fulfilled. Or a need for infrastructures to cover for producing food in an unsuitable environment (right atmosphere but no water, or no specie to cultivate, interaction between native ecosystem and terran crops...).

As a whole, I think terraforming could use more detailing for what happens once temperature and atmosphere concerns are addressed. For example, atmosphere without an ecosystem could degrade with oxygen turning to CO2. Pollution could also be an issue worth adding, requiring you to use terraforming installations and workers to remove dangerous gases from your otherwise breathable atmosphere.

Another thing worth thinking about would be alternative terraforming methods, like using ice asteroids to create an atmosphere and hydrosphere quicker than by adding gases manually, or introducing genetically altered flora converting gases (CO2 to O2 ...). Right now, terraforming seems to be too linear and straight forward. If a planet is colonizable, it is usually terraformable, and you always proceed the same way to do so. It reduces the thinking needed when choosing settlement targets since most worlds with the correct gravity can be terraformed to your specie's liking. Having to concern yourself with the existence of a magnetic field, the day length, seasonal variation strength, tidal lock, volcanic activity polluting the atmosphere, etc, could make it much more interesting and reflection inducing.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TMaekler on February 23, 2016, 10:32:03 AM
One thing that bugs me about Aurora 4X is that a world, once completely habitable can have a pretty much infinite number of people and installations.

There are pros and cons to changing the actual system. What I have seen so far the "only" problem arising out of an infinite population is the infinite income spiral. At some point money becomes no more a limitation of production etc. And limiting the population growth would introduce micromanagement of planets which is unnecessary for the main complexity focus that Aurora has (although you can find that kind of micromanagement in almost all 4x games).

My suggestion for a solution would be this: if too much wealth is accumulated the population becomes angry with the government and an empire wide unrest starts. This can be overcome by a new factor called: tax rate. So you would have to manage the amount of wealth you have with the tax rate you can set. This tax rate should be per colony - and differences between the colonies should not add to the unrest factor.

So in the end there is no need of limiting pop growth and any unnecessary micromanagement. But we would be able to limit wealth overgrow. Also, in times of war, where much production is needed, an increase of tax rates can help being able to increase war production... . Having one or two colonies with high populations in the backhand would then be beneficial for planned war efforts.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: jem on February 23, 2016, 04:40:07 PM
A counter to see how many active contacts you have.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Sheb on February 24, 2016, 01:53:24 AM
Is the income spiral that bad? I mean, sure, population grow exponentially, but so does production.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TheDeadlyShoe on February 24, 2016, 02:06:35 AM
tax rate would be lame when you can just slap an increasing inflation penalty on income when wealth > GDP
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: sloanjh on February 24, 2016, 07:14:53 AM
I'm aware that minerals may be mixed together in real life.  But in Aurora, each mineral is treated totally separately.  Why is all of the Gallicite mixed in with only 0.5% of the Duranium?

Point of history:  Originally (as in v0.1) each minerals was mined at the initial accessibility until it was gone, at which point it stopped.  I pointed out that this seemed a bit unrealistic, and that it actually made planning harder as well because your flow rate got hit with an abrupt change.  So Steve set up the current system to "tail off" minerals as they ran out.  I don't remember seeing any technobabble from Steve as to the original reasoning for the behavior Byron pointed out - I suspect it was along the lines of "they're digging at a TN vein that can have multiple components", without having thought through the subtleties.

John

PS - This is beginning to feel like it should be split into a separate thread....
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on February 24, 2016, 09:36:34 AM
Just gonna drop a link to a Plasma Carronade discussion thread, which has some suggestions in it.
http://aurora2.pentarch.org/index.php?topic=8383.msg87145#msg87145 (http://aurora2.pentarch.org/index.php?topic=8383.msg87145#msg87145)
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: QuakeIV on February 25, 2016, 02:02:00 PM
Given that maintenance is getting some love, any chance mothballing can be added in some capacity?  Some way to bring ships to a super-low maint requirement that requires them to go through overhaul (or something) before they can do anything.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TheDeadlyShoe on February 25, 2016, 02:07:53 PM
Many people consider using PDC hangars to be the rough equivalent of mothballing.

I briefly experimented with a scheme involving replacing expensive components that were going to be refitted in the future anyway, with very cheap very large components to keep the tonnage equivalent.  This drives the maintenance cost way down, and the ship is useless until reactivated by refitting with modern equipment. 
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on February 26, 2016, 11:46:39 AM
Idea for railguns:
Reduced Size Railgun Tech - reduces railgun size in exchange for reduced salvo size and power requirements. The railgun size reduction is slightly less than the tech reductions, so that full sized railguns are still more efficient in damage-per-HS. Railguns with a burst of 2 or less can be turret mounted.
I like to think of this like a backwards-spinal mount tech, and makes railguns occupy some more fancier niches without overextending over the presence of lasers.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: jem on February 28, 2016, 12:51:02 PM
A "move to and kill" order. Or a default order to move to nearest enemy.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Thineboot on February 29, 2016, 11:12:36 AM
Commanders > Civilian Administrators > Search by Ability or Location > Rank: Civilian Administrator
There are Min/Max radiobuttons but Civilian Administrators have no textual ranks. Instead they have Ax ranks. It would be really handy to use these Ax ranks for Min due Population and Sectors are limited to minimum ranks (Ax).
I know there is Ability A: Administration Rating. But with Ability B not really working there is no chance to search for specific abilities for high ranking administrators (sectors, terra-like worlds).
Individual titles would be nice addition, too.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on February 29, 2016, 01:10:36 PM
Make shielding and CIWS make it harder to board ships they are mounted on.

For CIWS, make them take shots at boarding parties before they can land on the ship, the boarding party speeds ranked based on how fast their parent ships were moving.
For shielding, make boarding parties deal damage equal to their defensive stat to the shields (this stat is combined if multiple are being launched at once) directly to the shield. If this fails to bring the shield down to less than the Attack power of the boarding parties, make the parties essentially "fight" the shield multiple times simultaneously until either the shield breaks or the boarding parties are killed before entry. The "fight" treats the shield as having Attack, Defense, and Morale equal to it's power. If the party defeats the shield, then it moves on to the insides of the craft.

With these two points in mind, it may be more viable to buff the boarding chance of such craft at low speed, as they're not a simple kill-switch against slow craft that don't have onboard marine-headquarter brigades.

Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TheDeadlyShoe on February 29, 2016, 02:27:45 PM
Suggestion: Passive Sensor Suppression (SM toggle)

This would disable passive sensors in a system.  It's mostly for processing combat more quickly in situations where both sides are engaged with actives but sensor checks are chugging increment processing times.

Alternatively, it could suppress the str1 passives possessed by default.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on February 29, 2016, 11:35:03 PM
Suggestion: Passive Sensor Suppression (SM toggle)

This would disable passive sensors in a system.  It's mostly for processing combat more quickly in situations where both sides are engaged with actives but sensor checks are chugging increment processing times.

Alternatively, it could suppress the str1 passives possessed by default.
To be honest though, we could very well do without the str1 passive sensors by default, seeing as one could make a size 0.1 or 0.2 sensor, and it would be considered commercial, too.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: firsal on March 01, 2016, 08:26:02 AM
In the Survey view of the Galactic Map Window, it would be nice to have a breakdown of the system bodies surveyed.  For example; rather than just a mere "System Bodies: 72/145", it'd show a breakdown of planets, moons, asteroids and comets.  This would help a lot in survey efforts since it's hard to tell if a planet-only or comet-only geological survey of a system is complete. 
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on March 01, 2016, 11:15:09 AM
It would be nice to see a reduced size/reduced efficacy cloaking device tech.  There are times when a 50-75% reduction in signature would be nice (survey ships, for instance), but 95%+ isn't needed, and having a smaller cloaking device would be very helpful.  Say that in exchange for a 3-4x improvement in efficiency, you end up with 5x the signature of the current cloaking device.  So a system which could normally cloak a 5000 ton ship at 95% now cloaks a 15,000 ton ship at 75%. 
(This may not be ideal.  Cloaking reduction gets so high at the upper end that it's hard to figure out how to deal with it.  This shouldn't be a slightly worse but much more efficient replacement for a regular cloak so much as a way of getting low-observable ships as opposed to full-on stealth.)
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Pixel1191 on March 02, 2016, 05:02:25 AM
What about some sort of "target drone"? it occured to me, after designing a laser-headed missile, that it would be nice to have the ability to test weapon systems BEFORE actual enemy contact. Kinda sucks to find out about the ineptitude of a new ship/weapon when the enemy gives you the finger and blows you to pieces.

And maybe the ability to strip crew out of an old ship, tow it into place and use it for target practice.

Real life naval and air forces use this. With the air force using remote controlled planes (either specially built drones or old planes refitted) and the navy is known to ocassionaly smash an old destroyer or something to pieces with ASMs. Would be nice to have a similar possibility. I only found out that laser heads don't quite work as I'd hoped...after they failed to produce the desired results against an invading enemy.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: TheDeadlyShoe on March 02, 2016, 09:32:03 AM
you can make a 'target drone' by adding an enemy faction, and then giving it ships for you to shoot.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on March 02, 2016, 09:40:46 AM
you can make a 'target drone' by adding an enemy faction, and then giving it ships for you to shoot.
I've done that several times.  I've been playing long enough that I rarely have serious questions about the effectiveness of my weapons, but there are days when you need to answer a weird mechanical question and the easiest way to do so is to shoot at things.  My most recent use of this was an attempt to use the 5 second missile timing exploit with multi-stage missiles, but it didn't work.
Also, it's sometimes worth building (or SMing) a version of your missiles with no warhead, and giving them to the target fleet.  That way, you can evaluate your missile defenses without worrying about damaging your ships.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Iranon on March 05, 2016, 07:54:03 AM
Unless I'm just ignorant and there's a way to do this already: generic orders for ground units transport.
Just getting a few dozen construction brigades from A to B shouldn't involve this much clicking if we don't care about the niceties.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: db48x on March 06, 2016, 12:07:02 PM
Some way to pause a task group so that it hold position without having to clear the orders would be nice. Also, when a task group can't be fully refueled from a tanker I get an interrupt, but when a task group can't be fully refueled from a colony I don't. Is that a bug or a reasoned design decision?
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: iceball3 on March 06, 2016, 06:52:51 PM
Some way to pause a task group so that it hold position without having to clear the orders would be nice.
A current, relatively reliable way to instigate this is by setting the task group speed to 1. Moving three orders of magnitude slower than normal is good for stalling movement to a relative complete standstill, though for very specific positioning might be more reliable to just wipe the task list. Though, worth noting that your ship will fail just about all maneuverability speed checks made against it, leaving it vulnerable to attack of all sorts. That said, your thermals will be about zero, essentially making your ship go invisible to thermal readings, though not to active sensor or EM readings.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: db48x on March 06, 2016, 07:53:47 PM
A current, relatively reliable way to instigate this is by setting the task group speed to 1. Moving three orders of magnitude slower than normal is good for stalling movement to a relative complete standstill, though for very specific positioning might be more reliable to just wipe the task list. Though, worth noting that your ship will fail just about all maneuverability speed checks made against it, leaving it vulnerable to attack of all sorts. That said, your thermals will be about zero, essentially making your ship go invisible to thermal readings, though not to active sensor or EM readings.

In this case they were out of fuel, having gotten about 100 yards away from Europa, where they were supposed to refuel. (Europa had run out.) It might have worked anyway; I've noticed that they sometimes have 0.0% fuel, but still have a few dozen liters in the tanks.

Perhaps a conditional order instead: if fuel tanks are empty, squawk and await rescue.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: DIT_grue on March 06, 2016, 08:32:56 PM
Unless I'm just ignorant and there's a way to do this already: generic orders for ground units transport.
Just getting a few dozen construction brigades from A to B shouldn't involve this much clicking if we don't care about the niceties.

It sounds like using HQs should alleviate the problem by a factor of sixteen - which for 'a few dozen' would make it bearable. Does require building and assigning the HQ units, of course; and it only defers the underlying issue.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: ExChairman on March 07, 2016, 02:04:06 PM
Fighters: They are nice to bombard your enemies or attacking other fighters, but now when "all" can have them, they seem to lose a bit. What I mean is that they will not try and avoid enemies or their fire. In my last game I have 50 assault fighters, mainly built to attack enemy ships, they have one large missile with a 32 point warhead and 4 gauss cannons, these are small and low hit(17%).
I sent them to attack my opponents fighter, unfortunately they arrived after they launched at my main fleet, but now they are flying back to their carriers in a straight line and I am butchering them.
No finesse at all.

Of course they only had missiles, but something would be needed to give them a chance, more armour, own Gaus Cannons, a small CIWS to defend against fighters/missiles fighters, etc.

Fixes, if even possible: Some kind of dogfighting or jinxes were they try to evade fire. Big/slow heavy fighter-bombers are easier to hit and the other is true with small faster/nimbler fighters being harder to hit and kill.
If you played/read Star Fleet Battles, they have the rule that a dog fight makes it impossible to attack another target, some fighters have an advantage in a dog fight  called "dog fighting" rating.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: drayath on March 08, 2016, 10:00:53 AM
Jumpoints: Allow assigning a jump capable Taskforce to a jumpoint that will then ferry across other taskforces that try to move through the jumpoint.

An alternative to using jump-gates.
Allows civilian trade without a jumpgate.
Costs having to station jump tender at the jump point, with a throughput limit (and fuel cost for jumps?) as the jump-drive takes time to recharge.
This can be done manually at present (except civilian use) but requires lots of micro-management to add/remove jump tender to the taskkforce before/after the jump.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on March 08, 2016, 10:20:45 AM
Jumpoints: Allow assigning a jump capable Taskforce to a jumpoint that will then ferry across other taskforces that try to move through the jumpoint.
This already works.  If you have a ship with a jump drive on the JP, any and all craft that it can pass through will be passed through.  It doesn't allow civilian trade, but that's probably realistic.  Shipping lines aren't going to be wild about going into the great unknown with only your word that the tender will be around when they want to come back.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: 83athom on March 08, 2016, 10:38:13 AM
Allow assigning a jump capable Taskforce to a jumpoint that will then ferry across other taskforces that try to move through the jumpoint.
That's already a thing.
An alternative to using jump-gates.
Like a jump drive that already exists? Or something else that wouldn't fit with the mechanics?
Allows civilian trade without a jumpgate.
If you put a commercial ship with a large jump drive on the point, works the  same.
Costs having to station jump tender at the jump point, with a throughput limit (and fuel cost for jumps?) as the jump-drive takes time to recharge.
Partially already a thing. Jumping gives a sickness where you cant see or jump for a short period.
This can be done manually at present (except civilian use) but requires lots of micro-management to add/remove jump tender to the taskkforce before/after the jump.
You can just sit a large ship with a large drive at the point and it can jump anything, and you don't need to add it to the task force that is jumping. And you don't need one at both sides, it work at both when one is at just one of the connected points.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on March 08, 2016, 01:10:57 PM
If you put a commercial ship with a large jump drive on the point, works the  same.
He was talking about shipping lines, which don't use jump tenders.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Paul M on March 09, 2016, 01:57:50 AM
A current, relatively reliable way to instigate this is by setting the task group speed to 1. Moving three orders of magnitude slower than normal is good for stalling movement to a relative complete standstill, though for very specific positioning might be more reliable to just wipe the task list. Though, worth noting that your ship will fail just about all maneuverability speed checks made against it, leaving it vulnerable to attack of all sorts. That said, your thermals will be about zero, essentially making your ship go invisible to thermal readings, though not to active sensor or EM readings.

Your ships at speed 1 are not easier to hit.  The maximum speed of the ship compared to the missile is what is used not the current speed.  I've seen this in engagements of wolvers who have slowed down, so long as their full engine power was available the missile to hit chance was calculated with their max possible speed.  Beam fire controls I have no experience with but I would assume use the same value.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on March 09, 2016, 08:43:36 AM
Jump Points in the System View are shown with a distance in billion km. If you want to relink Jumppoints in SM Mode the distances are shown there in AU.
Same difference in the Galactic Map. If you show the distances from selected system it is shown in billion km. But if you switch to the warp point data there you again see only AU.

I suggest conforming them so that the distances shown are everywhere the same. I find these differences in distances confusing - especially because the game does not tell you about in what measurement the numbers are shown.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on March 10, 2016, 10:10:35 AM
One thing I would like to see would be a 'spacer' or 'reserved space' component.  This is a box that is basically free and exists to take up space.  I can think of several uses:
Building a ship to size, where you want to save some space for future improvements.
If all but one component of a ship is researched, and you want to get started, you fill out the space with these, then lay down the ships.  Partway through construction, the research finishes, and you retool the yard (if necessary).  Then, when the ships complete, you refit them to the new sensors.  There are ways to do this today, but they cost more.
When you wish to slide a ship past your overlord's approval process, because they restrict what you can build, but not what you can refit.  (This one is probably pretty specific to my current game.)
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Paul M on March 10, 2016, 10:13:03 AM
I would suggest that the production of new shipping lines be forbidden when any of the existing lines has a share price below 2.

I would further suggest that in the advent an investment would be made that would start a new line instead that the money is randomly given to a shipping line in the form of new ships if the formation of a new line is blocked due to low share prices.

I would further suggest that when a new line forms it starts with its initial investment money already spent in terms of ships.  Otherwise I've seen them sit on their initial investment capital and even pay it out as dividends without building ships and then being stuck with having but a single ship. 

I would further suggest that a bit of programing is implemented to stop the mass effect in Aurora civillian shipping.  If I give a contract I've seen every single spare ship head off to the place where the pick up is...regardless of the fact that there are only 10 mines to move and that 10 faster ships are racing on ahead of the ship and that there are contracts now free (as everyone and their dog is heading off to the oort cloud to pick up 10 auto mines).  And similiar programing to preven the big dumps where there is 50K extra population available on a colony and 3 million colonists are landed on it.  Basically I would loop over the companies and assign a job to each company until no jobs remain to be assigned. 

I would further suggest that NPRs have to deal with fuel but it an abstract way.  The ships track fuel use and at 50% they return to their "home base" and refuel but that the NPR ships have no limitations on their movement if they run out of fuel on the way home.  Or you could say that they can do their thing until they do run out of fuel and then must return to their "home base" to refuel but again without any restriction on speed.  They can't "run out of fuel" (as it is now) but they at least have to automatically go back to their "home base" from time to time.  This will hopefully put a logicistics limit on NPRs without imposing a huge programing effort.

I would also suggest that the price paid for civillian fuel should be increased significantly.  I would leave the price the same and just charge that per 1000 l rather than per 10 000 l.  Civillian fuel is extremely valuable and very cheap which makes the harvesters less valuable to the company. 
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bean on March 10, 2016, 10:37:25 AM
I would further suggest that when a new line forms it starts with its initial investment money already spent in terms of ships.  Otherwise I've seen them sit on their initial investment capital and even pay it out as dividends without building ships and then being stuck with having but a single ship. 
This is a good idea.
Quote
I would further suggest that a bit of programing is implemented to stop the mass effect in Aurora civillian shipping.  If I give a contract I've seen every single spare ship head off to the place where the pick up is...regardless of the fact that there are only 10 mines to move and that 10 faster ships are racing on ahead of the ship and that there are contracts now free (as everyone and their dog is heading off to the oort cloud to pick up 10 auto mines).  And similiar programing to preven the big dumps where there is 50K extra population available on a colony and 3 million colonists are landed on it.  Basically I would loop over the companies and assign a job to each company until no jobs remain to be assigned. 
I thought that that bug got fixed.  I'll have to check, but I believe that several years ago, Steve added code to check for all inbound colonists when calculating where to send new ones.

Quote
I would further suggest that NPRs have to deal with fuel but it an abstract way.  The ships track fuel use and at 50% they return to their "home base" and refuel but that the NPR ships have no limitations on their movement if they run out of fuel on the way home.  Or you could say that they can do their thing until they do run out of fuel and then must return to their "home base" to refuel but again without any restriction on speed.  They can't "run out of fuel" (as it is now) but they at least have to automatically go back to their "home base" from time to time.  This will hopefully put a logicistics limit on NPRs without imposing a huge programing effort.
It might be worthwhile to do this for shipping lines.  Look at the ship's range, and reject any trip that is beyond said range.  Computational load should be relatively low.

Quote
I would also suggest that the price paid for civillian fuel should be increased significantly.  I would leave the price the same and just charge that per 1000 l rather than per 10 000 l.  Civillian fuel is extremely valuable and very cheap which makes the harvesters less valuable to the company.
Definitely.  I always groan when they buy one of the stupid things because it's never going to pay itself back.  (At least if you use them for revenue.  I haven't used them much as a means of getting more fuel.  May have to try that.)
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: Iranon on March 12, 2016, 04:40:58 AM
Very minor thing, but imo active sensor cost should scale with Sensitivity rather than Strength:
More interesting research/design trade-offs, avoids a newbie trap.

Current situation:
Range gains are comparable for either line.
Sensitivity gives you additional range for free and allows better passives.
Grav Pulse Strength increases build/R&D cost and EM footprint, with no secondary application. Essentially it's just a weight-saving tech that won't do very much on most designs.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: db48x on March 12, 2016, 02:04:32 PM
I don't think Xenology teams gain skill often enough, especially compared to Geology teams. Translating the text found in alien ruins seems like it would be the culmination of a life's work; surely they're going to learn more than 1% during that time :)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: formicae on March 14, 2016, 07:03:56 PM
I'd like to be able to set a commander name theme per species in my empire, not just a single set for my empire as a whole.

From an RP perspective, I don't want to force the aliens who join my empire to abandon their own names in favor of human-style ones.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on March 14, 2016, 07:05:41 PM
I'd like to be able to set a commander name theme per species in my empire, not just a single set for my empire as a whole.

From an RP perspective, I don't want to force the aliens who join my empire to abandon their own names in favor of human-style ones.
There is a part in the race window that you can select additional name themes to be drawn for your empire.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: formicae on March 14, 2016, 07:20:00 PM
Quote from: 83athom link=topic=8107. msg87955#msg87955 date=1458000341
There is a part in the race window that you can select additional name themes to be drawn for your empire.
There is, and I've been using it, but it looks like it selects one of the 5 themes randomly without any correlation with the commander's homeworld/training location (which is the only indication I can find of the commander's species).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: firsal on March 15, 2016, 07:33:38 AM
 A way to designate a world as off-limits to civilian colony ships. I'm trying to set up a severely limited colony on a Venusian world so that PDC morale doesn't go too far down, but civilians keep sending colonists in larger numbers than my orbital habitats can provide.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on March 15, 2016, 07:38:12 AM
A way to designate a world as off-limits to civilian colony ships. I'm trying to set up a severely limited colony on a Venusian world so that PDC morale doesn't go too far down, but civilians keep sending colonists in larger numbers than my orbital habitats can provide.
Once it reaches 25m pop you can. Alternatively you can stop sending colonists from the source planets. Option 3 is to ban the body from the system view (F9).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: intolerantape on March 15, 2016, 03:53:02 PM
Add an option to coordinate the completion dates of all current construction projects to the 'Industry' tab of the 'Population and Production' window. 

The player specifies the desired date of completion and clicks the button.  Then the game attempts to distribute the colony's construction capacity between the current projects in order to complete them all on the specified date. 

If the projects cannot be completed by the specified date, then 100% of the construction capacity will be allocated to finish all of the current projects at the same time as quickly as possible.

If the projects can be completed by the specified date, then only enough construction capacity will be allocated to finish all current projects by that date.  Any additional capacity is left unallocated.

It might be simpler to specify the time to complete (in days or seconds or whatever) instead of the date of completion.  This way the functionality could be presented with a single text box and a button.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on March 15, 2016, 06:20:31 PM
I dunno about defaulting to trying to complete everything at the same time.  I'd want it to just start spewing errors at that point so I can come and fix production.  If I am making something expensive that I want to happen over the course of a century or whatever (1000 factories lets say) then the last thing I want is production splitting to make sure everything gets done at the same time.  (and me not knowing that this had happened)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on March 16, 2016, 09:16:13 AM
I just noticed, it seems noone has yet to suggest this helpful little thing. A toggleable visible grid for the Galactic Map. It would be based on the grid size set for your "Line up" size setting. Its just a small thing that would help us line systems up easier into actual grids/sectors.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Iranon on March 16, 2016, 01:56:52 PM
Talking about the galactic map... how about more information about jump connections?

Colours to reflect one-way jump gates. A few short lines outwards from the circle for unexplored gates (orange or green depending on the presence of a jump gate)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Hydrofoil on March 23, 2016, 05:11:47 AM
Appologies if they do exist in the game and i just havnt gotten the right tech for it in all my games but... Id like to see Bio weapons added to the game
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: db48x on March 23, 2016, 05:50:57 AM
Appologies if they do exist in the game and i just havnt gotten the right tech for it in all my games but... Id like to see Bio weapons added to the game

You could dump chlorine gas into their atmosphere :)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on March 23, 2016, 09:28:44 AM
You could dump chlorine gas into their atmosphere :)
Technically, that's a chemical weapon. 

I'm not in favor of bioweapons, for the simple reason that bioweapons are only really useful against planetary populations.  Based on real-world experience, they'll be much more effective against civilians than against military units, and Steve has a strong aversion to what he calls GFFP, Genocide For Fun and Profit.  Basically, it shouldn't be too easy to simply wipe out a planetary population and take their stuff, and I largely agree with him as a matter of gameplay.  Bioweapons are only good for GFFP.  Abuse of terraforming is probably as close as we're ever going to come to that, for the simple reason that it's really hard to get rid of and not that easy to do.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: db48x on March 23, 2016, 09:56:35 AM
Technically, that's a chemical weapon. 

Close enough.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: intolerantape on March 23, 2016, 09:06:11 PM
Quote from: intolerantape link=topic=8107. msg87993#msg87993 date=1458075182
Add an option to coordinate the completion dates of all current construction projects to the 'Industry' tab of the 'Population and Production' window.   

The player specifies the desired date of completion and clicks the button.   Then the game attempts to distribute the colony's construction capacity between the current projects in order to complete them all on the specified date.   

If the projects cannot be completed by the specified date, then 100% of the construction capacity will be allocated to finish all of the current projects at the same time as quickly as possible. 

If the projects can be completed by the specified date, then only enough construction capacity will be allocated to finish all current projects by that date.   Any additional capacity is left unallocated. 

It might be simpler to specify the time to complete (in days or seconds or whatever) instead of the date of completion.   This way the functionality could be presented with a single text box and a button.

After playing the game a bit more, I'd like to change my suggestion to a simpler "complete in X days" function to supplement the "Create" and "Modify" buttons in the production screen.  The feature consists of 1) a text box to input the desired number of days til completion and 2) a button to execute the action.  When pressed, the game calculates the percentage of production needed to complete the project in the specified time frame and puts that amount into the "Percentage" field.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on March 25, 2016, 03:18:18 PM
For storytelling aspects it would be nice to have a Datasheet of deceased personell where you can see all their history and data, rather than to have to open a saved database to extract these informations - because who can memorise all those hundreds of personal vitas, right  ;)

Once you have the information the entries can be manually deleted.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: rorror on March 26, 2016, 08:57:23 AM
A Simple Suggestion, or more like a Feature Request.

Make the following thing sort on Alphabet (when dubble clicking on a row)
Easyer to find your TG
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on March 28, 2016, 01:02:34 AM
When designing components, could the company name field be a drop-down that you can add names to?  It would help me a lot with keeping consistent spelling/capitalization and also speed that up a bit.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on March 28, 2016, 10:14:11 AM
Per the recent discussion in the bugs thread, I'd like to suggest that we change the way ships work so that ships can only be added to the game after they've been locked.  Unlocked classes should not appear on the shipyard tooling/build lists, or on the fighter/PDC build lists, or in the Fast OOB window.  This closes several loopholes that players sometimes exploit accidentally, such as being able to build freighters with no engineering spaces.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on March 29, 2016, 09:59:10 AM
After a manual creation of a system and linking to other systems a randomize button which exchanged all the jump point targets in that one system would be nice. At least you yourself as space master would not know which jump point leads to which system.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Rich.h on April 02, 2016, 02:10:53 PM
Is there a reason why jump capable ships can only be built up to 1.25mt? If it is not down to an actual program limitation could we have the numbers changed so that at the top end you could have ships of 4,6,or 8 times larger?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: filippe999 on April 02, 2016, 04:56:54 PM
Would it be possible to add certain auto-turn stopping events to an "ignore" list? I'm tired of auto-turns stopping at every civilian ship scrapped/built or civilian mining colonies expanding or being founded.  I can see how they are useful to know for an experienced player but the only thing I was actually expecting was the end of my research or the orders finished from my task groups.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on April 03, 2016, 12:47:34 AM
Espionage & Counter Espionage:

I think that it is way to easy to steal important information from other Nations. It is not so much the amount of information stolen, but what is stolen. Information about a Ship design or Gravitational Data are ok. But having finished a 50.000 RP project and see it three month later be stolen by another Nation is kind of frustrating. I suggest the following system. Adding a "Researched at Timeindex" to any researched project, scientific grav or geological data or ship designs. So when the game roles a successfull espionage the odds of selecting which technology will be stolen can be separated into different categories:

a) State Secrets: All actual researched projects which are not older than 5 years (10% Chance)
b) Modern Information: All researched data which is between 5 and 10 years (30% Chance
c) Standard Information: All research data which is older than 10 years (60% Chance)

Through this older data will be picked more often as newly researched or found information.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Noble713 on April 03, 2016, 07:57:13 AM
I'm invading an NPR homeworld now, and I noticed there's no easy way to keep track of the enemy's ground OOB. The Event log tells you the names of enemy battalions that suffer casualties, but unless you keep a running tally in your head, you don't have even a semi-clear picture of how many and what type of units you are fighting.

So I'd like to have something like the Tactical Intelligence tab (which lists knowledge of enemy ship classes), but for ground units.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on April 04, 2016, 06:50:26 AM
So we all hate it when that great scientists has an earth attack, or when we loose experienced officers through health issue. It'd be nice to have a line of Biology research that boost life expectancy. It would fluff out biology a bit too.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Vandermeer on April 04, 2016, 09:40:46 AM
So we all hate it when that great scientists has an earth attack, or when we loose experienced officers through health issue. It'd be nice to have a line of Biology research that boost life expectancy. It would fluff out biology a bit too.
Yeah, these Earth attacks have really disturbed at least two of my games already. All the dead officers, a shame. (http://www.greensmilies.com/smile/smiley_emoticons_razz.gif)

...But I agree with the life expectancy thing, and had similar thoughts for long. This is especially an issue when you play as a phantastic race with non-earth start. Who says that a race of inky-skinned sauropoda must have the same life expectancy as humans, so a variable for the race's characteristics for this maybe could add something here for one.
On the other hand, if not standard, then at least some secret ruin tech for medicine would be nice. How that work exactly;...there are a couple things that would help. Instead of just making sickness or death more unlikely, it could also just introduce random "curing" events where the health status of a random afflicted officers betters "thanks to progress in medicine/he was treated successfully" or something.

Of course this would also increase the officer pool as a side effect, however with retirement age still in place, it shouldn't become too dramatic of an increase.(except maybe when there should be accustomed retirement with custom long-lived races)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on April 04, 2016, 05:46:45 PM
When the life expectency is prolonged then all affected parameters should also prolong. Meaning to get promoted or increase a statistical value should take proportionally longer. Otherwise the longer life expectency gives an imbalance to the game (don't know how much of an imbalance - but definitely one).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on April 05, 2016, 03:35:16 AM
Why? Promotion depends on the number of officers you have, not time, so our command structure wouldn't get more top-heavy. And yes, it would increase the effectiveness of academies... But is that a bad stuff?

It would also improve population growth I think, which would also be fine.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Vandermeer on April 05, 2016, 11:26:20 AM
It would also improve population growth I think, which would also be fine.
Actually either not, or opposite. :) If the fertile years stay constant, then increased life time will actually reduce the population growth average.(->more people, but a smaller part of them is reproducing) If the fertile years expand in proportion to longer life-time, it will just stay constant.

When the life expectency is prolonged then all affected parameters should also prolong. Meaning to get promoted or increase a statistical value should take proportionally longer. Otherwise the longer life expectency gives an imbalance to the game (don't know how much of an imbalance - but definitely one).
For one I wouldn't like that with the promotion, because it is timed to exactly one year, and adding imbalance to that is ugly. But on the other hand, just as Sheb staid, promotion is not dependent on time, but total officer count. I had plenty 60+ old commanders and lieutenants in my time because they never got promoted as the combined skill-to-free-positions cross section was not in their favor. There would be more officers as they die less, so there is this imbalance, but enlarging promotion period will not hinder this.

I also don't know how much that would be. Depends on how many officers die percentage wise of sickness instead of retiring or in battle. If that number is say 30% (high estimate), then medical technology that reduces this to half would on average improve officer numbers by 0.85/0.7 = ~21%. However, keep in mind that there is a large cropping function in the game that just retires unused officers after 6 years (which usually accounts for the most "loses" in my games), so you cannot in any case get too much anyway.
The only thing that is  imbalance here is that you would maybe need only 5 academies to fill demands of 6 with this, and....
Why? Promotion depends on the number of officers you have, not time, so our command structure wouldn't get more top-heavy. And yes, it would increase the effectiveness of academies... But is that a bad stuff?
No, that really doesn't seem too much or cheating.

Also, there is construction factory efficiency tech, and mine and research efficiency tech. Then this would be a small bonus academy efficiency tech. Why not?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on April 06, 2016, 09:41:42 AM
Example: If say at average 1 promotion is granted every 1 month per 60 officers.

Human Population: 3 academies by average lifespan as it is today lets say 300 officers on average - meaning 5 promotions per month - randomly dealt.
Alien Population: 3 academies by an average lifespan 1.5 of human population would give an average of 450 officers on average - meaning 7.5 promotions per month - randomly dealt.

Since officers in use usually get more promotions and upgrades, the top brass will be larger and more stronger in the alien population - just because of longer lifespan.

It can be that way - it should just be clear if it should be so - and be aware if it would be too strong a bonus for the alien population with the longer lifespan.


As far as I know Aurora has no underlying mechanic which calculates life span or anything similar. Just the Max Years to be in service for the officers. So we are talking pretty academic here with not much value to the game, I guess. The growth rate of a population is basically a curved % dependent only on the actual size of the population (of course modifiable by radiation or dust or leader bonus). If there are no negative or positive modifies whatsoever, the same size population on two different plants would grow exactly identical in size.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on April 06, 2016, 10:54:42 AM
Well, there are two things which determine the promotion rate - attrition and corps growth.  We can do basic analysis of each of these separately, and then look at combining them:
1. Assume the officer corps is in a steady state.  Officers are being introduced as fast as they are attrited by age, accidents, medical conditions, and lack of requirement.  In this case, the promotion rate will be based entirely on the average lifespan of officers.  Let's say it's 20 years.  In this case, assuming that attrition is constant at all ranks (a bad assumption, but I'm doing this on a piece of paper for fun), then each rank will lose 5% of its strength every year to attrition.  Which means that (5/3)% of officers of each rank will be promoted each year to the next rank up, plus those to replace losses of officers at that rank to the next rank up, and so on.  In practice, this will increase the percentage loss for promotions to 2.5% in the lower ranks.  So you'll see 7.5% turnover in each rank each year, and a 1 in 40 yearly chance of promotion for officers, or 1 per 480 officers per month.  Doubling the lifespan of the officers to 40 years would drop this to 1 per 960 officers per month, but the number of officers in the corps for a given number of academies would double.
In practice, you're going to see quite a few officers attrited out at 5 years or so due to non-assignment (because they just didn't have the skills) while others can easily pass 40 years.  I don't have the time to put together a better analysis of this case. 

2. Assuming that there's no attrition, and promotion only comes from corps growth.  In this case, there's a total of 1 promotion per 2 officers added.  (One-third of officer additions cause a promotion from O-1 to O-2, but 1/3rd of those cause a promotion from O-2 to O-3, and so on.  Those of you who had calculus just realize that we're doing a sum of a series, and wincing.  The sum comes to 1/2.)  In this case, the total size of the officer corps is irrelevant. 

That said, I'm in favor of adding medical technology to the tech tree.  If nothing else, it would make biology researchers more useful.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on April 06, 2016, 11:06:07 AM
It should be fairly easy to implement too: The game must have a %age chance of officers getting sick, dying from accidents, etc etc. You'd just need a tech to bring that percentage down.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on April 20, 2016, 04:35:40 AM
Add a level of army organisation above Division so that we can actually make use of Tier 4 ground officers, named either a "corps" or an "army. "
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on April 20, 2016, 04:51:07 AM
What about ground force staff officers, like for fleets?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Rich.h on April 20, 2016, 07:09:04 AM
Could we get the ability to add notes to specific bodies/colonies, either on the F9 system generation screen, or the F2 economy screen. It would help with general fluff type info to flesh out the RP of the game if we were able to add things.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on April 20, 2016, 09:44:01 AM
Quote from: Sheb link=topic=8107.   msg89905#msg89905 date=1461145867
What about ground force staff officers, like for fleets?
That would be pretty good.    Maybe at Corps/Army level you can have staff officers in addition to the actual leader of the corps.    I'm not sure how much you can do with it from a gameplay perspective though.    A guy for training, a guy for his combat bonus, a "public affairs" guy, and the general himself?

I think a better place to add staff officers personally is actually with civilian administrators.    Having a cabinet for the whole nation or for individual sectors would add a great deal to the game, in my opinion.   It'd certainly alleviate a lot of the civilian administrator bloat that I've been noticing in my current game, by actually giving these men something to do.  Maybe as well as that, we could have multiple "ranks" for civilian administrators so I could give my sector governors different titles.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Tree on April 20, 2016, 11:15:06 AM
Yeah, more stuff for civilian administrators would be amazing, ranks and cabinets both.

It'd be nice to have a sort of tier system (colony, system, sector, empire) so that the cabinets' bonuses are less effective the farther they are from the colony tier, but still have it stack with all those below.  Probably also a minimum population requirement so you can't abuse it and have a cabinet at each tier, everywhere.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on April 23, 2016, 02:05:50 PM
A way to exclude ships or posts from Auto-Assign. Alternatively Auto-Assign not only for ALL posts, but for a specified selection of posts.

Also an option that Auto Assign does not dump the overhead administrators and ranking officers.

Maybe an event warning that there are open posts (this warning should not be given if post is excluded from being filles by above marker).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on April 25, 2016, 05:54:38 PM
Could we change the 'Continual expansion' box for shipyards to an 'expand to'?  I often find myself needing to get a shipyard to some specific value which isn't divisible by 500, and it's annoying to have to keep an eye on the shipyard when I'm doing so.  Instead, set it so that it expands to the value you give it, and then sends an alert, with a target tonnage of 0 triggering the system as it currently works.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on April 25, 2016, 10:31:29 PM
I'm actually quite baffled no-one has suggested this yet (at least to my knowledge and searches).

A Squad Size reduction tech for jump engines. After maybe Squad size 6-7 you could be able to research Squad size 2 with x0.9 to engine size, and Self Jump for x0.8 engine size after that (invalid if drive size already makes it "self jump" to still have that branch meaning something).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Garfunkel on April 26, 2016, 04:24:17 AM
Could we change the 'Continual expansion' box for shipyards to an 'expand to'?  I often find myself needing to get a shipyard to some specific value which isn't divisible by 500, and it's annoying to have to keep an eye on the shipyard when I'm doing so.  Instead, set it so that it expands to the value you give it, and then sends an alert, with a target tonnage of 0 triggering the system as it currently works.
This would be great. Especially for commercial yards, where you always use the 10,000 tons increase anyway.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on April 26, 2016, 08:01:01 AM
Also would be awesome for all the OCD people like me around who hate ending up with a shipyard at 4783 tons.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on April 26, 2016, 09:21:13 AM
Also would be awesome for all the OCD people like me around who hate ending up with a shipyard at 4783 tons.
I'm with you on that.  The other way to deal with that is to only use the stepwise expansions, which always round to the nearest hundred.  But that's annoying when you want to add 200 tons, and have to keep checking the completion percentage to make sure you get it when it's at or just above 40% done.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on April 26, 2016, 08:41:51 PM
I had an idea for how to make industrial production easier to allocate.  Instead of assigning a fixed percentage of your industry to each project, you assign each one an arbitrary number of 'tokens'.  Each project gets a percentage of the total industrial output (the actual percentage utilization would be set separately) equal to the percentage of active tokens it has.  This makes doing things like building ship parts much, much easier because you don't have to reduce allocation to something else first (instead, the hit is taken across the whole basket unless you reduce something to match), and when projects finish, the rest of the basket is re-shuffled to match.  The only problem is that it doesn't really leave much room for the queue.  Maybe set it up so that if the queue is in use, tokens, instead of disappearing, go to the queued project until it gets the number it's supposed to have.
Also, can we please get an event message when shipyards and GFTFs are built?  It's annoying to go to the shipyards tab, see a new one, and think 'how long has that been sitting there?'.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: cakepie on April 27, 2016, 09:19:46 AM
So, you're suggesting that we specify the amount of industrial output to be allocated to each project as a ratio or proportion among the active projects, rather than as a percentage of total industrial output.  Mathematically speaking, "find the sum total number of 'tokens', normalize that as 100% of the industrial output, and calculate that as percentage utilization (the existing system)"

As for queuing, if I understand you correctly, a scenario might work like this:

Code: [Select]
Active projects (in expected order of completion; tokens): A(2),B(2),C(1) at {40%,40%,20%}
Queued projects (in priority order; tokens acquired/required): D(0/3),E(0/2)

Project A completes, freeing up two tokens, given to D, but not enough to start D, so:
Active projects: B(2),C(1) at {66%,33%}
Queued projects: D(2/3),E(0/2)

Project B completes, freeing up two tokens, D has enough tokens to start, but not E so:
Active projects: C(1),D(3) at {25%,75%}
Queued projects: E(1/2)

Project C completes, E can start:
Active projects: D(3),E(2) at {60%,40%}
Queued projects: none

Based on the use case you described, you want to be able to inject tokens into the system to force a queued project to start alongside existing ones, eg.  from the example above:
Code: [Select]
Active projects. A(2),B(2),C(1)
Queued projects: X(5/5),D(0/3),E(0/2)
Here, adding project X to the front of the queue, and giving it sufficient tokens effectively results in:
Code: [Select]
Active projects: A(2),B(2),C(1),X(5) at {20%,20%,10%,50%}
Queued projects: D(0/3),E(0/2)
By extension, you could inject tokens at any point in the queue:
Code: [Select]
Active projects: A(2),B(2),C(1)
Queued projects: D(0/3),X(5/5),E(0/2)

When projects A & B complete:
Active projects: C(1),D(3),X(5)
Queued projects: E(1/2)
You don't have to inject the full number of tokens needed, either:
Code: [Select]
Active projects: A(2),B(2),C(1)
Queued projects: D(0/3),X(4/5),E(0/2)

Conversely, if a project completes and there are no other projects in the queue to accept the freed up tokens, then those tokens would simply "fall out of circulation" and disappear. 


I see a number of potential issues with such an arrangement:
1.  Possible to queue a project that will never acquire enough tokens to start
2.  Non-constant (potentially highly variable) production rates over the course of a project
3.  The assumption that you always want 100% of possible industrial output

An example of (1) would be if we change my above original example such that project D queues up at 0/6 tokens -- it will never start since it can acquire at most 5 tokens from A,B,C -- and project E is also stuck as it is forced to wait behind D.  The simplest, obvious solution here is to prohibit queuing a project that requires more tokens than currently circulating in the system.  (Other, fancier scheduling algorithms, eg. allowing E to leapfrog over D, would only get unnecessarily complicated and would still have to contend with potential starvation problems. )

(2) is evident from the example above; the percentage of total industrial capacity used by each project can fluctuate quite wildly.  Compared to such behavior, the existing system (setting percetage utilization) has the key advantage that the production rate of each project is constant (assuming no changes in the colony's industrial capacity).  This also means that estimated completion dates for projects are reliable, which makes it simple to plan ahead, coordinate between different production projects, or even synchronize industry with other parts of the economy, eg. :
a) You can easily and reliably ensure that you've assigned sufficient production capacity to a project must be completed by a certain date -- eg.  your shipyard needs to expand and/or retool in order to start building a new class design, and you want to use this time while waiting for the shipyard to ready up to pre-build some ship components -- those components must be finished on time so that they are available for use by the shipyard at the start of ship construction. 
b) You can adjust the production rate according to the raw material availability -- eg.  say you want to build 10 fighter factories; however, your colony has no standing stockpile of vendarite, and you aren't shipping/shooting it in from elsewhere, just a stable production of 90 vendarite per year from local mining -- then it is pointless to assign the project any more than 120 production (the mines won't be able to keep up). 

Matching industrial production rate to raw material availability is also a reason why you'd might want to run at less than full capacity, which brings us to (3).  I'm not sure it is safe to assume that you'd always want to normalize the token-based industrial output allocation over a total of 100% of production capacity.  A setting could be added so that you could specify for the tokens to be normalized over less than 100%, but that seems a bit kludgy and doesn't really do much to help the issue of inconstant production rates (at least, not without user intervention each time a project starts/finishes).  Another possibility is to allow scheduling "idle" projects that occupy a certain number of tokens and "complete" after a fixed period of time or upon "consuming" a certain amount of "build cost" (albeit consuming/producing nothing) -- but this would probably be rather unintuitive and hard to use considering that you'd basically find yourself fiddling with the "idle" project in order to try to (indirectly) regulate the production rates of other projects. 


The existing percentage based allocation empowers the player with a lot of freedom and control to make fine adjustments (down to 4 decimal places of a percentage point!) to suit a wide variety of situational gameplay needs, and is capable of supporting different playstyles and arbitrary roleplay rules.  I can understand the use case you cited, but I'm concerned that the proposed token-based method would instead reduce the amount of choice and control that players have -- it's significantly less powerful; I'm not convinced the benefits are worth the trade off. 


Since you cited "don't have to reduce allocation to something else first", it suggests that your goal may be convenience, or you wish to "preserve the relative allocation across existing concurrently running projects".  Have you considered pushing 100% of existing projects back down into the queue? This preserves their relative allocations, and if you set your ship components to build sequentially, all at 100%, then the pre-existing projects will all pop back out of the queue upon completion of the ship components, and resume where they left off.  Basically, "drop everything you're doing, build these as a priority; once these are done, resume what you were doing before.  " Numerically, this is generally similar to building the ship components alongside with the "whole basket" of pre-existing projects, since in any case you'd have to divert an amount of production capacity equivalent to the build cost of the ship component project(s) away from the basket of pre-existing projects.  The difference is that by running both types alongside one another, some pre-existing projects might actually complete before the ship components are done.  On the other hand, pumping out the ship components first means that they are available sooner (advantageous in a way, given that components must be available in stockpile at the start of shipbuilding to be used. )
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on April 27, 2016, 10:53:32 AM
A production queue for ships and ground forces would be nice, too. It would make life much easier when you try to handle multiple nations.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on April 27, 2016, 12:12:49 PM
Cakepie:
You're pretty much correct, with a few minor exceptions.  First, I'd solve the starvation problem by allowing projects to begin work with fewer than their full set of tokens.  They'll take tokens up to their maximum, but work with however many are currently assigned.  This also makes it easy to re-allocate production from one thing to another, and then have the production go back to to the first thing when the second one finishes by setting the 'cap' for the first one to the original allocation.
Second, I'm aware of the swings that could take place.  It's an unavoidable consequence of this idea, and I think it would probably be worth it.  You'd have to keep an eye on time-critical projects, but I'm not sure it would be worse than it is now.
Third, there's no way to avoid having some semi-kluged mechanism for using less than 100% of industry, which is why I suggested it.
And I wasn't aware you could push existing projects back into the queue.  That would help a lot, actually.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Garfunkel on April 27, 2016, 04:15:16 PM
Also, can we please get an event message when shipyards and GFTFs are built?  It's annoying to go to the shipyards tab, see a new one, and think 'how long has that been sitting there?'.
There already is an event when they are constructed.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Gabethebaldandbold on April 27, 2016, 07:12:32 PM
Why do we not have live fire exercises? I was expecting to get the chance of testing my ships and crew before feeding them to the spoiler races...  (and if that or something like that already exists, how do I do it?)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on April 28, 2016, 09:50:33 AM
Why do we not have live fire exercises? I was expecting to get the chance of testing my ships and crew before feeding them to the spoiler races...  (and if that or something like that already exists, how do I do it?)
Task Force Training. Its the big button in one of the TG order window.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Gabethebaldandbold on April 28, 2016, 10:27:13 AM
Task Force training. Its the big button in one of the TG order window.
I know task force training, I meant like shooting missiles at allies to get them experience, you know, test the crew and see how it holds up
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on April 28, 2016, 02:41:06 PM
I know task force training, I meant like shooting missiles at allies to get them experience, you know, test the crew and see how it holds up
There are about three different ways this could be read:
1. You want to run experiments to learn about how your tech is working.  This is doable already.  Create a pop 0 race sharing your home planet.  Transfer stuff to them when you want to do experiments.
2. You want a faster way to get TF training.  This isn't a terrible idea, although it's been made somewhat redundant with the addition of automatic low-level TF training.  The easy way would be to have the ships train at full speed instead of half-speed, for maybe 50% more training per unit time.
3. You want something like TF training, but for crew quality.  I like this one, although it's mechanically difficult to work out.  What exactly does it cost you?  Missiles are an obvious choice, although the equally obvious counter is to make a training missile which has a conventional engine and is otherwise as cheap as possible.  And it leaves non-missile ships out in the cold.  I can't think of a non-gameable way to solve this.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on April 29, 2016, 11:03:05 AM
It is possible to Transfer parts of ship components via a cargo ship (happens in 0.2 increments). But since the stockpile does not show decimals, you might 'loose' a viable ship component, if you don't pay attention if you have transferred the whole part.

If you have 5 parts of one component and happen to transfer only 1.8 of them to another colony, the stockpiles would tell you 3 for the origin and 1 for the target stockpile - and not 3.2 and 1.8 as there would be in reality.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on April 30, 2016, 09:57:19 AM
It looks like our commanding officers appear at their 21-y academy graduate age, and not as graduate lieutenants, but as lt.  -commanders/colonels at once, however not annually - let it be in the middle of a year (1st July) - after theyr graduate party, but at random date.   
As for administrators and scientist program leaders, their invariable 21-y commission ages seems to be even more fanciful. 

So, I think it will be good, if our junior leaders (both commanders and administrative leaders - relevant window and buttons have quite deceptive name now, so far as administrators and scientists are _not_ commanders) will appear at random own ages too, not only random dates of commission, and average age of this commission should be somewhat higher, about 30-35 Earth years.   
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on April 30, 2016, 09:22:54 PM
Could we get the ability to add notes to specific bodies/colonies, either on the F9 system generation screen, or the F2 economy screen. It would help with general fluff type info to flesh out the RP of the game if we were able to add things.
Would be pretty nice, actually! I agree this should be something that needs to be added.

A current workaround for you, though, could be designing a tiny PDC called a "Planetary Archives Base", which you build on the surface of the planet in question, and then add notes to the PDC/Task group of it (i forget which one retains notes). This should be an exceptionally fluffy workaround in the meantime.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: seronis on May 02, 2016, 07:03:22 PM
When research finishes and a diff research is queued to immediately start can we please not have auto turn disable?   Autoturn should only disable for things that require intervention.    When we've set up a queue we dont want interrupted. 

In general EVERYTHING that has an interrupt should allow the player to disable that interrupt.   We did already intentionally check 'autoturn' after all.   
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on May 02, 2016, 07:39:45 PM
In general EVERYTHING that has an interrupt should allow the player to disable that interrupt.   We did already intentionally check 'autoturn' after all.
Not like this has been requested thousands of times already. [/sarcasm]
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Garfunkel on May 02, 2016, 09:36:12 PM
Ability to toggle jump gates completely off, for both player, the NPRs and of showing up randomly.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on May 03, 2016, 05:14:40 AM
Can the NPRs manage without jump gates? Especially for civilian expension?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Garfunkel on May 03, 2016, 09:17:30 AM
They do use jump engines. I don't know if NPRs even have a civilian sector the way a player does. I doubt it.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: KhazintheDark on May 03, 2016, 11:25:03 AM
Is there any possibility of a 'laptop mode' for lack of a better phrase that can be used in the game creation menu makes the tabs 1366x768 and adds a scroll bar on the side? I don't know whether it would be feasible but off the top of my head a modified CSS may be able to do it, if Aurora uses a CSS. . .

I don't know, either way it seems like something that would allow people with a laptop to play it on train journeys and the like.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on May 03, 2016, 12:42:46 PM
I mean, do they build jump freighters and jump colony ships?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Erik L on May 03, 2016, 01:08:22 PM
Is there any possibility of a 'laptop mode' for lack of a better phrase that can be used in the game creation menu makes the tabs 1366x768 and adds a scroll bar on the side? I don't know whether it would be feasible but off the top of my head a modified CSS may be able to do it, if Aurora uses a CSS. . .

I don't know, either way it seems like something that would allow people with a laptop to play it on train journeys and the like.
The simple answer is "no".

The extended answer is "no, because it is a one-man job, and Steve's resolution is greater than that. And this has been addressed multiple times prior. And Aurora does not use CSS."
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Paul M on May 04, 2016, 03:24:43 AM
An indicator on the system survey data chart/screen that the body has had a ground survey performed.  Once you abandon the "colony" it becomes increasingly difficult to remember which bodies you surveyed with a geoteam.  This could be something that shows up in the lower window when you click on a body rather than an additionaly column.

Also a change in the variable type for components so that you can transfer larger component in lots.  I tried to transfer a jump gate construction module and it showed up as 0 modules on earth and none on rosetta rather than 0.2 and 0.8 respectively.  I'm guessing this is due to integer variables used for the stockpile.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: cakepie on May 04, 2016, 10:57:19 PM
Quote from: Paul M link=topic=8107. msg90572#msg90572 date=1462350283
An indicator on the system survey data chart/screen that the body has had a ground survey performed.   Once you abandon the "colony" it becomes increasingly difficult to remember which bodies you surveyed with a geoteam.   This could be something that shows up in the lower window when you click on a body rather than an additionaly column.
Yes, this please.  For instance, in the F9 system display, where (blank)/S/M indicates survey+minerals status, add 'G' to flag ground survey completed (supersedes 'S') would be very helpful.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: linkxsc on May 08, 2016, 10:43:06 PM
Fuel "drop tanks" that are loaded into a missile launcher (mainly box launchers) to extend the range of a small ship.

Ie. I have a fighter or FAC. It has a set fuel load... but i want to make a strike at something a bit outside of its normal range.
I could send a tanker... or i could attach a tank to the ship somehow, giving it the bit extra fuel to go a little farther.


Have already done this in real warships using tractor beams and having a droptank "ship"
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: AL on May 09, 2016, 05:20:21 AM
List a ship's internal HTK stat in the class summary display.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Paul M on May 18, 2016, 05:09:36 AM
A minor fluf request:  can we have the possibility to name the ground training facilities?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Garfunkel on May 18, 2016, 09:55:19 AM
and Civilian Shipping Lines too, please!
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Mastik on May 18, 2016, 10:15:44 PM
Would it be possible to have PDCs listed on the planetary summary page.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Paul M on May 22, 2016, 10:21:36 AM
I would suggest that instead of a terra-former producing x atm of gas that the formula should be:

(tech_rating)*(12756/(diameter of current body))**3  [12756 is the diameter of Earth]

So using the NCN for Mars a single terraformer should produce:

(0.002 atm/year)*(12756/6800)**3 = 0.0132 atm/year

So smaller bodies terraform faster but larger bodies go even slower.  Basically this takes into effect the volume of gas the engine has to produce.  The cube is geometrically correct but other factors could be used to balance it for game purposes.  Even a linear increase would speed up terraforming smaller planets and moons.  Correspondingly large bodies will terraform much slower.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on May 23, 2016, 02:34:48 AM
Fund it.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: sloanjh on May 23, 2016, 07:04:52 AM
The cube is geometrically correct but other factors could be used to balance it for game purposes. 

Why do you say that cubed is correct when the surface area goes like R**2?

John
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Paul M on May 23, 2016, 08:32:06 AM
Why do you say that cubed is correct when the surface area goes like R**2?

John

I was being lazy.  I was working on the assumption that the volume of the gas can be related to the volume of the planet itself to avoid a messy formula for the ~10 km of dense gas above the planet that is the atmosphere.  But using the square is correct as the full formula can be approximately given by (Re/Rtf)^2 .  I just didn't follow the math all the way through as I was avoiding writing out the formula and doing the algebra.

But on the other hand my feeling is this is something that should be adjusted for game balance more than just out of geometric considerations.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: swarm_sadist on May 23, 2016, 10:22:38 AM
Just use the surface area of the planet. The atmosphere is mostly within 20km of the planet so there is no need for fancy calculations.

KISS (Keep It Simple Stupid). Words to live by.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Paul M on May 24, 2016, 02:56:07 AM
I am continually informed that my definition of "simple" doesn't alway match up with other peoples meaning of the word.  But the culprit was lazy thinking on my part more than anything else.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: swarm_sadist on May 24, 2016, 09:58:26 AM
I am continually informed that my definition of "simple" doesn't alway match up with other peoples meaning of the word.  But the culprit was lazy thinking on my part more than anything else.

Nothing wrong with being complex.

Surface Area of a Sphere = 4*pi*r^2
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on May 24, 2016, 10:00:28 AM
If we're fixing that formula, we should probably also take into account planetary gravity, both for realism and to avoid making large planets too hard to terraform.  Adding a factor of (gPlanet/gEarth) would work.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: swarm_sadist on May 24, 2016, 11:23:15 AM
I was thinking about that as well, but the surface area goes up at a pretty steady pace with planet mass. Surface Area < Volume, usually.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on May 24, 2016, 12:11:48 PM
I was thinking about that as well, but the surface area goes up at a pretty steady pace with planet mass. Surface Area < Volume, usually.
Well, surface area is going to scale with the square of radius, while mass scales with the cube of radius.  But gravity scales with the inverse square of radius, so the surface gravity scales linearly with radius.  So in theory, and assuming constant planet density, the required time will scale inversely with the radius of the planet. 
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on May 24, 2016, 05:03:41 PM
Well, surface area is going to scale with the square of radius, while mass scales with the cube of radius.  But gravity scales with the inverse square of radius, so the surface gravity scales linearly with radius.  So in theory, and assuming constant planet density, the required time will scale inversely with the radius of the planet.
Doesn't the inverse square law only apply to the diminishing effects of gravity over range, with the radius in question being said range?
Volume and mass are almost directly linearly correlated (granted, given the same density). With mass being directly tied to gravitational pull on a linear basis...
So I think in this case you might just be using the wrong maths. Surface area of the planet would be a lot better value to terraform by. Feel free to correct me if I'm wrong, though.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on May 24, 2016, 05:27:47 PM
Doesn't the inverse square law only apply to the diminishing effects of gravity over range, with the radius in question being said range?
Volume and mass are almost directly linearly correlated (granted, given the same density). With mass being directly tied to gravitational pull on a linear basis...So I think in this case you might just be using the wrong maths. Surface area of the planet would be a lot better value to terraform by. Feel free to correct me if I'm wrong, though.
I'm not using the wrong math, but we're into some moderately esoteric physics, so I'm going to have to show it to explain.  If I'm misunderstanding you, then I'm preemptively sorry.
The shell theorem states that a spherically symmetric body will behave as if it is a point mass concentrated at its geometrical center, and that it doesn't matter if it is solid or hollow.  So we can calculate the gravitational force on someone standing on the surface of the Earth using the mass and radius of the Earth, just as we do to work out the pull on the moon.  It also states that anything inside a spherically symmetrical shell will not be affected by that shell's gravity at all.  The parts closer to you are counterbalanced by the parts farther away.  This means that someone digging down into a spherical planet will see exactly what someone would see if they were peeling away the planet instead. 
(The second part isn't particularly relevant, but it is interesting, so I'm not going to take it out.)
Now for the math:
1. The planet's mass is equal to rho*4/3*pi*r^3, and we'll assume that rho (density) is constant.  The acceleration due to gravity on a planet's surface gPlanet (assuming that the second object is small relative to the first one) is G*mplanet/r^2.  If we substitute in the equation for the planet's mass we get G*rho*4/3*pi*r^3/r^2, which simplifies to G*rho*4/3*pi*r.
2. The pressure on a planet's surface P is (slightly simplified) equal to (MassAtm/4*pi*r^2)*gPlanet.  If this doesn't make sense, consider conservation of momentum.  The pressure on the piece of air just above the ground must be equal to the force of gravity on the column of air above that piece.  Otherwise, the air would be accelerating upwards or downwards.  Either would be bad if sustained. 
3. Let's assume that each terraforming platform produces so many tons of atmosphere each year, dMassAtm.  Using this we can work out:
dP = (dMassAtm*gPlanet)/(4*pi*r^2) = (dMassAtm*G*rho*4/3*pi*r)/(4*pi*r^2).
Cancelling terms, we get:
dP = (dMassAtm*G*rho)/(3*r)
In other words, the change in pressure is proportional to density (smaller planet for a given mass means less surface area to spread the weight out across and higher gravity) and inversely proportional to radius (bigger planet means that you have to pump out more mass).  In aurora terms, we'd spec the terraforming machines on Earth, and then multiply the rate by the relative density and by the inverse of the relative radius.
Make sense?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: sloanjh on May 25, 2016, 07:49:49 AM
I'm not using the wrong math, but we're into some moderately esoteric physics, so I'm going to have to show it to explain.  If I'm misunderstanding you, then I'm preemptively sorry.
The shell theorem states that a spherically symmetric body will behave as if it is a point mass concentrated at its geometrical center, and that it doesn't matter if it is solid or hollow.  So we can calculate the gravitational force on someone standing on the surface of the Earth using the mass and radius of the Earth, just as we do to work out the pull on the moon.  It also states that anything inside a spherically symmetrical shell will not be affected by that shell's gravity at all.  The parts closer to you are counterbalanced by the parts farther away.  This means that someone digging down into a spherical planet will see exactly what someone would see if they were peeling away the planet instead. 
(The second part isn't particularly relevant, but it is interesting, so I'm not going to take it out.)
Now for the math:
1. The planet's mass is equal to rho*4/3*pi*r^3, and we'll assume that rho (density) is constant.  The acceleration due to gravity on a planet's surface gPlanet (assuming that the second object is small relative to the first one) is G*mplanet/r^2.  If we substitute in the equation for the planet's mass we get G*rho*4/3*pi*r^3/r^2, which simplifies to G*rho*4/3*pi*r.
2. The pressure on a planet's surface P is (slightly simplified) equal to (MassAtm/4*pi*r^2)*gPlanet.  If this doesn't make sense, consider conservation of momentum.  The pressure on the piece of air just above the ground must be equal to the force of gravity on the column of air above that piece.  Otherwise, the air would be accelerating upwards or downwards.  Either would be bad if sustained. 
3. Let's assume that each terraforming platform produces so many tons of atmosphere each year, dMassAtm.  Using this we can work out:
dP = (dMassAtm*gPlanet)/(4*pi*r^2) = (dMassAtm*G*rho*4/3*pi*r)/(4*pi*r^2).
Cancelling terms, we get:
dP = (dMassAtm*G*rho)/(3*r)
In other words, the change in pressure is proportional to density (smaller planet for a given mass means less surface area to spread the weight out across and higher gravity) and inversely proportional to radius (bigger planet means that you have to pump out more mass).  In aurora terms, we'd spec the terraforming machines on Earth, and then multiply the rate by the relative density and by the inverse of the relative radius.
Make sense?

The important part here is your number 2 - the pressure on the surface is (assuming atmosphere depth is much smaller than radius) the weight of the mass of air above you (i.e. mass per unit surface area) times the planet's surface gravity.  The total mass of the entire atmosphere is then simply that times the surface area, which goes like radius squared.  I considered folding in surface gravity when I pinged Paul about R^2, but since the range of habitable surface gravities isn't very big (5x-ish at most) I didn't think it was worth bringing up that complexity.  The reason I'm going here is to make sure people understand that your original point (scale by relative surface gravities) is the real thing they should be paying attention to, both since that's the thing with a selection effect to not vary much and because that's what Aurora tracks, not the dependency on density.  They're both correct formulae, it's just the surface gravity part is a lot simpler to grok IMO.

John
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on May 25, 2016, 10:35:34 AM
The important part here is your number 2 - the pressure on the surface is (assuming atmosphere depth is much smaller than radius) the weight of the mass of air above you (i.e. mass per unit surface area) times the planet's surface gravity.
Exactly.  If you're doing really serious atmospheric modeling, you take variations in gravity into account, but it isn't worth doing here. 

Quote
The total mass of the entire atmosphere is then simply that times the surface area, which goes like radius squared.  I considered folding in surface gravity when I pinged Paul about R^2, but since the range of habitable surface gravities isn't very big (5x-ish at most) I didn't think it was worth bringing up that complexity.
I think it's very worth bringing up, to reduce how strongly planetary scaling cuts the effectiveness of terraforming stations.  If we assume that density is pretty much constant, the range of habitable planetary radii is also going to be 5-ish, too.  With varying density, it might be 50% larger.  This means that the ratio between large and small planets is going to be in the double digits, and large worlds will take forever to terraform.  Folding in gravity takes the scaling from square to linear (approximately).
Quote
The reason I'm going here is to make sure people understand that your original point (scale by relative surface gravities) is the real thing they should be paying attention to, both since that's the thing with a selection effect to not vary much and because that's what Aurora tracks, not the dependency on density.  They're both correct formulae, it's just the surface gravity part is a lot simpler to grok IMO.

John
Fair enough.  I did suggest that originally, then went into the full math to explain why it was important, but it's mathematically easier to use density when you do that.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: NihilRex on June 03, 2016, 10:30:35 AM
<Snip>
 and large worlds will take forever to terraform.
<Snip>

I see no problem with this part.  Reshaping a world should be the work of generations, and not "Sister Jenny found a planet on her lunch break, it should be ready for the Amish Colonists by Tuesday."
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ty55101 on June 03, 2016, 05:22:36 PM
Could you add some type of randomizer for the ship names? Maybe a checkbox on whether or not the names are put in order or not on the class creation screen. I love my giant cruisers/carriers being the list of books in the bible in order, but I hate it when my army of dog fighters are in alphabetic order.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Paul M on June 06, 2016, 08:03:06 AM
I don't know if this has been fixed but could the way combat experience is given out be looked at?  So far as I can see no experience is given out to ships that use their weapon systems in combat which seems wrong.

I hope this has been fixed since 6.10.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on June 06, 2016, 09:43:00 AM
I see no problem with this part.  Reshaping a world should be the work of generations, and not "Sister Jenny found a planet on her lunch break, it should be ready for the Amish Colonists by Tuesday."
Then you should have a problem with the other side, which is that terraforming of small worlds will be unrealistically short.  Regardless of anyone's views on the optimal time for terraforming, a model which scales with the square of the planet's diameter is a bad one.

I don't know if this has been fixed but could the way combat experience is given out be looked at?  So far as I can see no experience is given out to ships that use their weapon systems in combat which seems wrong.

I hope this has been fixed since 6.10.
The problem there is defining 'combat', particularly for missile-armed ships.  Otherwise, it would be easy to get really, really good crews by building conventional-engine training missiles.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Paul M on June 06, 2016, 10:14:25 AM
Defining combat isn't a problem...shooting a weapon at a hostile target is combat.

I'm not sure when the game has an SM mode that allows pretty much anything that it is necessary to put in "cheat protection."  Yes you can get super well trained crews by cheats but the current way prevents any crew skill advancement that isn't from leader training.   Ships appear to only gain skill while being damaged...in most cases a damaged ship will either be destroyed (making the gain moot) or take losses to crew which will negate the gain.

Sure I can designate a rock as a hostile and shoot a missile at it, but the fact is it costs me a missile.  Maybe a cheapso missile but still one that took resources to build.  And frankly a live fire excersize is better than a simulator any day of the week.  Actually I'm not sure I can designate the rock as hostile...I can just designate it as a target?  Or am I not following what you are trying to say Byron? 

It is just that currently you gain no experience from sucessful combat which seems odd.  A group of ships that sucessfully ingages and destroys every inbound missile launched at them over a 10 min period will gain 0 combat experience.  Maybe I'm nuts but I'd think they would have learned a lot from that experience.

Having finished Jabberwocky over the weekend...this point is driven home to me.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: chrislocke2000 on June 06, 2016, 11:01:49 AM
I have to agree, just getting experience from getting wholes shot in you does not seem the best basis of advancing crew experience. Perhaps having a system that ties to combat actions but also provides for reducing benefits as crew get more experienced.

Also looking forwadd to reading the results of jabberwoky.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on June 06, 2016, 12:16:33 PM
Defining combat isn't a problem...shooting a weapon at a hostile target is combat.

I'm not sure when the game has an SM mode that allows pretty much anything that it is necessary to put in "cheat protection."
Actually, crew skill above 10% is something which isn't easily cheated without the DB password.  Point taken, but it's not so much 'cheat' as 'loophole'.

Quote
Sure I can designate a rock as a hostile and shoot a missile at it, but the fact is it costs me a missile.  Maybe a cheapso missile but still one that took resources to build.
Look at how cheap missiles can be made.  A size 1 missile with 0.99 MSP of minimal-multiplier conventional engine and 0.01 of fuel would cost next to nothing.   
Quote
And frankly a live fire excersize is better than a simulator any day of the week.  Actually I'm not sure I can designate the rock as hostile...I can just designate it as a target?  Or am I not following what you are trying to say Byron? 
You can't designate a rock as hostile.  You can shoot at waypoints.  If you require hostile targets, then it's a bit harder to exploit.  Although now I'm thinking about leaving a spoiler PDC alive and neutered to use instead. 

Quote
It is just that currently you gain no experience from sucessful combat which seems odd.  A group of ships that sucessfully ingages and destroys every inbound missile launched at them over a 10 min period will gain 0 combat experience.  Maybe I'm nuts but I'd think they would have learned a lot from that experience.
I agree that it's odd, and I'd like to fix it. The best solution I can think of would be based on actual damage to hostile targets, with the training bonus based on what the target is, so shooting at freighters would be less lucrative than shooting at warships.  That may or may not be manageable to implement, and it doesn't game nearly as easily as other options.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on June 06, 2016, 05:38:28 PM
Actually, crew skill above 10% is something which isn't easily cheated without the DB password.  Point taken, but it's not so much 'cheat' as 'loophole'.
Look at how cheap missiles can be made.  A size 1 missile with 0.99 MSP of minimal-multiplier conventional engine and 0.01 of fuel would cost next to nothing.    You can't designate a rock as hostile.  You can shoot at waypoints.  If you require hostile targets, then it's a bit harder to exploit.  Although now I'm thinking about leaving a spoiler PDC alive and neutered to use instead. 
I agree that it's odd, and I'd like to fix it. The best solution I can think of would be based on actual damage to hostile targets, with the training bonus based on what the target is, so shooting at freighters would be less lucrative than shooting at warships.  That may or may not be manageable to implement, and it doesn't game nearly as easily as other options.
Maybe have crew grade scale explicitly with the capabilities of the ship (so a higher grade crew refitting to more advanced weapon systems, most specifically beam fire control and missile quality, will have their grade lowered somewhat, but still be higher than lower grade crews), and then make it so grade increase is based on the difficulty of the shots your ship makes?
In example, if you upgrade your ship by replacing BFC with better designs, the grade of all crew adapted to older ships goes down a bit, but not enough to make the upgrade a straight debuff (if anything, it should just slightly reduce the immediate benefits of refit while expanding the potential growth overall. That way, or ships can improve their skills by working with primitive systems, but overall, having the newest and best performing weaponry will benefit their skill most in the long run.
That said, missile effectiveness isn't necessarily static to an individual ship, so not sure how that'll be handled.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on June 07, 2016, 01:27:13 AM
Why don't fractional WH have a %age chance to destroy an armor block? So a 3.4 WH would destroy 3 armor block, and have a 40% chance of destroying a fourth.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ty55101 on June 07, 2016, 01:38:40 AM
Why don't fractional WH have a %age chance to destroy an armor block? So a 3.4 WH would destroy 3 armor block, and have a 40% chance of destroying a fourth.

I would imagine it is because Steve put the variable type as ints so it can't hold decimals/fractions. Honestly, putting that into the system would make too much variance on something that is already random. (in my opinion) Armor columns are already rounded too and most people design missiles to have a cubed damage output because it is how to get deepest into the hull. (most likely to damage the ship)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Paul M on June 07, 2016, 06:43:46 AM
I would require hostile targets, otherwise you could be shooting at rocks or waypoints and while "live fire excersizes" are good they aren't that good.

You could also for missiles scale the experience with the (cost of launched missile/most expensive missile of that size) but that is likely a pita to program and has its own issues.

Also keeping a neutered spoiler about is different from firing cheepso missiles how exactly?  In both cases your are exploiting the mechanics, and if someone wants to do this in aurora I think that is  an issue between them and their confessor.

The issue of fake wars and crew grade is a big one in Starfire so I'm familier with what can be abused but I still think the current system is in dire need of a good (or Good and KISS) suggestion on how best to implement a better solution.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on June 07, 2016, 10:25:59 AM
Maybe have crew grade scale explicitly with the capabilities of the ship (so a higher grade crew refitting to more advanced weapon systems, most specifically beam fire control and missile quality, will have their grade lowered somewhat, but still be higher than lower grade crews), and then make it so grade increase is based on the difficulty of the shots your ship makes?
That would be an interesting idea, although it's not at the top of my list of reforms I'd like to see for crew.  The problem is how to scale it properly, particularly because BFCs have two factors.

I'm going to repost a suggestion I made long ago for improved crew realism:
First, the crew pool tracks people and points separately.  The academy has a level that it pumps people in at.  For example, it may add 100 people and 20000 points in a given week.  These are added to the pool values.  When a ship is commissioned, it takes the correct number of people and points, based on the pool averages.  Adjusting the academy training level only affects the inflow, not what's already in the pool.  Also, people should leave the pool.  Maybe 5% a year, of average points.  In wartime, you can check a box which temporarily slows the loss rate, but eventually (5 to 10 years later) it comes back to normal, or even goes higher.  After you uncheck it, the war timer counts backwards until it reaches 0, so people don't just toggle it on and off when they get to the point of diminishing returns.
Second, rotate people on ships.  To make it easy, whenever a ship gets shore leave, a certain number of people rotate back into the pool, based on how long it's been out.  Maybe 10% per year.  They're replaced with normal people from the pool.  This is to avoid the "ICBM station with an enormous crew rating" problem.
Third, allow picked crews, and unpicked crews.  These have maybe 150% and 50% of normal points, respectively, taking the appropriate number of people and points from the pool, and getting those values when the crew rotates.  This is to allow you to have a good crew on your fancy new battleship, and give your second-line PDCs the dregs.
Fourth, conscript-crewed ships should not feed into the pool.  Because of the nature of the crews (and to avoid flooding the pool with untrained people), the people who leave the ship at the end of their tour are just lost. 

Integrating your suggestion would mean that while under refit, the crew loses points, or at least stops gaining them.

I would require hostile targets, otherwise you could be shooting at rocks or waypoints and while "live fire excersizes" are good they aren't that good.
Agreed.  It also avoids minelayers being the best ships in the fleet.

Quote
You could also for missiles scale the experience with the (cost of launched missile/most expensive missile of that size) but that is likely a pita to program and has its own issues.
That's not a bad suggestion, although it isn't perfect.  First, it would be easy to build a weird training missile.  Size 1.1, maybe.  Or, if rounding is implemented, some size that doesn't get used for anything else.  Second, the most expensive missile might be a special-purpose one considerably more expensive than normal.  It's better than counting all missiles equally, certainly, but I still don't think it's the right solution.

Quote
Also keeping a neutered spoiler about is different from firing cheepso missiles how exactly?  In both cases your are exploiting the mechanics, and if someone wants to do this in aurora I think that is  an issue between them and their confessor.
There's a fine line here.  You don't want to create a system where it's too easy to make exploits, but this isn't a multiplayer game, either.  And my point was that a neutered spoiler could be used to bypass a system which required you to fire missiles at a hostile target if firing was all that was required. 

Quote
The issue of fake wars and crew grade is a big one in Starfire so I'm familier with what can be abused but I still think the current system is in dire need of a good (or Good and KISS) suggestion on how best to implement a better solution.
I think our best bet is to base it on damage to hostile ship targets.  It's hard to fake that, and with a bit of careful design, gaming the system will be limited and come with tradeoffs.  You can get XP by shooting up the civilian fleet of the people you're conquering, but then you won't get it when they surrender, for instance.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on June 07, 2016, 10:50:38 AM
But if you base it on damage dealt, carrier crews will never get anything.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on June 07, 2016, 10:58:44 AM
But if you base it on damage dealt, carrier crews will never get anything.
That's a necessary consequence.  Also, carrier crew training is somewhat less important than fighter crew training anyway.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Paul M on June 08, 2016, 09:09:53 AM
Basing it on damage dealt also precludes point defence ships for the most part.  And speaking from experience the escorts might infact play critical roles in combat.

The system is Starfire Assistant basically rates the intensity of the combat and then rolls to see if the crewgrade improves.  The SM decides on the intensity based on the battle in question.  I don't see how this could be 1:1 brought over though.

Carriers can be handled in that the mothership gets training based on the damage the fighters based on it do.

Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on June 08, 2016, 09:43:25 AM
Basing it on damage dealt also precludes point defence ships for the most part.  And speaking from experience the escorts might infact play critical roles in combat.
I was assuming (but didn't state) that killing missiles would also count.  Probably on a flat points per missile kill basis for reasons of simplicity.

Quote
The system is Starfire Assistant basically rates the intensity of the combat and then rolls to see if the crewgrade improves.  The SM decides on the intensity based on the battle in question.  I don't see how this could be 1:1 brought over though.
I don't think it can at all.  Aurora doesn't do discrete combat, and human judgements need to be removed where possible.

Quote
Carriers can be handled in that the mothership gets training based on the damage the fighters based on it do.
How and why, though?  First, carrier crew training doesn't seem to do all that much (although I admit to not using carriers that much).  Second, this doesn't make much sense.  How does the fighters attacking make the carrier better?  Third, fighters aren't permanently attached to motherships in a way that makes this sensible.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Paul M on June 09, 2016, 02:40:05 AM
The fighters assigned to a mission are launched from a mothership, the game knows which mother ship that was.  The carrier crew grade I assume speeds up re-arming and repair.

As to how to give out the points...base it on the fact the fighters were in combat and then give a flat point value per fighter reflecting the "ground crew" pre-launch and post-recovery activities.  Basically something like a CV launches 60 fighters in a strike...they launch missiles and damage something or another and return to the carrier to rearm.  The carrier gains (on landing) 60*(x) points of crew grade.  What (x) should be I've no real idea. 

Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on June 09, 2016, 02:58:58 AM
Is loading/rearming fighter in combat any different than doing it and then having the fighter fire on note live targets?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on June 09, 2016, 09:43:53 AM
The fighters assigned to a mission are launched from a mothership, the game knows which mother ship that was.
But we don't have 'missions' per se.  What if the fighters weren't assigned to the ship they launched from?  What if I had a specialized FARP carrier that cycled fighters through?  What about the ship they recover to?
Quote
The carrier crew grade I assume speeds up re-arming and repair.
I'm not sure of that, actually.

Quote
As to how to give out the points...base it on the fact the fighters were in combat and then give a flat point value per fighter reflecting the "ground crew" pre-launch and post-recovery activities.  Basically something like a CV launches 60 fighters in a strike...they launch missiles and damage something or another and return to the carrier to rearm.  The carrier gains (on landing) 60*(x) points of crew grade.  What (x) should be I've no real idea.
You'd have to be careful to make sure that only fighters which actually did damage give the bonus.  Otherwise, you get slightly absurd cases where one fighter in a wing engaged an enemy and the bonus is based on the whole wing.  Also, you'd want to normalize by the size of the carrier wing so that big carriers don't overpower smaller ones.  (This is also a problem with regular ships, actually.  It would make sense to at least somewhat normalize the damage done by crew size when determining training gain.)

Is loading/rearming fighter in combat any different than doing it and then having the fighter fire on note live targets?
That's another reason not to worry about it.  It's a lot easier to simulate rearming under combat conditions than it is to simulate actual combat.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on June 10, 2016, 04:19:41 PM
Intelligence: Alien Turret Contacts.
Make it possible to determine if, how many, and how big turret emplacements are on vessels. However, to be even to see them first, they need to be visible as if they were a ship of the same size at it's position. For instance, a resolution 20 sensor would see a 20 HS turret out to it's max range, but would need to be closer to see a 10 HS turret. The game, however, won't tell us what kind of turret, how fast it goes, or it's armor based on this info, just the size and quantity.
When a turret has a contact designated as a target however, if the turret is seen by active sensors, the active sensors will report the turret's tracking speed, up to the speed of it's target. For instance, if a 12,000 km/s turret is tracking a 6,000 km/s target, intelligence will report the "Estimate Tracking Speed" of the turret to be 6,000 km/s, until it tries tracking something faster.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on June 15, 2016, 12:14:22 PM
Quote from: iceball3 link=topic=8107. msg92413#msg92413 date=1465593581
Intelligence: Alien Turret Contacts.
Make it possible to determine if, how many, and how big turret emplacements are on vessels.  However, to be even to see them first, they need to be visible as if they were a ship of the same size at it's position.  For instance, a resolution 20 sensor would see a 20 HS turret out to it's max range, but would need to be closer to see a 10 HS turret.  The game, however, won't tell us what kind of turret, how fast it goes, or it's armor based on this info, just the size and quantity.
When a turret has a contact designated as a target however, if the turret is seen by active sensors, the active sensors will report the turret's tracking speed, up to the speed of it's target.  For instance, if a 12,000 km/s turret is tracking a 6,000 km/s target, intelligence will report the "Estimate Tracking Speed" of the turret to be 6,000 km/s, until it tries tracking something faster.
Interesting thought, but how would you justify that? It doesn't feel as if Aurora sensor technology could give us that level of intelligence.  I mean, how could you know the tracking speed of a turret?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on June 15, 2016, 01:21:04 PM
Interesting thought, but how would you justify that? It doesn't feel as if Aurora sensor technology could give us that level of intelligence.  I mean, how could you know the tracking speed of a turret?
Maybe something along the lines of the fact that the turrets spin so fast, the tidal forces could register a contact signature?
Yes, very jargony and not accurate to science I guess, but...
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on June 15, 2016, 02:02:18 PM
Quote from: iceball3 link=topic=8107. msg92622#msg92622 date=1466014864
Maybe something along the lines of the fact that the turrets spin so fast, the tidal forces could register a contact signature?
Yes, very jargony and not accurate to science I guess, but. . .
Ooh, the scientific realists on the forum aren't going to like that one!
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on June 16, 2016, 02:41:18 AM
The ability to flag certain characters as "important" would be nice, so that I can come back to them when I have thousands of officers to manage. I've been doing it at the moment by creating "dynasty" medals and handing them out to people I want to track.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on June 16, 2016, 03:24:21 AM
That, and an ability to see dead characters...
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Herodotus4 on June 16, 2016, 08:47:56 AM
How about the ability to put shipyards, fighter factories, construction factories, ordinance factories and maybe even reasearch labs on big civilian ships: I want to build a totally nomadic race.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Erik L on June 16, 2016, 08:54:05 AM
That, and an ability to see dead characters...

Ustabe there. Taken out because it was too much clutter if I recall.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on June 16, 2016, 10:58:54 AM
Interesting thought, but how would you justify that? It doesn't feel as if Aurora sensor technology could give us that level of intelligence.  I mean, how could you know the tracking speed of a turret?
Doppler.  Just look at how fast the turret is turning.  They can do quite a bit of this kind of stuff with radar today.  No need to get complicated.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on June 16, 2016, 01:15:41 PM
How about the ability to put shipyards, fighter factories, construction factories, ordinance factories and maybe even reasearch labs on big civilian ships: I want to build a totally nomadic race.
I think it would be hard to get the game balance right on this. A lot of the game is about logistics, and ordinance factory ships, for instance, would be a dramatic change. There is no such thing as a supply line if you can move your entire military infrastructure on demand to the battlefront.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on June 16, 2016, 01:19:00 PM
Doppler.  Just look at how fast the turret is turning.  They can do quite a bit of this kind of stuff with radar today.  No need to get complicated.
Really? You're the expert on such things, so I guess that's something else I can chalk up to how amazing technology is these days. In that case adding turret tracking speed to intelligence reports seems very reasonable.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on June 16, 2016, 01:27:00 PM
RE: mobile industry, we're getting there. A big bottleneck was the way to code was stuctured in the VB6 version, but the new  C# version should let Steve do it. Also logistics will always be an issue, unless you want your mobile factory to be shot down.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on June 16, 2016, 02:40:06 PM
Really? You're the expert on such things, so I guess that's something else I can chalk up to how amazing technology is these days. In that case adding turret tracking speed to intelligence reports seems very reasonable.
Pretty much.  They do clever things like identifying ships based on doppler resulting from their roll (inverse synthetic aperture radar, where you basically build a profile of the ship from slices, working out the height of each slice from the doppler) and identifying aircraft from blade count in their turbines (non-cooperative target recognition).  Suggesting that you could work out how fast a turret could turn is not beyond the realm of possibility.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on June 17, 2016, 08:58:42 PM
I want SBMHAWKs
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on June 17, 2016, 09:40:24 PM
I want SBMHAWKs
That is a thing. Make a less than 1000 ton "ship" design with nothing but box launchers filled with missiles that are equipped with active sensors (and a fire control). Have a ship with hangars deploy the "pods" and jumps them (they can jump using another ship's jump drive), have them launch the missiles at a waypoint close to JP as they come in, and the missiles will seek out enemy ships in their range. A perfectly viable tactic and design already possible in game.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on June 17, 2016, 10:36:41 PM
That's an interesting idea. I rushed max jump efficiency in my game so it should be doable right now with the tech that I have.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on June 17, 2016, 10:58:47 PM
That's an interesting idea. I rushed max jump efficiency in my game so it should be doable right now with the tech that I have.
The 1000 ton pods don't need jump drives. Any ship with a large enough jump drive acts as a Jump Gate when parked on a jump point (up to the max jump size of course). And the squad size is only for squadron jumps, so you can jump as many pods through as you want with the standard jump.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on June 17, 2016, 11:54:43 PM
My efficiency rating's at 25, so personally I'd rather make pods that don't require the launcher to be directly ontop of a hostile jump node.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Ostia on June 18, 2016, 07:08:41 AM
Since Steve is messing around with the Name Themes:

Can the Themes be separated from the DB? So we simply have 4 more sub-folders : Class Names, System Names and a Rank Names and People Names.

The first 3 are as usual: Filename.txt with one entry per line. The Filename is what shows up as the the Theme name.
The names are as following: FilenameM.txt, FilenameF.txt and FilenameS.txt. Male names, female names and surnames.

This would make Theme management far easier and unburden the db a bit. Only downside I am seeing is a light increase on start up time for file reading.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on June 20, 2016, 09:53:13 AM
Thinking about the turret ID thing more, I'm not sure it makes sense to have the turret have the same size as its MSP.  Classifying things requires having a resolution significantly greater than their size.  Detecting that something is there is often easier than working out exactly what it is.  A good rule of thumb is 3 to 4 pixels is necessary to do anything, so treating the turret as having a third to a quarter of its MSP is probably adequate.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on June 20, 2016, 02:39:20 PM
Thinking about the turret ID thing more, I'm not sure it makes sense to have the turret have the same size as its MSP.  Classifying things requires having a resolution significantly greater than their size.  Detecting that something is there is often easier than working out exactly what it is.  A good rule of thumb is 3 to 4 pixels is necessary to do anything, so treating the turret as having a third to a quarter of its MSP is probably adequate.
Missile Size Points? I'm having a hard time grasping what you're trying to communicate. Most ship components are measured in Hullspace, and overall ship size is often in that granularity, except for fighters.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Soralin on June 21, 2016, 06:28:07 AM
An indicator on the system survey data chart/screen that the body has had a ground survey performed.  Once you abandon the "colony" it becomes increasingly difficult to remember which bodies you surveyed with a geoteam.  This could be something that shows up in the lower window when you click on a body rather than an additionaly column.
Yes, this please.  For instance, in the F9 system display, where (blank)/S/M indicates survey+minerals status, add 'G' to flag ground survey completed (supersedes 'S') would be very helpful.
This would also be useful to add to the geological survey report screen, along with a way to filter results for surveyed/unsurveyed objects.

The geological survey report in general could use a couple of improved search options, like specifying minimum accessibility/amount for additional elements, or being able to search or sort by the total (sum) of accessibility of elements.

Also, given that mines will mine all elements, it would make more sense for the Total row on the mining screen to give the sum of accessibilities for the object, rather than the average.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on June 21, 2016, 09:37:43 AM
Missile Size Points? I'm having a hard time grasping what you're trying to communicate. Most ship components are measured in Hullspace, and overall ship size is often in that granularity, except for fighters.
I meant HS, not MSP.  I don't know why I typed MSP.  Oops.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Paul M on June 21, 2016, 10:00:49 AM
What would be useful is if the "formation editor" allowed for the distance 5,000 km as the minium interval.  So I can tell a ship be 5,000 @ 30° from the protected ship as opposed to the current minimum interval of 10,000 km.

I would also suggest changing "Final Defensive Fire" to be at 10,000 km for a ship shooting at inbound missiles targeting itself but at whatever the the range to the ship being hit by missiles this 5 second turn for the other ships in the formation.  So a ship 20,000 km away will engage the missile hitting its consort but at a hit probability calculated by the range to the consort (in this case 20,000 km).  Based on what I saw this may be the way that Final Defensive Fire is working but not having to pack all your ships into a sphere 10,000 km across with the primary target in the centre would make formations easier to use.

Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on June 21, 2016, 01:11:06 PM
What would be useful is if the "formation editor" allowed for the distance 5,000 km as the minium interval.  So I can tell a ship be 5,000 @ 30° from the protected ship as opposed to the current minimum interval of 10,000 km.

I would also suggest changing "Final Defensive Fire" to be at 10,000 km for a ship shooting at inbound missiles targeting itself but at whatever the the range to the ship being hit by missiles this 5 second turn for the other ships in the formation.  So a ship 20,000 km away will engage the missile hitting its consort but at a hit probability calculated by the range to the consort (in this case 20,000 km).  Based on what I saw this may be the way that Final Defensive Fire is working but not having to pack all your ships into a sphere 10,000 km across with the primary target in the centre would make formations easier to use.
Isn't that what Area Defense fire is for? It's less convenient than final fire, sure, but I guess that's the cost of positioning your ships that far from each other. Formations still have a use, at least, it's just harder to "final fire" for something so far away.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Paul M on June 22, 2016, 02:55:46 AM
Area Defense and Final Fire are two aspects of "point defense" but, I'm guessing due to programming issues, are split appart.

Area Defense requires the missile stop movement inside the range defined by the area defense value that 5 s turn.  It will not fire on a missile that passes through and impacts that turn.

Final Fire requires the missile impact that 5 s turn.  It will not fire on missiles that stop movement in range even when no impacts are occuring that turn.

This means in general you have to split your ships/mounts/weapons between the two setting depending on the situation.  This is ok to me because the alternative is to ask Steve to program an aegis missile defense system; I think the reasons to not ask for this don't need to be mentioned right?  I am also not sure "Final Fire" for supporting ships doesn't fire out either to the range you set and or the ships weapons max range as it stands now.  In which case nothing needs to be changed except making it easier to use the "formation editor" to bring ships into close proximity to provide mutual support by adding in settings for 5000 km and maybe some other values (eg 15 000, 25 000).  I can specify a follow range in 1K km intervals but the "formation editor" is limited to 10K steps.  And that is a bit too coarse.

Ships with a range of their point defense weapons of 30k km should be able to support other ships up to 30K km using "Final Fire."    As I say, I think that may be working.  What may "not be working" or "working as programmed" or "working as intended" is that mutual formation support may not happen.  So ships from 7th Squadron will support a ship in the 7th Squadron but won't support a ship from the 8th Squadron.  I will have a better idea what is happening as I review Jabberwocky during the write up this week but my first impression is that "final fire" support was only coming from ships in the same squadron.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on June 24, 2016, 01:55:47 AM
In the ship combat screen we have a way of marking ships that are presently targeted by either empire or task group, can we have a checkbox for contacts that aren't presently targeted but do have a volley of missiles already on an intercept course with them?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: linkxsc on July 01, 2016, 05:04:50 PM
Remove the +10 maneuver rating that all missiles have default. This will hit both ASMs and AMMs rather hard. As to be honest, when is the last time you actually put agility into a missile, AMM or ASM? Maybe set it to 1

As it stands, we all know that tiny missiles going as fast as possible are by far the best. Very often even in AMM designs, you don't even see the addition of maneuver until the mid-late techs, when the speed lost by adding a couple more points becomes worth it. I figure this is primarily because all missiles by default start with a fairly large bonus to this. 10 maneuver rating at mid techs is still .1msp saved on an AMM, for a literal 10x to their tohit chance. Hell I can't honestly say I've ever felt the need to apply maneuver to ASMs either.

I feel that a change like this might help to reign in AMM spam a bit and comparatively buff turret based defenses because of these.
1. Missiles will need be a bit slower to hit anything because of the need to actually install some maneuver (especially at low techs), making them easier to track.
2. AMMs will need to devote a larger portion of their space to maneuvering, while still probably being the most powerful due to reload rates.
3. Larger missiles might actually see a surge of usage, due to the extra space needed to get the hit% up, forcing designers to step up a size in missiles. The rare size 2 AMM would also likely see a surge in usefulness as for the same range and speed it'd have 2x the hit chance. (at 1/4th the spam)


I dunno, it's just a thought. But it's always seemed odd to me that you can literally get away with never putting points into maneuver until the end.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on July 02, 2016, 06:30:34 PM
Remove the +10 maneuver rating that all missiles have default. This will hit both ASMs and AMMs rather hard. As to be honest, when is the last time you actually put agility into a missile, AMM or ASM? Maybe set it to 1

As it stands, we all know that tiny missiles going as fast as possible are by far the best. Very often even in AMM designs, you don't even see the addition of maneuver until the mid-late techs, when the speed lost by adding a couple more points becomes worth it. I figure this is primarily because all missiles by default start with a fairly large bonus to this. 10 maneuver rating at mid techs is still .1msp saved on an AMM, for a literal 10x to their tohit chance. Hell I can't honestly say I've ever felt the need to apply maneuver to ASMs either.

I feel that a change like this might help to reign in AMM spam a bit and comparatively buff turret based defenses because of these.
1. Missiles will need be a bit slower to hit anything because of the need to actually install some maneuver (especially at low techs), making them easier to track.
2. AMMs will need to devote a larger portion of their space to maneuvering, while still probably being the most powerful due to reload rates.
3. Larger missiles might actually see a surge of usage, due to the extra space needed to get the hit% up, forcing designers to step up a size in missiles. The rare size 2 AMM would also likely see a surge in usefulness as for the same range and speed it'd have 2x the hit chance. (at 1/4th the spam)


I dunno, it's just a thought. But it's always seemed odd to me that you can literally get away with never putting points into maneuver until the end.
Maybe to add on to this, we could make the Maneuver Rating per 1 Agility worth of maneuver points to be calculated as MR = Agility/(Size^0.9), to make it so agility point devotion gradually becomes better on larger missile sizes? The main reason for this being a sort of economies-of-scale, combined with the fact that by making bigger missiles you're trading off a huge amount in the sense of firing volume.

I am a tad worried about the -10 base maneuver rating making fighters really really hard to hit with anything you throw at them, given a tech level, though.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: linkxsc on July 02, 2016, 09:39:37 PM
Maybe to add on to this, we could make the Maneuver Rating per 1 Agility worth of maneuver points to be calculated as MR = Agility/(Size^0.9), to make it so agility point devotion gradually becomes better on larger missile sizes? The main reason for this being a sort of economies-of-scale, combined with the fact that by making bigger missiles you're trading off a huge amount in the sense of firing volume.

I am a tad worried about the -10 base maneuver rating making fighters really really hard to hit with anything you throw at them, given a tech level, though.
Could be worth a try.
Though in the meantime changing missile armor so that it was worthwhile is also a thought.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on July 03, 2016, 04:47:45 AM
To be fair, making fighter harder to hit isn't a bad thing IMO. Right now, their only worthwhile use is to shoot missiles from out of detection range, or they get swatted like flies by AMM. It'd be awesome for fighters to be able to close in to beam range more easily.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: MarcAFK on July 03, 2016, 07:08:04 AM
Fighters could just get a boost to evasion, doesn't high grade or fighter combat bonus or something affect this?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Haji on July 03, 2016, 11:43:30 AM
when is the last time you actually put agility into a missile, AMM or ASM? Maybe set it to 1

I always put agility into anti-missiles. Just look at the chances to hit of those two, one which has as big an engine as possible, and the other having smaller engine but additional agility:

Code: [Select]
Missile Size: 1 MSP  (0.05 HS)     Warhead: 1    Armour: 0     Manoeuvre Rating: 10
Speed: 37400 km/s    Engine Endurance: 5 minutes   Range: 10.5m km
Cost Per Missile: 0.718
Chance to Hit: 1k km/s 374%   3k km/s 120%   5k km/s 74.8%   10k km/s 37.4%
Materials Required:    0.25x Tritanium   0.468x Gallicite   Fuel x50

Code: [Select]
Missile Size: 1 MSP  (0.05 HS)     Warhead: 1    Armour: 0     Manoeuvre Rating: 22
Speed: 28800 km/s    Engine Endurance: 5 minutes   Range: 8.8m km
Cost Per Missile: 0.8404
Chance to Hit: 1k km/s 633.6%   3k km/s 198%   5k km/s 126.7%   10k km/s 63.4%
Materials Required:    0.25x Tritanium   0.5904x Gallicite   Fuel x50

As you can see the second missile is much slower but has nearly twice the chance to hit. Both missile are made with ion engine level technology (basically everything that costs 10k RP or less have been developed) with the first one having engine size 0.78, 4X engine power while the latter has engine size 0.6, 4x engine power and 0.18 agility. The difference is massive.

I admit however that I rarely put agility into anti-ship missiles, as those are usually fast enough to have decent hit chances.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on July 03, 2016, 11:52:16 AM
As to be honest, when is the last time you actually put agility into a missile, AMM or ASM? Maybe set it to 1
Quite often.  My AMMs always get agility (and in fact, it was recently proved that you need quite a lot of agility in high-level AMMs.  Some of my ASMs get it, too, although not as much.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Paul M on July 04, 2016, 06:09:42 AM
I also use agility in both my counter missiles and especially in the anti-shipping missiles.  It makes a major boost in their base line effectiveness.

But one thing is that the speed of missile to speed of target isn't a linear relationship.  A very fast missile has a problem that the warhead is only effective at about 1 km (after that the plasma is probably to thin to do anything) so basically 1 km divided by the speed of the missile is the time the detection, and detonation system has to work.  Otherwise basically the missile detonates ahead of or behind the target.

In game terms this means up to a certain speed you should have a constant chance to hit (basically more about catching the target) and then after that the missile should start to fall off as it is too fast compared to the target. 

Unfortunately this is a major simplification of a complexer situation and I'm not sure what the exact mathematical relationship between chance to hit and missile speed should be.  But the relationship that is used now is appropriate only to tracking speed versus missile speed. 

At the end of the day I'm not wholey happy with the way it is done now, but I'm not sure what to suggest as an alternative.  I dislike the current system since it basically keys off "speed" and this results in a total distortion of the game around the question of speed.  At some point for missiles speed starts to be deterimental in reality.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on July 04, 2016, 07:09:50 PM
But one thing is that the speed of missile to speed of target isn't a linear relationship.  A very fast missile has a problem that the warhead is only effective at about 1 km (after that the plasma is probably to thin to do anything) so basically 1 km divided by the speed of the missile is the time the detection, and detonation system has to work.  Otherwise basically the missile detonates ahead of or behind the target.
It's a pretty trivial problem, all in all.  Modern engineering is capable of making systems that do just that on a daily basis, with a bit of predictive software.  Also, that's not how nuclear weapons work in space.  They do damage via X-rays, not plasma, and there isn't a hard limit on the range of their damage.  But given the consistency of the damage we see in the game, they're clearly detonating at a set standoff.

Quote
At the end of the day I'm not wholey happy with the way it is done now, but I'm not sure what to suggest as an alternative.  I dislike the current system since it basically keys off "speed" and this results in a total distortion of the game around the question of speed.  At some point for missiles speed starts to be deterimental in reality.
The only case I know of of speed being detrimental was the AA fire control system of Bismarck, which had a minimum speed that was faster than the speed of the Swordfish.  In practical terms, a faster missile is generally better.  Particularly because this is Aurora, and things don't have momentum like they do in real life.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on July 04, 2016, 07:33:28 PM
I want to be able to fit massive carronades into strike craft at later tech levels. Is there the possibility that carronades could be allowed to benefit from a size reduction tech the same way lasers do?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: linkxsc on July 04, 2016, 08:14:58 PM
The only case I know of of speed being detrimental was the AA fire control system of Bismarck, which had a minimum speed that was faster than the speed of the Swordfish.  In practical terms, a faster missile is generally better.  Particularly because this is Aurora, and things don't have momentum like they do in real life.
Well TBH, there isn't much that's slower than the swordfish.


But my point still stands, that missiles in general get FAR too much maneuver by default. And because of this, are also intrinsically much faster than they really should be, because it's better to max their speed bonus over putting stuff into agility.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on July 04, 2016, 11:17:45 PM
Well TBH, there isn't much that's slower than the swordfish.
There are lots of things slower than the stringbag, but very few are airplanes.

Quote
But my point still stands, that missiles in general get FAR too much maneuver by default. And because of this, are also intrinsically much faster than they really should be, because it's better to max their speed bonus over putting stuff into agility.
I wouldn't totally disagree with that.  But there's a difference between suggesting that we reduce the basic maneuver bonus and suggesting that faster missiles should have a lower chance to hit.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Haji on July 05, 2016, 12:46:48 PM
Currently CMCs are only being put on bodies with high accessibility duranium or sorium. What I'd love to see is for them to be put on any body with high accessibility minerals, even if those don't include duranium or sorium.

But my point still stands, that missiles in general get FAR too much maneuver by default. And because of this, are also intrinsically much faster than they really should be, because it's better to max their speed bonus over putting stuff into agility.

As I showed in my previous post agility is critically important for anti-missiles. They may not be as important for shipkillers, but isn't it fine to have a statistic useful for one type of ammunition and useless for other? I mean I use sensors on my missiles quite often, but I never put them on anti-missiles, so I'd say their fine.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: linkxsc on July 05, 2016, 04:37:45 PM
As I showed in my previous post agility is critically important for anti-missiles. They may not be as important for shipkillers, but isn't it fine to have a statistic useful for one type of ammunition and useless for other? I mean I use sensors on my missiles quite often, but I never put them on anti-missiles, so I'd say their fine.
True... But missiles don't start default with a sensor rating. If they did, AMMs would actually be quite a bit more effective, because if a salvo is destroyed, and the other salvos from other ships were close enough by, AMMs would redirect onto the other salvos. Effectively making the multiple AMM fire controls we regularly use worthless, as you'd just fire at 1 salvo and let the missile's onboard sensors handle it from there..
Meanwhile missiles start with a default maneuver rating, that at ion tech, would take about 20% of the missile to create, before adding agility after that.

Why should maneuver get a bonus. Missiles don't get free fuel, free armor, sensors, or warhead. Why then free agility?

I mean if missiles got a free sensor included, and this scaled with the missile size, then there'd be something to counter the bonus that AMMs get from all that maneuver. But there isn't.
And as it's been stated that tere are no plans to tweak the armor system to make larger missiles more practical. There must be SOMETHING to make it worthwhile to load a missile larger than size 6.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on July 05, 2016, 06:40:37 PM
Why should maneuver get a bonus. Missiles don't get free fuel, free armor, sensors, or warhead. Why then free agility?
They do, actually get free engine efficiency. To elaborate, a 1.00 multiplier on engine efficiency at MSP 5, the max missile engine size, and one fourth the size of the smallest engine drive, while also requiring no crew onboard.

And I also figure that the built-in maneuver rating DOES have some rationale. Specifically, the idea that missiles are fully-designed to intercept a target, whereas ships aren't, then missile would simply be ten times better than ships at doing so, at the least.

That, and I think you're overthinking the base maneuver rating as something "earned" or a "resource", rather than just "base chance for missile-like object to hit, without agility tonnage devoted beyond 'be a missile'".

I mean if missiles got a free sensor included, and this scaled with the missile size, then there'd be something to counter the bonus that AMMs get from all that maneuver. But there isn't.
A sensor being added just for it being a missile seems superfluous. There's already a reason to design really big missiles with sensor space heavily devoted; they're called buoys.

The argument "why don't they get free (other thing?)" should be looked over carefully, because the answer will likely be "because they'd change the function of the missile where it otherwise should've been optional".

And as it's been stated that tere are no plans to tweak the armor system to make larger missiles more practical. There must be SOMETHING to make it worthwhile to load a missile larger than size 6.
Shock Damage? Long Range missiles? Long Range MIRV-style short-range-missile carrier stage? Armor penetration? Mines? Sensor buoys?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Paul M on July 06, 2016, 08:06:41 AM
It's a pretty trivial problem, all in all.  Modern engineering is capable of making systems that do just that on a daily basis, with a bit of predictive software.  Also, that's not how nuclear weapons work in space.  They do damage via X-rays, not plasma, and there isn't a hard limit on the range of their damage.  But given the consistency of the damage we see in the game, they're clearly detonating at a set standoff.
The only case I know of of speed being detrimental was the AA fire control system of Bismarck, which had a minimum speed that was faster than the speed of the Swordfish.  In practical terms, a faster missile is generally better.  Particularly because this is Aurora, and things don't have momentum like they do in real life.

To answer the first point.  A nuclear explosion in space does not, and frankly cannot produce xrays in any large number.  This is because xrays are produced by atomic processes (the compton effect or bremstrallung) and in a vacuum there are no atoms to produce this effect.

That being said, it is possible to produce a nuclear device which converts some of its energy into xrays via a sacrificial "plate/sphere/etc" but this material exists for only microseconds before it is reduced to plasma by the conversion process itself.  This leaves you with a warhead that is fine for frying the crap out of russian or us ICBM guidance systems but which won't make a significant impact on the material struture of the missile.  The last is true so long as the range to the target is greater than a few hundred meters.  Xrays like any other form of EM radiation are governed by the inverse square law.

That law tells you very clearly what range the weapon has to detonate at to be at all effective against a structural material.  Xrays are absorbed inside of a few cm in a high z material and you have only microsecond or so of production so you need a lot of energy in there in the first place.  1000 m radius gives 6x10^6 m2 surface area.  If I say I want a MJ per m2 energy deposition (and that isn't outrageous) then I need 10^12 joules of xrays.   That is do-able with a megatonne scale nuclear device, which produces 10^15 J of energy; in general  0.1% converstion efficiency basically.  But if the warhead is 2 km away then the surface area grows to 10^7 m2 and by 10 km standoff range it is 6x10^8 m2 and now you are at 100% conversion and this is principly impossible.

I have done gamma-beta coincidence measurements with nano-second timing accuracy but the system for that is entirely hardware.  If I want a safety system with msec reaction times I also use hardware.  A fast boolean processor with a burnt eprom program (which is nothing more than AND/OR type logic) is still 1 msec reaction times.  Software is CPU cycle determined and usually is >>5-10 msecond.

For a missile moving at 50,000 km/s to arrive at <1 km from the target it needs a determination of its position relative to a moving target performed with a time acuracy of 20 microseconds and half that if the target missile is also moving at 50,000 km/s.  Per microsecond the missile detonates wrongly the target is 0.5 km further away from the desired inteval.  At a time error of 2 microseconds more likely then not you are outside of your engagement range.

I have no idea why you feel the bismark's guns have anything to do with missile on missile intercepts.  I said that the system we use now works fine for point defence.  Your chance to hit is fixed till the missile is faster than your tracking speed then it drops linearly with the target speed.  Missiles that are moving too fast compared to their target have the problem of blowing past them while the missile hardware is saying "blow up" the best thing is to match speeds, maneuver close and then detonate.  But for a counter missile it is nearly alway in a head to head engagement.

If the target is too slow the attacking missile can blow past it and explode too far away, if the target is too fast it can blow past the attacker and the the explosion is too far away.  For soft kills likely it is better to detonate before the target and let it do the work of passing through the shell of radiation and let its guidance system get fried.  My issue with the current system is that a very fast missile is always better.  And it scales with speed, so a 50K km/s missile engaging a 10K km/s missile gains x5 to its accuracy.  Why?  The fact that one missile is faster than the other has no advantage to facilitating the intercept outside of the question of doing it before the other missile hits its target.  The actual intercept is determined by how good the missile is at maneuvering into its attack position against the other missile, which is what missile agility is I would take a wild assed guess.  The speed of the two missiles should not matter and if it does matter it is as said above not clearly an advantage to be so fast that time jitter makes things harder for you.  Matching velocity would be best so that as far as the two missiles or missile and target are concerned they are stationary to each other.

Missile hit chance should be given by the attacking missiles agility only including anti-shipping missiles.  The speed then determines only if an intercept is over all possible or how hard it is for point defence systems to engage.  Speed should not be included in the tohit chance.  The idea I figure was to use "target speed" to mean target agility given as a ship looses engines it becomes easier to hit.  You could make it an agility to agility contest where either the missiles agilty is used or else some ratio of engine power to mass for the ship as its agility rating.

Fundamentally the current system is not consistent.  If you make the argument that you are talking about standoff detonation and the detonation is a trivial matter than the missile speeds don't matter at all.  A slow missiles warhead is not any different than a fast ones.  Yet the slower missile is at a disadvantage even though it nearly always involved in a head to head intercept, where what matters is the closing velocity and isn't important at all which of the pair moves at what velocity.  There is no mathematical difference between a 10K km/s missile intercepting a 50K km/s missile, a 50K km/s missile intercepting a 10K km/s missile and a 30K km/s missile intercepting a 30K km/s missile.  Those are mathematically identical situations, but the game strongly differentinates between them.  They are even more clearly identical if you say that the fuse issue is irrelevant and the standoff range issue is irrelevant.  In all cases then I can switch to a frame of reference where one missile is at 0 km/s and the other is at 60K km/s and from symetry I can swap which missile is stationary and the situation is again unchanged.

I also think from a game design point of view removing speed from the to-hit chance formula would be better as it would open up the missile design possibilities more.  More possibile missile designs would lead to more diversification.  Unless it is just then that people min-max around agility.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on July 06, 2016, 09:38:49 AM
To answer the first point.  A nuclear explosion in space does not, and frankly cannot produce xrays in any large number.  This is because xrays are produced by atomic processes (the compton effect or bremstrallung) and in a vacuum there are no atoms to produce this effect.
http://www.projectrho.com/public_html/rocket/spacegunconvent.php#id--Nukes_In_Space (http://www.projectrho.com/public_html/rocket/spacegunconvent.php#id--Nukes_In_Space)
Seriously, look these things up occasionally.  The X-rays are thermal, produced because a nuclear weapon gets really, really hot.  If you want a more through treatment, try 'Effects of Nuclear Weapons'.

Quote
That being said, it is possible to produce a nuclear device which converts some of its energy into xrays via a sacrificial "plate/sphere/etc" but this material exists for only microseconds before it is reduced to plasma by the conversion process itself.  This leaves you with a warhead that is fine for frying the crap out of russian or us ICBM guidance systems but which won't make a significant impact on the material struture of the missile.  The last is true so long as the range to the target is greater than a few hundred meters.  Xrays like any other form of EM radiation are governed by the inverse square law.
I am aware of the inverse square law, which would also apply to your hypothetical 'plasma nuke'. 

Quote
I have done gamma-beta coincidence measurements with nano-second timing accuracy but the system for that is entirely hardware.  If I want a safety system with msec reaction times I also use hardware.  A fast boolean processor with a burnt eprom program (which is nothing more than AND/OR type logic) is still 1 msec reaction times.  Software is CPU cycle determined and usually is >>5-10 msecond.
And the guidance system couldn't be hardware why?

Quote
I have no idea why you feel the bismark's guns have anything to do with missile on missile intercepts.
I didn't want to say that there was absolutely no case where more speed was not harmful, but it is vanishingly rare. 

Quote
I said that the system we use now works fine for point defence.  Your chance to hit is fixed till the missile is faster than your tracking speed then it drops linearly with the target speed.  Missiles that are moving too fast compared to their target have the problem of blowing past them while the missile hardware is saying "blow up" the best thing is to match speeds, maneuver close and then detonate.  But for a counter missile it is nearly alway in a head to head engagement.
The missiles are trans-newtonian.  This means, among other things, that they can slow down arbitrarily if they need to.  I'm usually not the one to say this, but current physics doesn't really apply here.

Quote
Yet the slower missile is at a disadvantage even though it nearly always involved in a head to head intercept, where what matters is the closing velocity and isn't important at all which of the pair moves at what velocity.  There is no mathematical difference between a 10K km/s missile intercepting a 50K km/s missile, a 50K km/s missile intercepting a 10K km/s missile and a 30K km/s missile intercepting a 30K km/s missile.  Those are mathematically identical situations, but the game strongly differentinates between them.  They are even more clearly identical if you say that the fuse issue is irrelevant and the standoff range issue is irrelevant.  In all cases then I can switch to a frame of reference where one missile is at 0 km/s and the other is at 60K km/s and from symetry I can swap which missile is stationary and the situation is again unchanged.
This isn't even remotely true in Aurora, because of TN physics.  Assume that the missiles have some low-level dodging programming, because it costs them trivial range, and they don't have to burn remass like real space missiles would.  Suddenly, which missile is faster becomes absolutely critical.  A 50K km/s missile can dodge approximately 5 times as far as the 10K km/s missile, or counter dodges much more effectively.  The 10K km/s missile can't really hope to intercept the 50K one, simply because it will spend too much of its speed countering dodging, and then the 50K one will be past.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on July 06, 2016, 03:34:46 PM
The idea of missiles committing to evasion makes sense, respective to mechanics, especially due to the fact that both missiles and full size ships have the same chance of getting hit by a particular missile, per their speed.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: sloanjh on July 07, 2016, 07:22:07 AM
Just a reminder that this is the main suggestion thread, which we probably shouldn't hijack for a big sub-thread on any one topic (so that other suggestions don't get lost if they're interspersed in the discussion, and so that it's easier for Steve to look for individual suggestions when he re-scans the thread.)

I suggest that if anyone wants to continue this conversation in detail then they start a side thread and refer to it here.  I also suggest that people be alert to the possibility of getting into this mode in the future, and start side threads pre-emptively if/when it looks like we're about to embark on a round of detailed back-and-forth.

In the past I've teased sub-threads like this out upon request, but that's a bit of a pain to do so I'd rather have the issue just solve itself in the future.

Thanks,
John
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: MarcAFK on July 07, 2016, 07:41:18 AM
I want to contribute, but Sloanjh is correct, if I wasn't on my phone I could quote all the relevent discourse into a new thread, I do agree with Paul M that a slight modification of missile intercept mechanics might be a good idea.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: linkxsc on July 07, 2016, 11:53:04 AM
Well with interception you want to be faster than the target, but not faster to the point that you cant maneuver to account for them.

Further, unlike ships, missiles have a single burn engine that cant be reignited. They can't stop abruptly like a ship can. Trans newtonian materials or not.

If only the hame accounted for interception speed and angle.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on July 07, 2016, 12:24:47 PM
I decided to put my reply in a separate thread, but during the course of coming up with it, I came up with an idea that deserves to be here, too:
It might be interesting to look at making missiles with agility bonuses slightly harder to hit, on the assumption that they're using their maneuvering systems to execute dodges at a level that isn't apparent on-screen.  The bonus shouldn't be as high as the to-hit bonus of the same amount of agility, but it would raise the utility of agility in ASMs.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on July 07, 2016, 08:01:54 PM
Only if a fraction of the salvo's fuel is removed every time it executes a successful dodge against an AMM.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on July 07, 2016, 08:08:17 PM
I thought it was assumed that the missiles were dodging inbounds, and the fuel cost of that was just ignored to avoid an annoying level of micromanagement.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on July 07, 2016, 08:38:19 PM
I thought it was assumed that the missiles were dodging inbounds, and the fuel cost of that was just ignored to avoid an annoying level of micromanagement.
I thought the incoming missiles were just falling off of target, not that the target was doing anything other than speeding directly at its own target. There wouldn't really be any micromanagement in having AMMs cause fuel damage to the salvo when they miss. The most you'd have to do is a few minor adjustments at the design phase, but that's not micromanagement.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on July 08, 2016, 01:55:36 AM
That's a neato idea actually. I like the idea that you might just drown the enemy salvo in low-tech AMMs to kill their range.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: sloanjh on July 08, 2016, 06:12:02 AM
I decided to put my reply in a separate thread, but during the course of coming up with it, I came up with an idea that deserves to be here, too:
It might be interesting to look at making missiles with agility bonuses slightly harder to hit, on the assumption that they're using their maneuvering systems to execute dodges at a level that isn't apparent on-screen.  The bonus shouldn't be as high as the to-hit bonus of the same amount of agility, but it would raise the utility of agility in ASMs.

Thanks Byron - here's a link: http://aurora2.pentarch.org/index.php?topic=8808.0
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on July 08, 2016, 10:44:50 AM
Only if a fraction of the salvo's fuel is removed every time it executes a successful dodge against an AMM.
I can't see a significant enough fraction being removed.  The time spent dodging is going to be fractions of a second, and unless there's some way to dramatically increase fuel flow during that time, that means you'll be losing fractions of a second worth of fuel.  The overall effect is so small it will be lost in the noise.

That's a neato idea actually. I like the idea that you might just drown the enemy salvo in low-tech AMMs to kill their range.
I can't see you killing enough range without some rather dramatic reinterpretation of the current technobabble.  Where does the fuel go?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on July 08, 2016, 10:54:36 AM
The fuel is expended avoiding AMMs. It's less that the fuel is destroyed and more that the missile is delayed by a few seconds by averting its course slightly and then put itself back on it again in order to avoid being hit.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on July 08, 2016, 11:53:38 AM
The fuel is expended avoiding AMMs. It's less that the fuel is destroyed and more that the missile is delayed by a few seconds by averting its course slightly and then put itself back on it again in order to avoid being hit.
I understand that.  The problem is that it's hard to justify evasion taking enough fuel to actually be worth tracking in-game, and really really hard to justify it taking enough to make attempting to run ASMs out of fuel worthwhile.  You're talking fractions of a second spent dodging, so unless you can burn fuel much more rapidly during that time, it's a rounding error.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Mngwa on July 12, 2016, 02:01:59 PM
No idea if these have been suggested before, but here's a couple leader related ideas:

1.  Retired/Dead leader temporary storage vault (. . . you can come up with a better name, but for me that sounds cool)
I haven't been playing Aurora 4x for long, but a little digging told me that apparently there used to be a tab for all dead officers, but it was removed.

Having a list (probably accessible from the main leaders window) that would include the name, history and basically everything else there is to know that could be known before death/retirement would really serve no gameplay purpose, but for increased depth and roleplay, I think it should be there.  I'm sure we all want to remember those officers who did something big or survived something dangerous.
Having this list store dead/retired leaders only for a set amount of time (let's say a year by default) and allowing the player to customize the amount of time their info is stored (to possibly help with any technical issues or in case some people who know they don't have a great memory can have more time to check their dead) would prevent the list getting too long and taxing.

From this list (or vault like I originally called it) there could be an option to permanently store an officer and maybe write them an epitaph (although they will probably wonder why are you writing one if they just retired) or a button to store the officer's info/history to a text file for later reading.

I have zero idea on how difficult that would be to implement, but there you go.



2.  Hospital/medical technology.
Pretty straightforward.  Lessen the chance of harmful medical conditions, increased natural life span, so your leaders will die less often.
Also maybe safety technologies to cut down the chance accidents? Gotta remember those seat belts.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Kytuzian on July 19, 2016, 01:55:19 PM
It would be pretty fantastic if we had a way to group together alien ships so that they didn't clutter the screen so many when in large groups. Additionally (or alternatively), it'd be nice to be able to simply collapse large groups of alien ships that are in the same position without having to set up groups for the aliens, again to remove some clutter from the screen. So if, for example, you had something like this:

(http://i.imgur.com/nMILasO.png)

It could collapse that group of civilian Fuel Harvesters to something simply like, "FH x9", and that group of spaceliners to "SS x15" (or however many there are), or, if both were in the same position, "FH x9, SS x15".
Title: Re: Semi-Official 7.x Suggestion Thread: Designing Star Systems
Post by: nafaho7 on July 19, 2016, 04:57:10 PM
The ability to build or design star systems in their entirety would make custom scenarios and maps very possible.

At present, if I want to use Aurora to make an interesting system map for another game, I have to either ignore the marvelous system maps, or keep hitting "Generate New System" until I get something close enough.

What I would love to be able to do is use Aurora to handle my star maps (and generate system summaries) for any of several pen and paper RPGs.  The present rules for maintaining different  map information for separate player races fits my needs perfectly, as I can simply update various dummy faction maps as different groups gather more information about the galaxy.

For bonus nostalgia points, this would touch on Aurora's roots in Starfire Assistant, serving as a player aid for arbitrary set-ups and games.

I can already connect systems to other arbitrary systems, and generate populations, installations and ships to make a system map interesting, and this would make my Rogue Trader game simply awesome.  I'll be able to keep track of known Warp travel routes by adding jump points, and only revealing the connections to other dummy factions at my discretion.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on July 19, 2016, 05:51:08 PM
It would be pretty fantastic if we had a way to group together alien ships so that they didn't clutter the screen so many when in large groups. Additionally (or alternatively), it'd be nice to be able to simply collapse large groups of alien ships that are in the same position without having to set up groups for the aliens, again to remove some clutter from the screen. So if, for example, you had something like this:

It could collapse that group of civilian Fuel Harvesters to something simply like, "FH x9", and that group of spaceliners to "SS x15" (or however many there are), or, if both were in the same position, "FH x9, SS x15".

Go to the Contacts tab and click "Hide Active IDs".
Title: Re: Semi-Official 7.x Suggestion Thread: Designing Star Systems
Post by: Steve Walmsley on July 19, 2016, 05:52:17 PM
The ability to build or design star systems in their entirety would make custom scenarios and maps very possible.

At present, if I want to use Aurora to make an interesting system map for another game, I have to either ignore the marvelous system maps, or keep hitting "Generate New System" until I get something close enough.

What I would love to be able to do is use Aurora to handle my star maps (and generate system summaries) for any of several pen and paper RPGs.  The present rules for maintaining different  map information for separate player races fits my needs perfectly, as I can simply update various dummy faction maps as different groups gather more information about the galaxy.

For bonus nostalgia points, this would touch on Aurora's roots in Starfire Assistant, serving as a player aid for arbitrary set-ups and games.

I can already connect systems to other arbitrary systems, and generate populations, installations and ships to make a system map interesting, and this would make my Rogue Trader game simply awesome.  I'll be able to keep track of known Warp travel routes by adding jump points, and only revealing the connections to other dummy factions at my discretion.

I may add something on these lines for C# Aurora when I get to system generation.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Kytuzian on July 19, 2016, 07:24:58 PM
Go to the Contacts tab and click "Hide Active IDs".

Thanks, that helps, but I'm more talking about situations like this, where that option doesn't seem to do anything:

(http://i.imgur.com/u3DRVoF.png)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: DaMachinator on July 19, 2016, 09:45:30 PM
Construction times taking into account if you are building more construction yards simultaneously.
Title: Re: Semi-Official 7.x Suggestion Thread: Designing Star Systems
Post by: Sheb on July 20, 2016, 01:42:03 AM
I may add something on these lines for C# Aurora when I get to system generation.

Wow, awesome! Being able to edit bodies' orbital radius, mass and so on from the system page would be so cool.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: MarcAFK on July 20, 2016, 02:03:35 AM
I would welcome it, I spend hours generating systems trying to get one suitable for NPR or player controlled opponents.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Darkminion on July 22, 2016, 03:52:19 PM
No idea if these have been suggested before, but here's a couple leader related ideas:

1.  Retired/Dead leader temporary storage vault (. . . you can come up with a better name, but for me that sounds cool)
I haven't been playing Aurora 4x for long, but a little digging told me that apparently there used to be a tab for all dead officers, but it was removed.

Having a list (probably accessible from the main leaders window) that would include the name, history and basically everything else there is to know that could be known before death/retirement would really serve no gameplay purpose, but for increased depth and roleplay, I think it should be there.  I'm sure we all want to remember those officers who did something big or survived something dangerous.
Having this list store dead/retired leaders only for a set amount of time (let's say a year by default) and allowing the player to customize the amount of time their info is stored (to possibly help with any technical issues or in case some people who know they don't have a great memory can have more time to check their dead) would prevent the list getting too long and taxing.

From this list (or vault like I originally called it) there could be an option to permanently store an officer and maybe write them an epitaph (although they will probably wonder why are you writing one if they just retired) or a button to store the officer's info/history to a text file for later reading.

I have zero idea on how difficult that would be to implement, but there you go.



2.  Hospital/medical technology.
Pretty straightforward.  Lessen the chance of harmful medical conditions, increased natural life span, so your leaders will die less often.
Also maybe safety technologies to cut down the chance accidents? Gotta remember those seat belts.

I would love to see something like this as I feel it would be a boon for community games and AARs. I would also suggest to add ships to this as well. It would be nice if instead of saving 10k lines of events and swapping out stevefire.mdb backups to find a history of a ship/leader and what happened to them I could just bring up a list of dead/destroyed and view the info as if they were still active. In my current 6.43 game BGreman's aurora raw viewer has helped with this (at least while it still worked). Before updating things I can cut out lines pertaining to fallen leaders/ships and put them in a memorial list and it will have their entire history from commission date to their Nobel sacrifice during the defense of the Denver system. As of right now any chronicling of game histories is delegated to how many lines the event log holds or is dependent on if the player is recording events as they happen.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on August 03, 2016, 06:08:06 PM
Component Suggestion: Offender Field/Flak Field/Interfering Barrier/etc
A variant on the energy shield, which automatically engages detected targets in a certain range. It does this by storing up charges (like a shield), and doing beam damage to all targets, regardless of quantity, only if charge is available and consuming charge in the process. Does not protect from damage like normal shields. Should be big enough to be useless on fighters (10 HS per module perhaps?), and still emit EM fields that broadcast both their strength and effective range.

Techs:
Capacity Per Module: Amount of damage points stored per module on a ship. Similar to shield strength tech.
[Mechanic]: If an enemy ship closes in with a projected field, it only gets engaged as hard as any other missile, but every 1 point of damage consumes 10 points of charge in the field generator. Engaging with an energy shield consumes 20 points of charge per damage point, instead.

Regeneration per 300: Works like normal shields, how many points of charge are stored over time.


Fuel Efficiency: Like shield tech, reduces fuel usage.

Damage Per 5: The threshold in which this field cannot engage a target, based on how many times it was already hit by a field this turn. This applies across all field sources, but field sources engage targets in order of lowest Damage Per 5 to highest, so if you have three ships with DP5 1, 2, and 3 respectively, a target will be hit by the ship with 1 first, 2 second, and 3 third. This should be a steep tech, such that 3 DP5 should be roughly equal to ROF 6 gauss cannons in research points.
This means that a ship or missile will only be take as much damage as the highest tech field it's in range of every 5 seconds, regardless of how many ships it's in range of at the time.
Consideration: Allow fractions of DP5, so a DP5 of 0.25 would be lowest tech and only allow the field to engage a contact that hasn't been engaged by a field in the past 20 seconds.


Field Range: Distance from the parent ship the field extends out from the ship. 60,000 km should be the tech-equivalent of 60,000 km gauss. Being able to engage anything requires an active sensor contact, and ECM reduces the effective range.
[Mechanics]:The field only engages contacts that either ends their turn in the AOE, or missiles that attempt to hit the ship it's mounted on (like final fire (Self) defenses).


What's the purpose of this design? Mainly:
-To incentivize missile armor.
-To quelch or at least make-sane AMM spam against large ships.
-To allow a means of taking the edge off of extremely large, quantitous salvos, where fire rate of weapons becomes nearly irrelevant.
-To allow more fancy formation options, and to allow environments where beam weapons are the best answer as a result. For instance, a mothership that may be in the center of a great citadel-ish formation which would be a surrounding or directional arrangement of support craft mounting these fields. Actually, this sounds like an excellent idea for the swarm, too! Have the swarm queen be protected by such a formation. Giving them a capability like this sounds like pristine grounds to nerf their mesons back to sane levels (focusing tech 12 why oh why ;-;), and it'll also give them another unique output of damage that actually makes armor somewhat meaningful.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on August 04, 2016, 09:45:03 AM
Component Suggestion: Offender Field/Flak Field/Interfering Barrier/etc

[snip]

What's the purpose of this design? Mainly:
-To incentivize missile armor.
-To quelch or at least make-sane AMM spam against large ships.
-To allow a means of taking the edge off of extremely large, quantitous salvos, where fire rate of weapons becomes nearly irrelevant.
-To allow more fancy formation options, and to allow environments where beam weapons are the best answer as a result. For instance, a mothership that may be in the center of a great citadel-ish formation which would be a surrounding or directional arrangement of support craft mounting these fields.

I think those are very worthy goals, but the flak shield as you describe seems a complicated mechanic with some contradictions
- Is it targeted? (which it seems to be if it requires an active sensor contact), if so then why should it automatically hit? If not, then why doesn't it hit friendly ships and missiles in range also?
- The damage per five rule seems very complicated and difficult to predict

So I'd suggest a simpler mechanic for a flak field

Ionic field generator
A reformatted energy shield that creates a highly charged zone around a ship. When a physical target enters the field it will collapse, inflicting automatic damage on that target. Once discharged the field will require time to recharge, based on technology level and capacitor level. A newly activated field will also require recharge time to charge. The collapsing field will damage all targets within range, regardless of number. Please note that a charged ionic field will target all physical bodies within range, including friendly ships and missiles.

Techs: Recharge time and range, perhaps also with a slowly increasing damage (starts at 1, with maximum tech of 2 or 3).

So you have a weapon that can destroy any single wave of AMM missiles, but can be easily negated by armoured missiles or by multiple waves. And while active you can't fire any missiles yourself. You'll also want to turn it off before any fighters come in to dock. Should cause lots of additional "fun" with poorly trained fleets as blundering ship captains stray into range of each other. When attacking ion field equipped ships you'll need to use multiple smaller waves, which will of course allow traditional PD to be more effective, leading to a general nerf of small missiles.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on August 04, 2016, 11:37:14 AM
So, a missile-only shield?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on August 04, 2016, 11:42:02 AM
Er yes. That would be a considerably more concise way of saying it! Although I think the key would be to make it an AMM missile shield, while allowing AS missiles through. I guess you could do the same by adding in some sort of super armor with a minimum damage threshold, but that would also nerf small beam weapons.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on August 04, 2016, 11:54:17 AM
In fact, thinking about this, I think the reason why AMM missile spam is a problem, and why we don't see more large beam weapons is one in the same, that armor is ablative rather than (at least partially) absolute. If higher tech level armours (or a new type of shield) ignored the first point of damage then it would have a dramatic effect on game balance. I guess Steve has already gone some of the way with shock damage, which is a very cool mechanic, but I don't think that removes the sandblasting approach.

Any change like that would also entirely remove gauss cannon as AS weapons though*, and boost particle beams so a pretty big change.

*I'm not sure if that is a bad thing if that your point defense decisions become more complicated.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: lennson on August 04, 2016, 08:49:06 PM
Even with ablative armor (say damage of strength 1 is negated) there would still be the issue that anti-missile measures can be largely negated by simply putting all missiles into a "super" volley.

It seems like there should be some sort of defensive mechanic that prevents launching all missiles in a single volley from being ideal.


As has been suggested a form of area damage defensive measure is one approach.

An alternative is the idea of a "decoy" that would cause all missiles aimed at the ship to miss for one time increment. Think of the decoy as a flare that is expended to temporarily emulate the signature to the ship causing the missiles to target it instead of the ship. This would strongly encourage the use of multiple volleys since a ship can fully mitigate a small number of missile volleys aimed at it through the use of it limited number of decoys.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on August 05, 2016, 12:36:51 AM
Another thing could be a limit on the number of missiles that can be handled by a single fire control.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on August 05, 2016, 11:10:01 AM
In fact, thinking about this, I think the reason why AMM missile spam is a problem, and why we don't see more large beam weapons is one in the same, that armor is ablative rather than (at least partially) absolute. If higher tech level armours (or a new type of shield) ignored the first point of damage then it would have a dramatic effect on game balance. I guess Steve has already gone some of the way with shock damage, which is a very cool mechanic, but I don't think that removes the sandblasting approach.
Technically already exists, the Absorption Shields.
That said, I'm not sure if they actually still exist or not, they might've been removed.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on August 05, 2016, 02:07:36 PM
Technically already exists, the Absorption Shields.
That said, I'm not sure if they actually still exist or not, they might've been removed.
They're still in, you just have to get lucky with ruins or salvage a spoiler equipped with it.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on August 06, 2016, 04:45:38 PM
They're still in, you just have to get lucky with ruins or salvage a spoiler equipped with it.
Is it considered meta when you've set up a secondary layer of obsfucation within the first? Hah! Though, thanks for letting me know. Is there any information on the absorption shields specifically around? I'd like to know how they work and last I checked they weren't on the wiki.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Havear on August 07, 2016, 04:12:52 PM
Add gene-mod support for either individual poisonous gasses or them as a whole.  As it stands, besides the cost-benefit issue, gene-modding falls short in that it's often easier to terraform a poison gas out of an atmosphere followed by making it ideal. If a gene-mod to ignore poisonous gas(es) existed, it'd at least offer a very viable alternative in several cases.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on August 08, 2016, 01:27:38 PM
Another thing could be a limit on the number of missiles that can be handled by a single fire control.
I like this one.  It's quite realistic (up until fairly recently, this was a major limitation on naval SAMs) and it would cut the problem immediately.  It also fits the general principle of solving problems with the least new stuff possible.
Even better would be having the accuracy of missiles go down as more are stacked onto the same fire control.  Time-sharing the FC (different salvos linked to the same FC having different targets) might cut it even more, although this would muck up defensive AMM use considerably.

Even with ablative armor (say damage of strength 1 is negated) there would still be the issue that anti-missile measures can be largely negated by simply putting all missiles into a "super" volley.
How?  If I take 100 strength-1 AMMs but have ignore-1 armor, all of them will bounce off. 

Another solution is to add a mechanism for proximity kills.  Say that a sufficiently strong (4-9?) AMM warhead can do damage to other weapons in the same salvo as the target.  Suddenly a (probably ASM-sized) AMM can counter an arbitrarily-large salvo, and there's a serious motivation to go with lots of little salvos.  Again, no major new mechanics.
Edit:
Thinking proximity kills over more, I see a problem.  Allowing a missile that auto-kills a whole salvo is going to dramatically change the way the AMM game is played, and I'm not sure that's a good thing.  There are two ways to deal with this:
1. The warhead is not guaranteed to inflict proximity kills.  Instead, after the missile itself hits, there is a chance of a proximity kill on each missile in the rest of the salvo, based on warhead yield.  I'd have to run numbers before making a recommendation on the values to put there.
2. Increase the chances of a proxy kill based on how many missiles are in the salvo.  Assume that for (mumble mumble transnewtonian) reasons each salvo can only occupy a definite volume of space, which is larger than the damage radius of a typical weapon, but not hugely larger.  With a small salvo, the missiles are spread out, making it unlikely that more than one or two would be caught in a given weapon.  As more missiles are added, the chance of a given missile being caught in the radius goes up, although it's going to plateau at some point as the percentage of the space that the damage volume makes up.  (This can be somewhat modified by making the AMM smart and having it go after the densest part of the salvo.)

Edit 2:
Actually, I don't think 2 is necessary.  If the proxy kills are percentage-based, that provides all the incentive needed to avoid large salvos.  Let's assume that proxy kills first have to attack a missile using the normal rules before triggering the proxy effect.  (An alternative is to have them only attack by proxy, and give them a bonus to 'attack' necessary to trigger it.)  We have two options, both with the same probability of hitting:
A. A size 1 AMM.
B. A size 4 AMM with a 25% chance of proximity kill if it hits.
Let's say we choose between a single B and 4 As, options which should have equal cost.  (I'm assuming that all weapons hit.  Alternatively, assume I fired 1/PH of B and 4/PH of A.) 
If the target salvo is 5 weapons, A will kill 4, and B will kill one directly and one by proxy.  If it's 9, you'll see 4 kills by A and 3 by B.  Crossover is at 13, and above that, B gets more kills than A.  If we assume that above size 4, the scaling of proximity kills is linear with warhead size, you see the same effect.  Nonlinear scaling there is going to move equilibrium about some, but it's not hard to make a scenario where it's better to shoot current AMMs at small salvos and proxy-fused AMMs at big salvos.

This does bring up the launcher paradox.  At the moment, the launcher system has two separate linear scaling effects with weapons size, size of the launcher and time to reload, which means that the 'throw weight' (MSP/unit time) is inversely proportional to the size of the missiles being fired.  A 6-HS size-6 launcher is going to fire every 30 seconds (6 MSP/(30 seconds*6 HS) = 1/30 MSP/(HS*sec)) while a 1-HS size-1 launcher with the same tech fires every 5 seconds for 1 MSP/(5 sec*1 HS) = 1/5 MSP/(HS*sec).  I'm not sure that there shouldn't be some scaling, but the current setup is grossly against bigger launchers, and that probably plays into the reason AMM salvos are so powerful.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: lennson on August 08, 2016, 10:25:57 PM
Even with ablative armor (say damage of strength 1 is negated) there would still be the issue that anti-missile measures can be largely negated by simply putting all missiles into a "super" volley.
How?  If I take 100 strength-1 AMMs but have ignore-1 armor, all of them will bounce off. 

What I meant is that ablative armor armor doesn't encourage using multiple missile volleys. It would remain the case that the best way to get past an opponent's missile defenses is to throw all your missiles (which would of course need more damaging warheads) into a single volley.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on August 09, 2016, 10:34:00 AM
What I meant is that ablative armor armor doesn't encourage using multiple missile volleys. It would remain the case that the best way to get past an opponent's missile defenses is to throw all your missiles (which would of course need more damaging warheads) into a single volley.
True, but if you have to use ASM rather than AMM the absolute numbers of missiles in any volley will be much smaller, making current point defense more effective. It would also force a more realistic choice for players between AMMs that are only useful for missile defense (and targeting fighters/FACs that are too small for an absorption shield/armor) and ASMs that can also damage enemy warships.

It seems that this could be achieved by making absorption shields researchable for everyone?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on August 09, 2016, 02:03:44 PM
It seems like absorption armor would be enough.

Not clear how exactly you would design that mechanic though, would you gain one level of absorption every time you upgraded your armor tech?

Would absorption-1 armor stop every type of missile up to damage 4 where it gets two layers of penetration, or would it just linearly remove damage points from the missile?  I guess probably the latter, but it makes somewhat less sense in my opinion.

It seems like this would turn into a bit of a hassle for Steve to implement.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on August 09, 2016, 02:58:10 PM
How?  If I take 100 strength-1 AMMs but have ignore-1 armor, all of them will bounce off. 


What I meant is that ablative armor armor doesn't encourage using multiple missile volleys. It would remain the case that the best way to get past an opponent's missile defenses is to throw all your missiles (which would of course need more damaging warheads) into a single volley.
True.  But it does force a gap between AMMs and ASMs, and will usually drive up the size of the missiles required, both of which cut down on how many missiles can be flying at you.

That said, I still like proxy kills as a mechanism for controlling large salvos.  It doesn't render gauss weapons useless against other ships, and it breaks fewer things.
Other implementation thoughts:
Make the kill chance somewhat based on missile size (large missiles being more resilient).  This should provide some counterbalance against the trend towards small missiles.
Force a minimum size on the proxy warhead so you can't just load your size-1 AMMs up with proxy warheads at high tech levels.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on August 09, 2016, 03:40:53 PM
I don't see why a hard limit should be applied to technological progress, it seems to me that if you have the tech to make size 1 proxy-kill warheads then you should be allowed to.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on August 09, 2016, 04:38:20 PM
That said, I still like proxy kills as a mechanism for controlling large salvos.  It doesn't render gauss weapons useless against other ships, and it breaks fewer things.
Other implementation thoughts:
Make the kill chance somewhat based on missile size (large missiles being more resilient).  This should provide some counterbalance against the trend towards small missiles.
Force a minimum size on the proxy warhead so you can't just load your size-1 AMMs up with proxy warheads at high tech levels.
Great idea, here are two thoughts:

If you call it an EMP warhead then the proxy damage is actually damage to the missile control systems, so how about just varying the kill chance with armor? The better the missile radiation shielding (roughly speaking armor) the better the survival chance against the EMP pulse. That in turn favors larger missiles worth putting armor on. You could also hand wave a bit to say that larger missiles are more resilient as the controls are buried deeper, but that's a bit of a push.

Instead of making it a special proxy warhead, why not implement as a feature of all missile warheads, representing the natural EMP from the nuke going off, but with a sharply scaling effectiveness based on warhead strength (kind of like shock damage). The proxy kill chance could be the square of the AMM warhead strength for instance, so 1% for strength 1, but 81% for strength 9. That seems pretty fair as the EMP blast from the nuke gets bigger.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on August 09, 2016, 05:25:04 PM
I don't see why a hard limit should be applied to technological progress, it seems to me that if you have the tech to make size 1 proxy-kill warheads then you should be allowed to.
A fair point.  I tend to think out loud, although small proxy warheads do move the equilibrium towards smaller proxy missiles, which means that it's efficient to proxy-kill small salvos.  That may or may not be a bad thing.  If it is, a minimum size is important.

Great idea, here are two thoughts:

If you call it an EMP warhead then the proxy damage is actually damage to the missile control systems, so how about just varying the kill chance with armor? The better the missile radiation shielding (roughly speaking armor) the better the survival chance against the EMP pulse. That in turn favors larger missiles worth putting armor on. You could also hand wave a bit to say that larger missiles are more resilient as the controls are buried deeper, but that's a bit of a push.
Nuclear EMP is a result of interaction with a planet's magnetosphere, not something generated by a nuclear detonation in deep space.  I'm not sure if it would be possible to make a nuke generate an EMP on a meaningful scale in deep space, if for some reason you wanted to do that instead of killing your opponent with X-rays.
Actually, armor could be easily integrated.  Treat it as non-ablative against proxy kills, with the subtraction being equal to the MSP value of the armor.  So a missile with .25 armor is totally immune to a 25% proxy missile, except on a direct hit.

Quote
Instead of making it a special proxy warhead, why not implement as a feature of all missile warheads, representing the natural EMP from the nuke going off, but with a sharply scaling effectiveness based on warhead strength (kind of like shock damage). The proxy kill chance could be the square of the AMM warhead strength for instance, so 1% for strength 1, but 81% for strength 9. That seems pretty fair as the EMP blast from the nuke gets bigger.

Besides the fact that that's not how nukes work (I don't blame you for not know this, as nuclear effects are the area I'm familiar with where common knowledge is most wrong), I'd push very strongly for a cap on proxy percentage no higher than 50% (maybe 75%), and have the lethality scale inversely with yield above a certain point.  Under your math (and assuming that cost scales linearly with warhead yield), against a sufficiently large salvo (ignoring direct hits), a size-10 warhead is 10 times as effective per unit cost as a size-1.  Actually it's more so, because 100 1% hits will leave 36.6% of the targets intact vs 0% for the 100% killer.  In practice, direct hits will skew this somewhat in favor of the smaller missiles, but 100% is a very long lever, and should not be attainable.  More missiles in a salvo should always be worse for the defender, not something he's totally indifferent to, although I agree that the pendulum has swung too far in the opposite direction.  The reason for scale-down is to encourage medium-sized AMMs. 
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on August 09, 2016, 10:30:22 PM
I don't think it would be effecient to proxy kill small salvos if the missiles are overkilling their targets.  Still a waste of a missile.

On the other hand, you could probably achieve the effect you want just by making proximity kill warheads their own (heavier, more expensive) beast that essentially enables you to deter the use of large salvos.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on August 10, 2016, 09:51:38 AM
I don't think it would be effecient to proxy kill small salvos if the missiles are overkilling their targets.  Still a waste of a missile.
Sort of.  My point was that if we assume that missile cost is basically directly correlated with size, small proxy warheads change the balance between proxy kills and direct kills.  Let's assume we have a 25% PK warhead on a size-1 missile, which has 50% of the PH of an equivalent direct-kill missile.  In this case, the equilibrium salvo size for the proxy missile is 5.  If we raise the relative PH to 75%, then it drops to 2.333.  (That's not a typo.  Multiplying the numbers out, we expect .75 direct kills and .25 proxy kills per equivalent direct-kill hit).

Quote
On the other hand, you could probably achieve the effect you want just by making proximity kill warheads their own (heavier, more expensive) beast that essentially enables you to deter the use of large salvos.
I'm leaning towards that being a good idea.  Minimum warhead size of 1 MSP would be sufficient to mitigate the worst of the effects.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on August 10, 2016, 02:32:53 PM
Sort of.  My point was that if we assume that missile cost is basically directly correlated with size, small proxy warheads change the balance between proxy kills and direct kills.  Let's assume we have a 25% PK warhead on a size-1 missile, which has 50% of the PH of an equivalent direct-kill missile.  In this case, the equilibrium salvo size for the proxy missile is 5.  If we raise the relative PH to 75%, then it drops to 2.333.  (That's not a typo.  Multiplying the numbers out, we expect .75 direct kills and .25 proxy kills per equivalent direct-kill hit).
Thanks for the EMP in space correction, always good to learn new things. Guess we'll need to come up with a new technobabble name for Steve to use :-)

If you went with a dedicated PK warhead approach, what PK chance and direct damage numbers would you suggest for a minimum size 1 MSP proxy warhead?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on August 10, 2016, 03:23:00 PM
Thanks for the EMP in space correction, always good to learn new things. Guess we'll need to come up with a new technobabble name for Steve to use :-)
Best option there is probably enhanced-radiation weapons (neutron bombs).  A couple of US ABM systems used them, although I'm not 100% sure of the logic involved.
Note that the game uses enhanced-radiation to describe what are more accurately called salted weapons, and I'm not suggesting using the existing salted warhead rules for missile defense.

Quote
If you went with a dedicated PK warhead approach, what PK chance and direct damage numbers would you suggest for a minimum size 1 MSP proxy warhead?
A good question.  A minimum of maybe 10%, rising as you get better warhead tech.  Direct damage would be based solely on your existing warhead tech (maybe *0.5), but it's more or less irrelevant as you expect to mostly shoot at totally overwhelmed missiles.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on August 10, 2016, 03:56:31 PM
A good question.  A minimum of maybe 10%, rising as you get better warhead tech.  Direct damage would be based solely on your existing warhead tech (maybe *0.5), but it's more or less irrelevant as you expect to mostly shoot at totally overwhelmed missiles.
I think you'd need at least *0.5 damage modifier, otherwise you'd just make all your ASMs with dual purpose proxy warheads. 
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Bughunter on August 13, 2016, 08:57:54 AM
I used an empty troop transport to pick up some survivors and got life support failures. I think it would make sense to include unused troop transport and colonist capacity in the overcrowding check.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Kytuzian on August 13, 2016, 03:32:13 PM
I think you'd need at least *0.5 damage modifier, otherwise you'd just make all your ASMs with dual purpose proxy warheads.

It could also be similar to the enhanced radiation warheads. So you could decrease damage by half to double your proxy kill range (or maybe the number of missiles you can proxy kill), decrease it by a third to triple the range, et cetera.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on August 15, 2016, 06:07:19 PM
I'm not sure if this is already in the game, if it does I haven't witnessed it.

What I'd like to see is the chance for officers to be generated by combat. How it would work is that army/navy NCOs would become officers through actual battle experience. They'd have far higher starting skills, but they'd also be a lot older than your fresh academy recruits.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on August 16, 2016, 01:06:52 AM
That's actually nice!

Another thing I'd like is to stop officers from teleporting around. Maybe not force you to move them manually with shuttle but make them take a long time off-screen to arrive, to simulate them being underway.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on August 16, 2016, 09:13:56 AM
That's actually nice!

Another thing I'd like is to stop officers from teleporting around. Maybe not force you to move them manually with shuttle but make them take a long time off-screen to arrive, to simulate them being underway.
Perhaps it could be instant within a system, and impossible outside that? But even then there would be extra micro management as you'd probably want to carry spare officers around with every fleet, to prevent an accident removing a captain just before an important battle. 
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on August 16, 2016, 09:33:34 AM
Would be less of an issue if you have XO's on big ships.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on August 16, 2016, 01:40:02 PM
Would be less of an issue if you have XO's on big ships.
That's true.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: DIT_grue on August 17, 2016, 07:08:20 AM
Another thing I'd like is to stop officers from teleporting around. Maybe not force you to move them manually with shuttle but make them take a long time off-screen to arrive, to simulate them being underway.

This phrasing makes it sound like you've forgotten about the Commanders -> Assign to any Location and Population and Production -> Teams/Academy -> This Population Only checkboxes, since while they wouldn't satisfy your ideal scenario, they certainly "stop officers from teleporting around."
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on August 17, 2016, 07:18:07 AM
I did actually.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: DIT_grue on August 19, 2016, 07:45:29 AM
Beam Fire Controls assigned to Point Defence ought to choose their targets more intelligently at all. A whole cluster of guns should not be flailing away at a singleton when there are multiple-missile salvos in the same volley. Ideally there would be prioritisation taking into account the capabilities of the defending FCs and the weapons they control (e.g. a slow and short-ranged FC with multiple railguns shoots at the largest salvo because hits scored will be highly variable - it might miss everything, wipe out the whole lot, or anything in between - while a faster FC with a single twin laser turret picks off a salvo that was thinned out but not destroyed). But even if it continues to be a matter of each ship taking their turn, and each FC on that ship firing in turn, not obsessing over the first salvo on the list would allow killing more missiles.

The increased realism option would presumably be to organise what FCs are shooting at what targets then resolve the exchange, rather than resolving each FC in turn before letting the next one use that information to make its decision. It would be nice to be able to have a small number of FC reserved for swatting leakers, but that should probably be a single layer only (i.e. there's the standard intercepts, which might have five FCs firing at each salvo if there's enough of them, then you do the same sort of process to match reserve FCs to leaker salvos, but that's it and you don't get a third try). Perhaps it would also be a good idea to require a high tracking speed for a FC/weapon to be assigned as reserve, representing the necessary split-second reaction time to identify a missile that escaped destruction and then kill it. (Half the missile's speed? Equal? But if it's a decision made by the player setting PD modes the game can't know what will need to be intercepted. So just an additional targeting penalty for guns in reserve mode?)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: lennson on August 24, 2016, 10:57:01 PM
I was wondering why ships don't cost wealth to keep operational (think crew wages or in the case of a hive mind race food).

As it is a tiny population can keep an arbitrarily large fleet running provided there are the needed minerals for maintenance from auto mines.

I think it would make more sense that to support a fleet a reasonable economic base is need which would be best represented in a constant wealth cost. This cost for a ship could be proportional to the number of crew on the ship.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on August 25, 2016, 11:38:33 AM
I was wondering why ships don't cost wealth to keep operational (think crew wages or in the case of a hive mind race food).

As it is a tiny population can keep an arbitrarily large fleet running provided there are the needed minerals for maintenance from auto mines.

I think it would make more sense that to support a fleet a reasonable economic base is need which would be best represented in a constant wealth cost. This cost for a ship could be proportional to the number of crew on the ship.
I think the reason why ships don't run huge wealth upkeep costs is because constructing the ships themselves incur a significant wealth cost over time, and also the idea that running the crew is inexpensive compared to other expenditures, to the point of the fact that it isn't significant to any empire actually capable of building and maintaining a fleet.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on August 25, 2016, 02:54:21 PM
I think the reason why ships don't run huge wealth upkeep costs is because constructing the ships themselves incur a significant wealth cost over time, and also the idea that running the crew is inexpensive compared to other expenditures, to the point of the fact that it isn't significant to any empire actually capable of building and maintaining a fleet.
That isn't currently true though, so why should it be in the future? The US Navy budget for 2016 was about $160bn, with $46bn for personnel costs, and $50bn for operations and maintenance, so crew and running costs represents the majority of the US Navy budget. I guess you could argue that TN spaceships are exponentially more expensive to build than conventional warships, but is that true?

Probably more important IMHO is that Aurora doesn't have the necessary level of financial/economic detail to make wealth a major part of the game. I think you'd need variable tax rates at the least if ongoing costs became an important factor.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Sheb on August 26, 2016, 02:03:21 AM
Well, keep in mind that you can have ten millions workers mining ore for you without visible pay. The wage of a few scores of crewmen in comparison is insignificant.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: lennson on August 26, 2016, 12:49:03 PM
The lack of a wealth cost for running mines didn't seem like an issue to me since such large mining operations are going to pull up lots of conventional minerals. When sold to the civilian sector this would offset the running costs of the mines.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on August 28, 2016, 01:40:06 AM
Thanks, that helps, but I'm more talking about situations like this, where that option doesn't seem to do anything:
Maybe Steve can write an option for C# where those informations only show up as a PopUp when you MouseOver the individual dot?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ExChairman on August 30, 2016, 04:45:22 AM
Hospital ships: How about having these ships with replacement battalions on ship that will "heal" damaged units and then will get new replacements at a planet with ground force training facilities. As it is now they are more of a roleplaying element.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on September 01, 2016, 04:44:58 PM
It would be cool if upon the destruction of a shipyard, debris were to rain down on the planet it was based at and kill civilians in proportion to the mass of the shipyard.  Something similar to mass driver impacts.
Title: Re: Semi-Official 7.0 Suggestion Thread
Post by: bitbucket on September 02, 2016, 02:16:01 AM
Quote from: Nyvis link=topic=8107. msg87136#msg87136 date=1456241025
As a whole, I think terraforming could use more detailing for what happens once temperature and atmosphere concerns are addressed.  For example, atmosphere without an ecosystem could degrade with oxygen turning to CO2.  Pollution could also be an issue worth adding, requiring you to use terraforming installations and workers to remove dangerous gases from your otherwise breathable atmosphere.

I would like to see terraforming fleshed out a bit, even if it's just fluff that goes on automatically in the background.  For example, an indicator of the state of a planet's biosphere.  You can give a Mars-like planet an Earth-like atmosphere, but you're still going to have a planet of nothing but dead regolith and barren rock unless you gradually introduce life to it.  Building an ecosystem from scratch would have to start with basic pioneer plants like algae, mosses, and lichens to build up soil for more complex plants to grow in, which then allows for animals.

To keep a biosphere simulation fairly abstract, just break it down into a few categories:

Lifeless - The system body has never had life.  If left as is, it probably never will.
Microbial - Only single-celled lifeforms exist, either because conditions are too hostile for more complex forms, or there hasn't been enough time for it to develop further.
Simple - A limited biosphere of simple pioneer plants and small hardy animals exists.
Complex - A diverse, fully developed self-sustaining biosphere exists.

And some special cases for when things go wrong:

Degraded - The system body's biosphere has been significantly disrupted, perhaps from a natural disaster, minor xenoforming, or bombardment.  The biosphere may adapt and recover with time.
Dying - The system body's surface environment can no longer sustain its former biosphere, either due to stellar evolution shifting the habitable zone away, or because significant xenoforming has occurred.
Extinct - The system body once had life, but it has been extinguished.

On a lifeless world, once terraforming reduces the colony cost to, say, below 1, have the biosphere category change to Simple as organisms genetically adapted to the colonists' preferred environment are introduced.  After enough time at zero colony cost, further increase the biosphere category to Complex, simulating the colonists adding more advanced lifeforms to bring about ecological succession.

Handling alien ecosystems would be. . . somewhat less simple.  One species' ideal environment is another's horrible death.  We can see just from the examples our own Earth provides that life can take hold almost anywhere with an energy source and a fluid medium.  Perhaps the planet's biosphere could have tolerances and ideal conditions in the same way sentient races do, and if the environment is changed too much, the native life dies off, going through Degraded > Dying > Extinct as you terraform the planet away from its original conditions.  It would make for some delightful ethical dilemmas such as "that vital strategic planet with the methane/ammonia atmosphere is full of life, would you go ahead with terraforming and kill everything on it?" Conversely, finding a rare natural zero-colony-cost world would be all the more special if it also had a Complex biosphere on it, a true garden world.

You might also find Degraded, Dying, or Extinct worlds naturally too, with Dying/Extinct particularly around B/A/G-class stars nearing the end of their time on the main sequence, and Extinct worlds around red giants and white dwarfs.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Bughunter on September 02, 2016, 03:34:41 AM
It would be cool if upon the destruction of a shipyard, debris were to rain down on the planet it was based at and kill civilians in proportion to the mass of the shipyard.  Something similar to mass driver impacts.

I think mass driver impacts do this because the kinetic energy is large enough to make them cause damage even if they hit an unpopulated area. A shipyard would mostly burn up in the atmosphere and even if some pieces hit a city and people are killed it would not be effects that are noticable on a planetary scale.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: sloanjh on September 02, 2016, 07:08:36 AM
It would be cool if upon the destruction of a shipyard, debris were to rain down on the planet it was based at and kill civilians in proportion to the mass of the shipyard.  Something similar to mass driver impacts.

Looks like someone's been reading Honor Harrington recently :)

John
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on September 02, 2016, 11:08:08 AM
I think mass driver impacts do this because the kinetic energy is large enough to make them cause damage even if they hit an unpopulated area. A shipyard would mostly burn up in the atmosphere and even if some pieces hit a city and people are killed it would not be effects that are noticable on a planetary scale.
Well, Aurora seems to operate on a model where people are uniformly distributed over a planet's surface so that's unlikely.  I think it has more to do with the relative mass and velocity of the objects in question.  For that matter, there's no a priori reason to suppose a shipyard would fall out of orbit if it got destroyed.  The debris will mostly stay in orbit.  What does fall will be going more than two orders of magnitude slower than the slowest mass driver projectile, and will probably be lighter to boot.  Simple anti-meteor defenses would be enough, even if they have no in-game effect.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bitbucket on September 02, 2016, 12:24:42 PM
Quote from: byron link=topic=8107. msg96566#msg96566 date=1472832488
Well, Aurora seems to operate on a model where people are uniformly distributed over a planet's surface so that's unlikely.   I think it has more to do with the relative mass and velocity of the objects in question.   For that matter, there's no a priori reason to suppose a shipyard would fall out of orbit if it got destroyed.   The debris will mostly stay in orbit.   What does fall will be going more than two orders of magnitude slower than the slowest mass driver projectile, and will probably be lighter to boot.   Simple anti-meteor defenses would be enough, even if they have no in-game effect.

The energy of an impact generally increases with the mass of the impactor times the impact velocity squared.

While large objects falling at orbital speeds (10-15 km/s) is certainly still problematic, the atmosphere will slow it down quite a bit.

On the other hand, even a small object impacting at relativistic velocities can be a lot worse, and it'll just punch right through the atmosphere in a tiny fraction of a second.  That mass driver packet is coming in 100 times faster, but it's going to hit 10000 times harder than a similar mass freefalling from standard orbit.  This is why mass drivers are such a mainstay of science fiction; get a 50kg slug going fast enough and it can hit with the force of a nuclear weapon.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: MarcAFK on September 02, 2016, 12:48:51 PM
A 10 million ton shipyard coming down at orbital speed is'nt to be sneezed at however.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on September 02, 2016, 03:39:42 PM
The shipyards are built in large part out of TN materials, so as far as I know they don't actually orbit due to the nature of those materials.  They also probably wont readily burn up, since duranium is able to handle nuclear weapons to some degree.  Since they don't leave wrecks behind, I tended to assume that when destroyed they fell into the planet rather than sticking around in space like ships do.

Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on September 02, 2016, 05:03:36 PM
The shipyards are built in large part out of TN materials, so as far as I know they don't actually orbit due to the nature of those materials.  They also probably wont readily burn up, since duranium is able to handle nuclear weapons to some degree.  Since they don't leave wrecks behind, I tended to assume that when destroyed they fell into the planet rather than sticking around in space like ships do.
If they don't orbit, then wouldn't they float away from earth instead once they've lost their lock on their gravitational frame of reference? Assuming they weren't in Earth's path in it's revolution around the sun, that is.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on September 02, 2016, 07:30:26 PM
Depends on what percentage of them are made of TN materials.  Shipyards would be inclined to lag behind the earth as it orbited around the sun, but if they had enough run-of-the-mill material in them to overpower the drag from the TN materials then they would fall into the planet if they lost the power to maintain their altitude.  It wouldn't be feasible to keep them in a kinetic orbit because of all of the drag from the TN materials.

Personally I would prefer things work out in such a way that they fall into the planet because that is way cooler than just drifting off into space.

e: You could also argue that upon destruction they would break apart, and non TN chunks would fall into the planet while TN ones would pull away from the planet into space.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on September 03, 2016, 04:30:10 PM
I think it will be great, if construction and R&D output will count as some non-linear model. Linear output regularly provoke some strange effects, as nearly instantaneous construction and development cycles (new fire control or small engine model developed or constructed in 1 production cycle, that can be very short - I usually set it to 24 hours, for example, that is quite realistic and suitable on the other hand). I think it will be some "base time" for such processes, and pumping project with resources must change completion time in some negative power function, not a simple linear.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on September 06, 2016, 09:54:40 AM
The energy of an impact generally increases with the mass of the impactor times the impact velocity squared.
That would be the definition of kinetic energy, yes.

Quote
While large objects falling at orbital speeds (10-15 km/s) is certainly still problematic, the atmosphere will slow it down quite a bit.
As a rule of thumb, anything which has a lower sectional density than the atmosphere (10 tons/m2 for Earth) is going to reach the ground slowly.  Anything with a higher sectional density is going to reach the ground fast.

A 10 million ton shipyard coming down at orbital speed is'nt to be sneezed at however.
Why would it be coming down in one piece?  That's fantastically unlikely to occur as a result of getting shot at.  It's likely to remain in orbit initially, and come down in a rain of small pieces over a considerable period of time.

I think it will be great, if construction and R&D output will count as some non-linear model. Linear output regularly provoke some strange effects, as nearly instantaneous construction and development cycles (new fire control or small engine model developed or constructed in 1 production cycle, that can be very short - I usually set it to 24 hours, for example, that is quite realistic and suitable on the other hand). I think it will be some "base time" for such processes, and pumping project with resources must change completion time in some negative power function, not a simple linear.
I'm of two minds on this.  On one hand, what you say is true.  But it would be a tradeoff against micromanagement.  IRL, we'd have a lot more parallel projects running of different sizes.  Replicating this in Aurora would be annoying because you'd have to manage those projects.  I'd generally just headcanon it as 'this small FC was developed over the last few months in parallel with whatever the team was also working on'.  If necessary, wait a few months after you design it before you give it to the research team.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on September 07, 2016, 12:10:13 AM
Well, honestly, I'm not suffering from micromanagement. As a rule, I enjoy it. :D

But speaking about less peculiar gamers, if our goal is to minimize micromanagement horror, than it will be great to have some joint progects interface. For example, you can create some new ship class R&D joint project, fill it with specific projects of FC, weapon, radar, etc., select or deselect some colonies, that must participate in this joint project, and then quite simple algorithm can allocate labs, so that all specific projects will end virtually synchronous.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on September 07, 2016, 12:09:29 PM
Well, honestly, I'm not suffering from micromanagement. As a rule, I enjoy it. :D

But speaking about less peculiar gamers, if our goal is to minimize micromanagement horror, than it will be great to have some joint progects interface. For example, you can create some new ship class R&D joint project, fill it with specific projects of FC, weapon, radar, etc., select or deselect some colonies, that must participate in this joint project, and then quite simple algorithm can allocate labs, so that all specific projects will end virtually synchronous.
My goal is not to minimize micromanagement.  If I wanted that, I'd play something else.  My goal (which, so far as I've seen, is also what Steve does) is to balance micromanagement against enjoyment, and I don't think that setting it up so that you gain a significant advantage if you spend more time on your research lab allocation is a good example of that.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Thundercraft on September 19, 2016, 12:34:03 AM
...They [shipyards] also probably wont readily burn up, since duranium is able to handle nuclear weapons to some degree.  Since they don't leave wrecks behind, I tended to assume that when destroyed they fell into the planet rather than sticking around in space like ships do.

Good points.

...Personally I would prefer things work out in such a way that they fall into the planet because that is way cooler than just drifting off into space.

I also like the idea of them falling into the planet. Ships leave wrecks behind, which can be salvaged. I'd like to see destroyed shipyards deposit the TN elements used in construction (or at least a portion of them) onto the planet, where they can be mined.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on September 20, 2016, 06:08:29 PM
Some thoughts.

Now we have a situation, when:
1. There are so many different and effective types of battle ships, that any game AI would be miserable necessarily.
2. Missile Defence fire control is so smart, that Formation orders (one of the most beautiful game instruments!) are useless.
3. Jump points topology makes practically impossible for AI to operate on players communications.

Consequently, war in Aurora tends to become plain and one-dimensional (war-of-one-point-straightforward-task-force) at tactical level and boring at operational level.

So, some attempts to fix these problems and at the same time to make game more realistic and "intuitive measuring":

Ia. Strengthen main weapon (i.e. missile) damage effects and simplify their design. Missiles with such closing-in speed needs no warhead - they are their own WHs per se, and they must be crippling or killing for any ship, if they pass through active defence. This change will kill two birds. First, it will strengthen the role of active missile defence, making it mandatory for any main battle ship. Second, it will simplify missile design tasks for game AI, making it less miserable.

Ib. Strengthen fuel consumption of small and forced engines, and make engines forcing fully available at start to prevent miserable role of missile fuel tanks and, most importantly, to make light missiles suitable at close range only. It will prevent from not so effective, but very tiresome missile spam and, again, will make defence tasks more simple for AI.

Ic. No fire control must have 100% hit chance at once. It will approach to 100%, but never reach this point. And no fire control must have an ability to repeat fire only at intact targets at the same cycle of fire. The goal of this change is to make active defense to be disposed in depth mandatory. If our fire control at any reasonable conditions have a noticeable chance of miss, and, at the same time, any missile have a noticeable chance of oneshot kill, then you must have early warning and multilayer active defence. So, beautiful multilayer formations will live!

II. Strengthen stealth techs, but make it time-limited (fuel-burning, as shields, maybe, or simply limited with some tech-dependent timer). Maybe, in addition, make JP to have its own radius, to let these stealth ships to pass at nonzero distance at inbound (where it will be defence stations, ships or mines). It will make possible for well armed ships to pass through JP invisibly and to sneak at battle formations from any direction, attacking at close distance. No more absolutely safe and quiet rear star systems, defended with JP piquets-and-minefields. Less safe zone with one big radar. Again, war takes more tactical and operational depth with it. Even more need of deep formations, and most important - need for deep force deployment. Player must not only defend his main battle ships from sneak attacks, but also must defend his communications - must use patrols, convoys, trap ships.

Summary, these measures will force to use one or two main types of battle designs ("open" missile and stealth sneaking beam or kinetic), but gives no 100% warranty of success for each of them. Both these design types will be available for AI, and they don't need mandatory for any complicated timing of combined attacks, that will always be a weak point of AI - no, "sneak" groups can attack independently from "open" battle force and independently from each other too. So wining battles and campaigns against AI will be not a simple task and players will take their adrenaline systematically. At the same time, we will keep all splendid variety of Aurora weapon types, though their roles will be more specific.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Thundercraft on September 20, 2016, 10:37:08 PM
You do seem to bring up some good points, serger. Don't let me get in the way of arguing for making fleet combat more strategic and complex. However...

Ia. Strengthen main weapon (i.e. missile) damage effects and simplify their design. Missiles with such closing-in speed needs no warhead - they are their own WHs per se, and they must be crippling or killing for any ship, if they pass through active defence. This change will kill two birds. First, it will strengthen the role of active missile defence, making it mandatory for any main battle ship. Second, it will simplify missile design tasks for game AI, making it less miserable.

Sorry, but I'm afraid such a change would upset game balance. Already, missiles are so effective that (at high enough research) they largely leave other types of weapons behind. Aurora is already very missile-centric in comparison with other space 4x games. Do we really want to see even larger swarms of ASMs and AMMs, at the cost of making other weapons, like railguns and energy weapons, more obsolete?

If anything, I would suggest that missiles be nerfed slightly. (Or maybe give ships 1 point of damage absorption.)

This argument for missiles without a warhead has been suggested and hotly debated before, in other topics - in the AMM doesn't need warhead (http://aurora2.pentarch.org/index.php?topic=7000.0) topic, for one.

It was pointed out how missiles travel so fast that AMMs don't really need a warhead. The kinetic energy alone should very easily destroy a missile.

But then it was counter-argued:

Trying to fix the balance this way would promote smaller and even higher amounts of AMMs.

I would prefer going the other way around and giving ships with thicker armor 1 point of damage absorption so that AMMs don't scratch them.

Aurora doesn't need even smaller and more missiles going around IMHO.

Another words, we don't need to make missiles cheaper or more effective than they already are. If anything, we need to make missiles more restrictive.

Someone else pointed out that missiles probably do not actually collide with each other and the AMM just gets "close enough for the warhead to go off." Also:
...Trying to intercept something going 20000km/s while being relatively tiny is going to be very hard...
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on September 20, 2016, 10:50:57 PM
I'm not in total agreement regarding the stealth tech.  The ability to harry jump defenses is probably a good idea, to make it harder to make them a totally 100% impenetrable wall (per your 'nothing should be 100% certain' which I completely agree with), but letting stealth ships run blockades like that will just lead to dramatically increased micromanagement as you try to prevent stealth ships from sniping your assets deep within your empire.  Making players field that may formations seems like bad design to me.  Games would die from trying to keep everywhere properly defended, unless massively improved management tools came out with these changes.

Also, regarding high damage missiles, current missile gameplay would tend to lead to both combatants in any engagement getting reduced to debris as they launch sensor-equipped fire and forget missiles at each-other and then get ripped to shreds in a cloud of hundreds of nuclear detonations.  Shortening the engagement range per the increased fuel consumption wouldn't hugely effect this.

fake-edit: To help counteract the overpowered missles in comparison to other weapons, we could also beef up the other weapons.  I mean, sensors work at faster than light.  So do the aptly named FTL drives.  You could imagine some TN-beam that shoots faster than the speed of light and therefore can fire effectively over a much greater distance.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on September 21, 2016, 12:53:21 AM
I agree with both defined dangers, but I think there are some simple ways to neutralize these undesirable effects, and some of these ways are the same that I proposed already.

First, I have to notice, that my points I and II are in some way opposed already. First point is strengthening missiles, but second point is strengthening beam and kinetic weapons. You don't want to get your great missile ships to be butchered by some stealth sharks with big rude railguns! Missiles demand more time to get their targets even at point blank range, so, if you want to protect missile battle ships from sneak attacks, then you must equip them with defensive beam or kinetic weapon strong enough to kill or disable those sharks with one salvo. So, our main battle ships will be equipped with various weapon, and no weapon type will be obsolete.
As for balancing, relating to tech advance - it is a matter of tech advance only. Steve can fix it, regulating formulas of missile tech impact. My proposition only makes it more simple, because there would be fewer missile techs (I proposed to delete WH and Engine forcing techs), and so - balance with late game techs can become better even without such formula regulating. My thought is not to make missiles the only main weapon - it is to make all types of weapon to be mandatory, and in the same time - to make our beautiful battle formations alive.

As for micromanagement nightmare with deep operations - I agree with this objection more strongly. Maybe it will be too big problem. I need to try. Maybe it will be worth to add it as an option for the most micromanagement maniacal players, but I strongly want to try it.

And I have some more thoughts about ways of scaling down micromanagement workload, but these thoughts are rather unripe for now (in addition to a point, that it's hard to me to formulate my thoughts in English - I don't know even if all my ungrammatical statements are understandable at all; sorry for this disorder).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on September 21, 2016, 02:47:54 AM
I can more or less make sense of what you are saying without issue.

I will probably post something later, I need to go to bed.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on September 23, 2016, 07:31:11 AM
In "Fast OB Creation" adding an option to "Use Resources with OB Construction". It is fine that OB Creation does not use Resources while setting up a game; but at some point in the game it might be interesting to Add something afterwards which simply got forgotten during the setup. Having the option that this "Afterbuild" uses the actual resources (Minerals and Wealth) would be handy... .
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on September 24, 2016, 09:31:33 AM
Proceeding with a question of war at communications and following micromanagement nightmare - rose up to big and disputable separate post:
http://aurora2.pentarch.org/index.php?topic=9074.0
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on September 24, 2016, 10:33:20 AM
Use more random numbers of comets.
Add a check-box "Comets" in Display setup page (i.e. option to hide comets itself, not only comet paths).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on September 24, 2016, 11:15:39 AM
Some simple naming suggestions, partly touched in my big post, but partly different at all, and so - can be considered separately.
(RP-motivated only.)

Fighters (as type of hull design) - rename to small crafts (small-sized crafts?) or simply crafts.
Because there are not only fighters in this mass range. Fighters Factory - correspondingly.

Thermal Sensors - rename to TN-noise Sensors (Noise Signature correspondingly).
EM Sensors - rename to TN-pulse Sensors (Pulse Signature correspondingly).
Because there are not thermal and not EM (electromagnetic) - there are both FTL waves (while thermal and all EM emissions are light-speed emissions, and therefore cannot be seen by 5-sec pulse at more distance, than 5 light seconds = 1.5 mkm).

Geology - rename to Planetology (GEV to PSV).
2 reasons: 1st - "Geo-" is "Earth-" in latin, but our Geology vessels and teams must survey another planets; 2nd - Geology and Gravitational (GSV and GEV) are quite alike by cursory glance and it is easy to mix up.

Commanders - rename to Staff or Leaders.
Because there are not only commanders even at Naval Officers Leader Type page, and there are administrators and R&D staff there.

Scientist andResearch - rename to R&D.
Because there are not only science research there - bigger part of it is an engineering (development, not research).

Errmm... I don't insist, but. Marine - is for wet fleet (from latin "mare" - sea, seaside). And space fleet infantry is a Space Infantry.  ::)

Hide "-A" suffix for body names of one-component star systems (a "Sol", not a "Sol-A", etc.)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Kytuzian on September 24, 2016, 01:34:26 PM
Some simple naming suggestions, partly touched in my big post, but partly different at all, and so - can be considered separately.
(RP-motivated only.)

Fighters (as type of hull design) - rename to small crafts (small-sized crafts?) or simply crafts.
Because there are not only fighters in this mass range. Fighters Factory - correspondingly.

Thermal Sensors - rename to TN-noise Sensors (Noise Signature correspondingly).
EM Sensors - rename to TN-pulse Sensors (Pulse Signature correspondingly).
Because there are not thermal and not EM (electromagnetic) - there are both FTL waves (while thermal and all EM emissions are light-speed emissions, and therefore cannot be seen by 5-sec pulse at more distance, than 5 light seconds = 1.5 mkm).

Geology - rename to Planetology (GEV to PSV).
2 reasons: 1st - "Geo-" is "Earth-" in latin, but our Geology vessels and teams must survey another planets; 2nd - Geology and Gravitational (GSV and GEV) are quite alike by cursory glance and it is easy to mix up.

Commanders - rename to Staff or Leaders.
Because there are not only commanders even at Naval Officers Leader Type page, and there are administrators and R&D staff there.

Scientist andResearch - rename to R&D.
Because there are not only science research there - bigger part of it is an engineering (development, not research).

Errmm... I don't insist, but. Marine - is for wet fleet (from latin "mare" - sea, seaside). And space fleet infantry is a Space Infantry.  ::)

Hide "-A" suffix for body names of one-component star systems (a "Sol", not a "Sol-A", etc.)

While some of these I don't mind (TN-noise and TN-pulse), I have some points about both Geology and Marines.

1. "ge" is not Latin, it's Greek. It doesn't mean "Earth" it means "earth" or "land", so it's 100% valid to use for other planets. (https://en.wiktionary.org/wiki/%CE%B3%E1%BF%86#Ancient_Greek)
2. Even if it did mean "Earth", there's no reason we can't use it. Just because a word means something in the past doesn't mean that's its meaning now.
3. Marines are called marines for the same reason we use the word ship and not spacecraft. The terminology for almost all common space games is naval terminology--which includes Marines, not "Space Infantry."
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Thundercraft on September 25, 2016, 06:07:15 AM
Some simple naming suggestions...[snip]

These name change suggestions make a certain amount of sense. But Kytuzian had excellent counterarguments for a couple of them. Oh, and thanks to Warhammer 40K, I think the term "space marine" is mainstream - a part of pop culture. I've never played that, yet I know of it. For that matter, I'm pretty sure that I've heard of other media which reference marines in space.

Also, please consider that Aurora has been around for years. You want to change the names of all these things at this point? Players would have to un-learn these and memorize the new names. And if the wiki and existing forum guides and discussions are not updated with the new names, such changes could lead to confusion.

That said: Name changes that I would not object to are "R&D" and maybe "Small crafts, because they're obvious. Also, changing only one or two things does not add much confusion. Further, it sounds like your real objection to Geology is how GSV and GEV are easy to confuse. Instead of changing the name itself, perhaps Steve should alter the abbreviation for one of these?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on September 25, 2016, 09:06:34 AM
Abbreviations for hull types can be altered by player by adding hull types, though this is not very handy method now, because there is no way to remove unnecessary, dublicating hull types (as I understand - because many of these types can be used by NPR, so deleting can cause critical bugs).

As for marines - that suggestion was not serious.  :)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on September 25, 2016, 09:55:24 AM
Abbreviations for hull types can be altered by player by adding hull types, though this is not very handy method now, because there is no way to remove unnecessary, dublicating hull types (as I understand - because many of these types can be used by NPR, so deleting can cause critical bugs).

As for marines - this suggestion was nor serious.  :)

I will add an ability to change or delete hull types in C# Aurora.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on September 26, 2016, 10:12:02 AM
A suggested replacement for marines would be espatiers.  It's derived in the same way, from the French for the environment they work in.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Erik L on September 26, 2016, 10:24:23 AM
A lot of the names you use are not set in stone. You can change them as you wish.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on September 26, 2016, 11:25:57 AM
As for types of "ground" units - their abbreviations are set in stone (renaming procedure doesn't work for abbreviations), and so - radical renaming attempt causes total nonsense.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Erik L on September 26, 2016, 12:11:25 PM
As for types of "ground" units - their abbreviations are set in stone (renaming procedure doesn't work for abbreviations), and so - radical renaming attempt causes total nonsense.

I seem to recall you can rename those units. But then I'm also old and senile ;)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on September 26, 2016, 12:17:39 PM
I can rename units and types of units. But cannot rename their abbreviations. Renaming interface have a field for new abbreviation, not only new name, but abbreviation remains intact really.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: swarm_sadist on September 27, 2016, 07:12:38 AM
I can rename units and types of units. But cannot rename their abbreviations. Renaming interface have a field for new abbreviation, not only new name, but abbreviation remains intact really.

I'm pretty sure that changing the abbreviation comes right after changing the name. You input the name of the unit, hit enter, then input the abbreviation. Or do you mean existing units' abbreviation?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on September 27, 2016, 11:35:56 AM
Yes, It's true, changing the abbreviation comes right after changing the name! But abbreviation remains intact really, while full name  (of unit type) changes successfully. Change type name and abbreviation, build some units of this type - and you'll see units with new type name and old abbreviation.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on September 27, 2016, 11:41:12 AM
Just a small flavor thing I though of while watching a spectacular network of mass drivers. When an enemy is in orbit of either the launch point or destination of a mass driver package, there is a chance for the minerals to hit (this would naturally apply to your ships over an enemy world that fires/receives a mass driver package). Don't know the amount of damage it should do, but maybe it should be somewhere between 1:1 to 1:5 compared to the damage:tons.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on September 27, 2016, 01:01:39 PM
Just a small flavor thing I though of while watching a spectacular network of mass drivers. When an enemy is in orbit of either the launch point or destination of a mass driver package, there is a chance for the minerals to hit (this would naturally apply to your ships over an enemy world that fires/receives a mass driver package). Don't know the amount of damage it should do, but maybe it should be somewhere between 1:1 to 1:5 compared to the damage:tons.
Doesn't make much sense.  The mass driver package isn't going fast, and I think it has a beacon built in.  Dodging is easy, and wouldn't be visible at the level of granularity we have in the game.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: sloanjh on September 28, 2016, 07:18:57 AM
I'm pretty sure that I've heard of other media which reference marines in space.

Was it "Mariiiiiiiines in Spaaaaaaaace"? :)

John
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: boggo2300 on September 28, 2016, 05:23:34 PM
I'm pretty sure that was Piiiiiiiigs iiiiiiiinnnn Spaaaaaaaaaaaaaaace!
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: AbuDhabi on October 02, 2016, 07:17:42 AM
Here's a few:

How about an option to pause moon motion, but leave planetary motion on? After all, moons follow their planets around and have relatively tiny orbital diameters. It wouldn't break my suspension of disbelief any more than halting asteroids. :)

How about the ability to scrap PDCs, getting back some of the resources used to make them?

How about being able to chain up research in valid prerequisite order? I mean, to be able to say, up front, that you want to research, say, Mining Rate 500, then Mining Rate 600, then Mining Rate 720, etc, without having to use work arounds like top-queueing.

Actually not sure if this isn't in, but I haven't found it: How about ships being able to target their own current position/task group? For example, if I had a bunch of orbitals and tugs in the same Task Group, I would like to be able to select that in the location list, so that I could tractor the orbitals right from there.

Not so much a suggestion, as an inquiry: Is the database properly indexed? The other day at work, we had a major slowdown handling user requests, because there weren't proper indices in our database for the queries that the users were making. Adding them (an index each for every problematic query, with all the fields from the WHERE clause for that particular query) reduced request time by an order of magnitude.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on October 02, 2016, 04:54:57 PM
Some minor (or major) suggestions:
- It would be nice if we could choose which events do break the auto cycle
- when Leader Auto Assign is turned on there should be either an option to NOT scrap the unused officers OR get a list where you can confirm if you want to scrap them (also it might be handy if we could choose the length of the "scrap them after x years")
- choosing the name visibilty on the system map PER object or task group could be handy (I for one have a PDC_Group on every planet which I don't need to see the name of; I know it is there)
- having a general parameter which influences the population growth per game would also be nice. To me it feels like the pops are growing way to fast (at least for my playstyle)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: AbuDhabi on October 03, 2016, 03:07:08 AM
Ooh, ooh! Auto-assigning civilian administrators, please?

Or at least a specific event type that says "an administrator with an actual job died, please replace him", so it looks like something other than officer health update spam?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bitbucket on October 04, 2016, 11:52:14 AM
If we really want to go for accuracy here, maybe we could tweak Earth's initial atmosphere a little bit.

This is what we're actually breathing right now:

(https://s10.postimg.org/zb8qoxqjd/earthatmo.png)

It warms the planet 0.11° C but that really shouldn't matter, and human baseline tolerances don't need to be changed.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on October 04, 2016, 12:39:49 PM
A nice addition to the Auto-Assign Feature would be defining which type of leader a position should be filled with. The most automatic part is good, but there are several positions which are not filled by the automatic routine - obviously because the position can be filled with a different fitting variety of leaders, depending on taste. So why not giving a "job description" for those positions, so the auto routine can fill them according to the job description?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: alex_brunius on October 08, 2016, 11:25:32 PM
Why is it that mining is free without any cost to wealth? That doesn't make much sense IMO.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on October 09, 2016, 02:17:25 AM
Why is it that mining is free without any cost to wealth? That doesn't make much sense IMO.
Whats going to take payment, the planet? Seriously though, it does make sense because the mines are government owned, so they get a majority of the minerals extracted without needing to pay. This also helps to explain why civilian shipping lines don't use apparent minerals to build and why they pay you when they build ships. Because the numbers present in the geosurveys are representing the government share of the minerals.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on October 09, 2016, 05:03:44 AM
Increase a probability for any JP to open at more massive stars, not only closest ones.
Jump net maps with real stars option will be much more spectacular.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: alex_brunius on October 09, 2016, 11:38:07 AM
Whats going to take payment, the planet?

Generally speaking millions of people don't work for free  ;)

I just found it very inconsistent that having say 30 million workers mining don't cost any wealth at all, but all other manufacturing actions from F2 Summary ( except financial centers whose purpose is to generate wealth ) where people can be employed will cost you wealth.

Actually double-checking now it seems that Fuel Refinery Workers also work for free...

And it would also make sense if unemployed workers ( available workers ) generated less tax due to unemployment subsidies.

For consistency both Fuel refinery and mining workers probably should need wealth to operate.

are representing the government share of the minerals

It still doesn't make sense this would apply only to mining/fuel refineries. There must be civilian research and construction going on as well outside the government share to an equal degree that there is mining!
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: alex_brunius on October 09, 2016, 04:14:18 PM
Another idea.

It would be interesting to see a size/cost breakdown of category of systems somewhere in shipdesign. This I think also could help newer players create more balanced designs.

For example:

Offensive Systems: 20%   (weapons, active sensors, fc... )
Defensive Systems: 18%    (armour, shields, CIWS, passive sensors... )
Propulsion Systems: 31%  (engines)
Endurance Systems: 31%  (fuel, engineering, crew quarters... )

Or they could use the 5 categories in the Components list (Weapons & FC, Defences, Engines, Sensors, General).


Title: Re: Semi-Official 7.x Suggestion Thread
Post by: AbuDhabi on October 10, 2016, 12:16:11 AM
Heat-generating installations to warm up the really-cold places. There are some bodies, which while habitable, are just too damn cold, even with greenhouse factor 3. I figure enough fusion plants working the heaters might help.

Alternatively, mirrors elsewhere that redirect light to a given planet. Could even be cooling down that place, and warming up the target.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: alex_brunius on October 10, 2016, 03:44:23 AM
Heat-generating installations to warm up the really-cold places. There are some bodies, which while habitable, are just too damn cold, even with greenhouse factor 3. I figure enough fusion plants working the heaters might help.

Alternatively, mirrors elsewhere that redirect light to a given planet. Could even be cooling down that place, and warming up the target.

The issue is that unless there is an atmosphere the heating will just radiate and dissipate out into space instantly. It's like trying to heat a house without walls, where the surroundings are -273 degrees cold...  ;D So if such heating is available it would need to scale off atmosphere too anyways ( not a replacement for atmosphere ).

Mirrors to redirect sunlight from one body to another probably also is not feasible even with Sci-fi tech unless they are very very close, (say closer then our moon) due to light scattering and such on interplanetary scales.

So this part Aurora got somewhat accurate (where manipulating atmosphere is the way to change temperature).

Actually the cost of heating via fusion plants would probably be as expensive as doing orbital habitats... So you could just go for these instead and RP that they are powerplants used for heating. ( if you want to heat a -250 degree body without atmosphere ).

I guess you could hollow out and heat the insides of an asteroid for example (where walls act as insulators), but the cost of heating would probably be pretty minor in comparison to the hollowing out part, so it's probably included in the underground infrastructure cost already.




But what I would like to see the most when it comes to terraforming is that surface area on the body impacted how much atmosphere is needed, and that surface area also limited how much population you can have at colony cost 0. After a few hundred million for moons and some billions for Earth type planets you would have used up all "easy" space for farms, nature preserves, manufacturing, housing, services and such, and have to use infrastructure / Skyscrapers to fit more population.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: AbuDhabi on October 10, 2016, 04:10:23 AM
I meant the sunlight redirection to be in conjunction with greenhouse gases. So those walls around the house are there, it's just that the heat that gets there is insufficient (but already considerably amplified).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: totos_totidis on October 10, 2016, 08:52:16 AM
I think that bioweapons should be added.  You could use them to kill the population of a planet without damaging the surface structures.  Also each species would need different biological agents to kill it.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: alex_brunius on October 10, 2016, 09:19:28 AM
I think that bioweapons should be added.  You could use them to kill the population of a planet without damaging the surface structures.  Also each species would need different biological agents to kill it.

I remember reading that the reason this is not inplemented is because it would remove the need of ground combat to capture enemy planets somewhat intact.

And I kind of agree it's would make the game too easy.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on October 10, 2016, 09:43:21 AM
I think that bioweapons should be added.  You could use them to kill the population of a planet without damaging the surface structures.  Also each species would need different biological agents to kill it.
There is a warhead tech line that enhances radiation while lowering damage done. This is essentially what you are asking for but balanced.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: totos_totidis on October 10, 2016, 10:04:14 AM
Quote from: 83athom link=topic=8107. msg97904#msg97904 date=1476110601
There is a warhead tech line that enhances radiation while lowering damage done.  This is essentially what you are asking for but balanced.
Oh OK then.  What about adding a way for civilians to ship minerals from mining colonies and a way to automate your own mineral shipping with a conditional order.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on October 10, 2016, 10:06:49 AM
Oh OK then.  What about adding a way for civilians to ship minerals from mining colonies and a way to automate your own mineral shipping with a conditional order.
All CMCs have a mass driver. You can order them to shoot the minerals across the system.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: totos_totidis on October 10, 2016, 10:17:04 AM
Quote from: 83athom link=topic=8107. msg97907#msg97907 date=1476112009
All CMCs have a mass driver.  You can order them to shoot the minerals across the system.
I know I mean my mining colonies.  The Cargo ships are civilian.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on October 10, 2016, 10:19:06 AM
I know I mean my mining colonies.  The Cargo ships are civilian.
Ah. No method currently implemented to automate civilian shipping to ferry minerals around. You have to wither put a mass driver on the source and destination, or have a repeating order for one of your own cargo ships (not civilian) to just go back and forth between the mining colony and the destination of the minerals.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: totos_totidis on October 10, 2016, 01:08:06 PM
Quote from: 83athom link=topic=8107. msg97910#msg97910 date=1476112746
Ah.  No method currently implemented to automate civilian shipping to ferry minerals around.  You have to wither put a mass driver on the source and destination, or have a repeating order for one of your own cargo ships (not civilian) to just go back and forth between the mining colony and the destination of the minerals.
Yes i know.  I hope for this to be implemented in aurora 7. 2.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Kytuzian on October 15, 2016, 05:28:25 PM
In one of my games, I meant to add 14 ground units to an empire, but my finger accidentally hit the 3 right before I hit enter, and I added 143 Mobile Infantry Battalions instead, which mean I had to delete 129 units. An "Are you sure?" for SM stuff for high numbers--such as adding hundreds of ground units--would be greatly appreciated.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: AbuDhabi on October 18, 2016, 05:29:15 AM
Separate population names from body names. So you could have more distinguishable colonies.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on October 18, 2016, 01:13:30 PM
Separate population names from body names. So you could have more distinguishable colonies.
I think you're already able to rename the colony while keeping the planetary body named the same.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on October 18, 2016, 01:36:42 PM
Separate population names from body names. So you could have more distinguishable colonies.

This is already in C# Aurora.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: AbuDhabi on October 19, 2016, 12:44:56 AM
I think you're already able to rename the colony while keeping the planetary body named the same.

Sorta? The way it works in 7.1, is if you have, say, a population of Humans and a population of Smeerps on the same body, if you rename one population, you rename them both. I think it's tied to the planet, but the point is the populations share a name.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: AbuDhabi on October 25, 2016, 01:06:44 AM
If a theme is selected for a system and Real Stars are switched on, the theme will not be respected for adjacent systems - ie, the real name will be used, instead of the one generated according to theme, regardless of there being a theme set. I think this might be unintentional; after all, if you want the generic Wolf 235, Gliese 753, etc names, you would have switched the theme off. If themes were respected on Real Stars games, you could have real stars with automatic themed names, rather than the defaults.

Crossposting here from the Bugs thread, per suggestion.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: AbuDhabi on October 29, 2016, 12:05:37 PM
The current terraforming interface is a little cumbersome and prone to requiring micromanagement.

I propose the following improvement:

See the mock-up I've made.

As for the algorithm, it could go something like:
Code: [Select]
terraforming_potential = planet.terraforming_pressure(time)
if (planet.terraforming_active) {
   for (gas in ALL_GASES) {
      if (planet.get_gas(gas).pressure != intended_atm.get_gas(gas).pressure) {
         needed = intended_atm.get_gas(gas).pressure - planet.get_gas(gas).pressure
         if (abs(needed) <= terraforming_potential) {
            terraforming_potential = terraforming_potential - needed
            planet.get_gas(gas).pressure = intended_atm.get_gas(gas).pressure
         } else {
            if (needed >= 0) {
               planet.get_gas(gas).pressure = planet.get_gas(gas).pressure + terraforming_potential
            } else {
               planet.get_gas(gas).pressure = planet.get_gas(gas).pressure - terraforming_potential               
            }
            terraforming_potential = 0
         }
      }
      if (terraforming_potential == 0) {
         break
      }
   }
   if (terraforming_potential == planet.terraforming_pressure(time)) {
      planet.terraforming_active = false
      events.add("desired atmospheric composition reached")
   }
}
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: AbuDhabi on October 31, 2016, 04:03:00 AM
Orbital habitat modules should, perhaps, be loadable/unloadable just like cryogenic storage. And the population contributed to a planet would be dependent on how many people are loaded into a given module/ship. This would prevent certain silly things like moving habitats away from an inhospitable planet instantly killing everyone.

Title: Re: Semi-Official 7.x Suggestion Thread
Post by: baconholic on October 31, 2016, 02:09:22 PM
Assign/change planetary governor in the Population->Summary screen and ship commanding officer in the Individual Unit Details screen.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: RikerPicard on November 04, 2016, 09:23:59 PM
-"Permanent assignment" check box for officers, making them invisible to search by ability or location, similar to obsoleting tech, but you can check another box to show officers with permanent assignments.

-Scrap orbital habitat from industry(or if that doesn't fit the fluff, the assembled habitats are too big to bring down to the surface, let ships with salvage modules do it in space). 

-Dedicating a % of industry to "build components to order", and assigning it to any shipyard with current build orders, reducing the time needed to complete them. Less effective than prebuilding individual components.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Iranon on November 08, 2016, 06:26:30 PM
I'd greatly prefer it tractor links would not break whenever a lightbulb burns out.
Maybe tractor beam could do with some limitations, but making them too annoying to use in numbers seems the wrong way.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on November 09, 2016, 12:24:35 PM
A fighter sized fuel tank. 1 ton, carries 1000 Liters and costs .3 Boronide.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Bughunter on November 10, 2016, 03:43:21 PM
What about an option to do increment X ignoring interrupts no matter what happens?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: linkxsc on November 11, 2016, 12:04:16 AM
A fighter sized fuel tank. 1 ton, carries 1000 Liters and costs .3 Boronide.
Id be down for that. But at the same time I kinda wish you could build "drop tanks" to go in box launchers. Incase you want to send your fighter on a particularly long range mission, but dont need its normal full armament. "Firing" the fuel tank will add the fuel from that missile to the fighters current load.

Course that might be a real annoyance to code. And the idea that some of your ammo storage is now fuel storage is a bit meh.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Iranon on November 12, 2016, 05:51:08 AM
I'd really like more control about general game flow.
Maybe an adjustable "urgency rating" for any type of event, with associated settings like "display all events of urgency 3+, interrupt turns for all events of urgency 6+". Combined with nice defaults, this would be a great convenience feature imo.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: RikerPicard on November 12, 2016, 12:25:07 PM
Not sure if this is exactly what the previous poster was talking about, but I'd like to see the following events interrupt increments;

completed research
production of a single research lab
production of shipyard
completion of shipyard operation
production of ship/ground unit

I also don't think dropping off teams warrants an interrupt.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on November 13, 2016, 06:28:22 PM
Not sure if this is exactly what the previous poster was talking about, but I'd like to see the following events interrupt increments;

completed research
production of a single research lab
production of shipyard
completion of shipyard operation
production of ship/ground unit

I also don't think dropping off teams warrants an interrupt.
There are differences between Turn interrupts and Auto-turn interrupts. The first stops turns mid way and is more taxing for the program, the second just stops the auto-turn cycle until you increment time again.

The complete research, production of shipyard, completion of shipyard operation, and ground unit training are all already auto-turn interrupts. While completing research labs would be a handy interrupt, it would get really annoying and tedious quickly at the rates of production you should have (and idle labs are already an interrupt).

While Turn interrupts seem more useful than auto-turn interrupts, they are more annoying and counter-intuitive when you are supposed to be queuing these things so nothing is wasted.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: RikerPicard on November 13, 2016, 06:35:01 PM
There are differences between Turn interrupts and Auto-turn interrupts. The first stops turns mid way and is more taxing for the program, the second just stops the auto-turn cycle until you increment time again.

The complete research, production of shipyard, completion of shipyard operation, and ground unit training are all already auto-turn interrupts. While completing research labs would be a handy interrupt, it would get really annoying and tedious quickly at the rates of production you should have (and idle labs are already an interrupt).

While Turn interrupts seem more useful than auto-turn interrupts, they are more annoying and counter-intuitive when you are supposed to be queuing these things so nothing is wasted.

Didn't actually realize those things interrupt increments, I usually just start doing 1 day forward when something important is almost done.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: smoelf on November 16, 2016, 02:24:29 AM
I don't know if this has been suggested before or if it is even possible, but speaking of interrupts, I would love if it would be possible to distinguish between NPR's and PR's when determining an interrupt. This would especially pertain to battles where two NPR's are involved, and the player is not, but because you have a ship in the system, you are doomed to the inevitable 5-second turn interrupts every time an explosion is detected. And because this is a turn interrupt, you can't simply auto-turn your way out of it, but must sit there to click the turn button every time someone fires a weapon.

However, if it is was possible to distinguish between NPR's and PR's, you could do the following:

1) For any event where a PR ship is involved, you would stop the turn as per usual.

2) For any event where no PR ship is involved, but only NPR ships are involved, there would be no turn interrupt.

This should be able to be toggled on and off, as sometimes you might want to be able to react to the information given through those events, but once you know that there is a battle going on, and the movement of your ship has no bearing on it, you might as well set those kind of events as non-interrupting, and continue on your way. Naturally, if one of the ships fire at you, or activates an active sensor close to you, that would mean an interrupt, as your ship is directly involved in that event.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: SwordLord10 on November 16, 2016, 09:47:58 AM
I think it would be a good addition to add different kinds of missile systems, like radar-guided and heat-seeking missiles of today. You could use a normal active sensor, and that wouldn't change from how it works now, but you could also implement a system allowing for missiles to have thermal sensors, so they target the largest thermal source they can detect on their target, or EM sensors, to target either sensors or shields. That would also add a new counter-missile system in decoys, which could use "noisemakers" which send out EM signals, or "flares" which clutter thermal sensors, attempting to draw them off target.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on November 16, 2016, 10:15:43 AM
I think it would be a good addition to add different kinds of missile systems, like radar-guided and heat-seeking missiles of today. You could use a normal active sensor, and that wouldn't change from how it works now, but you could also implement a system allowing for missiles to have thermal sensors, so they target the largest thermal source they can detect on their target, or EM sensors, to target either sensors or shields. That would also add a new counter-missile system in decoys, which could use "noisemakers" which send out EM signals, or "flares" which clutter thermal sensors, attempting to draw them off target.
Technically that is already a thing. EM sensor equipped missiles will seek out enemy active sensor sources and thermals target largest thermal contact. However these only take effect if active contact is lost and the missiles sensors pick up the target on its own.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on November 16, 2016, 10:17:47 AM
I think it would be a good addition to add different kinds of missile systems, like radar-guided and heat-seeking missiles of today. You could use a normal active sensor, and that wouldn't change from how it works now, but you could also implement a system allowing for missiles to have thermal sensors, so they target the largest thermal source they can detect on their target, or EM sensors, to target either sensors or shields. That would also add a new counter-missile system in decoys, which could use "noisemakers" which send out EM signals, or "flares" which clutter thermal sensors, attempting to draw them off target.
It's a cool idea, but how does it work with the current generalized armor? Can you hit the sensors/shields bypassing armor? If not, then why are all your targeted missile strikes splashing against armor across the length of the ship, then suddenly all hitting the engine as soon as the armor is breached? I think for this to logically work Steve would need to move more towards localised armor, which opens a huge can of worms.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: SwordLord10 on November 16, 2016, 10:48:34 AM
It's a cool idea, but how does it work with the current generalized armor? Can you hit the sensors/shields bypassing armor? If not, then why are all your targeted missile strikes splashing against armor across the length of the ship, then suddenly all hitting the engine as soon as the armor is breached? I think for this to logically work Steve would need to move more towards localised armor, which opens a huge can of worms.
Well I can understand the difficulty hitting internal systems like sensors or shields, I would have to take some time to think of how that could work without remaking armor. Engines have to have an external element to generate thrust however, meaning that it would work by the missiles going behind the ship, then powering as close to the engine as they can before going boom.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on November 16, 2016, 11:50:03 AM
Well I can understand the difficulty hitting internal systems like sensors or shields, I would have to take some time to think of how that could work without remaking armor. Engines have to have an external element to generate thrust however, meaning that it would work by the missiles going behind the ship, then powering as close to the engine as they can before going boom.
But then shouldn't non-guided missiles should also have a chance to cause direct engine damage (just be happening to hit near the engine opening? Can-of-worms!
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on November 16, 2016, 12:20:17 PM
Engines have to have an external element to generate thrust however, meaning that it would work by the missiles going behind the ship, then powering as close to the engine as they can before going boom.
Not necessarily. There are plenty of Sci-Fi that I've read that describes types of internal engines that are basically mass chambers, energy drives, or gravity drives. Just because they produce enough heat to be visible from long range via sensors doesn't mean they are external. Also you could have the main bulk of engines tucked away in your armoring while having only the exhaust ports sticking out the back (if you want to think of the engines as advanced forms of traditional rockets).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on November 16, 2016, 12:45:04 PM
Not necessarily. There are plenty of Sci-Fi that I've read that describes types of internal engines that are basically mass chambers, energy drives, or gravity drives.
But Aurora engine names are fusion rocket engine names.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on November 16, 2016, 12:47:11 PM
But Aurora engine names are fission-fragment rocket engine names.
Could be the types of reactors used to produce the energy for said internal drives.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on November 16, 2016, 12:52:01 PM
But Aurora engines are not the same, as reactors.

P.S. I made a term mistake at previous post - fusion engines, not fission. But it's all engines with external jet part.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Black on November 29, 2016, 12:51:49 PM
Would it be possible to add filter to System Generation and Display window for C# Aurora? Something like display only systems with colonies. As the number of discovered systems increases there are lot of systems that are not really useful, and I have to scroll through a long list to find systems with my colonies.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on November 29, 2016, 02:26:27 PM
Would it be possible to add filter to System Generation and Display window for C# Aurora? Something like display only systems with colonies. As the number of discovered systems increases there are lot of systems that are not really useful, and I have to scroll through a long list to find systems with my colonies.
What do you need to search the System Information window for? I look at it when I'm surveying a new system, but after that I very rarely scroll through it from one system to the next. I might go to a specific system for info on minerals there, or something like that, but that's about it.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Black on November 29, 2016, 02:59:54 PM
You dont really need to scroll throug it that much as you can do most of the things like setting up colonies and checking minerals form specific windows. It just crossed my mind when I was scrolling through it to look for planets with hydrosphere (I RP in my current game that you can have 0 cost colonies only on worlds with water), that it would be nice to be able to filter the list of star systems.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on November 29, 2016, 04:08:43 PM
Ah, the RP angle makes more sense. The potential colonies screen is a bit lacking in detail for that kind of thing, would be nice if it clicked through to the system view containing the relevant body.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Black on November 29, 2016, 04:15:14 PM
Yeah exactly, there is info about atmosphere and minerals, but from RP standpoint, maybe you are interested in hydrosphere or if the planet has magnetic field or if it is tidaly locked, and as far as I know this info is only in System Generation window.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: NihilRex on November 29, 2016, 07:33:21 PM
Has there been any discussion of Force Directed Graphs for auto-arranging the interstellar maps?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on November 29, 2016, 07:43:36 PM
Has there been any discussion of Force Directed Graphs for auto-arranging the interstellar maps?
A few times. But a lot of people prefer making their own maps. Plus, hidden connections and one-way points kind of defeat the coding to auto arrange the map.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: NihilRex on November 30, 2016, 10:46:25 AM
Hidden connections can be given a negligible force, and one-way connections can be half-force...

I get frustrated trying to maintain my map, to be honest.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Kytuzian on December 01, 2016, 07:05:51 PM
I agree that having an auto range feature would be useful. It could just be a button that says "Arrange map" rather than something that happens every time you discover a system/open the map.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on December 05, 2016, 09:49:30 AM
How about expanding the uses of PoWs. Maybe having an interrogation stance based on your government and/or racial stats. A hard stance would pull more info (better chance) but have a higher chance of killing the subject, and a softer one would have a lower chance of pulling information but probably would never kill a subject. The use on planets they would have; Dead: they could be researched giving a ground combat bonus (and boarding bonus) against the species in question (and the enemy could do that against your people to have the same effect). Alive: They could be studied and questioned, giving a bonus to diplomatic rolls (if your race preferred peace). Or you could return PoWs to an alien population to boost your political standing with them. Or you can store them on your worlds to eventually turn into forced labor units.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Silvarelion on December 12, 2016, 07:50:00 PM
I agree that a larger increment or a build-to option on commercial shipyards would be very helpful.  I wouldn't mind taking a productivity hit for the increased quality of life.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: hiphop38 on December 14, 2016, 05:04:32 PM
Posted this on the "Not suggestion thread" So ill repost here:

So call me a big fat Space ####, but I often like to rp my Aurora games with Slavery not only allowed, but state sponsored. Currently they only really work as big and difficult to transport construction brigades, and thus can only build installations/PDC.

It could be nice to have further rules for the idea of slavery in general. Perhaps it could be made so that the slaves can be brought to a planet with minimal to no infrastructure and act as a disposable population. That way they can man installations (Each unit costs 10,000 population to create, why not have them be 10,000 of population for labor as well), such as mines or terraforming installations. (does it make me evil to want the filthy xenos I crushed under my Jackbooted heel to serve me in defeat?)

I do like the idea of the forced labor units in creating a rich dark rp environment, I just wished for a bit more options with them.
That being said, they do still work rather nicely as the transportable construction factory, sans the infrastructure/building/population, that they currently are. If I am the only bastard evil enough to even use the FLU then so be it and I'll be content with Slavery as it currently stands.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on December 15, 2016, 09:14:17 AM
Give PDCs more use in ground combat. Maybe adding an "anti-titan" weapon module that does damage/attack equal to ground combat tech, while doing 50% or so more damage to titans. And/Or an artillery module that has a similar combat mechanic to titans. Also, maybe adding gauss cannons and such should bolster ground combat defenses against invading troops (like 1 defense per rof tech).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TheDeadlyShoe on December 15, 2016, 10:41:53 AM
PDCs are reasonably useful in ground combat.  You can't capture a population that has a PDC, and a PDC containing troops gives them a multiplier based on its armor layers against direct assaults against it. The problem there is that the entire enemy army can be directed against one PDC at a time, so for this to be useful you need to make an enormous PDC that contains enough troops to be competitive....   After putting in weapons systems, PDC barracks, and thick layers of armor, such a PDC could easily absorb several years of your entire industrial output in a contested-earth start.

Meson cannons ruin this strategy, much like they ruin gorgeous spring days and brunch.

Title: Re: Semi-Official 7.x Suggestion Thread
Post by: smoelf on December 20, 2016, 05:35:57 AM
Since everything is being rewritten in C#, perhaps now would be an opportune time to replace the male pronoun in the event reports with the singular "they". Male and female pronouns would also work, but I imagine a singular they would be easier and faster to implement.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on December 20, 2016, 09:13:08 AM
Since everything is being rewritten in C#, perhaps now would be an opportune time to replace the male pronoun in the event reports with the singular "they". Male and female pronouns would also work, but I imagine a singular they would be easier and faster to implement.
Actually, it should only be a few lines of code and would change very little. But I know very little of C# as I've mainly used C++ or Java.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: smoelf on December 20, 2016, 12:12:57 PM
Actually, it should only be a few lines of code and would change very little. But I know very little of C# as I've mainly used C++ or Java.

True, but I just assumed that it would be easier to change a single word in the text instead of adding a line of code to check for the gender of the officer. In any case it would indeed be a cosmetic change with no impact on gameplay, but it just bugs me a little when female officers are referred to as male :)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Erik L on December 20, 2016, 03:48:28 PM
The table the names are generated from include a gender field. (or it's the officer table). It's just never been implemented in code.
Title: PDC and Ship Components
Post by: Marc420-2 on December 26, 2016, 03:51:07 PM
My suggestion today is to allow the construction of PDC's with stockpiled ship components.

Here's what I was trying to do.   I started with a group of relatively small shipyards.   All in the 7k to 10k size range.   So, its taken me awhile to build up to the SY big enough to build ships with the 25kt Cargo hold needed to ship prefab PDCs.

So, I had a bright idea that at least seemed to make sense.   I'd build the components I'd need . . .  the size 1 missile launchers, the mags, the missile fire controls, the sensors etc that I would need to build a rudimentary defense post.   Then, I'd ship them over to the planet I wanted to protect.   Then the construction factories and the construction brigade over there would dig the hole in the ground, pour the concrete, build the basic crew quarters etc, install the ship components, and I'd have a PDC over there.   Seemed to make a bit of sense.

Tried it, and of course it didn't work.   I found a threat on the Academy pages that said components are added to a ship when its added to the shipyard.   Since the PDC doesn't go through the shipyard, the stockpile of ship components is left untouched and the game is telling me that its going to take 3 years to build the PDC.   

So, changing the PDC construction code to have it use any stockpiled components would seem to be a nice add.

Actually, I'd also make a second suggestion to change the way ship components and the shipyards work.   If a shipyard knows a component is under construction, they could probably plan their work such that when the component arrived they could plug it in.   So, I don't know how difficult it is in the code, but it would be nice if a ship under construction could accept ship components that come from industry after the construction is begun and still have that speed up the completion of the ship.

But my main suggestion is to have the PDC construction code at least recognize that components are available and use them.   Doesn't seem to be much harder than spotting them, raising the completion pct of the PDC in the factories, and erasing the stockpiled components.   If you cancel the PDC completely later, the components are just gone.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on December 28, 2016, 05:28:57 AM
How about expanding the uses of PoWs. (...) Or you could return PoWs to an alien population to boost your political standing with them. Or you can store them on your worlds to eventually turn into forced labor units.
If you have 'collected' enough PoWs, you could release them as a separate colony.

Espionage Teams are actually killed when discovered. Would love to have a chance of capturing them which can provide some opportunities for RP (something along the line of 'Bridge of Spies')... .
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on December 30, 2016, 10:54:46 PM
If you have 'collected' enough PoWs, you could release them as a separate colony.
I imagine one problem of using PoWs as it's own colony is that: almost all PoWs you'll get are folks who work for the military of their home-nation, one way or another. Getting a massive quantity of crewmen for the express purpose of sticking them on a colony seems... like a bad idea. Getting them to reproduce will be difficult as well, for instance, if a nation made a policy to sterilize their interstellar soldiers or use only soldiers of a single sex for the exact reason of preventing a sexual colonial kidnapping.

Another issue with using them for such purposes is that you need a -lot- of PoWs to equate anything significant in population terms.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on December 30, 2016, 11:02:49 PM
Doublepost for full suggestion:
Rather than have NPR units ignore fuel costs, how about instead having them use fuel, as normal, but rather than stopping on no fuel, they will instead run at 1/3rd speed for commercial, 2/3rd speed for military. When they run out of fuel in this state, they will continue doing what they're doing, but queue up refueling at next convenience, with a bit of extra priority.
When they go to refuel, they will have a stored amount of "fuel used below 0", an amount that will instantly be deleted from the colony in question (resetting the "fuel used below 0" value), before adding fuel directly to the tank of the ship.

This'll basically make it so that NPRs are at least penalized for operating far outside of their spheres of influence without having some attackable logistics line to show for it.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Triato on December 31, 2016, 11:47:05 AM
I think rhis could be easy to exploit.  You could make it chase you and attack once it is out of fuel. How about instead,  th npc runs out of fuelel,  perform its last order and then has to go back home.  If there is combat,  it doesnt go back.  If it detects hostiles or neutral it also cancela refuel.

Npcs should not have a fuel pool becouse they would waste it if they dont have avanced Ai.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: alex_brunius on January 02, 2017, 03:02:27 AM
It would be cool if equal amount of mass-drivers was needed in both ends, so you can't have the max output of 20+ mass drivers be caught by a single one but required the same amount on the destination. This would need the warning of removing the last mass-driver to be added whenever setting a target that does not have capacity to catch the output as well.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TheDeadlyShoe on January 02, 2017, 03:25:16 AM
It would be pretty easy to accidentally detonate the Earth in that case -for instance when a CMC grows in size, or if you type in the wrong number on a logistics run.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: alex_brunius on January 02, 2017, 03:33:13 AM
It would be pretty easy to accidentally detonate the Earth in that case -for instance when a CMC grows in size, or if you type in the wrong number on a logistics run.

Typing in the wrong number would obviously still give you the same warning that exists today (for removing more capacity then required). IIRC it even prevents the order from being carried out.

CMCs might need some special rules to them to prevent additional Micromanagement of building spare massdrivers when you buy their output. Logically you would also buy the Civilian means to transport the minerals back home, so their transport could be "included in the cost" ( since obviously they had the infrastructure in place to handle the minerals mined before you started buying it ).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on January 14, 2017, 04:54:35 AM
World gen setting that lets you force all or a percentage of RNG-spawned NPRs to be Human.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Tree on January 14, 2017, 09:02:08 AM
World gen setting that lets you force all or a percentage of RNG-spawned NPRs to be Human.
Steve already mentioned adding a "lost colonies" setting allowing you to find NPRs of the race you're playing.
Title: Medical tech
Post by: ryuga81 on January 16, 2017, 04:53:01 AM
There are very few techs in Biology, so it wouldn't be bad if we had some kind of "medical tech" that improves lifespan of leaders/officers. At this point they retire quite early (~62 years), I'd expect 20 or 50 years into future people would remain active for longer.

It would be great if we could extend that by a year or two per tech level.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on January 16, 2017, 05:14:06 AM
In the very least, we should have techs to expand the lifespans of our highest officer tiers.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Silvarelion on January 17, 2017, 01:05:16 PM
It would be lovely if box launchers would default to the level 1 reload rate to save costs on a tech with no benefit to the system.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on January 20, 2017, 12:42:34 AM
Organising your salvos isn't too hard. In large battles, though, it can get difficult to make sense of what you've actually done to your enemy's ships. I'd like it if the game tracked exactly how much of your ordnance (maybe even down to numbers of specific missile types and their warhead values) that an enemy contact has been hit with and how much energy weapons fire (in damage points) that it has received.  It'd be great if, ontop of this, your intelligence information included a statistic for each enemy ship type's "average damage before kill" that becomes more precise as you kill more of them.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: smoelf on January 21, 2017, 04:13:05 AM
Being able to search for minerals based on a set number of jumps from a selected system.

Right now you can search for e.g. Duranium in either all surveyed systems or a single system. It would be awesome if you could select a system, like Sol, and search for e.g. Duaranium in systems one jump away from Sol or two jumps away from Sol. Would be really helpful when establishing colonies in deep space, and you want to ensure access to all minerals within a reasonable distance.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: alex_brunius on January 21, 2017, 08:36:45 AM
Being able to search for minerals based on a set number of jumps from a selected system.

Right now you can search for e.g. Duranium in either all surveyed systems or a single system. It would be awesome if you could select a system, like Sol, and search for e.g. Duaranium in systems one jump away from Sol or two jumps away from Sol. Would be really helpful when establishing colonies in deep space, and you want to ensure access to all minerals within a reasonable distance.

Well distance is not measured in number of jumps but in billions of km, so it would be better to be able to sort on that instead IMHO.

Another interesting metric that would be useful is to sort only on targets that are Jump Gate connected to your home planet.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Michael Sandy on January 21, 2017, 04:47:19 PM
I would like to see options for how many warp points the average system has.

That way, I could play with 90% (or higher) connect to stars in the local cluster, so there will be multiple routes to stars in my cluster, while still having good odds of connections to other clusters.

Also, a real galactic map, where you can see what your empire looks like in real space would be fun, especially if clustering is based on distance in real space.  So you could guess what stars it would be worth surveying to find a backdoor into an enemy empire, or for that matter, which to avoid if you wanted to avoid them.

Possibly have the galactic map be a researchable tech, with each new system discovered adding research points to the tech.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on January 21, 2017, 11:50:00 PM
Organising your salvos isn't too hard. In large battles, though, it can get difficult to make sense of what you've actually done to your enemy's ships. I'd like it if the game tracked exactly how much of your ordnance (maybe even down to numbers of specific missile types and their warhead values) that an enemy contact has been hit with and how much energy weapons fire (in damage points) that it has received.  It'd be great if, ontop of this, your intelligence information included a statistic for each enemy ship type's "average damage before kill" that becomes more precise as you kill more of them.
This is an amazing idea, yeah.
Worth noting, though, that Average Damage To Kill might be anywhere to extremely random, to extremely weapon profile dependant. I.E., thin skinned ship getting hit by large penetration weapons, vs same ship getting sandblasted apart by gauss or railguns. This is mainly due to ships not necessarily having a distinct HTK, as the HTK number for ships is actually the cumulative HTK of all internal components, and not actually directly deterministic of how fast it'll die to internal damage (for instance, 10HTK 1HS magazines won't contribute much to the ability of the ship to not die.)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on January 22, 2017, 06:53:07 AM
Organising your salvos isn't too hard. In large battles, though, it can get difficult to make sense of what you've actually done to your enemy's ships. I'd like it if the game tracked exactly how much of your ordnance (maybe even down to numbers of specific missile types and their warhead values) that an enemy contact has been hit with and how much energy weapons fire (in damage points) that it has received.  It'd be great if, ontop of this, your intelligence information included a statistic for each enemy ship type's "average damage before kill" that becomes more precise as you kill more of them.

This actually already exists in the game. It is tracked by NPRs :). They monitor how much damage is needed to kill each ship class. It would be simple enough to add this to the intelligence window. However, I'd never got around to modifying the NPR missile allocation code to take advantage of this information. It isn't very straightforward as you also need some idea of defensive capability before assigning targets.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on January 22, 2017, 06:55:12 AM
World gen setting that lets you force all or a percentage of RNG-spawned NPRs to be Human.

I will be adding something on these lines for C# Aurora. The first large campaign I have in mind (once properly tested) is the Great Crusade from WH40K, so I will need a proportion of NPRs to be human.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on January 22, 2017, 06:56:06 AM
If you have 'collected' enough PoWs, you could release them as a separate colony.

Espionage Teams are actually killed when discovered. Would love to have a chance of capturing them which can provide some opportunities for RP (something along the line of 'Bridge of Spies')... .

They can be captured. If they are, the enemy gains some intelligence.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on January 22, 2017, 06:57:32 AM
Doublepost for full suggestion:
Rather than have NPR units ignore fuel costs, how about instead having them use fuel, as normal, but rather than stopping on no fuel, they will instead run at 1/3rd speed for commercial, 2/3rd speed for military. When they run out of fuel in this state, they will continue doing what they're doing, but queue up refueling at next convenience, with a bit of extra priority.
When they go to refuel, they will have a stored amount of "fuel used below 0", an amount that will instantly be deleted from the colony in question (resetting the "fuel used below 0" value), before adding fuel directly to the tank of the ship.

This'll basically make it so that NPRs are at least penalized for operating far outside of their spheres of influence without having some attackable logistics line to show for it.

I will look at NPRs tracking fuel state correctly for C# Aurora. With much faster code execution, I can add a lot more intelligence to the NPRs.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ChildServices on January 22, 2017, 07:17:08 AM
This is an amazing idea, yeah.
Worth noting, though, that Average Damage To Kill might be anywhere to extremely random, to extremely weapon profile dependant. I.E., thin skinned ship getting hit by large penetration weapons, vs same ship getting sandblasted apart by gauss or railguns. This is mainly due to ships not necessarily having a distinct HTK, as the HTK number for ships is actually the cumulative HTK of all internal components, and not actually directly deterministic of how fast it'll die to internal damage (for instance, 10HTK 1HS magazines won't contribute much to the ability of the ship to not die.)
Could always only track "ADTK" based upon the last however many kills, or filter away all kills before a certain date.

Another option is to create an algorithm that filters away outliers such as you killing a ship using 500 AMMs out of desperation when you'd killed every other ship in its class in that battle with only 4 or 5 torpedoes (less raw damage overall, but more penetration), or the inverse of that where you get lucky and an enemy ship fails a bunch of damage allocation rolls and dies from only one torpedo. This is the much more "high effort" solution to the problem you mentioned as far as the coding work required, though.

Edit: A crazy third option I've come up with is to track "composite" kills with the same types of weapons, I.E if I hit it with both torpedoes and AMMs, then give me an average of how many torpedoes + AMMs (of the exact types used, or based solely upon warhead values of missiles used) that it takes on average to kill one based on the averages of all kills where those were the only two weapons used (possibly filtering away other things which did barely any damage into an "other sources" category). The information you'd get out of this would be pretty damn hard to read, because each ship would have several ADTK scores, but it would still ultimately be useful for planning purposes.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: SgtVennamo on January 23, 2017, 10:48:19 AM
Hi,

After playing around with boarding I noticed couple of illogicalities with it.   
First is that capturing a vessel doesn't give class design info on Alien Intel screen.   If you're in possession of an alien craft I think one can get all that info, maybe after scrapping it. 
Second is that the remaining crew of an alien vessel transforms into your own population instead of alien POWs.   I'd like to see the alien crew as POWs and marines capturing the vessel being tied to it until it gets to home base/fleet.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on January 31, 2017, 11:06:14 AM
An intel screen for enemy missile types similar to the ship one. It contains a log of the speed, warhead, sensor strength, size, etc of encountered missile types.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TheDeadlyShoe on February 04, 2017, 01:12:49 AM
Kinda feels like the existing suggestions threads ought to be bulldozered in favor of a C# suggestions thread. A lot of the early posts in this arn't taking into account C# changes... and God help the previous thread's suggestions, even though its still stickied xD

Cargo Handling Systems Rework:

I've long felt Cargo Handling Systems are a bit of a sideshow.  Most extrasolar colonies are far enough away that even maximum cargo handling times of 10 days make only a small difference.  For intrasolar traffic, even 1-2 of these relatively cheap systems is sufficient.  CHS do matter for transferring troops between troop bays and dropships - but cryo drop bays have rendered that awkward procedure somewhat antiquated.  Additionally, Spaceports are increasing in importance with the changes to refueling in C#, and are more likely to be present.  Mostly I use CHS to round out tonnages to aesthetically pleasing numbers.

My suggestion is to drastically increase the size and cost of CHS and drastically increase the penalties of not having them.  A sample number would be Size 100 CHS and 100 day standard unload time.  (For context, the existing CHS is size 2, a Standard Cargo Hold is size 500, and the standard unload time is ~10 days. I'm unsure of the formula, but a ship with a 1:1 cargo to CHS ratio has 80% less unload time and 2:1 gives it 90% less. )  A ship with CHS would be considerably bulkier and less fuel efficient than those without, but conversely the equipment is much more necessary for rough colonies.

Thus, there are incentives for larger variety in commercial ship design.  Bulk transportation between colonies with 1 spaceport can be best accomplished by 1-standard-cargo-hold ships without CHS - they would be the most space and fuel efficient by far.  Larger CHS-less freighters would require additional spaceports to load and unload with the same efficiency.  Rough-country transports with 1 or more CHS would be much more efficient transporting to unimproved colonies, or to colonies with less spaceports for shorter trips.   Colony ships would be pressured by the same design constraints. I can also see a potential role for a "Pioneer transport" - a combination colony/cargo ship that mounts 1-2 CHS specifically for opening new worlds in a specially-designed package, while follow-on traffic is handled by high efficiency ships once a spaceport is built.

As for troops, I would suggest deprecating CHS for troop loading to combat pods from starships. There's already a pretty huge logistics overhead in shipping both dropships and troops to an invasion mission, and combat cryo does exist.  CHS could still accelerate the initial loading of troops to transports or to combat cryo.  And of course non-combat unloading could still use it.  You couldn't really 'get around it' with combat drop vessels since those would cost a bundle more than just slapping on a CHS.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TheDeadlyShoe on February 05, 2017, 04:30:47 PM
Another thought:

Currently, until you research and build brigade and division HQs, you suffer a bleed of your best ground combat commanders. The guys with good scores get promoted beyond base rank, but there's no higher-authority slots to put them into, so eventually they get fired for not getting assignments.

Suggestion: Block promotions for ground combat commanders until higher-echelon technologies are researched.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on February 05, 2017, 07:14:02 PM
Currently, until you research and build brigade and division HQs, you suffer a bleed of your best ground combat commanders. The guys with good scores get promoted beyond base rank, but there's no higher-authority slots to put them into, so eventually they get fired for not getting assignments.

Suggestion: Block promotions for ground combat commanders until higher-echelon technologies are researched.
Or an Army command much like the Fleet command.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ryuga81 on February 13, 2017, 09:23:46 AM
Or an Army command much like the Fleet command.


Excellent point. We could definitely use something like that.

Also, I'd like to have "specialization" bonus types for ground commanders, rather than just ground combat and training. Something more specific would be great, like space-based combat (for boarding), siege warfare (vs PDCs or defending PDCs), urban warfare (attacking or defending heavily populated/industrialized planets), guerrilla warfare (attacking or defending mostly uncolonized/untame planets) and such... the latter two could be based on the new population caps thus they sort of fit with C# Aurora.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on February 13, 2017, 03:37:37 PM
Something small for a change. Could jump engines get a heading in the list of ship components at Class design screen so that they are clearly divided from normal engines? I have together over 20 active designs of them and this would help navigating that long list.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on February 13, 2017, 03:41:11 PM
Something small for a change. Could jump engines get a heading in the list of ship components at Class design screen so that they are clearly divided from normal engines? I have together over 20 active designs of them and this would help navigating that long list.
Don't see how that would fit. We have sections for Hull, Engines, Beam weapons, Missiles, Strike Groups, and Sensors. Why would we separate the engine grouping into two separate groups?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on February 13, 2017, 04:18:29 PM
Don't see how that would fit. We have sections for Hull, Engines, Beam weapons, Missiles, Strike Groups, and Sensors. Why would we separate the engine grouping into two separate groups?
... would fit?? That list goes for several screens... currently like 7 for me with 13 headings. Shields and electronic warfare seems grouped together but even Magazines have their separate section.

I am talking about the main list Available component in the tab Design view.
Do you mean some other section of Class design screen maybe? Or could be you not using "Reduced height windows" the  source of this confusion?

Also, as now here are grouped engines and jump engines together it looks quite weird when you select multiple engines and are told "just one engine" but engine+jump engine (aka 2 selections from Engines section) are fine.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Garfunkel on February 14, 2017, 01:08:58 AM
That's actually a good idea. They perform completely different functions already.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on February 14, 2017, 04:42:31 AM
Could closing pop-ups via X in the corner mean "NO" instead of "YES"?
Multiple times I misclicked and ordered refitting of my tanker (because his name is from A) to some other class. I am then asked if really want it with 400%+ refit price. I close the window via X, meaning "don't do it" but game takes it as "do it".

"X" treated as a default answer and default answer being "do nothing" would make more sense to me. See behaviour of "are you sure you want ot delete this file?".
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: swarm_sadist on February 20, 2017, 01:26:58 PM
Small suggestion for ECM:

Have Fire Control systems be detectable when used against your ships. This could be a simple omni-directional system that simply tells if a FC is active or hitting your ship, or a more advanced system which determines which ship is targeting and which ship is being painted.

Also, have that information be made available in the intelligence tab.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on February 27, 2017, 06:27:53 PM
They can be captured. If they are, the enemy gains some intelligence.

Yes, but the espionage teams are always killed. Having a chance of capturing them opens RP opportunities to do some kind of "spy exchange" ;-)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on March 07, 2017, 01:22:06 PM
Could _horizontal_ scrollbars be added to few areas with lists of components? The screen is divided there into several smaller panes and the important information is often in the end of row (differentiating code, hits left, repair value):
Repair value can be found as twice the cost in Class design but in overall this issue currently wrecks use of name of manufacturer before the name and code of ship component a bit. Yes, I am using 1280x800 laptop with Reduced Height Windows but the issue of just a bit too long names for these component lists is surely on other displays too. And trying to use short names of components just so they can fit in these places sounds like a less interesting option.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ExChairman on March 10, 2017, 10:08:11 AM
Declaring a emergency! Would be nice to enroll civilian shipping in an emergency, make them transport refuges, needed infrastructure, give fuel to stranded ships, etc.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TCD on March 10, 2017, 01:47:04 PM
Declaring a emergency! Would be nice to enroll civilian shipping in an emergency, make them transport refuges, needed infrastructure, give fuel to stranded ships, etc.
That could work with a sufficient penalty. Perhaps you should need to compensate the civilian shipping lines at double build cost when you appropriate a ship? Otherwise you could use a perpetual state of emergency to skip the mineral and shipyard time costs of building freighters and colony ships.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on March 10, 2017, 01:53:51 PM
Declaring a emergency! Would be nice to enroll civilian shipping in an emergency, make them transport refuges, needed infrastructure, give fuel to stranded ships, etc.
You can kinda roleplay it. You can steal their ships and after a month or two destroy those ships (without wrecks) and pay the shipping lines enough so that they can buy new ones. That way you are effectively borrowing their ships for high costs.

If he emergency is still going, repeat. It needs to be done this way because I don't think you can currently transfer a ship back to shipping company.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on March 12, 2017, 05:43:00 AM
Could we got an ability to rename fire controls in ship? In Class design would suffice though in Combat assignments with "Copy to TG"/"Copy to Race" would be great so you can change it together with PD mode. It would make reading the event log less confusing, if you can see which targeting is done by, say, "BFC-1" and which by "BFC-2" with more weapons under it.

Without this direct ability, I may start using to design BFCs twice, named the same just with "-A" and "-B" suffix, to be able to distinguish them then. Or using even number of weapons :| .
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Iranon on March 12, 2017, 06:35:44 AM
Regarding civilian vessel requisition: I really like the idea.
I'd have this impose a severe wealth penalty on the affected line (for lost earnings while there may be ongoing costs - wages, interest etc), and a moderate penalty to all lines (to account for reluctance to invest in more ships, some measures to discourage the state from seizing their assets, and general disturbance due to the uncertainty).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on March 12, 2017, 01:48:40 PM
Event log: add event "Jump gate finished".
There are currently only "Jump gate detected" and "Jump gate underway".
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: smoelf on March 13, 2017, 06:15:48 AM
I would love a separate colony category of "Asteroid Mining". It is a bit annoying when colonies with nothing but ships with asteroid mining modules are hidden in the "Other Colonies" category.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on March 13, 2017, 02:58:31 PM
I would love a separate colony category of "Asteroid Mining". It is a bit annoying when colonies with nothing but ships with asteroid mining modules are hidden in the "Other Colonies" category.
And for Ground units screen and other places there already exists "list of all ships parked at this colony" function so filtering such ships for asteroid mining may not be too hard. Or "ore is disappearing while they are no mines" could be used.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on March 14, 2017, 09:30:38 AM
Population and production->Populated systems:
When renaming colony put the old name in the textarea, already selected, so one doesn't need to write it again if one wants only to fix a typo or other small change. But if you want to change it completely you can just write the new name directly.

This already works so for renaming of task groups but for colonies one is presented with a blank name in the Rename popup.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: DAVIDARCNO on March 19, 2017, 11:54:17 AM
I do not know if any of this has been suggested, but for the civilian leaders:

1.  Each system have a governor for the entire system and passed down a fraction of his abilities to each colony in the system.
2.  A empire/federation/ leadership position for all systems.  Under would be the sector Governors, the system Governors and the planet Governors.  The tile of the empire wide leader could be determined by the empire theme.
3. The empire wide leaders could have a cabinet, Minister of war, industry, science, mining, terraforming etc.

I realize this would be a lot to add.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on March 19, 2017, 12:30:11 PM
Population and production->Populated systems:
When renaming colony put the old name in the textarea, already selected, so one doesn't need to write it again if one wants only to fix a typo or other small change. But if you want to change it completely you can just write the new name directly.

This already works so for renaming of task groups but for colonies one is presented with a blank name in the Rename popup.

I am doing this for all the rename options in C# Aurora.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on March 19, 2017, 12:31:03 PM
I would love a separate colony category of "Asteroid Mining". It is a bit annoying when colonies with nothing but ships with asteroid mining modules are hidden in the "Other Colonies" category.

in C# Aurora, all ground-based and orbital mining is considered when categorising the colony.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on March 19, 2017, 12:37:34 PM
I do not know if any of this has been suggested, but for the civilian leaders:

1.  Each system have a governor for the entire system and passed down a fraction of his abilities to each colony in the system.
2.  A empire/federation/ leadership position for all systems.  Under would be the sector Governors, the system Governors and the planet Governors.  The tile of the empire wide leader could be determined by the empire theme.
3. The empire wide leaders could have a cabinet, Minister of war, industry, science, mining, terraforming etc.

I realize this would be a lot to add.

There are already sector commanders in VB6 Aurora, which provide bonuses to all planets within their sector.

It might be possible to add extra levels between the sector and the planet, but then I would have to tone down the benefits. For example, a sector governor adds 25% of his bonuses to each population in his sector. If I added a system governor, I would probably apply that bonus to him and reduce the sector commander to perhaps 5-10% of his bonus. I'm not sure it would be worth it, especially as in many cases a system may only have a single population. However, if we leave planetary and sector governors as they are, it might be possible to add your suggested Empire-wide government with different ministers providing different bonuses.

I am adding Naval Admin as well to C# Aurora, which will add some administrative elements on the naval side.

Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on March 19, 2017, 12:40:02 PM
Could we got an ability to rename fire controls in ship? In Class design would suffice though in Combat assignments with "Copy to TG"/"Copy to Race" would be great so you can change it together with PD mode. It would make reading the event log less confusing, if you can see which targeting is done by, say, "BFC-1" and which by "BFC-2" with more weapons under it.

Without this direct ability, I may start using to design BFCs twice, named the same just with "-A" and "-B" suffix, to be able to distinguish them then. Or using even number of weapons :| .

I'll take a look at this when I start with the C# combat code.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on March 19, 2017, 12:41:26 PM
Declaring a emergency! Would be nice to enroll civilian shipping in an emergency, make them transport refuges, needed infrastructure, give fuel to stranded ships, etc.

Some form of government conscription for civilian shipping, or forced loan, is possible. There would have to be some significant penalties involved though to prevent this being a standard option.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on March 19, 2017, 12:41:55 PM
An intel screen for enemy missile types similar to the ship one. It contains a log of the speed, warhead, sensor strength, size, etc of encountered missile types.

Good idea. Will add to C# Aurora when I get to the Intelligence options.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on March 19, 2017, 12:43:24 PM
Something small for a change. Could jump engines get a heading in the list of ship components at Class design screen so that they are clearly divided from normal engines? I have together over 20 active designs of them and this would help navigating that long list.

Already done for C# Aurora.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on March 19, 2017, 01:08:33 PM
Could closing pop-ups via X in the corner mean "NO" instead of "YES"?
Multiple times I misclicked and ordered refitting of my tanker (because his name is from A) to some other class. I am then asked if really want it with 400%+ refit price. I close the window via X, meaning "don't do it" but game takes it as "do it".

"X" treated as a default answer and default answer being "do nothing" would make more sense to me. See behaviour of "are you sure you want ot delete this file?".

Good point. I have just been through the C# code and replaced all instances of "If Dialog Result = No, then Abort" to "If Dialog Result != Yes, then Abort".

I've also written my own text entry popup, so that will not change the text unless press OK. Cancel or X will abort.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on March 19, 2017, 01:09:57 PM
Could _horizontal_ scrollbars be added to few areas with lists of components? The screen is divided there into several smaller panes and the important information is often in the end of row (differentiating code, hits left, repair value):
  • Population and production->Industry->Ship component stockpile
  • Individual unit details->Damage control->Damage allocation chart
  • Individual unit details->Damage control->Damaged systems
Repair value can be found as twice the cost in Class design but in overall this issue currently wrecks use of name of manufacturer before the name and code of ship component a bit. Yes, I am using 1280x800 laptop with Reduced Height Windows but the issue of just a bit too long names for these component lists is surely on other displays too. And trying to use short names of components just so they can fit in these places sounds like a less interesting option.

The screens are all being redesigned for C# Aurora and there is more space available, so these issues should no longer exist.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TheBawkHawk on March 19, 2017, 01:49:15 PM
I don't know if this has been suggested before, but a default order for cargo fleets to complete civilian shipping contracts would be nice.  I find myself using civilian shipping more than state shipping even though it's less efficient, just because it takes less management on my part.

Or perhaps adding a separate shipping contracts screen to use for state controlled cargo ships, so you could have your own cargo ships automatically transferring installations you list there.

I have no idea if any of this would be possible, but it would definitely help me at least.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on March 19, 2017, 04:18:54 PM
A screen with list of found ruins and list of civilization those ruins belonged.
AFAIK there currently is only a list of not yet exploited ones and once you clear all those there is no way to find about those old civs.

(https://s4.postimg.org/eyu0bivfh/A4x_Ruins.png)

 All columns should be sortable. For that may be good idea to merge System and Body or also divide Status into Status and Number of installations so that statuses can go: "not explored"-"exploration in progress"-"X/X installations"-"Y/X installations" (0 <Y < X)-"0/X installations".
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Tuna-Fish on March 20, 2017, 06:33:39 AM
How about for box launchers, separate the launchers in the assign window by whether they have already fired or not, and always sort the spent launchers to the bottom?

The typical way box launchers are used is either in a single volley, or then select a few launchers, fire them at the enemy, then select a few different launchers, fire them at a different enemy, etc etc.  For ships with ~20 launchers this is very comfortable, but when you build a big ship with 200 launchers, you have to scroll the list quite a lot.

Another request for box launchers would be to allow size-0 missile stages on the condition that they have a submunition stage and an endurance of 0.  This would allow multi-packing missiles to launchers, and make ships with, say, size 8 launchers a little more versatile as you could quad-pack size-4 missiles with sensors for anti-fighter work.  But that's more of a game design choice.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Nice Save on March 21, 2017, 05:37:19 AM
Quote from: Kytuzian link=topic=8107. msg94297#msg94297 date=1468954519
It would be pretty fantastic if we had a way to group together alien ships so that they didn't clutter the screen so many when in large groups.  Additionally (or alternatively), it'd be nice to be able to simply collapse large groups of alien ships that are in the same position without having to set up groups for the aliens, again to remove some clutter from the screen.  So if, for example, you had something like this:

It could collapse that group of civilian Fuel Harvesters to something simply like, "FH x9", and that group of spaceliners to "SS x15" (or however many there are), or, if both were in the same position, "FH x9, SS x15".

I'd like to see something like this, but actually condensing the task groups themselves into bigger ones.

At the moment I have over 100 civvie harvesters in Sol, split between Neptune and Saturn (I'm playing a conventional sun-warming start and subsidised them so heavily I had to use an auto-click macro).

My single 40kT tanker can keep up with their production since it holds 26 million fuel to their 0. 9 million, but setting up the orders takes forever.  It would be better if they were condensed once they get to the sorium source, since it seems like they never move after that point.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on March 21, 2017, 07:55:27 AM
Don't know if you have already done the civilian shipping - I was thinking about this system a bit and maybe you like this ideas I have.

In general the civilian shipping is a nice idea because if gives you an easy way not to have to arrange for those transports all by yourself - which would clog you up in way to much detail work. But it comes at the price of lack of control. When and how the civilians do these transports sometimes feels very random (and buggy).

So my idea would be the following: next to the tasks you hand out there would be a list of available civilian transports (sorted by vicinity to the source of the tasks) from which you can choose ships who then would perform the transport. By this you can prioritize certain tasks. And if you don't choose specific transports for the tasks then the auto-assign routine would at some point pick them up.

Additionally to this a second list could be there which lists all your available transports, from which you also could choose. That would then auto-create a transport job for them and not the civilians.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Silvarelion on March 21, 2017, 02:56:28 PM
It would be great if the Flight Crew Berths were an input (much like deployment time) rather than something you have to play around with to refine.  This would make designing carriers much simpler and quicker.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: smoelf on March 23, 2017, 11:54:44 AM
A ship module that can generate a temporary jump point to another system independent of existing connections. This can easily become "overpowered" in the sense of removing the need for logistics as well as jump drives and jump gates, but I think it can be balanced properly and provide interesting game play.

The module itself would need to be expensive and bulky and classed as a military component, so it would be impossible to employ those connections indefinitely due to high maintenance. It could also require a lot of fuel to activate. There could be a need for having two ships with that module in order to establish a connection, so an assault would require moving a ship to the enemy system undetected. Maybe it requires an activation time with a high EM emission resulting in the possibility that the enemy shoots it down before you jump through. It could get its own tech line increasing the efficiency regarding the size of ships that can jump through and how many at a time and perhaps how far away from each other the ships can be.

The idea is that you would be able to transport a number of ships over a large distance in a short amount of time in a way that drains a lot of resources and requires preparation.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Bremen on March 26, 2017, 02:15:38 AM
I just posted my ideas for beam/missile balance in the C# forum; this isn't really part of the actual balance part but rather a cool idea I had, so I figured it fit better here.

New weapon: Ion cannon. Works similarly to a laser, except does double the base damage with the same energy need. Does normal (which is to say, double) damage to shields, skips armor, and only rolls to hit weapons and reactors in the same way microwaves only roll to hit electronics.
If it hits a weapon, it reduces charge in that weapon on a one for one basis (1 ion cannon damage to 1 weapon charge), up to the max charge of the weapon (so if a laser has 3 out of 3 power stored, it becomes 0; if it already fired that increment and has 0 out of 3, it becomes -3 out of 3). Doesn't actually damage the weapon. If the ion cannon still has remaining damage, it rolls to hit another part.
If it hits a reactor, it makes the standard roll to damage, and (assuming a normal weapon would destroy the component) then rolls the reactor explosion chance. If it rolls an explosion, the reactor blows up, taking out the component and doing internal damage as normal. If it rolls that the reactor wouldn't explode, the component is undamaged. If the ion cannon still has remaining damage, it keeps rolling to hit other parts.

This would produce a weapon that was good against shields (a role that's kind of lacking in Aurora) and had fun effects against beam warships as well. Could maybe work on engines like it works on reactors if only damaging beam warships ends up too weak. Though that might be pretty brokenly overpowered, when you combine Laser level performance and armor piercing.

Similarly, I think it would be cool if when designing a beam weapon you could devote tonnage to additional capacitor (so that, say, a laser or railgun that needed 8 power to fire could store 24 power, then fire three times in sequential 5 second increments instead of waiting to restore back to 8 power; actual recharge rate would remain the same). Both these suggestions wouldn't mean much in the current version of Aurora but would be more useful if changes make beam combat more common.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TheRowan on March 27, 2017, 12:01:18 PM
Declaring a emergency! Would be nice to enroll civilian shipping in an emergency, make them transport refuges, needed infrastructure, give fuel to stranded ships, etc.

I'd also like to see the reverse of this - the option to loan your civilian ships to shipping lines (possibly in exchange for a higher share of their trading profits) temporarily. This would allow you to build defensively armed merchants to sprinkle in among the traders, and also give a reason to use Passenger Accommodation on your designs (I often build "Hospital Ships" with good thrust and moderate cryo facilities, and add passenger facilities on the RP idea that in peacetime they'd be used as liners)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Dreadder on April 07, 2017, 04:16:02 PM
Sorry if that was already suggested but it would be really nice if we could ferry crew and troops to space stations.  Now tugging the entire station to colony is the only way to replace battle losses and load troops, which seems a bit silly from a RP point of view.

Another suggestion regarding crews - how do you feel about the option to replace entire ship crew, crew rotation of sorts I suppose, instead of having to wait for the crew to finish their shore leave?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: HighTemplar on April 09, 2017, 03:43:38 AM
ok so I am on an old version so this may have been changed but please make missiles able to be < size 1
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: DIT_grue on April 10, 2017, 12:34:40 AM
ok so I am on an old version so this may have been changed but please make missiles able to be < size 1

It's never going to happen, unless you can suggest a superior mechanic for achieving the same goal. Because originally there was no such limit and abusive designs proliferated, leaving the AI entirely trivialised (among other undesired outcomes). A search can probably find old threads discussing it, if you're interested in the reasoning or the specific problems.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Michael Sandy on April 17, 2017, 02:36:49 PM
Is it possible to see which asteroids, planets, moons have had completed geo survey team planetary survey from the System map?  Cause I want to be able to quickly check which places I have already done geo survey, and remove them from my colony list to reduce clutter.

I suppose I could just rename the ones that have had geo survey team completed.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Erik L on April 18, 2017, 12:07:00 PM
Is it possible to see which asteroids, planets, moons have had completed geo survey team planetary survey from the System map?  Cause I want to be able to quickly check which places I have already done geo survey, and remove them from my colony list to reduce clutter.

I suppose I could just rename the ones that have had geo survey team completed.

Only way I know to do it is from the task force screen.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on April 18, 2017, 11:16:50 PM
Missile design option: picketing.
The affected missile stage behaves as normal, except that during design, a picketing missile stage can have a distance set. This will cause the missile to picket the designated target at a particular distance. This can be useful for active/passive sensor missiles that you want to follow a target around without getting into gauss range, or for spacemines that you want to follow a particular carrier/planetary body/etc.
Requires at least a specific amount of agility on the missile in question before it can be used (with agility being otherwise useless for any picketing missile design), and missiles that picket will use fuel per normal.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Drgong on April 29, 2017, 06:27:43 AM
Completely silly idea -

Space whales that you can preserve or hunt down for resources. 
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: sloanjh on May 02, 2017, 07:19:02 AM
Completely silly idea -

Space whales that you can preserve or hunt down for resources.

Did you just say "Whaaaaaaales innnnnnnn Spaaaaaaaaaace"? :)

John
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: swarm_sadist on May 04, 2017, 03:30:50 PM
Some random suggestions:

1. Have either a "Date Launched" or "Age" for commercial ships in the Shipping Line Information

2. If a population has 0 people due to radiation, I should not get messages saying that unrest is rising due to radiation. -_-

3. A way to order which civilian contracts have priority would be nice. Especially if you could reorder it later.

4. Civilian ships do not use fuel, so why are they clogging up the "Fuel Situation" section?

5. Have ship designs separated similarly to missile series, with either a player custom list or have a premade list. Ex: Civilian ships, government civilian, captured ships, military ships, fighters/parasites, PDCs, misc.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: SerBeardian on May 18, 2017, 10:35:24 PM
Rebalancing Box Launchers.

I've been embroiled into a rather lengthy debate on the balance between box launchers an Launcher+Magazine.

On one hand, Box launchers can hold 6MSP per HS of missile.  They can't externally reload, but they also can't explode either.  They also only die one by one, instead of dumping all your missiles if one blows up.

Unarmored Mags store a maximum possible 20MSP per HS, which sounds great, until you add the launchers in, which are 20x larger than a box launcher.

This leaves us with an issue that the same tonnage in boxes can have not only a larger apha strike, but can even compete in sustained fire by only linking some launchers at once.  This is made worse by the fact that box launchers can be researched really quickly, often well before max storage efficiency for magazines has been reached.

This leaves launchers with only the fact that they can be resupplied in-flight by small colliers as a solid advantage (which, granted, C# will help with).

I propose that Box Launchers have a significant chance, when destroyed, of causing the loaded missile to detonate. Ejection chance can perhaps reduce this, but it should be significantly higher than magazines (100% at no reduction, maybe 25% at max reduction).

Fighters, which probably can barely handle the hit that just shot them, won't really care that the box launcher also blew up.
But it will no longer be viable to put 5000 tons of box launchers all over a 7000ton ship and have it outcompete a 7000ton launcher-based ship.
This will also provide a better choice between launchers and boxes, as you still can pack 5000t of boxes into a 7000ton ship, just don't expect it to survive if it gets shot at.  Or you can have the added safety that proper magazines and well-designed launchers provide.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Bremen on May 18, 2017, 11:10:52 PM
Rebalancing Box Launchers.

I've been embroiled into a rather lengthy debate on the balance between box launchers an Launcher+Magazine.

On one hand, Box launchers can hold 6MSP per HS of missile.  They can't externally reload, but they also can't explode either.  They also only die one by one, instead of dumping all your missiles if one blows up.

Unarmored Mags store a maximum possible 20MSP per HS, which sounds great, until you add the launchers in, which are 20x larger than a box launcher.

This leaves us with an issue that the same tonnage in boxes can have not only a larger apha strike, but can even compete in sustained fire by only linking some launchers at once.  This is made worse by the fact that box launchers can be researched really quickly, often well before max storage efficiency for magazines has been reached.

This leaves launchers with only the fact that they can be resupplied in-flight by small colliers as a solid advantage (which, granted, C# will help with).

I propose that Box Launchers have a significant chance, when destroyed, of causing the loaded missile to detonate. Ejection chance can perhaps reduce this, but it should be significantly higher than magazines (100% at no reduction, maybe 25% at max reduction).

Fighters, which probably can barely handle the hit that just shot them, won't really care that the box launcher also blew up.
But it will no longer be viable to put 5000 tons of box launchers all over a 7000ton ship and have it outcompete a 7000ton launcher-based ship.
This will also provide a better choice between launchers and boxes, as you still can pack 5000t of boxes into a 7000ton ship, just don't expect it to survive if it gets shot at.  Or you can have the added safety that proper magazines and well-designed launchers provide.

I like this idea. It doesn't make box launcher warships obsolete, but you would definitely want to get off the first shot  :P

I'd been thinking about limiting the number of box launchers based on exterior hull size (Which the game already calculates for armor purposes) but I think I like your idea better.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on May 20, 2017, 03:18:31 AM
Another approach to making other launchers competetive with box launchers is to make it so no launchers actually store missiles anymore, and have box launchers load directly from magazine (but only can fire once before requiring an external reload).
The idea being that the magazine can be abstracted as also including the place where missiles are actually stored in the launcher
For clarity, how it currently works in VB6 aurora:

Quote
Normal Launchers -
(75% efficiency) Size 5 Magazine: 75 MSP
Size 5 Missile launcher at 5 HS, stores 5 MSP
Total HS: 10
Total Firepower: 1 per salvo
Total Sustained Firepower: 16, low cooldown.

Box Launchers -
Total Firepower: 14
Sustained Firepower: 14, instant.

How it works in the new system were all storage is now magazine only:

Quote
"No launcher storage" normal launchers -
(75% efficiency) 75 MSP magazine at 5 HS
Size 5 Missile launcher at 5 HS
total HS: 10
total firepower: 1 per salvo.
Sustained firepower: 15, low cooldown

Whereas the "no launcher storage" box launchers -
9 size 5 box launchers = 6.75 HS
45 MSP magazine is 3 HS
total HS: 9.75
total firepower: 9
sustained firepower: 9, instant.
This has several effects.
-General missile capacity is very marginally nerfed. Very slight, easily ignorable threshold.
-Magazine efficiency techs now effect box launchers, and as a result, box launchers become more size efficient the better your tech gets rather than stagnating as "exactly the same as it always is."
-Box launchers are nerfed, as are reduced launcher techs, in the sense that they simply no longer render full sized launchers almost obsolete by outclassing them in every meaningful way besides one (which it barely stands to match anyway). This is a slightly less applicable point, with the upcoming logistics update, but the fact that launchers carry vastly more power, flexibility, etc in roughly the same tonnage is a bit... overbearing.
-Armored magazines now have enough elbow room now to be considered potentially useful. You can even armor box launcher magazines to make the capacity line up the MSP with the amount of launchers you want on a particular vessel.

The exact direct mechanical change would be:
-Set the mag capacity of any launcher in of itself to 0.
-Everything would otherwise behave the same, though maybe make the ship maker pop an error if magazines have insufficient storage to fire a missile out of every single launcher once.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on May 21, 2017, 09:58:18 PM
Another suggestion, this time concerning Ablative Armor and the intelligence menu.
I remember Steve mentioning that missiles use ablative armor as an extra chance to ignore point defense, contested by the point defense's sheer damage.

Could we make it so that if any of our point defense systems fail to kill a missile at this step (that is, we score an "accuracy" hit, but the "armor" check allowed the missile to ignore it), that it is reported as "this missile is armored" in the racial intelligence window and event logs?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: bean on May 24, 2017, 11:22:44 AM
This leaves us with an issue that the same tonnage in boxes can have not only a larger apha strike, but can even compete in sustained fire by only linking some launchers at once.  This is made worse by the fact that box launchers can be researched really quickly, often well before max storage efficiency for magazines has been reached.
This isn't quite true.  There are some use cases where conventional launchers really dominate, and reduced-size launchers can go quite a ways to even the balance. 
For missile defense, box launchers are the way to go if your enemy is launching lots of missiles and your fire control only gives you a few increments to shoot at them.  But if you have long-range AMMs and FCs, then it starts to turn into a contest of who has more missiles, particularly if they didn't go for box launchers themselves.  In that case, normal launchers carry at least 50% more missiles.
For attack, reduced-size launchers help a lot.  If my design case is needing to fire two salvos of 24 size-4 missiles an hour or more apart (let's assume I'm going for really long range or something), then 25% reduced-size launchers will take 24 HS for the launchers plus something like 6 HS for the magazines.  Box launchers will take 32 HS.  Adding a third salvo will take 16 HS for the boxes and 5-6 HS for the conventional launchers.  Obviously, I'm giving up the capability to combine my salvos, but in addition to the efficiency gains, I'm getting collier reload capability.  For bigger ships, that's a big deal.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on May 26, 2017, 05:00:11 PM
Suggestion - Change ship ramming to include some combination of the following:

- Limit the ram damage to 10-30% of the max armor points mounted on a ship.
- Make it so ships making a successful ramming maneuver instantly scuttles, or instantly destroys their own engines with the normal explosion chance rolls.
- Make it so ramming maneuvers have a range of 0, so that the only times a ramming maneuver can normally succeed is if the ship performing it has both superior initiative and movement speed.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: MagusXIX on May 26, 2017, 05:42:18 PM
Time advancement buttons on the event log would be nice. Currently I have to switch back to the map window to advance time, and then try to switch back to the event log while the program is running so that I can track the events as they scroll by. This wouldn't really big a big problem if the event log didn't keep having the tendency to hide behind the map at random while time is running.

Maybe most people don't hover over the event log as time is going by and I'm just weird, but it's the best way I've found for me to keep track of things as they're happening. Like I said, though, while time is processing the window likes to hide behind other windows. It's frustrating to no end.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Erik L on May 27, 2017, 01:54:24 AM
Time advancement buttons on the event log would be nice. Currently I have to switch back to the map window to advance time, and then try to switch back to the event log while the program is running so that I can track the events as they scroll by. This wouldn't really big a big problem if the event log didn't keep having the tendency to hide behind the map at random while time is running.

Maybe most people don't hover over the event log as time is going by and I'm just weird, but it's the best way I've found for me to keep track of things as they're happening. Like I said, though, while time is processing the window likes to hide behind other windows. It's frustrating to no end.
Run one increment at a time?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on May 27, 2017, 01:58:00 AM
Or split windows.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on May 27, 2017, 02:50:30 AM
If you're running windows 10, I noticed that using the Virtual Desktop feature is really helpful.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on June 01, 2017, 04:03:41 PM
Should be an easy suggestion:

Can we have a better way to delete and/or merge task groups?

Because I have ~30 terraformers I'm towing around one at a time right now.  Once they're all at their destination, they all end up in their own task groups, which I have to merge manually one at a time.  This then leaves me with 29 empty groups to delete.  So my idea is two new buttons; a "Merge TG's at this location" button, and a "Delete empty TG's" button.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on June 01, 2017, 04:06:45 PM
Should be an easy suggestion:

Can we have a better way to delete and/or merge task groups?

Because I have ~30 terraformers I'm towing around one at a time right now.  Once they're all at their destination, they all end up in their own task groups, which I have to merge manually one at a time.  This then leaves me with 29 empty groups to delete.  So my idea is two new buttons; a "Merge TG's at this location" button, and a "Delete empty TG's" button.
Does the "absorb task group" command work, or is that one bugged? If it isn't bugged with terraformers, you can have a single terraformer TG just absorb every other on in the same position from the task groups orders tab.

Naval organization, could also do this, if I'm not mistaken. It's a little tricky though, and requires some experimenting.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Garfunkel on June 01, 2017, 05:29:29 PM
Absorb TGs does work. You can also use Naval Organization tab to set the TG group and Aurora will automatically delete all the empty TGs after the next industrial cycle, I believe. Third method is to go to ship screen and manually move the terraformers into a single TG - you can just switch the second TG shown to do it fairly quickly and again let Aurora disband the empty TGs later.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Silvarelion on June 01, 2017, 05:44:55 PM
What I just started using is the Combine Task Group button on the special orders tab of the task group window. Quicker than the absorb order, and no pesky unfilled tasked groups to be deleted. If I'm tugging around a lot of ships (like my terraforming fleet) then I use the navel structure tab. One click and it's a single task group. Easy, as long as you stay on top of your navel organization.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on June 02, 2017, 01:24:11 AM
Naval organization, could also do this, if I'm not mistaken. It's a little tricky though, and requires some experimenting.
Yes. Once you have all those terraformers together, use "Organization branches - Add" and "Assign ships - Add TG" or you can use "Assign ships - Add Ship" to add them one by one. Once you transport them to one area, even with multiple TGs, select the branch and use "Create TG - Branch only" to put all terraformers into one TG. Just note this checks for members of given branch only in the spot of currently selected ship so you need to first select one of those terraformers.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Resident Evil on June 02, 2017, 03:23:00 PM
Hi

Got one, maybe two suggestions, and as I'm new here, forgive me if they've already been made.

1st. On the Class Design screen, would it be possible to have a Protected checkbox, maybe below 'keep excess Q' to prevent accidental deletion of a design. Every time I delete a design, I'm always double or triple checking because it's unrecoverable.

2nd. Maybe this is possible and I can't see how to do it, but a way to make carriers scoop fighters rather the fighters land on the carriers, if you see what I mean. The particular situation I have is using engine-less fighters as gate defense satellites and wanting to recover them for maintenance and crew rotations.

3rd. Alphabetical order on some of the menu's would be nice, ie lists of planets (especially asteroids), the OOB screen and others. It would just make things that bit easier to find particular items in a couple of cases.

Thanks
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on June 04, 2017, 01:17:53 AM
Perhaps a cool idea would be to allow asteroids to periodically spawn anomalies, as well? Using a separate chance as to not reduce the chances of planets doing so.
The main reason for doing so being offering a cool rare opportunity that requires significant investment in the form of 0 gravity or orbital infrastructure to truly exploit. And almost-deep-space science stations as cool, too.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on June 04, 2017, 11:04:01 AM
Could the initial screen where you pick which game you want to load and which game settings to use be made into a proper window that shows on taskbars, please?

Just too often I start Aurora, click on some other application and then need to carefully minimize multiple windows and hunt for the starting screen. If it was located on the taskbar (as other Aurora windows) I could easily select it there.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on June 04, 2017, 12:41:16 PM
Another little helping idea: when new scientist arrives, show his/her speciality even when their bonus is at 0%. If I am missing one type of scientist I would not have to go to research screen to find who this new guy is and if I should assign him/her a lab to start the training or if it is another biology enthusiast.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on June 05, 2017, 06:23:16 AM
A multi-suggestion to potentially encourage stealth tactics and to allow non-deathball strategies to strive:

A special upgrade to sensors that are only available for larger passive designs, such that every 5 day tick, after normal detection, these upgraded passive sensors (thermal and EM) make a check against all sources of signatures (detectable or not) where:
Distance from contact < (Total signature strength of all contacts currently not seen using normal passive detection)*sensor strength * 1000km.
For every emission source that passes this check, the game takes the mean of all bearings of these sources, weighted based on emission strength, modified by range, and checks for all ships within an angle from this mean.
If there are ships within this bearing range, a check is made, going:

(Total sum of all signatures within angle)*sensor platform sensitivity *1000km...

Where was I going with this? Scrub it. Lemme start over.

A special upgrade for passive sensors that can only be applied to larger sensor systems.
Every 5 day cycle, the sensor makes a check against all contacts within the system with 10 billion kilometers (or just checks all if that's theoretically faster for game performance)
Contacts outside of normal detection range generate a "subsignature" on this cycle that isn't directly reported or view-able.
At this point, the game checks all ships that have a tight grouping of bearings from the sensing ship, and adds all their signatures together.
If any of the contributing ships ends up being within:
Code: [Select]
Sensor sensitivity * cumulative signature strength * 1000kmdistance from the sensor platform, rather than generating a sensor contact, the game makes a special contact at the sensor platform's position on detection (viewable only by the owning race of that sensor platform), and it reports the average bearing used in the previous calculations, as well as the cumulative signature strength. Lost contacts would allow you to view old reports of this kind.




Anyway, on to the second idea:
-Make base ECM stronger
-To compensate, make it so that ecm is significantly mitigated by having multiple active sensors viewing the target. The effect is 0 when the sensors are at or near the same angle from the target, but increase if the ships doing the sensing are surrounding the target from different angles.

Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on June 05, 2017, 10:44:57 PM
Follow-up to iceball3's idea:

Not only should contacts be easier to detect if multiple sensors are observing them from different angles, but they should be easier to pinpoint, meaning better accuracy.  Perhaps improve fire-control range or beam fire control accuracy on targets painted from multiple directions?  Triangulation is a powerful thing, so is parallax.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Senji on June 08, 2017, 08:56:30 AM
Some multilanguage support will be good :)

Sure an english game is a good training for my poor english but i know some player how dislike playing game aren't in french.   
It's a big job because your need too modify the code but for the translation some guys (and girls) will help.   


And sorry again for english ^^

NB : Adding the possibility to choose the type of ship the civilian line can build (example no harvester but OK for colon and freighter)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on June 09, 2017, 11:04:13 PM
Could Fleet message automatically say the name of TG that has sent it?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on June 11, 2017, 01:03:19 PM
Intelligence screen: move Trading to the bottom of List of treaties as tech sharing needs more diplomacy points than geosurvey and gravsurvey.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on June 18, 2017, 09:33:46 AM


Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on June 18, 2017, 04:18:59 PM
Make jump gates a ship module.  I'd make them huge, so they would be hard to move, and I would not allow any ship with them to have engines, so they cannot move under their own power.

This would be a lot more realistic for a few reasons.  First of all, they'd be destructible.  Second, a station with a jump gate could have other equipment too; sensors to monitor the gate, fuel to refill transiting ships, maintenance modules to repair ships, maybe weapons to guard the gate.  Third, they'd be very expensive, instead of the current gates, which are free.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on June 19, 2017, 12:10:18 AM
Make jump gates a ship module.  I'd make them huge, so they would be hard to move, and I would not allow any ship with them to have engines, so they cannot move under their own power.

This would be a lot more realistic for a few reasons.  First of all, they'd be destructible.  Second, a station with a jump gate could have other equipment too; sensors to monitor the gate, fuel to refill transiting ships, maintenance modules to repair ships, maybe weapons to guard the gate.  Third, they'd be very expensive, instead of the current gates, which are free.
So you would build them in a normal shipyard and then use tugs to get it to JP? That sounds like current mobile jump gate designation, just a tender with both commercial and military jump engines. The only difference would be shipping lines could go through too. But what if it moves or gets destroyed while they are already on the way? If you make all jump gates movable you need to also rewrite how NPRs and shipping lines react to their ships getting stranded on the other side. I guess this not-too-big change could lead to big rewrites.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on June 19, 2017, 11:46:10 AM
I'd make them absolutely gigantic, maybe 20,000HS or more, so they pretty much have to be made in factories, using the orbital habitat build rules.

Maybe add an order for "install jump gate" for vessels with the jump gate module when at a jump point.  This would lock the gate in place, and then the AI could use their pre-existing jump point pathing.

Another advantage I thought of is that the gates would no longer be neutral.  Your enemies would not be able to use your jump gate network; not without capturing the gates at least.  Could make boarding attempts more worthwhile.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Garfunkel on June 21, 2017, 08:14:39 PM
Originally we had to build jump gate components and use those to build the gates but the gates themselves were not actual structures.

Building jump gates via factories and then tugging them to place is a great idea, especially if it's possible to use Marines to board and capture them. That would certainly make Marines vastly more useful than they are currently, where they only exist as the niche of a niche. It would also create one new level of diplomacy, of allowing friendly races/nations to use your jump gates and vice versa. We could still find old, abandoned jump gates but now we'd need combat engineers or construction brigades to activate them.

There should be some sort of delay before a jump gate activates after being moved to a jump point. Perhaps the jump gate construction tech line could be readjusted for that, shortening the time required to start it up once on location.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: DIT_grue on June 22, 2017, 12:00:45 AM
Bleh, no. I prefer a second stable configuration that Jump Points can be nudged into, no megastructures required.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on June 22, 2017, 11:31:08 AM
I think I've got it!

All "orbital habitats" should be built in pieces by factories, much like PDC's can be.  Then, they can be assembled on-site by construction ships, instead of being tugged into place.

This would allow the new jump gates to follow all the same rules as every other orbital habitat.  It would be realistic; our largest space station in real life, the ISS, was assembled piece-by-piece by "construction ships".  It would allow us situations like the second Death Star; fighting over an incomplete station.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Frank Jager on June 22, 2017, 01:05:59 PM
@Steve Walmsley

TL/DR Make Kinetic weapons useful, add an workable? ammunition component into the game.

I've searched the current forums and cant seem to find the discussion on why Kinetic Weapons don't have an ammunition requirement.
I feel that all Kinetic Weapons, (Rails and Gauss) should have an ammunition requirement leaving the true energy weapons (Lasers / Particle / Meson / Microwaves) with the current restrictions.

I propose a change to the weapons mix that I hope is easy to implement.


Kinetic Weapons  {Signifies real world counterpart}
Railguns                        {105mm Howitzers}
Turret-able, long range (Max BFC), slow reload, single shot, same damage profile, capacitor rate doubled

Gauss Cannon               {40mm Cannon}
Removed as CIWS, doubled range.               

Auto Cannon                 {Gatling Style Rotary Cannon}
Replaces CIWS Components, Max Size 1HS, 75% 50% 33% 25% Reduction techs, Baseline 10 shots per increment (120 RPM), double and triple fire rate techs.  Max Range 10km, base racial tracking speed or max ship speed.  Turret-able

Other Weapons
NO CHANGE

I feel this would further reduce the effectiveness of missiles, and give fighters a cannon to use against other fighters as close quarters (Dogfighting) this would also slightly increase the protection offered to Civilian ships.

As for the ammunition requirement, make its production similar to how MSP is produced in 7. 1 VBA.
Small 1 Missile Size Point containers with a 1 duranium cost produced in construction factories and stockpiled.
This fits nicely into the current magazine system, the tradeoff being that you can use energy weapons without magazines.
You would need to transport all kinetic ammunition around in magazines, which should be easier to do now there is a civilian magazine.  CIWS has a drawback in that it can be simply run out of ammunition and no longer be effective.  An advantage would be that the system is that CIWS would be twice as effective at base tech.

We simply deduct 1 Ammunition Crate per increment that the weapons are firing, including for CIWS weapons.  This is because rounds themselves are simply different sized strips of metal for each weapons system and they all have different fire rates.  I am unsure of proposing another tech line for reloading speed as i feel this is not necessary with the increment delay.

It doesnt make sense to me that civilian ships can have CIWS missile defenses but not have to pay any cost for the systems.

This would allow for a larger missile defense envelope allowing up to 5 ranges to engage missiles, AMM>Laser>Gauss>"Auto Cannon">CIWS

AMM would be as far out as missile design allowed.
Laser range is still out to 1. 4m km allowing for Light Speed limitations
Gauss Cannon range is doubled out to 20km at base and 120km at final tech
Auto Cannons are at Final Defensive Fire Range
CIWS are still at point blank.

This will allow more missiles to be destroyed short of their targets, but add in a strategic/logistical layer meaning that these weapon systems can be beaten by running the defending ships out of ammunition.

Railguns & Gauss would then be able to penetrate atmosphere and can be used within PDCs to defend a planet / system body, without using missiles.  This will make planetary assaults more challenging.

Because Railguns would be able to penetrate atmosphere they would still have an energy requirement but the capacitor recharge rate should be doubled, allowing for the fact that they will have a ammunition requirement.  This keeps them competitive with similar tech laser weapons as they can fire twice as fast, until they run out of ammunition.

Close Quarters Battles would then have more options than "Just stick big lasers on it".

Thoughts anyone?

Regards

Frank
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on June 22, 2017, 01:21:00 PM
I don't think this will change much of anything in any particular battle, especially in the case of missile defense.  Because missiles are much larger than bullets, it will always require more magazine space to carry X number of missiles than it will to carry the number of CIWS rounds needed to defeat X missiles.  Basically there are no reasonable scenarios where you run out of PD rounds before they run out of missiles.

In general, I don't believe it will change much because if it is realistically scaled, ships will carry such a ludicrously large amount of ammo that they'll never run out during a single battle.

All I see this really changing is fighter vs fighter combat, and adding logistical overhead.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Frank Jager on June 22, 2017, 03:33:00 PM
@Barkhorn

Even if this only changes fighter v fighter combat and adds a logistical overhead, id be excited.

Each CIWS has a 50% base chance toHit the new CIWS would fire 10-30 rounds per increment, the old system could fire 1-6 rounds per increment, that means in a salvo of 7 missiles one is always guaranteed to hit in VB6, potentially all 7 could get through without being engaged.  My system would mean that an 11 missile salvo would be needed to guarantee a hit, with the same possibility of all 11 getting through.  This is all per CIWS.

You could use a single missile salvo on targets you have identified as having PD forcing the CIWS to use 1 Ammunition Crate on only a single missile.  If there are multiple CIWS and they all fire this will increase the ammunition consumption.  Using a Size 1 Missile this creates an like for like scenario where the ship with the deepest magazine wins, like VB6 Aurora.

Alternatively you could then disengage, or force the other ship into direct combat.

The point is to make all the weapons in Aurora into more of a rock, paper & scissors fight where each system has its owns strengths and weaknesses.  I dont believe that CIWS should be able to fire at the same rate for the entire duration of the ships life without some additional drawbacks.

Regards

Frank
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on June 22, 2017, 09:55:38 PM
@Barkhorn

Even if this only changes fighter v fighter combat and adds a logistical overhead, id be excited.

Each CIWS has a 50% base chance toHit the new CIWS would fire 10-30 rounds per increment, the old system could fire 1-6 rounds per increment, that means in a salvo of 7 missiles one is always guaranteed to hit in VB6, potentially all 7 could get through without being engaged.  My system would mean that an 11 missile salvo would be needed to guarantee a hit, with the same possibility of all 11 getting through.  This is all per CIWS.

You could use a single missile salvo on targets you have identified as having PD forcing the CIWS to use 1 Ammunition Crate on only a single missile.  If there are multiple CIWS and they all fire this will increase the ammunition consumption.  Using a Size 1 Missile this creates an like for like scenario where the ship with the deepest magazine wins, like VB6 Aurora.

Alternatively you could then disengage, or force the other ship into direct combat.

The point is to make all the weapons in Aurora into more of a rock, paper & scissors fight where each system has its owns strengths and weaknesses.  I dont believe that CIWS should be able to fire at the same rate for the entire duration of the ships life without some additional drawbacks.

Regards

Frank
Missiles already got slapped into the dirt with the most recent update logs, and gauss was already "good enough" under the previous paradigm.
AMMs already take up the niche of "logistics-intensive anti-missile system" anyway, and tracking miniscule metal fragments that could be anywhere from a pound to a few grams apiece seems a bit unnecessary, all things considered.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on June 22, 2017, 10:05:20 PM
I would say it is a decent idea for a mod but I would not put kinetic ammo in the vanilla game.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on June 23, 2017, 11:02:39 AM
People already fire lots of single-missile salvos, with the aim of overwhelming their opponent's fire control capabilities.

I don't hate the idea; I actually really like it for fighters.  Maybe make a Gauss tech that lets you make a super-small yet still fairly accurate Gauss cannon, the drawback being that after X number of firings, it has to be reloaded in a hangar.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on June 23, 2017, 02:39:54 PM
People already fire lots of single-missile salvos, with the aim of overwhelming their opponent's fire control capabilities.

I don't hate the idea; I actually really like it for fighters.  Maybe make a Gauss tech that lets you make a super-small yet still fairly accurate Gauss cannon, the drawback being that after X number of firings, it has to be reloaded in a hangar.
Do you mean you would like to have the option to have flock of little gauss cannon-like weapons against few-missiles-lots-of-salvoes tactics?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on June 23, 2017, 02:43:39 PM
I was thinking to emulate the fact that basically all fighter aircraft nowadays have both missiles and a cannon.  The missiles are the primary armament, but if all else fails they can switch to guns.

What you use that for is up to you.

Might be kinda strange that, given enough time your fighters could kill battleships with what amounts to a machine gun.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on June 23, 2017, 02:53:34 PM
Might be kinda strange that, given enough time your fighters could kill battleships with what amounts to a machine gun.
Battleships should have enough weaponry, shielding and smaller friends around to not allow that.
On the other hand, yes, one machinegun could be all you need to capture an unguarded tanker or freighter.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on June 23, 2017, 03:53:27 PM
I think his point is the damage should be too low to do anything appreciable to the armor given its thickness.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on June 23, 2017, 08:25:06 PM
Got another suggestion.  Maybe its better considered a bugfix, but I don't know.

Currently, if you have a task group of mixed military and commercial ships, its difficult to get them to transit a jump point; for instance cruisers and their accompanying tankers.  They complain about not having a jump engine large enough, even if the tankers have their own jump engines.  You usually end up having to detach the tankers, have both groups transit individually, then reform the task group.  This makes traveling to a destination thats several jumps away a big micromanagement headache, since you can't queue up the entire trip at once.

My proposal is to have all ships use their own jump engines if they have them when you issue the "standard transit" order.  "Squadron transit" should remain unchanged.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Frank Jager on June 23, 2017, 10:06:58 PM
Quote from: iceball3 link=topic=8107. msg103236#msg103236 date=1498186538
Missiles already got slapped into the dirt with the most recent update logs, and gauss was already "good enough" under the previous paradigm.
AMMs already take up the niche of "logistics-intensive anti-missile system" anyway, and tracking miniscule metal fragments that could be anywhere from a pound to a few grams apiece seems a bit unnecessary, all things considered.

TL/DR I think its a tradeoff, make PD more effective but limit its use.  Missiles should only be a long range / first strike weapon and should have multiple strong counters.

In my opinion Missiles haven't been "Slapped into the dirt", they have been turned into what they should be I. E.  the primary long range armament of a space going ship, incremental missile sizes don't really change much of the status quo, only real difference to missiles that I can spot is that they wont have super ranges because of increased fuel usage, unless you build multi stage missiles which at least for the first stage will have to be slow.

I don't accept that Gauss Cannons are "good enough" I see it as trying to be two seperate weapons systems and failing at both.
I'm proposing to make a smaller system with its own inherent weakness, and actually make Gauss stronger for its size.

AMM's are one "logistics-intensive anti-missile system", but what if i wanted to play without missiles entirely? I should have missile defense systems that provide no drawbacks through the lifespan of a ship that simply its cost and how much tonnage it requires? C# Aurora should be more than capable of adding some variety into the weapons mix.

At no point did I suggest that the game tracks any of the above, it would simply tie into the current "5 Second Lightspeed" rule and all shots fired / damage / misses, would be displayed for that increment exactly the same as it does now for Gauss / Railguns, it simply adds an additional requirement in the code that checks for ammunition present in the ship after checking weapon damage, readiness, crew grade.  Tracking "Miniscule metal fragments" through space is completely unnecessary I wholeheartedly agree

No-one seems to be commenting on the changes to Railguns, so I'm assuming that no-one cares about having a replacement / alternative to Laser techs.

@Barkhorn
If you allow a fighter however armed to approach within 10k of your battleship and allow it to fire for long enough to penetrate the Armour then you my friend need to redesign you ships, Missile PD alone should be sufficient to destroy a group of Fighters at that range, hell even if you only mounted the same "Auto Cannons" as they did you should come off better as you will probably have more weapons per craft, they will both only fire at the minimum combat range (10km) which is the proposed MAX / only combat range these new cannons will allow, to track anti-ship missiles of a similar tech you will need a faster tracking speed than any fighter is capable of, and they will blow up as most fighters dont carry a huge amount of armour or HTK and these weapons are supposed to spit out 10-30 damage per increment (Over 10-30 individual shots).  I have yet to design a fighter that can take that sort of punishment.

My suggestion remains just that a suggestion for the community and Steve to consider and comment upon I value your comments but fear that some of you may not have read my huge wall of text.

I don't seem to actually be able of writing short posts  :)

Regards

Frank
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on June 23, 2017, 10:30:24 PM
Frank

I think its strange that machine guns could even conceivably do it though.  I didn't really mean that autocannon fighters killing BB's was a reason this idea shouldn't be implemented.  In fact, the more I think about it, the more I like it.  Ships should have some external parts, which could be disabled by these autocannons.  Really it doesn't make a lot of sense that turrets, sensors, engines, and missile launchers can be completely within the armor.

In WW2, fighters would often perform AAA suppression on enemy shipping by strafing the open-topped gun turrets to cover the bombers' approach.  The bridge, signalling equipment, radar, and fire control were also vulnerable.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: chrislocke2000 on June 25, 2017, 11:51:22 AM
For amm missile fire Chris control settings on think it would be useful to be able set both a minimu and a maximum engagement range so as to avoid the current situation where amms will fire when there is no actual time for them to intercept and are hence wasted. That should help with designing and setting a layered defence.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on June 27, 2017, 07:08:34 PM
Add two more sizes of beam fire controls: 0.75x and 8x.

Alternatively allow all sizes between 0.25x and (5x or 10x ?) in 0.25 increments.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on June 27, 2017, 11:50:37 PM
Add two more sizes of beam fire controls: 0.75x and 8x.

Alternatively allow all sizes between 0.25x and (5x or 10x ?) in 0.25 increments.
How about doing away with discreet sizes entirely and just let us type in numbers?

If I want a 3.1915926HS sensor, let me.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on June 28, 2017, 02:30:26 AM
Thats actually something I would like to remark upon.  I think that if the player wants to make an absolutely gigantic piece of hardware to do a job, then they should be allowed to do so.  Essentially, compensating for their lacklustre technology with sheer scale and cost.  It would make things a lot more potentially interesting I think.  If trying create machinery well above what you should be capable of results in dminishing returns, then after a certain point you would be defeated by an equivalent economy building lower tech equipment.  On the other hand, it would let you vaguely try to defend yourself against the attention of much more advanced empires.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on June 28, 2017, 02:47:34 AM
Thats actually something I would like to remark upon.  I think that if the player wants to make an absolutely gigantic piece of hardware to do a job, then they should be allowed to do so.  Essentially, compensating for their lacklustre technology with sheer scale and cost.  It would make things a lot more potentially interesting I think.  If trying create machinery well above what you should be capable of results in dminishing returns, then after a certain point you would be defeated by an equivalent economy building lower tech equipment.  On the other hand, it would let you vaguely try to defend yourself against the attention of much more advanced empires.
Sooo... what about any number between 0.1x and 10x as a size multiplier here?
So that you can get anywhere from 0.01 HS to 100HS with combining size for range and size for speed?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on June 30, 2017, 12:33:19 PM
I'd like to make a few suggestions about asteroid miners.

Currently they're a huge head-ache to use.  There is no default or conditional order to automate them.  The "move to mineral source" default order is not smart enough to only consider asteroids; your miners will happily fly to moons and then just sit there confused.

Worse yet, it seems miners can only mine from bodies that have colonies on them, and these colonies have to be made manually.  And then your colony list will get cluttered with dozens of asteroid mines.

The worst part though, is just how slowly they actually mine once they're actually working.

These three factors combine to make AM's just not worth it.  Its much easier to just explore more and find planets or moons with far more resources than even a hundred asteroids would have, and that you can focus several hundred automated or manned mines on.

So to solve these problems, here's some suggestions;

1) Make asteroid mining modules work much faster.  Perhaps make it depend on the size of the asteroid.  Smaller asteroids mine faster, since the ore deposits cannot be as deep.

2) Make asteroid mining ships automatically create colonies when they stop at an asteroid with minerals.  Perhaps automatically delete these colonies once the mining is complete and the minerals have been picked up.

3) Either make the "move to mineral source" default order only consider asteroids or add a new conditional that does so.

4) Add a conditional order that executes an order template.  This will allow us to essentially make our own conditional orders.  This is helpful for the asteroid miner situation because it will allow us to automate having a freighter follow the miner around, and when its full, drop off the minerals at Earth, then return to the miner.  I'm sure there are more situations this would be useful in as well.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Havear on July 05, 2017, 06:27:34 PM
Some fellow players and I were discussing the planned Plasma Lance for 7.2 and had a couple of suggestions. (This rolls with an earlier suggestion of mine making plasma carronades ignore atmosphere so beam bombardment presents another option. I also habitually refer to particle beams as particle torpedoes, since they 1) used to be called  that 2) have a torpedo-like footprint and 3) have an advanced form in plasma torpedoes like advanced lasers and advanced railguns)

With the addition of the Particle Lance (and Spinal options for lasers) we've got a few options for customizing beam weapons. Why not take that slightly further? Plasma Carronades as their own weapon system can be dropped in favor of a Particle/Plasma Carronade option on Particle Torpedoes that increases damage several ticks (like Spinal and Advanced Spinal) while slashing range. Railguns and Gauss Cannons could also conceivably rolled together into a single system, with something something like a unified "Kinetic Launch Velocity" and "Kinetic Payload Count", with Launch Velocity being a straight carryover of Gauss/Railgun Launch Velocity and "Kinetic Payload Count" not only adjusting Gauss RoF, but potentially Railguns shells fired in one volley. The Gauss module for Railguns would thus disable power requirements while reducing damage and range, or some other arrangement.

The main thrust is reducing the total beam weapon trees required while making individual choices more flexible.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on July 05, 2017, 10:26:12 PM
A suggestion regarding long voyages.

Specifically what I'd like to be able to do is select a TG and order it to go to a specific system.  I don't like that I have to do all the pathfinding myself.

If we had the ability to order a TG to move to a specific system, combined with the custom conditional orders I suggested above, we could totally automate interstellar mineral, MSP, and missile shipments, all of which right now are a bit of a hassle.

Basically I'm just tired of specifying every single jump on a voyage that's possible dozens of jumps long.  Its especially bad for long range gravsurvey ships, which are almost always taking the longest trips in your empire.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TheBawkHawk on July 05, 2017, 10:54:03 PM
Quote from: Barkhorn link=topic=8107. msg103438#msg103438 date=1499311572
A suggestion regarding long voyages.

Specifically what I'd like to be able to do is select a TG and order it to go to a specific system.   I don't like that I have to do all the pathfinding myself.

If we had the ability to order a TG to move to a specific system, combined with the custom conditional orders I suggested above, we could totally automate interstellar mineral, MSP, and missile shipments, all of which right now are a bit of a hassle.

Basically I'm just tired of specifying every single jump on a voyage that's possible dozens of jumps long.   Its especially bad for long range gravsurvey ships, which are almost always taking the longest trips in your empire.

I know it's not exactly what you're asking for, but there's something you can do that's kind of like this.

If you create a colony in a system near where you want to send your fleet, you can tell your fleet to go there and they'll automatically pathfind to it.  Make sure you have "Show All Pops" checked or you won't see the colony, and also make sure to check off "No Auto-Route Jump Check" or the fleet won't go if there aren't jump gates along the route.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on July 06, 2017, 12:19:00 AM
Oh my god, THANK YOU!!

New suggestion; add a "Help" menu full of useful, simple tips like this.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on July 06, 2017, 06:34:39 AM
For repeated journeys through a line of JPs you can also use command templates and save the list of orders for later.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: superstrijder15 on July 06, 2017, 06:42:27 AM
Suggestion: Allow us to give priorities to each office in each Task Force

The reason I brind this up: I really need to have someone in each TF command, so as to be able to fill in the lower offices in that TF.   The game doesn't do this with the auto assignments.   The second priority for my officers should be warships, then other ships, then the other offices in a TF, beginning with the TF 'Fleet HQ', then 'Dummy' & 'Dummy #2'  The reason is that these TFs only exist to get R1 leaders a job, so they won't be fired and I can get more leaders for my fleet.   However, this would obviously also be useful once I get multiple real TFs and a lot of ships, I'd want to get the best people in TF A, and the slightly worse one in TF B.   For that, this suggestion would be really useful. 

8/7/17: Another suggestion: Increase the max range of escorts.  It doesn't seem like a hard thing to do, and it would allow one to sen out scouts with the escort command, while atm I have to manually pilot them due to my missiles outranging the max range of the escort function.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on July 06, 2017, 02:22:01 PM
Suggestion:

Instead of setting HTK's for individual parts, let us draw the armor diagram manually, and allow us to have non-rectangular armor layouts.  This would let us replicate real designs more faithfully, because it would allow us to put essential components in heavily armored citadels, while the rest of the ship is more-lightly protected.

Our current system is good for dreadnought-era warships; they tended to have medium armor all over the ship.  WW2-era warships however tended to be mostly lightly armored, with a very-heavily armored citadel, in which the engine, magazines, and fuel bunkers were housed.  Your ship can survive a 14-inch shell penetrating and exploding inside a mess hall; it can't survive that same shell penetrating and exploding inside one of the magazines.  So by armoring only the parts that actually matter, you can save a lot of weight.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on July 10, 2017, 04:34:28 PM
Addition to my previous suggestion about armor:

Make the degree to which we can have a non-rectangular armor diagram a tech, in the same style as reduced-size launchers.  The higher the tech level, the less rectangular our armor diagram could be.

To measure how rectangular the diagram is, you can measure the slope of the diagram.  Higher tech will allow higher slope.

In the attached example diagram, green is non-essential components, orange is important components, red is most important components, and blue is armor.  The armor slope is 2.


Sorry, I can't get it to embed properly:
http://imgur.com/p5haknu
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on July 12, 2017, 06:55:05 PM
Suggestion:

Allow sensors to provide some intel on enemy ships.

In real life cargo ships look nothing like warships usually.  And not just visually, but to all manner of sensors.  All ships produce their own unique sonar signatures, and accurate hydrophones manned by well-trained sonar operators can tell them apart.  Warships sound different than merchant ships.  Experts can even tell ships of the same class apart.  I spoke with one sonar-man who said that on a calm day, you could hear the internal PA system of nearby ships.

So my suggestion is to allow sensors to give us some information on what exactly a contact is.  Thermal sensors should be able to tell whether an engine is a military or a commercial engine, maybe even what tech-level (I assume each engine type produces a different kind of exhaust).  Active sensors should be able to see components that need to be at least partially external, like sensors, turrets, weapons, hangar bays, mining modules, sorium harvesters, construction modules, and cargo holds.  EM sensors should not just warn you when an enemy active sensor is on, but also when a fire control is locked on, like a radar warning receiver in real life.

Obviously this intel should not be guaranteed.  You should need strong sensors, possibly with additional tech.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Garfunkel on July 15, 2017, 11:50:05 AM
Add a system administrator level between planetary and sector admins. That way it would be possible to create a proper civilian bureaucracy. Civilian administrators on asteroids/planets, then a system administrator overseeing the system, and finally a sector administrator that oversees multiple systems. Currently you can have either sector command buildings for each system but then you lose out the third level or you can build-up your sector commands but you lose out the system level.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on July 17, 2017, 03:42:49 PM
Suggestion:

Simplify shipyard expansion.  Merge all the orders like "Add 1000 tons to capacity" orders into one "Add X tons to capacity" with a field to input exactly how many tons we want to add.

Edited to add this addition:
Do the same thing for adding slipways; let us add more than one at once.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: MagusXIX on July 17, 2017, 05:57:13 PM
Suggestion:

Simplify shipyard expansion.  Merge all the orders like "Add 1000 tons to capacity" orders into one "Add X tons to capacity" with a field to input exactly how many tons we want to add.

Edited to add this addition:
Do the same thing for adding slipways; let us add more than one at once.

For those of us who like to keep our shipyard tonnage in nice, round numbers, this would be a godsend. I hate having to increment shipyards one step at a time. When I'm trying to get a civilian shipyard to 250,000t it really sucks to have to re-assign the 'Add 10,000 tons' order every other week. It'd be so much easier to just set it to grow until it reaches the size I want.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on July 18, 2017, 04:14:26 PM
Suggestion:

Add a maximum rank option on the DAC page of the ship design window.  I should be able to prevent rear admirals from being assigned to fighters.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: DIT_grue on July 19, 2017, 02:42:25 AM
Suggestion:

Add a maximum rank option on the DAC page of the ship design window.  I should be able to prevent rear admirals from being assigned to fighters.
The maximum rank is two levels above the minimum. So if you set R1 for a fighter, no one will be assigned to a fighter unless they are R3 or below.

If it's not working that way, you've got a bug report rather than a suggestion.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on July 19, 2017, 11:36:57 AM
I figured it out; the fighters were accidentally set to captain minimum.

But I think this is still a good suggestion; no reason for a hardcoded range of possible ranks.  Let the player decide it.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on July 19, 2017, 05:04:08 PM
Suggestion:

On the task groups window, make the check boxes for filtering destinations remember which ones you have selected. 
Currently if you have "Show all pops" selected, and give an order that would require leaving the system, it clears all the check boxes when it loads the new system.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on July 23, 2017, 11:09:52 AM
Suggestion:

On the task group window, allow us to filter task groups by task force.  Currently the task group dropdown can get pretty cluttered and there is no good way to clean it up.

Allowing us to filter by task force would both help this problem and would make task forces more useful.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: DuraniumCowboy on July 23, 2017, 02:28:47 PM
Any where a character name appears, a double click should open the character page with the record for the character selected displayed.  It takes me so long to award medals right now.

In a similar vein, a text box on the TG form to add a note to all existing characters' histories assigned to the group.  Maybe in the naval organization tab, so you could even do it by branch. That way you could bulk add notes like "Participated in battle if Gleiss 128" or whatever.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on July 24, 2017, 08:08:23 PM
Suggestion:

Make the Aurora icon on the taskbar flash when an interrupt occurs while it is not the active window.  I tend to browse the web or watch youtube videos while I wait for time to pass in-game.  It'd be nice if it alerted me when something needed my attention.

A good example of what I mean can be found in Dominions 4.  If you alt-tab out of the game, the icon will flash yellow when it is your turn again.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: hostergaard on July 26, 2017, 11:56:49 AM
Suggestion:

Make us design ship hulls rather than ships.  That is, instead of designing a complete ship and tooling a shipyard for it we design a hull with various hull spaces, hard points and mounts where ship system appropriate for said spot can mounted.  Have said hull be a racial research, then shipyards can tool for said hull.  After that ship variants can be designed from said hull (and possibly researched), by adding different systems in the appropriate places and all variants can then be build in the shipyard tooled for said hull.

See for example Star Citizen and their hull variation for inspiration. 

More elaborate explanation here (http://aurora2.pentarch.org/index.php?topic=9627.0)

Title: Re: Semi-Official 7.x Suggestion Thread
Post by: hostergaard on July 26, 2017, 02:35:55 PM
Suggestion:

Civilian contracts for racial tech (and possibly ships),

Instead of having your researcher do the engineering work of researching racial tech have private companies do it by defining system specs (kinda like wedo now) and have civilian companies develop their own designs that varies somewhat in specs, features, cost and so on (partially random, partially according to each company strength and weaknesses, tough they always at minimum add here to the given specs) that they use as a bid on said system specs. The player can then give out various contracts to said companies.

More here (http://aurora2.pentarch.org/index.php?topic=9630.0)


Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Seolferwulf on August 05, 2017, 11:36:03 AM
Suggestion: Catapults.
A new ship component which enables ships and space stations to launch other ships over a distance for military and commercial uses.
Link to the thread with a more detailed explanation:
http:aurora2.pentarch.org/index.php?topic=9633.0 (http://aurora2.pentarch.org/index.php?topic=9633.0)

Seems like I'm not yet allowed to post proper links D:
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: sloanjh on August 07, 2017, 08:48:31 AM
Seems like I'm not yet allowed to post proper links D:

I fixed it for you.  IIRC There's a post count that you should be hitting soon.

John
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: swarm_sadist on August 08, 2017, 03:26:59 PM
Some suggestions for C# officers:

1. Brig, which allows for the placement of an intelligence officer on a ship. I like to have a fast, stealthy ship with emergency cryopods move around the battlefield picking up lifepods, but I hate having to manually install a high Intelligence CO on these ships.

2. Joint Command Centre, which allows the placement of an Army officer on a ship, to support ground forces on a planet's surface.

3. Security Station, which allows for a security officer to protect against boarding action.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Belnivek on August 11, 2017, 10:01:23 AM
I would like to see Lagrange Points added to orbiting stars.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on August 11, 2017, 11:08:46 AM
Suggestion:

Allow us to switch back to the VB6 color scheme.  Personally I find the new UI a little straining to read.
Title: More sophisticated Migtation
Post by: Zerkuron on August 19, 2017, 05:30:52 PM
I had some thoughts on migration (moving colonists around).

Right now we have 3 factors in moving colonists as far as I noticed (written in pseudo code).

   - population supported by infrastructure
            - if PSBI is > population --> demand more colonist
            - else --> do not demand colonists

   - civilian colonisation status
            - if destination of colonist or pop < 25M --> request colonists
            - if stable or source of colonist --> do not request colonist
            - if source of colonist --> supply colonist

   - amount of colony ships == how many people can be moved at any given point

With the introduction of maximum Population in C# Aurora I would love to see a more sophisticated system. The System would work around migration pressure (MP). Negativ MP leads to emigration (leaving) and positiv leads to immigration (arriving).
Different factors should affect this MP. I want to give here some suggestions.

MP settles to 0 around 50% max population on Planet.
   - if actual pop < 50% max pop --> add MP
   - if actual pop > 50% max pop --> lower MP
   (greater deviation translates to more Pressure change)

Workforce influences MP it trends to 0 if there is no surplus nor shortage of workers.
   - if Available workers is < 0 --> add MP
   - if Available workers > 0 --> lower MP
   (greater deviation translates to more Pressure change)

Infrastructure influences MP. It trends to 0 if Infrastrucure is utilized to 100%. Planets with 0 colonization cost should be more attractive, because I imagine, that people want to live in places where they can walk outside without EVA suite.
   - if PSBI > actual pop --> add MP
   - if PSBI < actual Pop --> lower MP
   (greater deviation translates to more Pressure change)
   If colonization cost is 0 --> add  X-amount MP

Recreational facilities add MP they need workers to work properly

Protection influences MP.
   -if Requested Protection Level  > Actual Protection Level --> lower MP
   (greater deviation translates to more Pressure change)

How colonyships distributes colonists is determent by MP Rank. higher MP leads to more ships delivering lower MP leads to less deliveries. negativ MP leads to supply colonists.

   - all positiv MP are added --> all +MP
   - all negativ MP are added --> all -MP

   - if MP of Planet is > 0 --> MP of Planet / all +MP   
   - if MP of Planet is < 0 --> MP of Planet / all -MP

Ranking in List and distribute colonyship movement accordingly.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Kelewan on August 20, 2017, 03:42:27 AM
I like the idea, but there should still be some override/player controlled policy.

1.  there might be only Colonies with MP > 0, so the new Colony will not receive settlers:
    For example at the beginning on Earth the pop is < 50 % max pop, PSBI > actual pop and  colonization cost is 0.  Only available workers will reduce this by a little bit.

2.  the Civil Transporter AI does not take the settlers already the route into account.  so it tends to send to many


Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Rich.h on August 21, 2017, 07:15:38 AM
Clearly not an idea for the current Aurora but for Aurora C, would it be possible to implement a system of food requirements to populations? Now I am not proposing some huge complex system of specific goods, but more just a case of having populations limited by the use of an installation. I know we already have a set % that are allocated as food industry workers but it can seem very odd sometimes to wonder just how 50bn people are first of all able to fit physically on Earth and secondly how they are actually able to feed that many. TN space magic or not we have systems in place that limit ship maintenance and such so the concept of logistic limits already exist.

How about a system where for a colony zero plant a population would require nothing to start with, after all a few thousand people can easily feed and house themselves. Then population is limited by a ratio method of installations, call them what you want but they would represent both the actual food industry and the physical amount of space on the planet to do anything. If it could be done then take things one step further with hard limits based on a planet size, possibly allowing for techs to raise this limit by a % amount, arcology buildings, mile high ecumenopolis planets and so on.

For me I always feel that one of the issues is population in that once I find myself a good few sources of minerals then my industry can simply rocket upwards. Earth has all the population you ever need and happily grows to monumental numbers, so you just end up with 3000 or so construction factories and now have the ability to churn out anything you want in mere months. With population controls and limits, it will make the empire colonies into something of greater use than yet another source of minerals to be shipped back to Earth.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Hazard on August 21, 2017, 10:09:44 AM
Largely solved Rich, in the next version of Aurora there's an upper level to the amount of population that can be settled on a planet.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on August 21, 2017, 10:22:03 AM
Related suggestion:

Make the population limit subject to at least one tech.  Specifically something like "civil engineering".  To represent arcologies, i.e. single, huge buildings that are self-sufficient cities.  Imagine how many people could fit on Earth if all of it was covered in 1-2 mile tall buildings each a city in itself.  That's way more than 50 billion.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Seolferwulf on August 22, 2017, 11:50:49 AM
Related suggestion:

Make the population limit subject to at least one tech.  Specifically something like "civil engineering".  To represent arcologies, i.e. single, huge buildings that are self-sufficient cities.  Imagine how many people could fit on Earth if all of it was covered in 1-2 mile tall buildings each a city in itself.  That's way more than 50 billion.

As an addition to this: Underground Housing.
There's so much space underground and people make hardly use of it :D
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: MagusXIX on September 04, 2017, 01:28:42 PM
Suggestion - Production Anomalies

I'd like to see a most robust, engaging economy. There's a lot of ways that this could be done, but here's a couple initial suggestions, and a couple long-term suggestion that could be implemented only after an economy overhaul.

Take the research anomaly system that already exists and expand it to include anomalies that can boost or alter (or nerf!) production of specific items, whether it's specific trade goods, component categories (lasers, missiles, shields, cloaks, etc), or installations (mines, factories, PDCs, infrastructure, etc), or even just a direct boost to 'wealth' production. This change alone would be enough to tempt players to spread out their production. It's a big change from the current situation where, more often than not, the homeworld (and sometimes planets that have been terraformed/grown enough to become essentially identical to the homeworld) is where all meaningful production takes place and all goods go to and from it. Instead, you'd have the option to boost production by having worlds dedicated to certain products, from which goods would then have to be shipped where they are needed.

I'd make these sorts of production anomalies rather frequent, perhaps with more rare types that have more dramatic effects. The idea is to make colonized worlds more unique, especially in terms of economy, and to give the players a choice between more efficient but spread out production (more/better goods at the cost of the delays and vulnerabilities that come with shipping,) or more concentrated production (which also allows for more concentrated defenses) but without making full use of production anomalies.

Alongside this I'd also recommend re-looking at the Trade Goods system, where the goal would be to make them more meaningful and impactful, and especially more engaging for players. One possibility that I'd considered was giving some planets the ability to produce unique/rare trade goods that have special effects, such as increased population growth or better environmental tolerances to populations that have access to such a product. With it being planet specific, again, trade between worlds is made more engaging and meaningful, and the choice of which worlds to develop and how become more difficult and impactful.

With this, I'd include a way for players to choose between more interventionist trade policies (government gets more or less say in where trade goods are shipped and how many of each are produced, as well as setting import/export taxes and tariffs on specific goods, like a tea tax) or more laissez-faire  trade policies which would be the current system where trade goods are solely the province of private citizens/organizations (shipping companies and the colonists that produce the goods determine what happens with them, with little to no input from government/player.) Trade policies can affect production growth rates, maximum production capacity (probably per colonist working to produce the goods?), or a host of other possible effects to choose from. They could and probably should come in both domestic and foreign variants, where the domestic policies control how much of which goods are produced, where, and how much of what can/should be shipped to which planets, and foreign policies regulate how much of which goods we are willing to trade to and/or from any other specific empire (a full ban on Cuban cigars so our citizens can pretend they're somehow better than other cigars by virtue of being harder to obtain!) Policies regarding immigration/emigration between empires could even be introduced alongside (or after) this is implemented, using a very similar system.

Once trade goods are improved, we can then even start looking at more trade-related diplomatic options (trade sanctions against specific products, for instance, to allow trade between two empires while still denying access to unfavorable trades/markets.) There could even be things like trade wars, where total warfare is not permitted (no land-invasions, possibly other restrictions) but enemy shipping/fleets are free game, and planetary/system blockades could be a main feature of this sort of limited engagement. This is only as meaningful/impactful as the trade goods in question, though, so making those more important would have to come first.

Legality of goods is another thing to consider for after trade goods have been overhauled, where we could include things like military grade stimulants which you may or may not want in your military (short term combat effectiveness boosts at the expense of nasty side-effects?) but you certainly would not want in your civilian populations (increased Unrest relative to how much of the product is available in your population?) Could also include things like slave labor, legal in empires which practice slavery but illegal in empires where slavery has been abolished. There's a whole host of products that could play nicely in a system like this. Legal (read: minimal diplomatic effect) destruction/seizure of ships belonging to other empires when they are caught carrying illegal goods through your space could be a thing in this, along with a cargo-scanner module and perhaps other stuff for 'military police' ships (or a Coast Guard, or whatever you want to call your empire's Customs officials.) Alongside it, piracy and smuggling could be introduced.

But really, the suggestion is just to keep economic gameplay in mind when re-coding everything in C# so that at the very least it can be easily expanded on once economy becomes more of a development priority. Personally, expanded/improved economic gameplay is a top request of mine, so the sooner this happens the better. (Okay, maybe I just want more fun and impactful space-submarine and trade-interdiction gameplay, so sue me!)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Xkill on September 08, 2017, 02:56:24 AM
Just added a suggestion for ECM/ECCM systems in suggestion board. Here's the gist of it:

***

Make ECM have a more pronounced effect on combat by making it have a direct influence on missiles themselves instead of just fire control range. This would be done by making ECM deactivate (not destroy or change), a missile's tracking systems if it is in range.

*Occupy, distract, thin salvos, not destroy them;
*ECM range affected by ECM ship's sensor range;
*Number of missiles deactvated based on ECM rating, possibly based on a point system;
*ECCM reactivates missiles, or keeps them from being deactivated in the first place.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: adrianbard on September 11, 2017, 12:23:50 PM
drones, they are "fighter only" components that if on a fighter it doesn't need crew (but still uses extra HS per crew required as "computing power" or something similar) and it's actions delay is that of the ship that has a remote control component plus the time it takes light to cross the distance between the vessel and the controlling mothership
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: obsidian_green on September 12, 2017, 10:04:55 PM
I never posted this suggestion to this thread, so just to be sure. Original thread here: http://aurora2.pentarch.org/index.php?topic=9599.0 (http://aurora2.pentarch.org/index.php?topic=9599.0)

Quote from: obsidian_green
I don't know about other players, but twenty-something planetary administrators, brigadier generals, and naval captains somewhat break my sense of immersion. On the naval side, I can ... sort of ... remedy this by changing the initial rank (in the scheme I'm using) from lieutenant commander to lieutenant, but that's no help for that twenty-three year old ruler of Earth nor for the young scientists in charge of 60 labs (nor for the first initial crop of naval officers).

An easy "solution" (I grant that the current setup might actually appeal to some players) would be to make initial commander ages early 30s instead of early 20s. I can better stomach 30 year old lieutenant commanders (or even lieutenants if they're senior enough to command ships at the game's level of granularity) or head scientists ... colonels would still be a stretch, but beggars can't be choosers.

Less easy, but probably not difficult to code would be a dynamic means of establishing initial age at world/game generation, so that those (especially, perhaps exclusively military) commanders that get/would get auto-promoted in the initial commander crop are aged appropriately for their (maybe soon-to-be) rank. If colonel is to be the R1 rank for ground troops, perhaps their initial ages could be set separately---they should be (or I'd like them to be, at any rate) significantly older than the navy's lieutenant commanders.

A slightly related "problem" are the brigadier generals commanding Marine companies, which might fit a Star Wars-esque imagining (Han Solo didn't look like he could fit an entire battalion, much less any larger formation into that stolen shuttle), but doesn't quite fit with what I'm imagining for a force structure in my game.

It's all really minor stuff, but should be fairly headache-free to address if my suggestions appeal.  :)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on September 13, 2017, 03:24:51 AM
Oh hey, that sounds really nice.  Start the game with a mature officer corps.  It would certainly make sense.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on September 18, 2017, 11:33:58 PM
Suggestion:

Add another type of vessel, besides "PDC" and "Ship" to represent military orbital facilities.  Right now there's no good way to RP any universe that makes heavy use of orbital defenses, like the Orbital MAC Stations in the Halo universe, for example.  Right now all combat happens either in interplanetary space, or on the surface, orbital combat is sorely lacking.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on September 19, 2017, 02:34:41 AM
I'd argue that that would require new technologies to contrive to make close range 'orbital combat' an actual thing.  Otherwise everything in halo can be modeled with railguns (mac guns are railguns according to the lore), and you can see the guns are engaging at a considerable range, as do the games railguns.  Then the boarding pods can be simulated by boarding pods, which the game already has.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TheRowan on September 19, 2017, 04:07:11 AM
Suggestion: Nameable academies.

Have an option to change the name shown by officers/scientists/administrators for their training facility. Even better, have each body's academy customisable by character type (so Naval Officers from Earth train at Annapolis, Army Officers at West Point, scientists at MIT and administrators at Harvard). With the new commandant system, they'd be listed as the commandant/chancellor of the custom named facility relevant to their branch. If not customised, this could default to the current Earth Military Academy/University of Earth.

Only a little change, but I think it would be cool for RP purposes.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on September 19, 2017, 10:56:48 AM
I'd argue that that would require new technologies to contrive to make close range 'orbital combat' an actual thing.  Otherwise everything in halo can be modeled with railguns (mac guns are railguns according to the lore), and you can see the guns are engaging at a considerable range, as do the games railguns.  Then the boarding pods can be simulated by boarding pods, which the game already has.
I'm saying you never have military assets parked in orbit, which makes providing beam defenses to a planet with an atmosphere impossible.

Further, the addition of more stationary assets makes boarding capability more useful.  Right now it's fairly pointless, and absolutely not worth the dozens of interrupts you get during combat.  But if there were actual valuable assets that did not move (and thus were easy to board), it might be worth it.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on September 19, 2017, 11:53:00 PM
I mean, I make beam defense stations all the time, what are you talking about?

I'd agree its kindof pointless to try to capture them vs just destroying them, but thats true of halo as well.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on September 25, 2017, 08:19:39 AM
Add another type of vessel, besides "PDC" and "Ship" to represent military orbital facilities.  Right now there's no good way to RP any universe that makes heavy use of orbital defenses, like the Orbital MAC Stations in the Halo universe, for example.  Right now all combat happens either in interplanetary space, or on the surface, orbital combat is sorely lacking.
Technically, SMAC stations do have their own stationkeeping thrusters that they use when they fire (every 5 seconds). And you can build a ship with no engines then mass produce them from an " Orbital Construction Facility" (Shipyard). There is also a hand "Extend Orbit" order which does make a "Station" orbit the body further out (but then maintenance is a B unless you have that turned off).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Garfunkel on September 25, 2017, 04:06:33 PM
There are also class names existing for such "stations". There's Orbital Weapon Platform and Defence Base and quite a few others. Just design as a ship but without engines or fuel - or just one slow engine for "station keeping" and vóila.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on September 25, 2017, 04:53:42 PM
I just don't think the build model really fits with space stations.

The ISS wasn't built in a shipyard then towed into place, it was put together piece by piece in place.  I imagine the SMAC stations in Halo were as well.

Further, this could combine with how orbital habitats are built.  Instead of having factories churn out fully-built habitats, have them make habitat sections, which can then be assembled with construction ships.  I'd also combine this with jump gate construction.  Unifying systems is good, especially for a game that's already as complicated as Aurora.

Tactically, boarding beam defense platforms could make sense.  You time the arrival of your boarding craft with the arrival of a missile volley.  The stations then have to decide whether to target the missiles or the boarding craft.  If any stations are successfully captured, you can then turn their guns on the rest of the defense platforms.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on September 27, 2017, 07:42:10 AM
I just don't think the build model really fits with space stations.
The ISS wasn't built in a shipyard then towed into place, it was put together piece by piece in place.  I imagine the SMAC stations in Halo were as well.
Shipyards here are orbital installations while the UNSC's were primarily ground based (except for the installation in a nebula that constructed the Infinity, and space based construction of cruiser class and up). Not really much is known about the construction of SMAC platforms, but it is pretty safe to assume they are constructed at either a Construction Platform (https://www.halopedia.org/UNSC_construction_platform) or a Refit Station (https://www.halopedia.org/Refit_station) which are space based facilities but still shipyards. Its also safe to assume that the platform was built/moved into place by a refit station, as they were essentially mobile shipyards with their own engines and slipspace drive.

Further, this could combine with how orbital habitats are built.  Instead of having factories churn out fully-built habitats, have them make habitat sections, which can then be assembled with construction ships.  I'd also combine this with jump gate construction.  Unifying systems is good, especially for a game that's already as complicated as Aurora.
I agree that there is a bit of contradictory rules when constructing certain things. That does need a bit of cleaning up.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on September 30, 2017, 01:57:28 PM
Suggestion:
Make rail guns do the same damage across their entire range.  They fire solid projectiles, they don't need to worry about diffraction like lasers do.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: obsidian_green on September 30, 2017, 05:57:04 PM
Suggestion:
Make rail guns do the same damage across their entire range.  They fire solid projectiles, they don't need to worry about diffraction like lasers do.

Have to do the same with Gauss cannons, if we're applying that logic. We also have to explain how the projectiles eventually disappear. Hmmm ... maybe the TN materials evaporate? That might help explain why I have to maintain a parked ship in orbit with tons of materials when it's simply floating in a vacuum.  ;)

Now if those were plasma cannons (not talking whatever the "carronade" is supposed to be), the plasma "bullets" might dissipate after the magnetic pocket that contains it wears out and that could explain decreased damage at range. Also explains why they have apparently unlimited ammo---figure gas-compression tech and good batteries could give that appearance despite that being as finite as solid projectiles.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Hazard on September 30, 2017, 06:37:47 PM
Now if those were plasma cannons (not talking whatever the "carronade" is supposed to be), the plasma "bullets" might dissipate after the magnetic pocket that contains it wears out and that could explain decreased damage at range. Also explains why they have apparently unlimited ammo---figure gas-compression tech and good batteries could give that appearance despite that being as finite as solid projectiles.

A 'carronade' is a term from the age of sail. Due to a variety of factors warships were generally standardised on the concept of 8, 16, 24 and 32 pounder gun batteries. Frigates were the lightest of these ships, small, agile and generally equipped with a single deck of guns no heavier than 16 pounds. If they had another deck, it was probably 8 pounders.

This made these frigates fast ships and excellent for scouting, but not really suited to a battle line.

Ships of the line however carried batteries of big guns, often on 3 decks that were loaded from top to bottom with 16, 24 and 32 pounder guns. This made them very powerful in naval artillery, but slow and lumbering at best.

So what happens when you take a ship of the line and tear off the top gun deck?

Well, you get a heavy, slower frigate than normal that's absurdly overgunned for its size with its batteries of 24 and 32 pounders, but with crap for range. These ships were called carronade frigates.


And that's kind of the role the Plasma Carronade has in game; a big weapon system that's rather close in and horrifyingly good at breaking other ships.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: obsidian_green on September 30, 2017, 06:46:51 PM
Historically, I thought carronade was just a type of cannon. As far as the game is concerned, I still don't quite know what to make of it, given there's no reason for the magnetically-contained plasma bullets/shells (plasmoids) to be that limited in range.

Scratch that: if the plasmoid is that high energy, it probably wouldn't last that long. I might need to get a scientist working on that now that I have a rationale for it.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TheBawkHawk on September 30, 2017, 10:02:37 PM
Have to do the same with Gauss cannons, if we're applying that logic. We also have to explain how the projectiles eventually disappear. Hmmm ... maybe the TN materials evaporate? That might help explain why I have to maintain a parked ship in orbit with tons of materials when it's simply floating in a vacuum.  ;)

Now if those were plasma cannons (not talking whatever the "carronade" is supposed to be), the plasma "bullets" might dissipate after the magnetic pocket that contains it wears out and that could explain decreased damage at range. Also explains why they have apparently unlimited ammo---figure gas-compression tech and good batteries could give that appearance despite that being as finite as solid projectiles.

I always thought it was due to TN elements being partially in an alternate dimension with fluidic space, so they have drag. That's why our ships can do all these insane maneuvers at significant fractions of the speed of light - they exist partially in another dimension where Newton's laws aren't obeyed, and space itself resists movement. If the railgun/gauss cannon rounds are TN (which they almost certainly are to have a chance at even scratching a TN warship's armour), then they would be subject to that same force of drag.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on September 30, 2017, 10:08:01 PM
I think we can assume the railgun projectiles aren't suffering from TN drag since that drag will cause huge warships to instantly come to a halt, and yet the railgun projectiles can engage at range.

I agree that rail/gauss guns should have full damage throughout their range, and their effectiveness at range should purely relate to their ability to hit their targets.  Honestly the real reason I like this idea is that it would, in my opinion, provide another interesting distinction for railguns as compared to the other weapons systems.

Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on September 30, 2017, 10:12:36 PM
Gauss cannons DO do full damage at max range.  It's only railguns that have that damage drop-off for no reason.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Silvarelion on October 01, 2017, 06:48:46 AM
I always thought of it as effective damage and effective range, whereby the energy of the projectile doesn't change, but the damage does due to maneuvers or countermeasures taken by the target ship. Other games use dice rolls to simulate glancing hits and ineffective shots, but I like the predictability of the damage falloff.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: sloanjh on October 01, 2017, 09:09:04 AM
A 'carronade' is a term from the age of sail. Due to a variety of factors warships were generally standardised on the concept of 8, 16, 24 and 32 pounder gun batteries. Frigates were the lightest of these ships, small, agile and generally equipped with a single deck of guns no heavier than 16 pounds. If they had another deck, it was probably 8 pounders.

This made these frigates fast ships and excellent for scouting, but not really suited to a battle line.

Ships of the line however carried batteries of big guns, often on 3 decks that were loaded from top to bottom with 16, 24 and 32 pounder guns. This made them very powerful in naval artillery, but slow and lumbering at best.

So what happens when you take a ship of the line and tear off the top gun deck?

Well, you get a heavy, slower frigate than normal that's absurdly overgunned for its size with its batteries of 24 and 32 pounders, but with crap for range. These ships were called carronade frigates.


And that's kind of the role the Plasma Carronade has in game; a big weapon system that's rather close in and horrifyingly good at breaking other ships.

Ummmm based on my recollection from playing Wooden Ships & Iron Men oh so many years ago (and reading Horatio Hornblower) I think this explanation is a little bit off.  It looks good right up until "These ships were called carronade frigates" part at the very end.

The short version:  What you've described is a "razee frigate". Carronade is a niche type of gun, distinct from a "long gun", which has a shorter barrel and is of heavier caliber for the same weight.

The long version:

My recollection (and here are a couple of links to back it up https://en.wikipedia.org/wiki/Carronade (https://en.wikipedia.org/wiki/Carronade) https://www.eurobricks.com/forum/index.php?/forums/topic/6025-cannons-vs-carronades/ (https://www.eurobricks.com/forum/index.php?/forums/topic/6025-cannons-vs-carronades/) http://artillerymanmagazine.com/Archives/2004/carronades_sp04.html (http://artillerymanmagazine.com/Archives/2004/carronades_sp04.html)) was that carronades were much shorter guns that could fire much heavier shot for the same weight of barrel and hence were more inaccurate, i.e. like designing a sawed-off shotgun in a larger caliber to take advantage of the weight savings.

The 3rd link (to artillerymanmagazine) above was the most interesting (in the "I learned something" sense) to me - it's got a good discussion of how the accuracy issue is more nuanced than simply "short barrel = greater angular dispersion".

So Carronades are actually a different type of gun than "long guns".  BTW, cutting off the top deck of a ship was called "razeeing" (https://en.wikipedia.org/wiki/Razee) - I think you may have been thinking of "Razee Frigates" (as opposed to "carronade frigates) in your description.

John
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Hazard on October 01, 2017, 11:20:27 AM
You are right, I forgot a step (switching from long guns to short guns), but razee frigates were generally the ships equipped with carronades. Mostly because normal frigates were a little fragile for the throw weight a carronade battery could offer, so they needed to be more sturdily built in comparison. Razees were perfect for that because all the other bits were already in place and all that was needed was removing the superfluous top gun deck.

It also meant you had a use for captured ships of the battle you couldn't maintain on that level. Well, for more than spare parts anyway.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: alex_brunius on October 02, 2017, 01:52:04 AM
I think we can assume the railgun projectiles aren't suffering from TN drag since that drag will cause huge warships to instantly come to a halt, and yet the railgun projectiles can engage at range.

No, warships don't instantly come to a halt, it takes 5 seconds.

Since no projectiles travel for as long as 5 seconds even we have no way of telling if they suffer from drag or not, but I think we can assume they do suffer from drag since for example railgun damage is reduced at range.

Gauss seems to be too short range / inaccurate for it to have time to matter.



If projectiles didn't suffer drag why can't I fire them from 400 million km away at a stationary target?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: boggo2300 on October 02, 2017, 03:54:04 PM
You are right, I forgot a step (switching from long guns to short guns), but razee frigates were generally the ships equipped with carronades. Mostly because normal frigates were a little fragile for the throw weight a carronade battery could offer, so they needed to be more sturdily built in comparison. Razees were perfect for that because all the other bits were already in place and all that was needed was removing the superfluous top gun deck.

It also meant you had a use for captured ships of the battle you couldn't maintain on that level. Well, for more than spare parts anyway.

No carronades were actually very widely used, most ships of the line carried a deck of them as well as long guns, and most frigates used them as their primary guns with Long guns in a secondary role for some range,  carronades giving you more bang for the weight so to speak.

H.M.S. Indefatigable (sticking with Hornblower) though a Razee (though so many British Frigates were Razees rather than Frigate built it could be considered the norm) had;
twenty-six 24-pounder guns on her gundeck, and mounted eight 12-pounder guns on her quarterdeck and a further four on her forecastle, as well as four 42-pounder carronades on her quarterdeck and two on her forecastle.

Incidentally because of this,  Indefatigable was much more dangerous at close range AFTER she was Razee'd than before as a 64 gun third rate!
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on October 09, 2017, 05:49:05 AM
Event log:
add an event for "Industry reactivated" (end of that 180 days long period) which will say which industry and where was reactivated.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on October 09, 2017, 06:43:54 AM
No, warships don't instantly come to a halt, it takes 5 seconds.

Since no projectiles travel for as long as 5 seconds even we have no way of telling if they suffer from drag or not, but I think we can assume they do suffer from drag since for example railgun damage is reduced at range.

Gauss seems to be too short range / inaccurate for it to have time to matter.



If projectiles didn't suffer drag why can't I fire them from 400 million km away at a stationary target?

Accuracy I guess?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: 83athom on October 09, 2017, 08:19:32 AM
Directed Active Sensor.

Much like the current active sensor, yet longer ranged for a given technology. The downside being that it is only detects contacts in a cone in front of the mounting in the direction of travel. Could have multiple techs to research, IE; +50% range +/- 45 degree cone, +100% range +/- 30 degree cone, etc. My original thought about this was for use on missiles, so it could be a missile only component, but then I thought that it would also have its use on fighters and certain warship designs.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Xonok on October 09, 2017, 06:47:01 PM
What I'd like is some way to change resource abundance in system generation.    Something like a box called "Resource abundance" with a default value of 100 (%).    By changing that at system generation I would scale all minerals in the entire universe up or down.   
So for instance if I put it at 1000%, my homeworld minerals and all the minerals I will discover since will be 10x as large.   
It doesn't have to work retroactively. 
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on October 10, 2017, 02:19:31 AM
Class design -> DAC/Rank/Info:
There could be an option to continue the enumeration and not start again from 1 with the enumeration of generated names of given class. DAC/Rank/Info tab of Class design screen would offer "Enumeration style" listbox where one can either select "start again from 1" or select one of other classes to continue the enumeration of that other class. Great for updated version of class design after some research breakthrough.

Production -> Manage shipyards:
When ordering a construction/refit of ship there would be a checkbox "Don't use any stockpiled components" or even a list of stockpiled components this construction/refit will consume in which one can select which items should be really used. Useful when there are multiple classes that need the same parts. Player currently can't make sure  classes won't "steal" components intended for some other class in construction/refit other than with tiresome fiddling of industry tasks.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: alex_brunius on October 10, 2017, 02:32:00 AM
Accuracy I guess?

That doesn't make sense either. If you can hit a wildly maneuvering target within 5 seconds you should be able to hit a stationary target at way longer distances from an accuracy point of view.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on October 10, 2017, 10:03:12 PM
Thats not really true, mechanical accuracy of the gun would have nothing to do with short range hit chances, which purely have to do with your ability to predict where the target will be in five seconds.  (and possibly tracking speed of the gun is also a factor, if the target moves faster than the gun can precisely slew)

So like lets say the gun has a certain (very narrow) cone in which it can hit stuff.  It doesn't matter at super close range, where the only issue is swinging the gun to the correct orientation quickly, but 400 million kms out, its a big factor.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: alex_brunius on October 11, 2017, 03:32:09 AM
Thats not really true, mechanical accuracy of the gun would have nothing to do with short range hit chances, which purely have to do with your ability to predict where the target will be in five seconds.  (and possibly tracking speed of the gun is also a factor, if the target moves faster than the gun can precisely slew)

So like lets say the gun has a certain (very narrow) cone in which it can hit stuff.  It doesn't matter at super close range, where the only issue is swinging the gun to the correct orientation quickly, but 400 million kms out, its a big factor.

Yes, we do indeed know for a fact that the mechanical accuracy of the gun doesn't matter at all in Aurora, because if you take the same gun and slap on a twice as good fire control you always will get twice as high hit chance, meaning mechanical accuracy is not considered an issue in any weapon.

What I am talking about isn't hitting at 400 million kms out though, but at for example twice or +10% of the current max range...

If mechanical accuracy is NEVER any issue at all at current ranges, and with a good enough FC you could get 100% hit chance out to max range, then why is it suddenly such an insurmountable issue that you get 0% chance to hit at current max ranges +10%?

My point is that the current max ranges are totally arbitrary and don't make any logical sense from an accuracy perspective, they only make sense from a projectile damage perspective where the projectile and beam loses all damage potential beyond a certain range. ( Which for projectiles is consistent with being slowed down like ships are ).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: sloanjh on October 11, 2017, 07:39:07 AM
Yes, we do indeed know for a fact that the mechanical accuracy of the gun doesn't matter at all in Aurora, because if you take the same gun and slap on a twice as good fire control you always will get twice as high hit chance, meaning mechanical accuracy is not considered an issue in any weapon.

What I am talking about isn't hitting at 400 million kms out though, but at for example twice or +10% of the current max range...

If mechanical accuracy is NEVER any issue at all at current ranges, and with a good enough FC you could get 100% hit chance out to max range, then why is it suddenly such an insurmountable issue that you get 0% chance to hit at current max ranges +10%?

My point is that the current max ranges are totally arbitrary and don't make any logical sense from an accuracy perspective, they only make sense from a projectile damage perspective where the projectile and beam loses all damage potential beyond a certain range. ( Which for projectiles is consistent with being slowed down like ships are ).

[waves arms wildly]
Warning Will Robinson!  Danger! YASTD (Yet Another Suggestion Thread Diversion) Detected!
[battery pack removed]
[arms stop, slumps over]

Could we please take this conversation to a different thread?  I think a good rule of thumb for YASTD is if someone reading the post won't remember what the original suggestion was, or if the back and forth goes on more that a couple of laps.  I lost track of this one a couple of laps back.

Thanks!
John
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on October 13, 2017, 12:12:59 PM
Separate "Civilian Mining Colony" event type into pair of types:
1. "New CMC"
and
2. "CMC expantion"
- in the same way, as there are different event types "New Officer" and "Officer Update".

The reason is, that there is no need to react to CMC expantion at all, but when you have a new CMC, than you want to decide if you have to buy minerals from this new CMC.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Detros on October 22, 2017, 12:33:47 PM
Money gained from CMCs selling mined resources to civilian market could add to Annual Wealth Creation of given colony so that wealth bonuses from governors could then affect the amount of money one gets from those CMCs.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Seolferwulf on October 28, 2017, 07:06:59 PM
Suggestion: Inverse the effect of the "Show Surveyed Bodies" checkbox on the Minerals-tab.

Reason:
Whenever the checkbox is checked it adds a white ring to every body that has been surveyed, which makes the screen very noisy.
That's why I only check it whenever I want to know which bodies still need to be surveyed.
If the effect is inversed you could simply leave it ticked and have your survey ships remove the noise from your populated systems.

Pros:
+ one option less you have to fumble around with every now and then
+ as an added bonus you have less redundant information on the screen, since the checkbox "Show Mineral Concentrations" already implies what has been surveyed.

Cons:
- people will have to get used to the inversed effect

... feel free to add more to the pros and cons if something comes to mind.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on November 05, 2017, 12:35:27 PM
Institute a system like Hearts of Iron has for production efficiency.  In HoI, if you build a lot of sherman tanks, you get better at making them.  So the later ones are cheaper or are built quicker than the earlier ones.

This would be useful for ground units, missiles, fighters, and ship components.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: alex_brunius on November 05, 2017, 05:46:35 PM
Institute a system like Hearts of Iron has for production efficiency.  In HoI, if you build a lot of sherman tanks, you get better at making them.  So the later ones are cheaper or are built quicker than the earlier ones.

This would be useful for ground units, missiles, fighters, and ship components.

Yeah, another way to think about it is as a penalty to output until a sufficient investments has been made.

Shipyards do kind of have it built in a bit through their retooling mechanics.


If you want a system more realistic then in HoIs production though what you want to do is basically variable retooling. The bigger series you order (in terms of total cost) the more investments in tooling, assembly lines and specialized factories make sense to do.

It will take much longer to set up the most efficient production line, but once done each unit will be much cheaper. A tradeoff between short setup a high unit cost (workshop/prototyping) vs long setup and low cost (sequenced assembly line with optimized flow).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on November 11, 2017, 06:00:09 PM
I'll duplicate it here too:

Alien ship classes can be displayed by the phonetic alphabet tables, as it was in NATO naval practice ("Alpha class", "Bravo class", ... - list ordered by the time of first contact with this class).
That's easy, RP-cool, handy to memorize, and doesn't tell you any unnecessary information about alien designs.
More of that, this table can be selected from the list (NATO/ITU-R RTPA, Greek PA, Hebrew PA, LAPD PA), or even written by player himself.

Another solution is to use first names from officer names table, filtered by the main name scheme of that empire.
It will give more length, so when you contact more classes of that empire, than there are words in this phonetic alphabet - there will be less need with names list to use suffixes (like "Alpha-2" or "Alpha II" classes - those can be misunderstood by new players as succeed classes or blocks of one class).
But it can be less handy, because there are some very similar or even duplicated names in those name lists.

I'd like to see first variant (RTPA list) - smth like "Klingon Alpha class" ... "Klingon Victor class" ... "Klingon Alpha-2 class" ... - but only if it will be some personalization possibility.
If it will be hardcoded algorithm - than I'd prefer last variant (officer first names list of empire scheme).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Scandinavian on November 11, 2017, 06:10:41 PM
Slow steaming
There is currently no incentive for vessels in Aurora to cruise at less than their maximum speed. But wet-navy vessels often do so in reality, in order to economize on fuel. To simulate this, the fuel consumption calculation could be modified to use actual speed, rather than engine design speed, within a certain envelope of the engine design speed (say -50 % to +25 %, unlockable via research the same way the engine power multiplier currently is).

To ensure that it is still always more economical to simply design an engine optimized for the desired cruise speed, suggest adding a fuel efficiency penalty of (4 x [percentage deviation from design speed]^2). This will ensure that slow steaming remains economical throughout the suggested -50 % to +25 % performance envelope, while still providing an advantage for designs purpose-built for their desired cruise speed.

Assuming all other parameters are retained, this suggestion would effectively triple the deployment range of warships in the case where they just need to get there when they get there.

To further disincentivize warships from moving at above their design speed unless they have an urgent reason to do so (such as people shooting at them), suggest applying the same 4x[speed difference]^2 penalty to maintenance failure rate and progression speed of the overhaul clock when moving above their design speed, representing the fact that they really are not designed to do that for any extended period of time.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: serger on November 13, 2017, 03:56:28 PM
Add fuel trap component, that can gather sorium from space dust and burn it as raw fuel (see ramjet) to use for commercial ships, surveyors and raiders, especially NPR (will reduce disbelieve with no-fuel-usage NPR rule exception, and/or simplify strategic scripts for NPR). Maybe usable for other TN minerals gathering in nebulas.

Add more dangerous "wild" aliens, that can be generated in any new system, or make their generating probability customizable. (Especially significant for early C# AI - those hi-tech wild gees might be much simpler to code, comparing to growing race, that have an economy, strategy, shipping system, shipping lines, colonizing, ammo supply and so on, that is complete coding nightmare.)

(And that is duplicate from C# Aurora subforum)
Another suggestion that can limit the overusage of energy/kinetic weapon:
Every shot triggers a roll to maintenance incident, so firing vessels will consume supply much faster and have good chances of disabling weapon, if there is no sufficient supply value.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on November 14, 2017, 12:39:33 PM
Make it so some planets are better for certain kinds of facilities when they are not terraformed.

For instance, in real life, Titan is perfect for setting up factories and supercomputers.  The Landauer Limit is the theoretical maximum computation speed, and is inversely proportional to the computer's temperature.  Because Titan is so cold, and has a thick atmosphere to use as a heatsink, Titan would be perfect for use by datacenters.  A similar situation occurs with manufacturing.  Because Titan is so cold and has a thick atmosphere, manufacturing equipment can be run harder and hotter, improving production speed.

Basically, Titan is better for a colony the way it is now than if we terraformed it to be easily habitable.  I imagine a situation where society solely uses cryptocurrencies, with bitcoin mines on Titan maintaining the blockchain.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on November 14, 2017, 01:59:26 PM
#saveThePDC

Hmmm, how about making planetary population caps flexible based on the infrastructure? For instance, tidally locked planets can have much higher population caps just by having infrastructure in the less hospitable places, water planets can just have infrastructure built in the shallows, et cetera. Maybe make the useful population scale poorly for circumstances like that? (agriculture and environmental getting higher percentages as an increasing portion of your population lives in underwater spacedomes)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: schroeam on December 02, 2017, 10:34:58 PM
I think this is still Steve's cubbyhole for suggestions.  If not, please move this to the appropriate place.

POW's.  I'd like to see the option for rescuing POW's from enemy planets, either as part of conquering the planet, a special operations mission for an espionage team, or a mission for a marine company or battalion.   Maybe, if Steve is even bored enough one day, code in a diplomatic option to exchange prisoners utilizing a civilian ship (task of "pick up enemy POW for exchange" at your planet and then "exchange POW"at enemy planet, as long as one enemy planet is located.  Obviously this would require a change to how prisoners are handled by the AI, as well as the player, both when captured from lifepods and from ship boarding actions.

I realize it's a long shot with the current refit and modernization program Aurora is undergoing, but something for later.

Adam.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: obsidian_green on December 03, 2017, 03:33:11 PM
I'm not advocating that particular use of POWs, but I would like to see them have some added effect or utility in the game. I run across planets that have survivors and POWs on them, but I can't really do anything with them, as far as I can tell.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on December 04, 2017, 01:38:42 AM
I do really like the idea of daring rescue missions.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: JacenHan on December 24, 2017, 07:56:07 PM
Minor suggestion here. How about adding scientist age to the list in the research tab? I think that having it there in plain sight would give the player a bit more incentive to give projects to younger, but less experienced scientists, rather than investing solely in someone who will probably die within the next five years.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Scandinavian on January 05, 2018, 03:27:17 PM
Using military units to reduce unrest should damage their maximum morale. In the real world, prolonged use of combat troops for security operations and counterinsurgency warfare has a pronounced detrimental effect on their combat readiness.

Likewise, combat should give a non-trivial temporary (but relatively long-lasting) bonus to maximum morale, representing the fact that peacetime training really is no substitute for actual battlefield experience.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ropedog on January 10, 2018, 02:01:25 PM
How about adding the "geological team survey complete" info to the System View and/or Geology Survey Report pages.
Also, in the Teams tab, it seems that you should be able to see the teams that you have created and their location.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: King-Salomon on January 10, 2018, 02:31:07 PM
How about adding the "geological team survey complete" info to the System View and/or Geology Survey Report pages.
Also, in the Teams tab, it seems that you should be able to see the teams that you have created and their location.

I would like to see the whole "Team-system" overworked (maybe after C# is finishes in a later version) - the main point is that you can create them at will with no time and at every place/body you want and be able to delete them at will...  even if you don't want to do this, there is no way to handle them easily...
with the new system that allows more than 1 "officer" at a ship like CO, Exec, Tac, etcpp it could be possible to create "ships" (like special shuttles, or even a "Inquisition cruiser") with a special module for each sort of team - you still need the team-members but the "ship" would be the team in most aspects

the "special module" would need 5 Officers/commanders etc with the needed skill to function - could also be part of the "auto assessment (maybe with the option to not allow administrators, researchers etc), if one of the team members is a navy officer he/she is the commander of the ship but not of the team - these ships would be able to get orders to use the "team ability's" like "survey ground", "research ruins" etc - maybe even with a auto-function like survey ships atm

basically it would be the same as teams atm but with the need to use ships to transport the teams, for RP it would be better to create special ships for them and that teams are not just created/deleted at will at every body you choose...

I guess the new system with more than 1 officer on a ship would be great for this, to give teams more fluff and RP - the "team-site" could still be used to list the "team-ships" and check/uncheck if a ship should have team-members, which kind of team members, where the ship is atm, etc

I am a fan of using the same game mechanics at the most parts in a game were they make sense - and using the (new) ship mechanics for teams looks like a win-win for me :)

---

also I would like to see some "color coding" at the summary page of a body like "No" in red if the body was not team-surveyed, green "yes" if it was... green colour coded ruins and research bonus if any, etc ... just some "one view, all seen" QOL improvements - but that is an other can of worms i am afraid...
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: ropedog on January 17, 2018, 11:14:33 AM
Regarding failures, two similar ships with commercial components, except one has a grav sensor classifying it as military:
I'm fine with the military components failing, but when the engines continue to fail on the military ship and the commercial ship can go forever with the same equipment is frustrating.   Just having the grav sensor shouldn't make the commercial-rated engines or jump drives fail.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Graham on January 25, 2018, 08:02:05 PM
Could we have a button to rename a system or body for all player races, not just the currently active one?

Its not a major thing, would just save a lot of clicks.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on January 26, 2018, 09:56:36 AM
How about adding the "geological team survey complete" info to the System View and/or Geology Survey Report pages.
Also, in the Teams tab, it seems that you should be able to see the teams that you have created and their location.

This has been added for C# Aurora.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Drgong on February 03, 2018, 05:14:40 PM
It would be really neat to be able to "Part out" ships to MSP, even if it over time.   
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Hazard on February 04, 2018, 05:39:57 AM
It would be really neat to be able to "Part out" ships to MSP, even if it over time.

Very prone to abuse, it lets you design/build a ship with a few very large/MSP expensive components heavy on minerals you have no use for, break out the parts for MSP conversion and then use a shipyard to spend more useless minerals on repairs. Repeat as needed to keep up with MSP demand.

This lets you save on minerals you actually have a use for by not needing them for MSP production, which very deliberately requires a bit of every mineral type.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: waresky on February 04, 2018, 06:33:46 AM
My opinion : 7.1 Suggestion become USELESS. Let stay in peace STEVE pls. See ya in Space.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: linkxsc on February 10, 2018, 11:00:11 PM
Ability to manually design solar systems for use ingame.

Right now, the only guaranteed system we have is Sol. I'd like the ability to in future versions of the game, hand the game a well managed CSV file that dictates a system or systems that would be added to a roster for systems to be generated when visiting new systems, OR be able to grab them at will when using the "create new system" button in the F9 menu.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Graham on February 11, 2018, 12:19:39 AM
In VB6, and in what C# currently looks like, Box launchers seem to be just better than regular launchers 90% of the time.

At the moment 100 Boxes takes up the same space as 20 0. 25 mod launchers and 170 missiles of magazine space roughly, giving you half as many missiles but 5x the alpha strike.  And those 0. 25 launchers still have a x100 reload.  In C# aurora 0. 25 size has been increased to 0. 3 so the ratio will be even more favourable to the boxes. 
In VB6 and in C#, this means that the enemy will require 5x as many beam weapons to shoot down all of the missiles.
In VB6 due to the long range of AMMs, they could engage the single box launcher wave with many salvos, meaning that box launchers could often be worse against fast firing AMMs.  due to the lower amount of missiles.  However with the missile changes of C#, the range of AMMs has been decreased if I am not mistaken, which would favour one single large wave.

Especially now that box launchers are a free tech, I cannot see many scenarios where using box launchers is not dramatically more effective.  And the logistical issues with them do not seem overly troubling to me, seeing as they are able to be reloaded inside commercial hangers.

My ideal solution would be splitting box launched missiles into box launchers and externally mounted missiles.  Box launchers would function as they do now but increased to 0. 25 size mod, while externally mounted missiles would retain the 0. 15 size mod, but are treated as being outside of the ship's armour belt, meaning they may be hit every time the ship's armour takes damage.  If they are hit they have a chance to detonate, which causes them to explode and damage the ship, however this damage would not be internal damage.

This makes using box launchers as a main fleet armament still viable, although slightly nerfed, while still allowing their full use with a trade off of added risk of surface damage, dependent on how many missiles are mounted this way.


Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on February 11, 2018, 07:11:17 AM
I would like to see the whole "Team-system" overworked (maybe after C# is finishes in a later version) - the main point is that you can create them at will with no time and at every place/body you want and be able to delete them at will...  even if you don't want to do this, there is no way to handle them easily...
with the new system that allows more than 1 "officer" at a ship like CO, Exec, Tac, etcpp it could be possible to create "ships" (like special shuttles, or even a "Inquisition cruiser") with a special module for each sort of team - you still need the team-members but the "ship" would be the team in most aspects

the "special module" would need 5 Officers/commanders etc with the needed skill to function - could also be part of the "auto assessment (maybe with the option to not allow administrators, researchers etc), if one of the team members is a navy officer he/she is the commander of the ship but not of the team - these ships would be able to get orders to use the "team ability's" like "survey ground", "research ruins" etc - maybe even with a auto-function like survey ships atm

basically it would be the same as teams atm but with the need to use ships to transport the teams, for RP it would be better to create special ships for them and that teams are not just created/deleted at will at every body you choose...

I guess the new system with more than 1 officer on a ship would be great for this, to give teams more fluff and RP - the "team-site" could still be used to list the "team-ships" and check/uncheck if a ship should have team-members, which kind of team members, where the ship is atm, etc

I am a fan of using the same game mechanics at the most parts in a game were they make sense - and using the (new) ship mechanics for teams looks like a win-win for me :)

---

also I would like to see some "color coding" at the summary page of a body like "No" in red if the body was not team-surveyed, green "yes" if it was... green colour coded ruins and research bonus if any, etc ... just some "one view, all seen" QOL improvements - but that is an other can of worms i am afraid...

I haven't coded anything yet, but I am thinking of disabling the ability to create teams on any body without a minimum population (perhaps 1m). This is particularly for espionage teams so you can't just create them on alien worlds. For geology teams, I could add some default orders for shuttles to move them around automatically.

Or, I remove the concept of teams entirely and replace them with new ground force capabilities. Thinking out loud....

1) Espionage team replaced by a scout function for ground forces. Scout formations can land on alien worlds to learn about the alien population (size, industry, tech, ground forces). They are have (expensive) stealth capabilities boosted by the formation commander (stealth bonus replaces espionage). They can be hunted by hostile ground forces or have a chance of detection by any civilian population (much higher if not same species).

2) Geology team replaced by geological survey capability for ground forces and ground survey becomes a significantly larger task requiring more personnel - to prevent simply creating vast number of geo-survey formations. Geology bonus based on the formation commander

3) Xenology team replaced by Xenoarchaeology capability for ground forces. Surveying and deciphering alien ruins becomes a significantly larger task requiring more personnel. Xenology bonus based on the formation commander.

4) Diplomacy team replaced by small but expensive ship module that can only function when in the same system as an alien population. I also change NPR responses so that their reaction to alien ships in the system is based on ship size and reduced if the ship has a diplomatic function. Diplomacy skill is based on the ship commander.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on February 11, 2018, 08:00:29 AM
Could we have a button to rename a system or body for all player races, not just the currently active one?

Its not a major thing, would just save a lot of clicks.

Good idea. I've added 'Rename System All' and 'Rename Body All' to the System View in C# Aurora.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Hazard on February 11, 2018, 08:03:39 AM
I haven't coded anything yet, but I am thinking of disabling the ability to create teams on any body without a minimum population (perhaps 1m). This is particularly for espionage teams so you can't just create them on alien worlds. For geology teams, I could add some default orders for shuttles to move them around automatically.

Or, I remove the concept of teams entirely and replace them with new ground force capabilities. Thinking out loud....

1) Espionage team replaced by a scout function for ground forces. Scout formations can land on alien worlds to learn about the alien population (size, industry, tech, ground forces). They are have (expensive) stealth capabilities boosted by the formation commander (stealth bonus replaces espionage). They can be hunted by hostile ground forces or have a chance of detection by any civilian population (much higher if not same species).

2) Geology team replaced by geological survey capability for ground forces and ground survey becomes a significantly larger task requiring more personnel - to prevent simply creating vast number of geo-survey formations. Geology bonus based on the formation commander

3) Xenology team replaced by Xenoarchaeology capability for ground forces. Surveying and deciphering alien ruins becomes a significantly larger task requiring more personnel. Xenology bonus based on the formation commander.

4) Diplomacy team replaced by small but expensive ship module that can only function when in the same system as an alien population. I also change NPR responses so that their reaction to alien ships in the system is based on ship size and reduced if the ship has a diplomatic function. Diplomacy skill is based on the ship commander.

I like these changes.

For the scout units; the main issue would be moving them around. You want to be able to land a full formation with a single 500 tons or less spacecraft, and you want it to keep viable at all tech levels. This means that the stealth and reduced thermal signature mechanics need to be reconsidered. Also; the scout unit values should be impacted by planetary fortification mechanics. It's easier to hide in hard to travel through terrain.

Geosurvey capability should probably be restricted to engineering/construction units. The question of whether or not it's an inherent trait of them or a result of a specific skill or modifier or equipment is an open one, but it would require a lot of equipment regardless. Ship based geosurvey sensors kind of cheat, but by the mechanics of the game they don't actually catch everything, usually. Ground unit based geosurvey mechanics may be adjusted or not to limit odd results like an orbital survey finding nothing at all while a ground unit survey finds millions of tons of multiple minerals at high availability.

Xenoarcheology capability should likewise be restricted. It may be interesting to have the first round of ground combat if the xenoarcheology roll comes up with 'active defender bots' exclusively target a (random) xenoarcheology unit on planet. Kind of to emphasize that whole 'and they found something dangerous that killed the research team' you so often find in sci-fi stories.

A Diplomacy ship would be interesting, potentially with multiple ratings and sizes of 'diplomatic suite.' Bigger/better diplomatic suites are more capable, but especially the bigger ones may cause trouble. Maybe adjusting the impact of ships based on current relations, with larger ships with larger facilities being more effective when relations are already good?
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on February 11, 2018, 08:06:16 AM
Ability to manually design solar systems for use ingame.

Right now, the only guaranteed system we have is Sol. I'd like the ability to in future versions of the game, hand the game a well managed CSV file that dictates a system or systems that would be added to a roster for systems to be generated when visiting new systems, OR be able to grab them at will when using the "create new system" button in the F9 menu.

This is a much larger task than it sounds. I think it required about a year to write the original system generation code (much faster to translate to C#). The code performs a lot of checks to ensure systems are correct as they are generated and it would be hard to do that from outside the program.

What might be possible is to save systems created in game for future use (assuming version compatibility) and add some tools to modify systems in-game.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Tree on February 11, 2018, 09:00:22 AM
What might be possible is to save systems created in game for future use (assuming version compatibility) and add some tools to modify systems in-game.
That'd be great.
Would it possible to also force the game to generate a somewhat customized system? Something like asking for a G2V class star or a planet with a colony cost below 1 or usable Lagrange points, that sort of thing? Maybe not make the game generate the system with a goal in mind but maybe make the game generate a system and trash it instantly if it doesn't fit, until it outputs one that does? With some limit maybe, so that you can't just ask something impossible and get the game locked up forever.
That'd preserve some of the surprise, even if you know there's going to be a close to inhabitable planet in the new system, nothing guarantees there won't be an NPR, or Precursors. If you get a G2V star, nothing says there'll be an inhabitable planet, etc.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Titanian on February 11, 2018, 04:16:16 PM
Good idea. I've added 'Rename System All' and 'Rename Body All' to the System View in C# Aurora.
Even better would be something like 'Rename System/Body for selected races', opening a dialog with checkboxes for all races.

Would also be useful to have for intelligence info on ship classes, especially on the first increment in multi empire earth starts, where all classes detected during the first increment get random names as the races have not detected each other before.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: alex_brunius on February 12, 2018, 04:14:18 AM
In VB6, and in what C# currently looks like, Box launchers seem to be just better than regular launchers 90% of the time.

At the moment 100 Boxes takes up the same space as 20 0. 25 mod launchers and 170 missiles of magazine space roughly, giving you half as many missiles but 5x the alpha strike.  And those 0. 25 launchers still have a x100 reload.  In C# aurora 0. 25 size has been increased to 0. 3 so the ratio will be even more favourable to the boxes. 

Is this really true or am I missing something here? Box launches having 0.15 size vs 0.25 size should mean 100 Boxes take up the same space as 100*0.15/0.25 = 60 max reduced size launchers when I do the math. Changing it to 0.3 would mean 2:1 ratio or a 2x greater alpha strike, no more.

In VB6 and in C#, this means that the enemy will require 5x as many beam weapons to shoot down all of the missiles.
In VB6 due to the long range of AMMs, they could engage the single box launcher wave with many salvos, meaning that box launchers could often be worse against fast firing AMMs.  due to the lower amount of missiles.  However with the missile changes of C#, the range of AMMs has been decreased if I am not mistaken, which would favour one single large wave.

The range of AMMs has been decreased but I don't think it will result in that much less performance for a few reasons:

- VB6 AMMs only needed tiny % of size being fuel, like 1-5% so even if that increase by x4 you still won't need alot of AMM size % fuel to get more range then you need.
- Incoming missiles will be slower and larger overall, since they also get hit by the same fuel formula change, and probably get hit alot harder by it ( fuel in VB6 Aurora is a serious concern for ASM as is ).
- Sensors changes in C# also limit your ability to extend the AMM cover with a single huge res 1 sensor, so having alot of AMM range won't be very useful in practice.
- C# Changes to ECM/ECCM and missile sensors (http://aurora2.pentarch.org/index.php?topic=8495.msg103096#msg103096) inherently favor ASM and quality over quantity.
- Box launchers hit while containing a missile will explode in C# Aurora, and their reload was increased by 6.7 times. (link (http://aurora2.pentarch.org/index.php?topic=8495.msg102815#msg102815))
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Garfunkel on February 12, 2018, 09:19:56 AM
Would also be useful to have for intelligence info on ship classes, especially on the first increment in multi empire earth starts, where all classes detected during the first increment get random names as the races have not detected each other before.
You already can do this via Space Master. Check the diplomacy window carefully with SM turned on.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Titanian on February 12, 2018, 11:37:47 AM
- Box launchers hit while containing a missile will explode in C# Aurora.
Whether or not this has any effect depends on the details. If it works like magazines currently do, than empty magazines get hit first. Also one could launch all missiles (or just a few to create empty launchers, which get hit first) at a dummy target when overwhelming incoming missiles are detected, loosing the missiles is better than loosing the ship after all.

You already can do this via Space Master. Check the diplomacy window carefully with SM turned on.
Yes, but only after the empires have detected each other, and having to manually rename all starting classes per empire for each pair of 8 empires is very much clicking. There is other ways around it, like only sm-creating the ships after the first time increment, and it won't happen to me again, but knowing that does not help when it has already happened after designing and creating all the classes for all these empires. So it might be a function that is nice to have
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on February 12, 2018, 12:43:27 PM
Would it be possible for C# Aurora to change the movement mode when issuing new orders? ATM a ship stops where it is when giving a new order and then resumes moving when the order is executed. However this is very odd in a close combat or in real life where a ship would continue on its course and speed until the new order is executed. Would love to see that behaviour also in C# Aurora.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on February 12, 2018, 01:46:03 PM
Would it be possible for C# Aurora to change the movement mode when issuing new orders? ATM a ship stops where it is when giving a new order and then resumes moving when the order is executed. However this is very odd in a close combat or in real life where a ship would continue on its course and speed until the new order is executed. Would love to see that behaviour also in C# Aurora.

I haven't tackled the inexperienced fleet penalties yet, so I will bear this in mind when I do. There are some complexities though. Not all orders involve direction and the ship should only stop anyway if you remove the existing order and give a new one. Some form of abandon current order and move to next might be an option (with a delay) but the issue is that the second order may not make sense unless the first is completed. Another option may be that the crew operates on its own initiative until it responds to an order (moving away or toward the enemy depending on morale). In general though Aurora ships all stop when completing their orders list as it would not make sense for them to continue in the same direction.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Graham on February 12, 2018, 09:05:23 PM
Quote from: alex_brunius link=topic=8107.   msg106566#msg106566 date=1518430458
Is this really true or am I missing something here? Box launches having 0.   15 size vs 0.   25 size should mean 100 Boxes take up the same space as 100*0.   15/0.   25 = 60 max reduced size launchers when I do the math.    Changing it to 0.   3 would mean 2:1 ratio or a 2x greater alpha strike, no more.   


This doesn't take into account magazine space though.    Yes you could get half the alpha strike of box launchers using regular launchers, but now you have half as many missiles.    If you want to actually have any advantage and have an appreciably greater quantity of missiles, then your alpha strike potential becomes much lower.   

And in terms of box launchers exploding in C#, that just brings them back inline with magazines, although the explosion chances are higher.    Even then by the nature of box launchers, it is unlikely you will be taking damage with missiles still intact, and it is easy to launch all missiles the second the armour of your ship is breached.

The balance issue I have is that it is basically impossible for a beam focused fleet to combat box launched strikes, and the disadvantages of using box launchers are currently fairly minor IMO.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TheDeadlyShoe on February 12, 2018, 09:28:37 PM
it's too early to say. AMM ships don't look like they'll be as strong, and the main reason tfs take no damage even when fired on is invincible amm screens that can only be depleted, rarely defeated.

Title: Re: Semi-Official 7.x Suggestion Thread
Post by: sloanjh on February 13, 2018, 07:38:04 AM
I haven't tackled the inexperienced fleet penalties yet, so I will bear this in mind when I do. There are some complexities though. Not all orders involve direction and the ship should only stop anyway if you remove the existing order and give a new one. Some form of abandon current order and move to next might be an option (with a delay) but the issue is that the second order may not make sense unless the first is completed. Another option may be that the crew operates on its own initiative until it responds to an order (moving away or toward the enemy depending on morale). In general though Aurora ships all stop when completing their orders list as it would not make sense for them to continue in the same direction.

For the sake of argument, assume the order delay is 30s in the discussion below.

I think the idea here is that when an "interrupt order" is given (where any order that will happen in the next 30s is deleted) the current order queue continues for 30s, at which point Aurora changes the queue to put the new order first.  To put it a different way, Aurora would save and continue executing the old queue for 30s, then an interrupt would happen and the old queue would be thrown away and Aurora would start executing the new queue.  If the new queue didn't make sense, the TG would stop and do nothing (or try to execute the next order in the new queue until it ran out too), representing command confusion.  If one were going to be complete about it, there would actually be a queue of queues to represent "order, counter-order, dis-order": if a player gave an interrupt order at time=0, then gave another at time=10s and another at time=15s, there would be 4 queues instantiated at time=20s (the original plus 3 interrupts) and interrupts would happen at time=30s, 40s, and 45s.  Obviously there would be no delay for orders that were planned ahead.

The main reason I'm posting this, however, is that I realized that the above could be generalized in the game mechanics to a general "time delay" mechanism.  One of the things I REALLY liked about SA was the ability to send myself a message with a delay of N turns.  If the Aurora code had infrastructure to manage delayed events, there are probably other places where it would  be useful, e.g. speed of light detection and/or weapons' fire at > 5 light-seconds.  At the very least, it would be great to be able to send myself a message that would show up in a week (the old SA functionality) :)

John
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: TMaekler on February 13, 2018, 09:42:21 AM
I haven't tackled the inexperienced fleet penalties yet, so I will bear this in mind when I do. There are some complexities though. Not all orders involve direction and the ship should only stop anyway if you remove the existing order and give a new one. Some form of abandon current order and move to next might be an option (with a delay) but the issue is that the second order may not make sense unless the first is completed. Another option may be that the crew operates on its own initiative until it responds to an order (moving away or toward the enemy depending on morale). In general though Aurora ships all stop when completing their orders list as it would not make sense for them to continue in the same direction.

I see the problems that could arise. Continuing on is mainly important in battle. So maybe just a switch which sets a ship in battle mode (Red Alert) causes movement commands to continue when given a new movement command. Any other command and the ship stops (and possibly leaves Red Alert mode).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Conscript Gary on February 14, 2018, 03:55:47 AM
Similar to the button to export all designed ship classes as a text file, would it be feasible to have a similar function for racial techs/components/missiles as well? A common issue I run into when discussing Aurora with friends of mine who play it is that attempting to reverse-engineer someone's ships accurately from just the export data is pretty much impossible, and even with the help of the technology summary screen it's a tedious process- especially if someone is using tactics like not making use of the highest tech level available to them for whatever reason, or if a component is simply old.

It'd also be a great boon for people attempting to do any sort of multiplayer interaction that doesn't involve hotswapping database files (design competitions and such, I'm personally setting one such friendly brawl between two folks at the moment which is what prompted this suggestion).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Erik L on February 14, 2018, 01:13:04 PM
Similar to the button to export all designed ship classes as a text file, would it be feasible to have a similar function for racial techs/components/missiles as well? A common issue I run into when discussing Aurora with friends of mine who play it is that attempting to reverse-engineer someone's ships accurately from just the export data is pretty much impossible, and even with the help of the technology summary screen it's a tedious process- especially if someone is using tactics like not making use of the highest tech level available to them for whatever reason, or if a component is simply old.

It'd also be a great boon for people attempting to do any sort of multiplayer interaction that doesn't involve hotswapping database files (design competitions and such, I'm personally setting one such friendly brawl between two folks at the moment which is what prompted this suggestion).

I think a lot of people like that trying to reverse-engineer is not exact. Not to say that sort of button won't be useful :)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Conscript Gary on February 14, 2018, 06:20:49 PM
I think a lot of people like that trying to reverse-engineer is not exact. Not to say that sort of button won't be useful :)

From an in-game standpoint I can agree with that, but not so much when it comes to out-of-game reproducability  :P
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: sloanjh on February 21, 2018, 09:21:26 PM
FYI, there is now an official suggestion thread in the C# section (v0.x).  Since Steve is committed to getting the C# version out, it is extremely unlikely that there will ever be another VB version of Aurora, so any new suggestions should go into the C# thread.

Thanks,
John

PS - please read the posting guidelines at the beginning of that thread if you are unfamiliar with the way Steve uses the suggestion thread as a tracking database.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Rayuke on February 28, 2018, 03:55:34 PM
tachyon technologies, between both a displacement drive (or "wink" drive) also a tachyon gun that "teleports bombs into or around other ships" source is from the Odyssey One Book series
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on April 03, 2018, 11:48:27 AM
Suggestion:

Damage to a ship should do more than just reduce the HTK or break parts.  It should also have a chance to start a fire.  Aurora generally tries to emulate 20th and 21st century naval warfare, and during that time period fire was a major threat to warships.  It's a major reason the IJN suffered so badly in WW2.  Japanese crews weren't trained to fight fires; they had designated damage control teams.  Crews were trained to abandon their station and call for a DC team in the event of fire.  This meant that the fire would burn uncontrolled for several minutes, and would be much worse by the time the damage control team arrived.  American crews on the other hand were all trained to immediately start fire fighting.

Compare two examples.  The IJN Akagi was hit by a single 1000lb bomb at approximately 10:30AM, June 4th during the Battle of Midway.  Over the course of the day, Japanese damage control teams fought a losing battle against the flames, and at 4:30AM June 5th they were forced to scuttle the ship.

The USN Bunker Hill was hit by two kamikazes and two 550lb bombs in quick succession during the Battle of Okinawa.  390 crew were killed, but fires were put out and the ship was saved.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: tobijon on April 03, 2018, 01:55:56 PM
Quote from: Rayuke link=topic=8107. msg106917#msg106917 date=1519854934
tachyon technologies, between both a displacement drive (or "wink" drive) also a tachyon gun that "teleports bombs into or around other ships" source is from the Odyssey One Book series

how would tachyons help teleport something? they are just particles moving faster than light
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Hazard on April 03, 2018, 05:28:27 PM
Fires are much more dangerous in space. Spaceships are enclosed systems, you can't just vent the heat and toxic smoke the way you can on Earth. On the other hand, ships will be designed presuming that you need to close down entire sections of the ship at a time from air flow, either because of a hull breach or because of a fire or any other disaster, so fire control is a lot easier; just let the fire consume all oxygen and if possible use the cooling system to chill the local temperature to below the ignition temperature. Or, for that matter, open the burning sections to hard vacuum, it'll resolve itself soon enough.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on April 03, 2018, 07:09:54 PM
tachyon technologies, between both a displacement drive (or "wink" drive) also a tachyon gun that "teleports bombs into or around other ships" source is from the Odyssey One Book series
Your tachyon gun idea is basically what mesons do.  Mesons don't interact with anything, and when they decay they release a huge amount of energy.  You can control how long a meson takes to decay when you create it.  So what happens is, the fire control computer decides how far away the target is, and thus how long the meson should take to decay.  The meson is fired, it passes cleanly through the armor because mesons don't interact with anything.  Then, assuming the FC was accurate in it's distance measurement, the meson decays inside the ship, and goes off like a bomb.

They also travel at 99% the speed of light, so as far as the target is concerned, it teleported there.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: JacenHan on April 03, 2018, 09:43:48 PM
Fires are much more dangerous in space. Spaceships are enclosed systems, you can't just vent the heat and toxic smoke the way you can on Earth. On the other hand, ships will be designed presuming that you need to close down entire sections of the ship at a time from air flow, either because of a hull breach or because of a fire or any other disaster, so fire control is a lot easier; just let the fire consume all oxygen and if possible use the cooling system to chill the local temperature to below the ignition temperature. Or, for that matter, open the burning sections to hard vacuum, it'll resolve itself soon enough.

This FTL parody (https://www.youtube.com/watch?v=RVHw5Hcat9s) came to mind. "Works on people too."
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on April 21, 2018, 09:33:44 AM
I'm not advocating that particular use of POWs, but I would like to see them have some added effect or utility in the game. I run across planets that have survivors and POWs on them, but I can't really do anything with them, as far as I can tell.

That is a bug in VB6. The random POWs you find are from old games. They aren't being deleted correctly.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Garfunkel on May 03, 2018, 07:55:35 AM
Make default orders check whether the ship in question can complete it before executing it. For example, I have a Survey Group with a Jump Tender and multiple Survey Ships. I set Grav Survey as its default order and order the TG to split into individual ships after jumping through an unknown JP. Afterwards, I have to remember to clear default orders for the CJ as otherwise it will fruitlessly try to survey the JP locations.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Kurt on May 03, 2018, 11:30:28 AM
That is a bug in VB6. The random POWs you find are from old games. They aren't being deleted correctly.

Genius!

"Are they dead?"
"Yes"
"Are you dead?"
"No."
"Success!"

Ha!
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: sloanjh on May 04, 2018, 07:05:03 AM
Genius!

"Are they dead?"
"Yes"
"Are you dead?"
"No."
"Success!"

Ha!

Kurt!!!  Welcome back!!!!!

John
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Kurt on July 04, 2018, 12:43:19 PM
Genius!

"Are they dead?"
"Yes"
"Are you dead?"
"No."
"Success!"

Ha!

Kurt!!!  Welcome back!!!!!

John

Glad to be back!
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Rayuke on July 17, 2018, 09:35:29 PM
Quote from: tobijon link=topic=8107. msg107632#msg107632 date=1522781756
Quote from: Rayuke link=topic=8107.  msg106917#msg106917 date=1519854934
tachyon technologies, between both a displacement drive (or "wink" drive) also a tachyon gun that "teleports bombs into or around other ships" source is from the Odyssey One Book series

how would tachyons help teleport something? they are just particles moving faster than light
its easier to understand in the book but basically they convert the bomb into tachyons, as barkhorn said its almost exactly like mesons work, i also thank the other techs from the books would work awesomely hear armor that reflects lasers to 99% of there energy or armor that absorbs light 99% that its basically cloaked but is absolutely susceptible to laser fire, antimatter blasts, much like missiles but made for close combat (not exactly a good idea for this game) and power plants that are black holes that consume refuse and random matter for fuel but are detectable by gravametric censers but effect the accary of the tachyons (mesons) and last but not least tachyon censers that take a "snapshot" of the local space
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Felius on July 23, 2018, 08:38:09 AM
As instructed:


One of the main issues I've been finding with beam ships is that continuously scaling costs for more advanced beam fire controls as tech advances. With that in mind, I'd like to propose that its costs only scale with the multipliers applied to it, the tech advances being "free" bonuses.

In further thoughts: What I'd envision to make beam FCs better: Higher base cost to compensate a bit the non-escalating costs. "Sliding" values for range and speed instead of fixed multipliers, allowing for more precise fine control of the values, with a minimum and maximum value. Said value might just be the present 25% and 4x, or it could be set by tech, starting closer to 1 and increasing back to the present possible values (or other values, although that might present some issues with absolute max range due to light speed).
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: SpikeTheHobbitMage on July 24, 2018, 09:53:50 PM
As instructed:


One of the main issues I've been finding with beam ships is that continuously scaling costs for more advanced beam fire controls as tech advances. With that in mind, I'd like to propose that its costs only scale with the multipliers applied to it, the tech advances being "free" bonuses.

In further thoughts: What I'd envision to make beam FCs better: Higher base cost to compensate a bit the non-escalating costs. "Sliding" values for range and speed instead of fixed multipliers, allowing for more precise fine control of the values, with a minimum and maximum value. Said value might just be the present 25% and 4x, or it could be set by tech, starting closer to 1 and increasing back to the present possible values (or other values, although that might present some issues with absolute max range due to light speed).
We directly key in tracking speed when designing turrets, so having the same option for FC makes sense.  Selecting tonnage as well and getting a range might be advantageous.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on July 25, 2018, 11:13:18 PM
Having more scalable beam fire controls sounds really fun to me.  Then you can have a long range laser battleship that has some gigantic super expensive fire control, just so it can fight off a 100 tonne harassment fighter from a much more advanced faction.  That sort of hilarity.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Titanian on July 26, 2018, 06:21:40 AM
And fire control tracking speed really need a nonlinear scaling factor. Otherwise x4 is always the right choice for turreted pd. All the other settings exept x1.25 get used only very rarely by me, as x1.25 is usefull for railgun pd as it futureproofs the firecontrols for when the next level of fire control speed instantly upgrades all non-turreted weapons. All the other settings I don't really use, as my bfc tracking tech is usually higher than my ship speeds anyway.

Finer granularity would be nice for several settings, especially capacitor recharge. Then one could finally produce 10cm laser with 1.5 recharge rate instead of 2, and so on. Would be especially useful for particle beams with all their odd power requirements.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: jwoodward48 on September 23, 2018, 02:21:37 PM
In the System Information screen, Jupiter is listed as having the same magnetic field strength as Earth.  According to Wikipedia, this should be around 20 times that of Earth.  (Unless I misinterpreted "magnetic field" and it's measuring something different instead. )

(Also, Saturn should be somewhat less than Earth, but the two are listed as having the same magnetic field.  They're close enough that it's tricky, since magnetic field strength varies over the surface of Earth, but Saturn's average is less than the typical minimum for Earth, so it should be something from 0. 32 to 0. 84. )
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on September 23, 2018, 04:23:37 PM
In the System Information screen, Jupiter is listed as having the same magnetic field strength as Earth.  According to Wikipedia, this should be around 20 times that of Earth.  (Unless I misinterpreted "magnetic field" and it's measuring something different instead. )

(Also, Saturn should be somewhat less than Earth, but the two are listed as having the same magnetic field.  They're close enough that it's tricky, since magnetic field strength varies over the surface of Earth, but Saturn's average is less than the typical minimum for Earth, so it should be something from 0. 32 to 0. 84. )

Thanks for mentioning. I will update them. At the moment, magnetic field isn't used for any in-game function so the discrepancy hasn't affected anything.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on October 15, 2018, 06:39:05 PM
I suggest rethinking tracking speed to account not for the target's velocity, but instead its radial velocity.  A target moving directly towards or away from you has much lower radial velocity than one moving tangentially to you.  If you've ever gone skeet shooting, or defended against air attack in Silent Hunter 3, you'll surely have noticed it's much easier to aim at and hit targets moving directly towards or away from you.  It is also occasionally easier to aim at a target that is farther away than one that is closer, because farther targets will have a lower radial velocity.  A turret may be fast enough to track a target out near max range, but not fast enough to track it at close range.

This I think would provide a welcome buff to FAC's and fighters.  It would mean that turreted beam weapons would have optimal range bands, instead of always being more accurate as distance decreases.  This would mean fighters may be able to get in under the minimum effective range of the main guns, while remaining out of range of defensive armament.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Jorgen_CAB on October 15, 2018, 06:49:38 PM
I suggest rethinking tracking speed to account not for the target's velocity, but instead its radial velocity.  A target moving directly towards or away from you has much lower radial velocity than one moving tangentially to you.  If you've ever gone skeet shooting, or defended against air attack in Silent Hunter 3, you'll surely have noticed it's much easier to aim at and hit targets moving directly towards or away from you.  It is also occasionally easier to aim at a target that is farther away than one that is closer, because farther targets will have a lower radial velocity.  A turret may be fast enough to track a target out near max range, but not fast enough to track it at close range.

This I think would provide a welcome buff to FAC's and fighters.  It would mean that turreted beam weapons would have optimal range bands, instead of always being more accurate as distance decreases.  This would mean fighters may be able to get in under the minimum effective range of the main guns, while remaining out of range of defensive armament.

This would be an interesting addition to the game if easily implemented.

In spirit of this I also think that size should matter in ship to ship combat as well. It should be progressively harder to shoot at a small as oppose to a large target. Big targets should have the armor and shield advantages to take hits from big weapons, small targets should avoid them through size and speed.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Garfunkel on October 16, 2018, 06:48:09 PM
Shouldn't this thread be closed, since C# Aurora Suggestions thread exists? Or is it still useful to Steve as a sort of filing cabinet of dreams and hopes? :D
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on October 16, 2018, 06:49:07 PM
Shouldn't this thread be closed, since C# Aurora Suggestions thread exists? Or is it still useful to Steve as a sort of filing cabinet of dreams and hopes? :D

It should probably be closed in favour of the C# suggestion thread, although I will still work my way through it when I have the time.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: SIX10 on December 17, 2018, 07:50:28 PM
I don't know if this is the place to make the suggestion or if this the "galactic empire" option in the game (i assumed that was Star Wars) but it would be cool to have a Asimov Foundation/Empire theme in the game.  I would be down to make it or help out.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on December 18, 2018, 02:50:58 AM
I don't know if this is the place to make the suggestion or if this the "galactic empire" option in the game (i assumed that was Star Wars) but it would be cool to have a Asimov Foundation/Empire theme in the game.  I would be down to make it or help out.

If you can produce the name lists as text files (one name per line), I will add them to the game.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: iceball3 on December 27, 2018, 02:02:00 AM
One thing that might be handy to add if it hasn't yet would be a Commander Graveyard, where our commanders and their history are saved to when they go MIA or die, to allow their campaign history, notes, recorded roles, attributes and skills before they died.
Similarly, another handy idea could be the allowance of portraits to be assigned to commanders (on an opt-in basis, as maintaining hundreds more portraits for every species is a bit of unnecessary bloat) as to allow players and GMs alike to add some more flavor to their command structure.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on December 27, 2018, 08:56:42 PM
Also, posthumous promotion/medal awards.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Erik L on December 27, 2018, 11:34:51 PM
Also, posthumous promotion/medal awards.

From a gameplay/mechanics standpoint, what effect would that have? Medals currently only affect promotions.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on December 27, 2018, 11:36:50 PM
Mainly because its partly a roleplaying game, thusly players would probably find that to be an enjoyable thing to do.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Erik L on December 27, 2018, 11:47:54 PM
Mainly because its partly a roleplaying game, thusly players would probably find that to be an enjoyable thing to do.

I figured roleplaying was the reason :)

There used to be a dead/retired commander list in the Commander window, but it got removed because long games made it incredibly slow to load, if I recall.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: El Pip on December 28, 2018, 03:17:17 AM
Mainly because its partly a roleplaying game, thusly players would probably find that to be an enjoyable thing to do.

I figured roleplaying was the reason :)

There used to be a dead/retired commander list in the Commander window, but it got removed because long games made it incredibly slow to load, if I recall.
Tie the two together. Commanders get retained on a dead/retired list for a short period, say ~60 days (long enough that you don't accidentally skip over their death when running a 30 day turn) and are only retained on the dead/retired list if the player grants them a medal.

That way all the Lt Cdrs who ran fuel harvesters and freighters get forgotten, and don't slow the game down, while the heroes get memorialised.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: King-Salomon on December 28, 2018, 09:41:54 AM
not sure it make sense to list all the "accidential dead" commanders in the list...

what I was thinking some time ago was a "legendary role of honor" with KIA Commanders and pre-death flagged commanders by the player "so they do something and the player decides this one has to be remembered...

...

in the same category comes ships that were destroyed by the enemy... VB7 is already listing destroyed ships from "other races" - so it is also listing the player-ships which were destroyed (it has to as a 2nd player race would have them listed as "destroyed" in there intel-screen f.ex.)

I wanted to mahe a suggestion to add a "legacy update" after C#1.0 with this "features", but as the commander-list was mentioned now, it is a good time as later...
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Steve Walmsley on December 28, 2018, 10:26:02 AM
Currently C# is holding on to the dead commanders in memory until you shut down the game, although you can't see them. It wouldn't be much of a stretch to display those and let you decide which ones to store in a hall of fame.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: QuakeIV on December 28, 2018, 05:07:10 PM
Currently C# is holding on to the dead commanders in memory until you shut down the game, although you can't see them. It wouldn't be much of a stretch to display those and let you decide which ones to store in a hall of fame.

I would personally like such a thing.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Barkhorn on December 28, 2018, 06:01:19 PM
It could be automatic.  Retain any person who did any of the following
1) Commanded a ship or ground unit that took or dealt damage
2) Commanded a ship that jumped into an undiscovered system
3) Made some measure of espionage progress
4) Researched a technology
5) Governed a population, perhaps over some population threshold.
6) was marked for retention by the player
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Erik L on December 28, 2018, 07:14:40 PM
It could be automatic.  Retain any person who did any of the following
1) Commanded a ship or ground unit that took or dealt damage
2) Commanded a ship that jumped into an undiscovered system
3) Made some measure of espionage progress
4) Researched a technology
5) Governed a population, perhaps over some population threshold.
6) was marked for retention by the player

I second this :)
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: Garfunkel on December 29, 2018, 09:01:49 AM
Indeed, that would be a sweet feature.
Title: Re: Semi-Official 7.x Suggestion Thread
Post by: MarcAFK on January 06, 2019, 12:25:49 AM
Could dump them to a graveyard file when you close the game, could make a new graveyard every 10 years or so, or whatever is needed to prevent the file getting too bloated. Yearly even?