Aurora 4x

C# Aurora => C# Suggestions => Topic started by: Inglonias on April 12, 2020, 08:09:39 AM

Title: C# Suggestions
Post by: Inglonias on April 12, 2020, 08:09:39 AM
I can't believe this is a problem. Auto turns is SO fast that at game start, it's unusable and I waste precious time. Can we do one of these things?

1. Measure wall clock time on the turn and if it takes less than, say 0.1 seconds IRL, have the game just delay for a bit if auto turns is enabled
2. Maximum number of auto turns box, similar to the minimum increments in VB6
Title: Re: We've come so far - Auto turns are TOO FAST
Post by: RagnarVaren on April 12, 2020, 08:11:17 AM
I would prefer the second option personally
Title: Re: We've come so far - Auto turns are TOO FAST
Post by: MarcAFK on April 12, 2020, 08:11:49 AM
Thats a feature I've always wanted aurora to have. In fact, what I want is max increments of the time you have selected, increments lower than that arent counted. Bassically if i select 5 day auto turns and have max 10 selected it will auto turn untill passing 50 days then stop, irregardless of how many smaller increments it hits
Title: Screen Resolution
Post by: razanon on April 12, 2020, 09:47:25 AM
First of all, need to thank you Steve for that game. many years creating an empire, and living experiences no other game can bring.

i have new game, but old problems :)

as a lot people have, my screen resolution is 1366X768.

is there any way to change it? we need to use the 3rd party programs always recommend people?

thx in advance!
Title: Re: Screen Resolution
Post by: Father Tim on April 12, 2020, 09:55:52 AM
First of all, need to thank you Steve for that game. many years creating an empire, and living experiences no other game can bring.

i have new game, but old problems :)

as a lot people have, my screen resolution is 1366X768.

is there any way to change it? we need to use the 3rd party programs always recommend people?

thx in advance!

These days we're a lot better off than twenty years ago when Aurora first overran 768 height monitors.  You can HDMI into a televison, or BlueTooth, or shoutcast, or AppleTv, etc.

Otherwise. . .  well, C# on .NET is supposed to be easier to resize windows than Visual Basic, so maybe?
Title: Re: Screen Resolution
Post by: Steve Walmsley on April 12, 2020, 10:23:56 AM
First of all, need to thank you Steve for that game. many years creating an empire, and living experiences no other game can bring.

i have new game, but old problems :)

as a lot people have, my screen resolution is 1366X768.

is there any way to change it? we need to use the 3rd party programs always recommend people?

thx in advance!

According to Steam stats, only about 10% of people have resolutions below 1440x900, so that is why I chose that resolution. I don't plan to add a smaller resolution, but there are lots of options for cheap external monitors or using TV, etc.
Title: Re: Screen Resolution
Post by: razanon on April 12, 2020, 10:31:43 AM
yeah sure guys, never wanted to add you more jobs!

i have a computer attached to the TV, so theres no problem to play normally, only wanted to know if im outside with my old laptop. :)

only wanted to know if theres any way to change it easily :)

Title: Re: Screen Resolution
Post by: Energyz on April 12, 2020, 10:35:52 AM
Quote from: Steve Walmsley link=topic=10641.    msg121077#msg121077 date=1586705036

According to Steam stats, only about 10% of people have resolutions below 1440x900, so that is why I chose that resolution.     I don't plan to add a smaller resolution, but there are lots of options for cheap external monitors or using TV, etc.   

I guess not a lot of people are gaming with laptops (cause you want a big screen, and a good graphic card), but the most common resolution is 1366x768.     According to  https://www. rapidtables. com/web/dev/screen-resolution-statistics. html Of course this table is for web development, but I guess still representative of what people want to use to play aurora if you remove smartphones and such
Title: Remove confirmation popup for research Create Project
Post by: Doren on April 12, 2020, 10:42:32 AM
Since create project just assigns the researcher and labs and those projects can be cancelled with no ill effects I do not see much reason to show "are you sure" confirmation popup.
Since there's nothing being possible lost this confirmation is just one additional click to create a project
Title: Re: Screen Resolution
Post by: razanon on April 12, 2020, 10:44:11 AM
well im using this computer only to design things, or playing games like Aurora 4x, Balrum RPG, Dwarf Fortress, War in the pacific... if i want to play any "elite Dangerous" ones, i have my pc :) but when im out and i have my laptop its good to have any games like that.
Title: Add a save line to Event Log on save
Post by: Doren on April 12, 2020, 11:33:49 AM
Would be nice to be able to check when you last saved if you are like me and tend to forget if I saved or not and want something to be able to look at and confirm instead of clicking save again

Line should have time of the save in the message
Title: Re: Screen Resolution
Post by: swarm_sadist on April 12, 2020, 12:02:57 PM
Having the ability to resize the windows to larger than your current window size would probably work. You would have to shuffle the screens around but it would be a good stopgap. I feel like some buttons are just out of sight. Very frustrating.  >:(
Title: Add queue to ground unit construction
Post by: Garfunkel on April 12, 2020, 12:35:49 PM
Ground units construction is annoying if you're making a complicated Order of Battle as small units are built really fast and require the player to constantly come back to order the next unit(s) to be built.

A queue, similar to industrial production, would be a good improvement here. That way I can have complicated OOBs built automatically.
Title: Restore next research notice in event log
Post by: Garfunkel on April 12, 2020, 12:37:00 PM
In the VB6 event log, when a scientist completed a project and there was another queued up for them, the event log told us so. In C#, this is no longer the case. If possible, it would be nice to have it back.
Title: Re: Add a save line to Event Log on save
Post by: Jobran180 on April 12, 2020, 12:45:41 PM
as a stopgap you can just look at the "Date Modified" of your AuroraDB. db in the main Folder
Title: C# Suggestions
Post by: spqrein on April 12, 2020, 12:45:59 PM
Is there a way to resize the font and or change color/type?  I am playing with the same monitor and setting as vb aurora but things just seem to small or smaller.   Maybe its the same but it just seems harder to read.   So I lowered my monitor setting to 1440x900 it helped a little but the font is still small for the increase in everything else.

Another option to is different back ground color?  The dark blueish color is nice but maybe a black background option would help some font and objects stand out better making the font easier to read against the background without resizing it.
Title: C# Suggestions
Post by: Erik L on April 12, 2020, 12:51:36 PM
Please put all of your suggestions in this thread.
Title: Re: C# Suggestions
Post by: Demonides on April 12, 2020, 12:57:48 PM
When you want quit the game, a window pop up and asking "do you want to save the game"



Title: Re: C# Suggestions
Post by: RagnarVaren on April 12, 2020, 01:35:11 PM
Currently trying to set standing orders for an Admin command prompts the player to select a fleet.  It would be nice if it instead set the standing orders for all fleets attached to the Admin command.  This could be used to quickly set up geosurvey standing orders for multiple fleets. 
Title: Re: C# Suggestions
Post by: Erik L on April 12, 2020, 01:35:43 PM
An autosave every xx number of days/increments.
Title: Re: C# Suggestions
Post by: KvaNTy on April 12, 2020, 01:36:47 PM
Option of Darker UI Theme for buttons array in main game window.

Game now became way less bright with all windows having nice pleasant dark-blue background.  But if you spend significant time in Class Design(for example) and then switch back to System View you are suddenly greeted with this particularly bright white chunk of the screen and it somewhat puts a stress on your eyes.

Easiest solution that comes to mind is to make background on these buttons the same as it is on Increment Length buttons.  I. e.  white border outline, blue fill in background, icon in the center.
Title: Re: C# Suggestions
Post by: Ektor on April 12, 2020, 01:44:26 PM
There could be an indicator of how many officers you have on a given rank. Like say "Lieutenant Commander (28)"
Title: Re: C# Suggestions
Post by: Steve Walmsley on April 12, 2020, 02:06:50 PM
When you want quit the game, a window pop up and asking "do you want to save the game"

I've added this for the patch.
Title: Re: C# Suggestions
Post by: dr125 on April 12, 2020, 02:22:53 PM
As one of those with a 1366x768 screen, is there any chance of a "can move the screen around" option? Obviously not now as I am sure bug-squashing takes priority.  I can open everything up and so on, but the buttons at the bottom don't even show up.  Another monitor isn't really an option at the moment. 
Title: Re: C# Suggestions
Post by: Tunsku on April 12, 2020, 02:41:07 PM
Quote from: dr125 link=topic=10640. msg121322#msg121322 date=1586719373
As one of those with a 1366x768 screen, is there any chance of a "can move the screen around" option? Obviously not now as I am sure bug-squashing takes priority.   I can open everything up and so on, but the buttons at the bottom don't even show up.   Another monitor isn't really an option at the moment. 
>move taskbar to the side
>move the windows up with the mouse to peek at the buttons
>window scaling in settings? I have heard that might work.
Title: Re: C# Suggestions
Post by: Gnoman on April 12, 2020, 02:53:56 PM
This is minor, but the premade classifications in the ship design window are currently organized by "Prefix, Specialty, Role" (DDG Missile Destroyer, for example).  Reorganizing these to "Role, Specialty, Prefix" (so "Destroyer, Missile, DDG") would have better organization.
Title: Re: C# Suggestions
Post by: Resand on April 12, 2020, 03:54:58 PM
Could we maybe get a option to select what interrupts the auto turns?

Turns go so fast that, I could really need to stop the auto turns on more events. 

Also could we get the default colors back in the event viewer please?  :)
Title: Re: C# Suggestions
Post by: unkfester on April 12, 2020, 03:58:16 PM
i cant seem to load auto mines on asteroid.  is it because of its got suffix of LG? or am i doing something wrong.
Title: Re: C# Suggestions
Post by: 01010100 on April 12, 2020, 04:15:41 PM
An autosave every xx number of days/increments.

I'd prefer if it were based on real time minutes, like autosave every 30 minutes. That way you'll never lose more than 30 minutes of real time, whereas number of days/increments might not correspond well to real time. For example you could be spending an hour designing ships and components without ever incrementing the game time.
Title: Re: C# Suggestions
Post by: RagnarVaren on April 12, 2020, 04:16:28 PM
Would be nice to have some way to save metals and their conditions between save games.  In particular an export/import mechanic so I don't need to make them myself but can simply use someone elses ;D
Title: Re: C# Suggestions
Post by: DEEPenergy on April 12, 2020, 04:42:50 PM
It would be nice to be able to prototype a whole formation template, get a research cost for the whole thing as one and then go straight to building it to avoid having to research many individual ground units and then build a formation from the pieces.
Title: Re: C# Suggestions
Post by: MrHuman on April 12, 2020, 04:58:39 PM
It would be nice if you could designate yourself what events stop the auto increment, fx, I'd like to be able to stop it when civilian mining colonies are founded or when minerals run out in my colonies.
Title: Re: C# Suggestions
Post by: Inglonias on April 12, 2020, 05:19:04 PM
With the new "Continual Capactiy Expansion until X" task for shipyards, the old fixed value expansions are more or less obsolete. Can we remove those?
Title: Re: C# Suggestions
Post by: Ektor on April 12, 2020, 05:42:00 PM
There should be some way to see how many % of your industrial capacity are still left after you assign projects.
Title: Re: C# Suggestions
Post by: RagnarVaren on April 12, 2020, 06:06:30 PM
Crew-Served Anti-Personnel on infantry provide 6x the firepower at 2. 4x the cost and 2. 4x the size compared to Personal weapons making them the overall more efficient option.  I think it would be a better trade off if they cost 6-8x as much instead making it a trade off between taking the more resource efficient personal weapons or the more space efficient Crew-Served Anti-Personnel.  Nerfing the AP of CSAP to 1 less than personal weapons could also be another option for balancing. 
Title: Re: C# Suggestions
Post by: James Patten on April 12, 2020, 06:23:44 PM
Wow.  There's a lot to take in with the new game (I've held off playing for a number of years waiting for this).  Thanks, Steve, for doing this.

I will second (or third) the request to change colors.  I find it very hard to read on top of the small fonts.

My laptop in it's natural configuration is 1920x1080, but I usually run it at 125% so that I can see things.  So I can flip from 125% (where I can see most of the Aurora windows) or 100% (where I can see everything but may not be able to read it).
Title: Re: C# Suggestions
Post by: SultanPepper on April 12, 2020, 07:47:05 PM
The ability to save a Race preset sort of thing would be great. Sometimes I make a new game to try something different, but have to re-create my racial data. It would be nice to have an export/import feature
Title: Re: C# Suggestions
Post by: nitrah on April 12, 2020, 08:25:07 PM
Quote from: Resand link=topic=10640.  msg121368#msg121368 date=1586724898
Could we maybe get a option to select what interrupts the auto turns?

Turns go so fast that, I could really need to stop the auto turns on more events.   

Also could we get the default colors back in the event viewer please?  :)

I would like to second both of these requests. 

The inability to ignore the 'minerals have run out on X colony' or 'a new civilian mine has been added to Hale-Bopp' notifications was one of my biggest frustrations with VB6. 

I would also like to add when new scientists are recruited; particularly early game.
Title: Re: C# Suggestions
Post by: Frick on April 12, 2020, 10:46:10 PM
The visual style of VB6. Turns out my eyes really don't dig the visual style now. Also I really miss the table lines, because of the straining from the colour it's an ever bigger strain to just make out how the rows go.
Title: Re: C# Suggestions
Post by: Whitecold on April 13, 2020, 01:39:48 AM
Missile engines larger than 5MSP. They probably need less increments there, but if you build supersized missiles, they should get proper engines.
Title: Re: C# Suggestions
Post by: Wieseltrupp on April 13, 2020, 01:44:16 AM
Please add a warning if you try to fit a commercial engined starship with a military jump drive
Title: Re: C# Suggestions
Post by: IronRagnar on April 13, 2020, 02:52:10 AM
First of all I would like to say: Thank you, Steve.  Aurora is a masterpiece.

Now on to the suggestion.  I may be mistaken, but there are a few features missing which were in VB6 and not in C# (at least I can't find them).  Both of them are extremely useful for multistarting.  One is "Give tech" option which was visible when comparing Tech in SM mode.  And the other one is "Transfer Fleet", which was available in the fleet menu. 

I apologize if they are in the game and I just missed them, however if they haven't been implemented, would you consider adding them?

Thank you again.
Title: Re: C# Suggestions
Post by: Resand on April 13, 2020, 03:12:55 AM
Quote from: Wieseltrupp link=topic=10640. msg121527#msg121527 date=1586760256
Please add a warning if you try to fit a commercial engined starship with a military jump drive

Military Jump engine can't jump commercial engined ship in C#?
Title: Re: C# Suggestions
Post by: Wieseltrupp on April 13, 2020, 03:14:58 AM
It will fail to transit, yes
Title: Re: C# Suggestions
Post by: Resand on April 13, 2020, 03:26:40 AM
Quote from: Wieseltrupp link=topic=10640. msg121541#msg121541 date=1586765698
It will fail to transit, yes

This used to work just fine, and I'm not seeing any post about changes stating it shouldn't
Maybe it's just a bug that you can't jump. 

Would explain why the game doesn't warn you
Title: Re: C# Suggestions
Post by: Wieseltrupp on April 13, 2020, 04:18:31 AM
Would it be possible to either show the Research Project of a retiring Scientist or include a event about canceled Research Projects?
Title: Re: C# Suggestions
Post by: lupin-de-mid on April 13, 2020, 04:22:59 AM
Right now if I type text in dropdown list it scrollled to first element
May be it's possible to filtering all items
Title: Re: C# Suggestions
Post by: Resand on April 13, 2020, 04:54:26 AM
Not entirely sure if this is a bug or missing feature or what.
But there doesn't seem to be a way to see which class designed might be build in same shipyard as each other
Title: Re: C# Suggestions
Post by: so_noid on April 13, 2020, 04:59:16 AM
If downloads are through user mirrors can the author give a crc/sha/md5sum of the releases?
Title: Re: C# Suggestions
Post by: db48x on April 13, 2020, 06:10:24 AM
Now that there are 9 categories of research, it'd be nice if the category dropdown on the research page had room for 9 rows :)

Thanks!
Title: Re: C# Suggestions
Post by: smoelf on April 13, 2020, 06:44:12 AM
When selecting a new commander for either a ship, ground force unit, or planet, it would be amazing to be able to see, which commander is already in place, in order to determine whether the selected commander would be a better choice.

It might be a tight fit so get another window in there, but perhaps one of the existing windows could be repurposed for this? Possibly the medal window, where you can choose to have it display either medals or a shortened version of the commander of the selected ship/unit/planet.
Title: Re: C# Suggestions
Post by: dr125 on April 13, 2020, 06:55:56 AM
Quote from: Tunsku link=topic=10640. msg121333#msg121333 date=1586720467
Quote from: dr125 link=topic=10640.  msg121322#msg121322 date=1586719373
As one of those with a 1366x768 screen, is there any chance of a "can move the screen around" option? Obviously not now as I am sure bug-squashing takes priority.    I can open everything up and so on, but the buttons at the bottom don't even show up.    Another monitor isn't really an option at the moment.   
>move taskbar to the side
>move the windows up with the mouse to peek at the buttons
>window scaling in settings? I have heard that might work.

I have done the first two, but the problem is that the bottom of the screen literally doesn't generate.  I can move tho application around, but buttons/bottom of the screen won't be there on tall screens.  The scaling doesn't work as 100% is the lowest it can go.  I would need to have something like 80% for the screen to small enough.  FWIW, the things you mentioned work great for VB6 Aurora with the "Reduced Window Height" option. 
Title: Re: C# Suggestions
Post by: smoelf on April 13, 2020, 07:46:20 AM
An option to expand/collapse everything in the windows that have nested hierarchies (commanders, colonies, fleets, class design etc.)
Title: Re: C# Suggestions
Post by: Doren on April 13, 2020, 08:32:31 AM
Would be nice to see unused % capacity in construction screen
Title: Re: C# Suggestions
Post by: Veneke on April 13, 2020, 08:44:31 AM
Can an option be added to copy the design of a ground formation?
 
I find that I use the same protection detail for my geo/xeno/construction ground forces. Being able to copy one and then just swap out the different vehicles would be quicker.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on April 13, 2020, 08:51:08 AM
I would like to have the range tool from the tactical map back if possible... I often used that in VB6 Aurora.

If pressing shift and the left mouse button we should be able to use the range tool instead of moving the map around, or something like that.
Title: Re: C# Suggestions
Post by: Migi on April 13, 2020, 09:04:34 AM
When re-training scientists to a new field their research bonus is reduced by 75%.  However this lets you generate scientists with bonuses which aren't a multiple of 5, could it be changed so that it rounds (or rounds down) to the nearest 5? Given scientists gain bonuses in steps of 5 it would stop them from being permanently 'the odd one out'.
Title: Re: C# Suggestions
Post by: TMaekler on April 13, 2020, 09:06:19 AM
When you start conventional wouldn't it make sense that you could build conventional industry until you have researched TN Tech? Would make sense in terms of role play at least to boost your production capacities... .
Title: Re: C# Suggestions
Post by: chrislocke2000 on April 13, 2020, 09:06:33 AM
A few suggestions based on just some short game play:

- When starting on a conventional game I noted that all of my officers and admin started at 20 years old. Seems like there are some serious over achievers in my navy! I've also seen officers retiring at the age of 31 or 32 which also seems pretty slack. Perhaps add five years to the age of a person for each rank they have?

- The ship design screen does not remember the selection of wide screen, same with full height on the events tab. Would be good if it did.

- The creation of the first CMC causes the game to research and generate a garrison force template with units. This gives that unit low gravity capability and is available in the list of templates to build. Would suggest this does not generate an available template and if possible the log that shows the research done is just left in the background.

- The width of the events log seems a lot to me and could do with the event detail section squeezed by 3 or 4 centimetres so more space for the tactical map (Hopefully once the issue with the resized otactical map not centring is resolved.).

- A last thought which I will probably be shot for is that the game is now so fast a five day tick scrolls the the events log faster than can be ready so hard to see when to manually interrupt auto turns. Possibly having an option to set a minimum tick process time to begin with would help with that.
Title: Re: C# Suggestions
Post by: chrislocke2000 on April 13, 2020, 09:34:59 AM
Two more suggestions

On the minerals tab on the tactical display a button to expand all entries would be helpful to quickly scroll through the list and avoid a lot of clicking.

Also on the tactical display the minerals as text tab does not have a scroll functionality so hard to look through although can be made to scroll by highlighting the text and dragging outside of of the box.
Title: Re: C# Suggestions
Post by: serger on April 13, 2020, 10:10:48 AM
Is it possible to implement dependance between generated officers age and rank?
Now, Aurora generates 20y.o. officers only. It's ok, when they are naval lieughtenants. It's quite strange, when they are lieughtenant commanders and majors (default rank scheme). It's a major disbilieve disaster when they are (pregenerated) higher commanders, research leaders and high-level administrators.

I'l be happy to see the commission ages increase to 23+-1y.o., and a distribution of pregenerated ranks between this age and mean retire age (smth about 75 y.o.) correspondingly to the ranks quantity in this branch.
Title: Re: C# Suggestions
Post by: 01010100 on April 13, 2020, 10:10:58 AM
It would be great if we could give standing and conditional orders to admin commands, this would allow for easy automation. This change can be implemented by adding the appropriate columns for such orders to the admin commands. Assuming the current code looks something like this:

Code: [Select]
void CheckConditionalOrders(Fleet fleet)
{
    CheckFirstConditionalOrder(fleet);
    CheckSecondConditionalOrder(fleet);
}

then changing the code to something like this would work:

Code: [Select]
void CheckConditionalOrders(Fleet fleet)
{
    CheckFirstConditionalOrder(fleet);
    CheckSecondConditionalOrder(fleet);

    var current = fleet;
    while (current.HasParent())
    {
        current = current.Parent;
        CheckFirstConditionalOrder(current);
        CheckSecondConditionalOrder(current);
    }
}


The while loop would keep going up the command hierarchy and check conditional orders attached to the admin commands. This would allow us to effectively add more than 2 conditional orders to a fleet. It would also simplify setting up conditional orders for, say, survey fleets since the orders can be entered at the admin command level and all that needs to be done to have a fleet operate as a survey fleet is just to attach it to that command.
Title: Re: C# Suggestions
Post by: vorpal+5 on April 13, 2020, 10:20:00 AM
You might want to limit the zoom out level to something sensible, like the known size of the universe, factoring expansion (so 45 billions LY right?) Because I managed to reach distance no one can fathoms, with a lot of zero. Aurora did not crash though  ;D
Title: Re: C# Suggestions
Post by: DFNewb on April 13, 2020, 10:21:46 AM
It would be great if we could give standing and conditional orders to admin commands, this would allow for easy automation. This change can be implemented by adding the appropriate columns for such orders to the admin commands. Assuming the current code looks something like this:

Code: [Select]
void CheckConditionalOrders(Fleet fleet)
{
    CheckFirstConditionalOrder(fleet);
    CheckSecondConditionalOrder(fleet);
}

then changing the code to something like this would work:

Code: [Select]
void CheckConditionalOrders(Fleet fleet)
{
    CheckFirstConditionalOrder(fleet);
    CheckSecondConditionalOrder(fleet);

    var current = fleet;
    while (current.HasParent())
    {
        current = current.Parent;
        CheckFirstConditionalOrder(current);
        CheckSecondConditionalOrder(current);
    }
}


The while loop would keep going up the command hierarchy and check conditional orders attached to the admin commands. This would allow us to effectively add more than 2 conditional orders to a fleet. It would also simplify setting up conditional orders for, say, survey fleets since the orders can be entered at the admin command level and all that needs to be done to have a fleet operate as a survey fleet is just to attach it to that command.

As it is right now with split into single ships command not passing on the orders to the new fleets like it did in VB, this would be a nice change cause right now it requires more effort than in VB.
Title: Re: C# Suggestions
Post by: Father Tim on April 13, 2020, 10:46:21 AM
- When starting on a conventional game I noted that all of my officers and admin started at 20 years old. Seems like there are some serious over achievers in my navy! I've also seen officers retiring at the age of 31 or 32 which also seems pretty slack. Perhaps add five years to the age of a person for each rank they have?

Is it possible to implement dependance between generated officers age and rank?
Now, Aurora generates 20y.o. officers only. It's ok, when they are naval lieughtenants. It's quite strange, when they are lieughtenant commanders and majors (default rank scheme). It's a major disbilieve disaster when they are (pregenerated) higher commanders, research leaders and high-level administrators.

I'l be happy to see the commission ages increase to 23+-1y.o., and a distribution of pregenerated ranks between this age and mean retire age (smth about 75 y.o.) correspondingly to the ranks quantity in this branch.

No, it's a terrible idea.  Then we'd be right back where we were before, where 90% of the officer corps would retire before the first ship was launched.

(And retirement already includes rank effects, see http://aurora2.pentarch.org/index.php?topic=8495.msg104038;topicseen#msg104038 (http://aurora2.pentarch.org/index.php?topic=8495.msg104038;topicseen#msg104038))

- - - - - -

Also, I don't particularly like that officers are locked into human lifespan/working ages.   It's much more important to me that Aurora adds Racial Lifespan / Maturity / Health settings than fixes the one small case that all officers are generated at 20 years of age.

= = = = =

Besides, Admiral Sun Rising was a ship's Captain at five years of age, and an Admiral by fourteen.  So Aurora is perfectly "realistic" after all.
Title: Re: C# Suggestions
Post by: Droll on April 13, 2020, 10:55:55 AM
Quote from: Veneke link=topic=10640. msg121664#msg121664 date=1586785471
Can an option be added to copy the design of a ground formation?
 
I find that I use the same protection detail for my geo/xeno/construction ground forces.  Being able to copy one and then just swap out the different vehicles would be quicker.

The game has no lower limit on how small/granular your formations can get.  You can do what I did and create an infantry company with like 200 men for example, train your xeno archeology and company, then assign the company under the archeologists in the hierarchy.  This does warrant some level of micro and needs 2 facilities though due to how assignment and training works.

Along a similar vein it would be very nice if there was a way to make it so that larger templates could have smaller formations as part of its template.  So when im designing a battalion I can say that I want 4 companies to be trained alongside it as well as any units on the battalion level.  This either takes up all the training facilities or if there are less than 5 available it adds units to the queue.  (a ground unit queue would actually be very nice)
Title: Re: C# Suggestions
Post by: WSoxfan86 on April 13, 2020, 11:04:27 AM
I don't think there needs to be a set age range for each rank, but it also is weird to only have 20-year old officers at the start of the game.  Maybe the first retirement check shouldn't happen until a certain amount (say 70%) of officers have a command? That would stop 90% of officers leaving before you're ready, while allowing for a better age distribution at the start.
Title: Re: C# Suggestions
Post by: Droll on April 13, 2020, 12:13:39 PM
I just noticed that the stats on ground units do not update with the latest racial weapon and armor levels.

There needs to be some kind of system in place that allows us to "retrofit" ground templates en masse.  Otherwise i need to delete my entire army to upgrade them to a new tech level and consequently redo the entire hierarchy tree.

This could be some thing like infantry base types being able to retrofit into non-obsolete infantry sharing the same weapon type or larger vehicles being able to retrofit into non-obsolete vehicles sharing the same primary component.

Or it could just be that its automatic and free and ground units are always as strong as the racial armor and weapon values and are updated when tech increases.

The only issue would be with STOs since they use space weapons but you could then just have it so they can retrofit to a non-obsolete weapon of the players choice. 

No idea how retrofitting costs would be calculated in a fair way.
Title: Re: C# Suggestions
Post by: Father Tim on April 13, 2020, 12:33:44 PM
I just noticed that the stats on ground units do not update with the latest racial weapon and armor levels.

There needs to be some kind of system in place that allows us to "retrofit" ground templates en masse. . .

Refit to upgrade, yes.  Free & automatic upgrade, no.  Rifles don't just turn into better rifles.
Title: Re: C# Suggestions
Post by: Droll on April 13, 2020, 12:44:08 PM
I just noticed that the stats on ground units do not update with the latest racial weapon and armor levels.

There needs to be some kind of system in place that allows us to "retrofit" ground templates en masse. . .

Refit to upgrade, yes.  Free & automatic upgrade, no.  Rifles don't just turn into better rifles.

Ideally what you say is right, im just providing options in case there is some technical complication.
Title: Re: C# Suggestions
Post by: serger on April 13, 2020, 01:05:37 PM
No, it's a terrible idea.  Then we'd be right back where we were before, where 90% of the officer corps would retire before the first ship was launched.
And what's wrong with it? Starting with aerospace forces, they nearly should retire before the first ship was launched, younger ones will get their places, that's ok.
Title: Re: C# Suggestions
Post by: SirCookie on April 13, 2020, 01:52:53 PM
It would be nice if the events would show up on the map, its little bit hard to keep track about what happens on a notebook without it.  And it should not be to hard to implement this. 
Title: Re: C# Suggestions
Post by: Vivalas on April 13, 2020, 02:06:05 PM
In VB6 pretty sure the retirement was because of inactivity, not age. The 20yo officers really are quite silly.
Title: Re: C# Suggestions
Post by: GhostIsGone on April 13, 2020, 02:10:04 PM
Quote from: SirCookie link=topic=10640. msg121883#msg121883 date=1586803973
It would be nice if the events would show up on the map, its little bit hard to keep track about what happens on a notebook without it.   And it should not be to hard to implement this. 

If it weren't hard to do then it would have been included in the patch already, just sit tight, it's a known issue which will be fixed when it gets fixed :-)
Title: Re: C# Suggestions
Post by: Erik L on April 13, 2020, 02:45:59 PM
It would be nice if when you add a company name to a tech item, when you design a new item of that type it auto-fills the previous company name.

I.E. Create an active search sensor with the company name of Acme. When you got to update it, Acme gets autopopulated in the company name.
Title: Re: C# Suggestions
Post by: Luftwolfe on April 13, 2020, 03:24:28 PM
I'm not sure if it has been suggested before but it would very much appreciated to have the ability to remove awards from officers, either for RP reasons or otherwise.  Sometimes I didn't mean for an officer to get an award, so it would be nice to have an "undo", so to speak.
Title: Re: C# Suggestions
Post by: Desdinova on April 13, 2020, 03:26:18 PM
I would like to see a fighter-sized refueling component. It would have to have a very slow flow rate, or maybe be restricted to fighter-sized craft, but it would allow someone to create very small refuelers for as part of a carrier air wing.
Title: Re: C# Suggestions
Post by: DFNewb on April 13, 2020, 03:34:11 PM
Could you please add a default event color button like in VB and just use the colors you have set for the campaign the download comes with? That would be super awesome.
Title: Re: C# Suggestions
Post by: bombastico on April 13, 2020, 04:01:32 PM
It would be possible to add a little "Memo" tab right among the various "Display" tabs?
It would be useful to write down notes and memos to be check after a game loading. . .  so there will be no danger of disrupting your game thoughts. . .  like "check survey status in system X" or "terraform Titan" or "remember JP stabilisation in system x". . . 
Title: Re: C# Suggestions
Post by: Coleslaw on April 13, 2020, 04:10:00 PM
An option to include Naval Admin Commands alongside the auto assignment checkbox, so that you don't have to go through your entire hierarchy and make sure it's properly populated with commanders. You could probably just have the admin command take someone whose skills match the type of admin command it is. I.e., a logistics command would automatically have a high logistics naval commander assigned.

Edit: Likewise with colony/sector admins, but in this case you select one or more preferred skill(s) for the position.
Title: Re: C# Suggestions
Post by: alex_brunius on April 13, 2020, 04:30:32 PM
I might be missing something, but would be cool to see Hierarchy option in Ground Forces Formation Templates.

Basically you can set up for example a "1x INF Corps -> 3x INF Divisions -> 3x INF Battalions" standard hierarchy and can then select a ticbox "include subunits in training" in GU Training which allows you to instead of training an empty Corps trains INF Corps + 3x INF Divisions + 9x INF Battalions and deliver them in the assigned hierarchy into your OOB when finished.
Title: Re: C# Suggestions
Post by: Droll on April 13, 2020, 05:22:59 PM
I might be missing something, but would be cool to see Hierarchy option in Ground Forces Formation Templates.

Basically you can set up for example a "1x INF Corps -> 3x INF Divisions -> 3x INF Battalions" standard hierarchy and can then select a ticbox "include subunits in training" in GU Training which allows you to instead of training an empty Corps trains INF Corps + 3x INF Divisions + 9x INF Battalions and deliver them in the assigned hierarchy into your OOB when finished.

Ive already suggested this in a previous versions suggestions but you've worded it much better than mine lol ;D
Title: Re: C# Suggestions
Post by: Disguy on April 13, 2020, 05:35:09 PM
Did not read the whole thread. 

Get we get "Design Warnings" for the new dependencies:

Sorium Harvesting without fuel transfer, etc
Title: Re: C# Suggestions
Post by: Garfunkel on April 13, 2020, 06:19:41 PM
Did not read the whole thread. 

Get we get "Design Warnings" for the new dependencies:

Sorium Harvesting without fuel transfer, etc
But I will always have a dedicated tanker harvesting fuel from my harvesting bases and delivering it to my colonies.
Title: Re: C# Suggestions
Post by: GhostIsGone on April 13, 2020, 06:21:10 PM
Right now it's not possible to add research projects to the queue with a different scientist from the ongoing project. It would be nice if I could queue projects from different scientists, otherwise, I can't use the queue when I want to research a PP project and a sensors project next.
Title: Re: C# Suggestions
Post by: DFNewb on April 13, 2020, 06:21:18 PM
Did not read the whole thread. 

Get we get "Design Warnings" for the new dependencies:

Sorium Harvesting without fuel transfer, etc

If anything it should be checking the tanker box and not having the new fuel transfer comp.
Title: Re: C# Suggestions
Post by: Father Tim on April 13, 2020, 06:37:54 PM
Did not read the whole thread. 

Get we get "Design Warnings" for the new dependencies:

Sorium Harvesting without fuel transfer, etc

If anything it should be checking the tanker box and not having the new fuel transfer comp.

I believe that is what Disguy was suggesting -- Tankers without fuel transfer, freighters without cargo shuttles, colliers without ordnance transfer, etc.
Title: Re: C# Suggestions
Post by: Erik L on April 13, 2020, 07:06:07 PM
Some sort of delimiter in the ship type droplist between the abbreviation and the type for clarity purposes.
Title: Re: C# Suggestions
Post by: Peregrine on April 13, 2020, 07:38:23 PM
An ability to mass assign civilian economy orders to several colonies at once.     

For example, I just finished surveying a new system's asteroid belt and I want my civilian transports to ship a mass driver and 10 automated mines to each asteroid colony.  As of the latest patch, I must select each colony one by one, add each installation type individually, and input the desired amount of installations for every single asteroid/comet.  For sizeable systems the amount of colonies can get into hundreds.   

Also, perhaps, make the dropdowns in the civilian economy menu remember the last installation selection when a different colony is selected?

Edit: A button to flag all installations currently at the colony as available for pick up by the civilians would also be nice.  For examplem when the asteroid from the example above has been strip mined, I will just have to click that button for those installations to be picked up and utilized elsewhere.   
Title: Re: C# Suggestions
Post by: TacticalStats on April 13, 2020, 09:56:13 PM
Just an idea.  I spend an hour setting up my medals, names and promotion points.  An update is great.  Don't mind starting over.  Just would be nice to be able to save that group of medals into the next game file.  Not sure how easy that is.
Title: Re: C# Suggestions
Post by: lbpink on April 13, 2020, 10:29:03 PM
I've noticed in some of the pages, notably in ship construction and research, where the completion date field is too small to display the full date string.  Can there be an option to expand the field or shorten the info in that's displayed?

Also I'm pretty bad a window management apparently.  Would we be able to have the buttons on the system map open the last window created instead of opening a new one? I've caught myself with a dozen events windows open several time now.

Thanks
Title: Re: C# Suggestions
Post by: AJS1956 on April 14, 2020, 03:22:10 AM
Hi Steve,

Thanks for the game - It will make lockdown bearable !!

One suggestion is that on the system display you can zoom out a VERY long way (to a scale of billions of light years or more) and still see just the system you are at.  Can you put a hard limit on the zoom out? It just seems a bit unrealistic to have a scale where I should see most of the galaxy but can only see one system!

Andy
Title: Re: C# Suggestions
Post by: GL on April 14, 2020, 03:50:15 AM
In VB, I liked the "Exceptional New Officer" events; I could flag them by giving them a small medal.

Could it be brought back? Perhaps with a medal condition such as "Graduated with promotion score > x" ?

Thanks
Title: Re: C# Suggestions
Post by: Garfunkel on April 14, 2020, 04:08:38 AM
Import Ground Unit Template:

a button that allows us to upload a .txt file (or something similar) that has a specific layout that the DB understands which includes ground unit types, elements, and formations. Preferably they do not need to researched yet but if that isn't possible, it would still be useful, especially for multi-faction Earth starts.
Title: Re: C# Suggestions
Post by: YABG on April 14, 2020, 04:50:50 AM
Thanks for the release and bug squashing updates - the new features and performance improvements are great!

I'd like to suggest, for upgrading and reinforcing units, a "refit to template" option in the GU Training tab.  It would go to the right of the current "create task" button.  Pressing it either brings up a window that lists all the ground units on the population or changes the window that lists possible templates for construction with a similar list.  There is a drop down menu at the top or bottom that contains all race ground unit templates.  You pick the unit you want to change, select the template you want from the drop down menu, and select "refit" or "create task" depending on where we made a new window or replaced an existing one. 

To keep things simple, when you refit a unit you get the wealth and minerals back as if it was scrapped (assuming scrapping a unit refunds anything, I haven't checked that) and costs the full amount of the new template.  Training time is modified by how similar the templates are, eg: if I take 100 riflemen and change them into 5 tanks, that would take exactly the same amount of time a building 5 tanks (the riflemen don't know how to use the tanks and all the tanks need to be built from scratch).

To prevent funky things happening with transports and hierarchies, units that are being refitted get a red or purple (whatever is easy to see and warning like) text colour on the ground forces screen and the naval movement orders screen.  Attempts to change the unit on the ground forces screen are blocked and throws the warning "You may not edit units under refit" for the user.  Units being refitted throw a similar error in the event log whenever a ship attempts to load the unit. 

Similarly, to keep things simple and prevent funkiness, prevent the user from refitting units on a population with hostile ground forces present.  This throws a warning like "You may not edit units while hostile ground forces are present". 

Quote from: alex_brunius link=topic=10640. msg122037#msg122037 date=1586813432
I might be missing something, but would be cool to see Hierarchy option in Ground Forces Formation Templates.

Basically you can set up for example a "1x INF Corps -> 3x INF Divisions -> 3x INF Battalions" standard hierarchy and can then select a ticbox "include subunits in training" in GU Training which allows you to instead of training an empty Corps trains INF Corps + 3x INF Divisions + 9x INF Battalions and deliver them in the assigned hierarchy into your OOB when finished.

I'd also like to second something like this also.  Perhaps to the right of "formation templates" in the tab in the ground forces view we could have a "hierarchy template" tab where we can assemble templates similar to how you do it in the "Order of Battle" tab.  Then in the GU Training menu a button next to "Create task" that reads "create hierarchy" that pops up a drop down menu or replaces the existing formation selection menu with hierarchy templates for you to select. 

It then queues up all the relevant formations, with the top level formations first, (we'd also need the ability to queue ground unit construction  :P ) for training and assembles the hierarchy as units complete.  To use your example, selecting you INF Corps hierarchy template would train, in the following order, Corp > Division > Division > Division > Battalion > Battalion > Battalion > ect.

For extra functionality, you could maybe even choose how many GU Training facilities you want to dedicate to training a given hierarchy.
Title: Re: C# Suggestions
Post by: Vivalas on April 14, 2020, 05:07:18 AM
Dunno if I'm just doing it wrong or don't know how sub-fleets and fighters work, but here are some suggestions I have after messing around with fighters on my game:

1. Have an option to land on the mothership and join the fleet as a sub-fleet, so the fighter wing doesn't clutter the entire OOB (and have the fighter sub-fleet spawn underneath the sub-fleet the mothership is on, if any
2.  Have a display somewhere of which ship a selected fighter is landed on and on the mothership, which ships are currently landed on it.

I'm not really sure how fighters work in this version, since there's no launch parasites button that I can find. I can land on a mothership, set the fighters as their own sub-fleet while landed, and then detach the sub-fleet and the fighters "launch", however, it's hard for me to tell if fighters are flying along side a mothership or actually landed, per se.
Title: Re: C# Suggestions
Post by: Vivalas on April 14, 2020, 05:09:02 AM
And another separate suggestion, about auto-names for ground units. I think they should be numbered by formation template (or have an option to do so) and not every single ground unit in the race.

(So instead of you building 1st Armor, 2nd Infantry, 3rd Armor, 4th Armor, 5th Artillery it would be 1st Armor, 1st Infantry, 2nd Armor, 3rd Armor, 1st Artillery and so forth.
Title: Re: C# Suggestions
Post by: YABG on April 14, 2020, 05:18:48 AM
Oh tiny little thing, maybe I'm dumb and can't find it but somewhere (perhaps the new game screen?) can we have the version number?

I can't remember if I've updated or not! :)
Title: Re: C# Suggestions
Post by: peli08 on April 14, 2020, 05:22:28 AM
Congrats on the release! The resolution is a problem for me.  My laptop is only at 1366x768 it can handle somewhat the width but the length is bad.  So, a suggestion from me is if possible to make the windows of the game scrollable.  It would be nice.  Thanks.
Title: Re: C# Suggestions
Post by: Father Tim on April 14, 2020, 05:35:27 AM
Some sort of delimiter in the ship type droplist between the abbreviation and the type for clarity purposes.

Preferably two separate-but-linked lists, so that I can sort (alphabetically) either by abbreviation or long form of hull type.
Title: Re: C# Suggestions
Post by: Father Tim on April 14, 2020, 05:40:18 AM
And another separate suggestion, about auto-names for ground units. I think they should be numbered by formation template (or have an option to do so) and not every single ground unit in the race.

(So instead of you building 1st Armor, 2nd Infantry, 3rd Armor, 4th Armor, 5th Artillery it would be 1st Armor, 1st Infantry, 2nd Armor, 3rd Armor, 1st Artillery and so forth.

I would. . . NOT. . . like this.  But I would love a way to select a number of ground units and auto-renumber them starting from some ordinal I select.
Title: Re: C# Suggestions
Post by: Father Tim on April 14, 2020, 05:42:17 AM
Oh tiny little thing, maybe I'm dumb and can't find it but somewhere (perhaps the new game screen?) can we have the version number?

I can't remember if I've updated or not! :)

It used to be on the main menu bar, but since C# Aurora has ditched the main menu bar, I don't know where to find it now.
Title: Re: C# Suggestions
Post by: Doren on April 14, 2020, 06:44:46 AM
Unsurveyd Display option: Instead of showing the ring on surveyd bodies it would show the ring on unsurveyd bodies
Title: Re: C# Suggestions
Post by: nhb1986 on April 14, 2020, 07:57:14 AM
Quote from: Resand link=topic=10640. msg121579#msg121579 date=1586771666
Not entirely sure if this is a bug or missing feature or what. 
But there doesn't seem to be a way to see which class designed might be build in same shipyard as each other

Yes Please.

I would also add: can we have a list of eligible and not eligible shipyards (with reason why not) e. g.  Mil/Civ can be removed from list automatically I think based on type.  But could be interesting to see if a certain Pop is lacking resources for this ship type or simple Shipyard size is missing or just retooling
Title: Re: C# Suggestions
Post by: firsal on April 14, 2020, 08:18:00 AM
There should be some way to avoid opening up multiple instances of a single windows (ex. multiple ground forces windows), and when one clicks the button on the system view top bar, it should bring forward the corresponding window (like in VB6)
Title: Re: C# Suggestions
Post by: Kristover on April 14, 2020, 08:19:30 AM
There should be some way to avoid opening up multiple instances of a single windows (ex. multiple ground forces windows), and when one clicks the button on the system view top bar, it should bring forward the corresponding window (like in VB6)

Yeah, that has been an annoyance when after an hour of clicking I hover over the task bar and see twenty instances of the same window open.
Title: Re: C# Suggestions
Post by: nhb1986 on April 14, 2020, 08:19:57 AM
Regarding Medals.

So far it seems the Auto Assignment is working great and the variety of Triggers is great.  But it seems that multiple conditions are always OR, so just one of the Triggers will trigger the medal

Can we get an AND logic connection for multiple triggers?

E. g. 

10. 000 research points to achieve "Nobel Prize Nominee"
10. 000 research points + 20 years of Service both required to achieve Medal "Nobel Prize Winner"
Title: Re: C# Suggestions
Post by: nhb1986 on April 14, 2020, 08:21:52 AM
Quote from: Kristover link=topic=10640. msg122439#msg122439 date=1586870370
Quote from: firsal link=topic=10640. msg122437#msg122437 date=1586870280
There should be some way to avoid opening up multiple instances of a single windows (ex.  multiple ground forces windows), and when one clicks the button on the system view top bar, it should bring forward the corresponding window (like in VB6)

Yeah, that has been an annoyance when after an hour of clicking I hover over the task bar and see twenty instances of the same window open.

Or maybe a "close all" Button (except for the Main Game Window of course) OpenTTD does this nicely with the "Delete" Hotkey
Title: Re: C# Suggestions
Post by: sloanjh on April 14, 2020, 08:23:18 AM
No, it's a terrible idea.  Then we'd be right back where we were before, where 90% of the officer corps would retire before the first ship was launched.
And what's wrong with it? Starting with aerospace forces, they nearly should retire before the first ship was launched, younger ones will get their places, that's ok.
Steve could run a simple side game with only the player empire and no NPR for a few hundred years to get the steady-state officer age distribution.  He might need to turn off "up or out", but that should give a good distribution for at-start.

John
Title: Re: C# Suggestions
Post by: Jorgen_CAB on April 14, 2020, 08:26:18 AM
I found out that the Escort functionality of VB6 is not present in C#... I would really like to have some of that functionality in C# as well.

Being able to move entire formations using escort orders and have your escort ships move along specific set distances and direction from a main force is very useful. It is practically mandatory to manage large complex fleet formations and with the changes to sensors it is even more important in C# I think.

So when there is time I hope you add the Escort functionality back into the game, perhaps even expanding on it a bit too.
Title: Re: C# Suggestions
Post by: smoelf on April 14, 2020, 08:46:08 AM
Quote from: Kristover link=topic=10640. msg122439#msg122439 date=1586870370
Quote from: firsal link=topic=10640. msg122437#msg122437 date=1586870280
There should be some way to avoid opening up multiple instances of a single windows (ex.  multiple ground forces windows), and when one clicks the button on the system view top bar, it should bring forward the corresponding window (like in VB6)

Yeah, that has been an annoyance when after an hour of clicking I hover over the task bar and see twenty instances of the same window open.

Or maybe a "close all" Button (except for the Main Game Window of course) OpenTTD does this nicely with the "Delete" Hotkey

I would prefer a 'Close All' button. I remember seeing somewhere that having multiple instances of the same window was specifically implented as an improvement, so it's unlikely to be removed again. There are situations where it can be immensely useful, like trying to design multiple ships at the same time (like making a fighter and a carrier or a squad with command ship, escort, and main armament) or some technologies that are interdependent (designing active sensor and fire control in two different windows). This is definitely an improvement over VB6 where you had to deside on parameters before creating the technology.
Title: Re: C# Suggestions
Post by: Garfunkel on April 14, 2020, 08:48:59 AM
Maybe it could be made that Left-Click activates already existing window and Right-Click opens a new instance of that window. Then we could have both!
Title: Re: C# Suggestions
Post by: firsal on April 14, 2020, 09:00:53 AM
Also a tiny nitpick, it would be cool if the sort buttons on the ground forces screen also work on the hierarchy panel on the left, when the option to display elements is enabled

EDIT: Might as well add this on here, to avoid spamming up this thread

It would also be nice to have the Production Overview screen from VB6, which showed ongoing production/shipbuilding/research tasks, the time to complete them, where they were happening, etc... it was a neat little window where one could keep track of an entire empire's industry and research.
Title: Re: C# Suggestions
Post by: Shadow on April 14, 2020, 09:00:59 AM
It'd be ideal if the interface icons could be externalized, so we could customize them like we do race, ship, station and flag images.

I have plans. ;)
Title: Re: C# Suggestions
Post by: Doren on April 14, 2020, 11:35:18 AM
It would be nice if "In Overhaul" was painted red for readability and to be easier to spot on fleet screen.
Title: Re: C# Suggestions
Post by: Vivalas on April 14, 2020, 12:25:12 PM
Would be neat if hangars had a tech associated with them called "Launch operations". To avoid making hangars a designed component it could just be a racial tech, but would just change the number of fighters you can launch in a minute. Say, starting at 100t/min at lower techs and rising to maybe 1000t / min at the highest techs.

would add a little more in terms of immersion along with the new refueling and ordnance transfer rules so you don't have all of your fighters just pop out at once
Title: Re: C# Suggestions
Post by: Kelewan on April 14, 2020, 12:56:27 PM
Regarding Known Issues with  the date format and the decimal separator, can you override the value in aurora.

https://docs.microsoft.com/en-us/dotnet/api/system.globalization.cultureinfo.currentculture?view=netframework-4.8

Title: Re: C# Suggestions
Post by: Wieseltrupp on April 14, 2020, 12:57:53 PM
It would be nice if the design of a new component with the [CREATE] Button would also create a Research Prototype
Title: Re: C# Suggestions
Post by: Scorchicus on April 14, 2020, 01:09:30 PM
Currently, only lasers have enough tech levels to let your racial weapons level keep up with racial armour level at maxtech, meaning that to fully upgrade your ground weapons, you have to fully research lasers.

Specifically, lasers have 12 levels, particle beams have 11 and both railguns and plasma carronades have 10.

I'm suggesting that the tech branches without 12 tech levels either have some techs introduced to make 12, their racial weapon level bumped slightly so they reach the same racial weapons level at maxtech, or have racial weapon level based off of the capacitor recharge rate tech, since that's required for all of the primary energy weapons anyway.
Title: Re: C# Suggestions
Post by: Jaz010 on April 14, 2020, 01:56:09 PM
Hi 
I may be missing something,  is there a way to see the available percentage of unused construction factories.  Am always opening a calculator and adding the percentages to determine  how much I have available. 
Also a neet feature would be not only to fix the percentage , but the number of items you want built per year .   (For example 12 mines per year) and the percentage changes accordingly. 
Title: Re: C# Suggestions
Post by: Vivalas on April 14, 2020, 01:56:34 PM
Would be great if standing orders were checked every 5 days instead of at the end of the increment. This way your ships can survey more than 5 planets every 30 days or so because of the standing order only queuing up 5 new locations at the end of every turn
Title: Re: C# Suggestions
Post by: Inglonias on April 14, 2020, 01:56:55 PM
Can we get rid of the 30 day turn option, or is that a bridge too far? Now that the game runs so fast, it seems a little excessive.

While we're at it, can we remove the fixed shipyard expansion tasks (add 500, 1000, 2000, 5000, 10000 tons)? The new features on the continual capacity expansions make those orders superfluous.
Title: Re: C# Suggestions
Post by: GL on April 14, 2020, 02:05:52 PM
Hello

Ideas for new Conditional Orders:
Title: Re: C# Suggestions
Post by: JacenHan on April 14, 2020, 02:28:55 PM
Can we get rid of the 30 day turn option, or is that a bridge too far? Now that the game runs so fast, it seems a little excessive.

While we're at it, can we remove the fixed shipyard expansion tasks (add 500, 1000, 2000, 5000, 10000 tons)? The new features on the continual capacity expansions make those orders superfluous.
I think the 30-day turn is still useful for conventional starts, but I do agree with getting rid of expansion tasks and renaming "Continual Capacity Expansion" to just "Expand Capacity".
Title: Make Overhauling Ships refill the supplies
Post by: josh wood on April 14, 2020, 03:12:30 PM
Since conditionals can't give multiple orders for example

If Supply points Drop Below 20% Resuply then overhaul

It would be nice if overhaul would resuply the ship with Maint Supplies, since it kinda makes sense? Would mean i would never have to worry about my Grav/Geo ships anymore


Maybe adding some way to apply any number of conditionals and orders after the conditionals are met?
Title: Re: C# Suggestions
Post by: DFNewb on April 14, 2020, 04:13:09 PM
A way to obsolete tech from the class design page.
Title: Re: C# Suggestions
Post by: smoelf on April 14, 2020, 04:14:08 PM
A way to obsolete tech from the class design page.

You can do that. Second button on the bottom row. It says "Obso Comp".
Title: Re: C# Suggestions
Post by: Resand on April 14, 2020, 04:26:52 PM
Could we please get a Deployment time % conditional. Like @90% or 100% or something.
That way survey ships wouldn't run them self ragged if auto turn go by a bit fast  :)
Title: Re: C# Suggestions
Post by: Malorn on April 14, 2020, 04:29:14 PM
It might be quite a bit more useful to have civilians excluded from a lot more screens.  Right now they clutter up almost every fleet selection box.
Title: Re: C# Suggestions
Post by: Droll on April 14, 2020, 04:50:52 PM
Since carrying capacity is a thing, it would be a nice QOL feature for the game to tell you the maximum potential protection requirement of a planet when it reaches its pop cap.
That way one can plan the size of defensive garrison fleets.
Title: Re: C# Suggestions
Post by: SerBeardian on April 14, 2020, 04:52:31 PM
I would like to suggest a filter field for fleet destinations.
Trying to find that one asteroid amongst the way-too-many rocks in Sol when the list seems to use some archaic ordering system is not a fun time, especially when the object you're trying to find may not even be an asteroid...
Title: Re: C# Suggestions
Post by: thashepherd on April 14, 2020, 05:07:35 PM
Is there a way to provide custom ship names and/or ship class names?

There're already mechanisms for adding custom flags, racial portraits, and naval leader names; adding the ability to provide custom ship names and ship class names would create the potential for "Race packs" to customize starts. 

With a tweak to folder layout, you could allow coherent 'Races' to be created:
Code: [Select]
Races
  Race
    flag.png
    ship.png
    station.png
    portrait.png
    Medals
      medal###.png
    Names
      commanders.txt
      ships.txt
Title: Re: C# Suggestions
Post by: Father Tim on April 14, 2020, 05:12:15 PM
Oh tiny little thing, maybe I'm dumb and can't find it but somewhere (perhaps the new game screen?) can we have the version number?

I can't remember if I've updated or not! :)


On another thread, Steve Walmsley said, "(check the Misc tab for version number)?"  So I guess that's where it is.
Title: Re: C# Suggestions
Post by: JacenHan on April 14, 2020, 05:14:03 PM
Is there a way to provide custom ship names and/or ship class names?
Does the "Miscellaneous" tab of the system map do what you want? You can add new ship/commander name themes to your database via text files, though there is no way to pass it on to other people than to have them do the same thing in their game.
Title: Re: C# Suggestions
Post by: thashepherd on April 14, 2020, 05:53:32 PM
That's exactly what I was looking for - for some reason I thought that screen only allowed you to change commander name themes. Thanks!
Title: Re: C# Suggestions
Post by: WSoxfan86 on April 14, 2020, 07:15:37 PM
Is there a way to show all vacancies in your empire like there was in the VB6 version? If there isn't that would be pretty nifty.
Title: Re: C# Suggestions
Post by: Luftwolfe on April 14, 2020, 08:24:39 PM
Would it be possible to select an upper rank bound/range to who can command what class of ship in the design window? I know based on what components you have on a ship (auxiliary command, main engineering, etc) the minimum required racial rank increases, but for an upper bound I could see it being more feasible.

I specifically ask for fighter type ships.  I know you had said that the lowest racial rank would be the only eligible command for ships under 1k tons, but I would enjoy it for RP purposes to have a series of ranks that could command fighters and FACs, the first 3 racial ranks or something like that.
Title: Re: C# Suggestions
Post by: Droll on April 14, 2020, 08:28:38 PM
Would it be possible to select an upper rank bound/range to who can command what class of ship in the design window? I know based on what components you have on a ship (auxiliary command, main engineering, etc) the minimum required racial rank increases, but for an upper bound I could see it being more feasible.

I specifically ask for fighter type ships.  I know you had said that the lowest racial rank would be the only eligible command for ships under 1k tons, but I would enjoy it for RP purposes to have a series of ranks that could command fighters and FACs, the first 3 racial ranks or something like that.

To add to this it would also be good to have a minimum rank that the player can specify for each class not too dissimilar from VB6. The minimum rank would be the lowest ranking officer onboard that ship. So if the ship has CIC instead of racial minimum +2 the CO would have a rank of class minimum +2. The class design UI should still show the CO though.
Title: Re: C# Suggestions
Post by: Droll on April 14, 2020, 08:37:19 PM
Also when picking up cargo there should be some way to ignore pickup fail interrupts. Right now establishing mineral shipping routes is easily possible but hard to control.

I'm telling the ship to load 1000 of each mineral type at the source and using "load/unload to reserve" in order to unload cargo at the destination. This works fine except when the destination is full (at mineral reserve level) and the ship returns with a full cargo bay, attempting to overload itself and throwing a pickup fail interrupt.

Using "load/unload to reserve" has a problem where the ship will load from top to bottom. So it will fill itself with only duranium for example. This means that if you have a colony with lots of minerals and a small colony which you just want to have a small level of resources you end up with problems.

An alternative solution which is probably better is to have an "unload to reserve and wait until empty" command. Where the ship will unload until it hits the reserve level and then unload every production increment as the planet falls under reverse levels - only moving to the next order once the cargo holds are empty.
Edit: "unload to reserve and wait until empty" might be best if it can also be made mineral specific so "unload to reserve and wait until no 'mineral x' left in cargo" for example
Title: Re: C# Suggestions
Post by: Lightning on April 14, 2020, 09:13:10 PM
Maybe it could be made that Left-Click activates already existing window and Right-Click opens a new instance of that window. Then we could have both!
Or perhaps a check box/button that allows multiple instances of a window. So far, the improvement of multiple instances has been a real nuisance. I agree there are times it would be nice to have multiple of the same open at once, as stated before. However, most of the time I would prefer it brings the existing to front if it is already open. At a minimum, the 'close all' windows button to clean up all the open windows except the main one would help a lot.
Title: Re: C# Suggestions
Post by: Barkhorn on April 14, 2020, 09:56:54 PM
Ideally we should be able to have civilian shipping handle shipping minerals.  The US Navy doesn't transport ore after all.
Title: Re: C# Suggestions
Post by: Luftwolfe on April 14, 2020, 10:03:49 PM
A suggestion a friend and I drummed up is the "drop pod capability", whereas troops trained with this capability would have the ability to automatically take 1 turn of breakthrough attack to break up HQ elements and such, similar to how paratroopers would operate in WW2.
Title: Re: C# Suggestions
Post by: thashepherd on April 14, 2020, 11:54:32 PM
Some sort of prototype system for ground units would be great. I've probably realized I forgot to set HQ size and 'avoid combat' after researching a unit and building formations using it 5 times now.

There should be a 'load hierarchy' movement order.

Selecting a name using 'Select Name' on the class design screen should automatically set the class to use the name list that the selected name came from.
Title: Re: C# Suggestions
Post by: Marski on April 15, 2020, 12:10:09 AM
I'd appreciate it if researched ground units would be categorized in their own folders according to their classification so as to decrease the crowding of the list and saving time when making new ground formation templates. For example; Folder for Infantry, Light Vehicles, Medium Vehicles, Heavy Vehicles and so no and so forth.

The ability to import/export "packs" of medals and awards with their points, descriptions and pictures.

The ability to import/export ground formation templates
Title: Re: C# Suggestions
Post by: Icekiller on April 15, 2020, 01:01:14 AM
It would be great if there was a section on the ground combat tab that showed what percentage of a formations TO&E is complete, based on the template you used to build it.  This would make it far easier to build reinforcements for that unit, since you could at a glance see what it needed. 

For example:
If I have a infantry unit of 100 men, and 10 of them die.  It would show me that I am at 90% TO&E for that unit. 
Title: Re: C# Suggestions
Post by: GL on April 15, 2020, 01:38:40 AM
Could we have an Admin Command for Intelligence?
For example: 25% to intelligence and diplomacy, twice the range.
Title: Re: C# Suggestions
Post by: Demiurge on April 15, 2020, 05:14:52 AM
Can we have the game re-use windows? Every time I click a button for industry or ship design or anything else on the main map it opens a new window, I suddenly had 16 planet overview windows open when I realized this.

It'd also be nice if clicking a tab on a window refreshes the open window.  In ship design, anytime I change or create a new hull type I have to close the window and open a new one before it updates the list and it's pretty confusing at times.
Title: Re: C# Suggestions
Post by: Chris Foster on April 15, 2020, 05:54:09 AM
So uh i just made 1 Battalion (kinda doing things proper) with 3 companies with 3 platoons with 3 sections and i think im going to rip my hair out

So  . . .

Perhaps add a thing called "standard organisation" or something similar

The idea is that i set up what i just did, or even select what ive done and set it as such so that a the GU screen i can produce everything ive just done, with the organisation already done. Essentially its a formation like the other formations, but instead of consisting of units, it consists of other formations (woah thats a lot of formations! :))

I am currently making the 2nd battalion for my regiment (going to consist of 3 battalions) so i think im going to need another tea . . .
Title: Re: C# Suggestions
Post by: Demiurge on April 15, 2020, 06:08:29 AM
The new prototype system is pretty good, but it would be great it if was expanded in functionality. 

For example what if prototypes were saved between games? So when I start a new game I can pull up my old prototypes, allow the list to be sorted by current tech levels so I can use the same sensors and weapons systems/missiles between games without having to design them from scratch every game. 

Save these prototypes in a file separate from the database so they can be kept between updates and even shared between players!

Edit: To expand on this.  Make each prototype be its own text file in a folder, so when you pull up the prototype window it just populates the list from your folder.  This way individual designs can be easily shared between players by simply copy/pasting a text file.
Title: Re: C# Suggestions
Post by: Father Tim on April 15, 2020, 06:25:05 AM
Can we have the game re-use windows? Every time I click a button for industry or ship design or anything else on the main map it opens a new window, I suddenly had 16 planet overview windows open when I realized this.

It'd also be nice if clicking a tab on a window refreshes the open window.  In ship design, anytime I change or create a new hull type I have to close the window and open a new one before it updates the list and it's pretty confusing at times.

Aurora was deliberately switched away from that to enable drag-and-drop between multiple instances of the same window.  To switch back would require nearly every window increasing in size to fit a multi-function drag-and-drop space.
Title: Re: C# Suggestions
Post by: Demiurge on April 15, 2020, 06:51:29 AM
Quote from: Father Tim link=topic=10640. msg123111#msg123111 date=1586949905
Aurora was deliberately switched away from that to enable drag-and-drop between multiple instances of the same window.   To switch back would require nearly every window increasing in size to fit a multi-function drag-and-drop space.

That makes sense, however on a personal level it's extremely confusing so a toggle would be appreciated at least :)

Another suggestion I have that's probably a bit comprehensive.

With populations now being capped to planet size and growth being tied to the cap, it's now possible to have many small colonies that don't overcrowd and cause massive unrest problems.  This means I now want to colonize a bunch of things and I think an overhaul to the mining system could really benefit here.

Nerf automines into the ground and make them only useful for deposits with easy availability.  Make lower availabilities only mineable by regular mines staffed by actual people, and let those empty deposits continue to produce a trickle of resources once they run out.  This will incentivize smaller, dedicated mining colonies and keep them relevant into the endgame as a source of essential materials.  It will also be nice if this is coupled with deposits being vastly more common everywhere but the average deposit being very poor. 

From a roleplay perspective I always want to colonize Luna and now that the population is capped very low this works perfectly for me for narrative purposes, Luna also having some tiny deposits that would produce at least a little bit of duranium for the duration of a whole game would be fantastic for story telling.  Conversely, rare resources showing up in larger deposits on very high colony cost planets/moons would mean I have an incentive to terraform it to get to those, rather than fire and forget 200 auto mines and a mass driver.
Title: Re: C# Suggestions
Post by: iceball3 on April 15, 2020, 07:08:38 AM
Some manner of "permanent capped-output deposit" would be nice, if just to soften the grip of non-newtonian entropy and to allow somewhat more permanent low-intensity mining operations. I can imagine some people would like to keep that entropy factor around though, so i'm wondering what others might feel about it.
Title: Re: C# Suggestions
Post by: Black on April 15, 2020, 07:19:56 AM
Some manner of "permanent capped-output deposit" would be nice, if just to soften the grip of non-newtonian entropy and to allow somewhat more permanent low-intensity mining operations. I can imagine some people would like to keep that entropy factor around though, so i'm wondering what others might feel about it.

I would also like "permanent capped-output deposits" as you call them. I always liked the idea of heavily colonized home system with lot of small mining outposts in asteroid belts and moons. I did it by SMing low availability deposits in VB6 version, but it would be nice to have it as official feature.
Title: Re: C# Suggestions
Post by: iceball3 on April 15, 2020, 07:31:51 AM
Some manner of "permanent capped-output deposit" would be nice, if just to soften the grip of non-newtonian entropy and to allow somewhat more permanent low-intensity mining operations. I can imagine some people would like to keep that entropy factor around though, so i'm wondering what others might feel about it.

I would also like "permanent capped-output deposits" as you call them. I always liked the idea of heavily colonized home system with lot of small mining outposts in asteroid belts and moons. I did it by SMing low availability deposits in VB6 version, but it would be nice to have it as official feature.
A big part of me thinks that such deposits would either have to be represented as mined from the inter-celestial medium as fine dust, (which would make sense for asteroid belt deposits, fluffwise, i suppose), or as sourced from geologically-slow mantle extrusions on volcanically active planets (as it makes sense that it'd be much harder to blow a planet open just to get at it's non-newtonian guts anyway, and the mantle guts could be seen as both incredibly hard to get at at more than a trickle, and very impure).
In either case however, I do think a special rule in addition to availability should cap out the maximum output of the infinite-part of these deposits, just so that these deposits stay modest no matter how many mines you try to throw at them.
Having a hard cap on the infinite flow, anyway, would be great as those deposits would still have a "clearing house" phase like aurora already does, where you instead significantly downsize regional operations instead of immediately moving every single mine off-planet. Which means more of a reason to maintain a populations there, it's not like their presence is completely invalidated by the trickle of minerals suddenly drying up.
Title: Re: C# Suggestions
Post by: Chris Foster on April 15, 2020, 08:11:09 AM
So uh i just made 1 Battalion (kinda doing things proper) with 3 companies with 3 platoons with 3 sections and i think im going to rip my hair out

So  . . .

Perhaps add a thing called "standard organisation" or something similar

The idea is that i set up what i just did, or even select what ive done and set it as such so that a the GU screen i can produce everything ive just done, with the organisation already done. Essentially its a formation like the other formations, but instead of consisting of units, it consists of other formations (woah thats a lot of formations! :))

I am currently making the 2nd battalion for my regiment (going to consist of 3 battalions) so i think im going to need another tea . . .

Yeah so that didn't happen lol, got to two before i said flip it, just going to do stuff at a platoon level minimum.

so yeah, copy and paste formation hierarchy pretty please :)
Title: Re: C# Suggestions
Post by: Father Tim on April 15, 2020, 08:23:28 AM
Once the formations are actually built, you can drag-and-drop them between other formations.  So you can build a Division HQ that is only a single 750,000 command rating HQ component, and then later assign pre-built Regiments to it.
Title: Re: C# Suggestions
Post by: Chris Foster on April 15, 2020, 08:41:25 AM
Once the formations are actually built, you can drag-and-drop them between other formations.  So you can build a Division HQ that is only a single 750,000 command rating HQ component, and then later assign pre-built Regiments to it.

Yeah but i mean reproducing the entire group of formations on the ground unit training screen, ie being able to produce actual groups of formations to save time

Though i mightve just been taking forever because i was naming everything like 1st battalion - A company - 1st rifle platoon - infantry section Alpha
Title: Re: C# Suggestions
Post by: Garfunkel on April 15, 2020, 08:43:27 AM
What we need is a queue for ground unit construction complexes so I can first design a division and then just queue the whole division to be built instead of having to build it, platoon, by platoon every 5-15 days.

Since we're now building custom formations in a similar manner to how the industry works (instead of shipyards), it would make sense IMHO to change the whole ground production side to be like construction factories, so you don't assign individual projects to each complex. Instead the complexes increase your BP per production cycle and you just queue everything you want.
Title: Re: C# Suggestions
Post by: Doren on April 15, 2020, 09:18:34 AM
Would be nice if Governor death would cause auto turns to stop and would be easily differentiated from other officer deaths. After all these are rather important events from game play and RP perspective
Title: Re: C# Suggestions
Post by: TeSparg on April 15, 2020, 09:24:17 AM
Quote from: Doren link=topic=10640. msg123186#msg123186 date=1586960314
Would be nice if Governor death would cause auto turns to stop and would be easily differentiated from other officer deaths.  After all these are rather important events from game play and RP perspective
+1 This would be nice.
Title: Re: C# Suggestions
Post by: Father Tim on April 15, 2020, 10:10:03 AM
What we need is a queue for ground unit construction complexes so I can first design a division and then just queue the whole division to be built instead of having to build it, platoon, by platoon every 5-15 days.

Since we're now building custom formations in a similar manner to how the industry works (instead of shipyards), it would make sense IMHO to change the whole ground production side to be like construction factories, so you don't assign individual projects to each complex. Instead the complexes increase your BP per production cycle and you just queue everything you want.

Yeah, Steve said it's on the list for QoL changes, so hopefully we'll have it in a couple of months.
Title: Re: C# Suggestions
Post by: Ektor on April 15, 2020, 10:10:54 AM
Admin commands should auto-assign.
Title: Re: C# Suggestions
Post by: Father Tim on April 15, 2020, 10:19:48 AM
Once the formations are actually built, you can drag-and-drop them between other formations.  So you can build a Division HQ that is only a single 750,000 command rating HQ component, and then later assign pre-built Regiments to it.

Yeah but i mean reproducing the entire group of formations on the ground unit training screen, ie being able to produce actual groups of formations to save time

Though i mightve just been taking forever because i was naming everything like 1st battalion - A company - 1st rifle platoon - infantry section Alpha


I hope you mean renaming after building, not that you have twelve different infantry company templates Able Company through Easy Company to Jig Company.

In your shoes, I would Instant 1200 rifle platoons, 100 MG platoons, 100 mortar platoons, etc. and the various levels of HQ and assemble companies, battalions, regiments, etc., by drag and drop.  Or build many, many GFTFs.
Title: Re: C# Suggestions
Post by: Father Tim on April 15, 2020, 10:22:09 AM
Admin commands should auto-assign.


No they shouldn't.  As the most important and far-reaching assignments you can make, their effects and interdependencies are so vast and subtle that they profoundly affect your empire and no AI could ever get them right.

Which is why they don't.
Title: Re: C# Suggestions - Medal setting IMPORT EXPORT -
Post by: Mark Yanning on April 15, 2020, 10:23:38 AM
I really like the medal managment and costumization.  But every time I start a new game, I have to make custom medals again.  Is there a way to save and import the medal settings from one game to another? That would be nice.  Thanks
Title: Re: C# Suggestions
Post by: Alsadius on April 15, 2020, 10:41:14 AM
For the research screen, I'd like to see a couple more sorting options. In particular, sorting by research field and sorting by scientist skill would both be nice sometimes. Also, I want the option to see future techs, like VB6 had.

Prototypes are really awesome, but I have occasionally felt limited by the lack of them for some things. Can we get the option to create (FP) items for the non-researched components, like flag bridges, cargo shuttles, fuel tanks, and so on? Also, prototype ground units would be kind of nice.

The default organization of ship components in the build menu is a bit chaotic, IMO. I'd love to see some options to re-organize them. Something like the new fleet interface would be nice, with drag-and-drop and user-defined categories, but I know that's probably overkill. Even just having checkboxes for showing military and commercial components might be nice, though, so I can ignore all the weapons etc. on my freighters, and ignore all the cargo bays etc. on my battleships.

Crew-Served Anti-Personnel on infantry provide 6x the firepower at 2. 4x the cost and 2. 4x the size compared to Personal weapons making them the overall more efficient option.  I think it would be a better trade off if they cost 6-8x as much instead making it a trade off between taking the more resource efficient personal weapons or the more space efficient Crew-Served Anti-Personnel.  Nerfing the AP of CSAP to 1 less than personal weapons could also be another option for balancing.

It's not as obvious as you might think. A 12-ton machine gunner has no more HP than a 5-ton infantryman, so they lose 2.4x as much cost and 2.4x as much combat power when they're attacked. Equal-sized forces of PW infantry and CAP infantry are almost equally matched. 100 machine-gunners can kill 600 riflemen=3000 tons (ignoring hit chances, tech differences, etc.), and 240 riflemen can kill 240 machine-gunners=2880 tons. The machine gunners also use more supply in the process.

When re-training scientists to a new field their research bonus is reduced by 75%.  However this lets you generate scientists with bonuses which aren't a multiple of 5, could it be changed so that it rounds (or rounds down) to the nearest 5? Given scientists gain bonuses in steps of 5 it would stop them from being permanently 'the odd one out'.

Alternately, I'd like to see them go to a multiple of 5% the next time they upgrade. Just change the chances accordingly. For example, if a 15% scientist goes to a different field, they'll become a 4% scientist. The next upgrade should bring them to 5%, but because it's 1/5 the size, it should be 5x more likely. (This may be too much work, but if it's practical, it satisfies both my OCD and my desire to prevent obvious loopholes with the rules)
Title: Re: C# Suggestions
Post by: Father Tim on April 15, 2020, 10:45:34 AM
Alternately, I'd like to see them go to a multiple of 5% the next time they upgrade. Just change the chances accordingly. For example, if a 15% scientist goes to a different field, they'll become a 4% scientist. The next upgrade should bring them to 5%, but because it's 1/5 the size, it should be 5x more likely. (This may be too much work, but if it's practical, it satisfies both my OCD and my desire to prevent obvious loopholes with the rules)

I'd rather see all scientist bonuses go up 1% at a time -- and probably also more often as a result.
Title: Re: C# Suggestions
Post by: JacenHan on April 15, 2020, 10:50:10 AM
Would be nice if Governor death would cause auto turns to stop and would be easily differentiated from other officer deaths. After all these are rather important events from game play and RP perspective
Admin commands should auto-assign.
While I would also like admin commands to auto-assign, I think that a similar notification as suggested above for governors would be a good feature if people are against the idea of it in general.
Title: Re: C# Suggestions
Post by: Alsadius on April 15, 2020, 11:18:40 AM
I'd rather see all scientist bonuses go up 1% at a time -- and probably also more often as a result.

That seems like it'd be a bit spammy, tbh. If you do that, I'd really want the Event window to be clearer, with the "Commander Experience" entry replaced by "Scientist Experience" (or Army Commander/Navy Commander/Administrator, as appropriate).

The other way to avoid odd-man-out syndrome is to make the promotions random between(e.g.) 3-7%, instead of a flat 5%.
Title: Re: C# Suggestions
Post by: Agoelia on April 15, 2020, 12:01:13 PM
Unpopular opinion: I don't like comets.
Furthermore, I feel like they visually clutter some system, especially Sol.
We have options to hide everything, from gas giants to planets and moons to asteroids, but no option to hide comets, I wish there was one.
Secondly, there is a "min comets per system", but no "max comets per system", altough I think I'd be one of the only ones to use it.

More importantly, after some testing I found out that "all jump points already stabilised"  in game options doesn't work if enabled after game start.
I think it should be moved from "options that can be modified at any time" to "options that can be modified at game start"
Title: Re: C# Suggestions
Post by: Randy on April 15, 2020, 12:19:04 PM
Is there a way to provide custom ship names and/or ship class names?

There're already mechanisms for adding custom flags, racial portraits, and naval leader names; adding the ability to provide custom ship names and ship class names would create the potential for "Race packs" to customize starts. 

With a tweak to folder layout, you could allow coherent 'Races' to be created:
Code: [Select]
Races
  Race
    flag.png
    ship.png
    station.png
    portrait.png
    Medals
      medal###.png
    Names
      commanders.txt
      ships.txt

And add in medals.txt to define the medals, plus GU.txt to set up default ground forces organization...  ;D
Title: Re: C# Suggestions
Post by: Awazruk on April 15, 2020, 01:05:11 PM
After playing for a bit now i realised we could use more standing and conditional orders both in the amount of commands they use and amount of them you can set.
RN with Geo and Grav survey equipment being military gear I (and i assume many others) just put both on the same ship.  Everything is fine with that but you start running into problems if your surveyors are carrier based.  Now you have to either pick one type of survey as primary standing order and return to carrier as second one and divide parasites into those 2 duties or set all of them to both survey types and have to order the return manually.

We also could use some other orders like 'Until Fuel full - refuel from (pick Fleet)' - used for tankers hauling fuel from sorium harvesting stations.
In general being able to pick exact destinations or fleets in standing/conditional orders would be great.
Title: Re: C# Suggestions
Post by: Droll on April 15, 2020, 04:17:45 PM
Unpopular opinion: I don't like comets.
Furthermore, I feel like they visually clutter some system, especially Sol.
We have options to hide everything, from gas giants to planets and moons to asteroids, but no option to hide comets, I wish there was one.
Secondly, there is a "min comets per system", but no "max comets per system", altough I think I'd be one of the only ones to use it.

More importantly, after some testing I found out that "all jump points already stabilised"  in game options doesn't work if enabled after game start.
I think it should be moved from "options that can be modified at any time" to "options that can be modified at game start"

For clarity, the VB6 the equivalent "all jump gates" option also didn't stabilize already discovered jump points but made it so that any newly discovered ones were "stabilised". Are newly discovered jump points not being stabilized with this option for you? I don't play with that option so I wouldn't know.
Title: Explore Unexplored Jump Point
Post by: joshuawood on April 15, 2020, 04:43:26 PM
A standing Orderer for "Explore Unexplored Jump Point" which finds the nearest unexplored jump point and well. . .  explores it. . .  Would be amazing!

This along with overhauling that refills supplies would allow me to FULLY automate exploration hahaha, i can't see that going badly. . . can you?
Title: Re: C# Suggestions
Post by: Droll on April 15, 2020, 05:14:13 PM
I've been thinking about the whole ground unit replenishment thing and I think I have some ideas.

This has been suggested before but I want to parrot it since it will become relevant later. Ground unit construction can be made to behave exactly like how industrial construction with factories work. Each ground unit facility would add to an annual construction rate based on the tech that already exists and would go through a queue. If a player wants to build units in parallel they can use construction %modifier like with factories.

So the main issue that Steve has already said that he wants to implement is formation auto replenishment. I would suggest that the player can decide to specify a "target" template based on what has been designed that each formation tries to adhere to. So if the player wants to replenish/modify an existing formation all they'd need to do is press a button and the necessary GU construction would begin.
There are two main cases to consider that I can think of:
1 - The target template will have units that are not in the formation we are modifying
2 - The modified formation will have units that are no longer supposed to be in the formation as they are not in the target template

Suggested solution for 1:
So as said at the top if GU construction is handled like with factories then this can be solved by creating a temporary template comprising of the additional units that are needed and adding it as a construction order. This is more convenient with this new GU construction because we do not have to consider there not being available GU training facilities - we just add the new order to the queue.

Suggested solution for 2:
a - Similar to solution for 1 but instead we generate a new "surplus" formation with all the unnecessary units in it. This would facilitate not only auto-replenishment but also allow a player to modify an already built template. It would probably be easier to handle if this is done the moment the player presses the "set to template" button or something - that way the game doesn't have to track any construction orders.
b - This is much more involved. You could make it so that every planet has 2 "theaters" - "Active combatants" and "reserves". The active combatant is just what we have right now, all the formations organized according to the OOB. The reserve theater acts as one massive undeletable formation, regardless it is all the spare loose units on that planet just organized into a pile by unit class. In order to solve problem 2 you would simply move the "surplus" units in the formation that are no longer needed into the reserve formation.

Solution 2b is probably a bit unnecessarily complex for the problem as it opens a whole new can of worms but it has interesting possibilities, some balance considerations that pop into my head:
1 - How do reserves behave when there's combat?
2 - How do reserves interact with orbital bombardment?
3 - Can reserves reinforce active combat formations during combat to replace casualties?
4 - How do reserves interact with transports?
5 - Can I create templates without ground facilities by pushing reserves to the active front?
And most certainly issues that I cant think of

For 1 I would suggest that reserves do not perform attacks on their own. As for their target-ability by enemy ground forces the best I can think of is to either make the reserves a rear-echelon only formation or create a new reserve line that is even further behind the rear-echelon position. Maybe make it so that only long-range arty and Air-attacks can target them but I do not think it would be a good idea to make them only target-able if there are not active combatants.
For 2 I would recommend that Planetary and naval bombardment should impart casualties to reserves but their probability to be targeted should probably be weighted so that active troops are more likely to get bombed. Orbital bombardment support should maybe be restricted to active combatants or simply more biased to targeting active combatants relative to the other bombardment options.
1 and 2 could probably both be solved if you regard reserves as completely irrelevant for the combat itself. You can have it so that if a template has not seen any combat for X amount of time (X would be up to Steve but it could be a production increment for example) it is allowed to draw from reserves.

For 3 as mentioned earlier each formation can have assigned a target template that it tries to adhere to - during combat a unit might receive reinforcements from the reserve based on multiple factors:
- Amount of casualties as % of the target template: more heavily beaten formations likelier to get reinforced
- Amount of damage taken last combat round: A formation taking massive amounts of damage might be more or less likely to get reinforced
- Enemy breakthroughs: A formation that has been broken through is less likely to get reinforcements (could also make it so they don't get reinforcements)
- Total formation size (whatever is left alive so a lone surviving soldier isn't going to get a full reinforce) - this should also affect the total amount of reinforcements that a formation can receive
- Reserves total size: A reserve pool can mobilize a % of its total size to reinforce but not more - % could be affected by tech or maybe a new logistical unit class
- Position of formation: Do frontline formations get priority to reinforcements? Or do further back support positions get more reinforcements because it's easier for them to receive?
- Tot no. of casualties last combat round: Maybe only a % of casualties every combat round can be reinforced, maybe % influenced by tech or logistics
And more

Edit: I am a moron and forgot to write for after 3.
4 - Transports could have an additional "load units from reserve" that would allow them to load lets say X many of a unit that exists in the reserve. Unloading these troops should land them in the reserve position of their destination
5 - This would mostly need UI shenanigans to make sure it works smoothly but failing that using the features I discussed here you could just make a dummy template with 1 infantry unit and once built set his formations target template to whatever you want to add from reserves.


Any reserve reinforcements pushed to the front should start at no fortification and a formation should only receive reinforcements if it has an assigned target template to reinforce too or maybe give the player control like a "combat reinforcement" checkbox for the formation. Incoming reinforcement could also have a morale penalty based on the morale state of the formation they are headed to.
All reinforcements should either be handled at the beginning or end of each (or every X) combat round(s).

Apologies for the long one.
Title: Re: Explore Unexplored Jump Point
Post by: Froggiest1982 on April 15, 2020, 05:17:05 PM
A standing Orderer for "Explore Unexplored Jump Point" which finds the nearest unexplored jump point and well. . .  explores it. . .  Would be amazing!

This along with overhauling that refills supplies would allow me to FULLY automate exploration hahaha, I can't see that going badly. . . can you?

I would agree with your only for one reason: Once we explore the jump point the nomenclature changes making it very hard to remember which one was closer etc:

Explanation:

If you have 3 unexplored jump points they will appear as follows:

Unexplored jump point #1
Unexplored jump point #2
Unexplored jump point #3

When you explore the jump point 2 for instance (because a ship is closer or just arrive before the one you have sent to point 1) the Unexplored jump point #3 changes to Unexplored jump point #2

Bottom line: having that feature will ensure the ship always moves to the closer one, however it might be intricate when you have multiple scouts moving together as there should be a line of code to avoid scouts to move into the same location.
Title: Re: C# Suggestions
Post by: The_Seeker on April 15, 2020, 08:32:06 PM
I'm not sure if I missed something, but I can't shift or ctrl click ships to move groups of them between fleets, I can only move them one at a time, that'd be a huge QoL improvement.
Title: Re: C# Suggestions
Post by: Vivalas on April 15, 2020, 08:44:41 PM
Discussion came up in Discord about two new conditionals that would be pretty handy and maybe easy to implement:

1. Refuel when at range to nearest refueling hub. (give or take 10% to be safe)

2. Resupply when MSP is at max repair cost.

Both of these would be more reasonable than guestimating percentages, at the cost of perhaps slightly more complex calculating.
Title: Re: C# Suggestions
Post by: Desdinova on April 15, 2020, 10:13:42 PM
It would be really nice to have a warning when you have a tanker class design without a refueling system.
Title: Naval and Ground OOB Background text color
Post by: peli082 on April 15, 2020, 10:18:16 PM
Be able to recolor the background of a text just like the events tab to separate different sector command, Divisions, departments, etc.  for us who like to have complicated OOB would be nice.  Thanks for your hardwork!
Title: Re: C# Suggestions
Post by: SerBeardian on April 16, 2020, 05:27:57 AM
I have two suggestions:

1) A Damage % readout in Fleet View showing how many HTK of destroyed components a ship has lost, to go with the other status readouts. Would make it a little easier to find out if there are any damaged ships without relying on the Repair Report.

2) A list of unfulfilled contracts in the Civilian Economy Tab, so that we can see at a glance what contracts are missing their supply/demand orders, and can apply them to a colony with fewer clicks. Selecting an unfulfilled contract and clicking Add Demand/Add Supply would automatically add the appropriate supply/demand order for the selected colony to fulfill the selected order.
Title: Re: C# Suggestions
Post by: Agoelia on April 16, 2020, 05:57:54 AM
In new game settings, max and min NPR distance should be in jumps, not in light years.
The actual distance in light years is useless from a gameplay perspective, and it's also hard to estimate exactly how many jumps away the NPRs will be.
Furthermore, if it was in jumps, it would also be usable in Not Real Stars games. As far as I understand it, min and max NPR distance has no effect in Not Real Stars games.

And, if min distance was set to 0 jumps, maybe there should be a chance for NPRs to spawn inside the solar system, maybe on Mars, Venus or Titan.




In the research screen, it should be possible to "move down in queue" research that are currently being researched.
The industry queue already works like that.
It would make switching the current research much easier and faster, because we don't have to scrap and rebuild the entire queue every time.
Title: Re: C# Suggestions
Post by: Shadow on April 16, 2020, 06:12:03 AM
The ability to import/export "packs" of medals and awards with their points, descriptions and pictures.

The ability to import/export ground formation templates

I fully support this.
Title: Re: Explore Unexplored Jump Point
Post by: TMaekler on April 16, 2020, 06:16:49 AM
A standing Orderer for "Explore Unexplored Jump Point" which finds the nearest unexplored jump point and well. . .  explores it. . .  Would be amazing!

This along with overhauling that refills supplies would allow me to FULLY automate exploration hahaha, i can't see that going badly. . . can you?
If it would be possible to fully automate exploration, I was wondering if some kind of log message should be given by such exploration vessels for cases when they use over, let’s say, 75% of their fuel to move between exploration goals and refuel / resupply stations.

Example: a ship auto explores and hits the „less then 50%“ mark, auto returns to refuel and goes back exploring. After arriving back at the exploration Point the engineer states to the captain, that both flights back home and back to here took 75% of their total fuel. Of course in between it had been refueled, but nevertheless, both flights together make it eventually a bit inefficient. So a warning in the log for the player would be nice to stop that exploration or initiate creating a fuel depot somewhere in that are, to further exploration.
Title: Re: C# Suggestions
Post by: MinuteMan on April 16, 2020, 07:48:15 AM
Regarding the research queue

1. It would be awesome if you could add multiple items to the queue at once.
2. Sort the research queue by researcher and then by the research order
Title: Re: C# Suggestions
Post by: Zhatelier on April 16, 2020, 08:52:39 AM
I'm sure this has been suggested and discussed before, but I really hope the linking of a JP to a certain system in SM Mode will be added soon. My reasons for this are primarily selfish: I have plans for a custom galaxy with 50+ systems all forming a closed system and manual linking would make my job a lot easier. With the current tools, I can most likely still achieve it, but it may end up being highly time-consuming. I do realize that it probably won't, nor should, be a priority over important bugfixes and implementing it may not be as easy as it might sound. I simply wanted to voice my wish for it to be implemented sooner rather than later  ;)
Title: Re: C# Suggestions
Post by: Kashada on April 16, 2020, 10:23:27 AM
First off great game and thank you for making it available, your amazing!

Secondly my suggestion is a minor one but could we get some sort of dead weight module for ships.  Purely so my OCD doesn't get triggered by a ship coming in at 29,994 tons :)

But as a more practical reason it might be helpful to add say 1, 10, 100 & 1000 ton dead weight modules is it would the design of ships with dedicated upgrade slots.  This would be much more appealing at least RP wise when say a ship goes in for a sensor upgrade and comes out the refit same tonnage.
Title: Re: C# Suggestions
Post by: DFNewb on April 16, 2020, 10:24:59 AM
First off great game and thank you for making it available, your amazing!

Secondly my suggestion is a minor one but could we get some sort of dead weight module for ships.  Purely so my OCD doesn't get triggered by a ship coming in at 29,994 tons :)

But as a more practical reason it might be helpful to add say 1, 10, 100 & 1000 ton dead weight modules is it would the design of ships with dedicated upgrade slots.  This would be much more appealing at least RP wise when say a ship goes in for a sensor upgrade and comes out the refit same tonnage.

Just add tiny fuel and engineering components and edit deployment time with decimals.
Title: Re: C# Suggestions
Post by: Garfunkel on April 16, 2020, 10:43:32 AM
It affects armour calculation as well, so it's not as simple as adjusting tonnage. Hence why it's probably best to fiddle with deployment times and the fighter/tiny sized fuel/engineering modules.
Title: Re: C# Suggestions
Post by: Nori on April 16, 2020, 10:47:32 AM
Not sure if this was suggested (or possibly can be done but I don't know how) but it'd be nice to be able to select multiple ground units to move under a HQ and multiple ships to move under a fleet.
Title: Re: C# Suggestions
Post by: Doren on April 16, 2020, 10:49:56 AM
Maybe once a design is locked it would list the tonnage as a rounded out value while actually keeping the actual tonnage and size. Kind of as a stamp "This ship is 15 000 ton ship that we made" instead of "Well technically it is just shy of 15 000 tons a 14 999,87779 to be exact"
Title: Re: C# Suggestions
Post by: Barkhorn on April 16, 2020, 11:28:07 AM
I would very much like an option to automate where your fleet's escorts went.  In VB6, we had the ability to set what bearing the escorts stayed at with respect to the main fleet.  Most battles seem to be fought between one fleet that was already in a system and another that just jumped in.  So most fire should be going towards or away from the sun.  In other words, fire tends to generally follow lines of longitude.  So there's not much point in having your escorts along lines of latitude.  Basically instead of maintaining a bearing with respect to the parent fleet, I'd like the option to have them maintain a bearing with respect to the sun.

I hope I explained this clearly.
Title: Re: C# Suggestions
Post by: Droll on April 16, 2020, 11:54:15 AM
Not sure if this was suggested (or possibly can be done but I don't know how) but it'd be nice to be able to select multiple ground units to move under a HQ and multiple ships to move under a fleet.

You can do this with ships. Instead of highlighting in the OOB highlight them in the shiplist of whatever fleet they are in, make a new fleet and they should all be in this fleet. Then move that fleet under the fleet you want them to be under.
Title: Re: C# Suggestions
Post by: Aloriel on April 16, 2020, 12:40:29 PM
Can we get an event differentiation between "long term medical problem" and "death"?

Long term medical problems don't bother me. Death is a critical issue that requires a replacement officer, or worse, administrator.
Title: Re: C# Suggestions
Post by: Erik L on April 16, 2020, 12:47:12 PM
Can we get an event differentiation between "long term medical problem" and "death"?

Long term medical problems don't bother me. Death is a critical issue that requires a replacement officer, or worse, administrator.

Technically, they are both long term medical issues. Just one is more... permanent :D
Title: Re: C# Suggestions
Post by: BitterOldGuy on April 16, 2020, 01:26:12 PM
Quote from: Erik Luken link=topic=10640. msg124092#msg124092 date=1587059232
Quote from: Aloriel link=topic=10640. msg124083#msg124083 date=1587058829
Can we get an event differentiation between "long term medical problem" and "death"?

Long term medical problems don't bother me.  Death is a critical issue that requires a replacement officer, or worse, administrator.

Technically, they are both long term medical issues.  Just one is more. . .  permanent :D

Doctor: I have good good news and bad news.  The good news is that the Admiral's condition has stabilized. . .
Title: Re: C# Suggestions
Post by: darkevilme on April 16, 2020, 05:42:06 PM
Okay first off. I played this game a bit long ago and I had someone in discord i knew be like look new version of aurora!.. and the new version looks cool so far, so hats off and kudos.

That aside I have a suggestion. Can there be an option to have a start in the game that's not the sol system for those of us who like to play aliens?

All my attempts to do this with spacemaster mode to kludge it like I used to do it in a way older version have resulted in, not good things.
Title: Re: C# Suggestions
Post by: Luftwolfe on April 16, 2020, 05:49:55 PM
Quote from: darkevilme link=topic=10640. msg124233#msg124233 date=1587076926
Okay first off.  I played this game a bit long ago and I had someone in discord i knew be like look new version of aurora!. .  and the new version looks cool so far, so hats off and kudos.

That aside I have a suggestion.  Can there be an option to have a start in the game that's not the sol system for those of us who like to play aliens?

All my attempts to do this with spacemaster mode to kludge it like I used to do it in a way older version have resulted in, not good things.

There is a very specific way of doing non-Sol starts, it's been mentioned quite a few times on the forums here.  I'd look around and see if you can't find it
Title: Re: C# Suggestions
Post by: TMaekler on April 16, 2020, 05:55:15 PM
Maybe it is best that Steve doesn't release the game from now on. Having read a bit on reddit and the rant that is going on there ... makes me puke. No one should have this nice piece of software whilst this smegload is going on... .
Title: Re: C# Suggestions
Post by: rainyday on April 16, 2020, 07:10:22 PM
It might be nice to have an option on the research screen to show all racial techs. 

I tend to design everything I need for a ship (or a generation of ships) all at once and then go assign researchers to the individual projects when I'm done.  That involves hunting through all the tech categories and trying to remember everything I designed.  With such a big tech tree it's easy to miss things in the list.
Title: Re: C# Suggestions
Post by: swarm_sadist on April 16, 2020, 08:16:06 PM
That SM screen in VB6 that showed all the systems by number currently in play. I have been at 2 hour increments for about a month in game time and I would like to hunt down the responsible party.
Title: Re: C# Suggestions
Post by: Gnoman on April 16, 2020, 11:09:37 PM
I've had to rescue a few survey ships because they ran low on fuel, and can not get them to stop and refuel without mucking with the conditional orders.  It would be very helpful if we could have a "current location" option for fleet orders, so we could easily just override conditionals temporarily. 
Title: Re: C# Suggestions
Post by: MarcAFK on April 17, 2020, 01:30:57 AM
I should read through this thread to check what's already been proposed, but a search came up empty for this.
Adding cargo holds should give a warning message if no cargo shuttle bays are present
"Vessel contains cargo holds but no cargo shuttle bay, it will be unable to load or unload without the presence of a spaceport or ground based cargo handling facility"
Though perhaps that message is a little verbose, but the idea is that many people make the mistake of not adding any shuttles, I've done it several times myself :)
Title: Re: C# Suggestions
Post by: cool_hc on April 17, 2020, 01:58:32 AM
hi Steve

I just want to say thanks for all the hard work on C#.  I've been playing since the early days of the VB6 version

Just a few suggestions below:
- can we have the time increments on the events page, like we used to have in VB6 events page.  This would let us get thru first few years quickly whilst monitoring events.
- also, can we re-implement quick keys for various windows.  I remember VB6 had quick keys like F12 for fleet movements, F6 for design window, ESC key to close windows, etc.  It was really handy.
- could we have a button for "Shipyards" on the main screen? i feel its one of the more heavily used menus
-in orders screen, there used to be a button to 'repeat orders XX times".  any chance to reimplement that?


thanks again
Title: Re: C# Suggestions
Post by: Doren on April 17, 2020, 04:47:29 AM
Ticking "Tanker" on designer should give error if no "Fueling system" is present on the ship

Ticking "Supply ship" on designer should give error if no "Cargo shuttle bay" is present on the ship

Ticking "Collier" on designer should give error if no "Ordance transfer system" is present on the ship

Refueling capacity should also state how many ships the tanker can refuel simultaneously (to make it easier for people to recognize that you might need/want more of these modules on a single ship)
Title: Re: C# Suggestions
Post by: SerBeardian on April 17, 2020, 05:28:57 AM
Since we have ground troops doing survey that actually generates survey points, versus a semi-random dice roll, it would be nice to have a progress indicator of how much is done of a ground survey, similar to how orbital survey shows a "points remaining".
Title: Re: C# Suggestions
Post by: Rich.h on April 17, 2020, 11:05:40 AM
Is it possible we could get the old system graphic screen back at some point? Whilst it adds nothing in so far as gameplay I always found it great for general RP flavour when seeing systems and the different planetary pictures.
Title: Re: C# Suggestions
Post by: UberWaffe on April 17, 2020, 11:25:07 AM
Really awesome game.   Thank you for all of your hard work. 

Some suggestions:

Allow Fuel Refineries and Maintenance Fascilities to have 'targets' instead of on/off:
Refer to: Economy_CivEco_FuelAndMaintTargets. png
Change the "Stop / Start" button ("Economy -> Industry") for the Fuel refineries and Maintenance fascilities to "Manage" that opens a pop-up. 
In the pop-up have a target number to enter.   While the respective stockpile is below this number, the respective industries are on and working.   If above, they stop. 
Two quick action buttons for "Stop" (limit = 0) and "Max" (Limit = 2 billion or similar big number).   Default is "Max", i.  e.   if you build some industries they will process non-stop as far as possible. 


Clearer indication for text fields that can be edited:
Refer to: Economy_CivEco_TextInputStandard. png
For all text fields that can be edited (and are meant to be) give them a bounding box, so it is clear they are an input and not just info. 
This would make them similar is style to buttons, so it is more intuitive what can be changes and what cannot. 

Alternatively make fields that are not inputs non-green, and keep green only for input items. 


Civilian Mines, busy purchasing post-fix indicator
Refer to: Economy_Mining_PostfixBuyOrTax. png
In "Economy" window, on the left where the planet list is shown, for all civilian complex that minerals are being purchased from, add a (P) at the end of the name.   (Behind the CMC)
This would make it much easier to easily spot where we are purchasing or not. 
Alternatively, do the (T) for Tax instead.   I would suggest only doing one or the other, since it is easier to spot a shape (lack of a letter) at a glance than differentiating between two letters.   (If both P and T are post-fixed.  )


Civilian Demands and Supplies UI
Refer to: Economy_CivEco_DropdownRelocate. png
In "Economy" -> "Civilian Economy" for the supply and demand dropdowns (where you pick the installation), move those dropdowns to within the popup. 
In the case of doing a modify, make the field read-only. 
Title: Re: C# Suggestions
Post by: Kristover on April 17, 2020, 11:29:31 AM
Future feature request - I was playing Football Manager the another night and I walked away thinking, 'It would be nice if Aurora C# had a periodic autosave'.  Given I've had a couple game crashes at inopportune times, I would have liked to have a feature that auto-saved every 6 or 12 months setting dependent. 
Title: Re: C# Suggestions
Post by: Migi on April 17, 2020, 11:46:31 AM
Future feature request - I was playing Football Manager the another night and I walked away thinking, 'It would be nice if Aurora C# had a periodic autosave'.  Given I've had a couple game crashes at inopportune times, I would have liked to have a feature that auto-saved every 6 or 12 months setting dependent.

An autosave would have to be based around the number of full increments since last save, if you made it every 6 months it would only be useful for early game.
Title: Re: C# Suggestions
Post by: Elouda on April 17, 2020, 11:51:20 AM
Could the retirements of officers assigned to Admin Commands (which dont get assigned by the auto-assign) be made more discrete in the event log, and also have them break the autorun? I seem to often find these go months without anyone in them because the officer retirements/updates are so common.
Title: Re: C# Suggestions
Post by: AlStar on April 17, 2020, 02:09:02 PM
I'd be extremely surprised if I'm the first one to suggest this, but in the off chance that I am:

Given the number of bug reports and otherwise confused players (myself included!) I think that any ship that has either Cryogenic Transport modules or Cargo Hold modules but does not have at least one Cargo Shuttle Bay should trigger a warning in the ship designer saying "this ship will only be able to load/unload from planets or ships that have the needed cargo transfer equipment." (Or something similar.)
Title: Re: C# Suggestions
Post by: Inglonias on April 17, 2020, 04:21:38 PM
It would be nice if saving the game showed up in the event log so we can avoid this situation (https://www.youtube.com/watch?v=2T2EhHRCFUY)
Title: Re: C# Suggestions
Post by: Raaaak on April 17, 2020, 05:17:41 PM
Since it is now a known bug that will not be fixed I'll post it as a suggestion instead.

Please consider supporting language settings which use comma as a decimal separator.  A big part of what I was looking forward to with the C# version was not having to mess around with my Windows settings to get the game to run.

It should (dangerous word to use as a developer I know) not be more difficult than either outputting hardcoded numbers to input fields by standard string conversions instead of string constants.  (I. e.  InputBox. Text = (0. 1). ToString() instead of InputBox. Text = "0. 1")

Or less ideally, but a lot less work for you, overriding the culture settings of the program.
Code: [Select]
var ci = new System. Globalization. CultureInfo("en-UK");
System. Globalization. CultureInfo. DefaultThreadCurrentCulture = ci;
System. Globalization. CultureInfo. CurrentUICulture = ci;
as the first few lines of code on app startup.
This would also fix any problems with inconsistent date formats.


(Anti hyperlink function is messing up my code, please remove any extra spaces before reading)

And a question as well. Are we still supposed to use this thread now that there is an entire suggestions board?
Title: Re: C# Suggestions
Post by: ReviewDude01 on April 17, 2020, 05:29:27 PM
Suggestion: make this program work properly for any or at least: resolutions of 1366 X 766 or more

This is a C# script for Unity engine called uGUI tools made by Senshi

It makes every unity interface UI piece including its childrens fully rescalable with any resolution. (use the first option Anchors to Corners)
I have tested it, it works.
I have configured it.
I do not know what program are you using but Im posting it in case that it might be useful to you.
If yes please read below:

using UnityEditor;
using UnityEngine;

public class uGUITools : MonoBehaviour {

   [MenuItem("uGUI/Anchors to Corners %1")]
   static void AnchorsToCorners()
   {
      foreach (Transform trans in Selection.transforms)
      {
         RectTransform t = trans as RectTransform;
         RectTransform pt = trans.parent as RectTransform;

         if(t == null || pt == null) return;

         Vector2 newAnchorsMin = new Vector2(t.anchorMin.x + t.offsetMin.x / pt.rect.width,
            t.anchorMin.y + t.offsetMin.y / pt.rect.height);
         Vector2 newAnchorsMax = new Vector2(t.anchorMax.x + t.offsetMax.x / pt.rect.width,
            t.anchorMax.y + t.offsetMax.y / pt.rect.height);

         t.anchorMin = newAnchorsMin;
         t.anchorMax = newAnchorsMax;
         t.offsetMin = t.offsetMax = new Vector2(0, 0);
      }
   }

   [MenuItem("uGUI/Corners to Anchors %]")]
   static void CornersToAnchors(){
      RectTransform t = Selection.activeTransform as RectTransform;

      if(t == null) return;

      t.offsetMin = t.offsetMax = new Vector2(0, 0);
   }
}

this version needs Unity Editor, click on an UI piece and use Editor->AnchorsToCorners to make it work.

Here is a configured "function" version that can be applied to any UI piece created by script at runtime. :

void RuntimeAnchorsToCorners(GameObject InputGo)
   {
      
      Transform tempTransform = InputGo.transform;
      RectTransform t = tempTransform as RectTransform;
      RectTransform pt = tempTransform.parent as RectTransform;

         if(t == null || pt == null) return;

         Vector2 newAnchorsMin = new Vector2(t.anchorMin.x + t.offsetMin.x / pt.rect.width,
            t.anchorMin.y + t.offsetMin.y / pt.rect.height);
         Vector2 newAnchorsMax = new Vector2(t.anchorMax.x + t.offsetMax.x / pt.rect.width,
            t.anchorMax.y + t.offsetMax.y / pt.rect.height);

         t.anchorMin = newAnchorsMin;
         t.anchorMax = newAnchorsMax;
         t.offsetMin = t.offsetMax = new Vector2(0, 0);

   }

an example calling this function:

GameObject /* or var */ aNewButtonCreatedFromScript = .... // code to create a new button or an UI piece;

RuntimeAnchorsToCorners (aNewButtonCreatedFromScript); // needed for every UI piece

Notes for converting it to another engine:
: Vector2 is basically an unity engine (float,float) "struct".
Anchors are points representing UI element positions in 2d screen.

I believe that RectTransform is roughly represented as Top,Left,Right,Bottom properties in 2D.
https://docs.unity3d.com/ScriptReference/RectTransform.html

If you think that this solution might be viable I might dig more data about how to convert it for Aurora C.

Title: Re: C# Suggestions
Post by: Desdinova on April 17, 2020, 05:33:29 PM
Steve's not using Unity. The whole thing is written as a regular C# application using Windows Forms to draw the GUI.
Title: Re: C# Suggestions
Post by: Coleslaw on April 17, 2020, 06:19:55 PM
Not sure if this has already been discussed, and I'm pretty sure it's not a bug, just one of those things that had to be left out, but could/will we have the opportunity to "Repeat Orders X Times" when ordering fleets? That function was super helpful when trying to transfer exact quantities of stuff to populations, but as is I have to sort of guess the right amount with the "Repeat Orders" option instead, and using it in that way means I can only transfer installations in squares of 2.
Title: Re: C# Suggestions
Post by: DFNewb on April 17, 2020, 06:28:25 PM
Some sort of way for fighters to work without needing ground based forces (FFD in this case).
Title: Re: C# Suggestions
Post by: mtm84 on April 17, 2020, 06:33:02 PM
Per Steve: “ You can't resize window. Required resolution is 1440 x 900. There is no reduced height option. This will not change any time soon.”
Title: Re: C# Suggestions
Post by: alex_brunius on April 17, 2020, 06:51:30 PM
I think it feels pretty odd that fast firing AA and Autocannon weapons are larger than the corresponding Anti-Vehicle weapons, at least when it comes to the tanks/vehicle mounted weapons.

In my fantasy worlds at least I tend to associate Anti-Vehicle and higher penetration with some of the largest and heaviest guns, whatever technology or Sci-Fi setting I may be using as a basis ( although I can see how bombardment weaponry could be of equal size or larger than anti vehicle so that I'm fine with ).

So my suggestion is the AA & Autocannon should be a bit smaller or Anti Vehicle a bit larger in size to feel right ( which might require rebalancing other stats they have )
Title: Re: C# Suggestions
Post by: Erik L on April 17, 2020, 10:39:06 PM
Ability to automatically add a prefix/suffix to a ship if such a thing is decided on after ships of that class are built already.
Title: Re: C# Suggestions
Post by: Froggiest1982 on April 17, 2020, 10:41:19 PM
Make planes part of ground unit design and keep fighters as Orbital elements only with bombardment capability (same as spaceships)
Title: Re: C# Suggestions
Post by: DFNewb on April 17, 2020, 10:50:04 PM
I think it feels pretty odd that fast firing AA and Autocannon weapons are larger than the corresponding Anti-Vehicle weapons, at least when it comes to the tanks/vehicle mounted weapons.

In my fantasy worlds at least I tend to associate Anti-Vehicle and higher penetration with some of the largest and heaviest guns, whatever technology or Sci-Fi setting I may be using as a basis ( although I can see how bombardment weaponry could be of equal size or larger than anti vehicle so that I'm fine with ).

So my suggestion is the AA & Autocannon should be a bit smaller or Anti Vehicle a bit larger in size to feel right ( which might require rebalancing other stats they have )

In my opinion autocannons seem useless. I am not sure when you would want them, maybe if you want to make armies of just type of unit instead of combined arms? Still wouldn't be good tho.
Title: Re: C# Suggestions
Post by: Alsadius on April 17, 2020, 11:37:11 PM
We currently have the "Temp[late] as Text" button for ground units, which is nice, but it gives no details on the makeup of the elements. When we post our OOBs on the design forum, it's hard to tell what the "Tank" someone's using is. Can we get some unit info into that text?

Make planes part of ground unit design and keep fighters as Orbital elements only with bombardment capability (same as spaceships)

I really love the fighter pod concept, tbh. I wouldn't mind fighters as ground units, if there was some mechanical role they could play, but it's primarily a space game, and finding a nice clean way for space fighters to participate in the new ground combat system is really good to see.

In my opinion autocannons seem useless. I am not sure when you would want them, maybe if you want to make armies of just type of unit instead of combined arms? Still wouldn't be good tho.

The best use for them I can find is that they cause fairly low levels of collateral damage for their firepower, since they're high AP and low damage. Given that collateral damage is proportional to damage cubed, this makes a big difference. But I don't think it's something many will care about, and their stats are very weak.

The suggestion I made pre-launch was to make LACs available on infantry, give MACs a fourth shot, and HACs five shots (but up them from 72 tons to 80). With other stats equal to what they are now, those are fairly balanced.
Title: Re: C# Suggestions
Post by: DFNewb on April 17, 2020, 11:40:01 PM
We currently have the "Temp[late] as Text" button for ground units, which is nice, but it gives no details on the makeup of the elements. When we post our OOBs on the design forum, it's hard to tell what the "Tank" someone's using is. Can we get some unit info into that text?

Would be nice if an auto-naming thing is added for units the same way it works for ship components. I wouldn't mind having it auto put in MedVehAT+AT or something by itself.
Title: Re: C# Suggestions
Post by: firsal on April 18, 2020, 12:11:39 AM
A minor thing, it would be nice if MAA units could also provide AA coverage for units under the same parent formation as it's formation. For example, I have an AA battery and 3 tank battalions under one HQ; it would be great if it could cover its fellow subordinate formations. Plus, this isn't much different from having the AA units  within the HQ formation; it would still provide AA cover for the same units.
Title: Re: C# Suggestions
Post by: Alsadius on April 18, 2020, 07:40:34 AM
A minor thing, it would be nice if MAA units could also provide AA coverage for units under the same parent formation as it's formation. For example, I have an AA battery and 3 tank battalions under one HQ; it would be great if it could cover its fellow subordinate formations. Plus, this isn't much different from having the AA units  within the HQ formation; it would still provide AA cover for the same units.

I'm not entirely opposed, but you want to watch out for players who make larger formations just using MAA in a lot of front-line units and having them all cover each other.

So I'll propose a tweak. If a unit with MAA is in support position, it can cover its parent's subordinates.
Title: Re: C# Suggestions
Post by: Silverkeeper on April 18, 2020, 07:56:20 AM
I have limited experience with Aurora 7.2 but I really miss the old fighter window.
Refueling was easier too.

Thanks Steve for an awesome game.
Title: Re: C# Suggestions
Post by: DEEPenergy on April 18, 2020, 09:46:22 AM
It would reduce a lot of clutter if there was an option to 'Group Contacts' for civilian ships :)
Title: Re: C# Suggestions
Post by: Black on April 18, 2020, 09:59:29 AM
Yeah, I had to turn them off in Contacts menu, because there is heavy traffic in my home system, option to group them would be welcome.
Title: Re: C# Suggestions
Post by: Napier on April 18, 2020, 11:51:27 AM
These are some minor quality of life suggestions with the UI that I've come across so far in 1. 51.       

One of the most appreciated aspects of this and games in general for me are all the small details that enhance my willingness to play, rather than erode it.     



1.       Ship design, 2nd pane with items to add - if you extend one of the show/hide pulldowns, and then you close it again, the game doesn't remember that closure each time you re-open design window.       It'll keep them open until you restart the game, at which time all of them are closed.     

2.       Have the mouseover tooltips stay on the screen for much longer than 2 or 3 seconds.       Some of them are long and I need to mouseover several times to read the whole label.     

3.       Industry tab - after modifying a construction order, leave the line item that was modified highlighted.       Personally, often I want to change the queue order as well, especially in situations where I need to modify the % before the game will let me move it up into the active queue.     

4.       Movement orders tab - After adding an order the left most pane resets to the top of the list each time you add an order.       In scenarios where there is a scroll bar and I am working further down the list, I'd need to scroll down each time.        Ie.       if there is a long list of asteroids and I want to geo survey a specific set in the same general area of the list, I'd need to scroll down each time after I add an order to find the next one again.     

5.       Not sure if it's possible to add double clicking capability to the 3rd right most pane of the movement orders tab, as it has for the middle 2nd pane.     

6.       Movement orders tab - When trying to select multiple items in the 3rd right most tab, only the first item is added to the orders list rather than all of them.       i.      e.       a common scenario for me would be selecting multiple minerals to add the same amount to a cargo hold at once.       May not be able to use double clicking in this case.     

7.       Naval org - have the game remember the checked state of the 'Show civilians' checkbox.     

8.       Naval Org, OOB tab - 95% of the time for me at least, I am not interested in the civilians ships in the list.       And it's difficult to get an 'at a glance' view of your ships in the list with the current formatting of the ship list, in combination with the many civilian ship types once several shipping lines are building.        Suggestions: 1.       remove the civilian ships from the list or 2.       allow the 'Show civilians' checkbox in the window to toggle their inclusion in that tab as well, or 3.       at least separate the two with a space: player ship lists above and civilian ships below in each system, and maybe bold the system name.     

9.       Main system map window - Scenario: I mouse-select a new system in the pulldown that has multiple listed, then once the view changes to the new system, I use the mouse scroll bar to try to zoom into the map to get a closer view of it.       But the pulldown focus hasn't been deselected yet, so I end up scrolling off to a different system in the list instead.        Mouse clicking in the map area doesn't deselect the pulldown focus.       The only way I've found to deselect the focus is to use the Tab key, which may not be obvious to some players.        Perhaps mouse clicking on the general map area should also deselect the focus.     

10.       Shipyards tab - I think it would be useful if clicking on the part of the shipyard line under the 'Assigned class' column would also select the shipyard.       Right now, when I want to select a SY, I am finding my eyes and mouse cursor start under the class column to find the right ship type, and then I try to click it only to remember that it isn't selectable.        Then I move my eyes left across the line to find the right shipyard name to click.     

11.       Economics, left colony list pane - With 'By function' checked, the game does remember when you close a top level category.        But it doesn't remember when you close a system show/hide in any of the views, or when you close a star in the 'Star' view.        This is a bigger issue when there are colonies in many systems, some of which are less important and I want to keep them them from taking up space in the list.     
Title: Re: C# Suggestions
Post by: swarm_sadist on April 18, 2020, 12:29:47 PM
All the command and control components appear in the same line when designing a ship. The only other component I see that appears there is Diplomatic Modules (DIP), but there is no officer that gets attached to diplomatic modules.

My suggestion is: Ambassadors/Diplomats/Emissaries attached to Diplomatic Modules.

Second suggestion: Intelligence module (ISTAR/C3I/ISR) to attach an Intelligence Officer.
Title: Re: C# Suggestions
Post by: SerBeardian on April 18, 2020, 04:26:40 PM
Not sure if mentioned already, probably is, but a stop interrupt when a ship fails to repair something during a maintenance failure would be great.
Title: Re: C# Suggestions
Post by: yourITguy on April 18, 2020, 04:41:27 PM
Love the new AutoMedal system! That being said, I discovered that the conditions are OR instead of AND.  I personally think that AND makes more sense, but for maximum flexibility it would be great if we could toggle it per condition or per medal, so that we can setup something like an "Exceptional Explorer Ribbon" that is awarded when someone discovers 10 stars AND 100 jump points AND a habitable planet, etc.   I realize, that we could just have a separate medal for each of those, but picking out images is hard.  :)
Title: Re: C# Suggestions
Post by: yourITguy on April 18, 2020, 04:52:16 PM
Quote from: SerBeardian link=topic=10640.  msg125414#msg125414 date=1587245200
Not sure if mentioned already, probably is, but a stop interrupt when a ship fails to repair something during a maintenance failure would be great. 

Another good one would be when someone that is manually assigned dies; a naval admin commander or governor, for example.   The event log moves by so fast, which is awesome, it's hard to spot those. 

By the way, I enjoy your videos, SerBeardian!
Title: Re: C# Suggestions
Post by: yourITguy on April 18, 2020, 04:57:57 PM
Okay, one more.  I never can remember which fleet a certain ship is in, so it would be great if the event log would include that information for things like low fuel/MSP warnings.  For example, for low fuel, we currently get something like this:

"Benedict Allen has only 17. 1 percent of its maximum fuel (389 072 litres)"

It would be great if it said this instead:

"Benedict Allen in SRV-01 has only 17. 1 percent of its maximum fuel (389 072 litres)"
Title: Re: C# Suggestions
Post by: macks on April 18, 2020, 05:13:35 PM
Quote from: yourITguy link=topic=10640. msg125420#msg125420 date=1587246087
Love the new AutoMedal system! That being said, I discovered that the conditions are OR instead of AND.   
maybe if there were an option to choose OR/AND because for some medals like Hero of the Soviet States I give medals for the extremely difficult conditions, so researchers, commanders, administrators can all get it for exceptional service, making it AND would make it impossible for a broad medal like that to be awarded.
Title: Re: C# Suggestions
Post by: Father Tim on April 18, 2020, 06:02:00 PM
Okay, one more.  I never can remember which fleet a certain ship is in, so it would be great if the event log would include that information for things like low fuel/MSP warnings.  For example, for low fuel, we currently get something like this:

"Benedict Allen has only 17. 1 percent of its maximum fuel (389 072 litres)"

It would be great if it said this instead:

"Benedict Allen in SRV-01 has only 17. 1 percent of its maximum fuel (389 072 litres)"

If you double-click the event on the event window it should take you to the individual unit details window, with the Benedict Allen selected.
Title: Re: C# Suggestions
Post by: MasonMac on April 18, 2020, 07:38:45 PM
Let us make divisions in the military so I can create a Peace Keeper division alongside the main Military. All RP.
Title: Re: C# Suggestions
Post by: yourITguy on April 18, 2020, 07:59:03 PM
Quote from: macks link=topic=10640. msg125442#msg125442 date=1587248015
Quote from: yourITguy link=topic=10640.  msg125420#msg125420 date=1587246087
Love the new AutoMedal system! That being said, I discovered that the conditions are OR instead of AND.   
maybe if there were an option to choose OR/AND because for some medals like Hero of the Soviet States I give medals for the extremely difficult conditions, so researchers, commanders, administrators can all get it for exceptional service, making it AND would make it impossible for a broad medal like that to be awarded.

Yes, a toggle.  Which is what I originally proposed.
Title: Re: C# Suggestions
Post by: yourITguy on April 18, 2020, 08:06:00 PM
Quote from: Father Tim link=topic=10640. msg125470#msg125470 date=1587250920
Quote from: yourITguy link=topic=10640. msg125435#msg125435 date=1587247077
Okay, one more.   I never can remember which fleet a certain ship is in, so it would be great if the event log would include that information for things like low fuel/MSP warnings.   For example, for low fuel, we currently get something like this:

"Benedict Allen has only 17.  1 percent of its maximum fuel (389 072 litres)"

It would be great if it said this instead:

"Benedict Allen in SRV-01 has only 17.  1 percent of its maximum fuel (389 072 litres)"

If you double-click the event on the event window it should take you to the individual unit details window, with the Benedict Allen selected.

I did not know double-clicking rows in the event window did anything, so thanks for that; however, when I tried double-clicking it just zooms to it in the main display, but I can right click on it from there and pull it up in the fleet organization window, which is nice.  That does help a lot, though if there are more than one there it would only narrow it down.  So, I still think that ideally, the event should include the fleet name.
Title: Re: C# Suggestions
Post by: Father Tim on April 18, 2020, 08:15:17 PM
Let us make divisions in the military so I can create a Peace Keeper division alongside the main Military. All RP.

Sorry, I don't understand what you mean.  Ground forces can be renamed at will and dragged-and-dropped around into whatever organization you desire.  Likewise, new admin commands can be created and named practically anything and have any sorts of ships assigned to them.
Title: Re: C# Suggestions
Post by: Ektor on April 18, 2020, 08:28:34 PM
There should be a clear interrupt when something happens to someone on a non auto-assign position. Say a scientist, administrator or admin comand officer dies or retires, there should be an interrupt telling so, it's too easy to forget about that stuff.
Title: Re: C# Suggestions
Post by: johiah on April 18, 2020, 08:31:11 PM
This has already been suggested most likely but it would be nice if opening a window you already have open just updates the window.  (I'm looking at *you,* galactic map on another screen!)
Title: Re: C# Suggestions
Post by: Bubbaisagod on April 18, 2020, 09:30:59 PM
When you click on a surveyed planet in the system generation and display section, you can see the mineral amount.
I was wondering if it is possible to display the total mineral amount of all the surveyed planets in system
when you click the parent star. 
It would make it easier to determine whether or not the exploitation of a star system is worth it.

Thanks,
Bubbaisagod
Title: Re: C# Suggestions
Post by: Vasious on April 18, 2020, 11:01:02 PM
Going from the bug report where Officers of a higher rank than the rank assigned to a ship or formation not being assigned to an unoccupied command when unassigned themselves as WAI

Any possibility of being able to assign a range of ranks to a Command?

So for instance a Formation of  Platoon could be set as R9 Captain, And R10 Lieutenant using the R9s first then filling the remainder of any Formations requiring a Commander?
Title: Re: C# Suggestions
Post by: Alsadius on April 19, 2020, 08:59:27 AM
Can we get the "Select name" option from ship classes for ground units too? I tend to use generic names for infantry, but I like naming my tanks and installations, and the code is already built.
Title: Re: C# Suggestions
Post by: prunkstation on April 19, 2020, 12:58:18 PM
I propose a new button in the Research tab of the Economics window: when a queued Research Project is selected, the new "Promote" button would swap it with the currently active project for that Project Leader.

Where the button could be: https://i. imgur. com/AFsL0iW. png
Title: Re: C# Suggestions
Post by: Erik L on April 19, 2020, 02:18:19 PM
When running auto turns and you get an interrupt, maybe trigger a game save at that point?
Title: Re: C# Suggestions
Post by: TheBawkHawk on April 19, 2020, 02:38:14 PM
When running auto turns and you get an interrupt, maybe trigger a game save at that point?

I would like this, but perhaps make it a toggled feature.
Title: Re: C# Suggestions
Post by: GreyGoldFish on April 19, 2020, 03:27:06 PM
I would like it if we were able to set a standing order for refuel AND resupply at the same time.  There's a movement order that does that, so why not a standing order?

Also, I don't know if this isn't done for balance reasons, but perhaps overhauling a ship could also mean refueling and resupplying?

Cheers, and thanks for the awesome game.
Title: Re: C# Suggestions
Post by: Pedroig on April 19, 2020, 03:34:56 PM
I would like it if we were able to set a standing order for refuel AND resupply at the same time.  There's a movement order that does that, so why not a standing order?

Also, I don't know if this isn't done for balance reasons, but perhaps overhauling a ship could also mean refueling and resupplying?

Cheers, and thanks for the awesome game.

This, so this.  Not sure why one wouldn't fill the tanks back up after cleaning them out in the first place...
Title: Re: C# Suggestions
Post by: swarm_sadist on April 19, 2020, 04:12:30 PM
Can you put an Anomalies tab in the Galaxy Map screen?
Title: Re: C# Suggestions
Post by: stabliser on April 19, 2020, 07:29:13 PM
Could there be a variable delay delay option built in to time increments so we can simulate VB 6.0

I dont have time to make coffee between 5 day turns anymore.
Title: Re: C# Suggestions
Post by: Hazard on April 19, 2020, 07:35:28 PM
The ability to assign 'keep this much' values to delivery orders. I don't want to empty my tankers when they deliver the bounty of fuel harvesting stations to a colony, I want to keep some fuel for the next trip so I don't have to babysit them.
Title: Re: C# Suggestions
Post by: Migi on April 19, 2020, 08:16:52 PM
The ability to assign 'keep this much' values to delivery orders. I don't want to empty my tankers when they deliver the bounty of fuel harvesting stations to a colony, I want to keep some fuel for the next trip so I don't have to babysit them.
Set the minimum fuel for the tankers in the Class Design window (in the Misc tab).

Suggestion: Minimum fuel should be in % and should have a default value of 10%.
Title: Re: C# Suggestions
Post by: mike2R on April 20, 2020, 03:54:58 AM
I would love to see the conditional and standing orders systems be able to call an Order Template.
Title: Re: C# Suggestions
Post by: trainhighway on April 20, 2020, 05:58:44 AM
I would like to see a conditional order for when a ship had exceeded it deployment time.   Its super easy for a deployment to run long if its a vessel with several years of deployment. 
Title: Re: C# Suggestions
Post by: db48x on April 20, 2020, 07:59:25 AM
I'd like to see buttons for adding and removing fuel from a class design in 1t increments, without having to fiddle with adding and removing fuel tanks to get the right combination.
Title: Re: C# Suggestions
Post by: Shaun Broderick on April 20, 2020, 10:21:29 AM
Not sure if this has been suggested before, or if it would be possible, but I would love to see an option when creating a new game to have just the inner systems of the solar system surveyed.  Maybe out as far as Jupiter, or even out as far as Pluto, rather than having the whole of the system surveyed, as it is if you select the Home System Geo Surveyed checkbox on the Create New Race screen.  This would make a lot of sense to do, as IRL we already know a lot about the planetary bodies in our Solar System, through many years of sending probes, robotic vehicles, and manned missions to the moon, not to mention the planned manned mission to Mars.
Title: Re: C# Suggestions
Post by: davidr on April 20, 2020, 11:42:39 AM
Could the Events window remember the changes to text colours between sessions . At present every time I open the game the text colours have reverted to the default white and i then have to change the colours to my own preferences so I can easily see when I need to take action.

DavidR
Title: Re: C# Suggestions
Post by: Demonius on April 20, 2020, 11:46:21 AM
must be a Problem on your side, mine has consistently kept the selected Colors
Title: Re: C# Suggestions
Post by: UberWaffe on April 20, 2020, 11:51:39 AM
Ship component cost: Adjustments only affect wealth cost

Suggestion:
TN mineral cost of components would only be adjusted (increased / decreased) based on component size (HS).
All other adjustments such as for techs and modifiers, would only affect the complexity (wealth cost / build time).
HS size changes will still affect Wealth cost of component.
Wealth cost would also not be used when calculating the maintenance points / upkeep of a component.
Make the scaling of increased cost more severe (it only affects Wealth) for these adjustments & tech levels.


Reason:
Would give more uses to Wealth (throughout game).
Would allow for better techs to be more TN mineral 'efficient'.
Better immersion (maybe) in terms of better technology feeling less like a game of 'Tetris-for-fitting-more-TN-into-the-same-volume-for-more-space-magic'.
Would help delay late game TN mineral starvation.
Wealth, while reserves and income are limited, is infinite.  And can be scaled up via Technology or more colonies.


Example:
Consider the following two engine designs (under the current system)

Code: [Select]
Ion Engine (Tech 4)
Engine Power 125.00      Fuel Use Per Hour 125.00 Litres
Fuel Consumption per Engine Power Hour 1 Litres
Size 10 HS  (500 tons)      HTK 3
Thermal Signature 125.0      Explosion Chance 10%      Max Explosion Size 31
Cost 62.50      Crew 10
Military Engine
Development Cost 625 RP

Materials Required
Gallicite  62.50

Code: [Select]
Conventional Engine (Tech 1)
Engine Power 10.00      Fuel Use Per Hour 10.00 Litres
Fuel Consumption per Engine Power Hour 1 Litres
Size 10 HS  (500 tons)      HTK 3
Thermal Signature 10.0      Explosion Chance 10%      Max Explosion Size 2
Cost 5.00      Crew 10
Military Engine
Development Cost 50 RP

Materials Required
Gallicite  5.00

Note that the Ion Engine is x8,3 more expensive in terms of Gallicite, since it has x8,3 times the Engine Power.


Currently if I increase the power (from 100% to 150%) of the Ion engine, then the Gallicite cost goes up from (100% to 150%), along with increased fuel cost and such.

Similarly, if I adjust power down, or tech the TN cost changes along with it.

The suggestion would be that the TN cost is based purely on HS of the component (with a base cost of somewhere in the region of the fourth tech in the series for this component. )
And all other adjustments to the engine only adjusts wealth (though more severely. )

So all engine techs would cost 4 Gallicite per HS, from Tech 1 to final tech.
But for wealth while Tech 1 might only cost 1 wealth per HS, tech 6 (Ion) might cost 7,59 Wealth per HS, and tech 15 (Photonic) would cost 291,92 wealth per HS.
I used 1,5 ^ (Level - 1), but that is just as example.  The actual scale can be whatever.  I would make it a database column, so it can be fine tuned as needed.

For things like the "Engine Power" dropdown, the adjustment to the Wealth cost could follow the same formulae as the fuel efficiency calculation (More power means quickly scaling more cost, less power means diminishing cost savings. )

Etc.  etc.
Title: Re: C# Suggestions
Post by: davidr on April 20, 2020, 12:31:34 PM
Demonius,

many thanks

OK - I was only changing the text colour and not the background colour . I have changed both and it looks as if it does indeed remember the changes.

DavidR
Title: Re: C# Suggestions
Post by: Indefatigable on April 20, 2020, 01:05:23 PM
UI:
Ability to hide selected medals.
Let's say your guy has collected 5 different grades of same research medal for life long science career, you could hide the 4 first lower grade medals and only show the highest one.
Title: Re: C# Suggestions
Post by: hopeless4xnoob on April 20, 2020, 01:30:57 PM
Way, way way down the line...some changes for flavor would be appreciated. For instance, some flavor text like, "Are you sure you would like to award these contracts?" when deciding on research projects would be cool.

Of course, not everyone cares about this...but the option to have stuff like this would be cool.

Also, the ability for the game to remember company names that we input when designing components. That may be already implemented or on the road map. I'm not sure.
Title: Re: C# Suggestions
Post by: mike2R on April 20, 2020, 01:40:30 PM
Ability to hide selected medals:
Let's say your guy has collected 5 different grades of same research medal for life long science career, you could hide the 4 first lower grade medals and only show the highest one.

Kind of along the same lines, I'd like to be able to flag medals as not being worthy of an event when awarded - I like long service medals, its a cool feature... but I don't need 99.5% of all citation events to be for them.
Title: Re: C# Suggestions
Post by: mtm84 on April 20, 2020, 03:49:29 PM
Demonius,

many thanks

OK - I was only changing the text colour and not the background colour . I have changed both and it looks as if it does indeed remember the changes.

DavidR

I believe there was or still is a bug where it would save if you changed the background color or both colors, but not when you changed only the text color.
Title: Re: C# Suggestions
Post by: Ektor on April 20, 2020, 08:06:20 PM
Please add an interrupt for maintenance failures on ships.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on April 20, 2020, 08:54:53 PM
Warn if a ship design has engines but no fuel tanks.

Warn if a ship design has Sorium harvesters but no fuel tanks, unless fuel can be directly unloaded to another ship like Salvage Modules can do?

The ability to assign 'keep this much' values to delivery orders. I don't want to empty my tankers when they deliver the bounty of fuel harvesting stations to a colony, I want to keep some fuel for the next trip so I don't have to babysit them.
Set the minimum fuel for the tankers in the Class Design window (in the Misc tab).

Suggestion: Minimum fuel should be in % and should have a default value of 10%.
While I have no objections to a 10% default, my super-tankers typically have around a 0.1% reserve limit so expressing it as a percentage is unworkable.  Liters is the number that I actually want.
Title: Re: C# Suggestions
Post by: Migi on April 20, 2020, 09:06:23 PM
Warn if a ship design has engines but no fuel tanks.

Warn if a ship design has Sorium harvesters but no fuel tanks, unless fuel can be directly unloaded to another ship like Salvage Modules can do?

I support those 2 additions.

Quote
While I have no objections to a 10% default, my super-tankers typically have around a 0.1% reserve limit so expressing it as a percentage is unworkable.  Liters is the number that I actually want.

You could have a radio button to change between percent and absolute.
Trying to have a default value in absolute units would be unworkable, but having a default value of 0 litres causes lots of posts in the bugs thread so something needs to be done, like the cargo shuttles needed for unloading.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on April 20, 2020, 09:40:19 PM
Warn if a ship design has engines but no fuel tanks.

Warn if a ship design has Sorium harvesters but no fuel tanks, unless fuel can be directly unloaded to another ship like Salvage Modules can do?

I support those 2 additions.

Quote
While I have no objections to a 10% default, my super-tankers typically have around a 0.1% reserve limit so expressing it as a percentage is unworkable.  Liters is the number that I actually want.

You could have a radio button to change between percent and absolute.
Trying to have a default value in absolute units would be unworkable, but having a default value of 0 litres causes lots of posts in the bugs thread so something needs to be done, like the cargo shuttles needed for unloading.
Such an option, or just allowing the user to enter a number with a % sign, is acceptable.

There is a popup message when the tanker option is selected and the minimum is set to 10% of current capacity.  You only get 0 if you select 'Tanker' before you add fuel tanks.

I don't want it changing it behind my back when I add or remove tanks if I've specified an absolute number, but using a calculated minimum if a percentage was specified would be acceptable.

Suggestion:  Allow a number with a % in the Minimum Fuel field, in which case it means 'that percentage of the design maximum'.  Default to '10%', but also allow the user to specify an absolute number in liters.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on April 20, 2020, 10:54:33 PM
Class Design screen:
For tankers, add another line to show the range and endurance for minimum fuel amount.
Title: Re: C# Suggestions
Post by: surprise on April 20, 2020, 10:58:32 PM
Class design:

It would be nice if we could see the tech description for the selected component somewhere
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on April 20, 2020, 11:28:13 PM
Economics window:
When not running as SM, if there isn't enough IRP left for a tech then it should reduce the remaining cost by that amount rather than giving the whole tech.  IE if you have 200 IRP left and you Instant a 10000RP tech, it should only apply 200 RP to it instead of the full 10k.
Title: Re: C# Suggestions
Post by: firsal on April 20, 2020, 11:39:04 PM
Just upgraded my entire ground force from conventional to TN tech, and oh boy it was a pain to manually drag and drop elements for 72 ground units. A refit to template feature would be an amazing QoL improvement.

Also, it would be great if we could set minimum and maximum ranks for ships and ground units; the current auto-assignment system removes officers from their commands upon promotion. This would be useful for force structures where multiple ranks can hold the same command; for example, in my game both Majors and Lt. Colonels (lowest 2 ground force commander ranks) can command battalions, since I have a lot of the smaller formations and relatively few of the higher commands.

Even better would be the ability to set the ratio of higher ranks to lower ranks; e.g. 5 majors to 1 colonel, in determining when an officer gets promoted or not. This might be useful for ground force officers, since they usually have a set force structure (5 battalions to a regiment, 4 regiments to a division, so on and so forth).
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on April 21, 2020, 12:56:56 AM
Economics window, Research tab.

Projects in the Research Queue aren't in any particular order.

Suggestion:  Group the queue by scientist, with scientists in the same order as the active project list.
Title: Re: C# Suggestions
Post by: mike2R on April 21, 2020, 03:07:44 AM
Minor QoL suggestion:

I absolutely love the prototype feature - it makes designing ships so much more pleasant.

What would make it an even smoother process would be if any prototypes set to be researched would appear in a temporary research category - ie below Power and Propulsion you get Researchable Prototypes, and in that you get duplicate listings for all researchable prototypes.  Then once you've settled on a design, you could just go there and quickly allocate labs to them.
Title: Re: C# Suggestions
Post by: rbltiz23 on April 21, 2020, 04:21:46 AM
Quote from: mike2R link=topic=10640. msg126411#msg126411 date=1587456464
Minor QoL suggestion:

I absolutely love the prototype feature - it makes designing ships so much more pleasant.

What would make it an even smoother process would be if any prototypes set to be researched would appear in a temporary research category - ie below Power and Propulsion you get Researchable Prototypes, and in that you get duplicate listings for all researchable prototypes.   Then once you've settled on a design, you could just go there and quickly allocate labs to them.

this + maybe a button in the class design window to set for research all prototypes in highlighted design.
Title: Re: C# Suggestions
Post by: mike2R on April 21, 2020, 04:29:09 AM
Quote from: mike2R link=topic=10640. msg126411#msg126411 date=1587456464
Minor QoL suggestion:

I absolutely love the prototype feature - it makes designing ships so much more pleasant.

What would make it an even smoother process would be if any prototypes set to be researched would appear in a temporary research category - ie below Power and Propulsion you get Researchable Prototypes, and in that you get duplicate listings for all researchable prototypes.   Then once you've settled on a design, you could just go there and quickly allocate labs to them.

this + maybe a button in the class design window to set for research all prototypes in highlighted design.

Oh that would be really nice...
Title: Re: C# Suggestions
Post by: TMaekler on April 21, 2020, 05:48:53 AM
Any "jobless" population should try to find a job. They will do that in the service industry. So any planet will see an increase in people working in service industry, if you don't provide them with jobs in your manufacturing of "military assets". But of course you will increase your production over time, which then will lead to a demand for jobs. If there are more people in the service industry than in default Aurora, people will begin to leave their service jobs and join your "asset production" (because you pay way better than those lousy service companies, of course). Once the numbers working in service is down to Aurora default, no more people will come working for you (hey, at some point service is needed and people prefer to keep their living standards - as well as certain amount of people don't like the military industrial complex).

I would love to see more basegame mechanics like this. Maybe there is a benefit in termins of money income if more people work in services, so the moment you try to get them working for you, you will strangle your money income, so you have to begin building financial centers, allow more trade, etc.
Title: Re: C# Suggestions
Post by: Nori on April 21, 2020, 09:16:02 AM
A larger engineering space would be nice now that larger ships are quite viable (compared to VB). A two year maint 25k ton ship requires 20 engineering, so a 100kt ship could need 100. Something like a 250t or 500t engineering space would be nice.
Title: Re: C# Suggestions
Post by: lupin-de-mid on April 21, 2020, 09:25:09 AM
To build first jump drive is necessary to research first level in
Max Jump Squadron Size
Max Squadron Jump Radius
Jump Drive Efficiency.

May be it's better to replace all 3 this with simple "Jump Drive" with total cost as sum of this 3
Title: Re: C# Suggestions
Post by: Pedroig on April 21, 2020, 09:52:10 AM
Or have a Single Ship only Jump Drive be the first one unlocked...
Title: Re: C# Suggestions
Post by: Alsadius on April 21, 2020, 10:56:59 AM
On the Minerals window, I'd love to have an extra column for "Total", so that I can limit my search to, e.g., planets with at least 4 total accessibility, or at least a million units of total minerals.
Title: Re: C# Suggestions
Post by: Disguy on April 21, 2020, 12:14:25 PM
Quality of Life suggestion.  Can we get some more differentiation between non-editable numbers and static? I find it hard to tell what I can modify.
Title: Re: C# Suggestions
Post by: SevenOfCarina on April 21, 2020, 02:39:37 PM
This is a balance suggestion. Many of the early ground combat techs that are extremely necessary (construction, geosurvey, and xenoarcheology equipment, etc.) or needed for thematic reasons (fighter pods, etc.) end up arriving later than they should in conventional start games or in TN campaigns with small populations and/or low research rate multipliers. May I suggest lowering the cost on some of these to 2,000 RP from 5,000 RP?
Title: Re: C# Suggestions
Post by: Father Tim on April 21, 2020, 06:25:26 PM
This is a balance suggestion. Many of the early ground combat techs that are extremely necessary (construction, geosurvey, and xenoarcheology equipment, etc.) or needed for thematic reasons (fighter pods, etc.) end up arriving later than they should in conventional start games or in TN campaigns with small populations and/or low research rate multipliers. May I suggest lowering the cost on some of these to 2,000 RP from 5,000 RP?


How necessary is xenoarchaeology if you can't get off your home world?  (It's possible to start with alien ruins on your homeworld, but only if the SpaceMaster specifically adds them.)

How necessary is geosurvey of you can't get off your home world?  (Homeworlds start fully surveyed.)

How necessary is construction equipment if you have no offworld colonies?  (And if ground units with construction are more efficient than actual construction factories, that's a big reason to increase the tech cost, not decrease it.)

- - - - -

If things are "arriving later than they should" due to the research priorities the player set, I think that's an indication they set the wrong priorities (or have unfortunately-specialized scientists for their desires).
Title: Re: C# Suggestions
Post by: Migi on April 21, 2020, 06:39:29 PM
(or have unfortunately-specialized scientists for their desires).
You can change that now (best feature ever).
Title: Re: C# Suggestions
Post by: Tuli on April 21, 2020, 07:42:17 PM
Sorry with my question, Steve: Will you release a version compatible with 768 vertical high resolution? I have 1366x768 on a notebook screen

Thanks!
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on April 21, 2020, 11:58:01 PM
Minerals window:
Please allow sorting by availability before amount, as that is the more important number.
Please add a 'total' column showing the total amount of minerals and their combined availability.
Title: Re: C# Suggestions
Post by: SevenOfCarina on April 22, 2020, 12:37:46 AM

How necessary is xenoarchaeology if you can't get off your home world?  (It's possible to start with alien ruins on your homeworld, but only if the SpaceMaster specifically adds them.)

How necessary is geosurvey of you can't get off your home world?  (Homeworlds start fully surveyed.)

How necessary is construction equipment if you have no offworld colonies?  (And if ground units with construction are more efficient than actual construction factories, that's a big reason to increase the tech cost, not decrease it.)

- - - - -

If things are "arriving later than they should" due to the research priorities the player set, I think that's an indication they set the wrong priorities (or have unfortunately-specialized scientists for their desires).

With a 60,000 RP start and 20% research speed, I end up with mid-sized extra-solar colonies before Improved Nuclear Thermal Engines. It seems a bit weird to have multiple ruins and survey-able sites in your empire which you can't exploit because the prerequisite techs cost as much as the most expensive technology you've researched so far, but this might be situational.

The more pressing issue is that the ground combat techs appear to be clustered around the 5,000 RP mark, while all of the other categories have a more equitable distribution with several different cost brackets. My ground combat scientists typically sit around twiddling their thumbs until I can afford 5,000 RP techs, at which point they rip through them and then become useless because there's nothing else to research apart from the GFTF construction rate tech and the racial techs.

Construction equipment is a bit too good, I agree. They should be at least twice as expensive as they currently are for their construction capacity. The problem is that construction equipment is necessary for fully fortifying ground units, unless I'm mistaken, and in the early game with superior opponents, that fortification bonus is invaluable.
Title: Re: C# Suggestions
Post by: Migi on April 22, 2020, 02:42:30 AM
Sorry with my question, Steve: Will you release a version compatible with 768 vertical high resolution? I have 1366x768 on a notebook screen

Thanks!
Per Steve
The required resolution is 1440 x 900.

This is unlikely to change.
Title: Re: C# Suggestions
Post by: idefelipe on April 22, 2020, 02:55:01 AM
Hey Steve, is it possible to change the position of the acronym of the ship to be after the name?

Now it is shown:

AMT Ammunition Transport

ANC Anchorage

etc

is it possible to show them in the drop down of the ship design screen in the inverse order?

Ammunition Transport AMT

Anchorage ANC

I say this, because if you write a name in the field to "find" the ship, as the acronym is the first letters and some of them does not match with the name, it is a bit more difficult than as I suggest.

Just a bit of quality of life :D

Thanks!!
Title: Re: C# Suggestions
Post by: mike2R on April 22, 2020, 04:18:31 AM
Piracy.  I know this has been suggested for years, but as far as I remember the reasons against it were more lore based than anything else, so I've tried to think of a mechanic that would fit logically into the game.
                           
Gameplay reasons: Having occasional attacks by low threat enemies in rear areas would give the player a reason to build patrol ships.  These would have a different design philosophy than the battle fleet - with range and endurance being more important than raw combat efficiency - and to me anyway, that sounds fun.  Obviously you'd want an option to turn the system off in the same way as spoiler enemies for people who don't agree.
                           
Lore: Pirate ships should come from ships "scrapped" by civilian shipping companies.  The idea being that a few of these make their way onto the black market, get modified (increase their speed enough to make them useful, and add a few weapons).  They then slip through the jump gate network to somewhere to raid civilian shipping lanes, until the player hunts them down. 
                           
Mechanic:  A percentage of scrapped civilian ships generate a pirate.  Probably the system only starts after some set number ships have been scrapped (so its not a super early game thing).  When one is generated, a system that a) has a planet with a pop over 25 million and b) is connected to the home world via the jump gate network, gets a pirate generated.
                           
Each pirate in a system has a random chance of spawning any time there is a civilian ship in the system.  It appears at some distance from the target ship, and moves to intercept.  Once it intercepts it attacks, destroys the ship, salvages it, then flees outsystem.  Once it has been undetected on any player sensor for some length of time, it despawns.  If the player manages to destroy the ship, the pirate is removed from the game.
                           
The pirate should have enough weaponry to kill a civilian in a reasonable amount if time, and be fast enough to make an interception doable. But you'd want to be able to meet the threat with a small warship with range speced engines - the challenge is meant to be having a ship there at all.
Title: Re: C# Suggestions
Post by: peli082 on April 22, 2020, 06:15:47 AM
This is a small thing.  But I suggest we rename the "Beam Fire Control" to something else like "Weapons Fire Control" or "Turret Fire Control".  The reason for this is I am an avid railgun and dont like the beam part.  So, Thanks for atleast reading this small thing.
Title: Re: C# Suggestions
Post by: Shadow on April 22, 2020, 09:06:04 AM
Medal upgrades?

Maybe I missed this, but some decorations in real life have several levels/classes (i.e. the German Iron Cross (https://en.wikipedia.org/wiki/Iron_Cross#World_War_II), many Soviet orders (https://en.wikipedia.org/wiki/Orders,_decorations,_and_medals_of_the_Soviet_Union), certain service/expertise ribbons), and it's not unusual for the higher variant to supersede the lesser one. So it'd be cool if Aurora could implement that kind of evolution: an officer wouldn't have the first, second and third class of a given award of this type; only the highest (i.e. first class).
Title: Re: C# Suggestions
Post by: db48x on April 22, 2020, 09:19:34 AM
I've been playing around with stabilizing Lagrange points, and it's pretty obvious that the existing pathfinding is a bit limited. It is only used when the user adds orders to the queue, and then the orders are fixed. When a new Lagrange point is added, you have to go back to all your fleets and rebuild their orders from scratch so that it can be used. This is especially annoying when all of your fleets are going in and out of the same central system, because that's where you want the most Lagrange points to save time, and where you'll have to rebuild orders the most frequently.

Worse, Lagrange points move. If you stabilize the Earth Lagrange point as well as the Venus Lagrange point, the Venus Lagrange point will sometimes be the closest and other times the Earth Lagrange point will be closest. A fleet cycling its orders ought to be able to pick the closer of the two each time it cycles, rather than being limited to just one or the other.
Title: Re: C# Suggestions
Post by: Father Tim on April 22, 2020, 10:47:36 AM
Hey Steve, is it possible to change the position of the acronym of the ship to be after the name?

Now it is shown:

AMT Ammunition Transport

ANC Anchorage

etc

is it possible to show them in the drop down of the ship design screen in the inverse order?

Ammunition Transport AMT

Anchorage ANC

I say this, because if you write a name in the field to "find" the ship, as the acronym is the first letters and some of them does not match with the name, it is a bit more difficult than as I suggest.

Just a bit of quality of life :D

Thanks!!


That is a terrible idea.  I don't want my destroyers all over the place because they are the 'A' class, the 'B' class, the 'C' class, etc., and therefore interwoven with literally every other ship I've constructed.

Now, we could both probably be satisfied if 'Hull Type' and 'Ship Name' (or 'Class Name' where appropriate) were independently-searchable fields, so you can find your ships by name and I can keep everything ordered by type like it should be.
Title: Re: C# Suggestions
Post by: Father Tim on April 22, 2020, 11:11:37 AM
Piracy.  I know this has been suggested for years, but as far as I remember the reasons against it were more lore based than anything else, so I've tried to think of a mechanic that would fit logically into the game.

Great idea. . . for after we get a robust civilian economy & commercial shipping.  And preferably after, or along with, a way to use CIWS in offensive mode, or otherwise simulated an 'armed merchantman' concept.

Gameplay reasons: Having occasional attacks by low threat enemies in rear areas would give the player a reason to build patrol ships.  These would have a different design philosophy than the battle fleet - with range and endurance being more important than raw combat efficiency - and to me anyway, that sounds fun.  Obviously you'd want an option to turn the system off in the same way as spoiler enemies for people who don't agree.

Literally the only thing stopping you from building patrol ships and deploying them in your rear areas is you.  If it sounds fun, do it.  If it sounds not-fun due to current mechanics and/or software limitations, advocate for changing those.

Lore: Pirate ships should come from ships "scrapped" by civilian shipping companies.  The idea being that a few of these make their way onto the black market, get modified (increase their speed enough to make them useful, and add a few weapons).  They then slip through the jump gate network to somewhere to raid civilian shipping lanes, until the player hunts them down. 

No, the lore should be whatever I decide it should be to fit my fiction.  The same way I can rename Ion engines to "triple-expansion steam" engines if I so desire.

Not the least because I don't have a jump gate network.

Mechanic:  A percentage of scrapped civilian ships generate a pirate.  Probably the system only starts after some set number ships have been scrapped (so its not a super early game thing).  When one is generated, a system that a) has a planet with a pop over 25 million and b) is connected to the home world via the jump gate network, gets a pirate generated.

What if I want my pirates to be renegade ground troops with boarding shuttles?  Historically (and in modern times), the vast majority of pirates have been (are) shore-based in small craft who swarm over passing ships.

Sure, most people probably want an intense, somewhat-close-to-even ship-to-ship fight with a full-up starship, but an hour after Steve releases the 'Pirate Patch' there will be people on these boards posting "Just use a large cruiser with X sensor and Y missile launchers of Z size and A range to exterminate these pests from outside the range they even know you're there."

- - - - -

I apologize; I seem to have drifted off topic.  There are many, many ways to do the mechanics (What about ships that can turn on their commercial transponder and prevent you from firing at them?  What if they only way to deal with a pirate vessel is to board and capture it?) and that discussion should be left until after we decide what the purpose of adding pirates is, and what we want them to do, and -- for lack of a better term -- where 'the fun' of piracy is.

Each pirate in a system has a random chance of spawning any time there is a civilian ship in the system.  It appears at some distance from the target ship, and moves to intercept.  Once it intercepts it attacks, destroys the ship, salvages it, then flees outsystem.  Once it has been undetected on any player sensor for some length of time, it despawns.  If the player manages to destroy the ship, the pirate is removed from the game.

I would hate that.  I hate the idea of a ship literally disappearing from the game 'until next time' -- it stinks of the worst kind of video game logic.  Once a ships exists, it should continue to exist and Aurora should know where it is at all times.

Not the least because if I want to hunt pirates by finding their base, they darn well need to have a location to be found.  Pirate ships should not get a pass on fuel or maintenance or ordnance.  They should be stealling these things from their victims and running short if I do a good job of risk management.

The pirate should have enough weaponry to kill a civilian in a reasonable amount if time, and be fast enough to make an interception doable. But you'd want to be able to meet the threat with a small warship with range speced engines - the challenge is meant to be having a ship there at all.

The pirate should function by exactly the same rules as every other ship in the game.  If the humans / Alzairians / robots / Gorrthik of the pirate boat can figure out how to make something a functional starship weapon, my empire's highly-paid and pampered scientists can figure out the same thing with sufficient funding.
Title: Re: C# Suggestions
Post by: Father Tim on April 22, 2020, 11:14:39 AM
This is a small thing.  But I suggest we rename the "Beam Fire Control" to something else like "Weapons Fire Control" or "Turret Fire Control".  The reason for this is I am an avid railgun and dont like the beam part.  So, Thanks for atleast reading this small thing.

Yes, it would be nice if terminology shifted from "beam" to "direct fire" but given the extra letters involved, I doubt it would stick.

Oh, and "Turret Fire Control" is definitely out, as most 'beam' weapons can't be turret mounted.
Title: Re: C# Suggestions
Post by: Zincat on April 22, 2020, 11:19:53 AM
I dislike the idea of piracy. Some of my totalitarian empires don't have ANY civilians.
It would have to be yet again another on-off switch.

Besides, as father tim posted, it's really hard to think of pirates building any sort of warship in this setting. There's a reason piracy is basically nonexistant in the modern world, and that's the amount of resources needed to build a warship, and the fact it's not something easy to do "off-radar"

A more realistic approach (but one that is not meant to be automatic, but rather something the player does) is a colony going rogue. That can be more easily done. Just grant independance to a colony, and then SM the relationship so it's negative. Would be easy to do.
Title: Re: C# Suggestions
Post by: Demonides on April 22, 2020, 11:29:43 AM
Minerals window:
Please allow sorting by availability before amount, as that is the more important number.
Please add a 'total' column showing the total amount of minerals and their combined availability.

And starting vaule both 0/0 not 0/0.1 pls :D
Title: Re: C# Suggestions
Post by: Father Tim on April 22, 2020, 11:40:55 AM
Minerals window:
Please allow sorting by availability before amount, as that is the more important number.
Please add a 'total' column showing the total amount of minerals and their combined availability.

And starting vaule both 0/0 not 0/0.1 pls :D

I think this was changed to avoid "divide by zero" errors.  Also, with minimum values of zero-zero, it would logically show every surveyed body ever.
Title: Re: C# Suggestions
Post by: Steve Walmsley on April 22, 2020, 12:38:28 PM
Since create project just assigns the researcher and labs and those projects can be cancelled with no ill effects I do not see much reason to show "are you sure" confirmation popup.
Since there's nothing being possible lost this confirmation is just one additional click to create a project

Agreed. I've removed the popup.
Title: Re: C# Suggestions
Post by: HeroicHan on April 22, 2020, 01:05:42 PM
There's a few features missing from ye olde aurora that I'm missing sorely as a space master.
Galactic Map tickbox for seeing system ID (Or in system generation and display window)
Manual Jump point connecting
Transfer to alien Commanders/Ships
SM Editable Wealth/Fuel (colony)

As it stands if two of my players want to make a trade they would have to trade minerals. And if they wanna buy fuel they need to buy the refinery. And wait.

Edit: Also transfer of racial techs such as engine designs.
It's really cool to be able to be like "we don't want you to give you the ability to make your own military engines with our magneto-plasma tech, but we will license you this magneto-plasma commercial engine for xx dollars"
Title: Re: Restore next research notice in event log
Post by: Steve Walmsley on April 22, 2020, 01:08:01 PM
In the VB6 event log, when a scientist completed a project and there was another queued up for them, the event log told us so. In C#, this is no longer the case. If possible, it would be nice to have it back.

Done.
Title: Re: C# Suggestions
Post by: Steve Walmsley on April 22, 2020, 01:09:25 PM
There could be an indicator of how many officers you have on a given rank. Like say "Lieutenant Commander (28)"

That is already on the Commanders window.
Title: Re: C# Suggestions
Post by: Wieseltrupp on April 22, 2020, 01:16:07 PM
Could you please change the Standing Orders so they only stop time when both orders fail?
Title: Re: C# Suggestions
Post by: mike2R on April 22, 2020, 01:40:06 PM
Piracy.  I know this has been suggested for years, but as far as I remember the reasons against it were more lore based than anything else, so I've tried to think of a mechanic that would fit logically into the game.

Great idea. . . for after we get a robust civilian economy & commercial shipping.  And preferably after, or along with, a way to use CIWS in offensive mode, or otherwise simulated an 'armed merchantman' concept.

Well we're on page 21 of a suggestion thread where it looks like Steve has just started on page 1 - I don't imagine it will be the first thing implemented, even if he happens to love the idea :)

Gameplay reasons: Having occasional attacks by low threat enemies in rear areas would give the player a reason to build patrol ships.  These would have a different design philosophy than the battle fleet - with range and endurance being more important than raw combat efficiency - and to me anyway, that sounds fun.  Obviously you'd want an option to turn the system off in the same way as spoiler enemies for people who don't agree.

Literally the only thing stopping you from building patrol ships and deploying them in your rear areas is you.  If it sounds fun, do it.  If it sounds not-fun due to current mechanics and/or software limitations, advocate for changing those.

For me its just not fun because there is no gameplay reason to do so - I admire (and enjoy reading the fiction from) people who can RP a bit more deeply, or play multi-empire games.  But for me I need the game to provide the framework to do things - I'll RP a bit around that, but basically I need it to be at least a marginally efficient way to play to maintain interest. 

Obviously this is just speaking for what I want - but if you don't ask you don't get :)

Lore: Pirate ships should come from ships "scrapped" by civilian shipping companies.  The idea being that a few of these make their way onto the black market, get modified (increase their speed enough to make them useful, and add a few weapons).  They then slip through the jump gate network to somewhere to raid civilian shipping lanes, until the player hunts them down. 

No, the lore should be whatever I decide it should be to fit my fiction.  The same way I can rename Ion engines to "triple-expansion steam" engines if I so desire.

Not the least because I don't have a jump gate network.

Honestly I'm not attached to the lore - I just want the mechanics of minor threats in the rear areas.  This seemed a marginally believable way to do it, but I'm be extremely happy with something completely different that achieved the same goal.

Mechanic:  A percentage of scrapped civilian ships generate a pirate.  Probably the system only starts after some set number ships have been scrapped (so its not a super early game thing).  When one is generated, a system that a) has a planet with a pop over 25 million and b) is connected to the home world via the jump gate network, gets a pirate generated.

What if I want my pirates to be renegade ground troops with boarding shuttles?  Historically (and in modern times), the vast majority of pirates have been (are) shore-based in small craft who swarm over passing ships.

Sure, most people probably want an intense, somewhat-close-to-even ship-to-ship fight with a full-up starship, but an hour after Steve releases the 'Pirate Patch' there will be people on these boards posting "Just use a large cruiser with X sensor and Y missile launchers of Z size and A range to exterminate these pests from outside the range they even know you're there."

I wasn't actually proposing the threat be remotely difficult to beat - basically something that any military ship can do, even a small one that has sacrificed combat power in exchange for range and endurance. Maybe an obsolete destroyer that has had its engine replaced with a civvy spec one.  Or a big system-wide missile envelope.  Its just an excuse to build military ships that don't belong in the main fleet deathball really.

I apologize; I seem to have drifted off topic.  There are many, many ways to do the mechanics (What about ships that can turn on their commercial transponder and prevent you from firing at them?  What if they only way to deal with a pirate vessel is to board and capture it?) and that discussion should be left until after we decide what the purpose of adding pirates is, and what we want them to do, and -- for lack of a better term -- where 'the fun' of piracy is.

Each pirate in a system has a random chance of spawning any time there is a civilian ship in the system.  It appears at some distance from the target ship, and moves to intercept.  Once it intercepts it attacks, destroys the ship, salvages it, then flees outsystem.  Once it has been undetected on any player sensor for some length of time, it despawns.  If the player manages to destroy the ship, the pirate is removed from the game.

I would hate that.  I hate the idea of a ship literally disappearing from the game 'until next time' -- it stinks of the worst kind of video game logic.  Once a ships exists, it should continue to exist and Aurora should know where it is at all times.

Not the least because if I want to hunt pirates by finding their base, they darn well need to have a location to be found.  Pirate ships should not get a pass on fuel or maintenance or ordnance.  They should be stealling these things from their victims and running short if I do a good job of risk management.

The pirate should have enough weaponry to kill a civilian in a reasonable amount if time, and be fast enough to make an interception doable. But you'd want to be able to meet the threat with a small warship with range speced engines - the challenge is meant to be having a ship there at all.

The pirate should function by exactly the same rules as every other ship in the game.  If the humans / Alzairians / robots / Gorrthik of the pirate boat can figure out how to make something a functional starship weapon, my empire's highly-paid and pampered scientists can figure out the same thing with sufficient funding.

I wasn't thinking anything special in the war of weaponry, just enough to kill a civilian ship quickly enough to require you to have something nearby if you want to respond.  The idea was that the pirates would be in essentially a faster, armed freighter.  Enough to kill a civilian, not enough to worry a small patrol ship.

And you could beat them, as long as you got to them and destroyed them before they despawned, they wouldn't respawn.  If they don't need to spawn in and out, great, but probably harder to implement and still have any point to it.  If you can just send the navy in and clean them out at your convenience, its just another job for the fleet that happens to mess up your shipping lanes in an annoying way.

Basically I just want a reason to build patrol ships.
Title: Re: C# Suggestions
Post by: Alsadius on April 22, 2020, 09:37:36 PM
This is more balance than anything, but the Ground Combat category has no real top end techs. It's mostly clustered around a bunch of 5k-cost techs, plus the construction rate and a couple outliers. I'd like to see some higher-end techs. Here's a few possibilities to get you started:

- The "Capability" techs can have a tree structure, perhaps with some of the higher-end ones giving multiple skills. For example, a skill that takes Mountain and Rift Valley as prereqs, and gives the unit both, at a lower cost than taking both normally.

- A tech line that reduces the cost increase for "Capability" techs.

- A tech line that increases the command ratings of your ground commanders, to let them run bigger forces.

- A tech line that lowers supply costs.

- A "Capability" tech that reduces collateral damage, and maybe one that increases it too.

- Perhaps breaking the weapon/armour ratings away from the other trees and making them separate techs.
Title: Re: C# Suggestions
Post by: Marski on April 22, 2020, 09:43:18 PM
First off, thank you Steve for making such a magnificent work on developing the ground forces, and combat aspect of the game. I can't help but enjoy myself designing ground formations from squad-level all the way up to a division command.

However, building said formations is a very dreadful project.

Could it be possible to introduce "folders" with drop-down for "Formation Templates"? So that you can drag-and-drop formations into formations much the same way as with built ground formations. Even better; Introduce the possibility to build said formations, so that alongside the option of building each squad separately, you can queue the entire formation to be constructed.

(https://i.imgur.com/TfCc4zkl.png) (https://i.imgur.com/TfCc4zk.png)
Title: Re: C# Suggestions
Post by: JacenHan on April 22, 2020, 09:54:02 PM
It would be really nice for auto-assignment to start assigning officers without the skill corresponding to a command, once all other positions have been considered. I often find myself with both unfilled positions (usually secondary ship officers or FAC/fighter commanders) as well as dozens of unassigned officers who didn't have the matching bonus. Since officers are more likely to gain skills while on assignment (IIRC), it makes more sense to me to assign an unskilled officer and make them more likely to get that skill rather than leave the slot empty for years at a time.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on April 22, 2020, 11:29:32 PM
I'm not certain if this should go in Suggestions or Development Discussion since it is regarding the database, but there is potential for some improvement that Steve might want to consider.

Saving the 1.8.0 stock game on my machine takes around 30 seconds.  During this time the journal file is repeatedly created and destroyed with heavy disk activity.  This seems excessive for an 80MB file.

This post explains what is happening.
Quote from: Steve Walmsley link=topic=10096.msg116038#msg116038
I am using a single transaction for each table, so all rows are committed at once.

In an attempt to simulate this behaviour, I ran some tests using sqlite3's command line utility and the stock 1.8.0 database.

Test script:
Code: [Select]
# create test files, stripping query optimization data.
sqlite3 AuroraDB.db '.dump' | grep -v 'sqlite_stat' | grep -v 'ANALYZE' > dump.prime.txt

# insert DELETE FROM commands.
sed -E 's/CREATE TABLE (IF NOT EXISTS)?([^(]+)\(/DELETE FROM\2;\n\0/' < dump.prime.txt > dump.single.txt

# break into multiple transactions.
sed -E 's/(DELETE FROM|CREATE TABLE)/COMMIT;\nBEGIN IMMEDIATE;\n\0/' < dump.single.txt > dump.multi.txt

# prime temporary database
sqlite3 dump.db < dump.prime.txt

# simulate saving a game under various conditions
sqlite3 dump.db 'PRAGMA journal_mode=delete;'
time sqlite3 dump.db < dump.multi.txt
time sqlite3 dump.db < dump.single.txt

sqlite3 dump.db 'PRAGMA journal_mode=wal;'
time sqlite3 dump.db < dump.multi.txt
time sqlite3 dump.db < dump.single.txt

# clean up
rm dump.*

Results:
The closest simulation I could produce completed in 25.742 seconds.  This test was two transactions per table, one to erase followed by another to fill.
Converting to a single transaction for the entire operation reduced this to 3.489 seconds, more than 7x faster than baseline.
Multiple transactions running WAL mode completed in 8.712 seconds, nearly 3x faster than baseline.
Using both optimizations completed in only 2.876 seconds, nearly 9x faster than baseline.

3-4 seconds per save is fast enough that an auto-save option becomes viable, including save-on-exit.

Further testing (by killing Aurora while it was saving) revealed another issue:
Currently, if a save is interrupted (game or computer crash, power failure, etc), then sqlite can't correctly recover the database on the next start.  Some tables will be updated to the new state while others remain in the old state.  Because deletes and inserts are separate transactions, whichever table is being written at the time will be left blank*.  Using a single transaction per save guarantees that either the new state is completely written out or the old state can be automatically restored when Aurora is next started.

*While testing this I managed to delete every ship in the default game, and another time deleted the event history.  I'm not certain what got nuked by the other attempts, only that the database got smaller.  When restarted, Aurora reported no errors in any case.  Sadly, I never managed to accidentally Sol.  :(

Suggestions:
Use a single transaction per save so that auto-saving becomes practical.
-I recommend running all of the DELETEs before running any of the INSERTs to minimize fragmentation.
Auto-save periodically during long execution runs.
Auto-save on exit.

Two minor suggestions:
Set the page size to 4096 for around 10% faster disk performance on modern hardware.  This setting is persistent and requires no code changes.
The database could stand to be VACUUMed once in a while.  This is equivalent to the old VB "compact database" command.

If anyone is putting together a launcher like VB Aurora had, these last two are low hanging fruit.
Title: Re: C# Suggestions
Post by: Gyrfalcon on April 23, 2020, 06:08:36 AM
Would there be any interest if I set up a table with suggestions from this thread so that similar requests can be grouped together under headings? It might make it easier to both see if something that people want has been suggested already or if it's implemented or something that's caught Steve's attention.
Title: Re: C# Suggestions
Post by: Kiks on April 23, 2020, 09:09:13 AM
I would like to suggest a conventional+ start for Players and for player generated NPR's. This start would begin like any other conventional game with a 2 differences.

1. Trans-Newtonian Technology (TNT) is completed.
2. A Legacy Army is generated. This is just like a legacy fleet in RTW or like the troops you started with in VB6, with the option to build it yourself or not.

The early game armor tech is unfortunately useless in my honest opinion. In a conventional game any rational person would take the short time while they wait for TNT to finish to complete the conventional armor techs and then immediately research Duranium armor after TNT is completed so they can make massive weight savings on any new ship they build.
Also, any conventional start requires that you don't have an NPR present in your starting system as you are likely to get creamed if they decided to pick a fight thanks to the new minimum tech requirements for NPR. So, if you want to have a NPR in your starting system you have to start Trans-Newtonian, this means you would never even see those conventional armor techs.

What implementing this would do is actually allow you to use the early game armor tech, and build the "Trans-Newtonian upgrade" to conventional troops that you mentioned and showed everyone in your dev log. How? Because you could have an NPR either on Earth to fight for control of the planet, forcing a scenario where someone has to leave the planet to survive or make a tense but short peace for the new interplanetary empires, or you could have a NPR on the nearby planets to facilitate building a military to protect your borders. What these would do, in short, is allow you to make important early game military and economic decisions that would impact you throughout the mid and even late game.
Title: Re: C# Suggestions
Post by: Bremen on April 23, 2020, 03:52:19 PM
I think with the new system the number of installations in ruins could probably do with a lookover, since as far as I can tell they're always recovered instead of sometimes being lost, and the new ground forces system makes it easy to excavate them fast with pure construction formations.

In my current game I found ruins one jump from Sol with 1993 recoverable installations and recovering 2-4 of them a week along with bountiful tech has been doing crazy things to my economy.
Title: Re: C# Suggestions
Post by: RaidersOfTheVerge on April 23, 2020, 03:57:32 PM
Plot projections

System map
A check box in the contacts section with toggle on/off

The current course of all visible ships moving under their own power (not those orbiting bodies) would be projected into the future based on current course and speed.  The line should be a different color.  At intervals determined by sub-pulse length, with a minimum that makes sense based on the scale of the display, tick marks could appear to indicate the fleet's position at that many intervals in the future.
Title: Re: C# Suggestions
Post by: Father Tim on April 23, 2020, 04:02:10 PM
I would like to suggest a conventional+ start for Players and for player generated NPR's. This start would begin like any other conventional game with a 2 differences.

1. Trans-Newtonian Technology (TNT) is completed.
2. A Legacy Army is generated. This is just like a legacy fleet in RTW or like the troops you started with in VB6, with the option to build it yourself or not.

The early game armor tech is unfortunately useless in my honest opinion. In a conventional game any rational person would take the short time while they wait for TNT to finish to complete the conventional armor techs and then immediately research Duranium armor after TNT is completed so they can make massive weight savings on any new ship they build.
Also, any conventional start requires that you don't have an NPR present in your starting system as you are likely to get creamed if they decided to pick a fight thanks to the new minimum tech requirements for NPR. So, if you want to have a NPR in your starting system you have to start Trans-Newtonian, this means you would never even see those conventional armor techs.

What implementing this would do is actually allow you to use the early game armor tech, and build the "Trans-Newtonian upgrade" to conventional troops that you mentioned and showed everyone in your dev log. How? Because you could have an NPR either on Earth to fight for control of the planet, forcing a scenario where someone has to leave the planet to survive or make a tense but short peace for the new interplanetary empires, or you could have a NPR on the nearby planets to facilitate building a military to protect your borders. What these would do, in short, is allow you to make important early game military and economic decisions that would impact you throughout the mid and even late game.

Well, we specifically asked to have the new levels of armour below duranium added, so I for one would be pretty pissed if they were immediately taken away again.

Given that you can immediately award your empire Trans-Newtonian Tech with SpaceMaster, what's left of your suggestion is 'pre-made ground forces for conventional start games' which is functionally identical to the "ICBM bases" we used to get, so I suspect they are already on the list of "cosmetic and QoL features omitted from v1.0 so it would come out in April instead of August."  I look forward to them.
Title: Re: C# Suggestions
Post by: Kiks on April 23, 2020, 04:54:04 PM
I would like to suggest a conventional+ start for Players and for player generated NPR's. This start would begin like any other conventional game with a 2 differences.

1. Trans-Newtonian Technology (TNT) is completed.
2. A Legacy Army is generated. This is just like a legacy fleet in RTW or like the troops you started with in VB6, with the option to build it yourself or not.

The early game armor tech is unfortunately useless in my honest opinion. In a conventional game any rational person would take the short time while they wait for TNT to finish to complete the conventional armor techs and then immediately research Duranium armor after TNT is completed so they can make massive weight savings on any new ship they build.
Also, any conventional start requires that you don't have an NPR present in your starting system as you are likely to get creamed if they decided to pick a fight thanks to the new minimum tech requirements for NPR. So, if you want to have a NPR in your starting system you have to start Trans-Newtonian, this means you would never even see those conventional armor techs.

What implementing this would do is actually allow you to use the early game armor tech, and build the "Trans-Newtonian upgrade" to conventional troops that you mentioned and showed everyone in your dev log. How? Because you could have an NPR either on Earth to fight for control of the planet, forcing a scenario where someone has to leave the planet to survive or make a tense but short peace for the new interplanetary empires, or you could have a NPR on the nearby planets to facilitate building a military to protect your borders. What these would do, in short, is allow you to make important early game military and economic decisions that would impact you throughout the mid and even late game.

Well, we specifically asked to have the new levels of armour below duranium added, so I for one would be pretty pissed if they were immediately taken away again.

Given that you can immediately award your empire Trans-Newtonian Tech with SpaceMaster, what's left of your suggestion is 'pre-made ground forces for conventional start games' which is functionally identical to the "ICBM bases" we used to get, so I suspect they are already on the list of "cosmetic and QoL features omitted from v1.0 so it would come out in April instead of August."  I look forward to them.

I'm not advocating for a removal of the conventional armor tech, I just want a situation in which it would actually become applicable. As I said, I find no instance in the current game where it is useful, and it seems better just to tech past it before you even build your first ship. I would like to have a situation where actually equipping your army, air force, or navy with the stuff would make sense.

As for the legacy army being like ICBM bases, I mean yes I can see that. And if Steve is looking at adding them later then that would be awesome. But I would like some possible modability with the conventional forces.
Title: Re: C# Suggestions
Post by: Father Tim on April 23, 2020, 05:06:45 PM
As for the legacy army being like ICBM bases, I mean yes I can see that. And if Steve is looking at adding them later then that would be awesome. But I would like some possible modability with the conventional forces.

Building them yourself would be the "moddability" of conventional forces.

- - - - -

Have you tried creating a fully Trans-Newtonian empire with 0 reaserch points to see if it's closer to what you desire?
Title: Re: C# Suggestions
Post by: Scud on April 23, 2020, 05:22:54 PM
As for the legacy army being like ICBM bases, I mean yes I can see that. And if Steve is looking at adding them later then that would be awesome. But I would like some possible modability with the conventional forces.

Building them yourself would be the "moddability" of conventional forces.

- - - - -

Have you tried creating a fully Trans-Newtonian empire with 0 reaserch points to see if it's closer to what you desire?

May I also suggest perhaps playing at a lower research speed. Some people much enjoy the slower pace enabling better usage of early tech.
Title: Re: C# Suggestions
Post by: surprise on April 23, 2020, 10:45:53 PM
It would be nice if you could insert a tech at the head of the scientist's research queue. I usually have all my labs split between scientists in most/all of the fields, and when I want to research a designed tech, I have to cancel and rebuild the whole queue or add the designed tech to the queue and bump it up until it's next in line.

I'd like to be able to say "work on this first, then go back to that other stuff"
Title: Re: C# Suggestions
Post by: Silverkeeper on April 24, 2020, 07:19:04 AM
Naval Organization. Detach and Delete buttons are too close together. It should ask if you are sure before deleting.
There goes my new cargo ship.
Title: Re: C# Suggestions
Post by: TMaekler on April 24, 2020, 09:30:30 AM
(or have unfortunately-specialized scientists for their desires).
You can change that now (best feature ever).
Where can you do that?
Title: Re: C# Suggestions
Post by: TMaekler on April 24, 2020, 09:33:24 AM
Haven't found an option to SM Add Maintenance to a ship. If there is none, could we have such a SM-button in the game?
Title: Re: C# Suggestions
Post by: Alsadius on April 24, 2020, 09:44:14 AM
(or have unfortunately-specialized scientists for their desires).
You can change that now (best feature ever).
Where can you do that?

Commanders window. Click the scientist, "Change Field" bottom-middle.
Title: Re: C# Suggestions
Post by: Kiks on April 24, 2020, 10:27:25 AM
As for the legacy army being like ICBM bases, I mean yes I can see that. And if Steve is looking at adding them later then that would be awesome. But I would like some possible modability with the conventional forces.

Building them yourself would be the "moddability" of conventional forces.

- - - - -

Have you tried creating a fully Trans-Newtonian empire with 0 reaserch points to see if it's closer to what you desire?

So when I'm talking about the "moddability" of the legacy army I am talking about building it yourself. Rather then having a conventional start similar to VB6 where you get x amount of ICBM bases and x amount conventional forces and they will always be the same.

As for the trans-newtonian empire with 0 research, it doesn't fill that niche that I want. You already start with the conventional armor researched, and, like I said before, if you want to fight an NPR for control of the starting system/planet you can't start with no research as they will mop the floor with you because of their 100,000 research point minimum. It is also impossible to have a conventional NPR.

All together, if I really think about it, my suggestion would be fulfilled if player generated NPR's could start as conventional like the player, and if there was a legacy army as discussed before. There wouldn't need to be a whole other game start option if those two things could happen (the latter of which is already possibly coming into the game later).
Title: Re: C# Suggestions
Post by: Kiks on April 24, 2020, 10:37:01 AM
As for the legacy army being like ICBM bases, I mean yes I can see that. And if Steve is looking at adding them later then that would be awesome. But I would like some possible modability with the conventional forces.

Building them yourself would be the "moddability" of conventional forces.

- - - - -

Have you tried creating a fully Trans-Newtonian empire with 0 reaserch points to see if it's closer to what you desire?

May I also suggest perhaps playing at a lower research speed. Some people much enjoy the slower pace enabling better usage of early tech.

I don't think my issue lies with research speed, I believe that it stems from a lack of external issues that force me to stop and address them with the tech I have.
Though I do think a slower research speed would be interesting to try in the future. A slow research speed plus a starting system issue (sun cooling/heating) would make me want to use those early techs.
The only issue is it doesn't scratch that itch of low tech early fight for your starting system/planet as all NPR's start with 100,000 research points minimum.
Title: Re: C# Suggestions
Post by: Eretzu on April 24, 2020, 12:50:43 PM
It would be nice to have "shore leave" order. Basically it should just make the ship stay in orbit until the deployment clock is zero.

This is kinda not needed as you could just put ship to overhaul and then it will stay long enough to reset deployment as well, but could be mb nice for RP.

Not sure if it would just clutter the order list for no real benefit tho :/
Title: Re: C# Suggestions
Post by: Barkhorn on April 24, 2020, 07:12:25 PM
Could we have a way to sell ships and perhaps ground equipment on the civilian market?  In real life, nations have often sold off surplus military hardware.  Many small commercial vessels even today were originally auxiliary military ships in WW2.  I think the reverse should also be possible.  Many navies have bought civilian ships to fill auxiliary roles.
Title: Re: C# Suggestions
Post by: Father Tim on April 24, 2020, 07:54:07 PM
Could we have a way to sell ships and perhaps ground equipment on the civilian market?  In real life, nations have often sold off surplus military hardware.  Many small commercial vessels even today were originally auxiliary military ships in WW2.  I think the reverse should also be possible.  Many navies have bought civilian ships to fill auxiliary roles.

Delete the ship; SM add the wealth (and, if you feel it appropriate, minerals) you decide was the price.

For Aurora to dictate the price at which this happens, or whether or not there is a buyer, or to limit the frequency at which I can do this is to interfere with my fiction.  And I don't even know what that fiction is yet, but I'm pretty sure it's going to vary from game to game.

- - - - -

I would much rather see a way to sell (trade) to the AI.  I can already perform trade between two empires I control, but I can't buy up all my neighbour's Corbomite.  I can SM add all I want in exchange for my wealth, but the AI-run NPR doesn't lose any.
Title: Re: C# Suggestions
Post by: db48x on April 24, 2020, 10:23:50 PM
I'm not certain if this should go in Suggestions or Development Discussion since it is regarding the database, but there is potential for some improvement that Steve might want to consider.

Saving the 1.8.0 stock game on my machine takes around 30 seconds.  During this time the journal file is repeatedly created and destroyed with heavy disk activity.  This seems excessive for an 80MB file.

This post explains what is happening.
Quote from: Steve Walmsley link=topic=10096.msg116038#msg116038
I am using a single transaction for each table, so all rows are committed at once.

In an attempt to simulate this behaviour, I ran some tests using sqlite3's command line utility and the stock 1.8.0 database.

Test script:
Code: [Select]
# create test files, stripping query optimization data.
sqlite3 AuroraDB.db '.dump' | grep -v 'sqlite_stat' | grep -v 'ANALYZE' > dump.prime.txt

# insert DELETE FROM commands.
sed -E 's/CREATE TABLE (IF NOT EXISTS)?([^(]+)\(/DELETE FROM\2;\n\0/' < dump.prime.txt > dump.single.txt

# break into multiple transactions.
sed -E 's/(DELETE FROM|CREATE TABLE)/COMMIT;\nBEGIN IMMEDIATE;\n\0/' < dump.single.txt > dump.multi.txt

# prime temporary database
sqlite3 dump.db < dump.prime.txt

# simulate saving a game under various conditions
sqlite3 dump.db 'PRAGMA journal_mode=delete;'
time sqlite3 dump.db < dump.multi.txt
time sqlite3 dump.db < dump.single.txt

sqlite3 dump.db 'PRAGMA journal_mode=wal;'
time sqlite3 dump.db < dump.multi.txt
time sqlite3 dump.db < dump.single.txt

# clean up
rm dump.*

Results:
The closest simulation I could produce completed in 25.742 seconds.  This test was two transactions per table, one to erase followed by another to fill.
Converting to a single transaction for the entire operation reduced this to 3.489 seconds, more than 7x faster than baseline.
Multiple transactions running WAL mode completed in 8.712 seconds, nearly 3x faster than baseline.
Using both optimizations completed in only 2.876 seconds, nearly 9x faster than baseline.

3-4 seconds per save is fast enough that an auto-save option becomes viable, including save-on-exit.

Further testing (by killing Aurora while it was saving) revealed another issue:
Currently, if a save is interrupted (game or computer crash, power failure, etc), then sqlite can't correctly recover the database on the next start.  Some tables will be updated to the new state while others remain in the old state.  Because deletes and inserts are separate transactions, whichever table is being written at the time will be left blank*.  Using a single transaction per save guarantees that either the new state is completely written out or the old state can be automatically restored when Aurora is next started.

*While testing this I managed to delete every ship in the default game, and another time deleted the event history.  I'm not certain what got nuked by the other attempts, only that the database got smaller.  When restarted, Aurora reported no errors in any case.  Sadly, I never managed to accidentally Sol.  :(

Suggestions:
Use a single transaction per save so that auto-saving becomes practical.
-I recommend running all of the DELETEs before running any of the INSERTs to minimize fragmentation.
Auto-save periodically during long execution runs.
Auto-save on exit.

Two minor suggestions:
Set the page size to 4096 for around 10% faster disk performance on modern hardware.  This setting is persistent and requires no code changes.
The database could stand to be VACUUMed once in a while.  This is equivalent to the old VB "compact database" command.

If anyone is putting together a launcher like VB Aurora had, these last two are low hanging fruit.

There's an even easier way to save the in-memory database to an on-disk database. Just run 'VACUUM INTO filename', where the filename is the file you want to save into. It deletes the target file, so if you should first rename the exisiting file so that it becomes the backup. https://sqlite.org/lang_vacuum.html

Additionally, you should have access to the online backup API, which can also be used to save an in-memory database to a file. It doesn't do any vaccuming, so it's even faster. https://sqlite.org/backup.html

Edit: I almost forgot to mention, but the backup API can be run incrementally, meaning that autosaves can be really fast by doing incremental backups.
Title: Re: C# Suggestions
Post by: HeroicHan on April 24, 2020, 10:28:04 PM
Could we have a way to sell ships and perhaps ground equipment on the civilian market?  In real life, nations have often sold off surplus military hardware.  Many small commercial vessels even today were originally auxiliary military ships in WW2.  I think the reverse should also be possible.  Many navies have bought civilian ships to fill auxiliary roles.

Delete the ship; SM add the wealth (and, if you feel it appropriate, minerals) you decide was the price.

For Aurora to dictate the price at which this happens, or whether or not there is a buyer, or to limit the frequency at which I can do this is to interfere with my fiction.  And I don't even know what that fiction is yet, but I'm pretty sure it's going to vary from game to game.

- - - - -

I would much rather see a way to sell (trade) to the AI.  I can already perform trade between two empires I control, but I can't buy up all my neighbour's Corbomite.  I can SM add all I want in exchange for my wealth, but the AI-run NPR doesn't lose any.

And how do you SM the price?
Title: Re: C# Suggestions
Post by: Father Tim on April 24, 2020, 11:24:14 PM
And how do you SM the price?


Space Master on, Colony screen, commercial shipping tab or wealth tab or mining tab to see the buttons or stockpiles to which you want to add the "price".

- - - - -

If you mean 'how do I set the price for a particular ship' -- I let my fiction do it for me.  Sometimes I even roll dice.
Title: Re: C# Suggestions
Post by: skoormit on April 25, 2020, 07:17:12 AM
And how do you SM the price?


Space Master on, Colony screen, commercial shipping tab or wealth tab or mining tab to see the buttons or stockpiles to which you want to add the "price".

- - - - -

If you mean 'how do I set the price for a particular ship' -- I let my fiction do it for me.  Sometimes I even roll dice.

I'm not following.
I see SM buttons on the Civilian Economy tab to add/edit numbers of installations.
But I don't see anything similar on the Mining tab or the Wealth tab.
Title: Re: C# Suggestions
Post by: swarm_sadist on April 25, 2020, 07:49:13 AM
Put the advanced time buttons in the event screen, or have a toggle to keep the events screen in front of the tactical map.
Title: Re: C# Suggestions
Post by: SpaceMarine on April 25, 2020, 07:51:16 AM
this will be much less needed because events on the tactical map is coming in 1.9
Title: Re: C# Suggestions
Post by: Alsadius on April 25, 2020, 10:34:36 AM
Moving ground forces in a transport ship is annoying. A couple QoL requests - either:

1) Add a "Move including Subordinates" button that allows me to move a whole force structure, not just one division HQ at a time.

and/or

2) Let us multi-select in the orders window. I can click multiple ground units, but I can't actually order them all to be picked up at once.
Title: Re: C# Suggestions
Post by: Black on April 25, 2020, 11:03:17 AM
Moving ground forces in a transport ship is annoying. A couple QoL requests - either:

1) Add a "Move including Subordinates" button that allows me to move a whole force structure, not just one division HQ at a time.

It seem that this is possible, I am using Load All Sub-Units check box and my troop transport will load whole formation.
Title: Re: C# Suggestions
Post by: Father Tim on April 25, 2020, 11:22:36 AM
I'm not following.
I see SM buttons on the Civilian Economy tab to add/edit numbers of installations.
But I don't see anything similar on the Mining tab or the Wealth tab.


In SpaceMaster, untick "double click sets reserve amount" box.  Double-clicking now allows direct editing of colony stockpile.
Title: Re: C# Suggestions
Post by: RagnarVaren on April 25, 2020, 01:45:19 PM
Some suggestions for the civilians shipping orders mechanic.

1. Allow the player to specify supply and demand of minerals. This should preferably be in multiple of 1 thousand minerals to make it easier to set up.
2. Allow supply orders for installations that don't exist yet. When checking for supply to assign to a civilian check if that installation exists and then reserve it instead of failing to pickup when it doesn't exist. Current functionality makes it necessary to constantly update the supply when new installations are built for example when building terraforming installations at Earth would be nice to simply set supply and let the civilians check if it exists yet.
3. Allow civilian shipping of maintenance supplies and fuel (with the required new civilian designs). This will make it easier to manage outposts.
Title: Re: C# Suggestions
Post by: Father Tim on April 25, 2020, 02:06:08 PM
Some suggestions for the civilians shipping orders mechanic.

1. Allow the player to specify supply and demand of minerals. This should preferably be in multiple of 1 thousand minerals to make it easier to set up.
2. Allow supply orders for installations that don't exist yet. When checking for supply to assign to a civilian check if that installation exists and then reserve it instead of failing to pickup when it doesn't exist. Current functionality makes it necessary to constantly update the supply when new installations are built for example when building terraforming installations at Earth would be nice to simply set supply and let the civilians check if it exists yet.
3. Allow civilian shipping of maintenance supplies and fuel (with the required new civilian designs). This will make it easier to manage outposts.


Again, these largely amount to "remove any remaining need for government-owned shipping" and I, for one, would like to see shipping lines move in other direction -- that of becoming less useful.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on April 25, 2020, 02:26:10 PM
Some suggestions for the civilians shipping orders mechanic.

1. Allow the player to specify supply and demand of minerals. This should preferably be in multiple of 1 thousand minerals to make it easier to set up.
2. Allow supply orders for installations that don't exist yet. When checking for supply to assign to a civilian check if that installation exists and then reserve it instead of failing to pickup when it doesn't exist. Current functionality makes it necessary to constantly update the supply when new installations are built for example when building terraforming installations at Earth would be nice to simply set supply and let the civilians check if it exists yet.
3. Allow civilian shipping of maintenance supplies and fuel (with the required new civilian designs). This will make it easier to manage outposts.


Again, these largely amount to "remove any remaining need for government-owned shipping" and I, for one, would like to see shipping lines move in other direction -- that of becoming less useful.

I don't see why we could eventually get both.

First of the civilian economy should actually consume Trans-Newtonian elements... either by mining them or buying them from the government. Lack of minerals could then have reduced production capacities and the like. Now.. this could be solved through the civilian trade system in some form.

Now... civilian shipping lines should require both fuel and minerals to operate, like government ships. There should be no free rides anywhere... fuel in particular needs to be created even for the civilian fleets.

You as the head of the government could then dictate in what field the civilians are allowed to operate... so you could ban civilians from mining at all, build fuel harvesters or just ban certain systems. Although there can be consequences by doing that... if you restrict them too much their income might go down so they can't maintain their fleets properly.

Now... operating government owned commercial ships will still be highly useful even if there is a civilian fleet doing some of the work. You as a player also can restrict the civilian fleet where it can operate which will impact their economy and the amount of ship they can maintain and build.

I also think that both Commercial and Civilian ship should cost an amount of Wealth each year in a maintenance fee... it could be something like 1/20 the build cost of the ship in a yearly cost. This would represent crew salaries and general maintenance of the ships.
Title: Re: C# Suggestions
Post by: Barkhorn on April 25, 2020, 04:12:38 PM
Some suggestions for the civilians shipping orders mechanic.

1. Allow the player to specify supply and demand of minerals. This should preferably be in multiple of 1 thousand minerals to make it easier to set up.
2. Allow supply orders for installations that don't exist yet. When checking for supply to assign to a civilian check if that installation exists and then reserve it instead of failing to pickup when it doesn't exist. Current functionality makes it necessary to constantly update the supply when new installations are built for example when building terraforming installations at Earth would be nice to simply set supply and let the civilians check if it exists yet.
3. Allow civilian shipping of maintenance supplies and fuel (with the required new civilian designs). This will make it easier to manage outposts.


Again, these largely amount to "remove any remaining need for government-owned shipping" and I, for one, would like to see shipping lines move in other direction -- that of becoming less useful.
That's not very realistic though.  Governments mostly do not own cargo ships.  They contract out most of their needs.
Title: Re: C# Suggestions
Post by: Black on April 25, 2020, 04:37:47 PM
Would it be possible to add button to exclude CMCs from list of available Administrator Assignments? I currently have over 30 CMCs active and it kind of clutters the list.
Title: Re: C# Suggestions
Post by: JuergenSchT on April 25, 2020, 04:48:21 PM
I'm not sure that would be desirable.  CMCs will use the Mining bonus of your administrators (planetary and sector), therefore giving you more minerals for less expenditure if you are purchasing them.
But if you are letting the minerals go to the civilian sector. . .  if you give the CMC an administrator with no Mining bonus, then you will extend the duration time of the mineral deposits. . .  and increase your earnings.

CMCs are also useful for training administrators without creating as many empty colonies on asteroid belts.
Title: Re: C# Suggestions
Post by: Black on April 25, 2020, 05:12:11 PM
I'm not sure that would be desirable.  CMCs will use the Mining bonus of your administrators (planetary and sector), therefore giving you more minerals for less expenditure if you are purchasing them.
But if you are letting the minerals go to the civilian sector. . .  if you give the CMC an administrator with no Mining bonus, then you will extend the duration time of the mineral deposits. . .  and increase your earnings.

CMCs are also useful for training administrators without creating as many empty colonies on asteroid belts.

Thats why I want it to be button same as Eligible Only and Available Only, you can decide yourself if you want to see them.
Title: Re: C# Suggestions
Post by: JuergenSchT on April 25, 2020, 07:09:34 PM
Agreed.
Having an option to filter all unassigned (or assigned) leaders would be nice.

Incidentally, what happened to the production overview window? And the option to do a custom-length increment?
Title: Re: C# Suggestions
Post by: JacenHan on April 25, 2020, 07:14:04 PM
On that note, a visual indication of what officers are assigned, such as an (A) after their name and/or a colored name would be great as well.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on April 25, 2020, 07:25:37 PM
On the tactical map we can hide Planets, Dwarf Planets, Moons, and Asteroids, but there is no option to hide Comets.  I seem to recall this being available in VB.  Please add this option to C#.
Title: Re: C# Suggestions
Post by: Father Tim on April 25, 2020, 09:59:56 PM
That's not very realistic though.  Governments mostly do not own cargo ships.  They contract out most of their needs.


See, that's where you're wrong.  In the Hyborean Empire, only governments own cargo ships.  In the Hexapod Omnivoracity, the hive mind controls everything.  In the JG17i+Violet Connexion, the ships are the citizens and they conduct themselves in an harmonious manner.

In other words, what is "realistic" is determined by the fiction, not the other way around.
Title: Re: C# Suggestions
Post by: Pedroig on April 26, 2020, 07:07:52 AM
That's not very realistic though.  Governments mostly do not own cargo ships.  They contract out most of their needs.


See, that's where you're wrong.  In the Hyborean Empire, only governments own cargo ships.  In the Hexapod Omnivoracity, the hive mind controls everything.  In the JG17i+Violet Connexion, the ships are the citizens and they conduct themselves in an harmonious manner.

In other words, what is "realistic" is determined by the fiction, not the other way around.

Seems like there is a checkbox to not allow civilian shipping at all to provide for those scenarios.
Title: Re: C# Suggestions
Post by: davidr on April 26, 2020, 11:34:53 AM
Medals

In the medal screen , I only see the facility to show and award ribbons , rather than medals ( as shown in Steve's post of June 23rd 2019 - C# Changes list ) . The screen has changed since this post but could we have the ability to award and show actual medals rather than just ribbons - ribbons don't mean as much as whern seeing a medal.

DavidR
Title: Re: C# Suggestions
Post by: Pedroig on April 26, 2020, 11:55:36 AM
Medals

In the medal screen , I only see the facility to show and award ribbons , rather than medals ( as shown in Steve's post of June 23rd 2019 - C# Changes list ) . The screen has changed since this post but could we have the ability to award and show actual medals rather than just ribbons - ribbons don't mean as much as whern seeing a medal.

DavidR

Medals are now ribbons.  And in the military EVERY medal has a ribbon which is associated with it, a Purple Heart is an award, it is displayed as a medal on class A's and a ribbon on class B's, even the CMH has a ribbon.  This just cleans up the UI and makes it a standardized "ribbon board" for display. Priority levels will determine placement.
Title: Re: C# Suggestions
Post by: swarm_sadist on April 26, 2020, 12:42:38 PM
Separate the research modifier at game setup into "Research" and "Racial Tech". I want to make researching a tech like Ion Engines in my next game expensive, but I want designing individual ion engines be rather cheap to develop.
Title: Another Sort Function in Economics -> Research
Post by: Sara on April 26, 2020, 02:07:37 PM
I wish i could sort  the research that is beeing done as "per field" - with the same Sorting as in the research drop done.

Reason:
- it would keep better track of how many projects you are currently running in a specific field (and queued as well)
- makes finding the one you are looking for easier to spot

Sincerely
Title: Re: Another Sort Function in Economics -> Research
Post by: QuakeIV on April 26, 2020, 03:51:28 PM
I wish i could sort  the research that is beeing done as "per field" - with the same Sorting as in the research drop done.

Reason:
- it would keep better track of how many projects you are currently running in a specific field (and queued as well)
- makes finding the one you are looking for easier to spot

Sincerely

I currently have exactly 45 separate projects and would like this as well.
Title: Re: C# Suggestions
Post by: Doren on April 27, 2020, 01:04:52 AM
"Upgrade" button to ground forces formation templates which would auto create a unit research of currently selected unit class but with current level of racial weapon and armour tech
Title: Re: C# Suggestions
Post by: SevenOfCarina on April 27, 2020, 01:22:23 AM
It would be nice if missile warheads gained efficiency with increasing size, like reactors and shields. It would mean larger missiles would actually do useful damage as barely 10-20% of a salvo actually makes it past missile defences, and it's still always better to use more numerous smaller missiles.
Title: Re: C# Suggestions
Post by: EvadingHostileFleets on April 27, 2020, 01:29:46 AM
It feels weird when your industry increases its productivity, your speeds allow to travel to the other side of galaxy in matter of months, you ferry around millions of popsicle colonists, yet your lifepods have the same endurance as in conventional era.  Maybe  there should be some tech line concerning lifepod endurance, starting from 1 day, or as alternative option it could be tied in some way to reactor technology level.
Title: Re: C# Suggestions
Post by: mike2R on April 27, 2020, 02:27:52 AM
I think the overhaul order should also function as orders to refuel and resupply a fleet, and maybe rearm too.  Assuming the relevant facilities are available.

This would make automation so much easier, without needing any other new features (such as multiple orders from one conditional trigger).  You could set up eg a geosurvey jump ship to. 1) Survey next 5 bodies, 2) move to a system that needs geosurvey and Conditional1) if 40% fuel then overhaul.  And if you designed the ship so its maintenance requirements and fuel capacity were suitable, it should carry on surveying systems as they were discovered indefinitely.

It would also save clicks generally - I don't think I've ever issued an overhaul order where I didn't also order a resupply and refuel.  I can imagine situations where you wouldn't want them combined, but they are so much rarer that I think it makes more sense for the player to handle those as they come up.
Title: Re: C# Suggestions
Post by: TMaekler on April 27, 2020, 08:45:26 AM
It feels weird when your industry increases its productivity, your speeds allow to travel to the other side of galaxy in matter of months, you ferry around millions of popsicle colonists, yet your lifepods have the same endurance as in conventional era.  Maybe  there should be some tech line concerning lifepod endurance, starting from 1 day, or as alternative option it could be tied in some way to reactor technology level.
I think we had discussed that during development of C# at some point. Some kind of system where you can input "days of supplies for life pods" during ship design (similar to deployment time) would be nice. That way it depends on your philosophy and amound of ship size you want to use for life pods. Heck, you even can make it dependent upon your life pod rescue ships. If you planned for a decentral rescue network and can reach anything within 30 days, make your life pods last 35 days; or if you have one central rescue hub that would need 120 days to the outlying systems, let your life pods last 125 days... . It suddenly becomes a game decision how to play your empire.
Title: Re: C# Suggestions
Post by: TMaekler on April 27, 2020, 11:24:04 AM
The amount of wealth added (as in the economics window) could also be shown in the general game window next to the wealth.
Title: Re: C# Suggestions
Post by: swarm_sadist on April 27, 2020, 11:38:29 AM
In the industrial screen, have a toggle between number of assigned factories, and date of completion similar to the research screen.

A tab in the Ground forces screen to produce ground units.

A button in the research screen to design tech.

In the contact tab of the galaxy may, have clicking a contact highlight and select the system the contact is in. Double click have the tactical screen switch to that system, and bring the tactical view to the top.

A search feature in the galaxy map.

Sub-fleets above Task Group level.
Title: Re: C# Suggestions
Post by: TMaekler on April 27, 2020, 11:42:18 AM
A production queue for shipyards, identical to construction factories, so that you can do a longer production queue...
Title: New Terrain Types (Urban, Toxic, Wasteland, Planet-Cracked)
Post by: SpaceMarine on April 28, 2020, 03:31:55 AM
My suggestion would be to add terrain types that are less natural but instead effected by industry such as the follow:

Urban: After certain level of population density and or industry the world would be classified as an Urban or "Hive world" and that would effect combat accordingly.

Toxic: Worlds that are habitable but either through nuclear or natural disaster they have had their ecosystem and overall habitability ruined, this could effect logistics as well as how fighting takes place due to low visibility and specialised equipment.

Wasteland: Worlds that through high levels of fighting and damage have had the very landscape itself turned into a wasteland, such as Nuclear weapons firing from orbit or massive amounts of land warfare leading to ecosystem collapse as well as the destruction of the original terrain, this could be implemented based off how much fighting has occurred as well as the type and level of weapons used, this could either effect combat or mainly effect population growth and essentially scare the planet for generation to come.

Planet-Cracked: The next step after the wasteland essentially these types of worlds have either been bombed into submission in such a way that the planet itself has cracked and or that a natural disaster has caused terrible damage and made it uninhabitable, these worlds would be uninhabitable rocks with no atmosphere and reduced amounts of mineral deposits.

Overall I think new terrain types that you can effect through more then just terraforming that allow you to see how wars effect planets and the devastating costs of fighting prolonged drawn out wars with TN tech could be very interesting and enjoyable. So I hope this gets added eventually.
Title: Re: New Terrain Types (Urban, Toxic, Wasteland, Planet-Cracked)
Post by: Droll on April 28, 2020, 11:23:56 AM
My suggestion would be to add terrain types that are less natural but instead effected by industry such as the follow:

Urban: After certain level of population density and or industry the world would be classified as an Urban or "Hive world" and that would effect combat accordingly.

Toxic: Worlds that are habitable but either through nuclear or natural disaster they have had their ecosystem and overall habitability ruined, this could effect logistics as well as how fighting takes place due to low visibility and specialised equipment.

Wasteland: Worlds that through high levels of fighting and damage have had the very landscape itself turned into a wasteland, such as Nuclear weapons firing from orbit or massive amounts of land warfare leading to ecosystem collapse as well as the destruction of the original terrain, this could be implemented based off how much fighting has occurred as well as the type and level of weapons used, this could either effect combat or mainly effect population growth and essentially scare the planet for generation to come.

Planet-Cracked: The next step after the wasteland essentially these types of worlds have either been bombed into submission in such a way that the planet itself has cracked and or that a natural disaster has caused terrible damage and made it uninhabitable, these worlds would be uninhabitable rocks with no atmosphere and reduced amounts of mineral deposits.

Overall I think new terrain types that you can effect through more then just terraforming that allow you to see how wars effect planets and the devastating costs of fighting prolonged drawn out wars with TN tech could be very interesting and enjoyable. So I hope this gets added eventually.

A couple things I'd like to add - the urban modifier should stack with existing terrain so "jungle urban" temperate forest urban" or "urban jungle mountain", a planet that is sitting right at the population capacity "with some margin for error" should have "ecumenopolis" (think coruscant). The Planet-cracked modifier should not have reduced resources - it should have the opposite, since the depths of the crust/ upper mantle are likely to be more exposed the accessibility/availability of any minerals should increase not the other way around.

It would also be interesting for terrain to affect units depending on their base type. An urban environment should reduce the likelihood that infantry can avoid hits whereas heavy vehicle base types should have a reduced hit chance on their attacks. Deserts could improve the hit chance of armoured units while not affecting infantry that much. It would add some interesting force composition choices to invading planets with difficult terrain beyond just bringing even more stuff.
Title: Re: C# Suggestions
Post by: Droll on April 28, 2020, 11:30:18 AM
Some suggestions for the civilians shipping orders mechanic.

1. Allow the player to specify supply and demand of minerals. This should preferably be in multiple of 1 thousand minerals to make it easier to set up.
2. Allow supply orders for installations that don't exist yet. When checking for supply to assign to a civilian check if that installation exists and then reserve it instead of failing to pickup when it doesn't exist. Current functionality makes it necessary to constantly update the supply when new installations are built for example when building terraforming installations at Earth would be nice to simply set supply and let the civilians check if it exists yet.
3. Allow civilian shipping of maintenance supplies and fuel (with the required new civilian designs). This will make it easier to manage outposts.


Again, these largely amount to "remove any remaining need for government-owned shipping" and I, for one, would like to see shipping lines move in other direction -- that of becoming less useful.

I have to disagree with this - allowing the government to contract out transport of minerals not only makes sense from a realism perspective, it is a massive reduction on micromanagement requirements as I can set up construction on every planet with less hassle - and having functional construction facilities on every major colony is also realistic.
Title: Re: C# Suggestions
Post by: DoctorDanny on April 28, 2020, 01:56:37 PM
This has probably been suggested once allready.

I'd like the ability to save designs (ship/ground) externally.
That way I'd be able to import designs instead of designing the (more or less) same ships every new game.
Thinks like fuel harvesters, tugs, survey ships and the like are same in most of my games.

I realise that the designs use components that are also unique to that specific session so it will porably not be an option.
Title: Re: C# Suggestions
Post by: Black on April 28, 2020, 02:56:23 PM
Would it be possible to have message show up when a location with Maintenance Facilities is running low on maintenance supplies (something similar like when ship is low on fuel)? I got in trouble several times because my fleet base was out of maintenance supplies and I only realized it after ships started to acumulate damage from lack of maintenance.
Title: Re: C# Suggestions
Post by: Graham on April 28, 2020, 03:38:54 PM
Currently, unless I am going blind which is possible, there doesn't seem to be a way to modify either mineral stockpiles or racial wealth using SM in C#. This isn't so much of an issue in a lot of games, but it's a relatively small thing that adds a lot of utility to multi faction RP heavy games.
Title: Re: C# Suggestions
Post by: smoelf on April 28, 2020, 03:56:29 PM
Currently, unless I am going blind which is possible, there doesn't seem to be a way to modify either mineral stockpiles or racial wealth using SM in C#. This isn't so much of an issue in a lot of games, but it's a relatively small thing that adds a lot of utility to multi faction RP heavy games.

You can set minerals it in system view. Just activate SM and click on the body and then 'Specify Minerals' (see attached screenshot). Don't know about wealth, though.
Title: Re: C# Suggestions
Post by: Graham on April 28, 2020, 03:58:10 PM

I don't mean mineral deposits, I mean the mineral stockpile of an empire. being able to SM mod mineral stocks and wealth makes RP trades between player empires possible.
Title: Re: C# Suggestions
Post by: smoelf on April 28, 2020, 04:00:07 PM
Ahh, right. I misunderstood.

Yeah, that would actually be a really nice feature.
Title: Re: C# Suggestions
Post by: Black on April 28, 2020, 04:18:36 PM

I don't mean mineral deposits, I mean the mineral stockpile of an empire. being able to SM mod mineral stocks and wealth makes RP trades between player empires possible.

You can set stockpile in SM as well. Go to Mining tab in Economics - now you need to untick Double-click Sets Reserve Amount. Now if you double-click on Mineral, you can set a stockpile.
Title: Re: C# Suggestions
Post by: TMaekler on April 28, 2020, 04:31:05 PM
An easier function to exchange a researcher for all of his projects (the one he is working on and all his queued ones).

Edit: When a researcher dies his projects are terminated. Maybe you can exchange him against an "unknown nobody" which is very slow in research; but his queue-data isn't deleted. Then you can exchange the "unknown nobody" against a new researcher and don't have to requeue everything.
Title: Re: C# Suggestions
Post by: TMaekler on April 29, 2020, 05:15:47 AM
Can we have an option to select what is auto assigned? I would like to have Admin Commands also be auto assigned.
Title: Re: C# Suggestions
Post by: Mr Monnix on April 29, 2020, 05:30:46 AM
It would be nice include a autoturn interruption message for when a Naval Admin, Governor or  Academy chairman gets de-assigned from his role , i m playing a conventional start with a really low tech research rate and because a lot of in-game time pass by, i have to check each interruption, if  all the positions are still covered, which is really annoying if you have to do it every 5 minutes and find out that half of them are empty. 
I know that in a normal game it wouldn't be so recurrent because the in-game time pass by at a slower rate but the player is still not aware if all his arrangements are valid with the passing of time unless he checks manually, even if he uses the autometed assignments which doesn't work with those positions.  (the turns are so fast that those messages get overlooked in the event window)

also if the Civilian ships could be excluded in the pop up window when you right click on the tactical map would be a nice ui improvement because 99. 9% that function is useless on your Homeword (where you usually park your fleet) due to the clutter created by the hundreds of Civ FT and CS in that spot.

Steve thanks for all the time and work you put in this game, and for sharing it with us.





Title: Re: C# Suggestions
Post by: Eretzu on April 29, 2020, 06:13:15 AM
In shipyard, the use components checkbox should be marked by default.

I think it is more often you want to use the components so it should be default.
Title: Re: C# Suggestions
Post by: Eretzu on April 29, 2020, 06:16:30 AM
Remove crew quarters from component list (at least the addition side).

Since crew quarters are now always handled automatically, they serve no purpose in the component list.
Title: Re: C# Suggestions
Post by: TMaekler on April 29, 2020, 06:27:25 AM
Default Colors for Fleet Movement Orders. It always takes the eye a moment to find the right command. If I could highlight those whom I use most, that would be a nice QoL. Same for the Events Window, talking about the Event text: For example the text for "Maintenance Problem" is quite long and takes a moment to spot how much MSP has been used and how much is still in the ship. If these numbers would be color highlighted, again nice QoL :-)
Title: Re: C# Suggestions
Post by: Eretzu on April 29, 2020, 06:28:57 AM
Colors to events in system window.

As we can now color events in events window, it would be nice that those colors would be shown in main screen also.
Title: Re: C# Suggestions
Post by: mike2R on April 29, 2020, 06:46:11 AM
Speaking of coloured events, it would be great if that could be global rather than per game - set them up, and all subsequent games on that db share the same ones.
Title: Re: C# Suggestions
Post by: skoormit on April 29, 2020, 07:25:49 AM
Speaking of coloured events, it would be great if that could be global rather than per game - set them up, and all subsequent games on that db share the same ones.

Yes, yes, yes, please.
Title: Re: C# Suggestions
Post by: Cedras on April 29, 2020, 07:39:10 AM
Infantry transport module

Currently there is no way to create mechanized/armored infantry units.  Mechanized/armored infantry uses armored personnel carriers and infantry fighting vehicles to gain a degree of protection and mobility on the battlefield.  Adding armor to infantry does not make a lot of sense since aurora ground combat phases take 8 hours during which infantry would fight dismounted.  However, mobility could be implemented through a module that removes the 0. 5 breakthrough modifier from a set number of infantry units per module. 
Title: Re: C# Suggestions
Post by: Earthrise on April 29, 2020, 08:07:43 AM
I would like to suggest a small quality-of-life improvement:

On the research screen, would it be possible to show the number of current research projects, and the number of queued research projects? Ideally in a format like '20/18'.

This would allow a rapid check to see that all research projects have a queued research project, thus making it unnecessary to constantly count these things if, like me, you can't bear the thought of wasted research points, probably otherwise known as borderline OCD  :)
Title: Re: C# Suggestions
Post by: Pedroig on April 29, 2020, 08:08:20 AM
Infantry transport module

Currently there is no way to create mechanized/armored infantry units.  Mechanized/armored infantry uses armored personnel carriers and infantry fighting vehicles to gain a degree of protection and mobility on the battlefield.  Adding armor to infantry does not make a lot of sense since aurora ground combat phases take 8 hours during which infantry would fight dismounted.  However, mobility could be implemented through a module that removes the 0. 5 breakthrough modifier from a set number of infantry units per module.

Not sure I'm following you here.  You can put Vehicles into an Infantry formation.  As you stated, the infantry themselves would fight dismounted.  And in modern doctrine, those vehicles act as fire support platforms to support the dismounted infantry.  Motorized/Mechanized Infantry don't really breakthrough, they just can get from point A to B quicker, but they cannot fight in a battle from point A to point B quicker than regular leg infantry, because of the dismount doctrine which comes from weight of fire advantages of being dismounted.  Where do you see/find a "breakthrough modifier" for anything?  I've had static units "breakthrough" when their formation is set to Front Line Attack.
Title: Re: C# Suggestions
Post by: skoormit on April 29, 2020, 08:19:30 AM
On the Naval Organization screen, change the text color of admin commands based on the assignment status:
No commander assigned = Yellow
Commander of insufficient rank assigned = Red
Commander of sufficient rank assigned = Green (current color)
Title: Re: C# Suggestions
Post by: Cedras on April 29, 2020, 08:29:20 AM
Quote from: Pedroig link=topic=10640.   msg129076#msg129076 date=1588165700
Quote from: Cedras link=topic=10640.   msg129069#msg129069 date=1588163950
Infantry transport module

Currently there is no way to create mechanized/armored infantry units.     Mechanized/armored infantry uses armored personnel carriers and infantry fighting vehicles to gain a degree of protection and mobility on the battlefield.     Adding armor to infantry does not make a lot of sense since aurora ground combat phases take 8 hours during which infantry would fight dismounted.     However, mobility could be implemented through a module that removes the 0.    5 breakthrough modifier from a set number of infantry units per module.   

Not sure I'm following you here.     You can put Vehicles into an Infantry formation.     As you stated, the infantry themselves would fight dismounted.     And in modern doctrine, those vehicles act as fire support platforms to support the dismounted infantry.     Motorized/Mechanized Infantry don't really breakthrough, they just can get from point A to B quicker, but they cannot fight in a battle from point A to point B quicker than regular leg infantry, because of the dismount doctrine which comes from weight of fire advantages of being dismounted.     Where do you see/find a "breakthrough modifier" for anything?  I've had static units "breakthrough" when their formation is set to Front Line Attack.   
The idea is that they can keep up with the tanks.    Obviously not trucks (motorized), maybe APCs (mechanized) but IFVs (armored) are designed to do that.   Infantry would dismount when necessary.   The breakthroughs are explained here http://aurora2.pentarch.org/index.php?topic=8495.msg109786#msg109786 (Base Ground Combat Rules in C# Aurora Changes List)
Title: Re: C# Suggestions
Post by: smoelf on April 29, 2020, 09:49:49 AM
I would like to suggest a small quality-of-life improvement:

On the research screen, would it be possible to show the number of current research projects, and the number of queued research projects? Ideally in a format like '20/18'.

This would allow a rapid check to see that all research projects have a queued research project, thus making it unnecessary to constantly count these things if, like me, you can't bear the thought of wasted research points, probably otherwise known as borderline OCD  :)

Instead of a number, then perhaps a column right next to 'Pause' with a simple 'Yes/No' on whether that particular researcher has a queued project? That way you don't have to go through the list to see which reseacher is lacking a queued project.
Title: Re: C# Suggestions
Post by: Eretzu on April 29, 2020, 10:24:05 AM
Small versions of Cargo Shuttle Bay and Refueling, I would like to build some small savior class ships (to fix my inevitable fails while commanding), but having the cargo shuttle bay at 500 tons and maintenance storage at 50 tons seems a little excessive. Same with fule transfer (500) and standard fuel tank (50).

Of course the transfer rate should probably be something miniscule.

If this actually exists, I am sorry for spam, but cannot find it in research.
Title: Re: C# Suggestions
Post by: TMaekler on April 29, 2020, 11:07:59 AM
It would be nice to get a message that one of the postings you assigned is now vacant. Sure you get the warning that someone died; but that message has the same trigger of someone "only" looses health. Maybe you can split those two messages; because of the loads of "just-health-lost" I rarely recognize the ones when someone dies. So my posts are empty "all the time".

Maybe we get to set a bit "warn if this office is vacant"... and then receive a log message. Or, even better, refill them automatically with people of the needed skill.
Title: Re: C# Suggestions
Post by: skoormit on April 29, 2020, 11:38:46 AM
Current assignments for commanders are displayed in two places on the Commanders screen:
1) At the top (to the right of the captain's name).
2) In the filtered list of commanders on the bottom right.

When a commander is in command of a ship but is not the senior commander of a multi-ship fleet, the commander's current assignment displays the name of the ship.
When a commander is in command of a ship and is the senior commander of a multi-ship fleet, the commander's current assignment displays the name of the fleet.


In the second case, I would find it much more useful for the current assignment to display the name of the ship instead of the name of the fleet.

Title: Re: C# Suggestions
Post by: Earthrise on April 29, 2020, 11:52:58 AM
Quote from: smoelf link=topic=10640. msg129107#msg129107 date=1588171789
Quote from: Earthrise link=topic=10640. msg129075#msg129075 date=1588165663
I would like to suggest a small quality-of-life improvement:

On the research screen, would it be possible to show the number of current research projects, and the number of queued research projects? Ideally in a format like '20/18'. 

This would allow a rapid check to see that all research projects have a queued research project, thus making it unnecessary to constantly count these things if, like me, you can't bear the thought of wasted research points, probably otherwise known as borderline OCD  :)

Instead of a number, then perhaps a column right next to 'Pause' with a simple 'Yes/No' on whether that particular researcher has a queued project? That way you don't have to go through the list to see which reseacher is lacking a queued project.

Yes, even better.  +1
Title: Re: C# Suggestions
Post by: swarm_sadist on April 29, 2020, 05:06:25 PM
When declaring independence:
-Have the option to make the race an NPR
-If the population is the only one (of that empire) on the planet, then transfer all Orbital Habitats in orbit of the planet
-Reset political stability to 100% (or have an SM button to manually change it)
-All custom names of stars, planets, moons and populations remain the same. My Lunar colony declared independence and currently resides on "Sol A III - Moon 1"  >:( I am not renaming the solar system.
Title: Re: C# Suggestions
Post by: Graham on April 29, 2020, 09:15:25 PM
My Lunar colony declared independence and currently resides on "Sol A III - Moon 1"  >:( I am not renaming the solar system.

There is an SM button at the bottom of the system view page called "rename Sol System" or something along those lines. It will fix that for you.
Title: Re: C# Suggestions
Post by: tapk on April 30, 2020, 01:19:23 AM
With new ground survey system amount of minerals available in systems is almost halved.  I suggest to add minerals generation modificators (for each of three mineral generation phases) in game options (new game or even current game), so you can make game easier or more difficult.
Title: Re: C# Suggestions
Post by: esavier on April 30, 2020, 04:10:27 AM
hey everyone,
i wonder if there will be possible ground based missile silos (something like in old Aurora PDC with missile launchers).  In my opinion its kinda advantageous on real life to have cheap and immobile, big rockets silos instead of expensive mobile ones (in case of aurora orbital stations/platforms with basically only launchers and magazines).  I know there is STU available but so far i was unable to arm those with launchers, so i can imagine this feature is not planned?
Title: Re: C# Suggestions
Post by: zatomic on April 30, 2020, 05:16:15 AM
In conventional starts, I like to do some early geo-surveys by probe before I start building ships. One thing that slows this down and feels weird is besides geosurvey tech, I also need active sensor tech to create a fire control to be able to target a waypoint. In VB, I could use the ICBM fire control (along with the ICBM launcher) components to create a very early PDC capable of launching probes. Now with box-launchers available day 1, I don't really need the old ICBM launcher, but I do need a fire control. (Obviously ground based missile launchers would be nice but that's another thing that's already been suggested).

My thoughts would be to create a conventional level of active sensor tech (even strength 1 would allow targeting waypoints (and I guess the early thermonuclear war between powers on the same planet). Another option would be a pre-designed fire-control like the old ICBM fire control that can be used on day 1. Effectively zero range is fine since I'm targeting waypoints, but I would like it small enough to fit in a fighter-sized launch platform.
Title: Re: C# Suggestions
Post by: skoormit on April 30, 2020, 08:59:01 AM
On the tactical map, fleets undergoing overhaul have a "[OV]" appended to the fleet name.

Can we get something similar for ships being refitted?
I know it is slightly different, since overhaul is handled at the fleet level (via fleet orders) and refit is handled at the ship level (via shipyard tasks).
But both conditions to me mean "don't give this fleet orders right now". It would be nice to be able to see that without having to look at the ship list of a fleet.
Title: Re: C# Suggestions
Post by: skoormit on April 30, 2020, 10:09:08 AM
Scenario 1:
Fleet X has one ship in it.
I give a tug an order to tractor that ship.
When the tug completes the order, Fleet X is deleted.

Scenario 2:
Fleet Y has one ship in it.
I give the fleet orders to join another fleet.
When the fleet completes the order, Fleet Y is deleted.

Scenario 3:
Fleet Z has one ship in it.
I give another fleet orders to absorb fleet Z.
When that order is completed, Fleet Y is deleted.

My use case:
At planets where fleets congregate, I often use fleets as logical groupings.
Examples:
"Mining Platforms -> Eros"
"Mining Platforms -> Ecke"
"Awaiting Refit"
"Tanker Pool"

Often these groupings become empty. I don't like having to re-create them all the time.

Suggestion:
On the Fleet tab of the Naval Organization window, give us a checkbox to control if the fleet will be auto-deleted when it no longer has ships.

Title: Re: C# Suggestions
Post by: skoormit on April 30, 2020, 10:20:44 AM
Naval Organization window
Fleet tab
Top line of top-right pane has a summary line.
Summary line includes location, current orders, all orders distance, and travel time.

Suggestion: if current order is to stabilize a jump point, show the time remaining on this line.
Title: Re: C# Suggestions
Post by: Migi on April 30, 2020, 11:55:34 AM
Naval Organization window
Fleet tab
Top line of top-right pane has a summary line.
Summary line includes location, current orders, all orders distance, and travel time.

Suggestion: if current order is to stabilize a jump point, show the time remaining on this line.

Loading and unloading, refueling and reloading ordinance all take time and don't get shown either.
I suspect this is one of the QOL enhancements which was not included in order to release earlier.
Title: Re: C# Suggestions
Post by: Father Tim on April 30, 2020, 09:49:34 PM
When declaring independence:
-Have the option to make the race an NPR
-If the population is the only one (of that empire) on the planet, then transfer all Orbital Habitats in orbit of the planet
-Reset political stability to 100% (or have an SM button to manually change it)
-All custom names of stars, planets, moons and populations remain the same. My Lunar colony declared independence and currently resides on "Sol A III - Moon 1"  >:( I am not renaming the solar system.


Turning an empire that at any point was controlled by the player into an Aurora-run NPR is currently impossible, and Steve has said it is a massive programming undertaking.  As in, maybe a year or more of coding.  And even then the AI NPR  would ignore any tech, ships, fleets, ground units, etc. that it didn't 'understand'.

Folks who've played Aurora for a while will remember when it would build your civilian designs and try to treat them as commercial shipping -- which led to many a massive jump tender whizzing around the system slowly delivering one mine at a time because it had been 'padded out' in size with cargo holds.
Title: Re: C# Suggestions
Post by: Father Tim on April 30, 2020, 09:50:17 PM
hey everyone,
i wonder if there will be possible ground based missile silos (something like in old Aurora PDC with missile launchers).  In my opinion its kinda advantageous on real life to have cheap and immobile, big rockets silos instead of expensive mobile ones (in case of aurora orbital stations/platforms with basically only launchers and magazines).  I know there is STU available but so far i was unable to arm those with launchers, so i can imagine this feature is not planned?


It is not.  Ground-based missiles were deliberately removed for C# Aurora, so don't expect them back any time soon.
Title: Re: C# Suggestions
Post by: Neophyte on May 01, 2020, 12:41:29 AM
Rename either maintenance supplies (MSP) OR missile size points (MSP) to prevent confusion to new players.

Watching a stream I've already seen someone make a supply ship intended to transfer MSPs (using cargo shuttles) with an added unnecessary ordinance transfer system, which lists ordnance transfer in MSPs/hr (for missiles obviously).  The ship didn't have a magazine so it isn't intended as a collier.

Regardless, it's pretty confusing if you're new and honestly I'm surprised I didn't get confused myself in VB6.  Or maybe I did and forgot!

A simple renaming of either (Repair Supply Points?  Missile Total Size? etc.) to change the acronyms hopefully wouldn't be that complicated.
Title: Re: C# Suggestions
Post by: TMaekler on May 01, 2020, 12:51:01 AM
With left click on any system body you can center the view on that body. However the center point is calculated by screen size, not the size of the window. Would be nice if it would center the view dependent on the size of your window.
Title: Re: C# Suggestions
Post by: Haji on May 01, 2020, 01:52:09 AM
Considering how large tidal lock zone is for stars in the game (for Sol like stars is it 100-120 million kilometres, for some reason it varies from star to star even though said stars are identical) and considering that in reality tidal lock is actually time dependant (meaning young systems wouldn't have any) please give us an option to remove (or add) it via SM mode.

Edit:
If the graph on this site is correct: https://physics.stackexchange.com/questions/12541/tidal-lock-radius-in-habitable-zones
then the tidal lock zones around the stars are really too large. For Sol it should be just beyond Mercury so about 60-70 million kilometres and for a star half as massive it should be 0.3-0.4 AU or about 45-60 million kilometres. From the admittedly limited testing I've done it seems pretty much all the stars have tidal lock zone stretching out to over 80 million kilometres.

Edit 2: It would also be nice if we could do some things to gas tolerances. I'm creating a race of supped up cyborgs that can live pretty much anywhere and the game allows me to do that. No atmosphere at all? No problem. Temperature of -100C? No problem. Radiation? No problem. Gravity of 0.0001 g? No problem. That 0.01ppm of oxygen constitutes 31% of the atmosphere? Well, we can't live on that! And God forbid there is 0.0001 of fluorine.

Being a little more serious I do realise that this would require a significant amount of work most likely and fortunately thanks to the SM mode I can pretty much simulate this by SMing atmospheres. Even so it does make it difficult to create races that are less human especially since there is no longer an option to breathe methane. Which I would also love to have back by the way.
Title: Re: C# Suggestions
Post by: TMaekler on May 01, 2020, 02:49:05 AM
Civilian Mining: It really can cripple your economy if you buy minerals from the civilian - and they have so much fun that they increase the numbers of their mining facilities in rapid succession. Some kind of option to limit their numbers would be nice... .
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 01, 2020, 03:28:19 AM
Civilian Mining: It really can cripple your economy if you buy minerals from the civilian - and they have so much fun that they increase the numbers of their mining facilities in rapid succession. Some kind of option to limit their numbers would be nice... .
An option to ban CMCs like the option to ban CGMs?

In the meantime the same workaround as was in VB (putting your own colony on every world with minerals) mostly works, except that finding minerals isn't an interrupt so if your turn length is too long or you run autoturns the civvies can get in ahead of you.

On that note, while I know some people don't want minerals to be an interrupt, others do.  Could this maybe be an option?  Or a more general system to let players decide which events cause interrupts?
Title: Re: C# Suggestions
Post by: TMaekler on May 01, 2020, 05:26:31 AM
No, I am generally fine when the civilians do mining. I have blocked some which I want to do myself, but they can do the rest. No worries. I just had the case of having 4 civilian mining stations within like 6 month increasing their numbers from 1 to 3 or 4 - so "suddenly" I had to pay some 2.500 wealth for them. So some kind of: Civilian mining wants to increase their mines from 1 to 2. Allowed (y)es/(n)o would have been nice, so I could have some control over it.

I temporarily switched some of them to "tax civilian mining" - though I could use the minerals. Well, If you have no economy, no minerals are worth anything  ;D
Title: Re: C# Suggestions
Post by: SevenOfCarina on May 01, 2020, 06:25:01 AM
This is just a minor request, but could the medal criteria be changed from 'destroyed X tons of hostile shipping' to 'destroyed X times own command's tonnage of hostile ships'? It's kind of annoying when Commodore A gets meritorious service medals for slaughtering 10,000 tons of enemy gunboats while in command of a 15,000 ton battleship, but the plucky Commander B who took down a 5,000 ton enemy cruiser while in command of a tiny 1,000 ton destroyer gets absolutely no recognition at all.
Title: Re: C# Suggestions
Post by: Cosinus on May 01, 2020, 08:16:03 AM
QOL:
When Civilians scrap a ship, this uses the same Event as when a player scraps a ship ("Ship scrapped") and interrupts auto turns.
Scrapped civilian ships should use a different event and not stop auto turns.
Title: Re: C# Suggestions
Post by: skoormit on May 01, 2020, 08:21:54 AM
I would like a way to add or subtract from total racial wealth.
Title: Re: C# Suggestions
Post by: AlStar on May 01, 2020, 11:15:32 AM
The default order caused by double clicking on a JP in Movement Orders should be "Standard Transit", not an error message.
Title: Re: C# Suggestions
Post by: kenlon on May 01, 2020, 11:40:19 AM
Would it be possible to get an option to log the same data as the events window to a file so we can parse it with various tools?
Title: Re: C# Suggestions
Post by: Tyrope on May 02, 2020, 03:25:09 AM
I had the idea for a seed ship (A single ship that's capable of kickstarting a colony).  This can be done with various TN buildings, but Conventional Industry would be a perfect cargo-space saver for these things.

To the point then: TN empires should be able to build Conventional Industry.
Title: Re: C# Suggestions
Post by: Father Tim on May 02, 2020, 04:18:36 AM
Rename either maintenance supplies (MSP) OR missile size points (MSP) to prevent confusion to new players.

. . .

Regardless, it's pretty confusing if you're new and honestly I'm surprised I didn't get confused myself in VB6.  Or maybe I did and forgot!



There's a reason it's among the Top 5 most frequently asked questions for VB Aurora.

Personally, I'd prefer dumping MSP (that's Missile Size Points) altogether and using only "tons" to designate the size/displacement of missile components.  That would leave MSP as Maintenance Supply Points only (though I wouldn't mind dropping the "Points" part of that initialism -- "Maintenance Supplies" sounds much more appropriate to my fiction).
Title: Re: C# Suggestions
Post by: Eretzu on May 02, 2020, 04:30:16 AM
When choosing ship in Logistic Report (In Naval Organisation Window) It would be nice if it highlighted the whole row. Then it is easier to see exactly which ship has low maintenance or fuel.
Title: Re: C# Suggestions
Post by: Father Tim on May 02, 2020, 04:31:44 AM
Edit 2: It would also be nice if we could do some things to gas tolerances. I'm creating a race of supped up cyborgs that can live pretty much anywhere and the game allows me to do that. No atmosphere at all? No problem. Temperature of -100C? No problem. Radiation? No problem. Gravity of 0.0001 g? No problem. That 0.01ppm of oxygen constitutes 31% of the atmosphere? Well, we can't live on that! And God forbid there is 0.0001 of fluorine.

Being a little more serious I do realise that this would require a significant amount of work most likely and fortunately thanks to the SM mode I can pretty much simulate this by SMing atmospheres. Even so it does make it difficult to create races that are less human especially since there is no longer an option to breathe methane. Which I would also love to have back by the way.


There aren't too many substances that are completely immune to reacting with Flourine -- and those that are wouldn't make suitable cyborgs without completely encasing the more vulnerable parts. . . which gets us right back to needing protective suits or domes.  I think the best solution is to leave Aurora as it is and let you SM away any nasty gasses you don't want in your game.

- - - - -

Again, I successfully made a Methane-breathing race in 1.4.  I just did it again in 1.8.0.  Are you remembering to click the box for "Methane Breathing" on the Create Race window?  It's among the options that doesn't show up on the Race Details window after creation.
Title: Re: C# Suggestions
Post by: Father Tim on May 02, 2020, 04:37:35 AM
No, I am generally fine when the civilians do mining. I have blocked some which I want to do myself, but they can do the rest. No worries. I just had the case of having 4 civilian mining stations within like 6 month increasing their numbers from 1 to 3 or 4 - so "suddenly" I had to pay some 2.500 wealth for them. So some kind of: Civilian mining wants to increase their mines from 1 to 2. Allowed (y)es/(n)o would have been nice, so I could have some control over it.

I temporarily switched some of them to "tax civilian mining" - though I could use the minerals. Well, If you have no economy, no minerals are worth anything  ;D


If you don't want civilians mining the good minerals, put your own colonies on those sites.  The same as in VB Aurora, civilians won't compete with you.  CMCs are theft anyway -- there's no point in encouraging them.
Title: Re: C# Suggestions
Post by: MinuteMan on May 02, 2020, 04:42:02 AM
A mass driver component for space stations only.
This will reduce the amount of micro needed for all the mineral transfers.
Title: Re: C# Suggestions
Post by: Father Tim on May 02, 2020, 04:56:28 AM
I would like a way to add or subtract from total racial wealth.


It's coming, along with many other QoL improvements, sometime in the next couple of months.

(If you simply need to add a massive chunk of wealth to fix a problem -- rather than adjust things by a specific amount to simulate trade, for example -- you can SM Add nine hundred and ninety-nine thousand, nine hundred and ninety-nine Financial Centers and advance time by one production cycle, or similar work-arounds.)
Title: Re: C# Suggestions
Post by: Father Tim on May 02, 2020, 04:56:54 AM
This is just a minor request, but could the medal criteria be changed from 'destroyed X tons of hostile shipping' to 'destroyed X times own command's tonnage of hostile ships'? It's kind of annoying when Commodore A gets meritorious service medals for slaughtering 10,000 tons of enemy gunboats while in command of a 15,000 ton battleship, but the plucky Commander B who took down a 5,000 ton enemy cruiser while in command of a tiny 1,000 ton destroyer gets absolutely no recognition at all.


Changed, no.  A new criterion added, maybe -- Steve will have to tell us.  Though it is kind of assumed that destroying a cruiser five times your own tonnage is a notable (and rare) enough accomplishment that you'd award the medal personally.

There are plenty of real world examples that ignored your own capabilities, and focused solely on loss to your enemies.
Title: Re: C# Suggestions
Post by: Father Tim on May 02, 2020, 05:07:53 AM
The default order caused by double clicking on a JP in Movement Orders should be "Standard Transit", not an error message.


Double-click for almost all shortcuts was left out to in order to release V1.0 in April, not July.  They're all on the list for QoL improvements over the next couple of months.
Title: Re: C# Suggestions
Post by: Eretzu on May 02, 2020, 05:12:05 AM
Carronade should be renamed to Plasma Carronade (or opposite)

In component design window it is under Plasma Carronade, but in Class Design it is under Carronade. Having same name used everywhere would make it easier to find the component.

Also in research it is 20cm Carronade, not 20cm Plasma Carronade
Title: Re: C# Suggestions
Post by: TMaekler on May 02, 2020, 05:17:54 AM
When you open the class window, all ship classes trees are open by default. Gets a bit crowded after a while. Maybe having them closed by default or saved which were opened last time, would be a nice QoL, I think ;-)
Title: Re: C# Suggestions
Post by: Father Tim on May 02, 2020, 05:18:03 AM
I had the idea for a seed ship (A single ship that's capable of kickstarting a colony).  This can be done with various TN buildings, but Conventional Industry would be a perfect cargo-space saver for these things.

To the point then: TN empires should be able to build Conventional Industry.


We asked for the ability to build CI in VB Aurora, and back then Steve was against both building and moving Conventional Industry.

And it definitely wouldn't be a space saver.  Not only is 1 CI larger than 0.1 Mine + 0.1 CF + 0.05 Fuel refinery + 0.05 Financial centre + whatever else, it is in fact the size of either 10 or 20 mines / factories / refineries, etc.  (In other words, the size of a Research Lab, or half the size of a Research Lab -- it varied.)
Title: Re: C# Suggestions
Post by: Father Tim on May 02, 2020, 05:22:58 AM
A mass driver component for space stations only.
This will reduce the amount of micro needed for all the mineral transfers.


I don't think Structural Shells should be able to catch minerals -- and ships certainly shouldn't, unless we're getting the PIRACY! upgrade to steal MD packets.

- - - - -

If you want to reduce micromanagement, set up a government freighter to run out and collect the minerals and deliver them to the station via cycling orders.
Title: Re: C# Suggestions
Post by: Father Tim on May 02, 2020, 05:30:26 AM
Carronade should be renamed to Plasma Carronade (or opposite)

In component design window it is under Plasma Carronade, but in Class Design it is under Carronade. Having same name used everywhere would make it easier to find the component.

Also in research it is 20cm Carronade, not 20cm Plasma Carronade


I recommend posting this in the Typo thread.
Title: Re: C# Suggestions
Post by: Polestar on May 02, 2020, 05:35:01 AM
Miscellaneous suggestions for version 1.93, based on a few games.

The fleet order interface for choosing a minimum or maximum amount or a delay is cumbersome. If you don't carefully set things back to zero, all future orders might load only 1 factory, or be delayed 30 days. I don't have any ideas on streamlining the interface, so I'll just ask that all special conditions be cleared after an order is given.

The left-hand side of the Naval Organization window does not conveniently show me some of the information I need to make decisions. It would be great, for example, if fleets (and ships, when a fleet is expanded) showed the system they were in, as well as a few key indicators - low fuel, low supplies, low morale, low ordinance, damage, need for overhaul, and active sensor status.

On the same window, the "Select on Map" checkbox is handy, but it doesn't seem to adjust the Galactic map, which is what I really need in most cases. As an example, I have not figured out how to run exploration ships efficiently. Every time they need orders from me, I need to know where on the galactic map they are.

Relatedly, I have not been able to get value from Fleet Standing Orders->Go to system requiring geosurvey/gravsurvey. What I want is for fleets to find a system requiring a survey, that is reasonably close to my home world and reasonably close to the fleet's current position, and that has no fleet with the appropriate sensor already tasked to go there. Instead, I see fleets bunching up in the same system.

some types of messages on the Message Window now, when clicked, jump directly to the right window to get information and potentially take action. This is much appreciated! Messages shown on the system window do not yet do this. If they did, and did consistently, this game would have a real start to a unified "command screen" in which information is displayed or linked to, and from which orders are given.

Using Mass drivers to lob ore around is slow, in part because the speed at which mineral packets move does not appear to depend on Railgun Launch Velocity.

Ground surveys lack punch. In four games I've played with 50 stars and more, the total gain from all ground surveys might perhaps be one effectively usable mine world (2 games). Or the gain from all surveys together might, effectively, be nothing (2 games). This is due to several interlocking factors, among them the low return from all but the most promising (and lucky) surveys, the high concentration of TN resources in a few worlds, the critical importance of a few TN resources (and the near-ignorability of more than half the TN resource types), and the way mines produce from all resources on a world simultaneously.
Consider a successful survey. The most probable result is to add some non-critical TN resource, or add insufficient accessibility to make a world effectively mine-able given the alternatives available. Now, consider a survey that absolutely strikes the jackpot and adds 10,000,000 accessibility 0.9 Duranium. That's mighty interesting, but it'll be a long time on most maps before I actually mine such a world if it lacks Gallicite, Corundum, or Mercassium. To sum up, multiple features of the current TN resource allocation and mining system conspire against getting coolness from ground surveys.

Aurora shows a lot of messages, but my bandwidth for reading messages is low. I just want the critical ones. So I turn off such messages as leader retirement. 99% of the time, I lose nothing thereby, but when a truly important person vanishes I'd still like to know. So, who qualifies? Well, my personal answer is, roughly:
"If a scientist, and currently employed, or
If a civil administrator in charge of a sector, or in charge of a planet with any population or mines, or
If a ground commander and in charge of at least 500 build points-worth of units, or
If a navy officer and assigned to a fleet admin with ships attached, or in command of an armed military TF.

I want to know when a government ship has been scrapped. I do not want to know when a civilian ship has.

At present, the game provides no warning when a mineral is low, only when it has entirely run out. I propose that the game, for each production world, check to see if current construction and ship-building will both exhaust any mineral in less than (say) 20 days and also not complete before the mineral is exhausted.

Commander auto-assignment is very cautious about actually assigning officers. I'd like it to work harder to match suitable naval commanders with expensive ships instead of requiring me to hand-tweak ship class importance. Same story for ground units; the most expensive commands, and then the most expensive formations, should get officers more regularly. Same story with planets: the most populous worlds, and the ones with the most value in infrastructure, should immediately get the best eligible administrators. I like the fact that auto-assign doesn't re-assign leaders I've hand-placed, but I'd love it if the interface highlighted (gently) leaders that are off-limits for this reason.

In the Commanders window, I am having difficulty distinguishing between ships, populations, etc. that are highlighted in corniflower blue as having a leader and those in white without leaders. May I recommend a highlight color other than some tint of blue? Perhaps yellow, pale pink, or green?

Sector commanders, as expected, increase things like mining and production. I'm not seeing them increase population growth (could have sworn they did so in previous versions).

Managing research is more tedious than it needs to be. An initial proposal is for:
- Research facilities that become available through new construction, haulage, or scientist retirements to be automatically allocated. They should perhaps first be allocated to the projects with the most facilities already assigned, excepting projects that will complete in less than five days. If facilities remain un-allocated and no project has more than 1 facility assigned, then assign to the project with the earliest completion date, but not once that date is < five days away.
- A message to be shown of the form "Research re-allocated to developing X.". If more than one project gains facilities, than insert "and to other projects.".

A rather more ambitious proposal is for:
- All science to be centralized, but without losing track of the physical location of research facilities. All research facilities contributing to a project are combined. If at least some of these facilities are on a world with research bonuses, then indicate this in the Bonus Mod display. If any research is performed in a field, then the first facilities assigned are always from the world with the highest bonus in that field. The number of facilities from a world with bonuses are indicated, divided between those researching in a compatable field and those that are not.







Title: Re: C# Suggestions
Post by: Father Tim on May 02, 2020, 08:36:34 AM
Using Mass drivers to lob ore around is slow, in part because the speed at which mineral packets move does not appear to depend on Railgun Launch Velocity.

It is, and it should reamin so to encourage the use of government freighters.

Sector commanders, as expected, increase things like mining and production. I'm not seeing them increase population growth (could have sworn they did so in previous versions).

It did, and it still does.  I have many Administrators with Pop Growth modifiers.
Title: Re: C# Suggestions
Post by: skoormit on May 02, 2020, 08:56:33 AM
CMCs are theft anyway -- there's no point in encouraging them.

But muh taxes!
Title: Re: C# Suggestions
Post by: skoormit on May 02, 2020, 08:58:28 AM
A mass driver component for space stations only.
This will reduce the amount of micro needed for all the mineral transfers.

Oh my god, yes.
I was actually just now coming here to post this.
Please, please, please let me put a MD on a space station, park it at a jump point, and catch all the goodies I'm digging up in the system.
I'll even pay double the normal MD cost. Triple. Okay, quadruple! Just please let me have it.
Title: Re: C# Suggestions
Post by: skoormit on May 02, 2020, 09:04:03 AM
When you open the class window, all ship classes trees are open by default. Gets a bit crowded after a while. Maybe having them closed by default or saved which were opened last time, would be a nice QoL, I think ;-)

It actually is remembering which trees you have expanded.
It's just not remembering which trees you have collapsed.
So, it expands any tree that you have expanded since you started this session, even if you later collapsed that tree.

FWIW, if you close and re-open the game, the trees are collapsed again. Not a great workaround, obviously.
Title: Re: C# Suggestions
Post by: skoormit on May 02, 2020, 09:09:02 AM

If you want to reduce micromanagement, set up a government freighter to run out and collect the minerals and deliver them to the station via cycling orders.

That requires updating the freighter orders every time I set up a mining colony.
If my M.O. is to strip mine all the asteroids, then keeping the freighter orders up to date requires a lot of time.

The simple alternative now is to fling all mining output to a single MD on a body near the center of the system.
Letting us put a MD on a SS saves us hauling time, really.
Title: Re: C# Suggestions
Post by: smoelf on May 02, 2020, 09:13:50 AM
That requires updating the freighter orders every time I set up a mining colony.
If my M.O. is to strip mine all the asteroids, then keeping the freighter orders up to date requires a lot of time.

The simple alternative now is to fling all mining output to a single MD on a body near the center of the system.
Letting us put a MD on a SS saves us hauling time, really.

Not to mention those systems with only comets in them. If you automate the mineral pickup there, you might end up having a cargo ship chase a comet to the edge of space because the one comet you chose as gathering point is on its way away from the center. A space station with a mass driver would help greatly.
Title: Re: C# Suggestions
Post by: UberWaffe on May 02, 2020, 09:36:16 AM
I suggest a new research chain, related to long-term maintenance.

Orbital Standby Maintenance Efficiency (Logistics):
Reduces the number of MSP per annum used by ships that are being services by maintenance facilities (the mechanic where their maintenance clocks does not advance).
This is the [Ship BP cost * 0.25] in MSP the ship uses per year, being referred to here.
This would change to
Code: [Select]
Math.Floor("Ship BP cost" * 0.25 * "Orbital Standby Maintenance Efficiency Modifier"])By default the modifier is 1.0, and changes as tech is researched (like fuel efficiency).
At highest tech level the modifier should be around 0.25 or 0.2 (i.e. Docked ships use 4 to 5 times less MSP while in dry dock)

This is mainly to make it easier for larger (more late game) empires to maintain more standing fleets.

I would further suggest that an additional option be added to new game options, similar to research or terraform rate.
Code: [Select]
Math.Floor("Ship BP cost" * "Game Option Standby MSP Rate" * "Orbital Standby Maintenance Efficiency Modifier"])"Game Option Standby MSP Usage %" would normally be 0.25 (Represented as 25 in the field to fill in. I would not allow values higher than 25.).
Tooltip: 25 = Ship uses 25% of its BP cost in MSP per annum while in a maintenance facility. Lower means less MSP used per year.

This would be useful for newer players (like myself), or for games that play out over larger time scales (such as when research rate is adjusted down).
Title: Re: C# Suggestions
Post by: Father Tim on May 02, 2020, 10:21:03 AM

If you want to reduce micromanagement, set up a government freighter to run out and collect the minerals and deliver them to the station via cycling orders.

That requires updating the freighter orders every time I set up a mining colony.
If my M.O. is to strip mine all the asteroids, then keeping the freighter orders up to date requires a lot of time.

The simple alternative now is to fling all mining output to a single MD on a body near the center of the system.
Letting us put a MD on a SS saves us hauling time, really.

No, it merely requires one new freighter.  One mining colony, one freighter, one route each.  Not every mining colony and every freighter all on the same route.

Mule 001 gets the Phobos run, Mule 002 gets the Ceres run, Mule 003 gets the Hailey's Comet run, etc.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 02, 2020, 10:53:03 AM
A mass driver component for space stations only.
This will reduce the amount of micro needed for all the mineral transfers.
Mining stations?  Either have the civvies move the driver or include a cargo bay and shuttles and keep it with the station.
Title: Re: C# Suggestions
Post by: Migi on May 02, 2020, 11:23:55 AM
Not to mention those systems with only comets in them. If you automate the mineral pickup there, you might end up having a cargo ship chase a comet to the edge of space because the one comet you chose as gathering point is on its way away from the center. A space station with a mass driver would help greatly.
It sounds like the solution is to pick a comet which has a small orbit (and preferably angled near the jump point) and use that as a system-wide collection point.
Title: Re: C# Suggestions
Post by: Polestar on May 02, 2020, 12:47:28 PM
Using Mass drivers to lob ore around is slow, in part because the speed at which mineral packets move does not appear to depend on Railgun Launch Velocity.

It is, and it should reamin so to encourage the use of government freighters.
Certainly, government freighters should be a preferred option. But I submit that mass drivers should have more than a marginal reason even to exist in the game. At a minimum, they should maintain the same level of relative effectiveness through the tech progression.

Sector commanders, as expected, increase things like mining and production. I'm not seeing them increase population growth (could have sworn they did so in previous versions).

It did, and it still does.  I have many Administrators with Pop Growth modifiers.
[/quote]Yes, they do have growth modifiers. The report, however, is that the pop growth modifiers of sector governors do not appear to affect population growth in 1.93, and I am confident they did so in the past.
Title: Re: C# Suggestions
Post by: Disguy on May 02, 2020, 01:58:43 PM
Is there a way we can configure global ship "orders".

Avoid Enemy Systems
Auto Damage Repair
etc
Title: Re: C# Suggestions
Post by: skoormit on May 02, 2020, 02:07:38 PM

If you want to reduce micromanagement, set up a government freighter to run out and collect the minerals and deliver them to the station via cycling orders.

That requires updating the freighter orders every time I set up a mining colony.
If my M.O. is to strip mine all the asteroids, then keeping the freighter orders up to date requires a lot of time.

The simple alternative now is to fling all mining output to a single MD on a body near the center of the system.
Letting us put a MD on a SS saves us hauling time, really.

No, it merely requires one new freighter.  One mining colony, one freighter, one route each.  Not every mining colony and every freighter all on the same route.

Mule 001 gets the Phobos run, Mule 002 gets the Ceres run, Mule 003 gets the Hailey's Comet run, etc.

Assigning one ship per mining colony is a lot of overkill on ship construction, and therefore a lot of wasted fuel, unless you either have massive mining colonies, are using small cargo holds (which is less efficient), or traveling a very, very long way to your mining colonies.

One round trip from a standard cargo hold moves 12.5kt of minerals.
A freighter with a standard cargo hold and three 25% power, size-40 Magneto Plasma engines will make a round trip per year at a range of 11.5Bkm, using 52kL of fuel.
Even if it's a 35Bkm trip to your mining colony, this one ship is moving 4.1kt/year.
That's a lot of output for a mining colony, and will quickly strip most colonies, requiring that I move the mines again (and update the freighter orders again).
And that's at a range of 35Bkm. For a mining colony to keep up with one freighter at 10Bkm, I'd have to pull 43kt/year out of the rock.

Really, I'd just rather plop down a MD and point it at my collection station.
Title: Re: C# Suggestions
Post by: ChubbyPitbull on May 02, 2020, 03:24:02 PM
Not sure if it's been suggested already, but it would be nice to be able to queue up orders that stay after an overhaul order. For example, when a survey ship completes a system, what I like to do is say Return to colony -> Refuel -> Resupply -> Overhaul -> Standard Transit through Unexplored Jump Point #2, for example. This way, I don't have to come back to that survey ship and it will simply resume surveying the next unexplored location once the overhaul completes.

Currently, it appears all orders are automatically cancelled once overhaul begins, so when overhaul completes I now have to revisit fleets to again order them to explore a new system.

EDIT: Similar request for when tractoring ships. Sometimes my survey ships run out of fuel before reaching a refuel point, I set my tug fleet to go out, tractor the survey ship, then release the survey ship back at the colony. However, once the tugs first tractor the survey ship, the order to tow the tractored ships back to the colony and release them is removed from the tugs orders, so I have to go back in and tell it to do so again.
Title: Re: C# Suggestions
Post by: trainhighway on May 02, 2020, 08:13:09 PM
I've had a quick squiz at the suggestions but i might have missed something, so if its already been suggested sorry for repeating.
It would be great if there was the option to dump the events log into a text file, it would help when it comes to recording the dates of certain events for roleplay.
On a similar note it would be helpful if the little event log for each officer could be exported, especially just after an officer has died.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 02, 2020, 09:21:18 PM
On the topic of dumping event logs to text, please include detailed combat logs. VB Aurora recorded both the hit chance and damage dealt for every shot fired which was invaluable for weapon system comparison testing.
Title: Re: C# Suggestions
Post by: skoormit on May 02, 2020, 11:25:40 PM
On the Civilian Economy tab, when a colony is designated as "Source of Colonists", I would like to be able to specify a reserved population amount, such that only population in excess of that amount is considered available for relocation.

This would make it much easier to keep civvies from taking too many colonists and leaving too few workers for my installations.
Right now I have to keep a close eye on it, and switch the status back and forth all the time.
Title: Re: C# Suggestions
Post by: Father Tim on May 03, 2020, 01:05:35 AM
Certainly, government freighters should be a preferred option. But I submit that mass drivers should have more than a marginal reason even to exist in the game. At a minimum, they should maintain the same level of relative effectiveness through the tech progression.

And I submit that they shouldn't.  I want a robust civilian ecnomy so I can perform commerce raiding and commerce protection.  Until and unless I can steal mass driver packets in flight, they should be removed from the game.

Yes, they do have growth modifiers. The report, however, is that the pop growth modifiers of sector governors do not appear to affect population growth in 1.93, and I am confident they did so in the past.

Sector governor bonuses apply at a reduced rate.  The bonus might be small enough you're not noticing, or there might be enough bonuses that they don't all fit in the display area.

Governor bonuses (both colony & sector) to population growth exist in 1.9.3.  If they're not being displayed, or not being applied, that's a bug, not a suggestion.
Title: Re: C# Suggestions
Post by: Father Tim on May 03, 2020, 01:15:39 AM

If you want to reduce micromanagement, set up a government freighter to run out and collect the minerals and deliver them to the station via cycling orders.

That requires updating the freighter orders every time I set up a mining colony.
If my M.O. is to strip mine all the asteroids, then keeping the freighter orders up to date requires a lot of time.

The simple alternative now is to fling all mining output to a single MD on a body near the center of the system.
Letting us put a MD on a SS saves us hauling time, really.

No, it merely requires one new freighter.  One mining colony, one freighter, one route each.  Not every mining colony and every freighter all on the same route.

Mule 001 gets the Phobos run, Mule 002 gets the Ceres run, Mule 003 gets the Hailey's Comet run, etc.

Assigning one ship per mining colony is a lot of overkill on ship construction, and therefore a lot of wasted fuel, unless you either have massive mining colonies, are using small cargo holds (which is less efficient), or traveling a very, very long way to your mining colonies.

One round trip from a standard cargo hold moves 12.5kt of minerals.
A freighter with a standard cargo hold and three 25% power, size-40 Magneto Plasma engines will make a round trip per year at a range of 11.5Bkm, using 52kL of fuel.
Even if it's a 35Bkm trip to your mining colony, this one ship is moving 4.1kt/year.
That's a lot of output for a mining colony, and will quickly strip most colonies, requiring that I move the mines again (and update the freighter orders again).
And that's at a range of 35Bkm. For a mining colony to keep up with one freighter at 10Bkm, I'd have to pull 43kt/year out of the rock.

Really, I'd just rather plop down a MD and point it at my collection station.

I would suggest the "three 25% power, size-40 Magneto Plasma engines" is the problem (by two engines) and that if you add a step to the orders of 'load one automine at [major colony], unload at [new asteroid]' before traveling to [old asteroid] you could reduce order updates.

Or, I don't know, pick better asteroids?  Personally, I get decades out of each automine colony + single freighter run before I have to alter the orders to 'load automine old colony, unload new colony' for a few years then switch again to 'load minreals mining colony, unload minerals major colony' (plus sometimes 'load automine major colony').

Really, I'd just rather plop down a MD and point it at my collection station.

Yes, exactly.  And this is the problem.  Mass Drivers should not be preferable to government freighters.  They should be the choice of last resort, or reserved for cases like the Earth-Luna run where load & unload times for freighters are longer than the transit time from source to destination.
Title: Re: C# Suggestions
Post by: Father Tim on May 03, 2020, 01:22:31 AM
On the Civilian Economy tab, when a colony is designated as "Source of Colonists", I would like to be able to specify a reserved population amount, such that only population in excess of that amount is considered available for relocation.

This would make it much easier to keep civvies from taking too many colonists and leaving too few workers for my installations.
Right now I have to keep a close eye on it, and switch the status back and forth all the time.

Well, if the amount you want to specify is "25 million" you're in luck.  Otherwise, the answer is government colony ships.

Or start blowing up civilians, starving them of funds, tractoring their ships to capture them (if that exploit still exists) or even outright deleting shipping lines.
Title: Re: C# Suggestions
Post by: Scud on May 03, 2020, 02:36:47 AM
In regards to mass drivers vs civilian shipping, I think it’s clear there’s a difference in perspectives. Mass drivers are simple, convenient, and easy to automate. Ships (civilian or otherwise) are extremely difficult to automate at this time. Plopping down a mass driver or two on each AM colony in a system, as part of the initial shipment of mines, is simply good practice because it is painless. Setting up a circuitous route for a cargo ship (or building individual ships for each site) is just much more of an annoyance (this mine ran out, so now I have to delete all the orders... etc) but the additional gameplay depth of having mineral freighters that can be raided or intercepted makes for a better experience.

What about (what I see as) the best of both worlds: A section on the mineral UI under/next to the “mass driver destination” called “civilian freighter destination”, which then lists all colonies with a spaceport. When you select a destination, this creates a constant civilian contract demand to ship minerals to the selected destination. Civilian shipping this way will easily outstrip mass drivers in efficiency and ease of use, once mineral volumes are large enough.
Title: Re: C# Suggestions
Post by: Bubbaisagod on May 03, 2020, 03:38:53 AM
The ability to restrict the ship types civilian shipping lines can build/use.
It is mostly for role-playing purposes; but it would be nice if you can make companies
like ESSO Galactic, Häagen-Dazs Cryo Services or Amazon Cargo that specialize in a specific branch of civilian shipping.

Maybe check-boxes on the "Shipping Line" tab could be implemented without too much work,
similar to the check-boxes on the "Repair Report" & "Detailed Fuel Report" tab.
Title: Re: C# Suggestions
Post by: serger on May 03, 2020, 03:49:33 AM
It's very strange and counter-intuitive, that Racial (Ground Forces) Weapon Strength depends on "Max Size" (caliber) techs, and fully ignores wavelength / retardation / launch velocity / PB range. Why must infantry weapon depend on max sizes of guns, completely not depending on their "quality"? I think it will be much more consistent to make it on the contrary: both infantry and vechicle weapons can be dependent on "quality" tech lines.
Title: Re: C# Suggestions
Post by: Salva on May 03, 2020, 05:36:53 AM
Hi,

not sure if it has been posted, but please, please please:
add a button to disable automatic promotions for all officers, so i do not have to do this for 200 individuals one after the other.

thanks and best regards
Title: Re: C# Suggestions
Post by: smoelf on May 03, 2020, 05:50:35 AM
Ability to change rank theme after race creation.
Title: Re: C# Suggestions
Post by: Migi on May 03, 2020, 07:03:39 AM
Hi,

not sure if it has been posted, but please, please please:
add a button to disable automatic promotions for all officers, so i do not have to do this for 200 individuals one after the other.

thanks and best regards
Automatic promotions can be turned on or off using the game setting "Realistic Commander Promotions".
Game settings is the third button from the left.
If it isn't working then please post in the bug reports thread.
Title: Re: C# Suggestions
Post by: bean on May 03, 2020, 10:31:41 AM
Overall, I really like the new officer system, but I don't think it works as well for things like mining and stabilization as it could.  The problem is that while "you've been promoted, now we're kicking you out to wait for a command at your new rank to come open" is great for warship officers, it doesn't work for officers specializing in other things.  Unless you build a second design with senior commander selected or something, pretty much all of your civilian ships are going to be at your lowest officer level.  So someone who specializes in those things ends up out of a job after they get promoted.  Yes, I could give them a command hierarchy position, but there are a limited number of those, and because the game doesn't actually recognize span of command, at some point, it's actually adding micromanagement and reducing the numbers.  The same happens, to a lesser extent, to survey officers.

So how to solve this?  Add another checkbox to the Ship Design window for flexible command.  This would let the maximum rank on a ship go up to one rank over the minimum.  There's a lot more reason to insist on a strict hierarchy in combat units than in something like a mining operation.

(And yes, I know about the "do not promote" box.  I don't want more micromanagement.)
Title: Re: C# Suggestions
Post by: swarm_sadist on May 03, 2020, 10:50:42 AM
1) The ability to delete prototype components in the class design screen.

2) A message to confirm the game has been saved.
Title: Re: C# Suggestions
Post by: SirCookie on May 03, 2020, 11:06:48 AM
I really like to rebuild Systems from Space Engine in  Aurora, the "problem" i am facing is that the Star attributes are just an average for the Star types, a feature what I would like is to enter my own luminosity, mass, radius, temp etc for the stars.

It would be really great if you could add this possibility.
Title: Re: C# Suggestions
Post by: DEEPenergy on May 03, 2020, 11:23:02 AM
Hostile Flora/Fauna or natives on unsettled habitable worlds that increase the colony cost of a planet until they are pacified by ground forces.
Title: Re: C# Suggestions
Post by: TMaekler on May 04, 2020, 12:51:22 AM
Civilian Mining Colonies are named after the company. But you loose any reference to on what body they have build that colony. It is shown when they found it, but in any of the tabs you then only can see the name of the colony but nowhere the name of the body. Makes it hard to locate.
Title: Re: C# Suggestions
Post by: Black on May 04, 2020, 01:03:31 AM
Civilian Mining Colonies are named after the company. But you loose any reference to on what body they have build that colony. It is shown when they found it, but in any of the tabs you then only can see the name of the colony but nowhere the name of the body. Makes it hard to locate.

In Economics view you can check System Body and it will show the name of the body next to the colony name. But it would be certainly nice to have it in Movement Orders list of bodies.
Title: Re: C# Suggestions
Post by: serger on May 04, 2020, 02:22:40 AM
Automatic promotions can be turned on or off using the game setting "Realistic Commander Promotions".
Game settings is the third button from the left.
If it isn't working then please post in the bug reports thread.

AFAIK (I tested it in 1.9.3), "Realistic Commander Promotions" switches only an influence of Political Reliability of Commanders, not an auto-promotion turns as a whole.
Title: Re: C# Suggestions
Post by: ceselb on May 04, 2020, 03:54:19 AM
A more clear distinction between the names of standing orders for geosurvey vs gravsurvey, please. I keep always selecting the wrong set. It's not at all obvious from the current naming witch is witch.

Speaking of standing orders, how about setting a default standing order that gets applied to all ships unless overridden by changing manually? That would save a lot of clicks.
Title: Re: C# Suggestions
Post by: skoormit on May 04, 2020, 06:56:21 AM
On the Civilian Economy tab, when a colony is designated as "Source of Colonists", I would like to be able to specify a reserved population amount, such that only population in excess of that amount is considered available for relocation.

This would make it much easier to keep civvies from taking too many colonists and leaving too few workers for my installations.
Right now I have to keep a close eye on it, and switch the status back and forth all the time.

Well, if the amount you want to specify is "25 million" you're in luck.  Otherwise, the answer is government colony ships.

Or start blowing up civilians, starving them of funds, tractoring their ships to capture them (if that exploit still exists) or even outright deleting shipping lines.

It's 10 million now in C#. Or half the capacity of the system body, if lower.

And I know what the answer is. I am suggesting that another answer be made available.
Title: Re: C# Suggestions
Post by: skoormit on May 04, 2020, 06:59:00 AM
A more clear distinction between the names of standing orders for geosurvey vs gravsurvey, please. I keep always selecting the wrong set. It's not at all obvious from the current naming witch is witch.

Speaking of standing orders, how about setting a default standing order that gets applied to all ships unless overridden by changing manually? That would save a lot of clicks.

Agree on the wording of those standing orders.

I'd love to be able to define a default standing order per class that would apply to any fleet that contains only ships of that class.
But I suspect that's a relatively large nut to crack, codewise.
Title: Re: C# Suggestions
Post by: Demakustus on May 04, 2020, 08:21:54 AM
I'm happy to see the ruler from VB is back :)
Could we also get a bearing from the start point display next to the distance? Thanks :)
Title: Re: C# Suggestions
Post by: Father Tim on May 04, 2020, 08:43:21 AM
The ability to restrict the ship types civilian shipping lines can build/use.
It is mostly for role-playing purposes; but it would be nice if you can make companies
like ESSO Galactic, Häagen-Dazs Cryo Services or Amazon Cargo that specialize in a specific branch of civilian shipping.

Maybe check-boxes on the "Shipping Line" tab could be implemented without too much work, similar to the check-boxes on the "Repair Report" & "Detailed Fuel Report" tab.


Gord yes!  I have long advocated that civilians should build only one type of ship -- for many reasons, including that my luzury cruise passengers would not be susidizing more infernal CMCs.
Title: Re: C# Suggestions
Post by: Father Tim on May 04, 2020, 08:45:00 AM
Automatic promotions can be turned on or off using the game setting "Realistic Commander Promotions".
Game settings is the third button from the left.
If it isn't working then please post in the bug reports thread.

AFAIK (I tested it in 1.9.3), "Realistic Commander Promotions" switches only an influence of Political Reliability of Commanders, not an auto-promotion turns as a whole.


There is a separate tick box for Political Reliability; the two should have nothing to do with each other.
Title: Re: C# Suggestions
Post by: Father Tim on May 04, 2020, 08:51:06 AM
It's very strange and counter-intuitive, that Racial (Ground Forces) Weapon Strength depends on "Max Size" (caliber) techs, and fully ignores wavelength / retardation / launch velocity / PB range. Why must infantry weapon depend on max sizes of guns, completely not depending on their "quality"? I think it will be much more consistent to make it on the contrary: both infantry and vechicle weapons can be dependent on "quality" tech lines.

It would hardly change anything.  Aurora assumes the two things are equal, and since it is already selecting 'the highest of {group}' adding more elements to the group under consideration would only have an effect if your empire, for example, increased wavelength before increasing size.

A better question is why does ground force weapon strength completey ignore gauss cannon tech?  My empire is in the strange position of having to research a completely foreign weapon to make any progress.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 04, 2020, 09:01:36 AM
Yes, exactly.  And this is the problem.  Mass Drivers should not be preferable to government freighters.  They should be the choice of last resort, or reserved for cases like the Earth-Luna run where load & unload times for freighters are longer than the transit time from source to destination.
I violently disagree with this statement.  If you don't want to use mass-drivers in your games, that is your choice, but don't take them from me, especially before sensible hauling orders for government transports are both available and working.  We can't even refuel a ship reliably yet, let alone set up a logistics train.

1) The ability to delete prototype components in the class design screen.

2) A message to confirm the game has been saved.
An option to automatically save on exit.
Title: Re: C# Suggestions
Post by: Shodan13 on May 04, 2020, 09:36:57 AM
I'd like to see an option (or tech) to reduce jump engine squadron size with a small reduction in hull size.  Currently you can make the self-only jump engine if you go under the racial minimum which doesn't make for very useful drives. 

If I have independently acting ships, I'd like them to have the most efficient (meaning squadron jump size 1) jump engines.
Title: Re: C# Suggestions
Post by: serger on May 04, 2020, 10:03:11 AM
There is a separate tick box for Political Reliability; the two should have nothing to do with each other.

Well, I tested it again, and it works as I mentioned above.
And there are tooltips, discribing how it works correctly.
Title: Re: C# Suggestions
Post by: serger on May 04, 2020, 10:22:23 AM
It would hardly change anything.  Aurora assumes the two things are equal, and since it is already selecting 'the highest of {group}' adding more elements to the group under consideration would only have an effect if your empire, for example, increased wavelength before increasing size.

I don't understand. The two things (caliber-techs and "quality"-techs) are different and are used differently. I prefer medium-caliber quick firing guns, so I'm nearly always stop to research high-caliber techs, while continually researching wavelength techs to inc my lasguns' effective range.

It looks natural, that my infantry will have more efficient guns of the same size (they are not becoming giants, so they have quite the same hand gun sizes) with this progress. But no, in C# Aurora they have not, and to give better guns to my soldiers, I have to research high caliber guns... Why?!

A better question is why does ground force weapon strength completey ignore gauss cannon tech?

Agree. My imagination of best space infantry gun is gauss rifle! But it's the same: better infanry gauss rifle is a gauss rifle with better launch velocity per kg of weapon, not 12-inch caliber of them!
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 04, 2020, 10:45:14 AM
Regarding class design:
Currently Aurora uses a mix of HS and tons to calculate sizes.  This causes headaches when fine-tuning ship designs because 0.01 HS is 0.5 tons.

Suggestion:  Ditch HS entirely and just use tons.

Regarding jump engines:
Military jump drives no longer work with commercial engines.  This causes difficulties when designing jump tenders to support military engined ships, because those tenders can't use fuel efficient engines anymore.  Edit: This is especially painful when trying to support small long range survey ships.  The jump tender tends to wind up over 2500t, which is big enough to need commercial engines to keep pace with the survey ships, leaving it unable to self-jump.

Suggestion:
As Aurora already takes into account both drive types being available to a fleet, allow both a military jump drive and a commercial jump drive on the same ship. 

I'd like to be able to build this:
Code: [Select]
JumpMaster class Gate Builder      84,630 tons       243 Crew       1,606.2 BP       TCS 1,693    TH 0    EM 0
1 km/s    JR 2-25(C)      No Armour       Shields 0-0     HTK 37      Sensors 0/0/0/0      DCR 1      PPV 0
MSP 11    Max Repair 1000 MSP
Kaigun-Ch?sa    Control Rating 1   BRG   
Intended Deployment Time: 3 months   
Jump Point Stabilisation: 180 days

JC100K Commercial Jump Drive     Max Ship Size 100000 tons    Distance 25k km     Squadron Size 2
J3000(3-50) Military Jump Drive     Max Ship Size 3000 tons    Distance 50k km     Squadron Size 3

This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as a Space Station for construction purposes
Title: Re: C# Suggestions
Post by: kenlon on May 04, 2020, 10:57:35 AM
Quote from: Father Tim link=topic=10640.  msg130662#msg130662 date=1588599801
Gord yes!  I have long advocated that civilians should build only one type of ship -- for many reasons, including that my luzury cruise passengers would not be susidizing more infernal CMCs. 

While I don't share Father Tim's seething hatred for the mere idea of private shipping ;D, I do agree that having the various civilian companies specialize would be neat.   Having most lines operate only one category of vessel, with a chance of expanding to others as they get more wealthy would be neat.   

Quote from: Father Tim link=topic=10640.  msg130666#msg130666 date=1588600266
It would hardly change anything.    Aurora assumes the two things are equal, and since it is already selecting 'the highest of {group}' adding more elements to the group under consideration would only have an effect if your empire, for example, increased wavelength before increasing size. 

A better question is why does ground force weapon strength completey ignore gauss cannon tech?  My empire is in the strange position of having to research a completely foreign weapon to make any progress. 

Both of these could be addressed together - make racial ground weapon strength based on the average of your research into one of the weapon categories that are flagged as ground affecting.   I'd vote for railguns, gauss, laser and possibly plasma, personally - the first three have three techs that make sense for impacting ground combat, and plasma has two, making it a little cheaper to research up ground weapons.  I wouldn't want to have to select which weapon type a unit is using, just use whatever option produces the highest number (though throwing an automatic entry in the stat block of an element when it was built showing what category of weapons it's using could be neat for fluff reasons.  )

While this means you won't be as penalized by not researching a specific sub-field, races who invest in all the techs in a type will be better with them than ones who neglect one or more techs, which brings some nice verisimilitude. 
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 04, 2020, 03:19:40 PM
Quote from: Father Tim link=topic=10640.  msg130662#msg130662 date=1588599801
Gord yes!  I have long advocated that civilians should build only one type of ship -- for many reasons, including that my luzury cruise passengers would not be susidizing more infernal CMCs. 

While I don't share Father Tim's seething hatred for the mere idea of private shipping ;D, I do agree that having the various civilian companies specialize would be neat.   Having most lines operate only one category of vessel, with a chance of expanding to others as they get more wealthy would be neat.   

Quote from: Father Tim link=topic=10640.  msg130666#msg130666 date=1588600266
It would hardly change anything.    Aurora assumes the two things are equal, and since it is already selecting 'the highest of {group}' adding more elements to the group under consideration would only have an effect if your empire, for example, increased wavelength before increasing size. 

A better question is why does ground force weapon strength completey ignore gauss cannon tech?  My empire is in the strange position of having to research a completely foreign weapon to make any progress. 

Both of these could be addressed together - make racial ground weapon strength based on the average of your research into one of the weapon categories that are flagged as ground affecting.   I'd vote for railguns, gauss, laser and possibly plasma, personally - the first three have three techs that make sense for impacting ground combat, and plasma has two, making it a little cheaper to research up ground weapons.  I wouldn't want to have to select which weapon type a unit is using, just use whatever option produces the highest number (though throwing an automatic entry in the stat block of an element when it was built showing what category of weapons it's using could be neat for fluff reasons.  )

While this means you won't be as penalized by not researching a specific sub-field, races who invest in all the techs in a type will be better with them than ones who neglect one or more techs, which brings some nice verisimilitude.
Part of the problem that people seem to be having is that the civilian fleets expand too quickly.  Demand limiting would nip that in the bud.  I haven't seen mention of it here, so I'm going to repeat a suggestion from the old VB suggestions thread.

Suggestion:
Track civilian ships' idle time to limit growth.

Suggested method:
For every civilian shipping line keep a counter for each category of ship they operate (freight, colony, liner).
Every time a ship can't find work, increment the relevant counter.
Every time a civilian line considers building ships:
-check the counters to determine eligibility.
-only build categories with counters less than (idle ship limit*production cycles since last check).
-reset counters.

This will limit each line to (idle ship limit) surplus ships per category.
Title: Re: C# Suggestions
Post by: clew on May 05, 2020, 10:40:16 AM
I'm sure this has been mentioned before, but my survey FACs and carriers are really missing a "Refuel from Tanker" conditional order. 

As an aside, the "Refuel from Colony or Hub" does not count local tankers with Refueling Systems if it should.
Title: Re: C# Suggestions
Post by: Black on May 05, 2020, 11:21:24 AM
I'm sure this has been mentioned before, but my survey FACs and carriers are really missing a "Refuel from Tanker" conditional order. 

As an aside, the "Refuel from Colony or Hub" does not count local tankers with Refueling Systems if it should.

Refueling Hub is different component from Refueling System so Refuel from Colony or Hub should only work for ships with Refueling Hub system that is 100000 tons, not very useful for normal tankers.

I agree that Refuel from Tanker order would be welcome, but there may be problem with the fact that tanker can only refuel 1 ship at a time. So there could be problem when more ships arrive at once and that's why we don't have this command?
Title: Re: C# Suggestions
Post by: clew on May 05, 2020, 05:54:22 PM
Quote from: Black link=topic=10640. msg130966#msg130966 date=1588695684
Quote from: clew link=topic=10640. msg130956#msg130956 date=1588693216
I'm sure this has been mentioned before, but my survey FACs and carriers are really missing a "Refuel from Tanker" conditional order.   

As an aside, the "Refuel from Colony or Hub" does not count local tankers with Refueling Systems if it should.

Refueling Hub is different component from Refueling System so Refuel from Colony or Hub should only work for ships with Refueling Hub system that is 100000 tons, not very useful for normal tankers.

I agree that Refuel from Tanker order would be welcome, but there may be problem with the fact that tanker can only refuel 1 ship at a time.  So there could be problem when more ships arrive at once and that's why we don't have this command?

That’s what I figured, thanks for clarifying.

As far as I can tell, if multiple ships have the refuel order simultaneously and are all on the tanker, they just queue up and refuel one at a time.  That’s been my experience with my survey FACs so far.
Title: Re: C# Suggestions
Post by: consiefe on May 05, 2020, 08:17:21 PM
Hi fellows, I'm never getting tired of this great game.   In v1.  80 I created a game and still continue playing it.   It was rather calm as I was doing empire management and slowly building an advanced fleet.   I stumbled upon some precursors and with a few attemps I got close their ships and tore them apart with my 35kt cruisers.   What's bothering me is after I grouped up and come back to wipe clean the system I found all ships camped on the planet and after I swat their size5 ASMs they spammed me with size 1s.   

Actually I made a few save scumming to clarify the situation and oh boy was it annoying.   I really have good gauss turret and some beam pds, few on all ships plus dedicated pd ships plus dedicated AMMs 50k speed.   The size 1 missile spam was so intense when I cheesed my way between two points in an out of range with my fleet actually a real hour passed by and I got frustrated.   They camped all their big ass, like 20k-30k ships and they do nothing but size 1 spam.   One class of their ships has 66x size1 launchers.   It seemed impossible to overcome this nuisance.   

I'm not so experienced in Aurora but I feel I am decent.   I don't know if this is something to look at as an issue but it seemed a bit cheesy to fire 1m size1 amm spams.   My 100 shielded 10 armored 4x8 gaussed 4 cruisers and 4 destroyers plus quad laser turretted ships plus amm ships plus 12k+speedy beam ships, none survives the encounter to close the distance.   With so expensive fleet I didn't get to fire single ammo lol! :)

Edit:

I can always give the same medicine to them as I am more than capable to make 50kt amm spam ship(s) but I really don't want to do that as I don't like that kind of fight.  I can really not think of any other solution than making a ship and a missile just to defeat them as no matter how many PDs I have it doesn't seem to cut it off.  Out of 400-500dmg I eat ~200 of them in one salvo.  No need to say it's very hard on all kinds of PD systems as they have 68k size1 AMMs.  Either a response expressing this is the normal course and behaviour of the enemy AI to deal with it or acknowledging this as an unintended behaviour would be welcomed.
Title: Re: C# Suggestions
Post by: Father Tim on May 06, 2020, 03:31:52 AM
Hi fellows, I'm never getting tired of this great game. . .

So you would prefer doomed ships die quietly with missiles aboard rather than fire off everything they have in a last-ditch attempt to take a few enemies with them?

Do you also wish this behaviour to apply to your own vessels?  Should Aurora skip the battles entirely and simply tell you who won based on tonnage & technology?

Have you gone far enough to witness ramming attempts, yet?

- - - - -

Yes, it can sometimes be annoying to deal with the decisions the AI makes.  Live with it.
Title: Re: C# Suggestions
Post by: TMaekler on May 06, 2020, 03:32:17 AM
The range a tug can operate largely depends upon the tonnage it carries. There is no way to determine the range though. Would be nice to have something that makes it visible how much the range is reduced, once you tug something.
Title: Re: C# Suggestions
Post by: UberWaffe on May 06, 2020, 06:01:26 AM
tl;dr
Change tidal lock of planet into colony cost (from current 0.2 multiplier to maximum population).

Detailed
Instead of directly affecting maximum population of a planet, it is instead treated as a x5 colony cost multiplier.
This is an additional modifier (like "Water Available"or Ätmospheric Pressure" under the environment tab), that is 0.0 for planets that are not tidal locked, and x5 for planets that are.

A new research chain Environmental Processing (Biology) reduces this number (x5.0) for tidal locked planets.
The research should bring it down to around x2.0 in the end.
I.e. a tidal locked planet doesn't have a reduced maximum population, but even if fully terraformed in all other aspects, will still require infrastructure for the population to survive.

Reasoning:
It gives the player some means of overcoming the effect of tidal locking.
Title: Re: C# Suggestions
Post by: skoormit on May 06, 2020, 06:55:44 AM
The range a tug can operate largely depends upon the tonnage it carries. There is no way to determine the range though. Would be nice to have something that makes it visible how much the range is reduced, once you tug something.

What do you have to multiply the weight of the tug by to get the weight of the towed ship?
Add one to that.
That is your range ratio; divide the tugs unladen range by it and you have your laden range for that tonnage.

For example, my 50kt tugs have a range of 200bkm.
They often tow 250kt mining platforms.
250kt is 50kt times 5.
5 + 1 is 6.
200bkm / 6 is 33.33bkm.
Title: Re: C# Suggestions
Post by: Father Tim on May 06, 2020, 07:41:30 AM
The range a tug can operate largely depends upon the tonnage it carries. There is no way to determine the range though. Would be nice to have something that makes it visible how much the range is reduced, once you tug something.

What do you have to multiply the weight of the tug by to get the weight of the towed ship?
Add one to that.
That is your range ratio; divide the tugs unladen range by it and you have your laden range for that tonnage.

For example, my 50kt tugs have a range of 200bkm.
They often tow 250kt mining platforms.
250kt is 50kt times 5.
5 + 1 is 6.
200bkm / 6 is 33.33bkm.

Or, to simplify the math:

mass of tug + mass of payload
-----------------------------------   =   factor by which range of tug needs to be divided
mass of tug
Title: Re: C# Suggestions
Post by: mike2R on May 06, 2020, 09:05:48 AM
It would be nice if an open galaxy map window updated automatically when time advances.  I find I like running from there a lot of the time, but its a minor irritation to have to click refresh to see icons update, or newly discovered systems appear.
Title: Re: C# Suggestions
Post by: skoormit on May 06, 2020, 10:10:25 AM
It would be nice if an open galaxy map window updated automatically when time advances.  I find I like running from there a lot of the time, but its a minor irritation to have to click refresh to see icons update, or newly discovered systems appear.

True, but keep in mind that every auto-refresh of an open window adds a little bit of time to the execution of auto-turns.
Unless Steve can refactor it so that auto-refreshing only happens after auto-turns is interrupted.
Title: Re: C# Suggestions
Post by: mike2R on May 06, 2020, 10:33:29 AM
It would be nice if an open galaxy map window updated automatically when time advances.  I find I like running from there a lot of the time, but its a minor irritation to have to click refresh to see icons update, or newly discovered systems appear.

True, but keep in mind that every auto-refresh of an open window adds a little bit of time to the execution of auto-turns.
Unless Steve can refactor it so that auto-refreshing only happens after auto-turns is interrupted.

Assuming that this is only true if the window is open, I'm not sure that's a problem really.  If you have it open, you're likely willing to take a small hit to have it up to date.  I'd even say refresh during autoturns would be preferable, so you can watch changes as they happen.

Or maybe people with more monitors than I do just leave it open permanently?  I guess that could be an issue.  It shares a monitor with the system map for me, so I only have it open if I'm using it.
Title: Re: C# Suggestions
Post by: TMaekler on May 06, 2020, 11:37:36 AM
The range a tug can operate largely depends upon the tonnage it carries. There is no way to determine the range though. Would be nice to have something that makes it visible how much the range is reduced, once you tug something.

What do you have to multiply the weight of the tug by to get the weight of the towed ship?
Add one to that.
That is your range ratio; divide the tugs unladen range by it and you have your laden range for that tonnage.

For example, my 50kt tugs have a range of 200bkm.
They often tow 250kt mining platforms.
250kt is 50kt times 5.
5 + 1 is 6.
200bkm / 6 is 33.33bkm.
Yes, and some place in the fleet display where this "shorter range" is displayed. Maybe even more. At the moment the ship tugs onto something it calculates the distance to the given target until unlinking and sends a log entry: cannot reach destination with current tug load. Fuel too low :-)
Title: Re: C# Suggestions
Post by: skoormit on May 06, 2020, 02:22:58 PM

Yes, and some place in the fleet display where this "shorter range" is displayed. Maybe even more. At the moment the ship tugs onto something it calculates the distance to the given target until unlinking and sends a log entry: cannot reach destination with current tug load. Fuel too low :-)

Actually, I'd love to see any display of fuel range on the fleet details tab. Right now I have to go down to the ship level to see current range.
Title: Re: C# Suggestions
Post by: smoelf on May 06, 2020, 02:35:03 PM
It would be neat to have some sort of marker in the dropdown list of systems in the mineral search view to indicate which systems contain either normal or populated colonies. It could be either color or a '(C)' after the system's name. That way it will be much easier to quickly find and search those systems which are of interest. Especially since remembering which Luyten I have a colony in can be a bit of a pain.
Title: Re: C# Suggestions
Post by: Shodan13 on May 06, 2020, 02:42:01 PM
ELINT module should be something you build using EM Sensor Sensitivity, it makes no sense that you have to research it separately, but it uses the same tech.
Title: Re: C# Suggestions
Post by: kenlon on May 06, 2020, 02:46:36 PM
True, but keep in mind that every auto-refresh of an open window adds a little bit of time to the execution of auto-turns.
Unless Steve can refactor it so that auto-refreshing only happens after auto-turns is interrupted.

Now that it's not using VB6 anymore, updating open window contents really shouldn't be that expensive in CPU time, in theory. It's possible that something about how Steve has written the display code under the hood will make it problematic to implement, though with no way to look at the source we can only guess.

It would be really nice to have the option to make things update, maybe with a little warning when you first set the option that it may add a small amount of time to turns?
Title: Re: C# Suggestions
Post by: skoormit on May 06, 2020, 09:37:15 PM
True, but keep in mind that every auto-refresh of an open window adds a little bit of time to the execution of auto-turns.
Unless Steve can refactor it so that auto-refreshing only happens after auto-turns is interrupted.

Now that it's not using VB6 anymore, updating open window contents really shouldn't be that expensive in CPU time, in theory. It's possible that something about how Steve has written the display code under the hood will make it problematic to implement, though with no way to look at the source we can only guess.

It would be really nice to have the option to make things update, maybe with a little warning when you first set the option that it may add a small amount of time to turns?

I notice a very big difference in auto-turn speed when I have the econ window open, starting from turn 1.
And I'm not running it on a potato.

So I always close the econ window before starting auto-turns, unless I have a known interrupt coming soon.

Now that the Navy Org window is auto-refreshed with each increment, I close it as well.
Title: Re: C# Suggestions
Post by: serger on May 07, 2020, 03:24:10 AM
Separate event type "Commander health" to different ones:
1) "Commander health" (non-fatal)
and
2) "Commander death"

Because the is no need to react to 1st sub-type, while 2nd sub-type demands players choice of new commander.
Title: Re: C# Suggestions
Post by: davidr on May 07, 2020, 06:17:45 AM
Would it be possible to add a conditional order to Standing Orders for deployment time so that when a vessel is within say 1 or 2 months of its anticipated deployment period an automatic condition could kick in sending the vessel back to a colony for overhaul.

DavidR
Title: Re: C# Suggestions
Post by: dlathro1 on May 07, 2020, 07:42:23 AM
I have three requests for the naval organization window:

1) A button to delete empty fleets, similar to the button to delete empty colonies
2) Have the fleets sorted by the system they are in.  When I have a lot of fleets and I want to find one I usually know what system it is in, but it gets lost in the list of 20+ fleets in the window.
3) Have an order for all parasite ships within the fleet to dock with their assigned mothership.
Title: Re: C# Suggestions
Post by: Father Tim on May 07, 2020, 08:18:41 AM
It would be neat to have some sort of marker in the dropdown list of systems in the mineral search view to indicate which systems contain either normal or populated colonies. It could be either color or a '(C)' after the system's name. That way it will be much easier to quickly find and search those systems which are of interest. Especially since remembering which Luyten I have a colony in can be a bit of a pain.


I'm surprised there isn't -- certainly VB Aurora's mineral report differentiated between bodies with colonies an those without.

- - - - -

Re Luyten:
Turn off Known Stars.  One of my three biggest complaints about it is the proliferation of a small handful of names.  Fifteen Wolfs and twelve Glieses, etc.

Use a naming theme for systems --  not for 'realism' within your fiction but for information control.  Use Roman for everything through the first JP, French for the second JP chain, and Spanish for the third, or something like that.  A coherent naming theme tells you where each system is if done right.
Title: Re: C# Suggestions
Post by: smoelf on May 07, 2020, 08:45:25 AM
I'm surprised there isn't -- certainly VB Aurora's mineral report differentiated between bodies with colonies an those without.

- - - - -

Re Luyten:
Turn off Known Stars.  One of my three biggest complaints about it is the proliferation of a small handful of names.  Fifteen Wolfs and twelve Glieses, etc.

Use a naming theme for systems --  not for 'realism' within your fiction but for information control.  Use Roman for everything through the first JP, French for the second JP chain, and Spanish for the third, or something like that.  A coherent naming theme tells you where each system is if done right.

Well, in the list of bodies it does differentiate with a (C) next to those bodies with colonies on them, but it would be nice to extend it to system selection.

Agreed on known stars. I usually alternate between known and un-known stars, but when using known stars, I find that the game loses a lot of flavor if I use naming themes, even if it makes it harder to keep sane. Although information control is nice (and a good point), at that point I might as well play with un-known stars if I can't readily identify Barnards' Star, Alpha Centauri and Altair.
Title: Re: C# Suggestions
Post by: serger on May 07, 2020, 08:50:10 AM
Add a pair of settings of species description:
1) Age of commission (AOC).
2) Age of retirement (AOR).

To give player some flexibility for designing fantastic races and/or managing plausibility of human race in their campaigns.

Calculate tour length (time between auto-promotion checks) as AOR - AOC / quantity of ranks.
Title: Re: C# Suggestions
Post by: serger on May 07, 2020, 09:09:14 AM
Set default option of position types for Ground Force Commanders in Commanders window to "Ground Forces" (not "Academy commandant").
Title: Re: C# Suggestions
Post by: Eretzu on May 07, 2020, 09:28:16 AM
When prototyping a anti missile fighter, i ended up creating like 10 prototypes.

It would be nice, that if a prototype is not in use, then making it obsolete would just delete it instead.
Title: Re: C# Suggestions
Post by: Father Tim on May 07, 2020, 09:48:45 AM
Add a pair of settings of species description:
1) Age of commission (AOC).
2) Age of retirement (AOR).

To give player some flexibility for designing fantastic races and/or managing plausibility of human race in their campaigns.

Sounds great!

Calculate tour length (time between auto-promotion checks) as AOR - AOC / quantity of ranks.

Sounds terrible!  This should be a box in which we can specify a number of years (or months) like it was in VB Aurora.
Title: Re: C# Suggestions
Post by: Disguy on May 07, 2020, 11:34:51 AM
I have been thinking of doing a campaign where you start with (virtually) nothing but there really isn't any in-game method of doing this. I would like some "rebuilding" civ tech or structure which is highly inefficient. If you have no construction factories I am not aware of how to RP them starting from scratch. I guess you could spawn some Construction Squads but you would need a huge quantity just to build anything.

If ground forces are the only way to do it. It would be nice to have miners, fuel harvesters etc duplicated in troop rolls.
Title: Re: C# Suggestions
Post by: Black on May 07, 2020, 11:49:50 AM
You could use Conventional Industry, it is not very effective.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 07, 2020, 11:53:10 AM
Separate event type "Commander health" to different ones:
1) "Commander health" (non-fatal)
and
2) "Commander death"

Because the is no need to react to 1st sub-type, while 2nd sub-type demands players choice of new commander.
And then only if the commander was assigned somewhere.  If they were surplus then there is no reason to interrupt.
Title: Re: C# Suggestions
Post by: serger on May 07, 2020, 12:48:27 PM
Calculate tour length (time between auto-promotion checks) as AOR - AOC / quantity of ranks.

Sounds terrible!  This should be a box in which we can specify a number of years (or months) like it was in VB Aurora.
I have already proposed it in appropriate tread.
But it can be (AOR-AOC)/QOR by default, if a player haven't specified it manually.
Title: Re: C# Suggestions
Post by: swarm_sadist on May 07, 2020, 01:43:47 PM
Currently trying to create a static galaxy map in SM for a playthrough.

SM anomalies onto a planet, as well as it's type and modifier.
SM Specific ruins, with the option to associate said ruin to current empire, previously specified empire, or randomly.
SM Geosurvey potential
SM add specific spoiler races to a system body
SM Block new JP from connecting to current system
SM Descriptions that can be attached to wrecks, bodies, contacts or systems, which the player is able to see but not modify outside of SM mode.
SM Notes attached to system bodies or solar systems, not visible outside of SM mode.
SM Actions (like SM adding a ground force) based on conditions or trigger events (EG: performing a geosurvey or succeeding an excavation roll)
Title: Re: C# Suggestions
Post by: Erik L on May 07, 2020, 06:19:09 PM
I'd like to see the system numbers on the System window (F9) again.
Title: Re: C# Suggestions
Post by: serger on May 08, 2020, 03:15:33 AM
To prevent massive simultaneous auto-promotions, identical ages of commanders, absolutely identical ground formations and ship crews, and so on, implement some randomization in such functions:

Commander creation
Age = MinimalCommissionAge + Random(0..YearLength) + StartingRankAboveMinimal*MinimalTourTime*Min(YearLength*Random(100%..200%),MaxServiceAge)

Commander auto-promotion
PromotoionSuccess = 50% * ProductionPhaseLength / YearLength

Ground Formation Creation
ActualElementsNumber = Ceiling( TemplateElementsNumber * PopStabilityModifier * Random(90%..100%) )

ShipCreation
CrewGrade = BaseCrewGrade * PopStabilityModifier * Random(90%..100%)

P.S.
Can be combined well with Empire/Species player-customizable parameters like EmpireCalendarYearLength, EmpireMinimalTourTime, SpeciesMinimalCommissionAge and SpeciesMaxServiceAge.
Title: Re: C# Suggestions
Post by: Father Tim on May 08, 2020, 06:10:04 AM
I'd like to see the system numbers on the System window (F9) again.



YES!!!  Oh do I want these back so, SO much.
Title: Re: C# Suggestions
Post by: serger on May 08, 2020, 06:11:27 AM
Mark colonies in Tactical window with some color, different from orbital paths.
(As for me, ideally it would be white or light gray default, Empire-level customizable.)
Title: Re: C# Suggestions
Post by: Father Tim on May 08, 2020, 06:12:04 AM
I have been thinking of doing a campaign where you start with (virtually) nothing but there really isn't any in-game method of doing this. I would like some "rebuilding" civ tech or structure which is highly inefficient. If you have no construction factories I am not aware of how to RP them starting from scratch. I guess you could spawn some Construction Squads but you would need a huge quantity just to build anything.

If ground forces are the only way to do it. It would be nice to have miners, fuel harvesters etc duplicated in troop rolls.


One Conventional Indsutry is enough to get everything going, though you might hit the date limit (December 31st, 9999) if you start that small.
Title: Re: C# Suggestions
Post by: Father Tim on May 08, 2020, 06:29:42 AM
To prevent massive simultaneous auto-promotions, identical ages of commanders, absolutely identical ground formations and ship crews, and so on, implement some randomization in such functions:

Commander creation
Age = MinimalCommissionAge + Random(0..YearLength) + StartingRankAboveMinimal*MinimalTourTime*Min(YearLength*Random(100%..200%),MaxServiceAge)

No, though I agree that starting officers would be better if their ages were 'back-dated'.  Aurora even sets the number of starting officers and crew by multiplying some number (I believe ten) by the rate your academies produce per year; if it instead generated them one at a time and incremented their ages appropriaetly that would be better.

(Here's a work-around:  fire your entire officer corps at game start, and let your Academies send you new people at nice, semi-randomized rate.)

Commander auto-promotion
PromotoionSuccess = 50% * ProductionPhaseLength / YearLength

No.  The current system of promoting the most qualified officer when their is a vacancy is better.  The only reason you see "mass simultaneous promotions" is the identical starting dates (and time-in-grade) for the starting officer corps.  Fix that and the problem goes away.

(See above for work-around.)

Ground Formation Creation
ActualElementsNumber = Ceiling( TemplateElementsNumber * PopStabilityModifier * Random(90%..100%) )

No.  We already have a sizeable faction of players screaming bloody murder about their combat losses causing a pain of micro-management to fix.  I don't want to deal with them complaining about us forcing even their starting units to suffer the same way.

ShipCreation
CrewGrade = BaseCrewGrade * PopStabilityModifier * Random(90%..100%)

No.  First we need to fix the problem of well-trained ships' crews "dissolving" into the crew pool and raising everyone by one-half-of-one-percent.

In the mean time, content yourself with giving every ship a Conscript crew and letting your XOs whip them into (varying) shapes.

P.S.
Can be combined well with Empire/Species player-customizable parameters like EmpireCalendarYearLength, EmpireMinimalTourTime, SpeciesMinimalCommissionAge and SpeciesMaxServiceAge.

Yes, more Race and Empire customization options are always good.  We desperately need varying lifespans (and 'healthspans') for species.

As for calendars, I actually prefer VB Aurora's in-software solution.  I could re-define day & year lengths (and, of course, production cycles) by my homeworld's stats and use negative dates along with six-figure years.
Title: Re: C# Suggestions
Post by: vorpal+5 on May 09, 2020, 03:36:14 AM
I'm creating a new game as per the Garfunkel Protocol (tm), i.e several NPR races on Sol. Garfunkel emphasises on something, when you create the 2nd and subsequent human races, ** you should not ** use the first human race in the dropdown box, but the one from the first race you created (the only player race) on which you modified the race portrait, so you can identify it as the human race to use in races 2+

And indeed, in races 2+ there are 2 human races to choose from, the first one is not the valid one!!

This is quite the bobby trap shall I say! Perhaps Steve can remove this trap?
Title: Re: C# Suggestions
Post by: vorpal+5 on May 09, 2020, 03:42:49 AM
And another interface suggestion. Have a file naming convention for races and flags, like prefixing with an underscore, that make this image reserved for human use, so that no NPR is generated using it.

Quite simple, but would allow for example to have x human portraits in the directory to choose from when you create a game, while being sure the NPR won't be using it (which is a bit killing suspension of belief in many settings, unless you wanted to roleplay lost colonies).
Title: Re: C# Suggestions
Post by: Jorgen_CAB on May 09, 2020, 03:49:43 AM
Could we please... pretty please get a condition for standing order that trigger when a ship reaches its deployment time?

It is really tedious to have to babysit all your survey crafts and make sure they turn home when their deployment time is up. A ship that is "correctly" designed should not need to refuel or resupply before its crew need RnR anyway.

At least give us an interrupt when ships pass their deployment time... right now the turns just blast past any ship that need to return home for RnR.

If we had this as a trigger for conditions I could truly automate survey as I force them home for overhaul which give RnR in the process and then the ship head out again. I should not need to wait for ships stores of MSP to deplete before they head home and give the ships unreasonable deployment rates just so the ships are automated.

In addition to this I also want orders of "refuel & resupply" and "refuel, resupply then Overhaul" for standing orders too. There are no reason why ships would not both refuel and resupply if they get back to port anyway.
Title: Re: C# Suggestions
Post by: smoelf on May 09, 2020, 04:09:54 AM
I would love the ability to create a 'status report' interrupting event.

The idea is that once your empire grows there can be a lot of information to keep track of. I want to go over all the elements regularly, but either I forget when time passes, or I keep reminding myself to check mining status on all colonies or commander assignments so I check too often, which is pointless since time needs to pass for change to happen.

If we could have an event that interrupts every year with a message 'Status report' that would be a nice in-game reminder to check some of these things. If player-created events are too much to ask, then perhaps single event that could be activated at game start by setting the interval. '0' for inactive, '1' for every year, '2' for every other year and so on.
Title: Re: C# Suggestions
Post by: serger on May 09, 2020, 04:16:09 AM
(Here's a work-around:  fire your entire officer corps at game start, and let your Academies send you new people at nice, semi-randomized rate.)

That's what I do every time - recovering civilization from the scratch - because I just cannot believe in this story, if all my commanders of all ranks are 20-agers.
I like to do this, but it's very narrow work-around, I don't think there are more that a handle of players, ready to do such things, even among us, stodgy Aurorians.  :)

No.  The current system of promoting the most qualified officer when their is a vacancy is better.

I mean that's additional check, not a complete random.

The only reason you see "mass simultaneous promotions" is the identical starting dates (and time-in-grade) for the starting officer corps.  Fix that and the problem goes away.

Well, no.
There would be, sometimes, mass simultaneous promotions (after heavy losses, or completing some massive buildup, or smth like this).
It will be cruel to compel players to deal manually with such events more realistically (simulating stretched reaction of their HR Departments) - that is also a cause, that I don't suggest to make randomization of ship- and GF-building: it will be micromanagement nightmare.
But if such events to be - there will be "aftershock" every time: non-randomized auto-promotion will generate secondary wave of promotions every TourLength after that event. Randomized auto-promotion have to stretch it automatically, without adding any micromanagement strain.

No.  We already have a sizeable faction of players screaming bloody murder about their combat losses causing a pain of micromanagement to fix.  I don't want to deal with them complaining about us forcing even their starting units to suffer the same way.

The cause of this pain - is the fact, that new-built formations are ideally fit, and veterans are not.
Make all of them not-ideal, only close to fit - and players will see it as normal state of things (as it is in real life), and it will be micromanagement to deal with very important operations only (as it is in real life, too).
Title: Re: C# Suggestions
Post by: Migi on May 09, 2020, 06:35:46 AM
No.  We already have a sizeable faction of players screaming bloody murder about their combat losses causing a pain of micromanagement to fix.  I don't want to deal with them complaining about us forcing even their starting units to suffer the same way.

The cause of this pain - is the fact, that new-built formations are ideally fit, and veterans are not.
Make all of them not-ideal, only close to fit - and players will see it as normal state of things (as it is in real life), and it will be micromanagement to deal with very important operations only (as it is in real life, too).


What a terrible idea. For the life of my I can't grasp why you want this, do you also want your ships to be built with 89% crew to simulate people not showing up when it's time to leave port? Should that increase if the ship is going on a long deployment? Do you want to receive 93.2% fuel when you do a refuel order because it's easier to leave a little gap at the top of the tanks? Do you want to build an HQ with 30000 capacity only to have it arrive with 29321 because some of the staff officers are off sick?

If I pay for 6000 infantry inside the world of a game I damn well want to receive 6000 infantry not any other number.

Not to mention it would cause a continuously rain of posts in the bugs forum asking "why has my newly built formation has taken combat losses despite never leaving Earth?".
Title: Re: C# Suggestions
Post by: Father Tim on May 09, 2020, 06:46:54 AM
I'm creating a new game as per the Garfunkel Protocol (tm), i.e several NPR races on Sol. Garfunkel emphasises on something, when you create the 2nd and subsequent human races, ** you should not ** use the first human race in the dropdown box, but the one from the first race you created (the only player race) on which you modified the race portrait, so you can identify it as the human race to use in races 2+

And indeed, in races 2+ there are 2 human races to choose from, the first one is not the valid one!!

This is quite the bobby trap shall I say! Perhaps Steve can remove this trap?


The return of the "SM Race" to help with game starts should fix this problem.
Title: Re: C# Suggestions
Post by: skoormit on May 09, 2020, 10:35:57 AM
In the Naval Organization window, I would love to have the option to preserve fleet orders when detaching ships from a fleet.
Maybe another button next to Detach, called Detach with Orders?
Title: Re: C# Suggestions
Post by: kenlon on May 09, 2020, 11:00:48 AM
The cause of this pain - is the fact, that new-built formations are ideally fit, and veterans are not.
Make all of them not-ideal, only close to fit - and players will see it as normal state of things (as it is in real life), and it will be micromanagement to deal with very important operations only (as it is in real life, too).

The solution to "veteran units end up with ragged TO&E after a campaign is over and people don't like it" is not to make newly built units suddenly start missing pieces! Logistics are the cornerstone of a military, and while you should totally end up cramming together ad-hoc formations in the middle of a campaign, once things are over and you get back to friendly territory, putting your units back in order should not require micromanagement.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 09, 2020, 11:15:34 AM
The cause of this pain - is the fact, that new-built formations are ideally fit, and veterans are not.
Make all of them not-ideal, only close to fit - and players will see it as normal state of things (as it is in real life), and it will be micromanagement to deal with very important operations only (as it is in real life, too).

The solution to "veteran units end up with ragged TO&E after a campaign is over and people don't like it" is not to make newly built units suddenly start missing pieces! Logistics are the cornerstone of a military, and while you should totally end up cramming together ad-hoc formations in the middle of a campaign, once things are over and you get back to friendly territory, putting your units back in order should not require micromanagement.
Maybe an option to rebuild a formation to template at a training center, much like ships can be repaired at a shipyard?  If it can be queued then the micromanagement would be greatly reduced.  A default 'rebuild all present units' order would be ideal.
Title: Re: C# Suggestions
Post by: kenlon on May 09, 2020, 11:30:21 AM
Maybe an option to rebuild a formation to template at a training center, much like ships can be repaired at a shipyard?  If it can be queued then the micromanagement would be greatly reduced.  A default 'rebuild all present units' order would be ideal.

Yes, this would be the straightforward way to do it. And also to upgrade units, if there was a way to link obsolete unit classes to their replacements so it knows what to swap out.
Title: Re: C# Suggestions
Post by: Father Tim on May 09, 2020, 11:30:33 AM
Maybe an option to rebuild a formation to template at a training center, much like ships can be repaired at a shipyard?  If it can be queued then the micromanagement would be greatly reduced.  A default 'rebuild all present units' order would be ideal.

Yes, that is what most people suggest so I expect we'll see it sometime in the next couple of months.
Title: Re: C# Suggestions
Post by: smoelf on May 09, 2020, 04:22:15 PM
In the 'Autoroute by System' list, certain systems are colored based on the type of colony they contain. It would be nice if that list would also color systems, in which we don't have colonies but space stations. A temporary solution is of course to create an empty colony in those systems, where we might have a deep space base, but that would be impossible if the space station is located in an entirely empty system.

Perhaps a check could be made for stationary ships with the 'Space Station' tag, while colonies would take precedence in deciding the color of the system name.
Title: Re: C# Suggestions
Post by: Bremen on May 10, 2020, 08:56:47 AM
This may have already been suggested, but the ability to zoom or otherwise scale the galactic map would be handy for those larger games.
Title: Re: C# Suggestions
Post by: skoormit on May 10, 2020, 09:36:49 AM
The auto-assignment algorithm (http://aurora2.pentarch.org/index.php?topic=8495.msg104046;topicseen#msg104046) does not place high enough priority on my ships' non-commander positions (science officer, XO, etc.).

We can fine-tune the auto-assign priority of the commander positions for our ship classes, but the auto-assigner assigns command positions for all ships before assigning any non-command positions.
As a result, I often have to fight with the auto-assigner.
For example, an officer that would be a fine XO, but also has a 5% logistics bonus, will be auto-assigned as captain of some random freighter or tug.

I would like some way to modify this behavior.

Here is perhaps a workable approach:
Under the "Commander Priority" value on the Misc tab of Class design, add a dropdown that has the Primary Assignment Priority groupings and their associated bonus, plus a 10th item:

Code: [Select]
1 Geo Survey or Grav Survey, Bonus: Survey
2 Protection Values > 0, Bonus: Crew Training
3 Military Vessel, Bonus: Crew Training
4 Construction Ship, Bonus: Production
5 Terraformer, Bonus: Terraforming
6 Harvester, Bonus: Mining
7 Asteroid Miner, Bonus: Mining
8 Salvager, Bonus: Production
9 All Others, Bonus: Logistics
10 None

The default selection is 10 None.
If a non-default is selected, auto-assignment will assign non-commander positions for this ship design before assigning commanders of the selected priority group.


Another idea: let me flag a commander for a specific role.
Perhaps a dropdown on the commander details pane next to the checkboxes for "Story Character" and "Do not Promote".
The dropdown contains all of the non-command officer role types (Science, Engineering, XO, etc.), plus a default "None".
If a non-default is selected, auto-assignment will assign this officer to that role, if one is available, before assigning this officer as a ship commander.

Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 10, 2020, 03:17:13 PM
The ability to delete unused hull types from the list.  Alternatively the ability to have selectable hull type themes.
Title: Re: C# Suggestions
Post by: surprise on May 10, 2020, 04:01:59 PM
Minor quality of life suggestion:

Currently, if you train 9 company formations then train a HQ formation, the suggested name is "10th HQ". It would be nice if the ground unit construction tracked the unit numbers (1st Company, etc) by template rather than globally. I think it would be a relatively simple thing to track, and would make unit construction a smoother experience.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on May 10, 2020, 04:09:39 PM
Something I find myself wanting to do ALL the time is double click on ships in the "Logistics" view of the fleet manager to get the map to center on that the fleet with that ship in it.

If you were even more thorough then if you click in the ship you open the fleet view with that ship pre-selected. if you click on the fleet in the same column you just center the map on that fleet instead.

This would be a very good QoL service for me... no I have to manually find where the ship are exactly and then find it in the fleet view among all the task-forces and fleets I have in there.

I think there could be more similar ways of automatic focusing on stuff similar to this throughout the entire game, but this is one view I use often to check for the general status of my ships.
Title: Re: C# Suggestions
Post by: kenlon on May 10, 2020, 05:12:24 PM
The ability to delete unused hull types from the list.  Alternatively the ability to have selectable hull type themes.

I would stab something for hull type themes. Possibly two things.
Title: Re: C# Suggestions
Post by: hostergaard on May 11, 2020, 03:01:36 AM
Some way to select to show only commercial tech like in old aurora and also tech for space stations. Not sure if there is a difference, but I noted some military components can't be put on space stations. Space station can only have commercial components or is there also some commercial ones they can't have and its like its own thing? If so then a button to only display space station components, perhaps when no armor is selected as aparently that is what makes it a space station anyway.
Title: Re: C# Suggestions
Post by: hostergaard on May 11, 2020, 03:07:23 AM
A way to turn prototypes into real tech easily and quickly. Like, this prototype, make it a real tech as I wanna use it and don't wanna fiddle about with options to replicate the damn thing when I have been spending time designing ships and forgot the exact specs. Like, maybe a button in ship design that says something like "Research Prototypes" that turn all the prototypes used in the class into a real design.

In fact, why have prototypes as a separate thing? Why not make all designed tech that have yet to be researched be prototypes automatically? The moment you research them they are not prototypes anymore but real tech, but until then they could work as prototypes do now.

(I post this is in a seperate post, cause I figured it was a separate suggestion and I decided one suggestion per post was best since I do not want it to get it lost to people who skim post, hope that is acceptable. If not then write to me and I will move it all to one post and delete this one)
Title: Re: C# Suggestions
Post by: QuakeIV on May 11, 2020, 03:14:53 AM
A way to turn prototypes into real tech easily and quickly. Like, this prototype, make it a real tech as I wanna use it and don't wanna fiddle about with options to replicate the damn thing when I have been spending time designing ships and forgot the exact specs. Like, maybe a button in ship design that says something like "Research Prototypes" that turn all the prototypes used in the class into a real design.

In fact, why have prototypes as a separate thing? Why not make all designed tech that have yet to be researched be prototypes automatically? The moment you research them they are not prototypes anymore but real tech, but until then they could work as prototypes do now.

(I post this is in a seperate post, cause I figured it was a separate suggestion and I decided one suggestion per post was best since I do not want it to get it lost to people who skim post, hope that is acceptable. If not then write to me and I will move it all to one post and delete this one)

This is supposed to already exist, however I haven't acutally had success with it the one time I tried to use it.
Title: Re: C# Suggestions
Post by: hostergaard on May 11, 2020, 03:23:44 AM
Prototype ships/ship variants In the vein of the previous posts. A way to kinda make prototype ships. I sometimes fiddle about with ships design and often try out multiple designs would enjoy if there where a effective way to say save each design on the fly. To add to this, I always found the whole additional eligible classes to be too arbitrary and I made previous suggestion about designing ship chassis (on which systems could be fitted on later) rather than ships, but perhaps a middle ground could be achieved? What if I could select a ship as base class so to speak, and the click a button to create variants, each variants would then be classed in a submenu under that ships and extended like how ships are classed in submenues according to hulls now. Then when you design variants they would enforce the requirements to be in the same class so you could only select systems in a way that allowed it to eligible to be produced in the shipyard. Having to go between tabs and checking back and forth for every single system changed to see if they were eligible to be produced in the same shipyard was a PITA and made the whole thing egregious in the old Aurora. With a few small changes like this I think it could become a useful QoL feature instead

Edit: Now that I think about it, I haven't checked if the whole additional eligible classes is still a thing in Aurora C#. Then I guess it would be a suggestion on how to implement it.
Title: Re: C# Suggestions
Post by: hostergaard on May 11, 2020, 03:29:18 AM

This is supposed to already exist, however I haven't acutally had success with it the one time I tried to use it.

Okay, thanks, but could you tell me where/how? Tried to find a button like that but I failed so far. But still, I wonder why not make all unresearched tech prototypes? Seems to me that would simplify things, but maybe there is a reason not to that I am unaware of?
Title: Re: C# Suggestions
Post by: smoelf on May 11, 2020, 03:50:20 AM

This is supposed to already exist, however I haven't acutally had success with it the one time I tried to use it.

Okay, thanks, but could you tell me where/how? Tried to find a button like that but I failed so far. But still, I wonder why not make all unresearched tech prototypes? Seems to me that would simplify things, but maybe there is a reason not to that I am unaware of?

Turning a prototype into a researched component is an extra step. Very often I know fairly well which specifications a component needs and I only use prototypes when I am unsure of what would fit in the ship I am designing in terms of size and capability.

Prototypes are marked with a (P) in the class design window. If you select a prototype component, a new button appears called 'Research Prototype'. This change the marker to (RP) and you can now research it in the research window. You have to do it for each individual prototype. A ship that contains a prototype has a (P) after its name, which dissappears after you research the last prototype.

You can also check out SpaceMarine's video on it: http://aurora2.pentarch.org/index.php?topic=11003.msg130029#msg130029
Title: Re: C# Suggestions
Post by: TMaekler on May 11, 2020, 06:55:57 AM
The classes in the class design windows feel obsolete. I usually have one active ship class (occasionally two) in each of them. So it is an unnecessary act to klick on the class to open the respective list - which is one entry long.

Suggestion: If there is only one active entry in a group, don't display the group but instead display the abbreviation of the class in front of the ship class name. And only generate a group if there is more than one active entry (depending if you have obsoletes visible or not. If there are 4 ships in one class but three are obsolete - only show the abbreviation and no group. Only switch to group if obsoletes should be shown.
Title: Re: C# Suggestions
Post by: Cinnius on May 11, 2020, 06:57:22 AM
could you insert a string in the "academies" tab under the "Race Information" window to find out how many crewmen are available at the moment?
Title: Re: C# Suggestions
Post by: pwhk on May 11, 2020, 07:21:24 AM
Actually, I would like to have "# researched techs" and "researched points" in "Race Information" Window too
Title: Re: C# Suggestions
Post by: Shadow on May 11, 2020, 09:12:43 AM
Not sure if it's been suggested yet, but editable fields should be more obvious. At first I thought green text was editable, but that's not always the case, and it's not always readily apparent what is.

While it should be tidier, a quick fix could be to give editable fields an underlined font style.

What do you think?
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 11, 2020, 11:56:59 AM
Class Design window

I know some people wanted the abbreviation after the name, but I'd like an option to put back in front.  I use the abbreviations as a shorthand to quickly find the entries I want.  In that same vein, an option to include the abbreviation in the class list would be helpful for the same reason.

If Race Components is selected both left and right click will add a component.  It would be more convenient if right click instead removed the component.  An alternative would be for right click to bring up a popup where an amount can be entered.

The miscellaneous tab shows remaining build points but not the points about to be spent.  It would be helpful to add an entry showing (class BP*number to build).
Title: Re: C# Suggestions
Post by: Migi on May 11, 2020, 12:26:47 PM
A way to turn prototypes into real tech easily and quickly. Like, this prototype, make it a real tech as I wanna use it and don't wanna fiddle about with options to replicate the damn thing when I have been spending time designing ships and forgot the exact specs. Like, maybe a button in ship design that says something like "Research Prototypes" that turn all the prototypes used in the class into a real design.

Prototypes only show up in the research list when you go to the class design screen, select the prototype in the components list and press the Research Prototype which appears. It might be nice to have a button to research all the prototypes in a given class but personally I don't think I use more than 1 or 2 prototypes at a time.

The reason that prototypes don't automatically show up in the research list is that you might make several prototype components at the same time (eg sensors or engines) and then try and fit the largest one on your ship. The ones you don't use never appear on the research list so you don't have to worry about researching the wrong component.

Quote
In fact, why have prototypes as a separate thing? Why not make all designed tech that have yet to be researched be prototypes automatically? The moment you research them they are not prototypes anymore but real tech, but until then they could work as prototypes do now.

I think your second point could be re-phrased as "When you press the create project button for a component, generate a prototype component with the (RP) designation".
At the moment if you know what you want and create a research project, you can't get access to the component in the design screen without also creating a prototype, but if you create a prototype then you have to hunt it down in the class design screen in order to generate the research project. If you're used to researching every component before you can use it then you probably don't mind that much but if you're new to Aurora then you might see it as a lot of unnecessary clicking.


My suggestion:
Add a button which upgrades the armour but makes the class a prototype. For clarity it would have to be a separate button from the current upgrade armour button.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 11, 2020, 12:56:34 PM
Invaders.  There was some concern in the 1.10.0 changes discussion about limiting invaders.  There are some ways to curb them without being crippling:

1) Prevent invaders from exploring unconnected jump points.  This will prevent them from increasing their own spawn rate through unchecked exploration.
2) Invaders should only consider targets within a certain number of jumps.  If no target is found then they should return to a nearby rift to camp.  If no rift is reachable, the ship should time out.  Timeout could be handled through maintenance failures.
3) Limit the number of invaders that can camp at a given rift.  Larger rifts should support greater tonnage.  Excess campers should either move to a non-crowded rift or despawn.  Despawning should not create wrecks.

There are two failure modes that should be taken into consideration:

1) Returning ships must either always return to their original rift or overcrowded rifts must be able to redistribute.  This is to limit kiting exploits.
2) Rifts should be prevented from excessively flooding a player through redistribution.  Preventing rifts from over-spawning and limiting redistribution range would be sufficient.
Title: Re: C# Suggestions
Post by: Azuraal on May 11, 2020, 12:58:54 PM
In a similar vein to setting commanders as story characters or putting a glass celling on their careeer, could we get an option to set Military rank as manual promotion only or adding strict medal requirements?
Title: Re: C# Suggestions
Post by: QuakeIV on May 11, 2020, 12:59:30 PM
It would be kindof nice if prototypes became researchable as soon as you had the tech to do so.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 11, 2020, 01:05:45 PM
It would be kindof nice if prototypes became researchable as soon as you had the tech to do so.
They aren't researchable automatically for reasons Migi pointed out above, but being able to mark future tech as researchable so they appear in the research tab as soon as their prerequisites are done would be handy.
Title: Re: C# Suggestions
Post by: arty on May 11, 2020, 01:14:07 PM
i post it here again sorry for the wrong place

any chance that terraform get a order to terraform a world to race needs automatic?  without doing every gas yourself ?

thanks arty
Title: Re: C# Suggestions
Post by: QuakeIV on May 11, 2020, 01:26:48 PM
It would be kindof nice if prototypes became researchable as soon as you had the tech to do so.
They aren't researchable automatically for reasons Migi pointed out above, but being able to mark future tech as researchable so they appear in the research tab as soon as their prerequisites are done would be handy.

That would be agreeable to me.  I can understand wanting to have a variety of designs that never get researched, and wouldn't really have any problem ticking a box on my end to get the behavior I want instead.
Title: Re: C# Suggestions
Post by: Father Tim on May 11, 2020, 01:34:37 PM
Minor quality of life suggestion:

Currently, if you train 9 company formations then train a HQ formation, the suggested name is "10th HQ". It would be nice if the ground unit construction tracked the unit numbers (1st Company, etc) by template rather than globally. I think it would be a relatively simple thing to track, and would make unit construction a smoother experience.


I object to this.  It wouldn't improve my quality of life at all; it would wreck it.  I don't want to deal with fifteen different "1st Companies".

To put it bluntly, I think it would be easier for you to rename 10th HQ Co than for me to rename 2nd through 9th.
Title: Re: C# Suggestions
Post by: Father Tim on May 11, 2020, 01:37:50 PM
Class Design window

I know some people wanted the abbreviation after the name, but I'd like an option to put back in front.  I use the abbreviations as a shorthand to quickly find the entries I want.  In that same vein, an option to include the abbreviation in the class list would be helpful for the same reason.


Yes, Gord darn it!  Yes.  If we can't get the hull type and the hull type abbreviation separated into two fields, then put the abbreviations back in front where they belong and sort the list alphabetically by abbreviation, not long name.
Title: Re: C# Suggestions
Post by: smoelf on May 11, 2020, 02:14:02 PM
Minor quality of life suggestion:

Currently, if you train 9 company formations then train a HQ formation, the suggested name is "10th HQ". It would be nice if the ground unit construction tracked the unit numbers (1st Company, etc) by template rather than globally. I think it would be a relatively simple thing to track, and would make unit construction a smoother experience.


I object to this.  It wouldn't improve my quality of life at all; it would wreck it.  I don't want to deal with fifteen different "1st Companies".

To put it bluntly, I think it would be easier for you to rename 10th HQ Co than for me to rename 2nd through 9th.

You wouldn't necessarily have to rename all of them if the numbering is tracked per formation type instead of per unit. Build 10 Companies, and they will be numbered 1st to 10th. Build two HQ Companies and they will be numbered 1st to 2nd. Build 5 Armored Regiments and they will be numbered 1st to 5th. Compare this to the continuous 1st to 17th that we have now. I think that would be a nice feature, but I'm not sure it's worth it.

You might encounter some issues if you start updating or altering existing formations. I don't know how unit and/or formation ID is tracked, but if there is a chance that changing a formation composition (with an updated infantry unit) would also reset the numbering if it's considered a new formation, then the whole exercise becomes much less worthwhile. If it resets just once (or doesn't), when it shouldn't, then there is nothing gained from it.
Title: Re: C# Suggestions
Post by: Father Tim on May 11, 2020, 02:34:00 PM
You wouldn't necessarily have to rename all of them if the numbering is tracked per formation type instead of per unit. Build 10 Companies, and they will be numbered 1st to 10th. Build two HQ Companies and they will be numbered 1st to 2nd. Build 5 Armored Regiments and they will be numbered 1st to 5th. Compare this to the continuous 1st to 17th that we have now. I think that would be a nice feature, but I'm not sure it's worth it.

You might encounter some issues if you start updating or altering existing formations. I don't know how unit and/or formation ID is tracked, but if there is a chance that changing a formation composition (with an updated infantry unit) would also reset the numbering if it's considered a new formation, then the whole exercise becomes much less worthwhile. If it resets just once (or doesn't), when it shouldn't, then there is nothing gained from it.


I would have to rename every single unit after the first.  To be clear, the way I want it to work is exactly the way it works now.  My fifty-fifth battalion -- whatever 'type' it may be -- I want to be my 55th Battalion.
Title: Re: C# Suggestions
Post by: smoelf on May 11, 2020, 02:55:50 PM
I would have to rename every single unit after the first.  To be clear, the way I want it to work is exactly the way it works now.  My fifty-fifth battalion -- whatever 'type' it may be -- I want to be my 55th Battalion.

That's fair. I guess I misunderstood what you meant by 'fifteen different "1st Companies"'.
But since the way it works now means that I (and probably surprise, who suggested it) have to rename every single unit after the first, so I would probably be in favor of a change.
Title: Re: C# Suggestions
Post by: kenlon on May 11, 2020, 03:04:19 PM
I would have to rename every single unit after the first.  To be clear, the way I want it to work is exactly the way it works now.  My fifty-fifth battalion -- whatever 'type' it may be -- I want to be my 55th Battalion.

So your intent is to build all units at the same size and never incorporate them into any sort of hierarchy ever? That sounds suboptimal.
Title: Re: C# Suggestions
Post by: Father Tim on May 11, 2020, 03:38:29 PM
Actually my intent is to not have a "1st Infantry Company" and a "1st Machine Gun Company" and a "1st Mortar Company" and a "1st Headquarters Company" and a "1st Anti-Air Company" and a "1st Logistics Company" and a "1st Transport Company" and a "1st Infantry Battalion" and a "1st Tank Battalion" and a "1st Artillery Battalion" and a "1st Headquarters Battalion" and a "1st Fire Support Battalion" and a "1st Communications Battalion" and a "1st Infantry Division" and a "1st Armoured Division" and a "1st Motorized Division" and a "1st Mechanized Division" and a "1st Mountain Division" and a "1st Marine Division" and a "1st Desert Division" and a "1st Arctic Division" and a "1st Naval Division" and a "1st Jungle Division" and a "1st Swamp Division" and a first any other bloody thing.


I remember the nightmare it was trying NOT to have a system named Le Harve [sic] and how it damn near ruined that empire.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 11, 2020, 05:47:40 PM
I think the issues with naming (ships, fleets, ground forces, etc) all come down to different people having mutually incompatible play-styles and organizational methods and configuring such things to be flexible enough to support such different styles is a fussy problem.  I would suggest using a string interpolation system with a user supplied format string, but it seems C# doesn't support that out of the box and the solutions I could find in a quick search are best described as 'flakey'.

This was one of the better ones:
Code: [Select]
public string Format(string input, object p)
{
foreach (PropertyDescriptor prop in TypeDescriptor.GetProperties(p))
input = input.Replace("{" + prop.Name + "}", (prop.GetValue(p) ?? "(null)").ToString());

return input;
}

Code: [Select]
Format("test {first} and {another}", new { first = "something", another = "something else" })
Title: Re: C# Suggestions
Post by: Migi on May 11, 2020, 06:02:13 PM
Actually my intent is to not have a "1st Infantry Company" and a "1st Machine Gun Company" and a "1st Mortar Company" and a "1st Headquarters Company" and a "1st Anti-Air Company" and a "1st Logistics Company" and a "1st Transport Company" and a "1st Infantry Battalion" and a "1st Tank Battalion" and a "1st Artillery Battalion" and a "1st Headquarters Battalion" and a "1st Fire Support Battalion" and a "1st Communications Battalion" and a "1st Infantry Division" and a "1st Armoured Division" and a "1st Motorized Division" and a "1st Mechanized Division" and a "1st Mountain Division" and a "1st Marine Division" and a "1st Desert Division" and a "1st Arctic Division" and a "1st Naval Division" and a "1st Jungle Division" and a "1st Swamp Division" and a first any other bloody thing.


I remember the nightmare it was trying NOT to have a system named Le Harve [sic] and how it damn near ruined that empire.

I might regret asking but what do you do with your ships? Do you rename them in order of launch date, regardless of class?
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 11, 2020, 06:05:16 PM
Actually my intent is to not have a "1st Infantry Company" and a "1st Machine Gun Company" and a "1st Mortar Company" and a "1st Headquarters Company" and a "1st Anti-Air Company" and a "1st Logistics Company" and a "1st Transport Company" and a "1st Infantry Battalion" and a "1st Tank Battalion" and a "1st Artillery Battalion" and a "1st Headquarters Battalion" and a "1st Fire Support Battalion" and a "1st Communications Battalion" and a "1st Infantry Division" and a "1st Armoured Division" and a "1st Motorized Division" and a "1st Mechanized Division" and a "1st Mountain Division" and a "1st Marine Division" and a "1st Desert Division" and a "1st Arctic Division" and a "1st Naval Division" and a "1st Jungle Division" and a "1st Swamp Division" and a first any other bloody thing.


I remember the nightmare it was trying NOT to have a system named Le Harve [sic] and how it damn near ruined that empire.

I might regret asking but what do you do with your ships? Do you rename them in order of launch date, regardless of class?
Father Tim's system is actually used by many militaries.  The logic is that the divisions are really:
1st Division, Arctic
2nd Division, Desert
3rd Division, Arctic
4th Division, HQ

IIRC that system dates back to the Romans.
Title: Re: C# Suggestions
Post by: skoormit on May 11, 2020, 07:34:17 PM
...I would suggest using a string interpolation system with a user supplied format string, but it seems C# doesn't support that out of the box ...

Really? I think it does (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated).
Title: Re: C# Suggestions
Post by: Gnoman on May 11, 2020, 11:09:14 PM
Minor, but I'd like a "Hull Number" option in the "Name Templates". It would work like the "name plus number", but operate off the hull designation. So instead of something like "Essex 1, 2, 3; Saratoga 1, 2, 3; Forrestal 1", you'd have "CV 1, CV 2, CV 3, CV4, CV 5, CV 6, CV 7".

This would be handy if you're doing something like tiny missile stations or immobile fuel stations.
Title: Re: C# Suggestions
Post by: TMaekler on May 12, 2020, 02:35:35 AM
A special warning message when a story character dies.

Since gameplay is so much quicker in C# Aurora and since commander health is not differenciated from commander death, I quite often happen to miss when my planetary governors die and leave important positions vacant - until I happen to stumble upon it in the planetary display... .

So it would be nice to get a separate warning message for story characters when they die off. That way I can ensure "immediate new elections" :-)
Title: Re: C# Suggestions
Post by: TMaekler on May 12, 2020, 04:30:47 AM
What would you think of the event log as a kind of "notepad"? I am thinking of making event log entries permanently visible through a checkbox. Those whom I check they stay at the top of the eventlog, no matter how many event days are displayed. Good idea?

Also adding manual event log entries would be a nice addon to help remembering things that have to be done next, when saving a game.
Title: Re: C# Suggestions
Post by: Duzzit on May 12, 2020, 04:44:55 AM
I feel a bit bad putting this here because I mentioned it in the bug thread way back when, but if it's not too much trouble I'd like to ask if it's possible to (re)implement a 'research all techs up to X cost' for SM mode? Individually instating all techs after several restarts is not the quickest thing.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 12, 2020, 05:07:30 AM
...I would suggest using a string interpolation system with a user supplied format string, but it seems C# doesn't support that out of the box ...

Really? I think it does (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated).
That was one of the first things I looked at.  It fails for two reasons:  It is static compiled so it can't handle dynamic format strings, and even if it was dynamic there is no way to limit the scope.  Either of these faults by itself would be grounds to reject it outright.

Python's str.format would be ideal, but C# has no built-in equivalent and user-supplied methods seem to either be clunky or require asp.net support.  Something like this:
Code: [Select]
fmt = "This {thing} has {attribute} {feature}."
text = fmt.format({'thing':'cat', 'attribute':'grey', 'feature':'fur'})
Title: Re: C# Suggestions
Post by: UberWaffe on May 12, 2020, 11:12:18 AM
New movement order: Execute Order Template

I would add this as the first entry under the "Order Templates" radio button.
Then the order templates to pick from is listed in the secondary column.

The options for order templates to pick from are the same as would normally appear in that situation under order templates.
The current Order Template looks at the fleet's current position, so this will have to consider their position at that point in their order / movement queue.

When the fleet executes this order, they clear all of their standing orders, and then add the order template to their orders, same as if the player has at that moment went and added the order template.

This order should be able to be part of a template like any other order.

The rough equivalent can currently be achieved by having fleets send messages and then manually adding the order template when the message pops up in the event log.

The above would allow for infinitely repeating trade routes, without spamming repeat, or having to manually intervene from time to time.
Title: Overhauls to resupply ships
Post by: joshuawood on May 12, 2020, 12:06:48 PM
When you overhaul a ship it doesn't resupply, without changing the order system having overhauls resupply ships then you could set survey ships to "If supply points <20 -> go Overhaul" this would fully automate survey ships with the current orders system
Title: Re: C# Suggestions
Post by: bean on May 12, 2020, 12:16:28 PM
Currently, the galactic map uses direct habitability when showing habitable planets in a system, so if you research even colonization cost reduction 5%, every planet that's in the temperature zone but doesn't have a breathable atmosphere instantly turns into a blue dot.  It would be better if it used base habitability (unmodified by the tech) so you can sort the places that have a base cost less than 2.0 from those that are at 2.0.
Title: Re: C# Suggestions
Post by: skoormit on May 12, 2020, 03:27:40 PM
...I would suggest using a string interpolation system with a user supplied format string, but it seems C# doesn't support that out of the box ...

Really? I think it does (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated).
That was one of the first things I looked at.  It fails for two reasons:  It is static compiled so it can't handle dynamic format strings, and even if it was dynamic there is no way to limit the scope.  Either of these faults by itself would be grounds to reject it outright.


The FormattableString  (https://docs.microsoft.com/en-us/dotnet/api/system.formattablestring?view=netcore-3.1)class allows dynamic format strings.
Do we really need string interpolation instead of composite formatting?

Not sure what you mean about limiting scope.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 12, 2020, 04:08:04 PM
...I would suggest using a string interpolation system with a user supplied format string, but it seems C# doesn't support that out of the box ...

Really? I think it does (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated).
That was one of the first things I looked at.  It fails for two reasons:  It is static compiled so it can't handle dynamic format strings, and even if it was dynamic there is no way to limit the scope.  Either of these faults by itself would be grounds to reject it outright.


The FormattableString  (https://docs.microsoft.com/en-us/dotnet/api/system.formattablestring?view=netcore-3.1)class allows dynamic format strings.
Do we really need string interpolation instead of composite formatting?

Not sure what you mean about limiting scope.
FormattableString only takes positional parameters, not named parameters, and requires that all parameters be used.  Optional parameters aren't allowed.  The first is problematic at best and the second is a showstopper.  Think of this as being like environment variable expansion, with Aurora providing a dictionary and the user choosing which entries to include and how to display them.

C# string interpolation has access to all symbols visible from the declared scope.  While that is fine for a programmer supplied immutable string, it is far too broad when using user defined input.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 12, 2020, 07:49:24 PM
A couple of suggestions regarding Civilian shipping lines:
If a line already exists that has no ships, don't create new lines.
If a line has no ships and does not have enough money to build one, it should fold.
Title: Re: C# Suggestions
Post by: Migi on May 12, 2020, 08:08:45 PM
Actually my intent is to not have a "1st Infantry Company" and a "1st Machine Gun Company" and a "1st Mortar Company" and a "1st Headquarters Company" and a "1st Anti-Air Company" and a "1st Logistics Company" and a "1st Transport Company" and a "1st Infantry Battalion" and a "1st Tank Battalion" and a "1st Artillery Battalion" and a "1st Headquarters Battalion" and a "1st Fire Support Battalion" and a "1st Communications Battalion" and a "1st Infantry Division" and a "1st Armoured Division" and a "1st Motorized Division" and a "1st Mechanized Division" and a "1st Mountain Division" and a "1st Marine Division" and a "1st Desert Division" and a "1st Arctic Division" and a "1st Naval Division" and a "1st Jungle Division" and a "1st Swamp Division" and a first any other bloody thing.


I remember the nightmare it was trying NOT to have a system named Le Harve [sic] and how it damn near ruined that empire.

I might regret asking but what do you do with your ships? Do you rename them in order of launch date, regardless of class?
Father Tim's system is actually used by many militaries.  The logic is that the divisions are really:
1st Division, Arctic
2nd Division, Desert
3rd Division, Arctic
4th Division, HQ

IIRC that system dates back to the Romans.

That might be true for divisions IRL but IRL the sub-units of the divisions don't cause the division numbers to increase.
The way Aurora currently works gives you an orderly numbering of units as long as you don't have units in a hierarchy.
I'd be in favour of more options for unit naming and numbering like ships have.
As an aside,  does each level or type of unit have it's own numberline IRL? (I imagine it depends on the country)
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 12, 2020, 08:17:42 PM
Actually my intent is to not have a "1st Infantry Company" and a "1st Machine Gun Company" and a "1st Mortar Company" and a "1st Headquarters Company" and a "1st Anti-Air Company" and a "1st Logistics Company" and a "1st Transport Company" and a "1st Infantry Battalion" and a "1st Tank Battalion" and a "1st Artillery Battalion" and a "1st Headquarters Battalion" and a "1st Fire Support Battalion" and a "1st Communications Battalion" and a "1st Infantry Division" and a "1st Armoured Division" and a "1st Motorized Division" and a "1st Mechanized Division" and a "1st Mountain Division" and a "1st Marine Division" and a "1st Desert Division" and a "1st Arctic Division" and a "1st Naval Division" and a "1st Jungle Division" and a "1st Swamp Division" and a first any other bloody thing.


I remember the nightmare it was trying NOT to have a system named Le Harve [sic] and how it damn near ruined that empire.

I might regret asking but what do you do with your ships? Do you rename them in order of launch date, regardless of class?
Father Tim's system is actually used by many militaries.  The logic is that the divisions are really:
1st Division, Arctic
2nd Division, Desert
3rd Division, Arctic
4th Division, HQ

IIRC that system dates back to the Romans.

That might be true for divisions IRL but IRL the sub-units of the divisions don't cause the division numbers to increase.
The way Aurora currently works gives you an orderly numbering of units as long as you don't have units in a hierarchy.
I'd be in favour of more options for unit naming and numbering like ships have.
As an aside,  does each level or type of unit have it's own numberline IRL? (I imagine it depends on the country)
Point.  Different levels should be numbered independently.  I was still thinking in terms of the old VB system where you are normally only building brigades.  My bad.
Title: Re: C# Suggestions
Post by: hostergaard on May 13, 2020, 04:40:33 AM
Ability to import and export ship, components and other player designed systems. Or anything else relevant. And have it exportable in various usable formats like spreadsheet

I know its complicated with ships for example because of the player designed components not necessarily existing or might not be possible with whatever research level, but with the new prototype feature what if missing components simply got added as prototypes?

And if we get to export ships and designs, maybe make us able to select the export file type? I would love to be able to export my stuff into spreadsheets, I tried to make it work with old aurora but it was quite a mess. So exports like text spreadsheets would be nice.

Lastly, in the same vein, export and import fleet organization? And choose the export format so I can have my spreadsheets?

Hell, just most anything being exportable and importable and in particular formats like spreadsheets would be heavenly and would make things so much easier to set up. Especially early game, it could cut down on the time it takes to set up all the stuff you always set up and let you focus on the parts you like spending time on. Like, I just spend a couple of hours setting up medals. If I could reuse that work it would be absolutely wonderful!
Title: Re: C# Suggestions
Post by: hostergaard on May 13, 2020, 04:59:35 AM
New movement order: Execute Order Template

That gave me an idea!

Ability to add and have fleets execute order templates in standing orders and conditional orders.

Basically, some way to make order templates used as a standing order. So it either default to some costum command or when triggered like any other standing order or conditional order. This would also be helped if we had generalized commands in movement orders. Which would be a nice thing to have anyway. Like, refuel at the nearest colony or tanker a movement order. Would save some work not having to select it yourself. It could be a "location", so to speak, named general orders or something that is always there on top and the default selected on when you open the window. Would be rather handy.

This could further be expanded by allowing order templates to call other order templates. I bet we could set up some rather fancy and snazy behaviors then!
Title: Re: C# Suggestions
Post by: serger on May 13, 2020, 05:33:49 AM
I think I'm unoriginal and reccurrent, but.

Steve, plead to set starting admin levels of civillian administrators to 1, at least if "Realistical promotion" rule is on.

Title: Re: C# Suggestions
Post by: serger on May 13, 2020, 06:20:37 AM
Another feature to help with pushy youngsters:

Empire-level option, smth like "Lowest master rank tier" to make additional realistic and decision-flexible rank system level with Lieutenant as a starting (lowest) rank, not Lieutenant Commander.

That will help greatly with auto-assignments, decomposing small craft (mostly fighters) COs - lieutenants, and larger boats (mostly LACs) COs - lieutenant commanders.

I'll play with even more detailed rank schemes - with Second Lieutenants, to use "Senior C.O." option at my bigger and newer fighters, leaving smallest and oldest to my Second Lieutenants as training wings - in this case I'll set this proposed "Lowest master rank" option to "3".

(Now I'm playing all my campaigns with Lieutenant ranks, but it's quite difficult.)
Title: Re: C# Suggestions
Post by: Aloriel on May 13, 2020, 11:38:50 AM
As I am sitting here doing 36 refits of a frigate to a slightly better one, I found myself thinking that we need a refit queue. These refits take maybe 20-25 days. And so, every 20-25 days I have to click on one of the 5 buttons that brings up the colony info, switch to the shipyards tab, switch to refit, select the ship type to refit from, and click refit for each ship till the slipways are full. NB: I do not have a shipyard that has 36 slipways.

That's quite a lot of clicking and adjusting for the same task over and over again. I would much rather that I could queue up the additional refits. This would lock the ships in place, just as if they were in refit.

On a similar note, we should probably have a queue for production of ships as well.
Title: Re: C# Suggestions
Post by: skoormit on May 13, 2020, 12:57:33 PM
As I am sitting here doing 36 refits of a frigate to a slightly better one, I found myself thinking that we need a refit queue. These refits take maybe 20-25 days. And so, every 20-25 days I have to click on one of the 5 buttons that brings up the colony info, switch to the shipyards tab, switch to refit, select the ship type to refit from, and click refit for each ship till the slipways are full. NB: I do not have a shipyard that has 36 slipways.

That's quite a lot of clicking and adjusting for the same task over and over again. I would much rather that I could queue up the additional refits. This would lock the ships in place, just as if they were in refit.

On a similar note, we should probably have a queue for production of ships as well.

Try the Auto Refit task from the shipyard. It will keep repeating the same refit as long as there are ships available.
Title: Re: C# Suggestions
Post by: skoormit on May 13, 2020, 12:59:03 PM
...And so, every 20-25 days I have to click on one of the 5 buttons that brings up the colony info, switch to the shipyards tab...

Sidenote: double clicking the "refit completed" event will open the econ window to the shipyards tab.
Title: Re: C# Suggestions
Post by: Aloriel on May 13, 2020, 05:13:16 PM
Charts.

I would like charts showing the decline or growth of various resources. Both on a single planet, and over the entire empire. Just a simple line graph where you can see the current quantity of Corundium, or any other mineral or wealth, on Earth over the past month, 6 months, year, 5 years, and 10 years. I'd like to know the trends, and immediate numbers do not give that kind of information.
Title: Re: C# Suggestions
Post by: Cobaia on May 13, 2020, 06:38:38 PM
Hello,

Thank you for sharing this awesome game.

I didn't read the whole thread so here it goes:

Regarding ship components building. We can create the names for the manufacturer of the component. We can create the components by allocating CF.

My suggestion is:
Why not allocate CF to the manufacturers and when you commission a new ship the components are built with the construction rate that was allocated to the manufacturer, it makes more sense since it's not an empire wide task. It is a specific task and the empire should just allocate the CF they want to the private company.

Thank you!
Title: Re: C# Suggestions
Post by: Droll on May 13, 2020, 07:44:31 PM
I use 100s of fighter sized defence satellites in order to provide PPV and AMM defence for my colonies. Of course each one can have an LCR as its commanding officer.

This is problematic because automated assignments considers command assignments a priority above bridge crew assignments (eg Tac Officer). This means that despite having higher officer priority my heavy cruisers and such are being starved of LCR rank tac officers and chief engineers. A workaround is to have senior officer checked but I don't want every cruiser captain to be a commodore - that I want for big boy ships like fleet carriers.

I propose that a - give the player more control over the minimum rank a ship can have, instead of it being the racial minimum have it be the user defined class minimum with the racial minimum as default with all other rules being the same and b - add a checkbox "exclude class from automated assignments" in my case I would do this for my defence satellites and they would never swallow up all my minimum rank officers. Only one of these proposals would be needed to solve the issue I highlighted but they need not be mutually exclusive.
Title: Re: C# Suggestions
Post by: QuakeIV on May 13, 2020, 10:32:57 PM
I suggest that there be a 'change field' button for scientists in the research window in addition to the commander window.  It would make life a lot easier I think...
Title: Re: C# Suggestions
Post by: hostergaard on May 14, 2020, 05:03:10 AM
Designate skill priority for automated assignment

So automated assignment only work for a few things, like warships. But not for for example civilian administrators or naval admin commands. Now, I get that for many of those, it's very situational so it can't automatically assign like it would for example for a terraformer ship where it would just pluck whoever is free with the highest terraforming ability (except, it should be able to figure out it needs to assign administrators with high mining to civilian mining colonies).

But often, while its a per game to game basis, I find that in those games I usually assign the same type to a given assignment. So why not give us an ability to customize automatic assignments? So I can I can tell it to automatically assign whoever have this and this skill to that assignment. Like, say I am terraforming Mars, so I want it to automatically assign administrators with high terraforming skil. Or this academy, I want whoever naval officer with high crew training and so on. Maybe also have a field where we can add a priority number so when there is too free assignment and one commander with the required skills it will choose the assignment with the highest priority.


Have Academy names displayed when selecting academy commandants

Just a minor annoyance. I love the feature that the commandants influence who graduates, and I want to specialise but it quickly becomes a PITA to keep track of. Like, I want my academy on Io to have a ground commander as the leader. Simple enough when I just keep 4 academies. One for each type of leader. But if I want it to specialize into say, ground combat offence it quickly gets impossible to keep track of if I get too many specialized academies. So I noticed I could rename academies and thought "Sweet! I can just name them according to specialization! Awesome! ". But turns out when going into selecting commanders window it display the name of the planet its on, not the name of the academy which makes it somewhat useless. If I could see the name of the academy in the commander window when selecting commandant's that would be nice.


Display what is considered dangerous gasses

As written, I have to kinda guess at what the game consider is dangerous or not and at what level. Having it displayed, say, in the environment tab would be immensely helpful. If not all, then at least the ones actually in the atmosphere of the planet.
Title: Re: C# Suggestions
Post by: Inglonias on May 14, 2020, 03:17:40 PM
The ability to add build a freeform industrial project that does nothing might be handy for role play purposes. You would be allowed to decide what sort of resources would be required to build this project, and be notified when it was done. Other than that, it wouldn't do anything. Handy if you want to RP building something a little weird.
Title: Re: C# Suggestions
Post by: amram on May 14, 2020, 05:41:47 PM
A nice simple QoL suggestion.

When entering a fleet speed via the set speed button, would be great if it automatically unset the use max speed checkbox when you apply the new speed, ensuring that you do actually get that speed in the next increment - even when the user forgets the checkbox exists, as I had.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 14, 2020, 06:46:27 PM
A nice simple QoL suggestion.

When entering a fleet speed via the set speed button, would be great if it automatically unset the use max speed checkbox when you apply the new speed, ensuring that you do actually get that speed in the next increment - even when the user forgets the checkbox exists, as I had.
An alternative would be to grey-out the speed box when Maximum Speed is enabled as a visual cue to the user that it is enabled.
Title: Re: C# Suggestions
Post by: stabliser on May 14, 2020, 08:27:39 PM
I'd like it to be easier to see what body the Cives have setup a CMC on. Once they change the name. its not easy to tell if its a comet or an asteroid or a moon. A knockon effect from that makes it harder to prioritise administrators.
Title: Re: C# Suggestions
Post by: consiefe on May 14, 2020, 09:21:47 PM
I'd like it to be easier to see what body the Cives have setup a CMC on. Once they change the name. its not easy to tell if its a comet or an asteroid or a moon. A knockon effect from that makes it harder to prioritise administrators.

You can click one of the bottom chechboxes to enable system body name next to CMCs.
Title: Re: C# Suggestions
Post by: firsal on May 14, 2020, 11:53:58 PM
It would be great if Commander Auto Assignments could be set to fill all positions, regardless of the commanders having the necessary skills for that position. For example, a commander with no survey bonus can be assigned to a survey ship if this setting is enabled (however, it would prioritize those with survey skills for assignment, as well as respecting officer rank requirements). This would avoid having idle officers loafing around on your homeworld as well as having commander-less ships.
Title: Re: C# Suggestions
Post by: punchkid on May 15, 2020, 05:20:57 AM
With left click on any system body you can center the view on that body. However the center point is calculated by screen size, not the size of the window. Would be nice if it would center the view dependent on the size of your window.

This would be particularly nice for 4k or super wide monitors,
My current workaround is to change my resolution to the size I want the main window(1440p for instance) and then start the game.
After the game has started you can change it back and resize the main window to in my case half my superwide monitor and it will work with the center and zoom etc.
Title: Re: C# Suggestions
Post by: Second Foundationer on May 15, 2020, 01:33:09 PM
I could find several tangential suggestions, but not quite what I'm thinking of. My apologies if this has been posted before. I would wish for the following tweak to conditional refuelling:
     Make a conditional refuel order kick in only if the next non-transit order in the manual order list is not already: refuel (or refuel & resupply) including tankers/stations. Analogously for conditional resupply.
This would make my way of using survey ships much more convenient. And I don't think it would interfere with other ways to use manual and conditional refuel orders. (But if it does: shout 'stop!'.)

Memory may already be failing me as I enjoy C# Aurora more with every version; but I think: this was also the VB6 behaviour.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 15, 2020, 05:35:29 PM
When assigning weapons in the Naval Organization window there are several UI limitations that can make life difficult if you have a large number of weapons on a single ship:

It is not possible to assign targets/PD modes to groups of fire controls.  Instead each control must be assigned a target individually.  This gets tedious when there are more than a few fire controls to set up.

It is not possible to assign multiple weapons to the same fire control at once.  Instead each weapon must be assigned to the control one at a time.  This gets painful when you have a large number of weapons to assign.
Suggestion:  Allow multiple weapons to be selected together so they can be assigned to a control in one drag-and-drop action.

It is not possible to assign missiles to multiple launchers at the same time.
Suggestion:  When dropping a missile onto a weapon, if the shift key is being held then assign that missile to all launchers of the same type in the same group.  Alternatively, dropping a missile onto a fire control should assign that missile to all launchers under that control.

It is not possible to assign missiles to launchers that are not bound to a fire control.
Suggestion:  Allow missiles to be dropped into the Unassigned Weapons list.  Combined with the above it would be easy to set up a large number of launchers at once before assigning them to fire controls.

The weapon list scrolls to the bottom on every drop.  If the list is long then it means that you have to scroll to the top again every time.
The list of Unassigned Weapons opens on every drop.  This is especially tedious when the list of Unassigned Weapons is longer than the screen.
It is not possible to scroll the weapons list while dragging.

Dropping a target, mode, or weapon on a fire control must be on the fire control itself.  It would be more convenient if dropping on anything assigned to a control also counted.

Edit: Show the PD mode as a prefix in the fire control name when its sub-list is hidden.

This came up while assigning weapons on a missile cruiser with 10 MFCs and 100 launchers.  In VB aurora this class was trivial to configure.  Not so in C#.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 16, 2020, 12:44:44 PM
On the tactical map, when civilian fleets are hidden they still show up in a body's right click menu.  It would be better if they are not listed in that case.
Title: Galaxy Map Zooming
Post by: SpaceMarine on May 16, 2020, 01:49:10 PM
Please Steve this one would just help so much, please allow either mouse wheel scrolling or scrolling with buttons (anything is better than now) to the galaxy map as it would make life so much easier in the mid-lategame especially for AARs when you are trying to show off the galaxy, for you it tends to be fine cause you have a really big monitor but for others like me it is quite hard.
Title: Re: C# Suggestions
Post by: stabliser on May 16, 2020, 08:09:19 PM
I'd like it to be easier to see what body the Cives have setup a CMC on. Once they change the name. its not easy to tell if its a comet or an asteroid or a moon. A knockon effect from that makes it harder to prioritise administrators.

You can click one of the bottom chechboxes to enable system body name next to CMCs.

I had clicked that numerous times and never noticed that it had that effect. Thank you.  Theres still a lot to learn.
Title: Re: C# Suggestions
Post by: mike2R on May 17, 2020, 03:20:57 AM
I would really like a "blast anything that comes through that jump point" order right now - it feels like without it, I'm at an unfair disadvantage to the AI.

I'm camping a JP with a jump gate in both directions (so no jump cool down), and the AI is doing the same (or at least had a fleet there last time I poked through).  The AI keeps sticking some ships through the gate, then jumping straight back.  Which doesn't give me time to target them - they appear, I set up targeting and give the open fire command, and they vanish without me firing.  Since they have been doing this repeatedly with the same ships, if I leave the targeting orders in place, I do get to blast them as soon as they appear if they jump through the ships I have already set up targeting for.  But this spams my logs with target not in range reports.  And only works the second time they jump through with the same fleet (which they probably shouldn't be doing anyway - if they didn't like what was here the first time they jumped, they probably shouldn't do it again 6 hours later).

If I jump through, I just get blasted - presumably the AI sets up firing in the same tick.  I'd really like a way to set my ships to use this logic too. 

Or I suppose ideally, have the firing moved ahead of the jumping in the turn order, so I could get a shot at them normally on the turn they jump.  But I imagine messing with turn order involves a lot of other changes.
Title: Re: Galaxy Map Zooming
Post by: Father Tim on May 17, 2020, 02:43:42 PM
Please Steve this one would just help so much, please allow either mouse wheel scrolling or scrolling with buttons (anything is better than now) to the galaxy map as it would make life so much easier in the mid-lategame especially for AARs when you are trying to show off the galaxy, for you it tends to be fine cause you have a really big monitor but for others like me it is quite hard.


Does right-click-drag not work on the Galactic map like it does on the Tactical map?
Title: Re: Galaxy Map Zooming
Post by: SpaceMarine on May 17, 2020, 02:49:47 PM
Please Steve this one would just help so much, please allow either mouse wheel scrolling or scrolling with buttons (anything is better than now) to the galaxy map as it would make life so much easier in the mid-lategame especially for AARs when you are trying to show off the galaxy, for you it tends to be fine cause you have a really big monitor but for others like me it is quite hard.


Does right-click-drag not work on the Galactic map like it does on the Tactical map?

Right-click drag does nothing in either map, so unless you mean left click drag which is just to move around then yes thats in, but that does not allow you to zoom out fully to see the entire map on 1 screen
Title: Re: Galaxy Map Zooming
Post by: Father Tim on May 17, 2020, 05:18:07 PM
Right-click drag does nothing in either map, so unless you mean left click drag which is just to move around then yes thats in, but that does not allow you to zoom out fully to see the entire map on 1 screen


Yes, sorry.  I meant left-click drag to move around.  As far as I know, the galactic map is not zoomable in any way.  It exists at a fixed number of pixels.
Title: Re: C# Suggestions
Post by: JacenHan on May 17, 2020, 06:02:51 PM
Yes, sorry.  I meant left-click drag to move around.  As far as I know, the galactic map is not zoomable in any way.  It exists at a fixed number of pixels.
Hence his suggestion :).

I believe Steve has previously mentioned Galaxy Map zooming as one of the QoL features that fell through the cracks for the C# release, so we can probably expect it to return at some point.
Title: Re: C# Suggestions
Post by: Black on May 18, 2020, 01:33:00 PM
Not sure if this was suggested before.

I would like to have option to hide Habitable-Range Worlds on Galactic Maps that already have my population.

Currently when I select checkbox for Habitable it shows 7 Habitable-Range Worlds in Sol, but they already have colonies and I can use Populated systems checkbox to show me where my population centers are.

I would prefere option to show only Habitables without population so I can plan my next expansion by looking at Galactic map.
Title: Re: C# Suggestions
Post by: endemicslaughter on May 18, 2020, 01:41:08 PM
Quote from: mike2R link=topic=10640. msg133483#msg133483 date=1589703657
I would really like a "blast anything that comes through that jump point" order right now - it feels like without it, I'm at an unfair disadvantage to the AI.

I'm camping a JP with a jump gate in both directions (so no jump cool down), and the AI is doing the same (or at least had a fleet there last time I poked through).   The AI keeps sticking some ships through the gate, then jumping straight back.   Which doesn't give me time to target them - they appear, I set up targeting and give the open fire command, and they vanish without me firing.   Since they have been doing this repeatedly with the same ships, if I leave the targeting orders in place, I do get to blast them as soon as they appear if they jump through the ships I have already set up targeting for.   But this spams my logs with target not in range reports.   And only works the second time they jump through with the same fleet (which they probably shouldn't be doing anyway - if they didn't like what was here the first time they jumped, they probably shouldn't do it again 6 hours later).

If I jump through, I just get blasted - presumably the AI sets up firing in the same tick.   I'd really like a way to set my ships to use this logic too.   

Or I suppose ideally, have the firing moved ahead of the jumping in the turn order, so I could get a shot at them normally on the turn they jump.   But I imagine messing with turn order involves a lot of other changes.

That would be absolutely fantastic
Title: Re: C# Suggestions
Post by: Ulzgoroth on May 18, 2020, 01:51:51 PM
Are they supposed to be able to jump back out the tick after they jump in? That part seems weird.
Title: Re: C# Suggestions
Post by: QuakeIV on May 19, 2020, 01:58:15 AM
It sounds like they are backing out the following tick, for a total of one tick in the system.

I believe its technically possible due to the lack of jump shock since the point is stabalized.  (i have not personally checked if stabalized points actually have that characteristic yet)
Title: Re: C# Suggestions
Post by: serger on May 19, 2020, 02:53:07 AM
1) Implement production tasks with some preparational time and minimal production time (both proportional to BP/RP) for any production and research, in the same way as it works with shipyards.
2) Make production be parallel, if there is more summary factory/reasearch capability allocated, that it can be used to hasten task, considering minimal production/research cycle (preparational time + minimal production time) for this task with current construction tech + admin and/or research leaders skills.
3) Spawn researchers with lesser max labs skill - ideally with starting 1 max lab only.

It will bring following advantages:

1. Less micromanagement requirement with finished production/research, because there will be no more one-by-one trickles of results: nigh-any small production/research will be finished by consignments and we'll manage it by consignments too.
2. Less micromanagement requirement with production/research planning, because if you plan some small production line - this algorithm will calculate max factory size to build this consignment, in the same way as it works with scientist max labs quantity, so you can fill your production capacity with tasks without micromanagement burden. If you have some surplus - you always have an option to load it with some low priority considerable production plan.
3. Less micromanagement temptation-and-exhaustion, because you just cannot build/research things one by one quickly, and so you have to allot your resources as long-time plans and let it do as planned.

I think it combines realism (story-building comfort) with comfort of minimax-style play.
Title: Re: C# Suggestions
Post by: mike2R on May 19, 2020, 05:03:28 AM
Are they supposed to be able to jump back out the tick after they jump in? That part seems weird.

I'm not entirely sure, but I can do it too, so I assume it is WAI on a stabilised jump point.  Weapons do seem to get a cool down however.
Title: Re: C# Suggestions
Post by: serger on May 19, 2020, 05:23:28 AM
Rename "Fleets" to "Task Groups". Because there are task groups, not fleets.
Title: Re: C# Suggestions
Post by: skoormit on May 19, 2020, 06:49:52 AM
Decouple the research rate of technology from the research rate of designed systems, and allow them to be set separately.
That way I can play my 20% research rate game without also needing five times as long to research each new engine.
Title: Re: C# Suggestions
Post by: mike2R on May 19, 2020, 07:07:15 AM
Decouple the research rate of technology from the research rate of designed systems, and allow them to be set separately.
That way I can play my 20% research rate game without also needing five times as long to research each new engine.

I'd like this in the opposite direction as well - I'd quite like to be able to hike the relative cost of designed systems to increase the incentive to reuse already designed parts.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on May 19, 2020, 07:46:51 AM
Ground Formation Refit function

Not sure of this has already been mentioned... but...

A function to "refit" current formation to new technology would be really helpful... there would be a small extra cost and then you update your current formation to the new technological standard of the same components.

Obviously you need to research all the new components in that formation... so a system where you can research new version of every component and link them as upgrades for refit.

Example...

I have a Light Infantry with light personal weapons using weapons 8 and armour 10 technology. I then research level 12 in both and decide to upgrade my light infantry component to Light Infantry Type-2... it is the same component just with a higher tech level.

If I do this with all relevant components in a formation then that formation is selectable for upgrade and I pay a refit cost and the difference in cost between them to refit them with new equipment.

This also should reset their moral back to 100 as they need new training with their new weapons.
Title: Re: C# Suggestions
Post by: Second Foundationer on May 19, 2020, 08:08:46 AM
On top of the great new game-wide option, add options to disable/enable civilian shipping/harvesters individually for each player-controlled race.

This is for the "motor home has racked up some mileage"-longlist: One can work around the global option as it is by deleting any new civilian ship in an empire where they don't fit in (or invent a story to make them fit RP-wise), and I think (?) if you delete the first ships immediately before they produce revenue, any new line should be unable to afford new ones, so it shouldn't take much effort. But it would still be nice to simply have a tickbox in the Race Window.

PS: Still lower priority, as it already becomes still easier in 1.10, see consiefe's reply below. A single empire-wide setting might still be nice after very many miles. – (I've read that changes list at least three times before. Adds "limited perception" to own traits list....)
Title: Re: C# Suggestions
Post by: alex_brunius on May 19, 2020, 08:47:19 AM
Now that it's significantly harder to translate alien languages ( especially if they prove to be hostile ), it would be quite helpful if the check to be in range of a ship could be circumvented in a few other logical situations:

- You captured an alien colony
- You captured an alien colony ship
- You share colonies on the same body with X number of population minimum
- You captured X number of alien survivors from lifepods / ship crews

I feel in all these situations there could be a logical explanation how you can progress learning their language and open communications despite not being in signal contact with one of their ships.
Title: Re: C# Suggestions
Post by: consiefe on May 19, 2020, 09:45:04 AM
On top of the great new game-wide option, add options to disable/enable civilian shipping/harvesters individually for each player-controlled race.

This is for the "motor home has racked up some mileage"-longlist: One can work around the global option as it is by deleting any new civilian ship in an empire where they don't fit in (or invent a story to make them fit RP-wise), and I think (?) if you delete the first ships immediately before they produce revenue, any new line should be unable to afford new ones, so it shouldn't take much effort. But it would still be nice to simply have a tickbox in the Race Window.

Quote
Changes / Additions
Shipping Lines can be deleted


In a week or so, when 1.10 comes out you can do that. How it works remains to be seen but I imagine that's more or less what you say.
Title: Re: C# Suggestions
Post by: Rook on May 19, 2020, 11:28:39 AM
Some suggestions/requests for Troop Handling:
- Add ship/fleet tab with drag-and-drop capability for transferring units between parasites and motherships with troop transport bays, and possibly nearby ships in the fleet.

- Add order "Unload ground unit to ship in stationary fleet". Another handy one would be "Land on assigned Mothership and unload ground unit".

If transfer time between ships is a concern, perhaps the drag-and-drop function could put the fleet in a state similar to Overhaul, where additional orders cannot be carried out. It would be REALLY great if these things could be done while underway, but I'm not certain how that should be handled. Transfer delays for ships underway, but reduced if the transfer is between embarked parasites and/or the mothership(perhaps instant for embarked parasites?).


Regarding parasites:
- Add Fleet information panel regarding parasites assigned to ships in the fleet and their status (embarked, disembarked) and perhaps a temporary status listing for lost parasites.

- The above panel could double as a link to the parasites, so that clicking on one of the listings will take you to the ship's information panel. Or perhaps a right-click, so we don't accidentally bounce around.

- An entry on the ships information panel detailing assigned mother ship, and whether or not the parasite is embarked.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 19, 2020, 05:03:33 PM
An option to specify exact coordinates when creating a Waypoint.  This will help with manually calculated intercepts such as slow tugs trying to catch fast planets.
Title: Re: C# Suggestions
Post by: stabliser on May 19, 2020, 07:49:38 PM
More colour choices for the Labels on the galaxy map.   Of the 16 on offer, 2 are almost the same as the background and difficult to read, some others like grey and silver are quite similar, so our choices seem rather limited.  I guess the step up to 256 colours would do.
Title: Re: C# Suggestions
Post by: TMaekler on May 20, 2020, 02:01:49 AM
How about an extension to the shipyard system. To me in the actual system I have two choices how to design my shipyards: I can either have one for each class or I can design only a few for fitting sized of my ship classes and retool as needed.

I am suggesting a third option. Since we are talking shipyards here a lot of work is being done in a very modular way. So a component is constructed in some place and then assembled in the main assemble area. Somewhat components come together isn’t that relevant to what ship can be assembled but rather the size that can be assembled.

Adding production lines to a shipyard might be an interesting alternative then. So when you first design a shipyard you tool it for one class. Over time new classes can be added to that shipyard - as long as it would fit the size of the shipyard. But adding instead of retooling is more expensive than retooling. So one would end with a shipyard that maybe has three sliplines of 17.000t but that one can build/scrap/retool eight different ship classes.
Title: Re: C# Suggestions
Post by: alex_brunius on May 20, 2020, 05:58:53 AM
How about an extension to the shipyard system. To me in the actual system I have two choices how to design my shipyards: I can either have one for each class or I can design only a few for fitting sized of my ship classes and retool as needed.

I am suggesting a third option. Since we are talking shipyards here a lot of work is being done in a very modular way. So a component is constructed in some place and then assembled in the main assemble area. Somewhat components come together isn’t that relevant to what ship can be assembled but rather the size that can be assembled.

Adding production lines to a shipyard might be an interesting alternative then. So when you first design a shipyard you tool it for one class. Over time new classes can be added to that shipyard - as long as it would fit the size of the shipyard. But adding instead of retooling is more expensive than retooling. So one would end with a shipyard that maybe has three sliplines of 17.000t but that one can build/scrap/retool eight different ship classes.

Yeah this idea has alot of merit IMO, but needs careful balancing to not become the default way of playing. 8 different classes also does seem like quite alot so cost for that needs to be quite significant I think.

A way it could be set up in practice is to use the refit cost already in game so that the more different the classes you try to add in retooling the more expensive it will be to add additional ones.

For example like this:
- Each shipyard must still have a "main" assigned class retooled ( similar to now ).
- You can retool additional classes beyond the main class, but adding classes cost is scaled based on how much they differ from the main class
- This is balanced so that a class just barely not eligible to be built in the same shipyard for no additional cost ( refit being less than 20% of the primary ship class cost rule ) is very cheap / almost free to add as additional retooling.
- An additional cost factor to retooling is added based on how many different classes the shipyard can already build ( including free ones ). For example 10% * classes extra retooling cost.
- Removing capability to build an additional class is free ( to reduce above cost and get rid of obsolete classes / revert having retooled to too many ).


Overall I think retooling could benefit alot from an approach of having it's cost scaled by class difference, since It to me makes little sense that a class that miss the "refit being less than 20% of the primary ship class cost rule" by just a few % should be very easy to adapt the shipyard to building instead rather than costing just as much as retooling to a class twice as large and with zero shared components.
Title: Re: C# Suggestions
Post by: pwhk on May 20, 2020, 08:10:38 AM
I would like to have an interrupt event when a Naval command position is vacant. Considering that we do have an interrupt when such position are manned by under-ranked officers, and a vacant position has the same (in)effect...
Title: Re: C# Suggestions
Post by: wedgebert on May 20, 2020, 01:04:13 PM
It would be nice if we could split out the Retirement and Command Health events into separate events for Unassigned and Assigned leaders.

Retirement
Retirement (Unassigned)
Commander Health
Commander Health (Unassigned)

Even better would be to break it out by leader type

Retirement - Unassigned Ground Leader
Commander Health - Assigned Civ Adminstrator

It can be tiresome as your staff pools grow to hunt through the messages that appear at once to find the one scientist or governor who quit/died among the dozen retiring ground force commanders. This way I could just hide the Unassigned (or better, all the GFC as well)
Title: Re: C# Suggestions
Post by: Droll on May 20, 2020, 08:04:59 PM
Some sort of very expensive Jump point interdictor component would be very cool.

When in range of a jump point (depending on tech), a ship with that component can decide to scramble a jump point, if the JP is stabilized it can either not work or take a while to take effect. If a jump point is scrambled, even jump capable ships would be unable to transit through. This could provide some interesting possibilities for sieging.

In order to prevent indefinite lockdowns of JPs some sort of consequence needs to be present though, maybe the ship in question would need MSP to maintain interdiction.

Basically allowing players and NPRs to mess around with JPs would be cool.
Title: Re: C# Suggestions
Post by: Latrone on May 21, 2020, 05:49:18 AM
Hey Steve, as always thanks for all the work you've put in.  It's amazing.

I was designing a new ground unit and I saw that somehow it's armour rating was higher than a previously designed similar unit.  And then I noticed that it was because of an update in tech.

So I was wondering wheather we could have an "update unit" button for ground formations, in a similar sense to how copy design and update armour work for ships.
It would copy the design of the selected formation, update it's armour and damage and then generate a research project based on that.

All of the old units would just stay the same, but it would really save some time redesigning the same ground forces over and over again.
Title: Re: C# Suggestions
Post by: serger on May 21, 2020, 06:29:10 AM
Log assigned and finished research projects at Scientist's history, the same as it works now with "Releaved from leadership of" event.
Title: Re: C# Suggestions
Post by: UberWaffe on May 21, 2020, 06:51:35 AM
Suggestion
Add repeats to ground survey sites.

Refers to mechanics from this post by Steve: http://aurora2.pentarch.org/index.php?topic=8495.msg107705#msg107705


Repeating ground survey sites
Add a new value to ground survey sites when generated, for number of times the ground survey can be repeated on that planet. (I'll call this Repeats)
Ground survey can repeat as long as the ground survey site's repeats is 1 or more.
Each time the ground survey is completed, the repeats is reduced by 1, and the survey points needed to complete are reset.
When repeats reaches 0 the ground survey potential is exhausted and is removed.


Changes to ground survey completion
The multipliers (Step 2 from Steve's post) based on potential should be reduced.
If a mineral deposit is generated by the ground survey and a deposit of that mineral already exists on the system body, the existing deposit is increased (not replaced) by the amount rolled, and the accessibility is increased by one tenth of the accessibility rolled.
(Sidenote: the current 'replace' approach rewards holding off on doing a ground survey until all deposits are exhausted.)
The "HalfOriginalAmount" and "OriginalAcc" should be increased by the same values.


Increasing difficulty of repeated ground surveys
Add a new number to system bodies, called "Ground surveys completed".
The number of survey points required to complete a ground survey increases by the number of ground surveys already completed on this planet.
The deeper you go, the slower it gets.
So a survey site with a high number of repeats will take a long time to fully survey.


System / Planet generation changes
When generating a ground survey site, roll for number of repeats it has based on diameter and density of planet. (Larger and more dense planets have a higher number of repeats).
On average repeats should be around 3 for a Earth sized / density planet.
3 repeats should give roughly the same total reward (in terms of amount) as a ground survey currently does.
You should end up with the same total bonus amount, but more spread between minerals.
Repeats distribution should be similar to potential distribution. I.e: 3 repeats << 60%, 2 or 4 repeats << 20%, 1 or 5 repeats << 10%, 6 repeats << 6%, 7 repeats << 3%, 8 repeats << 1%.


Add global modifiers for minerals and ground survey potential
Add a game settings global modifier to Mineral abundance. This is a global multiplier. Whenever system abundance is used in a calculation, multiply it by this as well. Default: 100%
Add a game settings global modifier to Ground survey abundance. This is a global multiplier to the frequency of ground survey sites, and the number of repeats per survey site. Default: 100%


Title: Re: C# Suggestions
Post by: skoormit on May 21, 2020, 07:24:44 AM
I would like a way to group fleets within the same admin command, without needing to create a new sub-command.

This is purely for logical grouping--no mechanical effect.
I simply want an additional level of expand/collapse nodes so I can manage the dozens of freighter fleets in my logistical admin command without sacrificing the optimization of my admin hierarchy (right now I have to create parallel commands at the lowest level, using inferior officers).

Maybe call it a fleet group?

Title: Re: C# Suggestions
Post by: alex_brunius on May 21, 2020, 07:18:10 PM
Auto Target MFC/BFC buttons in Ship Combat tab of Naval Organization should probably prioritize assigning military ships as targets to FCs over civilian ship ( assign all available FCs to military ships until only civilian ship are left )
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 21, 2020, 07:38:32 PM
I would like a way to group fleets within the same admin command, without needing to create a new sub-command.

This is purely for logical grouping--no mechanical effect.
I simply want an additional level of expand/collapse nodes so I can manage the dozens of freighter fleets in my logistical admin command without sacrificing the optimization of my admin hierarchy (right now I have to create parallel commands at the lowest level, using inferior officers).

Maybe call it a fleet group?
Or just skip intermediate fleets that don't have any ships in them when working out command bonuses.
Title: Re: C# Suggestions
Post by: skoormit on May 21, 2020, 07:51:39 PM
I would like a way to group fleets within the same admin command, without needing to create a new sub-command.

This is purely for logical grouping--no mechanical effect.
I simply want an additional level of expand/collapse nodes so I can manage the dozens of freighter fleets in my logistical admin command without sacrificing the optimization of my admin hierarchy (right now I have to create parallel commands at the lowest level, using inferior officers).

Maybe call it a fleet group?
Or just skip intermediate fleets that don't have any ships in them when working out command bonuses.

Not sure I follow. When you say fleets do you mean admin commands?
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 21, 2020, 11:01:08 PM
I would like a way to group fleets within the same admin command, without needing to create a new sub-command.

This is purely for logical grouping--no mechanical effect.
I simply want an additional level of expand/collapse nodes so I can manage the dozens of freighter fleets in my logistical admin command without sacrificing the optimization of my admin hierarchy (right now I have to create parallel commands at the lowest level, using inferior officers).

Maybe call it a fleet group?
Or just skip intermediate fleets that don't have any ships in them when working out command bonuses.

Not sure I follow. When you say fleets do you mean admin commands?
Sure.  If I'm not making sense then I should probably go to bed.  Cheers.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on May 22, 2020, 04:08:19 AM
I really would need a "follow at" that don't just include the distance but also the vector.

This way I could tell a fleet to follow another fleet at a specific distance and direction. This would be an immense help when setting up patrols, escort or even when attacking an enemy if you want to do it from a specific direction. But mostly it is about setting up patrols, recon and escort missions.

Right now it is a bit fiddly to do so with way-points as it becomes allot of micromanagement to use picket scouts and so forth...

Title: Re: C# Suggestions
Post by: Froggiest1982 on May 22, 2020, 07:01:55 AM
I really would need a "follow at" that don't just include the distance but also the vector.

This way I could tell a fleet to follow another fleet at a specific distance and direction. This would be an immense help when setting up patrols, escort or even when attacking an enemy if you want to do it from a specific direction. But mostly it is about setting up patrols, recon and escort missions.

Right now it is a bit fiddly to do so with way-points as it becomes allot of micromanagement to use picket scouts and so forth...

Regarding the following command, I've found something odd which wasn't happening in VB6. If you actually manage to reach the followed fleet the command gets erased and you will find yourself standing still. Very annoying. I remember in VB6 you would keep following the selected fleet forever.

I don't know if it's a bug or WAI though

Another problem right now is also that you can't set the speed of ships as that feature don't work so it is very difficult to get picket scouts to follow a fleet unless they have the same speed as the slowest ship in that fleet. This is a big problem right now which make picket scouts very difficult to use.

Currently, when I follow a fleet and I close in at the range I am happy with I just match the speed of the target and avoid this issue. Do you mean the set speed doesn't work? I haven't noticed that.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 22, 2020, 08:34:02 AM
I really would need a "follow at" that don't just include the distance but also the vector.

This way I could tell a fleet to follow another fleet at a specific distance and direction. This would be an immense help when setting up patrols, escort or even when attacking an enemy if you want to do it from a specific direction. But mostly it is about setting up patrols, recon and escort missions.

Right now it is a bit fiddly to do so with way-points as it becomes allot of micromanagement to use picket scouts and so forth...

Another problem right now is also that you can't set the speed of ships as that feature don't work so it is very difficult to get picket scouts to follow a fleet unless they have the same speed as the slowest ship in that fleet. This is a big problem right now which make picket scouts very difficult to use.
To set the speed you have to uncheck 'use max speed'.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on May 22, 2020, 09:56:20 AM
To set the speed you have to uncheck 'use max speed'.

I missed that little detail... very good to know.. that will make my life so much easier now... ;)
Title: Re: C# Suggestions
Post by: Lamandier on May 22, 2020, 10:43:11 AM
Several new modules for ships:

- A mobile repair facility capable of repairing other ships, provided the repairing ship has raw materials and/or MSP on hand
- A mobile MSP production facility
- A mobile ordnance production facility

Apologies if this has already been suggested or discussed/turned down, but I have always wanted to duplicate the 'fleet auxiliaries' depicted in the Lost Fleet series, and those three capabilities are pretty key to the concept, not to mention that it would make fleet logistics much more forgiving.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 22, 2020, 11:48:04 AM
Several new modules for ships:

- A mobile repair facility capable of repairing other ships, provided the repairing ship has raw materials and/or MSP on hand
- A mobile MSP production facility
- A mobile ordnance production facility

Apologies if this has already been suggested or discussed/turned down, but I have always wanted to duplicate the 'fleet auxiliaries' depicted in the Lost Fleet series, and those three capabilities are pretty key to the concept, not to mention that it would make fleet logistics much more forgiving.
There is a maintenance module that handles the 'mobile repair facility' function.  I haven't used them yet so I don't know if they make MSP or not.
Title: Re: C# Suggestions
Post by: Second Foundationer on May 22, 2020, 12:10:31 PM
Could the Intelligence window automatically include the full class summary for the class of an enemy ship that has surrendered?

I seem to remember that intelligence and own ship class summaries (including classes of surrendered survey ships/freighters after home world capture) were also strictly separate in VB6. But it doesn't make much sense after acquisition of an intact ship, does it? Now that the intelligence system and window have been improved in so many other ways, it would be convenient to have all information on enemy ship classes displayed centrally.

(Isolated ship surrender to avoid certain destruction=great feature! Especially when the player-aggressor is a semi-robotic monstrosity that sends 'biology is futile' no-reply messages as standard greeting...)
Title: Re: C# Suggestions
Post by: Egifer on May 22, 2020, 02:59:19 PM
Rewatching Starship Troopers got me some ideas for a new type of ground based hivemind invader NPR that consists of organic ground units.  Think Star Swarm but ground based like arachnids from Starship Troopers for example.

Main idea
What I have in mind is NPR that consists of special ground unit called Hive that will consume planet minerals and generate organic ground units over time.  The hive will also grow over time and consume more minerals, get more armor, fortification and spawn more and higher tier units depending on the current stage.

Hive stages
let's say Stage 1 Hive will consume 1000 minerals annually and produce several company size formations consisting of only warrior class units that can be dealt with by infantry.  While let's say Stage 5 hive will consume 25k minerals ,generate STO units and regiment size formations including Behemoth class units that will require heavy firepower to take down.  And also will be capable of creating Seed ships that upon arriving on another low colony cost planet in system with minerals will deploy into new hive and some basic defence formations.
Also if the planet have colonists, events will be created randomly over time.  I think of something like this: "Arachnid Hive on planet Mars attacked heavily populated region, killing 12 million colonists and destroying 15 financial centers, 120 infrastructure. . . " This will give the player a sense of time pressure unlike Rakhas or Precursors that just sits on the planet doing nothing.  Since if you leave the hive alone for a few decades not only it will deplete the minerals but also grow into later stage that is capable of spreading the hives on potentially populated planets and will become very hard to get rid of if you don't want the planet to become uninhabitable wasteland from all the orbital bombardment necessary to destroy fully developed hive.

Way of generation
-Upon discovering new system with comets and planets with colony cost < 2, there will be chance that the comet carry a dormant hive to simulate interstellar seed comet since I don't really like the idea of organic ships with jump engines.  Upon detection of the player ship near the comet the hive will enter stage 1 and will start it's growth cycle.  As Stage 1 hive, it will be considerably easier to deal with so the player will have to deal with it soon if he doesn't want to let it spread.  Mainly for some early game challenge.
-Chance of generating new comet containing dormant hive in already discovered systems In great distance from the center like 100b km from Sun. 
-Lower chance of higher stage dormant hive on low colony cost moons, planets for some mid to end game challenge.

Spreading of hives in system of origin
- Last stage of hive will generate heavily armored and fast seed ships let's say every 10 years (maybe making a new parameter in the new game creation menu to change the difficulty) that will choose random planet, move to it and deploy into hive. 
-The ship can also be a special mass driver packet that can be shot down upon detection but I am not sure how hard it would be to implement.

Spreading outside of system of origin
Allowing the hives to spread to other system would make for a proper NPR type but inability to create proper military ships would make it easy to contain in system by camping the gates or deploying mines on them.
Maybe combining Star Swarm and this new type of new NPR would be the way by allowing the last stage hives to generate Star Swarm motherships.

implementation
-I am not sure how hard it would be to implement hives as special type of ground units that generate new units, seed ships.  The hive unit could also be unique NPR only ground force construction complex renamed as Hive but those are easily destroyed.
-organic units can either be unique NPR only military units with defined parameters and unique component like claws, mandibles, plasma discharge that is not dependent on research since this type of NPR would depend more on quantity then quality.  This is mainly for RP reasons but could be left as a standard units.
-seed ships can be ordinary ships with lot of armor, speed and troop transport carrying the hive unit and some formations for defense.
-Could also work only though special events like "Arachnid Hive on Oumuamua successfully deployed new hive.  Estimated target is Mars with ETA of 48 days".  Destroying all the hives in system would halt these events for good.

Well that's my idea for new type of NPR.  I hope that this will give Steve at least some ideas for new content in later versions.
Title: Re: C# Suggestions
Post by: UberWaffe on May 23, 2020, 08:34:16 AM
New fleet order: Load all ground units of template X

tl;dr: Acts like "Load Ground Unit", but targets a template Id instead of a specific ground unit Id.

Under "Movement Orders" -> "System Locations" -> "Any system body" add a new order namely "Load all ground units of template X"
Condition: Fleet must have troop transport capacity.

As a secondary parameter, it lists all Ground Unit templates you have, and you select one.
The fleet will attempt to move to the location and load all ground units it finds that are of the selected template.
The fleet will attempt to load as many of these ground units (of the selected template), until there are none left of planet, or the fleet troop capacity has insufficient space remaining.

Insufficient space results in the fleet generating an interrupt message "Insufficient capacity to load ground unit of target {template} from {system body}". Where {template} is the target template name and  {system body} is the target location of the order.
If no ground unit of the picked template is found, fleet generates an interrupt message "Cannot find ground unit of {template} to load on {system body}".

It shouldn't worry about if the template is complete or not. As long as the ground unit is of that template.
(Orders for moving specific ground units already exist for cases like that.)

Reason: This would greatly help with setting up large bulk move troop orders, or repeating orders of moving multiple troop divisions.
Need to move 50 construction divisions to that new colony with only 1 small transport ship? Load by template and spam repeat.
Need to load your fleet of 100 assault transports with genetically engineered deus vult? Target your fortress world and do so in a single order.
Title: Re: C# Suggestions
Post by: unkfester on May 23, 2020, 03:41:00 PM
will destroying Stabilisation Gates be a thing? so you could contain NPRs. Just a thought
Title: Re: Screen Resolution
Post by: Froggiest1982 on May 23, 2020, 04:16:34 PM
yeah sure guys, never wanted to add you more jobs!

i have a computer attached to the TV, so theres no problem to play normally, only wanted to know if im outside with my old laptop. :)

only wanted to know if theres any way to change it easily :)

you may want to have have look into the FAQ.
Title: Re: C# Suggestions
Post by: QuakeIV on May 24, 2020, 08:50:44 PM
What about shipyards that are pre-planned in size?  My general understanding is usually slipways don't generally change size in reality once built, and while that doesn't have to apply to aurora, it might be an interesting gameplay aspect if building a significantly bigger slipway was actually a big revolution for your civiliation's shipbuilding capability, where you otherwise are pretty much confined to what is already built in terms of ship size (rather than the slow increase in size that currently exists, which you can even do without disrupting the current ship production run).
Title: Re: C# Suggestions
Post by: the obelisk on May 25, 2020, 02:45:35 PM
Some kind of SM option to turn an NPR into a player race would be cool, if that's feasible.

will destroying Stabilisation Gates be a thing? so you could contain NPRs. Just a thought
The switch from describing it as jump gate construction to jump gate stabilization was, if I remember correctly, specifically because Steve does not want it to be possible to undo the connection (outside of SM mode).
Title: Re: C# Suggestions
Post by: stabliser on May 25, 2020, 07:24:09 PM
Artificial planets, ringworlds and Dyson spheres. (on a 2d solar system map is there a difference)

I'm sure it wouldn't be simple to do, but these extremely rare worlds would be wonderful to find.  Obviously they are constructed by ancient aliens, who may well still inhabit them.
Since they occupy an entire orbital path, where would our fleets target as a landing? would there be multiple landings?  would they have multiple colonys?  what absolutely huge population cap would they have?   This is a crazy idea right?
Title: Re: C# Suggestions
Post by: QuakeIV on May 25, 2020, 11:06:33 PM
Not clear how to do them properly but probably could be fun.
Title: Re: C# Suggestions
Post by: stabliser on May 26, 2020, 06:49:21 AM
Perhaps Dyson-spheres could be restricted to replacing the second star in a binary as if they have completely enclosed it.  That might make them seem boringly like a very very large Planet X and not worth the effort though.

Or suppose a Ringworld was displayed as 90, 180, 360 or 720 bodies on a single orbital ring, all close to colonisable and likely already occupied by precursors.  Would that be fun or just tedious.  They would not have minerals to mine since they're not naturaly formed, but potentially 1000s of ruins to explore... at each.   They must be very rare, perhaps even excluded from SM creationg to keep them super rare.

If a rift touches them do they disintegrate in some way.
Can ground units move around the ring.

I think I just want to know theres always something new to find out there in Aurora.
Title: Re: C# Suggestions
Post by: sneer on May 26, 2020, 07:01:07 AM
please think about minerals needed for dyson sphere (size!!!) and than you will see even biggest player empires are not even close with mineral extraction to start such project
Title: Re: C# Suggestions
Post by: stabliser on May 26, 2020, 07:15:12 AM
I wasnt suggesting that players should be able to build them... although ;)
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 26, 2020, 07:44:58 PM
1.9.5 Class Design window

Components and classes that use prototypes are flagged with (P), but there is no such notification for obsolete components or the classes that use them.  It would be helpful while upgrading a fleet if such were clearly marked.

Suggestions:
In the Class Components list, flag obsolete components with (O).
In the hull list, flag classes that include obsolete components with (O).
If both flags apply to a component or class, use the mark (OP).
Title: Re: C# Suggestions
Post by: Borealis4x on May 26, 2020, 08:23:07 PM
Would having Deep Space habitats be possible? I'd like to develop systems that are empty beyond just placing a gas station.
Title: Re: C# Suggestions
Post by: wedgebert on May 27, 2020, 09:45:01 AM
This might be a little complicated for the general suggestions thread (and possibly suggested before), but here goes with advanced Standing and Conditional Orders.

Instead of having a Primary and Secondary Standing/Conditional Order, let us add as many as we desire in a priority queue.

For example, my grav/geo survey ship could have the following orders configured


Theoretically, this would have the ship survey all systems until there were no more geosurveys to be done, then move to the next unexplored system and continue the process.

Likewise, the conditional orders could be set up like


Again, in theory this should tell the ship to return to a colony when supplies or fuel are low, at which point it will refuel, resupply, and overhaul (in a particular order to account for Overhauling not refueling and resupplying). Likewise, if it encounters a hostile force, it retreats home.

Even better would be for the Fuel and Supply Point conditions to be consolidated into Fuel less than X% and Supply Points less than X% so I could say to return home when supply points are less than 35% to provide a bigger safety net.

Finally, a nice to have might be to have multiple orders per condition. So using the previous example, I could say

Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 27, 2020, 06:04:31 PM
For standing orders and conditional orders there isn't much of a limit on what would be useful, so the list can be expected to grow indefinitely.  There are also times when the orders in that list would be handy from the movement list.  A better solution might be to make those unique automatic orders (refuel from colony or hub, etc) available as regular orders, and then make standing and conditional orders use order templates.  Such a system should be both easier to manage and more flexible than the current approach.
Title: Re: C# Suggestions
Post by: vorpal+5 on May 28, 2020, 01:57:44 PM
There are a lot, and really a lot of names themes in Aurora ...

And some of them might feel silly, or useless. It depends of the player, but I'm sure most of you, if you were to browse the entire list, would say that some lists, you would never use them. And probably you would prefer not having a NPR use them either.
Or perhaps you feel a list is too short so not good to use.

So here is my suggestion. Have a txt file in the Aurora directory, this is  the list of excluded lists of names, that the player wants to be ignored by Aurora.

So for example, if I find that 'Ukrainian Birds' is not a list I want to see, for whatever reasons (no offense toward Ukrainian birds  ;D  ) then I would add the list name in the txt file and Aurora would not show it as a possible list.

That would allow also some 'sanitization' I believe. We just can't have all possible lists submitted by everyone appears in the game, this slow browsing the lists you might be interested in.
Title: Re: C# Suggestions
Post by: wedgebert on May 28, 2020, 02:55:25 PM
There are a lot, and really a lot of names themes in Aurora ...

And some of them might feel silly, or useless. It depends of the player, but I'm sure most of you, if you were to browse the entire list, would say that some lists, you would never use them. And probably you would prefer not having a NPR use them either.
Or perhaps you feel a list is too short so not good to use.

So here is my suggestion. Have a txt file in the Aurora directory, this is  the list of excluded lists of names, that the player wants to be ignored by Aurora.

So for example, if I find that 'Ukrainian Birds' is not a list I want to see, for whatever reasons (no offense toward Ukrainian birds  ;D  ) then I would add the list name in the txt file and Aurora would not show it as a possible list.

That would allow also some 'sanitization' I believe. We just can't have all possible lists submitted by everyone appears in the game, this slow browsing the lists you might be interested in.

I would go on further and say just move all name lists to external files (be it text or json or whatever is best). This could be themes, hull types, company names, etc. When you start a new game, it would load all files and show them in-game as normal. You don't like a theme? Just delete (or move) the corresponding file. Likewise if you want to add your own or edit an existing, it would be easy. Players could even easily trade them between themselves.

I know there's an option to import themes, but this seems like a more flexible solution that doesn't require manual work once the files are the way the player wants them.
Title: Re: C# Suggestions
Post by: DFNewb on May 28, 2020, 07:56:57 PM
Some sort of way to "repair" or "refit" ground unit formations into a formation template.
Title: Re: C# Suggestions
Post by: Borealis4x on May 28, 2020, 09:49:50 PM
Adding an a command layer in-between TG commanders and Admin commanders. These commanders are mounted on ships and their command skills are passed down to any TG assigned to them in the same system.

Title: Re: C# Suggestions
Post by: vorpal+5 on May 28, 2020, 10:25:43 PM
Some sort of way to "repair" or "refit" ground unit formations into a formation template.

Perhaps a button where if you select a formation, you are being asked which one it should refill, and it would transfer elements from formation A into formation B automatically and correspondingly to the template?
Easier said than done!
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 29, 2020, 12:51:10 AM
I can see some possible use cases to handle mangled/obsolete formations:
An option to swap units with another formation to meet a template.  This could also be used to quickly reorganize existing formations in the field.
An option for a training center to replace any missing units in an existing formation.  Bonus points if the replacement cohort can be built for a formation that is at another location, to be transported and merged on site.
An option for a training center to refit existing units to a new type.
Title: Re: C# Suggestions
Post by: firsal on May 29, 2020, 05:59:47 AM
Minor QoL feature, it would be great if we could have the "Hide Civilian Contact Names" option on the Display window back. It really declutters the system view while still being able to see civilian shipping (and watch the trade convoys pass by)
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on May 29, 2020, 08:21:52 PM
Minor QoL feature, it would be great if we could have the "Hide Civilian Contact Names" option on the Display window back. It really declutters the system view while still being able to see civilian shipping (and watch the trade convoys pass by)
Contacts tab, uncheck 'Civilians'.

It would be nice to be able to create a system in SM mode without passing knowledge of it to the player,  and have the ability to delete knowledge of a system from a player.  This would allow two player races in different systems to start without any knowledge of each other, even if one of them starts in Sol.
Title: Re: C# Suggestions
Post by: Migi on May 29, 2020, 09:54:18 PM
I can see some possible use cases to handle mangled/obsolete formations:
An option to swap units with another formation to meet a template.  This could also be used to quickly reorganize existing formations in the field.
An option for a training center to replace any missing units in an existing formation.  Bonus points if the replacement cohort can be built for a formation that is at another location, to be transported and merged on site.
An option for a training center to refit existing units to a new type.
I think the refit and repair tasks which shipyards do could be a model for this.
You repair a formation by telling the GFCC what formation to start with and what you want it to end up as, it just builds the difference and adds them automatically.
I'm less keen on building replacement formations and shipping them around but it would probably make more people more happy if that was an option.


On an unrelated note, can we get a default Field Position for each template?
I don't think I'd ever want my artillery formations in the front line while the divisional logistics units want to be in the rear.
If I could have them automatically take up the appropriate support or rear position it would save a bunch of clicking.

A way of mass selecting and assigning formation position would also be nice and probably a good substitute for the above.

Also for STO targeting, could we get a default target or mass assign for them? (STOs designed as PD weapons are probably going to want one of the PD options)
Also the STO targeting tab would be better if you had the option to group them by system and body like the normal ground units tab.
Also could we get an option to target the closest ship?
Also (final one I promise) what is the difference between Final Defensive Fire and Final Defensive Fire Self? (I know what it does in the context of ships but I don't see the point for STOs)
Title: Re: C# Suggestions
Post by: serger on May 30, 2020, 02:02:20 AM
Make CMC reach range determined by current tech level (with the same tech, that determines velocity of mass driver's mineral packets; now this reach range is 80 AU constant).
Title: Re: C# Suggestions
Post by: firsal on May 30, 2020, 04:36:26 AM
Minor QoL feature, it would be great if we could have the "Hide Civilian Contact Names" option on the Display window back. It really declutters the system view while still being able to see civilian shipping (and watch the trade convoys pass by)
Contacts tab, uncheck 'Civilians'.

It would be nice to be able to create a system in SM mode without passing knowledge of it to the player,  and have the ability to delete knowledge of a system from a player.  This would allow two player races in different systems to start without any knowledge of each other, even if one of them starts in Sol.

No, what I'd like is to be able to see the blue dots that mark the location of civilian ships without the TG names attached. Using this option hides civilians completely.
Title: Re: C# Suggestions
Post by: wedgebert on May 30, 2020, 09:24:11 PM
I'd be nice to be able to use ground force templates to build other templates.

For example, I might define what makes up an infantry platoon (or even a squad), but those size units are way to small be of use, so I want to make an infantry company that is made up of three infantry platoons which is made up of three rifleman squads and a heavy weapons squad.

So I go to the template and add those templates to it and it just adds the appropriate unit numbers to my company. Maybe even have a special non-buildable template that is just there for this kind of design
Title: Re: C# Suggestions
Post by: plasticpanzers on May 30, 2020, 10:32:24 PM
A Suggestion, if not already brought up, to be able to pick a color for you planets, colonies, and outposts in the system maps so you can pick them
out of the background jumble.
Title: Re: C# Suggestions
Post by: Borealis4x on May 30, 2020, 11:04:57 PM
A special message that appears when an Admin Command or a colony/sector loses a leader would be nice. Right now you have to scrutinize every retirement to make sure they weren't assigned to something, and most of the time I can't see it cuz the words don't fit on my skinny secondary monitor. 

Of course, being able to set automatic assignments for those jobs would be most  ideal.
Title: Re: C# Suggestions
Post by: Iceblade02 on May 31, 2020, 02:14:39 AM
Quote from: BasileusMaximos link=topic=10640.   msg135541#msg135541 date=1590897897
A special message that appears when an Admin Command or a colony/sector loses a leader would be nice.    Right now you have to scrutinize every retirement to make sure they weren't assigned to something, and most of the time I can't see it cuz the words don't fit on my skinny secondary monitor.     

Of course, being able to set automatic assignments for those jobs would be most  ideal.   

To expand upon this - being able to hide events affecting non-assigned officers.    I may have hundreds o unassigned officers, but I really want to know when something happens to the few dozen important ones.   

As someone on the discord so eloquently put it:

"I really don't care if Jack Sparrow who takes extended holidays and is never employed gets trampled by a rhinoceros while on a Safari.    Jill Sparrow however who's researching my planet annihilator 500 tonne missile, yeah her death is a bit more important.   "

EDIT:
Also, I've noticed that bodies with large amounts of terraforming equipment (particularly small ones due to the terraforming multipliers) can have accuracy troubles when terraforming.   For instance, in my current terraforming of Luna, one terraforming tick is about 0.  0033 atmospheres.   I suppose it's just a bit of QOL, but it makes adding non-safe gasses such as CO2 (for rp reasons) hard without poisoning the atmosphere. 
Title: Re: C# Suggestions
Post by: serger on May 31, 2020, 02:34:44 AM
1. Sort records in Commander's personal history by Date + index both decreasing, to avoid partially reversed order, when there was several manual promotions/assingning events during one game pause.
2. Delete previous promotion/assignment personal history record, when player counteracted it in the same datetime, to provide player an ability to correct mistakes without silly "blots" in commander's personal records.
Title: Re: C# Suggestions
Post by: serger on May 31, 2020, 02:47:35 AM
Repliyng to Steve's new post in FAQ (http://aurora2.pentarch.org/index.php?topic=11578.0).

I think it will be cool, if there will be no blunt "max range" parameter at all, because there is no parabolic ballistical trajectory of energy and kinetical impacts in Aether, I suppose.
That's enough to have hit chance decreasing with distance, so with current fire mechanics, where guns devouring maintainance during fire, there will be no endless kiting and so no big advantage of long range beam weapons.
Title: Re: C# Suggestions
Post by: Vasious on May 31, 2020, 03:36:17 AM
Mainly for roleplay reasons, but a way to put a ship into a sort of mothballed state as perhaps a museum ship.

A ship kept in a deactivated state requiring minimal crew and maintenance but keeping the ships history, maybe having each Academy being able to host/maintain a Museum ship to limit numbers.

Blame Rule the waves for the idea
Title: Re: C# Suggestions
Post by: xenoscepter on May 31, 2020, 04:13:18 AM
Can we have a refit tech line? Something akin to OmniTechnology in BattleTech?

I propose a "Modular" technology having two tech lines; "Modular Ship Building, Weight Margin +'x'%", and "Modular Ship Building, Cost Margin +'x'%"

My proposition for both tech lines would be increments of the following:

5% for tier one, 10% for tier two, 15% for tier three, 20% for tier four and 40% for tier five up to a total of 100% increase in margins for both weight and cost, with both lines being separate to ensure that while some improvement isn't too costly, dedicated refitters will need to shell out RPs to maintain parity.

This would allow some flavor for races who favor refitting over scrapping and would serve as an alternative to those who wish to avoid carriers or missile ships for whatever reasons. This change would make beam ships less constrained by refit rules as well. I see this as being good for Role-Play as a machine or hive race, where they would build "Hulls" and fill them to mission spec as needed via the refit mechanic. I also see this as making beam weapons and non-carrier ships more appealing as they can have some flexibility if you invest a bit into refit techs. Even the tier one improvement would take the current margin of 20% size / cost to 25%, offering an improvement of 25% over the original baseline.

Feedback is welcome.
Title: Re: C# Suggestions
Post by: xenoscepter on May 31, 2020, 04:15:44 AM
Also, can we have a way to add officers of lower rank? I want to add ranks of less than Major, like Sergeant and Lance Corporal. It's a pain in the arse right now to do it...
Title: Re: C# Suggestions
Post by: serger on May 31, 2020, 04:32:33 AM
Change GF weapons to represent different accuracies of one-shot vs burst fire, so the more shots - the more additional resupply cost.
That's it, LPW might be small and cheap police-and-staff weapon, yes; IPW - with the same Resupply Cost as PW (round-thrifty - during combat - marksman's weapon, so the same RC despite larger size of weapon and rounds), and CSAP - much less round-thrifty than PW (say 12 resup.cost per 6 shots), the same as Auto-Cannons (6 RC per 3 shots), though both CSAP and AC can be quite smaller, than they are now, to save balance.
Title: Re: C# Suggestions
Post by: serger on May 31, 2020, 04:36:25 AM
Also, can we have a way to add officers of lower rank? I want to add ranks of less than Major, like Sergeant and Lance Corporal. It's a pain in the arse right now to do it...
You have add-to-the-top-and-rename-all option. That's one-time per company start, so not a catastrophe. Yes, boring, but I do it at every new start. :)
Title: Re: C# Suggestions
Post by: serger on May 31, 2020, 04:37:03 AM
Ow. Let's forbid or penalize indirect fire weapon use during boarding combat!
Title: Re: C# Suggestions
Post by: xenoscepter on May 31, 2020, 02:56:54 PM
Let's not, the idea of a boarding crew turning a corner and coming face to face with the barrel of 105mm Howitzer is just too funny.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on June 01, 2020, 02:17:54 AM
Some thoughts on improvements to the Mining reports on the Economics window...

I would like to see that the projected Usage of mineral was shown not just in total but yearly as well. We see the yearly production of minerals and having a yearly consumption of minerals would also be very informative. The total can often be very misleading if you have long running industrial project that take decades if not more to finish.

In addition to this I think it would be better if the colour of the minerals should turn yellow if the stockpile change was negative in the last three or maybe six months and not if the SP+Production is less than Projected Usage that often don't say anything. It would be more helpful to at a glance see which stockpiles are moving negatively or positively over a certain time period without having to look at them from turn to turn.... the "Recent SP" line can't always be trusted as resources can come and go all the time.

It also is quite easy to see if the Projected Usage value is higher than the "SP + Production" value at a glance as it is.

I also think the Empire mining tab cold be expanded to show the same type of values in the same way the planetary does but for the entire empire.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on June 01, 2020, 02:31:20 AM
Also, can we have a way to add officers of lower rank? I want to add ranks of less than Major, like Sergeant and Lance Corporal. It's a pain in the arse right now to do it...

Not sure if this is what you mean... but in the "Commanders" window you can add additional ranks and rename them. You can model any rank system that you like.

If you need more ground force commanders then make one the leader of your Academies so you get more ground force commanders each year.
Title: Re: C# Suggestions
Post by: wedgebert on June 01, 2020, 08:18:54 AM
Also, can we have a way to add officers of lower rank? I want to add ranks of less than Major, like Sergeant and Lance Corporal. It's a pain in the arse right now to do it...

Not sure if this is what you mean... but in the "Commanders" window you can add additional ranks and rename them. You can model any rank system that you like.

If you need more ground force commanders then make one the leader of your Academies so you get more ground force commanders each year.

I think he means that the only way to add new ranks is at the top. So if using the United States rank theme I wanted to add Captains, I'd have to add a new rank, rename it to General of the Army, then rename the existing General of the Army to General, General to Lt General, and so on down the line until I'm finally able to make a Captain by renaming Major to Captain.

So it'd be a time saver if we could just say "Add Rank To Bottom" (or even Insert Rank Above/Below Selected).

Also, there is my tangental suggestion of storing rank/class/system/etc theme files in external files that are read when starting a new game. That way we can easily persist and share our changes.
Title: Re: C# Suggestions
Post by: wedgebert on June 01, 2020, 08:33:23 AM
Small QoL suggestion.

If a fleet consists of only a single ship, ships with only self-only jump drives, or is going through a stabilized jump point, double clicking the jump point in the movement orders list should automatically selected Standard Transit similarly to how it works when using the Autoroute by System option.

Of if it's easier, just always have double click use Standard Transit.

*edit typo
Title: Re: C# Suggestions
Post by: chrislocke2000 on June 01, 2020, 04:46:12 PM
I've noticed that the rates of death in my scientists seem to be disproportionately high at the start of a game when using a non TN start. I suspect this is because of the relatively small pool of military officers, administrators and scientists from which to apply random problems to and often results in me having only 5 or 6 scientists left from a reasonably healthy start point by the time I'm ready to start using them. I wonder if the death rates could be adjusted to reflect the age of the relevant person so that naturally your young and upcoming bunch have less chance of ending their careers very early.

That might also tie well with allowing players to set a normal retirement age to better reflect different starting conditions.
Title: Re: C# Suggestions
Post by: Droll on June 01, 2020, 05:54:50 PM
I've noticed that the rates of death in my scientists seem to be disproportionately high at the start of a game when using a non TN start. I suspect this is because of the relatively small pool of military officers, administrators and scientists from which to apply random problems to and often results in me having only 5 or 6 scientists left from a reasonably healthy start point by the time I'm ready to start using them. I wonder if the death rates could be adjusted to reflect the age of the relevant person so that naturally your young and upcoming bunch have less chance of ending their careers very early.

That might also tie well with allowing players to set a normal retirement age to better reflect different starting conditions.

Honestly I want a medical technology that allows you to increase the average lifespan of the population and/or officers.
You could even have a tech that only the highest level alien ruins have that makes your officers functionally immortal (but not invincible).
Title: Re: C# Suggestions
Post by: Borealis4x on June 02, 2020, 01:23:07 AM
Subfleets should be more than just a convenient way to organize your fleets. They should have commanders of their own if they have a flag bridge and shouldn't be lost when you order them inside a carrier or something. They should also be detachable while still being considered 'under' the main fleet, benefiting from the bonuses of the fleet commander as long as they are in the same system.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on June 02, 2020, 02:37:10 AM
Another thing that is sort of "annoying" is that we can't scrap old ground units and get some of the resources back in the way we can with ships. The only thing we can do is delete them and get nothing back.

I would either that we get the ability to upgrade them to new formations for some extra cost or if we at least can get some resources back when we scrap them.

I would prefer it both was possible but if I can only get one then allow me to just scrap them and get say 25% of the resources back.
Title: Re: C# Suggestions
Post by: Borealis4x on June 02, 2020, 05:26:01 PM
A way to 'link' planets with their moons, meaning they essentially become on planet.

I think at sufficient tech levels, going to the Moon should be like going the next State over, or taking the Chunnel to France.
Title: Re: C# Suggestions
Post by: QuakeIV on June 02, 2020, 10:00:20 PM
I request that in the 'ground forces->order of battle' window, bind the delete key to 'delete formation'.

Additionally, it would be cool if that window supported multi-select. (my general understanding is that has the potential to be a lot trickier to get working right however, having faffed with QT and such in my day)
Title: Re: C# Suggestions
Post by: Borealis4x on June 03, 2020, 02:33:02 AM
Only Auxiliary Control should require a level 2 officer. This way, you can still make smaller ships like corvettes and frigates that you'll likely have many of be commanded by officers rank 2 and lower, which sounds about right. I don't think frigates these days (at least true frigates, not oversized psudo-destroyers) are commanded by full Captains.

I also think tonnage and/or crew size should play a bigger role in deciding what level of commander you need in Commerical ships. A 500,000 ton super-freighter with over 2,000 crew should require a full-blown Captain.
Title: Re: C# Suggestions
Post by: Siccles on June 03, 2020, 07:07:00 AM
Orbital habitat population capacity of a body could be changed to an int64 (or some other higher-capacity datatype) instead of the current int32, limiting current capacities to just over 2b and throwing errors above it.

While 2b capacity might not be something that most players would ever be close to reaching on a single body in their games, I've been thinking about doing an orbital-habitat-only game, which this limitation makes infeasible.
Title: Re: C# Suggestions
Post by: Migi on June 03, 2020, 12:29:24 PM
Orbital habitat population capacity of a body could be changed to an int64 (or some other higher-capacity datatype) instead of the current int32, limiting current capacities to just over 2b and throwing errors above it.

While 2b capacity might not be something that most players would ever be close to reaching on a single body in their games, I've been thinking about doing an orbital-habitat-only game, which this limitation makes infeasible.
If you are getting errors, post it in the bugs thread, it's more likely to get attention there.


Title: Re: C# Suggestions
Post by: Siccles on June 03, 2020, 01:45:10 PM
Quote from: Migi link=topic=10640.   msg135977#msg135977 date=1591205364
Quote from: Siccles link=topic=10640.   msg135952#msg135952 date=1591186020
Orbital habitat population capacity of a body could be changed to an int64 (or some other higher-capacity datatype) instead of the current int32, limiting current capacities to just over 2b and throwing errors above it.   

While 2b capacity might not be something that most players would ever be close to reaching on a single body in their games, I've been thinking about doing an orbital-habitat-only game, which this limitation makes infeasible.   
If you are getting errors, post it in the bugs thread, it's more likely to get attention there.   

It isn't per se a bug though.    There are dozens of ways to generate overflow-errors in the game (ship design for example) that are intended behavior.    And I strongly assume this is intended behavior as well since someone wanting to put more than 2b orbital capacity on some body was simply not considered.   
Title: Re: C# Suggestions
Post by: QuakeIV on June 03, 2020, 11:00:05 PM
I could wind up reaching that pretty easily, its a little concerning that the limit is so low.  (i have in relatively early-game situations wound up with around 200m of orbital habitats over venus for instance)
Title: Re: C# Suggestions
Post by: skoormit on June 04, 2020, 04:12:12 PM
It isn't per se a bug though.   

I just want to say thank you for using (and spelling) per se correctly. I see it so rarely.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 04, 2020, 06:38:52 PM
We currently have little way to fine-tune MSP production.
1) Add a colony MSP stockpile limit.  While the amount of MSP on a planet exceeds this have maintenance facilities stop producing.
2) Add a colony MSP reserve.  MSP below this level can only be used by maintenance facilities.  This will prevent starvation during surge loads, such as when building a large supply station.
3) Make MSP build-able using industry.  This will also help when dealing with large temporary demands.
Title: Re: C# Suggestions
Post by: skoormit on June 05, 2020, 11:53:56 AM
We currently have little way to fine-tune MSP production.
1) Add a colony MSP stockpile limit.  While the amount of MSP on a planet exceeds this have maintenance facilities stop producing.
2) Add a colony MSP reserve.  MSP below this level can only be used by maintenance facilities.  This will prevent starvation during surge loads, such as when building a large supply station.
3) Make MSP build-able using industry.  This will also help when dealing with large temporary demands.

I love 1 and 2, but not 3.
I like that I can't compensate for my insufficient planning by just throwing some factories at the problem for a week or two.

Maybe it's possible to make it configurable per game (at game creation)?
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 05, 2020, 04:34:11 PM
We currently have little way to fine-tune MSP production.
1) Add a colony MSP stockpile limit.  While the amount of MSP on a planet exceeds this have maintenance facilities stop producing.
2) Add a colony MSP reserve.  MSP below this level can only be used by maintenance facilities.  This will prevent starvation during surge loads, such as when building a large supply station.
3) Make MSP build-able using industry.  This will also help when dealing with large temporary demands.

I love 1 and 2, but not 3.
I like that I can't compensate for my insufficient planning by just throwing some factories at the problem for a week or two.

Maybe it's possible to make it configurable per game (at game creation)?
You could just RP such a limitation, but I won't object to making it an option.  Insufficient planning isn't the only reason to want #3.  MSP demand can be quite variable if you use beam fleets and you can't always predict the timing or tempo of a campaign.  Front-loading production before a major battle can make all the difference.  The problem with overbuilding maintenance facilities isn't just the construction cost of the facilities, but the excess capacity has continuous worker and mineral costs as well.

This brings up another issue:  In VB we could turn off entire industries on a colony which would free up the workers for other jobs.  This feature is missing in C#.
Title: Re: C# Suggestions
Post by: skoormit on June 05, 2020, 04:42:24 PM
We currently have little way to fine-tune MSP production.
1) Add a colony MSP stockpile limit.  While the amount of MSP on a planet exceeds this have maintenance facilities stop producing.
2) Add a colony MSP reserve.  MSP below this level can only be used by maintenance facilities.  This will prevent starvation during surge loads, such as when building a large supply station.
3) Make MSP build-able using industry.  This will also help when dealing with large temporary demands.

I love 1 and 2, but not 3.
I like that I can't compensate for my insufficient planning by just throwing some factories at the problem for a week or two.

Maybe it's possible to make it configurable per game (at game creation)?
You could just RP such a limitation, but I won't object to making it an option.  Insufficient planning isn't the only reason to want #3.  MSP demand can be quite variable if you use beam fleets and you can't always predict the timing or tempo of a campaign.  Front-loading production before a major battle can make all the difference.  The problem with overbuilding maintenance facilities isn't just the construction cost of the facilities, but the excess capacity has continuous worker and mineral costs as well.

This brings up another issue:  In VB we could turn off entire industries on a colony which would free up the workers for other jobs.  This feature is missing in C#.

I don't like the option to just self-impose, because I want the AI to have to play by the same rules.

Fair points about labor issues, and burst demand from beam fleets.

To free up workers, I have resorted to hauling unneeded installations to an unused moon. It's a slow and expensive Off switch, but I find I don't need to use it very often.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 05, 2020, 05:12:00 PM
I don't like the option to just self-impose, because I want the AI to have to play by the same rules.

Fair points about labor issues, and burst demand from beam fleets.

To free up workers, I have resorted to hauling unneeded installations to an unused moon. It's a slow and expensive Off switch, but I find I don't need to use it very often.
Fair point about the AI.

The scenario that comes to mind is a maxed-out industrial world building mines for export.  Until they are shipped out those mines will cause a worker shortage while not doing anything actually useful.  Turning off mining on that colony would neatly solve the problem.
Title: Re: C# Suggestions
Post by: Droll on June 05, 2020, 05:49:53 PM
We currently have little way to fine-tune MSP production.
1) Add a colony MSP stockpile limit.  While the amount of MSP on a planet exceeds this have maintenance facilities stop producing.
2) Add a colony MSP reserve.  MSP below this level can only be used by maintenance facilities.  This will prevent starvation during surge loads, such as when building a large supply station.
3) Make MSP build-able using industry.  This will also help when dealing with large temporary demands.

I love 1 and 2, but not 3.
I like that I can't compensate for my insufficient planning by just throwing some factories at the problem for a week or two.

Maybe it's possible to make it configurable per game (at game creation)?
You could just RP such a limitation, but I won't object to making it an option.  Insufficient planning isn't the only reason to want #3.  MSP demand can be quite variable if you use beam fleets and you can't always predict the timing or tempo of a campaign.  Front-loading production before a major battle can make all the difference.  The problem with overbuilding maintenance facilities isn't just the construction cost of the facilities, but the excess capacity has continuous worker and mineral costs as well.

This brings up another issue:  In VB we could turn off entire industries on a colony which would free up the workers for other jobs.  This feature is missing in C#.

I don't like the option to just self-impose, because I want the AI to have to play by the same rules.

Fair points about labor issues, and burst demand from beam fleets.

To free up workers, I have resorted to hauling unneeded installations to an unused moon. It's a slow and expensive Off switch, but I find I don't need to use it very often.

You can use SM mode to delete unused installations through the civilian economy (the one where you make contracts) menu. This has the obvious problem of making such installations unrecoverable.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 05, 2020, 05:57:53 PM
You can use SM mode to delete unused installations through the civilian economy (the one where you make contracts) menu. This has the obvious problem of making such installations unrecoverable.
Installations can be replaced the same way, but deleting them tends to be problematic when you are trying to ship them somewhere else.  And if you ever do want them back it means needing to manually keep track of which 'ghost' installations go where.
Title: Re: C# Suggestions
Post by: Borealis4x on June 07, 2020, 08:48:34 PM
I think that assigning Admin positions could be easily automated since they are already designated as employing one of a couple of skills officers have. So to fill a logistics Admin the game would look first for the lowest rank that could fill the positions and then for the highest logistics skill.

Its a bit less straightforward with naval and General Admins, I grant you, since General could be anything and Naval could be tactical, reaction, etc.

At the very least, messages should be narrowed down so you don't miss that an Admin post lost a commander. Instead of reporting every retirement, promotion, XP gain (this is a big one, I get spammed hard by this mid game) by default the game should only let you know when a post has been vacated without a replacement. Perhaps highlight it as a priority message.

EDIT:

Oh! And an option to make a ruin guaranteed to spawn on Mars that gives you TN tech. You are unable to research it otherwise.
Title: Re: C# Suggestions
Post by: wedgebert on June 07, 2020, 10:25:37 PM
How about Research Complexes. These would be assigned research labs and a research queue like a scientist, however they would also have a scientist assigned to them.

At their simplest, they would just provide a way to set up a research queue without having to worry about the scientist retiring or dying and having to reconfigure the queue. If no scientist is assigned, it just sits idle like the labs would, but assigning a new scientist would make it continue as normal.

A more advanced version would allow multiple scientists and would automatically assign the scientist with the highest total research points for the given project. That way, if the lead dies, someone can automatically take his place. Or if the a backup scientist increases her skill or max labs such that she would do more research with the assigned labs, she would take over.

They wouldn't even have to be a building, necessarily, just a list of assigned scientists, a research queue, and number of labs assigned (obviously they'd still have to all be on the same planet)
Title: Re: C# Suggestions
Post by: Rince Wind on June 08, 2020, 03:08:04 AM
Different naming themes for different species.

It would be nice if you could distinguish different species by giving them different naming themes.

Adding to that: multiple species starts. I'd love to continue my OpenXcom XPiratez game in space and start with a couple different species under one empire.
Title: Re: C# Suggestions
Post by: serger on June 09, 2020, 12:49:05 PM
Use FFD to increase rear bombardment's weapon chances to hit, not only air and orbital ones.
Title: Re: C# Suggestions
Post by: Marv on June 09, 2020, 12:56:25 PM
Two things in the Commander window that I would kindly ask to be improved:
1.   Colours that make the destinction between filled and vacant position MUCH more obvious then actually possible, currently it is a hassle to see if a position is already filled or not, especially because
2.   There is no functionality that when I click on a filled job title the owner is highlighted on the list on the left side and/or the top part of the window (including age, traits etc.   of a given commander).   Click-selecting a position should show me the owner, that is my wish. 
Thank you for listening,
Marv
Title: Re: C# Suggestions
Post by: bitbucket on June 11, 2020, 07:12:11 PM
I just want the ability to spacemaster jump point destinations brought back.
Title: Re: C# Suggestions
Post by: Droll on June 11, 2020, 10:33:53 PM
I just want the ability to spacemaster jump point destinations brought back.

You can create jump points with SM but they wont show if:
a - There is no survey
b - If there is a complete gravsurvey you need to SM redo it for them show up
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 12, 2020, 01:23:12 AM
Use BindingList and relatives with appropriate DataSource objects for UI forms, and then send update notification messages instead of clearing and rebuilding them.  This should fix the various scrolling and focus problems that people have been complaining about while also making the UI faster.
Title: Re: C# Suggestions
Post by: wedgebert on June 12, 2020, 08:13:52 AM
Would be nice if various screens remembered the last selected values. I'm particularly thinking of the Commanders screen as 9 times out of 10 I'm going to reassign/check on Planetary Administrators who are good at mining.
Title: Re: C# Suggestions
Post by: Droll on June 12, 2020, 09:39:03 AM
Use FFD to increase rear bombardment's weapon chances to hit, not only air and orbital ones.

Does the FFD need to be with the arty formation for this or the formation being supported?
Does the accuracy boost still apply if the FFD is also directing CAS/OBS?
Title: Re: C# Suggestions
Post by: Shadow on June 12, 2020, 10:06:42 AM
For performance reasons, it'd be very welcome to implement limits on civilian ship traffic. Ideally all configurable in the game options.

A few alternatives:
Cheers!
Title: Re: C# Suggestions
Post by: Migi on June 12, 2020, 11:33:27 AM
For performance reasons, it'd be very welcome to implement limits on civilian ship traffic. Ideally all configurable in the game options.

A few alternatives:
  • Global civilian vessel cap
  • Civilian vessel cap tied to number of colonies
  • Civilian vessel cap tied to empire population (best one in my opinion ;))
Cheers!
In case you weren't aware, you can turn off civilian vessel generation in the game settings any time after starting.
Title: Re: C# Suggestions
Post by: Droll on June 12, 2020, 12:50:03 PM
For performance reasons, it'd be very welcome to implement limits on civilian ship traffic. Ideally all configurable in the game options.

A few alternatives:
  • Global civilian vessel cap
  • Civilian vessel cap tied to number of colonies
  • Civilian vessel cap tied to empire population (best one in my opinion ;))
Cheers!
In case you weren't aware, you can turn off civilian vessel generation in the game settings any time after starting.

I think people want the civilian economy to scale with their empire without destroying game performance on the long term, which is why a lot of people want to see a more limited approach to civies.
The checkbox you mention is a perfectly valid solution and it should never be removed IMO but it is kind of stop gap.

I personally think that the civilian economy should be abstracted more so that individual ships shouldn't be simulated all the time. Maybe instead use a system similar to how the "detection only in systems where player is" dropdown works and instead dynamically load in civilian freighters only when there are enemy/NPR ships in the same system. That way you only load in like 100 of the total 600 civilian ships during an NPR attack for example
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 12, 2020, 01:03:23 PM
For performance reasons, it'd be very welcome to implement limits on civilian ship traffic. Ideally all configurable in the game options.

A few alternatives:
  • Global civilian vessel cap
  • Civilian vessel cap tied to number of colonies
  • Civilian vessel cap tied to empire population (best one in my opinion ;))
Cheers!
In case you weren't aware, you can turn off civilian vessel generation in the game settings any time after starting.

I think people want the civilian economy to scale with their empire without destroying game performance on the long term, which is why a lot of people want to see a more limited approach to civies.
The checkbox you mention is a perfectly valid solution and it should never be removed IMO but it is kind of stop gap.

I personally think that the civilian economy should be abstracted more so that individual ships shouldn't be simulated all the time. Maybe instead use a system similar to how the "detection only in systems where player is" dropdown works and instead dynamically load in civilian freighters only when there are enemy/NPR ships in the same system. That way you only load in like 100 of the total 600 civilian ships during an NPR attack for example
I don't think that ships in transit are the problem, rather it is the idle ships looking for work and not finding it.  If so, then the problem is that the civvies build more ships than they need.
Title: Re: C# Suggestions
Post by: Shadow on June 12, 2020, 01:05:06 PM
In case you weren't aware, you can turn off civilian vessel generation in the game settings any time after starting.

I'm aware, but having to handle that aspect entirely manually is quite a pain and requires you to be constantly aware of civilian ship numbers and guesstimating when you have enough (and when you don't). Not to mention turning it on and off in the long run as your empire expands, and doing some manual scrapping since disabling civilian construction also stops upgrades.

I'm certain that side of the game stands to gain plenty from just a little bit of intelligent automation. It's not where the player's brainpower should be.
Title: Re: C# Suggestions
Post by: Zincat on June 12, 2020, 01:12:40 PM
Frankly the simplest soultion would be:
If there are idle ships, do not build more of those ships. That way, the number of civ ships do not increase unless they are actually doing something.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 12, 2020, 01:21:24 PM
Frankly the simplest soultion would be:
If there are idle ships, do not build more of those ships. That way, the number of civ ships do not increase unless they are actually doing something.
I've been saying that for years.  :)
Title: Re: C# Suggestions
Post by: Shadow on June 13, 2020, 08:58:02 AM
Frankly the simplest soultion would be:
If there are idle ships, do not build more of those ships. That way, the number of civ ships do not increase unless they are actually doing something.

At first glance, yes, but then one realizes the game needs to gauge what constitutes idle in practice, because idle today doesn't mean idle yesterday or tomorrow. If it's something like "inactive for X days", that means putting a timer on every civilian ship out there, which may well not be particularly performance-friendly.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 13, 2020, 09:15:27 AM
Frankly the simplest soultion would be:
If there are idle ships, do not build more of those ships. That way, the number of civ ships do not increase unless they are actually doing something.

At first glance, yes, but then one realizes the game needs to gauge what constitutes idle in practice, because idle today doesn't mean idle yesterday or tomorrow. If it's something like "inactive for X days", that means putting a timer on every civilian ship out there, which may well not be particularly performance-friendly.
It is actually trivial to track and shouldn't noticeably affect performance.  Give each shipping line a counter for each category of ships it operates (F, C, L).  Every time a civilian ship can't find* a job, bump the appropriate counter.  Every time a shipping line builds new ships, only consider categories that have low** counters and then reset the counters for that line.  If all categories are too high then don't build anything and put the money into dividends instead.

*They check every time they finish a job or once every five days while idle.
**One more than the number of production cycles since the last build cycle is probably a good upper limit.
Title: Re: C# Suggestions
Post by: Zincat on June 13, 2020, 09:44:25 AM
Something similar to what SpiketheHobbitMage said, and check every production cycle (5 days). If the ship did nothing, then increase the counter. You just need one counter for the entire shipping line, if multiple ships did nothing the counter gets increased mutliple times. Should have negligible performance impact.

We also have the history of what the civilian ships did, if we want to use that, but the various tasks do not have the same lenght of course, so it could be tricky. One trip to the moon is different than one trip to a 60 billion km colony in another system. So I'd just use a counter based on how many production cycles the ships of the company had nothing to do.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 13, 2020, 10:37:51 AM
Some QoL ideas regarding fleet management:

Current Location:
If a fleet is in orbit around a body, at a jump point, etc, then that body/JP should be listed first in the locations list.
If the fleet is in space then an entry called 'Current location' should be listed first with commands like a way-point.

Sub-fleets:
Allow sub-fleets to have standing orders.  Such orders shouldn't do anything as-is, but:
-When a fleet is given the order 'Join as Sub-Fleet' it should remember its standing orders.
-When a sub-fleet is detached its standing orders should become active again.

An order to detach all sub-fleets.

Remember the parent fleet when detaching a sub-fleet, or parent sub-fleet if detaching a sub-sub-fleet.  This should survive the parent fleet joining another fleet as a sub-fleet and/or detaching from a grandparent fleet.
-A standing order to re-join the parent fleet as a sub-fleet.
-If a fleet has a parent fleet then it should be listed second in the locations list, even if the 'Fleets' option isn't checked.

An order to wait for all detached sub-fleets to rejoin.

Fleet list:
Dropping a fleet onto another should join as a sub-fleet instead of merging.
Right-clicking on a fleet should give options to merge into the parent and/or absorb sub-fleets.
If a fleet is dropped on another fleet that is at a different location, ask the player if they want to issue move and join orders.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on June 13, 2020, 03:57:20 PM
Frankly the simplest soultion would be:
If there are idle ships, do not build more of those ships. That way, the number of civ ships do not increase unless they are actually doing something.

At first glance, yes, but then one realizes the game needs to gauge what constitutes idle in practice, because idle today doesn't mean idle yesterday or tomorrow. If it's something like "inactive for X days", that means putting a timer on every civilian ship out there, which may well not be particularly performance-friendly.
It is actually trivial to track and shouldn't noticeably affect performance.  Give each shipping line a counter for each category of ships it operates (F, C, L).  Every time a civilian ship can't find* a job, bump the appropriate counter.  Every time a shipping line builds new ships, only consider categories that have low** counters and then reset the counters for that line.  If all categories are too high then don't build anything and put the money into dividends instead.

*They check every time they finish a job or once every five days while idle.
**One more than the number of production cycles since the last build cycle is probably a good upper limit.

I think it is simply better to use the same mechanic that build ships which is income... make every ship they have cost something to support... if the income stagnate then the cost will outweigh the income and eventually they will have to sell their ships. They might be able to sell them to some other civilian company, even to another faction of there is trade for a cheap price. If no one want's to buy the ship it simply get scraped and the company get a small return on the ships build cost.

This would make it so that civilian shipping lines only exist when they are needed and there will be a natural decline if there is little to no work for them to do.

There is no need to use artificial and arbitrary rules for this, the economy can govern itself.

I would even eventually extend this to fuel costs and a more dynamic civilian economy that also need trans-Newtonian materials to thrive well. But that would be the next logical step...
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 13, 2020, 04:46:42 PM
I think it is simply better to use the same mechanic that build ships which is income... make every ship they have cost something to support... if the income stagnate then the cost will outweigh the income and eventually they will have to sell their ships. They might be able to sell them to some other civilian company, even to another faction of there is trade for a cheap price. If no one want's to buy the ship it simply get scraped and the company get a small return on the ships build cost.

This would make it so that civilian shipping lines only exist when they are needed and there will be a natural decline if there is little to no work for them to do.

There is no need to use artificial and arbitrary rules for this, the economy can govern itself.

I would even eventually extend this to fuel costs and a more dynamic civilian economy that also need trans-Newtonian materials to thrive well. But that would be the next logical step...
Such a system would make the shipping lines overbuild until they bankrupted themselves and collapsed.  Not only does it do nothing to address the problem at hand (overbuilding ships) it actually manages to be worse than the existing system (introduces catastrophic collapse cycles).  The demand limiting mechanisms under discussion aren't arbitrary, but a simplified model of how actual shipping lines manage production.

Civilians using TN materials, especially fuel, would not only eliminate the sole advantage to having them but it would make them an active threat.  There would be no reason to ever enable them.
Title: Re: C# Suggestions
Post by: QuakeIV on June 13, 2020, 06:41:10 PM
The proposed system of running costs, plus selling ships the line cant afford, would work perfeclty fine if there was dampening on both ends of the behavior.

That is to say: if current rate of income isnt meeting current costs (sum of income vs sum of costs for past year for instance), start scrapping ships (less effecient ships first, so for instance older engine tech perhaps), rather than waiting to run out of money first (waiting to run out would cause a catastrophic collapse).  Additionally, only purchase new ships if surplus income is sustained for a while (maybe a year? i dunno).

The running cost could be changed to calibrate roughly how many ships they keep on hand.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on June 13, 2020, 07:33:50 PM
I think it is simply better to use the same mechanic that build ships which is income... make every ship they have cost something to support... if the income stagnate then the cost will outweigh the income and eventually they will have to sell their ships. They might be able to sell them to some other civilian company, even to another faction of there is trade for a cheap price. If no one want's to buy the ship it simply get scraped and the company get a small return on the ships build cost.

This would make it so that civilian shipping lines only exist when they are needed and there will be a natural decline if there is little to no work for them to do.

There is no need to use artificial and arbitrary rules for this, the economy can govern itself.

I would even eventually extend this to fuel costs and a more dynamic civilian economy that also need trans-Newtonian materials to thrive well. But that would be the next logical step...
Such a system would make the shipping lines overbuild until they bankrupted themselves and collapsed.  Not only does it do nothing to address the problem at hand (overbuilding ships) it actually manages to be worse than the existing system (introduces catastrophic collapse cycles).  The demand limiting mechanisms under discussion aren't arbitrary, but a simplified model of how actual shipping lines manage production.

Civilians using TN materials, especially fuel, would not only eliminate the sole advantage to having them but it would make them an active threat.  There would be no reason to ever enable them.

No... they would not..

1. They first would try to sell it... if that don't work they scrap it and get some wealth back.

2. When a ship is sold/scraped their running cost is lowered and they get some fresh new cash.

This would act to balance their economy and not make it crash, not very hard to make right at all... They would only crash if there is NO jobs at all. In that case there can be some safeguard in place where they are guarantied to keep a few ship that they don't have to pay maintenance for.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 13, 2020, 08:33:54 PM
The proposed system of running costs, plus selling ships the line cant afford, would work perfeclty fine if there was dampening on both ends of the behavior.

That is to say: if current rate of income isnt meeting current costs (sum of income vs sum of costs for past year for instance), start scrapping ships (less effecient ships first, so for instance older engine tech perhaps), rather than waiting to run out of money first (waiting to run out would cause a catastrophic collapse).  Additionally, only purchase new ships if surplus income is sustained for a while (maybe a year? i dunno).

The running cost could be changed to calibrate roughly how many ships they keep on hand.
Building surplus ships due to surplus income is the problem behaviour that we need to fix.  Adding a delay would cause unnecessary production lag during growth periods, especially in the critical early game, while doing nothing to actually limit overbuilding.  The only 'dampening factor' that will effectively curb idle civilian ships is to track their idle time.  No measurement of supply (income) can ever accomplish that goal because it is measuring the wrong thing, and any valid proxy will always be inferior to direct measurement.

No... they would not..

1. They first would try to sell it... if that don't work they scrap it and get some wealth back.

2. When a ship is sold/scraped their running cost is lowered and they get some fresh new cash.

This would act to balance their economy and not make it crash, not very hard to make right at all... They would only crash if there is NO jobs at all. In that case there can be some safeguard in place where they are guarantied to keep a few ship that they don't have to pay maintenance for.
Even granting that, your proposed system still requires a large idle fleet to create the increased costs needed to curb growth.  It will always produce a fixed ratio of working to idle ships, which is what the current system already gives us and is exactly the problem that we need to fix.  Simply changing the ratio does not address the problem.  Reducing the ratio too far will also cripple small lines in the early game.

If there aren't enough jobs to support them then the civilian lines should fold.  That is the only way to automatically limit the number of civilian lines.
Title: Re: C# Suggestions
Post by: Coleslaw on June 13, 2020, 09:31:11 PM
I feel like this one has been suggested already but I can't seem to find it, so maybe it hasn't.

Being able to queue the research project that follows after the project you assigned a scientist and labs for would be super handy. I.e., I'm researching active sensor strength 16, it would be nice if I could also then queue active sensor strength 21 (the next tier after 16), and then also queue active sensor strength 28 (the next tier after 21.)
Title: Re: C# Suggestions
Post by: QuakeIV on June 14, 2020, 12:19:59 AM
It should control their population somewhat if there is a substantial running cost for the ships.
Title: Re: C# Suggestions
Post by: xenoscepter on June 15, 2020, 07:50:58 PM
I would like some form of orbital ground command, if I haven't asked for it already. ;D

Here's a link to the bigger, nicer looking request:
http://aurora2.pentarch.org/index.php?topic=11671.0
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 15, 2020, 08:30:40 PM
It should control their population somewhat if there is a substantial running cost for the ships.
That would cause idle colonizers to limit needed freighter production without actually preventing construction of unnecessary ships in the first place.

Seriously, what is wrong with my proposal?  It is well defined, directly addresses the problem, shouldn't have any negative side-effects, and should be trivial to implement.
Title: Re: C# Suggestions
Post by: QuakeIV on June 15, 2020, 11:44:35 PM
In general I'm not against it, I was just pontificating about somewhat more realistic alternatives.  In fairness the shipping AI would probably need to respect which ships are idle regardless, and that would serve as one of two deciding factors to whether it makes new ships, or even keeps existing ones.

What you are proposing would be a reasonable solution from a gameplay perspective.
Title: Re: C# Suggestions
Post by: QuakeIV on June 16, 2020, 12:27:14 AM
Rather simple one:  Rename military academy to just academy, since IIRC it now also produces administrators and scientists (and can have an administrator assigned to pump one output more than the other).
Title: Re: C# Suggestions
Post by: skoormit on June 16, 2020, 08:16:51 AM
I don't think that ships in transit are the problem, rather it is the idle ships looking for work and not finding it.  If so, then the problem is that the civvies build more ships than they need.

If that's the case, then refactoring the code to avoid redundant checks could go a long way towards solving the problem.
After all, if one small freighter at location X looks for work and does not find any, then the rest of the small freighters at location X don't even need to look.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 16, 2020, 12:24:09 PM
I don't think that ships in transit are the problem, rather it is the idle ships looking for work and not finding it.  If so, then the problem is that the civvies build more ships than they need.

If that's the case, then refactoring the code to avoid redundant checks could go a long way towards solving the problem.
After all, if one small freighter at location X looks for work and does not find any, then the rest of the small freighters at location X don't even need to look.
As long as those freighters all belong to the same race so they all share the same job pool, then yes that would help a lot.
Title: Re: C# Suggestions
Post by: alex_brunius on June 16, 2020, 04:28:02 PM
Suggesting that 300 x NPR STO ground units should fire on your fleets of mostly undefended troop transports without drop bays that spend 3 days in orbit to unload enough forces to be able to conquer them.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 16, 2020, 11:51:12 PM
While the new logistics modules add game play options when supporting fleets of large ships, they are prohibitively expensive when trying to support small ships.

For example, in VB it was practical to build a 2500 ton jump tender/tanker to support small survey, scout, and patrol craft:
Code: [Select]
J-2.5k Ise 1 class Tanker     2,500 tons     46 Crew     133.05 BP      TCS 50  TH 50  EM 0
1000 km/s    JR 3-50     Armour 1-16     Shields 0-0     Sensors 1/1/0/0     Damage Control Rating 1     PPV 0
MSP 33    Max Repair 33 MSP
Intended Deployment Time: 24 months    Spare Berths 0   

J3000(3-50) Military Jump Drive     Max Ship Size 3000 tons    Distance 50k km     Squadron Size 3
50 EP Commercial Nuclear Pulse Engine (1)    Power 50    Fuel Use 1.64%    Signature 50    Exp 2%
Fuel Capacity 150,000 Litres    Range 658.5 billion km   (7621 days at full power)

This design is classed as a Commercial Vessel for maintenance purposes

This is the nearest equivalent at a similar tech level in C#:
Code: [Select]
Taiho class Tanker (P)      5,977 tons       53 Crew       116.3 BP       TCS 120    TH 120    EM 0
1003 km/s    JR 1-25(C)      Armour 1-29       Shields 0-0       HTK 15      Sensors 0/0/0/0      DCR 1      PPV 0
MSP 12    Max Repair 20 MSP
Kaigun-Ch?sa    Control Rating 1   BRG   
Intended Deployment Time: 3 months   

JC6K Commercial Jump Drive     Max Ship Size 6000 tons    Distance 25k km     Squadron Size 1

60HS 120EP 1.07L (1)    Power 120    Fuel Use 0.89%    Signature 120    Explosion 2%
Fuel Capacity 150,000 Litres    Range 505.4 billion km (5832 days at full power)
Refuelling Capability: 50,000 litres per hour     Complete Refuel 3 hours

This design is classed as a Commercial Vessel for maintenance purposes
The reduced cost is due to lower fuel tank costs in C# (24 BP savings) and using a commercial jump drive (23 BP).  Note that this design also can't jump tend for military engined survey ships like the VB version can.  That requires a second ship with a military jump drive.

Suggestions:
Implement small craft Refuelling System, Shuttle Bay, and Ordnance Transfer System components at 1/10 size for 1/5 cost and with 1/20 of the capacity of their full sized counterparts.  Please consider fighter scale (1/100 size, 1/25 cost, 1/400 capacity) as well.

Allow military jump drives to work with commercial engines again.
Title: Re: C# Suggestions
Post by: Demakustus on June 17, 2020, 02:01:22 AM
(...)
Allow military jump drives to work with commercial engines again.
Yes, please do, or allow mounting different jump engines on the same ship. It's impractical to make a commercial jump tender for military ships, as it cannot jump itself.
Title: Re: C# Suggestions
Post by: Malorn on June 17, 2020, 03:40:59 AM
(...)
Allow military jump drives to work with commercial engines again.
Yes, please do, or allow mounting different jump engines on the same ship. It's impractical to make a commercial jump tender for military ships, as it cannot jump itself.

I would rather like the idea of having multiple jump engines on the same ship. Then making jump stations becomes fairly possible.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 17, 2020, 08:52:51 AM
(...)
Allow military jump drives to work with commercial engines again.
Yes, please do, or allow mounting different jump engines on the same ship. It's impractical to make a commercial jump tender for military ships, as it cannot jump itself.

I would rather like the idea of having multiple jump engines on the same ship. Then making jump stations becomes fairly possible.
Frankly, I want both.  :)


Various drive capacities in tons:
Drive (size/cost)Eff 4Eff 25
Smallest Military (1HS/10BP)2001250
Cheapest Military (7.5HS/10BP)15009400
Smallest Commercial (10HS/10BP)15009500
Cheapest Commercial (75HS/10BP)11,00070500
Largest Military (1kHS/63kBP)200,0001,250,000
Largest Commercial (10kHS/63kBP)1,500,0009,375,000

If a 7.5HS or smaller military jump drive has enough capacity then it is always preferred.  Depending on efficiency this cutoff can be anywhere from 1500 tons to 9400 tons.  As ships start using commercial engines at 2500 tons, there is a broad range of commercial engined ships that prefer to use military jump drives.

Military drives starting at 8HS have slightly cheaper commercial alternatives, with the cost advantage increasing rapidly to 33:1 at ~55HS (75HS commercial).  The affected ship size during this transition depends on drive efficiency tech.  The range starts at 1500-11,000 tons at efficiency 4 and increases to 9500-70,500 tons at efficiency 25.

Military jump drives cannot be larger than 1000HS.  1340HS commercial drives have slightly higher capacity for only 1/36th the cost.  This affects ships from 200k tons to 1,250k tons depending on drive efficiency.

No military engined ship larger than 1,250k tons can ever use an unstabilized jump point.

The largest possible commercial drive is 10,000HS, and at efficiency 25 it supports up to 9,374,000 ton ships.  It has exactly the same BP and RP costs as a 1000HS military drive.


Final Analysis:
Commercial shipyards have 10 times the capacity of military shipyards at the same price and worker requirements.  This implies a 10:1 expected tonnage disparity.  Commercial jump drives that are 75 HS or larger are between 33 and 36 times cheaper than equal capacity military drives.  Commercial drives also have a higher upper limit regardless of tech.  Due to these factors, large tenders will naturally want one of each type of drive, sized according to the largest ships of each type that they will service.  Note that such tenders may be too large to self-jump using their military drive, especially at low tech levels.

The cost advantage of commercial drives decreases rapidly at sizes below 75HS, reaching parity at their minimum size of 10HS, equivalent to a 7.5HS military drive.  Military drives can be as small as 1HS and have finer granularity, available in 0.5HS increments as opposed to 5HS increments for commercial drives.  This means that all small ships and tenders will prefer military jump drives regardless of engine type, especially at higher tech levels.

Finally, military drives typically become squadron transit capable at 2500 to 3000 tons capacity, well before commercial drives gain that ability, so any ship smaller than ~18,000 tons that needs to be able to lead squadron transits requires a military jump drive.
Title: Re: C# Suggestions
Post by: Droll on June 17, 2020, 11:27:57 AM
(...)
Allow military jump drives to work with commercial engines again.
Yes, please do, or allow mounting different jump engines on the same ship. It's impractical to make a commercial jump tender for military ships, as it cannot jump itself.

As an extension I actually want one of the bugs from the earlier versions of C# to return as a feature.

The game allowed us to use different types of the same engine archetype - eg. my ships could have 1 HS 15 military engine and 2 HS 6 military engines but would not be able to mix-match commercial and military engines.
I don't think allowing different size engines on the same ship compromises any sort of game balance. Fuel consumption and thermal signature are already calculated per-engine.

I also do not understand why a ship cannot mount different sized shields, the regen rate and capacity are already calculated on a component-wise basis.
Title: Re: C# Suggestions
Post by: Droll on June 17, 2020, 06:25:11 PM
In addition to this I only think that a certain size of troops only should be able to face of against a maximum enemy size and this should depend on both terrain and colony size. The more developed a planet is the more difficult it should be to overwhelm a garrison force as the infrastructure will prevent it in it self.

A combat width mechanic based on tonnage (affected by stuff like terrain still) would be very interesting, It would also put more emphasis on having a more in-depth OOB since small formations would have an easier time joining/reinforcing the fight.

I also think that a counter to the attacker fortification problem is to use fortification levels below 1.
Consider using orbital drop pods in your transports - this option exists to protect your transports as it allows them to just dump all ground units at once, however you could make it so that every unit that is dropped this way starts at 0.5 fortification due to how disorganized the troops are in the initial landing, you could also have a commander skill for landing which makes these units start at higher fortification.
This does 2 things:
The defender is incentivized to put some of their units on frontline attack as now is the time where the attackers are at their most vulnerable and where most of their casualties will be.
The attacker is incentivized to not immediately charge in and wait for their troops to establish an actual "beachhead", getting their fortification up to at least 1 before pushing on.

This also means that there is an additional emphasis on STO protection. You could make it so that the fortification penalty does not apply when troops are unloaded from the transport bays normally. Ofc this means that the transports have to linger around STO range for much longer and troops might be coming in piece-meal.
So now defenders are encouraged to have more STO units in order to force an attacker to face the fortification penalty or for them weather the STO storm on their transports.

IMO right now planetary landings are just made too easy because of the drop pods, fast, armored/shielded transports almost completely nullify any benefit STOs give to a defense beyond preventing orbital bombardment. The initial landing should be the bloodiest part of the fight for the attacker and right now it isn't any deadlier than the rest of the fight.

Since this is a very defender-centric suggestion I think there should be some form of combat engineer capability for infantry that speeds up the rate of self-fortification which helps the attacker get over the initial drop phase quicker.

Someone suggested I paste this in here
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 17, 2020, 10:31:32 PM
As an extension I actually want one of the bugs from the earlier versions of C# to return as a feature.

The game allowed us to use different types of the same engine archetype - eg. my ships could have 1 HS 15 military engine and 2 HS 6 military engines but would not be able to mix-match commercial and military engines.
I don't think allowing different size engines on the same ship compromises any sort of game balance. Fuel consumption and thermal signature are already calculated per-engine.

I also do not understand why a ship cannot mount different sized shields, the regen rate and capacity are already calculated on a component-wise basis.
I was going to object to this on the basis of potential exploits, but I can't find any.

Shields:
BP cost is the simple sum of the strength and the recharge rate and is independent of size.  This applies both individually and in aggregate.  While higher tech levels and larger generators give more performance per ton, the cost for a given performance level is constant.
Per-design RP cost is a flat multiple of the BP cost.

Optimizing for cost always favours dividing shields into smaller, equal sized units, with 1HS being the ideal.  Such cost savings are always at the expense of performance.
Due to the size bonus, optimizing for performance always favours using the largest possible generators, but always for an increase in cost, especially RP.

Example 1:
Suppose that we can build up to 10HS Gama shields with recharge rate 2 and have 24HS space available.
24*1 HS gives us 24 strength and 48 recharge for 72 BP and 60 RP.  This is the cheapest but lowest performing option.
3*8 HS gives us 42 strength and 48 recharge for 90 BP and 600 RP.  This is the best performance under current rules, but at the highest cost.
Under the proposed change, 2*10 HS + 1*4 HS would give us 45 strength and 48 recharge for 93 BP and 1060 RP.
Increasing shield size tech to allow a single 24HS shield would give us 74 strength and 48 recharge for 122 BP and 2440 RP.

Example 2:
If the above case is reduced to 23 HS, about a 4.2% space reduction, the differences are more striking.
23*1 HS gives us 23 strength and 46 recharge for 69 BP and 60 RP.  Performance and BP cost are reduced by almost exactly 4.2% across the board.
3*8 HS won't fit, but we can reduce to 3*7 HS for 36 strength and 42 recharge for 78 BP and 520 RP.  This option leaves 1 HS unused and we take a 14.3% strength penalty and a 12.5% recharge penalty for a 13.3% BP reduction.  The larger difference is because we effectively lost 2 HS instead of 1.
2*10 HS + 1*3 HS gives us 43 strength and 46 recharge for 89 BP and 980 RP, a reduction of 4.4% strength and 4.2% recharge, for 4.3% less BP.
A 23HS shield gives 70 strength and 46 recharge for 116 BP and 2320 RP.  This takes 5.4% strength and penalty and 4.2% recharge penalties with a 4.9% BP reduction.

Final analysis:
While allowing mixed shield sizes does allow increased shield performance in common circumstances, those gains are in amounts and come with costs consistent with existing optimization and improvement strategies.  Large gains, like in Example 2, are restricted to critical cases where the existing rules give notably poor results.  In all such cases the improved values are in line with similar non-critical cases.


Edit: Engine analysis complete.
Engines:
Engines are more complex than shields.  They can also suffer from the same prime number space problem that shields have.

For engines, the player controlled inputs are engine tech, boost multiplier, fuel consumption, thermal reduction, and engine size.
Derived factors are engine power, fuel use per hour, thermal signature, BP cost.

Engines have a minimum cost of 5 BP.  RP cost is 10x BP cost.

Unless otherwise stated, reference engines are Improved Nuclear Pulse, 100% boost, Fuel consumption 1, 100% thermal, and 10 HS.

Simple cases:
Base engine power only increases other costs because it increases engine power.  These cost increases are linear so they average out when mixing.
Fuel consumption tech doesn't increase costs at all and the benefits average out.

Conclusion:
It is always better to just use the better tech than mix tech levels.

Boost:
Engine power scales directly with boost.  A pair of otherwise equal engines with boosts in a 3:1 ratio have exactly the same combined power output as two boost 2:2 engines.
The cost multiplier does not scale consistently.  At 100% boost and up, cost is 50% of EP,  Below 100% the cost is again multiplied by the boost factor.

The stock reference engine costs 50 BP.  At 200% boost this increases to 100 BP and at 300% it is 150 BP.  50 + 150 = 100 + 100, so mixing different boosts above 100% balances out the BP cost.

To prevent hitting the 5 BP price floor, we increase to 100 HS for this test.  At 25% boost this costs 31.25 BP, 50% boost costs 125 BP, and 75% gives 281.25.  2x 125 = 250.  31.25 + 281.25 = 312.5, a 25% increase.    Mixing different boosts below 100% always costs more.

Going back to 10 HS to simplify fuel consumption gives us the following results:
25% boost = 0.75 L/h
50% boost = 8.84 L/h
75% boost = 36.54 L/h
100% boost = 100 L/h
200% boost = 1131.37 L/h
300% boost = 4676.54 L/h

Mixing engines with a 3:1 boost ratio consumes 2.1 times as much fuel as a pair of 2:2 engines.

Conclusion:
Mixing different boost values is always a loss.

Thermal reduction:

Two stock engines with 50% thermal have 50 TH signature and cost 75 BP each, for 100 TH and 150 BP total.
Two stock engines, one with 25% and the other 75% gives *24 TH/100 BP and 75 TH/62.5 BP, for 99 TH and 162.5 BP total.

Conclusion:
Mixing different thermal reduction techs is always a loss.

*25% reduction actually giving 24% has been reported as a bug.

Engine size:
HSHSEPL/hBPRP
1010200200100500
911200199.751001000
515200193.181001000
119200169.461001000
20200141.421001000

Assuming 10 HS maximum engine size, 24 HS space, 48 HS ship, and 10kL fuel:
HS*#EPL/hBPRPRangeSpeed
1*24240758.8812050237m km5k km/sThese engines are exactly at the 5 BP cost floor, so going smaller has no cost benefit.
8*3240268.32120400671m km5k km/s
10*2+4*1240263.25120700684m km5k km/s
24*1240154.9212012001162m km5k km/s

Reducing to 23 HS, same ship and fuel:
HS*#EPL/hBPRPRangeSpeed
23*1230727.2611550237m km4.79k km/s
7*3210251.01105350627m km4.4k km/s
7.6*3228261.54114380654m km4.75k km/s
10*2+3*1230254.77115650677m km4.79k km/s
23*1230151.6611511501137m km4.79k km/s

Without the reduced size engine:
10 HS*2 produce 200 EP, consume 200L/h, and cost 100 BP.  RP cost is 500.  750m km range at 4.2k km/s.

Analysis:
Finer granularity of engine sizes in C# helps. The 7.6 HS engines lost less speed and range than the 7 HS engines.
Mixed size engines always get better range than an equal number and tonnage of evenly sized engines without affecting speed or BP cost, but the RP cost is multiplied by the number of sizes.
Reducing the number of engines while maintaining engine tonnage always produces better results than mixing sizes.
Sacrificing the smallest engine without maintaining tonnage will improve range and reduce cost, but at the expense of speed.  L/EPh is what determines range, and all else being equal, smaller engines have worse L/EPh.

Conclusion:
Mixing engine sizes is never cheaper than using evenly sized engines, and always has a higher RP cost.  The optimum use case is to reduce the size of a single engine while expanding all others equally to take up the space.  The extreme limit, reducing the odd engine to zero, is logically and numerically equivalent to removing an engine while retaining tonnage, which is already a known and legal optimization.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on June 18, 2020, 03:21:04 AM
New fleet command: Follow from direction

I really need this command implemented in absence of the Escort mechanic... it is almost impossible to use any form of advanced fleet coordination without some way to have a ship or fleet follow another fleet from a set direction.

It could either be set with you adding the heading you want to follow another fleet or it just would use the heading it is at at the time the order was given... I think both  could be used. There could also be absolute and dynamic follow orders. One where the ship try to follow from an absolute set direction no matter what heading the ship followed have or a more dynamic where you follow it at a direction relative to what heading the followed ship have. Both of these wold be important. So the commands could be Follow from Absolute direction or Follow from Dynamic direction or some such.

Currently I need to micromanage any scouting and fleet formation using ALLOT of way-points and that is really tedious to perform. It would be so much easier if I could have fleets follow other fleets at a specific angle... this is also very important when you want to scout an enemy fleet by shadowing it. Right now the shadowing ship will always fall in behind the enemy which is not really what you want... you might want to follow that fleet in front or from a specific side or something.

It makes very little sense that I need to always follow a ship from behind, that can be a bit dangerous for scouts. As the sensor mechanic have been changed to make small scouts so much more useful and viable this mechanic really need to be fleshed out and the above two orders could easily replace the escort mechanic or at least be a beginning of adding such mechanics again.

This is my number one important feature to add to make the fleet operations part of the game more tolerable at this point... I don't want to be forced to move ships in a few fleets just out of not being patient enough.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on June 18, 2020, 03:33:48 AM
Another thought about command would be a multi selection type of command structure so the list is not so long and easier to manage and add more command.

Structure them so you can double click on them and then you get more specific command available so the first list just have the basic command available... this way you can add more command without cluttering the list.

So the list could look something like this...

Move
Logistics
Load
Miscellanous


If you select Move. (double click)

You get a list of...

Move to Location
Follow
Picket


If you click on Logistics.

Refuel from Colony
Resupply from Colony
Refuel and Resupply from Colony
etc...


You could also make this as a selectable choice if you want all command in a list or sorted in categories.

But the reason is to make it easier to implement new commands without having everything in one list making it hard to find the correct order.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 18, 2020, 03:53:52 AM
New fleet command: Follow from direction
This sounds like the old Protect Threat Axis special order from VB.  It had options for specifying a protected fleet, follow distance, primary threat, and a bearing offset.  Yes, please bring that back.

Another thought about command would be a multi selection type of command structure so the list is not so long and easier to manage and add more command.

Structure them so you can double click on them and then you get more specific command available so the first list just have the basic command available... this way you can add more command without cluttering the list.

So the list could look something like this...

Move
Logistics
Load
Miscellanous


If you select Move. (double click)

You get a list of...

Move to Location
Follow
Picket


If you click on Logistics.

Refuel from Colony
Resupply from Colony
Refuel and Resupply from Colony
etc...


You could also make this as a selectable choice if you want all command in a list or sorted in categories.

But the reason is to make it easier to implement new commands without having everything in one list making it hard to find the correct order.
The movement orders tab can get crowded, and there are quite a few QoL and logistical orders that people have been asking for.  Sorting and grouping orders will help going forward.  I would make it a single click to expand a heading, and expanding one collapses any other that was open.  I've seen this style of control on the web, but I'm totally forgetting the name.

The locations column could use the same treatment.  The location category radio buttons (System Locations, Autoroute, Templates) could be made into categories in the list, and I would be in favour of making Colonies, Fleets and Survey Locations their own categories as well.


Title: Re: C# Suggestions
Post by: TMaekler on June 18, 2020, 06:45:28 AM
Moving around jump points for strategic reasons. Since we are capable of stabilizing them, maybe jump points can be relocated as long as they are unstable. So before you stabilize one you can think about if they can be moved around to make the system potentially more save or if a transit system move the jps closer together... .

Two limiting factors: the more you want to move them the exponentially expensive it should be. Additionally on the costs it should become even more expensive if you come too close to another JP.
Title: Re: C# Suggestions
Post by: skoormit on June 18, 2020, 08:11:10 AM
Implement small craft Refuelling System, Shuttle Bay, and Ordnance Transfer System components at 1/10 size for 1/5 cost and with 1/20 of the capacity of their full sized counterparts.  Please consider fighter scale (1/100 size, 1/25 cost, 1/400 capacity) as well.

I agree with this.

Sidenote: it seems you can make such components available by adding the appropriate records to a single table in the database. That won't cause civvies, NPRs, or spoilers to use them, but they will be available for your own use.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 18, 2020, 01:40:49 PM
Implement small craft Refuelling System, Shuttle Bay, and Ordnance Transfer System components at 1/10 size for 1/5 cost and with 1/20 of the capacity of their full sized counterparts.  Please consider fighter scale (1/100 size, 1/25 cost, 1/400 capacity) as well.

I agree with this.

Sidenote: it seems you can make such components available by adding the appropriate records to a single table in the database. That won't cause civvies, NPRs, or spoilers to use them, but they will be available for your own use.
This is true, but Steve has asked us not to mod, and I do try to respect that.  Cheers.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on June 18, 2020, 07:35:33 PM
Implement small craft Refuelling System, Shuttle Bay, and Ordnance Transfer System components at 1/10 size for 1/5 cost and with 1/20 of the capacity of their full sized counterparts.  Please consider fighter scale (1/100 size, 1/25 cost, 1/400 capacity) as well.

I agree with this.

Sidenote: it seems you can make such components available by adding the appropriate records to a single table in the database. That won't cause civvies, NPRs, or spoilers to use them, but they will be available for your own use.
This is true, but Steve has asked us not to mod, and I do try to respect that.  Cheers.

Making changes to the database is not what is meant with "modding" the game.... that is all about changing the exe file and tinkering with the code.
Title: Re: C# Suggestions
Post by: liveware on June 18, 2020, 08:28:30 PM
Moving around jump points for strategic reasons. Since we are capable of stabilizing them, maybe jump points can be relocated as long as they are unstable. So before you stabilize one you can think about if they can be moved around to make the system potentially more save or if a transit system move the jps closer together... .

Two limiting factors: the more you want to move them the exponentially expensive it should be. Additionally on the costs it should become even more expensive if you come too close to another JP.

As a corollary to this concept, the capability to UN-stabilize jump points after they have been stabilized would be an interesting addition the game.
Title: Re: C# Suggestions
Post by: Droll on June 18, 2020, 08:42:14 PM
Moving around jump points for strategic reasons. Since we are capable of stabilizing them, maybe jump points can be relocated as long as they are unstable. So before you stabilize one you can think about if they can be moved around to make the system potentially more save or if a transit system move the jps closer together... .

Two limiting factors: the more you want to move them the exponentially expensive it should be. Additionally on the costs it should become even more expensive if you come too close to another JP.

As a corollary to this concept, the capability to UN-stabilize jump points after they have been stabilized would be an interesting addition the game.

I don't think permanent de-stabilization is a good idea however I think it would be great to have some sort of "interdiction module" that when used on a jump point will take x amount of time and will distrupt a stabilized point for y amount of time, after which the jump point reverts back to its stabilized state.

To further extend this I think it would be cool to have some sort of advanced interdiction that can (albeit temporarily) completely disrupt a jump point, rendering it unusable by anything. I don't think allowing this to happen permanently is a good idea since you would end up with a bunch of useless isolated systems eventually.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 18, 2020, 08:56:50 PM
Moving around jump points for strategic reasons. Since we are capable of stabilizing them, maybe jump points can be relocated as long as they are unstable. So before you stabilize one you can think about if they can be moved around to make the system potentially more save or if a transit system move the jps closer together... .

Two limiting factors: the more you want to move them the exponentially expensive it should be. Additionally on the costs it should become even more expensive if you come too close to another JP.

As a corollary to this concept, the capability to UN-stabilize jump points after they have been stabilized would be an interesting addition the game.

I don't think permanent de-stabilization is a good idea however I think it would be great to have some sort of "interdiction module" that when used on a jump point will take x amount of time and will distrupt a stabilized point for y amount of time, after which the jump point reverts back to its stabilized state.

To further extend this I think it would be cool to have some sort of advanced interdiction that can (albeit temporarily) completely disrupt a jump point, rendering it unusable by anything. I don't think allowing this to happen permanently is a good idea since you would end up with a bunch of useless isolated systems eventually.
Jump point stabilization has significant strategic implications, primarily border control and containing civilian operations.  Permanent destabilization would be an asset when moving into an area where an NPR 'helpfully' stabilized every jump point.
Title: Re: C# Suggestions
Post by: QuakeIV on June 18, 2020, 11:06:06 PM
I personally think it would be cooler if jump gates were actually big constructs, however the reason they arent is Steve is a big fan of them being a major strategic choice to stabalize a point.

I'm not a huge fan of the idea but point being, the points not really being possible to de-stabalize is working as intended.
Title: Re: C# Suggestions
Post by: serger on June 18, 2020, 11:57:04 PM
Make "not enough PPV" unrest depending on racial xenophobia and maybe militancy too.
Make it enabled in the moment of first contact, maybe with an option (checkbox) of "Precontact Xenophobia", that will switch it on from the start of game.
Title: Re: C# Suggestions
Post by: serger on June 19, 2020, 12:07:08 AM
Make Available Workers (~ unemployed) generating some unrest, maybe affected by Determinancy and/or Trade racial stats.

(The thing I want is some constant source of economic unrest, not only military and life-support ones.)
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 19, 2020, 12:55:13 AM
Make Available Workers (~ unemployed) generating some unrest, maybe affected by Determinancy and/or Trade racial stats.

(The thing I want is some constant source of economic unrest, not only military and life-support ones.)
While I like this idea, population management is already too micro-managy.  The only viable solution would become 'drop troops on it until things settle down'.
Title: Re: C# Suggestions
Post by: liveware on June 19, 2020, 01:05:07 AM
Moving around jump points for strategic reasons. Since we are capable of stabilizing them, maybe jump points can be relocated as long as they are unstable. So before you stabilize one you can think about if they can be moved around to make the system potentially more save or if a transit system move the jps closer together... .

Two limiting factors: the more you want to move them the exponentially expensive it should be. Additionally on the costs it should become even more expensive if you come too close to another JP.

As a corollary to this concept, the capability to UN-stabilize jump points after they have been stabilized would be an interesting addition the game.

I don't think permanent de-stabilization is a good idea however I think it would be great to have some sort of "interdiction module" that when used on a jump point will take x amount of time and will distrupt a stabilized point for y amount of time, after which the jump point reverts back to its stabilized state.

To further extend this I think it would be cool to have some sort of advanced interdiction that can (albeit temporarily) completely disrupt a jump point, rendering it unusable by anything. I don't think allowing this to happen permanently is a good idea since you would end up with a bunch of useless isolated systems eventually.
Jump point stabilization has significant strategic implications, primarily border control and containing civilian operations.  Permanent destabilization would be an asset when moving into an area where an NPR 'helpfully' stabilized every jump point.

I have never encountered a 'helpful' NPR nor have I encountered a jump point stabilized by a NPR. Is this actually a possibility in-game?

I stand by my previous assertion that jump point destabilization would be an interesting game mechanic. ESPECIALLY if NPRs can stabilize jump points.

If demons were invading Earth would you not want the ability the close the demonic warp gate? I certainly would....

To clarify I am not arguing for permanent destabilization of jump points. I think it should be allowable to re-stabilize a previously destabilized jump point.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 19, 2020, 01:27:37 AM
Moving around jump points for strategic reasons. Since we are capable of stabilizing them, maybe jump points can be relocated as long as they are unstable. So before you stabilize one you can think about if they can be moved around to make the system potentially more save or if a transit system move the jps closer together... .

Two limiting factors: the more you want to move them the exponentially expensive it should be. Additionally on the costs it should become even more expensive if you come too close to another JP.

As a corollary to this concept, the capability to UN-stabilize jump points after they have been stabilized would be an interesting addition the game.

I don't think permanent de-stabilization is a good idea however I think it would be great to have some sort of "interdiction module" that when used on a jump point will take x amount of time and will distrupt a stabilized point for y amount of time, after which the jump point reverts back to its stabilized state.

To further extend this I think it would be cool to have some sort of advanced interdiction that can (albeit temporarily) completely disrupt a jump point, rendering it unusable by anything. I don't think allowing this to happen permanently is a good idea since you would end up with a bunch of useless isolated systems eventually.
Jump point stabilization has significant strategic implications, primarily border control and containing civilian operations.  Permanent destabilization would be an asset when moving into an area where an NPR 'helpfully' stabilized every jump point.

I have never encountered a 'helpful' NPR nor have I encountered a jump point stabilized by a NPR. Is this actually a possibility in-game?

I stand by my previous assertion that jump point destabilization would be an interesting game mechanic. ESPECIALLY if NPRs can stabilize jump points.

If demons were invading Earth would you not want the ability the close the demonic warp gate? I certainly would....
Spamming JP stabilizers is one of the possible AI behaviours that gets chosen at random at NPR creation.  My current game has one inside my perimeter because it managed to sneak past my sensor buoys.  Unless NPRs don't need to gravsurvey then they also got some of those in undetected as well and I can't find them.  :(
Title: Re: C# Suggestions
Post by: QuakeIV on June 19, 2020, 03:04:53 PM
Yeah almost every JP in my game is stabalized.
Title: Re: C# Suggestions
Post by: QuakeIV on June 19, 2020, 03:05:44 PM
I suggest that there be an order along the lines of '80% of maintenance life exceeded', and an ability to queue an order to go find a place to get an overhaul and resupply.  It would reduce the burning agony of dealing with survey ships by quite a lot.
Title: Re: C# Suggestions
Post by: skoormit on June 20, 2020, 09:24:20 AM
Two small QoL suggestions:

1) Allow me to designate a current research project as the assignment of any new research labs. That way I don't get an interrupt for idle labs every time I build or import a lab.

2) New shipyard activity: "Add Multiple Slipways." Works like "Continual Capacity Upgrade": I give it a target number, and it keeps building slipways until I have that many.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on June 20, 2020, 01:24:21 PM
I suggest that there be an order along the lines of '80% of maintenance life exceeded', and an ability to queue an order to go find a place to get an overhaul and resupply.  It would reduce the burning agony of dealing with survey ships by quite a lot.

I don't think this is enough...

I need a condition for deployment exceeded so I can send them home when their deployment is over... i don't want to wait until their maintenance supply fall below a certain level. I build all of my survey ship from a specific deployment time and send them home for overhaul when that is over.

I also don't understand why ship that do overhauls don't automatically try to refuel and resupply if they can when overhaul is done... at least add a conditional order such as refuel, resupply and Overhaul.

If we also had expandable order lists we could easily get the option of a condition such as "On MSP level..."  and then a list from 10-90%. The order would then be On MSP level 80% then "conditional order".
Title: Re: C# Suggestions
Post by: QuakeIV on June 20, 2020, 03:37:49 PM
I don't think you read my thing, I said 'maintenance life' not MSP quantity.  I'd like an order to send them home for overhaul and resupply once they reach a certain percentage of their planned maintenance life.  That tends to be a lot closer to the limit of the ship than trying to do it off of MSP, since the MSP thing tends to run out all at once near the end of said maint life.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on June 20, 2020, 04:38:55 PM
I don't think you read my thing, I said 'maintenance life' not MSP quantity.  I'd like an order to send them home for overhaul and resupply once they reach a certain percentage of their planned maintenance life.  That tends to be a lot closer to the limit of the ship than trying to do it off of MSP, since the MSP thing tends to run out all at once near the end of said maint life.

That would be a good one too of course and still I would like one for deployment as well.  ;)
Title: Re: C# Suggestions
Post by: Gram123 on June 21, 2020, 07:32:20 AM
I made this post in the general discussion topic and someone suggested that it might belong in suggestions so here I go:

http://aurora2.pentarch.org/index.php?topic=11688.0

Its a few features in the galatic map that used to be in VB but did not make it to C# for some reason.
Title: Re: C# Suggestions
Post by: Droll on June 21, 2020, 02:23:45 PM
Split the military academy into multiple structures:
Institute (scientists)
University (civilian admins)
Naval Academy (navy officers)
Ground Academy (ground officers)

Each one of these buildings would train only the officers of corresponding positions. This would give finer control to the player over who gets recruited as a commander and works well with the admin commandant system in place. Much like now, military officers and civie admins with certain skills would make their assigned academy produce officers who also have those skills. Scientists would focus their assigned institute for the field that they are experts in. However, because the facilities are more separate, you could probably double down on the bonuses that current academy commandants give.

I could have one planet have an academy with a commandant who was an artillery officer making more artillery officers while another on another world has an infantry commander training new infantry commanders. Right now I find that even with commandants the academy is still producing the whole cast of officers - it doesn't feel specialized enough plus I can't control how many of what type of officers I have very well.
Title: Re: C# Suggestions
Post by: coolkirk1701 on June 21, 2020, 07:34:59 PM
Definitely second the suggestion of a zoom feature for the galactic map.   In addition, I know it would probably be difficult to script, but I would just LOVE a button to automatically arrange new systems so that i can stop having to refresh the map, move the Sol system to the side, move the new system to the right place, put the Sol system back, save, and then immediately discover a new system and repeat the entire process.
Title: Re: C# Suggestions
Post by: Demakustus on June 23, 2020, 03:58:40 AM
(...)
2) New shipyard activity: "Add Multiple Slipways." Works like "Continual Capacity Upgrade": I give it a target number, and it keeps building slipways until I have that many.
I second that but with an addition, that the amount of slipways is stored as a decimal. Then you could interrupt expanding a new slipway to retool the shipyard to a new class, and resume the expansion afterwards without loosing progress, similarly how you can do right now with continual capacity expansion.

Making the retool activity to be just an interrupt, after which the previous activity is restored without penalty, would be even better.
Title: Re: C# Suggestions
Post by: Dawa1147 on June 23, 2020, 05:55:38 AM
Expand on the Carried Items screen, currently it shows Ordenance and Cargo, have it include Parasites
Title: Re: C# Suggestions
Post by: skoormit on June 23, 2020, 11:37:16 AM
The new ability to stabilize Lagrange points for large bodies is great. I love making shortcuts throughout all of my systems to improve the operational efficiency of my freighters, colonizers, and tankers, and of civilian shipping.

But, since LPs move along with the orbit of the associated body, an LP hop that shortens a given route today might actually lengthen that route at some point in the future.
The shorter the orbital period of the LPs, and of the solar body that is the final destination, the more frequently a given LP hop will alternate between being a shortcut and being a...longcut.
Which means I have to constantly update my order templates and the cycling paths of my fleets to use LPs appropriately.

Can we instead let fleets use LPs dynamically?
In this mode, LP shortcuts are not added to the ships order list as we give the fleet orders.
Instead, every time a ship begins to move towards the next order location, it first checks if a shorter route is available via LP hops.
If so, it makes use of that hop (or hops) and inserts the order(s) for the shorter route at the top of the order list, so we can tell why the fleet is moving that way.

In this mode, the "All Orders Distance" displayed at the top of the fleet window should account for all anticipated LPs along the path.
Therefore the distance displayed would be an estimate. Optimal LP shortcuts may change while the fleet is in transit; the estimated distance would change to reflect that.
To save processing, perhaps a fleet checks its remaining path only whenever it begins moving towards a new location (instead of checking every sub-pulse).
The order list could indicate any orders for which an LP shortcut is anticipated, and perhaps also the distance saved. For example:
Quote
Earth: Move to Location (-1.1 b km via jump LP1-LP2)

We probably want to preserve the per-fleet option to not automatically use LPs, for those rare cases when traveling the longer route is needed.
Title: Re: C# Suggestions
Post by: Shaunus82 on June 23, 2020, 02:27:48 PM
Not sure if this has been mentioned before, but I would love to see some kind of help list where you could go to find out information on what the various buildings, components and weapon systems are for, and what they do.  This would greatly help new players.  For instance, I have been playing this game for a few months now, and there are several weapons systems I have never used, because I simply don't have any idea what they are used for, or how they work, so I have just mainly been sticking to simple weapons such as lasers, railguns.  It would just be nice to have some additional information to hand, in game.
Title: Re: C# Suggestions
Post by: Droll on June 23, 2020, 02:30:37 PM
Not sure if this has been mentioned before, but I would love to see some kind of help list where you could go to find out information on what the various buildings, components and weapon systems are for, and what they do.  This would greatly help new players.  For instance, I have been playing this game for a few months now, and there are several weapons systems I have never used, because I simply don't have any idea what they are used for, or how they work, so I have just mainly been sticking to simple weapons such as lasers, railguns.  It would just be nice to have some additional information to hand, in game.

When creating research projects some of them have links to the aurora wiki I think.
Title: Re: C# Suggestions
Post by: QuakeIV on June 23, 2020, 04:24:32 PM
I was pretty sure fleets actually accounted for orbital motion when planning out LP use.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 23, 2020, 04:27:43 PM
I was pretty sure fleets actually accounted for orbital motion when planning out LP use.
That is when planning a simple route.  Templates, cycled orders, and repeated orders have problems.
Title: Re: C# Suggestions
Post by: QuakeIV on June 23, 2020, 04:30:21 PM
Oh, snap.  Yeah it might make more sense if the ships just planned LP use under the hood so that you dont accidentally repeat them later.
Title: Re: C# Suggestions
Post by: bean on June 25, 2020, 12:07:23 PM
Two usability improvements.

First, the game reuses alien class names in a really confusing way.  I was taking over someone else's system, and I kept having classes flagged with reporting names, then learning the real name of the class, then having the name get reused for a new, completely different class.  For some names, this happened more than once.  It would be extremely nice if it just crossed the name off even when you found out the proper name.

Second, when you use the autoroute by system, it currently sorts systems alphabetically.  This is annoying when you have a 100+ systems, and keep wanting to send ships back to Sol, most of the way down the list.  I want to go to populated systems far more often than I want to go to empty ones, after all, and I doubt I'm alone in this.  So why not sort to show populated systems first, then unpopulated systems with colonies, then empty systems?
Title: Re: C# Suggestions
Post by: Droll on June 25, 2020, 01:03:01 PM
Second, when you use the autoroute by system, it currently sorts systems alphabetically.  This is annoying when you have a 100+ systems, and keep wanting to send ships back to Sol, most of the way down the list.  I want to go to populated systems far more often than I want to go to empty ones, after all, and I doubt I'm alone in this.  So why not sort to show populated systems first, then unpopulated systems with colonies, then empty systems?

+1 points to Griffindor!

Jokes aside I agree and second this motion
Title: Re: C# Suggestions
Post by: amram on June 25, 2020, 02:06:34 PM
Second, when you use the autoroute by system, it currently sorts systems alphabetically.  This is annoying when you have a 100+ systems, and keep wanting to send ships back to Sol, most of the way down the list.  I want to go to populated systems far more often than I want to go to empty ones, after all, and I doubt I'm alone in this.  So why not sort to show populated systems first, then unpopulated systems with colonies, then empty systems?

Definitely this.

As a workaround that does what you're asking, rename them by putting a space in front of their name, they'll be in their own sort at the top of the list.  i.e. "Sol" becomes " Sol".  All the names with space will be above all the names without.  When they get to be too numerous, and you have a couple really important colonies, add another space, al the names with two leading spaces will be above the names with only one leading space.
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 25, 2020, 02:09:13 PM
Second, when you use the autoroute by system, it currently sorts systems alphabetically.  This is annoying when you have a 100+ systems, and keep wanting to send ships back to Sol, most of the way down the list.  I want to go to populated systems far more often than I want to go to empty ones, after all, and I doubt I'm alone in this.  So why not sort to show populated systems first, then unpopulated systems with colonies, then empty systems?

Definitely this.

As a workaround that does what you're asking, rename them by putting a space in front of their name, they'll be in their own sort at the top of the list.  i.e. "Sol" becomes " Sol".  All the names with space will be above all the names without.  When they get to be too numerous, and you have a couple really important colonies, add another space, al the names with two leading spaces will be above the names with only one leading space.
The problem with renaming systems, including this method and using routing numbers, is that it breaks themes.  Every new system will be given the first name in whichever theme you are using.
Title: Re: C# Suggestions
Post by: S1mancoder on June 25, 2020, 03:53:24 PM
Would be very nice and logical if Refueling/Ordnance transfer system performance would stack (atm.  they do not).  This is seem like a very easy implement by itself, and if the balance is a consideration (to prevent almost instant combar ressuply from "flying magazine" ship) then this can already be done with multiple smaller reloader ships (that would also have smaller cross section and thus less vulnerable to detection).
Title: Re: C# Suggestions
Post by: Second Foundationer on June 28, 2020, 09:17:53 AM
Second, when you use the autoroute by system, it currently sorts systems alphabetically.  This is annoying when you have a 100+ systems, and keep wanting to send ships back to Sol, most of the way down the list.  I want to go to populated systems far more often than I want to go to empty ones, after all, and I doubt I'm alone in this.  So why not sort to show populated systems first, then unpopulated systems with colonies, then empty systems?

Definitely this.

As a workaround that does what you're asking, rename them by putting a space in front of their name, they'll be in their own sort at the top of the list.  i.e. "Sol" becomes " Sol".  All the names with space will be above all the names without.  When they get to be too numerous, and you have a couple really important colonies, add another space, al the names with two leading spaces will be above the names with only one leading space.
The problem with renaming systems, including this method and using routing numbers, is that it breaks themes.  Every new system will be given the first name in whichever theme you are using.

It would take some interface work; but the central options tickbox box in the movement orders isn't actually used with autoroute by system, is it? So, how about just having autoroute filter and sort options in there while Autoroute by System is selected? Show populated/colonized-unpopulated/uncolonized systems and desc-sort by population/[maybe # of colonies or total # of installations/AMs].

Since this is the suggestions thread and the universe of ideas and wishful thinking: Sort by number of jumps and sort by distance from starting system (=where in the orders list one switches to autoroute by system) might be useful options there at times as well.
At least they would be for me as the inhabited part of my current empire crosses the 50 b km star-to-star cross-section mark with ion engines, and sometimes I want to weigh possible destinations for installations or survey ships based on speed/deployment effeciency.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on June 28, 2020, 11:43:42 AM
While we are begging for autoroute improvements, I'd like to add that it would be really nice if autoroute (and the related refuel/resupply standing orders) would actually find the shortest path.  At the scale of Aurora jump point networks, Dijkstra's algorithm (aka uniform cost search) should be effectively free.  It's rather annoying to watch my survey ships run out of fuel because they took a route 20% longer than the actual correct path.
Title: Re: C# Suggestions
Post by: S1mancoder on June 29, 2020, 06:00:59 AM
Would be nice if NPR's (at least special ones suffer from this) STO's would have sensor enabled (which would let them actually engage targets) and if large caliber (any arbitrary way to determine) then mode set to target ships, not all point defence.
Kinda sad to see that NPR 20-ish strength 37 laser battery sitting sensors off and in PD mode.
Title: Re: C# Suggestions
Post by: rekrats on June 29, 2020, 11:45:05 AM
A nice feature would be if i could set jump point construction ships to automatically stabilize Lagrange points like i could set the to automatically build nearest jump gate.
Title: Re: C# Suggestions
Post by: skoormit on June 30, 2020, 01:37:58 PM
A nice feature would be if i could set jump point construction ships to automatically stabilize Lagrange points like i could set the to automatically build nearest jump gate.

I am intrigued.
I'm a huge fan of stabilizing Lagrange points, but I find that I leave most available LP points alone, either because they don't improve any possible routes, or they take too long to be worthwhile.
Are you really stabilizing all of the available LPs?
Title: Re: C# Suggestions
Post by: QuakeIV on June 30, 2020, 09:36:21 PM
That would be a lot of Lagrange points, you can stabilize large-ish moons even (in fact its kindof critical for having fast routs out to distant gas giants).
Title: Re: C# Suggestions
Post by: SpikeTheHobbitMage on June 30, 2020, 10:51:21 PM
That would be a lot of Lagrange points, you can stabilize large-ish moons even (in fact its kindof critical for having fast routs out to distant gas giants).
Reaching gas giants and secondary stars is why the Lagrange point system exists in the first place.  Stabilizing an inner system body helps with that, but otherwise I can't think of any reason to ever stabilize an LP.
Title: Re: C# Suggestions
Post by: QuakeIV on July 01, 2020, 12:58:29 AM
I feel like this must have been suggested before, but it would be nice if in the ship design menu, you had the same window as the 'select name' window from the shipyard screen.  It would make it a lot easier to figure out what the different name themes have to offer.
Title: Re: C# Suggestions
Post by: Cobaia on July 01, 2020, 03:23:38 AM
I feel like this must have been suggested before, but it would be nice if in the ship design menu, you had the same window as the 'select name' window from the shipyard screen.  It would make it a lot easier to figure out what the different name themes have to offer.

Sorry if I miss understanding what you are saying, but  the same screen is available. Third button top row.
Title: Re: C# Suggestions
Post by: skoormit on July 01, 2020, 07:52:34 PM
Reaching gas giants and secondary stars is why the Lagrange point system exists in the first place.  Stabilizing an inner system body helps with that, but otherwise I can't think of any reason to ever stabilize an LP.

I also find that it is not uncommon for an LP at an outer planet of a primary star to provide a nice shortcut for getting to/from a nearby JP.
The farther out, the better, since that means a slower orbit, and a longer time during which the LP is in a useful position.
Title: Re: C# Suggestions
Post by: QuakeIV on July 02, 2020, 02:18:22 AM
I feel like this must have been suggested before, but it would be nice if in the ship design menu, you had the same window as the 'select name' window from the shipyard screen.  It would make it a lot easier to figure out what the different name themes have to offer.

Sorry if I miss understanding what you are saying, but  the same screen is available. Third button top row.

Hmm, I mean with respect to the miscellaneous tab in the ship design window (actually called class design turns out) when you are picking the ship naming theme.  I just checked and I cant find what you are referring to so I believe we are talking about different windows entirely.
Title: Re: C# Suggestions
Post by: Cobaia on July 02, 2020, 03:41:58 AM
I feel like this must have been suggested before, but it would be nice if in the ship design menu, you had the same window as the 'select name' window from the shipyard screen.  It would make it a lot easier to figure out what the different name themes have to offer.

Sorry if I miss understanding what you are saying, but  the same screen is available. Third button top row.

Hmm, I mean with respect to the miscellaneous tab in the ship design window (actually called class design turns out) when you are picking the ship naming theme.  I just checked and I cant find what you are referring to so I believe we are talking about different windows entirely.


Picture 1 was the option you were talking about right?

Picture 2 is the same button on the class design window.

Is it the same?
Title: Re: C# Suggestions
Post by: QuakeIV on July 02, 2020, 11:16:33 PM
Oh ok its in the main tab, that makes sense.  Its for picking the name of the class rather than picking the naming theme of the ships that get built, but its at least more localized.
Title: Re: C# Suggestions
Post by: Panopticon on July 03, 2020, 07:35:03 PM
Reading the latest AAR from Steve and I noticed that he said population growth on Earth is more or less keeping up with evacuation. Humans are pretty idiotic at times but I think maybe if the planet was gonna crash into the sun soon we might not be reproducing like rabbits in the meantime. Maybe add an option to remove or reduce population growth on bodies effected by a disaster?
Title: Re: C# Suggestions
Post by: Vastrat on July 03, 2020, 07:43:19 PM
You gotta do something while waiting for the planet to plunge into the sun.  ;D
Title: Re: C# Suggestions
Post by: amram on July 04, 2020, 04:34:39 AM
Reading the latest AAR from Steve and I noticed that he said population growth on Earth is more or less keeping up with evacuation. Humans are pretty idiotic at times but I think maybe if the planet was gonna crash into the sun soon we might not be reproducing like rabbits in the meantime. Maybe add an option to remove or reduce population growth on bodies effected by a disaster?

I'd think a large number of people would be indulging more.  The saying is to live today as if its your last day, and for the majority of humans, it would be, I would not be surprised if the birthrate skyrocketed in such scenario.
Title: Re: C# Suggestions
Post by: QuakeIV on July 04, 2020, 09:22:11 PM
Thats silly, birth control is super easy.  Maybe people wouldn't normally go out of their way to use it, but if the planet is literally about to explode it seems like they might be more willing to avoid children at that point.

Maybe a setting of 'evacuation' to go along with 'destination of colonists' 'source of colonists' etc setting would trigger that kind of behavior for when you are trying to get as close to reducing a colonies population to zero as possible before its destroyed.

e: Honestly it would actually be really cool if an 'evacuation' colony let you effectively cause all of your civilian shipping to drop what its doing and start evaccing that planet (though that might be going a bit too far).  (for instance imagine when capella or vasuda was being evacuated in freespace 2)
Title: Re: C# Suggestions
Post by: Panopticon on July 04, 2020, 09:50:37 PM
Yeah, I'm not sure it would be realistic to drop pop growth to zero entirely, but I know that if the world was ending in a few years I certainly wouldn't be bringing a child into it, and TN birth control has to be pretty effective right?

I also think that it might be too much to apply pop growth controls wherever you want, which is why I suggested tying it to disasters, since it will probably take the literal end of the world to get humans to stop reproducing so much.
Title: Re: C# Suggestions
Post by: QuakeIV on July 05, 2020, 02:09:35 AM
Even if it opens the road to be a bit cheesy I'd kindof like to be able to move people off of a planet that I know is going to die.  Its not like there are huge negative side effects of overpopulation that you need to avoid in this game so there isnt any huge incentive to cheese that that I know of.
Title: Re: C# Suggestions
Post by: S1mancoder on July 09, 2020, 07:45:33 AM
Designing yet another combat jump-capable fleet I relaized that you are pretty much forced into roughly same sized ship for efficient utilizing of a jump drive potential and having all ships kinda equal size is kinda. . .  boring.

So apparently I think there is an easy and rather consistent solution: instead of having Squadron Size as a number of ships, we could have it as a multiplier to tender tonnage with resulting number defining total jumping tonnage.  Squadron Size 2 would mean that with a jump tender of tonnage X any number of ships with total tonnage of X can jump as squadron (so total of 2*X), Squadron Size 4 would mean that for tonnage X any number of ships up to totall tonnage 3*X can jump (so total of 4*X).  So Squadron Size would define total sqadron tonnage including jump ship.

This way we can have some fancy RP-ish fleets with a jumping supercaptial/supercarrier and a fleet of escorts utilising the jump wormhole created by that supership, which I think would be very nice  and more fun than just all 5k/10k/20k/30k ships to keep up with current tender mechanics.
Title: Re: C# Suggestions
Post by: xenoscepter on July 09, 2020, 11:44:44 AM
 - I think that's brilliant. Simple, elegant, effective and most importantly of all it would add so much to the game...
Title: Re: C# Suggestions
Post by: Cobaia on July 09, 2020, 12:31:38 PM
Designing yet another combat jump-capable fleet I relaized that you are pretty much forced into roughly same sized ship for efficient utilizing of a jump drive potential and having all ships kinda equal size is kinda. . .  boring.

So apparently I think there is an easy and rather consistent solution: instead of having Squadron Size as a number of ships, we could have it as a multiplier to tender tonnage with resulting number defining total jumping tonnage.  Squadron Size 2 would mean that with a jump tender of tonnage X any number of ships with total tonnage of X can jump as squadron (so total of 2*X), Squadron Size 4 would mean that for tonnage X any number of ships up to totall tonnage 3*X can jump (so total of 4*X).  So Squadron Size would define total sqadron tonnage including jump ship.

This way we can have some fancy RP-ish fleets with a jumping supercaptial/supercarrier and a fleet of escorts utilising the jump wormhole created by that supership, which I think would be very nice  and more fun than just all 5k/10k/20k/30k ships to keep up with current tender mechanics.


I don't get the difference from the system we have in place now. I use 18.000t ship that has the Jump Drive and I can jump any ship from 0t to 18.000t, isn't that the same concept? I can jump a 2.000.000t fleet as long as the tonnage is lower. Right?
Title: Re: C# Suggestions
Post by: Droll on July 09, 2020, 12:44:25 PM
Designing yet another combat jump-capable fleet I relaized that you are pretty much forced into roughly same sized ship for efficient utilizing of a jump drive potential and having all ships kinda equal size is kinda. . .  boring.

So apparently I think there is an easy and rather consistent solution: instead of having Squadron Size as a number of ships, we could have it as a multiplier to tender tonnage with resulting number defining total jumping tonnage.  Squadron Size 2 would mean that with a jump tender of tonnage X any number of ships with total tonnage of X can jump as squadron (so total of 2*X), Squadron Size 4 would mean that for tonnage X any number of ships up to totall tonnage 3*X can jump (so total of 4*X).  So Squadron Size would define total sqadron tonnage including jump ship.

This way we can have some fancy RP-ish fleets with a jumping supercaptial/supercarrier and a fleet of escorts utilising the jump wormhole created by that supership, which I think would be very nice  and more fun than just all 5k/10k/20k/30k ships to keep up with current tender mechanics.


I don't get the difference from the system we have in place now. I use 18.000t ship that has the Jump Drive and I can jump any ship from 0t to 18.000t, isn't that the same concept?

No, what he is saying that with a squadron size 3, your 18000t jump tender would be able to squadron jump any number of ships as long as the total tonnage of the squadron is under/equal to 54000t (18000t x 3) and no single ship in the squadron is above 18000t.

Right now with the way squadron jumping works, a squadron jump size of 3 means you can support up to 3 ships regardless of overall tonnage. So a 50k ton jump tender would be able to jump at most 3 ships even if they are tiny 2000t corvettes, Whereas with this new system that same tender would be able to jump 75 of those corvettes.

I think this change is inspired since it removes the end game squadron size cap of 12 and places that limit in the hand of the player with how they design their jump tenders.
Title: Re: C# Suggestions
Post by: Cobaia on July 09, 2020, 12:49:16 PM
Designing yet another combat jump-capable fleet I relaized that you are pretty much forced into roughly same sized ship for efficient utilizing of a jump drive potential and having all ships kinda equal size is kinda. . .  boring.

So apparently I think there is an easy and rather consistent solution: instead of having Squadron Size as a number of ships, we could have it as a multiplier to tender tonnage with resulting number defining total jumping tonnage.  Squadron Size 2 would mean that with a jump tender of tonnage X any number of ships with total tonnage of X can jump as squadron (so total of 2*X), Squadron Size 4 would mean that for tonnage X any number of ships up to totall tonnage 3*X can jump (so total of 4*X).  So Squadron Size would define total sqadron tonnage including jump ship.

This way we can have some fancy RP-ish fleets with a jumping supercaptial/supercarrier and a fleet of escorts utilising the jump wormhole created by that supership, which I think would be very nice  and more fun than just all 5k/10k/20k/30k ships to keep up with current tender mechanics.


I don't get the difference from the system we have in place now. I use 18.000t ship that has the Jump Drive and I can jump any ship from 0t to 18.000t, isn't that the same concept?

No, what he is saying that with a squadron size 3, your 18000t jump tender would be able to jump any number of ships as long as the total tonnage of the squadron is under/equal to 54000t (18000t x 3) and no single ship in the squadron is above 18000t.

Right now with the way squadron jumping works, a squadron jump size of 3 means you can support up to 3 ships regardless of overall tonnage. So a 50k ton jump tender would be able to jump at most 3 ships even if they are tiny 2000t corvettes, Whereas with this new system that same tender would be able to jump 75 of those corvettes.

I think this change is inspired since it removes the end game squadron size cap of 12 and places that limit in the hand of the player with how they design their jump tenders.

OK so it's a multiplier instead of an hard number. Sorry I updated the reply. My question is: one 18.000t Jump Drive can jump any number of ships not just the 3 as long as it is in the JP, so a fleet composed of x number of ships with tonnage < 18.000t and y total fleet tonnage > 18.000t can jump trough right?

Maybe I'm just confusing myself :O
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on July 09, 2020, 01:04:44 PM
There are two kinds of transits: squadron jump and standard transit.

In a standard transit, one jump drive can handle an arbitrary number of ships as long as they are all smaller than its max size (i.e. 18kt in the current example).

In a squadron transit, one jump drive can handle a fixed number of ships (3 is the starting tech, can be increased at a slight increase in size of the drive). All ships ALSO need to be <= max size (again, 18kt).

The proposal is to modify squadron transits to work on a total tonnage capacity, rather than a number of vessels. So a 3x jump drive at 18kt could jump 3x18kt ships, or 6x9kt ships. But not 1x36kt ship + 1x18kt ship.
Title: Re: C# Suggestions
Post by: Cobaia on July 09, 2020, 01:09:16 PM
Yeah I forgot about the difference between Squadron and Standard transit.... my fault. Thank you.

Title: Re: C# Suggestions
Post by: Andrew on July 11, 2020, 06:03:11 PM
New Standing Order. Rescue closest Life pod.

It would save a lot of manual effort if a lot of ships have been blown up and you want to rescue all the survivors
Title: Please add "repeat order by X amount"
Post by: SpaceMarine on July 12, 2020, 05:23:10 AM
This was in VB6 and is not in C# as I presume an oversight, you currently have to do multiplication to actually get the orders you want, this can be extremely annoying and forces me to instead just use civs for this to get precise quantities of stuff.

Would be great, I feel this should of been re added a while ago, thanks for reading steve if you are!
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 12, 2020, 05:43:57 AM
1) Allow me to designate a current research project as the assignment of any new research labs. That way I don't get an interrupt for idle labs every time I build or import a lab.

Added and extended a little.

http://aurora2.pentarch.org/index.php?topic=11593.msg138663#msg138663
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 12, 2020, 05:44:17 AM
New Standing Order. Rescue closest Life pod.

It would save a lot of manual effort if a lot of ships have been blown up and you want to rescue all the survivors

Added for v1.12.
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 12, 2020, 05:57:53 AM
I need a condition for deployment exceeded so I can send them home when their deployment is over... i don't want to wait until their maintenance supply fall below a certain level. I build all of my survey ship from a specific deployment time and send them home for overhaul when that is over.

Added for v1.12

http://aurora2.pentarch.org/index.php?topic=11593.msg138666#msg138666
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 12, 2020, 06:07:35 AM
Expand on the Carried Items screen, currently it shows Ordenance and Cargo, have it include Parasites

Added for v1.12
Title: Re: Please add "repeat order by X amount"
Post by: Steve Walmsley on July 12, 2020, 06:22:46 AM
This was in VB6 and is not in C# as I presume an oversight, you currently have to do multiplication to actually get the orders you want, this can be extremely annoying and forces me to instead just use civs for this to get precise quantities of stuff.

Would be great, I feel this should of been re added a while ago, thanks for reading steve if you are!

Added for v1.12

http://aurora2.pentarch.org/index.php?topic=11593.msg138669#msg138669
Title: Re: C# Suggestions
Post by: Marski on July 12, 2020, 06:44:37 AM
Number of officer types graduated by military academy relatively to the number of ranks. I've added 3 additional ranks to the ground forces due to designing ground forces down to squad-level and even with all military academies having a ground force commander assigned to them, it is still too little to supply the required officers for three regiments of size 68,000~ each.

(https://i.imgur.com/0QXaHxe.png)
Title: Re: C# Suggestions
Post by: Froggiest1982 on July 12, 2020, 06:51:47 AM
As Steve is rock and rolling today I am trying my luck as I am sure many others would love to see this happening sometime

http://aurora2.pentarch.org/index.php?topic=11597.msg135897#msg135897
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 12, 2020, 07:00:24 AM
I need a condition for deployment exceeded so I can send them home when their deployment is over... i don't want to wait until their maintenance supply fall below a certain level. I build all of my survey ship from a specific deployment time and send them home for overhaul when that is over.

Added for v1.12

http://aurora2.pentarch.org/index.php?topic=11593.msg138666#msg138666

Thanks, this is really great... would it also be possible to make it so when a ship finish the overhaul during the conditional order it also try to resupply and refuel before it heads back out or at least a second overhaul conditional order that add those two. Otherwise you still will need to manually make sure that this happens... sure you can clear the order and you will get a notification of it, but this I think would be very appreciative by everyone and probably in your own games as well.  ;)
Title: Re: C# Suggestions
Post by: SpaceMarine on July 12, 2020, 07:06:06 AM
I need a condition for deployment exceeded so I can send them home when their deployment is over... i don't want to wait until their maintenance supply fall below a certain level. I build all of my survey ship from a specific deployment time and send them home for overhaul when that is over.

Added for v1.12

http://aurora2.pentarch.org/index.php?topic=11593.msg138666#msg138666

Thanks, this is really great... would it also be possible to make it so when a ship finish the overhaul during the conditional order it also try to resupply and refuel before it heads back out or at least a second overhaul conditional order that add those two. Otherwise you still will need to manually make sure that this happens... sure you can clear the order and you will get a notification of it, but this I think would be very appreciative by everyone and probably in your own games as well.  ;)

big +1
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 12, 2020, 07:19:12 AM
I need a condition for deployment exceeded so I can send them home when their deployment is over... i don't want to wait until their maintenance supply fall below a certain level. I build all of my survey ship from a specific deployment time and send them home for overhaul when that is over.

Added for v1.12

http://aurora2.pentarch.org/index.php?topic=11593.msg138666#msg138666

Thanks, this is really great... would it also be possible to make it so when a ship finish the overhaul during the conditional order it also try to resupply and refuel before it heads back out or at least a second overhaul conditional order that add those two. Otherwise you still will need to manually make sure that this happens... sure you can clear the order and you will get a notification of it, but this I think would be very appreciative by everyone and probably in your own games as well.  ;)

I hadn't really understood the issue with resupply/refuel with overhauls because I always set the two orders together, but didn't want to force a refuel/resupply for those players who could be running with a shortage.

What I hadn't realised was that this was in connection to conditional overhaul orders, in which case the option for the preceding order isn't available. I've added a new conditional order on that basis.

http://aurora2.pentarch.org/index.php?topic=11593.msg138675#msg138675
Title: Re: C# Suggestions
Post by: QuakeIV on July 12, 2020, 08:04:05 PM
So I was talking with some dude known only as 'Niko' on the discord and he pointed out that dismantling components would be a lot more useful if it provided 'say, X% of that tech level's stuff'.

I kindof took this to mean if it provided X% of progress to every intervening tech level up to and including the final technology itself, that would make it a lot more useful.  I personally wholeheartedly approve of this notion and felt the need to post it on the forums.  Currently you are encouraged to wait until one tech level before the tech of the device, to maximize the research point gain.  I think that some kind of boost of this nature would make archeology a significantly more fun mechanic in general as it would mean you want to dismantle whatever you find as soon as possible and would be rushing to obtain artifacts and ship them off for disassembly.

In example, a component offers 10% progress towards ion drive tech, and your empire is currently at nuclear thermal.

Currently:
10% progress towards improved nuclear thermal

Proposed:
10% progress towards improved nuclear thermal
10% progress towards nuclear pulse
10% progress towards improved nuclear pulse
10% progress towards ion engines
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 13, 2020, 03:49:23 AM
So I was talking with some dude known only as 'Niko' on the discord and he pointed out that dismantling components would be a lot more useful if it provided 'say, X% of that tech level's stuff'.

I kindof took this to mean if it provided X% of progress to every intervening tech level up to and including the final technology itself, that would make it a lot more useful.  I personally wholeheartedly approve of this notion and felt the need to post it on the forums.  Currently you are encouraged to wait until one tech level before the tech of the device, to maximize the research point gain.  I think that some kind of boost of this nature would make archeology a significantly more fun mechanic in general as it would mean you want to dismantle whatever you find as soon as possible and would be rushing to obtain artifacts and ship them off for disassembly.

In example, a component offers 10% progress towards ion drive tech, and your empire is currently at nuclear thermal.

Currently:
10% progress towards improved nuclear thermal

Proposed:
10% progress towards improved nuclear thermal
10% progress towards nuclear pulse
10% progress towards improved nuclear pulse
10% progress towards ion engines

It might sound good from a game-play perspective but not from a more realistic perspective. If a medieval society found a working computer they would never make anything out of it before they progressed through the technology to understand how it works. It is the same principle in the game. You can use the technology but you can't understand how it works unless you have a fundamental understanding of the technologies necessary.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 13, 2020, 10:14:40 AM
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.

The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.

We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.

This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.

As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.
Title: Re: C# Suggestions
Post by: Iceranger on July 13, 2020, 10:54:33 AM
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.

The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.

We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.

This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.

As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.

So basically the 'escort' order in VB6 I guess?
Title: Re: C# Suggestions
Post by: Droll on July 13, 2020, 10:54:50 AM
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.

The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.

We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.

This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.

As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.

I think a cool extension of the VB6 escort mechanics would be to make a new kind of waypoint which instead of being fixed to a point in space, is determined relative to the position of the parent fleet.

So I could have two forward "fleet waypoints" that are attached to the main body, one is 45 degrees off the port beam and the other 45 degrees off the starboard beam, each 20m km away. I could have a sensor parasite be sent to one of those points and make a cycling order for it to move between the two waypoints, effectively creating a very convenient forward sensor patrol to detect targets for the main fleet.

Of course having a type of waypoint that can change position is a new concept programmatically so that can complicate things.
Title: Re: C# Suggestions
Post by: skoormit on July 13, 2020, 11:19:19 AM
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.

The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.

We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.

This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.

As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.

I think a cool extension of the VB6 escort mechanics would be to make a new kind of waypoint which instead of being fixed to a point in space, is determined relative to the position of the parent fleet.

So I could have two forward "fleet waypoints" that are attached to the main body, one is 45 degrees off the port beam and the other 45 degrees off the starboard beam, each 20m km away. I could have a sensor parasite be sent to one of those points and make a cycling order for it to move between the two waypoints, effectively creating a very convenient forward sensor patrol to detect targets for the main fleet.

Of course having a type of waypoint that can change position is a new concept programmatically so that can complicate things.

I think you could do this with the VB6 escort mechanics, without needing waypoints.
You would just create two empty escort fleets at the desired bearing and distance from the main fleet, and give your sensor craft orders to move back and forth between the two fleets.

In other words, an empty fleet can act just like a waypoint.
Title: Re: C# Suggestions
Post by: Droll on July 13, 2020, 11:34:15 AM
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.

The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.

We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.

This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.

As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.

I think a cool extension of the VB6 escort mechanics would be to make a new kind of waypoint which instead of being fixed to a point in space, is determined relative to the position of the parent fleet.

So I could have two forward "fleet waypoints" that are attached to the main body, one is 45 degrees off the port beam and the other 45 degrees off the starboard beam, each 20m km away. I could have a sensor parasite be sent to one of those points and make a cycling order for it to move between the two waypoints, effectively creating a very convenient forward sensor patrol to detect targets for the main fleet.

Of course having a type of waypoint that can change position is a new concept programmatically so that can complicate things.

I think you could do this with the VB6 escort mechanics, without needing waypoints.
You would just create two empty escort fleets at the desired bearing and distance from the main fleet, and give your sensor craft orders to move back and forth between the two fleets.

In other words, an empty fleet can act just like a waypoint.

Empty fleets can only move at 1km/s, watpoints also don't clutter the naval OOB, though that is a minor issue at best since there are ways around it.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 13, 2020, 12:19:30 PM
The only really important game play mechanic thing I think Aurora lack at the moment for me to start a real multi-faction game that I can invest hundreds of hours into is some form of way to use escort, scouting or patrol with my fleets.

The current follow command always make your fleets follow from "behind" the target fleet or at a vector of 180 degree relative the heading of the target fleet. I believe that the code is pretty much there to just allow us to plug in the vector we want to follow the fleet rather than just "behind" the target fleet.

We probably could just use the same command just allow us to enter in the vector we want to follow the fleet as an option, if you leave it at zero you follow it from behind by default.

This would allow us to use passive and active scouts around our fleets with allot more simplicity than what we currently can, now we need to figure all this out with way points and that probably are too tedious for most players to even consider. I'm not going to use multiple way points for scouting and patrols around fleets for multiple faction games, that will simply take way too much time.

As much as I understand the coding for the function of this mechanic seem to already be there, we just need a way to add a variable to change the focus of where the following fleet should position itself in relation to the target fleet heading.

I think a cool extension of the VB6 escort mechanics would be to make a new kind of waypoint which instead of being fixed to a point in space, is determined relative to the position of the parent fleet.

So I could have two forward "fleet waypoints" that are attached to the main body, one is 45 degrees off the port beam and the other 45 degrees off the starboard beam, each 20m km away. I could have a sensor parasite be sent to one of those points and make a cycling order for it to move between the two waypoints, effectively creating a very convenient forward sensor patrol to detect targets for the main fleet.

Of course having a type of waypoint that can change position is a new concept programmatically so that can complicate things.

I think you could do this with the VB6 escort mechanics, without needing waypoints.
You would just create two empty escort fleets at the desired bearing and distance from the main fleet, and give your sensor craft orders to move back and forth between the two fleets.

In other words, an empty fleet can act just like a waypoint.

Empty fleets can only move at 1km/s, watpoints also don't clutter the naval OOB, though that is a minor issue at best since there are ways around it.

I have already suggested to bring back the escort mechanic and I would really like to have that back.

This particular suggestion that I made is more realistic in the short term as I believe most of the coding is already there and Steve could do this relatively quickly with little effort in comparison to code all of the escort mechanic from VB6.

Just adding in an expanded follow order would essentially make patrols around fleets quite viable.

I would not be against being able to say have way-points that move with fleets as an optional way to use scouting reference points. It would then be possible to have true patrols in a more dynamic fashion. But that is a different thing for the future, very good suggestion though.
Title: Re: C# Suggestions
Post by: QuakeIV on July 13, 2020, 10:06:06 PM
I think it would suffice to say that it would be really nice to have an easy-to-use escort mechanic, without speculating as to how difficult it would be to implement.

Also:
So I was talking with some dude known only as 'Niko' on the discord and he pointed out that dismantling components would be a lot more useful if it provided 'say, X% of that tech level's stuff'.

I kindof took this to mean if it provided X% of progress to every intervening tech level up to and including the final technology itself, that would make it a lot more useful.  I personally wholeheartedly approve of this notion and felt the need to post it on the forums.  Currently you are encouraged to wait until one tech level before the tech of the device, to maximize the research point gain.  I think that some kind of boost of this nature would make archeology a significantly more fun mechanic in general as it would mean you want to dismantle whatever you find as soon as possible and would be rushing to obtain artifacts and ship them off for disassembly.

In example, a component offers 10% progress towards ion drive tech, and your empire is currently at nuclear thermal.

Currently:
10% progress towards improved nuclear thermal

Proposed:
10% progress towards improved nuclear thermal
10% progress towards nuclear pulse
10% progress towards improved nuclear pulse
10% progress towards ion engines

It might sound good from a game-play perspective but not from a more realistic perspective. If a medieval society found a working computer they would never make anything out of it before they progressed through the technology to understand how it works. It is the same principle in the game. You can use the technology but you can't understand how it works unless you have a fundamental understanding of the technologies necessary.

I don't agree, it seems to me that generally speaking (by default) the vast majority of components you try to disassemble will be within 100 years of whatever tech you have now (if not like 20 to 40 years) rather than centuries upon centuries (computers vs medieval tech level).  It would be a reasonable approximation to assume that generally speaking your civilization knows what its looking at when it tries to disassemble a component, and the current mechanic is in my opinion far too harsh in its punishment of disassembling stuff that is more than one tech level past what you currently have.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 14, 2020, 02:18:53 AM
I think it would suffice to say that it would be really nice to have an easy-to-use escort mechanic, without speculating as to how difficult it would be to implement.

Also:
So I was talking with some dude known only as 'Niko' on the discord and he pointed out that dismantling components would be a lot more useful if it provided 'say, X% of that tech level's stuff'.

I kindof took this to mean if it provided X% of progress to every intervening tech level up to and including the final technology itself, that would make it a lot more useful.  I personally wholeheartedly approve of this notion and felt the need to post it on the forums.  Currently you are encouraged to wait until one tech level before the tech of the device, to maximize the research point gain.  I think that some kind of boost of this nature would make archeology a significantly more fun mechanic in general as it would mean you want to dismantle whatever you find as soon as possible and would be rushing to obtain artifacts and ship them off for disassembly.

In example, a component offers 10% progress towards ion drive tech, and your empire is currently at nuclear thermal.

Currently:
10% progress towards improved nuclear thermal

Proposed:
10% progress towards improved nuclear thermal
10% progress towards nuclear pulse
10% progress towards improved nuclear pulse
10% progress towards ion engines

It might sound good from a game-play perspective but not from a more realistic perspective. If a medieval society found a working computer they would never make anything out of it before they progressed through the technology to understand how it works. It is the same principle in the game. You can use the technology but you can't understand how it works unless you have a fundamental understanding of the technologies necessary.

I don't agree, it seems to me that generally speaking (by default) the vast majority of components you try to disassemble will be within 100 years of whatever tech you have now (if not like 20 to 40 years) rather than centuries upon centuries (computers vs medieval tech level).  It would be a reasonable approximation to assume that generally speaking your civilization knows what its looking at when it tries to disassemble a component, and the current mechanic is in my opinion far too harsh in its punishment of disassembling stuff that is more than one tech level past what you currently have.

Just have to agree to disagree then... until then you can always use the components instead. I don't find this are either game breaking or imbalanced as there is a use for the items in the mean time. At least you used to be able to use items you had in store but could not make.
Title: Re: C# Suggestions
Post by: SevenOfCarina on July 14, 2020, 05:38:04 AM
I would like it if launchers became more space-efficient as their size increases. Larger missiles are not exactly in a good place right now considering how frightfully deadly point-defence is; missile ECM and sensors force a certain minimum size, but there's still a really strong incentive to downsize as far as possible.

Instead of linearly scaling launcher size with missile size, I was thinking :
Launcher Size (HS) = (Missile Size in MSP)^0.8 x (Launcher Size Modifier)

This would mean that a full-size launcher for a 2.5 ton missile would take up 50 tons, for a 10 ton missile it would be 152 tons instead of 200 tons, for a 20 ton missile it would be 264 tons instead of 400 tons, and for a max-sized 250 ton missile it would be 1,990 tons instead of 5,000 tons.

I selected 0.80 as the exponent to avoid max-sized box launchers being smaller than the missiles they hold, but the exact factor is negotiable.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 14, 2020, 11:06:25 AM
I would like it if launchers became more space-efficient as their size increases. Larger missiles are not exactly in a good place right now considering how frightfully deadly point-defence is; missile ECM and sensors force a certain minimum size, but there's still a really strong incentive to downsize as far as possible.

Instead of linearly scaling launcher size with missile size, I was thinking :
Launcher Size (HS) = (Missile Size in MSP)^0.8 x (Launcher Size Modifier)

This would mean that a full-size launcher for a 2.5 ton missile would take up 50 tons, for a 10 ton missile it would be 152 tons instead of 200 tons, for a 20 ton missile it would be 264 tons instead of 400 tons, and for a max-sized 250 ton missile it would be 1,990 tons instead of 5,000 tons.

I selected 0.80 as the exponent to avoid max-sized box launchers being smaller than the missiles they hold, but the exact factor is negotiable.

One other way is to force a communications module on each missile based on how far you like to guide it. Scale it so short distances are larger than longer distances too. This would force larger missiles for any type of range and still force a small communications device on really short distances, including AMM missiles. I think that would make even more sense.

There could be a size efficiency as well in addition to this.

Small swarming missiles are very potent and perhaps a bit too effective currently, as has always been the case.
Title: Re: C# Suggestions
Post by: xenoscepter on July 14, 2020, 09:52:10 PM
 - I agree more with seven of carina, large missiles already have an advantage in range over small missiles. They suffer mostly from throw weight, or rather their lack of it. However, I would think being able to add an additional to hit chance via a communications module would be nice. Better yet, have Thermal Reduction / Cloak work on missiles and bring back armored missiles. I also think armor should add HtK like turret armor does, but also add the % chance to not take damage while being unable to be added in amounts of less than 1 MSP. So no 1.5 or 0.5 MSP of armor.

 - The main issue I can see with larger missiles, sans the issue of saturating enemy PD, is the lack of something to do with them. ECM/ECCM isn't very big, and neither are Active or Passive Sensors. Engines automatically use the best fuel consumption, so even range stops being a big deal after a certain level of tech. The other big issue is accuracy, there is no reason to make slow missiles... at all. Slow probes? Yes, but slow missiles? No.

 - Seven of Carina's idea has in fact already been implemented by Steve to a point, larger launchers reload much, much faster than before. However, they do not yet scale their tonnage to capacity like Reactors and Shields now do, so big launchers are still ton for ton as efficient as smaller ones. Jorgen_CAB's idea would give big missiles something to do that small missiles can't. Even ECM/ECCM can be mounted comfortably in a Size 6 or 9 missile, while Active Sensors really don't matter much for ASMs.

 - Giving the big ones the ability to load up on accuracy gives them more of a reason to exist, as the whole advantage of a biger missile woudl be more room to put stuff. Sol there needs to be stuff to make them better. I am more in favor of an Advanced FCS Module though, which is tied to sensors on the missile itself. Two such FCS Modules in fact, one for Active and one for Passive, with each FCS conferring a bonus based on it's type.

 - The Active FCS would confer an accuracy bonus that would work identically to Missile Tracking Speed Bonus, the longer the missile is tracking the target the better the bonus. The Passive FCS would provide the same kind of bonus as the Active FCS, but would scale based on enemy EM/TH output versus the missile's ability to detect said output. So a really hot target would confer a much higher bonus regardless of the passive sensor strength of the missile, while a really good passive sensor suite on the missile would confer a high bonus despite the target being relatively "cold".

 - When you combine those ideas with Cloak / Thermal Reduction and add back in armor, suddenly all kinds of new options exist for all the different missile sizes. Want slow, but accurate torpedoes for Commerce Raiding? Use a combination of Passive TH Sensors with Passive FCS and add Armor. Want a speedy shield buster? Big engines, Passive FCS and Passive EM Sensors. Want an ASM to cut through enemy PD? Size 8 with 75% Cloak to appears as a Size 6 and 1 layer of Armor to help deal with Meson / Gauss / Railguns. Want a super accurate mega missile of DOOM? Just cram a crap ton of Active Sensors, Passive Sensors and FCS, add ECM/ECCM, armor and so on and so forth.

 - Under that model, missiles get deadlier as they get bigger, but they also get more expensive. Medium sized missiles become more useful, while Cloaked Missiles get more powerful as Cloaking Tech increases. At 50% Cloak, a Size 12 is as hard to see as a Size 6, but would cost more. A slow torpedo would benefit from the Thermal Reduction and the Passive FCS, while everything that is big enough to mount a credible Active Sensor would benefit greatly from an Active FCS. Armor would make big missiles even more viable, as by adding HtK suddenly Railguns and Gauss become less powerful against small salvos, while AMMs will need to be more powerful to compensate.

 - Incidentally, Mesons should ignore missile armor's % chance to block incoming damage, and just deal HtK against any missiles they hit. Conversely, AMMs should suffer a flat reduction proportional to the number of layers, and then deal the rest to HtK. So the % chance to ignore damage only involves Non-Meson Beam PD and CIWS. As an aside, Missile Stages should have an option to "Deploy Sub munitions on..." and then two check boxes that read, "Launch" and "Sensor Contact" respectively. This would allow the player to designate something as a mine or a bus w/o the fiddly bits, while a lack of designation in this regard would allow booster stages, armored shells to carry them past Fighter PD, or to create buses for Orbital Bombs
Title: Re: C# Suggestions
Post by: TMaekler on July 15, 2020, 03:41:15 AM
Spacemaster Control for AI Players

This suggestion should make it possible to keep AI empires as AI empires (and not having to switch them over to play-by-player) and therefore benefitting from not having to do everything on your own.

What is the goal of having AI empires in a game? Well, we ultimately want to tell a story. But knowing everything beforehand is boring (at least for the Storyteller). So having this unknown element of AI in the game benefits the story telling.

However you have to adjust the gameplay of the human empire(s) to how the AI is playing in order to not be overwhelmed by them. At the moment AI empires have their fixed ratios of how many research they ought to build and you have to match that - or loose the tech game in the long run. Being able to except some rough control over the AIs would make it nicer to tell stories and also play at „your own pace“ if you could limit or steer some general parameters of the AI empires. At some point it might be interesting to have maybe two allied AI empires split up and one joint a human empire. Being able to control the diplomacy on some Spacemaster level would be awesome... .

What do you all thing about this? Should we as SpaceMasters have some way to steer AI in certain directions? Would you benefit from that in your storytelling?
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 15, 2020, 05:00:05 AM
- I agree more with seven of carina, large missiles already have an advantage in range over small missiles. They suffer mostly from throw weight, or rather their lack of it. However, I would think being able to add an additional to hit chance via a communications module would be nice. Better yet, have Thermal Reduction / Cloak work on missiles and bring back armored missiles. I also think armor should add HtK like turret armor does, but also add the % chance to not take damage while being unable to be added in amounts of less than 1 MSP. So no 1.5 or 0.5 MSP of armor.

 - The main issue I can see with larger missiles, sans the issue of saturating enemy PD, is the lack of something to do with them. ECM/ECCM isn't very big, and neither are Active or Passive Sensors. Engines automatically use the best fuel consumption, so even range stops being a big deal after a certain level of tech. The other big issue is accuracy, there is no reason to make slow missiles... at all. Slow probes? Yes, but slow missiles? No.

 - Seven of Carina's idea has in fact already been implemented by Steve to a point, larger launchers reload much, much faster than before. However, they do not yet scale their tonnage to capacity like Reactors and Shields now do, so big launchers are still ton for ton as efficient as smaller ones. Jorgen_CAB's idea would give big missiles something to do that small missiles can't. Even ECM/ECCM can be mounted comfortably in a Size 6 or 9 missile, while Active Sensors really don't matter much for ASMs.

 - Giving the big ones the ability to load up on accuracy gives them more of a reason to exist, as the whole advantage of a biger missile woudl be more room to put stuff. Sol there needs to be stuff to make them better. I am more in favor of an Advanced FCS Module though, which is tied to sensors on the missile itself. Two such FCS Modules in fact, one for Active and one for Passive, with each FCS conferring a bonus based on it's type.

 - The Active FCS would confer an accuracy bonus that would work identically to Missile Tracking Speed Bonus, the longer the missile is tracking the target the better the bonus. The Passive FCS would provide the same kind of bonus as the Active FCS, but would scale based on enemy EM/TH output versus the missile's ability to detect said output. So a really hot target would confer a much higher bonus regardless of the passive sensor strength of the missile, while a really good passive sensor suite on the missile would confer a high bonus despite the target being relatively "cold".

 - When you combine those ideas with Cloak / Thermal Reduction and add back in armor, suddenly all kinds of new options exist for all the different missile sizes. Want slow, but accurate torpedoes for Commerce Raiding? Use a combination of Passive TH Sensors with Passive FCS and add Armor. Want a speedy shield buster? Big engines, Passive FCS and Passive EM Sensors. Want an ASM to cut through enemy PD? Size 8 with 75% Cloak to appears as a Size 6 and 1 layer of Armor to help deal with Meson / Gauss / Railguns. Want a super accurate mega missile of DOOM? Just cram a crap ton of Active Sensors, Passive Sensors and FCS, add ECM/ECCM, armor and so on and so forth.

 - Under that model, missiles get deadlier as they get bigger, but they also get more expensive. Medium sized missiles become more useful, while Cloaked Missiles get more powerful as Cloaking Tech increases. At 50% Cloak, a Size 12 is as hard to see as a Size 6, but would cost more. A slow torpedo would benefit from the Thermal Reduction and the Passive FCS, while everything that is big enough to mount a credible Active Sensor would benefit greatly from an Active FCS. Armor would make big missiles even more viable, as by adding HtK suddenly Railguns and Gauss become less powerful against small salvos, while AMMs will need to be more powerful to compensate.

 - Incidentally, Mesons should ignore missile armor's % chance to block incoming damage, and just deal HtK against any missiles they hit. Conversely, AMMs should suffer a flat reduction proportional to the number of layers, and then deal the rest to HtK. So the % chance to ignore damage only involves Non-Meson Beam PD and CIWS. As an aside, Missile Stages should have an option to "Deploy Sub munitions on..." and then two check boxes that read, "Launch" and "Sensor Contact" respectively. This would allow the player to designate something as a mine or a bus w/o the fiddly bits, while a lack of designation in this regard would allow booster stages, armored shells to carry them past Fighter PD, or to create buses for Orbital Bombs

I think you touched on a few great points here.

One problem with missiles is that speed is the primary defence mechanisms for missiles. ECM is not really effective unless you have level 3 or more. As adding ECM before that slows down the missile too much and also make the missile way more expensive.

In order to make larger missile more viable there need to be some space in smaller missiles that needs to be filled so they need to sacrifice both speed and range to keep the same yield or reduce the yield to keep the speed and/or range.

I still believe that agility is a problem because it will make AMM missiles over time way too powerful while benefiting offensive missiles very little in return. A missile that use low speed with good agility and ECM should for the most part be more effective than just a pure fast missile... at least over medium to long range. But currently you will need pretty high ECM... at level 3 it often is a toss up and at level 4 then ECMs start to be very powerful, both for offence and defence.

In my multi-faction games I just give all factions an agility of 100 and never touch it again. It makes the missile balance relatively well... in my opinion that speaks for agility as implemented being a "problem".

It is just pure math in what is the best solution for whatever range you want to fire your missiles at. You always want as small missiles as possible to overpower the enemy point-defence. There is no point in using large powerful missiles if they never get to hit in the first place. If you need a size 6 missiles to fit both ECM and ECCM and a 12 point yield that missiles also need to be 50% more efficient than a size 4 missile that is faster with the same yield. That is most often a tall order unless ECM/ECCM levels are relatively high.

In my opinion ASM missiles at medium to long range should probably be designed in the game to be the most effective sizes of 6-10.

If you require a guidance system in every missile you will effectively make larger missiles more space effective even at smaller ranges too. This guidance system might be based of your EM technology as it is mainly a passive system that receive data not transmitting data. If the module are say 0.1 MSP for 1mkm, 0.2 MSP for 10mkm and 0.4 for 100mkm then distance is modified by your EM tech. Just as an example. When you create the missile this "module" is automatically added and adjusted as the missile maximum range is changed. You could easily then adjust the size by modifying the fuel to get the missile at the right size.

So now... if you want a missile to fire 50 million km it also will need a guidance system at 0.333 MSP, this will inflate missile size by roughly one point and it also will make the minimum 0.25 for other electronic modules smaller in comparison as increasing the missile further in size to fit them will not impact its performance as much anymore.

I have no direct ideas how to "fix" agility as a mechanic other than reducing the overall range of the agility score. It should start higher but also end much lower during progression... so perhaps start at 80 and end at 120 or so. Increase in agility will have a very huge impact on AMM missiles and not so much on ASM in general.

Perhaps adding some more electronic warfare that is not directly related to missiles could also be something interesting in the future.

If we start to fill missiles with more stuff and make them more expensive we might also need to increase the yield tech level one up the ladder as there will be less space for the same throw weight so missiles still have the same rough power as before.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on July 15, 2020, 06:28:42 PM
Regarding agility...realistically, a missile's chance to BE HIT should scale with agility. The "issue" with agility is that it makes AMMs more efficient as technology improves (this is not necessarily a bad thing), since attack missiles can only make themselves safer by increasing speed while AMMs can make themselves more lethal via speed, agility (and smaller warheads, to a lesser extent). Making agility help attack missiles avoid AMMs would negate that mismatch.

On the topic of modifying how to-hit chances work, should smaller ships (and missiles, presumably) inherently be harder to hit? Again from a realism perspective, they would be...though if we want to bring realism into Aurora's accuracy mechanics the changes will be...drastic.
Title: Re: C# Suggestions
Post by: Droll on July 15, 2020, 07:10:16 PM
Regarding agility...realistically, a missile's chance to BE HIT should scale with agility. The "issue" with agility is that it makes AMMs more efficient as technology improves (this is not necessarily a bad thing), since attack missiles can only make themselves safer by increasing speed while AMMs can make themselves more lethal via speed, agility (and smaller warheads, to a lesser extent). Making agility help attack missiles avoid AMMs would negate that mismatch.

On the topic of modifying how to-hit chances work, should smaller ships (and missiles, presumably) inherently be harder to hit? Again from a realism perspective, they would be...though if we want to bring realism into Aurora's accuracy mechanics the changes will be...drastic.

Agility based evasion is a bit weird from a missile on missile evasion perspective because it assumes that missiles somehow have the ability to decide to engage in evasive maneuvers. Understand that because of the small detection range of AMMs combined with the relatively large attack range of attack missiles means that missiles will somehow need to evade missile which they don't even know they exist. So such detection would require an onboard missile sensor, passive or active which in turn takes up a large part of the missiles real estate, kind of defeating the point of the exercise.

Mind you this is a realism argument, not a gameplay one. I think from that perspective the missile needs to know that the AMM exists for it to even be able to attempt evasive maneuvers.
Title: Re: C# Suggestions
Post by: QuakeIV on July 15, 2020, 09:47:03 PM
Since people were mentioning 'communication module' and such to inflate missile sizes, maybe its worth mentioning the idea of guidance sections.  It would probably be reasonable to say that for a given engagement range (and perhaps agility also?) a certain size of guidance section is required.  This would then cause smaller missiles to be lower performance from a range/agility perspective due to the added cost of the guidance section.

Consider this cross section of the hellfire to see how much room the guidance stuff takes up in current times (cone shaped bit is the actual warhead, everything in front is guidance).
(https://i.imgur.com/uAUUIBb.png)
Title: Re: C# Suggestions
Post by: xenoscepter on July 15, 2020, 10:20:37 PM
Point of contention... IIRC the Hellfire can be used for multiple forms of attack, no? Top down or side on IIRC. That would need substantially more guidance than a typical missile. And what of the Maverick? It was TV Guided, and thus would need far less.

I don't think requiring guidance should be a thing simply on account of ships in Aurora already possessing M-FCS in proportion to the range and size of target. A rudimentary sensor and/or telemetry would probably be sufficient for a bare bones guidance under the model of Speed and Agility determining the accuracy. You can flash a lot of information to a relatively small storage device, and so long as the missile knows were it is, where it's been and how to use the information provided to it to get where you want it to be, that's enough.

I think there should be additional guidance systems, namely missile mounted FCS to take advantage of missile mounted sensors. I don't like forcing restrictions on the player, doubly so for restrictions which make no sense IRL and more so when all it does is penalize something. Don't nerf the strong, buff the weak... if the buffs don't balance it out then use nerfs. If that doesn't work... ya don goofed and need to pull the system apart and overhaul it.

Or ya would if balance was an issue. Buff the big missiles, as it stands there isn't much of anything they can do that small / medium sized ones can't do better, cheaper or both.
Title: Re: C# Suggestions
Post by: QuakeIV on July 15, 2020, 10:46:39 PM
Hellfire is about as simple as it gets.

Maverick is actually relatively similar (both TV/infrared have pretty similar sections):
(https://thaimilitaryandasianregion.files.wordpress.com/2016/08/911176agm_65_1.jpg)

Sadly couldn't find nearly as nice of a cross section image.
Title: Re: C# Suggestions
Post by: xenoscepter on July 16, 2020, 01:17:25 AM
Huh, that's pretty interesting. Wonder what those sections actually weigh though...
Title: Re: C# Suggestions
Post by: Rince Wind on July 16, 2020, 02:56:41 AM


Agility based evasion is a bit weird from a missile on missile evasion perspective because it assumes that missiles somehow have the ability to decide to engage in evasive maneuvers. Understand that because of the small detection range of AMMs combined with the relatively large attack range of attack missiles means that missiles will somehow need to evade missile which they don't even know they exist. So such detection would require an onboard missile sensor, passive or active which in turn takes up a large part of the missiles real estate, kind of defeating the point of the exercise.

Mind you this is a realism argument, not a gameplay one. I think from that perspective the missile needs to know that the AMM exists for it to even be able to attempt evasive maneuvers.

You could just say that the missiles flies erraticly to avoid being an easy target. And higher agility allows for better maneuvers/a better threat detection system while still staying on target.
Title: Re: C# Suggestions
Post by: Black on July 16, 2020, 03:32:51 AM
Would it be possible to get option to have Populated Systems in Economics window sorted by Sectors they are part of? They are currently sorted by population and I would like to be able to group them by the Sector.
Title: Re: C# Suggestions
Post by: TMaekler on July 16, 2020, 07:33:03 AM
Population Growth Modificator: I was thinking about creating a multi faction start on earth with one dummy "United Nations" which holds just most of the population of earth and then some playable nations holding the rest. It would be nice to be able to lower the pop growth value of this dummy nation.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on July 16, 2020, 10:12:22 AM


Agility based evasion is a bit weird from a missile on missile evasion perspective because it assumes that missiles somehow have the ability to decide to engage in evasive maneuvers. Understand that because of the small detection range of AMMs combined with the relatively large attack range of attack missiles means that missiles will somehow need to evade missile which they don't even know they exist. So such detection would require an onboard missile sensor, passive or active which in turn takes up a large part of the missiles real estate, kind of defeating the point of the exercise.

Mind you this is a realism argument, not a gameplay one. I think from that perspective the missile needs to know that the AMM exists for it to even be able to attempt evasive maneuvers.

You could just say that the missiles flies erraticly to avoid being an easy target. And higher agility allows for better maneuvers/a better threat detection system while still staying on target.

This is exactly what "real" missiles do. If you look at the literature on designing control schemes for anti-missile missiles, the key parameters are the off-axis dynamics of the interceptor and target.  In much of the literature, this is assumed to be a ground-launched interceptor and a nuclear reentry vehicle. The reentry vehicle will at some point (either randomly or at a carefully chosen moment depending on the reentry vehicle designer's knowledge of the interceptor's capabilities) perform a evasive maneuver (usually a max acceleration turn, but again the optimal solution depends on what you know about your opponent). The interceptor must then attempt to follow the maneuver; its ability to do so successfully depends on the ratio of off-axis accelerations achievable as well as time delays (primarily actuator lags, but can also include sensor issues).

Agility is thus an abstraction of missile tonnage devoted to off-axis thrusters, sophisticated computers necessary to solve the differential game in real time, and the g-hardening necessary to allow aggressive maneuvers without breaking the missile. And the thing to note is that the effects of this on the interception encounter are symmetric; making the reentry vehicle have a smaller time constant is simply the inverse of making the interceptor have a larger time constant. Thus, a decent model for how agility affects accuracy would be to take the ratio of interceptor and evader agility, rather than the current model of just using the interceptor's agility.

Agility should also affect beam weapon accuracy, but beam weapon accuracy would also need to account for target size for that to really make sense. Size doesn't matter so much for missile hitting things because the lethal radius is generally much larger than the target...it doesn't matter if the target is 2 meters or 3 meters when the missile is lethal if it blows up within 10 km of said target. But a beam weapon needs a direct hit to do anything at all, so a 2 meter cross section is meaningfully more difficult to hit than a 3m cross section would be.

Making smaller ships harder to hit might make beam fighters actually effective, as well as just generally giving a better reason to build small ships. There are economic advantages to smaller vessels, but in terms of performance per ton, bigger is better in Aurora (at least for beam combat; missile range scaling with resolution gives small to mid-size vessels a niche there).
Title: Re: C# Suggestions
Post by: skoormit on July 16, 2020, 02:59:18 PM
Population Growth Modificator: I was thinking about creating a multi faction start on earth with one dummy "United Nations" which holds just most of the population of earth and then some playable nations holding the rest. It would be nice to be able to lower the pop growth value of this dummy nation.

Pop growth rate is already a setting for custom races.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 16, 2020, 05:18:04 PM
Point of contention... IIRC the Hellfire can be used for multiple forms of attack, no? Top down or side on IIRC. That would need substantially more guidance than a typical missile. And what of the Maverick? It was TV Guided, and thus would need far less.

I don't think requiring guidance should be a thing simply on account of ships in Aurora already possessing M-FCS in proportion to the range and size of target. A rudimentary sensor and/or telemetry would probably be sufficient for a bare bones guidance under the model of Speed and Agility determining the accuracy. You can flash a lot of information to a relatively small storage device, and so long as the missile knows were it is, where it's been and how to use the information provided to it to get where you want it to be, that's enough.

I think there should be additional guidance systems, namely missile mounted FCS to take advantage of missile mounted sensors. I don't like forcing restrictions on the player, doubly so for restrictions which make no sense IRL and more so when all it does is penalize something. Don't nerf the strong, buff the weak... if the buffs don't balance it out then use nerfs. If that doesn't work... ya don goofed and need to pull the system apart and overhaul it.

Or ya would if balance was an issue. Buff the big missiles, as it stands there isn't much of anything they can do that small / medium sized ones can't do better, cheaper or both.

Adding a communications section that scales with range is not "nerfing" small missiles... it is adding a small mechanical part that makes actual sense in my opinion. Missiles need a communication device to receive the information sent by the fire-control. You could make it a flat size as well if you consider the fire-control to make up the part of range. But I think a scaling size would mechanically be better for balance otherwise AMM missiles might get hammered too much. But you could simply make it a 0.25MSP module, but it would then inflate the size of AMM missiles... perhaps not a bad idea though.

As I also mentioned increasing the strength of the warhead technology one step up would perhaps also be needed to keep the missiles at roughly the same power level.

but adding this would make it much harder to swarm point defences with huge numbers of really small missiles... at least if you want them to actually deal any significant damage.
Title: Re: C# Suggestions
Post by: QuakeIV on July 16, 2020, 05:28:58 PM
Most missiles do not communicate, they look at something that is painting the target, or they detect the target completely by their own means.  Hence a guidance section usually on the front of the missile.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on July 16, 2020, 06:26:50 PM
Most missiles do not communicate, they look at something that is painting the target, or they detect the target completely by their own means.  Hence a guidance section usually on the front of the missile.

Depends on the purpose of the missile. Short ranged anti-air missiles or ground attack missiles? Sure.

Cruise missiles? Nope. Modern tomahawks have two-way communications for inflight retargeting.

Ditto for the latest versions of the Harpoon (US anti-surface missile).

And the Standard missile series seems to have been designed from the outset for receiving guidance from the launcher (as far as I'm aware, that's the ENTIRE POINT of the so-called "Aegis" system.

There is an entire wikipedia page about "Command Guidance," which is the practice of using a remote platform to provide steering to missiles.
Title: Re: C# Suggestions
Post by: QuakeIV on July 16, 2020, 10:44:59 PM
While true, that mainly has to do with the possibility of directing missiles against alternate targets, rather than enhancing their terminal guidance.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 17, 2020, 03:59:59 AM
While true, that mainly has to do with the possibility of directing missiles against alternate targets, rather than enhancing their terminal guidance.

A target that changes course in Aurora are pretty much the same as guiding the missile on to a new target given the speed of ships versus missiles. Missiles in Aurora often don't even have its own thermal, EM or active targeting systems either so they are effectively blind.
Title: Re: C# Suggestions
Post by: esavier on July 17, 2020, 06:07:05 AM
Can we get medal conditions based on ammount of researched projects?
I would love to give those for my best and most dedicated researchers. . .
Title: Re: C# Suggestions
Post by: Froggiest1982 on July 17, 2020, 06:28:29 AM
Can we get medal conditions based on ammount of researched projects?
I would love to give those for my best and most dedicated researchers. . .

I am quite sure there are already for 1 and 5 respectively condition number 26 and 27. You can find the list under mechanics and changelist 1.10
Title: Re: C# Suggestions
Post by: esavier on July 17, 2020, 07:46:34 AM
Quote from: froggiest1982 link=topic=10640. msg138890#msg138890 date=1594985309
Quote from: esavier link=topic=10640. msg138889#msg138889 date=1594984025
Can we get medal conditions based on ammount of researched projects?
I would love to give those for my best and most dedicated researchers.  .  .

I am quite sure there are already for 1 and 5 respectively condition number 26 and 27.  You can find the list under mechanics and changelist 1. 10

sorry, just recently changed from 1. 9. 5, thank you!
Title: Re: C# Suggestions
Post by: Marski on July 17, 2020, 11:11:28 AM
"Renumber ground formation and/or subordinate formations" button
Title: Re: C# Suggestions
Post by: Stryker on July 17, 2020, 07:21:04 PM
Conditional orders

Condition when deployment time equals x%.

Orders
Refuel and Resupply (This is in the movement orders but not the conditional).
Refuel, Resupply and Overhaul.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 17, 2020, 07:47:09 PM
Conditional orders

Condition when deployment time equals x%.

Orders
Refuel and Resupply (This is in the movement orders but not the conditional).
Refuel, Resupply and Overhaul.

This is already pretty much confirmed to be implemented in 1.12.

Conditional order will be when deployment is exceeded and the new conditional order is Refuel, Resupply and Overhaul.
Title: Re: C# Suggestions
Post by: QuakeIV on July 18, 2020, 01:52:46 AM
It would be really nice if banning a system from 'auto routing' meant that orders like 'refuel from hub(all)' and 'salvage nearest wreck' didnt cause ships to fly into that banned system, particularly when that system is gate camped and is massacring all of my survey ships.
Title: Re: C# Suggestions
Post by: xenoscepter on July 18, 2020, 01:59:09 AM
Quote
It would be really nice if banning a system from 'auto routing' meant that orders like 'refuel from hub(all)' and 'salvage nearest wreck' didnt cause ships to fly into that banned system, particularly when that system is gate camped and is massacring all of my survey ships.

Damn the torpedoes! Full speed ahead!
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 18, 2020, 06:31:35 AM
It would be really nice if banning a system from 'auto routing' meant that orders like 'refuel from hub(all)' and 'salvage nearest wreck' didnt cause ships to fly into that banned system, particularly when that system is gate camped and is massacring all of my survey ships.

They should not venture in there if you also set the system as Alien Controlled... but I'm not 100% sure.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on July 18, 2020, 09:52:55 AM
If you have set the "no alien controlled" tick box on a fleet, the conditional orders will avoid systems set as alien controlled.

I use this to block my survey fleets from taking long routes back to refuel (since the autoroute doesn't find the shortest path).
Title: Re: C# Suggestions
Post by: QuakeIV on July 18, 2020, 12:18:25 PM
Well thats useful.  It was in fact set as alien controlled.  I'll use that at least...
Title: Re: C# Suggestions
Post by: xenoscepter on July 18, 2020, 10:22:18 PM
Bumping the change to Jump Squadron Mechanics.

Link to my full topic in the Suggestions Board:
http://aurora2.pentarch.org/index.php?topic=11754.0
Title: Re: C# Suggestions
Post by: Black on July 19, 2020, 11:12:25 AM
Would it be possible to get an option to restore original name of the system for real stars game? I captured some aliens and they gave me info on system but it has non real star name, so I have no idea what system it is.
Title: Re: C# Suggestions
Post by: Cobaia on July 20, 2020, 06:22:57 AM
In Ground Unit training it would be nice to have a create x times button.

My Ground Unit formations start at Squad level so a Platoon has 3 squads a Company has 5 Platoons a Battalion has 5 Companies so this adds up to several clicks when creating units.
Title: Re: C# Suggestions
Post by: mike2R on July 21, 2020, 08:48:42 AM
I've been using automated fuel harvester ships this game, with the conditional order: fuel tank full -> harvester transfer and return.  This works well, but there are a couple of niggles.

You get warning events when the fuel tank is above 90%.  Which basically means you need to hide that event because it just spams repeatedly.  I normally use these events to manage fuel harvester stations - sending a tanker out to the FHS fleet whenever its needed.  So I can only use one type of fuel harvester or the other. 

Suggestion: Suppress the fuel over 90% event for fleets that have a conditional order with a fuel tanks full trigger.

The harvester fleets still generate Order Complete events when arriving back at their gas giants, which is a mild irritant when I've got many FH fleets - I pay attention to Order Complete events for managing my fleets generally, so seeing ones that don't require me to take action is a distraction.

Suggestion: Suppress order complete events for a ship which has a conditional order set with trigger: fuel tank full, and action: harvester transfer and return, that has arrived at a gas giant with sorium.  Maybe get really fancy and if a ship with that conditional order finishes its orders anywhere that is not a gas giant with sorium, generate a "Cannot Mine Here" event, which would be handy for spotting when sorium is depleted.

Bonus Suggestion: I think harvester transfer and return is an 'S' order, so can only find a colony within that system to transfer its fuel to.  Personally I'd like it to be an 'A' order, so I could mine in systems I don't have a suitable colony in - be handy for keeping fuel on hand at a colony in a system without gas giants.
Title: Re: C# Suggestions
Post by: Kirkegaard on July 21, 2020, 10:34:06 AM
Currently all drop down menues requires that the user either pick the desired options or write an exact text match to chose an option.

I suggest adding the option to match on partial text strings, so in "environment" a "O" will default to Oxygen, since it is the only one starting with an O and "C" will default to "Carbon Dioxide" since it is the first with a "C" and so forth.
Title: Re: C# Suggestions
Post by: Kirkegaard on July 21, 2020, 10:47:02 AM
In "Research" in Economics no scientist are chosen as default, so you always have to chose one yourself.

I suggest that the first (often best) scientist is always chosen as default, so you don't get "Please select a scientist to lead the project" unless you actively remove the chosen scientist and do not chose a replacement.
If you chose "Matching Scientist Only" the new first one are chosen (if there are any).

This will also make it easier to use the arrows to navigate.
Title: Re: C# Suggestions
Post by: Kirkegaard on July 21, 2020, 10:56:09 AM
In Economics there are a number of sub-menus: Industry, Mining etc. I suggest the rather drastic step of either removing or "greying out" the options with no relevant actions. So if there are no Shipyards on a planet or an asteroid you can not chose Shipyard or Shipyard task on that body.

I think this could be applied to Shipyard, Shipyard Tasks, Research, GU training, Stockpiles and Ancient Constructs.

Title: Re: C# Suggestions
Post by: Kirkegaard on July 21, 2020, 11:02:19 AM
In naval organization - standing orders I suggest to either remove or "grey out" all options that the fleet cannot do.

So a basic fleet with one survey ship can't chose a order like "Load colonist"or "Build jumpgate" that it cannot perform.
Title: Re: C# Suggestions
Post by: QuakeIV on July 21, 2020, 10:05:56 PM
I request a continual slipway expansion option (like unto the continual capacity expansion order that currently exists) for shipyards, for purposes of expanding FAC production yards.
Title: Re: C# Suggestions
Post by: Silverkeeper on July 23, 2020, 02:24:36 AM
Political stability falling should have consequences. Say for example riots, rival factions and maybe eventually independence.
In my current game I can just ignore it on luna because I have no installations there yet.

Static energy weapons should give PPV like they do when mounted on ships.
Title: Re: C# Suggestions
Post by: Black on July 23, 2020, 03:19:28 AM
It would be nice if STO weapons had same PPV value s if the weapon would be placed on ship or space station.

I think it was planed feature for colony to gain independence if stability gets too low. I suppose it was not implemented at the end.
Title: Re: C# Suggestions
Post by: TMaekler on July 23, 2020, 03:52:04 AM
Like with factors for research, exploration etc. it would be nice to also add a general factor to population reproduction. It feels somehow too quick a growth if one slows down everything else for a longer playtime, and then being overwhelmed by unemployed people do to too quick growth... .
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 23, 2020, 04:45:55 AM
I have played around with automation of my empire and one thing I think would help allot with automation would be if we could use Order Templates for "Conditional Orders". If we could use that only our imagination would put limits on automation.

One thing that I definitely would like would be a "Send Message" conditional order. Let's say I have a refuelling station it can be difficult to know when it starts to run out of fuel, so I want it to send a message when it is at say 30% fuel or something telling me who is at low fuel so I can send a tanker there.

This would simplify some things as you don't have to continually look up these places in certain intervals.

I also think that we need orders for stay until cargo or tankers full order for all installation and fuel as well as minerals. I want my freighters to wait until they can fill all their cargo holds with auto-mines from the colony producing them. Or a tanker want to sit at the harvester until it can fill up their tanks entirely etc...
Title: Re: C# Suggestions
Post by: mike2R on July 23, 2020, 05:08:28 AM
It feels somehow too quick a growth if one slows down everything else for a longer playtime, and then being overwhelmed by unemployed people do to too quick growth... .

I had that my first few slow research games, but I've come to the conclusion it just meant I was underbuilding construction factories.  More factories mean more research labs, and enough research labs will soak up any amount of pop.  In my current game Earth is over 5 billion and I'm still constantly hurting for workers.

That said, adjustable pop growth would be cool.
Title: Re: C# Suggestions
Post by: TMaekler on July 23, 2020, 05:27:05 AM
An addition to civilian contracts: I tend to build small fleets of mineral harvesters that roam around to collect TN Minerals from the small planetoids etc. where a mining facility would be a waste of resources. So I was thinking: why not opening that up to the civilians? It should be possible to write out contracts for civilian mineral harvesting. Once a company accepts that they will mine that planet to the last gram of mineral and transport them to the planet where you ordered that contract from.
Title: Re: C# Suggestions
Post by: Kamilo on July 23, 2020, 08:16:50 AM
An addition to civilian contracts: I tend to build small fleets of mineral harvesters that roam around to collect TN Minerals from the small planetoids etc. where a mining facility would be a waste of resources. So I was thinking: why not opening that up to the civilians? It should be possible to write out contracts for civilian mineral harvesting. Once a company accepts that they will mine that planet to the last gram of mineral and transport them to the planet where you ordered that contract from.

That way you could reduce the massive amounts of corundium you need to operate such mining operations. To balance that out the civilian mining operation should be quite expensive. Then again you could use the saved ressources to build financial centers. Automines would lose their "need".

Title: Re: C# Suggestions
Post by: Droll on July 23, 2020, 11:25:19 AM
Automines would lose their "need".

Well not really, civilian orbital mining would be constrained by the orbital mining size tech so larger bodies would still need it.

I guess you could extend the civilian mining operation feature and allow the player to fund civilian mines with immense wealth.
Title: Re: C# Suggestions
Post by: TMaekler on July 24, 2020, 01:48:07 AM
Well not really, civilian orbital mining would be constrained by the orbital mining size tech so larger bodies would still need it.

I guess you could extend the civilian mining operation feature and allow the player to fund civilian mines with immense wealth.
I would definitely want to manage my bigger sources on my own. I mean, those civilians do cost a LOT... lol... ;-)
Title: Re: C# Suggestions
Post by: Kamilo on July 24, 2020, 02:05:31 AM
I got two suggestions regarding ground forces:

The ability to have reserves. You can build x amount of an element and they get "stored". You can use them to create a formation. It would be more or less like construction ship components and then use them to build the ships faster. That way you could be more flexible about formations and could train them faster.

The second suggestion is to be able to "repair and/or refit" formations. Losses could be filled with new elements to its previous hp. Refitting could be used to adapt to suit changing situations quickly. You could refit an already built formation to a different type of formation. For example switching from desert warfare to mountain warfare.

What do you think about these changes?
Title: Re: C# Suggestions
Post by: esavier on July 25, 2020, 06:39:25 AM
It would be awesome to be able to share transported survivors between ships on the fleet, possibly also allowing all ships to average their transported crew vs their capacity, for example spreading survivors between ships to 20%(or whatever necessary) of ship capacity, including overcrowding
examples:
1:
survivors = 250
fleet = 2 ships A that can take 100 additional personnel and 1 ship B that can take 300, ships will share space in following fashion:
each of two ships A will take 50 (50% capacity)
1 ship B will take 150 (50% capacity)

2:
survivors = 750
fleet = 2 ships A that can take 100 additional personnel and 1 ship B that can take 300, ships will share space in following fashion:
each of 2 ships A will take 150 (150% capacity)
1 ship B will take 450 (150% capacity)
Title: Re: C# Suggestions
Post by: xenoscepter on July 25, 2020, 07:21:39 AM
That's already been implemented via Rescue Shuttles. Also, the deliberate allocation of superfluous Spare Berths has been removed from C#, a feature I would sorely like back...

Thus, Ship A and Ship B will seldom if ever have enough spare room to store survivors. Instead, Cryo Berths are used for that purpose. Which kinda sucks... since it would be nice if we could integrated rescued crew, or daresay even commanders, into ships that had suffered casualties.

Also, being able to build out some extra Crew Quarters to stave off Life Support failure on account of battle damaged Crew Quarters would be nice. :)
Title: Re: C# Suggestions
Post by: esavier on July 25, 2020, 06:32:50 PM
That's already been implemented via Rescue Shuttles. Also, the deliberate allocation of superfluous Spare Berths has been removed from C#, a feature I would sorely like back...

Thus, Ship A and Ship B will seldom if ever have enough spare room to store survivors. Instead, Cryo Berths are used for that purpose. Which kinda sucks... since it would be nice if we could integrated rescued crew, or daresay even commanders, into ships that had suffered casualties.

Also, being able to build out some extra Crew Quarters to stave off Life Support failure on account of battle damaged Crew Quarters would be nice. :)

I may have wrote what i meant incorrectly,
This is small ship that is ment to help both in boarding and rescue situations:
Code: [Select]
Byzantium class Pinnace      6'935 tons       79 Crew       1'027.6 BP       TCS 139    TH 330    EM 0
4758 km/s      Armour 6-32       Shields 0-0       HTK 33      Sensors 32/32/0/0      DCR 4      PPV 0
Maint Life 17.54 Years     MSP 8'370    AFR 96%    IFR 1.3%    1YR 51    5YR 771    Max Repair 136.125 MSP
Troop Capacity 1'000 tons     Boarding Capable    Cryogenic Berths 1'000    Cargo Shuttle Multiplier 5   
Lieutenant Commander    Control Rating 1   BRG   
Intended Deployment Time: 96 months    Morale Check Required   

MD SCAM S0750 E0330 x055-025 TR50  (2)    Power 660    Fuel Use 4.58%    Signature 165.0    Explosion 5%
Fuel Capacity 150'000 Litres    Range 85 billion km (206 days at full power)

ASS-60-32 E4 R0050 S0050  = 0024M (1)     GPS 60     Range 24.7m km    MCR 2.2m km    Resolution 1
ASS-60-32 E4 R5000 S0050  = 0114M (1)     GPS 6000     Range 114.7m km    Resolution 100
TH-32 E5 S0050 [4/14/44] (1)     Sensitivity 32     Detect Sig Strength 1000:  44.7m km
EM-32 E5 S0050 [4/14/44] (1)     Sensitivity 32     Detect Sig Strength 1000:  44.7m km

This design is classed as a Military Vessel for maintenance purposes
now having 8 ships of that class in my temporary hospital fleet, i rescued around ~4000 survivors, but those are split between first two ships in the fleet. having them overcrowded while there is still spare space on another ships.

Still, sharing and refilling crew would be also a nice one to have.
Title: Re: C# Suggestions
Post by: Barkhorn on July 25, 2020, 09:55:08 PM
Maybe there's already a way to do this and I'm just missing it, but I would love a way to create a research project straight from a prototype.
Title: Re: C# Suggestions
Post by: xenoscepter on July 25, 2020, 10:00:39 PM
The fix for rescue shuttles has been implemented in v1.12.0, the fix is not live yet.
Title: Re: C# Suggestions
Post by: Froggiest1982 on July 26, 2020, 02:50:49 AM
Maybe there's already a way to do this and I'm just missing it, but I would love a way to create a research project straight from a prototype.

Click on the prototype component under the design window, on the bottom right a new button called reasearch proto should appear. Once clicked just go under the research tab and research the component. It will be there then.
Title: Re: C# Suggestions
Post by: esavier on July 26, 2020, 09:36:20 PM
* Delivering survivors to a race's controlled planet should yield diplomatic points,
* Ships containing diplomacy module should be exemp from penalties of being in restricted system, (diplomacy module should be able to stay in restricted sysyem)
Title: Re: C# Suggestions
Post by: esavier on July 26, 2020, 11:38:16 PM
multiple tugs should contribute to  hauling speed
( right now tug fleets are counterproductive )
Title: Re: C# Suggestions
Post by: esavier on July 26, 2020, 11:41:22 PM
* there should be reverse filter in event window, working similary to "grep", i.e. you want messages only on specific topics (right now we can specify only one topic to listen to)
* there should be possibility to allow player to check what event to pause on
Title: Re: C# Suggestions
Post by: Froggiest1982 on July 26, 2020, 11:59:53 PM
* there should be possibility to allow player to check what event to pause on

There is already an approved mod for this
Title: Re: C# Suggestions
Post by: Andrew on July 27, 2020, 05:29:46 AM
Auto-delete Empty fleets.
A button to remove all empty fleets in the same way all empty colonies can be removed. Because when 80 fighters have been killed by close range beam and missile fire as they are damaged and drop out of formation they spawn a fleet each and then when they die that empty fleet remains and they clutter the fleet list a lot and need individual deleting
Title: Re: C# Suggestions
Post by: mike2R on July 27, 2020, 07:35:05 AM
* Ships containing diplomacy module should be exemp from penalties of being in restricted system, (diplomacy module should be able to stay in restricted sysyem)

I believe there is a mechanic for allowing a diplo ship in a restricted system - from here http://aurora2.pentarch.org/index.php?topic=8495.msg118318#msg118318 (http://aurora2.pentarch.org/index.php?topic=8495.msg118318#msg118318)

Quote
NPRs deduct 10,000 tons from the tonnage of one Diplomatic Ship (see Part 8) per system for threat purposes if that class type has never fired weapons and the Diplomatic Ship is in a non-Core system. If the NPR only has one system, it is not treated as core for this purpose.
Title: Re: C# Suggestions
Post by: Black on July 27, 2020, 02:22:27 PM
Something came to me as I was starting new game. We are near the default starting year of Aurora with no TN minerals in sight. Maybe Steve should set new default starting year, that is farther in the future.  ;D
Title: Re: C# Suggestions
Post by: Barkhorn on July 30, 2020, 10:45:52 PM
I'm loving the new prototypes feature, but I think it could be even better.  I'd like to be able to create research projects for parts I don't have the tech for.  Currently, if you make a prototype using tech you don't have, like a twin gauss turret when you haven't researched the gun yet or an engine with fuel use 0.5 when you're only at 0.6, the part has (FP) next to it in the class design window, and the button to make a research project from it is hidden.  Even when you finish the necessary techs, that button never reappears.
Title: Re: C# Suggestions
Post by: Froggiest1982 on July 30, 2020, 11:37:45 PM
I'm loving the new prototypes feature, but I think it could be even better.  I'd like to be able to create research projects for parts I don't have the tech for.  Currently, if you make a prototype using tech you don't have, like a twin gauss turret when you haven't researched the gun yet or an engine with fuel use 0.5 when you're only at 0.6, the part has (FP) next to it in the class design window, and the button to make a research project from it is hidden.  Even when you finish the necessary techs, that button never reappears.

I am not sure you can prototype it, but there is a flag to see the next available tech though...
Title: Re: C# Suggestions
Post by: Barkhorn on July 30, 2020, 11:44:27 PM
You CAN prototype it, I just did it.  I'm saying you can't create a research project from it even once you have the requisite techs.  The button never appears, so you have to design that part again.  Maybe it's incomplete or not working as intended.
Title: Re: C# Suggestions
Post by: xenoscepter on July 31, 2020, 04:08:33 AM
Are you certain you have the pre-requisitie techs?

I've ran into this with Active Sensors, when you tick off "Use Future Tech" it uses the best tech and automagically assigns it. So what was supposed to be an Active 10 / EM 5 future prototype became an Active 10 / EM 6 Future prototype.
Title: Re: C# Suggestions
Post by: Froggiest1982 on July 31, 2020, 08:22:07 PM
Add separation range on 2 stage missiles in the Missiles slide under Tech Overview window.
Title: Re: C# Suggestions
Post by: Breadabix on August 01, 2020, 06:37:38 PM
So I noticed a few requests for a galactic map zoom function and I completely agree it is needed after discovering a lot of systems. Does anyone know if this is going to be added? Cheers
Title: Re: C# Suggestions
Post by: Barkhorn on August 02, 2020, 12:11:59 AM
Suggestion: Let us issue conditional orders to tugs based on the thing they're tugging.  So for example, I could automatically have a tug pull my mining platform along when the asteroid it's on runs out of minerals.

Follow-up: Let us issue custom conditional orders.  We already have order templates, let us hook them up to conditions.
Title: Re: C# Suggestions
Post by: Froggiest1982 on August 02, 2020, 03:27:30 AM
Follow-up: Let us issue custom conditional orders.  We already have order templates, let us hook them up to conditions.
I am not entirely sure as now conditional orders have been made for the players and on player request as well, however the main function of the conditional orders were to make AI fleets to work including civilians. I am not sure a custom set of conditional orders would be either possible or anywhere simple to code.
Title: Re: C# Suggestions
Post by: QuakeIV on August 02, 2020, 08:16:35 PM
It would be nice if conditional orders were improved on to make them a little more like a programming language or somesuch, but I wouldn't personally go beyond expressing support for that kind of idea.  Seems nice, who knows if it will ever happen.
Title: Re: C# Suggestions
Post by: Kirkegaard on August 03, 2020, 04:57:30 AM
How performance taxing would it be to update all open windows after each turn?

I feel like I'm spending quite a lot of clicks refreshing or closing and opening the same windows all the time.
Title: Re: C# Suggestions
Post by: Elvin on August 03, 2020, 06:14:13 AM
How performance taxing would it be to update all open windows after each turn?

I feel like I'm spending quite a lot of clicks refreshing or closing and opening the same windows all the time.

It depends at what stage of the game you are at. A handful of windows do do at least partial refreshes on each new turn. If you keep the main Economy window open at game start, and leave on auto-turns, you can easily see the speedup gained by simply closing the window. It's up to a second or so per turn on my system. Screen re-drawing is fairly taxing to do. Of course, when turns start taking 30+ seconds a time, an extra second to redraw all the screens isn't going to be noticed.
Title: Re: C# Suggestions
Post by: Azuraal on August 03, 2020, 07:15:16 AM
Quote from: Kirkegaard link=topic=10640. msg139520#msg139520 date=1596448650
How performance taxing would it be to update all open windows after each turn?

I feel like I'm spending quite a lot of clicks refreshing or closing and opening the same windows all the time.
But at least for now, every window can be updated by reselecting your empire in the drop down menu which is probably slightly faster than closing and opening it.
Title: Re: C# Suggestions
Post by: Black on August 04, 2020, 01:23:07 PM
Would it be possible to get ability to visualy interrupt jump lines on galactic map? For example I discover new conection between two systems that are on other sides of galactic map, so the line goes through five other jump lines and several star system icons. So I would like to turn such jump line into a stub that would end by for example smaller circle or arrow and text would be something like: To Alpha Centauri and from Alpha Centauri there would lead another stub that would have text that reads: To Sigma Draconis.

Something like on this Starfire map: http://www.baen.com/images/Imperative/map1_HR.jpg
Title: Re: C# Suggestions
Post by: Barkhorn on August 04, 2020, 03:21:51 PM
Suggestion: Add the next techs to the list after creating a research project, so we can queue them all up.  Like for example, if I create a project for Missile Launcher Reload 4, add Missile Launcher Reload 5 to the list so I can add it to the MK scientist's queue.

Related suggestion: Only interrupt auto-increment when a tech finishes if that scientist has no more techs queued up.
Title: Re: C# Suggestions
Post by: Dreadder on August 05, 2020, 09:06:00 AM
It would be nice if we could add and replenish crews in space - using either shuttle modules or a special crew shuttle.

Replenishing crew casualties on space stations guarding jump points would become MUCH easier, because currently the only way to do it, at least to my knowledge, is to tug them back to the colony. Another possible application would be to transfer crews between ships in fleet, for instance, when one ship is badly damaged and has to be left behind for repairs, while the main fleet could use few extra hands due to casualties but can otherwise press the attack/continue with their mission. Another possibility would be to rotate crews on long duration missions, though there's already a recreational module for space stations for that particular case.

Edit: Another use for crew shuttles could also be to transfer survivors from one ship to another - for instance when the first ship on site picks them up and then later transfers them to the dedicated rescue ship or colony ship when it arrives, in order to avoid overcrowding.
Title: Re: C# Suggestions
Post by: skoormit on August 05, 2020, 10:05:25 AM
I would like to be able to configure auto-turn interrupt conditions for individual fleets based on the fleet's sensor observations.

For example, right now I have a sensor fleet observing a jump point at which the enemy has camped a lot of ships.
If any of those ships move away from the jump point, I want to stop auto-turns and react.
This means I have to manually observe the tactical map and turn auto-turns off myself.
Which means I have to choose a shorter increment length than I otherwise would, since my own reaction will stop time at least one increment after the observation.

I would like to be able to configure my sensor fleet such that an auto-turn interrupt is triggered if it observes any enemy ships moving away from the jump point.

A robust feature would perhaps provide options to limit the interrupts by other parameters: a list of ship classes, observed speed, total tonnage, class characteristics, etc.

But for now, a simpler per-fleet option (interrupt auto turns if any enemy ships are observed in motion) would suffice.

Title: Re: C# Suggestions
Post by: Barkhorn on August 06, 2020, 01:56:47 PM
Here's an idea to make replenishing losses in ground unit formations simpler.  Add a new type of unit that can be consumed just like supplies.  This unit would be consumed in the field to replace losses, analogous to MSP being spent to repair damaged parts in ships.  This way we don't have to personally manage building tons of each kind of unit just so we can have spares to dole out after a battle.  I mean, if a ship gets hit and a beam fire control is blown up, we don't have to queue up a beam fire control production job to fix it.
Title: Re: C# Suggestions
Post by: Borealis4x on August 06, 2020, 06:28:07 PM
A template constructor for creating large formations out of smaller ones.

I model everything from the company level, so making even a single division-sized unit is a major hassle. It would be nice if I could just make a division template out of my company formations and have it pop out fully formed and ready to go.
Title: Re: C# Suggestions
Post by: idefelipe on August 07, 2020, 06:51:11 AM
Would be possible to edit the age of a character? Specially for the first wave that all have 20 years... or change the age of the characters in the beginning :)

Also, if possible, to include in the event text, the promotion score of new officers. That would be very helpful to notice when a great promise appears.
Title: Re: C# Suggestions
Post by: Erik L on August 07, 2020, 06:51:39 PM
I'd like to see a method to specify my own technologies known at the start, but have the game auto-generate ships and troops based on those techs.
Title: Re: C# Suggestions
Post by: QuakeIV on August 07, 2020, 08:18:26 PM
Might be kindof nice if you could melt down ground units into a 'reinforcements pool' and then that gets used to replnish depleted units back towards whatever template they were built around.

As a related thing, the ground units could have a configurable template (default to whatever template they were built from) which determines how they get reinforced.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on August 07, 2020, 08:30:14 PM
I think that it would be great if we could turn different sensors types on and off individually on ships. For example there is little to no reason to put large resolution actives on ships as they will reveal your position as soon as you turn them on. Lower resolution scanners on the other hand like 1-10 in resolution is more effective as the type of craft they tries to find usually struggle to have passive good enough to detect them before they are themselves detected by the active sensors so there can be a reason to use them and not large resolution scanners that will guarantee to reveal you long before you detect anything with that active sensor.

In addition to this I might also think it is time for an upgrade to how hangars work too... it simply is too easy to deploy just about anything with hangars and rely on them for just about anything. In my opinion hangars simply is too powerful and basically is more like a modular compartment than an actual hangar. It is too easy to use them as a compartment to hold modular vessels, sensor options, weapons and everything is perfectly interchangeable with any size, type and configurations. We have advances and rather intricate mechanics for fuel, supplies and ordnance but hangar operations and types are quite free, too dynamic and effective.

hangars should simply be a module where you add certain abilities such as max docking size, launch/recovery capability, ability to reload ordnance, maintenance of weapon versus say sensor system. It should be much cheaper and less space requirement to have say two bays that accommodate two 500t survey shuttles or four 300t recovery shuttles or servicing 20 300t missile fighter-bombers that need a whole different types of maintenance, space for quick reloading of ordnance and fuel as well as rapid launch and recovery facilities. There could be a difference between serviceable and storage capacity and the ability to operate offensive fighters. A ship might even have several separate hangar facilities that can do different things.


I don't think this has to be very complex, just that different things should have different costs and take up different amounts of space too accommodate. Launching and recovering crafts should no more complex than it is to refuel or rearm a ship in space.
Title: Re: C# Suggestions
Post by: Froggiest1982 on August 08, 2020, 12:42:37 AM
I think that it would be great if we could turn different sensors types on and off individually on ships. For example there is little to no reason to put large resolution actives on ships as they will reveal your position as soon as you turn them on. Lower resolution scanners on the other hand like 1-10 in resolution is more effective as the type of craft they tries to find usually struggle to have passive good enough to detect them before they are themselves detected by the active sensors so there can be a reason to use them and not large resolution scanners that will guarantee to reveal you long before you detect anything with that active sensor.

In addition to this I might also think it is time for an upgrade to how hangars work too... it simply is too easy to deploy just about anything with hangars and rely on them for just about anything. In my opinion hangars simply is too powerful and basically is more like a modular compartment than an actual hangar. It is too easy to use them as a compartment to hold modular vessels, sensor options, weapons and everything is perfectly interchangeable with any size, type and configurations. We have advances and rather intricate mechanics for fuel, supplies and ordnance but hangar operations and types are quite free, too dynamic and effective.

hangars should simply be a module where you add certain abilities such as max docking size, launch/recovery capability, ability to reload ordnance, maintenance of weapon versus say sensor system. It should be much cheaper and less space requirement to have say two bays that accommodate two 500t survey shuttles or four 300t recovery shuttles or servicing 20 300t missile fighter-bombers that need a whole different types of maintenance, space for quick reloading of ordnance and fuel as well as rapid launch and recovery facilities. There could be a difference between serviceable and storage capacity and the ability to operate offensive fighters. A ship might even have several separate hangar facilities that can do different things.


I don't think this has to be very complex, just that different things should have different costs and take up different amounts of space too accommodate. Launching and recovering crafts should no more complex than it is to refuel or rearm a ship in space.

About the Hangars, I was thinking something too. I think that they should work more like launchers and pods and or have a launcher and a tonnage similar to what you said.

So for instance you would design your Hangar for storage of units and then a launcher/door able to fit only a specific displacement or less.

You will end up with 12000 ton hangar and laucher/door for 1000 ton displacement.

But I think will really be hard...either to code and manage.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on August 08, 2020, 03:00:54 AM
I think that it would be great if we could turn different sensors types on and off individually on ships. For example there is little to no reason to put large resolution actives on ships as they will reveal your position as soon as you turn them on. Lower resolution scanners on the other hand like 1-10 in resolution is more effective as the type of craft they tries to find usually struggle to have passive good enough to detect them before they are themselves detected by the active sensors so there can be a reason to use them and not large resolution scanners that will guarantee to reveal you long before you detect anything with that active sensor.

In addition to this I might also think it is time for an upgrade to how hangars work too... it simply is too easy to deploy just about anything with hangars and rely on them for just about anything. In my opinion hangars simply is too powerful and basically is more like a modular compartment than an actual hangar. It is too easy to use them as a compartment to hold modular vessels, sensor options, weapons and everything is perfectly interchangeable with any size, type and configurations. We have advances and rather intricate mechanics for fuel, supplies and ordnance but hangar operations and types are quite free, too dynamic and effective.

hangars should simply be a module where you add certain abilities such as max docking size, launch/recovery capability, ability to reload ordnance, maintenance of weapon versus say sensor system. It should be much cheaper and less space requirement to have say two bays that accommodate two 500t survey shuttles or four 300t recovery shuttles or servicing 20 300t missile fighter-bombers that need a whole different types of maintenance, space for quick reloading of ordnance and fuel as well as rapid launch and recovery facilities. There could be a difference between serviceable and storage capacity and the ability to operate offensive fighters. A ship might even have several separate hangar facilities that can do different things.


I don't think this has to be very complex, just that different things should have different costs and take up different amounts of space too accommodate. Launching and recovering crafts should no more complex than it is to refuel or rearm a ship in space.

About the Hangars, I was thinking something too. I think that they should work more like launchers and pods and or have a launcher and a tonnage similar to what you said.

So for instance you would design your Hangar for storage of units and then a launcher/door able to fit only a specific displacement or less.

You will end up with 12000 ton hangar and laucher/door for 1000 ton displacement.

But I think will really be hard...either to code and manage.

I think that might be a bit too restrictive... I was more thinking that hangars had to be researched as a specific module like a magazine or shield where the bigger they are the less certain traits will take up in space so large hangars are more efficient than smaller ones for example. That way if you want a small boat bay at 600t to accomodate three smaller vessels you would designe it as such...

Hangar, storage 600t, launch/recovery 1 access port max 200t size, refuel and maintenance of non weapons system, crew quarters for 40 people. Total size might be say about 1000t or so. If you wanted ordnance handling and weapon maintenance capability the size might be bloated to say 1250t and the cost would be different. You then research these modular hangars and can add one or several on a ship and they act as one large hangar for management properties to simplify things.

Launch/recovery should then take time based on the size of the vessel docking as well as some technology and you also choose how fast the hangar would dock or launch crafts when designing the hangars. There could even be systems on ships themselves to improve dock and launch times as well representing more carrier focused craft over none carrier focused crafts, or the seeped would entirely be dictated by size and the design of the docking craft and not the hangar that would only limit the size and numbers of craft that can dock or launch at the same time to make the choices more interesting.

Docking a 10kt ship into a hangar would likely take a hours while docking a 100t scout perhaps only will take a 5-20 min depending on their design.

For simplicity you should probably only allow one type of hangar on a ship... otherwise you need to also manage which hangar a ship is docking with.
Title: Re: C# Suggestions
Post by: SevenOfCarina on August 08, 2020, 03:10:08 AM
Regarding hangars, haven't we had this exact same discussion (or something similar) before? See here (http://aurora2.pentarch.org/index.php?topic=10387.0). IIRC, Steve wasn't too keen on the idea.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on August 08, 2020, 05:50:40 AM
Regarding hangars, haven't we had this exact same discussion (or something similar) before? See here (http://aurora2.pentarch.org/index.php?topic=10387.0). IIRC, Steve wasn't too keen on the idea.

I think he is mostly concerned about how to solve the docking and launching of crafts and not make it complicated. My idea is not to make that complicated at all just take time based on how the hangars is designed. If you try to dock and launch craft into a hangar the game will just queue them up and land or launch them appropriately... pretty much the same as refuelling and ordnance transfer taking time based on some factors.

It also would make choices for how to build hangars and not make every hangar into a modular slot you can put just anything in. You could for example just build a carrier meant to carry fighters... so you have no refuelling system or maintenance system in them at all and just minimal docking system. They simply would be a freighter system for parasites... or you have light carrier with only refuel and maintenance systems to carry spare fighters and who can service scouts... but they really can't operate fighters for combat but they can store them.

I think there are allot of RP potential and feel to this without making it too complicated.

I also feel that hangars simply is too effective as they can store too much for what they do, missile fighters are extremely effective and could see a slight hit with the nerf hammer.  :)
Title: Re: C# Suggestions
Post by: Dreadder on August 08, 2020, 12:27:23 PM
Quote
Commanders can be assigned as an Academy Commandant on any population with at least one military academy. Any type of commander can be assigned with the following restrictions:

1) A civilian administrator must have an Admin Rating equal or greater than the number of military academies at the population
2) A scientist must have a Research Administration rating (new bonus for C# which is the max number of labs) at least five times the number of military academies at the population
3) A naval or ground forces officer must have a rank (with 1 being the lowest rank) at least equal to the number of military academies
Any chance of changing that to a different system, perhaps allowing the top naval rank to command any number of academies?

The problem currently is, that it's impossible to assign academy commander in case where the number of academies is higher than a number of different ranks - in case of Terran Federation ranking for instance 8, while I find myself in a much greater need for officers and therefore academies now that we have a more detailed and complex ground combat and structures, not to mention all the aux bridges, tactical officers and so on.
Title: Re: C# Suggestions
Post by: Barkhorn on August 08, 2020, 07:37:33 PM
Suggestion: Stop automatically adding a bridge when a ship is over 1000 tons.  I'm fine with requiring a bridge on ships over 1000 tons, but don't do that for us automatically.  It's very annoying when fine-tuning FAC's to constantly have to remove the bridge every time I add one too many fuel tanks.
Title: Re: C# Suggestions
Post by: Dreadder on August 11, 2020, 10:28:54 AM
Would it be possible to have an option to somehow make the date/timestamp in the event log more visible/distinguishable from actual events or even better a button to jump to the start of the last increment log?

I like to have my ground combat reports detailed but that unfortunately sometimes means hundreds of events per date, so scrolling back to the start of the increment can be a bit of a chore, especially since it's quite easy to miss the actual start of the increment due to all the scrolling and timestamp looking the same as non-modified event text.

I suppose the easiest way would be to have an option to change text/background colour of the timestamp, same as there is for events, or perhaps underlining the timestamp, though "Jump to the start of the last increment" button would still be godsend. :)
Title: Re: C# Suggestions
Post by: Barkhorn on August 11, 2020, 11:04:58 AM
You can set the color of events by type in the event window. 
Title: Re: C# Suggestions
Post by: Dreadder on August 11, 2020, 11:15:14 AM
You can set the color of events by type in the event window.
I know. I am talking about the date/timestamp at the beggining of increment log which can't be modified/coloured the same way events can.
Title: Re: C# Suggestions
Post by: skoormit on August 11, 2020, 11:38:19 AM
You can set the color of events by type in the event window.
I know. I am talking about the date/timestamp at the beggining of increment log which can't be modified/coloured the same way events can.

I suppose if you modify the color of all the event types, then the timestamp will be the only one left as the default.
That might suit your purposes for the time being, but I agree that in cases like these (dozens or hundreds of events in a single increment) it would be nice to have a way to quickly jump to the beginning of an increment, or to the previous increment.
Title: Re: C# Suggestions
Post by: Dreadder on August 11, 2020, 12:06:37 PM
I suppose if you modify the color of all the event types, then the timestamp will be the only one left as the default.
That might suit your purposes for the time being, but I agree that in cases like these (dozens or hundreds of events in a single increment) it would be nice to have a way to quickly jump to the beginning of an increment, or to the previous increment.
I actually tried something similar and while it's still better than nothing, I still often managed to miss a timestamp, due to it being inconspicuous while everything else was visually just screaming for attention. :)
Title: Re: C# Suggestions
Post by: skoormit on August 11, 2020, 04:48:51 PM
In the Overview pane of the Galactic Map window, add the (JG) suffix to gated jump points (as in the jump point list of the System View window).
Title: Re: C# Suggestions
Post by: Barkhorn on August 12, 2020, 12:58:55 AM
Suggestion: How about requiring a few combat increments before you can have rear and support field positions.  Seems kinda crazy to me that my static HQ can be safely behind the lines before those lines even have a chance to form.  What we have now is basically like if the paratroopers on D-Day dropped in with a full fire-base, buildings and all.
Title: Re: C# Suggestions
Post by: kingflute on August 12, 2020, 08:01:37 AM
Suggestion: adding the ability to mothball obsolete/surplus ships, so that they have very small upkeep costs and crews and dont run down maintinance clocks and are quicker to bring into service than brand new ships
Title: Re: C# Suggestions
Post by: Barkhorn on August 12, 2020, 01:10:51 PM
Suggestion: On the tactical map, don't keep focus on the system selection dropdown.  It's very annoying to pick a system, then scroll thinking you're going to zoom in or out, but it actually scrolls through the system list.
Title: Re: C# Suggestions
Post by: Elvin on August 12, 2020, 04:44:44 PM
Suggestion: On the tactical map, don't keep focus on the system selection dropdown.  It's very annoying to pick a system, then scroll thinking you're going to zoom in or out, but it actually scrolls through the system list.

Unfortunately you're fighting a Windows standard feature there. The scroll wheel will operate on whatever is left in focus. I suppose you could possibly deliberately unfocus the field when a selection is made, but I think that may not play nicely with trying to type into the field in order to select a system?
Title: Re: C# Suggestions
Post by: skoormit on August 12, 2020, 09:27:34 PM
Suggestion: On the tactical map, don't keep focus on the system selection dropdown.  It's very annoying to pick a system, then scroll thinking you're going to zoom in or out, but it actually scrolls through the system list.

When I select a system in the dropdown and then immediately use the scroll wheel, the map zooms, unless I leave the mouse pointer over the dropdown.
I'm using the Windows setting "scroll inactive windows when I hover them". Maybe that's the difference?
Title: Re: C# Suggestions
Post by: skoormit on August 13, 2020, 11:18:09 AM
On the Naval Organization window, in the admin/fleet structure pane on the left, when I drag a fleet to a different naval admin node, a different fleet becomes the currently selected fleet.

Can we change that so that a fleet remains the selected fleet after it is dragged to a different node?
Title: Re: C# Suggestions
Post by: Dreadder on August 13, 2020, 12:49:45 PM
A place in the Intelligence and Foreign Relation window that would show relationships between NPRs revealed through espionage, since it's currently not recorded anywhere except in the event log.
Title: Re: C# Suggestions
Post by: Borealis4x on August 14, 2020, 09:27:32 PM
Executive officers for ground formations would be nice.
Title: Re: C# Suggestions
Post by: skoormit on August 15, 2020, 09:06:38 AM
Right clicking a location on the tactical map displays a selection list of colonies and fleets near the location.
In many cases, the list includes a large number of civilian ships, which makes it difficult to select the fleet I am interested in.

I never actually want to select a civilian ship, but I can imagine that there are occasions when it might be useful (especially if it actually worked correctly--currently, if you select a civilian ship, the Naval Organization window opens but it does not have a fleet selected).

Suggestion:
In the selection list that appears when right clicking a location on the tactical map, don't list civilian ships.
Instead, if civilian ships are present, add a "Civilian ->" item at the top of the list. If that item is clicked, display the list of civilian ships (to the side of the original list).
Title: Re: C# Suggestions
Post by: Tikigod on August 15, 2020, 09:18:30 AM
Right clicking a location on the tactical map displays a selection list of colonies and fleets near the location.
In many cases, the list includes a large number of civilian ships, which makes it difficult to select the fleet I am interested in.

I never actually want to select a civilian ship, but I can imagine that there are occasions when it might be useful (especially if it actually worked correctly--currently, if you select a civilian ship, the Naval Organization window opens but it does not have a fleet selected).

Suggestion:
In the selection list that appears when right clicking a location on the tactical map, don't list civilian ships.
Instead, if civilian ships are present, add a "Civilian ->" item at the top of the list. If that item is clicked, display the list of civilian ships (to the side of the original list).

Definitely helpful. Whilst a bit more complicated to implement, having the right click list take whatever tactical map display filters you have enabled/disabled would be a nice touch as well so we have full control over the right click menu.
Title: Re: C# Suggestions
Post by: skoormit on August 17, 2020, 09:26:56 AM
When an Auto Refit task is created while the Use Components checkbox is checked, the first refit task created uses existing components, but subsequent tasks do not.

Can we make the auto-refit task continue to use components for subsequent tasks?
Title: Re: C# Suggestions
Post by: Barkhorn on August 17, 2020, 03:42:55 PM
Suggestion: Let us restrict medals to certain classes of ship and ground formation.  I may want my missile ships to get different medals than my orbital defense platforms.  The US Navy and US Coast Guard don't issue the same medals.
Title: Re: C# Suggestions
Post by: HeroicHan on August 22, 2020, 11:26:03 AM
I'm sure this has already been expressed at some level, but there are a bunch of missing SM features that are pretty critical to any sort of multi-human rp/multiplayer experience.
Transferring ships and commanders to aliens. (Ground troops have the option but for some reason these don't)
Critical if you have a merchant/mercenary empire that wants to sell ships/fleets.

Transferring tech (including racial techs). Super fun to RP 'licensing' engines or other components to other factions.

SM Wealth. It really leaves a giant hole. Without it, races can currently only trade in minerals, and without the aforementioned transferring of ships/tech, there's really nothing to buy anyways.
It's also nice to be able to 'buy' research labs and whatnot from the civilian sector.

Suggestion: Add a game option to toggle the tech bleed effect. It really kills competitive teching in a multiplayer setting. For example, why would a player research "Research Rate" if they are just going to bump up everyone else's tech as well? For most techs there is a work around to just remove the bled techs, but the Construction category seems to remember your highest ever level, so if you remove the 'gifted' Research Rate 240, the research rate doesn't go back down to 200.
And believe me I have tried everything to circumvent this. I tried to make three different 'races' of 'humans'. I tried to shatter the Earth and made 3 identical Earths, in slightly different locations, with different names. I can only conclude that the tech bleeding is linked to home system and not home planet or race. I'd really just like a toggle.   :)
Title: Re: C# Suggestions
Post by: Froggiest1982 on August 22, 2020, 04:15:40 PM
Export Event Log function as VB6
Title: Re: C# Suggestions
Post by: Dutchling on August 23, 2020, 03:12:21 PM
Suggestion: An option in the Galaxy Map to see the distance in LY between systems, similar to the current in-game distance.
Title: Re: C# Suggestions
Post by: Zap0 on August 24, 2020, 06:14:30 PM
I'm having four tankers of the same type, three ran out of fuel, one hasn't. There's no way for me that I can see to make them equalize/share their fuel.
Title: Re: C# Suggestions
Post by: Demonides on August 25, 2020, 02:21:28 AM
Suggestion: An option in the Galaxy Map to see the distance in LY between systems, similar to the current in-game distance.

Title: Re: C# Suggestions
Post by: Demonides on August 25, 2020, 02:22:50 AM
I'm having four tankers of the same type, three ran out of fuel, one hasn't. There's no way for me that I can see to make them equalize/share their fuel.

In C# Aurora, refuelling is no longer instant and ships without specialised equipment cannot exchange fuel in space. A ship can only refuel at a Spaceport, a Refuelling Station, a ship with a Refuelling System or a base with a Refuelling Hub.

http://aurora2.pentarch.org/index.php?topic=8495.msg97525#msg97525

http://aurora2.pentarch.org/index.php?topic=10666.0

Title: Re: C# Suggestions
Post by: skoormit on August 25, 2020, 10:06:15 AM
I'm having four tankers of the same type, three ran out of fuel, one hasn't. There's no way for me that I can see to make them equalize/share their fuel.

Detach the tanker with fuel from the fleet.
Give the other three orders to refuel from it.
Manually monitor the fuel levels until equalized (or roughly), then rejoin the fourth tanker to the fleet.
Title: Re: C# Suggestions
Post by: Panopticon on August 25, 2020, 01:42:14 PM
It'd probably be a huge pain to code but the Imperium AAR has been making me want to see some mechanic for forgetting tech.

Some mechanic, maybe time based, or perhaps based on scientists dying or something would give a chance for your empire to "forget" a particular tech, like Magneto-Plasma engines or something, they, and all the stuff dependent on it becomes unavailable outside of whatever you have in use and you either have to reverse engineer it back or discover it in ruins or with conquest to get it back.

It would make for a fun mix of ship styles and some neat gameplay choices, do you send in your best ships on the jump point assault and risk losing the last example of Antimatter reactors in your fleet? Or do you use your newer weaker ships and risk failing entirely?
Title: Re: C# Suggestions
Post by: Drakale on August 25, 2020, 02:59:18 PM
I am playing with fighter based operations lately and one of the things I would really like to see at some point in the future is some kind of countermeasure system for light crafts.

The main reason I suggest this is the extreme vulnerability of fighters to AMM. Don't get me wrong, AMM should be a deadly threat to fighters, but at the moment they are basically certain death even in modest quantities. Even missiles designed to kill capital ships are fairly effective at killing fighters which I think is a bit counter intuitive. One can design crafts to stay out of missile/sensor range, and indeed that is kind of the only real build that work against a sizeable force for strike fighters.

The way I would imagine it is basically a personal range only amm that use lightweight ammo. The System itself is a comparable to a mini size 1 launcher. The amount of countermeasure launcher would determine how many evade attempts can be made per salvo increments(probably more than 5sec at start depending on tech level). The system can only be mounted on fighters(500 ton and <) since it rely on maneuverability and sensor overload. Technically it would be cool to separate the countermeasure in chaff/flares and the likes, but I fear this would make it quite a bit of a management hell, not to mention much harder to implement. I would just assume the countermeasure are designed to deal with thermal/grav/EM guidances at the same time.

The countermeasure launch would be automatic when the closest targeting missile get within a certain configurable range. The countermeasure affect all missiles currently targeting the craft within a range defined by tech level(about 200 k I would say at low tech level). At that point a roll is made and the affected missiles have a certain % chance to get misdirected, effectively destroying it. To keep it simple I would use a flat % dependent on tech(50%, 60%, 70% or something to that effect).

I am thinking fighters could carry 5 countermeasure per dedicated storage ton, but that might be too much. Keep in mind the system can launch multiples countermeasure per increment with more than one launcher, making more evade rolls. The countermeasure are replenished with MSP when landed at a carrier(not from on board MSP).

For an example scenario, a fighter is currently targeted by 20 missiles from 4 different waves of 5 each. The closest wave is within the configured 50k countermeasure activation range, causing the fighter to automatically launch a salvo. The second wave is within the 200k max effect range so it will also be affected, but the 3rd and 4th waves are out of range so entirely unaffected. The fighter has 2 launcher with a flat 60% chance to misdirect. So for each of the 10 affected missiles 2 rolls are made and any successful roll will (effectively)destroy the missile. Surviving missiles will then continue on their way or try and hit if they would reach this increment.

So with a squadron equipped with this system, there is now a meaningful choice when a wave of missiles show up on scanner. You can push on into firing range or try and get out of reach. You will still probably lose the squad if you ventured too far but this get you a fighting chance.

I realize that fighters are already strong, but this would exchange firepower for some measure of protection. The "strong" fighter design in the current version never get into missile range anyway, this would make a larger array of fighter roles viable.

Thanks for listening to my TED talk.
Title: Re: C# Suggestions
Post by: clew on August 25, 2020, 03:17:47 PM
I'm sure this has been stated before but I would like to request the return of the "Destroy Missile" button.  As it stands, there's no way to remove a misplaced or messed up buoy or survey missile.
Title: Re: C# Suggestions
Post by: Droll on August 25, 2020, 04:13:51 PM
I am playing with fighter based operations lately and one of the things I would really like to see at some point in the future is some kind of countermeasure system for light crafts.

The main reason I suggest this is the extreme vulnerability of fighters to AMM. Don't get me wrong, AMM should be a deadly threat to fighters, but at the moment they are basically certain death even in modest quantities. Even missiles designed to kill capital ships are fairly effective at killing fighters which I think is a bit counter intuitive. One can design crafts to stay out of missile/sensor range, and indeed that is kind of the only real build that work against a sizeable force for strike fighters.

The way I would imagine it is basically a personal range only amm that use lightweight ammo. The System itself is a comparable to a mini size 1 launcher. The amount of countermeasure launcher would determine how many evade attempts can be made per salvo increments(probably more than 5sec at start depending on tech level). The system can only be mounted on fighters(500 ton and <) since it rely on maneuverability and sensor overload. Technically it would be cool to separate the countermeasure in chaff/flares and the likes, but I fear this would make it quite a bit of a management hell, not to mention much harder to implement. I would just assume the countermeasure are designed to deal with thermal/grav/EM guidances at the same time.

The countermeasure launch would be automatic when the closest targeting missile get within a certain configurable range. The countermeasure affect all missiles currently targeting the craft within a range defined by tech level(about 200 k I would say at low tech level). At that point a roll is made and the affected missiles have a certain % chance to get misdirected, effectively destroying it. To keep it simple I would use a flat % dependent on tech(50%, 60%, 70% or something to that effect).

I am thinking fighters could carry 5 countermeasure per dedicated storage ton, but that might be too much. Keep in mind the system can launch multiples countermeasure per increment with more than one launcher, making more evade rolls. The countermeasure are replenished with MSP when landed at a carrier(not from on board MSP).

For an example scenario, a fighter is currently targeted by 20 missiles from 4 different waves of 5 each. The closest wave is within the configured 50k countermeasure activation range, causing the fighter to automatically launch a salvo. The second wave is within the 200k max effect range so it will also be affected, but the 3rd and 4th waves are out of range so entirely unaffected. The fighter has 2 launcher with a flat 60% chance to misdirect. So for each of the 10 affected missiles 2 rolls are made and any successful roll will (effectively)destroy the missile. Surviving missiles will then continue on their way or try and hit if they would reach this increment.

So with a squadron equipped with this system, there is now a meaningful choice when a wave of missiles show up on scanner. You can push on into firing range or try and get out of reach. You will still probably lose the squad if you ventured too far but this get you a fighting chance.

I realize that fighters are already strong, but this would exchange firepower for some measure of protection. The "strong" fighter design in the current version never get into missile range anyway, this would make a larger array of fighter roles viable.

Thanks for listening to my TED talk.

+1, as you said this is not really buff for missile fighters who will avoid AMM ranges altogether but it makes smol beamy bois like meson fighters have much stronger endurance against fleets.

Making beam fighters better at engaging fleets might also make interceptors become viable as actual anti-fighter craft who and instead fill in instead of secondary batteries and AMMs.

Its important to note that firing AMMs at fighters results in AMMs that can no longer be fired on hostile missiles.
Title: Re: C# Suggestions
Post by: Droll on August 27, 2020, 04:00:02 PM
I've been thinking of an idea to facilitate longer range missiles, specifically LRAMMs (Long Range AMM). Instead of making MFCs stronger, allowing MFCs to "take over" missiles in flight and guide them to a target.

As a case example of what I mean, consider a scenario where an orbital AMM platform is firing 2-stage LRAMMs against a salvo that is fired at nearby shipping, the stations MFC lacks the range to lock on to the missiles so instead fires the missiles towards a waypoint in the direction of the incoming salvo.

Near that waypoint is a fighter/ship with no missile launchers but equipped with MFC(s) that are within tracking range of the salvo. When the LRAMMs are near the waypoint, the player can assign the missiles in flight to the MFC(s) of the fighter and assign the target as the incoming salvo allowing the fighter to provide terminal guidance to the LRAMMs which will then incercept the salvo.

This would only be possible in the presence of strong thermal detection however since Active sensors against size 6 missiles and smaller lacks the range for this to be useful.

Right now proper PD area defense on a large scale isnt really possible especially since adding range to AMMs doesnt make sense as most NPR missiles can only be tracked at sub 10m km ranges (owing to their <6 MSP size).
Title: Re: C# Suggestions
Post by: Erik L on September 01, 2020, 08:24:43 PM
I am sure this has been suggested prior, but an autosave feature. Maybe every thirty days, it triggers the save routine.

Second suggestion for beam FC. As standard up to their size and range. From range to 2x range, hit chances are 50%, 2x to 4x range, hit chances are 25%. 4x to 10x, hit chances are 10%. Maybe 10x to weapon max range the hit chances are 1%.
Title: Re: C# Suggestions
Post by: Barkhorn on September 01, 2020, 10:07:13 PM
I wouldn't be surprised if this has already been suggested, but I'm bringing it up anyways because how it currently works is weird and annoying.

Why not unify all the design UI styles?  Why do some fields, like engine size, have extremely long drop-down lists while other fields, like turret tracking speed, allow us to type arbitrary values in?  Why not have all fields allow arbitrary values?

Likewise, the way BFC's work is weird.  Why can we only choose a handful of size multipliers?  Why not let us choose any arbitrary tracking speed and range we want, and calculate the size of the BFC from that?  I'm not arguing to change how BFC's work, just how we design them.
Title: Re: C# Suggestions
Post by: Droll on September 01, 2020, 10:20:52 PM
I am sure this has been suggested prior, but an autosave feature. Maybe every thirty days, it triggers the save routine.

Second suggestion for beam FC. As standard up to their size and range. From range to 2x range, hit chances are 50%, 2x to 4x range, hit chances are 25%. 4x to 10x, hit chances are 10%. Maybe 10x to weapon max range the hit chances are 1%.

If an autosave feature makes it into vanilla aurora, I would like to be able to turn it off/configure the frequency though.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on September 02, 2020, 03:22:35 AM
I've been thinking of an idea to facilitate longer range missiles, specifically LRAMMs (Long Range AMM). Instead of making MFCs stronger, allowing MFCs to "take over" missiles in flight and guide them to a target.

As a case example of what I mean, consider a scenario where an orbital AMM platform is firing 2-stage LRAMMs against a salvo that is fired at nearby shipping, the stations MFC lacks the range to lock on to the missiles so instead fires the missiles towards a waypoint in the direction of the incoming salvo.

Near that waypoint is a fighter/ship with no missile launchers but equipped with MFC(s) that are within tracking range of the salvo. When the LRAMMs are near the waypoint, the player can assign the missiles in flight to the MFC(s) of the fighter and assign the target as the incoming salvo allowing the fighter to provide terminal guidance to the LRAMMs which will then incercept the salvo.

This would only be possible in the presence of strong thermal detection however since Active sensors against size 6 missiles and smaller lacks the range for this to be useful.

Right now proper PD area defence on a large scale isnt really possible especially since adding range to AMMs doesnt make sense as most NPR missiles can only be tracked at sub 10m km ranges (owing to their <6 MSP size).

In 1.12 you will be able to easily deploy escorts, you can easily deploy several small fighter scouts to extend your AMM detection bubble quite far out... then you can definitely design some long range AMM and engage at a much further distance.

Not saying your suggestion is a bad one, just saying it will be allot easier to pull of in 1.12 when that is released.
Title: Re: C# Suggestions
Post by: Droll on September 02, 2020, 06:25:40 AM
I've been thinking of an idea to facilitate longer range missiles, specifically LRAMMs (Long Range AMM). Instead of making MFCs stronger, allowing MFCs to "take over" missiles in flight and guide them to a target.

As a case example of what I mean, consider a scenario where an orbital AMM platform is firing 2-stage LRAMMs against a salvo that is fired at nearby shipping, the stations MFC lacks the range to lock on to the missiles so instead fires the missiles towards a waypoint in the direction of the incoming salvo.

Near that waypoint is a fighter/ship with no missile launchers but equipped with MFC(s) that are within tracking range of the salvo. When the LRAMMs are near the waypoint, the player can assign the missiles in flight to the MFC(s) of the fighter and assign the target as the incoming salvo allowing the fighter to provide terminal guidance to the LRAMMs which will then incercept the salvo.

This would only be possible in the presence of strong thermal detection however since Active sensors against size 6 missiles and smaller lacks the range for this to be useful.

Right now proper PD area defence on a large scale isnt really possible especially since adding range to AMMs doesnt make sense as most NPR missiles can only be tracked at sub 10m km ranges (owing to their <6 MSP size).

In 1.12 you will be able to easily deploy escorts, you can easily deploy several small fighter scouts to extend your AMM detection bubble quite far out... then you can definitely design some long range AMM and engage at a much further distance.

Not saying your suggestion is a bad one, just saying it will be allot easier to pull of in 1.12 when that is released.

For detection this has always been possible - the issue is not detection its FC target aquisition. Those fighters can see the missiles but they cannot provide terminal guidance with their own MFCs. Normally this is not an issue as MFC ranges are quite high however with AMMs the target lock range for size 6 and smaller missiles can be somewhat restrictive. At least for the purposes of providing area defense with AMMs which is their main appeal.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on September 02, 2020, 03:32:52 PM
I've been thinking of an idea to facilitate longer range missiles, specifically LRAMMs (Long Range AMM). Instead of making MFCs stronger, allowing MFCs to "take over" missiles in flight and guide them to a target.

As a case example of what I mean, consider a scenario where an orbital AMM platform is firing 2-stage LRAMMs against a salvo that is fired at nearby shipping, the stations MFC lacks the range to lock on to the missiles so instead fires the missiles towards a waypoint in the direction of the incoming salvo.

Near that waypoint is a fighter/ship with no missile launchers but equipped with MFC(s) that are within tracking range of the salvo. When the LRAMMs are near the waypoint, the player can assign the missiles in flight to the MFC(s) of the fighter and assign the target as the incoming salvo allowing the fighter to provide terminal guidance to the LRAMMs which will then incercept the salvo.

This would only be possible in the presence of strong thermal detection however since Active sensors against size 6 missiles and smaller lacks the range for this to be useful.

Right now proper PD area defence on a large scale isnt really possible especially since adding range to AMMs doesnt make sense as most NPR missiles can only be tracked at sub 10m km ranges (owing to their <6 MSP size).

In 1.12 you will be able to easily deploy escorts, you can easily deploy several small fighter scouts to extend your AMM detection bubble quite far out... then you can definitely design some long range AMM and engage at a much further distance.

Not saying your suggestion is a bad one, just saying it will be allot easier to pull of in 1.12 when that is released.

For detection this has always been possible - the issue is not detection its FC target aquisition. Those fighters can see the missiles but they cannot provide terminal guidance with their own MFCs. Normally this is not an issue as MFC ranges are quite high however with AMMs the target lock range for size 6 and smaller missiles can be somewhat restrictive. At least for the purposes of providing area defense with AMMs which is their main appeal.

I understood what you meant... but it is not that difficult to build a bigger fire-control to guide the missiles at distances that is reasonable to engage missiles with AMM without sacrificing too much accuracy of the AMM.

I don't think it is a bad idea either... I just think it might have other unwanted side effects that has nothing to do with AMM.
Title: Re: C# Suggestions
Post by: Droll on September 02, 2020, 04:08:51 PM
I've been thinking of an idea to facilitate longer range missiles, specifically LRAMMs (Long Range AMM). Instead of making MFCs stronger, allowing MFCs to "take over" missiles in flight and guide them to a target.

As a case example of what I mean, consider a scenario where an orbital AMM platform is firing 2-stage LRAMMs against a salvo that is fired at nearby shipping, the stations MFC lacks the range to lock on to the missiles so instead fires the missiles towards a waypoint in the direction of the incoming salvo.

Near that waypoint is a fighter/ship with no missile launchers but equipped with MFC(s) that are within tracking range of the salvo. When the LRAMMs are near the waypoint, the player can assign the missiles in flight to the MFC(s) of the fighter and assign the target as the incoming salvo allowing the fighter to provide terminal guidance to the LRAMMs which will then incercept the salvo.

This would only be possible in the presence of strong thermal detection however since Active sensors against size 6 missiles and smaller lacks the range for this to be useful.

Right now proper PD area defence on a large scale isnt really possible especially since adding range to AMMs doesnt make sense as most NPR missiles can only be tracked at sub 10m km ranges (owing to their <6 MSP size).

In 1.12 you will be able to easily deploy escorts, you can easily deploy several small fighter scouts to extend your AMM detection bubble quite far out... then you can definitely design some long range AMM and engage at a much further distance.

Not saying your suggestion is a bad one, just saying it will be allot easier to pull of in 1.12 when that is released.

For detection this has always been possible - the issue is not detection its FC target aquisition. Those fighters can see the missiles but they cannot provide terminal guidance with their own MFCs. Normally this is not an issue as MFC ranges are quite high however with AMMs the target lock range for size 6 and smaller missiles can be somewhat restrictive. At least for the purposes of providing area defense with AMMs which is their main appeal.

I understood what you meant... but it is not that difficult to build a bigger fire-control to guide the missiles at distances that is reasonable to engage missiles with AMM without sacrificing too much accuracy of the AMM.

I don't think it is a bad idea either... I just think it might have other unwanted side effects that has nothing to do with AMM.

I guess this is just me wanting to lob AMMs 100m km instead of 10m km against size 6 missiles. The detection range of the larger missiles doesn't really matter to me since I always seem to come up against small ones.

I think as an additional suggestion I could ask for a lower minimum resolution for MFCs which would accomplish the same thing without the mechanical complexity
Title: Re: C# Suggestions
Post by: TMaekler on September 04, 2020, 02:11:27 AM
I am thinking about including a deeper exchange system for technology - not necessarily the tech itself but rather selling or leasing ships, fighters, etc. In our world are some countries who build high tech weaponry and others who don’t. Those usually bye them from the high tech countries. And the low tech countries usually can’t afford the research - which is no hindrance in Aurora at all. The cost for a research facility is quite low. So one starting point for this could be a two step change:
A) building cost for a research center could be a lot higher; maybe also adding a kind of maintenance system for buildings in general... . Which would increase the overall costs to maintain being a high tech country.
B) A new research path that starts with a way lower research output for research facilities - so if you want to become a high tech power, you have to do quite an amount of research first to even get there. Included in this would be a starting option to start as a low tech or high tech nation - latter having already done that process and start on what is the current level of research in Aurora.

So as a low tech country you can choose to bye your ships and fighters, or you can invest into research and become one yourself later. Which gives you more options to specialize your nations industry. You could become a money power house but bad in research - or become a research giant and be dependent upon weapon sales to keep your country going... .
Title: Re: C# Suggestions
Post by: SevenOfCarina on September 04, 2020, 03:44:38 AM
I think the base reload time for missiles should be reduced to 15s from the current 30s. As things stand, full-sized AMM launchers are too ineffective to act as a countermeasure for box-launched ASMs at low tech levels, which means that combat quickly devolves into fleets of glass cannon vessels attempting to shoot the opposite side first. The only realistic defence is apparently box-launched AMMs.

This would allow AMM launchers to achieve 5s reload times at about the same time beam weapons achieve 5s reloads, and would also make larger AMMs viable at higher tech levels. Since reload times are rounded up, even a slight increase in AMM size in the Fusion eras would increase the reload time from 5s to 10s, which can be crippling since you'd need sensors that are four times as large to fire the same total MSP with an equal displacement in larger launchers.

About the only thing that such a change would do is improve the effectiveness of full-sized AMM launchers against box-launched ASMs. Full-sized ASM launchers are hilariously bad, full-sized AMM launchers are hard-countered by beam point-defence, and I don't think it's significantly different if reduced-size ASM launchers reload every ten minutes instead of every twenty.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on September 04, 2020, 06:49:17 AM
I am thinking about including a deeper exchange system for technology - not necessarily the tech itself but rather selling or leasing ships, fighters, etc. In our world are some countries who build high tech weaponry and others who don’t. Those usually bye them from the high tech countries. And the low tech countries usually can’t afford the research - which is no hindrance in Aurora at all. The cost for a research facility is quite low. So one starting point for this could be a two step change:
A) building cost for a research center could be a lot higher; maybe also adding a kind of maintenance system for buildings in general... . Which would increase the overall costs to maintain being a high tech country.
B) A new research path that starts with a way lower research output for research facilities - so if you want to become a high tech power, you have to do quite an amount of research first to even get there. Included in this would be a starting option to start as a low tech or high tech nation - latter having already done that process and start on what is the current level of research in Aurora.

So as a low tech country you can choose to bye your ships and fighters, or you can invest into research and become one yourself later. Which gives you more options to specialize your nations industry. You could become a money power house but bad in research - or become a research giant and be dependent upon weapon sales to keep your country going... .

In my opinion there should perhaps be two different tech buildings... one for theoretical technologies and one for practical engineering of components. Theoretical knowledge should much easily bleed into other factions that has trade with each other while practical engineering of components really don't in the same way. You could then both sell components or even license their production which also eventually transfer the knowledge to build them, sort of bleeding that knowledge to the licensed faction.

I would also like to see a change to how administration and research work... I would like to see a diminishing return on adding labs to projects and the admin rating would flatten that curve instead of being a hard limit, this would make admin rating important directly in a similar way to their skill but in a different way.

We already pay maintenance in labs in the form of wealth so I don't believe that we need to more maintenance, but a diminishing return on research point will effectively have the same effect as you pay more the more labs you put into a specific project (each lab would still cost max wealth for the tech level, not actual RP produces). Having a diminishing return also make spreading the labs around more of a thing and will also reduce the tech progression in a linear manner rather than exponential that we often see now. I have to repeatedly lower the tech rate in my games to seem more of a linear progression so factions don't snowball too hard.
Title: Re: C# Suggestions
Post by: DEEPenergy on September 04, 2020, 02:55:30 PM
It would be nice if racial weapon and armor bonuses for ground troops were applied when the troops were being constructed instead of being designed. Or for more complexity and fine tuning allow us to re-research ground units so the design is updated with the most recent armor and weapons tech. Having to remake ground forces is a chore and in the early tech levels, you almost dont want to build them because you're going to blow passed the tech level quickly  :) Love the game
Title: Re: C# Suggestions
Post by: Droll on September 04, 2020, 06:26:48 PM
It would be nice if racial weapon and armor bonuses for ground troops were applied when the troops were being constructed instead of being designed. Or for more complexity and fine tuning allow us to re-research ground units so the design is updated with the most recent armor and weapons tech. Having to remake ground forces is a chore and in the early tech levels, you almost dont want to build them because you're going to blow passed the tech level quickly  :) Love the game

Your concern is partially addressed in 1.12, much like the missile series of old, there will be unit series. You will be able to add units under your own unit series and designate certain formations as a "replacement formation". The unit at the top of a unit series is the one that is looked for first so you can put the high tech versions of the same unit at the top of its own series and units will automatically fill up formations that lack units.

To read more about it look at the 1.12 changes under the mechanics subsection on the forum
Title: Re: C# Suggestions
Post by: Barkhorn on September 06, 2020, 02:57:23 PM
Suggestion: Damage that propagates.  I've been watching a lot of Rule the Waves and Ultimate Admiral: Dreadnoughts content and fire and flooding make damage control much more interesting.  Maybe we could have something similar.
Title: Re: C# Suggestions
Post by: Droll on September 06, 2020, 08:04:04 PM
Suggestion: Damage that propagates.  I've been watching a lot of Rule the Waves and Ultimate Admiral: Dreadnoughts content and fire and flooding make damage control much more interesting.  Maybe we could have something similar.

Having ship interiors burst into flames could be cool. Im not sure how you would handle unique situations regarding space combat though. Life support failure is already in and is modelled quite well imo but perhaps you could have hull breaches that stick and require actual damage con to fix.
Title: Re: C# Suggestions
Post by: StarshipCactus on September 07, 2020, 06:25:54 AM
Maybe there could be some system of warning shots? So if you make a claim to something that is resisted, you can park a warship nearby and fire a warning shot if the alien ship does not change course. Or they can do the same to you.
Title: Re: C# Suggestions
Post by: TMaekler on September 08, 2020, 08:56:06 AM
I would find it a funny option if jump points could be orbital to the stars they are around - so basically they would move like planets around their main star - or even funnier - if they could be orbital around planets or moons... .

Of course optional when you start a new game: jump point orbital mechanics: yes/no
Title: Re: C# Suggestions
Post by: Annuminas on September 08, 2020, 01:19:06 PM
I apologize if these suggestions have been suggested or Steve is aware of them and plans to implement them when he gets to low priority stuff.

Could we have the option of transferring ordnance and fuel where I can specifically choose the exact amount being transferred with a slider or text box?

I understand where the ordnance template can come in handy, but when you are scrounging for missiles sometimes I would just like to go "this ship gets 12 of those, this other ship gets 9 of these, this other ship gets 2 of those". Perhaps I am stupid and this is already an option but I haven't seen it. I don't like having a collier go to a fleet and rearm everyone equally to try and fit their template. Sometimes I want certain ships to have more or less ordnance than usual *just once* and I don't want to have to go in, change the template, and then execute.

As for fuel, I understand you can set the minimum fuel, but I would much rather have the system in old Aurora where I can specify for a ship with 10,000,000 liters of fuel: "Transfer 2,350,000 liters at Earth...Transfer 1,200,000 liters at Luna...Transfer X more at Y location..."
Title: Re: C# Suggestions
Post by: Jorgen_CAB on September 10, 2020, 09:14:57 AM
In the event windows I would like to add either a text or background colour to the first row (empire name) as well as for the type of event.

When you play a multi-faction game it is way easier to browse specific messages by empire when they have a different colour rather than look at the name.
Title: Re: C# Suggestions
Post by: Barkhorn on September 10, 2020, 02:33:22 PM
I know we can color-code events in the event log, but could we also have a separate color for events that trigger interrupts?  In a busy empire, it can be annoying to read through ~50 events, looking for which event was important enough to stop auto-turns.  I know they're usually at the bottom, but a few, like scientist death/retirement are not.
Title: Re: C# Suggestions
Post by: dlathro1 on September 10, 2020, 06:56:02 PM
One problem I tend to have as my empire grows larger is that managing populations, specifically making sure planetary populations do not drop below the population necessary to run all the installations on the planet.

I have two potential solutions that will significantly decrease the micromanaging of populations:

1. Limit the colonists allowed to leave the body to Available Workers. The attached image shows a mock-up of how I think this could be done. The "Limit Emigration" checkbox, if checked, would limit colonists leaving the body to the number of Available Workers.

2. If the previous solution is too code-intensive, I would be satisfied with a similar checkbox that when checked would automatically switch the setting from "Source of Colonists" to "Stable" if there is a worker shortage. Ideally, the player would be alerted to this change trough an event, preferably one that stops time.

Some notes: I am not at all attached to any phasing or positioning I have put forward in this post, I am just requesting a feature and outlining the basics of how I think it could be implemented.
Title: Re: C# Suggestions
Post by: drejr on September 10, 2020, 07:24:18 PM
One thing I've noticed is that fleets tend to come "unstuck" from orbits fairly easily. This can be especially troublesome for stations with no engines.
Title: Re: C# Suggestions
Post by: Barkhorn on September 11, 2020, 03:29:05 PM
A few related suggestions:

First, can we please have different save files for each game?  It seems crazy to me that all our saves are in one DB file.  Splitting it would make creating back-ups easier, and would help with save and load times; no need to save or load games you aren't actually currently playing.

Second, can we have a way to trim superfluous entries from the DB, specifically in the event log?  The discord has found that a major source of long save times and possibly slow-down is the event log.  Late-game event logs can be hundreds of thousands of entries, especially if you have had significant ground combat.  Most of those entries will likely not matter for anything.  I don't expect the game to figure out which entries can be dropped, but maybe the user could.  Maybe it could be something like "Delete all entries before X date".
Title: Re: C# Suggestions
Post by: db48x on September 15, 2020, 10:33:35 AM
I've been thinking about terraforming lately, and I suggest that the terraforming tab include all the climate information about the planet, including things like the plate tectonics level that you can't change. This would make it easier to make a terraforming plan that changes the climate type as well as the colony cost.

As a further suggestion that would aid new players, you could add information about the current terrain type as well. The upper and lower bounds for temperature, hydrology, and oxygen content for the current terrain type are very useful to know when terraforming, but the only way to find out are either trial and error or searching the forum.
Title: Re: C# Suggestions
Post by: Barkhorn on September 15, 2020, 03:57:53 PM
Two related suggestions:

Can we please have display showing mineral totals for each system?  I get that I can eventually get that info by looking at the system window, but that is one system at a time and breaks it down by individual planets.  I want the totals of each mineral type in each system; that will help narrow down the search for systems to focus colonization efforts on.  I could then see at a glance what minerals a system has without having to scroll through the system window looking at every planet.  I will still want to do that eventually, but this way I can weed out many garbage systems with little effort.

With that in mind, can we please have the ability to mark systems on the galactic map, and have those marks influence standing orders?  The idea being that I could mark specific systems to be surveyed, and my surveyors would automatically go there and survey them.  Ideally we would be able to do this for other standing orders like "Move orbital miner to mineral source", but geosurveying is the one I'd want the most.
Title: Re: C# Suggestions
Post by: TMaekler on September 17, 2020, 03:29:57 AM
I know Steve isn't to keen on implementing features that don't add too much gameplay... I was wondering though if we could talk about ideas to get population and planetary management a bit more into the direction of having more details and interaction happening. For example that happiness and political support for what you are doing is interconnected with what you are doing and that is interconnected to the political system you are running your empire with. A democracy for example should make its citizens more unhappy if they start a war (yes, I know, totally unrealistic, but you know... ) etc.

Any ideas welcome that really add gameplay mechanics...
Title: Re: C# Suggestions
Post by: Migi on September 17, 2020, 12:49:46 PM
Can you please make the Components tab in the Class Design window show sizes in tons?

Also in the View Technology window, the size in tons setting causes missiles to show in tons rather than MSP.
That's not consistent with the size rating of missile launchers and magazines which stay in MSP.
Also Jump Engines only ever show their rating in Tons not in HS, regardless of the checkbox about tons.
Title: Re: C# Suggestions
Post by: Froggiest1982 on September 17, 2020, 08:51:25 PM
Also Jump Engines only ever show their rating in Tons not in HS, regardless of the checkbox about tons.

This sounds more like a bug, you could report it eventually.
Title: Re: C# Suggestions
Post by: dag0net on September 19, 2020, 06:26:16 AM
Reserve, Import/Export produce (buildings/-) add/draw excess by assigning contracts to civilian shipping.


I know Steve isn't to keen on implementing features that don't add too much gameplay... I was wondering though if we could talk about ideas to get population and planetary management a bit more into the direction of having more details and interaction happening. For example that happiness and political support for what you are doing is interconnected with what you are doing and that is interconnected to the political system you are running your empire with. A democracy for example should make its citizens more unhappy if they start a war (yes, I know, totally unrealistic, but you know... ) etc.

Any ideas welcome that really add gameplay mechanics...

Democracy? In a xenocidal war?  Tho that Star Fire series includes a plutocrat rebellion
Funny thing about democracy is that nobody ever submits things to a vote if they think they actually need doing, much less a public vote. Though perhaps in the far far future when people admit for more that 2 years at a time that there is no true divide between the military and civilian aspect of a civilization..military do not fight to beat military, they fight for one group of 'civilians' to subjugate another group of 'civilians.'


How to implement tho? In a democracy the military is not responsible for civilian happiness or the civilian economy, it's responsible for protecting civilian and state assets, if I was Steve I'd prolly go with implementing a system reversing the economic interaction, have the player piggyback on an NPR. Potentially complex but creating an impetus to flesh out AI/NPR's
Title: Re: C# Suggestions
Post by: Jorgen_CAB on September 19, 2020, 06:44:15 AM
How to implement tho? In a democracy the military is not responsible for civilian happiness or the civilian economy, it's responsible for protecting civilian and state assets, if I was Steve I'd prolly go with implementing a system reversing the economic interaction, have the player piggyback on an NPR. Potentially complex but creating an impetus to flesh out AI/NPR's

This obviously is correct... Aurora though is built in such a way that we are suppose to role-play this interaction of civilian and state assets. If you role-play a democratic society then the "state" assets is the part of the economy that you the "player" have access to and can distribute based on role-play of those resources. They don't have to be viewed as "state" owned resources entirely.

I know that allot of people, especially lately as the game have received more attention, play it like just another game that you are suppose to beat or compete with NPRs. Aurora has never really been intended to be that kind of game... it is purely meant to be about building a story and part of that is often to do things that might often not be mathematically optimal. Life rarely are about making the most mathematically optimal choices, that would be a boring life to live.

Anyway... the game are intentionally open so we can use role-play to set these restrictions on whatever empire type we are playing. Therefore any changes that Steve does usually have to be considered in respect to that concept.
Title: Re: C# Suggestions
Post by: dag0net on September 19, 2020, 07:22:12 AM
How to implement tho? In a democracy the military is not responsible for civilian happiness or the civilian economy, it's responsible for protecting civilian and state assets, if I was Steve I'd prolly go with implementing a system reversing the economic interaction, have the player piggyback on an NPR. Potentially complex but creating an impetus to flesh out AI/NPR's

This obviously is correct... Aurora though is built in such a way that we are suppose to role-play this interaction of civilian and state assets. If you role-play a democratic society then the "state" assets is the part of the economy that you the "player" have access to and can distribute based on role-play of those resources. They don't have to be viewed as "state" owned resources entirely.

I know that allot of people, especially lately as the game have received more attention, play it like just another game that you are suppose to beat or compete with NPRs. Aurora has never really been intended to be that kind of game... it is purely meant to be about building a story and part of that is often to do things that might often not be mathematically optimal. Life rarely are about making the most mathematically optimal choices, that would be a boring life to live.

Anyway... the game are intentionally open so we can use role-play to set these restrictions on whatever empire type we are playing. Therefore any changes that Steve does usually have to be considered in respect to that concept.

Of course, I am there responding to a hypothetical.
Title: Re: C# Suggestions
Post by: Froggiest1982 on September 19, 2020, 04:52:41 PM
How to implement tho? In a democracy the military is not responsible for civilian happiness or the civilian economy, it's responsible for protecting civilian and state assets, if I was Steve I'd prolly go with implementing a system reversing the economic interaction, have the player piggyback on an NPR. Potentially complex but creating an impetus to flesh out AI/NPR's

This obviously is correct... Aurora though is built in such a way that we are suppose to role-play this interaction of civilian and state assets. If you role-play a democratic society then the "state" assets is the part of the economy that you the "player" have access to and can distribute based on role-play of those resources. They don't have to be viewed as "state" owned resources entirely.

I know that allot of people, especially lately as the game have received more attention, play it like just another game that you are suppose to beat or compete with NPRs. Aurora has never really been intended to be that kind of game... it is purely meant to be about building a story and part of that is often to do things that might often not be mathematically optimal. Life rarely are about making the most mathematically optimal choices, that would be a boring life to live.

Anyway... the game are intentionally open so we can use role-play to set these restrictions on whatever empire type we are playing. Therefore any changes that Steve does usually have to be considered in respect to that concept.

Of course, I am there responding to a hypothetical.

As always, Jorge is correct. However I am trying to answer to this here http://aurora2.pentarch.org/index.php?topic=11908.msg140960#msg140960 big project but I think it has its market.
Title: Re: C# Suggestions
Post by: Barkhorn on September 24, 2020, 03:52:36 PM
Suggestion: Make passive sensor contacts less informative, and thus more realistic.  How can I know what class of ship I'm looking at just from how much heat it's radiating?  I mean, a long-range tanker running low-power high efficiency engines might have a thermal signature of 200.  Meanwhile a tiny fighter running very boosted engines might also have a thermal signature of 200.

Ideally I'd think we'd need an active sensor contact on a ship to tell what class it is.  Maybe even that should take time.
Title: Re: C# Suggestions
Post by: Elvin on September 24, 2020, 04:43:45 PM
Suggestion: Make passive sensor contacts less informative, and thus more realistic.  How can I know what class of ship I'm looking at just from how much heat it's radiating?  I mean, a long-range tanker running low-power high efficiency engines might have a thermal signature of 200.  Meanwhile a tiny fighter running very boosted engines might also have a thermal signature of 200.

Ideally I'd think we'd need an active sensor contact on a ship to tell what class it is.  Maybe even that should take time.

I don't remember exactly where I saw it, but in the modern world I'm fairly sure we can identify the type of submarine via passive sonar due to the exact noise profile it'll give out - different submarines will be running different levels of internal machinery, at different distances from the outer hull, and those tiny variations can be used to identify the ship. I wouldn't be too surprised if you could use the fact different nations ships will run on different voltages in some way.

To relate this back to the situation: Just because they're both level 200 doesn't mean they're identical signals. The "200" is an abstraction, and could easily represent a much more nuanced and in-depth set of sensor readings.
Title: Re: C# Suggestions
Post by: Barkhorn on September 24, 2020, 04:56:37 PM
That's because each sub creates a unique mix of frequencies.  But black body radiation is all the same.  A piece of iron at 800 degrees glows the same color as a block of aluminum at 800 degrees or a pool of lead at 800 degrees or a cloud of argon at 800 degrees.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on September 24, 2020, 08:04:31 PM
Yes, but a thermal signal of "200" from a single boosted engine is gonna look different than a total 200 signal that is the result of 4x50 engines spaced apart on a space frame.

The point is, thermal passives aren't infrared cameras looking at blackbody radiation. There is more going on. It's all technobabble, and as long as Aurora remains incapable of handling uncertainty (i.e. this will never change), you CAN'T make it "realistic" or even particularly close to it.
Title: Re: C# Suggestions
Post by: Borealis4x on September 24, 2020, 10:58:45 PM
I wonder if ground units should have to be equipped with 'suppression' or 'peace-keeping' equipment/training in order to reduce unrest on planets. An army isn't trained to police civilians, you should have to have special police units for that.

In combat, suppression equipment would perform like light infantry weapons but be more expensive.
Title: Re: C# Suggestions
Post by: xenoscepter on September 24, 2020, 11:42:18 PM
I wonder if ground units should have to be equipped with 'suppression' or 'peace-keeping' equipment/training in order to reduce unrest on planets. An army isn't trained to police civilians, you should have to have special police units for that.

I like this idea! And maybe a Miltia Unit too! :D
Title: Re: C# Suggestions
Post by: Borealis4x on September 24, 2020, 11:50:27 PM
I wonder if ground units should have to be equipped with 'suppression' or 'peace-keeping' equipment/training in order to reduce unrest on planets. An army isn't trained to police civilians, you should have to have special police units for that.

I like this idea! And maybe a Miltia Unit too! :D

Militia units should be spawned, not built. They'd have similar stats to crew; they'd use light weapons nly and have 1/3rd the armor of regular troops.

Another idea: Ground Unit Templates made of templates. For instance, instead of having to que up 3 infantry companies, 1 heavy weapons company, and 1 battalion command and then connect them all I could make an infantry battalion template that ques all those templates up, trains them together, and then deploys them all at once correctly attached to one-another.

EDIT: I also wish that ground units had executive officers which were just CO rank - 1. That way I'd actually use my Lt. Colonels and such.
Title: Re: C# Suggestions
Post by: Theoatmeal2 on September 25, 2020, 12:25:56 AM
How about a conditional order that tells the geo/grav ships to survey an unsurveyed system.  I`m getting sick of doing this manually.

If there is already a way to do this I`ll feel pretty stupid.
Title: Re: C# Suggestions
Post by: dag0net on September 25, 2020, 12:40:49 AM
How about a conditional order that tells the geo/grav ships to survey an unsurveyed system.  I`m getting sick of doing this manually.

If there is already a way to do this I`ll feel pretty stupid.

It depends how your geo/grav ships are designed to operate, the order system allows flexibility.
Don't have the orders to look at so phrasing is off.

Standing, not conditional: Survey next 5 system bodies(geo) & Survey next 3 system locations(grav)
&
'Move to system requiring geosurvey/gravsurvey

with conditionals for fuel/msp/enemies


If you don't see those, check version?

The selection favors single role, long range, jump drive equipped survey craft for hands off.
Title: Re: C# Suggestions
Post by: Theoatmeal2 on September 25, 2020, 12:47:39 AM
Quote from: dag0net link=topic=10640. msg141111#msg141111 date=1601012449
Quote from: Theoatmeal2 link=topic=10640. msg141110#msg141110 date=1601011556
How about a conditional order that tells the geo/grav ships to survey an unsurveyed system.   I`m getting sick of doing this manually. 

If there is already a way to do this I`ll feel pretty stupid.

It depends how your geo/grav ships are designed to operate, the order system allows flexibility.
Don't have the orders to look at so phrasing is off.

Standing, not conditional: Survey next 5 system bodies(geo) & Survey next 3 system locations(grav)
&
'Move to system requiring geosurvey/gravsurvey

with conditionals for fuel/msp/enemies


If you don't see those, check version?

The selection favors single role, long range, jump drive equipped survey craft for hands off.

Christ you are absolutely right, I`ve looked over and over how have I not seen that ???
Title: Re: C# Suggestions
Post by: linkxsc on September 27, 2020, 12:58:05 PM
Couple suggestions to make managing training fleets a bit easier.

First, movement order "Shore Leave". Orders a fleet to a planet to perform shore leave, and temporarily blocks standing orders and training until shore leave is completed. (Naturally manually canceling the shore leave and ordering the fleet will let you move them again. But otherwise, no automatic canceling of leave by standing orders)

Second. Conditional order and reaction, "Max Deployment Reached", and move to nearest recreational location and shore leave.

Basically these 2 are to make training divisions a little less manual (as one has to very often shift fleets around in commands to give training ships shore leave... and it gets a touch micromanagey after a while)
Title: Re: C# Suggestions
Post by: Droll on September 28, 2020, 10:51:45 AM
Couple suggestions to make managing training fleets a bit easier.

First, movement order "Shore Leave". Orders a fleet to a planet to perform shore leave, and temporarily blocks standing orders and training until shore leave is completed. (Naturally manually canceling the shore leave and ordering the fleet

Second. Conditional order and reaction, "Max Deployment Reached", and move to nearest recreational location and shore leave.

Basically these 2 are to make training divisions a little less manual (as one has to very often shift fleets around in commands to give training ships shore leave... and it gets a touch micromanagey after a while)

+1, this would make exploration vessel automation that much easier too
Title: Re: C# Suggestions
Post by: Barkhorn on September 28, 2020, 09:17:41 PM
Suggestion: A new module that works like the science department or CIC, which can be staffed by a ground unit commander, and can act as the highest level hq for a ground formation.  Eisenhower didn't go ashore in the first wave on D-Day after all, but that's what happens in Aurora.
Title: Re: C# Suggestions
Post by: xenoscepter on September 28, 2020, 09:25:51 PM
Suggestion: A new module that works like the science department or CIC, which can be staffed by a ground unit commander, and can act as the highest level hq for a ground formation.  Eisenhower didn't go ashore in the first wave on D-Day after all, but that's what happens in Aurora.

 - I took at stab at this same idea, here: http://aurora2.pentarch.org/index.php?topic=11671.0
Title: Re: C# Suggestions
Post by: Borealis4x on September 29, 2020, 01:16:31 AM
Suggestion: A new module that works like the science department or CIC, which can be staffed by a ground unit commander, and can act as the highest level hq for a ground formation.  Eisenhower didn't go ashore in the first wave on D-Day after all, but that's what happens in Aurora.

I agree. This would also be good for when you want to put all the Marines in your fleet under a unified command.
Title: Re: C# Suggestions
Post by: Migi on September 29, 2020, 04:35:57 PM
Suggestion: A new module that works like the science department or CIC, which can be staffed by a ground unit commander, and can act as the highest level hq for a ground formation.  Eisenhower didn't go ashore in the first wave on D-Day after all, but that's what happens in Aurora.
In order to work like I think you want it you would have to break the requirement for HQ's to be in the same location as the ground units in order to provide a bonus.
And if that's the case, why not have Eisenhower back on earth instead?

The flaw with your analogy is that when attacking a planet you can land literally anywhere on the planet, so all you do is locate the defenders, land your assault divisions 50 miles away, land your support divisions 100 miles away, and your rear area units 150 miles away (distances representative, not literal).
No one gets shot as soon as they get out the transport and everyone has time to get in formation for the big push.

Whereas Eisenhower was limited to a narrow strip of French coastline (unless he wanted to join the paratroopers).
Title: Re: C# Suggestions
Post by: Barkhorn on September 29, 2020, 04:52:45 PM
What makes you think anywhere is 100's of km away from defenders?  I mean sure if you're dropping on some listening post or frontier mining colony, but not if you're dropping on a homeworld.  To continue the D-Day analogy, the entire planet will be behind the Atlantic Wall.
Title: Re: C# Suggestions
Post by: Borealis4x on October 01, 2020, 01:39:16 AM
Suggestion: A new module that works like the science department or CIC, which can be staffed by a ground unit commander, and can act as the highest level hq for a ground formation.  Eisenhower didn't go ashore in the first wave on D-Day after all, but that's what happens in Aurora.
In order to work like I think you want it you would have to break the requirement for HQ's to be in the same location as the ground units in order to provide a bonus.
And if that's the case, why not have Eisenhower back on earth instead?


Realistically, cuz of communication. That limitation is somewhat modeled in the game already since you have to expand your Naval HQ for it to have a longer range, which I imagine means adding an even bigger communication array on top of the last one.

Also its just easier if the commander in charge of invading the planet is somewhere close by so they can physically meet with their commanders and have a better handle on the situation. I also think adding a 'middle layer' between forward commanders and the generals back at HQ would be interesting and create more realistic scenarios. System-wide commands are perfect to fill it.

Personally, I'd even expand on the idea and have bigger command modules be able to effect all ground forces in the entire system so a Field Marshal can lead an entire solar campaign. I'd also expand said mechanics to fleets, so that you can put multiple task forces acting independently in a system under the command of an in-system Admiral.
Title: Re: C# Suggestions
Post by: Migi on October 01, 2020, 05:09:00 PM
What makes you think anywhere is 100's of km away from defenders?  I mean sure if you're dropping on some listening post or frontier mining colony, but not if you're dropping on a homeworld.  To continue the D-Day analogy, the entire planet will be behind the Atlantic Wall.
Earth has 148 million square kilometres of land, a space assault is not landing like the marines at Normandy, it is like the gliders landing in the middle of a French farmers field except you aren't limited to light infantry and light equipment, you have navigation systems so that you don't get lost and your transports are 100% re-usable.
Title: Re: C# Suggestions
Post by: QuakeIV on October 01, 2020, 09:01:31 PM
Conversely also probably will have a pretty good idea of where you are landing so they might not have much issue contesting your attempted landing.
Title: Re: C# Suggestions
Post by: Migi on October 02, 2020, 08:24:49 AM
Conversely also probably will have a pretty good idea of where you are landing so they might not have much issue contesting your attempted landing.
In the scenario where one side has control over space and the other side has control over ground, it seems to me that the space side can fairly easily target anything moving on the surface or flying in the air. Things which are dug in are harder to pinpoint and destroy.

Therefore any movement or redeployment by the ground based side in order to contest landing sites will cause them to be exposed to potential attack from space. So although they might have a good idea of where you are landing, a sensible general would avoid exposing his or her troops.

I'm sure there are 100's of gotcha scenarios where disembarking troops can get shot at and therefore maybe Eisenhower wants to stay in orbit rather than risk getting muddy but Aurora does not model them. A whole 20kT division shows up in a single 5s increment rather than individual infantrymen getting ferried down in cargo shuttles which presumably ought to be finite, consume fuel and be target-able by AA or STO's but only the ones which can see them over the curvature of the planet in hypothetical the world where Aurora models everything down to the last minute detail.
Unless someone comes up with a proposal that is concrete, reasonably balanced (or becomes so through discussion) and interests Steve it isn't relevant because it isn't modelled.

I would like to be able to see Naval and Ground OOB linked in some way but I haven't got a proper idea of how to do it so I'm not going to waste everyone's time by making a bunch of posts about it until I do.
Title: Re: C# Suggestions
Post by: Barkhorn on October 02, 2020, 11:32:05 PM
Suggestion: make it less micro-intensive to load huge formations into troop transports.  I am currently trying to load a whole corps into troop transports.  The corps has 4 brigades.  Each brigade has 3 divisions.  Each division has 4 battalions.  For each one I have to click "Load Ground Formation", then the formation I want to load, then add move.  So that's 3 clicks per formation.  And the formation list is too long to fit in the list, so for about 3/4 of them, I have to scroll as well.  Worse yet, the formations don't all fit in the order queue, so it's very easy to lose track while I'm doing it.  There's also a gameplay problem; I have 14 transports, but I believe they only load one ground formation at a time.  My transports can hold 25000 tons, but I think the whole fleet waits while one transport loads one 5000 ton battalion at a time.

I propose two possible solutions.

EDIT: I just found the "Load subordinates" checkbox.  I'd still like to see transports in the formation window, but it's no biggie.
Title: Re: C# Suggestions
Post by: Borealis4x on October 03, 2020, 12:54:37 AM
Make Ground Unit Construction Facilities work more like regular construction facilities. They generate a set number of construction points every year that get invested into ground units. It doesn't make sense that a company takes up as many GUCFs as a brigade.
Title: Re: C# Suggestions
Post by: Droll on October 03, 2020, 06:00:04 AM
Make Ground Unit Construction Facilities work more like regular construction facilities. They generate a set number of construction points every year that get invested into ground units. It doesn't make sense that a company takes up as many GUCFs as a brigade.

+1, making ground facilities act like normal industry also means that on the UI they can be placed as a tab in the industrial construction menu. The tech already makes it so that each GUCF contributes a certain amount per cycle much like construction/ordnance/fighter factories. It would make the system much more consistent.
Title: Re: C# Suggestions
Post by: Elvin on October 03, 2020, 08:01:44 AM
Suggestion: make it less micro-intensive to load huge formations into troop transports.  I am currently trying to load a whole corps into troop transports.  The corps has 4 brigades.  Each brigade has 3 divisions.  Each division has 4 battalions.  For each one I have to click "Load Ground Formation", then the formation I want to load, then add move.  So that's 3 clicks per formation.  And the formation list is too long to fit in the list, so for about 3/4 of them, I have to scroll as well.  Worse yet, the formations don't all fit in the order queue, so it's very easy to lose track while I'm doing it.  There's also a gameplay problem; I have 14 transports, but I believe they only load one ground formation at a time.  My transports can hold 25000 tons, but I think the whole fleet waits while one transport loads one 5000 ton battalion at a time.

I propose two possible solutions.
  • 1: Make it like cargo fleets.  Fleets of freighters just all fill up somewhat intelligently.  Why can't cargo ships do that?  When issued to a fleet of mixed size, make them load the big units first, so you don't get a situation where a transport with 25000 ton capability picks up a 1000 ton boarding party that was actually meant for the boarding shuttle, and now it doesn't have room for the 25000 division.  Combine this with the ability to shift-click orders to issue them all at once to make it pretty much perfect.
  • Include transports in the formation window, and let us move formations with drag and drop, just like moving them from one population to another.

EDIT: I just found the "Load subordinates" checkbox.  I'd still like to see transports in the formation window, but it's no biggie.

There is already a checkbox to load a formation and all its subordinate formations, which should fix most of the issue. I think you have to select a formation first for it to appear. It took me a long time to spot it...
Title: Re: C# Suggestions
Post by: Vasious on October 08, 2020, 11:32:50 PM
Random suggestion

Just as occasionally jump points can be found stabilized to suggest that once along time ago there was a spacefaring civilization that stabilized it; could planets rarely be found with Aestusium or Frigusium in the atmosphere hinting at ancient Terraforming attempts?
Title: Re: C# Suggestions
Post by: QuakeIV on October 08, 2020, 11:38:40 PM
Bonus points if the gas is moving an extreme planet towards a less extreme temperature.  Maybe throw in some ruins as well.
Title: Re: C# Suggestions
Post by: Droll on October 09, 2020, 11:05:45 AM
Allow infinite production cycles on the construction menu for all types of factories.

Would allow me to set a base rate of missile production and use the %industry in order to throttle it as needed.
Would allow me to constantly build additional infrastructure without having to return to it and change its production value.
Would allow me to set a rate of construction factory expansion without having to come back to the value.

The production order only stops when the player cancels it and makes it stop. Ofc it might also stall due to resource concerns.
Title: Re: C# Suggestions
Post by: Froggiest1982 on October 10, 2020, 07:59:26 PM
Make Ground Unit Construction Facilities work more like regular construction facilities. They generate a set number of construction points every year that get invested into ground units. It doesn't make sense that a company takes up as many GUCFs as a brigade.

+1, making ground facilities act like normal industry also means that on the UI they can be placed as a tab in the industrial construction menu. The tech already makes it so that each GUCF contributes a certain amount per cycle much like construction/ordnance/fighter factories. It would make the system much more consistent.

I think the difference is that current way allows you to rename units while producing or before working in a way similar to the shipyard tab. I guess that could be integrated eventually.

The number of factories then also act as tge slipways do in the shipyard allowing multiple units to be trained at same time, something probably not possible with the production mechanic and I would rather not lose.
Title: Re: C# Suggestions
Post by: Droll on October 11, 2020, 10:46:46 AM
The number of factories then also act as tge slipways do in the shipyard allowing multiple units to be trained at same time, something probably not possible with the production mechanic and I would rather not lose.

You do not fully lose this ability with the normal construction process thanks to you being able to adjust production %. You could potentially be building 100 divisions in parallel with this. Granted with the current system you could potentially go more than that but I don't know how many people go over that.
Title: Re: C# Suggestions
Post by: Froggiest1982 on October 11, 2020, 01:48:04 PM
The number of factories then also act as tge slipways do in the shipyard allowing multiple units to be trained at same time, something probably not possible with the production mechanic and I would rather not lose.

You do not fully lose this ability with the normal construction process thanks to you being able to adjust production %. You could potentially be building 100 divisions in parallel with this. Granted with the current system you could potentially go more than that but I don't know how many people go over that.

You kinda do as they all operate at 100% while with your suggestion they do not.
Title: Re: C# Suggestions
Post by: Droll on October 11, 2020, 03:27:48 PM
The number of factories then also act as tge slipways do in the shipyard allowing multiple units to be trained at same time, something probably not possible with the production mechanic and I would rather not lose.

You do not fully lose this ability with the normal construction process thanks to you being able to adjust production %. You could potentially be building 100 divisions in parallel with this. Granted with the current system you could potentially go more than that but I don't know how many people go over that.

You kinda do as they all operate at 100% while with your suggestion they do not.

You forget that with ground force facilities each unit can be produced at the max rate of 1 facility whereas in the construction menu the industrial capacity is aggregate.

1% of 200 facilities is still going to produce each of those 100 formations at double the rate that 1 facility at 100% will.
Title: Re: C# Suggestions
Post by: Barkhorn on October 11, 2020, 03:34:41 PM
Suggestion: Some kind of ELINT facility so I can drop listening posts in enemy territory and spy long-term.  This would be historically accurate, the Germans in WW2 had a listening post hidden on the east coast of Canada.
Title: Re: C# Suggestions
Post by: Froggiest1982 on October 11, 2020, 03:44:16 PM
The number of factories then also act as tge slipways do in the shipyard allowing multiple units to be trained at same time, something probably not possible with the production mechanic and I would rather not lose.

You do not fully lose this ability with the normal construction process thanks to you being able to adjust production %. You could potentially be building 100 divisions in parallel with this. Granted with the current system you could potentially go more than that but I don't know how many people go over that.

You kinda do as they all operate at 100% while with your suggestion they do not.

You forget that with ground force facilities each unit can be produced at the max rate of 1 facility whereas in the construction menu the industrial capacity is aggregate.

1% of 200 facilities is still going to produce each of those 100 formations at double the rate that 1 facility at 100% will.

true
Title: Re: C# Suggestions
Post by: xenoscepter on October 11, 2020, 06:13:31 PM
 - Why not just make the Ground Forces Construction Facilities use the aggregate model?
Title: Re: C# Suggestions
Post by: Kev on October 13, 2020, 12:22:22 AM
It would be nice if some windows (e. g.  Event Log) were sizeable.

Also zoom to mouse cursor would be an awesome feature.
Title: Re: C# Suggestions
Post by: Llamageddon on October 14, 2020, 11:04:40 AM
Is this the thread to add suggestions that are small enough not to warrant their own post or will it likely not get looked at here?

Either way; it would be great if the diplomacy screen told you what an NPR had last broadcast as the proection status of their system as well as what you have set it to for them. Unless I am missing something obvious I can only see this by searching through the events log. Not huge deal, but would be a small QOL improvement and make the diplomacy screen more dynamic.
Title: Re: C# Suggestions
Post by: Garfunkel on October 14, 2020, 11:09:40 AM
Is this the thread to add suggestions that are small enough not to warrant their own post or will it likely not get looked at here?

Either way; it would be great if the diplomacy screen told you what an NPR had last broadcast as the proection status of their system as well as what you have set it to for them. Unless I am missing something obvious I can only see this by searching through the events log. Not huge deal, but would be a small QOL improvement and make the diplomacy screen more dynamic.
This is the right thread and that is an excellent suggestion.
Title: Re: C# Suggestions
Post by: Droll on October 14, 2020, 07:01:29 PM
Is this the thread to add suggestions that are small enough not to warrant their own post or will it likely not get looked at here?

Either way; it would be great if the diplomacy screen told you what an NPR had last broadcast as the proection status of their system as well as what you have set it to for them. Unless I am missing something obvious I can only see this by searching through the events log. Not huge deal, but would be a small QOL improvement and make the diplomacy screen more dynamic.

The galactic map has a checkbox under display that says "security status". I have no idea if this does what you wan't and I've never used it myself but its the closest thing that might work.
Title: Re: C# Suggestions
Post by: StarshipCactus on October 15, 2020, 06:58:56 AM
Can multiple NPRs of the same race spawn on the same planet? If you were just playing a normal game and exploring the galaxy, would you be able to find the equivalent of insect USA and insect USSR on some swamp planet, orbiting a red dwarf and flying round in space pretending to be from somebodies cold-war-in-space fiction?

If not, that would be really awesome. You could even have more than two factions, you could spawn 4 or 5, with alliances and enemies, so if two factions go to war, others might join in to help friends, or to even out the balance of power to ensure no power bloc wins and becomes too powerful.

Imagine how cool it would be if you were playing a multi faction game on Earth and you run into an NPR with multiple factions. Some Earth factions have similar RP-ed ideologies and want to try team up with certain NPR factions, so other player factions start to panic at this one player faction allying with an NPR and growing too powerful, so they try make alliances or launch a preemptive strike, which brings in some of the previously neutral NPR factions looking for some improvement to their lot on the galactic stage. If the NPR and the player factions all had several colonies that were quite spread out and lots of fleets, it could get quite messy. :)
Title: Re: C# Suggestions
Post by: Droll on October 15, 2020, 07:04:17 AM
Can multiple NPRs of the same race spawn on the same planet? If you were just playing a normal game and exploring the galaxy, would you be able to find the equivalent of insect USA and insect USSR on some swamp planet, orbiting a red dwarf and flying round in space pretending to be from somebodies cold-war-in-space fiction?

If not, that would be really awesome. You could even have more than two factions, you could spawn 4 or 5, with alliances and enemies, so if two factions go to war, others might join in to help friends, or to even out the balance of power to ensure no power bloc wins and becomes too powerful.

Imagine how cool it would be if you were playing a multi faction game on Earth and you run into an NPR with multiple factions. Some Earth factions have similar RP-ed ideologies and want to try team up with certain NPR factions, so other player factions start to panic at this one player faction allying with an NPR and growing too powerful, so they try make alliances or launch a preemptive strike, which brings in some of the previously neutral NPR factions looking for some improvement to their lot on the galactic stage. If the NPR and the player factions all had several colonies that were quite spread out and lots of fleets, it could get quite messy. :)

Although not same race I have randomly encountered multi-race planets. In my case it was a planet that had two alien species on it. They seemed friendly with each other.
Title: Re: C# Suggestions
Post by: Llamageddon on October 15, 2020, 11:23:02 AM
The galactic map has a checkbox under display that says "security status". I have no idea if this does what you wan't and I've never used it myself but its the closest thing that might work.

I was just looking at that, I wasn't sure if that meant I would automatically use that security status demand on them or if it just made a note of it for me. If the latter, I suppose it helps to make a note for myself, if I remember to check. If it added a text note next to the system icon on the map that would be even better. Ideally the diplomacy screen would show their security claim alonside mine, but I am just being choosy if the latter works well.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on October 15, 2020, 11:27:49 AM
Pretty sure the security status checkbox is related to civilian shipping.

Civilians won't transit into systems that have recently had large hostile forces detected, unless you have significant local naval forces. Security status will display the hostile and friendly forces ratings that the civilians are using to decide if a system is "safe."
Title: Re: C# Suggestions
Post by: Llamageddon on October 15, 2020, 11:52:18 AM
In this case there is a drop-down menu selection on the miscellaneous tab of the Galactic Map where you can set the security status from "No Protection" to "Demand Leave with Threat". I am not sure if this is purely a personal note or if it has an effect on anything. Also not sure if it is related to what I am telling the aliens or what the aliens are telling me.
Title: Re: C# Suggestions
Post by: Llamageddon on October 15, 2020, 12:23:33 PM
Just another tiny suggestion; On the Economics window it would be cool if you had a "History" tab similar to on ships, or bar that, a founding date in the summary.

* I'm editing this post because this suggestion is related. On the Wealth/Trade tab you can see you expenditure over a month, 3 month, 6 months and 1 year. It would be really helpful if you could add fuel and maintenance supply consumption, just like this, to the economics screen as well.
Title: Re: C# Suggestions
Post by: Vasious on October 15, 2020, 03:59:32 PM
Can multiple NPRs of the same race spawn on the same planet? If you were just playing a normal game and exploring the galaxy, would you be able to find the equivalent of insect USA and insect USSR on some swamp planet, orbiting a red dwarf and flying round in space pretending to be from somebodies cold-war-in-space fiction?

If not, that would be really awesome. You could even have more than two factions, you could spawn 4 or 5, with alliances and enemies, so if two factions go to war, others might join in to help friends, or to even out the balance of power to ensure no power bloc wins and becomes too powerful.

Imagine how cool it would be if you were playing a multi faction game on Earth and you run into an NPR with multiple factions. Some Earth factions have similar RP-ed ideologies and want to try team up with certain NPR factions, so other player factions start to panic at this one player faction allying with an NPR and growing too powerful, so they try make alliances or launch a preemptive strike, which brings in some of the previously neutral NPR factions looking for some improvement to their lot on the galactic stage. If the NPR and the player factions all had several colonies that were quite spread out and lots of fleets, it could get quite messy. :)

I believe there is a small chance of this happening for 2 powers on the same world and a even small change for 3 powers to be created.


Title: Re: C# Suggestions
Post by: LoSboccacc on October 16, 2020, 04:03:28 PM
standing orders: explore jump point

standing order: load surplus minerals (load from any colony with resources above reserve)

standing order: restock minerals (unload to colony based on reserve shortages)

order conditions: fuel 60% (to have some margin, fleet keep running out couple million km from earth)

normal order: load mineral as needed for other colonies (select a colony, picks minerals that are in negative projected value)


Title: Re: C# Suggestions
Post by: Llamageddon on October 16, 2020, 07:08:13 PM
Make the ship history window start at the top of the list (latest entry) rather than the bottom.
Title: Re: C# Suggestions
Post by: Droll on October 17, 2020, 03:37:05 PM
Continuous shipyard capacity expansion but for slipways.
Title: Re: C# Suggestions
Post by: Droll on October 17, 2020, 05:39:04 PM
Auto governor assignment is useless to me right now because it will repeatedly reassign my commandants to a colony, forcing me to constantly micromanage the commandants themselves.

Can auto governors be changed so that they don't mess with already assigned governors and instead pick an already unassigned one?
Title: Re: C# Suggestions
Post by: arty on October 18, 2020, 03:07:43 AM

a order for troop transports  load all troops would be nice :)
Title: Re: C# Suggestions
Post by: Garfunkel on October 18, 2020, 08:40:17 AM

a order for troop transports  load all troops would be nice :)
You can load entire formations by loading "HQ and all subordinate units" which helps a lot.
Title: Re: C# Suggestions
Post by: arty on October 18, 2020, 09:07:00 AM
yes i know but it would be nice to load a xeno and constrution  units in one go
Title: Re: C# Suggestions
Post by: Droll on October 18, 2020, 10:38:24 AM
yes i know but it would be nice to load a xeno and constrution  units in one go

Organize all your xeno and construction formations under a superior formation then use the checkbox to load all of them.
Title: Re: C# Suggestions
Post by: Garfunkel on October 20, 2020, 01:01:19 PM
You should have them under HQ's any way to get commander bonuses.
Title: Re: C# Suggestions
Post by: swarm_sadist on October 20, 2020, 06:02:15 PM
The ability to "Mute" certain interrupts, either for a certain amount of turns, game time or RL time. I am currently facing interrupts of: "Enemy forces on [Location] have been defeated but the population refuses to surrender." every production cycle and it is very annoying.
Title: Re: C# Suggestions
Post by: Froggiest1982 on October 20, 2020, 07:03:13 PM
The ability to "Mute" certain interrupts, either for a certain amount of turns, game time or RL time. I am currently facing interrupts of: "Enemy forces on [Location] have been defeated but the population refuses to surrender." every production cycle and it is very annoying.

there is a mod for it atm.

yes i know but it would be nice to load a xeno and constrution  units in one go

Organize all your xeno and construction formations under a superior formation then use the checkbox to load all of them.

I always have the "Transport Company HQ" formation and unit just for this purpose.

It is cheap and also will let you move formations freely later on for replacements and stuff.

That was done because we did not have replacement options before 1.12
Title: Re: C# Suggestions
Post by: Llamageddon on October 21, 2020, 10:43:17 AM
Just checking I understand correctly. Making formation templates that are just an HQ with enough capacity to cover a set ammount of subordinate formations is standard procedure? I.e. a regiment HQ with capacity 5000 to command 5 small brigades of size 1000. These subordinate formations can still benefit from having their own HQ embedded so they can have a junior commanding officer lower in the order of battle heirarchy?
Title: Re: C# Suggestions
Post by: Droll on October 21, 2020, 10:53:02 AM
Just checking I understand correctly. Making formation templates that are just an HQ with enough capacity to cover a set ammount of subordinate formations is standard procedure? I.e. a regiment HQ with capacity 5000 to command 5 small brigades of size 1000. These subordinate formations can still benefit from having their own HQ embedded so they can have a junior commanding officer lower in the order of battle heirarchy?

Exactly, so you have lets say your colonel commanding the regiment itself and then in the HQs inside each brigade you have a major in command. That way your fighting formations in addition to getting the full bonuses of their commanding Majors will get a fraction of the bonuses of their colonel stacked on top of that.
Title: Re: C# Suggestions
Post by: Witty on October 21, 2020, 03:57:47 PM
I noticed one of my ground officers was assigned to a unit I did not produce. It appears to actually be a ground unit owned by one of my civilian mining companies. Presumably the unit is stationed on the mining comet as some base security. However, I cannot see or have any access of this unit (as far as I can tell) outside of this indirect confirmation through my officers.

It would be nice if civilian ground units were listed in the formation menu, as civilian ships are.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on October 21, 2020, 04:06:02 PM
Just checking I understand correctly. Making formation templates that are just an HQ with enough capacity to cover a set ammount of subordinate formations is standard procedure? I.e. a regiment HQ with capacity 5000 to command 5 small brigades of size 1000. These subordinate formations can still benefit from having their own HQ embedded so they can have a junior commanding officer lower in the order of battle heirarchy?

Exactly, so you have lets say your colonel commanding the regiment itself and then in the HQs inside each brigade you have a major in command. That way your fighting formations in addition to getting the full bonuses of their commanding Majors will get a fraction of the bonuses of their colonel stacked on top of that.

FWIW, this does not actually work right now. It was reported in 1.11 that ground combat command bonuses don't properly flow down the hierarchy, and a fix is not listed in the change log for 1.12
Title: Re: C# Suggestions
Post by: QuakeIV on October 24, 2020, 05:11:17 PM
When deleting some things, the confirmation window will display the name of this thing about to be deleted when asking for confirmation.

I would suggest that this be applied to the 'Delete Race' button on the race information window as well.
Title: Re: C# Suggestions
Post by: QuakeIV on October 24, 2020, 10:40:32 PM
Additionally:

It would be kindof nice if EM and Thermal sensors were both categorized under 'Passive sensors' instead of getting their own categories (in my opinion).
Title: Re: C# Suggestions
Post by: Black on October 25, 2020, 03:10:22 PM
When alien ship is captured, it is completely removed from Known Ships Classes list of Known Ships. Destroyed ships stay on the list with Destroyed status. Would it be possible to do something similar for captured ships with status - Captured?
Title: Re: C# Suggestions
Post by: Froggiest1982 on October 25, 2020, 04:29:35 PM
I noticed one of my ground officers was assigned to a unit I did not produce. It appears to actually be a ground unit owned by one of my civilian mining companies. Presumably the unit is stationed on the mining comet as some base security. However, I cannot see or have any access of this unit (as far as I can tell) outside of this indirect confirmation through my officers.

It would be nice if civilian ground units were listed in the formation menu, as civilian ships are.

Under Ground Forces Tab, tick Show Civilian on top.

You will get Civilian Forces listed in the OOB.
Title: Re: C# Suggestions
Post by: Ektor on October 29, 2020, 02:34:00 PM
Could we get a separate message when an administrator or admin commander leaves duty? I usually don't bother reading the reports of who retired because given the several tens of officers I usually have, there's always some random person retiring, but it's actually super important to admin commands since for some reason there's no auto assign for them. Auto assign for admin command would be great, as well.

Also, another thing I've thought about, the "load minerals until full" order has been added which is an absolute lifesaver and I'm really glad it got added, but there should be a similar order for refuelling. "Refuel from hub until full." Why? So we could set transport tankers parked on fuel harvesters that would function the same way as mineral transporters.
Title: Re: C# Suggestions
Post by: Froggiest1982 on October 29, 2020, 03:33:40 PM
Auto assign for admin command would be great, as well

While I understand why many people ask for this and as said all other times it popped up, I am against that as it could lead to confusion assigning officers not suitable for the task. I think a solution similar to the colony governors that it's optional would be better.

Polemic Note
Off-Topic: show
However, on this last point, something that I pointed out it's already happening. People are complaining because the auto assignment is not behaving as they want. This is the problem with automation: it's automatic. If you want control it's called manual.
Title: Re: C# Suggestions
Post by: Ektor on October 29, 2020, 04:21:52 PM
I'm rather satisfied with colony auto-assign, actually. I'd love a similar feature for admin commands.
Title: Re: C# Suggestions
Post by: Droll on October 30, 2020, 03:54:22 PM
I'm going to repeat one of my older suggestions:

The ability to create hierarchy templates for ground construction so that if I make a very detailed OOB for a single division I don't have to take the time every time I want to expand my army.

I ask because I like to make my hierarchy go down to company level and it takes a long time to form a divisional hierarchy even if you know what you are doing.
Title: Re: C# Suggestions
Post by: Droll on October 31, 2020, 05:03:58 PM
Double clicking on a terraforming related event should open up the environment tab of the relevant body.
Title: Re: C# Suggestions
Post by: nuclearslurpee on October 31, 2020, 06:53:52 PM
Quote from: Droll link=topic=10640. msg142452#msg142452 date=1604091262
I'm going to repeat one of my older suggestions:

The ability to create hierarchy templates for ground construction so that if I make a very detailed OOB for a single division I don't have to take the time every time I want to expand my army.

I ask because I like to make my hierarchy go down to company level and it takes a long time to form a divisional hierarchy even if you know what you are doing.
Seconded.

Piggyback: it would be nice to be able to set ground formations to a default field position (front/support/rear) in the formations window instead of manually setting every formation after construction.  If I have a battalion full of static heavy bombardment, I think it's safe to say that I'm not going to be putting any of those in the front line and it would be nice to have that reflected at build time, not post-deployment.
Title: Re: C# Suggestions
Post by: SerBeardian on October 31, 2020, 09:41:18 PM
I would suggest that the "you can't change a locked design" error happen after you try and actually change a locked design.

It is so incredibly annoying to try and take a look at a component on a design and have it throw you an error, and then you have to go looking for the component in the component list instead. And good luck if that component is obsolete, because then you have to look through all your obsolete components to find this one thing... It's just so much easier to just find the ship that has the component and look at it in the current design.
Title: Re: C# Suggestions
Post by: Kristover on November 01, 2020, 09:49:55 AM
Ground Combat Spam:

I got involved in my first super-extended ground campaign last night - a nice-sized multi-Division affair that lasted several months where I had technological overmatch, but they had terrain advantages, and I had to reinforce and resupply many times.  While I had noticed it previously with smaller combats, this one was simply too much with the 100+ messages per 8 hour phase and I found I started losing track of the other things I needed to do in the empire - including the space component of the conflict I was engaged due to the spam.  Here is the thing, I like the spam in some instances - it certainly gives me very useful feedback about my design choices and situation - but at some point I got the point and I don't need all of the info.

What I propose is either a better filtering mechanism that allows messages to be better filtered out of the event list - or ground combat summaries written to a separate tab on the events that DOESN'T show up in the 'display on map' function.  This I think a good compromise for those that like the granularity of the information but don't want to be assaulted by it.
Title: Re: C# Suggestions
Post by: Barkhorn on November 01, 2020, 02:22:15 PM
Suggestion: Include some kind of system for salvaging wrecked ground units, to simulate capturing and using enemy equipment.  In WW2, the Germans, Russians, and Japanese made extensive use of captured weapons and vehicles.  For instance, many of the shore batteries guarding the Atlantic Wall were French guns the Germans had captured.

Imagine having dropships dash past the orbital defenses to capture STOs and turn them on their former owners.
Title: Re: C# Suggestions
Post by: SerBeardian on November 01, 2020, 04:11:26 PM
This has probably been suggested in some form earlier but to help alleviate the RSI of weapon assignment:

---

1) In the firecontrol panel, group identical weapon types assigned to the same firecontrol group together under a subheading.
2) Let this group be collapsible so it can be hidden way.
3) Let use use this group as a mass-assign function, by letting anything done to the group be done to the weapons within that group.

---

There are many, many benefits to this:
Got 30 launchers? No problem! Drag the group heading to the firecon, now all 30 are assigned to that firecon. Drag that missile to the group and now all 30 are loaded with that missile!
Got 30 single 10% gauss turrets on that 40kton battleship? Well they're all on your PD firecon with a single drag and drop now!
Got two launchers sitting beneath that stack of 30 other launchers? Collapse that stack and now you can assign the lower ones without needing to open a second fleet screen!
Finally, no more relying on autoassign to assign large numbers of weapons and hoping against hope that it knows what you want amongst all your mixed weapon types, because if it doesn't you're in for a loooong day of drag and dropping...
Title: Re: C# Suggestions
Post by: Droll on November 02, 2020, 07:05:11 AM
This has probably been suggested in some form earlier but to help alleviate the RSI of weapon assignment:

---

1) In the firecontrol panel, group identical weapon types assigned to the same firecontrol group together under a subheading.
2) Let this group be collapsible so it can be hidden way.
3) Let use use this group as a mass-assign function, by letting anything done to the group be done to the weapons within that group.

---

There are many, many benefits to this:
Got 30 launchers? No problem! Drag the group heading to the firecon, now all 30 are assigned to that firecon. Drag that missile to the group and now all 30 are loaded with that missile!
Got 30 single 10% gauss turrets on that 40kton battleship? Well they're all on your PD firecon with a single drag and drop now!
Got two launchers sitting beneath that stack of 30 other launchers? Collapse that stack and now you can assign the lower ones without needing to open a second fleet screen!
Finally, no more relying on autoassign to assign large numbers of weapons and hoping against hope that it knows what you want amongst all your mixed weapon types, because if it doesn't you're in for a loooong day of drag and dropping...

I think it would be better if many menus (including ground OOB) would allow for shift-clicking in order to select and drag multiple list elements. This would achieve what you want as well I think.
Title: Re: C# Suggestions
Post by: bankshot on November 02, 2020, 10:07:25 AM
The "Equalize Fuel" order was removed as fuel transfer now requires a refueling system/hub and time to transfer fuel.  I would like to see it re-enabled for fleets that consist entirely of ships that are tankers (re: that have a refueling system or hub).  It should be subject to the normal time/movement speed constraints of standard refueling.

I normally use slow but not immobile Fuel Harvester/tankers with orders to transfer and return with minimum fuel reserve set to 5%.  When adding new ships to the harvesting fleet I have to manually partially refuel them to balance their tanks with the existing fleet or send a delivery tanker to empty the other harvesters. 

Also when you issue the "refuel from stationary tankers" command it pulls fuel from the target fleet in sequence, so your first few tankers get drained down to 5% before later tankers get touched.  This is good if you are delivering fuel with mobile tankers which could then be detached to be refilled, but is not desirable if your tankers are also harvesters.  So I have to send my delivery tanker back to get that last partial load to equalize all of the harvesters at empty. 

You could also consider changing the "refuel from stationary tankers" order to preferentially pull from the most full tankers so that each fuel draw would move the tankers towards equality, but that is probably a more complex code change and less useful overall. 
Title: Re: C# Suggestions
Post by: Platys51 on November 02, 2020, 11:26:26 AM
Suggestion: Empty military formations and reinforcements

In my current campaign, I'm making 320kt construction companies.  1000 medium construction vehicles and HQ to control them.
Inevitably, I have ran into issues related to big military formations.  It would take decades to make single one of these in one facility.

And so, I made HQ formation and 100 vehicles in a second one.  Then I add all these manually into HQ formation until 1000 units is reached.

My suggestion is simple.  Give us ability to make formation that is empty or incomplete, with replacement template of whole formation.  Then, on every building cycle check for formations tagged as use for replacements and fill out the empty spots.

If we could tag formations as for replacement as we design them that would be ideal.

This change would mainly help with making and use of larger formations.
Title: Re: C# Suggestions
Post by: QuakeIV on November 02, 2020, 10:24:13 PM
I'd kindof prefer if ground training just worked like factories and you could have multiple facilities working the same job.
Title: Re: C# Suggestions
Post by: Malorn on November 02, 2020, 11:30:56 PM
I'd kindof prefer if ground training just worked like factories and you could have multiple facilities working the same job.

Yeah, ground forces are really awesome, but they are a bit cumbersome currently.
Title: Re: C# Suggestions
Post by: Droll on November 03, 2020, 01:12:29 PM
I'd kindof prefer if ground training just worked like factories and you could have multiple facilities working the same job.

This is actually essential if you want to make STO formations of any substance. You can have 1000 GU facilities and a single STO battery will still take decades to train
Title: Re: C# Suggestions
Post by: Black on November 03, 2020, 01:50:16 PM
I basically gave up on STOs, they just took too long to train.
Title: Re: C# Suggestions
Post by: Ektor on November 05, 2020, 05:30:02 PM
Could we please get another conditional order slot, or a "refuel and ressuply" order? There's already a "refuel, resupply and overhaul" order but it doesn't work, being able to refuel/resupply at different moments through either a third slot or a specific conditional order would be so, so very useful.
Title: Re: C# Suggestions
Post by: Froggiest1982 on November 06, 2020, 03:47:20 AM
Could we please get another conditional order slot, or a "refuel and ressuply" order? There's already a "refuel, resupply and overhaul" order but it doesn't work, being able to refuel/resupply at different moments through either a third slot or a specific conditional order would be so, so very useful.

Massive UI work. It is easier to get the error fixed. I have personally found a workaround (although the error still triggers) to keep all ships going without managing them.

I am sure Steve that is playing the game have either fixed it or about to do it.
Title: Re: C# Suggestions
Post by: Cobaia on November 06, 2020, 04:53:43 AM

Could we please get another conditional order slot, or a "refuel and ressuply" order? There's already a "refuel, resupply and overhaul" order but it doesn't work, being able to refuel/resupply at different moments through either a third slot or a specific conditional order would be so, so very useful.

Massive UI work. It is easier to get the error fixed. I have personally found a workaround (although the error still triggers) to keep all ships going without managing them.

I am sure Steve that is playing the game have either fixed it or about to do it.

What workaround?
Title: Re: C# Suggestions
Post by: Froggiest1982 on November 06, 2020, 06:49:42 AM

Could we please get another conditional order slot, or a "refuel and ressuply" order? There's already a "refuel, resupply and overhaul" order but it doesn't work, being able to refuel/resupply at different moments through either a third slot or a specific conditional order would be so, so very useful.

Massive UI work. It is easier to get the error fixed. I have personally found a workaround (although the error still triggers) to keep all ships going without managing them.

I am sure Steve that is playing the game have either fixed it or about to do it.

What workaround?

The conditional order Fuel less than 50% (my standard), Refuel Resupply and Overhaul at Colony  it doesn't trigger any error, so I just use this in combination with the Deployment exceeded. So ship will overhaul only at deployment exceeded but not refuel running the full process when running out of Fuel.

You'll get the function error but that's all. I am honestly not looking after my exploration at all currently unless something shows up on radar.

Sure sometimes I still like to jump in, be careful etc, but when you have 50 plus ships exploring and surveying you could become tired of the process quite fast.
Title: Re: C# Suggestions
Post by: chrislocke2000 on November 06, 2020, 08:38:43 AM
A small quality of Life point. It would be great if the system tracked which names have been used in any naming convention list such that if you want to use the same naming convention such as RN Destroyers across a range of designs or on subsequent updates to designs then the suggested name recognises this rather than going back to the start of the list.

Similarly if you have ships destroyed making the names available again would be great.

Title: Re: C# Suggestions
Post by: TheTalkingMeowth on November 06, 2020, 09:42:50 AM
A small quality of Life point. It would be great if the system tracked which names have been used in any naming convention list such that if you want to use the same naming convention such as RN Destroyers across a range of designs or on subsequent updates to designs then the suggested name recognises this rather than going back to the start of the list.

Similarly if you have ships destroyed making the names available again would be great.


Does it...not already do this?

I routinely have multiple classes sharing the same name list, and no name collisions.
Title: Re: C# Suggestions
Post by: Ektor on November 06, 2020, 11:36:22 AM
The conditional order Fuel less than 50% (my standard), Refuel Resupply and Overhaul at Colony  it doesn't trigger any error, so I just use this in combination with the Deployment exceeded. So ship will overhaul only at deployment exceeded but not refuel running the full process when running out of Fuel.

You'll get the function error but that's all. I am honestly not looking after my exploration at all currently unless something shows up on radar.

Sure sometimes I still like to jump in, be careful etc, but when you have 50 plus ships exploring and surveying you could become tired of the process quite fast.

Let's see if I understand it correctly, the Refuel, Resupply and Overhaul order works for you if you set it associated with fuel levels? I had set it at Deploymen Exceeded - Refuel, Resupply and Overhaul. But it returns an error and makes my ships not refuel and resupply. Can you get them to both survey automatically, overhal and refuel/resupply that way?
Title: Re: C# Suggestions
Post by: Erik L on November 06, 2020, 11:41:42 AM
It would be nice if officers that are not the best qualified for a slot still get put into a slot rather than sitting around picking their orifices, i.e. an officer of sufficient rank, but no skills is left unassigned when there are available slots. He should be put into one.

As an adjunct to that, let the officers get some OJT. If they are in a slot with no skill relative to that job, eventually they will learn something about it. Hopefully.
Title: Re: C# Suggestions
Post by: db48x on November 06, 2020, 11:44:24 AM
It would be nice if officers that are not the best qualified for a slot still get put into a slot rather than sitting around picking their orifices, i.e. an officer of sufficient rank, but no skills is left unassigned when there are available slots. He should be put into one.

As an adjunct to that, let the officers get some OJT. If they are in a slot with no skill relative to that job, eventually they will learn something about it. Hopefully.

All assigned officers should have a double chance of gaining political skill ;)
Title: Re: C# Suggestions
Post by: Erik L on November 06, 2020, 08:39:58 PM
Something in the ship display to show how much free cargo space is left.

A way to change sector colors. Usetowas there was a way.
Title: Re: C# Suggestions
Post by: Froggiest1982 on November 07, 2020, 02:59:03 AM
The conditional order Fuel less than 50% (my standard), Refuel Resupply and Overhaul at Colony  it doesn't trigger any error, so I just use this in combination with the Deployment exceeded. So ship will overhaul only at deployment exceeded but not refuel running the full process when running out of Fuel.

You'll get the function error but that's all. I am honestly not looking after my exploration at all currently unless something shows up on radar.

Sure sometimes I still like to jump in, be careful etc, but when you have 50 plus ships exploring and surveying you could become tired of the process quite fast.

Let's see if I understand it correctly, the Refuel, Resupply and Overhaul order works for you if you set it associated with fuel levels? I had set it at Deploymen Exceeded - Refuel, Resupply and Overhaul. But it returns an error and makes my ships not refuel and resupply. Can you get them to both survey automatically, overhal and refuel/resupply that way?

Yes it doesn't trigger any error on the refuel. So you have the ship coming back for exceeded deployment to resupply refuel and overhaul triggering the error and overhaul only, then as soon as fuel will be under 50% it will come back (or never leave if fuel is already below lebels) and have overhaul, refuel and resupply correctly.

So except for u clicking through the errors when triggered there isnt anything else required.
Title: Re: C# Suggestions
Post by: Erik L on November 07, 2020, 07:05:37 PM
When using the "Survey x/Move to system requiring x survey", it would be nice if it did not double up on fleets. If a fleet is actively surveying said system, the next fleet to encounter that sequence of standing orders should go on to the next system.
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 07, 2020, 07:14:39 PM
The ability to reorder ground unit series would be immensely helpful for keeping things organized across multiple generations of ground units with evolving technology and doctrines.
Title: Re: C# Suggestions
Post by: Alrune on November 08, 2020, 06:20:46 AM
standing order: Move to System Requiring Gravsurvey or Geosurvey to go with the Survey next three system bodies or locations that was added
Title: Re: C# Suggestions
Post by: rtyler on November 08, 2020, 09:35:20 AM
Officers should be able to not only improve their current skills, but develop new ones if placed in a ship that need it.  IE.  If i dont have any officers with survey, but i assign someone to a DSS ship, they should eventually learn a thing or two about how survey works.
Title: Re: C# Suggestions
Post by: Garfunkel on November 08, 2020, 01:27:04 PM
Officers should be able to not only improve their current skills, but develop new ones if placed in a ship that need it.  IE.  If i dont have any officers with survey, but i assign someone to a DSS ship, they should eventually learn a thing or two about how survey works.
Administrators certainly pick up new skills - I thought naval officers also did?
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on November 08, 2020, 05:27:11 PM
They do. The precise example given (learn to survey) happens all the time. I have a bunch of 1% survey skill officers now. It is very amusing.
Title: Re: C# Suggestions
Post by: Froggiest1982 on November 08, 2020, 09:57:06 PM
Abilitate Delete key to work as a delete button. Very handy while canceling many fleets and reorganizing your admin commands.

Collapse all and regroup all button

Title: Re: C# Suggestions
Post by: Aloriel on November 09, 2020, 01:24:17 PM
I would love to see a line chart on the Empire Minerals tab of the economy window that depicts your stockpile of the various minerals. With such a line chart, we could see the trend of our mineral production and do something about it before we get to critical levels.

Options for the chart:
Ability to depict stockpile levels of each mineral individually
Ability to display data accrued over the last month, year, 5 years, and 10 years with data points every 5 days, weekly, monthly, and quarterly (respectively), or allow these choices of data points to be adjustable
Ability to choose an individual planet's stockpile to display as well as the entire empire's stockpiles

One additional advantage for this chart is that there is a ton of space on the Empire Minerals tab just begging for a chart. :)


Rationale:
As it stands right now, you only see the stockpile change over the past 5 days. However, you can't see the spikes you might be getting (up or down) that actually create a trend. For example, I could be running a deficit on Corundium, but can't see the 25,000 that a freighter is carrying to Earth and suddenly dumps it. It would appear that I am losing Corundium, but in fact, I am gaining because the freighter has more in it than the losses add up to. The same can happen on a downward trend, where you happen to look just after a mass driver delivery, but you missed the two negative days between that add up to a greater decline than the delivery.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on November 09, 2020, 02:59:33 PM
I would love to see a line chart on the Empire Minerals tab of the economy window that depicts your stockpile of the various minerals. With such a line chart, we could see the trend of our mineral production and do something about it before we get to critical levels.

Options for the chart:
Ability to depict stockpile levels of each mineral individually
Ability to display data accrued over the last month, year, 5 years, and 10 years with data points every 5 days, weekly, monthly, and quarterly (respectively), or allow these choices of data points to be adjustable
Ability to choose an individual planet's stockpile to display as well as the entire empire's stockpiles

One additional advantage for this chart is that there is a ton of space on the Empire Minerals tab just begging for a chart. :)


Rationale:
As it stands right now, you only see the stockpile change over the past 5 days. However, you can't see the spikes you might be getting (up or down) that actually create a trend. For example, I could be running a deficit on Corundium, but can't see the 25,000 that a freighter is carrying to Earth and suddenly dumps it. It would appear that I am losing Corundium, but in fact, I am gaining because the freighter has more in it than the losses add up to. The same can happen on a downward trend, where you happen to look just after a mass driver delivery, but you missed the two negative days between that add up to a greater decline than the delivery.

Related: it would be nice if the empire stockpile looked only at production and consumption for showing the change. As it stands, it appears to just look at the total minerals on all colonies and look at the delta. If the delta instead was "minerals produced in past cycle-minerals consumed in past cycle" it would be far more useful, since right now the data gets distorted by mass drivers and freighters moving minerals around. And really, what I need to know is: did I produce more than I consumed?
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 11, 2020, 05:27:31 PM
When commander auto-assign is unchecked, it would be nice if commander "auto-unassign" was also turned off. It's annoying in the early game when you don't have enough skilled officers to go around and need to micromanage commands, and it's annoying throughout the game when dealing with specialized roles (survey, etc.)
Title: Re: C# Suggestions
Post by: Tavik Toth on November 12, 2020, 07:16:12 PM
Hm, not sure if someone's asked this before, but how practical would it be to add a aircraft type to the ground forces designs to represent VTOLs and the like?
Title: Re: C# Suggestions
Post by: Froggiest1982 on November 12, 2020, 07:55:40 PM
Hm, not sure if someone's asked this before, but how practical would it be to add a aircraft type to the ground forces designs to represent VTOLs and the like?

I honestly think would be awesome and I did ask this too.

I dont like PODs and also currently AA combat is not active. It will make easier for AI to handle that and abilitate AA on ground level will be probably easier as the mechenic will be confined in that framework without the need of moving into fleet level (ships, fighters and pods).

Fighters can fight above orbit vs other fighter and orbital bombardment will still be a thing countered by STO.
Title: Re: C# Suggestions
Post by: Garfunkel on November 13, 2020, 11:10:09 AM
There is nothing in the game that says what each vehicle category is, just their general weight and size which prohibits how much armour they can carry and what weapons can fit into them. Whether it's rolling on wheels, chugging on tracks, flying on jets, walking on hydraulic legs, or even hovering thanks to anti-gravity plate, is all up to the player and their imagination and the story they are telling.

The ground combat model only understands the concept of the front line, support area and rear area because it supports both a handful of space marines shooting it out on a tiny asteroid as well as fifty million soul strong combined arms army group pulverizing a Super-Earth planet.

Which means that there is no point in determining whether a specific unit walks or swims or flies. All vehicles can achieve breakthrough already - whether that means German tanks driving through the Ardennes forest or American helicopters flying over Vietnamese jungle is mechanically meaningless. There already is a weapon that can reach enemy Rear Area and multiple weapons that can reach Support Area.

Time-wise, it would be much better for Steve to fix planetary support fighters, AAA and STO, as well as give NPR/spoilers the ability to use them.

Of course, if you can come up with a new, novel mechanic that adds to the ground combat model, then, by all means, do write it all down - but adding planes as a ground unit alone is a waste of time. Not to mention that you would have to make all sorts of exceptions to it to explain how helicopters/aeroplanes can operate on airless rocks in space as well as Venusian planets.
Title: Re: C# Suggestions
Post by: xenoscepter on November 13, 2020, 11:51:07 AM
There is nothing in the game that says what each vehicle category is, just their general weight and size which prohibits how much armour they can carry and what weapons can fit into them. Whether it's rolling on wheels, chugging on tracks, flying on jets, walking on hydraulic legs, or even hovering thanks to anti-gravity plate, is all up to the player and their imagination and the story they are telling.

The ground combat model only understands the concept of the front line, support area and rear area because it supports both a handful of space marines shooting it out on a tiny asteroid as well as fifty million soul strong combined arms army group pulverizing a Super-Earth planet.

Which means that there is no point in determining whether a specific unit walks or swims or flies. All vehicles can achieve breakthrough already - whether that means German tanks driving through the Ardennes forest or American helicopters flying over Vietnamese jungle is mechanically meaningless. There already is a weapon that can reach enemy Rear Area and multiple weapons that can reach Support Area.

Time-wise, it would be much better for Steve to fix planetary support fighters, AAA and STO, as well as give NPR/spoilers the ability to use them.

Of course, if you can come up with a new, novel mechanic that adds to the ground combat model, then, by all means, do write it all down - but adding planes as a ground unit alone is a waste of time. Not to mention that you would have to make all sorts of exceptions to it to explain how helicopters/aeroplanes can operate on airless rocks in space as well as Venusian planets.

 - VTOLs and Heavy VTOLs could be a ground unit with better Hit Mods in exchange for having 0 Self Fortification and 0 Max Fortification. The VTOLs would have better hit mods than Light Vehicles, maybe a 0.2, but worse armor... more akin to Light Infantry, maybe a 1x or 1.25x modifier. Heavy VTOLs would have a 0.3 Hit Mod but have armor closer to Power Armored Infantry, 1.5x or 1.75x. Additionally they could use any terrain modifications except Boarding Capable, to account for things like FLIR (Jungles) and "mast mounted" RADAR (Mountains / Rift Valley) or special training to fight better in tractless lands (Desert). I say mast mounted RADAR, but the Aurora VTOLs would basically be flying with Trans-Newtonian engines like the ships.

 - The VTOLs and Heavy VTOLs couldn't mount Logistics Modules; the VTOL would have one module slot and the Heavy VTOL would have two. The Heavy VTOLs could mount Geological Survey and Xeno-Archaeology modules, but not Construction Equipment; while the regular VTOLs couldn't mount any of those. Perhaps the VTOLs could have a tech for "Improved VTOL Armor" taking the regular VTOLs armor from 1x to 1.25x and the Heavy VTOLs from 1.5x to 1.75x Just spitballing.
Title: Re: C# Suggestions
Post by: Anamori on November 13, 2020, 02:20:21 PM
Low priority, small suggestion for uncommon case:

Allow fighter/shuttle (<500t vessel) to load/unload colonist without cargo shuttle station/spaceport on targeted celestial body. We can't put cargo shuttle module (500t) inside -shuttle- but it still should be able to land on planet according to lore:

Quote
Cargo Shuttle Bays

Part of the background in C# Aurora will be that large TN ships function only in space and cannot move any closer to planetary bodies than low orbit. Small craft below a limit of 500 tons, such as fighters and shuttles, are capable of landing on planets. Ship are built in orbit and habitats are assembled in orbit. Only fighters can be built on the ground.

 My example design I was testing it with:

Code: [Select]
K-Orzel STK wz 1 class Shuttle      499 tons       11 Crew       58.3 BP       TCS 10    TH 7    EM 0
722 km/s      Armour 1-5       Shields 0-0       HTK 3      Sensors 0/0/0/0      DCR 0      PPV 0
Maint Life 8.65 Years     MSP 25    AFR 6%    IFR 0.1%    1YR 1    5YR 9    Max Repair 20 MSP
Cryogenic Berths 1 000   
Lieutenant Commander    Control Rating 1   BRG   
Intended Deployment Time: 3 months    Morale Check Required   

Improved Nuclear Pulse Engine  EP7.20 (1)    Power 7.2    Fuel Use 19.08%    Signature 7.20    Explosion 4%
Fuel Capacity 1 000 Litres    Range 1.9 billion km (30 days at full power)

This design is classed as a Fighter for production, combat and planetary interaction

It isn't important or commonly used/needed, just a little oddity that may be intentional and I accidentally noticed. Feel free to totally ignore it.
Title: Re: C# Suggestions
Post by: Garfunkel on November 14, 2020, 06:25:37 PM
An expanded version of this has already been suggested here: http://aurora2.pentarch.org/index.php?topic=11946.0

The inability of fighters to load/unload is a bug.
Title: Re: C# Suggestions
Post by: Anamori on November 15, 2020, 04:23:32 AM
An expanded version of this has already been suggested here: http://aurora2.pentarch.org/index.php?topic=11946.0

The inability of fighters to load/unload is a bug.

I posted about this problem few days before (Nov 07) at: http://aurora2.pentarch.org/index.php?topic=11545.msg142733#msg142733
Didn't noticed that attempt and nobody told me about post you linked before. Please feel free to ignore me then.
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 15, 2020, 08:23:05 PM
Suggestion for Conventional Starts:

The issue: presently in a conventional start it is not possible to build any of the following:
Obviously the solution to this is to immediately research, SM, or start with Trans-Newtonian Technology and unlock all of these things. However it would be nice to have the option of extended, meaningful play in the conventional era for RP purposes or to create a particular setup.

Suggestion: Enable EM Strength level 1, Geological Survey Sensors, and Troop Transport Modules to be researched without TN Tech. The EM Strength tech can be the existing 5-strength tech or a new (lower) conventional EM strength if preferred (the former is probably less work to implement).
Title: Re: C# Suggestions
Post by: Garfunkel on November 16, 2020, 12:48:38 PM
Or perhaps a conventional sensor that is, like conventional industry, a combination of all possibilities but way worse - so it'd be like 0.2 EM 0.2 TH 0.2 AS 0.4 Geo in a 50 HS package.

Alternatively, have conventional versions of all 4 sensors that require only wealth to build.

I would love to have a game where the first stage of interplanetary exploration (and primitive warfare) is done by fighter-sized vessels.
Title: Re: C# Suggestions
Post by: serger on November 16, 2020, 01:04:21 PM
I think it also would be very, very nice, if all conventional-tech objects will reqire no TN mineral.
I would not change ballance, still would bring much flavour to slow-start campaings.
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 16, 2020, 01:32:28 PM
Or perhaps a conventional sensor that is, like conventional industry, a combination of all possibilities but way worse - so it'd be like 0.2 EM 0.2 TH 0.2 AS 0.4 Geo in a 50 HS package.
This would be nice. However, I suspect it would require more work for Steve to add a new component type and doesn't solve the problem of lacking a MFC.

The easy solution to the active sensor/MFC problem is to have a conventional EM Strength similar to conventional engine tech which is available at the start of the game. This would enable active/MFC sensors and I think should only require two lines in the DB - the EM Strength 10 tech would not even need to be changed since it has TN Tech as a prereq.

Alternatively, have conventional versions of all 4 sensors that require only wealth to build.

I would love to have a game where the first stage of interplanetary exploration (and primitive warfare) is done by fighter-sized vessels.
You can actually build thermal and EM sensors without a problem, although EM requires active signals to detect in order to be worth having. I'm fine with grav sensors being TN tech as they're locked behind JP Theory anyways, so Geo sensors are the missing link (along with active + MFC).

Conventional warfare with these limits would be an interesting tactical situation since not only are only missiles possible to build as weapons, but there are no magazines. Thus you'd have squadrons of box launcher-armed fighters taking runs at each other and fleeing back to a base to reload (ordnance transfer systems exist, but again with no magazines are functionally useless. Hangars are also not possible). There would be an interesting dynamic between building for missile payload, sensor range, speed/evasion, and armour on the shipbuilding side as well as trade-offs of speed/range/power on the missile side as usual, so there's certainly some play there.

The other cool feature would be a requirement for physical supply lines due to lack of mass drivers, offering tempting targets for space piracy and such. One thing I hadn't realized though was that colonization requires conventional industry due to lack of TN Mines, but a good RP setup can give a reason to relocate those from Earth anyways.

I think it also would be very, very nice, if all conventional-tech objects will reqire no TN mineral.
I would not change ballance, still would bring much flavour to slow-start campaings.

Presently in a conventional start you can still mine TN minerals, but very slowly due to the limits of conventional industry versus TN Mines. I think keeping the TN material requirements is good to promote a little bit of resource management in terms of not outpacing your slow pace of stockpiling.
Title: Re: C# Suggestions
Post by: Garfunkel on November 16, 2020, 01:50:08 PM
Well, the big problem is lack of Active Sensors of course. That's what kills conventional space war. It's now possible to have conventional ground war and actually have some granularity there thanks to 3 armour levels before Duranium. With the boost to the conventional engine that Steve gave us in C# there's lot more capability with conventional engines - heck I still only use them in my 1890 campaign! - but yeah the lack AS and MFC is the killer.

In a dream world, Steve would add a Conventional Rail Gun that fires only 1 shot instead of 4 and would be half the size of 10cm RG. Then there would be a Conventional Radar or Lidar that works as AS 5 (instead of AS 10 that comes with TN tech). As well as the 100-ton cargo hold for fighter-sized freighters.

That way I could RP a multi-faction Earth start where there are 3 distinct and separate game phases:
1. Exploration and expansion while the factions are unlocking the mysteries of transnewtonian stuff - ends with the discovery of TN-tech.
2. Exploitation of the Sol system as the factions become truly interplanetary with colonies and bases all over - ends with the discovery of Jump tech.
3. Now the factions get to transform into interstellar powers and conflict moves from Sol to other systems as well as aliens.

By the time I've finished my 1890 campaign and am ready to start a new one, Steve might have had the time and inspiration to add stuff like this! Man can hope  ;D
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 16, 2020, 07:04:05 PM
Active sensors, geo sensors, and troop transport bays...that might not actually be too hard to do with a few lines of DB modding, if I ever get around to trying a similar setup I might try it and see what's involved. The extra low-tier railgun would work by itself since BFCs and power plants are already possible without TN Tech.

That said, this is the suggestions thread and we've clearly made a suggestion, so I'll shut up now.
Title: Re: C# Suggestions
Post by: QuakeIV on November 16, 2020, 10:01:42 PM
I'd personally favor the simplest possible approach, I don't think we really gain anything with a combined unit 'conventional' sensor other than a weird thing that deviates from the usual system and requires some kind of special code.
Title: Re: C# Suggestions
Post by: DIT_grue on November 17, 2020, 12:54:29 AM
Just to get it into this thread so it isn't forgotten: Platys51 suggests allowing shipyards to retool to a design containing prototype components (http://aurora2.pentarch.org/index.php?topic=12072.msg143062#msg143062).
Title: Re: C# Suggestions
Post by: Froggiest1982 on November 19, 2020, 02:14:08 AM
Exclude Alien Controlled Flag as default when a new ship is built.

I think that is the obvious choice while to put ship purposely in danger should be optional.
Title: Re: C# Suggestions
Post by: Black on November 22, 2020, 12:22:05 PM
I noticed that my engineers are busy playing archaeologists while assaulting Precursor positions. I think that it would be better if facility recovery was not possible while hostile forces are on the planet.
Title: Re: C# Suggestions
Post by: Garfunkel on November 22, 2020, 12:26:51 PM
I noticed that my engineers are busy playing archaeologists while assaulting Precursor positions. I think that it would be better if facility recovery was not possible while hostile forces are on the planet.
Perhaps restrict that to only Precursor forces. I can imagine a situation with multiple armies fighting over ruins and having competing archaeologist teams racing to salvage stuff before the enemy.
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 24, 2020, 11:57:29 AM
Change the starting age of new leaders to 30 or 35, or change "Age" to "Years of Service" and start from zero.

Starting a new game with a bunch of 20-year-old admirals and head scientists is just a tad unrealistic.  :P

Actually the dream would be to have years of service be separate from age and have the latter be SM-able for RP purposes, especially at game start, but that would require more coding so the simple change is probably preferable.
Title: Re: C# Suggestions
Post by: Iestwyn on November 24, 2020, 04:42:21 PM
Maybe have more then one tech for tugs. Instead of jumping straight to tractor beams, which seems like an advanced tech, there could be prerequisite techs with speed penalties.

I'm not great with naming, but maybe there could be "conventional hauling arms" at a 50% penalty, "trans-newtonian tug thrusters" at 75%, and then the tractor beams. I don't think it would make sense to have anything give bonus speed when tugging, but more experienced people may have better ideas.
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 24, 2020, 04:52:24 PM
Maybe have more then one tech for tugs. Instead of jumping straight to tractor beams, which seems like an advanced tech, there could be prerequisite techs with speed penalties.

I'm not great with naming, but maybe there could be "conventional hauling arms" at a 50% penalty, "trans-newtonian tug thrusters" at 75%, and then the tractor beams. I don't think it would make sense to have anything give bonus speed when tugging, but more experienced people may have better ideas.

Max tractor size would be interesting and could be done in a few different ways. Just having a plain absolute maximum would be kind of limiting and probably slow down the game economy too much, but either making it a multiple of the tug size or allowing multiple tractor modules with additive total tugging capacity. Doing both would be really interesting, i.e. each module lets you tug X% of the tug's mass, but that might be making things overly complicated. Personally I think the mass-per-module makes the most sense, physically a single tractor beam would have an upper limit of tugging capacity regardless of its mount.
Title: Re: C# Suggestions
Post by: Iestwyn on November 24, 2020, 06:02:42 PM
Maybe have more then one tech for tugs. Instead of jumping straight to tractor beams, which seems like an advanced tech, there could be prerequisite techs with speed penalties.

I'm not great with naming, but maybe there could be "conventional hauling arms" at a 50% penalty, "trans-newtonian tug thrusters" at 75%, and then the tractor beams. I don't think it would make sense to have anything give bonus speed when tugging, but more experienced people may have better ideas.

Max tractor size would be interesting and could be done in a few different ways. Just having a plain absolute maximum would be kind of limiting and probably slow down the game economy too much, but either making it a multiple of the tug size or allowing multiple tractor modules with additive total tugging capacity. Doing both would be really interesting, i.e. each module lets you tug X% of the tug's mass, but that might be making things overly complicated. Personally I think the mass-per-module makes the most sense, physically a single tractor beam would have an upper limit of tugging capacity regardless of its mount.

Makes sense to me. That way, there could be the same kind of design decisions as other modules, like how grav sensors scale up as the tech increases. That would also allow for more and more efficient tugs as tech improves.

I do wonder what happens if you try to tug something above what the tug is rated for. Does it just not work? Are there speed or fuel efficiency penalties?
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on November 24, 2020, 06:21:25 PM
Maybe have more then one tech for tugs. Instead of jumping straight to tractor beams, which seems like an advanced tech, there could be prerequisite techs with speed penalties.

I'm not great with naming, but maybe there could be "conventional hauling arms" at a 50% penalty, "trans-newtonian tug thrusters" at 75%, and then the tractor beams. I don't think it would make sense to have anything give bonus speed when tugging, but more experienced people may have better ideas.

Max tractor size would be interesting and could be done in a few different ways. Just having a plain absolute maximum would be kind of limiting and probably slow down the game economy too much, but either making it a multiple of the tug size or allowing multiple tractor modules with additive total tugging capacity. Doing both would be really interesting, i.e. each module lets you tug X% of the tug's mass, but that might be making things overly complicated. Personally I think the mass-per-module makes the most sense, physically a single tractor beam would have an upper limit of tugging capacity regardless of its mount.

Makes sense to me. That way, there could be the same kind of design decisions as other modules, like how grav sensors scale up as the tech increases. That would also allow for more and more efficient tugs as tech improves.

I do wonder what happens if you try to tug something above what the tug is rated for. Does it just not work? Are there speed or fuel efficiency penalties?

The most interesting mechanically would be to have tractors have an engine power (which is speed*mass) transfer rating. Like, a 1000 EP tractor would allow hauling a 100 ton (2 hull spaces) target at 10,000 km/s, or 1000 tons at 1000 km/s. Then have tech that scales the efficiency of tractor beams, and let us design different size tractors. Finally, let tractor beams work both directions; the tugged ship can also have the tractor.

The point of this would be to allow using multiple tugs on a single target to speed it up, or to let a single super tug haul multiple things. It would also make tiny tractor beams reasonable. I want to make the self-tractoring missile pods from Honor Harrington! But currently, with fixed, 500 ton tractors that have to be on the ship providing the engines, this is thoroughly impractical.

Mathematically, working out the acceptable speed for a tug network would end up being a linear program. There are very very fast algorithms for this!
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on November 24, 2020, 06:26:47 PM
Sorry about double post, but as this is thoroughly unrelated....

The new reduced size single weapon fire controls could be taken further: make fire controls, in general, have limited number of weapon allocations. Bigger fire controls would allow more weapons to be assigned to them.

The purpose of this is to make giant infrequent missile salvos less effective, since it becomes hard to have enough fire control channels to make it work. It also opens up interesting design space related to sharing fire control channels, much like the rotating guidance schemes used in some of the later Honor Harrington books.

If applied to beam fire controls, it would also create more of a reason to go for layered anti-missile schemes, since you can't manage 100 railguns firing simultaneously anymore. This would help balance out the nerf to missiles, too.
Title: Re: C# Suggestions
Post by: xenoscepter on November 24, 2020, 09:47:53 PM
http://aurora2.pentarch.org/index.php?topic=12088.msg143483#msg143483
^I'm gonna put this here as it is more of a Suggestion than a helpful contribution to the 1.13.0 Changes Discussion. The Off Topic contains the reply itself, just incase a duplicate proves useful. The above is a link to the original.

Off-Topic: show
- Well, the return of reduced size FCS already makes Beam fighters wayyyy more practical than they were before. Like, quite significantly so.

 - With that having been said; for Plasma Carronades I'd like to see them have an option to consume fuel as ammo. Perhaps a kind of alternative shield that was stronger and/or smaller, but consumed fuel as well to go with it. In Homeworld and Homeworld 2, the Plasma Bombs were fluffed as using a portion of the starship's fuel as ammo, which keeps with the idea and logic of what plasma actually is, that being a state of matter. I don't really expect Steve to put all that work into them though, as much as I'd like to see such a change it really doesn't jive to well with Aurora's flavor, IMO.

 - An alternative for the Carronades would simply to be adding in the reduced size and giving them an "Extended Minimum" analogous to the Laser's Spinal Mounts. The Extended Minimum would have two levels, with the first reducing damage drop off for a corresponding increase in weight, say halving the drop off in exchange for a mass increase equal to +1 calibre. AKA, like how Spinal Mounts increase the laser's weight. The second tier would add +2 calibres of mass for a removal of damage drop off. This would mean that you could combine the two upgrades to make an expensive 15cm Plasma Carronade that had no drop off and weighed the roughly the same mass, but had drastically increased recharge needs.

 - For the HPMs, I'd really just like the option to turret 'em, tbh. I think they'd make nice Anti-Fighter / Anti-FAC guns. I'd also like to see the damage of HPMs, well "damage", but you know what I mean... I'd like to see that increase with calibre. Likewise for Mesons, I'd like to see bigger Meson Guns do more damage. So a 12cm HPM would do 4 damage to shields and a 15cm would do 5 damage to them, but both would still only roll once for E-DAC, while the 20cm would do 6 Damage to shields and roll twice on the E-DAC. Basically have the bigger HPMs increase the shield damage while making the number of rolls on the E-DAC be equal to half the shield damage rounded down.

 - Mesons could do something similar, in that they fire a bigger "shot". So a 12cm Meson fires a 2-point "shot", a 15cm Meson fires a 3-point "shot" and so on and so forth. Thus the Meson Retardation Tech would become more useful as you went up in size, with each failed roll removing 1 point of strength from the "shot" until it finally fizzled. The size, power requirements, costs and so on would keep smaller guns useful for fighters, turrets and such, while the FCS needed to make use of the better range would help keep the mid-sized guns relevant for some time as well. These factors would also curb the usefulness of truly monstrous guns, like 30cm+ ones, as their FCS and Power Requirements would hamstring their damage output via accuracy, RoF, and required technological & material investment.

 - Thus under these changes Plasma Carronades would become a more robust and interesting weapon system to invest in, without losing their low-cost / low-tech niche. HPMs would become shield-buster / ion cannon-esque weapons, and with the option to turret would double as Anti-Fighter / Anti-FAC against beam-centric foes. Mesons would a lot more useful to research as a main weapon option, since the big ones would give better performance against ships while the turreted small ones remain a viable Anti-Missile / Anti-FAC, with the ones in the 12~15cm range would double as Anti-Fighter weapons. These would make Mesons into an actually threatening weapon, without reverting them to the overpowered monstrosities that they were. Add back them Armored Missiles and suddenly they become very, very attractive options indeed. :)
Title: Re: C# Suggestions
Post by: xenoscepter on November 24, 2020, 09:57:39 PM
Sorry about double post, but as this is thoroughly unrelated....

The new reduced size single weapon fire controls could be taken further: make fire controls, in general, have limited number of weapon allocations. Bigger fire controls would allow more weapons to be assigned to them.

The purpose of this is to make giant infrequent missile salvos less effective, since it becomes hard to have enough fire control channels to make it work. It also opens up interesting design space related to sharing fire control channels, much like the rotating guidance schemes used in some of the later Honor Harrington books.

If applied to beam fire controls, it would also create more of a reason to go for layered anti-missile schemes, since you can't manage 100 railguns firing simultaneously anymore. This would help balance out the nerf to missiles, too.

 - I like the idea as applied to Beam FCS, but frankly the big, infrequent salvos thing is already sub-optimal to the point of being near ineffective. Box Launcher spam notwithstanding mind you, but Box Launcher spam is already balanced out by counter-AMM Box Launcher spam, cheap decoy missiles, and by virtue of being a "one shot wonder" as they can't be reloaded mid-battle. The Beam FCS requiring more weight to control more guns is a bit... weird in terms of logic, but since any number of guns can be tacked onto any number of FCS systems to engage any number of missile salvos that might actually create some interesting design decisions, without forcing a meta. It would also serve to increase the role of CIWS as a military system, making it a more attractive option and thus creating even more flavors of design.

 - As to 100 railguns... under the C# weapons model you'd probably destroy the damn ship by eating through MSP, so that's not really a great example, but yes having bigger FCS to handle those bajillion guns would be pretty neat. However you already more than one FCS to track more than one (non-missile salvo) target, and you need at least four FCS units if you want to perform offensive beam attacks, Area Defense PD, Final Fire PD and Final Fire PD(Self-Only) at the same time. So it already seems pretty balanced as is, tbh. An erstwhile and good suggestion in any case. :)
Title: Re: C# Suggestions
Post by: vorpal+5 on November 25, 2020, 05:42:31 AM
Scientist history: Would be nice to have their completed projects there!
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on November 25, 2020, 10:11:02 AM

 - I like the idea as applied to Beam FCS, but frankly the big, infrequent salvos thing is already sub-optimal to the point of being near ineffective. Box Launcher spam notwithstanding mind you, but Box Launcher spam is already balanced out by counter-AMM Box Launcher spam, cheap decoy missiles, and by virtue of being a "one shot wonder" as they can't be reloaded mid-battle. The Beam FCS requiring more weight to control more guns is a bit... weird in terms of logic, but since any number of guns can be tacked onto any number of FCS systems to engage any number of missile salvos that might actually create some interesting design decisions, without forcing a meta. It would also serve to increase the role of CIWS as a military system, making it a more attractive option and thus creating even more flavors of design.
Big, infrequent salvos (box launchers, or just reduced reload rate launchers) are the optimal way to use missiles. That doesn't mean they are the optimal way to play the game, which may be what you are getting at. But currently, if you want to use missiles this is the best route. And as a result, antimissile capabilities need to be balanced around it. This, in turn, makes other approaches untenable. Increasing the expense of huge salvos would allow weakening missile defense capabilities without causing missiles to dominate, in turn allowing other missile approaches to work better.

- As to 100 railguns... under the C# weapons model you'd probably destroy the damn ship by eating through MSP, so that's not really a great example, but yes having bigger FCS to handle those bajillion guns would be pretty neat. However you already more than one FCS to track more than one (non-missile salvo) target, and you need at least four FCS units if you want to perform offensive beam attacks, Area Defense PD, Final Fire PD and Final Fire PD(Self-Only) at the same time. So it already seems pretty balanced as is, tbh. An erstwhile and good suggestion in any case. :)

Currently, very little tech is required to put up a nigh-impenetrable wall of 10cm railgun PD. However, this relies on large quantities of such guns, since each shot is really inaccurate. If the mass (and thus, cost) of fire controls to support your PD scaled with the number of guns, that would make mass railguns weaker without affecting stuff like turreted PD or AMMs as much (since they use fewer numbers of higher accuracy weapons, and thus need less fire control).

Basically, the whole point of scaling fire control size with # of weapons is to force players to spread shots out temporally. If we can't handle 500 missiles in one tick, we need to use strategies relying on 300 missiles every other tick. If we can't manage 1000 final defense shots when the missiles arrive, we need to thin them out with AMMs, then longer ranged PD fire.

As to flavoring why beam fire controls scale with # of weapons controlled...well, it never really sat right with me that non-turreted weapons were truly hull mounted (how can they all engage a single target? Isn't the ship in the way?). So the fire control mass allocation could include some limited traverse capabilities for all the weapons assigned to it. Or something.
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 25, 2020, 09:53:30 PM
Commander auto-assign needs a couple of tweaks to be actually useful.

First: Some degree of allowance needs to be made for commanders to command a ship that they are technically overqualified for. Currently, the auto-assign will only assign a commander to a ship if they are exactly the minimum rank needed to command that ship. This is fine for warships where you have a few different classes and generally can designate one class to have Senior C.O.s as it's the more important one anyways. Where this doesn't work well is for specialized ships, particularly survey ships - using RN ranks for example, if my survey ships require a Commander, the auto-assign will not assign a survey-skilled Captain who has nothing better to do, and unlike the warship situation I am usually not running around with 2-3 different classes of survey ships so that I can designate one for Senior C.O.s. Perhaps an easy implementation would be to add a checkbox under the Senior C.O. checkbox in the class design window, called "Flexible Rank" or something similar which allows assignment of above-minimum-grade C.O.s.

Second: It would be helpful if we could assign an alternative commander specialty in the "Miscellaneous" tab of the class design window. For example, if I make a mining platform with a cargo bay to port a mass driver around, the game will treat it as a freighter and assign a Logistics commander instead of a Mining commander

Second one is a minor (heh) detail but the first one is in my opinion much-needed, being the primary reason I hesitate to click "Automated Assignments" even as my empire grows and I have to replace multiple retired or promoted commanders after every increment.
Title: Re: C# Suggestions
Post by: Froggiest1982 on November 26, 2020, 12:02:47 AM
Commander auto-assign needs a couple of tweaks to be actually useful.

First: Some degree of allowance needs to be made for commanders to command a ship that they are technically overqualified for. Currently, the auto-assign will only assign a commander to a ship if they are exactly the minimum rank needed to command that ship. This is fine for warships where you have a few different classes and generally can designate one class to have Senior C.O.s as it's the more important one anyways. Where this doesn't work well is for specialized ships, particularly survey ships - using RN ranks for example, if my survey ships require a Commander, the auto-assign will not assign a survey-skilled Captain who has nothing better to do, and unlike the warship situation I am usually not running around with 2-3 different classes of survey ships so that I can designate one for Senior C.O.s. Perhaps an easy implementation would be to add a checkbox under the Senior C.O. checkbox in the class design window, called "Flexible Rank" or something similar which allows assignment of above-minimum-grade C.O.s.

Second: It would be helpful if we could assign an alternative commander specialty in the "Miscellaneous" tab of the class design window. For example, if I make a mining platform with a cargo bay to port a mass driver around, the game will treat it as a freighter and assign a Logistics commander instead of a Mining commander

Second one is a minor (heh) detail but the first one is in my opinion much-needed, being the primary reason I hesitate to click "Automated Assignments" even as my empire grows and I have to replace multiple retired or promoted commanders after every increment.

I just dont understand 2 things:

1-Why we got rid of the minimum rank selection for ships in VB6.

2-Why the rank selection have been instead moved to the ground units and it is not even flexible!

During development I was very happy with the changes. When I saw suddenly the ground units I was skeptikal. After almost a year I am afraid I was right.

The ground unit changes are welcome and when they work they really add a nice extra layer. The problem is that they most likely going to break your game.

I am now more into DB managing editing though as it can help fixing these minor issues when you face them.

However, I think it focused Steve's mind on a less important part of the game leaving the the core a bit unfinished.

If you think we just got formations back and yet they still different and there was no much need to change it. Some solutions like escorts are awesome, but do I miss the feature of 1 unique survey fleet moving together, arriving in the system, split and survey? God yes! Or maybe there is and I could not make it work.

Mines, still not working and not even investigated.
Fighter Squadrons.
Galaxy map with no zoom.

These are just some of the things I miss.

Regardless the above I love C#, I support Steve and all I can do is keep playing and waiting faithfully for more things to be added. I like the change is doing on Fighters for instance from 1.13 on as I think they will allow for interesting RP games.

EDIT: I know the release was rushed to get Aurora out, just trying to understand how some things got prioritized over others. Obviously, without having no idea how the game is made I still want this to be read in a constructive way and without having any malicious intentions. Hence the last part.
Title: Re: C# Suggestions
Post by: db48x on November 26, 2020, 02:24:15 AM
Where this doesn't work well is for specialized ships, particularly survey ships - using RN ranks for example, if my survey ships require a Commander, the auto-assign will not assign a survey-skilled Captain who has nothing better to do, and unlike the warship situation I am usually not running around with 2-3 different classes of survey ships so that I can designate one for Senior C.O.s. Perhaps an easy implementation would be to add a checkbox under the Senior C.O. checkbox in the class design window, called "Flexible Rank" or something similar which allows assignment of above-minimum-grade C.O.s.

Flexible ranks could be nice, but don't forget that you have two new tools now as well. The new command & control modules allow more than one officer per ship, and admin commands provide a bonus to more than one fleet at a time.

Survey officers should start their careers in a Science Department, then be promoted and have a shot at commanding a ship, and then when promoted again they should move into a regional admin command, then get promoted again and take over the whole survey operation for the western spiral arm and so on. Once in an admin command, they provide one quarter of their bonus to every ship in their department. As long as that's four or more ships, then they're using that bonus well. Once promoted again, they provide one sixteenth of their bonus to all the ships two levels down from them. Individually that's not a lot, but if it's spread out over 16 or more ships, then they're contributing just as much as they ever were. Even if you have fewer than 16 ships they'll still be beneficial.

With 16 survey ships you have enough room for four levels of promotions. There will be 16 captains that get promoted and will vie for the chance to run one of the four regional admin commands; you'll give the best four of them the job. Most of the others will retire early, or find jobs in other parts of your navy (since they might have or develop other skills too). The best of the four will end up running the whole survey operation. They could end up running the whole navy on their next promotion, if you decide that they've got enough non-survey skills built up by then.

There is one wrinkle, of course. The standing orders for moving to a system requiring survey do not appear to take into account the location of the admin command to which the ship is assigned. (Not that I've investigated the matter very thoroughly…) As far as I can tell, it just picks the system closest to where the ship is at the time. That will mostly work, but after returning to your capital for overhaul they'll probably end up in a system on the other side of the galaxy, where they won't be getting any bonuses from their admin command. The solution to this is either micromanagement or better logistics: give each region a facility capable of overhauling survey ships. That cuts down on travel times too.
Title: Re: C# Suggestions
Post by: Kristover on November 26, 2020, 09:53:46 AM
Couple of suggestions involving medals:

1. Could you add a condition for governors, sector governors, and academy commandants?  I realize it is minor and really for flavor but given that I'm one of those guys that LOVES the medals process, I wouldn't mind having some ability to auto-recognize those who get these posts. 

2.  Similar to systems, could you standardize a 1, 10, 25, 100 gradation for discovery of minerals and jump-points?  What I find is with auto-assignment, no commander is every going to get close to 1000 minerals discovery and almost none will ever get 100 minerals (I think I only had one reach 100 and that was one game I forgot to click auto assign commanders).  On the contrary, finding 3 JP for a single ship commander happens all of the time when I send a single long endurance ship to survey a system and thus doesn't feel like much of an accomplishment.  I think the 1, 10, 25, 100 level would be a better standard.
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 26, 2020, 11:33:04 AM
Where this doesn't work well is for specialized ships, particularly survey ships - using RN ranks for example, if my survey ships require a Commander, the auto-assign will not assign a survey-skilled Captain who has nothing better to do, and unlike the warship situation I am usually not running around with 2-3 different classes of survey ships so that I can designate one for Senior C.O.s. Perhaps an easy implementation would be to add a checkbox under the Senior C.O. checkbox in the class design window, called "Flexible Rank" or something similar which allows assignment of above-minimum-grade C.O.s.

Flexible ranks could be nice, but don't forget that you have two new tools now as well. The new command & control modules allow more than one officer per ship, and admin commands provide a bonus to more than one fleet at a time.

Survey officers should start their careers in a Science Department, then be promoted and have a shot at commanding a ship, and then when promoted again they should move into a regional admin command, then get promoted again and take over the whole survey operation for the western spiral arm and so on. Once in an admin command, they provide one quarter of their bonus to every ship in their department. As long as that's four or more ships, then they're using that bonus well. Once promoted again, they provide one sixteenth of their bonus to all the ships two levels down from them. Individually that's not a lot, but if it's spread out over 16 or more ships, then they're contributing just as much as they ever were. Even if you have fewer than 16 ships they'll still be beneficial.

With 16 survey ships you have enough room for four levels of promotions. There will be 16 captains that get promoted and will vie for the chance to run one of the four regional admin commands; you'll give the best four of them the job. Most of the others will retire early, or find jobs in other parts of your navy (since they might have or develop other skills too). The best of the four will end up running the whole survey operation. They could end up running the whole navy on their next promotion, if you decide that they've got enough non-survey skills built up by then.

I do something like this already, in fact my survey admin command structure is three layers deep (CDRE-RADM-VADM) assuming I have the officers for it, and I require science officers on all my survey ships (at least for TN start). The problem is just that CDR-CAPT split as I usually prefer to keep Captains (or other 3rd rank) as senior ship commanders and Commodores as the lowest level of admin command both for RP and ease of management.

Don't get me wrong, I certainly appreciate and make use of the new rank features in C# but I prefer those features as tools available to be used how I like, rather than as a constraint saying "you must play in this way" which the auto-assign very much feels like due to how it handles ranks. The feature as it stands to me feels more like a puzzle to be solved, i.e. how to design a fleet structure so that the auto-assign "works", rather than a helpful feature to reduce tedious micro-management.

Of course, manual assignment always works as long as you don't mind occasional RSI.  ;)

Quote
There is one wrinkle, of course. The standing orders for moving to a system requiring survey do not appear to take into account the location of the admin command to which the ship is assigned. (Not that I've investigated the matter very thoroughly…) As far as I can tell, it just picks the system closest to where the ship is at the time. That will mostly work, but after returning to your capital for overhaul they'll probably end up in a system on the other side of the galaxy, where they won't be getting any bonuses from their admin command. The solution to this is either micromanagement or better logistics: give each region a facility capable of overhauling survey ships. That cuts down on travel times too.

I usually use the system map to manage this using the labels feature to track which system each ship is assigned to and plan out my surveying accordingly. Even with double-digit survey ships each one only needs new orders every couple of years so the micromanagement is minimal to accomplish balanced or directed exploration missions.
Title: Re: C# Suggestions
Post by: swarm_sadist on November 26, 2020, 02:54:21 PM
Reserving installations.

Currently, I am building Mass Drivers at an Industrial Planet, and shipping them out to the neighbouring Mining Worlds in the system. I want to keep 1 Mass Driver on the industrial planet, but going back and forth to set the supply manually is rather tedious.

I suggest:
1) Allowing you to set reserve levels for planets in the "Civilian Economy" tab, in the left-hand field. This could look like Mass Driver 3(1), with double clicking bringing up a field to change the reserve number. Your civilian cargo ships won't touch these.

2) Disable the alert for no supply, allowing you to have supply requests for non-existent installations. (I think this has been suggested already)

3) Have some installations have defaults, well, by default. Spaceport (1), Mass Driver (1), Naval Headquarters (1, mostly because you might get some weird errors if the HQ disappears)

4) Perhaps a floating default based on use. Ground Force Complex being used, Infrastructure supporting population, Research Labs in use, etc.
Title: Re: C# Suggestions
Post by: db48x on November 26, 2020, 03:47:55 PM
I do something like this already, in fact my survey admin command structure is three layers deep (CDRE-RADM-VADM) assuming I have the officers for it, and I require science officers on all my survey ships (at least for TN start). The problem is just that CDR-CAPT split as I usually prefer to keep Captains (or other 3rd rank) as senior ship commanders and Commodores as the lowest level of admin command both for RP and ease of management.

I see. I guess you could add Main Engineering to your survey ships too. Then you'd have the three lowest ranks on all of them, and the ship's commander would be a captain.
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 26, 2020, 10:20:02 PM
I do something like this already, in fact my survey admin command structure is three layers deep (CDRE-RADM-VADM) assuming I have the officers for it, and I require science officers on all my survey ships (at least for TN start). The problem is just that CDR-CAPT split as I usually prefer to keep Captains (or other 3rd rank) as senior ship commanders and Commodores as the lowest level of admin command both for RP and ease of management.

I see. I guess you could add Main Engineering to your survey ships too. Then you'd have the three lowest ranks on all of them, and the ship's commander would be a captain.

That's certainly not the worst idea, though the Main Engineering isn't a Survey position so one rank of survey-skilled commanders missed out regardless, but that's probably fine as the LCDR rank is more of a training rank really.

That being said, I'd still appreciate at least the option for a more flexible auto-assignment. I use survey ships as the most vexing example personally, but this also applies to e.g. various industrial-type ship commands where I'd rather have my 50 Logistics/Mining commanders stay in command of a logistics or mining ship instead of promoting into command of a frigate or something. Plenty of other small examples, and as always there's ways to work with the system, but more flexibility and options is not a bad thing here is my main point.
Title: Re: C# Suggestions
Post by: db48x on November 30, 2020, 09:57:18 PM
There are a fair number of queues in Aurora, but few commonalities between them. The industry, ordinance, and fighter queues all share a common UI, and so they all have the same features.

The other queues all have different UI and generally fewer features.

Some of these differences are justified as being different game mechanics. For example, shipyards generally must be retooled in order to build a different type of ship, so you can't pause the current ship, build another, and then continue the first the way you can with items in the industry queue.

Other differences are not so justifiable. For example, there is no game mechanic that explains why you cannot set your terraformers to add oxygen to the atmosphere now, and then schedule them to start adding water vapor afterwards.

I've prepared a table summarizing the queues and some of their salient characteristics, highlighting in red those items that I do not think have a mechanical justification. These are the ones that could be changed to a "yes" without changing the game mechanics.

Queue Name          Pooled resources? Multiple items? Future items? Change order? Percentage allocation?
Fleet Orders yes yes yes  no no                           
Industry yes yes yes yes yes
Ordnance yes yes yes yes yes
Fighters yes yes yes yes yes
Shipyard no yes no no no
Research partial yes yes partial partial
Ground Units no yes yes partial no
Civilian Contracts yes yes no no no                           
Terraforming yes no no no no

Some of these have been suggested individually before, and probably I'm not the first to suggest unifying the features of all the queues as much as possible, even if the UI remains ideosyncratic.

Some of these would be easier than others. For example, with sufficient effort it is actually possible for the shipyard queue(s) to support the case where the current ship is paused and another ship is completed first. If retooling operations were a part of the queue, and the game inserted those operations automatically when the queue was edited, then moving the current ship down in the list would probably insert retooling operations before it and after it. The user would probably change their mind right away, but it would not be impossible to implement.

The terraforming queue has obviously gotten the short end of the stick here, even though terraforming itself has been improved significantly.
Title: Re: C# Suggestions
Post by: Froggiest1982 on December 01, 2020, 01:53:35 AM
A raise all lower all button for shields so that you don't need to go manually ship by ship.

I know there is an order for it, but I think a button will be more intuitive.
Title: Re: C# Suggestions
Post by: Droll on December 01, 2020, 06:11:56 AM
A raise all lower all button for shields so that you don't need to go manually ship by ship.

I know there is an order for it, but I think a button will be more intuitive.

The same but for active sensors as well would be nice - like in VB6
Title: Re: C# Suggestions
Post by: Ghrathryn on December 01, 2020, 06:32:52 AM
I'm not sure if this is in the game or not, but with regards to fleets and subfleets, being able to order subfleets to separate to perform tasks on standing orders (IE: you have a fleet of 2+ survey ships you want them to be a single fleet but want them to separate to survey the systems.  Maybe ones geo, the other is grav, or you want them to hit multiple places at once rather than bunch up).

It might also be useful to have the ability to have more than two conditional orders, for example you have a survey ship/fleet jump to a new system with orders to survey bodies and locations, but you also want them to return to refuel once you're below a certain percentage, return if they hit their deployment clock and if they run low on MSP.  You're also sending them into new territory, so you want to be able to have them immediately take evasive action/retreat should an unknown or known hostile ship appear on their sensors.

You could also potentially expand the two primary standing orders into a more complex thing which might allow things like ordering a ship to survey planets primary, then moons, and only after that comets/asteroids or have colony ships follow a specific order for where to hunt for potential colonists, or deal with automated warp transits during a mission ala gathering minerals from a mining colony in one system and shunting them back to the capital in another.

It depends on how deep you want to go, although I would possibly recommend having a way to have standing orders pause instead of wipe if they cannot be met at the moment to allow things like automated rescue, salvage, building transport, survey, etc to stick (particularly if you've got early game geosurvey/grav survey and want them to automatically hitch a ride with a jump tender without having to reset all their standing orders for each new system for example).

Another potentially useful thing to have in, on ground forces this time, is the ability to lock formations together so for example you have three 1-5kt formations with a particular superior and you want to shunt them to a new world to guard or attack.  Being able to lock the combined formation would be useful in making them use the same transport fleet and in reducing micro on the other side since you don't have the companies become unattached from their battalion during transport and need to set them back up on the other end, when they maybe under fire.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on December 01, 2020, 08:52:42 AM
A raise all lower all button for shields so that you don't need to go manually ship by ship.

I know there is an order for it, but I think a button will be more intuitive.

Can't you multiselect then use the existing button? I thought that worked.
Title: Re: C# Suggestions
Post by: Droll on December 01, 2020, 09:29:58 AM
A raise all lower all button for shields so that you don't need to go manually ship by ship.

I know there is an order for it, but I think a button will be more intuitive.

Can't you multiselect then use the existing button? I thought that worked.

As far as I know no such button exists in C#. Though it wouldn't be the first time I missed a UI element
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on December 01, 2020, 09:48:46 AM
Derp, replied to the wrong post.

I meant for active sensors. The activate sensors button applies to all the ships selected on the fleet tab, I'm pretty sure.
Title: Re: C# Suggestions
Post by: Migi on December 01, 2020, 05:44:46 PM
I have approximately 3 small suggestions:

1) I would like to be able to set a default field position for each template.
When a template is built it is automatically assigned to that position, after that it has no further effect.
There are a lot of rear and support elements that are never going to need to be assigned to any other position, being able to set their position during creation would save quite a bit of micromanagement.

2) I would like to be able set targeting for STO's more easily.
2a) Like field position, I think that having a default value which is assigned when the unit is built would go some way towards addressing this (although it might need to be set on the unit rather than the template because a template can have more than 1 STO in it).
2b) I would like the ability to copy existing settings to other units, in the same way we can copy fire control setup to ships in the same fleet (body in this case), system or empire-wide.
2c) I think being able to select more than 1 STO at a time in that window would be very helpful. Given that most lists in game don't support multi-select I am guessing this would either require some extra programming you don't want to spend time on or don't know how to do but I thought I would mention it anyway.
2d) I would like the option of having the STO targeting window show the STO's in a location tree like the Order of Battle window.

3) Currently static and infantry units can't use autocannons, and I would like to be able to do so.
Is there a reason for this or is it an oversight?

If I've missed something obvious feel free to point it out.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 01, 2020, 06:29:29 PM
I have approximately 3 small suggestions:

Might be 2.9, might be 3.1, we can't be sure, but it's about 3.  :P

Quote
1) I would like to be able to set a default field position for each template.
When a template is built it is automatically assigned to that position, after that it has no further effect.
There are a lot of rear and support elements that are never going to need to be assigned to any other position, being able to set their position during creation would save quite a bit of micromanagement.

Seconded. One of the more annoying bits of game setup for me especially with a larger BP limit.
Title: Re: C# Suggestions
Post by: DIT_grue on December 02, 2020, 02:08:53 AM
Zap0 started a discussion (http://aurora2.pentarch.org/index.php?topic=12121.msg143843#msg143843) about the inconsistency in the cost of repairing a ship depending on whether you use a shipyard or the onboard damage-control.
Title: Re: C# Suggestions
Post by: Froggiest1982 on December 02, 2020, 03:04:13 AM
A raise all lower all button for shields so that you don't need to go manually ship by ship.

I know there is an order for it, but I think a button will be more intuitive.

Can't you multiselect then use the existing button? I thought that worked.

As far as I know no such button exists in C#. Though it wouldn't be the first time I missed a UI element

There is a button if you select a ship with shields in the ship UI on the side of the combat slide (where you also have MFC and FC buttons). I havent tried to multiselect yet, it's just seems like a lot of non required clicks though...
Title: Re: C# Suggestions
Post by: aks2161989 on December 03, 2020, 12:02:21 PM
Steve, first I would like to thank you for creating this game.  Its completely different from what I have played so far.  Reading the threads here, I know that you don't intend to add support for smaller screen resolutions (which is fine considering you probably have to work on other important tasks).  But, could you please add scroll-bars to every window? That would be great for those of us playing on smaller resolutions.

Currently I am using AuroraMod to add scroll bars, but it would be great if the default game  had scroll bars.
Title: Re: C# Suggestions
Post by: Drakale on December 03, 2020, 12:09:24 PM
I have approximately 3 small suggestions:

1) I would like to be able to set a default field position for each template.
When a template is built it is automatically assigned to that position, after that it has no further effect.
There are a lot of rear and support elements that are never going to need to be assigned to any other position, being able to set their position during creation would save quite a bit of micromanagement.


That would be insanely useful. Also the ability to multiselect in the army tab and set position would help cut down on clicking. I made a complex army organisation structure in my current game and I like the granularity a lot, but the amount of work it takes is pretty insane, a lot of it is going unit by unit and setuping the proper position.
Title: Re: C# Suggestions
Post by: Borealis4x on December 03, 2020, 06:31:24 PM
Probably too complicated, but it'd be super cool if the game was designed to model all levels of officers, starting from Ensign all the way to Fleet Admiral. The way this would work is that every ship would need certain billets to be filled by default by lower-ranking officer (Department Heads, Co-Pilot on small craft, etc) and then on top of that every part you add to a ship needs a certain amount of officers to work properly (fire controls, engines, hangars, cargo shuttle bays, active sensors, ELINT etc). Frankly, I think the XO and Chief Engineer should present on every ship you build above 1000 tons at the very least.

Currently officers start of as way too young, as the game models them as being mid-level officers (Senior LTs, Commanders) but they all start out at 21. Adding in more opportunities for multiple lower-ranking officers to serve on a ship would be extremely cool from an immersion and storytelling perspective.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 03, 2020, 06:47:10 PM
Probably too complicated, but it'd be super cool if the game was designed to model all levels of officers, starting from Ensign all the way to Fleet Admiral. The way this would work is that every ship would need certain billets to be filled by default by lower-ranking officer (Department Heads, Co-Pilot on small craft, etc) and then on top of that every part you add to a ship needs a certain amount of officers to work properly (fire controls, engines, hangars, cargo shuttle bays, etc). Frankly, I think the XO and Chief Engineer should present on every ship you build above 1000 tons at the very least.

Currently officers start of as way too young, as the game models them as being mid-level officers (Senior LTs, Commanders) but they all start out at 21. Adding in more opportunities for multiple lower-ranking officers to serve on a ship would be extremely cool from an immersion and storytelling perspective.

Not to be a Debbie Downer, but in addition to adding complication for questionable game benefits I do want to point out that this system would be absolute Hell to use if you play without automatic assignments, or even if you do but also do a lot of manual work because you don't trust the system.

If the problem is that officers are too young, a simpler solution is to either change the default starting age to 30 or 35, or to decouple age from career length entirely and have age be another randomly-generated starting trait. Personally I headcanon that my leaders don't start at age 20/21, rather this is their career length to date and they've been promoted to a senior officer role after a couple decades climbing the ropes.
Title: Re: C# Suggestions
Post by: Borealis4x on December 03, 2020, 06:53:02 PM
Probably too complicated, but it'd be super cool if the game was designed to model all levels of officers, starting from Ensign all the way to Fleet Admiral. The way this would work is that every ship would need certain billets to be filled by default by lower-ranking officer (Department Heads, Co-Pilot on small craft, etc) and then on top of that every part you add to a ship needs a certain amount of officers to work properly (fire controls, engines, hangars, cargo shuttle bays, etc). Frankly, I think the XO and Chief Engineer should present on every ship you build above 1000 tons at the very least.

Currently officers start of as way too young, as the game models them as being mid-level officers (Senior LTs, Commanders) but they all start out at 21. Adding in more opportunities for multiple lower-ranking officers to serve on a ship would be extremely cool from an immersion and storytelling perspective.


Not to be a Debbie Downer, but in addition to adding complication for questionable game benefits I do want to point out that this system would be absolute Hell to use if you play without automatic assignments, or even if you do but also do a lot of manual work because you don't trust the system.

If the problem is that officers are too young, a simpler solution is to either change the default starting age to 30 or 35, or to decouple age from career length entirely and have age be another randomly-generated starting trait. Personally I headcanon that my leaders don't start at age 20/21, rather this is their career length to date and they've been promoted to a senior officer role after a couple decades climbing the ropes.

I don't know why you wouldn't play with automatic assignment tbh. To me the un-optimized nature of it actually contributes to the gameplay and feel of expanding your empire. For your first couple of ships, you can hand select the best guys personally to staff these groundbreaking space ships you are going to use to change humanity forever. As space travel gets more casual and the fleet gets larger however, it naturally becomes more and more difficult to hold leaders accountable and make sure the best guys are getting into positions of responsibility and you have to rely more on the 'system' which is imperfect and subject to bias and nepotism. 

Of course, that doesn't stop you from hand selecting a crew for your most important and groundbreaking ships.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 03, 2020, 07:02:56 PM
I don't know why you wouldn't play with automatic assignment tbh. To me the un-optimized nature of it actually contributes to the gameplay and feel of expanding your empire. For your first couple of ships, you can hand select the best guys personally to staff these groundbreaking space ships you are going to use to change humanity forever. As space travel gets more casual and the fleet gets larger however, it naturally becomes more and more difficult to hold leaders accountable and make sure the best guys are getting into positions of responsibility and you have to rely more on the 'system' which is imperfect and subject to bias and nepotism. 

Of course, that doesn't stop you from hand selecting a crew for your most important and groundbreaking ships.

My #1, #2, and #3 issue with the auto-assign is that unless you design your navy precisely to the dictate of the auto-assign algorithm, it will regularly either leave swathes of ships without a commander, or refuse to assign entire ranks to suitable commands, quite often both.

I would love if the auto-assign would reliably keep ships commanded and commanders assigned even if the result was not close to optimal, as you say the RP implications are a perfect fit for the game. I have a lot harder time RPing why half of my frigates lack a commander while half my Captains are sitting around scratching their asses just because my frigates require a "mere" commander and all the cruiser billets are filled. At some point manually filling in all of the holes left by auto-assign becomes tedious enough that one might just be better off doing everything themselves.

Of course, one can design their fleet structure to fit to the auto-assign, but this is a rather limiting view of how the game should be played. There are many systems in the game that impose constraints on the player which can be solved in interesting ways. The auto-assign requires the player to either do exactly as it says, or it just breaks entirely - "interesting" is hardly the word I'd use to describe this.

Anyways, I'm just ranting now and I've already made suggestions in this thread on the topic so I'll let it lie now.
Title: Re: C# Suggestions
Post by: Droll on December 03, 2020, 07:49:50 PM
I don't know why you wouldn't play with automatic assignment tbh. To me the un-optimized nature of it actually contributes to the gameplay and feel of expanding your empire. For your first couple of ships, you can hand select the best guys personally to staff these groundbreaking space ships you are going to use to change humanity forever. As space travel gets more casual and the fleet gets larger however, it naturally becomes more and more difficult to hold leaders accountable and make sure the best guys are getting into positions of responsibility and you have to rely more on the 'system' which is imperfect and subject to bias and nepotism. 

Of course, that doesn't stop you from hand selecting a crew for your most important and groundbreaking ships.

My #1, #2, and #3 issue with the auto-assign is that unless you design your navy precisely to the dictate of the auto-assign algorithm, it will regularly either leave swathes of ships without a commander, or refuse to assign entire ranks to suitable commands, quite often both.

I would love if the auto-assign would reliably keep ships commanded and commanders assigned even if the result was not close to optimal, as you say the RP implications are a perfect fit for the game. I have a lot harder time RPing why half of my frigates lack a commander while half my Captains are sitting around scratching their asses just because my frigates require a "mere" commander and all the cruiser billets are filled. At some point manually filling in all of the holes left by auto-assign becomes tedious enough that one might just be better off doing everything themselves.

Of course, one can design their fleet structure to fit to the auto-assign, but this is a rather limiting view of how the game should be played. There are many systems in the game that impose constraints on the player which can be solved in interesting ways. The auto-assign requires the player to either do exactly as it says, or it just breaks entirely - "interesting" is hardly the word I'd use to describe this.

Anyways, I'm just ranting now and I've already made suggestions in this thread on the topic so I'll let it lie now.

I will say that I agreed with you up until 1.12 dropped and fixed the way commander priority worked. I have a lot of higher rank officers but that is less auto assignment making mistakes and more me having more than enough academies.

The only thing I did differently compared to other games is that I made my lowest rank lieutenant and moved the shifted the command structure upwards. Using the senior commander checkbox I have had absolutely no problem with filling commanders and bridge crews (this in particular used to be a problem). This is despite having 1000s of defense satellites for PPV normally hogging the lowest rank.

I haven't really felt that auto-assign limits and restricts the structure of the fleet. Unassigned commanders / vacant ships to me is more a problem with the way military academies work. A while ago I made a suggestion to split military academy into multiple buildings - each one only graduating a single type of commander, thereby giving the player more control over what officers they actually want. Either that, or allow the player to determine the ratio between each rank.
Title: Re: C# Suggestions
Post by: Borealis4x on December 03, 2020, 08:01:51 PM
A while ago I made a suggestion to split military academy into multiple buildings - each one only graduating a single type of commander, thereby giving the player more control over what officers they actually want. Either that, or allow the player to determine the ratio between each rank.

I like that idea. Though I would create different academies for each skill instead of saying they belong to the same school. We are talking planets here, it can have more than one school.

That actually makes me think of a completely different idea. The rate at which character spawn should not be dictated by academies. Instead, academies should increase the quality of students recruited off that planet. Sure Westpoint is a thing, but most officers come from ROTC programs held at their local colleges. Instead, character spawn rate should depend on how much you have allocated to recruitment via budget sliders.

I'll stop there, cuz budget sliders as a concept needs to be developed more in my head, but I think they would make the player pay more attention to their economy and overall make Financial Centers more desirable.
Title: Re: C# Suggestions
Post by: Droll on December 03, 2020, 08:50:40 PM
I like that idea. Though I would create different academies for each skill instead of saying they belong to the same school. We are talking planets here, it can have more than one school.

The reason why I avoided taking my suggestion there is because this would make academy commandants obsolete. If my suggestion were to be implemented it would probably be a good idea to have academy commandant skills have more of an influence on the skill set of the graduates.
Title: Re: C# Suggestions
Post by: Ghrathryn on December 04, 2020, 06:03:32 AM
Quote from: Droll link=topic=10640. msg143969#msg143969 date=1607050240
Quote from: Borealis4x link=topic=10640. msg143964#msg143964 date=1607047311
I like that idea.  Though I would create different academies for each skill instead of saying they belong to the same school.  We are talking planets here, it can have more than one school. 

The reason why I avoided taking my suggestion there is because this would make academy commandants obsolete.  If my suggestion were to be implemented it would probably be a good idea to have academy commandant skills have more of an influence on the skill set of the graduates.

Might depend on how it's implimented.  At the moment we have an academy and every time we build it, it adds one level to the existing for that planet.  What could happen is split the academy between the 'officers' so you have one that's pure navy, one pure science, one pure admin and one pure ground, making four commandants initially and have training skill buff the number or quality of graduates (though that would mean every officer type would have that skill).

Maybe if Steve impliments that system, down the line you could have it that each academy also takes the highest one or two skills from the commandant and depending on the level of them and training, you'll have more chance of officers from that planet's x academy having those skills at some level so different worlds would produce officers with different starting skills depending on the commandant's skill set.

Or go a different route, maybe expand things so there's additional buildings you can build linked to the academy ala the ship command modules.  Each module building requires a certain type of officer and improves both the number of that type and the likelihood of others with that skill set.  It's still one planetary academy so to speak, but the additional 'campuses' both improve the output and allow different skill sets to be taught.

It kind of depends on how complex the programming is and how much manual work players want to deal with.
Title: Re: C# Suggestions
Post by: Borealis4x on December 04, 2020, 12:15:57 PM
Quote from: Droll link=topic=10640. msg143969#msg143969 date=1607050240
Quote from: Borealis4x link=topic=10640. msg143964#msg143964 date=1607047311
I like that idea.  Though I would create different academies for each skill instead of saying they belong to the same school.  We are talking planets here, it can have more than one school. 

The reason why I avoided taking my suggestion there is because this would make academy commandants obsolete.  If my suggestion were to be implemented it would probably be a good idea to have academy commandant skills have more of an influence on the skill set of the graduates.

Might depend on how it's implimented.  At the moment we have an academy and every time we build it, it adds one level to the existing for that planet.  What could happen is split the academy between the 'officers' so you have one that's pure navy, one pure science, one pure admin and one pure ground, making four commandants initially and have training skill buff the number or quality of graduates (though that would mean every officer type would have that skill).

Maybe if Steve impliments that system, down the line you could have it that each academy also takes the highest one or two skills from the commandant and depending on the level of them and training, you'll have more chance of officers from that planet's x academy having those skills at some level so different worlds would produce officers with different starting skills depending on the commandant's skill set.

Or go a different route, maybe expand things so there's additional buildings you can build linked to the academy ala the ship command modules.  Each module building requires a certain type of officer and improves both the number of that type and the likelihood of others with that skill set.  It's still one planetary academy so to speak, but the additional 'campuses' both improve the output and allow different skill sets to be taught.

It kind of depends on how complex the programming is and how much manual work players want to deal with.

I think it makes sense to at least have sperate institutions for the different leaders.

Naval Academies run by Commandants

Army Academies run by Superintendents

Scientist Academies run by Directors

Civil Servant Academies run by Deans
Title: Re: C# Suggestions
Post by: QuakeIV on December 04, 2020, 04:18:29 PM
That would probably make it more convenient to weight the number of specialists produced by the academy system.  I'd say it would probably almost purely a quality of life thing.
Title: Re: C# Suggestions
Post by: Frank Jager on December 04, 2020, 07:44:21 PM
Would it be possible to add another filter set to the ship design window?

For grouping common types of ship / station designs, that still have distinct name for class and hull.

I tend to design ships and stations that complement each other but have different hull names.

Currently I'm grouping them via hull name.

What I'm proposing is either a third drop-down list or a drag and drop functionality so that my "Combat Logistics" ships which all have different hull names (therefore appearing in different places on the list) could all be displayed together.

Or all my "Carriers" could all be displayed together even though one design is an Escort Carrier, one is an Auxiliary Carrier, and one is a Carrier, and the last is a "Supercarrier" they all have the same basic function (carrying, refuelling and rearming short ranged parasite craft) but all also have different purposes (Auxillary to move undamaged craft to the combat zone as replacements, Escorts to move with other craft, Carriers and Supercarriers to be flagships.
Title: Re: C# Suggestions
Post by: Droll on December 04, 2020, 08:49:48 PM
Would it be possible to add another filter set to the ship design window?

For grouping common types of ship / station designs, that still have distinct name for class and hull.

I tend to design ships and stations that complement each other but have different hull names.

Currently I'm grouping them via hull name.

What I'm proposing is either a third drop-down list or a drag and drop functionality so that my "Combat Logistics" ships which all have different hull names (therefore appearing in different places on the list) could all be displayed together.

Or all my "Carriers" could all be displayed together even though one design is an Escort Carrier, one is an Auxiliary Carrier, and one is a Carrier, and the last is a "Supercarrier" they all have the same basic function (carrying, refuelling and rearming short ranged parasite craft) but all also have different purposes (Auxillary to move undamaged craft to the combat zone as replacements, Escorts to move with other craft, Carriers and Supercarriers to be flagships.

What you want is unit series and the old missiles series to be extended to ships by the sounds of it. At least that's the easiest way I see it being implemented.
Title: Re: C# Suggestions
Post by: db48x on December 04, 2020, 09:04:41 PM
What I'm proposing is either a third drop-down list or a drag and drop functionality so that my "Combat Logistics" ships which all have different hull names (therefore appearing in different places on the list) could all be displayed together.

Or all my "Carriers" could all be displayed together even though one design is an Escort Carrier, one is an Auxiliary Carrier, and one is a Carrier, and the last is a "Supercarrier" they all have the same basic function (carrying, refuelling and rearming short ranged parasite craft) but all also have different purposes (Auxillary to move undamaged craft to the combat zone as replacements, Escorts to move with other craft, Carriers and Supercarriers to be flagships.

In the mean time, you can create your own hull names. Make hulls called "Carrier, Escort", "Carrier, Auxiliary", etc. Then they'll be sorted so that the carriers are next to each other. You can give hull types whatever abbreviations you want.

Use the "New Hull" button at the bottom of the window.
Title: Re: C# Suggestions
Post by: Froggiest1982 on December 05, 2020, 04:23:48 AM
http://aurora2.pentarch.org/index.php?topic=8495.msg119602#msg119602

Would be nice to have a way to see what is the status of the transponder also on the map like it currently happens for the overhaul, as when you are planning to betray allies (I know I am a piece of s**t) you may don't want them to know where your ships are and you don't want to go check manually fleet by fleet.
Title: Re: C# Suggestions
Post by: Platys51 on December 05, 2020, 04:29:19 AM
Suggestion: Put ammount of free facilities on top of the screen in ground construction window.

When you make 80 at once, its hard to hit just right amount when you cant see how many facilities are left...
Title: Re: C# Suggestions
Post by: db48x on December 05, 2020, 05:08:30 AM
When you find alien ship components, the alien race's name should be used in the name of the component as if it had been in the company field when it was designed. I'm putting a House of Emris 25.0cm C5 Far Ultraviolet Laser on each of the new Hammer of Light battleships that I've just designed (along with divers railguns and some particle beams; I have no laser tech at all).
Title: Re: C# Suggestions
Post by: vorpal+5 on December 06, 2020, 01:01:47 PM
Could replenishing occurs if there is a wait order before processing the next order, when you don't have underway replenishment (or have it but you are going too fast) ?
Because right now, if there is an order, any order, even one where you are not moving, then it won't work.

And the issue is that you can't automate: Move to waypoint, wait a few hours (replenishing would occur, you are not moving), resume travel. You must reach the WP, make sure the order list is empty, wait some hours, and plan the end of the travel.
Title: Re: C# Suggestions
Post by: Froggiest1982 on December 06, 2020, 02:27:27 PM
Add a station filter so that you don't need to scroll through fleets for refuel, maint, and more.

Can be challenging in busy systems to find what you need.

I currently leave a space before the name so that they always listed on top.

Off-Topic: show
I learned this trick on VB6 when to arrange my fleets without Admin Commands I used 1 or more spaces to sort.
Title: Re: C# Suggestions
Post by: Migi on December 06, 2020, 04:11:01 PM
Add a station filter so that you don't need to scroll through fleets for refuel, maint, and more.

Can be challenging in busy systems to find what you need.

I currently leave a space before the name so that they always listed on top.

Off-Topic: show
I learned this trick on VB6 when to arrange my fleets without Admin Commands I used 1 or more spaces to sort.

I like this idea, but there are more possibilities:
Fleets with stations
Fleets with commercial ships
Fleets with military ships
Fleets with civilian ships (not sure if there is ever a reason for them but anyway)

I'm not so enthusiastic about cluttering up the UI with that many more options, so is there a way they could they be hidden until the fleet box is ticked?
Title: Re: C# Suggestions
Post by: Kristover on December 06, 2020, 05:06:38 PM
Feature Request:  Is it possible to put a flag on particular colonies that exempts them from conditional refueling/resupply orders?  I tend to create small fighter/FAC bases in my systems with enough fuel/resupply to see to their needs and kind of tired of having my exploration ships ignoring the giant shipping hub in the same system with 250K fuel/MSP to go grab the 5K fuel/MSP I have stashed at these sites.
Title: Re: C# Suggestions
Post by: Kristover on December 06, 2020, 05:14:33 PM
Feature Request:  Is it possible to add a flag to prevent an officer from being assigned to a particular ship class?  I tend to create small commercial sensor platforms on jump points and crank them out with industry - I then load them into a special sensor tender which I then use to drop them.  I tend to overproduce academies so officer shortage usually isn't a problem but I rather not have auto-assign wasting Lieutenants on these.
Title: Re: C# Suggestions
Post by: Kristover on December 06, 2020, 05:17:42 PM
Feature Request:  Last one for tonight but I REALLY like the new feature to create 'garbage' modules for ships that allow you to differentiate them for RP purposes - I have already have a list of 100 potential modules that I am going to use for my ships.  It got me to thinking, can one do something similar for colonies?  Create a facility that we can rename to add more 'flavor' for a world?  I would like such a thing plus perhaps a notes pages that allows me to add manual notes to the world entry which I can then use for flavor text - frankly I wouldn't mind such a thing for each of my ships as well but that might get crazy.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 06, 2020, 07:01:44 PM
Feature Request:  Is it possible to add a flag to prevent an officer from being assigned to a particular ship class?  I tend to create small commercial sensor platforms on jump points and crank them out with industry - I then load them into a special sensor tender which I then use to drop them.  I tend to overproduce academies so officer shortage usually isn't a problem but I rather not have auto-assign wasting Lieutenants on these.

A good "quick fix" for this would be to make newly-created ship classes have a priority of 10 instead of 0, allowing for ultra-low-priority classes like these to exist. That way you should never see a rank-1 officer assigned to one of these when a better XO or freighter posting is open, but excess commanders will still be able to find employment.

Actually I'd like this as a separate feature, both are good.
Title: Re: C# Suggestions
Post by: Droll on December 06, 2020, 07:15:01 PM
A good "quick fix" for this would be to make newly-created ship classes have a priority of 10 instead of 0, allowing for ultra-low-priority classes like these to exist. That way you should never see a rank-1 officer assigned to one of these when a better XO or freighter posting is open, but excess commanders will still be able to find employment.

Actually I'd like this as a separate feature, both are good.

In 1.12 the default priority of new classes is set to 10 so this is already in.
Title: Re: C# Suggestions
Post by: Lord Solar on December 06, 2020, 09:16:31 PM
A good "quick fix" for this would be to make newly-created ship classes have a priority of 10 instead of 0, allowing for ultra-low-priority classes like these to exist. That way you should never see a rank-1 officer assigned to one of these when a better XO or freighter posting is open, but excess commanders will still be able to find employment.

Actually I'd like this as a separate feature, both are good.

In 1.12 the default priority of new classes is set to 10 so this is already in.
In addition, 0 = lowest priority now.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 06, 2020, 09:31:55 PM
A good "quick fix" for this would be to make newly-created ship classes have a priority of 10 instead of 0, allowing for ultra-low-priority classes like these to exist. That way you should never see a rank-1 officer assigned to one of these when a better XO or freighter posting is open, but excess commanders will still be able to find employment.

Actually I'd like this as a separate feature, both are good.

In 1.12 the default priority of new classes is set to 10 so this is already in.

Ignore me I'm blind apparently.  :-[
Title: Re: C# Suggestions
Post by: Drakale on December 07, 2020, 12:59:08 PM
So, a small suggestion for NPR AI; They should shoot down any encountered buoy/missiles present in territories they consider 'owned', even from non hostiles entities. It's too easy right now to keep perfect tabs on them by littering their homeworlds with buoy, since they won't shoot them down until war is declared. I guess there could be edge case where you would want to cooperate with a NPR in their territory without them shooting down your probes/mines, but that could be taken care of with relation level or a formal alliance system.
Title: Re: C# Suggestions
Post by: Ghrathryn on December 07, 2020, 03:09:24 PM
Not sure if any of these have been suggested before, but here's a few potentially useful suggestions.

1) Have an option for a tug fleet to attach to multiple/all ships/stations in another fleet without having to manually select every ship/station you want to have towed (this should probably limit up to either the amount of ships in the tug fleet or the amount of tractor beams in it or the beams' lift capacity).  I'd also suggest allowing the tugs to tow station fleets without breaking said fleets since it's a bit annoying to have a batch of stations (especially ones liable to be moved) be put into a fleet, towed to a site and find your fleet has been broken into individual ship units when it reaches its (possibly temporary) destination.

2) I mentioned this partially in my last post on this thread ala allowing sub-fleet components to spread out so recon or survey could run from a single fleet but multiple separated elements, but it could also be useful to allow full fleets to spread across an amount of territory with being split up (particularly if it's something like a group of terraforming/harvesting/mining stations being dragged into position as above) because they're in motion or they're immobile and there's not enough tugs on hand to move everything at once.

3) Allow us to set up 'colony types' along with base rules for them.  I know Aurora will take what we put at a 'colony' into account to decide whether it's a mining site, populated colony, archaeological dig, listening post, civilian mining site or 'other' and we can limit whether civilians visit, but it could be useful to allow us some extra control like allowing us to set digs to being excluded from civilian traffic by default so we don't suddenly get civilians dropping colonists there because we unearthed some usable building and forgot to say we don't want civilians involved in the site or tag which asteroids/moons/planets are just for mining over population before we start shipping automines over there.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 07, 2020, 06:42:47 PM
Not sure if any of these have been suggested before, but here's a few potentially useful suggestions.

1) Have an option for a tug fleet to attach to multiple/all ships/stations in another fleet without having to manually select every ship/station you want to have towed (this should probably limit up to either the amount of ships in the tug fleet or the amount of tractor beams in it or the beams' lift capacity).  I'd also suggest allowing the tugs to tow station fleets without breaking said fleets since it's a bit annoying to have a batch of stations (especially ones liable to be moved) be put into a fleet, towed to a site and find your fleet has been broken into individual ship units when it reaches its (possibly temporary) destination.

2) I mentioned this partially in my last post on this thread ala allowing sub-fleet components to spread out so recon or survey could run from a single fleet but multiple separated elements, but it could also be useful to allow full fleets to spread across an amount of territory with being split up (particularly if it's something like a group of terraforming/harvesting/mining stations being dragged into position as above) because they're in motion or they're immobile and there's not enough tugs on hand to move everything at once.

3) Allow us to set up 'colony types' along with base rules for them.  I know Aurora will take what we put at a 'colony' into account to decide whether it's a mining site, populated colony, archaeological dig, listening post, civilian mining site or 'other' and we can limit whether civilians visit, but it could be useful to allow us some extra control like allowing us to set digs to being excluded from civilian traffic by default so we don't suddenly get civilians dropping colonists there because we unearthed some usable building and forgot to say we don't want civilians involved in the site or tag which asteroids/moons/planets are just for mining over population before we start shipping automines over there.

(1) would be great as long as the limit remains one ship per tug. I'm not sure how much work it would be to code, but something similar exists for squadron jumping so it's certainly possible.

(2) Isn't really needed. You can detach a subfleet from a fleet into its own fleet and then have it rejoin later with the "Rejoin as Subfleet" order. Presently this is necessary since Aurora is coded so that every separate formation on the tactical map is a "fleet" and fleets don't have a hierarchy of fleets under them. However, the one reason I can think of why this would be needed would be if you have a flag bridge and want your ships to keep the bonus from that officer when they split off. Maybe a good way to implement this would be that a flag bridge functions like a naval admin command?

(3) I'm not sure what really needs to be added here. Currently we have the ability to ban civilian traffic from a body, civilian shipping as far as I know will not ship infrastructure and colonists to a colony that doesn't already have such things (e.g. a listening post or xenoarcheology dig), and CMCs as far as I know will not establish themselves on any body that already has a racial colony even if the colony is empty. These functions seem adequate to control civilian behavior pretty reliably as-is.
Title: Re: C# Suggestions
Post by: liveware on December 07, 2020, 11:03:37 PM
I would really like to see ships be given a maneuver rating similar to missiles which would affect their chance to hit and chance to be hit. Missiles already have this option and it makes for much more interesting design choices than ships currently posses. Implementing maneuverability by way of a new 'maneuvering thruster' component might be a good way to implement it, as the additional component weight of the maneuvering thrusters would compete with hull space which would otherwise be used for other components (like engines/armor).
Title: Re: C# Suggestions
Post by: Shuul on December 08, 2020, 05:25:30 AM
Steve, may i suggest to add a new hangar module called "external clamps" or similar ?

It will serve the purpose of transporting small ships but without ability to resupply or repair them in any way, just carry and hold of maintenance clock. Size should be smaller than regular docks.

Im planning to RP Galactic Empire for 1.13 release and really wanted to have ships like Gozanti assault carriers with 4 TIE fighters attached like in this pic
(https://www.belloflostsouls.net/wp-content/uploads/2015/12/swx35_preview2.jpg)
but current hangar types do not really suit it.

I guess this type of dock will also give some interesting RP possibility for others.
Title: Re: C# Suggestions
Post by: Ghrathryn on December 08, 2020, 07:40:07 AM
Quote from: nuclearslurpee link=topic=10640. msg144185#msg144185 date=1607388167
(1) would be great as long as the limit remains one ship per tug.  I'm not sure how much work it would be to code, but something similar exists for squadron jumping so it's certainly possible.

(2) Isn't really needed.  You can detach a subfleet from a fleet into its own fleet and then have it rejoin later with the "Rejoin as Subfleet" order.  Presently this is necessary since Aurora is coded so that every separate formation on the tactical map is a "fleet" and fleets don't have a hierarchy of fleets under them.  However, the one reason I can think of why this would be needed would be if you have a flag bridge and want your ships to keep the bonus from that officer when they split off.  Maybe a good way to implement this would be that a flag bridge functions like a naval admin command?

(3) I'm not sure what really needs to be added here.  Currently we have the ability to ban civilian traffic from a body, civilian shipping as far as I know will not ship infrastructure and colonists to a colony that doesn't already have such things (e. g.  a listening post or xenoarcheology dig), and CMCs as far as I know will not establish themselves on any body that already has a racial colony even if the colony is empty.  These functions seem adequate to control civilian behavior pretty reliably as-is.

With regards to 2, I hadn't thought about that, but it's somewhat annoying to have either to a) constantly split and merge fleet containing multiple survey ships if you want them to hit multiple targets at once or if you have two classes of ship and some only work for geosurvey while others only work for gravsurvey but you want them organised into a single fleet most of the time so they can all be sent to different systems together, but split them up every new system to run the survey.  Presuming you've got the standing orders set, you'll be ordering them to split and merge every time you move system.  Being able to use sub-fleets as separate manoeuvre entities would be a big help, even if when tugging a station or damaged ship the entity gets made into a sub-fleet, it'll mean we keep the existing structure and don't have to keep remaking it if things happen or if you need things to move on their own rather than with their assigned fleet.

There's also, as mentioned, point b) You've a station group you want to use together, but from what I've seen as soon as a tug tractors a station, it'll make that station its own fleet meaning you're constantly having to reorganise when you've got stations running mining, fuel gathering, maintenance, terraforming, etc and you need to move them around to a new locale.  (Luna finishes terraforming, move stations to Mars, Venus, Mercury, etc or Jupiter is out of Sorium, shunt the fuel harvester station group to Saturn, Uranus, Neptune or some outsystem gas giant without losing their grouping).

On point 3, the issue I've found is more for arch digs in that as soon as you have a construction ground unit dig up a working civ building, it turns it from a dig to a hab world at which point, particularly if the building is 'x infrastructure', civilian colony ships jump in and deliver population, which you might not want and might not realise until you check the eco screen.  Yes you can tell the civvies not to have anything to do with a colony, but when there's a change due to an event, if you're not checking things when you set a colony, you can wind up having the AI screw you up, particularly if the dig is a high cost planet like Venus, or one you never want colonised even if it's 'viable'.  The other thing for automines is more a visual aid.  Most colonies we create start as 'other' unless they've got a ruin on site, but auto-mine sites change colour in the fleet orders menu, and shuffle around if you've got 'view by role' on the eco screen, allowing a quick reference for where you're aiming to actually colonise/terraform versus where you just want mines prior to sending anything there, particularly if it's something that might take a while to do because you've got to build things first.

It doesn't even need to be much, just allow us to decide without dropping anything what body has a particular classification of colony and don't auto-change it.  Space Empires IV and V allowed you to pick a colony type as a player, so just letting us set and reassign so we keep digs as digs and can see our locales for mines/pops if we have to return to things later and have forgotten what's supposed to be what would help.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 08, 2020, 11:36:24 AM
On point 3, the issue I've found is more for arch digs in that as soon as you have a construction ground unit dig up a working civ building, it turns it from a dig to a hab world at which point, particularly if the building is 'x infrastructure', civilian colony ships jump in and deliver population, which you might not want and might not realise until you check the eco screen.  Yes you can tell the civvies not to have anything to do with a colony, but when there's a change due to an event, if you're not checking things when you set a colony, you can wind up having the AI screw you up, particularly if the dig is a high cost planet like Venus, or one you never want colonised even if it's 'viable'.  The other thing for automines is more a visual aid.  Most colonies we create start as 'other' unless they've got a ruin on site, but auto-mine sites change colour in the fleet orders menu, and shuffle around if you've got 'view by role' on the eco screen, allowing a quick reference for where you're aiming to actually colonise/terraform versus where you just want mines prior to sending anything there, particularly if it's something that might take a while to do because you've got to build things first.

It doesn't even need to be much, just allow us to decide without dropping anything what body has a particular classification of colony and don't auto-change it.  Space Empires IV and V allowed you to pick a colony type as a player, so just letting us set and reassign so we keep digs as digs and can see our locales for mines/pops if we have to return to things later and have forgotten what's supposed to be what would help.

The "Military Restricted" flag should do what you want as it basically tells all civilian ships to avoid that body. When you establish a new dig site colony, in the Economics window / Civilian Economy tab there is a checkbox along the top row for "Military Restricted Colony" that per this comment from Steve (http://aurora2.pentarch.org/index.php?topic=8495.msg117794#msg117794) should cause civilian ships to avoid the body. If that isn't working it is probably a bug and should be reported.

N.B. you can rename a colony/population separately from the body it is on, so you could establish a colony on Mars for instance and call it "Mars Dig Site" to keep track of what it's for.
Title: Re: C# Suggestions
Post by: Ghrathryn on December 09, 2020, 05:09:25 AM
Quote from: nuclearslurpee link=topic=10640. msg144215#msg144215 date=1607448984
The "Military Restricted" flag should do what you want as it basically tells all civilian ships to avoid that body.  When you establish a new dig site colony, in the Economics window / Civilian Economy tab there is a checkbox along the top row for "Military Restricted Colony" that per this comment from Steve should cause civilian ships to avoid the body.  If that isn't working it is probably a bug and should be reported.

N. B.  you can rename a colony/population separately from the body it is on, so you could establish a colony on Mars for instance and call it "Mars Dig Site" to keep track of what it's for.
Yeah, presuming you remember to do it before a ground force with construction units find something that causes the arch dig to become a settlement or viable for one, as mentioned before.

Case in point, see attached.  I've not added anything to Mars or Venus in my current game as far as buildings are concerned, and Venus had a 6 building ruined site that's been cleared.  Both became auto-mines because the construction team found automines.  Mars could actually get a civilian colony ship show up if I hadn't already set it to military only, like Venus did in my last game, as they've already found infrastructure there.

I'm not arguing that what's there can't do the job, I'm requesting the ability to allow players to pick on colonise (and manually change after) and have templates to set things up automatically rather than rely on the AI recognition and have to remember to go into a tab you're likely not going to use unless you're establishing the colony for population to tell civilian ships that they're not allowed there just in case the AI decides that 'hey, this ruin has automines, it's an automine now' or 'hey, there's infrastructure here, send in the colonists'.

Honestly speaking, what tabs are ones you look at for a colony in general? Main economy tab and mining are probably the two I care about for most colonies, the others are pretty much only if there's a population, which if I'm not planning a population but find a ruin, could (and did) result in a populated colony where I don't want one right then, or a place being tagged wrong from the AI.

Hell, having templates for colony types could help with automation, because you can set as an example from my current game an automine colony template as needing 100 automines and 5 mass drivers delivered and have a cargo fleet set to automatically do those orders as a standing order.  You tell the game you want to colonise some asteroid, tell it that the rock is an automine and if there's available automines/mass drivers the fleet with standing orders will deliver, or it could even set a construction queue to the nearest populated colony and have those buildings reserved.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 09, 2020, 12:02:52 PM
Honestly speaking, what tabs are ones you look at for a colony in general? Main economy tab and mining are probably the two I care about for most colonies, the others are pretty much only if there's a population, which if I'm not planning a population but find a ruin, could (and did) result in a populated colony where I don't want one right then, or a place being tagged wrong from the AI.

Admittedly, putting the button somewhere more obvious such as the Summary tab would probably be a good idea.
Title: Re: C# Suggestions
Post by: Droll on December 10, 2020, 10:21:59 AM
Maybe a way to do STO missile combat is to treat formations with missile weapons like MFCs in combat as opposed to individual missile STO units. This would allow a player to target their STO weapons like they would with a ship while also creating useful grouping for STO missiles to prevent UI clutter/micro. (literally organizing missiles into batteries via the existing ground OOB system)

Its not without problems though - multiple types of missile launchers in the formation can complicate things (so a formation has an MFC for each missile type it has? Idk if that's a good solution)
                                               - this does nothing for the magazine issues.

The only idea I have for the magazine problem is to just assign and use missiles in the planetary stockpile and maybe create missile STO as a separate component under static type units whose tonnage/reload speed can vary based on magazine feed efficiency technologies - kinda like how the BFC quality of beam STOs is determined through normal BFC tech.
Title: Re: C# Suggestions
Post by: Garfunkel on December 10, 2020, 12:19:40 PM
Maybe a way to do STO missile combat is to treat formations with missile weapons like MFCs in combat as opposed to individual missile STO units. This would allow a player to target their STO weapons like they would with a ship while also creating useful grouping for STO missiles to prevent UI clutter/micro. (literally organizing missiles into batteries via the existing ground OOB system)

Its not without problems though - multiple types of missile launchers in the formation can complicate things (so a formation has an MFC for each missile type it has? Idk if that's a good solution)
                                               - this does nothing for the magazine issues.

The only idea I have for the magazine problem is to just assign and use missiles in the planetary stockpile and maybe create missile STO as a separate component under static type units whose tonnage/reload speed can vary based on magazine feed efficiency technologies - kinda like how the BFC quality of beam STOs is determined through normal BFC tech.

4 new modules for ground units:

1. Active Sensor
2. Missile Fire Control
3. Missile Launcher
4. Magazine

This actually matches well with the real-world - the notorious Russian S-300 system, for example, has different vehicles for different roles, it's not a single thing handles all because of the size and complexity of the systems. And that's just a Surface-to-Air missile, not a Surface-to-Space missile.

The AS and MFC parts could automatically draw their values from racial tech levels like STO units do, with the addition that player could type in a resolution the way we put in HQ value. Then the launcher module is just a single box of size X as determined by the player and the magazine module is X * Y in tons based on player input.

So an SSM formation would have at least four different units in it. This would be more complex than what STO formations are and of course, I have no idea how the code under the hood works if it's actually impossible to have the hooks to missiles as well as how to handle loadouts without turning the SSM unit/element/formation into a fake-ship at which point it becomes a PDC again which we don't want.
Title: Re: C# Suggestions
Post by: Droll on December 10, 2020, 01:33:54 PM
Maybe a way to do STO missile combat is to treat formations with missile weapons like MFCs in combat as opposed to individual missile STO units. This would allow a player to target their STO weapons like they would with a ship while also creating useful grouping for STO missiles to prevent UI clutter/micro. (literally organizing missiles into batteries via the existing ground OOB system)

Its not without problems though - multiple types of missile launchers in the formation can complicate things (so a formation has an MFC for each missile type it has? Idk if that's a good solution)
                                               - this does nothing for the magazine issues.

The only idea I have for the magazine problem is to just assign and use missiles in the planetary stockpile and maybe create missile STO as a separate component under static type units whose tonnage/reload speed can vary based on magazine feed efficiency technologies - kinda like how the BFC quality of beam STOs is determined through normal BFC tech.

4 new modules for ground units:

1. Active Sensor
2. Missile Fire Control
3. Missile Launcher
4. Magazine

This actually matches well with the real-world - the notorious Russian S-300 system, for example, has different vehicles for different roles, it's not a single thing handles all because of the size and complexity of the systems. And that's just a Surface-to-Air missile, not a Surface-to-Space missile.

The AS and MFC parts could automatically draw their values from racial tech levels like STO units do, with the addition that player could type in a resolution the way we put in HQ value. Then the launcher module is just a single box of size X as determined by the player and the magazine module is X * Y in tons based on player input.

So an SSM formation would have at least four different units in it. This would be more complex than what STO formations are and of course, I have no idea how the code under the hood works if it's actually impossible to have the hooks to missiles as well as how to handle loadouts without turning the SSM unit/element/formation into a fake-ship at which point it becomes a PDC again which we don't want.

This is great as it allows one greater customization over the overall missile STO system.
Magazine components could simply draw missiles from the planetary stockpile at a rate that depends on ammo feed efficiency. I think it would be easiest to add their magazine capacity to the formation that they are attached to though (or maybe their parent formation so you can have an ammo formation and a launcher formation).
This would also mean that like ships an M-STO formation would need to have a missile loadout option so the player can choose what missiles are loaded.

Some level of bespokeness/shipyness is unavoidable with M-STOs because they are fundamentally different that B-STOs in that they fire a projectile that is both strategically and tactically tracked. They just behave way differently. I think however that it is important that stuff like missile loadouts and magazine sizes remain consistent with what is going on with ships.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on December 10, 2020, 01:44:49 PM
Some level of bespokeness/shipyness is unavoidable with M-STOs...

Unfortunately, this is why old-style PDCs were removed in the first place.
Title: Re: C# Suggestions
Post by: Droll on December 10, 2020, 02:03:35 PM
Some level of bespokeness/shipyness is unavoidable with M-STOs...

Unfortunately, this is why old-style PDCs were removed in the first place.

PDCs were removed because they were literally ships with special rules - you could design a ship with no engines and it would literally be a PDC -5 armor.
Missile mechanics have to be same across ships and M-STOs because it wouldn't make sense for there to be a mechanical difference between a missile launched from the ground and from space.

What I am saying here is that there is common ground between M-STOs and missile ships - the missiles. With new ground mechanics M-STOs can be made so that they arent just ships with +5 armor and no engines, avoiding the pointlessness of PDCs while also not causing mechanical inconsistency.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on December 10, 2020, 02:29:13 PM
My understanding was that the shipyness caused actual bugs and code smell problems, not just an annoying "this is inconsistent" issue. But that's all second hand; I've never seen Steve's actual take.

Certainly, the new ground force system would need dramatic under the hood AND user facing changes to support missiles.
Title: Re: C# Suggestions
Post by: Droll on December 12, 2020, 04:46:24 PM
I would like the ability to filter out CMCs both in the misc tab when using SM to teleport fleets and the commander assignment menu when im trying to find my colony amongst a swarm of CMCs I've no interesting in putting people on.
Title: Re: C# Suggestions
Post by: db48x on December 13, 2020, 09:00:07 AM
I suggest that a few unobtrusive hint messages be added to various situations in the game.

Just to give a single concrete suggestion, perhaps instead of saying "Orders Completed  DD Sword of Retribution 002 has completed orders.", it could says "Orders Completed  DD Sword of Retribution 002 has completed orders, but there was insufficient fuel in the tanker to fully refuel. Or, indeed, for it to actually take on any fuel at all.".
Title: Re: C# Suggestions
Post by: 83athom on December 13, 2020, 10:40:38 PM
Something to go along with the carrier/fighter automatic assignment change; Give carriers an order that lets them "Resupply (Parasites) to Template Levels".

Secondly; The option to make multiple "loadouts" for carriers and missile armed ships that they will try to resupply to instead of doing it manually if you want to carry something else for a specific mission.
Title: Re: C# Suggestions
Post by: xenoscepter on December 14, 2020, 07:37:15 PM
 - I'd like to request a "Status Report" order, in response to these replies:

http://aurora2.pentarch.org/index.php?topic=12151.msg144548#msg144548

&

http://aurora2.pentarch.org/index.php?topic=12151.msg144555#msg144555
Title: Re: C# Suggestions
Post by: vorpal+5 on December 15, 2020, 01:16:13 AM
For Christmas  ;)  ;D, a super minor request, to help find faster commanders. When you select a ship in the Commander Window, have the commander selected (if you don't always want this behavior, just add a checkbox to enable the option).

Because right now finding the commander of a ship, when you want to switch allocations is rather convoluted.
Title: Re: C# Suggestions
Post by: Droll on December 15, 2020, 04:09:05 AM
For Christmas  ;)  ;D, a super minor request, to help find faster commanders. When you select a ship in the Commander Window, have the commander selected (if you don't always want this behavior, just add a checkbox to enable the option).

Because right now finding the commander of a ship, when you want to switch allocations is rather convoluted.

To add to the commander menu theme - right now when you open the commander menu, the bottom right section of the menu where you filter search through commanders by default is set to filter from lowest naval officer rank to highest. This causes problems with loading times later both when assigning commanders and when opening the commander menu (I currently have 4k officers in my game across all branches) as the filtered search refreshes the whole thing every time.
Title: Re: C# Suggestions
Post by: Migi on December 17, 2020, 05:19:18 PM
Speaking of commanders, within the commander search area, could you add a filter to only show unassigned commanders?

Title: Re: C# Suggestions
Post by: ChubbyPitbull on December 19, 2020, 05:26:55 PM
Finally discovered medals after how many years of playing and going a bit nutty. Loving the conditions for automatic award of medal conditions; would be nice if there could be a medals for #s of Worlds Terraformed, for those Terraforming ships or bases.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 20, 2020, 12:09:26 PM
In my current game I've run into an NPR only two systems from Sol, things have gone sour (they shot first!), and both parties now have large fleets camping both sides of a jump point, where my side happens to be Sol itself.

You would think that the NPR, knowing that it's at least a heavily-populated system of mine based on their response to my "Request Leave Urgently" (they didn't, but they said they would...R.I.P. their survey fleet) would reasonably presume that I'm camping my side of the jump point with a fairly sizable force, particularly given that they're doing the exact same thing on their side. However, they keep sending in small fleets which seem to consist of a civilian ship or two with some military escorts, which I have been shredding like clockwork with my triple laser turrets. Particularly, you'd think they'd have learned the first time they did that, or better yet before then when their survey fleet tried and failed to make a break for home.

As much as I enjoy turning Rindao scum into space dust as just punishment for being stupid (also, for shooting at me), maybe the AI would be better-served realizing that if it is literally camping a jump point, the other guy might be doing the same thing, and sending salvage ships through might be a bit premature if not an outright Bad Idea™.
Title: Re: C# Suggestions
Post by: Froggiest1982 on December 20, 2020, 02:37:36 PM
this was in the changes discussion but as it turns out I am making a suggestion out of my answer.

Perhaps an option to make all mineral deposits infinite with the option to choose individually whether they are infinite on planets, moons, and asteroids/comets.

I remember I did once played a game humans only+ spoiler races no NPRs and where I have disabled all mineral techs (capped at 10) and every mineral source found would have to be reduced to 0.1 access and increased to 100,000,000 tons.

The point of the test was not to have mineral difficulties, as after a while in Aurora it hardly is because the issue is mere a logistical one, but to face bottlenecks due to a scarcity of minerals directly in the stockpile.

I don't remember if it ended up because I got bored or because there were too many interruptions...it may have been both.

I think, while having the minerals to mine is a great thing, we should have also some sort of limitation in game to avoid piling up minerals to the point that find new better sources are almost useless. Beware, this is mid game problem as when you grow big then you need access to more minerals either because the one left behind have been depleted or it would take simply too long to transport.

I was thinking maybe we could get a sort of stockpile mechanic? I mean a physical one. So let's say that as we have capped pop related to planets, we could have the same on stock. For instance Luna would be able to "stock" 1,000,000 tons of minerals (you can expand through a dedicated structure) while Mars and Earth more as they are bigger. This would impact the asteroids which are small and making collection centers more of a thing. To reflect Aurora Mineral mechanics the cap should go per mineral and not on the total so the 1,000,000 will be divided by the amount of minerals available and not summed up. So if you have 2 minerals on Luna you will have 500,000+500,000 stock otherwise if you have 10 it will be 100,000 each.

As this could create issues with load and pick, considering we already have the wait until full order an unload until empty one could be added?
Title: Re: C# Suggestions
Post by: Droll on December 20, 2020, 02:46:59 PM
this was in the changes discussion but as it turns out I am making a suggestion out of my answer.

Perhaps an option to make all mineral deposits infinite with the option to choose individually whether they are infinite on planets, moons, and asteroids/comets.

I remember I did once played a game humans only+ spoiler races no NPRs and where I have disabled all mineral techs (capped at 10) and every mineral source found would have to be reduced to 0.1 access and increased to 100,000,000 tons.

The point of the test was not to have mineral difficulties, as after a while in Aurora it hardly is because the issue is mere a logistical one, but to face bottlenecks due to a scarcity of minerals directly in the stockpile.

I don't remember if it ended up because I got bored or because there were too many interruptions...it may have been both.

I think, while having the minerals to mine is a great thing, we should have also some sort of limitation in game to avoid piling up minerals to the point that find new better sources are almost useless. Beware, this is mid game problem as when you grow big then you need access to more minerals either because the one left behind have been depleted or it would take simply too long to transport.

I was thinking maybe we could get a sort of stockpile mechanic? I mean a physical one. So let's say that as we have capped pop related to planets, we could have the same on stock. For instance Luna would be able to "stock" 1,000,000 tons of minerals (you can expand through a dedicated structure) while Mars and Earth more as they are bigger. This would impact the asteroids which are small and making collection centers more of a thing. To reflect Aurora Mineral mechanics the cap should go per mineral and not on the total so the 1,000,000 will be divided by the amount of minerals available and not summed up. So if you have 2 minerals on Luna you will have 500,000+500,000 stock otherwise if you have 10 it will be 100,000 each.

As this could create issues with load and pick, considering we already have the wait until full order an unload until empty one could be added?

I always tend to gravitate to something similar to this. The initial scarcity problem is a very compelling one to navigate but once it stops being a problem not only is it not hard to find new sources, it becomes tedious to do so.
Title: Re: C# Suggestions
Post by: Borealis4x on December 20, 2020, 09:43:48 PM
I've suggested this previously, but I'd really like it if Steve added a larger Formation Template Constructor. My smallest formation is a company, so to make Regiment I need to train 16 companies, and thats not including HQs or Logistics. It'd be really great if I could just create preset Regiment templates out of existing smaller templates.

I suppose this would have to change how Ground Unit Construction Complexes work, seeing as right now they only train one unit at a time regardless of size. I think they should work more like Construction Factories and generate a number of Ground Unit Construction Points a tick to contribute towards building ground units.
Title: Re: C# Suggestions
Post by: spartacus on December 22, 2020, 11:13:20 AM
this was in the changes discussion but as it turns out I am making a suggestion out of my answer.

Perhaps an option to make all mineral deposits infinite with the option to choose individually whether they are infinite on planets, moons, and asteroids/comets.

I remember I did once played a game humans only+ spoiler races no NPRs and where I have disabled all mineral techs (capped at 10) and every mineral source found would have to be reduced to 0.1 access and increased to 100,000,000 tons.

The point of the test was not to have mineral difficulties, as after a while in Aurora it hardly is because the issue is mere a logistical one, but to face bottlenecks due to a scarcity of minerals directly in the stockpile.

I don't remember if it ended up because I got bored or because there were too many interruptions...it may have been both.

I think, while having the minerals to mine is a great thing, we should have also some sort of limitation in game to avoid piling up minerals to the point that find new better sources are almost useless. Beware, this is mid game problem as when you grow big then you need access to more minerals either because the one left behind have been depleted or it would take simply too long to transport.

I was thinking maybe we could get a sort of stockpile mechanic? I mean a physical one. So let's say that as we have capped pop related to planets, we could have the same on stock. For instance Luna would be able to "stock" 1,000,000 tons of minerals (you can expand through a dedicated structure) while Mars and Earth more as they are bigger. This would impact the asteroids which are small and making collection centers more of a thing. To reflect Aurora Mineral mechanics the cap should go per mineral and not on the total so the 1,000,000 will be divided by the amount of minerals available and not summed up. So if you have 2 minerals on Luna you will have 500,000+500,000 stock otherwise if you have 10 it will be 100,000 each.

As this could create issues with load and pick, considering we already have the wait until full order an unload until empty one could be added?


I like this idea, the only caveat I would add is a mechanism to discontinue the mining of a resource once the stockpile for it was full.  I have played games with stockpile restrictions before where the resource in the ground continues to diminish every turn due to mining even though there is no place to put what is being mined so it just teleports into an unreachable dimension.
Title: Re: C# Suggestions
Post by: spartacus on December 22, 2020, 11:47:15 AM
This is an idea that would probably take too much work for Steve and may not be well received, however I just wanted to throw it out there.  I have seen many posts about weapons systems that are only useful for roleplaying and similarly if you are really trying to win in the most efficient way you research these techs and build these ships etc.

What if there was a small but significant amount of RNG put into the various techs at the start of every game.  The idea being that in one gameplay the lasers might well be the way to go, however the next time with the same exact setup it may be plasma or mesons etc.  The player wouldn't know before actually doing the research how effective any one weapon system would be in that particular game requiring one to experiment and find a different path each game.

I think this would be great for roleplaying as well, those who like to assign different preferences to different groups in the multiplayer starts would no longer feel constricted by considerations like well this isn't right because now this group has the weakest weapon system because you wouldn't know beforehand who had what.

I know this would be very difficult as a range would need to be arrived at for each system so that the weapons were not useless on the bottom end and not superpowered on the top end.  This would have to be balanced enough however that the value of the systems would change in relation to each other depending on where they were assigned in the range when the game was generated.

Perhaps a check box could be added at game setup for those that preferred the current system as opposed to this proposal.
Title: Re: C# Suggestions
Post by: RougeNPS on December 22, 2020, 12:16:46 PM
Im not even sure if this is a good idea or not but a communications array/module or whatever you want to call it, that would increase the chance of successful communication between species.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on December 22, 2020, 01:19:48 PM
Im not even sure if this is a good idea or not but a communications array/module or whatever you want to call it, that would increase the chance of successful communication between species.

Diplomatic module does this if you assign a CO with a communications bonus.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 22, 2020, 01:59:47 PM
This is an idea that would probably take too much work for Steve and may not be well received, however I just wanted to throw it out there.  I have seen many posts about weapons systems that are only useful for roleplaying and similarly if you are really trying to win in the most efficient way you research these techs and build these ships etc.

What if there was a small but significant amount of RNG put into the various techs at the start of every game.  The idea being that in one gameplay the lasers might well be the way to go, however the next time with the same exact setup it may be plasma or mesons etc.  The player wouldn't know before actually doing the research how effective any one weapon system would be in that particular game requiring one to experiment and find a different path each game.

I think this would be great for roleplaying as well, those who like to assign different preferences to different groups in the multiplayer starts would no longer feel constricted by considerations like well this isn't right because now this group has the weakest weapon system because you wouldn't know beforehand who had what.

I know this would be very difficult as a range would need to be arrived at for each system so that the weapons were not useless on the bottom end and not superpowered on the top end.  This would have to be balanced enough however that the value of the systems would change in relation to each other depending on where they were assigned in the range when the game was generated.

Perhaps a check box could be added at game setup for those that preferred the current system as opposed to this proposal.

Without giving the player some sort of indication, what you're suggesting basically amounts to a player getting randomly screwed by their research choices with no way of predicting that this will happen, no way of actually knowing if they're on the optimal path (if I start with lasers and they are 5% stronger than normal, there's no guarantee that I'm not missing a better weapons system at 15% stronger than normal), and the only way to elucidate the mechanic is to dump a massive amount of precious early-game RPs into weapons research, or else pick one and hope you got luckier than the NPRs.

Presently, while some weapons are pretty clearly optimal all of them except maybe plasma have a place in a well-developed doctrine, and even plasma is cheap enough RP-wise that you can slot it into most doctrines as a short-ranged "bomber" weapon if you want to. The thing is that not every weapon or more accurately combination of weapons is suitable as a standalone armament, as really only missiles, lasers, and railguns can be used as standalone fleet armaments as these have both point defense/AMM and anti-ship capabilities. In this sense, the "optimal" play is to pick one of those three weapons systems and use only that weapon to minimize RP investment which maximizes RP available for other things like engines, however going the "RP" route of using additional weapon types is not much worse than this "optimal" route and in fact for the RP invested can give overall stronger ships since other weapon types are more specialized - for example, a laser-based fleet can benefit from Gauss turrets for more effective point defense or HPM secondary weapons to deal with shielded opponents against which the armor penetration of lasers is otherwise mitigated.

Aurora is always going to have a fairly boring "optimal" path, as is the case for nearly any strategy game that revolves around maximizing the efficiency of limited resources...this is why metagaming exists in nearly every game since the dawn of gaming. However, Aurora generally does very well at ensuring that the "optimal" is not too far ahead of various other, more interesting strategies so that players can pursue fun alternatives without being heavily underpowered, and I think this is a better goal from a design perspective than trying to add opaque randomness into the game just to upset or eliminate the meta strategies.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 22, 2020, 03:12:31 PM
Suggestion, unrelated to the above post:

On the Galactic Map, it would be neat to have a faintly-visible grid behind the system balls to help with aligning systems neatly. For example having lines every x or y = +/- 140, 280, 420, ... as this is the increment the game uses by default for new systems. The current snap-to-grid button seems to snap systems to the nearest increment of 20 in x and y, which is a good amount but having a visible grid would be helpful for more complex arrangements, most prominently anything involving diagonal lines.
Title: Re: C# Suggestions
Post by: Garfunkel on December 22, 2020, 11:44:45 PM
this was in the changes discussion but as it turns out I am making a suggestion out of my answer.

Perhaps an option to make all mineral deposits infinite with the option to choose individually whether they are infinite on planets, moons, and asteroids/comets.

I remember I did once played a game humans only+ spoiler races no NPRs and where I have disabled all mineral techs (capped at 10) and every mineral source found would have to be reduced to 0.1 access and increased to 100,000,000 tons.

The point of the test was not to have mineral difficulties, as after a while in Aurora it hardly is because the issue is mere a logistical one, but to face bottlenecks due to a scarcity of minerals directly in the stockpile.

I don't remember if it ended up because I got bored or because there were too many interruptions...it may have been both.

I think, while having the minerals to mine is a great thing, we should have also some sort of limitation in game to avoid piling up minerals to the point that find new better sources are almost useless. Beware, this is mid game problem as when you grow big then you need access to more minerals either because the one left behind have been depleted or it would take simply too long to transport.

I was thinking maybe we could get a sort of stockpile mechanic? I mean a physical one. So let's say that as we have capped pop related to planets, we could have the same on stock. For instance Luna would be able to "stock" 1,000,000 tons of minerals (you can expand through a dedicated structure) while Mars and Earth more as they are bigger. This would impact the asteroids which are small and making collection centers more of a thing. To reflect Aurora Mineral mechanics the cap should go per mineral and not on the total so the 1,000,000 will be divided by the amount of minerals available and not summed up. So if you have 2 minerals on Luna you will have 500,000+500,000 stock otherwise if you have 10 it will be 100,000 each.

As this could create issues with load and pick, considering we already have the wait until full order an unload until empty one could be added?


I like this idea, the only caveat I would add is a mechanism to discontinue the mining of a resource once the stockpile for it was full.  I have played games with stockpile restrictions before where the resource in the ground continues to diminish every turn due to mining even though there is no place to put what is being mined so it just teleports into an unreachable dimension.

If you want infinite minerals for a turtle game, you can just use SM to add 100 million tons of all 11 minerals on Earth and if you do happen to mine it all out, rinse ^ repeat. It's really not difficult.

The stockpile limitation idea is a bit bonkers. Population density at least makes sense and is based on human demographics vis-a-vis Earth. But that's because humans require space and food and water and air = minerals do not. You can literally stack them on top of each other endlessly until the mass reaches singularity or something. Million tons sounds like a lot but it really isn't - it's peanuts. In 2019, we mined 7921 million tons of coal alone on Earth and I don't remember seeing giant piles of coal anywhere. This means that either the limits are ludicrously small, like in some 4X games where a planet can inexplicably only hold a handful of buildings, or they are "realistically" sized which makes them completely pointless.
Title: Re: C# Suggestions
Post by: spartacus on December 23, 2020, 12:05:19 AM
This is an idea that would probably take too much work for Steve and may not be well received, however I just wanted to throw it out there.  I have seen many posts about weapons systems that are only useful for roleplaying and similarly if you are really trying to win in the most efficient way you research these techs and build these ships etc.

What if there was a small but significant amount of RNG put into the various techs at the start of every game.  The idea being that in one gameplay the lasers might well be the way to go, however the next time with the same exact setup it may be plasma or mesons etc.  The player wouldn't know before actually doing the research how effective any one weapon system would be in that particular game requiring one to experiment and find a different path each game.

I think this would be great for roleplaying as well, those who like to assign different preferences to different groups in the multiplayer starts would no longer feel constricted by considerations like well this isn't right because now this group has the weakest weapon system because you wouldn't know beforehand who had what.

I know this would be very difficult as a range would need to be arrived at for each system so that the weapons were not useless on the bottom end and not superpowered on the top end.  This would have to be balanced enough however that the value of the systems would change in relation to each other depending on where they were assigned in the range when the game was generated.

Perhaps a check box could be added at game setup for those that preferred the current system as opposed to this proposal.

Without giving the player some sort of indication, what you're suggesting basically amounts to a player getting randomly screwed by their research choices with no way of predicting that this will happen, no way of actually knowing if they're on the optimal path (if I start with lasers and they are 5% stronger than normal, there's no guarantee that I'm not missing a better weapons system at 15% stronger than normal), and the only way to elucidate the mechanic is to dump a massive amount of precious early-game RPs into weapons research, or else pick one and hope you got luckier than the NPRs.

Presently, while some weapons are pretty clearly optimal all of them except maybe plasma have a place in a well-developed doctrine, and even plasma is cheap enough RP-wise that you can slot it into most doctrines as a short-ranged "bomber" weapon if you want to. The thing is that not every weapon or more accurately combination of weapons is suitable as a standalone armament, as really only missiles, lasers, and railguns can be used as standalone fleet armaments as these have both point defense/AMM and anti-ship capabilities. In this sense, the "optimal" play is to pick one of those three weapons systems and use only that weapon to minimize RP investment which maximizes RP available for other things like engines, however going the "RP" route of using additional weapon types is not much worse than this "optimal" route and in fact for the RP invested can give overall stronger ships since other weapon types are more specialized - for example, a laser-based fleet can benefit from Gauss turrets for more effective point defense or HPM secondary weapons to deal with shielded opponents against which the armor penetration of lasers is otherwise mitigated.

Aurora is always going to have a fairly boring "optimal" path, as is the case for nearly any strategy game that revolves around maximizing the efficiency of limited resources...this is why metagaming exists in nearly every game since the dawn of gaming. However, Aurora generally does very well at ensuring that the "optimal" is not too far ahead of various other, more interesting strategies so that players can pursue fun alternatives without being heavily underpowered, and I think this is a better goal from a design perspective than trying to add opaque randomness into the game just to upset or eliminate the meta strategies.

I understand your concerns and that was why I suggested an option at setup to use this or not.  However I do believe what you characterize as a player getting randomly screwed is actually how things go IRL.  Today I just happened to be browsing through a list of failed aircraft, both civilian and military that were designed and built with high hopes and just didn't work out as planned.

Something that we are all probably familiar with today that speaks to this is all of the vaccines that are under development some of which are now out for use but some of which are failed and no longer being pursued.  I don't see this as the player being randomly screwed I just see this as more of a situation that exists where you don't know exactly what the return will be on the research path you choose and you will either live with pushing down a certain line of research even though there may be a better one or more broadly pushing several paths to get a feel for which might be the best way to go this particular time. 

If research and development was as cut and dried as we find it in games than every country would field basically the same tanks, planes and ships.  This is not the case because real research has a huge degree of uncertainty and results are often not what was anticipated when the project was begun.
Title: Re: C# Suggestions
Post by: dag0net on December 23, 2020, 12:47:40 AM
Yes, but a part of gaming is people trying to wrap themselves up in the illusion of a simple, orderly & predictable environment where they can exercise a level of control lacking elsewhere. :)
Title: Re: C# Suggestions
Post by: Barkhorn on December 23, 2020, 12:51:05 AM
I love this idea.  I've always somewhat been annoyed by games like Civilization where you can see the whole tech tree in the stone age and plan out your development from pottery to microchips.  Hammurabi didn't sit around planning like "hmm, I'll get bronze working now, then writing so I can start building libraries.  By ~1500AD I should be making ~600 science per turn and working on acoustics".
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 23, 2020, 12:52:07 AM
I understand your concerns and that was why I suggested an option at setup to use this or not.  However I do believe what you characterize as a player getting randomly screwed is actually how things go IRL.  Today I just happened to be browsing through a list of failed aircraft, both civilian and military that were designed and built with high hopes and just didn't work out as planned.

Something that we are all probably familiar with today that speaks to this is all of the vaccines that are under development some of which are now out for use but some of which are failed and no longer being pursued.  I don't see this as the player being randomly screwed I just see this as more of a situation that exists where you don't know exactly what the return will be on the research path you choose and you will either live with pushing down a certain line of research even though there may be a better one or more broadly pushing several paths to get a feel for which might be the best way to go this particular time. 

If research and development was as cut and dried as we find it in games than every country would field basically the same tanks, planes and ships.  This is not the case because real research has a huge degree of uncertainty and results are often not what was anticipated when the project was begun.

One of the tricky things about a game, even a "realistic" one, is that real life itself actually makes a terrible game. This is because a game is at the end of the day meant to be fun, while real life has no such developer's mandate and no such need to sell copies/pad download numbers. I don't believe that for most players, failing at random would be considered "fun" - if anything, random elements in games work best when they make a game unpredictable and present challenges for a player to overcome - Precursors are an excellent example of this.

As a player however, Aurora gives you considerable leeway for roleplay and that means you can have the freedom and flexibility to play in such a way that you get a mix of successful and failed component and ship designs if you choose to play more experimentally instead of seeking the purely optimal designs. Sure, you can just build every ship with 50% engine mass and railguns, or lock onto a whole-hog carrier + missile bomber doctrine which is proven to be highly effective, but where's the fun in that? (Rhetorical question; for many people this is fun and they are very happy with it. Weirdos...)

There are really quite a lot of variables in Aurora to design with, so certainly it's possible to design and build many "failed" designs in the process of finding a good balance of different components or even the doctrine of the designs. In my current campaign I ran into an aggressive NPR very early and had to wage a tense defense with my starting ship designs and insufficient logistics to support them. Notably my mixed torpedo bomber / Gauss fighters ran into numerous problems due to a combination of superior enemy tech (the NPR invested a lot of RP into shields) and, uh, poor naval doctrine (also known as PEBKAC) and were ineffective. Because of this, my next generation of carrier fighters will be designed very differently, as my initial designs did not work out as well as planned or hoped for (much like, incidentally, the IRL British carrier aircraft they were based on).

The difference here is that as a player of a game, I can recognize where my plans failed and devise an approach to correct those failures. The research system in Aurora lacks that capability in the sense that it exists in real life. In reality, if a new technology or vehicle doesn't work out, the researchers learn from how that technology performed and figure out what needs to be fixed in the next designs. In Aurora we don't have that aspect in the research mechanic itself, and adding a random modifier doesn't give that either - if my tech fails, I can't learn anything from it, all I can do is roll the dice again (for the low, low price of another 5,000 RP).
Title: Re: C# Suggestions
Post by: Jorgen_CAB on December 23, 2020, 05:35:14 AM
This is an idea that would probably take too much work for Steve and may not be well received, however I just wanted to throw it out there.  I have seen many posts about weapons systems that are only useful for roleplaying and similarly if you are really trying to win in the most efficient way you research these techs and build these ships etc.

What if there was a small but significant amount of RNG put into the various techs at the start of every game.  The idea being that in one gameplay the lasers might well be the way to go, however the next time with the same exact setup it may be plasma or mesons etc.  The player wouldn't know before actually doing the research how effective any one weapon system would be in that particular game requiring one to experiment and find a different path each game.

I think this would be great for roleplaying as well, those who like to assign different preferences to different groups in the multiplayer starts would no longer feel constricted by considerations like well this isn't right because now this group has the weakest weapon system because you wouldn't know beforehand who had what.

I know this would be very difficult as a range would need to be arrived at for each system so that the weapons were not useless on the bottom end and not superpowered on the top end.  This would have to be balanced enough however that the value of the systems would change in relation to each other depending on where they were assigned in the range when the game was generated.

Perhaps a check box could be added at game setup for those that preferred the current system as opposed to this proposal.

In my opinion it would make allot more sense if each and individual component would have a small random variation of its efficiency for every parameter when researched. If you research a size 10 engine then its fuel efficiency will vary with +/- 10% its power will vary with +/- 10%. If you are no happy with the component you have to spend more research point to perhaps get a better one.

In addition to this you cold then increase research project by allowing more time to be invested to increase the chance for a better more effective component such as if you use two times the RP you are sure to end up with 0-10% more efficiency rather than -10% to 10% variation.

I would understand if this would be problematic for some people as they MUST have ships being exactly the same in some respect which might be problematic with this rules change. If could be optional, but I'm no fan of optional rules.

Personally I would like for research to be a bit less certain of the final result and you simply will have to live with the results.

I also think that it is not super realistic that a size 1 component takes half the time to research from a s size 2 component. I think there should be more of a logarithmic scale to research times of components in most circumstances.
Title: Re: C# Suggestions
Post by: spartacus on December 23, 2020, 10:27:15 AM
I am glad some people see some merit to this idea or a variation of it.  I must not have been clear in my original post the idea was not to make some tech lines completely ineffective.  Just to alter the balance changing which ones were better.  As Aurora stands now it is very winnable even when utilizing inferior techs, many have roleplayed this and still come out on top, and I wouldn't want this to change.  The point to this being that no one wants a game where the roll of the dice at the beginning determines whether or not you win or lose.

For me with a lot of games some of the first play throughs are the most fun just because you don't know what is the best way to go and there is a lot of experimenting to find out which ways are good for what you are trying to do.  This idea was a way to perhaps extend that early joy of discovery and newness throughout the time playing the game.  I know we can pretend we don't know and roleplay inferior paths to increase the challenge and that is fine, however I guess maybe I am just not as good at pretending as some because I always know what I really know to be true. 

To borrow from the season I like to look at research results like Christmas presents and they are always much more fun when what is inside is a surprise instead of knowing what you will get every time over and over again.

I would be open to any system that could replicate this type of experience so I can see some merit to the idea Jorgen_CAB had about shifting this to the components, I am not a programmer and don't know which way would be harder for Steve to change the game.  As I said originally I am afraid that any of this would be too much effort and require a major reworking of the game. 

To sum up for me it would just be fun to sit down at the beginning and have some mystery every game to the choices I would make at the beginning of the game.  I realize that this would not be for everyone but I think it would appeal to more than just me alone and for those that aren't interested I see nothing wrong with the way anyone chooses to play the game as long as they have fun doing it.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 23, 2020, 12:18:30 PM
In my opinion it would make allot more sense if each and individual component would have a small random variation of its efficiency for every parameter when researched. If you research a size 10 engine then its fuel efficiency will vary with +/- 10% its power will vary with +/- 10%. If you are no happy with the component you have to spend more research point to perhaps get a better one.

In addition to this you cold then increase research project by allowing more time to be invested to increase the chance for a better more effective component such as if you use two times the RP you are sure to end up with 0-10% more efficiency rather than -10% to 10% variation.

I would understand if this would be problematic for some people as they MUST have ships being exactly the same in some respect which might be problematic with this rules change. If could be optional, but I'm no fan of optional rules.

Personally I would like for research to be a bit less certain of the final result and you simply will have to live with the results.

I also think that it is not super realistic that a size 1 component takes half the time to research from a s size 2 component. I think there should be more of a logarithmic scale to research times of components in most circumstances.

This would be a much more reasonable system. Instead of crippling entire research paths through dice rolls this works on an individual component level and should broadly average out over time and many components, which should provide some interesting flavor and design decisions at a fairly small level, also encouraging a larger variety of components perhaps even with the same set of techs. Additionally since player and NPR research work differently this would not affect the NPRs negatively which is great.
Title: Re: C# Suggestions
Post by: Droll on December 23, 2020, 02:24:01 PM
Option to disable CMCs for those planned economy enthusiasts
Title: Re: C# Suggestions
Post by: Garfunkel on December 24, 2020, 04:27:06 AM
That research thing probably deserves a thread of its own where it can be hashed out further as it is a complex topic.

Option to disable CMCs for those planned economy enthusiasts
Are they not disabled together with shipping lines?
Title: Re: C# Suggestions
Post by: Droll on December 24, 2020, 04:31:26 AM
Option to disable CMCs for those planned economy enthusiasts
Are they not disabled together with shipping lines?

Nop. I'm playing a no civie game right now and they are building their CMCs regardless.
Title: Re: C# Suggestions
Post by: spartacus on December 24, 2020, 08:03:32 AM
That research thing probably deserves a thread of its own where it can be hashed out further as it is a complex topic.


Admittedly I am biased, but I do think it is an interesting concept that could potentially add a lot of flavor to the game for a lot of people.  Steve would really need to comment on it's viability however before people get all worked up about it.  It seems to be more polarizing, at least to some, than I thought it would be and if it is simply unworkable or Steve is not interested in it at all then there is no real reason to pursue or argue about it.
Title: Re: C# Suggestions
Post by: xenoscepter on December 24, 2020, 12:49:11 PM
Option to disable CMCs for those planned economy enthusiasts
Are they not disabled together with shipping lines?

Nop. I'm playing a no civie game right now and they are building their CMCs regardless.

 - Seconded. Can confirm that this is the case.  :)
Title: Re: C# Suggestions
Post by: db48x on December 24, 2020, 01:22:02 PM
In my opinion it would make allot more sense if each and individual component would have a small random variation of its efficiency for every parameter when researched. If you research a size 10 engine then its fuel efficiency will vary with +/- 10% its power will vary with +/- 10%. If you are no happy with the component you have to spend more research point to perhaps get a better one.

That's an interesting idea, but I fear that it's too readily exploitable. Players of a certain mindset would feel compelled to simply reroll every component they design until they get one that has the +10% bonus.

Perhaps instead, the formulas for component abilities should have an extra modifier that is randomized per-game. This modifier would apply equally to all components that have the same characteristics, so a boring action like rerolling would never help. It would also be predictable, so once you've figured it out you can take it into consideration.

A concrete example might help. Currently, the fuel consumption of an engine is determined by a formula: SQRT(10/Engine Size in HS). What if the formula was SQRT(10/Engine Size in HS) + 0.2 * sin(?*x+?), where ? and ? are random parameters choosen at game start and saved in the database. This would give some engines sizes a small bonus and other engine sizes a small penalty, and you wouldn't know which ahead of time.

I'm still not sure that this would be sufficiently interesting, but it would eliminate the compulsion.

I also think that it is not super realistic that a size 1 component takes half the time to research from a s size 2 component. I think there should be more of a logarithmic scale to research times of components in most circumstances.

This I can get behind. Military HQ research times get really ridiculous really quickly, since the HQ size is the primary factor.
Title: Re: C# Suggestions
Post by: Droll on December 24, 2020, 01:27:01 PM
I'm also dubious as to why above a certain HQ size the unit size stays the same. Is it to avoid large HQs getting targetted easily?
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 24, 2020, 02:19:49 PM
In my opinion it would make allot more sense if each and individual component would have a small random variation of its efficiency for every parameter when researched. If you research a size 10 engine then its fuel efficiency will vary with +/- 10% its power will vary with +/- 10%. If you are no happy with the component you have to spend more research point to perhaps get a better one.

That's an interesting idea, but I fear that it's too readily exploitable. Players of a certain mindset would feel compelled to simply reroll every component they design until they get one that has the +10% bonus.

Perhaps instead, the formulas for component abilities should have an extra modifier that is randomized per-game. This modifier would apply equally to all components that have the same characteristics, so a boring action like rerolling would never help. It would also be predictable, so once you've figured it out you can take it into consideration.

A concrete example might help. Currently, the fuel consumption of an engine is determined by a formula: SQRT(10/Engine Size in HS). What if the formula was SQRT(10/Engine Size in HS) + 0.2 * sin(?*x+?), where ? and ? are random parameters choosen at game start and saved in the database. This would give some engines sizes a small bonus and other engine sizes a small penalty, and you wouldn't know which ahead of time.

I'm still not sure that this would be sufficiently interesting, but it would eliminate the compulsion.

I think a deterministic approach like that would be more annoying than interesting, given that in many cases certain component sizes are standard for good reasons, e.g. size 25 for commercial engines until the player starts bumping up the size tech (and then usually size 40, 60, etc.), and even past that I wouldn't want to be constantly tweaking my engine designs +/- 1 HS just to dodge a poor modifier. Gauss cannons are another example where the sizes remain quite fixed. I suppose you can consider more factors than just size but then it's just complicated.

On the other hand, I don't see much of an "exploit" here. Major components like big engines, large weapons, etc. are quite expensive to research so if anything rerolling these becomes a significant game decision. On the other hand rerolling a smaller component I don't think is problematic, after all you can issue a specification for a sensor or fighter engine with X, Y, Z specifications to five different companies and get five different designs to test.

Maybe a reasonable check here is that the +/- 10% (or other value) applies separately to each performance characteristic. So an engine has a separate roll for each of EP, fuel efficiency, power modifier, ... or a laser has separate rolls for power, recharge/ROF, range, ... and in this case you can even for game balance purposes add a constraint that the net randomness averages out to +/- 0% so you get for example two engines that have the same total performance for their tech, but one may be faster and another more fuel-efficient. This makes "better" components a subjective judgment and again rerolling becomes a strategic decision rather than an "optimize nao" button.

Quote
I also think that it is not super realistic that a size 1 component takes half the time to research from a s size 2 component. I think there should be more of a logarithmic scale to research times of components in most circumstances.

This I can get behind. Military HQ research times get really ridiculous really quickly, since the HQ size is the primary factor.

I really don't understand why HQs don't follow the same cost scaling as every other unit based on size and armor. Even if they worked correctly in-game the bonuses from HQs are not so overbearing that the research costs need to be so prohibitive - the ability to command a corps, a formation used in various forms for centuries now, should not be more expensive to develop than futuristic ion engine technology!
Title: Re: C# Suggestions
Post by: Jorgen_CAB on December 24, 2020, 02:39:30 PM
On the other hand, I don't see much of an "exploit" here. Major components like big engines, large weapons, etc. are quite expensive to research so if anything rerolling these becomes a significant game decision. On the other hand rerolling a smaller component I don't think is problematic, after all you can issue a specification for a sensor or fighter engine with X, Y, Z specifications to five different companies and get five different designs to test.

This is also why I raised the fact that small components should be more expensive and larger less expensive than they currently are. I would like to see most components to go from a current size 10 as standard size and cost and then larger get substantially cheaper to research in comparison to size while smaller get way more expensive per size. This would make it much more of a choice to research several small components as research is a rather limiting resource you have.


Maybe a reasonable check here is that the +/- 10% (or other value) applies separately to each performance characteristic. So an engine has a separate roll for each of EP, fuel efficiency, power modifier, ... or a laser has separate rolls for power, recharge/ROF, range, ... and in this case you can even for game balance purposes add a constraint that the net randomness averages out to +/- 0% so you get for example two engines that have the same total performance for their tech, but one may be faster and another more fuel-efficient. This makes "better" components a subjective judgment and again rerolling becomes a strategic decision rather than an "optimize nao" button.

I think this makes sense.... I would like to see normal research to perhaps be a around +/-10% net change and if you want you could make it a 0-10% net change if you invest twice the RP from the start.

I would see such a feature pretty easy to add to the game as it is just about randomise the end values of a component once the research is complete.

Personally I would find it quite entertaining that not every component are carbon copies of each other and it could be interesting to put components of different types yet the same technology and size in different ships. Sure you might end up with ships in your fleet that will now differ about +/-5% in speed unless you compensate with the ships size instead.

I would not mind varied research speeds either for that matter... sometimes research can take more or less time than expected.
Title: Re: C# Suggestions
Post by: papent on December 24, 2020, 10:18:23 PM
these are probable niche items.
Return of designer mode it makes setting specific scenarios a little bit easier. Although I know it does allow people to destroy their games with mistakes pretty easily.
Enable transfers of Ships to other empires.
Title: Re: C# Suggestions
Post by: Borealis4x on December 24, 2020, 10:59:49 PM
Its currently not possible to load a single formation into multiple different transports, but would it be possible for it to in the future? I'd like it if I could deploy my marine companies via 4 fighter transports rather than 1 large boarding ship.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 25, 2020, 01:09:22 AM
Component suggestion: Commercial missile dropper/buoy layer. Basically a component that can deploy missiles only with the Launch Ready Ordnance order. Could be designed with a variable missile size or just fixed at size 25 if you want to be cute about it. Ideally this would have an internal MFC and not require an MFC to be designed and added, similar to how CIWS has an internal BFC.

Main motivation is to make laying sensor buoys easier as right now there's no great solution (putting missile launchers on a survey ship seems to make the commander auto-assign consider it a warship, which is unfortunate). In theory this could also be used to lay minefields except that those are broken presently, otherwise I don't think this would be an immediately broken addition.
Title: Re: C# Suggestions
Post by: QuakeIV on December 25, 2020, 04:49:35 AM
I personally think there should be more of a 'range' of more or less normal costing engine sizes (or whatever), and you can research to push that range outward, the further you go outside of that range the more expensive it gets.
Title: Re: C# Suggestions
Post by: StarshipCactus on December 25, 2020, 05:55:38 AM
Component suggestion: Commercial missile dropper/buoy layer. Basically a component that can deploy missiles only with the Launch Ready Ordnance order. Could be designed with a variable missile size or just fixed at size 25 if you want to be cute about it. Ideally this would have an internal MFC and not require an MFC to be designed and added, similar to how CIWS has an internal BFC.

Main motivation is to make laying sensor buoys easier as right now there's no great solution (putting missile launchers on a survey ship seems to make the commander auto-assign consider it a warship, which is unfortunate). In theory this could also be used to lay minefields except that those are broken presently, otherwise I don't think this would be an immediately broken addition.

You could avoid the minelaying thing by making a prebuilt sensor buoy that can only be launched by the sensor buoy launcher, it would also be the only thing the SBL could launch. You could make it more granular by being able to select the size of sensor buoy you want. If you just want a tiny, cheap passive sensor in orbit of an NPR world or on a JP, you go for a small buoy and launcher. If you want a larger sensor to watch trade lanes and can spot a fleet that jumped at 100K KM away from a JP, you go for a larger buoy with actives instead of passives. Maybe you can even armour them to allow you to gather weapon data if they fail to OHKO your buoy.
Title: Re: C# Suggestions
Post by: Migi on December 25, 2020, 12:22:07 PM
Minor Suggestion:
When a fleet is in a training admin and is given an overhaul order, the order should fail and display an error message something to the effect "Fleets in a training admin command cannot undergo overhaul." or maybe "Ships cannot undergo training and overhaul at the same time."
Alternately:
Every construction cycle check each fleet which is in a training admin and see if it contains an overhaul order. Display the same message  as previous in the log.

I think adding this would be help new players.
Title: Re: C# Suggestions
Post by: Droll on December 25, 2020, 06:35:03 PM
In the formation template creation screen, the existing templates should be sorted by abbreviation and not their names
Title: Re: C# Suggestions
Post by: Borealis4x on December 26, 2020, 01:15:51 AM
The player should be guaranteed to spawn with at least 1 scientist in every field.

Title: Re: C# Suggestions
Post by: QuakeIV on December 26, 2020, 02:48:05 AM
You can switch scientists fields so you are never truly without one, but the thing of which you speak sounds nice and convenient (also they will start with a higher bonus generally than a switched-over scientist).
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 26, 2020, 03:00:08 AM
The player should be guaranteed to spawn with at least 1 scientist in every field.

We already have the ability to switch a scientist's field for a 75% skill penalty which is reasonably fair (I use my 0% skill scientists for this and then try to train them up, usually I pop a better one in that field first though). This is sufficient IMO, part of the challenge particularly on smaller starts is dealing with a lack in some areas and one of those areas can be scientists.

Keep in mind that a scientist can research in any field, e.g. a 40% researcher in biology can still research a propulsion tech and will give the 40% bonus instead of the 160% bonus you would get from them if they researched a biology tech, in other words they are the same as a 10% researcher in P&P except that the latter has a chance to gain more skill in that field (which is why you could just retrain the biologist instead). Research speed will be slower but not crippling, certainly it is not as if the NPRs are going to dramatically outpace the player in ship speeds.
Title: Re: C# Suggestions
Post by: Borealis4x on December 26, 2020, 11:50:46 AM
The player should be guaranteed to spawn with at least 1 scientist in every field.

We already have the ability to switch a scientist's field for a 75% skill penalty which is reasonably fair (I use my 0% skill scientists for this and then try to train them up, usually I pop a better one in that field first though). This is sufficient IMO, part of the challenge particularly on smaller starts is dealing with a lack in some areas and one of those areas can be scientists.


Didn't know you could do that. Thought I still think you should at least start with 1 reasonably skilled scientist in every field.
Title: Re: C# Suggestions
Post by: Froggiest1982 on December 26, 2020, 01:26:22 PM
The player should be guaranteed to spawn with at least 1 scientist in every field.

We already have the ability to switch a scientist's field for a 75% skill penalty which is reasonably fair (I use my 0% skill scientists for this and then try to train them up, usually I pop a better one in that field first though). This is sufficient IMO, part of the challenge particularly on smaller starts is dealing with a lack in some areas and one of those areas can be scientists.


Didn't know you could do that. Thought I still think you should at least start with 1 reasonably skilled scientist in every field.

I like to don't have scientists in all fields becausevit adds to variety at the start.

You can always add yourself an extra batch of 100 people (civ ad, officers etc) at the start by SM with literally one click. I am sure this will produce you at least another scientist in the missing field.
Title: Re: C# Suggestions
Post by: Borealis4x on December 26, 2020, 01:52:03 PM
How about an option to lock trans-newtonian tech behind surveying a ruin on Mars?

It always felt weird to me how cheap the tech that lets you break the basic rules of physics is, so I always waited until I colonized Mars with conventional tech to research it. In my mind, my guys find Precursor ruins there that can be reverse-engineered to understand Trans-Newtonian physics. Its a well-worn trope, but a good one.

Of course, that would necessitate making troop bays Conventional tech.
Title: Re: C# Suggestions
Post by: Droll on December 26, 2020, 03:00:03 PM
How about an option to lock trans-newtonian tech behind surveying a ruin on Mars?

It always felt weird to me how cheap the tech that lets you break the basic rules of physics is, so I always waited until I colonized Mars with conventional tech to research it. In my mind, my guys find Precursor ruins there that can be reverse-engineered to understand Trans-Newtonian physics. Its a well-worn trope, but a good one.

Of course, that would necessitate making troop bays Conventional tech.

I get the feeling you've already come up with a decent solution to this problem.
Title: Re: C# Suggestions
Post by: Migi on December 26, 2020, 04:29:31 PM
How about an option to lock trans-newtonian tech behind surveying a ruin on Mars?

It always felt weird to me how cheap the tech that lets you break the basic rules of physics is, so I always waited until I colonized Mars with conventional tech to research it. In my mind, my guys find Precursor ruins there that can be reverse-engineered to understand Trans-Newtonian physics. Its a well-worn trope, but a good one.

Of course, that would necessitate making troop bays Conventional tech.
This would railroad the start of the game in a way fundamentally the opposite of how Steve wants to use Aurora.
Aurora is more of a role-playing tool than a game and that means giving more options and flexibility.

If you want to RP situational limits to certain technologies that is 100% encouraged.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 26, 2020, 06:02:59 PM
This would railroad the start of the game in a way fundamentally the opposite of how Steve wants to use Aurora.
Aurora is more of a role-playing tool than a game and that means giving more options and flexibility.

If you want to RP situational limits to certain technologies that is 100% encouraged.

I usually headcanon in my TN start games that TN tech was discovered from observations after a massive nuclear event large enough to affect the gravitational field.

There's no need to railroad the game and limit how people RP things.
Title: Re: C# Suggestions
Post by: xenoscepter on December 26, 2020, 08:35:44 PM
This would railroad the start of the game in a way fundamentally the opposite of how Steve wants to use Aurora.
Aurora is more of a role-playing tool than a game and that means giving more options and flexibility.

If you want to RP situational limits to certain technologies that is 100% encouraged.

I usually headcanon in my TN start games that TN tech was discovered from observations after a massive nuclear event large enough to affect the gravitational field.

There's no need to railroad the game and limit how people RP things.

 - I typically headcannon it as a Tiberium-esq. event but instead of a meteor falling it's a universe-scale dimensional distortion.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 01, 2021, 08:14:37 PM
Something that is sort of a pet peeve of mine albeit a small one is sub-fleet management. I usually build complex sub-fleet structures to my fleet and there is one order that I really miss and that is joining a specific fleet as a sub-fleet and insert it into a specific sub-flee in the tree of sub-fleets. Now I have to join the sub-fleet into the fleet at root level and then manually inject it into the proper place. It works great for parasites into motherships but not that well for other parts of a fleet structure.

I would suggest that the order "Join as sub-fleet" also give a list of Fleet (as in it works now, perhaps call it root) and also a list of all the sub-fleets in that fleet. Now I could join as a fleet and inject mu sub-fleet into any part of the organizational tree directly from my movement order so I don't have to deal with it separately later on.

I really like to use many sub-fleets and have a large and complex organizational structure to my navy.
Title: Re: C# Suggestions
Post by: Droll on January 01, 2021, 08:56:00 PM
Something that is sort of a pet peeve of mine albeit a small one is sub-fleet management. I usually build complex sub-fleet structures to my fleet and there is one order that I really miss and that is joining a specific fleet as a sub-fleet and insert it into a specific sub-flee in the tree of sub-fleets. Now I have to join the sub-fleet into the fleet at root level and then manually inject it into the proper place. It works great for parasites into motherships but not that well for other parts of a fleet structure.

I would suggest that the order "Join as sub-fleet" also give a list of Fleet (as in it works now, perhaps call it root) and also a list of all the sub-fleets in that fleet. Now I could join as a fleet and inject mu sub-fleet into any part of the organizational tree directly from my movement order so I don't have to deal with it separately later on.

I really like to use many sub-fleets and have a large and complex organizational structure to my navy.

To add to this aurora also does not handle multi-layer sub-fleet hierarchies very well right now
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 01, 2021, 08:58:50 PM
To add to this aurora also does not handle multi-layer sub-fleet hierarchies very well right now

In what manner do you mean it does not handle well?
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 01, 2021, 10:09:50 PM
To add to this aurora also does not handle multi-layer sub-fleet hierarchies very well right now

In what manner do you mean it does not handle well?

Offhand, two things:

Subfleets work fine, but they could definitely be better integrated mechanically. Personally I'd like to be able to drag a fleet into another fleet (at the same location) and have it join as a subfleet, maybe something like a Ctrl+drag would work. Currently the only way to combine fleets this way is the Join as Sub-Fleet order, which takes 5 seconds (okay in Earth orbit, risky during a combat maneuver) and requires issuing an order (click, scroll, click, scroll...) instead of just doing a neat little drag-and-drop.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 02, 2021, 07:11:34 AM
To add to this aurora also does not handle multi-layer sub-fleet hierarchies very well right now

In what manner do you mean it does not handle well?

Offhand, two things:
  • Aurora doesn't have orders that handle layers of subfleets. Most orders or controls either affect the whole fleet or the lowest subfleet. An example is fire control (the player interface, not the components): if I have two subfleets each with two more subfleets (1-2-4 sub-units at each level), I can give target assignments for the whole fleet or for each lowest-level subfleet, but I cannot give targeting orders for the mid-level subfleets.
  • Aurora doesn't handle creation of nested subfleets from the bottom up. Ideally we would be able to select a fleet subunit (ship or subfleet) and create a subfleet containing that subunit. Currently we must create empty subfleets and drag units into them individually which is a bit annoying.

Subfleets work fine, but they could definitely be better integrated mechanically. Personally I'd like to be able to drag a fleet into another fleet (at the same location) and have it join as a subfleet, maybe something like a Ctrl+drag would work. Currently the only way to combine fleets this way is the Join as Sub-Fleet order, which takes 5 seconds (okay in Earth orbit, risky during a combat maneuver) and requires issuing an order (click, scroll, click, scroll...) instead of just doing a neat little drag-and-drop.

Yes... those are good points. I hope that Steve will take another pass at the sub-fleet mechanic at some point when he finds the time to do that. I think it in general works well but it could be better as I use it allot for building my fleet structure.

One example is parasites on ships. As I tend to use hangars on almost every capital warship I would like to attach sub-fleets to individual ships... now I have to put each ship in it's own sub fleet instead. If I could attach sub-fleets directly to ships I could have my parasites in their own sub fleets or attached that way instead. It would be easier if these "sub-fleets" where sorted so they end up beneath the ship they are assigned to in the list so I at a glance can see which scouts group belong to which ship in a small squadron of escorts for example. If I then individually detach the ship those sub-fleets are detached as well of course which are attached to the ship not the fleet.

In essence I think that sub-fleets should be able to be attached to either fleets (sub-fleets) or ships separately. In the hierarchy then sub-fleet for ships and fleets should be colored differently and sorted differently.
 
There are a few more of those little things I would like to see to make things easier to manage in the sub-fleet structure.
Title: spectator mode
Post by: Jitel on January 04, 2021, 02:20:56 AM
Hello everyone. 
It would be great to have something like a spectator mode, so that you can just watch the computer play multiple races, being able to switch between them and check all the details.   Maybe it's not a very important option, but just to see what features the game provides, or what designs the computer will create and so on.
Title: Re: spectator mode
Post by: kingflute on January 04, 2021, 09:49:41 AM
Quote from: Jitel link=topic=10640. msg145838#msg145838 date=1609748456
Hello everyone.   
It would be great to have something like a spectator mode, so that you can just watch the computer play multiple races, being able to switch between them and check all the details.    Maybe it's not a very important option, but just to see what features the game provides, or what designs the computer will create and so on.
I dont think that watching the AI play would be of massive use, as I believe that an AI race has a few different rules and limitations as a player race
Title: Re: C# Suggestions
Post by: Borealis4x on January 06, 2021, 01:55:42 AM
The ability to have medals for ships, like battle-stars would be cool.

Also, the ability to mass-award officers in a task group or an administrative hierarchy would be nice to make campaign/war medals more feasible.
Title: Re: C# Suggestions
Post by: Steve Walmsley on January 06, 2021, 06:20:11 AM
Also, the ability to mass-award officers in a task group or an administrative hierarchy would be nice to make campaign/war medals more feasible.

You can already do that :)
Title: Re: C# Suggestions
Post by: Theoatmeal2 on January 06, 2021, 08:44:54 AM
It would be nice if one could set a home port for a ship or a task group and then just press one button to go home.
Now I have to navigate manually and it takes some time.
Title: Re: C# Suggestions
Post by: Steve Walmsley on January 06, 2021, 10:16:27 AM
It would be nice if one could set a home port for a ship or a task group and then just press one button to go home.
Now I have to navigate manually and it takes some time.

Just select a system using auto-route and it will go home. It's two clicks but close enough.
Title: Re: C# Suggestions
Post by: Kylemmie on January 06, 2021, 10:44:12 AM
It would be nice if one could set a home port for a ship or a task group and then just press one button to go home.
Now I have to navigate manually and it takes some time.

Just select a system using auto-route and it will go home. It's two clicks but close enough.

Ahhh the fond memories.....That totally made me flashback to my "OMG" moment when I discovered Auto-route. Quill18 introduced me to the game and I was off and running learning as much as I could on my own.  Moving around became a pita, but the mirco was worth it cuz I was having so much fun learning all the cool battle and economic mechanics. I tended to avoid clicking on stuff I didn't know to avoid info overload.

Then I discovered how auto-route works and my life changed forever.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 06, 2021, 03:32:40 PM
Slight adjustment suggestion:

Presently the commander auto-assign, when it works correctly, assigns warship commanders based on Crew Training bonus, then assigns a bunch of other things including auxiliary command roles, and then fills remaining warship commands based on Reaction, Engineering, and Tactical bonuses.

I would suggest that instead Reaction should be the primary and first skill bonus for warship commanders, and Crew Training grouped in with Engineering and Tactical at the end. This is a very simple change but I think it works better with how C# handles commander roles compared to VB6.

The reason being that each of these skills only give 50% of their benefits from a ship commander, but 100% from the associated command module officers. Reaction however gives 100% of the commander's bonus as there is no module for it.
Title: Re: C# Suggestions
Post by: Droll on January 07, 2021, 03:33:57 PM
Nerf the missile neutralization tech line.
At max level I'm making magazines that have a 0.1% chance to explode (and that doesn't even account for chief engineer modifiers). This means that my ammunition storage full of nuclear warheads is somehow less likely to explode than my engine or reactor. There is absolutely no point to use the internal magazine armor for this reason.

I've also noticed that larger magazines have less of a chance to explode, maybe remove that too.

Maybe the best it gets is 60%-75%? It would nerf the short range assault potential of missiles since their parent ships would be powder kegs while also weakening AMM PD.

Regardless I believe that missile storage on combat ships is too safe.
Title: Re: C# Suggestions
Post by: QuakeIV on January 07, 2021, 03:48:26 PM
I never noticed because I don't really use magazines, larger is actually less likely to explode?  It seems like that aught to be the opposite...
Title: Re: C# Suggestions
Post by: xenoscepter on January 07, 2021, 03:48:44 PM
Nerf the missile neutralization tech line.
At max level I'm making magazines that have a 0.1% chance to explode (and that doesn't even account for chief engineer modifiers). This means that my ammunition storage full of nuclear warheads is somehow less likely to explode than my engine or reactor. There is absolutely no point to use the internal magazine armor for this reason.

I've also noticed that larger magazines have less of a chance to explode, maybe remove that too.

Maybe the best it gets is 60%-75%? It would nerf the short range assault potential of missiles since their parent ships would be powder kegs while also weakening AMM PD.

Regardless I believe that missile storage on combat ships is too safe.

 - Your at Maximum Tech, of course it's absurd. Even at Maximum Tech magazine armor isn't useless as it increases the HtK of the magazines making them draw more Internal Damage away from engines and reactors and such. They don't need to be nerfed, you just need to play at a lower tech level if you want to be more vulnerable. The game changes drastically at certain tech levels; Ion, Fusion, and Anti-Matter propulsions are the benchmarks most often used, but generally above 40,000 RP is where the game really starts shifting. If your burning through the tech levels, consider reducing your research rate, or using a lower mineral modifier or starting with less pop.

 - Also, if we want to be ultra-realistic your stockpile of nuclear weapons should never explode no matter how much you shoot them because nuclear weapons are inert until armed AND detonated... and even then they sometimes fail to denotate properly. If anything, damage to them should render them less explosive, not more. To be short, I disagree, a lot. :)
Title: Re: C# Suggestions
Post by: Droll on January 07, 2021, 03:49:38 PM
When a civilian shipping line is created - there should be a chance that it appears on a large established colony (100m pop?) instead of just spawning on earth

Only complication is if there is a lack of stabilized routes to earth/other colonies AND the system in question only has one colony (so no interplanetary trade)
Title: Re: C# Suggestions
Post by: Droll on January 07, 2021, 03:55:17 PM
Nerf the missile neutralization tech line.
At max level I'm making magazines that have a 0.1% chance to explode (and that doesn't even account for chief engineer modifiers). This means that my ammunition storage full of nuclear warheads is somehow less likely to explode than my engine or reactor. There is absolutely no point to use the internal magazine armor for this reason.

I've also noticed that larger magazines have less of a chance to explode, maybe remove that too.

Maybe the best it gets is 60%-75%? It would nerf the short range assault potential of missiles since their parent ships would be powder kegs while also weakening AMM PD.

Regardless I believe that missile storage on combat ships is too safe.

 - Your at Maximum Tech, of course it's absurd. Even at Maximum Tech magazine armor isn't useless as it increases the HtK of the magazines making them draw more Internal Damage away from engines and reactors and such. They don't need to be nerfed, you just need to play at a lower tech level if you want to be more vulnerable. The game changes drastically at certain tech levels; Ion, Fusion, and Anti-Matter propulsions are the benchmarks most often used, but generally above 40,000 RP is where the game really starts shifting. If your burning through the tech levels, consider reducing your research rate, or using a lower mineral modifier or starting with less pop.

 - Also, if we want to be ultra-realistic your stockpile of nuclear weapons should never explode no matter how much you shoot them because nuclear weapons are inert until armed AND detonated... and even then they sometimes fail to denotate properly. If anything, damage to them should render them less explosive, not more. To be short, I disagree, a lot. :)

But I don't want to play at lower tech levels, albeit I see your point I think I should modify my suggestion - the minimum level of magazine neutralization should be much lower IMO, make it start at like 15% and then let it go up to 99%. That way I have the choice of limiting myself in the design process while you can have your standard levels.

My point about larger magazines somehow being less explosive stands though, I think that should be changed so that size has no effect - or instead make it based on how full the magazine was at the time of explosion (which I think is already factored in?).

Honestly though - even at ion levels assuming you only have the first level, 75% ejection still seems to high to me for entry level.

As for the realism point, sure nukes are pretty inert - but these are space nukes!  ;D
Title: Re: C# Suggestions
Post by: xenoscepter on January 07, 2021, 04:20:46 PM
 - But, you still have the choice. You can design magazines with less neutralization tech. ???
Title: Re: C# Suggestions
Post by: Droll on January 07, 2021, 05:02:07 PM
- But, you still have the choice. You can design magazines with less neutralization tech. ???

Honestly though - even at ion levels assuming you only have the first level, 75% ejection still seems to high to me for entry level.

I just realized that the minimum is 70% and not 75% - my point still stands. Even at their worst the highest explosion chance for a magazine is 30%, what I'm saying is that even that is too low.
Not only that this chance is for an HS1 magazine, most magazines are larger and this pushes that % even lower. This is on the lowest neutralization tech, so no I don't have that choice.
Title: Re: C# Suggestions
Post by: xenoscepter on January 07, 2021, 05:05:28 PM
- But, you still have the choice. You can design magazines with less neutralization tech. ???

The minimum is 75% as I've already said - which I think is too generous/safe

 - The minimum is 70%, but yeah that does seem rather generous... I recall Steve mentioning that in the changelog though, now that you bring it up. The idea was that explosions would be less frequent, but more devastating. It was, IIRC, an answer to VB6 having far too many explosions overall... like H.M.S. Hood, but instead of a lucky shot to one ship it's your entire fleet and it happens a lot.
Title: Re: C# Suggestions
Post by: Droll on January 07, 2021, 05:08:33 PM
- But, you still have the choice. You can design magazines with less neutralization tech. ???

The minimum is 75% as I've already said - which I think is too generous/safe

 - The minimum is 70%, but yeah that does seem rather generous... I recall Steve mentioning that in the changelog though, now that you bring it up. The idea was that explosions would be less frequent, but more devastating. It was, IIRC, an answer to VB6 having far too many explosions overall... like U.S.S. Hood, but instead of a lucky shot to one ship it's your entire fleet and it happens a lot.

Was editing the post as you sent this lol. Also you most likely are thinking of the H.M.S Hood, unless there is an American doppleganger im unaware of.
I think it wouldn't be too bad if magazine size didn't also reduce the chance of detonation.
Title: Re: C# Suggestions
Post by: xenoscepter on January 07, 2021, 05:11:53 PM
- But, you still have the choice. You can design magazines with less neutralization tech. ???

The minimum is 75% as I've already said - which I think is too generous/safe

 - The minimum is 70%, but yeah that does seem rather generous... I recall Steve mentioning that in the changelog though, now that you bring it up. The idea was that explosions would be less frequent, but more devastating. It was, IIRC, an answer to VB6 having far too many explosions overall... like U.S.S. Hood, but instead of a lucky shot to one ship it's your entire fleet and it happens a lot.

Was editing the post as you sent this lol. Also you most likely are thinking of the H.M.S Hood, unless there is an American doppleganger im unaware of.

I was originally going to reference the U.S.S. Arizona, but about 60% of the way through I realized that H.M.S. Hood was a better one.  :)
Title: Re: C# Suggestions
Post by: QuakeIV on January 07, 2021, 06:52:46 PM
Strictly if you have very high radiation weapons then you might cause a premature ignition on a nuclear warhead.  Generally speaking if you detonate a nuclear bomb with any of todays conventional weapons there is no real change of it going off (well, the explosives for the fission bomb might detonate but its unlikely to produce a nuclear explosion), however for instance shooting nukes at nukes might actually get a reaction.
Title: Re: C# Suggestions
Post by: xenoscepter on January 07, 2021, 07:09:51 PM
Strictly if you have very high radiation weapons then you might cause a premature ignition on a nuclear warhead.  Generally speaking if you detonate a nuclear bomb with any of todays conventional weapons there is no real change of it going off (well, the explosives for the fission bomb might detonate but its unlikely to produce a nuclear explosion), however for instance shooting nukes at nukes might actually get a reaction.

 - So, instead of having a higher minimum magazine, we could have enhanced radiation warheads that could potentially damage magazines and intentionally cause said explosions? I'd like that! ;D
Title: Re: C# Suggestions
Post by: Kristover on January 07, 2021, 07:10:35 PM
<Repost from original thread>

I tend to play Aurora as an RPG and I love playing with the officer system, hierarchies, and medals.  One thing I note is after several C+ games is some of the medal conditions are difficult to achieve if you are using realistic promotions.  None of my officers stay in position long enough to meet some of the gates like discovering 1000 bodies with minerals.  I would like some additional conditions to allow me to create additional and achievable medals and judging off a look at the DB it seems like it would be easy to add with no new coding.  Request the following conditions be added:

Destroy 500,000 tons of Military Shipping
Destroy 5,000,0000 tons of Commercial Shipping
Destroy 250,000 tons of Hostile Ground Forces

(In some of my longer games I have created some super warships whose Captains have come close to achieving these conditions)

Participate in Three Combat Drops (both formation & transport)
Participate in 10 Combat Drops (both formation & transport)

(I find that especially my transports reach 5 drops pretty easily and my specialized marine ground forces will reach 3 to 5 clearing a single system)

Destroy 500 Hostile Missiles
Destroy 2500 Hostile Missiles

(I haven't had any Commander hit 2500 hostile missiles but I have had a few hit 1000 and get quite a bit over it)

Survive 3 Ship Destructions

(I had a Commander recently reach this distinction and I thought it should be recognized)

Discover 3 New Star Systems
Discover 5 New Star Systems

(Very few of my Survey Captains stay in position long enough to discover 10 new star systems - it has happened - and none reached 25.  I would like gradations of 3 & 5 because enough of my survey Captains reach these marks)

Discover 1 System Bodies with Minerals
Discover 10 System Bodies with Minerals
Discover 50 System Bodies with Minerals

(This is the one which I had the most issues.  I think I had a Commander ONCE reach 100 system bodies with minerals because he discovered two systems with couple hundred asteroids and he stayed in an abnormally long time.  I haven't yet had a single Commander even get a quarter of a way to 1000.  1, 10, 50, 100 seems like a right set of achievable gates)

Discover 1 Jump Point
Discover 3 Jump Points
Discover 5 Jumps Points

(100 JPs is not achievable unless you are immortal.  I haven't had a Commander yet hit 10.  Most only hit 1 to 3 before the automated promotions send them onward).

Stabilise 5 Jump Points or Lagrange Points

(Purely to keep it roughly in line with the Discover JP hierarchy)

Recover 1 Abandoned Installations

(On some of the smaller alien ruins, there might be only a few installations recoverable and if there is more than one Engineering unit present, the Commander only might get 1 installation)

Five years of Service, Ten years of Service, Fifteen years of Service, Twenty years of Service, Twenty-Five years of Service, Thirty Years of Service, Thirty-Five years of Service, Forty Years of Service

(Not strictly necessary - I would be fine with keeping 10,20,30 - but I think I would like to see gradations of five because it would tell me a bit more about length of service and give each officer a shot at more bling)
Title: Re: C# Suggestions
Post by: QuakeIV on January 07, 2021, 07:11:10 PM
Strictly if you have very high radiation weapons then you might cause a premature ignition on a nuclear warhead.  Generally speaking if you detonate a nuclear bomb with any of todays conventional weapons there is no real change of it going off (well, the explosives for the fission bomb might detonate but its unlikely to produce a nuclear explosion), however for instance shooting nukes at nukes might actually get a reaction.

 - So, instead of having a higher minimum magazine, we could have enhanced radiation warheads that could potentially damage magazines and intentionally cause said explosions? I'd like that! ;D

That is not what I meant by that at all (I was just remarking that in general the games high power weapons are more likely to set smeg off) but it is a really cool idea.  Maybe a function of enhanced radiation warheads could be to greatnly enhance the odds of missile and power system secondary explosions.
Title: Re: C# Suggestions
Post by: Droll on January 07, 2021, 07:13:52 PM
Strictly if you have very high radiation weapons then you might cause a premature ignition on a nuclear warhead.  Generally speaking if you detonate a nuclear bomb with any of todays conventional weapons there is no real change of it going off (well, the explosives for the fission bomb might detonate but its unlikely to produce a nuclear explosion), however for instance shooting nukes at nukes might actually get a reaction.

 - So, instead of having a higher minimum magazine, we could have enhanced radiation warheads that could potentially damage magazines and intentionally cause said explosions? I'd like that! ;D

This is brilliant because it provides a use-case for enhanced radiation missiles in ship-to-ship combat. You could use them on a missile ship with weakened armor to try and detonate the magazine.
Title: Re: C# Suggestions
Post by: Froggiest1982 on January 08, 2021, 02:09:24 AM
Custom Water Requirements.
Title: Re: C# Suggestions
Post by: RougeNPS on January 08, 2021, 10:58:08 AM
Custom Water Requirements.

What would this entail?
Title: Re: C# Suggestions
Post by: Droll on January 08, 2021, 11:09:17 AM
Custom Water Requirements.

What would this entail?

Right now every species needs 20% water. He is suggesting that we be allowed to change this requirement for various species. So one only needs 15% and another wants 30% for example.
Title: Re: C# Suggestions
Post by: RougeNPS on January 08, 2021, 11:13:02 AM
Custom Water Requirements.

What would this entail?

Right now every species needs 20% water. He is suggesting that we be allowed to change this requirement for various species. So one only needs 15% and another wants 30% for example.

Ah ok then.
Title: Re: C# Suggestions
Post by: Black on January 08, 2021, 03:57:29 PM
Custom Water Requirements.

Could be interesting to go for aquatic species, so more water there is the more people you can put on the planet.
Title: Re: C# Suggestions
Post by: Gabrote42 on January 08, 2021, 04:36:32 PM
Custom Water Requirements.

Could be interesting to go for aquatic species, so more water there is the more people you can put on the planet.
I was thinking about that the other day. I would love it! Customizable water% is higher on priority IMO but that would be really cool if you could implement it with just a toggle.
Title: Re: C# Suggestions
Post by: Borealis4x on January 09, 2021, 12:35:03 PM
Would it be possible to add an unlimited number of conditional orders and saving said orders as a standard template to be applied either manually or as default from the ship design menu?

Also, a message alert when colonists are exceeding infrastructure would be nice to have. I know we have unrest alerts, but that is a symptom that happens after its too late.
Title: Re: C# Suggestions
Post by: Droll on January 09, 2021, 12:54:04 PM
Would it be possible to add an unlimited number of conditional orders and saving said orders as a standard template to be applied either manually or as default from the ship design menu?

I like the idea of standing order templates but I don't think it would make sense to set defaults from the ship design menu. Standing orders apply to fleets, not ships.
Title: Re: C# Suggestions
Post by: Borealis4x on January 09, 2021, 12:54:39 PM
Would it be possible to add an unlimited number of conditional orders and saving said orders as a standard template to be applied either manually or as default from the ship design menu?

I like the idea of standing order templates but I don't think it would make sense to set defaults from the ship design menu. Standing orders apply to fleets, not ships.

oh yeah, duh.
Title: Re: C# Suggestions
Post by: Froggiest1982 on January 09, 2021, 02:34:52 PM
Custom Water Requirements.

Could be interesting to go for aquatic species, so more water there is the more people you can put on the planet.

That was my idea. Aquatic species, desert species (little to no water) but mostly Robots. I can currently create Robotic species that are in no need of oxy and are not affected by any temperature but....they still need water.

We Robots need no water!
Title: Re: C# Suggestions
Post by: Gabrote42 on January 09, 2021, 03:06:42 PM
Custom Water Requirements.

Could be interesting to go for aquatic species, so more water there is the more people you can put on the planet.

That was my idea. Aquatic species, desert species (little to no water) but mostly Robots. I can currently create Robotic species that are in no need of oxy and are not affected by any temperature but....they still need water.

We Robots need no water!
Thoughts on this: For now, just RP robots as needing Coolant (like cars). One should be careful when implementing Aquatic and Desert species, since an aquatic race can be completely nonviable if they can only have 2m pop on a planet, and a desert species can be very OP if they can use 100% of the surface just like that. It might require another thread to discuss balance, unless Steve makes an executive decision.
Title: Re: C# Suggestions
Post by: Droll on January 09, 2021, 03:14:31 PM
Custom Water Requirements.

Could be interesting to go for aquatic species, so more water there is the more people you can put on the planet.

That was my idea. Aquatic species, desert species (little to no water) but mostly Robots. I can currently create Robotic species that are in no need of oxy and are not affected by any temperature but....they still need water.

We Robots need no water!
Thoughts on this: For now, just RP robots as needing Coolant (like cars). One should be careful when implementing Aquatic and Desert species, since an aquatic race can be completely nonviable if they can only have 2m pop on a planet, and a desert species can be very OP if they can use 100% of the surface just like that. It might require another thread to discuss balance, unless Steve makes an executive decision.

The carrying capacity problem is easily solved for aquatic and desert species - flip it on its head

So for an aquatic species - anything below 75% water reduces their carrying capacity.
For a desert species - anything above their water requirement (let's say 10% for this example) will reduce the effective carrying capacity.
The best part is that you don't even need to have the custom water requirements implemented and use the current ruleset for water (keep it between 10-20% for desert and above 75% for aquatic).

The existence and function of the population density modifier already shows us that aurora in its current form already tracks carrying capacity on a species-wise basis so this isn't too much of an ask (i think).
Title: Re: C# Suggestions
Post by: xenoscepter on January 09, 2021, 04:35:26 PM
Custom Water Requirements.

Could be interesting to go for aquatic species, so more water there is the more people you can put on the planet.

 - That's a very elegant solution! I would add that we should be able to alter the tolerances so that we can have OP races if we want them. :)

That was my idea. Aquatic species, desert species (little to no water) but mostly Robots. I can currently create Robotic species that are in no need of oxy and are not affected by any temperature but....they still need water.

We Robots need no water!
Thoughts on this: For now, just RP robots as needing Coolant (like cars). One should be careful when implementing Aquatic and Desert species, since an aquatic race can be completely nonviable if they can only have 2m pop on a planet, and a desert species can be very OP if they can use 100% of the surface just like that. It might require another thread to discuss balance, unless Steve makes an executive decision.

The carrying capacity problem is easily solved for aquatic and desert species - flip it on its head

So for an aquatic species - anything below 75% water reduces their carrying capacity.
For a desert species - anything above their water requirement (let's say 10% for this example) will reduce the effective carrying capacity.
The best part is that you don't even need to have the custom water requirements implemented and use the current ruleset for water (keep it between 10-20% for desert and above 75% for aquatic).

The existence and function of the population density modifier already shows us that aurora in its current form already tracks carrying capacity on a species-wise basis so this isn't too much of an ask (i think).
Title: Re: C# Suggestions
Post by: QuakeIV on January 09, 2021, 05:29:34 PM
Custom Water Requirements.

Could be interesting to go for aquatic species, so more water there is the more people you can put on the planet.

That was my idea. Aquatic species, desert species (little to no water) but mostly Robots. I can currently create Robotic species that are in no need of oxy and are not affected by any temperature but....they still need water.

We Robots need no water!
Thoughts on this: For now, just RP robots as needing Coolant (like cars). One should be careful when implementing Aquatic and Desert species, since an aquatic race can be completely nonviable if they can only have 2m pop on a planet, and a desert species can be very OP if they can use 100% of the surface just like that. It might require another thread to discuss balance, unless Steve makes an executive decision.

The carrying capacity problem is easily solved for aquatic and desert species - flip it on its head

So for an aquatic species - anything below 75% water reduces their carrying capacity.
For a desert species - anything above their water requirement (let's say 10% for this example) will reduce the effective carrying capacity.
The best part is that you don't even need to have the custom water requirements implemented and use the current ruleset for water (keep it between 10-20% for desert and above 75% for aquatic).

The existence and function of the population density modifier already shows us that aurora in its current form already tracks carrying capacity on a species-wise basis so this isn't too much of an ask (i think).

I think the water one is more clearcut as to how exactly it would work and is in general a good idea.

Title: Re: C# Suggestions
Post by: Borealis4x on January 09, 2021, 11:03:34 PM
The ability to queue up slipway additions for shipyards. Really annoying when I'm trying to build a FAC shipyard with 10 or so slipways with how fast they build.
 
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 09, 2021, 11:07:55 PM
It would be nice if the System View window has an Auto-Rename System button that would select either the next name or (ideally) a random system name from the naming theme, for one-click random renaming of Gliese 184628946 and WISE +03846182037-73541894767 systems.
Title: Re: C# Suggestions
Post by: QuakeIV on January 09, 2021, 11:33:47 PM
The ability to queue up slipway additions for shipyards. Really annoying when I'm trying to build a FAC shipyard with 10 or so slipways with how fast they build.

Perhaps an 'expand to X slipays' order like the greatly improved 'expand to capacity' order.
Title: Re: C# Suggestions
Post by: TMaekler on January 10, 2021, 07:26:31 AM
Sometimes it is a bit annoying to select the right modules for a ship. Who knows be the names "small", "tiny", etc. what exact size that component is - especially because they can be a different size depending on the type of module. So it boils down to try. I changed my module names so that I can see that instantly in the module name - but I have to do it anew with every new release. Since there is a special module found in the Reddit modding forum for exactly this, I suggest that Steve includes the respective sizes of the modules in the base game. Seems to me that I am not the only one doing this... .
Title: Re: C# Suggestions
Post by: Borealis4x on January 10, 2021, 01:29:04 PM
I know a lot of people would appreciate Ground Forces automatic name generation to be changed so it only starts counting the number of that specific template used instead of all of them (so you don't get 1st infantry battalion and then 2nd motorized battalion even though its the first mot battalion you built).

I'd go a step further and suggest that the game let us 'lock' in a custom name for the units you are about to train (for example, 'Mars Infantry Battalion) and then automatically apply numbers as you queue up production orders (so you get 1st Mars Infantry Battalion and then 2nd Mars Infantry Battalion and so on) until you unlock or change the custom name.
Title: Re: C# Suggestions
Post by: Droll on January 10, 2021, 01:40:46 PM
I know a lot of people would appreciate Ground Forces automatic name generation to be changed so it only starts counting the number of that specific template used instead of all of them (so you don't get 1st infantry battalion and then 2nd motorized battalion even though its the first mot battalion you built).

I'd go a step further and suggest that the game let us 'lock' in a custom name for the units you are about to train (for example, 'Mars Infantry Battalion) and then automatically apply numbers as you queue up production orders (so you get 1st Mars Infantry Battalion and then 2nd Mars Infantry Battalion and so on) until you unlock or change the custom name.

The custom name sort of exists, before creating the formation training task you can rename the unit to whatever, but it doesn't get locked in for some reason so you have to retype said name. I think the custom name part of this suggestion is easily done, increment only the number and don't reset the name of the formation I'm training until I click on another formation template to train.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 10, 2021, 02:17:59 PM
I know a lot of people would appreciate Ground Forces automatic name generation to be changed so it only starts counting the number of that specific template used instead of all of them (so you don't get 1st infantry battalion and then 2nd motorized battalion even though its the first mot battalion you built).

I'd go a step further and suggest that the game let us 'lock' in a custom name for the units you are about to train (for example, 'Mars Infantry Battalion) and then automatically apply numbers as you queue up production orders (so you get 1st Mars Infantry Battalion and then 2nd Mars Infantry Battalion and so on) until you unlock or change the custom name.

From the 1.13 changes:

Quote
Ordinal Numbers for ground formations will increment on a per-template basis rather than for all ground formations.

You can get the custom names to work by copying the formation template, if you don't mind a bit of extra clutter in the formations tab.
Title: Re: C# Suggestions
Post by: Black on January 12, 2021, 12:19:10 PM
Would it be possible to add choice to rename Order Templates?
Title: Re: C# Suggestions
Post by: Borealis4x on January 15, 2021, 05:14:59 AM
The ability to build shipyards to specific specifications right off the bat would be nice.

Obviously a larger shipyard with more slipways would take longer to build an require more resources, but you could make it more efficient in terms of time and resources to build a large shipyard from scratch than modify it over time, the downside being that the larger shipyards won't be available until its complete. 

Streamlining shipyard construction is very important for me, as I find myself spending a lot of time just queuing up upgrade orders and its very tedious.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 15, 2021, 06:23:57 AM
The ability to build shipyards to specific specifications right off the bat would be nice.

Obviously a larger shipyard with more slipways would take longer to build an require more resources, but you could make it more efficient in terms of time and resources to build a large shipyard from scratch than modify it over time, the downside being that the larger shipyards won't be available until its complete. 

Streamlining shipyard construction is very important for me, as I find myself spending a lot of time just queuing up upgrade orders and its very tedious.

The only thing that need to be added from this point of view are that slipways work as continual upgrade, you set the amount you need. You only need to interact two times to get to a specific yard. You could add a combination order to make it a one interaction only... but I would not think that is too important. But having the option to expand until you have X slipways should be simple enough to add.

I would not want an option for my construction factories to do this as that would in most cases be a complete waste of factory production as the yards can build themselves, I would never use that option for obvious reasons. Sure... you could potentially be pressed on time to get a yard up and factories could potential do it faster, but that would be in a desperate situation.
Title: Re: C# Suggestions
Post by: TMaekler on January 15, 2021, 11:45:06 AM
As SpaceMaster an option to create a Dummy-Technology which a nation has to research in order to be able to use certain tech combinations.

Trying to simulate Fuel Consumption Efficiency per Engine Type. So a dummy technology I can set up would help me not having to "keep a certain amount of research labs free for a specified time period to simulate the RPs needed for this".
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 16, 2021, 02:42:22 PM
Medal conditions for terraforming, awarded e.g. when a world has been terraformed to CC 0.0 (and then three/five/ten/etc. as appropriate). Mechanically: awarded to any commander of a terraforming ship/station at a planet on the game tick that planet reaches CC 0.0.
Title: Re: C# Suggestions
Post by: Black on January 17, 2021, 10:57:50 AM
I am using repair ships in my current campaign - based on commercial hangars. They work pretty nicely, but there is unfortunate consequence - repaired ships will suck all fuel from the repair ship if they have damaged fuel tanks. Would it be possible to add checkbox to forbid mothership to refuel parasites?
Title: Re: C# Suggestions
Post by: Droll on January 17, 2021, 11:01:20 AM
I am using repair ships in my current campaign - based on commercial hangars. They work pretty nicely, but there is unfortunate consequence - repaired ships will suck all fuel from the repair ship if they have damaged fuel tanks. Would it be possible to add checkbox to forbid mothership to refuel parasites?

Does this not exist already? If you select the mothership on the fleet OOB you should be able to access drop downs that affect resupply behaviour
Title: Re: C# Suggestions
Post by: Black on January 17, 2021, 11:50:33 AM
I am using repair ships in my current campaign - based on commercial hangars. They work pretty nicely, but there is unfortunate consequence - repaired ships will suck all fuel from the repair ship if they have damaged fuel tanks. Would it be possible to add checkbox to forbid mothership to refuel parasites?

Does this not exist already? If you select the mothership on the fleet OOB you should be able to access drop downs that affect resupply behaviour

I have dropdowns for resupply and ordnance, but not fuel. Does the resupply menu affects fuel as well?
Title: Re: C# Suggestions
Post by: Droll on January 17, 2021, 12:02:27 PM
I am using repair ships in my current campaign - based on commercial hangars. They work pretty nicely, but there is unfortunate consequence - repaired ships will suck all fuel from the repair ship if they have damaged fuel tanks. Would it be possible to add checkbox to forbid mothership to refuel parasites?

Does this not exist already? If you select the mothership on the fleet OOB you should be able to access drop downs that affect resupply behaviour

I have dropdowns for resupply and ordnance, but not fuel. Does the resupply menu affects fuel as well?

don't know, what you can do instead is go to the class design and set a minimum fuel level for the ship
So if you have 1m liters of fuel and you only want it to refuel down to 800k, you set the minimum fuel to 800k and maybe it'll stop refueling parasites
Title: Re: C# Suggestions
Post by: Black on January 17, 2021, 12:05:19 PM
don't know, what you can do instead is go to the class design and set a minimum fuel level for the ship
So if you have 1m liters of fuel and you only want it to refuel down to 800k, you set the minimum fuel to 800k and maybe it'll stop refueling parasites

That is a good idea, this should work. Thanks.
Title: Re: C# Suggestions
Post by: Borealis4x on January 17, 2021, 12:48:46 PM
An NPR 'Race Bank' where you can customize the NPR's that will appear in your game like a Player Race. Option would include the ability to the chances of encountering them as well as a threshold for how far away or close they have to be to Sol before having a chance to spawn (1 jump away? 2 jumps? 500 jumps?).

This, coupled with a way to easily save and import your races between games and updates would import what I think is the best feature from Stellaris.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 17, 2021, 04:06:11 PM
This would be neat for RP. Frankly, I'd even settle for Along with that, it would be nice to be able to change NPR race/ship/flag pics in-game. It's really not immersive when the bloodthirsty NPR that keeps sending deathball fleets into Sol has a dinky little 1960s satellite as their ship sprite.
Title: Re: C# Suggestions
Post by: Droll on January 17, 2021, 05:05:08 PM
It would be nice to be able to change NPR race/ship/flag pics in-game

Ummm you can?

SM mode, go to the alien intel screen, at the bottom you have a list of buttons, the rightmost 3 IIRC are the ones you want but you need SM mode enabled for them to show I think.
Title: Re: C# Suggestions
Post by: QuakeIV on January 17, 2021, 05:49:42 PM
Yea I think thats one of the few things you can change about NPRs from SM mode
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 18, 2021, 12:56:45 AM
I don't know how I never noticed that, but this makes my life much easier, thanks!
Title: Re: C# Suggestions
Post by: Darth Nihilus on January 18, 2021, 12:59:04 AM
be able to close any window with escape.
be able to save\load the new game settings to a json.
1 custom json for the system\class\rank names.
be able to save\load the race settings at a game start to a json.
checking the rank as story makes all the dudes in it to become story.
add an option to make any officer\scientis\admin adding (and removing) to the event-stopper.
a component or a command that reserves the fuel needed for the ship to rout between two choosable objects in space (for the tanker-harvester chain).
Title: Re: C# Suggestions
Post by: Norm49 on January 18, 2021, 10:27:22 AM
It wold be nice if we can order ground troop to execute civilian and have medal for the amount of civilian kill. A lot of people are making game were they play space ####.
Title: Re: C# Suggestions
Post by: Droll on January 18, 2021, 12:53:03 PM
When encountering an enemy with shields, the tactical map shows the shield HP but the intel screen does not show the shield HP, only the signature strength of the shield.

It would be nice if the intel screen showed both maximum observed shield signature and HP
Title: Re: C# Suggestions
Post by: serger on January 19, 2021, 09:55:05 AM
Trojan JP to be visible and usable after JP Theory research only.
Title: Re: C# Suggestions
Post by: kuhaica on January 19, 2021, 11:00:09 AM
It wold be nice if we can order ground troop to execute civilian and have medal for the amount of civilian kill. A lot of people are making game were they play space ####.
Could just SM pop away and make a medal for that
Title: Re: C# Suggestions
Post by: serger on January 19, 2021, 11:02:06 AM
Alien ruin points to be fractional values, which integer parts (that are large tough constructions) are to be digged by xenoarcheology parties, while fractional leftovers (that are small objects) are to be digged (like minerals do) by population as alien artifacts.
Title: Re: C# Suggestions
Post by: Froggiest1982 on January 20, 2021, 01:27:55 AM
Ability to open the fleet orders from the Naval Forces Tab in the Galactic Map.

When you have larger forces this will cut your time by a lot as you will not need to scroll through all your admin commands to find the proper fleet.
Title: Re: C# Suggestions
Post by: alex_g on January 20, 2021, 02:03:56 AM
It would be nice if we could exclude known commercial ships from auto targeting or maybe even exclude them from the target list on the ship combat screen - only if we have the intelligence on those ships and know they're commercial of course.

Also, settings for construction speed and growth speed would be great (similar to Research Speed, Terraforming Speed, etc...) and being able to use fractional values for all the speeds available, example: I would love to reduce survey speed below 1% because even so it's too fast for my taste.
Title: Re: C# Suggestions
Post by: Sunmannus on January 20, 2021, 05:30:52 AM
Title: Re: C# Suggestions
Post by: liveware on January 20, 2021, 05:40:54 AM
  • A "Update Unit Class Design" button (in the Ground Forces/Formation Templates tab) that automatically updates the racial armor and weapons of already created unit designs.  That way we would avoid having to recreate each and every one of the units and formations every time we achieve a technological advance in armor or weaponry.

    The idea of series of units is good as a replacement for units already created, but does not avoid the tedium of having to recreate the designs for all the different types of units in our game.  With this suggestion, with just one click we would update our Rifleman PW (Arm. 6-Str. 6) to Rifleman PW (Arm. 8-Str. 8), and so on with each element.

Alternatively, change it so that new ground units are always trained using latest racial tech instead of the racial tech that existed when the unit design was created. This would be arguably more realistic as well as easier to manage.
Title: Re: C# Suggestions
Post by: serger on January 20, 2021, 06:18:26 AM
I think the right way will be to create research tasks by "Update Request" button, not update all autonatically without Research Points use.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 20, 2021, 08:59:07 AM
I think the right way will be to create research tasks by "Update Request" button, not update all autonatically without Research Points use.
This is an important point as the RP cost for upgrading units must be preserved in such a new system.
Title: Re: C# Suggestions
Post by: Cosinus on January 20, 2021, 03:46:51 PM
Not sure if this was suggested before, but I would like it, if the colour of ship names in the ship list changed according to their damaged status, just like in the fleet tree view. This would allow players to see at a glance whether a ship in the fleet is damaged, without having to open the fleet and all the subfleets.

I've poorly edited in the orange colour, so you can see what it would look like.

EDIT: A better image:
(https://i.imgur.com/eqE4BrE.png)
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 20, 2021, 03:55:06 PM
Not sure if this was suggested before, but I would like it, if the colour of ship names in the ship list changed according to their damaged status, just like in the fleet tree view. This would allow players to see at a glance whether a ship in the fleet is damaged, without having to open the fleet and all the subfleets.

(https://i.imgur.com/MZurQL7.png)

I've poorly edited in the orange colour for 2 ships, so you can see what it would look like.

+1.

Piggyback: it would be nice to have a few more colors corresponding to the "Status" codes so we can see from the left-hand fleet tree which ships e.g. are in overhaul/refit, have sensors on, etc. This would help cut down on the amount of flipping-between-tabs in the Fleet window.
Title: Re: C# Suggestions
Post by: LiquidGold2 on January 20, 2021, 09:55:25 PM
Would it be possible to add a checkbox to exclude single ships from the maintenance system? It would presumably be an SM power.

I like to take capture enemy ships and bring them home as trophies, but as they're trophies that never align with my doctrine I never use them in actual combat.  I often don't even repair them.
I also like keeping "historical" ships instead of sending them to the breakers when they're no longer useful.


What I'd really like is a full mothball system, wherein you can trade ongoing maint requirements for "de-mothballing" time, to allow for the use of reserve fleets.  But I suspect that would involve a fair bit of work on Steve's end.  A simple version of this might be able to use the same system interrupted overhaul and boarding ship control penalties use.
Title: Re: C# Suggestions
Post by: TMaekler on January 21, 2021, 05:07:23 AM
Showing the actual max travel distance of an active tug would be nice somewhere in the ship info... maybe additionally a log entry which checks when a tug picks up another ship how far it can travel with that load. If the travel distance is larger than how far the tug with the load actually can go until the tug receives the release order, then a log entry should pop up warning you that a tug is going to be stranded in space if nothing is done.
Title: Re: C# Suggestions
Post by: TMaekler on January 21, 2021, 05:23:10 AM
For SpaceMaster Mode: In Role-play it is sometimes useful to add certain values to for example research or construction. Lets say you manage several parties and grant certain bonus actions for one player. Like a research bonus on a certain tech. It would make it easier for the SpaceMaster to simply add 50% research points to that one research rather than having to manually remember the shortened time when he has to "Instant" that tech for that one player. Same goes also in the other direction. Lets say you want to simulate an attack on a research facility where one of your scientists has died. As SpaceMaster you could simulate also the loss of research by being able to remove RP from that research.

And so on and so forth for anything that happens in game.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 21, 2021, 07:06:28 PM
I would like to be able to click on a system in the Galaxy map and have the main map focus on that system... If I double right click the system view comes up and if I double left click the tactical map centres and zoom in to that system.

After a while it become rather tedious to scroll through the list on the tactical map and navigating on the galaxy map would be so much easier.

Unless there already is a way to do this that I'm unaware of?!?



I would also like to have zoom on the galaxy map, would also help when the galaxy start to sprawl out.
Title: Re: C# Suggestions
Post by: alex_g on January 22, 2021, 02:04:13 AM
I would also like to have zoom on the galaxy map, would also help when the galaxy start to sprawl out.

Yes, please! I'm up to 400 star systems and the time it takes for me to get from one corner of the galaxy to the other is quite long.
Title: Re: C# Suggestions
Post by: QuakeIV on January 22, 2021, 03:55:00 AM
Showing the actual max travel distance of an active tug would be nice somewhere in the ship info... maybe additionally a log entry which checks when a tug picks up another ship how far it can travel with that load. If the travel distance is larger than how far the tug with the load actually can go until the tug receives the release order, then a log entry should pop up warning you that a tug is going to be stranded in space if nothing is done.

I'd prefer if it wasnt too incessant, I make fairly heavy use of tankers to top off tugs doing long term hauling jobs (the longest to my memory was 20 years or so) but I would find some indication of how far it can get without being topped up to be exceedingly useful.  Sometimes a hualing job is just flat out impractical and it would be nice to have an easy indication of that rather than having to do math (i will take a hard pass if i need to tank something more than like a dozen times at absolute most).
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 22, 2021, 06:17:47 AM
Another thing that is really tedious to manage are automated ship runs and when you need to go in and tweak or change them just slightly. Now you basically need to scrap their orders and give them new ones.

Instead it would be really helpful if we could just select an order in the list and update it with new conditional input, such as order delays, max/min mineral pickup and the like. Now I could just adjust the amount of mineral of each type a freighter pick up and/or drop off or change the delay to make a ship go more or less often to a specific destination.

When I change the factory production of a colony I might also need to change the minerals carried to that planet. When the colony expands it factory output I need to increase the visit of my mineral haulers to accommodate the higher production rate.

In addition to this I would also like for all installation to be affected by the max/min order conditions. It would be far easier to set up automated runs if my transport would sit and wait for the next Automine to be produce rather than me having to calculate how long it will take and use an order delay, this also means I have to recalculate this once in a while depending on production rates.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 22, 2021, 10:27:03 AM
I have another thing that I have been thinking of lately in regard to balance... I think that shipyards that are doing any sort of construction such as expanding the size or adding slipways should get half production capacity if it also are building any ships, or reduced production capacity based on the number of slipways currently under use.

The general issue I have with shipyards is in comparison to ground construction factories, here you have to actually choose if you want to build more factories or something else.

I'm not saying this is a huge issue as you are still dependent on mined resources, but the shipyards are in general terms really effective once you start pumping out terraforming, orbital mining bases in their own dedicated yards. As you can keep building these while expanding the yards to build even more of them.

In order to curtail the snowball effect a bit I would suggest that yards get an efficiency modifier based on how many slipways are in use at the same time, up to 50% if all of them are in use at the same time as it does any sort of upgrade on itself. If you don't want it to be as severe you could make the max penalty like 33% or 25% instead, or you could turn it into a new tech line that start the penalty at even worse like 75% (you loose overall productivity if you multi-task) and then reduce the penalty down to a much smaller one at really high technology.
Title: Re: C# Suggestions
Post by: serger on January 22, 2021, 01:18:00 PM
Maybe it's possible to compensate this with an ability to add their expantion capacity to other shiyard's expantion (so, in extremum, all yards of the same planet will be able to sum all their expantion capacity on the one, most critical, yard).
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 22, 2021, 01:36:34 PM
I have another thing that I have been thinking of lately in regard to balance... I think that shipyards that are doing any sort of construction such as expanding the size or adding slipways should get half production capacity if it also are building any ships, or reduced production capacity based on the number of slipways currently under use.

The general issue I have with shipyards is in comparison to ground construction factories, here you have to actually choose if you want to build more factories or something else.

I'm not saying this is a huge issue as you are still dependent on mined resources, but the shipyards are in general terms really effective once you start pumping out terraforming, orbital mining bases in their own dedicated yards. As you can keep building these while expanding the yards to build even more of them.

In order to curtail the snowball effect a bit I would suggest that yards get an efficiency modifier based on how many slipways are in use at the same time, up to 50% if all of them are in use at the same time as it does any sort of upgrade on itself. If you don't want it to be as severe you could make the max penalty like 33% or 25% instead, or you could turn it into a new tech line that start the penalty at even worse like 75% (you loose overall productivity if you multi-task) and then reduce the penalty down to a much smaller one at really high technology.

I would support even a simpler solution of making shipyards either/or - either they can do an expansion or they can build ships. As this would be quite restrictive currently I'd support coupling this with a significant boost to shipyard operations. To be less restrictive this could be on a per-slipway basis, i.e. a shipyard with two slipways can use one to build a cruiser and one to expand.

Net effect would be to create a decision between building ships and expanding the yard for future classes, while reducing the time it takes to get a fresh new shipyard up to useful capacity which presently is to be frank a bit of an annoyance.
Title: Re: C# Suggestions
Post by: Borealis4x on January 22, 2021, 01:54:41 PM
I have another thing that I have been thinking of lately in regard to balance... I think that shipyards that are doing any sort of construction such as expanding the size or adding slipways should get half production capacity if it also are building any ships, or reduced production capacity based on the number of slipways currently under use.

The general issue I have with shipyards is in comparison to ground construction factories, here you have to actually choose if you want to build more factories or something else.

I'm not saying this is a huge issue as you are still dependent on mined resources, but the shipyards are in general terms really effective once you start pumping out terraforming, orbital mining bases in their own dedicated yards. As you can keep building these while expanding the yards to build even more of them.

In order to curtail the snowball effect a bit I would suggest that yards get an efficiency modifier based on how many slipways are in use at the same time, up to 50% if all of them are in use at the same time as it does any sort of upgrade on itself. If you don't want it to be as severe you could make the max penalty like 33% or 25% instead, or you could turn it into a new tech line that start the penalty at even worse like 75% (you loose overall productivity if you multi-task) and then reduce the penalty down to a much smaller one at really high technology.

I would support even a simpler solution of making shipyards either/or - either they can do an expansion or they can build ships. As this would be quite restrictive currently I'd support coupling this with a significant boost to shipyard operations. To be less restrictive this could be on a per-slipway basis, i.e. a shipyard with two slipways can use one to build a cruiser and one to expand.

Net effect would be to create a decision between building ships and expanding the yard for future classes, while reducing the time it takes to get a fresh new shipyard up to useful capacity which presently is to be frank a bit of an annoyance.

I'll go against both of you for the sake of argument and say that shipyards should use Ground Construction Capacity. I don't think it makes sense that a shipyard would have to cease all operation cuz its building another slipway, but that building capacity should be coming from somewhere. Using GC to build out shipyards would give the player more control over how quickly they want them built and eliminate redundant techs like Shipyard Operations while making the game's systems more interconnected.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 22, 2021, 02:11:19 PM
I'll go against both of you for the sake of argument and say that shipyards should use Ground Construction Capacity. I don't think it makes sense that a shipyard would have to cease all operation cuz its building another slipway, but that building capacity should be coming from somewhere. Using GC to build out shipyards would give the player more control over how quickly they want them built and eliminate redundant techs like Shipyard Operations while making the game's systems more interconnected.

Assuming you mean factory production and not ground unit construction, this would certainly be interesting. However it would slow things down a lot especially in the early game. Part of the whole advantage of shipyards is that they can be used in parallel to planetside industry, so tying them to your factories reduces that benefit. It could certainly work as a from-scratch concept, but you'd need to rebalance the whole game economy to account for the additional demands on industry.
Title: Re: C# Suggestions
Post by: serger on January 22, 2021, 02:39:58 PM
Yards are space objects, not ground objects. They are to be build primarily by themselves. I'd like even to see completely different model of their initial construction: by construction spacecraft fleet (made by small craft factories), not by construction factories!
Title: Re: C# Suggestions
Post by: Borealis4x on January 22, 2021, 02:50:13 PM
Yards are space objects, not ground objects. They are to be build primarily by themselves. I'd like even to see completely different model of their initial construction: by construction spacecraft fleet (made by small craft factories), not by construction factories!

That sounds like the current system with extra steps tho. Construction Factories already make the initial yard, why wouldn't they make produce the expansions as well?
Title: Re: C# Suggestions
Post by: serger on January 22, 2021, 06:19:01 PM
That sounds like the current system with extra steps tho. Construction Factories already make the initial yard, why wouldn't they make produce the expansions as well?
Construction Factories already make the initial yard now, in current version. What I proposed - is excluse Construction Factories completely, except of them make Small Craft Factories (now Fighter Factories, but it's not Fighters, especially at the beginning of the game), which could make Construction spacecraft, which could make Shipyards.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 22, 2021, 06:27:57 PM
That sounds like the current system with extra steps tho. Construction Factories already make the initial yard, why wouldn't they make produce the expansions as well?

The initial yard one assumes is built in prefabricated sections and shuttled up into orbit by those invisible small ships that we never see but thanklessly perform vital tasks to keep our empires functional. Presumably once the yard is built, additional prefabbed sections don't make as much sense since we're not just chucking on another module but rather building something more carefully integrated to the yard and it must be built in place.

And again, in game terms clogging up planetside industry even more by requiring them to be used for shipyard operations would significantly slow down the economics of the game. That kind of major change isn't something that can be made lightly.
Title: Re: C# Suggestions
Post by: serger on January 22, 2021, 06:36:13 PM
Construction Factories already make the initial yard now, in current version. What I proposed - is excluse Construction Factories completely, except of them make Small Craft Factories (now Fighter Factories, but it's not Fighters, especially at the beginning of the game), which could make Construction spacecraft, which could make Shipyards.
Though no. I don't like this idea any more. Space crafts are not those who make yards - Borealis4x is right, they are moving it in orbit and mount there only, and this is already abstracted with shuttles. So, current model of initial buildup is good.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 22, 2021, 06:48:09 PM
Building anything in space by a construction factory should at least require a space station located at the same colony...   ;)

Construction yards in Aurora are not really like dockyards that build ships in Earth... dockyards on Earth mostly just assemble ships.

Construction yards in Aurora are entire factories in space that builds every component and part of a ship... they are basically giant factory and construction complexes, they also require allot of people to operate. I also think Steve said in the past that a majority of the worker is located on the planet and not in space... I also presume allot of the industry is on the planet surface as well.

I don't have any problem with yards being able to expand their own capacity... I just wish there was an efficiency modifier so you can't expand as fast as long as you also use the yard to build ships. I think this make sense both from a role-play and mechanics perspective.

If Steve would like to redo how ship yards work and divide them into a factory section and a slipway section that could be interesting too. Every planet would then basically have an orbital industry that is a pool for all slipways, the slipways are the machinery and infrastructure to assemble the ships. I also think you should be able to convert commercial yards to build military ships for a price and some time... they produce 1/12 the size and also a reduce the assembly speed with say a 25% penalty, commercial slipways should be able to be militarized in an emergency.

If the factory part is separate from the assembly there could be some interesting choices to be made. You also should be able to pre build ship components with your shipyard factories so you can store them for quicker assembly later, just as you can do with ground factories. It sometimes make sense to keep components around for strategical purposes.
Title: Re: C# Suggestions
Post by: serger on January 23, 2021, 02:05:08 AM
I also think you should be able to convert commercial yards to build military ships for a price and some time... they produce 1/12 the size and also a reduce the assembly speed with say a 25% penalty, commercial slipways should be able to be militarized in an emergency.

If the factory part is separate from the assembly there could be some interesting choices to be made. You also should be able to pre build ship components with your shipyard factories so you can store them for quicker assembly later, just as you can do with ground factories. It sometimes make sense to keep components around for strategical purposes.

Second these!
Title: Re: C# Suggestions
Post by: Warer on January 23, 2021, 06:15:16 AM
Redlining Engines-In combat engine boosting with a per tick chance to suffer a breakdown or engine explosion, based on the degree of boosting, and a disproportionately large rise in fuel consumption and a per tick cost in maintenance supplies.
Title: Re: C# Suggestions
Post by: captainwolfer on January 23, 2021, 10:42:08 AM
I have two suggestions:

1. Make turrets/guns set to Final Defensive Fire randomly choose which salvo to target
- Currently, if I shoot a salvo that targets 4 enemy ships, and the enemy can shoot down half the missiles, I know that always only 2 ships will be hit, since salvos are targeted in a set order.
- If instead each weapons randomly chose which salvo to target, then damage would be spread more equally unless all missiles were targeted on a single ship. This would also effectively increase the survivability of ships under missile attack, since you wouldn't have a only a few of the targeted ships taking all of the hits.

2. Make Auto-targeting choose targets based on size instead of seemingly randomly
- If Auto-target assigned weapons in the following order, I think it would generally work better, since bigger ships tend to be more dangerous
- Proposed order of targeting list: Largest to smallest ships with military engines, then largest to smallest ships with unknown engines, then finally largest to smallest commercial ships.
- This way, when you have less ships, the largest (and therefore usually most dangerous) enemy ships are targeted first, and once all military ships are targeted any ships that may be military are targeted, and then finally commercial ships are targeted. It also ensures that if you are using lots of small ships, the larger enemy ships are targeted more in general
Title: Re: C# Suggestions
Post by: Droll on January 23, 2021, 11:10:09 AM
Redlining Engines-In combat engine boosting with a per tick chance to suffer a breakdown or engine explosion, based on the degree of boosting, and a disproportionately large rise in fuel consumption and a per tick cost in maintenance supplies.

Hell no on the malfunctions, I agree that some "afterburner" mechanic should burn more fuel than usual. But the fuel use is already a big enough draw back of boosting engines, they don't need to be anymore explosive than they already are.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 23, 2021, 12:00:42 PM
Redlining Engines-In combat engine boosting with a per tick chance to suffer a breakdown or engine explosion, based on the degree of boosting, and a disproportionately large rise in fuel consumption and a per tick cost in maintenance supplies.
Hell no on the malfunctions, I agree that some "afterburner" mechanic should burn more fuel than usual. But the fuel use is already a big enough draw back of boosting engines, they don't need to be anymore explosive than they already are.

This would essentially have no impact for large ships, which have a high explosion chance already, and an always-on button for fighters. Without the breakdown chance this could be an interesting way to make beam fighter PD competitive but given the limited use I don't see this being added.
Title: Re: C# Suggestions
Post by: Borealis4x on January 23, 2021, 01:19:33 PM
Shouldn't techs like Infared Lasers and such effect Racial Weapon Strength instead of Laser Focal Size?
Title: Re: C# Suggestions
Post by: Droll on January 23, 2021, 01:25:02 PM
Shouldn't techs like Infared Lasers and such effect Racial Weapon Strength instead of Laser Focal Size?

Focal size affects per-shot damage whereas wavelength affects range. Given the expected engagement ranges on the ground I think it makes sense that the focal size tech matters more on the ground.
Title: Re: C# Suggestions
Post by: Gabrote42 on January 23, 2021, 02:05:40 PM
Redlining Engines-In combat engine boosting with a per tick chance to suffer a breakdown or engine explosion, based on the degree of boosting, and a disproportionately large rise in fuel consumption and a per tick cost in maintenance supplies.

Hell no on the malfunctions, I agree that some "afterburner" mechanic should burn more fuel than usual. But the fuel use is already a big enough draw back of boosting engines, they don't need to be anymore explosive than they already are.
IIRC, last time we had one of those it got super removed (was it called hyperdrive?). My guess is that Steve wants to keep components more fixed.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 23, 2021, 02:16:03 PM
IIRC, last time we had one of those it got super removed (was it called hyperdrive?). My guess is that Steve wants to keep components more fixed.

One of the big design goals with C# was to get rid of "special cases" that were present in VB6 and keep everything working by the same set of mechanics. For example that's why we don't have PDCs anymore, which were basically a special case of ships, and instead we have STOs which are their own thing as a ground forces element. Conceptually not that different but mechanically much better for Steve the programmer. Similarly this is why we no longer have separate missile engines as now the same engines as everything else with an overboost feature.
Title: Re: C# Suggestions
Post by: serger on January 23, 2021, 02:17:24 PM
Focal size affects per-shot damage
In the cost of the size, and that is what infantry cannot pay.
Title: Re: C# Suggestions
Post by: Droll on January 23, 2021, 02:36:56 PM
Focal size affects per-shot damage
In the cost of the size, and that is what infantry cannot pay.

I mean the smallest laser IIRC is 150 tons and an infantryman in most cases takes 5 tons maybe 6 if you like PWI.
Meanwhile the lowest tech infrared gives infantry weapons that can fire out to 10,000km, which I'm going to assume is not a feasibly usable range for a dude with a laser gun.

For a 12mm focal size infantry "machinegun" compared to 10cm(100mm) focal size space gun if we assume linear progression that results in 1,100 km range, 10% of this is still 110km in case of damage falloff so suffice to say, regardless of what wavelength technology that you have, it won't have any effect on the damage potential of ground weapons. Maybe you could argue artillery - but indirect fire laser artillery doesn't make sense anyways.

On the other hand with focal size you could argue that it also represents the increase in the complexity of laser weapons and not just the raw size that it can be built in. Something which could feasibly benefit a laser armed ground army.

IMO now that I think about it it probably makes more sense to have capacitor tech affect racial weapon tech since it is important for almost every type of energy weapon in the game and allows you more RP flexibility. Only problem is capacitor tech only goes up to 25 but then again rakhas only have 15 racial weapon strength anyways. Capacitors make even more sense in the context of lasers because it usually is the main driving factor when using reduced size lasers - directly attacking the argument that lasers too big for infantry.
Title: Re: C# Suggestions
Post by: Borealis4x on January 24, 2021, 12:23:08 AM
Someone had an idea somewhere about adding in commercial buoy launchers for launching sensors and such. I'd like to second it; you shouldn't need to dedicate a military ship to setting up buoys. Hell, I'd ask if a regular freighter could deploy them if possible; no reason to need a special launch system other than game engine restraints.
Title: Re: C# Suggestions
Post by: serger on January 24, 2021, 02:40:42 AM
I mean the smallest laser IIRC is 150 tons and an infantryman in most cases takes 5 tons maybe 6 if you like PWI.
Meanwhile the lowest tech infrared gives infantry weapons that can fire out to 10,000km, which I'm going to assume is not a feasibly usable range for a dude with a laser gun.

For a 12mm focal size infantry "machinegun" compared to 10cm(100mm) focal size space gun if we assume linear progression that results in 1,100 km range, 10% of this is still 110km in case of damage falloff so suffice to say, regardless of what wavelength technology that you have, it won't have any effect on the damage potential of ground weapons.

Well, linear formulas of Aurora mechanics just are not those I'm happy to see - too much physical and mathematical education sitting in my head - and so I'm just not looking at this direction if I could.
But tech line names and their general logics - there is no option of not looking at this direction, that is what I must play with (well, some part I can rewrite in DB, changing tech names only to not break smth). And I cannot beleave that you can directly improve infantry weapon researching bigger naval guns. But I can beleave - there is nothing to beleave really, because it's natural - that tech line, leading to increase of effective range of any gun (any caliber of them) will improve infantry weapon in the same way.


Maybe you could argue artillery - but indirect fire laser artillery doesn't make sense anyways.

Yep. I'd suggest tha arty must depend on kinetic techs only.

IMO now that I think about it it probably makes more sense to have capacitor tech affect racial weapon tech

Second this.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 24, 2021, 08:54:12 AM
Focal size affects per-shot damage
In the cost of the size, and that is what infantry cannot pay.

I mean the smallest laser IIRC is 150 tons and an infantryman in most cases takes 5 tons maybe 6 if you like PWI.
Meanwhile the lowest tech infrared gives infantry weapons that can fire out to 10,000km, which I'm going to assume is not a feasibly usable range for a dude with a laser gun.

For a 12mm focal size infantry "machinegun" compared to 10cm(100mm) focal size space gun if we assume linear progression that results in 1,100 km range, 10% of this is still 110km in case of damage falloff so suffice to say, regardless of what wavelength technology that you have, it won't have any effect on the damage potential of ground weapons. Maybe you could argue artillery - but indirect fire laser artillery doesn't make sense anyways.

On the other hand with focal size you could argue that it also represents the increase in the complexity of laser weapons and not just the raw size that it can be built in. Something which could feasibly benefit a laser armed ground army.

IMO now that I think about it it probably makes more sense to have capacitor tech affect racial weapon tech since it is important for almost every type of energy weapon in the game and allows you more RP flexibility. Only problem is capacitor tech only goes up to 25 but then again rakhas only have 15 racial weapon strength anyways. Capacitors make even more sense in the context of lasers because it usually is the main driving factor when using reduced size lasers - directly attacking the argument that lasers too big for infantry.

It is all just an abstraction... the weapons technology is just the level of technology that you can use with ground troops as the general basis for warfare. It is not like you will put a 10cm laser in the hands of an infantryman, that would just be absurd.

The stats for ship mounted weapons have nothing to do with ground based weapons in the slightest in this regard.
Title: Re: C# Suggestions
Post by: Droll on January 24, 2021, 02:42:28 PM
It is all just an abstraction... the weapons technology is just the level of technology that you can use with ground troops as the general basis for warfare. It is not like you will put a 10cm laser in the hands of an infantryman, that would just be absurd.

You are right, no one here believes that we are giving infantry 10cm lasers.

But what if your empire has only ever researched laser technology? Then suffice to say your infantry though not using naval lasers, will use some form of laser weaponry. Your argument only holds up in scenarios where an empire has multi-specced into different weapon types which leaves it as an RP restrictive line of thought.

That is why we suggested capacitor tech as the driver for ground based weapon tech - every energy weapon that affects the ground weapon strength is affected by capacitor strength, meaning that it provides a much stronger abstraction to ground combat power (since we are assuming that they are based on energy weapons). Now you can imagine a scenario where although the only naval grade weapon you have researched are lasers, you can much more easily justify the fact that your infantry and artillery are more powerful while also pretending that they are ground based railguns.

If researching lasers is what made my ground army stronger why would they be using non-laser weapons?
Title: Re: C# Suggestions
Post by: Borealis4x on January 24, 2021, 08:36:38 PM
I wonder if one day ground units will be as customizable as ships, being made up of multiple components you have to design separately. Like body-armor and weapons.

Ground Units need more work to make them less of a hassle to manage first tho.
Title: Re: C# Suggestions
Post by: Droll on January 25, 2021, 09:46:53 AM
Like ships, STOs can be built from components (weapons) in the stockpile, reducing their production time significantly
Title: Re: C# Suggestions
Post by: Kylemmie on January 25, 2021, 10:49:48 AM
Like ships, STOs can be built from components (weapons) in the stockpile, reducing their production time significantly

Now this is something I've wondered but assumed not since there is no 'use components' checkbox for GU (unless I'm blind, happened before). Seems odd for Steve to give us the choice in shipyard construction but not GU? So if I build STO's with my best Lasers that I'm stockpiling for a naval rush build....the GU STO production will scarf them up?

I totally get the benefit when this mechanic is known and can be planned for, but the current mechanic as presented here seems at odds with what a new player would assume. I have the choice here but not here, so it must work differently. i.e. Not the same.
Title: Re: C# Suggestions
Post by: Droll on January 25, 2021, 11:01:50 AM
Like ships, STOs can be built from components (weapons) in the stockpile, reducing their production time significantly

Now this is something I've wondered but assumed not since there is no 'use components' checkbox for GU (unless I'm blind, happened before). Seems odd for Steve to give us the choice in shipyard construction but not GU? So if I build STO's with my best Lasers that I'm stockpiling for a naval rush build....the GU STO production will scarf them up?

Wait you've confused me, to clarify:
That post is me suggesting that we have the option to use components to build STOs, it is not saying that STOs use components right now - they don't and cannot use the component stockpile as of right now.
Title: Re: C# Suggestions
Post by: xenoscepter on January 25, 2021, 04:40:35 PM
 - A crazy, stupid idea... what if we could deploy Buoys and/or Mines from Cargo Holds? Haver it so that Cargo Holds could carry any missile or missile stage w/o an engine and then drop them on their location. No active target allowed, but no MFCS needed or indeed even useable. It *could* be used offensively or defensively... technically, for AMMs with active sensor "cans", or big sensor cans to engage a target with the actives... but that's hardly game changing I'd reckon.

 - Maybe have the option to deploy them from magazines? I dunno, perhaps tie it to a cargo shuttle bay. I'd honestly like a minelayer / buoy dropping module...
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on January 25, 2021, 04:55:44 PM
- A crazy, stupid idea... what if we could deploy Buoys and/or Mines from Cargo Holds? Haver it so that Cargo Holds could carry any missile or missile stage w/o an engine and then drop them on their location. No active target allowed, but no MFCS needed or indeed even useable. It *could* be used offensively or defensively... technically, for AMMs with active sensor "cans", or big sensor cans to engage a target with the actives... but that's hardly game changing I'd reckon.

 - Maybe have the option to deploy them from magazines? I dunno, perhaps tie it to a cargo shuttle bay. I'd honestly like a minelayer / buoy dropping module...

Unless you are wanting this to be commercial, it's not significantly different than a magazine+pile of launchers+min size MFC. At that point, why add it?
Title: Re: C# Suggestions
Post by: xenoscepter on January 25, 2021, 05:09:32 PM
- A crazy, stupid idea... what if we could deploy Buoys and/or Mines from Cargo Holds? Haver it so that Cargo Holds could carry any missile or missile stage w/o an engine and then drop them on their location. No active target allowed, but no MFCS needed or indeed even useable. It *could* be used offensively or defensively... technically, for AMMs with active sensor "cans", or big sensor cans to engage a target with the actives... but that's hardly game changing I'd reckon.

 - Maybe have the option to deploy them from magazines? I dunno, perhaps tie it to a cargo shuttle bay. I'd honestly like a minelayer / buoy dropping module...

Unless you are wanting this to be commercial, it's not significantly different than a magazine+pile of launchers+min size MFC. At that point, why add it?

 - I seem to have been unclear, I want this to be commercial. Be able to store Buoys in a Cargo Hold with Missile Size = Cargo Points, to account for the stowage kit. So a 500 Ton Cargo Hold could hold 100 Szie 5 Missiles, or 5 Size 100 missiles or 50 Size 10 Missiles, etc. I only included mines in my suggestions because I felt it'd be a bit dumb to not be able to dump those too.
Title: Re: C# Suggestions
Post by: captainwolfer on January 25, 2021, 05:56:36 PM
- A crazy, stupid idea... what if we could deploy Buoys and/or Mines from Cargo Holds? Haver it so that Cargo Holds could carry any missile or missile stage w/o an engine and then drop them on their location. No active target allowed, but no MFCS needed or indeed even useable. It *could* be used offensively or defensively... technically, for AMMs with active sensor "cans", or big sensor cans to engage a target with the actives... but that's hardly game changing I'd reckon.

 - Maybe have the option to deploy them from magazines? I dunno, perhaps tie it to a cargo shuttle bay. I'd honestly like a minelayer / buoy dropping module...

Unless you are wanting this to be commercial, it's not significantly different than a magazine+pile of launchers+min size MFC. At that point, why add it?

 - I seem to have been unclear, I want this to be commercial. Be able to store Buoys in a Cargo Hold with Missile Size = Cargo Points, to account for the stowage kit. So a 500 Ton Cargo Hold could hold 100 Szie 5 Missiles, or 5 Size 100 missiles or 50 Size 10 Missiles, etc. I only included mines in my suggestions because I felt it'd be a bit dumb to not be able to dump those too.
We already have commercial magazines, though. I could see the use of a commercial "Buoy Deployer" though. It would make minelayers and sensor buoy deployment ships much more economical
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 25, 2021, 06:43:16 PM
Commercial buoy launchers have been suggested a few times before, at least I know I've suggested it.

We do have a bit of a compromise in 1.13 in that Steve is adjusting how ships types are determined for commander auto-assign, so that a ship with survey sensors outmassing weapons will be a survey ship rather than a warship, which makes mounting (military) buoy droppers not throw a wrench into the auto-assign. As survey ships are a natural choice for buoy droppers and are always military ships anyways this change should help a lot.
Title: Re: C# Suggestions
Post by: Erik L on January 25, 2021, 11:34:27 PM
The option of a medal to grant a title also.

Bob Smith gets the KBE and gets to be Sir Bob Smith.
Title: Re: C# Suggestions
Post by: Droll on January 26, 2021, 03:55:06 PM
The game should probably notify the player if a new aether rift has opened in one of their populated systems. Apparently I've had one thats now grown to 40m in diameter in one of my systems with 400m people and never saw it because I usually just keep my view on sol.

I don't think it would clutter my game logs too much.
Title: Re: C# Suggestions
Post by: Demonius on January 26, 2021, 08:56:40 PM
2 RP things:

1. Mix the Home Worlds and the Academies that the people graduated from. At least a bit. If Planets that are 10M+ pop without an Academy are also added to the name pool, even better. Like, John Smith, born on Earth, graduated from the Sirius Academy or Jane Doe, born on Alpha Centauri, graduated at Sol Academy.

2. the building company that was the original builder should be preserved somewhere in the Ship Infos.

I think both features were in place in VB6.
Title: Re: C# Suggestions
Post by: xenoscepter on January 27, 2021, 01:12:38 AM
 - I'd like to see the ability to create Academies as separate entities, for example: Earth has 27 Military Academies. I would like the ability to divide these into 9 Naval, 9 Ground Forces and 9 Scientific Academies. The sub-divided those among independent commandants, so 3 Naval Fighter, 3 Naval Survey, 3 Naval Crew Training and so on and so forth. Not sure how hard that would be to implement though...
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 27, 2021, 08:08:40 AM
Something that I really would like to have, mostly of RP purposes would be a standing order for patrolling a system. If a fleet is ordered for a patrol order they should more or less randomly move to mining sites, colonies or follow civilian ships in the system. They probably also should randomly set their speed to move relatively slowly as they are not suppose to burn their fuel too much, the idea is they should be out there patrolling.

 They should not move to other systems but stay in the system where they are.
Title: Re: C# Suggestions
Post by: Iceranger on January 27, 2021, 03:00:36 PM
Not sure if it has been suggested before, but I think a new tech line improving the efficiency for engineering spaces could be interesting. With higher 'engineering efficiency', we should be able to achieve the same maintenance life with less percentage of the ship devoted to the engineering spaces.
Title: Re: C# Suggestions
Post by: TMaekler on January 27, 2021, 03:30:22 PM
Mining Focus: I would like to see a mining focus for each mineral. I find it odd (and annoying) that the amount of minerals you get out of the soil is solely dependent upon how accessible it is. It would therefore be nice if we could increase or decrease the mining focus for each mineral. Since these factories are very modern and specialized, they should be able to focus on certain minerals.

So how should that work?

Let's say you have the following minerals on a planet:
Duranium 2.344.415t @0,4
Gallicite 455.209t @0,1
Mercassium 12.580t @0,9

Your mines will deplete Mercassium very quickly due to the low amount AND high extraction efficiency. Gallicite and Duranium would be depleted almost at the same time due to the combination of amount and extraction efficiency. But let's say that you do have a Gallicite shortage - how convenient would it be if you could focus the mines on this planet to gallicite for a while?

These focuses should be limited though. Max double the amount should be possible. So with focus added this would look like:
Duranium @0,4 Focus:0,5 =@0,2
Gallicite @0,2 Focus:2,0 =@0,2
Mercassium @0,9 Focus:0,5 = @0,45

You would lose 1/x of the efficiency of all other minerals but gain it for the one you want to focus on. Overall you would lose, but it could be a nice help if you get into a mineral crisis... .
Title: Re: C# Suggestions
Post by: serger on January 27, 2021, 03:58:32 PM
Not sure if it has been suggested before, but I think a new tech line improving the efficiency for engineering spaces could be interesting. With higher 'engineering efficiency', we should be able to achieve the same maintenance life with less percentage of the ship devoted to the engineering spaces.
Can be merged with Maintenance Production Rate (rename on smth like Maintenance Efficiency).
Title: Re: C# Suggestions
Post by: TMaekler on January 28, 2021, 06:55:07 AM
Racial Growth Rate seems to me to be too high. I was wondering if like research and other stuff could be controlled by a factor, racial growth could also. I usually play with 20% Research so all techs are longer valid - why not the same for racial growth? Could you add a similar factor to the general game parameters for racial growth? I certainly would appreciate it - especially for a conventional start it is near impossible to keep people from unemployment.
Title: Re: C# Suggestions
Post by: TMaekler on January 28, 2021, 07:09:52 AM
I was wondering how newly detected ship classes could be identified as coming from a before unknown empire... . Surely there are indicators like markings on the hull (if identifiable) or later audio or visual communication. But as long as a new detected ship class cannot be identified as belonging to a specific race, it should be "falsely" put into the wrong empire (yes, I know the problems with the actual structure of the database - I am just thinking aloud).

The idea here is as follows: In a multiplayer campaign captured ships could be used for false flag operations. Inciting war between two enemy factions. Just think about what could become possible storewise with this "tool"... .
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 28, 2021, 11:20:34 AM
Mining Focus: I would like to see a mining focus for each mineral. I find it odd (and annoying) that the amount of minerals you get out of the soil is solely dependent upon how accessible it is. It would therefore be nice if we could increase or decrease the mining focus for each mineral. Since these factories are very modern and specialized, they should be able to focus on certain minerals.

So how should that work?

Let's say you have the following minerals on a planet:
Duranium 2.344.415t @0,4
Gallicite 455.209t @0,1
Mercassium 12.580t @0,9

Your mines will deplete Mercassium very quickly due to the low amount AND high extraction efficiency. Gallicite and Duranium would be depleted almost at the same time due to the combination of amount and extraction efficiency. But let's say that you do have a Gallicite shortage - how convenient would it be if you could focus the mines on this planet to gallicite for a while?

These focuses should be limited though. Max double the amount should be possible. So with focus added this would look like:
Duranium @0,4 Focus:0,5 =@0,2
Gallicite @0,2 Focus:2,0 =@0,2
Mercassium @0,9 Focus:0,5 = @0,45

You would lose 1/x of the efficiency of all other minerals but gain it for the one you want to focus on. Overall you would lose, but it could be a nice help if you get into a mineral crisis... .

Steve has explicitly stated that he has zero interest in anything of this sort.
Title: Re: C# Suggestions
Post by: ZimRathbone on January 28, 2021, 04:58:33 PM
Something that I really would like to have, mostly of RP purposes would be a standing order for patrolling a system. If a fleet is ordered for a patrol order they should more or less randomly move to mining sites, colonies or follow civilian ships in the system. They probably also should randomly set their speed to move relatively slowly as they are not suppose to burn their fuel too much, the idea is they should be out there patrolling.

 They should not move to other systems but stay in the system where they are.

Sounds very like the old training behavior in VB...units  while in training would have orders generated to move them around the system to random locations at  random speed.
Title: Re: C# Suggestions
Post by: QuakeIV on January 28, 2021, 09:20:22 PM
In defense of the current system, you could argue that the TN minerals are spread in a kindof generally uniform distribution and there isn't any way to focus on one over the other, so in other words its possible for it to make sense that there is no way to focus.

Its noteworthy though that due to how accessibility works (a fixed 0-1 scale except when there are multiple minerals in which case it add up to a lot higher) you will get a vastly higher overall rate of extraction if you have multiple minerals on the planet you are currently mining.  Assuming all minerals are more or less uniformly distributed wherever it is they are being extracted from, if you limited all minerals to add up to a total of '1' accessiblity at a maximum, then it would also act to normalize the productivity of mines in the same way that allowing them to freely specialize towards one mineral would.
Title: Re: C# Suggestions
Post by: papent on January 28, 2021, 11:53:22 PM
unsure if previously mentioned before:

commercial import and export of minerals for colonies via a set of radio buttons/dropdown list on the mining screen just below the CMC tax/purchase option
for import options:
A) do not import minerals
B) Import to reserve levels
C) Import mineral shortfalls [this is already calculated and displayed on the mineral screen as an orange highlight of a mineral]
D) Import everything in system

for export options:
A) do not export minerals
B) export to reserve levels
C) export everything anywhere
D) export to system only

Could lead to possible interempire trading as commercial fleets of friendlies and allies fill mineral movement contracts and the ghost minerals from tax CMC's are sent to friendly empires.
as usually i'm unsure how much of the current trade code would be applicable to such a idea.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 29, 2021, 10:40:44 AM
unsure if previously mentioned before:

commercial import and export of minerals for colonies via a set of radio buttons/dropdown list on the mining screen just below the CMC tax/purchase option
for import options:
A) do not import minerals
B) Import to reserve levels
C) Import mineral shortfalls [this is already calculated and displayed on the mineral screen as an orange highlight of a mineral]
D) Import everything in system

for export options:
A) do not export minerals
B) export to reserve levels
C) export everything anywhere
D) export to system only

Could lead to possible interempire trading as commercial fleets of friendlies and allies fill mineral movement contracts and the ghost minerals from tax CMC's are sent to friendly empires.
as usually i'm unsure how much of the current trade code would be applicable to such a idea.

I like this idea as it is much more immersive than mass drivers and much less micro work than manual freighter transport. I doubt it gets added because we have Mass Drivers and civvies cause enough lag already, but I really like it.
Title: Re: C# Suggestions
Post by: Borealis4x on January 29, 2021, 11:10:51 AM
Such a mechanic wouldn't be useful for inter-system trade, true, but extremely valuable for planets in other systems. I currently use cheap light traders to try and make all minerals available to system capitals and distribute them via mass drivers from their, but it is a very inexact science with the current tools available.

Since civies are too unreliable, I'd like to put my own ships under the control of a personal shipping company controlled by the civilian AI that always takes our shipping contracts and nothing else. Be a good dumping ground for obsolete freighters I cant convert.
Title: Re: C# Suggestions
Post by: serger on January 29, 2021, 11:33:28 AM
It's quite inconsistent now that the most natural type of armoured battle machines (those with mixed weapon, smth like main battle tanks and assault armoured machines), just as the most natural types of battle orders (mixed ones too - infantry with battle machines and mixed weapon types) are rather meaningless against most of decent, nearly-equal-tech enemies, at least during assault or meeting engagement, because with current ground battle model they have no option to select their targets, and so relatively low fire performance of armored battle machines makes them nearly useless in the beginning of battle with it's huge numbers of small targets. Battle machines with this ground battle model have only a niche of baffle pursuit force: elements, that are designed for the finishing blow against enemy's survived armored machines in the end of long, multistage battle.

To give them an ability to contribute in battle from it's beginning and to open a niche of midsized assault machines, I'd suggest to change battle model in two ways:

1. More dividing of front line and battle phase, so that each battle location will be separated from direct fire of units, placed on other locations, and, on the other hand, each battle phase divided to more successive (iterative) subphases.
2. Confined breakthrough rule can be added to these subphases, adding assaulting units an ability to continue an advance, while their opponents are suppressed. Confined breakthrough might be different from full breakthrough in that during subphases there is no ability to change opposing formation or even location, so assaulting subformation is just continue to push with their high-morale units againt opponent in the same location. That will make those units with high armour levels effectively more fire performance and give armors their natural assault role, instead of finishing blow tool in the most intense battles they are now.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 29, 2021, 12:33:53 PM
It's quite inconsistent now that the most natural type of armoured battle machines (those with mixed weapon, smth like main battle tanks and assault armoured machines), just as the most natural types of battle orders (mixed ones too - infantry with battle machines and mixed weapon types) are rather meaningless against most of decent, nearly-equal-tech enemies, at least during assault or meeting engagement, because with current ground battle model they have no option to select their targets, and so relatively low fire performance of armored battle machines makes them nearly useless in the beginning of battle with it's huge numbers of small targets. Battle machines with this ground battle model have only a niche of baffle pursuit force: elements, that are designed for the finishing blow against enemy's survived armored machines in the end of long, multistage battle.

To give them an ability to contribute in battle from it's beginning and to open a niche of midsized assault machines, I'd suggest to change battle model in two ways:

1. More dividing of front line and battle phase, so that each battle location will be separated from direct fire of units, placed on other locations, and, on the other hand, each battle phase divided to more successive (iterative) subphases.
2. Confined breakthrough rule can be added to these subphases, adding assaulting units an ability to continue an advance, while their opponents are suppressed. Confined breakthrough might be different from full breakthrough in that during subphases there is no ability to change opposing formation or even location, so assaulting subformation is just continue to push with their high-morale units againt opponent in the same location. That will make those units with high armour levels effectively more fire performance and give armors their natural assault role, instead of finishing blow tool in the most intense battles they are now.

I don't agree with the assessment here. Rather opposite, I think it is good that mixed machines/formations are not appreciably superior to monoform. This allows players to design units and formations according to whatever RP they wish without having to worry too much about deploying a "suboptimal" configuration.

Further, even if there is no tangible difference between mixed formations and mixed forces of monolithic formations, there is still a clear value in having combined arms in some capacity whether this means at the company/battalion level or by landing one armored division for every two infantry divisions to make an assault.

The topic of random vs selective targeting has been debated as nauseum in many threads by now. I will only say that personally I largely prefer the ground battle system as it is, due to its simplicity and general friendliness to RP over minimaxing. I personally would consider accurate targeting something of a restrictive headache, depending on its implementation, and certainly don't want to deal with a complicated frontage system in my game that was advertised as being about spaceships.
Title: Re: C# Suggestions
Post by: papent on January 29, 2021, 01:13:54 PM
Such a mechanic wouldn't be useful for inter-system trade, true, but extremely valuable for planets in other systems. I currently use cheap light traders to try and make all minerals available to system capitals and distribute them via mass drivers from their, but it is a very inexact science with the current tools available.

Since cities are too unreliable, I'd like to put my own ships under the control of a personal shipping company controlled by the civilian AI that always takes our shipping contracts and nothing else. Be a good dumping ground for obsolete freighters I cant convert.

I would love to loan out part of my Government fleet to Civvies groups. mass drivers are very practical unless you trying to ship minerals between a primary and secondary with distance in billions of K
Title: Re: C# Suggestions
Post by: serger on January 29, 2021, 01:28:38 PM
I don't agree with the assessment here. Rather opposite, I think it is good that mixed machines/formations are not appreciably superior to monoform.

My point was not that they are not appreciably superior to monoform. My point was that they are obviously inferior to monoform both in the first and in the final phases of battle.
You say you want an RP freedom and less micro during ground battles and less penalties with efficiency? Well, what I proposed is serving your declared goal exactly: you'll have much easier way to balance army against averaged opponent, while more scurpulous players will have their complicated toys too.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 29, 2021, 01:39:53 PM
I don't agree with the assessment here. Rather opposite, I think it is good that mixed machines/formations are not appreciably superior to monoform.

My point was not that they are not appreciably superior to monoform. My point was that they are obviously inferior to monoform both in the first and the final phases of battle.
You say you want an RP freedom and less micro durinf grounf battles and less penalties with efficiency? Well, what I proposed is serving your declared goal exactly: you'll have much easier way to balance army against averaged opponent, while more scurpulous player will have their complicated toys too.

In what way are they obviously inferior? The only thing I am really aware of is that mixed CAP and AV are more GSP-heavy than using CAP and sending in AV after the enemy infantry are dead, which is admittedly not ideal but a fairly small issue in relative terms. Any other mechanics that I can think of are suitably averaged over the formation so that two mixed formations will perform similarly to two distinctive formations. Unfortunately your OP is not very clear as it only mentions target selection.
Title: Re: C# Suggestions
Post by: serger on January 29, 2021, 02:12:55 PM
In what way are they obviously inferior? The only thing I am really aware of is that mixed CAP and AV are more GSP-heavy than using CAP and sending in AV after the enemy infantry are dead, which is admittedly not ideal but a fairly small issue in relative terms.

An opportunity of losing your supply before the end of battle, caused by GSP load of inefficient (in this stage of battle) heavy AV weapons, will be enough, obviously! You can lose all the battle because of this supply shortage only.

But that's not all. Throwing your battle machines in the battle while they just cannot decently contribute yet - it's causing them to suffer losses from enemy infantry, static and light vehicles AV weapons! And in the end of battle, when you'll desperately need these your armoured machines, because they are the only ones that can cope with enemy counterparts - you'll have not enough of them any more because of that early losses!
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 29, 2021, 02:43:38 PM
It's quite inconsistent now that the most natural type of armoured battle machines (those with mixed weapon, smth like main battle tanks and assault armoured machines), just as the most natural types of battle orders (mixed ones too - infantry with battle machines and mixed weapon types) are rather meaningless against most of decent, nearly-equal-tech enemies, at least during assault or meeting engagement, because with current ground battle model they have no option to select their targets, and so relatively low fire performance of armored battle machines makes them nearly useless in the beginning of battle with it's huge numbers of small targets. Battle machines with this ground battle model have only a niche of baffle pursuit force: elements, that are designed for the finishing blow against enemy's survived armored machines in the end of long, multistage battle.

To give them an ability to contribute in battle from it's beginning and to open a niche of midsized assault machines, I'd suggest to change battle model in two ways:

1. More dividing of front line and battle phase, so that each battle location will be separated from direct fire of units, placed on other locations, and, on the other hand, each battle phase divided to more successive (iterative) subphases.
2. Confined breakthrough rule can be added to these subphases, adding assaulting units an ability to continue an advance, while their opponents are suppressed. Confined breakthrough might be different from full breakthrough in that during subphases there is no ability to change opposing formation or even location, so assaulting subformation is just continue to push with their high-morale units againt opponent in the same location. That will make those units with high armour levels effectively more fire performance and give armors their natural assault role, instead of finishing blow tool in the most intense battles they are now.

I don't agree with the assessment here. Rather opposite, I think it is good that mixed machines/formations are not appreciably superior to monoform. This allows players to design units and formations according to whatever RP they wish without having to worry too much about deploying a "suboptimal" configuration.

Further, even if there is no tangible difference between mixed formations and mixed forces of monolithic formations, there is still a clear value in having combined arms in some capacity whether this means at the company/battalion level or by landing one armored division for every two infantry divisions to make an assault.

The topic of random vs selective targeting has been debated as nauseum in many threads by now. I will only say that personally I largely prefer the ground battle system as it is, due to its simplicity and general friendliness to RP over minimaxing. I personally would consider accurate targeting something of a restrictive headache, depending on its implementation, and certainly don't want to deal with a complicated frontage system in my game that was advertised as being about spaceships.

No... the best units in the game are specialised units and you ALWAYS want to keep your heavier guns in reserve until you eliminated most of the lighter enemy units. (medium vehicles with heavy or medium guns is awesome for their cost to fight enemy vehicles this way). This creates a rather boring micro intensive way to conduct battles. If you assault a world you should basically keep your heavy gunned units in orbit so they don't waste shots and thus LOG units against enemy infantry they will not hit anyway and even if they hit them it is not wort it. Once most of the enemy infantry is taken care of by your CAP and HACP equiped heavy vehicles and infantry you retire most of the CAP vehicles and land the vehicles and heavy artillery with the heavy guns to blast all of the heavy enemy stuff upp.

This is the effect of random targeting. The current mechanic only allow RP on the surface due to how the mechanic work.

I NEVER do this in the game as the AI don't do it and when I play multi-faction it certainly is not fun doing it. But... from a pure mechanic purpose this is what you should do!!!
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 29, 2021, 03:11:50 PM
No... the best units in the game are specialised units and you ALWAYS want to keep your heavier guns in reserve until you eliminated most of the lighter enemy units. (medium vehicles with heavy or medium guns is awesome for their cost to fight enemy vehicles this way). This creates a rather boring micro intensive way to conduct battles. If you assault a world you should basically keep your heavy gunned units in orbit so they don't waste shots and thus LOG units against enemy infantry they will not hit anyway and even if they hit them it is not wort it. Once most of the enemy infantry is taken care of by your CAP and HACP equiped heavy vehicles and infantry you retire most of the CAP vehicles and land the vehicles and heavy artillery with the heavy guns to blast all of the heavy enemy stuff upp.

This is the effect of random targeting. The current mechanic only allow RP on the surface due to how the mechanic work.

I NEVER do this in the game as the AI don't do it and when I play multi-faction it certainly is not fun doing it. But... from a pure mechanic purpose this is what you should do!!!

I remember this from the last thread on the subject.

In my mind, the issue here is essentially that mixed formations will run out of supplies faster, which is not optimal but can be managed by bringing more LOG units along, at least in theory. Combat efficiency is not strongly affected as far as I am aware.

On the flip side, if we change the targeting system to be "perfect", for sake of example we'll say every weapon always targets the largest element it has 100% kill chance or as close as possible against, the system becomes much less RP-friendly as now the balance swings completely towards monolithic formations. If an enemy has, say, 50% CAP and 50% MAV weapons by tonnage, with perfect targeting the optimal approach is to send only one kind of unit which renders one of those two weapon types ineffective, either infantry to render the MAV minimally effective or heavy armor to neutralize the CAP. This is then the same issue as we already have except that the determining factor is combat efficiency, not supply efficiency, which I at least would consider a much worse problem to have.

Given that no system can be perfect, and there have been quite contentious discussions about this in the past I think the present system is at least satisfactory, and certainly I do not want to see ground combat become even more micro-intensive nor do I want to always be designing my formations with an eye towards maintaining some optimal ratio of forces to frustrate enemy targeting.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 29, 2021, 03:34:26 PM
I remember this from the last thread on the subject.

In my mind, the issue here is essentially that mixed formations will run out of supplies faster, which is not optimal but can be managed by bringing more LOG units along, at least in theory. Combat efficiency is not strongly affected as far as I am aware.

On the flip side, if we change the targeting system to be "perfect", for sake of example we'll say every weapon always targets the largest element it has 100% kill chance or as close as possible against, the system becomes much less RP-friendly as now the balance swings completely towards monolithic formations. If an enemy has, say, 50% CAP and 50% MAV weapons by tonnage, with perfect targeting the optimal approach is to send only one kind of unit which renders one of those two weapon types ineffective, either infantry to render the MAV minimally effective or heavy armor to neutralize the CAP. This is then the same issue as we already have except that the determining factor is combat efficiency, not supply efficiency, which I at least would consider a much worse problem to have.

Given that no system can be perfect, and there have been quite contentious discussions about this in the past I think the present system is at least satisfactory, and certainly I do not want to see ground combat become even more micro-intensive nor do I want to always be designing my formations with an eye towards maintaining some optimal ratio of forces to frustrate enemy targeting.

No... it is not just LOG units but this is actually a VERY large saving as heavy wepaons will consume huge amounts of GSP in comparison to CAP or HCAP weapons.

I have actually done testing and the difference can be quite substantial even if you disregard LOG units. Just the fact the the enemy waste all their shots on mostly low value units of yours and you increase the amount of infantry versus tanks and your tanks are less likely to be hit by enemy AT weapon. Once the enemy infantry has been whittled down you add your AT tanks and withdraw the CAP/HCAP tanks and now your heavy weapon have great effect. If the enemy have little or no tanks or heavy vehicles then there is almost no reason to use your heavy weapon units at all.

From a mechanic point of view mixed weapon units is rather bad. You can have mixed formations, that is fine. You can add and remove elements as you see fit during a battle from your formations.

You also can't underestimate the importance of the cost of LOG units... they are neither cheap or small in size... why not bring more small arms fire to kill the enemy infantry faster rather than bring more LOG units. It is a pure math question, that is the problem with random targeting... it becomes mostly relatively easy math.

If the targeting was a bit more unpredictable I think it would add to the the game. This could be attained through some event system. This could be tied with the planets type, terrain or the general colony typed and infrastructure on the colony. This way mixed units and mixed formation could become more important and support RP a bit more.

I think just adding a rule that heavy weapons on units withhold fire if the formation they fire on is too weak could make this much less pronounce and mixed weapon units (and formation) less of a drawback to use. A heavy weapon should only fire under some specific circumstance. This could be both up and down the scale. You could also flag a formation to always fire no matter what as an option. Now it would actually make sense to have a few AT tanks to support your infantry or light mechanised force.

Title: Re: C# Suggestions
Post by: QuakeIV on January 29, 2021, 03:54:32 PM
Could just have an 80% chance that your vehicle will target an ideally suited target to its weapon (or closest match) instead of being completely random or completely predictable.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 29, 2021, 03:58:53 PM
No... it is not just LOG units but this is actually a VERY large saving as heavy wepaons will consume huge amounts of GSP in comparison to CAP or HCAP weapons.

I have actually done testing and the difference can be quite substantial even if you disregard LOG units. Just the fact the the enemy waste all their shots on mostly low value units of yours and you increase the amount of infantry versus tanks and your tanks are less likely to be hit by enemy AT weapon. Once the enemy infantry has been whittled down you add your AT tanks and withdraw the CAP/HCAP tanks and now your heavy weapon have great effect. If the enemy have little or no tanks or heavy vehicles then there is almost no reason to use your heavy weapon units at all.

From a mechanic point of view mixed weapon units is rather bad. You can have mixed formations, that is fine. You can add and remove elements as you see fit during a battle from your formations.

You also can't underestimate the importance of the cost of LOG units... they are neither cheap or small in size... why not bring more small arms fire to kill the enemy infantry faster rather than bring more LOG units. It is a pure math question, that is the problem with random targeting... it becomes mostly relatively easy math.

If the targeting was a bit more unpredictable I think it would add to the the game. This could be attained through some event system. This could be tied with the planets type, terrain or the general colony typed and infrastructure on the colony. This way mixed units and mixed formation could become more important and support RP a bit more.

I think just adding a rule that heavy weapons on units withhold fire if the formation they fire on is too weak could make this much less pronounce and mixed weapon units (and formation) less of a drawback to use. A heavy weapon should only fire under some specific circumstance. This could be both up and down the scale. You could also flag a formation to always fire no matter what as an option.

This is enlightening. If there is a serious difference in combat performance that's a different matter.

I really like the rule suggestion at the end here since that could be applied asymmetrically. In other words, you could prohibit or at least limit how much heavy weapons fire at small targets while not limiting how much CAP and other light weapons fire at heavy targets, which preserves the role of armor as, well, armor - for the infantry. Something like:
Code: [Select]
%Chance to Fire = ( Base_Armour / Base_Penetration ) * ( Base_Hitpoints / Base_Attack )
applied after a target is chosen. Using base, not racial, stats so that a tech-based overmatch doesn't cause units to avoid firing because they would kill the low-tech enemy too hard or something. For example a MAV targeting a basic INF element would only fire 1/16 of the time. This could of course be modified to use an average, square root, etc. to get the desired balance, and random targeting can be retained which avoids the problems of selective targeting and keeps things "unpredictable".

What strikes me as clever about this rule is that it "fixes" the targeting problem without reducing the defensive efficiency of mixed formations very much - the heavy weapons conserve ammo by not firing at infantry (very often), but the infantry still "distracts" the heavy weapons from shooting friendly armored units so that mixed formations remain efficient for blunting enemy firepower.

Could just have an 80% chance that your vehicle will target an ideally suited target to its weapon (or closest match) instead of being completely random or completely predictable.

This doesn't really solve the problem from a mathematical analysis view, even with only a %chance for selective targeting the optimal move is to deploy a single base unit type to blunt the fire of all but one weapon type.
Title: Re: C# Suggestions
Post by: Panpiper on January 29, 2021, 04:07:03 PM
I expect this has been suggested many times. Could we have a feature that allows us to select which of a given field position a unit template will define by default? My infantry units are ALWAYS on Frontal Defence. My tank companies are ALWAYS on Frontal Attack. My medium artillery units are ALWAYS on support. My heavy bombardment is ALWAYS on Rear Echelon, all for instance.

Right now, every time we build anything, let alone anything with a deep hierarchy of units, we have to set each one, pretty much one by one.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 29, 2021, 04:09:14 PM
This is enlightening. If there is a serious difference in combat performance that's a different matter.

I really like the rule suggestion at the end here since that could be applied asymmetrically. In other words, you could prohibit or at least limit how much heavy weapons fire at small targets while not limiting how much CAP and other light weapons fire at heavy targets, which preserves the role of armor as, well, armor - for the infantry. Something like:

%Chance to Fire = ( Base_Armour / Base_Penetration ) * ( Base_Hitpoints / Base_Attack )

applied after a target is chosen. Using base, not racial, stats so that a tech-based overmatch doesn't cause units to avoid firing because they would kill the low-tech enemy too hard or something. For example a MAV targeting a basic INF element would only fire 1/16 of the time. This could of course be modified to use an average, square root, etc. to get the desired balance, and random targeting can be retained which avoids the problems of selective targeting and keeps things "unpredictable".

What strikes me as clever about this rule is that it "fixes" the targeting problem without reducing the defensive efficiency of mixed formations very much - the heavy weapons conserve ammo by not firing at infantry (very often), but the infantry still "distracts" the heavy weapons from shooting friendly armored units so that mixed formations remain efficient for blunting enemy firepower.

Could just have an 80% chance that your vehicle will target an ideally suited target to its weapon (or closest match) instead of being completely random or completely predictable.

Yes... I think it should be based on formation mix. So if you fire on a formation that has 1000t infantry and 100t anti-tank tanks there would be a low chance that the main guns of your tanks fire (I think it could be a random chance they fire or not depending on the enemy composition). But the tanks CAP will certainly fire.

This actually would fix many things... it would make mixed units actually mechanically interesting and important and armoured units can be used in units to soak lighter weapons and the infantry could sort of "protect" the AT weapons from enemy AT assets to some degree.

You could still use random targeting and you would never feel you "waste" energy firing at the enemy. I also think it is somewhat more realistic this way. It would support role-play formation to a much higher degree.

Disregarding race tech might not be too good for the one with lower tech as they might need higher calibre weapon to deal with lighter vehicle on the enemy, in that case it is not wasting GSP. You probably could find a formula that fits. You also could have an override flag on the units as well though to fix those situations.
Title: Re: C# Suggestions
Post by: serger on January 29, 2021, 05:45:10 PM
It seems I have failed to provide understandable explanation of what and why I have proposed. Let me try to reformulate it.

Random targetting leads to the effect we discuss here only in combination with an ability to "change lines" during combat. You see masses of enemy infantry and/or light vehicles - you bring your infantry and AP vehicles. You see "naked" armored machines - you bring your AV weapons.

What I proposed - is to effectively take away this ability to change lines. During subphase fights player will have no ability to change front line forces. Iterative fights during long combat phase will bring a necessity to keep every frontline formation mixed, because if your formation will have only AP weapons - it will win first subphases and fail against armored core of enemy formation in the end, and if your formation will have only AV weapons - it'll fail at the beginning. Bring random division of local battle groups - and you'll have much more dispersion of probable results, so lesser temptation of micro-calculating even if you have full knowledge of enemy forces (though this calculation will be available for those, who can do such things, but it will give them lesser advantage per hour of math work, and they'll have no obvious, easy, boring solution from the first glance, that we are obliged to close our eyes at, if we have to play with more interesting formations). This semi-random division of locations and iterations of fights will also bring deeper, however nearly hidden battle stories at the background - we'll know why we must send mixed forces, we'll have no need to close our eyes an envision things that will contradict with game screen. It will be just more RP-ish battle mechanics per se.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 29, 2021, 07:04:37 PM
It seems I have failed to provide understandable explanation of what and why I have proposed. Let me try to reformulate it.

Random targetting leads to the effect we discuss here only in combination with an ability to "change lines" during combat. You see masses of enemy infantry and/or light vehicles - you bring your infantry and AP vehicles. You see "naked" armored machines - you bring your AV weapons.

What I proposed - is to effectively take away this ability to change lines. During subphase fights player will have no ability to change front line forces. Iterative fights during long combat phase will bring a necessity to keep every frontline formation mixed, because if your formation will have only AP weapons - it will win first subphases and fail against armored core of enemy formation in the end, and if your formation will have only AV weapons - it'll fail at the beginning. Bring random division of local battle groups - and you'll have much more dispersion of probable results, so lesser temptation of micro-calculating even if you have full knowledge of enemy forces (though this calculation will be available for those, who can do such things, but it will give them lesser advantage per hour of math work, and they'll have no obvious, easy, boring solution from the first glance, that we are obliged to close our eyes at, if we have to play with more interesting formations). This semi-random division of locations and iterations of fights will also bring deeper, however nearly hidden battle stories at the background - we'll know why we must send mixed forces, we'll have no need to close our eyes an envision things that will contradict with game screen. It will be just more RP-ish battle mechanics per se.

This sounds complex and difficult to implement. How is a "subphase" defined? Why can't a player (or AI, maybe someday...) move their forces around at will? Logically this makes little sense as a round of ground combat is 8 hours which is plenty of time for a battlefield commander to order a retreat or the reserves forward. It seems like this is arbitrarily taking away the ability for a player to control their forces except at specific intervals, and I'm not a big fan of taking options away from the player to force a desired outcome.

Additionally, it seems like this random division actually forces mixed-element formations, at the exclusion of a capability to deploy a mix of like-element formations. That is, if I would like to build brigades with 2x INF battalions and 1x ARM battalions, this random division means I risk having INF in one "subphase" and my ARM in a separate one - meaning that if I want to ensure a combined arms battle I must build mixed-element formations instead of separate tank, infantry, etc. battalions intended to work together.

Finally this seems like it either requires a new interface for ground combat (i.e. more complications) or else makes the results even more opaque to the player. As complex of a game as Aurora is, it benefits significantly from simplicity of the individual moving parts. This does not mesh well with that design philosophy.

I strongly prefer Jorgen's suggestion about a rule which prevents or limits heavy weapons from firing at small targets. This is a simple change that solves most of the existing mechanical issues while preserving player agency and RP ability. No need to overcomplicate things when a simple tweak will solve it.
Title: Re: C# Suggestions
Post by: papent on January 29, 2021, 08:09:05 PM
it would be easier for all to follow suggestions/discussion of ground combat if it was forked to another thread.
Title: Re: C# Suggestions
Post by: serger on January 30, 2021, 01:16:30 AM
I strongly prefer Jorgen's suggestion about a rule which prevents or limits heavy weapons from firing at small targets. This is a simple change that solves most of the existing mechanical issues while preserving player agency and RP ability. No need to overcomplicate things when a simple tweak will solve it.
Personally I prefer this too. But Steve obviously doesn't go this way (I don't know why, there must be some reasons), so I proposed to go the way Steve already moved, but to move farther.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 30, 2021, 03:08:21 AM
I strongly prefer Jorgen's suggestion about a rule which prevents or limits heavy weapons from firing at small targets. This is a simple change that solves most of the existing mechanical issues while preserving player agency and RP ability. No need to overcomplicate things when a simple tweak will solve it.
Personally I prefer this too. But Steve obviously doesn't go this way (I don't know why, there must be some reasons), so I proposed to go the way Steve already moved, but to move farther.

I think we should have patience with Steve. The entire ground forces system is completely new in C#, and Steve has spent some time making improvements but he has limited time, and this kind of change would require a lot of testing to figure out the right formula for the rule. Usually if Steve has not done something, the reason is either "he doesn't want to" (and often he will say so) or "he hasn't had time yet", and as we have no evidence of the former we should prefer the latter.  :)
Title: Re: C# Suggestions
Post by: kingflute on January 30, 2021, 04:47:33 AM
Instead of mounting weapon systems to fighters and small craft during design, allow us to add 'hardpoints' which can mount weapons and other systems, such as ECM or refuelling, etc...
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 30, 2021, 07:06:34 AM
Instead of mounting weapon systems to fighters and small craft during design, allow us to add 'hardpoints' which can mount weapons and other systems, such as ECM or refuelling, etc...

If this were implemented in some form it could not be for small crafts only but for all ships. Fighters in Aurora are not the difference between a jet fighter and a naval ship, they are all the same. Steve have been quite thorough during the development of C# to not build exceptions to different rules bit consistent general rules and mechanics.

Not saying it is a bad idea... I would like for ships to have possibility for more modular components as that is realistic.

I also would like to have a system of a bit more restriction when building ships to as to some degree we have a bit too much freedom sometimes which sometimes actually limit our actual choices as there are too many bad ones. I would like some hull integrity value to be applied and different components will require different hull integrity or that components will require more or less space consideration in regards to internal or external positioning. Some components would compete more for the same space others will not etc... this way a "figter" would have more external space than internal than for example a 10kt Destroyer would, for the same reason how armour work... Armour would take both its space from external and from internal, but in actuality that usually mean less space available from external components in relation to its size.

Anyway... more modular components would be nice. Values for hull integrity and weight to satisfy it (based on technology) and a difference of internal and external space for components would make ship design even more interesting in my opinion. More complex... yes... but I think we could handle it.
Title: Re: C# Suggestions
Post by: liveware on January 30, 2021, 09:33:47 AM
Instead of mounting weapon systems to fighters and small craft during design, allow us to add 'hardpoints' which can mount weapons and other systems, such as ECM or refuelling, etc...

If this were implemented in some form it could not be for small crafts only but for all ships. Fighters in Aurora are not the difference between a jet fighter and a naval ship, they are all the same. Steve have been quite thorough during the development of C# to not build exceptions to different rules bit consistent general rules and mechanics.

Not saying it is a bad idea... I would like for ships to have possibility for more modular components as that is realistic.

I also would like to have a system of a bit more restriction when building ships to as to some degree we have a bit too much freedom sometimes which sometimes actually limit our actual choices as there are too many bad ones. I would like some hull integrity value to be applied and different components will require different hull integrity or that components will require more or less space consideration in regards to internal or external positioning. Some components would compete more for the same space others will not etc... this way a "figter" would have more external space than internal than for example a 10kt Destroyer would, for the same reason how armour work... Armour would take both its space from external and from internal, but in actuality that usually mean less space available from external components in relation to its size.

Anyway... more modular components would be nice. Values for hull integrity and weight to satisfy it (based on technology) and a difference of internal and external space for components would make ship design even more interesting in my opinion. More complex... yes... but I think we could handle it.

A simple 'figure of merit' that would vary with ship size would be a surface/volume ratio. If one assumes ships to be spherical (or even ellipsoidal), that ration would be easy to calculate for a given tonnage and would vary pretty smoothly with ship size.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 30, 2021, 09:35:36 AM
Was thinking a bit more about distribution of separate external and internal hull space. With extarnal I don't mean things just mounted on the outside of the ship as they are measured in volume and not weight.

The external hull would be like the egg shell, like armour would be part of the external hull of a ship.

Now.. this would put a bit more realistic restriction on ship design. There would be a difference on how much hull space different sized hull has... there might also be different configuration of ships available that could distribute the hull differently but receive some positive or negative effect, such as slightly better or lower speed, more or less hull integrity etc..

Anyway... we could finally get a meaningfull differenc beteen say box launched or full size missile launchers. A full size missile launcher would likely be something like 15% external and 85% internal hull while a box launcher are 97% external hull and 3% internal hull space. This would severely limit the amount of box launcher you can mount on certain ships in a realistic way. You could have a sleek hull form that give additional speed and external hull-space perfect for a missile fighter that already have allot of external versus internal hull-space to begin with.

It would usually be so that the larger the ship the more internal hull-space you get... this means you can't build a huge ship only blistering in guns as allot of the hull-space for guns are external, you need to find a good use for the internal hull-space. You could make a sleeker larger ship to with more external hull-space, but with lower hull integrity and more susceptible to chock perhaps and so on. Spinal weapons would of course also have mostly internal hull space in relation to other weapons. Turreted weapons also would require more external space than standard weapons etc..

Anyway... I think such a model could be worked into the game without huge issues and still keep it free in ship design, I thin ship design would actually find more actually useful hulls.

Also... a ships could not change form as it upgrades, you are stuck with a ships hull form throughout its lifetime.

Different components could also have different configuration and abilities depending on if you want it to require more or less external or internal hull-space. For engines then the larger the engine is the more it proportionally fit into internal versus external hull. This means large ships really wants large engines while really small ships can have trouble fitting too big engines without compromising external hull-space... perhaps not an issue for a survey ships, but certainly for a military ship.

When components are hit then external hull components should have a much higher chance to get hit first... this would make armoured turrets more interesting to have for example.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 30, 2021, 09:37:21 AM
A simple 'figure of merit' that would vary with ship size would be a surface/volume ratio. If one assumes ships to be spherical (or even ellipsoidal), that ration would be easy to calculate for a given tonnage and would vary pretty smoothly with ship size.

A actually assume all ships tonnage is volume, so there is no surface mounted stuff per see, it all is included in the external part in this instance. Everything is usually beneath the armour anyway But it should be based on the surface area to some extent... I agree... and then somehow in relation to the size of the ship as well. I think it would make sense that the larger the hull then even more internal most hull-space become, even if the area is less on larger ships.
Title: Re: C# Suggestions
Post by: Borealis4x on January 30, 2021, 11:42:40 AM
I think Power Plants should either be expanded in their use or just be taken out and added on to the HS of beam weapons.

I get that they are there to make beam weapons a little less HS efficient when compared to missiles that need (usually multiple) launchers, a big magazine + a FC and AS, but I don't think they justify being their own customizable part ATM.

If they also powered shields or if having a surplus of power somehow increase the performance of beam weapons then that would justify their inclusion.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 30, 2021, 11:50:25 AM
I think Power Plants should either be expanded in their use or just be taken out and added on to the HS of beam weapons.

I get that they are there to make beam weapons a little less HS efficient when compared to missiles that need (usually multiple) launchers, a big magazine + a FC and AS, but I don't think they justify being their own customizable part ATM.

If they also powered shields or if having a surplus of power somehow increase the performance of beam weapons then that would justify their inclusion.

I support this. Just make reactors another integral component of a beam weapon and leave it at that, as they are easily the most boring component presenting very little in the way of interesting decisions. Presently the only real reason they exist separately is so that building bigger reactors can be more tonnage-efficient, which I would be fine living without and just tacking a few more HS onto my lasers.
Title: Re: C# Suggestions
Post by: Erik L on January 30, 2021, 12:08:38 PM
I think Power Plants should either be expanded in their use or just be taken out and added on to the HS of beam weapons.

I get that they are there to make beam weapons a little less HS efficient when compared to missiles that need (usually multiple) launchers, a big magazine + a FC and AS, but I don't think they justify being their own customizable part ATM.

If they also powered shields or if having a surplus of power somehow increase the performance of beam weapons then that would justify their inclusion.

I support this. Just make reactors another integral component of a beam weapon and leave it at that, as they are easily the most boring component presenting very little in the way of interesting decisions. Presently the only real reason they exist separately is so that building bigger reactors can be more tonnage-efficient, which I would be fine living without and just tacking a few more HS onto my lasers.

What about when your ship (or the bad guy) takes internals and the power plant goes? Unless he has gauss or missiles, he's mission killed.
Title: Re: C# Suggestions
Post by: serger on January 30, 2021, 01:41:29 PM
Decline arbitrary tonnage margins between fighters, FACs (w/o bridge) and ships (with bridge), with these changes to ship mechanics:

1. Bridge component reveals an ability to add other command components and makes Crew Quarters 3 times more effective (that are 3 watches, and without command components you cannot relieve watch for commanding personnel, because your Crew Quarters are the only action stations available for them).
2. Add a property "max spacecraft size able to take off" for any planet, dependent on it's mass or gravity. Colony and spacecraft design windows to show these properties accordingly.
3. Fighter Factories becoming Shipbuilding Factories, able to produce space components and build unarmored (yet-to-be-assembled by shuttles) stations and any spacecraft, that can take off this planet.
4. Construction Factories becoming unable to produce spacecraft components and unarmored stations, they are to build surface objects only.
Title: Re: C# Suggestions
Post by: Black on January 30, 2021, 02:02:05 PM
Would it be possible to get checkbox for ground units to not show on the list of units when loading ground troops to transports? I have garrison troops on my planet that I have no intention to move and I have to scroll through them to find my assault units.
Title: Re: C# Suggestions
Post by: Droll on January 30, 2021, 02:09:32 PM
Would it be possible to get checkbox for ground units to not show on the list of units when loading ground troops to transports? I have garrison troops on my planet that I have no intention to move and I have to scroll through them to find my assault units.

Better yet - when you select the SUB checkbox it removes all formations that have no subordinates of their own from the list
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 30, 2021, 02:13:43 PM
I think Power Plants should either be expanded in their use or just be taken out and added on to the HS of beam weapons.

I get that they are there to make beam weapons a little less HS efficient when compared to missiles that need (usually multiple) launchers, a big magazine + a FC and AS, but I don't think they justify being their own customizable part ATM.

If they also powered shields or if having a surplus of power somehow increase the performance of beam weapons then that would justify their inclusion.

I support this. Just make reactors another integral component of a beam weapon and leave it at that, as they are easily the most boring component presenting very little in the way of interesting decisions. Presently the only real reason they exist separately is so that building bigger reactors can be more tonnage-efficient, which I would be fine living without and just tacking a few more HS onto my lasers.

What about when your ship (or the bad guy) takes internals and the power plant goes? Unless he has gauss or missiles, he's mission killed.

If the only purpose of a component is to introduce a weakness, I question the inclusion of that component in the game.

Reactors to me already struggle to make sense since the rest of the ship components are generally considered to be "powered" by the ship's engines. Beam weapons are the only component that apparently needs a separate power source, and that power source is arguably the most boring component in the game when combining the design and "what does it do" elements (as plasma carronades at least shoot at things which is fun).

I'd also be happy with an alternative rework that made all ship systems require reactor power, but I doubt that ever happens.

Decline arbitrary tonnage margins between fighters, FACs (w/o bridge) and ships (with bridge), with these changes to ship mechanics:

1. Bridge component reveals an ability to add other command components and makes Crew Quarters 3 times more effective (that are 3 watches, and without command components you cannot relieve watch for commanding personnel, because your Crew Quarters are the only action stations available for them).
2. Add a property "max spacecraft size able to take off" for any planet, dependent on it's mass or gravity. Colony and spacecraft design windows to show these properties accordingly.
3. Fighter Factories becoming Shipbuilding Factories, able to produce space components and build unarmored (yet-to-be-assembled by shuttles) stations and any spacecraft, that can take off this planet.
4. Construction Factories becoming unable to produce spacecraft components and unarmored stations, they are to build surface objects only.

I agree the limits are a bit arbitrary but I dislike these proposals to address them.

(1) if I understand it correctly would not have the desired effect as it represents a nerf to FACs and fighters. I would suggest as an alternative that the definition of a FAC (not fighter) be defined in terms of a maximum crew count which can be commanded without a bridge module, probably with a tech to increase this limit over time as components become more complex. This would be simpler and since the FAC definition does not interact with other game mechanics it is okay to change this.

(2) would add needless complication as now I cannot just design my fighter craft to a given standard, I have to arbitrarily limit tonnage based on which planet(s) I want to build them on. This reduces player flexibility, and also doesn't play neatly with the fact that the game needs a consistent definition of a "fighter" e.g to correctly apply the commander skill for Fighter Combat. As arbitrary as it may seem, having a round tonnage mark for "fighter" definition is good for gameplay and an acceptable abstraction.

(3) and (4) again place restrictions on the player where currently there exists an interesting choice, mainly (4) as currently the choice of what to use construction capacity on is a relevant one in many cases. Why remove decision making from the player? (3) by itself is probably okay as I wouldn't mind making fighter factories more interesting.
Title: Re: C# Suggestions
Post by: Droll on January 30, 2021, 02:22:46 PM
I think Power Plants should either be expanded in their use or just be taken out and added on to the HS of beam weapons.

I get that they are there to make beam weapons a little less HS efficient when compared to missiles that need (usually multiple) launchers, a big magazine + a FC and AS, but I don't think they justify being their own customizable part ATM.

If they also powered shields or if having a surplus of power somehow increase the performance of beam weapons then that would justify their inclusion.

I support this. Just make reactors another integral component of a beam weapon and leave it at that, as they are easily the most boring component presenting very little in the way of interesting decisions. Presently the only real reason they exist separately is so that building bigger reactors can be more tonnage-efficient, which I would be fine living without and just tacking a few more HS onto my lasers.

What about when your ship (or the bad guy) takes internals and the power plant goes? Unless he has gauss or missiles, he's mission killed.

If the only purpose of a component is to introduce a weakness, I question the inclusion of that component in the game.

Reactors to me already struggle to make sense since the rest of the ship components are generally considered to be "powered" by the ship's engines. Beam weapons are the only component that apparently needs a separate power source, and that power source is arguably the most boring component in the game when combining the design and "what does it do" elements (as plasma carronades at least shoot at things which is fun).

I'd also be happy with an alternative rework that made all ship systems require reactor power, but I doubt that ever happens.

Decline arbitrary tonnage margins between fighters, FACs (w/o bridge) and ships (with bridge), with these changes to ship mechanics:

1. Bridge component reveals an ability to add other command components and makes Crew Quarters 3 times more effective (that are 3 watches, and without command components you cannot relieve watch for commanding personnel, because your Crew Quarters are the only action stations available for them).
2. Add a property "max spacecraft size able to take off" for any planet, dependent on it's mass or gravity. Colony and spacecraft design windows to show these properties accordingly.
3. Fighter Factories becoming Shipbuilding Factories, able to produce space components and build unarmored (yet-to-be-assembled by shuttles) stations and any spacecraft, that can take off this planet.
4. Construction Factories becoming unable to produce spacecraft components and unarmored stations, they are to build surface objects only.

I agree the limits are a bit arbitrary but I dislike these proposals to address them.

(1) if I understand it correctly would not have the desired effect as it represents a nerf to FACs and fighters. I would suggest as an alternative that the definition of a FAC (not fighter) be defined in terms of a maximum crew count which can be commanded without a bridge module, probably with a tech to increase this limit over time as components become more complex. This would be simpler and since the FAC definition does not interact with other game mechanics it is okay to change this.

(2) would add needless complication as now I cannot just design my fighter craft to a given standard, I have to arbitrarily limit tonnage based on which planet(s) I want to build them on. This reduces player flexibility, and also doesn't play neatly with the fact that the game needs a consistent definition of a "fighter" e.g to correctly apply the commander skill for Fighter Combat. As arbitrary as it may seem, having a round tonnage mark for "fighter" definition is good for gameplay and an acceptable abstraction.

(3) and (4) again place restrictions on the player where currently there exists an interesting choice, mainly (4) as currently the choice of what to use construction capacity on is a relevant one in many cases. Why remove decision making from the player? (3) by itself is probably okay as I wouldn't mind making fighter factories more interesting.

I agree that power plants as they are currently aren't very interesting. Making them have uses outside of beam weapons and just power the whole ship in general makes more sense to me.
It allows you to do more things with power plants - they might be made to have their own fuel requirements with boosting decreasing fuel efficiency much like engines
Every ship could also be made to have batteries so that if the generator goes, the ship has some life support left before everything shuts off, now you might want to avoid firing some weapons to ration power.
Each beam weapon benefits from power surplus, some may hit harder, others may shoot more shots and some may be able to fire further by drawing extra power, shields that have extra power may be able to recharge faster than normal.
Hell you could configure a design to "overclock" its life support, using more power but making crew quarters more efficient with an increased chance for maintenance failures for them.

Having power act as a ship-wide resource instead of a beam weapon "reload rate" opens the grounds for a lot of interesting tactical decisions IMO.
Title: Re: C# Suggestions
Post by: QuakeIV on January 30, 2021, 03:37:38 PM
I rather like the idea of having a tonnage limit for fighters/land based ship construction based on the planet somehow.

Among other things you would desire to colonize a low gravity body to facilitate easier shipbuilding, which does make a degree of sense.  It would reduce the energy requirements for moving stuff off of the surface.

I can't think of a good set of rules for that personally though.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 30, 2021, 03:48:19 PM
I agree that power plants as they are currently aren't very interesting. Making them have uses outside of beam weapons and just power the whole ship in general makes more sense to me.
It allows you to do more things with power plants - they might be made to have their own fuel requirements with boosting decreasing fuel efficiency much like engines
Every ship could also be made to have batteries so that if the generator goes, the ship has some life support left before everything shuts off, now you might want to avoid firing some weapons to ration power.
Each beam weapon benefits from power surplus, some may hit harder, others may shoot more shots and some may be able to fire further by drawing extra power, shields that have extra power may be able to recharge faster than normal.
Hell you could configure a design to "overclock" its life support, using more power but making crew quarters more efficient with an increased chance for maintenance failures for them.

Having power act as a ship-wide resource instead of a beam weapon "reload rate" opens the grounds for a lot of interesting tactical decisions IMO.

We already had this discussion before... a couple of times... Steves answer have so far been that he don't want an energy mechanic for ships as that will shift focus from the game strategic and tactical operations of fleets or squadrons of ships to individual ships too much.

I don't think he is against the idea itself, just that it is one step too far in the detail and management of the ships in general.
Title: Re: C# Suggestions
Post by: serger on January 30, 2021, 05:09:51 PM
(1) if I understand it correctly would not have the desired effect as it represents a nerf to FACs and fighters.

Rather minor nerf and very natural.
I'd like to see much more lowering of small craft deployment times, though it might be in combination with some racial or game property, that can switch deployment time off, to play with robotic or other strange race, that needs no life intercourse nor much life support.

I would suggest as an alternative that the definition of a FAC (not fighter) be defined in terms of a maximum crew count which can be commanded without a bridge module

That will be just another arbitrary interracial margin we'll have to shut our eyes wide.

(2) would add needless complication as now I cannot just design my fighter craft to a given standard, I have to arbitrarily limit tonnage based on which planet(s) I want to build them on.

I'll say with fighters you must have nearly no limit for habitable planets, because with this mechanics Steve will have an ability to implement even small tenders (several kt), that will have no need to use shuttles.
Though it will add some complication with logistics, yes. Personally I'd prefer to have an ability to land any ship and use more local (planetary or on-board) loading facilities abstraction (not shuttles), but that's what Steve have made, we need to deal with it.

and also doesn't play neatly with the fact that the game needs a consistent definition of a "fighter" e.g to correctly apply the commander skill for Fighter Combat. As arbitrary as it may seem, having a round tonnage mark for "fighter" definition is good for gameplay and an acceptable abstraction.

I'd say that "fighter" tag can be defined as direct fire* armed mobile (not orbital) craft with no more than 2 crewmen (that's pilot and operator). Give them an ability to lead fighter squadrons (providing them with bonus) - and it will be great.
All heavier crafts will be FACs quite naturally, their tactics and operational requirements have no fundamental difference from corvettes or even frigates.

(*) now it's named often as "beam"despite gauss and railguns are kinetic weapon, not beam

(3) and (4) again place restrictions on the player

Nope. What I proposed to take away from Construction Factories - will be added to Shipbuilding (former Fighter) Factories.
That's not a restriction, that's replacing. Why? Because Fighter Factories are now too much restricted, too specialised (and some players even have no desire to make fighters at all), while Construction Factories are overburden with diverse tasks.
With Construction Factories and Shipbuilding Factories it might be much more balanced.
Title: Re: C# Suggestions
Post by: QuakeIV on January 30, 2021, 05:20:28 PM
I'm definitely starting to like the idea of shipbuilding factories in general, particularly if they supported shipyard operations and were also the way to pre-build ship components, I always thought construction factories were way too multifaceted.
Title: Re: C# Suggestions
Post by: captainwolfer on January 31, 2021, 10:43:50 AM
Suggestion:
1. Make missiles with sensors that are not controlled by a missile fire control pick targets using a weighted selection process like how the "Fire at Will" command for missile fire controls will work in 1.13, except make it so it uses the sensors the missile has, IE if missile has thermal sensors, the weighting is thermal signature/distance, if it has EM sensors then it uses EM signature/distance, etc.
2. Make it so that if a missile is fired at a target and the target is destroyed, the missile will continue heading on its current path, instead of just stopping in space

This way, missiles with sensors won't all hit the same ship in an enemy fleet, and it will actually be possible to use them when chasing an enemy fleet, instead of the sensors only being useful when running from an enemy fleet.
Title: Re: C# Suggestions
Post by: Barkhorn on January 31, 2021, 11:06:03 AM
Suggestion:
1. Make missiles with sensors that are not controlled by a missile fire control pick targets using a weighted selection process like how the "Fire at Will" command for missile fire controls will work in 1.13, except make it so it uses the sensors the missile has, IE if missile has thermal sensors, the weighting is thermal signature/distance, if it has EM sensors then it uses EM signature/distance, etc.
2. Make it so that if a missile is fired at a target and the target is destroyed, the missile will continue heading on its current path, instead of just stopping in space

This way, missiles with sensors won't all hit the same ship in an enemy fleet, and it will actually be possible to use them when chasing an enemy fleet, instead of the sensors only being useful when running from an enemy fleet.
This is how they worked back in VB6 and I believe how they're supposed to work now, they're just bugged.
Title: Re: C# Suggestions
Post by: dlathro1 on January 31, 2021, 08:25:11 PM
Would it be possible to have the Assign New Labs option work with research queues?

It is somewhat annoying to reenable Assign New Labs every time research is completed.
Title: Re: C# Suggestions
Post by: TMaekler on January 31, 2021, 11:42:01 PM
This is how they worked back in VB6 and I believe how they're supposed to work now, they're just bugged.

Missiles are bugged?!?
Title: Re: C# Suggestions
Post by: QuakeIV on February 01, 2021, 12:26:48 AM
My general understanding is its more like they are incomplete.
Title: Re: C# Suggestions
Post by: serger on February 01, 2021, 10:30:22 AM
Have an idea about heavy weapon supply problem.
Suggestion is to make any weapon to do supply roll against it's target armour*HP, not against weapon's own GSP (that will be max GSP instead of constant GSP).

That's not ideal, not as if it will be some sort of anti-personnel shells, that will be able to kill several units of the same element, proportionally to shell power, and targetted specifically at largest units and elements, but this first rule might be much simpler to code.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 01, 2021, 11:21:12 AM
Have an idea about heavy weapon supply problem.
Suggestion is to make any weapon to do supply roll against it's target armour*HP, not against weapon's own GSP (that will be max GSP instead of constant GSP).

That's not ideal, not as if it will be some sort of anti-personnel shells, that will be able to kill several units of the same element, proportionally to shell power, and targetted specifically at largest units and elements, but this first rule might be much simpler to code.

This...isn't the worst idea actually. It could probably work though I do think it is a bit opaque, and it makes sense as e.g. a tank planning to attack infantry instead of enemy armor would load a cheaper HE shell instead of an expensive AP/APCR/HEAT/etc.

That said, I do want to point out that it does require a bit more implementation than just adding the rule, specifically the way supply is currently handled (and you can see this in the DB) is that every unit has enough supply for 10 rounds of combat; internally this 10-round mark is what is tracked, not the actual total GSP of the element. Thus probably a simpler implementation is to have a %chance of consuming a round of supplies for "sub-caliber" targets, which is similar to how resupply is implemented already.

Compared to Jorgen's rule proposal this means heavy weapons will be guaranteed to always shoot but the cost of shooting small targets will be reduced. Net effect, supply consumption with this change is probably somewhat higher overall but weapon kill rates are also a little higher. Notably I've realized this avoids problems with e.g. heavy artillery not firing which would crop up with the other approach.
Title: Re: C# Suggestions
Post by: Sunmannus on February 01, 2021, 12:45:10 PM
I'm sure it's been suggested before, but to bring it back to your attention:

I would like some kind of visual indicator regarding the fuel needed to fulfill the orders assigned to a fleet.  A simple indication in the naval organization> fleet tab (maybe next to the all orders distance and travel time required) that indicates in red if the fleet lacks enough fuel to finish all current orders or yellow if it passes the point of no return.
This would definitely help us better plan routes and avoid stranded fleets out of fuel in the middle of nowhere. 
Title: Re: C# Suggestions
Post by: Barkhorn on February 03, 2021, 12:48:22 AM
I'm sure it's been suggested before, but to bring it back to your attention:

I would like some kind of visual indicator regarding the fuel needed to fulfill the orders assigned to a fleet.  A simple indication in the naval organization> fleet tab (maybe next to the all orders distance and travel time required) that indicates in red if the fleet lacks enough fuel to finish all current orders or yellow if it passes the point of no return.
This would definitely help us better plan routes and avoid stranded fleets out of fuel in the middle of nowhere. 

This could only be an estimate as the distance is never precisely known, because destinations can move.
Title: Re: C# Suggestions
Post by: Barkhorn on February 03, 2021, 12:54:51 AM
Suggestion: Some kind of combat engineer training similar to the environment training you can give ground units.

My idea is to have combat engineer infantry reduce enemy fortification levels similar to the way construction units increase them.  Combat engineer units would have terrible or maybe even no attack; satchel charges are a lot less effective than laser guns against people or tanks.  They would also reduce fortification significantly faster than construction vehicles build it; it's much faster to blow up a bunker than build one.  Last, I would have combat engineer training severely reduce a unit's dodge ability, both to balance it and to represent the fact that they have to get much closer to their targets and possible sit exposed affixing demolitions charges to them.
Title: Re: C# Suggestions
Post by: Kiero on February 03, 2021, 01:50:47 AM
1) Ability to tug wrecks!
2) An installation that can change mineral accessibility.   
3) Ability to turn prisoners of war into a population of an alien race. 
Title: Re: C# Suggestions
Post by: Borealis4x on February 03, 2021, 12:54:25 PM
First Suggestion:

The ability to mothball ships and demobilize ground units.

Mothballed ships would take up 1/100th of its usual maintenance capacity, require no crew or officers, and be drained of all its fuel, munitions, and MSP. It will, however, run down its maintence clock at 1/10th the speed of normal regardless of maintence facilities present.

Demobilized ground units will maintain only a fraction of their strength and cut down on the financial burden of keeping them dramatically. They also do not need officers. Once mobilized however, they require some time to get back up to fighting strength.
Title: Re: C# Suggestions
Post by: Erik L on February 03, 2021, 01:13:48 PM
First Suggestion:

The ability to mothball ships and demobilize ground units.

Mothballed ships would take up 1/100th of its usual maintenance capacity, require no crew or officers, and be drained of all its fuel, munitions, and MSP. It will, however, run down its maintence clock at 1/10th the speed of normal regardless of maintence facilities present.

Demobilized ground units will maintain only a fraction of their strength and cut down on the financial burden of keeping them dramatically. They also do not need officers. Once mobilized however, they require some time to get back up to fighting strength.
Mothballed ships were a thing in VB Aurora, but were removed. Searching the VB threads would tell you why. I don't recall and I'm not sure which version it was removed in.
Title: Re: C# Suggestions
Post by: ZimRathbone on February 03, 2021, 03:18:48 PM
First Suggestion:

The ability to mothball ships and demobilize ground units.

Mothballed ships would take up 1/100th of its usual maintenance capacity, require no crew or officers, and be drained of all its fuel, munitions, and MSP. It will, however, run down its maintence clock at 1/10th the speed of normal regardless of maintence facilities present.

Demobilized ground units will maintain only a fraction of their strength and cut down on the financial burden of keeping them dramatically. They also do not need officers. Once mobilized however, they require some time to get back up to fighting strength.
Mothballed ships were a thing in VB Aurora, but were removed. Searching the VB threads would tell you why. I don't recall and I'm not sure which version it was removed in.

I don't think it ever existed in Aurora - IIRC it was one of the design decisions at the outset.  It DID exist in Starfire Assistant tho, and was perceived to cause some difficulties there as players could build ships straight into mothballs,  building up huge reserves that could be reactivated very quickly (at about 45% of the cost of a new build), which meant that it was economically beneficial if the unit was not paying maintenance for 5+ turns.  There was a bit of a risk in that the unit might be behind the current tech level but I think you could refit while in mothballs which would mitigate that.
Title: Re: C# Suggestions
Post by: QuakeIV on February 03, 2021, 09:52:37 PM
I actually originally thought mothballs were going to be a thing in C#, having followed that conversation.  I have absolutely no idea why the idea died, presumably I missed something.

First Suggestion:

The ability to mothball ships and demobilize ground units.

Mothballed ships would take up 1/100th of its usual maintenance capacity, require no crew or officers, and be drained of all its fuel, munitions, and MSP. It will, however, run down its maintence clock at 1/10th the speed of normal regardless of maintence facilities present.

Demobilized ground units will maintain only a fraction of their strength and cut down on the financial burden of keeping them dramatically. They also do not need officers. Once mobilized however, they require some time to get back up to fighting strength.
Mothballed ships were a thing in VB Aurora, but were removed. Searching the VB threads would tell you why. I don't recall and I'm not sure which version it was removed in.

I don't think it ever existed in Aurora - IIRC it was one of the design decisions at the outset.  It DID exist in Starfire Assistant tho, and was perceived to cause some difficulties there as players could build ships straight into mothballs,  building up huge reserves that could be reactivated very quickly (at about 45% of the cost of a new build), which meant that it was economically beneficial if the unit was not paying maintenance for 5+ turns.  There was a bit of a risk in that the unit might be behind the current tech level but I think you could refit while in mothballs which would mitigate that.

I'm not sure that any of those things are a bad thing per se.  As posed they still would have had a cost.
Title: Re: C# Suggestions
Post by: Kishmond on February 03, 2021, 09:56:04 PM
I think we need an installation that can increase or decrease surface temperature i.e. orbital mirrors.

I'm trying to make one of Minerva's moons a bit more habitable but I can only raise its temperature by 30 degrees with 5 atm of aestusium.
Title: Re: C# Suggestions
Post by: Stormtrooper on February 04, 2021, 03:14:47 AM
I think we need an installation that can increase or decrease surface temperature i.e. orbital mirrors.

I'm trying to make one of Minerva's moons a bit more habitable but I can only raise its temperature by 30 degrees with 5 atm of aestusium.

Oh yeah, terraforming Nibiru... from -253 to -210 degrees, just gread. To add to this I'd love a bit more depth into terraforming, for example having to care about building magnetic field.
Title: Re: C# Suggestions
Post by: serger on February 04, 2021, 03:47:14 AM
I'd like to see surface construction like Atmosphere Heater Reactor, that will increase atmosphere temperature by some fixed value * reactor tech bonus / ( surface square * atmosphere density ). It might give an interesting option to terraform outermost small planets, that cannot gain enough light to heat up through the greenhouse effect.
These structures might give also very significant thermal signatures.
Title: Re: C# Suggestions
Post by: Gabrote42 on February 04, 2021, 08:41:19 AM
An option for "Interrupt Mitigation". This would work so that if it's checked, similar to auto-turns, the game wouldn't stop until the desired increment happened. This would work by saving the desired increment length and adding up the time that had passed each subpulse and if an NPR interrupt happened, the game would immediately click an increment button and continue to do so until the desired time had passed. The idea is to circumvent the fact that NPRs need new increments to think.
Example: Player clicks 5 days. An NPR gets detected by another NPR at 2 days 6 hours. Since "Interrupt Mitigation" is checked, the game will click 1 day. The NPR ship gets undetected at 2 days 12 hours. Step 3) repeats twice. Now that the time is at 4 days 12 hours, and that's less than 24 hours, the game clicks (whatever is most efficient, probably 8 hours). And so becoming smaller and smaller until the elapsed time is 5 days, where the game stops.
This might require tagging events to see which ones interrupt this sequence, or just use whatever controls if the event is visible.
Feedback appreciated! Will read tomorrow.
Title: Re: C# Suggestions
Post by: Kylemmie on February 04, 2021, 10:40:19 AM
I think we need an installation that can increase or decrease surface temperature i.e. orbital mirrors.

I'm trying to make one of Minerva's moons a bit more habitable but I can only raise its temperature by 30 degrees with 5 atm of aestusium.

I believe the max atmo is 3 for gaining any effect of Greenhouse or Anti-G gasses. Just fyi, you can move the Terraformers on to the next project at that point.
Title: Re: C# Suggestions
Post by: Droll on February 04, 2021, 11:27:25 AM
I think we need an installation that can increase or decrease surface temperature i.e. orbital mirrors.

I'm trying to make one of Minerva's moons a bit more habitable but I can only raise its temperature by 30 degrees with 5 atm of aestusium.

I believe the max atmo is 3 for gaining any effect of Greenhouse or Anti-G gasses. Just fyi, you can move the Terraformers on to the next project at that point.

Its not max atmo but the greenhouse factor being 3 that stops atmosphere from affecting temperature
Title: Re: C# Suggestions
Post by: kilo on February 04, 2021, 01:48:03 PM
Hi ladies,

what do you think of going full Star Wars and adding planetary shields to the game? They would make a great addition to planetary defense and could help preventing some collateral damage from bombing.
Title: Re: C# Suggestions
Post by: Droll on February 04, 2021, 02:11:19 PM
Hi ladies,

what do you think of going full Star Wars and adding planetary shields to the game? They would make a great addition to planetary defense and could help preventing some collateral damage from bombing.

I'm not sure, it sounds really cool but orbital bombardment is already pretty balanced, a planetary shield would make orbital bombardment even weaker and there is already a counter to both missile and beam orbital bombardment in the form of STOs.
Title: Re: C# Suggestions
Post by: TMaekler on February 05, 2021, 12:40:58 AM
Civilian shipping: It would be nice of you could create some kind of priority queue for what the civilians ship around. In my case I wanted to ship some MDs to some new colonies and added them to the source planet. However the civilians finished an oder order of Installations first (which took them ages). So some kind of priority system for the requests would be nice to have.
Title: Re: C# Suggestions
Post by: serger on February 05, 2021, 10:05:47 AM
Just another suggestion to reduce heavy weapons ineffectiveness during assault.

Divide fortification bonus between current camouflage masking effect (reducing hit chance) and additional armouring masking effect (reducing penetration chance).
It will lead to the increase of AV, arty, aerial and space-based heavy weapons effectiveness against fortified garrisons comparing to mere infantry and AP weapon, that needs a breakthrough to be effective.
Title: Re: C# Suggestions
Post by: Kishmond on February 05, 2021, 11:59:16 AM
Why oh why is "Salvage nearest wreck" a galaxy-wide standing order?
Title: Re: C# Suggestions
Post by: unkfester on February 05, 2021, 01:42:44 PM
I've fell foul of that one too
Title: Re: C# Suggestions
Post by: Droll on February 05, 2021, 05:00:49 PM
Why oh why is "Salvage nearest wreck" a galaxy-wide standing order?

Probably the only instance in aurora where a feature is too automated
Title: Re: C# Suggestions
Post by: xenoscepter on February 05, 2021, 07:31:44 PM
 - Can we bring back the button that let's us Research all techs up to a certain RP cost?
Title: Re: C# Suggestions
Post by: Warer on February 05, 2021, 07:34:42 PM
- Can we bring back the button that let's us Research all techs up to a certain RP cost?
Super second
Title: Re: C# Suggestions
Post by: TMaekler on February 06, 2021, 12:55:15 AM
Is there a way to generate two separate "person has died" message? Usually, I ignore when a person dies or leaves his service because I don't need to react to it. But that is of course totally different when a character in an important position dies. Like a sector commander etc. So, is there a way you could separate that somehow into two different kinds of "death" messages so we can color code the one we need to react to?
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 06, 2021, 11:22:58 AM
Is there a way to generate two separate "person has died" message? Usually, I ignore when a person dies or leaves his service because I don't need to react to it. But that is of course totally different when a character in an important position dies. Like a sector commander etc. So, is there a way you could separate that somehow into two different kinds of "death" messages so we can color code the one we need to react to?

Piggyback: Some way to access a dead/retired officer's service record, even if just during the construction increment after their death, so we can honor our most decorated admirals with a moment of silence, or potentially even award posthumous medals to make ourselves feel better about leading our fleet to certain death out of sheer overconfidence eh he deserved it...
Title: Re: C# Suggestions
Post by: kilo on February 06, 2021, 04:19:12 PM
Can we have planet based shield generators like in Star Wars during the attack on Hoth? It might destroy the balance between ships and STO units though.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 06, 2021, 04:54:25 PM
Can we have planet based shield generators like in Star Wars during the attack on Hoth? It might destroy the balance between ships and STO units though.

Making the same suggestion multiple times does not improve the odds of it being implemented.

I don't think planetary shields would fit well, as presumably they would take damage from every shot and be destroyed very quickly. STOs and other ground units have as their principal defense from orbital fire a high fortification level that makes them very difficult to hit. The alternative is incredibly strong shields which would definitely make STOs overpowered as things currently stand, they already gain a 25% range bonus over ship weapons.
Title: Re: C# Suggestions
Post by: papent on February 06, 2021, 06:23:45 PM
Can we have planet based shield generators like in Star Wars during the attack on Hoth? It might destroy the balance between ships and STO units though.

I don't think planetary shields would fit well, as presumably they would take damage from every shot and be destroyed very quickly. STOs and other ground units have as their principal defense from orbital fire a high fortification level that makes them very difficult to hit. The alternative is incredibly strong shields which would definitely make STOs overpowered as things currently stand, they already gain a 25% range bonus over ship weapons.

roleplay the fortification bonus as nuclearslurpee suggested? otherwise how would the mechanics of such a system work?
Title: Re: C# Suggestions
Post by: Borealis4x on February 07, 2021, 12:24:27 AM
Change the name of Power Armor and Heavy Power Armor to Improved Armor and Advanced Armor.

Using a less specific name makes roleplaying easier. I hate how I have to clad my assault infantry in 'power armor' when I believe such thing should be used for truly elite units.
Title: Re: C# Suggestions
Post by: serger on February 07, 2021, 02:34:11 AM
In addition, Power Armour name makes an illusion of depending on Shields tech line, so I'd like it to be renamed, too.

It can be renamed manually in the DB (DIM_GroundUnitArmour and FCT_TechSystem tables) and I think it's rather safe to do, though "no bug post" rule will be swithed on.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 08, 2021, 02:47:10 AM
I know there already is all of stuff that we need to research in the game but I really would like for complete ships to be needed to be researched in the same way we need to research components. Building new ships in reality are a pretty research intensive thing to do even if most the individual components are more or less known or common. Everything always need some sort of special treatment to work in practice.

There could be a template ship type and then you can do variation of that same ship... so variations should then be a separate thing. The template is the basic ship hull with a basic sett of components you then can do variation of that template which are much cheaper to research, similar to retooling for a similar ship.

When you update a template to a new ship type that are similar to the old template is also is cheaper but not nearly as cheap as just doing a variant ship type.

In this I think that components probably need to be weighted not only in cost but also in size and/or type depending on if the ship is variant or you need to produce an entire new template. You also would then replace the retooling system with this system as well. A shipyard retooled for a certain template could also build all the variants.

It would be a nice opportunity to make ships more into a modular lego system rather than the more free form we have today where anything goes everywhere. In reality I'm sure we could not just put any component in any place on a ship without some consequence. So making some changes to fit such a system into the design would be nice as well. It would put a few more restrictions as some components would compete for the same space on the ship while others won't. There definitely should be a large difference if a component need to be placed closer to the edge of a ship or not or if it matter more or less to some components, this then could also have an impact on how different components are exposed to combat damage as well rather than just being based on size. Sensors for example usually are pretty small but often will have to be placed in compromised locations so should be much more likely damaged when just looking at pure size. Compared with an engineering section that likely are located much deeper inside a ship and thus less likely to be hit.

I also think that the research cost should not scale linear by size so a small ship should be allot more expensive than a larger ship seen to their mass. A small fighter should be relatively expensive to design versus a 100kt carrier seen to their respective size.

In any way... we then would have to research each ship design and all its variants and then we retool the shipyards to build them. This would give us a more "realistic" ship design procedure... in general I don't think the retooling cost is nearly enough of a cost to represent the investment in building new ships.

Obviously not a small change so nothing to take lightly...  :)
Title: Re: C# Suggestions
Post by: TMaekler on February 08, 2021, 03:19:42 AM
Obviously not a small change so nothing to take lightly...  :)
The construction yards have all of that build in. They do the research while they construct the first ship or retool for it.

Well, that is just my in-lore explanation. And research is already jam packed and for my taste a too strong factor in "winning the game"... I don't think we should put more on this factor.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 08, 2021, 03:42:06 AM
Obviously not a small change so nothing to take lightly...  :)
The construction yards have all of that build in. They do the research while they construct the first ship or retool for it.

Well, that is just my in-lore explanation. And research is already jam packed and for my taste a too strong factor in "winning the game"... I don't think we should put more on this factor.

I think the opportunity cost for just creating new versions is too simple and research would be more expensive and so building more jack of all trades ships make more realistic sense than it does currently in terms of opportunity cost from a research perspective.

I also find that having ships based on templates also would impose more interesting ship design considerations and some important restrictions.

So I think it should be quite viable to do this as the cost to retool can often be kept very low most of the time between a refit from one type to the next.

The changes to shipyards also make it so having one yard for every type of ship quite affordable so the retooling is rather cheap for the most part.
Title: Re: C# Suggestions
Post by: serger on February 08, 2021, 05:23:34 AM
I think it might be quite simple and very good change to have a logarithmic research costs instead of linear from the size.
Smaller components and hulls are really not much simpler then larger ones, and R&D times for missiles, planes and battleships are nearly equal really.

(I understand that it can be made as home rule, but it's very micro-heavy to implement this home rule every time - we must remember separately to not use this, and this, and this component and GF unit until next year, and keep all research labs busy with some research of straw to load population and economics, and then remember to reward or not reward some scientists... Umpffffff. My hope is that Steve likes to conduct stories and read details as they flow, not calculate and script the very small detail unassisted!)
Title: Re: C# Suggestions
Post by: serger on February 08, 2021, 05:49:12 AM
And, in addition to the previous, I'd remind that new GF units, missile-size ordnance and small (fighter-sized) crafts are unaffected by shipyard's retooling process completely, and exactly these objects are very cheap with linear rule, so in those cases we have to rely on home rules ONLY if we want to have some realism.
Title: Re: C# Suggestions
Post by: shepard1707 on February 08, 2021, 09:15:49 PM
I still think it'd be really handy to have some way to automatically number Hulls in a class, while still having the ship's have Given names.  It's just dang useful to know which ships are older and which ships are newer.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 09, 2021, 01:06:22 AM
I still think it'd be really handy to have some way to automatically number Hulls in a class, while still having the ship's have Given names.  It's just dang useful to know which ships are older and which ships are newer.

Seconded. Since we already have prefixes and suffixes, it would be great if typing "Number" into those fields inserted the number, same as how "None" is recognized as the code to have no pre/suffix except adding a number instead.

Advice to commenter: you can see the ships in a class sorted by age in the Class Design Window, Ships in Class tab as they are by default sorted by launch date.
Title: Re: C# Suggestions
Post by: QuakeIV on February 09, 2021, 01:28:23 AM
I'd personally argue for a function of total RP cost of the constituent components, to reflect the cost of integrating more complicated parts.

Perhaps somewhere in the domain of 10-20% of said cost?

e: Honestly 10-20% actually feels excessive.  It seems like you should be able to get more than 5-10 ship designs out of your components before integration costs exceeds the RND cost of the initial hardware.
Title: Re: C# Suggestions
Post by: Ektor on February 09, 2021, 01:52:50 AM
I'm not sure whether this has been brought up before, but I'd love an option to make a robotic race, where you need to build facilities to have pop growth, kinda like gene editing facilities existed in VB6. Perhaps the robots could even take TN materials to build, so you could unlock robot building as a tech through research to boost your population growth. Maybe robots could have tolerances and such and could have a tech line dedicated to them, like biology messes with the tolerances of biological races.
Title: Re: C# Suggestions
Post by: TMaekler on February 09, 2021, 08:19:21 AM
Max Population Factor:

Aurora basically simulates only population which is capable of working productively. Children and older people are not modelled. Thinking that through I was wondering of the actual pop max of 12B for Earth isn't too large. Let's say that we actually have around half of the worlds population in the worker age bracket, that would mean that a maxed out earth in Aurora would have 24B people living here.

Whilst maybe possible, having 12B workers seems to me to be too much in terms of the production values Aurora has. How many 10.000 over 10.000 of production factories could earth have?!?

So I was thinking about adding some kind of population factor: Humans for example do have 0.5. So max pop would still be 12B, but only 6B of them would be in the worker age bracket. And so on.

Other races could perhaps have a factor of 0.7 - and thereby be better of with larger populations. Or 0.3 and have to compensate for their lack of production with massive pop growth... .
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 09, 2021, 09:21:20 AM
Max Population Factor:

Aurora basically simulates only population which is capable of working productively. Children and older people are not modelled. Thinking that through I was wondering of the actual pop max of 12B for Earth isn't too large. Let's say that we actually have around half of the worlds population in the worker age bracket, that would mean that a maxed out earth in Aurora would have 24B people living here.

Whilst maybe possible, having 12B workers seems to me to be too much in terms of the production values Aurora has. How many 10.000 over 10.000 of production factories could earth have?!?

So I was thinking about adding some kind of population factor: Humans for example do have 0.5. So max pop would still be 12B, but only 6B of them would be in the worker age bracket. And so on.

Other races could perhaps have a factor of 0.7 - and thereby be better of with larger populations. Or 0.3 and have to compensate for their lack of production with massive pop growth... .

I'm not saying that I dislike this idea because I don't... but I generally just assume that population already take old and young people into account as is so there would be no immediate need for this. When a factory need 50.000 workers that is just general population and only part of them will actually be working not everyone. Both children and seniors are still an important part of society in different ways so there is no need to differentiate them. We still end up with the same numbers at the end.
Title: Re: C# Suggestions
Post by: serger on February 09, 2021, 02:31:02 PM
Besides, about Max Population.

I think it will be good, if it will depend on the "depth" of planet's surface properties in the sense of population's tolerance intervals. So, say, if your population have temperature interval -10..10C, and planet's average surface temperature is -10, then you will have Current Max Population = 1/2 of Ideal Max Population + current infrastructure with minimal colony cost (that is - you can establish a city in the middle of Antarctic, if you have enough infrastructure). Terraform this planet to 0C - and you'll have Current Max Population = Ideal Max Population + current infrastructure.
Title: Re: C# Suggestions
Post by: serger on February 10, 2021, 02:53:01 AM
There was an autoсalculated field in VB Aurora's Class Design window named Power Required - it was very helpful, especially for new players, and for anyone who doesn't have a fun with routine arithmetic.
Will be cool to have it in C# again.
Title: Re: C# Suggestions
Post by: Ektor on February 10, 2021, 01:16:42 PM
My current game is locked into 6 hour increments due to NPRs. I really, really wish that we could have our time increments not be disturbed by their activity. I'm not even talking about when it goes down to 5 seconds because I understand computing battles must be harder on the game, but when nothing's happening, I really wish I could play with 5 day increments again.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 10, 2021, 08:18:15 PM
One of two suggestions:

(1) Preferably, remove the Ground Combat Command skill from the game. This has been discussed many times and the general consensus is that is a limiting, unfun mechanic (or it would be, if it worked) which functions uniquely to every other skill in the game which are strictly bonuses.

(2) At a minimum, remove this skill from the commander auto-assign algorithm, as presently all it accomplishes is leaving numerous battalions devoid of commanders. As far as I know, the skill doesn't even work as intended so is a completely artificial limit on commander assignments, and even if it is WAI it does not mechanically prevent a commander from leading an "oversize" formation, and as a fraction of a bonus is better than no bonus I would much rather see commanders with low Command skills still assigned to formations they lack the skill to command at full effectiveness.
Title: Re: C# Suggestions
Post by: Ektor on February 10, 2021, 09:19:56 PM
snip

I really agree. I have a lot of ground commanders that are unassigned and formations with no commander. I think it should be better implemented.

I'm not sure whether I've said this before, but I'd really like the possibility to have different tech speed modifiers for part design and research. I love doing 15% research games, but I don't want designing a single ship to take multiple years.
Title: Re: C# Suggestions
Post by: Barkhorn on February 10, 2021, 10:05:03 PM
I'd like to see a similar thing for ships.  If I have officers available and captainless ships, it should match them up, even if the ranks might not make sense.  I am more upset by seeing an idle admiral and a commanderless corvette than I would be by seeing an admiral commanding a corvette.
Title: Re: C# Suggestions
Post by: TMaekler on February 11, 2021, 12:24:17 AM
I think that the assignment system in general works. Though it could be improved. For example usually a nation trains their commanders in the jobs they are going to embark into. Also according to the nations needs. So if a country needs 25 commanders, 15 captains they will train people for these jobs so they can perform those. If the quality lacks, that is another issue ... . But the game should check the vacancies and make some kind of training skills list needed to fill those vacancies. The universities then could train for those vacancies and newly trained commanders will graduate with a higher chance of having those skills. So over time those vacancies should fill up slowly but steadily.
Title: Re: C# Suggestions
Post by: xenoscepter on February 11, 2021, 12:25:28 AM
I'd like to see a similar thing for ships.  If I have officers available and captainless ships, it should match them up, even if the ranks might not make sense.  I am more upset by seeing an idle admiral and a commanderless corvette than I would be by seeing an admiral commanding a corvette.

 - It shouldn't auto-assign an Admiral to a Corvette unless you tell it to, mostly because IRL, or in this case let's go with an RP trying to mimic IRL as much as possible; that Admiral wouldn't want to command such a cramped ship, and by extension there wouldn't be too many people in the Navy who could order him(her) to do otherwise. There should be a toggle for ignoring over-ranked officers, and likewise you should be able to simply force an up-ranked officer to command whatever you assign them to.
Title: Re: C# Suggestions
Post by: QuakeIV on February 11, 2021, 12:39:31 AM
Or you could just not promote them out of their command if there is nothing available for them at the higher rank...
Title: Re: C# Suggestions
Post by: Gabrote42 on February 11, 2021, 09:44:29 AM
My current game is locked into 6 hour increments due to NPRs. I really, really wish that we could have our time increments not be disturbed by their activity. I'm not even talking about when it goes down to 5 seconds because I understand computing battles must be harder on the game, but when nothing's happening, I really wish I could play with 5 day increments again.
I proposed a workaround for that earlier. Take a read, and if you want you can quote it and give me feedback.
Title: Re: C# Suggestions
Post by: misanthropope on February 11, 2021, 09:59:32 AM
in the global modifiers, i'd love to be able to modify (specifically increase) gate building time, and i'd love to be able to modify (specifically decrease) jump drive size (and by extension cost)
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 11, 2021, 10:26:05 AM
in the global modifiers, i'd love to be able to modify (specifically increase) gate building time, and i'd love to be able to modify (specifically decrease) jump drive size (and by extension cost)

I'm pretty sure you can  modify both of those values in the DB if you are up for it. I modify a bunch of stuff for most of my games to fit into my story and campaigns, quite simple to do. If everyone should get access to their preferred version of every component the list would get pretty long I imagine.   ;)
Title: Re: C# Suggestions
Post by: papent on February 11, 2021, 01:06:07 PM
3 Minor Suggestions:

I) A 5 HS refuel system with 5000 LPH For Fighters and FAC's. Intent is a refuel system useful for small craft but too slow of refuel rate to be of any use on larger ships.

II) Squadron Transit Distance Applies to Departure system in addition to Arrival system. Intent is allow for rapid retreats or raiding parties to evade possible jump pickets.

III) Casemates options for non-turret weapons. Intent is to increase HTK for weapons such as missile launchers, railguns, plasma cannonades, and etc. by armoring them up.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 11, 2021, 01:40:25 PM
3 Minor Suggestions:

I) A 5 HS refuel system with 5000 LPH For Fighters and FAC's. Intent is a refuel system useful for small craft but too slow of refuel rate to be of any use on larger ships.

II) Squadron Transit Distance Applies to Departure system in addition to Arrival system. Intent is allow for rapid retreats or raiding parties to evade possible jump pickets.

III) Casemates options for non-turret weapons. Intent is to increase HTK for weapons such as missile launchers, railguns, plasma cannonades, and etc. by armoring them up.

I) is a simple change, possible as simple as a DB entry, and would not be very useful but would allow RP possibilities using tanker fighters to pull off long-range logistical missions. No reason not to add this I think.

II) is not a simple change, and would need to be balanced by a corresponding change so that smaller ships can jump farther than big ones. Otherwise it becomes trivial to evade JP pickets with even very large fleets - why send a raiding party when you can send the entire invasion?

III) would be amazing for RP as I sometimes like to RP with e.g. laser turrets but these are greatly impractical due to the wasted tonnage just to bring a turret up to the ship's tracking speed. However as this would mechanically overlap with turrets maybe a better change is to change turrets so that they add their speed to that of the ship (and reduce the gear efficiency per tech level to compensate)? The a turret with 0 km/s speed would not be a hindrance and you could still put armor on your weapons, but Steve only needs to adjust one mechanic instead of adding a new, semi-parallel one. Of course now we have the limitation that turrets can only be used with some weapon types...
Title: Re: C# Suggestions
Post by: kilo on February 11, 2021, 01:42:00 PM
I was thinking about and hoping for a jump point deconstruction module or a weapon of sorts that does the job. It would allow for scorched earth tactics and maybe close a jump point or stabilized intra-system jump point before an enemy fleet can follow.
There are quite a few useful applications for this in defensive warfare against superior empires.
Title: Re: C# Suggestions
Post by: unkfester on February 11, 2021, 01:51:56 PM
Plus one this  ;)
Title: Re: C# Suggestions
Post by: Erik L on February 11, 2021, 01:59:09 PM
I was thinking about and hoping for a jump point deconstruction module or a weapon of sorts that does the job. It would allow for scorched earth tactics and maybe close a jump point or stabilized intra-system jump point before an enemy fleet can follow.
There are quite a few useful applications for this in defensive warfare against superior empires.

Since they are no longer physical gates, that is why you cannot destroy them. A destabilizer would be nice :)
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on February 11, 2021, 02:14:34 PM
I was thinking about and hoping for a jump point deconstruction module or a weapon of sorts that does the job. It would allow for scorched earth tactics and maybe close a jump point or stabilized intra-system jump point before an enemy fleet can follow.
There are quite a few useful applications for this in defensive warfare against superior empires.

Since they are no longer physical gates, that is why you cannot destroy them. A destabilizer would be nice :)
Ha, wasn't the reason for changing from gates to stabilizers so that people would stop asking for a way to destroy them?
Title: Re: C# Suggestions
Post by: serger on February 11, 2021, 02:17:10 PM
Ha, wasn't the reason for changing from gates to stabilizers so that people would stop asking for a way to destroy them?
:D
Title: Re: C# Suggestions
Post by: papent on February 11, 2021, 02:28:27 PM
snip
II) is not a simple change, and would need to be balanced by a corresponding change so that smaller ships can jump farther than big ones. Otherwise it becomes trivial to evade JP pickets with even very large fleets - why send a raiding party when you can send the entire invasion?
snip

It would scatter the entire invasion force around the arrival system jump point in small packets perfect for defeat-in-detail.
For a small group of stealth raiders I would risk it.
A planetary invasion taskforce with specialized Combatants it could be risky on how the ships get scattered and in which directions they get placed..
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 11, 2021, 02:33:05 PM
snip
II) is not a simple change, and would need to be balanced by a corresponding change so that smaller ships can jump farther than big ones. Otherwise it becomes trivial to evade JP pickets with even very large fleets - why send a raiding party when you can send the entire invasion?
snip

It would scatter the entire invasion force around the arrival system jump point in small packets perfect for defeat-in-detail.
For a small group of stealth raiders I would risk it.
A planetary invasion taskforce with specialized Combatants it could be risky on how the ships get scattered and in which directions they get placed..

This is already basically how a squadron jump into the system works. The point is more relating to the jumping-out mechanic which was the original suggestion.
Title: Re: C# Suggestions
Post by: papent on February 11, 2021, 02:48:47 PM
okay it would require a change to the average JP picket operation...
It would require an force to have a forward defense towards the threat vector instead of just sitting directly on the Jump point.
Title: Re: C# Suggestions
Post by: TMaekler on February 12, 2021, 12:23:41 AM
I was thinking about and hoping for a jump point deconstruction module or a weapon of sorts that does the job. It would allow for scorched earth tactics and maybe close a jump point or stabilized intra-system jump point before an enemy fleet can follow.
There are quite a few useful applications for this in defensive warfare against superior empires.
Yes, let's go "Deep Space Nine" all the way: destabilise the worm hole entirely and collapse it :-)
Title: Re: C# Suggestions
Post by: QuakeIV on February 12, 2021, 12:58:07 AM
I honestly feel like the effect of 'comitting' to stabalizing a point would be about the same if you had a way to destabalize them and it just took a lot more time (or inordinate investment of some other kind).  If I had to leave a ship on a point for 10 years to get rid of the jump point (and it then needed a jump drive to be able to leave) then I would absolutely exercise that option periodically.
Title: Re: C# Suggestions
Post by: unkfester on February 12, 2021, 01:34:26 AM
I was thinking destabilise. Meaning gone, gone forever, no going back.
That way you would really think about closing it.
Title: Re: C# Suggestions
Post by: kilo on February 12, 2021, 02:18:32 AM
When I was making this suggestion I was merely thinking of removing the door handle on one side, not destroying the connection between systems. A star empire that is on the offense would need to capture intact jump points so that it can handle it's logistics, as the fat ships might not be able to follow your war fleet due to damages to the jump network. On top of that, it would allow trapping an enemy fleet in your space after destroying their jump capability by denying jump points.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 12, 2021, 02:49:16 AM
While destroying them completely sound a bit extreme we could perhaps damage or destabilise them enough so only "Military" jump drives could enter them, perhaps also making any jump having twice the blinding effect as normal too. You now would first have to repair them for your civilian support ships to follow your fleet.

This could be the more interesting form of scorched earth type of tactics in this game as it is right now.

It would most likely need some rewriting of AI logic as well so perhaps a much bigger task than it's worth, I don't know.
Title: Re: C# Suggestions
Post by: QuakeIV on February 12, 2021, 02:00:13 PM
I'm not sure we really have the mechanics on hand to make a satisfying system where the jump point is only partially disabled.

I guess a partially dead jump point could have a tonnage limit.  Maybe that then slowly comes back up over time as the point recovers or something.

Making the jump blinding worse is decent but that does kindof worsen the whole 'jump point defenses are really difficult to deal with' problem.
Title: Re: C# Suggestions
Post by: Droll on February 12, 2021, 02:22:05 PM
I don't think its smart to "destroy" JPs permanently unless there is a way to "rebuild" them with a stabilizer.

For example a destroyed JP would need x2 the time that the stabilizer module is rated at in order to repair. You could make it so that stabilized JPs cannot be destroyed in order to add an incentive to stabilize JPs that are on the frontline.

I think this is the easiest way programmatically to implement something like this without creating new underlying mechanics.
Title: Re: C# Suggestions
Post by: Kristover on February 12, 2021, 09:09:12 PM
It seems to be that the tools to 'destroy' JPs could be easily put into place - the functionality obviously exists to stabilize a JP, couldn't Steve put in the function to reverse it in the same manner?  You're not actually destroying the JP.  You are just destabilizing it to make it harder to travel through.  This would open up good gameplay options it seems to me.
Title: Re: C# Suggestions
Post by: TMaekler on February 13, 2021, 05:45:04 AM
I like the idea of jump points being at different cohesion levels which then would impact the amount of jump distance / parallel jump capacity of that said jump point. The general technology to control this is already there - jump stabilization. It just needs to be expanded in both ways: make it more cohesive or less.

The question is: what and how should or could a jump point be limited?
For one, making it completely go away is for sure too far outside of the base game mechanics - unless we want to make them being build up from the ground as well... but I don't think so.

But make a jump point limited to the number of parallel ships that could pass - sure, why not? A "small" wormhole simply can only max transfer 2 ships at most. Whilst the "Amazon River" has no problem with 10 ships floating in parallel... . Also, if we limit the number of max parallel ship transfers this should be a limiting factor only from one side. I don't want to have it in a way where my enemy could diminish a jump connection down to one or two ships making it impossible to jump him. So if the jump point from my side is ok, I can jump in 10 ships in parallel, but because he diminished it from his side he can only jump in two ships at a time. So minimizing a jump point for me he would have to have control for a time being to destabilize it from my side.

And - sure, those diminishing and strengthening should take a lot of time... three to four times your standard stabilization time at least.... .
Title: Re: C# Suggestions
Post by: Kristover on February 13, 2021, 09:44:16 AM
Okay here is the pettiest and most minuscule of requests ever made.....can we get the stars recolored to reflect their true color, i.e yellow, red, orange, blue, white based off their type?  It is the smallest of things but I think it would be a cool low impact way to differentiate the systems visually.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 13, 2021, 09:53:39 AM
I terms of JP I'm not actually a huge fan of them at all to be honest, it is a bit too limited in tactical and strategic operational sense.

If Steve ever make any concerted effort to make any big changes I just he make a 2.0 update and use his Aurora 2 ideas for space travel instead, this would in my opinion be an even more fun game.

http://aurora2.pentarch.org/index.php?topic=3011.0 (http://aurora2.pentarch.org/index.php?topic=3011.0)
Title: Re: C# Suggestions
Post by: QuakeIV on February 13, 2021, 01:33:11 PM
Okay here is the pettiest and most minuscule of requests ever made.....can we get the stars recolored to reflect their true color, i.e yellow, red, orange, blue, white based off their type?  It is the smallest of things but I think it would be a cool low impact way to differentiate the systems visually.

As an addendum to this, maybe that could bias the background color a bit.
Title: Re: C# Suggestions
Post by: xenoscepter on February 14, 2021, 02:31:27 AM
 - I would like to request / suggest the addition of derelict ships. Like ruins, but in space, ghost ships so to speak. I'd also like to request / suggest the addition of Space Hulks, with both these and the derelicts having a chance to appear at random even after that system has been generated. Perhaps at a reduced rate compared to their chance to spawn at system creation. :) Furthermore I'd propose a new NPR for the Space Hulks, with a chance to spawn either Precursors, Swarm (If they have Ground Forces), or a new spoiler race with an Eldritch / Lovecraftian / 40K Warp theme to them. This would have the byproduct of greatly increasing the utility of Marine Forces. The Derelicts and the Space Hulks could be boarded and captured to provide useful techs and modules, or perhaps expand the use of Science Departments & ELINT to gather the data. Maybe have those be required to identify the boni in the vein of a Xenoarchaeology Module before boarding, or require boarding first and then have them do the actual extraction.

 - It might be fun to have Derelicts be a sort of minor ruin, with the possibility of permanent capture & research, but to have the Space Hulk be ever under the threat of reclamation from the Eldritch NPR. The lore behind it could be that some ships get lost in or ruined by the Aether, while others get sucked in from alternate universes and occasionally spat out in the player's universe. This would make the Space Hulks potential bridges to other dimensions, while the Derelicts could be more like ruins in that they are ships that remain after an old civilization died out. Potentially having drifted several hundreds or even thousands of lightyears or more and quite possibly being ancient in the extreme. They could similarly have grades like ruins, indicating their state of decay and determining their usefulness... if any. Having Derelicts re-rolled at a higher chance if they fail to spawn, but a ruin successfully spawns in that system would be one idea.
Title: Re: C# Suggestions
Post by: QuakeIV on February 14, 2021, 03:31:12 AM
Regarding box launchers vs 'regular' launchers, what if 'regular' missile launchers were allowed to build up a salvo of missiles by jettisoning them into space and then allowing the missiles to sit and wait until the full salvo is ready to go?

It may or may not wind up being overpowered, but I would note that it would result in a tradeoff where you would potentially want to build ships that are relatively bad at short ranged combat (if suddenly finding themselves at close range then they cant launch a big salvo quickly) but which are highly specialized into long range combat.

This might also justify a degree of differentiation between box launchers and reloading launchers, if it were said that the reloading launchers are capable of releasing missiles without requiring them to ignite their engines, whereas box launchers due to their generally light weight and simplified construction aren't equipped to be able to do that (the missile needs to leave under its own power).

e: 'regular' in quotes because i think box launchers are currently a lot more common
Title: Re: C# Suggestions
Post by: Zap0 on February 14, 2021, 05:28:53 AM
Regarding box launchers vs 'regular' launchers, what if 'regular' missile launchers were allowed to build up a salvo of missiles by jettisoning them into space and then allowing the missiles to sit and wait until the full salvo is ready to go?

It may or may not wind up being overpowered, but I would note that it would result in a tradeoff where you would potentially want to build ships that are relatively bad at short ranged combat (if suddenly finding themselves at close range then they cant launch a big salvo quickly) but which are highly specialized into long range combat.

This might also justify a degree of differentiation between box launchers and reloading launchers, if it were said that the reloading launchers are capable of releasing missiles without requiring them to ignite their engines, whereas box launchers due to their generally light weight and simplified construction aren't equipped to be able to do that (the missile needs to leave under its own power).

e: 'regular' in quotes because i think box launchers are currently a lot more common

I might be wrong, but I think I remember some ancient AAR where this was a thing. I think that yes, it would very much be overpowered, and take away much of the distinction between regular and box launchers. At that point you might just give a field for how many missiles out of your magazines you want to launch at an enemy, bypassing the annoying setting and targeting of waypoints entirely.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 14, 2021, 07:26:37 AM
There are two big issues why box launchers are so powerful.

One large reason are freedom to build a ship how ever you like with no real constraints on actual space on the ship. A box launcher are relatively small but most of it's actual size have to be rather near the surface of the ship. A full size launcher would have the majority if it's size much deeper into the hull of the ship, the same goes for the magazines, this is space that box launched variants could not use.
There is a major difference in design of a ship that is practically the size of a few missiles or a ship that are hundred of time bigger than the missiles they fire. The bigger ship would not have the external space to fit as much missiles as the smaller one who are essentially built around those few missiles. It is like the difference between a spinal weapon and a standard weapon.

The other major reason is fire-controls... there are no limitation to what a fire-control can manage and how they can track and give order corrections to missiles.

When you combine these two things and how salvoes and beam point defenses work there is not really much contest between box launched salvoes and full size launchers. Full size launchers are mainly effective at small crafts and ships with little to no or less effective PD and rarely have access to AMM defenses.

In my opinion box-launchers should have a limit based in the missiles size in relation to the ship size and how much space it can take of the total ships mass (space). Just as an example... say a size 6 missile could take up 50% of a 500t hull... but a size 6 would only be able to take up 33% of a 1000t hull or maybe 9.5% of the space on a 8000t hull. In my opinion most components should have limits like this to some extent. I think that ship building would become a bit more balanced that way.
Title: Re: C# Suggestions
Post by: QuakeIV on February 14, 2021, 01:37:26 PM
Realistically you could just build a ship with more surface area
Title: Re: C# Suggestions
Post by: kilo on February 14, 2021, 02:03:39 PM
Realistically you could just build a ship with more surface area

And by doing this you will shoot yourself in the foot. You would need significantly more armor and huge parts of the hard points on your vessel would be in locations without line of fire.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 14, 2021, 02:45:05 PM
Realistically you could just build a ship with more surface area

And by doing this you will shoot yourself in the foot. You would need significantly more armor and huge parts of the hard points on your vessel would be in locations without line of fire.

The latter of these isn't really a problem for missile launchers. "Vertical" may be relative in deep space, but the concept of a VLS works just fine all the same.
Title: Re: C# Suggestions
Post by: QuakeIV on February 14, 2021, 06:50:47 PM
Should probably be able to pay for more armor if I so desire
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 14, 2021, 08:55:26 PM
Realistically you could just build a ship with more surface area

The problem is that from a "realistic" or "practical" perspective it would likely pose very large problems with hull integrity, armour, usage of crew space, engineering, and fitting the engine to allow for the ship to move efficiently. No complex vehicle is that easy to design and I don't believe they actually are in Aurora either.

I'm just saying that ships likely are built in certain shapes for a reason... this is the problem when we get free reign to fit whatever we want with no regards to what is practically actually possible from an engineering perspective.

It makes sense that components can't just be placed anywhere on a ship and box launchers are a pretty good examples of this. Imagine that the ship is a sphere which is the basic shape of the ships and go from there. Not saying that ships in Aurora are spheres... but I presume they have a relatively large interior space for a reason, armour and hull integrity probably being the biggest reasons for this and probably also for making the engines as effective as possible as in Aurora the volume of the ship is the most important factor.

There is no problem with role-play these limits... I do that all the time. But it would give somewhat more balance to ship design in general.

Title: Re: C# Suggestions
Post by: QuakeIV on February 14, 2021, 10:04:01 PM
Realistically you could just build a ship with more surface area

The problem is that from a "realistic" or "practical" perspective it would likely pose very large problems with hull integrity, armour, usage of crew space, engineering, and fitting the engine to allow for the ship to move efficiently. No complex vehicle is that easy to design and I don't believe they actually are in Aurora either.

I'm just saying that ships likely are built in certain shapes for a reason... this is the problem when we get free reign to fit whatever we want with no regards to what is practically actually possible from an engineering perspective.

It makes sense that components can't just be placed anywhere on a ship and box launchers are a pretty good examples of this. Imagine that the ship is a sphere which is the basic shape of the ships and go from there. Not saying that ships in Aurora are spheres... but I presume they have a relatively large interior space for a reason, armour and hull integrity probably being the biggest reasons for this and probably also for making the engines as effective as possible as in Aurora the volume of the ship is the most important factor.

There is no problem with role-play these limits... I do that all the time. But it would give somewhat more balance to ship design in general.

I'd rather that be based on real reasons rather than 'it feels unrealistic'.  Even if a sphere of box launchers seems ridiculous to you, its probably possible.  Generally speaking new stuff looks ridiculous to older ways of war.
Title: Re: C# Suggestions
Post by: Erik L on February 14, 2021, 11:08:14 PM
Should probably be able to pay for more armor if I so desire

Just add more layers?
Title: Re: C# Suggestions
Post by: QuakeIV on February 15, 2021, 12:35:32 AM
Should probably be able to pay for more armor if I so desire

Just add more layers?

I think Jorgen was referring to the idea of limited surface area for the ships to try to constrain box launchers, so I was saying I'd be willing to accept paying for more armor in exchange for more surface area.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 15, 2021, 04:55:00 AM
Should probably be able to pay for more armor if I so desire

Just add more layers?

I think Jorgen was referring to the idea of limited surface area for the ships to try to constrain box launchers, so I was saying I'd be willing to accept paying for more armor in exchange for more surface area.

Sure... if there was some sort of system for this... the problem that I have is that people almost always think like gamers and don't understand how complex things actually are in "reality" even within a games lore there are internal consistent rules you need to follow that are in some way consistent with our reality in some sense.

This is also why I think that we sometimes think that we can do this when in "reality" it would likely be impossible or the drawback would be so huge that doing so would be stupid.

A ship with too much surface area would probably be so unstable or weak that no one in their right mind would build it. The reason why you can fit more box launcher on a smaller platform is because the ship is built around the launcher system as they take up the internal part of the ship, just like a spinal weapon would. When a ship gets larger this is no longer possible so a much smaller area to fit the launchers would be possible. making the hull as thin as that of a 500t craft would make the ship so weak it might not even be able to turn without breaking or even turn their engines on (depending on the the technology work), also probably could not fit either engineering or most other components in there either in a reasonable way.

What I mean is that we often just hand-wave these limitations that most probably would exists, and the only way we can do this is role-play.

I have no problem using role-play to impose these risks, AI ships are never designed to do any of this so there is no real problem. I don't know what's in Steves mind... but from past discussions on similar matters he seem to think that people should just build reasonable ships but they don't have too. You can play however you like and use whatever restriction feels best for you. If it make little sense from an engineering perspective to fit a 20kt ship with 50% size 4 box launchers then that is how it is in your lore, there are mechanical and engineering reasons for not doing it.

I invoke MANY engineering reason for how different system can interact on different types of ship hulls, in my opinion this give allot more character to the game than just abusing game mechanic as they are. I also think this is how the game is intended to be played... using your own lore to what is possible or not.

My reasoning though was that I think the game would in general be beneficial of making it slightly more balanced so these extreme cases are less one sided as they are mainly the only way to go if you do what is most efficient from a game mechanics perspective. Not everyone can or want to role-play self limitations. Box launched strikes should still be a strong tactic, just not as strong (or the only way) and a bit more expensive.
Title: Re: C# Suggestions
Post by: Steve Walmsley on February 15, 2021, 10:02:18 AM
Okay here is the pettiest and most minuscule of requests ever made.....can we get the stars recolored to reflect their true color, i.e yellow, red, orange, blue, white based off their type?  It is the smallest of things but I think it would be a cool low impact way to differentiate the systems visually.

They do have the correct colours :)

A 'yellow' star isn't actually yellow. If you look in DIM_StellarType you can see that each star has a specific colour based on its spectral type. The colour is also affected by atmosphere.
Title: Re: C# Suggestions
Post by: Steve Walmsley on February 15, 2021, 10:03:23 AM
Ha, wasn't the reason for changing from gates to stabilizers so that people would stop asking for a way to destroy them?

Yes :)
Title: Re: C# Suggestions
Post by: Droll on February 15, 2021, 10:12:02 AM
Ha, wasn't the reason for changing from gates to stabilizers so that people would stop asking for a way to destroy them?

Yes :)

Well that didn't work lol
Title: Re: C# Suggestions
Post by: Steve Walmsley on February 15, 2021, 11:37:24 AM
There was an autoсalculated field in VB Aurora's Class Design window named Power Required - it was very helpful, especially for new players, and for anyone who doesn't have a fun with routine arithmetic.
Will be cool to have it in C# again.

As a quick fix, I have added the required power and reactor power to the 'insufficient power' alert on the class design window.
Title: Re: C# Suggestions
Post by: Steve Walmsley on February 15, 2021, 11:45:21 AM
(1) Preferably, remove the Ground Combat Command skill from the game. This has been discussed many times and the general consensus is that is a limiting, unfun mechanic (or it would be, if it worked) which functions uniquely to every other skill in the game which are strictly bonuses.

Yes, I agree on this. I had forgotten the bonus existed, but you are right that it is a limitation without adding any meaningful decisions. I've removed it for v1.13.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 15, 2021, 12:34:45 PM
(1) Preferably, remove the Ground Combat Command skill from the game. This has been discussed many times and the general consensus is that is a limiting, unfun mechanic (or it would be, if it worked) which functions uniquely to every other skill in the game which are strictly bonuses.

Yes, I agree on this. I had forgotten the bonus existed, but you are right that it is a limitation without adding any meaningful decisions. I've removed it for v1.13.

Will higher ranked commander give any bonuses to lower formations as well now... I think that this also have not been working as intended either up until now?

I also thin it would be nice if we could give each formation a primary and secondary choice of skill? Not sure how commanders are pucked at the moment for different formations.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 15, 2021, 01:35:36 PM
I also thin it would be nice if we could give each formation a primary and secondary choice of skill? Not sure how commanders are pucked at the moment for different formations.

This could probably work automatically, similar to naval auto-assign, by simply applying special cases based on the type of the single largest formation element (by total weight). E.g. in a 5,000-ton formation with 3,000 tons of INF+PW and 2,000 tons of LVH+CAP the formation is typed as "infantry".

Suggested bonuses to consider would be:

Skills like GC Offense, Defense, Training, Logistics are useful for nearly all formation types and do not need specialization rules. GC occupation can be neglected.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 15, 2021, 03:15:14 PM
I also thin it would be nice if we could give each formation a primary and secondary choice of skill? Not sure how commanders are pucked at the moment for different formations.

This could probably work automatically, similar to naval auto-assign, by simply applying special cases based on the type of the single largest formation element (by total weight). E.g. in a 5,000-ton formation with 3,000 tons of INF+PW and 2,000 tons of LVH+CAP the formation is typed as "infantry".

Suggested bonuses to consider would be:
  • If the major element has a STO weapon, no commander should be assigned
  • Artillery bonus if the major element has a bombardment weapon
  • AA bonus if the major element is an AA weapon
  • PRD/SRV/XEN bonus if blah blah blah...
  • Manoeuvre bonus if the major element of the formation is a Vehicle type which does not meet one of the above classifications (assuming the formation is tanks, etc.)
  • Otherwise no special bonus is preferred and a formation is assumed to be INF or STA and given any remaining commanders

Skills like GC Offense, Defense, Training, Logistics are useful for nearly all formation types and do not need specialization rules. GC occupation can be neglected.

Yes... I think that could work pretty well and I'm not sure if this is not already the case or not... but it seem to me most of the time that they are randomly put in charge of formations but I can be wrong.

There also are the Tactical skill which should be applied to STO formations, but this skill seem super rare and it also is not in the sorting list for some reason so perhaps it does not work properly. I think the Tactical skill should be more common for STO formations.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 15, 2021, 03:21:07 PM
I also thin it would be nice if we could give each formation a primary and secondary choice of skill? Not sure how commanders are pucked at the moment for different formations.

This could probably work automatically, similar to naval auto-assign, by simply applying special cases based on the type of the single largest formation element (by total weight). E.g. in a 5,000-ton formation with 3,000 tons of INF+PW and 2,000 tons of LVH+CAP the formation is typed as "infantry".

Suggested bonuses to consider would be:
  • If the major element has a STO weapon, no commander should be assigned
  • Artillery bonus if the major element has a bombardment weapon
  • AA bonus if the major element is an AA weapon
  • PRD/SRV/XEN bonus if blah blah blah...
  • Manoeuvre bonus if the major element of the formation is a Vehicle type which does not meet one of the above classifications (assuming the formation is tanks, etc.)
  • Otherwise no special bonus is preferred and a formation is assumed to be INF or STA and given any remaining commanders

Skills like GC Offense, Defense, Training, Logistics are useful for nearly all formation types and do not need specialization rules. GC occupation can be neglected.

Yes... I think that could work pretty well and I'm not sure if this is not already the case or not... but it seem to me most of the time that they are randomly put in charge of formations but I can be wrong.

There also are the Tactical skill which should be applied to STO formations, but this skill seem super rare and it also is not in the sorting list for some reason so perhaps it does not work properly. I think the Tactical skill should be more common for STO formations.

As far as I can tell it is random aside from a check on GC Command which is to be removed. If it's not Steve can feel free to correct me and give us all peace of mind.

I don't think I've ever yet seen the Tactical skill show up on a ground commander even once, though I have heard of it, so I discounted it. Of course if it does exist STOs should receive Tactical commanders with a top priority as they are after all the first line of ground defense for a colony.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 15, 2021, 03:27:24 PM
I also thin it would be nice if we could give each formation a primary and secondary choice of skill? Not sure how commanders are pucked at the moment for different formations.

This could probably work automatically, similar to naval auto-assign, by simply applying special cases based on the type of the single largest formation element (by total weight). E.g. in a 5,000-ton formation with 3,000 tons of INF+PW and 2,000 tons of LVH+CAP the formation is typed as "infantry".

Suggested bonuses to consider would be:
  • If the major element has a STO weapon, no commander should be assigned
  • Artillery bonus if the major element has a bombardment weapon
  • AA bonus if the major element is an AA weapon
  • PRD/SRV/XEN bonus if blah blah blah...
  • Manoeuvre bonus if the major element of the formation is a Vehicle type which does not meet one of the above classifications (assuming the formation is tanks, etc.)
  • Otherwise no special bonus is preferred and a formation is assumed to be INF or STA and given any remaining commanders

Skills like GC Offense, Defense, Training, Logistics are useful for nearly all formation types and do not need specialization rules. GC occupation can be neglected.

Yes... I think that could work pretty well and I'm not sure if this is not already the case or not... but it seem to me most of the time that they are randomly put in charge of formations but I can be wrong.

There also are the Tactical skill which should be applied to STO formations, but this skill seem super rare and it also is not in the sorting list for some reason so perhaps it does not work properly. I think the Tactical skill should be more common for STO formations.

As far as I can tell it is random aside from a check on GC Command which is to be removed. If it's not Steve can feel free to correct me and give us all peace of mind.

I don't think I've ever yet seen the Tactical skill show up on a ground commander even once, though I have heard of it, so I discounted it. Of course if it does exist STOs should receive Tactical commanders with a top priority as they are after all the first line of ground defense for a colony.

I have one in my current game, but I generated a test in another where I have 1000 ground commanders with no Tactical skill in sight... so it is weird?!?
Title: Re: C# Suggestions
Post by: serger on February 15, 2021, 03:35:58 PM
There were 3 ground commanders with Tactical skill (10, 5 and 5%) in my last compaign, and all of them but one aquired it in STO duty.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 15, 2021, 03:50:02 PM
Sounds like it may be gained through experience but is missing from the random skill assignment when a new leader is generated. Maybe this is a bug?
Title: Re: C# Suggestions
Post by: liveware on February 16, 2021, 07:11:39 AM
I would like to suggest changing the research point (RP) cost for ground force headquarters units be changed to scale with the square root of command size instead of the current (linear?) model. I think the current model makes large command units prohibitively difficult to research, field, and upgrade. If scaled with SQRT of command size small HQ units would not be drastically different than they are now but large HQ units would be much less expensive.
Title: Re: C# Suggestions
Post by: clew on February 16, 2021, 09:07:18 AM
Can you bring back the "Destroy Salvo" button? As it stands, mines and buoys aren't the most useful because you can't remove or replace them once laid.
Title: Re: C# Suggestions
Post by: serger on February 16, 2021, 10:42:50 AM
I would like to suggest changing the research point (RP) cost for ground force headquarters units be changed to scale with the square root of command size instead of the current (linear?) model.
I'd say the game will benefit if all research point costs of components/weapons will be SQRT or even LOG2 from the size.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 16, 2021, 11:18:35 AM
I would like to suggest changing the research point (RP) cost for ground force headquarters units be changed to scale with the square root of command size instead of the current (linear?) model. I think the current model makes large command units prohibitively difficult to research, field, and upgrade. If scaled with SQRT of command size small HQ units would not be drastically different than they are now but large HQ units would be much less expensive.

Even just making HQ elements cost the same as every other element i.e. tonnage * armor / 50 would be a huge improvement. There is no reason why the ability to command a large number of troops, a capability mankind has had since at least the 19th century depending how you want to mark things and certainly has in abundance by the present day, should have a higher research cost than a cutting-edge ion engine.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 16, 2021, 01:18:48 PM
I would like to suggest changing the research point (RP) cost for ground force headquarters units be changed to scale with the square root of command size instead of the current (linear?) model.
I'd say the game will benefit if all research point costs of components/weapons will be SQRT or even LOG2 from the size.

Yes... pick one "standard" size and it goes from there. It is not balanced for really small components to cost nearly nothing and then super large ones to be so expensive you would never ever consider them at all.

This is very noticeable by things like engines and sensors in particular but even for weapons this makes some sense as a small weapon should probably be more expensive to research and really large ones cheaper.

I'm not to fond of the linear research rates in general... for me this also goes for assigned labs to be honest... I would like them to have diminished returns as well, but that is a different question. This would help bridge the gap between weaker and stronger empires to some degree.
Title: Re: C# Suggestions
Post by: TMaekler on February 16, 2021, 04:39:05 PM
The Auto-Refit routine should not auto pick ships that are in a fleet that has an order list. It grabbed one of my transports which was loading cargo and then the fleet couldn't move.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 16, 2021, 04:47:22 PM
Yes... pick one "standard" size and it goes from there. It is not balanced for really small components to cost nearly nothing and then super large ones to be so expensive you would never ever consider them at all.

This is very noticeable by things like engines and sensors in particular but even for weapons this makes some sense as a small weapon should probably be more expensive to research and really large ones cheaper.

I'm not to fond of the linear research rates in general... for me this also goes for assigned labs to be honest... I would like them to have diminished returns as well, but that is a different question. This would help bridge the gap between weaker and stronger empires to some degree.

Personally I do not mind the linear costs in general, though I don't usually play with very slow research speeds so that may color my perceptions. Certainly I would not object to a square-root reformulation although I think logarithmic is more problematic than is worth it.

However, I do think that a few small tweaks to specific component research costs would solve most of the big issues, aside from engines. Jump Drives for example actually scale as size^1.8 which is why large jump drives are so ridiculously expensive, and while they are a critical component I don't think having a prohibitive research cost adds anything to the game as the major opportunity cost is always the lost tonnage aboard any ship which carries one. The other big example is ground unit HQ elements which have horribly outsized research costs compared to every other ground element, this has been discussed numerous times. Simply bringing these components into line with the other components/elements in the game will solve a lot of problems without requiring a wholesale rebalancing of the tech tree - less work for Steve, but still many benefits for all of us I think.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 16, 2021, 05:01:00 PM
Yes... pick one "standard" size and it goes from there. It is not balanced for really small components to cost nearly nothing and then super large ones to be so expensive you would never ever consider them at all.

This is very noticeable by things like engines and sensors in particular but even for weapons this makes some sense as a small weapon should probably be more expensive to research and really large ones cheaper.

I'm not to fond of the linear research rates in general... for me this also goes for assigned labs to be honest... I would like them to have diminished returns as well, but that is a different question. This would help bridge the gap between weaker and stronger empires to some degree.

Personally I do not mind the linear costs in general, though I don't usually play with very slow research speeds so that may color my perceptions. Certainly I would not object to a square-root reformulation although I think logarithmic is more problematic than is worth it.

However, I do think that a few small tweaks to specific component research costs would solve most of the big issues, aside from engines. Jump Drives for example actually scale as size^1.8 which is why large jump drives are so ridiculously expensive, and while they are a critical component I don't think having a prohibitive research cost adds anything to the game as the major opportunity cost is always the lost tonnage aboard any ship which carries one. The other big example is ground unit HQ elements which have horribly outsized research costs compared to every other ground element, this has been discussed numerous times. Simply bringing these components into line with the other components/elements in the game will solve a lot of problems without requiring a wholesale rebalancing of the tech tree - less work for Steve, but still many benefits for all of us I think.

Yes... although I think Jump Drives is a good example on a research path that I like as it is not linear for a reason, this work really well.

For engines I generally just think that small engines should be more expensive and really big engines a bit less expensive. Larger engines are not that good for their cost in research most of the time.

For sensors I definitely want really small sensors to be more expensive because small sensors are very effective now and really large sensors are prohibitively expensive for what they are worth, especially in terms of research. An active sensor larger than size five I generally find to be very expensive for what you can do with it.

Sure... I almost always play with 10-20% tech rate so differences in tech cost are quit significant.
Title: Re: C# Suggestions
Post by: liveware on February 16, 2021, 05:30:58 PM
Yes... pick one "standard" size and it goes from there. It is not balanced for really small components to cost nearly nothing and then super large ones to be so expensive you would never ever consider them at all.

This is very noticeable by things like engines and sensors in particular but even for weapons this makes some sense as a small weapon should probably be more expensive to research and really large ones cheaper.

I'm not to fond of the linear research rates in general... for me this also goes for assigned labs to be honest... I would like them to have diminished returns as well, but that is a different question. This would help bridge the gap between weaker and stronger empires to some degree.

Personally I do not mind the linear costs in general, though I don't usually play with very slow research speeds so that may color my perceptions. Certainly I would not object to a square-root reformulation although I think logarithmic is more problematic than is worth it.

However, I do think that a few small tweaks to specific component research costs would solve most of the big issues, aside from engines. Jump Drives for example actually scale as size^1.8 which is why large jump drives are so ridiculously expensive, and while they are a critical component I don't think having a prohibitive research cost adds anything to the game as the major opportunity cost is always the lost tonnage aboard any ship which carries one. The other big example is ground unit HQ elements which have horribly outsized research costs compared to every other ground element, this has been discussed numerous times. Simply bringing these components into line with the other components/elements in the game will solve a lot of problems without requiring a wholesale rebalancing of the tech tree - less work for Steve, but still many benefits for all of us I think.

Yes... although I think Jump Drives is a good example on a research path that I like as it is not linear for a reason, this work really well.

For engines I generally just think that small engines should be more expensive and really big engines a bit less expensive. Larger engines are not that good for their cost in research most of the time.

For sensors I definitely want really small sensors to be more expensive because small sensors are very effective now and really large sensors are prohibitively expensive for what they are worth, especially in terms of research. An active sensor larger than size five I generally find to be very expensive for what you can do with it.

Sure... I almost always play with 10-20% tech rate so differences in tech cost are quit significant.

Most of what you are talking about could be solved using a RP=SQRT(size) methodology (i.e. small things are relatively expensive and big things are less so). This has the advantage of being simple and not terribly different the the current implementation.

If you wanted to make things REALLY interesting, I would suggest using a variation of RP = e^(size)*(sin(2*pi*size)+size). See here for plot of this function: https://www.wolframalpha.com/input/?i=e%5E%28x%29*%28sin%282*pi*x%29%2Bx%29 (https://www.wolframalpha.com/input/?i=e%5E%28x%29*%28sin%282*pi*x%29%2Bx%29)

This would make successive generations of research proceed in a rather nonlinear fashion, however later generations of research would be dramatically more expensive (and presumably better) than early generations. However successive generations of research would not be linearly 'better' or more expensive than previous generations.

NOTE: You could wrap the aforementioned RP='a bunch of math' thing in a SQRT function also, but that introduces some divide-by-zero singularities. These can be avoided by careful choice of RP values but I didn't want to go off the deep end on that tangent. An interesting variation is RP = sqrt(e^(size))*(sin(2*pi*size)+size)
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 16, 2021, 07:10:25 PM
Most of what you are talking about could be solved using a RP=SQRT(size) methodology (i.e. small things are relatively expensive and big things are less so). This has the advantage of being simple and not terribly different the the current implementation.

If you wanted to make things REALLY interesting, I would suggest using a variation of RP = e^(size)*(sin(2*pi*size)+size). See here for plot of this function: https://www.wolframalpha.com/input/?i=e%5E%28x%29*%28sin%282*pi*x%29%2Bx%29 (https://www.wolframalpha.com/input/?i=e%5E%28x%29*%28sin%282*pi*x%29%2Bx%29)

This would make successive generations of research proceed in a rather nonlinear fashion, however later generations of research would be dramatically more expensive (and presumably better) than early generations. However successive generations of research would not be linearly 'better' or more expensive than previous generations.

NOTE: You could wrap the aforementioned RP='a bunch of math' thing in a SQRT function also, but that introduces some divide-by-zero singularities. These can be avoided by careful choice of RP values but I didn't want to go off the deep end on that tangent. An interesting variation is RP = sqrt(e^(size))*(sin(2*pi*size)+size)

I generally don't like the idea of using logs, exponentials, or anything else transcendental to determine RP as a function of size (or another size-like parameter depending on the tech under discussion). From the player-facing side they are just not intuitive or easy to noodle around in your head. Linear of course is very simple. SQRT is a bit more complicated but still simple enough to do head math - if I make an engine 4x as large it will cost 2x the RP, easy enough. With LOG, EXP, etc. there is no easy way to think of it mentally, while simple rational functions can be reasoned with.

From the developer side it is also quite difficult to balance these functions across a very wide range of sizes, tech levels, and so on. LOG in particular is difficult because it has a sharp drop to negative infinity near zero, a fairly small useful region of variation, and then for large arguments it barely changes even for wide differences in size. It is also a problem I think that whatever balance "fit" you use will work only for the existing data set, so to speak - if Steve decided for example to increase maximum engine or sensor size all component research costs would need to be redone. Something like SQRT doesn't really need to be fitted as it behaves the same over the entire range as long as you can't go to zero which is generally true for components.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on February 16, 2021, 07:16:05 PM
LOG in particular is difficult because it has a sharp drop to negative infinity near zero

No matter the field, if you think about it hard enough you end up doing calculus.

This pleases me.
Title: Re: C# Suggestions
Post by: liveware on February 16, 2021, 10:14:11 PM
Most of what you are talking about could be solved using a RP=SQRT(size) methodology (i.e. small things are relatively expensive and big things are less so). This has the advantage of being simple and not terribly different the the current implementation.

If you wanted to make things REALLY interesting, I would suggest using a variation of RP = e^(size)*(sin(2*pi*size)+size). See here for plot of this function: https://www.wolframalpha.com/input/?i=e%5E%28x%29*%28sin%282*pi*x%29%2Bx%29 (https://www.wolframalpha.com/input/?i=e%5E%28x%29*%28sin%282*pi*x%29%2Bx%29)

This would make successive generations of research proceed in a rather nonlinear fashion, however later generations of research would be dramatically more expensive (and presumably better) than early generations. However successive generations of research would not be linearly 'better' or more expensive than previous generations.

NOTE: You could wrap the aforementioned RP='a bunch of math' thing in a SQRT function also, but that introduces some divide-by-zero singularities. These can be avoided by careful choice of RP values but I didn't want to go off the deep end on that tangent. An interesting variation is RP = sqrt(e^(size))*(sin(2*pi*size)+size)

I generally don't like the idea of using logs, exponentials, or anything else transcendental to determine RP as a function of size (or another size-like parameter depending on the tech under discussion). From the player-facing side they are just not intuitive or easy to noodle around in your head. Linear of course is very simple. SQRT is a bit more complicated but still simple enough to do head math - if I make an engine 4x as large it will cost 2x the RP, easy enough. With LOG, EXP, etc. there is no easy way to think of it mentally, while simple rational functions can be reasoned with.

From the developer side it is also quite difficult to balance these functions across a very wide range of sizes, tech levels, and so on. LOG in particular is difficult because it has a sharp drop to negative infinity near zero, a fairly small useful region of variation, and then for large arguments it barely changes even for wide differences in size. It is also a problem I think that whatever balance "fit" you use will work only for the existing data set, so to speak - if Steve decided for example to increase maximum engine or sensor size all component research costs would need to be redone. Something like SQRT doesn't really need to be fitted as it behaves the same over the entire range as long as you can't go to zero which is generally true for components.

Maybe I went a little overboard. RP=SQRT(size) is good enough for me.
Title: Re: C# Suggestions
Post by: liveware on February 16, 2021, 10:14:34 PM
LOG in particular is difficult because it has a sharp drop to negative infinity near zero

No matter the field, if you think about it hard enough you end up doing calculus.

This pleases me.

But this would be better :-)
Title: Re: C# Suggestions
Post by: Desdinova on February 17, 2021, 12:00:24 PM
With this update being pretty fighter-focused, could we get the crew requirements once again scaled with deployment time as in VB6, so that fighters with deployment times measured in hours don't have like 30 crew members and the associated habitation space requirements?
Title: Re: C# Suggestions
Post by: Steve Walmsley on February 17, 2021, 12:24:36 PM
With this update being pretty fighter-focused, could we get the crew requirements once again scaled with deployment time as in VB6, so that fighters with deployment times measured in hours don't have like 30 crew members and the associated habitation space requirements?

It is already scaled with deployment time.

Accommodation = Personnel * (Planned Deployment ^ (1/3));
Title: Re: C# Suggestions
Post by: kilo on February 18, 2021, 01:38:04 PM
Is it possible to change the way sensors and fire control systems work for STOs? Right now you can choose between range x4 speed x1 or vice versa. This is pretty restrictive. On top of that you have to use a single weapon beam fire control and cannot develop fire controls for a battery of guns.
These single weapon beam fire control restriction can even lead to situations in which the fire control + sensor is more expensive than it's carronade.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 18, 2021, 02:00:49 PM
Is it possible to change the way sensors and fire control systems work for STOs? Right now you can choose between range x4 speed x1 or vice versa. This is pretty restrictive. On top of that you have to use a single weapon beam fire control and cannot develop fire controls for a battery of guns.

I would suggest that the restricted nature is a balance concern as much as anything. STOs are already quite strong due to their +25% range boost and benefitting from fortification level. The current restrictive STO fire controls allow you to build either a long-range anti-ship weapon which is limited by racial tracking speed (probably reducing accuracy by 25% to 50% depending on your tech and the enemy fleet speed), or a short-range PD weapon. Both have limitations which helps keep STOs from completely outclassing orbital platforms for example.

Quote
These single weapon beam fire control restriction can even lead to situations in which the fire control + sensor is more expensive than it's carronade.

Carronades are supposed to be quite cheap so this isn't necessarily a problem. Same applies for e.g. 10cm railguns although those make quite poor STOs due to lack of turret.
Title: 1.13 ground formation suggestions
Post by: Polestar on February 18, 2021, 04:27:27 PM
I'm loving the changes in 1.13 for ground formations, some of the juiciest bits in what's going to be an especially heavy-hitting Aurora update. In fact, they are so juicy as to give me hope that a few other issues might be considered sooner rather than later.

1. As of fairly recently, ground commanders didn't apply any bonuses to any subordinate formations. [ed: to make it clear, this is not a bug report, merely one of an unimplemented feature] So there's never been much point - aside from role-play - to building a 250k HQ, whether the research cost be 5k or 1.5k, because such a large HQ provides only (expensive) automatic supply distribution and mouse-click reduction. More than anything else, I hope that 1.13 lets us field ground formation hierarchies that actually provide bonuses.

2. Large HQs continue to be extremely expensive to build. Even when fully hierarchical commander bonuses are implemented, we'll still face the problem that, in order to actually field a formation hierarchy, we have to pay for HQs at every level of command, and we still have to up-armor or duplicate HQs, at every level, in order to avoid losing commanders in battle. Once bonuses from superior commanders are implemented, we will also have to avoid breaking the chain of command at any level and thus lose those bonuses. This gets pricey, fast. So, request to either make HQs (especially large ones) a lot less expensive to build, or make them much less like to be targeted and destroyed in battle, or both.

A more radical suggestion would be to remove the HQ type altogether and have the assigned officer, plus (in higher-level formations) a number of generic officers taken from the national pool to serve as staff, provide both the command span and the command bonuses. If the formation type is too small to be commanded by an officer of the lowest rank modeled by the game (by default, a major), and an officer has not been directly assigned anyway, then the simplest thing to do is to just check to see if that formation is in a hierarchy, find the lowest-ranking officer in direct line of command, and apply that officer's full bonuses, treating that officer as though they were also in direct command of each subordinate formation.

This would - finally - get players what many of us keep trying to do: include formations below the size commanded by a major - squads, platoons, and companies - and do so without gimping their battle effectiveness.


3. Aurora 1.13 is going to make some great game balance changes, and so perhaps a few more might be added to those considered:
3a. Several players have requested that heavy weapons get better at targeting suitable opponents. I heartily second these requests for both logical and game balance reasons.
3b. Heavy A isn't only more flexible than light AA, it is also considerably more cost-effective. It kills more fighters per unit cost and unit size. I propose that it should instead be somewhat less cost-effective, and light AA be especially cost-effective for defending a particular formation from air attack.
3c. Infantry armor is a really good buy at present (assuming armor tech is at least equal to the opposition's weapon tech). Consider increasing the cost a little bit, or applying a small disadvantage.

4. Turning to quality of life issues, I'm very glad that managing large numbers of similar formations (of a given template) is to get easier in 1.13. Another change I'd love to see is the ability to set a default field position for each formation template.

5. Finally, turning to the "gotchas" that the current ground formation system sets up for unwary players, I'll make a plea to consider these:
5a. Artillery only fires if the formation it is in is set to support another formation [I think this is still true - apologies if not]. Artillery should fire in any case, or at least it should be clearly indicated that, unless the player does something, it will not fire.
5b. The "Avoid Combat" checkbox is always waiting to trip you up. Do not apply it to AA or artillery; they will both hit in all forms of combat much less often. Request: please remove the "Avoid Combat checkbox and always apply it to, and only to, the appropriate unit types.
5c. Morale bonuses disappear on the next build phase if the formation's commander lacks sufficient Training bonuses. This plays very poorly with automated assignments! Request: please either change the name of this bonus, or have unit morale decrease far more slowly. If the second option is decided on, then I would recommend reducing the power of this bonus by roughly half, because at present it is - as long as the commanding officer is not replaced - considerably more powerful than either Offense or Defence (as it affects both chance to hit and chance to be hit).


Many thanks, Steve, for your continuous improvement of your masterwork. With every version of Aurora 4X and Aurora C#, your ability to recreate Warhammer 40K and other cosmos has becomes more and more impressive, and I've been glad to ride along!
Title: Re: C# Suggestions
Post by: Desdinova on February 18, 2021, 05:03:46 PM
It'd be really nice to have industrial command & control modules for terraforming and mining ships, call it a "mining control center" or something. As it is, you either leave miner and terraformer commands to junior officers, who have a very high turnover, or have to micromanage by manually promoting officers with high mining & terraforming bonuses.
Title: Re: 1.13 ground formation suggestions
Post by: nuclearslurpee on February 18, 2021, 05:58:42 PM
This would - finally - get players what many of us keep trying to do: include formations below the size commanded by a major - squads, platoons, and companies - and do so without gimping their battle effectiveness.

I love 95% of this comment, but I do want to point out that this suggested change will not really make sub-company size formations much more viable. The major limits on formation size are those due to micromanagement (nothing to be done, sadly, unless we get the feature to build hierarchies which I doubt) and breakthrough mechanics - very small formations simply break too easily allowing a larger opposing formation extra chances to deal bonus damage.


Quote
3c. Infantry armor is a really good buy at present (assuming armor tech is at least equal to the opposition's weapon tech). Consider increasing the cost a little bit, or applying a small disadvantage.

Power armor is quite good but I'm not sure it needs any nerf. The advantages of light armored units (LVH/STA) are plentiful enough compared to infantry - more HP than even gene modded infantry, ability to mount medium-size weapons, and better exploitation/breakthrough chance to name a few. Later in the game INF with full armor and HP mods is more tonnage-efficient in many cases but also much more expensive per ton due to the cost multiplier of HP mods, so I think the balance is still there.

Quote
5b. The "Avoid Combat" checkbox is always waiting to trip you up. Do not apply it to AA or artillery; they will both hit in all forms of combat much less often. Request: please remove the "Avoid Combat checkbox and always apply it to, and only to, the appropriate unit types.

I suspect this is done manually mainly as there's not always a clear answer as to what type an element "should" be. For example a command tank with HQ+AV could be set to avoid combat to keep the HQ alive, or not to bring another gun to bear. However I think a useful compromise would be if the checkbox is only available if an element would contain a non-combat weapon (HQ, LOG, FFD, etc.) as this avoids confusion for units with artillery, AA, etc.

It'd be really nice to have industrial command & control modules for terraforming and mining ships, call it a "mining control center" or something. As it is, you either leave miner and terraformer commands to junior officers, who have a very high turnover, or have to micromanage by manually promoting officers with high mining & terraforming bonuses.

Would this work like the command modules for ships already in the game? If so I don't think this solves the problem, since commander turnover will still happen and the only change is to what position a commander is assigned.
Title: Re: C# Suggestions
Post by: liveware on February 18, 2021, 06:14:18 PM
It'd be really nice to have industrial command & control modules for terraforming and mining ships, call it a "mining control center" or something. As it is, you either leave miner and terraformer commands to junior officers, who have a very high turnover, or have to micromanage by manually promoting officers with high mining & terraforming bonuses.

What I do is stick mining/terraforming platforms in a separate industrial admin command. You don't get the auto-assign niceness but keeping admin commands stocked with good commanders isn't a huge burden really. I also usually build a huge number of mining/terraforming platforms (if I build them at all) in which case having a junior officer on each on is usually not practical.

For example I would set up an admin command like "Venus Orbital Terraforming Complex" and would then assign something like 25 terraforming space stations to it. The admin command gets a commander, but the space stations usually don't because there are too many for my academies to keep up with. I prioritize keeping my military ships fully staffed with commanders so if the commercial sector falls by the wayside I don't worry too much about it.
Title: Re: C# Suggestions
Post by: pwhk on February 18, 2021, 06:45:24 PM
So with RP changes large ship are even more practical now. But... able to build large ships quickly always irk me.
As one play with reduced research speed games, shipyards can often grow very large while waiting for research to finish. Same goes to facilities constructions too, later just find myself having too many construction factories to think of what to build.

Can we have an option to set the factor for shipyard build speed, shipyard modification speed and perhaps facility construction speed, like the one we have for research speed and terraforming speed?
Title: Re: C# Suggestions
Post by: liveware on February 18, 2021, 07:22:18 PM
I always assumed that the shipyard production rate was also affected by the construction speed multiplier, but I have never actually tested this.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 18, 2021, 07:45:52 PM
I always assumed that the shipyard production rate was also affected by the construction speed multiplier, but I have never actually tested this.

Even if so, this is I believe a race-specific modifier so it will set the player behind the NPRs which may not be quite what is desired.
Title: Re: C# Suggestions
Post by: liveware on February 18, 2021, 07:54:09 PM
I always assumed that the shipyard production rate was also affected by the construction speed multiplier, but I have never actually tested this.

Even if so, this is I believe a race-specific modifier so it will set the player behind the NPRs which may not be quite what is desired.

I'm pretty sure there is a global modifier and also a separate racial modifier.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 18, 2021, 08:44:03 PM
I always assumed that the shipyard production rate was also affected by the construction speed multiplier, but I have never actually tested this.

Even if so, this is I believe a race-specific modifier so it will set the player behind the NPRs which may not be quite what is desired.

I'm pretty sure there is a global modifier and also a separate racial modifier.

Nope. Global game settings only have Difficulty, Research, Terraforming, and Survey modifiers. You might be thinking of Construction Cycle Time which is not a difficulty modifier.

Racial settings include Population Density, Population Growth, Research Rate, and Factory Production - only the research rates overlap between both settings groups.
Title: Re: C# Suggestions
Post by: QuakeIV on February 18, 2021, 09:10:51 PM
I would also personally prefer if shipyard size and construction speed were separate characteristics.

I think the size of the ship vs how quickly you want to be able to build it should be a strategy choice (for instance I could then plan how quickly ships are built so that shipyards don't spend as significant of a time idle).

e: One way to maintain gameplay balance would be to start shipyards as they are now with 1/2 of their BP dedicated to build capacity and 1/2 to slipway size.  So for instance, if you expanded your shipyard from 1000 ton capacity to 2000 ton, that operation would cost half of what it does now, but the BP/cycle would be half of what it is now (and ships would take twice as long to build as now) until you made a corresponding investment to build rate (at which point it would be equivalent to what we have now again).
Title: Re: C# Suggestions
Post by: liveware on February 18, 2021, 09:35:09 PM
I always assumed that the shipyard production rate was also affected by the construction speed multiplier, but I have never actually tested this.

Even if so, this is I believe a race-specific modifier so it will set the player behind the NPRs which may not be quite what is desired.

I'm pretty sure there is a global modifier and also a separate racial modifier.

Nope. Global game settings only have Difficulty, Research, Terraforming, and Survey modifiers. You might be thinking of Construction Cycle Time which is not a difficulty modifier.

Racial settings include Population Density, Population Growth, Research Rate, and Factory Production - only the research rates overlap between both settings groups.

You are quite right!
Title: Re: C# Suggestions
Post by: Ektor on February 18, 2021, 09:38:24 PM
I'd appreciate if shipyards were more flexible, now that we're talking about it. Many naval shipyards IRL build several types of ship of different sizes and classes. I always have short bursts of intense shipbuilding where I can't seem to have enough capacity, and then long periods where those tens of millions of shipyard workers are just sitting there doing nothing. I think shipyards should just have capacity and slipways, and you could build any ship that was under the capacity, with more efficiency the closest the class size is to shipyard capacity, so you'd need smaller shipyards for your smaller ships and larger ones for your big ships.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 19, 2021, 02:45:04 AM
I would suggest to change the way we can use sensors on missiles and the targeting of missiles on general.

Given that it is relatively easy to guesstimate the amount of missiles you need to fire to either disable, destroy or severally damage a ship then sensors on ships have a very small reason to exist on missiles outside mines. Having to use way-points to calculate where to fire in order for a passive to lock on to enemy ship is just tedious boring work.

Given how expensive and inefficient it is to use sensors on missiles we should be able to target and guide missiles versus passive or actively spotted enemies. When you loose the sensor lock on a target the missile should still travel to the last known coordinate. If you require the sensor lock (passive or active) then the fire-control should be able to direct the missile against the new position again.

If a missile don't have active guidance of a missile fire-control. It either is out of range or there are no passive or active sensor on the target the missile will use it's onboard sensor to target anything that it can see... if not it just travel to the last know coordinate if its intended target. Missile should not even need sensors to require a new target if their initial target is destroyed before it arrives... the fire-control could very well use the random mechanic to target a new ship as long as you have some sensor on the target (passive or active) and a fire-control is guiding the missile.
Sensor on the missile should probably also give some bonus on the to-hit function of missiles as well, that just seem fair. To be frank, missiles without sensors should have trouble hitting anything to be fair.

In my opinion this would make the stealth game of missile combat allot more interesting and using inefficient large long range missiles with sensors more meaningful. It would give us more options in terms of missile warfare. When we look at the economy of scale large missiles with sensors are just really bad, we should make them more viable. It also would be more fun if missiles just suddenly appear on the radars and we had no clue there even was an enemy out there.

Perhaps the AI will not be able to take full advantage of this, but there are so many other ways to abuse AI designs and mechanics in the game I don't think that matters much, I'm more interested in this when playing with multiple factions. Right now I can fire against a point in space and I also can make sure the opponent end up inside the envelop of the missile sensors to simulate this, but I really don't think that we should have to do that and it also make sense that missiles worked like this.
Title: Re: C# Suggestions
Post by: SevenOfCarina on February 19, 2021, 11:26:15 PM
I'm not sure if this has been suggested before, but can we please have a "No Commander" checkbox in the class design tab? Commanders seem to get assigned to fighter CO posts before XO/TO/CE posts on larger vessels regardless of class priority, and I'd rather not use up 90% of my officer corps crewing swarms of expendable fighters.
Title: Re: C# Suggestions
Post by: kilo on February 20, 2021, 01:28:39 AM
@Jorgen

Missiles are completely OP right now, given that everyone is using reduced-size or even box launchers. Requiring sensors would have a terrible side effect when it comes to AMMs, as these would have to bring a .25 size active sensor on top of the .25 requirement for ECCM. Taken into account that the sensors need a power plant we end up with horribly ineffective AMMs, as more than half of their tonnage is electronics.
Don't get me wrong. It would be a fantastic change for ASMs to be able to fire at enemy ships without having to rely upon active sensors, but Steve would have to rework the electronic warfare or the detection side of combat to make it counterbalance it.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 20, 2021, 06:22:16 AM
@Jorgen

Missiles are completely OP right now, given that everyone is using reduced-size or even box launchers. Requiring sensors would have a terrible side effect when it comes to AMMs, as these would have to bring a .25 size active sensor on top of the .25 requirement for ECCM. Taken into account that the sensors need a power plant we end up with horribly ineffective AMMs, as more than half of their tonnage is electronics.
Don't get me wrong. It would be a fantastic change for ASMs to be able to fire at enemy ships without having to rely upon active sensors, but Steve would have to rework the electronic warfare or the detection side of combat to make it counterbalance it.

That is NO problem because I already use both in my own multi-faction campaign with no issues... I do have some limitation on how box launchers can be fitted to ships and the amount of fire-controls as well. It just make larger missiles more viable and larger AMM is also needed most if the time. In my campaign I MUST fit at least .25 electronic on AMM if they are to engage something with better range than a size 1 resolution 1 sensor (against size 6 missile) can see them for example, any missile that engage something beyond a size 1 resolution 100 must have at least .50 electronics. This work just fine... (I have also increased the yield level one step to compensate a bit for less force in missiles otherwise). In addition to this I also flattened the missile agility technology to be within 80-130 as this technology have too much of an impact on the effectiveness on AMM. So early AMM is allot more viable.

As missiles get slightly larger there is no problem with larger AMM as well either. I also don't see a reason why the active on AMM could not be smaller than .25... I think it should be able to be smaller, there could be some new rules for how this would work.

If you cram in all the box launched missiles on your ships that is on you to abuse the game mechanic. I want this functionality so I can use sensors without micromanagement with way-point which is just a weirdly annoying way to use sensors in a way they should be able to be used.

I also would not say that missiles are OP... it is the box-launcher mechanic that is OP and it is on the player if they abuse it until Steve decide to change things. I have already outlined in other threads why using massed box launchers on big ships are unrealistic in the first place.  ;)

I think the game would do well with a surface mechanic and that there is limited space there as well for certain components as well as shock damage would be way more likely to happen to these components, even that it require much less damage to the armour in order to damage these exposed components. If the normal shock chance is damage/HS in size these component would be more like damage*4/HS in size or something.
Title: Re: C# Suggestions
Post by: Droll on February 20, 2021, 11:44:26 AM
I also would not say that missiles are OP... it is the box-launcher mechanic that is OP and it is on the player if they abuse it until Steve decide to change things. I have already outlined in other threads why using massed box launchers on big ships are unrealistic in the first place.  ;)

Even reduced size spam is very powerful thanks to how little fire rate matters on ASM launchers. On the other hand, AMM launchers can't take advantage of reduced size as much which gives somewhat of an advantage to missiles.

I do somewhat understand why missiles are tactically OP though as they are the only weapon type that creates a logistical and strategic burden on the user. But beam fleets have always felt weak compared to their missile counterparts as the missile ships can fire without fear of retaliation.
Title: Re: C# Suggestions
Post by: SpaceMarine on February 20, 2021, 11:53:50 AM
[quote author=Jorgen_CAB link=topic=10640.msg149258#msg149258 date=1613823736
I also would not say that missiles are OP... it is the box-launcher mechanic that is OP and it is on the player if they abuse it until Steve decide to change things. I have already outlined in other threads why using massed box launchers on big ships are unrealistic in the first place.  ;)

Even reduced size spam is very powerful thanks to how little fire rate matters on ASM launchers. On the other hand, AMM launchers can't take advantage of reduced size as much which gives somewhat of an advantage to missiles.

I do somewhat understand why missiles are tactically OP though as they are the only weapon type that creates a logistical and strategic burden on the user. But beam fleets have always felt weak compared to their missile counterparts as the missile ships can fire without fear of retaliation.
[/quote]

On the last part this isnt completely true as for every weapon activation (thats not for PD) theres a 1% chance of a beam weapon breaking same with a missile launcher, while this wont break the bank it can in certain circumstances such as orbital bombardment where three days of bombing can burn through tens of thousands of MSP
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 20, 2021, 02:28:11 PM
[quote author=Jorgen_CAB link=topic=10640.msg149258#msg149258 date=1613823736
I also would not say that missiles are OP... it is the box-launcher mechanic that is OP and it is on the player if they abuse it until Steve decide to change things. I have already outlined in other threads why using massed box launchers on big ships are unrealistic in the first place.  ;)

Even reduced size spam is very powerful thanks to how little fire rate matters on ASM launchers. On the other hand, AMM launchers can't take advantage of reduced size as much which gives somewhat of an advantage to missiles.

I do somewhat understand why missiles are tactically OP though as they are the only weapon type that creates a logistical and strategic burden on the user. But beam fleets have always felt weak compared to their missile counterparts as the missile ships can fire without fear of retaliation.
[/quote]

For what it's worth, Steve has gone on record saying that he feels missiles are underpowered if anything right now...granted I'm not certain how much he accounts for the box launcher spam in that assessment, which I certainly agree is ridiculous if a player chooses to exploit it.

I've said before, a significant issue with missile vs. beam balance is that they do not scale with each other across all tech levels. Discounting ECM vs. ECCM, missiles have really only one way to improve their ability to avoid PD which is to increase speed. This can be done principally by improving the engine tech as well as the maximum boost tech, with side-effect gains from improved agility and warhead techs. However, the boost tech line ends fairly early with the 3.0x modifier tech capping out at I believe 15k RP. So for a race that invests into missiles, speed increases roughly quadratically* with tech up until around MP drive tech, and then only linearly* after that. Given that most players seem to start with ion drives this is quite early in the game.

*Disclaimer: "quadratic" and "linear" here are simplifications, since the actual tech levels do not themselves increase linearly, but for the sake of argument this should be clear enough.

On the other hand point defense tech improves at more or less the same kind of rate throughout the game. AMMs for example gain the same benefits of any other missiles, plus improved hit chances due to agility tech and so they will consistently improve relative to ASMs at every tech level. For beam PD the question is more complicated, at a basic level of course capability increase is linear* due to improvements in ship/BC/turret speeds, but generally there are ancillary boosts which give beam PD an increasing edge as tech level increases. All beam PD benefits from the missile tracking bonus which is tied to active sensor tech. Gauss PD also benefits hugely from increases in ROF tech which is probably the largest cause of missile effectiveness drop-off at late-game tech levels.

There's not really an easy solution to this - if one even considers it a problem, which it might not be as having a progressive shift of technology over time is more interesting than a static balance at every tech level. Most any solution would require changing the core mechanics, which Steve generally doesn't like to do it seems.
Title: Re: C# Suggestions
Post by: Droll on February 20, 2021, 04:02:02 PM
On the last part this isnt completely true as for every weapon activation (thats not for PD) theres a 1% chance of a beam weapon breaking same with a missile launcher, while this wont break the bank it can in certain circumstances such as orbital bombardment where three days of bombing can burn through tens of thousands of MSP

Orbital bombardment isn't really a good example to bring up because you'll only be doing that after the enemy has already lost their navy, at which point it's just a matter of time while you ferry supplies back and forth.

On the other hand with missiles when you run out of ammo that directly affects the outcome of the naval engagement, and in my experience you'll already have tons of MSP on board for your beam combat ships to have decent maintenance anyways so you'll never have trouble killing targets before running out of MSP.

There is also the fact that missile ships also suffer weapons failures on their launchers so they need to have logistics for missiles and MSP whereas beamers only have MSP to contend with.
Title: Re: C# Suggestions
Post by: QuakeIV on February 20, 2021, 04:15:47 PM
On the last part this isnt completely true as for every weapon activation (thats not for PD) theres a 1% chance of a beam weapon breaking same with a missile launcher, while this wont break the bank it can in certain circumstances such as orbital bombardment where three days of bombing can burn through tens of thousands of MSP

Orbital bombardment isn't really a good example to bring up because you'll only be doing that after the enemy has already lost their navy, at which point it's just a matter of time while you ferry supplies back and forth.

On the other hand with missiles when you run out of ammo that directly affects the outcome of the naval engagement, and in my experience you'll already have tons of MSP on board for your beam combat ships to have decent maintenance anyways so you'll never have trouble killing targets before running out of MSP.

There is also the fact that missile ships also suffer weapons failures on their launchers so they need to have logistics for missiles and MSP whereas beamers only have MSP to contend with.

Do note that here you are presuming that the enemy will only have one large colony worthy of bombing (that is to say, that they will be obliged to fight to annihilation with their entire navy to prevent it being bombed).  That isn't necessarily actually going to be the case.
Title: Re: C# Suggestions
Post by: Droll on February 20, 2021, 04:22:45 PM
On the last part this isnt completely true as for every weapon activation (thats not for PD) theres a 1% chance of a beam weapon breaking same with a missile launcher, while this wont break the bank it can in certain circumstances such as orbital bombardment where three days of bombing can burn through tens of thousands of MSP

Orbital bombardment isn't really a good example to bring up because you'll only be doing that after the enemy has already lost their navy, at which point it's just a matter of time while you ferry supplies back and forth.

On the other hand with missiles when you run out of ammo that directly affects the outcome of the naval engagement, and in my experience you'll already have tons of MSP on board for your beam combat ships to have decent maintenance anyways so you'll never have trouble killing targets before running out of MSP.

There is also the fact that missile ships also suffer weapons failures on their launchers so they need to have logistics for missiles and MSP whereas beamers only have MSP to contend with.

Do note that here you are presuming that the enemy will only have one large colony worthy of bombing (that is to say, that they will be obliged to fight to annihilation with their entire navy to prevent it being bombed).  That isn't necessarily actually going to be the case.

That still means you have won the engagement for that system as a whole and there aren't any reinforcements coming in - it also means that the system is safe for supply ships to enter and resupply as well.

Also at least for me if I'm bombing a planet for the sake of bombing it I'm using missiles. Beam bombardment only gets used when I've already launched an invasion as support. I think it's incredibly dumb on the players part not to do that otherwise.

Oh and I also use dedicated bombardment ships too so there's that. Orbital bombardment without missiles is incredibly weak in this game and if doing it affects your ability to fight then your doing it wrong.
Title: Re: C# Suggestions
Post by: QuakeIV on February 20, 2021, 05:24:37 PM
Do note that here you are presuming that the enemy will only have one large colony worthy of bombing (that is to say, that they will be obliged to fight to annihilation with their entire navy to prevent it being bombed).  That isn't necessarily actually going to be the case.

That still means you have won the engagement for that system as a whole and there aren't any reinforcements coming in - it also means that the system is safe for supply ships to enter and resupply as well.

Well no, I'm saying that reinforcements might actually be coming if this isn't their home system we are talking about.

It should be possible to do bombardment generally properly without crippling yourself, but its not necessarily reasonable to suppose that either you cannot at all, or that you could do so at your leisure and take your time with it.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 20, 2021, 08:33:18 PM
I think we can agree that if you use full sized launchers then missiles are perhaps a bit under powered, if you use either box launched or smallest reduced sized launchers then they are over powered instead. The main reason is that missiles do so much alpha damage when used in large numbers. This is despite their general cost and logistical hurdles.

My suggestion had nothing to do with missiles being over powered or not... it had to do with targeting using more common sense method so I don't have to use way-points to use passive/active targeting on the missiles themselves as this is a bit tedious to do.

When you play if you simply never abuse the box launcher or reduced sized launchers you will be just fine with game balance. I always make sure ships have a rough "realistic" amount of weapons on them based on their size. The bigger the ship is the less external weapons I put on my ships in relation to their size, this is somewhat realistic and also makes it all quite balanced as well.
Title: Re: C# Suggestions
Post by: TMaekler on February 21, 2021, 03:22:48 AM
When you play if you simply never abuse the box launcher or reduces sized launchers you will be just fine with game balance. I always make sure ships have a rough "realistic" amount of weapons on them based on their size. The bigger the ship is the less external weapons I put on my ships in relation to their size, this is somewhat realistic and also makes it all quite balanced as well.
This is basically true for anything in Aurora. It is not meant to be a game of its own, but rather a tool to tell stories (though we all crave for the game to be as round as it gets  ;D)
Title: Re: C# Suggestions
Post by: TMaekler on February 21, 2021, 04:04:58 AM
Research: Switching research to a different one without losing already queued research one can put the urgent research only up to first place in the queue. Would be a nice QoL if you could switch it with the actual research and put that back into the queue - much like you can do with production.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 21, 2021, 09:21:23 AM
Do note that here you are presuming that the enemy will only have one large colony worthy of bombing (that is to say, that they will be obliged to fight to annihilation with their entire navy to prevent it being bombed).  That isn't necessarily actually going to be the case.

That still means you have won the engagement for that system as a whole and there aren't any reinforcements coming in - it also means that the system is safe for supply ships to enter and resupply as well.

Well no, I'm saying that reinforcements might actually be coming if this isn't their home system we are talking about.

It should be possible to do bombardment generally properly without crippling yourself, but its not necessarily reasonable to suppose that either you cannot at all, or that you could do so at your leisure and take your time with it.

In terms of bombardment you also can build very efficient bombardment cruisers using very cheap slow firing weapons. These would not be terribly good in a beam fight but that is also not their role. You actually can get allot of cheap bombardment out of any such ground support ships. I would likely put such weapons on any serious assault carrier as well.

You also could essentially build them as bombardment platforms and use tugs to get them in place... this seem quite an interesting way to use them. It's basically just a large bombardment station. Might not be the best solution if you approach ground defences with lots of STO.
Title: Re: C# Suggestions
Post by: TMaekler on February 21, 2021, 03:13:46 PM
Message Tags: It would be a nice QoL if we could display certain values in the message system. Something like this for an automated fuel harvest cycle:

"We have transferred all fuel from HV Site Uranus. Our tanks are filled up to %shipfuelpercent%."

I would put such a message into the cycle directly after the harvesters have been emptied. That way I could see if I would have to adjust the speed of the cycle or if that sorium harvester site is beginning to go down. %shipfuelpercent% should be exchanged with the % of fuel the sending ship has ATM. And I could think of many more interesting values I would like to put into messages to make my life easier.
Title: Re: C# Suggestions
Post by: xenoscepter on February 21, 2021, 06:36:09 PM
Vertical Envelopment: (Working Title)

 - The premises itself is fairly simple and straightforward, have Fighters that are equipped with Troop Transport Bays be able to conduct a special Ground Support Mission that I'm going to refer to as "Vertical Envelopment" from this point on. I'm open to a better name. :) This Ground Support Mission allows any Fighter Sized craft with a Troop Transport Bay to give a random formation an extra breakthrough chance when supported by eligible fighters assigned to said mission. The formations to be supported are chosen at random, with each fighter assigned choosing one until all eligible fighters with this mission are assigned. Formations gain a breakthrough chance increase equivalent to the Troop Transport tonnage of all supporting fighters, divided by the largest unit in the formation then multiplied by the number of eligible fighters assigned. Formations with FFD can have fighters assigned to them to provide support for them as per the usual rules for FFD and Ground Support Fighters.

 - The breakthrough chance is applied in it's relative phase, but a fighter assigned to a "Vertical Envelopment" Mission still takes AA fire in the relevant stage. Light AA fire will be taken by the fighter from the formation that was engaged by the formation that the "Vertical Envelopment" support was provided to. Medium AA fire will be taken by the fighter from a formation that was directly supporting the formation that was engaged by the formation that the "Vertical Envelopment" support was provided to. Heavy AA fire will be taken by any fighters taking part in "Vertical Envelopment" Missions regardless of what formations are supported by them, assuming the Heavy AA is in a valid position to fire. A fighter with both a Troop Transport Bay AND at least one Fighter Pod Bay may also fire as if providing CAS during the relevant phase, but will not draw additional AA fire as a result of this.

 - If fighters assigned to a "Vertical Envelopment" Mission have a formation loaded into their Troop Transport Bays, instead of the usual bonus they will provide a breakthrough bonus equal to the tonnage of their largest unit multiplied by the number of units. For the purposes of this calculation, LOG and S-LOG do not count for unit tonnage when determining the largest unit tonnage and are not counted towards the number of units multiplier. Formations assigned to fighters that themselves are assigned to a "Vertical Envelopment" Mission are treated as part of the formation that they are supporting for the purposes of ground combat and can take casualties as such. These formations also use supply AND provide supply during that phase as if they were a part of the formation that the fighter they are assigned to is supporting.

 - Fighters destroyed during a "Vertical Envelopment" mission will also automatically result in the destruction of any formations that they were carrying. I would not be against some kind of derived percentage of survival with the surviving remnants treated as normal ground combatants from that point on, but I feel it might add too much complexity. Different types of Troop Transport Bays will NOT add any additional benefit over a Standard type, however the Drop Capable bays could allow for an "Orbital Envelopment" mission. The differences between the "Orbital Envelopment" and the "Vertical Envelopment" would be that Fighter Pod Bays would NOT allow a fighter on an "Orbital Envelopment" mission to conduct a CAS mission. Fighters on an "Orbital Envelopment" mission COULD provide Orbital Bombardment in the appropriate phase IF they had a suitable weapon. Fighters on an "Orbital Envelopment" mission would NOT incur AA fire, but WOULD incur fire from enemy STOs. Orbital Bombardment could be toggled by unassigning the B-FCS, or by having a separate set of orders for "Vertical Envelopment w/ CAS" and "Orbital Envelopment w/ Orbital Bombardment".
Title: Re: C# Suggestions
Post by: Droll on February 21, 2021, 08:44:05 PM
Vertical Envelopment: (Working Title)

 - The premises itself is fairly simple and straightforward, have Fighters that are equipped with Troop Transport Bays be able to conduct a special Ground Support Mission that I'm going to refer to as "Vertical Envelopment" from this point on. I'm open to a better name. :) This Ground Support Mission allows any Fighter Sized craft with a Troop Transport Bay to give a random formation an extra breakthrough chance when supported by eligible fighters assigned to said mission. The formations to be supported are chosen at random, with each fighter assigned choosing one until all eligible fighters with this mission are assigned. Formations gain a breakthrough chance increase equivalent to the Troop Transport tonnage of all supporting fighters, divided by the largest unit in the formation then multiplied by the number of eligible fighters assigned. Formations with FFD can have fighters assigned to them to provide support for them as per the usual rules for FFD and Ground Support Fighters.

 - The breakthrough chance is applied in it's relative phase, but a fighter assigned to a "Vertical Envelopment" Mission still takes AA fire in the relevant stage. Light AA fire will be taken by the fighter from the formation that was engaged by the formation that the "Vertical Envelopment" support was provided to. Medium AA fire will be taken by the fighter from a formation that was directly supporting the formation that was engaged by the formation that the "Vertical Envelopment" support was provided to. Heavy AA fire will be taken by any fighters taking part in "Vertical Envelopment" Missions regardless of what formations are supported by them, assuming the Heavy AA is in a valid position to fire. A fighter with both a Troop Transport Bay AND at least one Fighter Pod Bay may also fire as if providing CAS during the relevant phase, but will not draw additional AA fire as a result of this.

 - If fighters assigned to a "Vertical Envelopment" Mission have a formation loaded into their Troop Transport Bays, instead of the usual bonus they will provide a breakthrough bonus equal to the tonnage of their largest unit multiplied by the number of units. For the purposes of this calculation, LOG and S-LOG do not count for unit tonnage when determining the largest unit tonnage and are not counted towards the number of units multiplier. Formations assigned to fighters that themselves are assigned to a "Vertical Envelopment" Mission are treated as part of the formation that they are supporting for the purposes of ground combat and can take casualties as such. These formations also use supply AND provide supply during that phase as if they were a part of the formation that the fighter they are assigned to is supporting.

 - Fighters destroyed during a "Vertical Envelopment" mission will also automatically result in the destruction of any formations that they were carrying. I would not be against some kind of derived percentage of survival with the surviving remnants treated as normal ground combatants from that point on, but I feel it might add too much complexity. Different types of Troop Transport Bays will NOT add any additional benefit over a Standard type, however the Drop Capable bays could allow for an "Orbital Envelopment" mission. The differences between the "Orbital Envelopment" and the "Vertical Envelopment" would be that Fighter Pod Bays would NOT allow a fighter on an "Orbital Envelopment" mission to conduct a CAS mission. Fighters on an "Orbital Envelopment" mission COULD provide Orbital Bombardment in the appropriate phase IF they had a suitable weapon. Fighters on an "Orbital Envelopment" mission would NOT incur AA fire, but WOULD incur fire from enemy STOs. Orbital Bombardment could be toggled by unassigning the B-FCS, or by having a separate set of orders for "Vertical Envelopment w/ CAS" and "Orbital Envelopment w/ Orbital Bombardment".

"Air assault" might be the name you are looking for here.
Title: Re: C# Suggestions
Post by: TMaekler on February 22, 2021, 09:13:06 AM
Race Tech Naming Patterns: I think most of us either just take the names of tech modules created as given or heavily edit them to whatever extent. In my case, I add certain information to the name so I can see the info without having to click on it to see the details. Sensors are one example where I add the weight to the name or some of the default techs so I instantly can see how large in t is a "small fuel tank".

It would though be nice if we could save these patterns in the game DB so they get auto-generated by the game when you create new tech. Another example is rockets: I add the string "S3 W4 25.5mkm" to a missile - so I instantly can see that it is a size 3, warhead 4, and has a travel range of 25.5mkm. If I could auto-generate that when creating the missile in the first place - marvelous :-)
Title: Re: C# Suggestions
Post by: QuakeIV on February 22, 2021, 08:47:43 PM
Semi-sorta related:

It would be nice if the 'company' field was also a dropdown that contained previously used company names (and the most recently used company name gets sorted to the top, so that unused names slowly filter to the bottom of the list).
Title: Re: C# Suggestions
Post by: Desdinova on February 23, 2021, 11:03:23 PM
Steve - can you make "Geo Survey Complete" for ground surveys a time-interrupting event?
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 23, 2021, 11:16:02 PM
Steve - can you make "Geo Survey Complete" for ground surveys a time-interrupting event?

Piggyback: Please have an event that explicitly says a ground geosurvey came up empty. I spend way too much time scrutinizing the events list looking for the results from fruitless surveys.
Title: Re: C# Suggestions
Post by: QuakeIV on February 24, 2021, 12:35:27 AM
I actually dont use them because they just get left on a planet until time immemorial because I never noticed they didnt find anything.  I also support this idea.
Title: Re: C# Suggestions
Post by: AlStar on February 26, 2021, 01:34:00 PM
I highly suspect that this (or ideas like it) have already been suggested, but *shrug* doesn't hurt to re-hash some things.

Boarding combat - currently, 99% of all boarding combat seems to consist of a squad of highly trained, heavily armored marines against the hapless spacers aboard whatever ship gets boarded.

Thoughts (to be taken individually or mixed and matched):
1. Armory Module - perhaps with size scaling with number of crew. Upgrades typical crew from light weapons and half racial armor to regular weapons and racial armor.
2. Robotic Defender Module - provides X number of defensive troops for the ship. Default with same stats as a normal infantry, with a possible upgrade tree that can lead to heavily armored or heavy weapon variants. Could be RP'd as either actual robotic troops, or as automated boobytraps / hidden turrets in the ship.
3. Ship Security Module - a module that can be filled with X tons of troops, selectable from your currently researched ground combat templates. Set in the ship build menu. Then, when you queue up a new ship to be built, the cost of the troops will be added to the cost of the ship, and when the ship is completed, it will have the troops on board. (Basically, a troop transport bay, but without having to micromanage loading up individual defensive compliments of troops for each ship.)
Title: Re: C# Suggestions
Post by: Droll on February 26, 2021, 04:25:45 PM
I highly suspect that this (or ideas like it) have already been suggested, but *shrug* doesn't hurt to re-hash some things.

Boarding combat - currently, 99% of all boarding combat seems to consist of a squad of highly trained, heavily armored marines against the hapless spacers aboard whatever ship gets boarded.

Thoughts (to be taken individually or mixed and matched):
1. Armory Module - perhaps with size scaling with number of crew. Upgrades typical crew from light weapons and half racial armor to regular weapons and racial armor.
2. Robotic Defender Module - provides X number of defensive troops for the ship. Default with same stats as a normal infantry, with a possible upgrade tree that can lead to heavily armored or heavy weapon variants. Could be RP'd as either actual robotic troops, or as automated boobytraps / hidden turrets in the ship.
3. Ship Security Module - a module that can be filled with X tons of troops, selectable from your currently researched ground combat templates. Set in the ship build menu. Then, when you queue up a new ship to be built, the cost of the troops will be added to the cost of the ship, and when the ship is completed, it will have the troops on board. (Basically, a troop transport bay, but without having to micromanage loading up individual defensive compliments of troops for each ship.)

I like all of this but no. 3 sounds hard to implement if you want it fully automated and also making sense - what you suggest here would mean that a shipyard would also "train" the troops which kind of sidesteps the requirement to have GU training facilities. So doing it properly would be a lot of work.
Title: Re: C# Suggestions
Post by: QuakeIV on February 26, 2021, 06:14:11 PM
There is already a concept of being able to produce ship components either via factories or shipyard.  I personally think that doing some production in the shipyard is reasonable.  Particularly for convenience.  I think if the troops were pretty fundamentally confined to the ship and generally still had to go somewhere to replenish this complement, then it would be reasonable.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 26, 2021, 07:05:06 PM
I highly suspect that this (or ideas like it) have already been suggested, but *shrug* doesn't hurt to re-hash some things.

Boarding combat - currently, 99% of all boarding combat seems to consist of a squad of highly trained, heavily armored marines against the hapless spacers aboard whatever ship gets boarded.

Thoughts (to be taken individually or mixed and matched):
1. Armory Module - perhaps with size scaling with number of crew. Upgrades typical crew from light weapons and half racial armor to regular weapons and racial armor.
2. Robotic Defender Module - provides X number of defensive troops for the ship. Default with same stats as a normal infantry, with a possible upgrade tree that can lead to heavily armored or heavy weapon variants. Could be RP'd as either actual robotic troops, or as automated boobytraps / hidden turrets in the ship.
3. Ship Security Module - a module that can be filled with X tons of troops, selectable from your currently researched ground combat templates. Set in the ship build menu. Then, when you queue up a new ship to be built, the cost of the troops will be added to the cost of the ship, and when the ship is completed, it will have the troops on board. (Basically, a troop transport bay, but without having to micromanage loading up individual defensive compliments of troops for each ship.)

I'm not sure what any of these add to the game mechanically that isn't already doable by sticking a troop bay with some highly-trained, heavily-armored defenders. The armory at least functions differently, but the other two are basically just troop bays with a little flavor on top, not really worth coding in a new mechanic for.

The armory is an interesting idea but in the proposed form would be blatantly overpowered as it upgrades the entire crew of a ship to basically full light infantry. I also don't think the mechanic makes sense as it's simply not how shipboard armories work in any real navy, in most cases including a troop bay is a more realistic model of an armory module.
Title: Re: C# Suggestions
Post by: QuakeIV on February 26, 2021, 07:53:57 PM
What a ship security module adds is making staffing actual security forces on the ship way easier.

I think the Armory is reasonable if there is a sufficient weight aspect to it.  It seems to me like the crew should still be inferior to dedicated troops, just better armed than otherwise.
Title: Re: C# Suggestions
Post by: Droll on February 26, 2021, 08:03:00 PM
What a ship security module adds is making staffing actual security forces on the ship way easier.

I think the Armory is reasonable if there is a sufficient weight aspect to it.  It seems to me like the crew should still be inferior to dedicated troops, just better armed than otherwise.

You could just make it so that a single armory arms a certain number of crewmen. That way you can't just cheese it on large ships with one armory for everyone.
Title: Re: C# Suggestions
Post by: QuakeIV on February 26, 2021, 08:46:57 PM
I agree it should scale to crew, you had already mentioned that so I was just mentioning, if the weight (per crew) is big enough then it should be possible to make it not-imbalanced.
Title: Re: C# Suggestions
Post by: Steve Walmsley on February 27, 2021, 04:40:50 AM
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.

1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.

1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.

3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.

4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.

The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.
Title: Re: C# Suggestions
Post by: xenoscepter on February 27, 2021, 05:13:13 AM
 - I already use static units and vehicles for boarding defense, the former being ship board turrets, the latter being used as trams on space stations for the ferrying of supplies and providing heavy weapon support. Since ground formations defend their mothership, anything goes really, or so I assume...
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 27, 2021, 06:46:44 AM
- I already use static units and vehicles for boarding defense, the former being ship board turrets, the latter being used as trams on space stations for the ferrying of supplies and providing heavy weapon support. Since ground formations defend their mothership, anything goes really, or so I assume...

Only infantry is used in ship combat, so I don't think that either static nor vehicles will help you much there.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 27, 2021, 06:55:19 AM
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.

1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.

1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.

3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.

4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.

The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.

In my opinion it would be much better if you changed the UI to better support small ship based security forces and marines. I would like the ground troop screen to be able to filter out troops onboard ships or that you can flag formations as ship security/marine forces so the game understand these are troops assigned to the ship rather than being transported from one place to another.

We should then also be able to see such forces in the ship information screen as more like part of the ship, perhaps even in the ship info screen as if then parasites and missiles are added.

I think this would be better and would fit better in general in my opinion. People on ships should usually be dedicated marines or not.
Title: Re: C# Suggestions
Post by: Droll on February 27, 2021, 07:47:53 AM
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.

1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.

1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.

3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.

4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.

The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.

Your final suggestion is a very good one.

As for your concerns - The power armor stuff I think is a non-issue, just have the armory upgrade the crew weapons and keep their armor the same. The whole point of the armory is to improve the damage dealing potential of crew against gene modded space marines in power armor which are the most likely assailants. I don't think it's reasonable to expect the armory to also provide armor.

As for the weapon tracking problem, an alternative would be for the armory to not arm existing crew - but instead add a specific amount of "security personnel" who are better armed and form another defensive element during boarding combat. This creates a life support burden but also solves the problem of needing to track equipment. When a red shirt gets shot their equipment goes with them and can only be replenished with the "replace crew" order. This also sidesteps the training question since they are trained security personnel who are specialized in defending ships.
Title: Re: C# Suggestions
Post by: TMaekler on February 27, 2021, 07:54:33 AM
When the order to refuel or restock is auto-generated by the game it should check if such orders are already in the ship's queue. It is a bit annoying when I set up a deep space recco to return home manually and have them stop at some fuel depots on the way and the auto-generate deletes all of that making the ship stranded in deep space...
Title: Re: C# Suggestions
Post by: xenoscepter on February 27, 2021, 07:55:15 AM
- I already use static units and vehicles for boarding defense, the former being ship board turrets, the latter being used as trams on space stations for the ferrying of supplies and providing heavy weapon support. Since ground formations defend their mothership, anything goes really, or so I assume...

Only infantry is used in ship combat, so I don't think that either static nor vehicles will help you much there.

 - Don't formations defend their own ship? I thought the infantry-only was with regards to the attacking force only...
Title: Re: C# Suggestions
Post by: Droll on February 27, 2021, 08:13:45 AM
- I already use static units and vehicles for boarding defense, the former being ship board turrets, the latter being used as trams on space stations for the ferrying of supplies and providing heavy weapon support. Since ground formations defend their mothership, anything goes really, or so I assume...

Only infantry is used in ship combat, so I don't think that either static nor vehicles will help you much there.

 - Don't formations defend their own ship? I thought the infantry-only was with regards to the attacking force only...

No it also applies to the defending side.
Title: Re: C# Suggestions
Post by: xenoscepter on February 27, 2021, 08:15:29 AM
- I already use static units and vehicles for boarding defense, the former being ship board turrets, the latter being used as trams on space stations for the ferrying of supplies and providing heavy weapon support. Since ground formations defend their mothership, anything goes really, or so I assume...

Only infantry is used in ship combat, so I don't think that either static nor vehicles will help you much there.

 - Don't formations defend their own ship? I thought the infantry-only was with regards to the attacking force only...

No it also applies to the defending side.

 - Well, crap. >:(
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 27, 2021, 11:34:58 AM
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.

1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.

1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.

3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.

4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.

The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.

In my opinion it would be much better if you changed the UI to better support small ship based security forces and marines. I would like the ground troop screen to be able to filter out troops onboard ships or that you can flag formations as ship security/marine forces so the game understand these are troops assigned to the ship rather than being transported from one place to another.

We should then also be able to see such forces in the ship information screen as more like part of the ship, perhaps even in the ship info screen as if then parasites and missiles are added.

I think this would be better and would fit better in general in my opinion. People on ships should usually be dedicated marines or not.

I second this viewpoint. Besides being probably easier to implement than a whole new armory mechanic, the existing approach of sticking a troop bay and a platoon of marines, security guards, or what have you is I think just better for RP, plus handles all of the caveats Steve mentioned just fine with existing mechanics (leaving #1 and #2 up to player RP - never a bad result - #3 and #4 take care of themselves). Some tweaks to reduce micro are always welcome but adding a new and probably rather opaque mechanic I don't think is worth it.
Title: Re: C# Suggestions
Post by: Droll on February 27, 2021, 11:39:05 AM
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.

1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.

1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.

3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.

4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.

The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.

In my opinion it would be much better if you changed the UI to better support small ship based security forces and marines. I would like the ground troop screen to be able to filter out troops onboard ships or that you can flag formations as ship security/marine forces so the game understand these are troops assigned to the ship rather than being transported from one place to another.

We should then also be able to see such forces in the ship information screen as more like part of the ship, perhaps even in the ship info screen as if then parasites and missiles are added.

I think this would be better and would fit better in general in my opinion. People on ships should usually be dedicated marines or not.

I second this viewpoint. Besides being probably easier to implement than a whole new armory mechanic, the existing approach of sticking a troop bay and a platoon of marines, security guards, or what have you is I think just better for RP, plus handles all of the caveats Steve mentioned just fine with existing mechanics (leaving #1 and #2 up to player RP - never a bad result - #3 and #4 take care of themselves). Some tweaks to reduce micro are always welcome but adding a new and probably rather opaque mechanic I don't think is worth it.

It would also be quite well suited to have micro sized troop transport bays - so a 50 or 100t module that will basically only ever house a single squad for example. These tiny variants need not have boarding / drop pod versions. That way you can design your own security team for the ship, this works incredibly well because it give total player agency and synergizes very well with the new misc components - so your ship can just have an "armory" anyways.
Title: Re: C# Suggestions
Post by: Zincat on February 27, 2021, 12:30:41 PM
I would be very much a fan of a "select standard defense squad" for a given ship design, with auto-load function. Not so much to reduce the micro, but also to avoid those: "oops I forgot to load the defense troops" moments
Also having smaller troop transport bays sound nice
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 27, 2021, 05:31:55 PM
I would be very much a fan of a "select standard defense squad" for a given ship design, with auto-load function. Not so much to reduce the micro, but also to avoid those: "oops I forgot to load the defense troops" moments
Also having smaller troop transport bays sound nice

Something like... if you designate a formation as a ship force it shows up in the "Class Design" window in a new tab called troops. You now select formations in the same way like ordnance. You also can just have a ship order to load/unload ship troops to easily load and unload these troops. You also could use this to transfer reinforcements to killed soldiers from any formation on that body designated as "reserved".

This would make it easy to manage small ship troop forces and stay true to the rest of the troop system at the same time.
Title: Re: C# Suggestions
Post by: db48x on February 27, 2021, 08:57:33 PM
I would be very much a fan of a "select standard defense squad" for a given ship design, with auto-load function. Not so much to reduce the micro, but also to avoid those: "oops I forgot to load the defense troops" moments
Also having smaller troop transport bays sound nice

Something like... if you designate a formation as a ship force it shows up in the "Class Design" window in a new tab called troops. You now select formations in the same way like ordnance. You also can just have a ship order to load/unload ship troops to easily load and unload these troops. You also could use this to transfer reinforcements to killed soldiers from any formation on that body designated as "reserved".

This would make it easy to manage small ship troop forces and stay true to the rest of the troop system at the same time.

I like all of these ideas. Selecting a formation template during the class design makes a lot of sense, and adding orders for replenishing those troops makes it even better. Add in an order that allows one fleet to draw replacements from another, and I think it completes the set.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 27, 2021, 10:41:39 PM
I would be very much a fan of a "select standard defense squad" for a given ship design, with auto-load function. Not so much to reduce the micro, but also to avoid those: "oops I forgot to load the defense troops" moments
Also having smaller troop transport bays sound nice

Something like... if you designate a formation as a ship force it shows up in the "Class Design" window in a new tab called troops. You now select formations in the same way like ordnance. You also can just have a ship order to load/unload ship troops to easily load and unload these troops. You also could use this to transfer reinforcements to killed soldiers from any formation on that body designated as "reserved".

This would make it easy to manage small ship troop forces and stay true to the rest of the troop system at the same time.

I like all of these ideas. Selecting a formation template during the class design makes a lot of sense, and adding orders for replenishing those troops makes it even better. Add in an order that allows one fleet to draw replacements from another, and I think it completes the set.

The last bit is actually probably an even better idea by itself than anything else, since it would enable us to use troop transports as carriers for reinforcements to keep our boarding marines topped off.
Title: Re: C# Suggestions
Post by: Borealis4x on February 28, 2021, 12:09:41 PM
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.

1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.

1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.

3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.

4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.

The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.

I quite like the Armory solution to ship security and would highly discourage making the player use regular ground formations for the purpose, which I feel would still be far too much micro whichever way you slice it.

1) I actually had an old co-worker who was a Sonar operator on a USN sub, and he said he received periodic weapons and tactics training. I believe it is standard practice on most ships to 'draft' and equip the crew to repel boarders although specialized security personnel do exist. I'd say it justified to assume crewmen are still trained in anti-boarding tactics as part of their standard curriculum. They're by no means SEALs, but they get the job done. Perhaps if you add a training level attribute to ground units one day armed crewmen could be stuck at 'basic'.

2) I completely agree, Power Armor should be specialized equipment that is by no means standard issue. They shouldn't be issued on ship Armories meant for defense. If you want PA'd troops, you need to do it the old fashioned way with a troop transport bay.

3) I think that 'upgrading' ground troops should be as simple as retraining them when you have better racial armor and weapons at a Ground Force facility; the current system is too convoluted IMO. Same for Armory Modules, they should be upgraded after a ship finishes overhaul or even just when a ship resupplies at a friendly port. After all, you're just clearing out the old guns and brining in the new.

However, when constrained to current systems I think its fine to just make Armories components with a Weapons tech slot and Armor tech slot. Sure its annoying and unrealistic that you have to create a whole new class of ship just to restock the Armory, but its the most straight-forward and easy to understand solution. Perhaps you could make armory 'retrofits' extremely cheap and almost instant.

4) Perhaps link Armory usage to MSP. Whenever you take casualties during a boarding operation, it drains MSP and your armor has to consume more to re-arm. Given how abstract MSP is currently I don't see the harm in extending it to security equipment.

An Armor would be a much more elegant and realistic solution to improving ship security than adding ground forces to every ship.
Title: Re: C# Suggestions
Post by: Droll on February 28, 2021, 12:34:28 PM
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.

1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.

1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.

3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.

4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.

The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.

I'm quite like the Armory solution to ship security and would highly discourage making the player use regular ground formations for the purpose, which I feel would still be far too much micro whichever way you slice it.

1) I actually had an old co-worker who was a Sonar operator on a USN sub, and he said he received periodic weapons and tactics training like all seamen and officer do. I believe it is standard practice on most ships to 'draft' and equip the crew to repel boarders although specialized security personnel do exist. I'd say it justified to assume crewmen are still trained in anti-boarding tactics in space. They're by no means SEALs, but they get the job done. Perhaps if you add a training level attribute to ground units one day armed crewmen could be stuck at 'basic'.

2) I completely agree, Power Armor should be specialized equipment that is by no means standard issue. They shouldn't be issued on ship Armories meant for defense. If you want PA'd troops, you need to do it the old fashioned way with a troop transport bay.

3) I think that 'upgrading' ground troops should be as simple as retraining them when you have better racial armor and weapons at a Ground Force facility; the current system is too convoluted IMO. Same for Armory Modules, they should be upgraded after a ship finishes overhaul or even just when a ship resupplies at a friendly port. After all, you're just clearing out the old guns and brining in the new.

However, when constrained to current systems I think its fine to just make Armories components with a Weapons tech slot and Armor tech slot. Sure its annoying and unrealistic that you have to create a whole new class of ship just to restock the Armory, but its the most straight-forward and easy to understand solution. Perhaps you could make armory 'retrofits' extremely cheap and almost instant.

4) Perhaps link Armory usage to MSP. Whenever you take casualties during a boarding operation, it drains MSP and your armor has to consume more to re-arm. Given how abstract MSP is currently I don't see the harm in extending it to security equipment.

An Armor would be a much more elegant and realistic solution to improving ship security than adding ground forces to every ship.

Training level in ground combat is abstracted under morale. Notice that officer with ground force training will slowly increase the morale of their formation over time.
It would certainly be appropriate even if an armory or such isn't added to make it so that the crew grade bonus applies to the morale of defending crew. So a crew grade bonus of 22% will create crewmen elements at 122 morale. 22% accuracy boost for the defenders will certainly make boarding more dangerous.
Title: Re: C# Suggestions
Post by: Borealis4x on February 28, 2021, 12:44:16 PM
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.

1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.

1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.

3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.

4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.

The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.

I'm quite like the Armory solution to ship security and would highly discourage making the player use regular ground formations for the purpose, which I feel would still be far too much micro whichever way you slice it.

1) I actually had an old co-worker who was a Sonar operator on a USN sub, and he said he received periodic weapons and tactics training like all seamen and officer do. I believe it is standard practice on most ships to 'draft' and equip the crew to repel boarders although specialized security personnel do exist. I'd say it justified to assume crewmen are still trained in anti-boarding tactics in space. They're by no means SEALs, but they get the job done. Perhaps if you add a training level attribute to ground units one day armed crewmen could be stuck at 'basic'.

2) I completely agree, Power Armor should be specialized equipment that is by no means standard issue. They shouldn't be issued on ship Armories meant for defense. If you want PA'd troops, you need to do it the old fashioned way with a troop transport bay.

3) I think that 'upgrading' ground troops should be as simple as retraining them when you have better racial armor and weapons at a Ground Force facility; the current system is too convoluted IMO. Same for Armory Modules, they should be upgraded after a ship finishes overhaul or even just when a ship resupplies at a friendly port. After all, you're just clearing out the old guns and brining in the new.

However, when constrained to current systems I think its fine to just make Armories components with a Weapons tech slot and Armor tech slot. Sure its annoying and unrealistic that you have to create a whole new class of ship just to restock the Armory, but its the most straight-forward and easy to understand solution. Perhaps you could make armory 'retrofits' extremely cheap and almost instant.

4) Perhaps link Armory usage to MSP. Whenever you take casualties during a boarding operation, it drains MSP and your armor has to consume more to re-arm. Given how abstract MSP is currently I don't see the harm in extending it to security equipment.

An Armor would be a much more elegant and realistic solution to improving ship security than adding ground forces to every ship.

Training level in ground combat is abstracted under morale. Notice that officer with ground force training will slowly increase the morale of their formation over time.


That doesn't make much sense to me. GI's don't become Delta Force just because their commander changed. Moral should be important sure, but the training level of Ground Units should be something akin to Genetic Modification that greatly enhances their abilities but makes the biggest impact on training time. A solider is more than their equipment.
Title: Re: C# Suggestions
Post by: Droll on February 28, 2021, 03:24:45 PM
I have been considering some form of 'armoury' module to allow the crew to be better armed for a while. It is less micromanagement than building ground forces to assign to ships where the intention is solely to improve boarding defence. The armoury could be a fixed size and would arm a fixed number of crew with personal weapons with the rest of the crew functioning as they do now. There are a few caveats however.

1) It is unlikely that crew would be as well trained as the troops in a regular infantry formation
2) It is unlikely than crew would be able to function in powered armour
3) It would unreasonable for an armoury module to auto-upgrade crew weapons when that doesn't apply to normal infantry formations.
4) What happens to the ability of the armoury to equip crew after they have been in a battle and some have been killed.

1) and 2) could be handled in 2 ways. Either assign some form of attack penalty, which reduces the effect of having the armoury, or handwave it and assume the 'armoury' module is also used to train the crew.

3) is trickier. The only real way around it is make the armoury a designed module that has fixed weapon and armour strengths at the time of creation. if I did that, I could also have a 'training' option on the module that makes it larger but allows the crew to function at full effectiveness. Plus maybe a 'powered armour' option that also increases size but allows crew to use powered armour. Although that is starting to get more complex.

4) is also tricky. In normal ground combat, when someone is killed their equipment is also lost so the armoury should be less effective after a battle, but I don't want to track weapons held by individual armouries.

The various questions above are why I haven't yet moved forward with this type of module. Perhaps a better option is to give ships an assigned group formation type in the same way as ordnance (which would have to fit within their troop transport capacity), so when they are built they pick up their ground formation. That, together with queueing ground units, solves a lot of the micromanagement. I can even have a name template for the formation so it gets renamed when assigned to the ship.

I'm quite like the Armory solution to ship security and would highly discourage making the player use regular ground formations for the purpose, which I feel would still be far too much micro whichever way you slice it.

1) I actually had an old co-worker who was a Sonar operator on a USN sub, and he said he received periodic weapons and tactics training like all seamen and officer do. I believe it is standard practice on most ships to 'draft' and equip the crew to repel boarders although specialized security personnel do exist. I'd say it justified to assume crewmen are still trained in anti-boarding tactics in space. They're by no means SEALs, but they get the job done. Perhaps if you add a training level attribute to ground units one day armed crewmen could be stuck at 'basic'.

2) I completely agree, Power Armor should be specialized equipment that is by no means standard issue. They shouldn't be issued on ship Armories meant for defense. If you want PA'd troops, you need to do it the old fashioned way with a troop transport bay.

3) I think that 'upgrading' ground troops should be as simple as retraining them when you have better racial armor and weapons at a Ground Force facility; the current system is too convoluted IMO. Same for Armory Modules, they should be upgraded after a ship finishes overhaul or even just when a ship resupplies at a friendly port. After all, you're just clearing out the old guns and brining in the new.

However, when constrained to current systems I think its fine to just make Armories components with a Weapons tech slot and Armor tech slot. Sure its annoying and unrealistic that you have to create a whole new class of ship just to restock the Armory, but its the most straight-forward and easy to understand solution. Perhaps you could make armory 'retrofits' extremely cheap and almost instant.

4) Perhaps link Armory usage to MSP. Whenever you take casualties during a boarding operation, it drains MSP and your armor has to consume more to re-arm. Given how abstract MSP is currently I don't see the harm in extending it to security equipment.

An Armor would be a much more elegant and realistic solution to improving ship security than adding ground forces to every ship.

Training level in ground combat is abstracted under morale. Notice that officer with ground force training will slowly increase the morale of their formation over time.


That doesn't make much sense to me. GI's don't become Delta Force just because their commander changed. Moral should be important sure, but the training level of Ground Units should be something akin to Genetic Modification that greatly enhances their abilities but makes the biggest impact on training time. A solider is more than their equipment.

I mean I agree that it is a weird abstraction to make from a logical perspective but mechanically it makes sense. After all, the only thing training level would affect would be the hit chance - likewise the only thing morale would affect is also the hit chance.

My suggestion would be to rename morale to "readiness" or to split morale into two; "morale" and "training": Morale acts like fortification, if above 100, enemies are less likely to score hits on that element and if below 100 the element is more likely to get hit. On the other hand training is the offensive counterpart, above 100 training improve the chance that the element scores hits on their targets whereas if below 100 they are less likely to hit the enemy. This introduces a subtle difference between how morale and training would behave but I'm not sure if it is mechanically different enough to warrant an increase in complexity.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on February 28, 2021, 04:11:27 PM
I quite like the Armory solution to ship security and would highly discourage making the player use regular ground formations for the purpose, which I feel would still be far too much micro whichever way you slice it.

1) I actually had an old co-worker who was a Sonar operator on a USN sub, and he said he received periodic weapons and tactics training. I believe it is standard practice on most ships to 'draft' and equip the crew to repel boarders although specialized security personnel do exist. I'd say it justified to assume crewmen are still trained in anti-boarding tactics as part of their standard curriculum. They're by no means SEALs, but they get the job done. Perhaps if you add a training level attribute to ground units one day armed crewmen could be stuck at 'basic'.

2) I completely agree, Power Armor should be specialized equipment that is by no means standard issue. They shouldn't be issued on ship Armories meant for defense. If you want PA'd troops, you need to do it the old fashioned way with a troop transport bay.

3) I think that 'upgrading' ground troops should be as simple as retraining them when you have better racial armor and weapons at a Ground Force facility; the current system is too convoluted IMO. Same for Armory Modules, they should be upgraded after a ship finishes overhaul or even just when a ship resupplies at a friendly port. After all, you're just clearing out the old guns and brining in the new.

However, when constrained to current systems I think its fine to just make Armories components with a Weapons tech slot and Armor tech slot. Sure its annoying and unrealistic that you have to create a whole new class of ship just to restock the Armory, but its the most straight-forward and easy to understand solution. Perhaps you could make armory 'retrofits' extremely cheap and almost instant.

4) Perhaps link Armory usage to MSP. Whenever you take casualties during a boarding operation, it drains MSP and your armor has to consume more to re-arm. Given how abstract MSP is currently I don't see the harm in extending it to security equipment.

An Armor would be a much more elegant and realistic solution to improving ship security than adding ground forces to every ship.

While I don't think that Armory sections on ships for small security forces necessarily is bad my thinking is that we should make ALL permanent troops on ships work with the same mechanic and make it better than what it currently is. I for one like to add even small proper marine detachment to ships as well as a more modest security force. I don't see why they should be handled differently as they are more or less interchangeable.

I don't like to build dedicated boarding carriers just because it is simpler and less micromanagement... my idea is to make the mechanic so it fits all ways you can possibly use them instead. It should be easy to reinforce them, board enemy vessels and use specific marine detachment forces for your ships without cluttering the ground forces list of troops etc... Otherwise we should abstract boarding pods in the same manner in my opinion which is something I would not want to do to be honest.
Title: Re: C# Suggestions
Post by: Kristover on February 28, 2021, 04:29:52 PM
While we are on the subject of Commanders, I would like to have some additional ground combat commander bonuses that reflect the terrain bonuses that are out there.  I was thinking about this the other night when I was playing - I always create a 'Federation Marine Corps' who have boarding and low-gravity fighting capabilities.  When I'm fighting wars, these are the guys I usually send after any Low-G colonies the enemy might have.  I have also recently created 'Raider Battalions' - Marines with High-G capability.  I think it would be great if we had a '<Capability> Modifer' so that certain commanders are adept Jungle, Desert, Low-G, or Mountain Fighters and that the auto-assignment code is biased to place those Commanders into formations with those capabilities.  It is a smaller thing but I think it would reward some specialization of formations by having dedicated commanders who are expert in their capabilities.
Title: Re: C# Suggestions
Post by: Kiero on March 01, 2021, 02:20:42 AM
I would love to see a truly randomly generated world with an intertwining research tree. What I mean by that:

1) Resouces. In Aurora, "sorium" is always a fuel source. I would love to see randomly generated "minerals". So the name, quality (how much fuel you can get out of that resource), and abundance is determined at the start of a game. Higher quality, lower the abundance.
It can also apply to other resources.
Of course, new minerals can be discovered/generated during a game.
Exp. Mineralium from which you can extract 45 Duranium, 12 Gallicite, 2 Sorium. That value can be increased by researching a Mineralium Refining tech.
And if you don't have any other source of sorium... then Mineralium Sorium refining tech will be the research for you to follow. That might also deteriorate duranium and gallicite that can be extracted from that mineral. So the use of a mineral can be "chosen" by a player.

2) Research is accelerated by what you find. For example, you can always develop shiels but if you'll find a black hole or a special nebula or a unique asteroid and a ship with a science module is send there to get samples or to stay at that location. The research project that is linked to it would be accelerated (how much, might be determined as game difficulty, but it should be significant).
Title: Re: C# Suggestions
Post by: TMaekler on March 01, 2021, 02:55:32 AM
I would love to see a truly randomly generated world with an intertwining research tree. What I mean by that:

Aurora is meant as a storytelling tool. And as such it works great. It though works only within its confined rules. Some kind of different economy model or what minerals can produce what goods is not in the game. Whilst being nice having those features (being able to define your own minerals and what installations use what resources for production) - the question is: would that be beneficial for the storytelling? I don't think so...
Title: Re: C# Suggestions
Post by: Kiero on March 01, 2021, 03:17:14 AM
Aurora is meant as a storytelling tool. And as such it works great. It though works only within its confined rules. Some kind of different economy model or what minerals can produce what goods is not in the game. Whilst being nice having those features (being able to define your own minerals and what installations use what resources for production) - the question is: would that be beneficial for the storytelling? I don't think so...

In my opinion, it would.
Just like spice in "Diuna"
Title: Re: C# Suggestions
Post by: TMaekler on March 01, 2021, 03:55:39 AM
You could just rename Sorium into "Spice" and role play it as only being found on one planet you rename "Arrakis" :-)
Title: Re: C# Suggestions
Post by: serger on March 01, 2021, 04:04:50 AM
I'll second the p.2) of the previous post by Kiero.
I think it will be great to have more situational research multipliers in addition to research complexes.
Now we have Ancient Constructs that are doing like that, but it might be much more consistent and less micro-heavy, I think, if research model will be more weighted in this manner.

There might be:

1. Instead of fixed amount of RsPs alien component can give while being instantly deconstructed - it might give fixed multiplier for the relevant research fields, while this research is going, with some chance of the researching component being broken in the process every construction cycle. (And that is local multiplier - components have to be in the same colony with research labs to give bonus.)
2. Ground force adaptations. The more population you have in some surface type (grav, atm, temperature, terrain) - the more global research multiplier you might have with this type of GF specs, representing cumulative practical experience your empire have with this surface (LOG function, I think, will be appropriate). It might be local and global both, so it will be very easy for you to research, say, desert low grav infantry, if your home world is low grav desert. In addition, GF construction cost might be lower (spec multiplier halved?), if your GF construction facility is located on the planet with the same surface spec, so it will be much cheaper to build up desert low grav infantry in the desert low grav planet.
3. Some small global bonus when a ship with Science Department and survey officer is stationed at specific bodies (Ancient Constructs and so on), even if there is no colony there.
Title: Re: C# Suggestions
Post by: Kiero on March 01, 2021, 04:12:53 AM
You could just rename Sorium into "Spice" and role play it as only being found on one planet you rename "Arrakis" :-)

But this is still predetermined.
My point is that with random minerals it is more like exploring the game world every time you start a new game. And it is different every time you play. Sometimes fuel can be gathered from gas giants and sometimes from asteroids.
Title: Re: C# Suggestions
Post by: serger on March 01, 2021, 04:19:23 AM
But this is still predetermined.
My point is that with random minerals it is more like exploring the game world every time you start a new game. And it is different every time you play. Sometimes fuel can be gathered from gas giants and sometimes from asteroids.
It will be great really, but it's very hard to code for Steve.
Even large gamedev companies have constant troubles with this sort of mecanics.
Title: Re: C# Suggestions
Post by: TMaekler on March 01, 2021, 04:57:53 AM
But this is still predetermined.
My point is that with random minerals it is more like exploring the game world every time you start a new game. And it is different every time you play. Sometimes fuel can be gathered from gas giants and sometimes from asteroids.
I fully agree.
Title: Re: C# Suggestions
Post by: xenoscepter on March 01, 2021, 05:46:31 AM
 --- Some thoughts on the talk about Boarding Combat and Armory Components:

 - What if there was a 4th type of Troop Transport Bay? This one would allow Static Units and Light Vehicles to participate in the defense of a ship. It could simply be bigger, and could maybe be labeled as "Troop Transport Bay, Security" On that subject, a 5th type of Troop Transport Bay called, "Troop Transport Bay, Landers" could have integrated Cargo Shuttles that were better than normal Cargo Shuttles for hauling Troops, but couldn't transfer MSP like normal ones can.

 - If there were a system of Ground Supplies, maybe GSP for "Ground Supply Points" or something, and LOG / LOG-S became re-usable systems instead of consumables; then tracking equipment for an Armory module would be as simple as having it drain GSP. Have GSP be a function of Cargo Bays, make some Fighter-Sized Cargo Bays (100 Ton "Tiny" and 25 Ton "Fighter" Bays) for small armories to stock up, and viola! Now it becomes possible to use Ground Support Fighters to use the CAP mission to cut ground forces off from their orbital supply lines. It also becomes possible to make small, interplanetary Mineral Shunts.

 - Most importantly of all, GSP means that boarding defense units don't need LOG / LOG-s, just a little cargo bay or three. It could work that Ground Forces tracked their supply as they do now, but instead of consuming the LOG / LOG-S, each force simply pooled together their total LOG capacity, and drew it's GSP from it. Having it be that a unit with both a LOG and LOG-S would draw it's GSP through one or the other, possibly prioritizing LOG-S or something. I dunno I'm just spit-balling here. Steve knows this stuff better than me and could probably do a WAY better job of balancing it than I could.
Title: Re: C# Suggestions
Post by: serger on March 01, 2021, 06:48:05 AM
Besides, is it possible to add some form of irregular combatants, instantly spawning before you can occupy a colony, in the same way as crews are defending their ships automatically?

I'll say - random roll on (pop*militance) to make quantity of squads, then random roll for every squad on the same factor to determine squad's size.
(Infantry with side weapons only and, say, halved morale.)
Title: Re: C# Suggestions
Post by: TMaekler on March 01, 2021, 10:38:05 AM
Ordering one fleet to join another works quite well - especially when the target fleet jumps into a different system - the join-up fleet can follow with any issues. So a QoL could be if I could give a join command to ANY fleet even if it is not in the same system and the join-up fleet would auto navigate and follow that fleet until it can join up. Possible?
Title: Re: C# Suggestions
Post by: TMaekler on March 02, 2021, 02:51:26 PM
Can LP Jump Points be colored differently than the default yellow color?
Title: Re: C# Suggestions
Post by: Barkhorn on March 02, 2021, 05:56:40 PM
Could we have ground units re-supply during the construction phase in addition to during battle?  It's kinda weird that a unit that has survived combat can't replenish its internal stores until the start of the next combat.
Title: Re: C# Suggestions
Post by: liveware on March 03, 2021, 05:04:11 PM
Could we have ground units re-supply during the construction phase in addition to during battle?  It's kinda weird that a unit that has survived combat can't replenish its internal stores until the start of the next combat.

Yes I second this. It's quite annoying having to maintain a separate logistics garrison alongside a depleted combat garrison after the combat garrison has been used once or twice and is out of GSP.
Title: Re: C# Suggestions
Post by: liveware on March 03, 2021, 05:25:15 PM
Another suggestion that I am stealing shamelessly from some other 4x games out there: planet specific 'special attributes'. These would be similar to how ancient constructs currently modify research rate, but could apply boni (or mali) to something other than research. Something like 'dangerous wildlife' might provide a malus to population growth but also provide a ground combat defensive bonus for example. This might require too much detail to program on Steve's end but maybe a more generic system is possible?
Title: Re: C# Suggestions
Post by: liveware on March 03, 2021, 05:30:44 PM
While we are on the subject of Commanders, I would like to have some additional ground combat commander bonuses that reflect the terrain bonuses that are out there.  I was thinking about this the other night when I was playing - I always create a 'Federation Marine Corps' who have boarding and low-gravity fighting capabilities.  When I'm fighting wars, these are the guys I usually send after any Low-G colonies the enemy might have.  I have also recently created 'Raider Battalions' - Marines with High-G capability.  I think it would be great if we had a '<Capability> Modifer' so that certain commanders are adept Jungle, Desert, Low-G, or Mountain Fighters and that the auto-assignment code is biased to place those Commanders into formations with those capabilities.  It is a smaller thing but I think it would reward some specialization of formations by having dedicated commanders who are expert in their capabilities.

I also think something like this would be nice to have.
Title: Re: C# Suggestions
Post by: nuclearslurpee on March 03, 2021, 06:41:18 PM
While we are on the subject of Commanders, I would like to have some additional ground combat commander bonuses that reflect the terrain bonuses that are out there.  I was thinking about this the other night when I was playing - I always create a 'Federation Marine Corps' who have boarding and low-gravity fighting capabilities.  When I'm fighting wars, these are the guys I usually send after any Low-G colonies the enemy might have.  I have also recently created 'Raider Battalions' - Marines with High-G capability.  I think it would be great if we had a '<Capability> Modifer' so that certain commanders are adept Jungle, Desert, Low-G, or Mountain Fighters and that the auto-assignment code is biased to place those Commanders into formations with those capabilities.  It is a smaller thing but I think it would reward some specialization of formations by having dedicated commanders who are expert in their capabilities.

I also think something like this would be nice to have.

It's an interesting concept, but there are a couple of caveats for its inclusion into the game:

The combination of the first and last points I think make me worry that this mechanic would not really add anything to gameplay in terms of new and interesting decisions, rather just add a bit of RP fluff at the cost of potentially railroading some decisions. That's not a trade I would consider good to make for the design of the game.
Title: Re: C# Suggestions
Post by: liveware on March 03, 2021, 06:49:59 PM
Maybe it would be better to differentiate species and races as was done in VB6, so that one 'race' could contain several species each with a different environmental bonus.

But that seems to be in the 'not yet implemented pile'. Steve I hope you decide to bring this back!
Title: Re: C# Suggestions
Post by: Droll on March 03, 2021, 07:29:41 PM
While we are on the subject of Commanders, I would like to have some additional ground combat commander bonuses that reflect the terrain bonuses that are out there.  I was thinking about this the other night when I was playing - I always create a 'Federation Marine Corps' who have boarding and low-gravity fighting capabilities.  When I'm fighting wars, these are the guys I usually send after any Low-G colonies the enemy might have.  I have also recently created 'Raider Battalions' - Marines with High-G capability.  I think it would be great if we had a '<Capability> Modifer' so that certain commanders are adept Jungle, Desert, Low-G, or Mountain Fighters and that the auto-assignment code is biased to place those Commanders into formations with those capabilities.  It is a smaller thing but I think it would reward some specialization of formations by having dedicated commanders who are expert in their capabilities.

I also think something like this would be nice to have.

It's an interesting concept, but there are a couple of caveats for its inclusion into the game:
  • Redundant mechanic. Simply put, we already have capability modifiers so this is really just doubling down on a bonus that already exists.
  • Given the variety of terrain and other modifiers we have, there's a serious potential for the listing of commander traits to become quite long and unwieldy.
  • There is potential for this to make the choice of assigning a commander basically pointless because for a high-G or extreme temps formation you will always want to assign a high-G or extreme temps commander, rather than choosing from several commanders with different traits depending on the mission the formation will have. The easy way to avoid this is to make the skill so rare that players don't really get to use it. The hard way to do this is a lot of tedious balance testing.

The combination of the first and last points I think make me worry that this mechanic would not really add anything to gameplay in terms of new and interesting decisions, rather just add a bit of RP fluff at the cost of potentially railroading some decisions. That's not a trade I would consider good to make for the design of the game.

I think terrain based commander skills should only be earned if the commander actually spends combat rounds fighting in that terrain. It would make sense that a commander who fights on the frontlines of a desert planet will overtime become better at commanding troops in the desert.

Alternatively instead of just having troop capability, it might be cool to have elements "acclimatize" to various planet types as they spend combat rounds on those terrains. This would create situations where you have certain formations that are desert fighters, amphibious specialists, mountaineers, rangers, or jungle fighters because they spent a lot of time fighting in those environments. It would be a cool way to marry story telling with gameplay.
Title: Re: C# Suggestions
Post by: serger on March 04, 2021, 01:03:34 AM
In addition to the previous - there is a problem with current terrain GF specialization: it's nearly useless mechanics, because there are too much terrain types, so very small chance that some good part of current terrain-specialized formations will find another planet with the same terrain to be conquered before this formation will become outdated, and so terrain-specialized formations are really nearly one-time things. Combined with their cost and the fact that cost modifiers are cumulative - it is inevitable that players have no desire to use these specs.

I see several good ways to resurrect terrain specs:

1. Reduce their cost. (I'd consider to add, say, forest-spec to some of my first line formations, if it's cost will be no more than 10%.)
2. Make it's cost reducable (down to zero) by the terrain of home planet and the terrain of decent garrisoning / combat experience.
3. Add unit update mecanics, so we'll have a way to remove specs, that are useless now, and add what we need with the next big battle.
Title: Re: C# Suggestions
Post by: JacenHan on March 04, 2021, 03:00:56 PM
Related to the above, perhaps ground units could get free/reduced-cost specializations matching the planet they were built on? It would be interesting to build special training facilities in harsh environments. I also like the idea of unit acclimatization through combat/garrison experience.
Title: Re: C# Suggestions
Post by: anomaly63 on March 04, 2021, 10:09:56 PM
A button to copy the current fleet's orders to all fleets in the same system under the same naval admin would be useful.
Title: Re: C# Suggestions
Post by: TMaekler on March 05, 2021, 03:45:29 PM
A planetary fuel limit that prevents fuel transports to completely empty a planet from fuel. If any other ship refuels at that planet it can freely do so, but any fuel transport should not be able to empty the planet of fuel. If possible the same should apply to any space station that has a refueling hub. Only normal ships should be able to empty that spaceport.

A super nice bonus would be that the user gets a log warning message if a space station or planet is emptied to zero; and/or if a tanker or ship isn't completely refilled so you can check if that fleet is eventually run out of fuel in the future.
Title: Re: C# Suggestions
Post by: nuclearslurpee on March 05, 2021, 06:53:05 PM
A planetary fuel limit that prevents fuel transports to completely empty a planet from fuel. If any other ship refuels at that planet it can freely do so, but any fuel transport should not be able to empty the planet of fuel. If possible the same should apply to any space station that has a refueling hub. Only normal ships should be able to empty that spaceport.

A super nice bonus would be that the user gets a log warning message if a space station or planet is emptied to zero; and/or if a tanker or ship isn't completely refilled so you can check if that fleet is eventually run out of fuel in the future.

Piggyback/alternative: Allow a maximum fuel loading to be specified when a Refuel order is issued. I like to keep my tankers empty unless I'm absolutely swimming in fuel to make sure my planetary stocks can continually refuel my commercial fleets, so if I need to send a tanker off to support a fleet that only needs a third as much fuel as the tanker can carry I don't want to spend an extra month in port loading it up all the way, but other than calculating the loading time and firing a message from an idle ship there's no good way to accomplish this.
Title: Re: C# Suggestions
Post by: TMaekler on March 06, 2021, 10:49:52 AM
Piggyback/alternative: Allow a maximum fuel loading to be specified when a Refuel order is issued. I like to keep my tankers empty unless I'm absolutely swimming in fuel to make sure my planetary stocks can continually refuel my commercial fleets, so if I need to send a tanker off to support a fleet that only needs a third as much fuel as the tanker can carry I don't want to spend an extra month in port loading it up all the way, but other than calculating the loading time and firing a message from an idle ship there's no good way to accomplish this.
My issue is with the regular fleets coming by to refuel - directly after I filled a tanker for a mission. It then happens that in the regular fleet halve of the ships get filled and the rest swims along with tanks not refilled. They then can get stranded on their tour - which is annoying. I sure can manually equalize fuel - not nonetheless annoying.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on March 06, 2021, 10:52:56 AM
Piggyback/alternative: Allow a maximum fuel loading to be specified when a Refuel order is issued. I like to keep my tankers empty unless I'm absolutely swimming in fuel to make sure my planetary stocks can continually refuel my commercial fleets, so if I need to send a tanker off to support a fleet that only needs a third as much fuel as the tanker can carry I don't want to spend an extra month in port loading it up all the way, but other than calculating the loading time and firing a message from an idle ship there's no good way to accomplish this.
My issue is with the regular fleets coming by to refuel - directly after I filled a tanker for a mission. It then happens that in the regular fleet halve of the ships get filled and the rest swims along with tanks not refilled. They then can get stranded on their tour - which is annoying. I sure can manually equalize fuel - not nonetheless annoying.

Agreed. Tankers really, really need an equalize fuel command.
Title: Re: C# Suggestions
Post by: TMaekler on March 06, 2021, 03:07:34 PM
Recently run into the fighter refit and got stopped by the program to do so due to the 20% size difference limit. I think the idea behind being able to refit fighters is the minimization of micro. Great idea. But the 20% limit is limiting it too much at that low tonnages. Maybe, Steve, you can think about changing it? Lifting it for anything below 500t or expanding it?
Title: Re: C# Suggestions
Post by: papent on March 06, 2021, 07:41:59 PM
maybe a 20% or 500t whicher is larger rule?
Title: Re: C# Suggestions
Post by: Black on March 07, 2021, 05:31:08 AM
I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.
Title: Re: C# Suggestions
Post by: xenoscepter on March 07, 2021, 09:10:01 AM
I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.

 - Yeah, I was thinking this too, refitting a 100 Ton / 125 Ton ship into a 500 Ton vessel is like turning a little Prius into a friggin' Mac Truck... Just build a new one at that point. There should be some way to transfer crew to a new design though. Although to be honest, using the SM Mode to just... up the crew rating would fix that, since you could handwave it as, "We put the veteran fighter pilots into new ships."
Title: Re: C# Suggestions
Post by: papent on March 07, 2021, 11:36:06 PM
Personally I don't see any problem with Shipyard refits as at that small size point the entire spacecraft is smaller than LRU's for some larger vessels. Why not allow it? 

[IRL example]
Off-Topic: show

It does happen on RL designs for heavy/small military aircraft and small boats. I once had the pleasure of crewing an EC-130H that was a former WC-130 and before that spent time as a HC-130 that started it's USAF life as a slick C-130E. all those variants and the added mods in between had significant weight differences between them and greater than 20% of previously modification weight. That isn't even considering some of the franken airframes that make up the KC-135 fleet or B-1 fleet.

The U-2 various Electronic packages makeup over 50~25% of dry weight depending on package and that's a field level swap.

same can be said of ocean workboats, as they often do get refitted drastically when acquired by a different owner or for a new project. 


- Yeah, I was thinking this too, refitting a 100 Ton / 125 Ton ship into a 500 Ton vessel is like turning a little Prius into a friggin' Mac Truck...
i would compare it to a camper conversion of a truck or van. or bulking up a cruiser bike for a long trip.
Title: Re: C# Suggestions
Post by: TMaekler on March 07, 2021, 11:54:24 PM
I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.
As I wrote, the idea of the functionality is to lessen micromanagement. I also was thinking more in the line of my example - refitting a 410t ship into a 304t ship... . So if it is lifted fully or the % for below 500t is increased... .
Title: Re: C# Suggestions
Post by: Jorgen_CAB on March 08, 2021, 11:30:57 AM
I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.
As I wrote, the idea of the functionality is to lessen micromanagement. I also was thinking more in the line of my example - refitting a 410t ship into a 304t ship... . So if it is lifted fully or the % for below 500t is increased... .

I think it should stay the way it is... I see no reason why the rules should be different just because the ship is small, that make very little sense. Just because it might be inconvenient for fighters in general is not a good argument. We are only suppose to refit fighters with mainly fire-controls and other minor changes... otherwise we should just scrap them and build new ones.

The only issue is retaining the crew skill, but that is a different issue and should not be solved in changing the refit mechanics.
Title: Re: C# Suggestions
Post by: Droll on March 08, 2021, 02:44:54 PM
I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.
As I wrote, the idea of the functionality is to lessen micromanagement. I also was thinking more in the line of my example - refitting a 410t ship into a 304t ship... . So if it is lifted fully or the % for below 500t is increased... .

I think it should stay the way it is... I see no reason why the rules should be different just because the ship is small, that make very little sense. Just because it might be inconvenient for fighters in general is not a good argument. We are only suppose to refit fighters with mainly fire-controls and other minor changes... otherwise we should just scrap them and build new ones.

The only issue is retaining the crew skill, but that is a different issue and should not be solved in changing the refit mechanics.

I think the underlying problem is that it is annoying/time consuming to replace fighters which is why people want refitting to be easier for them, not that refit mechanics are bad for fighters. Some aspects of this will improve when 1.13 hits thanks to the carrier hoover mechanic.

Still, I would propose implementing a replace task for fighter factories. You tell them to replace a certain fighter design in orbit for the target design you selected. Mechanically, what this does is build a new copy of the modern fighter, then scrap an old fighter that is in orbit on the relevant body but not docked at a carrier at the body. This gives a quick and easy way to replace large numbers of outdated fighters.

Some error handling might be wanted to handle cases where the factories are told to replace more fighters than there are available to be replaced.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on March 08, 2021, 06:44:29 PM
I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.
As I wrote, the idea of the functionality is to lessen micromanagement. I also was thinking more in the line of my example - refitting a 410t ship into a 304t ship... . So if it is lifted fully or the % for below 500t is increased... .

I think it should stay the way it is... I see no reason why the rules should be different just because the ship is small, that make very little sense. Just because it might be inconvenient for fighters in general is not a good argument. We are only suppose to refit fighters with mainly fire-controls and other minor changes... otherwise we should just scrap them and build new ones.

The only issue is retaining the crew skill, but that is a different issue and should not be solved in changing the refit mechanics.

I think the underlying problem is that it is annoying/time consuming to replace fighters which is why people want refitting to be easier for them, not that refit mechanics are bad for fighters. Some aspects of this will improve when 1.13 hits thanks to the carrier hoover mechanic.

Still, I would propose implementing a replace task for fighter factories. You tell them to replace a certain fighter design in orbit for the target design you selected. Mechanically, what this does is build a new copy of the modern fighter, then scrap an old fighter that is in orbit on the relevant body but not docked at a carrier at the body. This gives a quick and easy way to replace large numbers of outdated fighters.

Some error handling might be wanted to handle cases where the factories are told to replace more fighters than there are available to be replaced.

A replace mecahnc seem like a good solution to that particular problem, I would be in favour if this. But I don't like to change the refit mechanic to do it.
Title: Re: C# Suggestions
Post by: Droll on March 08, 2021, 08:12:52 PM
I don't know, idea that I can refit 125t fighter to 500t design just because both are under 500t does not sit well with me.
As I wrote, the idea of the functionality is to lessen micromanagement. I also was thinking more in the line of my example - refitting a 410t ship into a 304t ship... . So if it is lifted fully or the % for below 500t is increased... .

I think it should stay the way it is... I see no reason why the rules should be different just because the ship is small, that make very little sense. Just because it might be inconvenient for fighters in general is not a good argument. We are only suppose to refit fighters with mainly fire-controls and other minor changes... otherwise we should just scrap them and build new ones.

The only issue is retaining the crew skill, but that is a different issue and should not be solved in changing the refit mechanics.

I think the underlying problem is that it is annoying/time consuming to replace fighters which is why people want refitting to be easier for them, not that refit mechanics are bad for fighters. Some aspects of this will improve when 1.13 hits thanks to the carrier hoover mechanic.

Still, I would propose implementing a replace task for fighter factories. You tell them to replace a certain fighter design in orbit for the target design you selected. Mechanically, what this does is build a new copy of the modern fighter, then scrap an old fighter that is in orbit on the relevant body but not docked at a carrier at the body. This gives a quick and easy way to replace large numbers of outdated fighters.

Some error handling might be wanted to handle cases where the factories are told to replace more fighters than there are available to be replaced.

A replace mecahnc seem like a good solution to that particular problem, I would be in favour if this. But I don't like to change the refit mechanic to do it.

The whole point is to solve the problem without touching the refit mechanics. The way the refit system does not favour small ships like fighters makes a lot of thematic sense anyways. It's generally not worth it to overhaul and redo something so small when you can recycle and make a new one cheaper. They didn't start turning F16s into F22s/F35s when they became available for a reason.
Title: Re: C# Suggestions
Post by: papent on March 08, 2021, 10:50:15 PM

The whole point is to solve the problem without touching the refit mechanics. The way the refit system does not favour small ships like fighters makes a lot of thematic sense anyways. It's generally not worth it to overhaul and redo something so small when you can recycle and make a new one cheaper. They didn't start turning F16s into F22s/F35s when they became available for a reason.

an more apt comparison would F-16Cs to F-16XL's or DC-10's to KDC-10's But again that's an real world example which has no place ingame.


It may be simpler to implement a simple change such as:
Code: [Select]
IF( (Original.ShipClass / New.ShipClass) < 0.2 ) == TRUE OR IF(New.ShipClass - Original.ShipClass <= 500) == TRUE then REFIT For refitting the small craft instead creation of an all new function to replace small craft using fighter factories to do so.
Why write new code that functionally that does the same thing as another part of the code? Also, that this new function may introduce new bugs.
Title: Re: C# Suggestions
Post by: serger on March 09, 2021, 12:23:42 AM
I'll add a notion, that Aurora tonns are not weight measure, but volume measure - it's a mass of liquid hydrogen, displaced by craft's hull, and there is no such thing in Aurora as above-water part of ship.
So, 20% - is 20% of hull's volume, that's not adding some heavy stuff inside the same hull.
I don't know a difference of volumes between F-16XL and F-16Cs, but I doubt it's much greater than 20%, the same as DC-10's / KDC-10.

And it's the purport of refit: you have to make some changes, but not to redo your hull.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on March 09, 2021, 02:23:23 AM
I'll add a notion, that Aurora tonns are not weight measure, but volume measure - it's a mass of liquid hydrogen, displaced by craft's hull, and there is no such thing in Aurora as above-water part of ship.
So, 20% - is 20% of hull's volume, that's not adding some heavy stuff inside the same hull.
I don't know a difference of volumes between F-16XL and F-16Cs, but I doubt it's much greater than 20%, the same as DC-10's / KDC-10.

And it's the purport of refit: you have to make some changes, but not to redo your hull.

In Aurora term this generally mean you can't change engine or weapons as these are hard defining of what the ship actually is.... a change to either is simply too much of a change and it is just cheaper to build a new fighter around the new engine or weapon. In general you might be able to change the fire-controls or maybe the sensors as long as they are not too big. An Aurora fighter is not like a jet fighter either as they are way bigger, more like a small real life Corvette or something.

Anyway... I could see a mechanic where you could "replace" the fighter and even retain the crew experience. Your factories would build a new fighter, scrap the old one and reuse the old crew in the new one. It would feel like it was refitted but it really is not.

In fact I think that regular ships could have something similar. If the new ship require more crew then new crew is added as if the ship received losses. If it require less crew the excess is added to to the crew pool. This would be a good way to retain experienced crew for older ship in a more "realistic" manner. But then... crew in this game can be around for hundreds of years which really is not very realistic to begin with. All ships should require some sort of crew rotation which should make experience do down to some equilibrium, the same goes for fleet training, but this is a different issue. Crew rotation should be part of the mechanic when your crew is resting. Some part of the crew is then replenished and experience and fleet training are changed accordingly. How much crew is replaced should be based on policy and the time the ship has been away. A ship that stay at port for a long time would have a small part of the crew replaced all the time, just like they pay a small amount of supplies all the time.
Title: Re: C# Suggestions
Post by: papent on March 09, 2021, 08:31:02 AM
Why create an new mechanic to do something that functionally already exist? An if then statement is a simpler task than creating an entire scrap and replace system.

If I remember correctly from VB6  Excess crew did return to the pool and it presumably should work or is planned to work the same in C#.

An Aurora fighter is not like a jet fighter either as they are way bigger, more like a small real life Corvette or something.

Like refitting an workboat, converting a cruiser to a carrier, making a Razee, or an Huey to Cobra.

But again IRL is irrelevant. If you must find a real-world grounding for this idea it does exist and has and will continue to occur, As I previously mentioned several times before.
It does happen on RL designs for heavy/small military aircraft and small boats. I once had the pleasure of crewing an EC-130H that was a former WC-130 and before that spent time as a HC-130 that started it's USAF life as a slick C-130E. all those variants and the added mods in between had significant weight differences between them and greater than 20% of previously modification weight. That isn't even considering some of the franken airframes that make up the KC-135 fleet or B-1 fleet.

The U-2 various Electronic packages makeup over 50~25% of dry weight depending on package and that's a field level swap.

same can be said of ocean workboats, as they often do get refitted drastically when acquired by a different owner or for a new project. 


If a grounding IRL you looking for it then that does exist, if a simplicity of operation in terms of game mechanics, how could we justify suggestion of creating a brand new mechanic and associated hooks into other parts of the code.
Title: Re: C# Suggestions
Post by: Droll on March 09, 2021, 11:00:31 AM
Why create an new mechanic to do something that functionally already exist? An if then statement is a simpler task than creating an entire scrap and replace system.

To add scalability in regards to micromanagement? Obviously this is not anything you cant do right now but its time consuming and tedious which is why this discussion exists in the first place...
We also want to avoid exception cases in the refit system since that was one of the main things about C# in general to make things more mechanically consistent.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on March 09, 2021, 11:03:40 AM
Why create an new mechanic to do something that functionally already exist? An if then statement is a simpler task than creating an entire scrap and replace system.

If I remember correctly from VB6  Excess crew did return to the pool and it presumably should work or is planned to work the same in C#.

An Aurora fighter is not like a jet fighter either as they are way bigger, more like a small real life Corvette or something.

Like refitting an workboat, converting a cruiser to a carrier, making a Razee, or an Huey to Cobra.

But again IRL is irrelevant. If you must find a real-world grounding for this idea it does exist and has and will continue to occur, As I previously mentioned several times before.
It does happen on RL designs for heavy/small military aircraft and small boats. I once had the pleasure of crewing an EC-130H that was a former WC-130 and before that spent time as a HC-130 that started it's USAF life as a slick C-130E. all those variants and the added mods in between had significant weight differences between them and greater than 20% of previously modification weight. That isn't even considering some of the franken airframes that make up the KC-135 fleet or B-1 fleet.

The U-2 various Electronic packages makeup over 50~25% of dry weight depending on package and that's a field level swap.

same can be said of ocean workboats, as they often do get refitted drastically when acquired by a different owner or for a new project. 


If a grounding IRL you looking for it then that does exist, if a simplicity of operation in terms of game mechanics, how could we justify suggestion of creating a brand new mechanic and associated hooks into other parts of the code.

All of the things that you point to is what I would constitute to being within the 20% margin as what the game represents as the constraints. There just need to be a hard limit as it is a game so the limit have to be at some point.

The issue is that it should not be different for a 125t fighter than what it is for a 12500t destroyer. It is all based on the change in cost of the parts to replace... if the cost is too great it is abstracted as too big of a change from the former design so it have to be a new design.

It is way better to introduce a mechanic to replace one design with another that also can transfer crew from one platform to the next. A system that scrap one item and build a new one in it's place.

This would be useful for both fighters and ships... I don't see why it should be limited to fighters only.

I also don't see why fighter factories can't refit and scrap fighters as well as build them, that is just odd to me as well. Why do you need shipyards to do that?!?
Title: Re: C# Suggestions
Post by: nuclearslurpee on March 09, 2021, 11:36:24 AM
I also don't see why fighter factories can't refit and scrap fighters as well as build them, that is just odd to me as well. Why do you need shipyards to do that?!?

I think ultimately the reason it is this way is that the factory GUI doesn't have a way to do so. Currently fighters are built from the exact same GUI as all other construction projects (unless built at a shipyard of course), so to add refit ability to fighter factories Steve would have to either fit new elements into that window or rewrite the window to switch GUI elements when fighter construction is selected.

Personally I'd like to see the former as it would be good to apply the same functionality to space stations, in that case not as much for crew training purposes as to be able to upgrade old tech to keep old stations in service since scrapping them is often inconvenient at best.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on March 09, 2021, 02:02:56 PM
I also don't see why fighter factories can't refit and scrap fighters as well as build them, that is just odd to me as well. Why do you need shipyards to do that?!?

I think ultimately the reason it is this way is that the factory GUI doesn't have a way to do so. Currently fighters are built from the exact same GUI as all other construction projects (unless built at a shipyard of course), so to add refit ability to fighter factories Steve would have to either fit new elements into that window or rewrite the window to switch GUI elements when fighter construction is selected.

Personally I'd like to see the former as it would be good to apply the same functionality to space stations, in that case not as much for crew training purposes as to be able to upgrade old tech to keep old stations in service since scrapping them is often inconvenient at best.

Yes... I think that adding some element to the GUI so we can refit, replace and scrap using both construction and fighter factories would be really nice.
Title: Re: C# Suggestions
Post by: TMaekler on March 10, 2021, 11:25:36 AM
Separating the two messages "civilian mining colony founded" and "extended". I don't care so much if they extend a colony, but I do care if I make it a "send me your minerals" or "I will milk money out of you" - mining complex. So if I could color the "founded" message different to "extended" would be great.
Title: Re: C# Suggestions
Post by: nuclearslurpee on March 10, 2021, 11:36:54 AM
I'd like to request a slight tweak to jump transit with mixed engine types in a fleet.

With the change to military/commercial drives only jumping engines of that type, I've found that trying to use paired mil/comm jump tenders is rather micro-intensive Trying to stick a naval fleet, a military jump tender (commercial ship & engines), and a commercial jump tender in one fleet doesn't work for jumping as you get the "no suitable jump drive" failure event. I guess Aurora still only uses one jump drive to transit an entire fleet and doesn't check if the fleet is able to transit using the combination of jump drives.

It would make life easier and make commercial jump tenders for military fleets less painful if the jump transit logic was adjusted to check for both military and commercial jump drives as necessary.
Title: Re: C# Suggestions
Post by: TMaekler on March 13, 2021, 05:27:28 AM
QoL to minimize micromanagement: A new command for ships to refit to a new class. You can add this command in the fleet tab. It check's if the shipyard has a free slipway and auto inserts itself into its queue. When done, the command is deleted - even if the fleet is set to cycle commands.
If at the time of checking the command there is no slipway free the command is kept alive - or if the fleet is on cycle commands, it is just skipped and added at the end of the queue and rechecked next time the fleet is back at the shipyard.
Title: Re: C# Suggestions
Post by: TMaekler on March 19, 2021, 07:01:09 AM
The system generator gave me a system with 291 Asteroids. They are unfortunately at a distance of 97 to 448bkm to the main star. A bit annoying to have to manually select the asteroids the exploration ship has to go to. Is there any way you can give us a special "go to closest system body" auto command which goes beyond the actual limit of I think 10bkm search radius?
Title: Re: C# Suggestions
Post by: nuclearslurpee on March 19, 2021, 11:22:49 AM
The system generator gave me a system with 291 Asteroids. They are unfortunately at a distance of 97 to 448bkm to the main star. A bit annoying to have to manually select the asteroids the exploration ship has to go to. Is there any way you can give us a special "go to closest system body" auto command which goes beyond the actual limit of I think 10bkm search radius?

Bit of a counter point: Having two orders to go survey a body is likely to confuse players, and the 10b km limit exists for a good reason with this system actually being a good example of that, if the nearest asteroid is 97b km your survey ships will almost certainly run out of fuel and get stranded in a very inconvenient place.

I would honestly take a hint from the game mechanics and leave the asteroid belt alone at that point, even exploiting it would be tricky at best, but if one does want to survey it I think having to manually manage that is a fair game, basically the Aurora version of 'sudo' in telling the game "Yes, I do think I know what I'm doing, let me screw things up the way I want to".  :P
Title: Re: C# Suggestions
Post by: Stormtrooper on March 19, 2021, 12:06:51 PM
I'd argue this limit could either be removed or configurable, this hurts especially with gas gaints with bazillion of moons just outside default range or binary systems even when you have lagrange points so that distance travelled is much shorter than distance between stars.

We have "survey nearest wreck" that is too automated because ships will automatically travel between systems to execute it, often ending up killed if the war is still raging on, meanwhile I can't even survey a big system without 28273651515 manual orders.

Also take into consideration that not all ships have the range to only go up to 10b km away and back, for my ships there are no systems big enough that'd prevent them exploring all, at least with real stars.
Title: Re: C# Suggestions
Post by: Droll on March 19, 2021, 02:13:12 PM
The system generator gave me a system with 291 Asteroids. They are unfortunately at a distance of 97 to 448bkm to the main star. A bit annoying to have to manually select the asteroids the exploration ship has to go to. Is there any way you can give us a special "go to closest system body" auto command which goes beyond the actual limit of I think 10bkm search radius?

Bit of a counter point: Having two orders to go survey a body is likely to confuse players, and the 10b km limit exists for a good reason with this system actually being a good example of that, if the nearest asteroid is 97b km your survey ships will almost certainly run out of fuel and get stranded in a very inconvenient place.

I would honestly take a hint from the game mechanics and leave the asteroid belt alone at that point, even exploiting it would be tricky at best, but if one does want to survey it I think having to manually manage that is a fair game, basically the Aurora version of 'sudo' in telling the game "Yes, I do think I know what I'm doing, let me screw things up the way I want to".  :P

I would agree but this messes up the automation of surveys, specifically the "go to system requiring geosurvey" standing order will make ships to to the system with the asteroid belt and just idle around there when there are other systems with more useful geosurvey targets. So being able to flag systems as "do not survey" or allowing some way to set up survey orders for them I think is a good idea.
Title: Re: C# Suggestions
Post by: nuclearslurpee on March 19, 2021, 02:15:04 PM
I would agree but this messes up the automation of surveys, specifically the "go to system requiring geosurvey" standing order will make ships to to the system with the asteroid belt and just idle around there when there are other systems with more useful geosurvey targets. So being able to flag systems as "do not survey" or allowing some way to set up survey orders for them I think is a good idea.

Excellent point I hadn't thought of. There is the flag we can set to mark a system for military access only but that's obviously a bit limiting as the only option.
Title: Re: C# Suggestions
Post by: TMaekler on March 19, 2021, 03:47:48 PM
Bit of a counter point: Having two orders to go survey a body is likely to confuse players, and the 10b km limit exists for a good reason with this system actually being a good example of that, if the nearest asteroid is 97b km your survey ships will almost certainly run out of fuel and get stranded in a very inconvenient place.

I would honestly take a hint from the game mechanics and leave the asteroid belt alone at that point, even exploiting it would be tricky at best, but if one does want to survey it I think having to manually manage that is a fair game, basically the Aurora version of 'sudo' in telling the game "Yes, I do think I know what I'm doing, let me screw things up the way I want to".  :P
Wanted to start a discussion about it. The 10bkm limit is a leftover from VB6 Aurora - where such gigantic systems weren't possible if I recall correctly; so it wasn't a big issue. Additionally, I don't think C# Aurora will slow down immensely if the search radius would be bigger.

My actual survey ship can fly roughly 190bkm - so it could fly back and forth. And I even have a special fuel ship that could accompany it to extend the range :-)

My main issue with that system is simply that there are over 290 of these asteroids. I surely won't fly to the outmost of them (448bkm which is what? Over a lightyear...), but a lot of them are in a belt between 90 and 120 bkm. I had send a ship there to begin investigating. But the space between them often is more than 10bkm... . Maybe Steve can make the search radius depending on the system. If the outmost object is 20bkm out, search in 10bkm radius. But if it is 200bkm why not allowing the search radius to be 20 or 30bkm to keep automation working and reflect the bigger spaces between objects? Or else a new base game parameter. Don't create objects beyond x bkm in system generation... .

Just floating out some ideas... .
Title: Re: C# Suggestions
Post by: nuclearslurpee on March 19, 2021, 04:00:58 PM
Bit of a counter point: Having two orders to go survey a body is likely to confuse players, and the 10b km limit exists for a good reason with this system actually being a good example of that, if the nearest asteroid is 97b km your survey ships will almost certainly run out of fuel and get stranded in a very inconvenient place.

I would honestly take a hint from the game mechanics and leave the asteroid belt alone at that point, even exploiting it would be tricky at best, but if one does want to survey it I think having to manually manage that is a fair game, basically the Aurora version of 'sudo' in telling the game "Yes, I do think I know what I'm doing, let me screw things up the way I want to".  :P
Wanted to start a discussion about it. The 10bkm limit is a leftover from VB6 Aurora - where such gigantic systems weren't possible if I recall correctly; so it wasn't a big issue. Additionally, I don't think C# Aurora will slow down immensely if the search radius would be bigger.

My actual survey ship can fly roughly 190bkm - so it could fly back and forth. And I even have a special fuel ship that could accompany it to extend the range :-)

My main issue with that system is simply that there are over 290 of these asteroids. I surely won't fly to the outmost of them (448bkm which is what? Over a lightyear...), but a lot of them are in a belt between 90 and 120 bkm. I had send a ship there to begin investigating. But the space between them often is more than 10bkm... . Maybe Steve can make the search radius depending on the system. If the outmost object is 20bkm out, search in 10bkm radius. But if it is 200bkm why not allowing the search radius to be 20 or 30bkm to keep automation working and reflect the bigger spaces between objects? Or else a new base game parameter. Don't create objects beyond x bkm in system generation... .

Just floating out some ideas... .

I certainly don't dislike the suggestion, I just like to look at the other side of things.

I wouldn't want to necessarily eliminate the limit entirely, as it is a useful limit to prevent survey ships from running about to extreme distances in systems with distant binaries or Oort clouds when they're not built to handle that or if the player doesn't want to waste all that fuel (why survey something that won't be easy to exploit with freighters, after all?). On the other hand, the current limit can definitely stand to be raised as even in the Sol system I usually have to manually control the last dozen or so surveys which involves searching through all the bodies and etc.

Maybe an increase to 30b km (Sol system diameter, roughly) would be a good compromise and easy enough for Steve to implement as it's just changing one constant in the code. That should be large enough to automatically survey those distant belts, after giving a single order to jump-start things, which should be a good compromise as the player still has to "give permission" to survey those big systems, but hopefully only once or twice.
Title: Re: C# Suggestions
Post by: Polestar on March 19, 2021, 05:29:18 PM
Perhaps replace the 10b km limit on auto-survey with two time- and fuel-based triggers?

IF, time needed to reach the next closest unsurveyed body or destination is greater than 180 days,
OR, if fuel is expected to run out before reaching the destination,
THEN, cancel the automatic survey order and state why.

ELSE IF, time needed to reach the next closest unsurveyed body or destination is greater than 60 days,
OR, if fuel remaining at destination is expected to be less than the limit set by the player (or 10% if no limit was specified),
THEN, continue but issue a warning with the expected transit time or fuel remaining.

Title: Re: C# Suggestions
Post by: nuclearslurpee on March 19, 2021, 07:36:59 PM
Perhaps replace the 10b km limit on auto-survey with two time- and fuel-based triggers?

IF, time needed to reach the next closest unsurveyed body or destination is greater than 180 days,
OR, if fuel is expected to run out before reaching the destination,
THEN, cancel the automatic survey order and state why.

ELSE IF, time needed to reach the next closest unsurveyed body or destination is greater than 60 days,
OR, if fuel remaining at destination is expected to be less than the limit set by the player (or 10% if no limit was specified),
THEN, continue but issue a warning with the expected transit time or fuel remaining.

Conditional standing orders would definitely solve this and many other issues which are raised on a frequent basis. It has been suggested quite often but thus far we have seen no movement in this direction. I believe based on similar discussions about (regular) movement orders that Steve worries it would cause too many spurious bug reports.
Title: Re: C# Suggestions
Post by: TMaekler on March 22, 2021, 12:39:07 PM
Seems like that there is no message in the log that indicates that a fleet couldn't be refueled to it's max capacity. A bit annoying realizing this when the 20% warnings begin to pop up whilst the fleet is already underway and way out.

Could you add such a warning message when refueling doesn't fill up? Thanks.
Title: Re: C# Suggestions
Post by: Droll on March 22, 2021, 01:30:57 PM
Seems like that there is no message in the log that indicates that a fleet couldn't be refueled to it's max capacity. A bit annoying realizing this when the 20% warnings begin to pop up whilst the fleet is already underway and way out.

Could you add such a warning message when refueling doesn't fill up? Thanks.

I would like to add that this might be difficult to do for underway replenishment but is a really good idea for stationary refueling, both planetary and tanker based.
Title: Re: C# Suggestions
Post by: TMaekler on March 22, 2021, 03:09:55 PM
I would like to add that this might be difficult to do for underway replenishment but is a really good idea for stationary refueling, both planetary and tanker based.
That is true. Don't need message spam during an underway replenishment  ;)
Title: Re: C# Suggestions
Post by: xenoscepter on March 24, 2021, 07:27:04 PM
 - I'd like to see weaponized tractor beams, to be honest. Have ships that can use their tractor beam to "latch on" for the purposes of boarding actions, maybe a special kind of Tractor Beam that's smaller and can't tug things? Perhaps instead have a Troop Transport Bay that is heavier than a normal Boarding Bay, but has the function of buffing the success chance. Maybe some sort of "Boarding Harpoon" that can be fired like a normal weapon, at range that is, and makes boarding way easier, but also slows down both ships... with the faster and/or bigger ones getting advantages over slower and/or smaller ones.
Title: Re: C# Suggestions
Post by: Vivalas on March 24, 2021, 09:12:24 PM
This has probably been suggested in some form but having cargo bays be able to transport formations consisting solely of logistical elements would be a nice little boost to logistics for protracted ground combat, while also making a good deal of thematic sense. (Logistical elements embedded inside formations don't necessarily 'disappear' when they are used. A batallion of men can't eat a truck, no matter how hungry they are! The transports are simply hauling supplies to replenish the ground forces with)
Title: Re: C# Suggestions
Post by: xenoscepter on March 24, 2021, 09:23:12 PM
This has probably been suggested in some form but having cargo bays be able to transport formations consisting solely of logistical elements would be a nice little boost to logistics for protracted ground combat, while also making a good deal of thematic sense. (Logistical elements embedded inside formations don't necessarily 'disappear' when they are used. A batallion of men can't eat a truck, no matter how hungry they are! The transports are simply hauling supplies to replenish the ground forces with)

 --- I don't recall when, where or specifically what, but I do recall saying something of the sort somewhere around here. I don't remember exactly why, but I do remember Steve himself replying about, if I recall correctly, not wanting GSP to be another thing for the player to manage. I believe I said something along the lines of having GSP work like MSP, in that you produced it and ground units consumed it. You'd have the LOG and LOG-S then functioning analogously to the Maintenance Storage Bays on ships, except for Ground Units instead. Take this with a small mountain of salt though, as the memory is vague at best...
Title: Re: C# Suggestions
Post by: TMaekler on March 25, 2021, 04:51:29 PM
Instead of turning fuel and MSP production on and off, why not giving them the option for a set value. With tools like AuroraMarvin you can easily see if you begin to run out of fuel or MSP and simply increase your MSP/fuel production accordingly (instead of having to switch them on and off every now and then). Of course, you should not be able to set above planetary maximum. But being able to set to any percentage between 0 and 100 would be a nice QoL.
Title: Re: C# Suggestions
Post by: xenoscepter on March 27, 2021, 05:40:17 PM
 - Can we have an option to make Jump Drives Self-Jump only on purpose? I'd like the option for this since each Jump Drive would be cheaper, and because I'd like to make Jump Carriers that don't really need the squadron jump anyway. Maybe have them be smaller too? Options are always nice to have. :)
Title: Re: C# Suggestions
Post by: nuclearslurpee on March 27, 2021, 06:24:55 PM
- Can we have an option to make Jump Drives Self-Jump only on purpose? I'd like the option for this since each Jump Drive would be cheaper, and because I'd like to make Jump Carriers that don't really need the squadron jump anyway. Maybe have them be smaller too? Options are always nice to have. :)

Self jump-only drives don't have any special cost reduction, so I'm not sure what the point would be as it's not hard to just RP this restriction. Unless you're suggesting reworking how jump drive design works so that self-jump drives are cheaper, which would be a different matter.
Title: Re: C# Suggestions
Post by: xenoscepter on March 27, 2021, 06:26:29 PM
- Can we have an option to make Jump Drives Self-Jump only on purpose? I'd like the option for this since each Jump Drive would be cheaper, and because I'd like to make Jump Carriers that don't really need the squadron jump anyway. Maybe have them be smaller too? Options are always nice to have. :)

Self jump-only drives don't have any special cost reduction, so I'm not sure what the point would be as it's not hard to just RP this restriction. Unless you're suggesting reworking how jump drive design works so that self-jump drives are cheaper, which would be a different matter.

 - http://aurora2.pentarch.org/index.php?topic=12035.0 "Jump drive costs are no longer affected by squadron size if the drive is self-jump only." They are cheaper.
Title: Re: C# Suggestions
Post by: Zap0 on March 27, 2021, 07:34:37 PM
That just means they're the same cost as if you selected squadron size 3, the minimum, I take it, not some extra cost reduction beyond that.
Title: Re: C# Suggestions
Post by: Kristover on March 27, 2021, 07:49:17 PM
Suggestion: I have advocated earlier for the addition or readjustment of conditions for medal awarding (example:  Survey 25 Systems, Destroy 50 Missiles, etc).  I was looking at the categories today and I think I'm fine with the existing categories but is it possible to add an adjustment that allows us to change the condition through the game UI?  Say instead of a condition, 'Discover 3 Habitable Worlds' I could adjust it to 'Discover 2 Habitable Worlds' if I wanted without diving into the DB?  I'm not sure this would be hard to add because we already are able to modify the promotion points per medal so it seems that this could be done without a lot of additional work.
Title: Re: C# Suggestions
Post by: xenoscepter on March 27, 2021, 08:18:38 PM
That just means they're the same cost as if you selected squadron size 3, the minimum, I take it, not some extra cost reduction beyond that.

 - Ah, that makes sense then. Cheers! In that case though, I would like to instead request a Self-Jump Only option that makes a drive cheaper and slightly more efficient at the cost of being... well self-jump only. :P Have it be at the bottom of Squadron Jump Size, and have it unlocked by default perhaps? Or unlocked with Squadron Jump Size 3 would be far, FAR simpler. That or a "Compact Jump Drive" tech that is ruins and/or Spoiler only, that only has a Drive Size and Drive Range tech. Make it so that it's cheaper, more efficient and self-jump only. I'm not too amendable to this idea myself, but it could be an option.

 - One other thing would be a Compact Jump Drive that the player can research as a separate tech. It would be way more efficient, but costlier, have no engine restrictions, but be self-jump only. With the added caveat that it could be mounted in addition to a normal Jump Drive, so our Commercial / Military Tenders could mount whatever they needed to move their intended "cargo", and have one for themselves to move... erm, well themselves! ;D
Title: Re: C# Suggestions
Post by: nuclearslurpee on March 27, 2021, 08:40:35 PM
Suggestion: I have advocated earlier for the addition or readjustment of conditions for medal awarding (example:  Survey 25 Systems, Destroy 50 Missiles, etc).  I was looking at the categories today and I think I'm fine with the existing categories but is it possible to add an adjustment that allows us to change the condition through the game UI?  Say instead of a condition, 'Discover 3 Habitable Worlds' I could adjust it to 'Discover 2 Habitable Worlds' if I wanted without diving into the DB?  I'm not sure this would be hard to add because we already are able to modify the promotion points per medal so it seems that this could be done without a lot of additional work.

This would be really nice actually, if we could have a single numeric variable for each condition. Would require an extra column in the DB and another UI element but would solve so many complaints about the medal conditions.
Title: Re: C# Suggestions
Post by: xenoscepter on March 27, 2021, 09:00:14 PM
 - One other suggestion that sprung to mind when thinking about Self-Jump Drives... using Gravitational Survey Sensors to detect ships Jumping in. Perhaps every one point of Gravitational Sensor translating to 1 billion km of detection? Maybe have Science Department enhance it?
Title: Re: C# Suggestions
Post by: Droll on March 27, 2021, 09:18:51 PM
- One other suggestion that sprung to mind when thinking about Self-Jump Drives... using Gravitational Survey Sensors to detect ships Jumping in. Perhaps every one point of Gravitational Sensor translating to 1 billion km of detection? Maybe have Science Department enhance it?

You could perhaps rig it so that based on the various parameters of the Jump drive, upon entering a system it emits an EM pulse for 5-15secs (or maybe during the jump shock period) which can then be picked up on EM passives. You could also have it be on the gravitational sensor which would give that component an actual combat use. However, from an implementation standpoint the EM version is probably easier.

It would definitely make it easier to use static defenses to defend jump points with self-guided active missiles or at the very least make deep space tracking stations much more viable for detection.
Title: Re: C# Suggestions
Post by: TMaekler on March 28, 2021, 01:13:52 AM
Could we have waypoints that are linked to an object like a planet and they keep moving with that object? I don't mean directly on that object but more like a patrol point around that object, i.e. at a certain distance. I would love to set up patrol routes around planets and moons - and those "orbital waypoints" would be a great help with this.
Title: Re: C# Suggestions
Post by: nuclearslurpee on March 28, 2021, 11:26:57 AM
Could we have waypoints that are linked to an object like a planet and they keep moving with that object? I don't mean directly on that object but more like a patrol point around that object, i.e. at a certain distance. I would love to set up patrol routes around planets and moons - and those "orbital waypoints" would be a great help with this.

Piggyback: the ability to tell a fleet to move to or follow a target at a specified distance and heading. I'm sick of having to eyeball a new waypoint placement every time I just want a fleet to move away from a hostile contact on a 45-degree heading instead of directly opposite.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on March 29, 2021, 07:28:09 AM
Could we have waypoints that are linked to an object like a planet and they keep moving with that object? I don't mean directly on that object but more like a patrol point around that object, i.e. at a certain distance. I would love to set up patrol routes around planets and moons - and those "orbital waypoints" would be a great help with this.

Piggyback: the ability to tell a fleet to move to or follow a target at a specified distance and heading. I'm sick of having to eyeball a new waypoint placement every time I just want a fleet to move away from a hostile contact on a 45-degree heading instead of directly opposite.

Yes... I have suggested some similar things before... a waypoint that is tied to another object (range and heading) which could be a ship or a planet would be nice. This would be very helpful for so many reasons.
Title: Re: C# Suggestions
Post by: TMaekler on March 30, 2021, 01:46:36 PM
Being able to define for each LaGrange-Point if it should be used or not.
Title: Re: C# Suggestions
Post by: kilo on April 01, 2021, 12:55:38 PM
I would like to suggest something regarding scuttling ships and boarding combat.


The goal of a captain in the navy should be to scuttle the ship so that no useful equipment can be captured by the enemy. This means the ship shall not fall into enemy hands as a hole or in parts via salvaging. To achieve that, I would suggest that captains try to blow up their ships by overloading their remaining drives and power plants causing them to explode.

The same thing should be done automatically when an enemy force tries to commandeer the ship. There should be a certain chance that the crew blows up the remaining reactors to destroy their ship and the invading force before they manage to kill off the crew.


What do you guys think about it?
Title: Re: C# Suggestions
Post by: nuclearslurpee on April 01, 2021, 01:48:03 PM
I would like to suggest something regarding scuttling ships and boarding combat.


The goal of a captain in the navy should be to scuttle the ship so that no useful equipment can be captured by the enemy. This means the ship shall not fall into enemy hands as a hole or in parts via salvaging. To achieve that, I would suggest that captains try to blow up their ships by overloading their remaining drives and power plants causing them to explode.

The same thing should be done automatically when an enemy force tries to commandeer the ship. There should be a certain chance that the crew blows up the remaining reactors to destroy their ship and the invading force before they manage to kill off the crew.


What do you guys think about it?

This isn't really accurate for real-life wet navies, as historically prevention of salvaging has rarely, if ever, been a priority. Admittedly this is partly due to the fact that salvage operations for wet navies are relatively more difficult than they are for Aurora navies, but really the value of salvage is not so much as to justify the added expense, complexity, and risk of equipping a ship to totally obliterate itself beyond what is needed to render it wrecked.

Mechanically, I don't see this being added as it's really just not a fun mechanic to deny the opponent salvage. If the NPR can use the mechanic, it's not fun for a player, and if the NPRs can't use the mechanic it's yet another advantage for the player and I don't see Steve coding a mechanic purely to give the player an advantage over the hapless AIs. I can't recall if you can 'Abandon Ship' while being boarded, though I know people did this in VB6, but if you can I think that should be sufficient for RP purposes.
Title: Re: C# Suggestions
Post by: nuclearslurpee on April 02, 2021, 12:13:51 PM
Suggestion: Buff ground surveys.

Presently, ground surveys are so minimally beneficial that it's questionable whether they're worth the vendarite to build + fuel to ship around the galaxy. The reason for this is that the actual benefits of a survey are quite small in practical terms: on one hand, finding new mineral deposits is not very useful because they are usually at minimal (0.1) accessibility; on the other hand, raising the accessibility of an existing deposit most frequently ends up raising a low-accessibility deposit by 0.1 or 0.2 accessibility, which rarely if ever raises a body to "worth mining" status. In practice, it's quite rare to find a surveyable body which was already worth mining and then to get a strong result from the survey.

As a suggested revision of the mechanic, I would suggest keeping the existing probabilities for survey results (for Minimal, Low, Good, etc. survey potential ratings) but increase the accessibility of any findings - I don't think it would be imbalanced if new deposits had an accessibility of 0.5 and raising accessibility gave +0.5 instead of +0.1. Even 0.7 would not be unreasonable, given the probability of finding a mineral type you don't care much about, but I think 0.5 would at least be sufficient to make ground surveys worth the investment.
Title: Re: C# Suggestions
Post by: QuakeIV on April 02, 2021, 12:32:43 PM
That seems reasonable to me personally.  I usually dont bother with it unless an already-mineable place is surveyable.

Honestly I feel like it used to be that pretty much anywhere could be surveyed, which did cause me to do it more often because my mining worlds at least could usually benefit from it.
Title: Re: C# Suggestions
Post by: anomaly63 on April 02, 2021, 11:16:54 PM
The Scrap Component button should scrap the top-most component if no component is selected.   Alternatively, there should be a 'Scrap All' button.   
Title: Re: C# Suggestions
Post by: TMaekler on April 03, 2021, 02:24:09 AM
Mass Driver ship module

Wouldn't it be nice if a mining ship fleet also could have an additional ship with a mass driver module that can send mineral packages to a base planet or space station to collect minerals? Or if you could build a mineral collection base close to a jump point, set up a small transfer line to a space station on the other side of the wormhole and continue mineral transport from there?
Title: Re: C# Suggestions
Post by: TMaekler on April 03, 2021, 02:33:22 AM
Choke Point circumvention via temporal wormhole

How about a new type of temporal wormhole generator ship module? With that module, one can create a temporal exit point on an existing jump point connection that is up to 10bkm away from the regular jump point exit. This temporal exit will be open for a few days only and needs at least two years to generate. It also can be archived in the target system once every 20 to 30 years (so no temporal spamming).

Maybe it can be included with a tech line to generate it quicker or keep it open for some days more?

The goal is to archive two things: of course, avoiding jump point slaughter as a key strategic element of surprise in a war situation (but to avoid overuse have it limited as described). And deploying stealth ships without them being detected when coming through the default jump point exit.
Title: Re: C# Suggestions
Post by: Demonides on April 03, 2021, 02:33:36 AM
Mass Driver ship module

Wouldn't it be nice if a mining ship fleet also could have an additional ship with a mass driver module that can send mineral packages to a base planet or space station to collect minerals? Or if you could build a mineral collection base close to a jump point, set up a small transfer line to a space station on the other side of the wormhole and continue mineral transport from there?

↑ This ↑
Title: Re: C# Suggestions
Post by: Demonides on April 03, 2021, 02:35:04 AM
Choke Point circumvention via temporal wormhole

How about a new type of temporal wormhole generator ship module? With that module, one can create a temporal exit point on an existing jump point connection that is up to 10bkm away from the regular jump point exit. This temporal exit will be open for a few days only and needs at least two years to generate. It also can be archived in the target system once every 20 to 30 years (so no temporal spamming).

Maybe it can be included with a tech line to generate it quicker or keep it open for some days more?

The goal is to archive two things: of course, avoiding jump point slaughter as a key strategic element of surprise in a war situation (but to avoid overuse have it limited as described). And deploying stealth ships without them being detected when coming through the default jump point exit.

Or maybe something like a jump bridge with EvE-O?
Title: Re: C# Suggestions
Post by: idefelipe on April 03, 2021, 03:35:55 AM
Hello Steve!

First off, thanks again for the amazing work you are doing.

Recently I have found a "new way" (for me) to play Aurora and it is slow, tasting each 5 days pulse, creating a diary with the events, roleplaying the characters situations, the orders from the goverment, giving background to each of the steps I take, etc. This is a very slow pace for the game, in 15 hours I have advanced 27 years or so, but I found that incredibly the game gets a new level of deep and complexity.

Thanks to this diary I am creating (in an excel, of course, hahaha) I can follow the careers of the characters. I always have considered the characters in the game as a key feature of Aurora and it gives to the game a new level that no other game, of this style, has (maybe rimworld or dwarf fortress are at the same level). I really love how you implemented the characters, the careers, the records of their achievements, the medals and how they affect to the characters career, the traits...

When I learnt how to "include" all this in a somekind of diary and background, the histories crossing different characters started inmediately. Rivalries, families and dinasties, using the promotion score to find the best and more capable officers when graduate, friends, etc.

I say all this because there is one thing that is a bit annoying (I don't know if that is the correct word, excuse my english I'm spanish). When a character dies, he/she automatically is removed from the database and I can't take a last look to his profile and remember all the things he/she have done in the playthrough. Now, with my diary, I have a lot of things and with a quick search I can remember the most important events related to the character, but I would really love to take one last look to the profile and get a pic for the records on those best and more reknown officers.

I understand that keepin all the characters in the database is insane and will affect dramatically to the performance, so I have though that you could implement somekind of "Grace Period" of, for example, 30 days pulse (for those who plays with that pulse), before the character is removed. I am not programmer and don't know if it is possible or it is a crazy thing, but that would allow to those crazy players like me, that are following the careers of the officers, to take one last look to the profile and give that small though as final tribute to the characters that have been starrings of the history for many years.

What do you thing? Is it possible?

Thanks!

PS: Yeah, it is possibly the same as the feature that includes extra weight for custom installations in ships without in-game benefits and not many players will use it... but, you would make some of us very very happy :)
Title: Re: C# Suggestions
Post by: Vivalas on April 03, 2021, 07:03:56 PM
If there was a feature where you could issue an order to every ship in a naval admin command (and the same for standing orders), that would be a complete godsend and an amazing organizational tool.

E.g., refitting your fleet in waves. For example, I have new, more fuel efficient engines, but only so many shipyards. I can issue a "admin order" or something to Explorationary Squadron 1, so every ship returns to earth to refit in that fleet, and then I can send them all back out as well and re-set their standing orders much easier (in addition to combined "admin orders", any standing orders issued to a naval admin command would also override every fleet's standing orders below it, for easy organization. So instead of clicking 4 boxes on 10 different fleets, I click 4 boxes on the admin command and voila). After Squadron 1 is done and outbound again for the stars, I bring in squadron 2 and rinse and repeat. Far less clicking and headache.
Title: Re: C# Suggestions
Post by: papent on April 09, 2021, 11:53:39 AM
A minor suggestion and an expansion of the Misc component Idea

Miscellaneous Ship Officer Stations
You design the components on the Create Research Projects window by:

Cost is equal to size in HS and the mineral requirements are split between 20% Duranium and 80% Corbomite. The HTK is equal to the square root of the size. additional the officer improves the skill required by the ship station up to 1% or 1 per year per HTK of the component. [ballparking some figures]

two example Officer Stations

Code: [Select]
Internal Security Control
Cost 100   Size 100 tons   Crew 15   HTK 1
Officer: Ground Force Officer
Rank: Major
Skill: Ground Combat Defence
Base Chance to hit 100%
Materials Required: Duranium  20    Corbomite  80   

Code: [Select]
Civil Logistic Liaison
Cost 200   Size 200 tons   Crew 30   HTK 2
Officer: Civilian Administrator
Rank: Admin Rating 1
Skill: Logistics
Base Chance to hit 100%
Materials Required: Duranium  40    Corbomite  160   

thoughts?

Edited: Change Rank Idea with RougeNPS input.
Title: Re: C# Suggestions
Post by: RougeNPS on April 09, 2021, 01:58:04 PM
I really like your idea but i have one thing to add.

Have no restriction on what rank you can make for it. Just as a way of eating up extra officers if you have a massive pool of them. Although i guess it would make it harder for them to stand out if they are in a position doing nothing. It would make more sense.
Title: Re: C# Suggestions
Post by: StarshipCactus on April 10, 2021, 10:37:11 PM
I think it would be great if one faction could contract another faction to tug shipyards to different planets.
Title: Re: C# Suggestions
Post by: bsh on April 11, 2021, 12:50:26 PM
My list of suggestions (or wishes):
- some kind of search function on the galactic map, to center on a given system. also zoom would be great again. (iirc there was zoom in VB6 version?)
- possibility to delete connection between two jump points and make them undiscovered again. (iirc this was in the VB6 version?) without having to delete and recreate the jump point(s) itself.
- sector colors
- automated commander assignments for sectors and admin commands as well.
- possibility to exclude certain bonuses when searching or assigning admins. for example, i don't want to use any colony admins with population growth bonus.
- scrapping of unneeded installations
- returning prisoners to their own race, (maybe for some extra DR boost.)
- an optimized algorithm for civilian contracts would be good: it should consider nearby but busy ships as well, calculating when they unload their current cargo and become available and how long they take to get to the pickup location, instead of just picking random idle ships from the other side of the galaxy who literally take months and months to even get to pickup.
Title: Re: C# Suggestions
Post by: Pesinario on April 12, 2021, 11:40:27 AM
It would be nice to be able to give a condition to a fleet to do X (most likely resupply and overhaul) after MSP falls below max repair, it's common for me to have fleets with over 20% MSP get a maintenance failure that breaks the only engine, since the MSP of the engine is more than 20% my reserves
Title: Re: C# Suggestions
Post by: nuclearslurpee on April 12, 2021, 12:01:06 PM
Please change the rank ratio for ground forces to be 4:1 (as I believe it was in VB6).

The current 3:1 is not feasible for trying to model any modern military formation structure post-WWI era. The change was made for C# along with the 2:1 ratio (was 3:1) for naval officers, however ground forces did not receive the non-command roles as naval officers did, so there is no good reason for the change to 3:1 ratio.

Many people would prefer to see non-command roles added. I agree, but as this would be extra work I would rather have the reversion to 4:1 ratio than no change at all.
Title: Re: C# Suggestions
Post by: Barkhorn on April 12, 2021, 06:04:33 PM
Please change the rank ratio for ground forces to be 4:1 (as I believe it was in VB6).

The current 3:1 is not feasible for trying to model any modern military formation structure post-WWI era. The change was made for C# along with the 2:1 ratio (was 3:1) for naval officers, however ground forces did not receive the non-command roles as naval officers did, so there is no good reason for the change to 3:1 ratio.

Many people would prefer to see non-command roles added. I agree, but as this would be extra work I would rather have the reversion to 4:1 ratio than no change at all.
Why not just let us set our own ratios?
Title: Re: C# Suggestions
Post by: nuclearslurpee on April 12, 2021, 06:06:14 PM
Please change the rank ratio for ground forces to be 4:1 (as I believe it was in VB6).

The current 3:1 is not feasible for trying to model any modern military formation structure post-WWI era. The change was made for C# along with the 2:1 ratio (was 3:1) for naval officers, however ground forces did not receive the non-command roles as naval officers did, so there is no good reason for the change to 3:1 ratio.

Many people would prefer to see non-command roles added. I agree, but as this would be extra work I would rather have the reversion to 4:1 ratio than no change at all.
Why not just let us set our own ratios?

This would be even better but I dare not set my hopes on the impossible.  :P
Title: Re: C# Suggestions
Post by: Demetrious on April 18, 2021, 02:22:05 PM
Am I the only one who feels it would be appropriate to have another mission type for ground support fighters called "Suppress STO?" This would allow ground support fighters to attack revealed STO elements without fear of reprisal. Weapons built to engage starships at quarter-light-second distances wouldn't be able to engage low-flying fighters. It'd also obligate hostile ground forces to assign AA units to their STO formations.

Using airpower to attack rear-echelon troops like this is standard military practice, but given the importance of STO units - and the fact that they reveal their location when they fire by dint of their massive power plants and output - it makes sense that we'd be able to attack them directly. It would also go a long way towards solving the current collateral damage problems in the game - while collateral damage values may need tweaking eventually, the fact that the only viable way of suppressing STO's is with direct naval bombardment certainly doesn't help. While free-ranging Seek and Destroy missions might well find and engage STO units already, the chance is greatly diluted by all the normal ground combat formations... which is the entire point of having STO units hold fire to begin with; to hide them and retain a threat that can "pop up" later to surprise enemy space assets trying to move in and provide close support. (Much how modern SAM systems are often used.)

This would help make ground fighters far more crucial for allowing the capture of a planet without mass devastation of population and infrastructure and, conversely, make AAA defenses much more important for repelling invasions. A combination of AAA and STO units would be instrumental in denying the enemy orbital superiority, making it hard for them to land troops, resupply them, or provide orbital bombardment support.

This change should probably wait till the version after next, however, as the STO bug that let them fire on fighters on ground support missions has prevented anyone from playtesting how fighters v. STO's work with the extant rules.
Title: Re: C# Suggestions
Post by: Warer on April 19, 2021, 08:41:44 AM
Horrible no good balance-shattering component number i8182401840 (Does it count as not serious if I would like to see it just think its very very unlikely?)
External Fighter Clamps/Collar
Cost 50 Size 550 Crew 10 HTK 0/1
Base Chance to hit 100%
Materials Required: Duranium  25    Vendarite  75
Capacity 1000tons
-Half-size military hangar bay that acts like a commercial hanger but is as capable as Hangar Deck while half the size and can, obviously be used on military carriers. Double capacity is meant to be balanced by lack of deployment time pause, and possibly not being able to reload missiles and or maintenance supplies if that proves not enough. Thus a carrier that can carry more fighters but is more expensive and even more vulnerable to fire. Though this would allow for more compact carriers as well.

And here are current a hangar components minus commercial hangers

Hangar Deck
Cost 100   Size 1,050 tons   Crew 15   HTK 4
Base Chance to hit 100%
Materials Required: Duranium  25    Vendarite  75   

Boat Bay - Small
Cost 18   Size 150 tons   Crew 3   HTK 0
Base Chance to hit 100%
Materials Required: Vendarite  18   

Boat Bay
Cost 30   Size 300 tons   Crew 5   HTK 1
Base Chance to hit 100%
Materials Required: Vendarite  30     
Title: Re: C# Suggestions
Post by: nuclearslurpee on April 19, 2021, 10:33:35 AM
Horrible no good balance-shattering component number i8182401840 (Does it count as not serious if I would like to see it just think its very very unlikely?)
External Fighter Clamps/Collar
Cost 50 Size 550 Crew 10 HTK 0/1
Base Chance to hit 100%
Materials Required: Duranium  25    Vendarite  75
Capacity 1000tons
-Half-size military hangar bay that acts like a commercial hanger but is as capable as Hangar Deck while half the size and can, obviously be used on military carriers. Double capacity is meant to be balanced by lack of deployment time pause, and possibly not being able to reload missiles and or maintenance supplies if that proves not enough. Thus a carrier that can carry more fighters but is more expensive and even more vulnerable to fire. Though this would allow for more compact carriers as well.

And here are current a hangar components minus commercial hangers

Hangar Deck
Cost 100   Size 1,050 tons   Crew 15   HTK 4
Base Chance to hit 100%
Materials Required: Duranium  25    Vendarite  75   

Boat Bay - Small
Cost 18   Size 150 tons   Crew 3   HTK 0
Base Chance to hit 100%
Materials Required: Vendarite  18   

Boat Bay
Cost 30   Size 300 tons   Crew 5   HTK 1
Base Chance to hit 100%
Materials Required: Vendarite  30     


Half size isn't going to make much of a difference except maybe in build cost, as the actual size of a carrier is going to have to be scaled up to what it's actually carrying (for purposes of calculating speed, sensor signature, etc.), so you're not saving any tonnage unless the carrier is empty. Unless you're suggesting that a hangar with 550 tons size can carry 1000 tons of fighters and still be considered 550 tons for speed, sensor, etc. purposes, which doesn't make sense.

Given that the existing hangar component essentially "maths out" as 50 tons of component and 1000 tons of fighter space, I'm not sure why not just RP it as an external clamp if you want to. Gripper arms plus refueling and transfer tubes displacing 50 tons seems reasonable to me.
Title: Re: C# Suggestions
Post by: Warer on April 19, 2021, 03:59:22 PM
Horrible no good balance-shattering component number i8182401840 (Does it count as not serious if I would like to see it just think its very very unlikely?)
External Fighter Clamps/Collar
Cost 50 Size 550 Crew 10 HTK 0/1
Base Chance to hit 100%
Materials Required: Duranium  25    Vendarite  75
Capacity 1000tons
-Half-size military hangar bay that acts like a commercial hanger but is as capable as Hangar Deck while half the size and can, obviously be used on military carriers. Double capacity is meant to be balanced by lack of deployment time pause, and possibly not being able to reload missiles and or maintenance supplies if that proves not enough. Thus a carrier that can carry more fighters but is more expensive and even more vulnerable to fire. Though this would allow for more compact carriers as well.

And here are current a hangar components minus commercial hangers

Hangar Deck
Cost 100   Size 1,050 tons   Crew 15   HTK 4
Base Chance to hit 100%
Materials Required: Duranium  25    Vendarite  75   

Boat Bay - Small
Cost 18   Size 150 tons   Crew 3   HTK 0
Base Chance to hit 100%
Materials Required: Vendarite  18   

Boat Bay
Cost 30   Size 300 tons   Crew 5   HTK 1
Base Chance to hit 100%
Materials Required: Vendarite  30     


Half size isn't going to make much of a difference except maybe in build cost, as the actual size of a carrier is going to have to be scaled up to what it's actually carrying (for purposes of calculating speed, sensor signature, etc.), so you're not saving any tonnage unless the carrier is empty. Unless you're suggesting that a hangar with 550 tons size can carry 1000 tons of fighters and still be considered 550 tons for speed, sensor, etc. purposes, which doesn't make sense.

Given that the existing hangar component essentially "maths out" as 50 tons of component and 1000 tons of fighter space, I'm not sure why not just RP it as an external clamp if you want to. Gripper arms plus refueling and transfer tubes displacing 50 tons seems reasonable to me.
Thanks knew I forgot some minor detail or another~  ;D
Anyway in an attempt to play devils advocate how bout justifying it as either gravity manipulation or "aether magic" ie a regular hangar bay that has systems/devices that "negate" half the mass of its onboard craft and just its own machinery/structure?
Something like
Horrible no good balance-shattering component number i8182401840 MkII (Does it count as not serious if I would like to see it just think its very very unlikely? and you do it twice)
Gravitic Hangar Deck
Cost 150 Size 525 Crew 15 HTK 2
Base Chance to hit 100%
Materials Required: Duranium  38    Vendarite  108 (maybe some other mineral as well? ahh) Uridium 50
Capacity 1000tons
-And to "justify" it I guess you have it be tied to having every type of hangar module (Deck, boat bays and commercial) and then either 3rd of 4th gen Grav Survey sensors

And yes I think it would be useful if you have 12kt carrier with lets say 5kt capacity that's 5.25kt of mass with these that's 2.625kt freeing up space for either more magazines,supply bays, engines, defenses etc
 
Title: Re: C# Suggestions
Post by: Warer on April 19, 2021, 04:05:16 PM
Actually serious(ish) suggestion a thread for Unrealistic Suggestions, a place for people to shove all their "cool and wacky ideas" (me) into a space away from suggestions which might be feasible for a hobby project.
Title: Re: C# Suggestions
Post by: xenoscepter on April 19, 2021, 07:15:05 PM
Actually serious(ish) suggestion a thread for Unrealistic Suggestions, a place for people to shove all their "cool and wacky ideas" (me) into a space away from suggestions which might be feasible for a hobby project.

Make one. ;D
Title: Re: C# Suggestions
Post by: TMaekler on April 20, 2021, 04:52:00 AM
How about a global range factor for missiles?

It would be great if we could change the overall range calculations for missiles to make it fit better with different scenarios. Whilst long range as it is fits quite well for example into an Expanse Universe, it doesn't fit so much for a Battlestar Galactica Universe where beam and missiles are roughly the same (low) range weapons.
Title: Re: C# Suggestions
Post by: nuclearslurpee on April 20, 2021, 10:55:08 AM
How about a global range factor for missiles?

It would be great if we could change the overall range calculations for missiles to make it fit better with different scenarios. Whilst long range as it is fits quite well for example into an Expanse Universe, it doesn't fit so much for a Battlestar Galactica Universe where beam and missiles are roughly the same (low) range weapons.

I'm curious how you would accomplish this. Currently the idea of missiles is to use the same engine rules as ships except for the overboost ability, part of the whole idea in C# of making the mechanics consistent rather than the plague of exceptions in VB6. Throwing an extra "divide by X" into the missile range formula seems at odds with that philosophy.

Also this would horribly screw with the NPRs AI, but that's not news.  :P
Title: Re: C# Suggestions
Post by: QuakeIV on April 20, 2021, 09:28:32 PM
It wouldn't necessarily screw with NPR AI, but it would definitely derail the intent to make everything follow the same rules.
Title: Re: C# Suggestions
Post by: Black on April 21, 2021, 01:43:54 AM
I understood TMaekler idea about missile range as something you select at game start in similar way as research and survey speed. Not sure if it is possible or not to implement this in such way.
Title: Re: C# Suggestions
Post by: QuakeIV on April 21, 2021, 02:40:05 AM
It might be easier to just have a global fuel effeciency modifier
Title: Re: C# Suggestions
Post by: Stryker on April 21, 2021, 08:46:16 AM
Please put missile series back in.  As is, I have to change the loadout of each ship or the class loadout every time I want to top off my magazine with older missiles.  So please, please put this back in.
Title: Re: C# Suggestions
Post by: kingflute on April 23, 2021, 04:53:50 AM
Allow for ships to provide control to missiles fired from other ships/fighters in the same fleet. Each FC system could control a fixed number of missiles each, with a new tech line to increase the number of missiles it can control.
Title: Re: C# Suggestions
Post by: Borealis4x on April 24, 2021, 07:13:43 PM
You should only be able to change ship commanders when they are in port over a friendly world. I hate it when I send out a hand-picked commander only for him to be promoted in transit and be magically replaced with someone else. Promotion and assignment checks should only occur to unassigned and orbiting officers.

Be really cool if the XO or, failing that, highest rated officer on a ship could take over if the commander is killed.
Title: Re: C# Suggestions
Post by: nuclearslurpee on April 24, 2021, 07:25:40 PM
You should only be able to change ship commanders when they are in port over a friendly world. I hate it when I send out a hand-picked commander only for him to be promoted in transit and be magically replaced with someone else. Promotion and assignment checks should only occur to unassigned and orbiting officers.

This sounds really good in theory (realism, hooray!) but in reality is a huge micromanagement pain. Especially once commanders start being located on different worlds so that every time you want to assign a specific commander you need to figure out which system to send the shuttle to. This would work a lot better if we had some automation for it though.

Quote
Be really cool if the XO or, failing that, highest rated officer on a ship could take over if the commander is killed.

This would be great.
Title: Re: C# Suggestions
Post by: Borealis4x on April 24, 2021, 09:38:55 PM
You should only be able to change ship commanders when they are in port over a friendly world. I hate it when I send out a hand-picked commander only for him to be promoted in transit and be magically replaced with someone else. Promotion and assignment checks should only occur to unassigned and orbiting officers.

This sounds really good in theory (realism, hooray!) but in reality is a huge micromanagement pain. Especially once commanders start being located on different worlds so that every time you want to assign a specific commander you need to figure out which system to send the shuttle to. This would work a lot better if we had some automation for it though.


I wasn't thinking it'd be that granular. The only requirment would be for a ship to be in orbit over any friendly planet to get a new officer.
Title: Re: C# Suggestions
Post by: Stryker on April 26, 2021, 10:10:42 AM
A refuel until full order.  This would be like the fill minerals until full order, except for fuel.  This would allow a simple set of orders for working with tankers and harvesters.  Refuel until full - Transfer fuel to colony x - Cycle orders.  Then I can stop trying to guess the right speed for my tankers so I'm not running half empty, or end up leaving my harvesters too full to where they are not harvesting.
Title: Re: C# Suggestions
Post by: Garfunkel on April 26, 2021, 12:43:14 PM
A refuel until full order.  This would be like the fill minerals until full order, except for fuel.  This would allow a simple set of orders for working with tankers and harvesters.  Refuel until full - Transfer fuel to colony x - Cycle orders.  Then I can stop trying to guess the right speed for my tankers so I'm not running half empty, or end up leaving my harvesters too full to where they are not harvesting.
Not quite as easy as you think because all loading/unloading happens sequentially. So your tanker would refuel from Harvester 001 until that one is empty, then refuel from Harvester 002 until full and leave, while leaving Harvester 003 untouched. There is no way to siphon fuel from each harvester equally so you would still need to calculate the optimal travel speed for your tanker(s) to avoid 'wasting' harvesting time.
Title: Re: C# Suggestions
Post by: Zap0 on April 26, 2021, 01:13:37 PM
A refuel until full order.  This would be like the fill minerals until full order, except for fuel.  This would allow a simple set of orders for working with tankers and harvesters.  Refuel until full - Transfer fuel to colony x - Cycle orders.  Then I can stop trying to guess the right speed for my tankers so I'm not running half empty, or end up leaving my harvesters too full to where they are not harvesting.
Not quite as easy as you think because all loading/unloading happens sequentially. So your tanker would refuel from Harvester 001 until that one is empty, then refuel from Harvester 002 until full and leave, while leaving Harvester 003 untouched. There is no way to siphon fuel from each harvester equally so you would still need to calculate the optimal travel speed for your tanker(s) to avoid 'wasting' harvesting time.

I'd very much like that suggestion because I haven't figured out how to have automated fuel transfers from stations yet.

MSP and ordnance transfers manage to balance how much they put on each ship, pulling fuel from the highest fuel level in the target fleet should be possible. And be nice if that was the regular "refuel from" behaviour :-)
Title: Re: C# Suggestions
Post by: Stryker on April 28, 2021, 04:05:14 PM
A refuel until full order.  This would be like the fill minerals until full order, except for fuel.  This would allow a simple set of orders for working with tankers and harvesters.  Refuel until full - Transfer fuel to colony x - Cycle orders.  Then I can stop trying to guess the right speed for my tankers so I'm not running half empty, or end up leaving my harvesters too full to where they are not harvesting.
Not quite as easy as you think because all loading/unloading happens sequentially. So your tanker would refuel from Harvester 001 until that one is empty, then refuel from Harvester 002 until full and leave, while leaving Harvester 003 untouched. There is no way to siphon fuel from each harvester equally so you would still need to calculate the optimal travel speed for your tanker(s) to avoid 'wasting' harvesting time.

Never said it was easy, just useful.
Title: Re: C# Suggestions
Post by: Bubbaisagod on April 29, 2021, 05:47:15 AM
When you use the “harvester transfer and return” conditional order, every time the harvester returns
to the gas giant you get an interruption and event log message.
I don’t know if there is a reason for the interruption or if it’s possible to disable for harvester conditional orders only.

If it can be disabled I would suggest ask beg beg while crying
“Please Steve, oh great creator … save my sanity and disable the interruption”
Title: Re: C# Suggestions
Post by: DeMatt on April 29, 2021, 06:23:45 AM
A refuel until full order.  This would be like the fill minerals until full order, except for fuel.  This would allow a simple set of orders for working with tankers and harvesters.  Refuel until full - Transfer fuel to colony x - Cycle orders.  Then I can stop trying to guess the right speed for my tankers so I'm not running half empty, or end up leaving my harvesters too full to where they are not harvesting.
Not quite as easy as you think because all loading/unloading happens sequentially. So your tanker would refuel from Harvester 001 until that one is empty, then refuel from Harvester 002 until full and leave, while leaving Harvester 003 untouched. There is no way to siphon fuel from each harvester equally so you would still need to calculate the optimal travel speed for your tanker(s) to avoid 'wasting' harvesting time.
Eh... in Aurora VB, there was a button to equalize the fleet's fuel.  It seems to be gone from Aurora C#, but that functionality could be part of how the order works:
Title: Re: C# Suggestions
Post by: Garfunkel on April 29, 2021, 07:25:46 AM
A refuel until full order.  This would be like the fill minerals until full order, except for fuel.  This would allow a simple set of orders for working with tankers and harvesters.  Refuel until full - Transfer fuel to colony x - Cycle orders.  Then I can stop trying to guess the right speed for my tankers so I'm not running half empty, or end up leaving my harvesters too full to where they are not harvesting.
Not quite as easy as you think because all loading/unloading happens sequentially. So your tanker would refuel from Harvester 001 until that one is empty, then refuel from Harvester 002 until full and leave, while leaving Harvester 003 untouched. There is no way to siphon fuel from each harvester equally so you would still need to calculate the optimal travel speed for your tanker(s) to avoid 'wasting' harvesting time.
Eh... in Aurora VB, there was a button to equalize the fleet's fuel.  It seems to be gone from Aurora C#, but that functionality could be part of how the order works:
  • If tanker is not at harvester fleet, move to harvester fleet.
  • Tanker refuels from harvesters, sequentially.
  • If tanker is not full, wait a construction cycle and return to step 1.
  • Equalize the harvester fleet's fuel.
  • (Order complete, proceed with next order.)
The equalize fuel button went away because fuel transfer rules changed massively. What you suggest is of course possible except for the equalizing part. The problem comes from how to make sure that the single tanker refuels equal amounts from each harvester. Because currently the code does not support that as far as I know. It's not just changing one toggle; it would need Steve to rewrite the fuel-refuel code which impacts everything else. That's what I meant when I said that it isn't as easy as we make it sound - apologies if it wasn't clear.
Title: Re: C# Suggestions
Post by: Warer on April 30, 2021, 06:09:23 AM
Multi-shot missile launchers...because they`re cool. That and I guess maybe they`d help full-size launchers overcome enemy PD?
Title: Re: C# Suggestions
Post by: Droll on April 30, 2021, 09:31:11 AM
Multi-shot missile launchers...because they`re cool. That and I guess maybe they`d help full-size launchers overcome enemy PD?

This is kind of possible with 2-stage MIRVs. Empty 1st stage and just set the separation range to the attack range and the missile will split into multiple missiles 5s after launch.
Title: Re: C# Suggestions
Post by: Warer on April 30, 2021, 03:16:39 PM
Multi-shot missile launchers...because they`re cool. That and I guess maybe they`d help full-size launchers overcome enemy PD?

This is kind of possible with 2-stage MIRVs. Empty 1st stage and just set the separation range to the attack range and the missile will split into multiple missiles 5s after launch.
True but I mean a true MSML, ie a launcher that fires off multiple shots per 5 seconds. Some super tech used possibly by invaders of precursors, or discoverable from ruins. Is it possible to make a random chance per completely empty system to generate an lets call it "Ancient Wreck" that has the tech and other advanced ones?
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on April 30, 2021, 03:22:52 PM
Multi-shot missile launchers...because they`re cool. That and I guess maybe they`d help full-size launchers overcome enemy PD?

This is kind of possible with 2-stage MIRVs. Empty 1st stage and just set the separation range to the attack range and the missile will split into multiple missiles 5s after launch.
True but I mean a true MSML, ie a launcher that fires off multiple shots per 5 seconds. Some super tech used possibly by invaders of precursors, or discoverable from ruins. Is it possible to make a random chance per completely empty system to generate an lets call it "Ancient Wreck" that has the tech and other advanced ones?

Do you just...want something that is "stronger" than existing tech? Because I don't really see how what you've described is in any way different than 1. empty 1st stage approach on a large launcher or 2. just having multiple 5s fire rate launchers attached to a single fire control. Both let you put multiple missiles in space in the same increment pointed at the same target.
Title: Re: C# Suggestions
Post by: Bremen on April 30, 2021, 05:16:03 PM
Multi-shot missile launchers...because they`re cool. That and I guess maybe they`d help full-size launchers overcome enemy PD?

This is kind of possible with 2-stage MIRVs. Empty 1st stage and just set the separation range to the attack range and the missile will split into multiple missiles 5s after launch.
True but I mean a true MSML, ie a launcher that fires off multiple shots per 5 seconds. Some super tech used possibly by invaders of precursors, or discoverable from ruins. Is it possible to make a random chance per completely empty system to generate an lets call it "Ancient Wreck" that has the tech and other advanced ones?

I think multi-missile launchers are modeled fine just by using multiple missile launchers and visualizing it as a single weapon. If you want something that shoots a bunch and then takes a long time to reload, just used the reduced reload speed option.
Title: Re: C# Suggestions
Post by: Coleslaw on May 03, 2021, 05:17:13 PM
This is an extremely small thing.

How feasible would an "Unload All" order for cargo spaces be? For example, my salvagers pick up a whole bunch of random minerals and ship modules. Rather than having to separately unload minerals and separately unload ship components, an option that just dumps the entire cargo space onto the body would be nice. If this could be used before the ship had anything in it, that'd be cool too. I find I can't actually tell my salvagers to unload anything until they actually have something in their cargo space, which means I have to tell it to salvage, then refuel at a colony, and then remember later to empty themselves before I send them out again.

Also, I see the All Active Sensors On/Off thing has been added. Could we also get one for shields?

...And another thing! I was puttering along and suddenly two hostile contacts appear in my home system, but for some reason the autoturns don't stop. Fortunately, they didn't seem keen to doing me any harm, but if they were, they would've had literally two months to do so simply because the autoturns kept going. They weren't new contacts in the sense that I hadn't seen them before, but I did lose them before they popped into my system so theoretically I should've gotten interrupted once they reappeared, no?
Title: Re: C# Suggestions
Post by: nuclearslurpee on May 03, 2021, 06:22:59 PM
...And another thing! I was puttering along and suddenly two hostile contacts appear in my home system, but for some reason the autoturns don't stop. Fortunately, they didn't seem keen to doing me any harm, but if they were, they would've had literally two months to do so simply because the autoturns kept going. They weren't new contacts in the sense that I hadn't seen them before, but I did lose them before they popped into my system so theoretically I should've gotten interrupted once they reappeared, no?

This occurs because of how the contacts system interacts with the events. The events are only fired when a contact changes, so if you lost a hostile contact at (say) full speed with all sensors on, and it later reappears in the same state, a notification may not be fired and the auto-turn won't stop. Be nice if this was improved though!
Title: Re: C# Suggestions
Post by: idefelipe on May 04, 2021, 12:38:54 AM
Hey there Steve!!

I would have another small suggestion for the commanders tab. I like to manually assign commanders to the ships, so none of them keep without a command while is in the lower rank. Even if the commander has not a proper skill for the work he will do, I don't think that the Fleet Command would keep commanders looking through the window when there are ships without CO.

I also use automatic assigment, of course, but as said I like to assign from year to year those that are not assigned. Is it possible to add a checkbox in the commander tab to show the "unassigned" commanders? So the list will show only those that need a new ship :)

Thanks.
Title: Re: C# Suggestions
Post by: chrislocke2000 on May 04, 2021, 08:27:33 AM
Two thoughts on ground forces and combat.

Rather than having to build units with specific terrain capabilities such as jungle etc and deal with the inherent costs this could be treated as a training option in much the same way that ships are trained at the moment. This would then approximate a little more on true to life with work up training rather than ground up troops. Depending on how detailed this is made you could accelerate training by placing troops on planets with the same overall environment and provide officers with terrain specific bonuses to both help on trainings and combat in those environments. You could then also retrain troops as needed for some better flexibility.

My other general comment is that collateral damage still seems very high to me for ground troops. For me I’m using troops more for RP reasons rather than balance as there is little to no incremental benefit in dropped troops v just pummelling from above at the moment.
Title: Re: C# Suggestions
Post by: skoormit on May 04, 2021, 08:53:31 AM
...there is little to no incremental benefit in dropped troops v just pummelling from above at the moment.

I'm not a ground combat expert, so correct me if I'm wrong: against fortified defenders, isn't it cheaper/faster to drop troops than to bombard from orbit, when you take into account the very low hit chance and the MSP cost of weapon failures?
Title: Re: C# Suggestions
Post by: nuclearslurpee on May 04, 2021, 11:14:06 AM
Hey there Steve!!

I would have another small suggestion for the commanders tab. I like to manually assign commanders to the ships, so none of them keep without a command while is in the lower rank. Even if the commander has not a proper skill for the work he will do, I don't think that the Fleet Command would keep commanders looking through the window when there are ships without CO.

I also use automatic assigment, of course, but as said I like to assign from year to year those that are not assigned. Is it possible to add a checkbox in the commander tab to show the "unassigned" commanders? So the list will show only those that need a new ship :)

Thanks.

Seconded.

...there is little to no incremental benefit in dropped troops v just pummelling from above at the moment.

I'm not a ground combat expert, so correct me if I'm wrong: against fortified defenders, isn't it cheaper/faster to drop troops than to bombard from orbit, when you take into account the very low hit chance and the MSP cost of weapon failures?

I believe there is also a significant difference in collateral damage as shipboard weapons have both lower chance to hit (requiring more shots) and often are quite overkill - to say nothing about using missiles which just devastate the entire environment of a body. That said collateral damage in general is rather excessive at the moment so it may get looked at sometime.
Title: Re: C# Suggestions
Post by: Droll on May 04, 2021, 11:22:48 AM
That said collateral damage in general is rather excessive at the moment so it may get looked at sometime.

Ground artillery also is quite insane for collateral damage. Its why I prefer long range bombardment over heavy bombardment.
Title: Re: C# Suggestions
Post by: nuclearslurpee on May 04, 2021, 12:11:29 PM
That said collateral damage in general is rather excessive at the moment so it may get looked at sometime.

Ground artillery also is quite insane for collateral damage. Its why I prefer long range bombardment over heavy bombardment.

I've noticed a lot of players will rush to the heavy+ weapons and vehicle types thinking that more powerful == better. Aurora's ground unit system in general is really designed with a "less is more" ideal, as bringing an overkill weapon to a battle is more wasteful than useful, but new players do not always realize this. That might contribute to the collateral damage excess as well.
Title: Re: C# Suggestions
Post by: Stryker on May 04, 2021, 06:17:19 PM
It would be nice to have an auto damage control checkbox in the design screen.  This way you can set auto damage control for the entire class, instead of having to do it ship by ship.

Edit:  I meant damage control, not maintenance. 
Title: Re: C# Suggestions
Post by: QuakeIV on May 05, 2021, 12:07:53 AM
That said collateral damage in general is rather excessive at the moment so it may get looked at sometime.

Ground artillery also is quite insane for collateral damage. Its why I prefer long range bombardment over heavy bombardment.

I've noticed a lot of players will rush to the heavy+ weapons and vehicle types thinking that more powerful == better. Aurora's ground unit system in general is really designed with a "less is more" ideal, as bringing an overkill weapon to a battle is more wasteful than useful, but new players do not always realize this. That might contribute to the collateral damage excess as well.

In this regard I'd actually personally kindof like if more bigger = more better' to some extent, the tech isn't as rewarding as you would initially assume currently.
Title: Re: C# Suggestions
Post by: Tavik Toth on May 06, 2021, 08:33:29 AM
Hm, not sure if this has been suggested before, but if it's practical I'd like to see some sort of Non-Trans Newtonian ship weapons and sensors.  Maybe have them be 50% less effective/efficient that Trans Newtonian weapons and sensors?
Title: Re: C# Suggestions
Post by: DFNewb on May 06, 2021, 08:57:03 AM
Can search and destroy fighters and flak suppression be buffed? Currently they are kinda useless, I always wanted to crush a planet's ground forces with fighters but as it currently is, that is impossible to do.
Title: Re: C# Suggestions
Post by: nuclearslurpee on May 06, 2021, 10:39:12 AM
Hm, not sure if this has been suggested before, but if it's practical I'd like to see some sort of Non-Trans Newtonian ship weapons and sensors.  Maybe have them be 50% less effective/efficient that Trans Newtonian weapons and sensors?

It's been discussed before. To my recollection, in order for pre-TN warfare to be viable or have any point we need:
Title: Re: C# Suggestions
Post by: Demetrious on May 06, 2021, 04:08:53 PM
My humble suggestion: Make NPR's treat diplomatic ships as harmless. It's getting pretty frustrating that I can never do Diplomacy or even maintain diplomatic contact with a new NPR because they screech at my harmless, unarmed diplomatic station like it's a battleship or something.
Title: Re: C# Suggestions
Post by: nuclearslurpee on May 06, 2021, 04:14:38 PM
My humble suggestion: Make NPR's treat diplomatic ships as harmless. It's getting pretty frustrating that I can never do Diplomacy or even maintain diplomatic contact with a new NPR because they screech at my harmless, unarmed diplomatic station like it's a battleship or something.

Diplo ships in general need to be more obvious. I had an NPR parking their diplo ships on "my" jump points, which I thought were destroyers of some sort due to size and military engines. Since I did not have any diplo ships of my own, at no point did I gain any indication that these were in fact not armed vessels until I, um, accidentally destroyed them much later on.
Title: Re: C# Suggestions
Post by: Demetrious on May 06, 2021, 08:09:47 PM
My humble suggestion: Make NPR's treat diplomatic ships as harmless. It's getting pretty frustrating that I can never do Diplomacy or even maintain diplomatic contact with a new NPR because they screech at my harmless, unarmed diplomatic station like it's a battleship or something.

Diplo ships in general need to be more obvious. I had an NPR parking their diplo ships on "my" jump points, which I thought were destroyers of some sort due to size and military engines. Since I did not have any diplo ships of my own, at no point did I gain any indication that these were in fact not armed vessels until I, um, accidentally destroyed them much later on.

Indeed. NPR's will auto-flag a ship as a diplomatic vessel once it attempts communication while on-sensors. It would be useful for players if a custom event message (at the least) popped up indicating that a ship is a diplomatic ship, or perhaps an auto-flag for players, using the standard alien intelligence prefix flagging system.

Of course, having some NPRs with high xenophobia take a more... testy approach to even diplomatic ships and have less inclination towards sending diplomatic ships of their own is entirely possible, as well...
Title: Re: C# Suggestions
Post by: Droll on May 06, 2021, 08:27:57 PM
It would be useful for players if a custom event message (at the least) popped up indicating that a ship is a diplomatic ship...

I do get special events that mark alien ships as diplomatic vessels, the problem is that they don't have a visible marker on their contact info in the tactical view, which means you often forget which specific ship is diplomatic.

The problem is that both sides need sensor coverage for such communication to happen, which means that often you have to get uncomfortably close to identify the diplomats. I think its realistic since it shows how difficult it is to establish contact with an unknown alien force.
Title: Re: C# Suggestions
Post by: Garfunkel on May 07, 2021, 12:04:02 PM
Can search and destroy fighters and flak suppression be buffed? Currently they are kinda useless, I always wanted to crush a planet's ground forces with fighters but as it currently is, that is impossible to do.
Never in human history has airpower crushed ground armies completely or even driven them to surrender. Even the best possible case scenario, the Gulf War of 1991, required the Coalition to drive their ground forces into Kuwait and Irak, and that was a war where one side had complete control of the airspace, could bomb the enemy with total freedom, and had complete intelligence about the enemy's disposition and equipment. Plus both terrain and weather were on the side of the attacker.

If you don't want to wage a ground war, the only option is to nuke the planet and that's how it should be. It is ludicrous and impossible, regardless of technology, to be able to wipe out armed resistance on a planetary scale.
Title: Re: C# Suggestions
Post by: QuakeIV on May 07, 2021, 04:40:02 PM
Can search and destroy fighters and flak suppression be buffed? Currently they are kinda useless, I always wanted to crush a planet's ground forces with fighters but as it currently is, that is impossible to do.
Never in human history has airpower crushed ground armies completely or even driven them to surrender. Even the best possible case scenario, the Gulf War of 1991, required the Coalition to drive their ground forces into Kuwait and Irak, and that was a war where one side had complete control of the airspace, could bomb the enemy with total freedom, and had complete intelligence about the enemy's disposition and equipment. Plus both terrain and weather were on the side of the attacker.

If you don't want to wage a ground war, the only option is to nuke the planet and that's how it should be. It is ludicrous and impossible, regardless of technology, to be able to wipe out armed resistance on a planetary scale.

There were literally large numbers of infantry surrendering to helicopters.
Title: Re: C# Suggestions
Post by: Garfunkel on May 07, 2021, 06:18:16 PM
Not large numbers and it only happened twice and then afterwards got blown out of all proportion, just like the myth of Polish cavalry charging German tanks in 1939. In both cases it were vehicle crews surrendering after seeing their comrades getting blown up. And despite the publicity that the Highway of Death got, that massacre only happened after the advancing Coalition troops had routed the Iraqi troops who then fled in panic.
Title: Re: C# Suggestions
Post by: Stryker on May 07, 2021, 09:59:42 PM
Not large numbers and it only happened twice and then afterwards got blown out of all proportion, just like the myth of Polish cavalry charging German tanks in 1939. In both cases it were vehicle crews surrendering after seeing their comrades getting blown up. And despite the publicity that the Highway of Death got, that massacre only happened after the advancing Coalition troops had routed the Iraqi troops who then fled in panic.

The details may be wrong, but the point is valid.  During world war ii, the luftwaffe bombed the hell out of England.  They went into their bunkers, then, when the raid was over, they came back out and rebuilt.  You have to put boots on the ground.
Title: Re: C# Suggestions
Post by: Stryker on May 07, 2021, 10:03:57 PM
It would be nice if we could get a formation update button.  If you select you're infantry battalion, for example, then click the update button, the engine would look at the unit series, and replace on a one for one basis the units in that batallion with the ones at the top of the unit series.  This would save having to replace every element in a formation indivually.  Some adjustments may have to be made to the formation, but this is much easier than replacing every element by hand.

I'm referring to the formation template, not an existing formation.
Title: Re: C# Suggestions
Post by: xenoscepter on May 07, 2021, 11:34:55 PM
It would be nice if we could get a formation update button.  If you select you're infantry battalion, for example, then click the update button, the engine would look at the unit series, and replace on a one for one basis the units in that batallion with the ones at the top of the unit series.  This would save having to replace every element in a formation indivually.  Some adjustments may have to be made to the formation, but this is much easier than replacing every element by hand.

I'm referring to the formation template, not an existing formation.

 - I usually just update them by making a new template and then adding the same number of new units as the old, then hitting "Obsolete" on the old units and deleting the old template for sanity's sake. Not sure if you can delete a template while units still use it, but I'd assume you can... an "Obsolete Template" Button would be nice though. :)
Title: Re: C# Suggestions
Post by: Stryker on May 08, 2021, 12:10:13 AM
It would be nice if we could get a formation update button.  If you select you're infantry battalion, for example, then click the update button, the engine would look at the unit series, and replace on a one for one basis the units in that batallion with the ones at the top of the unit series.  This would save having to replace every element in a formation indivually.  Some adjustments may have to be made to the formation, but this is much easier than replacing every element by hand.

I'm referring to the formation template, not an existing formation.

 - I usually just update them by making a new template and then adding the same number of new units as the old, then hitting "Obsolete" on the old units and deleting the old template for sanity's sake. Not sure if you can delete a template while units still use it, but I'd assume you can... an "Obsolete Template" Button would be nice though. :)

But you still have to add everything manually.  Much easier if there was an update button.
Title: Re: C# Suggestions
Post by: nuclearslurpee on May 08, 2021, 09:34:43 AM
It would be nice if we could get a formation update button.  If you select you're infantry battalion, for example, then click the update button, the engine would look at the unit series, and replace on a one for one basis the units in that batallion with the ones at the top of the unit series.  This would save having to replace every element in a formation indivually.  Some adjustments may have to be made to the formation, but this is much easier than replacing every element by hand.

I'm referring to the formation template, not an existing formation.

This is a great and natural extension of the Series system.
Title: Re: C# Suggestions
Post by: skoormit on May 08, 2021, 10:06:03 AM
I would love to have a "Rename Fleet" order.

I use fleet names to indicate current assignment, and it would be great if I could, for example, have a freighter fleet rename itself after it unloads.
Title: Re: C# Suggestions
Post by: QuakeIV on May 09, 2021, 05:07:48 AM
That is a seriously interesting concept, I could have a fleet rename itself to 0Unloaded or something so that I see it at the top of the list.
Title: Re: C# Suggestions
Post by: skoormit on May 10, 2021, 06:26:10 AM
Append Template Orders To Current Orders

Right now, using an order template overwrites a fleet's current orders.
I suggest adding a way to append template orders to the end of the current orders list.

Perhaps a checkbox "Append Orders" next to the Create/Delete Template buttons?

If the box is checked, then double-clicking a template appends the orders.
Otherwise, double-clicking replaces the current orders (as it does now).
Title: Re: C# Suggestions
Post by: nuclearslurpee on May 10, 2021, 07:49:45 AM
Append Template Orders To Current Orders

Right now, using an order template overwrites a fleet's current orders.
I suggest adding a way to append template orders to the end of the current orders list.

Perhaps a checkbox "Append Orders" next to the Create/Delete Template buttons?

If the box is checked, then double-clicking a template appends the orders.
Otherwise, double-clicking replaces the current orders (as it does now).

In the past Steve has been opposed to this because it would potentially create confusing bugs due to order targets not being where expected. However this already occasionally happens and is resolved through a nice event trigger and canceling the order, so I don't think it would be problematic. This would be a very useful addition.
Title: Re: C# Suggestions
Post by: Droll on May 10, 2021, 09:19:08 AM
In the past Steve has been opposed to this because it would potentially create confusing bugs due to order targets not being where expected. However this already occasionally happens and is resolved through a nice event trigger and canceling the order, so I don't think it would be problematic. This would be a very useful addition.

I never quite understood this because the order templates only showed when the expected destination system matched with the system that the order template was created in, which means that it would be impossible to activate that sequence of orders in the wrong system.
Title: Re: C# Suggestions
Post by: Garfunkel on May 10, 2021, 11:07:45 AM
I would love to have a "Rename Fleet" order.

I use fleet names to indicate current assignment, and it would be great if I could, for example, have a freighter fleet rename itself after it unloads.
Wow, how have I not thought of that before? That's a great idea and it has historical merit too - during WW2 convoys were renamed based on whether they were "going in" or "coming out".
Title: Re: C# Suggestions
Post by: RagnarVaren on May 11, 2021, 04:21:37 PM
It would be nice to have a Ground Combat Forces Summary event similar to the Ground Combat Intelligence event but for the player's forces. Currently you can only see the latest forces on the colony as no history is saved so if the formations didn't match the templates exactly (i.e no additions or losses) then it isn't possible to know exactly how many forces were present for each round. This would be very useful as I'm currently extracting the GUC vs GUC summary events from the database after the battle to look at the performance of each of my ground unit classes against the enemy and it would be nice to know the exact number of my own forces present as they fluctuate due to reinforcements arriving.
Title: Re: C# Suggestions
Post by: Remilian on May 11, 2021, 09:03:00 PM
(Edited from my removed post into a more cohesive terraforming related suggestions)

Currently, there are a few issues with terraforming process and controls:

Based on the "Add Gas to Atmosphere" checkbox, certain database columns and log messages, I assume that current implementation involves unnecessary storage of TerraformStatus variable for each pop, which is then retrieved and used during production cycle in a series of checks.  In my opinion, MaxAtm (which can be more appropriately renamed into TargetAtm) variable is enough to extrapolate everything needed for terraformation calculations.

I suggest replacing terraform logic with this:
Code: [Select]
If ( Current_Atm != Target_Atm ) then        // I know about double's wonky equality check, but hear me out
    Terraform_change = Terraform_Capacity / Year_length * Cycle_length * other_modifiers....       //Amount of atm change possible on this body this production cycle
    If ( Terraform_change > 0 ) then
        Difference = Target_Atm - Current_Atm
        If ( ABS(Difference) <= Terraform_change ) then       //Can target be reached with available change?
            Current_Atm = Target_Atm         //gives people nice and clean values AND allows that target equality check at the beginning
            //Log message here? I know there are several versions of them, but maybe 1 universal "Target has been reached" is enough
        else
            If ( Difference < 0 ) then        //>0 means we need to add gas, <0 means we need to extract gas
                Current_Atm -= Terraform_change
                If ( Current_Atm < 0 ) then
                    Current_Atm = 0
            else
                Current_Atm += Terraform_change
           

This would fix the first problem and remove the need for that checkbox (and variable) completely, which is a part my proposal to fix to the second problem: change up terraform control panel from environmental tab.
Title: Re: C# Suggestions
Post by: Remilian on May 12, 2021, 03:03:48 PM
A lot of people still think that stacking Spaceports increases colony's cargo handling multiplier.  It doesn't, but this change is so buried in the changelogs and mentioned only in passing (with conflicting outdated statements as well) that people did not notice.  Maybe it could be put as a note in the next changelog to fully solidify that it does not stack?

As far as I understand the change has been done to increase the value of logistics technology tree, commander's logistics bonuses, and cargo handling bays (which is stackable but affects only individual ships), but that makes Spaceport inferior to triple station in almost every way.   I think Spaceport should still have some positive counterbalance to it's disadvantages.  Can't think of anything good for now, unfortunately.
Title: Re: C# Suggestions
Post by: Droll on May 12, 2021, 04:01:58 PM
As far as I understand the change has been done to increase the value of logistics technology tree, commander's logistics bonuses, and cargo handling bays (which is stackable but affects only individual ships), but that makes Spaceport inferior to triple station in almost every way.   I think Spaceport should still have some positive counterbalance to it's disadvantages.  Can't think of anything good for now, unfortunately.

I think it's quite simple, the spaceport is already quite a bit more expensive than its less generalized counterparts. Just make it so that the spaceport doesn't need 1m workers and I think it's in a decent place.
Title: Re: C# Suggestions
Post by: Remilian on May 12, 2021, 04:29:18 PM
I think it's quite simple, the spaceport is already quite a bit more expensive than its less generalized counterparts. Just make it so that the spaceport doesn't need 1m workers and I think it's in a decent place.
It is actually 17% cheaper than stations (3k vs 1.2k x3). But it is not enough to offset population used and 266% more cargo space required for transportation (2000kt vs 250kt x3).
The problem with just removing pop usage is that stations become kinda pointless. They were added in the first place to make specialized frontier bases possible on colonies without population. This could have been done in the past with the same pop+multiplier tweak to spaceports, but Steve decided to make stations instead. At the time it made sense, because stations were designed to not provide any bonuses while spaceports still stacked them. And now... it just adds to the unnecessary clutter.

Edit: New Idea: both ship's and spaceport's cargo handling modifiers can be set to sqrt(#). This would slightly decrease viability of Bay stacking, but it will bring back Spaceport stacking without taking away from station, technology, and commander importance. Players who just put 1 of each won't be affected at all, but it allows logistics-minded players to think about "investment vs speed gain" because of diminishing returns with large numbers.
Title: Re: C# Suggestions
Post by: Droll on May 12, 2021, 05:56:29 PM
Right now when building ground formations you have to click once for each unit. Allow the option to have players input a number of formations to build exactly like the SM instant build. The game should also used the name typed on the dialog box.
Title: Re: C# Suggestions
Post by: Coleslaw on May 12, 2021, 11:39:44 PM
This is a miniscule suggestion, but it'd be neat if bodies were to scale on the map like stars do. I can zoom in on Sol and see it increase in size on my screen proportional to the scale, but when I zoom in on planetary bodies they remain the same-sized blue dot. The only impact I imagine this having is providing a better frame of reference in naval combats nearby large planetary bodies. Recently I had a battle close to Saturn, would be really cool to see a bigger blue dot representing the gas giant as the ships and missiles involved in the combat flutter around it.
Title: Re: C# Suggestions
Post by: ISN on May 13, 2021, 12:49:33 PM
I'm not posting this in the bugs thread, since as far as I can tell from the rules post this is working as intended, but Fire at Will allows you to more or less completely negate jump shock for a well-trained fleet.  If you press the Fire at Will button after jumping it seems to overwrite the fire delay from jump shock, and if your fleet is trained then you'll end up with little to no delay.  Of course you don't get to choose your targets, and in some cases that's a big downside, but it's usually better than the alternative of not firing at all, and if your fleet outnumbers the enemy then it's often not a huge problem.

This makes taking a jump point generally much easier, but it's especially unbalanced because the AI has a tendency to jump through the jump points when attacked.  So you jump through a JP into an enemy fleet, the enemy jumps to escape you, you jump back and chase them -- and now you can use Fire at Will to wipe them out while they recover from the jump shock.

Was Fire at Will intended to negate jump shock, or just reduce the normal fire delays when crews are untrained? The balance issues could be fixed by making the AI use Fire at Will as well to counter the advantage the player has, but that just makes jump shock kind of pointless.  I think it would make the most sense to change Fire at Will so that it doesn't affect jump shock.
Title: Re: C# Suggestions
Post by: Droll on May 13, 2021, 01:35:37 PM
I'm not posting this in the bugs thread, since as far as I can tell from the rules post this is working as intended, but Fire at Will allows you to more or less completely negate jump shock for a well-trained fleet.  If you press the Fire at Will button after jumping it seems to overwrite the fire delay from jump shock, and if your fleet is trained then you'll end up with little to no delay.  Of course you don't get to choose your targets, and in some cases that's a big downside, but it's usually better than the alternative of not firing at all, and if your fleet outnumbers the enemy then it's often not a huge problem.

This makes taking a jump point generally much easier, but it's especially unbalanced because the AI has a tendency to jump through the jump points when attacked.  So you jump through a JP into an enemy fleet, the enemy jumps to escape you, you jump back and chase them -- and now you can use Fire at Will to wipe them out while they recover from the jump shock.

Was Fire at Will intended to negate jump shock, or just reduce the normal fire delays when crews are untrained? The balance issues could be fixed by making the AI use Fire at Will as well to counter the advantage the player has, but that just makes jump shock kind of pointless.  I think it would make the most sense to change Fire at Will so that it doesn't affect jump shock.

So I looked at the 1.13 changelogs:
Quote
A new Fire At Will option allow ships to reduce fire delays by half, at the expense of targeting choice. This can be applied to a single fire control, a ship or a fleet.

When the order is given, each fire control is assigned a random target (based on the rules below). Each ship is then assigned a fire delay with a modifier of -50% vs normal. This fire delay will override any existing fire delay (even if the current delay is longer), except if the command is assigned to a specific fire control, rather than ship or fleet, in which case the new fire delay will only override any existing fire delay if the new delay is longer.

Based on the first paragraph, fire at will is intended to affect just training based fire delays and not necessarily the jump shock.

However the second paragraph says "This fire delay will override any existing fire delay (even if the current delay is longer)" which to me indicates that the implementation is such that, if fire delay and jump shock delay are both in play, the game will ignore the jump shock delay. So although there is most likely no bug in the code, it does seem like "fire at will" does nullify jump shock.

Is this what Steve intended? I'm honestly not sure.
Title: Re: C# Suggestions
Post by: Lord Solar on May 13, 2021, 01:37:15 PM
I'm not posting this in the bugs thread, since as far as I can tell from the rules post this is working as intended, but Fire at Will allows you to more or less completely negate jump shock for a well-trained fleet.  If you press the Fire at Will button after jumping it seems to overwrite the fire delay from jump shock, and if your fleet is trained then you'll end up with little to no delay.  Of course you don't get to choose your targets, and in some cases that's a big downside, but it's usually better than the alternative of not firing at all, and if your fleet outnumbers the enemy then it's often not a huge problem.

This makes taking a jump point generally much easier, but it's especially unbalanced because the AI has a tendency to jump through the jump points when attacked.  So you jump through a JP into an enemy fleet, the enemy jumps to escape you, you jump back and chase them -- and now you can use Fire at Will to wipe them out while they recover from the jump shock.

Was Fire at Will intended to negate jump shock, or just reduce the normal fire delays when crews are untrained? The balance issues could be fixed by making the AI use Fire at Will as well to counter the advantage the player has, but that just makes jump shock kind of pointless.  I think it would make the most sense to change Fire at Will so that it doesn't affect jump shock.
Before Fire at Will existed, combining full training with flag bridge and a good flag officer (lots of reaction) can do the same thing but also select targets.
Title: Re: C# Suggestions
Post by: Zhukov on May 13, 2021, 03:43:18 PM
I would like to see the option to make labs "Sort by Date" as standard.   Every time I open this window I have to set ""by Date" to know what is finishing next.
Title: Re: C# Suggestions
Post by: Droll on May 13, 2021, 04:55:49 PM
Currently in game settings we can set the chances that a player or another NPR generates an NPR. It would be nice to also add settings to separately configure the % chance that spoilers can appear based on which ones are enabled.
Title: Re: C# Suggestions
Post by: villaincomer on May 14, 2021, 02:27:50 AM
It would be helpful when constructing installations to have an option for local colony or to be placed in a stockpile (radio button).   
1) Its easy to forget to ship something meant for another colony
2) Doesn't plunge local civilian pop into a deficit.   

Also for allocation of population jobs on a colony.   It would be nice to be able to prioritise between construction while sacrificing refining (without shutting down?).   

Finally, civilian mining outposts to be able to generate a small amount of pop that can emigrate.

Thank you :)
Title: Re: C# Suggestions
Post by: Coleslaw on May 15, 2021, 12:50:25 AM
I'm almost sure this has been suggested before, but I can't seem to find it elsewhere. In VB6 Aurora we could right-click a planetary body and click an option to create a colony on the body. Would be super convenient for some of the oddly named asteroids in Sol that don't sort in the list too well or have non-unique names (i.e. 2001 XH255.)
Title: Re: C# Suggestions
Post by: Droll on May 15, 2021, 12:43:00 PM
My intuition tells me that PD STOs can be more economical/less economical than orbital PD bases depending largely on planetary terrain. If your planet is a jungle mountain, even if your making massive turret STOs their survivability will be so damn high because of fortification bonuses that enemy fleets will have massive trouble initiating a land invasion or destroying the PD defense shooting down the enemy missiles. On the other hand, orbital bases can't take advantage of the planets terrain, although if the terrain is something like desert there is a good chance orbital bases would be cheaper and overall more cost-effective.

The problem I have with PD STOs is that they are unreasonably expensive, since every single gun has a full-price fire control system which is tuned to anti-missile fire. So you can easily have each gun cost 2000k uridium or something because of the fire control. Big turrets help mitigate this since your quad gauss packs 4x the firepower per FC.

I think there needs to be a new static component called "planetary active sensor" which lets you choose which designed active sensor to use from your racial tech. Likewise when designing standard STOs a checkbox to toggle the inclusion of inbuilt FCs should also be added. I'll crosspost this to the suggestion thread.
Title: Re: C# Suggestions
Post by: smoelf on May 15, 2021, 01:28:01 PM
Ability to turn off automatic construction of infrastructure on colonies with a colony cost.

On some planetary bodies with low gravity I might want to colonize them using orbital habitats exclusively, but once a population has been established they will automatically start building Low Gravity Infrastructure, which will results in civilians shipping colonists to the surface. This changes the balance between agriculture, service, and manufacturing, which can be a serious detriment on colonies with high Colony Cost.

A temporary solution is to set a cargo ship to perpetually transport the LG Infrastructure away from the planet, and you could probably avoid new colonists by military restricting the planet, but turning off automatic construction of infrastructure is a cleaner solution.
Title: Re: C# Suggestions
Post by: skoormit on May 16, 2021, 07:16:56 AM
Could we get a Copy Fleet Name button on the Naval Organization window?
The button would merely copy (to the clipboard) the name of the currently selected fleet.

Maybe put it right next to Rename? Or even all the way at the end of the buttons, after Delete.

Reasoning:
I do a lot of fleet renaming, particularly freighters, to keep track of which fleets are doing what, what's left to take where, etc.
My fleet names include several bits of info, and rather than re-type it all when giving a fleet orders that match (exactly or nearly) another fleet's, it is faster for me to select that other fleet, click the Rename button, copy to clipboard, close the Rename popup, re-select the target fleet, click the Rename button, paste from the clipboard, and make whatever changes are needed (often none).
A Copy Fleet Name button would save me an enormous number of fiddly clicks.
Title: Re: C# Suggestions
Post by: Density on May 16, 2021, 04:42:39 PM
Quote from: smoelf link=topic=10640. msg151565#msg151565 date=1621103281
Ability to turn off automatic construction of infrastructure on colonies with a colony cost.

On some planetary bodies with low gravity I might want to colonize them using orbital habitats exclusively, but once a population has been established they will automatically start building Low Gravity Infrastructure, which will results in civilians shipping colonists to the surface.  This changes the balance between agriculture, service, and manufacturing, which can be a serious detriment on colonies with high Colony Cost.

A temporary solution is to set a cargo ship to perpetually transport the LG Infrastructure away from the planet, and you could probably avoid new colonists by military restricting the planet, but turning off automatic construction of infrastructure is a cleaner solution.

I'm also in favor of this, but for a different reason: venusian atmo planets.
Just mentioning it because it would be disappointing to see this get implemented for LG's only.
Title: Re: C# Suggestions
Post by: Warer on May 16, 2021, 11:15:46 PM
Land on Specified Mothership as Sub-Fleet (+Assign) for carrier micro reduction.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on May 17, 2021, 03:32:10 AM
Quote from: smoelf link=topic=10640. msg151565#msg151565 date=1621103281
Ability to turn off automatic construction of infrastructure on colonies with a colony cost.

On some planetary bodies with low gravity I might want to colonize them using orbital habitats exclusively, but once a population has been established they will automatically start building Low Gravity Infrastructure, which will results in civilians shipping colonists to the surface.  This changes the balance between agriculture, service, and manufacturing, which can be a serious detriment on colonies with high Colony Cost.

A temporary solution is to set a cargo ship to perpetually transport the LG Infrastructure away from the planet, and you could probably avoid new colonists by military restricting the planet, but turning off automatic construction of infrastructure is a cleaner solution.

I'm also in favor of this, but for a different reason: venusian atmo planets.
Just mentioning it because it would be disappointing to see this get implemented for LG's only.

While I don't think this is a bad option (either of them) it is quite simple to avoid this currently. You just assign a small colony ship with a return trip to another colony and match this with the amount of people that is added to the colony over a years time. You can easily then adjust this once every ten years with just speeding up or slowing down that colony ship. But if you time it right you will only have to do this like once every hundred years or so.

The size of the colony ship you need is of course depending on the size of your habitat, but habitats usually are not that big so a single colony ship are usually enough.¨

Now you can also enjoy their production of infrastructure and move it to someplace else more useful.
Title: Re: C# Suggestions
Post by: smoelf on May 17, 2021, 03:54:23 AM
While I don't think this is a bad option (either of them) it is quite simple to avoid this currently. You just assign a small colony ship with a return trip to another colony and match this with the amount of people that is added to the colony over a years time. You can easily then adjust this once every ten years with just speeding up or slowing down that colony ship. But if you time it right you will only have to do this like once every hundred years or so.

The size of the colony ship you need is of course depending on the size of your habitat, but habitats usually are not that big so a single colony ship are usually enough.¨

Now you can also enjoy their production of infrastructure and move it to someplace else more useful.

Yeah, there are some ways to work around it. I've chosen to simply transport the infrastructure away to my home planet and RP that they the people dying on the surface due to no infrastructure simply never existed in the first place.

But I think that the frequency has to be a bit higher than you suggest, or perhaps I am misunderstanding you. If you only remove people/infrastructure every ten or hundred years, then you will get 10/100 years of slowly relocating workforce from industry to agriculture and thus losing efficiency. You should really remove people/infrastructure whenever there is something to remove to maintain the efficiency of orbital habitats. Also, while a single of my habitats only has room for 1.000.000 colonists, I have a lot of them at each colony as I intend to sustain a medium-large colony with only orbital habitas.

But you are absolutely right that the problem can be circumvented as the game is now.
Title: Re: C# Suggestions
Post by: Borealis4x on May 17, 2021, 12:55:12 PM
Maybe add the option for specified types of bodies to have unlimited amounts of minerals. You'd have sperate options for planets, gas giants, dwarfs, moons and asteroids.

I'd always make gas giants have unlimited sorium cuz I'm always paranoid about running out. Its never happened to be fair, but it does give me anxiety. Having unlimited minerals on full planets might also be a good idea for the same reason.

Keep in mind accessibility would still be a thing, so some planets would still be more valuable than others just cuz you can mine at a faster rate. It'd make gameplay more like Stellaris and other more traditional 4X games.
Title: Re: C# Suggestions
Post by: Droll on May 17, 2021, 02:13:40 PM
Maybe add the option for specified types of bodies to have unlimited amounts of minerals. You'd have sperate options for planets, gas giants, dwarfs, moons and asteroids.

I'd always make gas giants have unlimited sorium cuz I'm always paranoid about running out. Its never happened to be fair, but it does give me anxiety. Having unlimited minerals on full planets might also be a good idea for the same reason.

Keep in mind accessibility would still be a thing, so some planets would still be more valuable than others just cuz you can mine at a faster rate. It'd make gameplay more like Stellaris and other more traditional 4X games.

What I do is SM mode "specify minerals" and set every mineral type to 999999999999. But it definitely would be nice to be able to do that with one click-per planet.
I also have a house-rule that I'm trying out where I can only build 250 mines per 1000 km of diameter.
Title: Re: C# Suggestions
Post by: villaincomer on May 17, 2021, 02:36:03 PM
I like how we have our own "house rules".
Mine is if I SM minerals is to set availability to 0. 1 as a penalty
Title: Re: C# Suggestions
Post by: Garfunkel on May 17, 2021, 03:09:18 PM
It has been suggested before and shot down as well, because you can always use SM mode to add more minerals if you really need them so it's pretty much pointless for Steve to code something like that in, especially as he has said in the past that he views the need to find more minerals to fuel your production an important part of Aurora.
Title: Re: C# Suggestions
Post by: Demetrious on May 17, 2021, 06:08:51 PM
I like how we have our own "house rules".
Mine is if I SM minerals is to set availability to 0. 1 as a penalty

Given how large planets so often have tens or even hundreds of millions of tons of minerals (most if not all of the types, even) with 0.1 accessibility, this is effectively implemented already. Which is also good from a lore perspective; it explains how long-lived TN empires could exist. Strip mining small bodies provides the materiel to build up big fleets fast, and the slow production from the effectively bottomless taps is what sustains those empires, fleets and massive facility tonnage.

It is not hard to imagine that the slow collection of TN minerals to gravity wells may happen fast enough to be significant on a civilizational timescale; hundreds of years rather than thousands, as well.
Title: Re: C# Suggestions
Post by: ChubbyPitbull on May 18, 2021, 07:43:36 AM
Ability to directly begin upgrading a Ground Unit to a new Template

Right now as ground units become outdated, there's no way to directly re-equip units with the latest tech short of having them take losses that need to be replenished. Would be great if there was a way to upgrade/convert one template to a new one, similar to how ships can be upgraded. Something along the lines of an "Upgrade" order at Ground Force Training Facilities, where the mineral cost is spent to manufacture the replacement equipment, and the time cost to both build it, and train the unit on the new gear. This way unit formations with storied histories can easily be kept on the cutting edge of empire technology and not be lost to obsolescence.
Title: Re: C# Suggestions
Post by: xenoscepter on May 18, 2021, 08:54:51 AM
Ability to directly begin upgrading a Ground Unit to a new Template

Right now as ground units become outdated, there's no way to directly re-equip units with the latest tech short of having them take losses that need to be replenished. Would be great if there was a way to upgrade/convert one template to a new one, similar to how ships can be upgraded. Something along the lines of an "Upgrade" order at Ground Force Training Facilities, where the mineral cost is spent to manufacture the replacement equipment, and the time cost to both build it, and train the unit on the new gear. This way unit formations with storied histories can easily be kept on the cutting edge of empire technology and not be lost to obsolescence.

 - It'd be nice to have this as a function of a refit mechanic tied to Ground Forces Construction Facilities, but without the refit rules for ships obviously.
Title: Re: C# Suggestions
Post by: villaincomer on May 18, 2021, 09:23:29 AM
It would be nice to be able to search for minerals that *dont* have a colony already on them.
I appreciate there is a (C) at the end of the text string but would be nice to filter out the list.
Especially when creating new colonies en masse.

Open Mineral Survey Window > Add a radio button to Exclude Existing Colonies?
Thank you :)
Title: Re: C# Suggestions
Post by: villaincomer on May 18, 2021, 10:32:16 AM
Survey Sites

Trying to track (remember) where I have landed survey teams.

I've just noticed, and am assuming that (body name) * denotes troops on site

Would it be possible to add a %/progress bar next to body names?
+ organise by systems would be helpful to concentrate on 1 system at a time as an alternative to High to Minimal. 
Aiming to save ferrying troops from one end of the galaxy to the other.

Bonus:  Filter to display completed.

Thank you :)
Title: Re: C# Suggestions
Post by: skoormit on May 18, 2021, 03:42:58 PM
Survey Sites

Trying to track (remember) where I have landed survey teams.

I've just noticed, and am assuming that (body name) * denotes troops on site

Would it be possible to add a %/progress bar next to body names?
+ organise by systems would be helpful to concentrate on 1 system at a time as an alternative to High to Minimal. 
Aiming to save ferrying troops from one end of the galaxy to the other.

Bonus:  Filter to display completed.

Thank you :)

Nice timing...just this morning I wrote a db query to pull this information into my spreadsheet. Message me for the query if you are interested.
Title: Re: C# Suggestions
Post by: Drakale on May 19, 2021, 09:14:42 AM
Here's a suggestion for a ground combat addition that I think would make sense:

When attacking an alien force in ground combat for the first time you have a very vague idea of their capabilities, which is cool but there should be a way, with the proper preparation and research to scout the enemy and figure out some information about their firearm power, armor levels etc. Now, this is all possible in the current build by sacrificing a battalion and get some information before committing to a major offensive, but my problem with that is it does not feel like something a proper army would do and feels like gaming the system.

What I would like to see is an infiltration squad mechanic where some troop can be trained to be commando style specialists. They need to be researched and assigned to a ground unit like for boarding squads. When deployed on a world these units get a large chance to avoid combat and over time can give you information on the size and composition of the opposing forces. They are not invincible of course and if long enough they will start getting casualties, at which point you have the option to retrieve them if you want.

They could also have a minor role during an active fight also, maybe something like spotter for artillery or a mechanic where they burn through some of the enemy supplies, simulating hitting munition depot and guerilla warfare.

Title: Re: C# Suggestions
Post by: villaincomer on May 19, 2021, 09:56:19 AM
Like an SAS (or equivalent) recon unit that can also disrupt supplies or improve breakthrough chances.
Title: Re: C# Suggestions
Post by: kingflute on May 19, 2021, 10:53:45 AM
Like an SAS (or equivalent) recon unit that can also disrupt supplies or improve breakthrough chances.
Perhaps a ground team that could interfere with logistics, like loading/unloading ships etc, or gather intel on the planet and its orbit. The player could set how active/passive the team is, the more active, the greater the chance of detection.
Title: Re: C# Suggestions
Post by: Alrune on May 19, 2021, 11:53:07 AM
have an option to prevent the "Move to System Requiring Gravsurvey/Geosurvey" standing order from moving the fleet outside the range of its admin command
Title: Re: C# Suggestions
Post by: nuclearslurpee on May 19, 2021, 12:21:11 PM
have an option to prevent the "Move to System Requiring Gravsurvey/Geosurvey" standing order from moving the fleet outside the range of its admin command

This but for all standing orders which can cause a fleet to move between systems, e.g., the salvage standing order.
Title: Re: C# Suggestions
Post by: skoormit on May 20, 2021, 10:20:19 AM
On the Industry tab of the Economics screen, when I make a change to an existing project and click the Modify button, the project becomes unselected.
Very often I want to make multiple changes to a project (number, percentage, up/down queue). I must re-select the project after each change.

It would be nice if the selected project remained selected after clicking the Modify button.
Title: Re: C# Suggestions
Post by: Marski on May 21, 2021, 04:21:37 AM
Add a checkboxes for Ground Formation Templates, that decides if the ground formation is numbered or not and/or even has a commander spot assigned.
It would help significantly reduce the micromanagement of re-assigning commanders from supply units to combat units.
Title: Re: C# Suggestions
Post by: villaincomer on May 21, 2021, 05:20:58 AM
Auto Assignment in Naval Command.
To save a but of micro it would be useful to assign people based on criteria.
Perhaps a similar model to that used for colonies.  I.e  Required, secondary and tertiary bonus. But applied to crew training, tactical, or logistics etc.

Bonus:  Same for ship types.  E.g. Primary bonus in surveying for my surveying ships, missiles for my missile ship.  Etc
I know we have allocation of people already based per ship type if say, people are rare.

Of course people can still micro if they choose.

Apologies if this is a duplication.  I couldn't immediately see one related.

I have automated assignments on, plenty of people but naval admin posts arent being filled.
Title: Re: C# Suggestions
Post by: simast on May 21, 2021, 07:33:23 AM
Add manual "auto-assignment" control for ship designs

Currently ship designs get commander auto-assignment based on the components they contain. This leads to various issues, for example if I build an orbital miner and add a cargo space to carry a mass driver - this will not be flagged as an "Orbital Miner" for commander auto-assignment purposes. So you end up micro managing those ships to make sure they have commanders with mining skill.

An option would be to just allow player to override this behavior and manually select ship "role".
Title: Re: C# Suggestions
Post by: Kristover on May 21, 2021, 07:44:09 AM
Conditional Order: Refuel, Resupply, and/or Overhaul at <Destination>

I really dig the exploring game and I tend to set up a lot of orbital stations, advanced bases, and/or forward deployed replenishment ships to support those efforts.  As my empires expand, I might end up having dozens of ships out there surveying so I make judicious use of conditional orders to manage the micro.  The problem is that under the current conditionals, these ships will go to the nearest site - it doesn't matter if it is the most appropriate site or if it is one that has enough to fuel/supplies.  This becomes especially an issue in the early exploration game where I am surveying systems 2 or 3 jumps out from Sol and I might have just Earth, Mars, and one of the Jupiter moons colonized and with facilities on them and with orbital motion, instead of returning to Earth the ship decides the closest point is Europa and goes and drains the fuel I have there to 0 supporting fighters/rescue ships/etc.  I think a conditional <destination> would be a very welcome addition to address it.  The destination can be set to any body - I would expect setting it to a fleet would be a bit much work and throw a lot of errors - but I think a conditional <destination> could work.

This addition would benefit my play ENORMOUSLY.
Title: Re: C# Suggestions
Post by: nuclearslurpee on May 21, 2021, 09:29:45 AM
Add manual "auto-assignment" control for ship designs

Currently ship designs get commander auto-assignment based on the components they contain. This leads to various issues, for example if I build an orbital miner and add a cargo space to carry a mass driver - this will not be flagged as an "Orbital Miner" for commander auto-assignment purposes. So you end up micro managing those ships to make sure they have commanders with mining skill.

An option would be to just allow player to override this behavior and manually select ship "role".

I'd like to clarify on this example specifically:

The commander auto-assignment logic is supposed to work in an order of priorities, which is documented elsewhere but among other criteria assigns Mining-spec commanders to mining ships before assigning Logistics-spec commanders to "other" ships.

However, the logic that determines the class type for auto-assignment purposes prioritizes the cargo hold (Logistics) over the mining modules, which is not the desired behavior in most cases. Notably it prevents designs for orbital miners with an attached cargo hold for a mass driver from being usable with the commander auto-assign.

If manual assignment criteria is too big of an ask (which I can see how it would be so), at least it would be very appreciated to have the ship classification logic match the auto-assign priorities.
Title: Re: C# Suggestions
Post by: ISN on May 21, 2021, 11:45:33 AM
This is pretty minor, but it would be nice if the events when ground forces commanders are killed in combat included the names of those commanders, rather than just saying that the C.O. of the formation was killed. Similarly, when commanders escape to lifepods or fail to escape when their ship is destroyed, the events don't include their ranks for some reason. I like to keep track of my commanders, name things after those killed in the line of duty, etc.
Title: Re: C# Suggestions
Post by: DEEPenergy on May 21, 2021, 11:49:07 AM
I'd like the ability to automate assignments for admin commands and anything else where auto assignment is currently not implemented  :)
Title: Re: C# Suggestions
Post by: Andrew on May 23, 2021, 03:56:27 AM
In the Ship movement command it would be nice to have some way of filtering which contacts are displayed.  With multiple NPR's in one system there are a lot of contacts and when looking for the 3 remaining venusian warships to have them chased down they do tend to get lost in the long list of contacts in no particularly useful order . Being able to filter by race, or something similar would be helpful
Title: Re: C# Suggestions
Post by: skoormit on May 24, 2021, 08:12:18 AM
I would like it if fleets would dynamically optimize the use of Lagrange points.

I use order templates a lot. Any given template might be in use for tens or hundreds of years.
I also stabilize Lagrange points a lot.

As a result, I have lots of order templates through systems with multiple Lagrange points.
Since Lagrange points are not fixed in space, but rather move along the orbit of the parent body, the optimal Lagrange path through a system is not constant over time.
This means I have to re-create my order templates periodically to avoid sending my fleets on suboptimal routes.

A proposal:
1) Automatically include Lagrange point orders at the time of order creation, the way it is done now, if the Auto-include Lagrange Points checkbox is checked.
2) Make the Auto-include Lagrange Points checkbox sticky per fleet.
3) Every time a fleet completes an order, if that fleet is set to Auto-include Lagrange Points and the next order involves movement, reassess (and revise if necessary) the use of Lagrange points to travel to the next non-Lagrange point order target.
(If no subsequent orders involves movement to a location that is not a Lagrange point, then use the last destination in the order list.)

This approach, I think, would add minimal calculation cost during turn gen, would not require significant new code (since it is just reusing the existing code to calculate optimal path at current time), and would greatly improve our ability to use Lagrange points efficiently.
Title: Re: C# Suggestions
Post by: simast on May 25, 2021, 03:07:05 PM
New order - Refuel From Stationary Tankers Until Full

We have recently got the excellent "Load All Minerals Until Full" order for cargo ships - which does reduce the micro and allows us to setup mineral transfer in an efficient way with cargo ships. It would be appropriate to get a similar order for tankers - "Refuel From Stationary Tankers Until Full" so that the same automation could be used with fuel harvesters.
Title: Re: C# Suggestions
Post by: Lord Solar on May 25, 2021, 04:48:01 PM
Right now I playing around with fighters a lot and there is a problem that I keep noticing.
Fighters die, but before they die they create a new fleet. This results in dozens or hundreds of empty fleets than I have to clean up or quarantine to a special admin command for fighter combat.

I suggest a "Delete Empty Fleets"  button that deletes all fleets with no ships in them, are not in any active orders (EG at the time ships are ordered to join that empty), and are not assigned to have ships build into them.
Title: Re: C# Suggestions
Post by: nuclearslurpee on May 25, 2021, 06:36:23 PM
Right now I playing around with fighters a lot and there is a problem that I keep noticing.
Fighters die, but before they die they create a new fleet. This results in dozens or hundreds of empty fleets than I have to clean up or quarantine to a special admin command for fighter combat.

I suggest a "Delete Empty Fleets"  button that deletes all fleets with no ships in them, are not in any active orders (EG at the time ships are ordered to join that empty), and are not assigned to have ships build into them.

I support this, but we will need a toggle to protect specific fleets from this behavior so the Shipyard Fleet doesn't mysteriously disappear.
Title: Re: C# Suggestions
Post by: Droll on May 25, 2021, 07:05:34 PM
Right now I playing around with fighters a lot and there is a problem that I keep noticing.
Fighters die, but before they die they create a new fleet. This results in dozens or hundreds of empty fleets than I have to clean up or quarantine to a special admin command for fighter combat.

I suggest a "Delete Empty Fleets"  button that deletes all fleets with no ships in them, are not in any active orders (EG at the time ships are ordered to join that empty), and are not assigned to have ships build into them.

I support this, but we will need a toggle to protect specific fleets from this behavior so the Shipyard Fleet doesn't mysteriously disappear.

This is literally just the "delete empty pop" but for fleets, which is a good idea. Could also be potentially useful to help in NPR garbage collection in case they have tons of empty fleets that need to be deleted.
Title: Re: C# Suggestions
Post by: Lord Solar on May 25, 2021, 07:29:18 PM
Right now I playing around with fighters a lot and there is a problem that I keep noticing.
Fighters die, but before they die they create a new fleet. This results in dozens or hundreds of empty fleets than I have to clean up or quarantine to a special admin command for fighter combat.

I suggest a "Delete Empty Fleets"  button that deletes all fleets with no ships in them, are not in any active orders (EG at the time ships are ordered to join that empty), and are not assigned to have ships build into them.

I support this, but we will need a toggle to protect specific fleets from this behavior so the Shipyard Fleet doesn't mysteriously disappear.
This is what I tried to say in the last sentence, Shipyard Fleet (s) would be protected.
Title: Re: C# Suggestions
Post by: Demetrious on May 26, 2021, 03:48:07 PM
A tiny suggestion: add an infrequent check that SM-repairs-all civilian ships.

During a recent incursion into the Sol system that caught me with my main fleet elsewhere, I scrambled whatever I had on hand to defend - including a recently completed batch of ten railgun fighters intended for my new carrier, still on the ways. While they couldn't bring the fight to the enemy, they COULD inhibit their missile attacks, and did so - I used them to escort an unlucky civilian cargo ship and they handily shot down every salvo. Only one leaker got through, punching a hole in the freighter's armor and taking out the cargo bay.

As an experiment I let this ship alone, and sure enough, a few times later, I noticed an error message indicating that the freighter in question had failed to pick up a civilian contract load. So I tracked it down in the civilian ships list and SM repaired its cargo bay.

Civilian ships being damaged but not destroyed is of course rare, the remedy is at hand and it even throws an event message. So this isn't exactly high-priority. By the same token, there seems no good reason not to let damaged civilian ships (at sensibly infrequent intervals) automate pressing the "SM Repair All" button. If this could cause problems elsewhere, it's certainly not worth it, but if the occasional civvie ship with a nonfunctional cargo bay could throw an error in other parts of the civilian contract code, it might be an edge case worth plugging. I wouldn't know, I haven't seen the code.  :)

Title: Re: C# Suggestions
Post by: QuakeIV on May 26, 2021, 09:36:03 PM
A tiny suggestion: add an infrequent check that SM-repairs-all civilian ships.

During a recent incursion into the Sol system that caught me with my main fleet elsewhere, I scrambled whatever I had on hand to defend - including a recently completed batch of ten railgun fighters intended for my new carrier, still on the ways. While they couldn't bring the fight to the enemy, they COULD inhibit their missile attacks, and did so - I used them to escort an unlucky civilian cargo ship and they handily shot down every salvo. Only one leaker got through, punching a hole in the freighter's armor and taking out the cargo bay.

As an experiment I let this ship alone, and sure enough, a few times later, I noticed an error message indicating that the freighter in question had failed to pick up a civilian contract load. So I tracked it down in the civilian ships list and SM repaired its cargo bay.

Civilian ships being damaged but not destroyed is of course rare, the remedy is at hand and it even throws an event message. So this isn't exactly high-priority. By the same token, there seems no good reason not to let damaged civilian ships (at sensibly infrequent intervals) automate pressing the "SM Repair All" button. If this could cause problems elsewhere, it's certainly not worth it, but if the occasional civvie ship with a nonfunctional cargo bay could throw an error in other parts of the civilian contract code, it might be an edge case worth plugging. I wouldn't know, I haven't seen the code.  :)

I'd personally favor having the shipping line just scrap ships that have anything other than armor damage, but in any case I agree thats an issue.
Title: Re: C# Suggestions
Post by: Droll on May 29, 2021, 11:36:39 AM
New conditional -  "when cargo bays full"
New conditional order -  "unload all minerals, components and installations at colony"

Mostly for automating salvage ships.
Title: Re: C# Suggestions
Post by: Droll on May 29, 2021, 10:37:02 PM
When an alien ship is captured, populate the intel screen text field of the appropriate ship class with the design details (the largely unused space).

Also, in addition to having intel about a race's technology, also include a new field or all designable race-specific components like weapons, shields etc.
Title: Re: C# Suggestions
Post by: Steve Walmsley on May 30, 2021, 04:48:40 AM
When an alien ship is captured, populate the intel screen text field of the appropriate ship class with the design details (the largely unused space).

I thought that already happened. If not, that is a bug.
Title: Re: C# Suggestions
Post by: nuclearslurpee on May 30, 2021, 09:52:35 AM
When an alien ship is captured, populate the intel screen text field of the appropriate ship class with the design details (the largely unused space).

I thought that already happened. If not, that is a bug.

It does not seem to. In my game (still 1.12, though) if I capture a ship (well, in my case they surrendered to me as I don't have boarding marines yet) the design specs are added to my class designs, but not the intel screen. The intel screen only seems to hold designs that I've gained intelligence about from e.g. capturing prisoners.
Title: Re: C# Suggestions
Post by: ChubbyPitbull on May 30, 2021, 10:52:40 AM
When an alien ship is captured, populate the intel screen text field of the appropriate ship class with the design details (the largely unused space).

I thought that already happened. If not, that is a bug.

Steve, is it intended that the Class Summary should be completed after capturing, or just the other "Observed Weapons/Sensors/Tech" fields? Looking through my intel windows those appear to be filled out,
Title: Re: C# Suggestions
Post by: Droll on May 30, 2021, 12:16:43 PM
When an alien ship is captured, populate the intel screen text field of the appropriate ship class with the design details (the largely unused space).

I thought that already happened. If not, that is a bug.

The intel screen updates information regarding the technology present in the ship only.
The description of the class design does not update, honestly I thought it wasn't implemented yet, which is why it was a suggestion and not a bug report.
Title: Re: C# Suggestions
Post by: Droll on May 30, 2021, 12:18:27 PM
The "Observed Weapons/Sensors/Tech" does not update once a ship has been captured, much like the text description of the class design.


As I said, the only thing that updates is the known technology onboard the ship.
Title: Re: C# Suggestions
Post by: Andrew on May 30, 2021, 02:51:15 PM
The ability to set fleet training at the start of the game, to represent established fleets so you don't have to train all ships at the start of the game
Title: Re: C# Suggestions
Post by: Platys51 on May 30, 2021, 04:04:58 PM
I would like to suggest changing espionage roll table to not include infinite "Race X is in war with *insert known spoiler*" I had 11 reports like that so far from my neighbour. Its about one fourth of all reports I got from them...
Title: Re: C# Suggestions
Post by: Froggiest1982 on May 30, 2021, 04:22:20 PM
Finally, civilian mining outposts to be able to generate a small amount of pop that can emigrate.

Not really sure about this one. First, Civilian Mining Outposts are fully Automated but mostly this will cause the Outpost to become a Colony with consequential listing into civilian fleet activity for trading and generation of trading goods. Overall, this could cause also cluttering on the orders tab for fleets and ultimately several performance issues.
Title: Re: C# Suggestions
Post by: nuclearslurpee on May 30, 2021, 04:40:40 PM
I would like to suggest changing espionage roll table to not include infinite "Race X is in war with *insert known spoiler*" I had 11 reports like that so far from my neighbour. Its about one fourth of all reports I got from them...

In general redundant espionage reports get annoying. I've 'discovered' the same enemy sensor entirely too many times...
Title: Re: C# Suggestions
Post by: Droll on May 30, 2021, 05:20:33 PM
I would like to suggest changing espionage roll table to not include infinite "Race X is in war with *insert known spoiler*" I had 11 reports like that so far from my neighbour. Its about one fourth of all reports I got from them...

In general redundant espionage reports get annoying. I've 'discovered' the same enemy sensor entirely too many times...

This is almost certainly a bug that should be on the bug thread. There is no reason to rediscover the same component.
Title: Re: C# Suggestions
Post by: nuclearslurpee on May 30, 2021, 05:21:27 PM
I would like to suggest changing espionage roll table to not include infinite "Race X is in war with *insert known spoiler*" I had 11 reports like that so far from my neighbour. Its about one fourth of all reports I got from them...

In general redundant espionage reports get annoying. I've 'discovered' the same enemy sensor entirely too many times...

This is almost certainly a bug that should be on the bug thread. There is no reason to rediscover the same component.

Sadly I'm still playing 1.12 so I can't file such a report.
Title: Re: C# Suggestions
Post by: Droll on May 30, 2021, 07:01:41 PM
In 1.13 carriers will use MSP to repair armor damage sustained by any parasites in its hangars.
Extend this ability to damaged internal components too.
Title: Re: C# Suggestions
Post by: Lord Solar on May 30, 2021, 09:22:36 PM
In 1.13 carriers will use MSP to repair armor damage sustained by any parasites in its hangars.
Extend this ability to damaged internal components too.
carriers do this already
Title: Re: C# Suggestions
Post by: Droll on May 30, 2021, 10:25:16 PM
In 1.13 carriers will use MSP to repair armor damage sustained by any parasites in its hangars.
Extend this ability to damaged internal components too.
carriers do this already

Pretty sure they don't. At the very least my carrier which was housing damaged CAS fighters did not do this, only their armor was repaired.
Idk if there's some setting I missed that enables it but I made that post after I noticed my carriers weren't doing this.

EDIT: And yes, the carrier had plenty of MSP for all damaged fighters.
Title: Re: C# Suggestions
Post by: ChubbyPitbull on May 31, 2021, 08:40:07 AM
If your ships have Fire Controls on Open Fire but don't have any targets assigned, it would be good if you got an event log about it. Have gotten stuck a number of times in 5 second increments because I missed a fleet who had been firing and lost their target; I get logs that the increment had been auto adjusted to 5 seconds because of potential open fire controls, but no log as to which of my ships still was on Open Fire and causing the increment to be decreased. Each time I have to go one by one through my fleets and make sure all had been told to cease fire to resolve the issue.
Title: Re: C# Suggestions
Post by: Coleslaw on May 31, 2021, 12:58:43 PM
I was hesitant to put this into the bugs reporting since I don't think it's technically a bug. The Fire At Will fleet setting doesn't retarget a different enemy ship after destroying its initial target. You have to manually select Fire At Will again for it to select a new target. It'd cut some unnecessary micro if it did, especially during large fleet combats.
Title: Re: C# Suggestions
Post by: ChubbyPitbull on May 31, 2021, 02:00:38 PM
I've really been enjoying the new ground mechanics in C# Aurora, but there are a few QoL changes I think would be nice. For one, I've been building lots of STO formations to defend colonies, but it's hard going through every single new formation to set default orders. It would be nice when defining an STO formation to also define default firing orders for it. For example, my Gauss Cannon Batteries could at design time be set to default to "Final Defensive Fire" so that once built, they would already be set to that order instead of having to constantly go back and manually set them.

This would especially be advantageous for my Garrison or Planetary Defense formations that combine Anti-Missile weapons as well as various anti-ship weapons. The goal is a base general colony defense capability, but each formation adds 3 entries to the STO weapons table that could require manual retargeting after being built.

Similarly, it would be cool to have the ability on the STO targeting tab to give all weapons of type X the same order, or all weapons of type X on the same planet the same order.
Title: Re: C# Suggestions
Post by: Droll on May 31, 2021, 02:24:33 PM
I was hesitant to put this into the bugs reporting since I don't think it's technically a bug. The Fire At Will fleet setting doesn't retarget a different enemy ship after destroying its initial target. You have to manually select Fire At Will again for it to select a new target. It'd cut some unnecessary micro if it did, especially during large fleet combats.

It's certainly not a bug but I'd also like to add an extension to the fire at will buttons that should be quite obvious based on their name.
Fire at will BFC
Fire at will MFC

It's quite bad when I tell the fleet to fire at will and then all the AMM ships start wasting precious AMM unless I go and disable their FCs. For me its annoying because my missile ships can have like 5-8 MFCs on them.
Title: Re: C# Suggestions
Post by: TMaekler on June 02, 2021, 02:46:57 AM
Anyway, when I assign my junior officer with the best Crew Training skill to be the XO of a warship, the auto-assignment feature inevitably reassigns him to command the next fighter that rolls off the production line, which is a complete waste of his talents.
Usually if I'm going to be using a lot of fighters, I tick the box on my large ship designs to bump up the officer ranks by one level so my XOs are e.g. CDRs instead of LCDRs.

Somewhere in the Suggestions thread I posted that it would be good to have the Reaction skill be the preferred skill for warship commanders in the auto-assignment algorithm instead of Crew Training, to reserve the latter skill for XO postings and since Reaction has no corresponding officer module (whereas Crew Training, Engineering, and Tactical do). It would also be really great if Fighter Combat was actually checked by the auto-assignment as I don't think it currently is.

Generally speaking, it would be nice if we somehow could define the rules for the auto selection in some place. Maybe Steve can rework it in a way that the rules are not hard coded but live in the DB and can be changed like rules for medals in a UI screen? It would also open up for individual play and promotion styles for different empires.
Title: Re: C# Suggestions
Post by: Density on June 02, 2021, 07:26:15 AM
Generally speaking, it would be nice if we somehow could define the rules for the auto selection in some place. Maybe Steve can rework it in a way that the rules are not hard coded but live in the DB and can be changed like rules for medals in a UI screen? It would also open up for individual play and promotion styles for different empires.

I also would love to see some kind of player-defined rules for auto-assign beyond the current priority system.
Even just a tick box to define a ship design as less important than non-CO command positions would be huge.
Title: Re: C# Suggestions
Post by: Density on June 02, 2021, 07:38:51 AM
On a tangental note, not sure if this is a bug, but it'd be nice if Chief Engineers could gain experience in Engineering. (Or maybe I'm just getting extreme RNG on this point.)

So far my observations are that ENGs can gain Crew Training and Reaction, but not Engineering. (Naval Admins can gain Engineering, so it doesn't seem to be a non-trainable skill.) Which means that with auto assignments, commanders with Engineering get posted to ENG, then eventually gain Crew Training, then get moved to the next CO post on a fighter that opens up.

If this is a bug, I suspect it hasn't come up because I only started noticing the lack of Engineering experience after I stopped using auto assignments.
Title: Re: C# Suggestions
Post by: Droll on June 02, 2021, 08:02:49 AM
On a tangental note, not sure if this is a bug, but it'd be nice if Chief Engineers could gain experience in Engineering. (Or maybe I'm just getting extreme RNG on this point.)

So far my observations are that ENGs can gain Crew Training and Reaction, but not Engineering. (Naval Admins can gain Engineering, so it doesn't seem to be a non-trainable skill.) Which means that with auto assignments, commanders with Engineering get posted to ENG, then eventually gain Crew Training, then get moved to the next CO post on a fighter that opens up.

If this is a bug, I suspect it hasn't come up because I only started noticing the lack of Engineering experience after I stopped using auto assignments.

I wonder if tactical has the same problem.
Title: Re: C# Suggestions
Post by: Density on June 02, 2021, 01:32:41 PM
I wonder if tactical has the same problem.

Just started retooling for a generation of ships with CICs, so I'll let you know what I see "soon."
Title: Re: C# Suggestions
Post by: ChubbyPitbull on June 05, 2021, 07:34:32 PM
Building on the ground formation enhancement suggestions, it would be nice when working on Ground Forces OOB, we could multi-select with shift-clicks or control clicks to easily drag multiple formations at once. So for example when moving 4 brigades to be under a division HQ, or when dropping all the STO units under an omnibus administrative HQ unit, I can do it all at once instead of having to individually move 20 units.

Also, when opening the Ground Forces OOB list, would also be nice if formations and drop-downs aren't auto-expanded; right now when I open it it expands random HQs so I have to scroll a long way to get to the colony I'm looking to work on.
Title: Re: C# Suggestions
Post by: xenoscepter on June 05, 2021, 07:44:56 PM
A few things I thought of; just gonna list 'em here for perusal at one's leisure. :)
Link to Standalone Thread Here ====> http://aurora2.pentarch.org/index.php?topic=12598.0

  -  A Jump Cooldown w/ Shock Mechanic Tweak: Have Jump Shock be tied to max Jump Tonnage as a function of Increments per 5HS, with 5 seconds minimum. Then multiply it by the number of ships jumped; 1.25x per ship for Squadron, 1.5x for Standard with the rates doubled for Commercial Drives. When under the effects of Jump Shock, ships cannot perform another jump, but a ship not suffering from jump shock CAN jump ships that are. Jump Shock would NOT be cumulative when this happens, simply being reset to either the new value or the old value, whichever is longer.

  -  Transit Drive: A type of Jump Drive that runs on fuel, allows instant transit between points within a system. I had the idea that it would use special fuel, and have it's own special fuel tanks to hold them with the base capacity being 1 Unit of Jump Fuel per HS. Each jump would require one unit of this "Jump Fuel" and larger Fuel Tanks would give more Jump Fuel per HS, but at the trade-off of being more expensive. Each Transit Drive could have at least one unit of Jump Fuel capacity built in, although larger drives might have more and REALLY small (like, Fighter-scale) would have none. These drives could also transit Jump Points, both stabilized and non-stabilized, but would only transit the ship mounting them in addition to giving higher amounts of Jump Shock than if an actual Jump Drive was used. If implemented with the above changes to Jump Drives, it would give double the amount if Military, but Triple if the Transit Drive was Commercial. Like regular Jump Drives, these would be tied to engine type.
Off-Topic: show

 --- Designing a Transit Drive would involve the following:

  1. Choosing a Jump Drive Efficiency, tied to the existing Tech, but with a 2x modifier applied.

  2. Choosing a Jump Drive Size.

  3. Choosing a Jump Fuel Capacity, new tech with the values "0" and "1" available from the start. Adds 1HS per unit of capacity. (Optional)

  -  "Pulse" Sensor: A variant of the Active Sensor that is smaller and more powerful than a regular version. Has a cooldown between uses and is significantly more visible than a regular Active Sensor of equal strength. Fluff wise the unit uses capacitors to "charge up" power and then releases it all at once to detect targets. Some ideas for implementation include:
Off-Topic: show

  1. A separate module that allows mounted sensors to be pulsed, with an order to go with it. This would make all mounted Active Sensors "pulse".

  2. Having them be their own sensor "type" selected from the same drop down as Missile FCS and tied to the "Turn Active Sensors On", but with a "ping" between them to represent the cooldown.

  3. Same as #2, but tied to it's own order like #1. This would allow only the "Pulse" Sensors to be fired, while allowing the active ones to remain on or off.

 --- Coding #1 would likely involve a new part type added along with new flags to check for it and possibly even new techs as well. Coding #2 might prove the easiest as it uses most of the existing framework, but just needs to be tied to the increments for the "ping". Coding #3 would require a new order set, much like #1, and could potentially generate a faux-missile centered on the ship doing the "pulse" that would generate the relative Active Sensor effect as well as the related EM spikes.

  -  Commercial Engine Change: Currently, to qualify as Commercial an engine must take up at least 1,250 Tons(25HS) and possess a Power Modifier of 50% or less. Under this suggestion the minimum size of engine would be tied to the power modifier. For every 10% less than 50, the HS requirement for an engine to be considered Commercial would be 5HS less. So, under this proposal we would have:
Off-Topic: show

  1,250 Tons(25HS) = 50% or less for Commercial Rating.

  1,000 Tons(20HS) = 40% or less for Commercial Rating.

    750 Tons(15HS) = 30% or less for Commercial Rating.

    500 Tons(10HS) = 20% or less for Commercial Rating.

    250 Tons(5HS) = 10% or less for Commercial Rating.
Title: Re: C# Suggestions
Post by: Droll on June 05, 2021, 08:20:20 PM
Generally speaking, it would be nice if we somehow could define the rules for the auto selection in some place. Maybe Steve can rework it in a way that the rules are not hard coded but live in the DB and can be changed like rules for medals in a UI screen? It would also open up for individual play and promotion styles for different empires.

I also would love to see some kind of player-defined rules for auto-assign beyond the current priority system.
Even just a tick box to define a ship design as less important than non-CO command positions would be huge.

I have before suggested an "exclude class from auto-assignment" button.
As for choosing preferred properties for CO and bridge positions on a specific class of ship I think this is a good idea, especially since the game already does something like this with auto-assign governors.
Title: Re: C# Suggestions
Post by: linkxsc on June 05, 2021, 11:02:56 PM
1. Per my attachment. On screens showing tasks and a "Completion date". Can't actually tell when techs, ships, ground units, and etc are actually going to be complete due to the date format being so... verbose.

Could you please update it such that the columns on these menus are resizeable. Or, if that proves to be annoying, maybe throw a radio button somewhere to set the date format to something smaller like YYYY/MM/DD/Monday?


2. Could we get some multi-select capability in the task force management screen? IE, ctrl clicking multiple ships in a fleet to drag to another fleet. Or perhaps shift clicking at the top and bottom of a group of ships to multi-select them.
Same goes for Ground Forces. Managing large armies can get extremely click intensive.
Title: Re: C# Suggestions
Post by: Droll on June 06, 2021, 10:28:23 AM
2. Could we get some multi-select capability in the task force management screen? IE, ctrl clicking multiple ships in a fleet to drag to another fleet. Or perhaps shift clicking at the top and bottom of a group of ships to multi-select them.
Same goes for Ground Forces. Managing large armies can get extremely click intensive.

2. is possible for ships, instead of trying to select ships in the tree view, try ctrl-clicking or shift-clicking in the "ship list" tab of the naval org window.
For ground units it would be very nice to have this.
Title: Re: C# Suggestions
Post by: YABG on June 06, 2021, 12:35:05 PM
Don't know if something like this has been suggested before, but I'd like to suggest a new game setting - asteroid richness and planetary richness.

Richness would be a percentage (default 100%) which changes how many minerals are spawned. We could have individual settings for asteroids and planets (comets could be separate or joint with asteroids) to further tailor a campaign.

You could have these settings be editable during the campaign, so if you want asteroid mining to be more important early on when you're putting about sol but then returning to normal once you leave you could do edit the mineral route easily.

Edit: further to that, I'd like to suggest that when you use the redo minerals button on a mineral less body, it repeats the routine until you get a result with minerals. There probably aren't very many cases where someone using redo minerals on a mineral less body wants it to remain a mineral less body, if that makes sense.
Title: Re: C# Suggestions
Post by: Density on June 06, 2021, 01:21:34 PM
1. Per my attachment. On screens showing tasks and a "Completion date". Can't actually tell when techs, ships, ground units, and etc are actually going to be complete due to the date format being so... verbose.

Could you please update it such that the columns on these menus are resizeable. Or, if that proves to be annoying, maybe throw a radio button somewhere to set the date format to something smaller like YYYY/MM/DD/Monday?

This pulls from the long date format for windows, and can be changed in your windows settings.
Title: Re: C# Suggestions
Post by: Sebmono on June 06, 2021, 08:39:55 PM
Was thinking today that something I would love to see is the ability to assign weapons to fire controls on the ship design screen, similar to how we can assign ordnance and fighter loadouts. This would be a huge timesaver for me! :)
Title: Re: C# Suggestions
Post by: Droll on June 06, 2021, 08:49:30 PM
Was thinking today that something I would love to see is the ability to assign weapons to fire controls on the ship design screen, similar to how we can assign ordnance and fighter loadouts. This would be a huge timesaver for me! :)

Excellent idea. Just in case you didn't know though:
If you have at least one instance of a class in active service, you can use "assign all" to copy it's weapon/FC assignments to all other instances of that class which means that often its just a couple clicks before battle to assign everything the way you want it.
Title: Re: C# Suggestions
Post by: Sebmono on June 06, 2021, 11:46:25 PM
Excellent idea. Just in case you didn't know though:
If you have at least one instance of a class in active service, you can use "assign all" to copy it's weapon/FC assignments to all other instances of that class which means that often its just a couple clicks before battle to assign everything the way you want it.
Great reminder, I often forget about that one until way after the fact but it is indeed better than going one by one or fleet by fleet.
Title: Re: C# Suggestions
Post by: Blogaugis on June 09, 2021, 05:50:53 AM
I have a suggestion about ground force HQ and fire direction units:

Make them have another parameter - operating range.
The simple explanation is: have options for HQ and fire direction units to be:

Planetary - which essentially limits their capability to command/direct fire the units in the same planet and it's orbit, Generally, what we have now;
Solar System/interplanetary - Allows commanders in HQs to provide bonuses to units under their command while in the same solar system, and FFDs to provide coordinates for ships/STOs further away from the planet;
Sector/Interstellar - A bit like Naval Admin command range, it is generally relevant to the HQ formations than FFDs (since, I don't know if you can fire a missile, make it go through a wormhole, and then find the FFD's indicated coordinates?)

This feature would allow to design 'Command and Control ships', that can hold, like, Army group HQ (rank 7, with like 1. 000. 000 Command points and Solar System/Interplanetary upgrade) that provides commander bonuses to units fighting on a Planet in this system (with just planetary upgrade), while this Army group HQ could itself be attached to a 'Earth High Command' (rank 8, with 10. 000. 000 Command points and Sector/Interstellar upgrade).
For FFD unit, with Solar System/Interplanetary upgrade, it could direct fire from a STO on a moon that is orbiting the planet on which the FFD is.

Mechanically wise, these options can function similarly to upgrades that we have now.  What they essentially do - in case of HQ unit, they double the price of the HQ unit if it is Solar system/Interplanetary upgrade, triple or quadruple (perhaps there can be another variable, like with Naval Command HQs), determining how big their operating range is.

Generally, another mechanically supported role-play option.  It would allow us to have a more interesting means to disperse our forces across solar systems, making dugouts and small defensible fortresses on them a more viable strategy in terms of defending the solar system.

Semi-autonomous bases on asteroids further away - Activate!
Title: Re: C# Suggestions
Post by: QuakeIV on June 09, 2021, 06:14:41 PM
I like the idea of room in the mechanics for command and control ships.
Title: Re: C# Suggestions
Post by: Nori on June 09, 2021, 08:10:23 PM
I may just not know how to do this, but in case...
When I rescue survivors they seem to go on the first ship in the fleet. Which would be fine if I had no ships with cryo. But, I nearly always have a few ships in a battlefleet with 250, or 1k cryo for RP/rescues. Inevitably the survivors always go on a ship without cryo.

Anyway to a preference could be added for the ships that have cryo?
Title: Re: C# Suggestions
Post by: Droll on June 09, 2021, 08:15:43 PM
I may just not know how to do this, but in case...
When I rescue survivors they seem to go on the first ship in the fleet. Which would be fine if I had no ships with cryo. But, I nearly always have a few ships in a battlefleet with 250, or 1k cryo for RP/rescues. Inevitably the survivors always go on a ship without cryo.

Anyway to a preference could be added for the ships that have cryo?

Yeah the game should prioritize cryo capable ships first for picking up survivors.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 09, 2021, 08:59:55 PM
I may just not know how to do this, but in case...
When I rescue survivors they seem to go on the first ship in the fleet. Which would be fine if I had no ships with cryo. But, I nearly always have a few ships in a battlefleet with 250, or 1k cryo for RP/rescues. Inevitably the survivors always go on a ship without cryo.

Anyway to a preference could be added for the ships that have cryo?

Yeah the game should prioritize cryo capable ships first for picking up survivors.

Fixed in 1.14:
Quote
Updated the rescue code so that the fleet ship that picks up a specific life pod is the first ship in a list ordered by Descending Available Cryogenic Capacity then Descending (Class Crew - Current Survivors)
Title: Re: C# Suggestions
Post by: linkxsc on June 10, 2021, 12:08:58 PM
Civilian Industry.

A building type that acts like an upgraded conventional industry. Only at about 25% efficiency (compared to regular TN factories)

Untransportable, and un-upgradable. This industry spawns on colonies of sufficient size that have significant amounts of unemployment. ,Have it set to a low priority for jobs (due to the cushy jobs at govt construction centers paying better perhaps)
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 10, 2021, 01:55:59 PM
Add a "Match Target Speed" order, which functions identically to the Follow order except that once you reach the contact (or the specified minimum distance) the fleet speed is set to the same speed as the target if possible.

This would make following enemy fleets while avoiding their weapons range a bit less micromanage-y, especially if the speed matching part of the order remains active, i.e. if the target speed changes so does your fleet's speed to match.
Title: Re: C# Suggestions
Post by: Blogaugis on June 11, 2021, 10:28:15 AM
I have another suggestion/question:

Would it be feasible to have a "Cargo Hold - Fighter", with 250 ton size (or less) in the game?
Considering that a ship has to be 500 tons or smaller in order to interact with a planet (to load cargo, passengers, etc.), do we still need to rely on Cargo Shuttle Bays, or would it be possible to micro-design them ourselves?

I feel like I'm making a mistake with a cryogenic shuttle design, in terms of practicality.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 11, 2021, 11:41:43 AM
I have another suggestion/question:

Would it be feasible to have a "Cargo Hold - Fighter", with 250 ton size (or less) in the game?
Considering that a ship has to be 500 tons or smaller in order to interact with a planet (to load cargo, passengers, etc.), do we still need to rely on Cargo Shuttle Bays, or would it be possible to micro-design them ourselves?

I feel like I'm making a mistake with a cryogenic shuttle design, in terms of practicality.

You can get away with not having a cargo shuttle bay, but only if the source and destination colonies both have cargo handling capability themselves. Otherwise it won't work.

At any rate, a "microfreighter" like this is extremely impractical anyways - the small engine size means not only is fuel efficiency very poor but it is impossible to make these as a commercial ship, so your "freighters" will eat into your maintenance capacity as military vessels. If you want small freighters you're usually better off with a small commercial design, a single commercial engine is 1,250 tons at minimum so a ship in the 3,000-5,000 ton range can work, or you can build up to 10,000 tons (size of a new commercial yard) with 2-3 engines and more cargo space. Such designs are usually most practical for moving minerals around where mass drivers are not practical, although pretty quickly you'll find a need for more traditional large freighters once you start expanding mining operations appreciably.
Title: Re: C# Suggestions
Post by: Blogaugis on June 11, 2021, 01:04:52 PM
You can get away with not having a cargo shuttle bay, but only if the source and destination colonies both have cargo handling capability themselves. Otherwise it won't work.

At any rate, a "microfreighter" like this is extremely impractical anyways - the small engine size means not only is fuel efficiency very poor but it is impossible to make these as a commercial ship, so your "freighters" will eat into your maintenance capacity as military vessels. If you want small freighters you're usually better off with a small commercial design, a single commercial engine is 1,250 tons at minimum so a ship in the 3,000-5,000 ton range can work, or you can build up to 10,000 tons (size of a new commercial yard) with 2-3 engines and more cargo space. Such designs are usually most practical for moving minerals around where mass drivers are not practical, although pretty quickly you'll find a need for more traditional large freighters once you start expanding mining operations appreciably.
Guess what? It didn't work.
The less than 500 ton shuttle can't even work as a shuttle - colonists couldn't leave the ships.

We need SPECIALIZED shuttles (The ones in the background of 'Cargo Shuttle Bay', and not the ones you spend oh so long creating in the designs screen)!
Out of the idea of a quick colonist shuttle transport, I get nothing.
Sorry sir, we're not IMPLEMENTED to react with a planet in this way! - imagine hearing this while role-playing as a shuttle transport captain...

Well, I suppose I'll add another suggestion then:
In the class design screen, It would be nice to have categories and subcategories of components, like - cargo/colonist/ordnance/fuel handling components - Once you open this category, you can then choose one of these 4, and then choose the specific component you're looking for.
CCOFtT -> Cargo/Colonist/Ordance/Fuel/Troop Transport -> Cargo ->
- actually, there already is 'cargo hold' category, and plenty of others...
Also - It would be nice if in the events screen it says that the loading/unloading orders could not be completed due to lack of Cargo Shuttle Bays or planetary installations.
Title: Re: C# Suggestions
Post by: Droll on June 11, 2021, 01:33:29 PM
You can get away with not having a cargo shuttle bay, but only if the source and destination colonies both have cargo handling capability themselves. Otherwise it won't work.

At any rate, a "microfreighter" like this is extremely impractical anyways - the small engine size means not only is fuel efficiency very poor but it is impossible to make these as a commercial ship, so your "freighters" will eat into your maintenance capacity as military vessels. If you want small freighters you're usually better off with a small commercial design, a single commercial engine is 1,250 tons at minimum so a ship in the 3,000-5,000 ton range can work, or you can build up to 10,000 tons (size of a new commercial yard) with 2-3 engines and more cargo space. Such designs are usually most practical for moving minerals around where mass drivers are not practical, although pretty quickly you'll find a need for more traditional large freighters once you start expanding mining operations appreciably.
Guess what? It didn't work.
The less than 500 ton shuttle can't even work as a shuttle - colonists couldn't leave the ships.

We need SPECIALIZED shuttles (The ones in the background of 'Cargo Shuttle Bay', and not the ones you spend oh so long creating in the designs screen)!
Out of the idea of a quick colonist shuttle transport, I get nothing.
Sorry sir, we're not IMPLEMENTED to react with a planet in this way! - imagine hearing this while role-playing as a shuttle transport captain...

Well, I suppose I'll add another suggestion then:
In the class design screen, It would be nice to have categories and subcategories of components, like - cargo/colonist/ordnance/fuel handling components - Once you open this category, you can then choose one of these 4, and then choose the specific component you're looking for.
CCOFtT -> Cargo/Colonist/Ordance/Fuel/Troop Transport -> Cargo ->
- actually, there already is 'cargo hold' category, and plenty of others...
Also - It would be nice if in the events screen it says that the loading/unloading orders could not be completed due to lack of Cargo Shuttle Bays or planetary installations.

This sounds like a bug. The whole shtick of 500 ton fighter sized craft is that they don't need cargo handling facilities to interact with planets. If your design is considered as a fighter by the game, then you should not need a cargo shuttle bay to land cargo/colonists on a planet. So I feel like this is a bug.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 11, 2021, 02:00:07 PM
This sounds like a bug. The whole shtick of 500 ton fighter sized craft is that they don't need cargo handling facilities to interact with planets. If your design is considered as a fighter by the game, then you should not need a cargo shuttle bay to land cargo/colonists on a planet. So I feel like this is a bug.

Not sure if this is a bug, my understanding of fighters was that in spite of the lore around them their only special mechanic was being built by planetary facilities. Once they're built they don't have any other special rules aside from benefitting from Fighter Combat skills.

As a suggestion though expanding the fighter mechanics to fit the lore is a good idea, in a broader sense. I know many players would also like to be able to do ground-side refits for example. The ability to land fighters on a planet and keep them safe from enemy spaceships (unless orbital bombardment happens) also seems neat.
Title: Re: C# Suggestions
Post by: Droll on June 11, 2021, 02:54:22 PM
Not sure if this is a bug, my understanding of fighters was that in spite of the lore around them their only special mechanic was being built by planetary facilities. Once they're built they don't have any other special rules aside from benefitting from Fighter Combat skills.

I can't be bothered to dig through the C# mechanics changes thread for the first release right now but IIRC one of the posts there explicitly stated that fighters did not need planetary cargo handling facilities to interact with planets, the lore justification for the mechanic being that fighters could viably perform planetary landings.

That's why I think it's a bug that fighters can't do this. Though I suppose you also have a point in that there actually isn't a fighter sized cargo bay in the game right now, but you do have cryo that can be fit onto a fighter so why not (I mean fighter sized cargo bays to the order of 200t is a good suggestion too).
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 11, 2021, 03:08:39 PM
I can't be bothered to dig through the C# mechanics changes thread

But I can!

Closest I can find is this post here (http://aurora2.pentarch.org/index.php?topic=8495.msg105591#msg105591). It comes close to what you are describing, stating that lore-wise only craft of <500 tons can land on a planet, and using this as the logic for cargo shuttles. However, it does not state explicitly that fighter-size ships would be able to land on a planet to load and unload cargo.

I'd guess that Steve never thought anyone would actually be trying to do this for any purpose other than RP and thus either didn't think of or didn't get around to implementing shuttle-free load/unload for fighters.
Title: Re: C# Suggestions
Post by: Droll on June 11, 2021, 03:53:25 PM
I can't be bothered to dig through the C# mechanics changes thread

But I can!

Closest I can find is this post here (http://aurora2.pentarch.org/index.php?topic=8495.msg105591#msg105591). It comes close to what you are describing, stating that lore-wise only craft of <500 tons can land on a planet, and using this as the logic for cargo shuttles. However, it does not state explicitly that fighter-size ships would be able to land on a planet to load and unload cargo.

I'd guess that Steve never thought anyone would actually be trying to do this for any purpose other than RP and thus either didn't think of or didn't get around to implementing shuttle-free load/unload for fighters.

This is the post I was thinking of, now that I re-read it, I think you might be right in your interpretation. I recall reading that post and making the assumption that the 500 ton rule was supposed to be all crafts below 500 tons and didn't realize that it was specifically referring to the shuttles that are a part of the cargo shuttle bay component.
Title: Re: C# Suggestions
Post by: QuakeIV on June 11, 2021, 09:16:04 PM
To be honest I bet you he forgot.
Title: Re: C# Suggestions
Post by: xenoscepter on June 11, 2021, 11:47:31 PM
I can't be bothered to dig through the C# mechanics changes thread

But I can!

Closest I can find is this post here (http://aurora2.pentarch.org/index.php?topic=8495.msg105591#msg105591). It comes close to what you are describing, stating that lore-wise only craft of <500 tons can land on a planet, and using this as the logic for cargo shuttles. However, it does not state explicitly that fighter-size ships would be able to land on a planet to load and unload cargo.

I'd guess that Steve never thought anyone would actually be trying to do this for any purpose other than RP and thus either didn't think of or didn't get around to implementing shuttle-free load/unload for fighters.

This is the post I was thinking of, now that I re-read it, I think you might be right in your interpretation. I recall reading that post and making the assumption that the 500 ton rule was supposed to be all crafts below 500 tons and didn't realize that it was specifically referring to the shuttles that are a part of the cargo shuttle bay component.

 --- Well, I pestered Steve about Fighter-Sized Colony Ships, and he implemented them for v1.11. They were buggy though, and AFAIK, remained so through v1.12. However, in v1.13 I believe they are fixed... although I haven't tested that theory...
Title: Re: C# Suggestions
Post by: kyonkundenwa on June 12, 2021, 09:49:12 AM
Closest I can find is this post here (http://aurora2.pentarch.org/index.php?topic=8495.msg105591#msg105591). It comes close to what you are describing, stating that lore-wise only craft of <500 tons can land on a planet, and using this as the logic for cargo shuttles. However, it does not state explicitly that fighter-size ships would be able to land on a planet to load and unload cargo.

I'd guess that Steve never thought anyone would actually be trying to do this for any purpose other than RP and thus either didn't think of or didn't get around to implementing shuttle-free load/unload for fighters.

In the 1.12 changes list (http://aurora2.pentarch.org/index.php?topic=11593.0), Steve explicitly states that "Fighter-sized craft do not require cargo shuttles to load / unload colonists or cargo. Due to their size they can land and load/unload directly."
I don't know if it actually works. I made an engineless fighter with cryo transports the other day and it couldn't load/unload without a cargo station but that might be because it was engineless. I didn't test it exhaustively in order to produce a bug report.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 12, 2021, 10:26:41 AM
Closest I can find is this post here (http://aurora2.pentarch.org/index.php?topic=8495.msg105591#msg105591). It comes close to what you are describing, stating that lore-wise only craft of <500 tons can land on a planet, and using this as the logic for cargo shuttles. However, it does not state explicitly that fighter-size ships would be able to land on a planet to load and unload cargo.

I'd guess that Steve never thought anyone would actually be trying to do this for any purpose other than RP and thus either didn't think of or didn't get around to implementing shuttle-free load/unload for fighters.

In the 1.12 changes list (http://aurora2.pentarch.org/index.php?topic=11593.0), Steve explicitly states that "Fighter-sized craft do not require cargo shuttles to load / unload colonists or cargo. Due to their size they can land and load/unload directly."
I don't know if it actually works. I made an engineless fighter with cryo transports the other day and it couldn't load/unload without a cargo station but that might be because it was engineless. I didn't test it exhaustively in order to produce a bug report.

In that case someone who has confirmed this should report it as a bug. I would do it but I can't confirm myself at the moment.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on June 12, 2021, 11:27:10 AM
I can verify that small crafts still can't unload/load cargo on their own, at least not colonists which is what I tested, I did not try from a cargo hold.

Another issue that still exist is that Troop Transports can unload/load troops on any planet no matter their size without cargo shuttles a well, I'm pretty sure they are not suppose to be able to do that. At least it is a bit weird that they can.
Title: Re: C# Suggestions
Post by: Polestar on June 12, 2021, 12:14:23 PM
Some suggestions and observed issues, based on a couple of 1.13 games:

1. The Swarm is too variable in the danger level it poses, and can be far too deadly. What deep-space bugs should not do is a) scout your home planet (>10B km away from any jump point or linked LP point) five years into a game, park 10s of thousands of tons-worth of warships in orbit a few months later, destroy all your shipyards, and start bombarding your helpless early-game homeworld to dust and ruin. Endlessly, because they never run out of supplies.

This is unfair, because:
a) The player, if they set up using ordinary early-TN tech levels (the ones the game offers as defaults), may well not be able to fend off such an attack so early on. "You lose. Regardless of any attempt you might have made at preparedness." is not what a game should tell players. This applies also to the Invaders.
b) Distance should matter to the AIs. If the AI can't be made to understand fuel limits, it should at least respect a travel distance limit.
c) Supplies should matter to the AIs, at least in some sense. They don't have to run out when attacked, but if attacking, they should not be able to fire beam weapons endlessly, especially when bombarding.
d) If it is intended for space bugs to be a mortal threat, or at least if they should attempt to wipe out players if not stopped, then the game should provide some sort of warning that these aren't just ship-killing, wreck-harvesting critters ... the Swarm wages wars of extermination!


2. The bugs or game design choices that trigger lengthy - and in some cases quasi-endless - runs of increments measured in seconds, when the player is not involved, need to be hunted down and put of players' misery.

a) Are all fire controls being properly cleared when a target is lost or no longer available?
b) Can AI-versus-AI fights be resolved using a simplified set of rules? "If on attack and not in range, but might be able to get into range, chase until in range. Otherwise, defend. If has missiles, and missiles can't be shot down well enough, subtract missiles and inflict damage. If has beam weapons, and can catch target, catch target and inflict damage. Otherwise, set to chase or defence, and counter-fire only. Repeat for all other sides. Repeat for each suitable sub-block of time. Stop when all but one side is destroyed or escapes, or all sides are on defense, or the player-specified block of time ends." That kind of thing.
c) If a) and b) are not sufficient, then at least allow the player to learn which fleets are killing game progression, so they they can be deleted. Make it easier to kill off fleets without triggering "not set to an object" error messages.


3. On the subject of those dratted error messages: The keystroke used to clear the message should not be the same keystroke used to request another turn increment. At present, both are ENTER on my keyboard. Extra credit if the error message could be presented without popping up a box, and/or if the game got better at deleting objects that trigger such messages. For example, if a ship can't find its fleet, maybe kill off the ship?


4. The game interface redraws windows and refreshes text extremely inefficiently. This is immediately noticeable on the message window. The Economics window also has a problem here, a problem worsened by its refreshing every turn increment (even if only 5s) instead of just doing one automatic refresh every construction cycle. In long games, the Leaders window and even the Ship Design window can also bog down.
Title: Re: C# Suggestions
Post by: Droll on June 12, 2021, 12:32:11 PM
In long games, the Leaders window and even the Ship Design window can also bog down.

So for the leaders window I actually know exactly what the problem is. The game has a filter system that lets you choose between officers of certain type, rank and skills. The problem is, the filtering is automatically done and not done manually at the players discretion.

Furthermore, when you open the commander window this search is done with the default settings which are set to "Naval Officer, R1 - Rmax" which means that every time you open the commander window the game is going to search through and sort potentially 1000s of naval officers and sort them in descending order of crew training even if the player has no reason to.

This problem is further exacerbated by the inefficient refreshing present in the commander screen like all the others because every time you do something in the commander window, the search gets repeated and you have to wait again.

The ideal solution is to have the player press a filter button, so that a search only happens when they tell it to. The easy work around for Steve (and to a lesser extent us) to do is to change the default settings for the search, specifically make the ranks a range such as R2-R1, which will return a list of 0 officers almost instantly. If you have multiple assignments on the commander window I recommend that players also do this, wont save you the initial loading time but you will at least be able to assign officers and not have to wait.
Title: Re: C# Suggestions
Post by: Blogaugis on June 13, 2021, 04:22:32 AM
Some suggestions and observed issues, based on a couple of 1.13 games:

1. The Swarm is too variable in the danger level it poses, and can be far too deadly. What deep-space bugs should not do is a) scout your home planet (>10B km away from any jump point or linked LP point) five years into a game, park 10s of thousands of tons-worth of warships in orbit a few months later, destroy all your shipyards, and start bombarding your helpless early-game homeworld to dust and ruin. Endlessly, because they never run out of supplies.

This is unfair, because:
a) The player, if they set up using ordinary early-TN tech levels (the ones the game offers as defaults), may well not be able to fend off such an attack so early on. "You lose. Regardless of any attempt you might have made at preparedness." is not what a game should tell players. This applies also to the Invaders.
b) Distance should matter to the AIs. If the AI can't be made to understand fuel limits, it should at least respect a travel distance limit.
c) Supplies should matter to the AIs, at least in some sense. They don't have to run out when attacked, but if attacking, they should not be able to fire beam weapons endlessly, especially when bombarding.
d) If it is intended for space bugs to be a mortal threat, or at least if they should attempt to wipe out players if not stopped, then the game should provide some sort of warning that these aren't just ship-killing, wreck-harvesting critters ... the Swarm wages wars of extermination!
Personally, I always disable Star Swarm because - I simply refuse to believe that the open cosmos can be habitable to any sort of living being.
Even with precursors and extra-galactic invaders I am reluctant to add them, due to the phrase - "...which do not behave in the same way as a normal non-player race (NPR)" - but for the latest play-through, I've decided to add them, for extra challenge and that they may have a reason to exist.

Since, at the start, and even as the game goes on, the player has the option to enable or disable the "Spoilers", that is more of a player's preference, whether he/she wants a greater challenge/have fun with a strategic nightmare story of monsters that can live and multiply in space and how a player defeats them, or sees himself/herself defeated by them. I choose to disable them, because it would ruin my suspension of disbelief.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 13, 2021, 11:53:14 AM
One can always enable a spoiler race after the game has started and the player race is situated.
Title: Re: C# Suggestions
Post by: Black on June 13, 2021, 12:07:16 PM
Would it be possible to get SM command to "reset" system bodies? Basically it would delete all bodies and spawn new ones.
Title: Re: C# Suggestions
Post by: xenoscepter on June 13, 2021, 02:14:21 PM
I can verify that small crafts still can't unload/load cargo on their own, at least not colonists which is what I tested, I did not try from a cargo hold.

Another issue that still exist is that Troop Transports can unload/load troops on any planet no matter their size without cargo shuttles a well, I'm pretty sure they are not suppose to be able to do that. At least it is a bit weird that they can.

 --- This is a bug, I myself reported it in v1.11, it was "fixed" in v1.12, then again in v1.13. http://aurora2.pentarch.org/index.php?topic=12035.0 <=== This post confirms that the function is intended. You should post it in the v1.13 Bugs Section. I haven't confirmed it yet, and probably won't be able to for a while due to my son being born yesterday.

 - Sent from Mobile.
Title: Re: C# Suggestions
Post by: Droll on June 13, 2021, 03:14:22 PM
due to my son being born yesterday.

Congratulations!
Title: Re: C# Suggestions
Post by: xenoscepter on June 13, 2021, 03:55:46 PM
due to my son being born yesterday.

 --- Cheers! Currently stuck in a hospital with little to do. Poor guy was a month and a week early... But he's getting better real quick.

 --- That's enough Off-Topic in C# Suggestions though. :)

Congratulations!
Title: Re: C# Suggestions
Post by: TMaekler on June 14, 2021, 05:06:34 AM
This raises an interesting point whether or not the policing requirements of a planetary population should increase as the planet becomes more full above a certain threshold. For example, when the space taken is at least 50% the policing requirements start to increase more than usual, with the increase being more extreme as the space used approaches 100%.

Found this in the "What is your biggest empire" - thread and thought, this is worthwhile to think about. We do have unrest due to overpopulation, though it makes sense that once you get close to the maximum (lets say 95%) that people get uneasy and begin rioting which leads to an increase in police needed... . And it would make sense that people will increase violence more if they are in enclosed spaces (i.e. installations) - so the need for a non-zero planet which needs installations should be higher than on a zero world... .
Title: Re: C# Suggestions
Post by: Blogaugis on June 14, 2021, 06:36:12 AM
This raises an interesting point whether or not the policing requirements of a planetary population should increase as the planet becomes more full above a certain threshold. For example, when the space taken is at least 50% the policing requirements start to increase more than usual, with the increase being more extreme as the space used approaches 100%.

Found this in the "What is your biggest empire" - thread and thought, this is worthwhile to think about. We do have unrest due to overpopulation, though it makes sense that once you get close to the maximum (lets say 95%) that people get uneasy and begin rioting which leads to an increase in police needed... . And it would make sense that people will increase violence more if they are in enclosed spaces (i.e. installations) - so the need for a non-zero planet which needs installations should be higher than on a zero world... .
I guess I'll repeat my thoughts on this too - if it is going to be implemented, leave a choice whether to use "advanced policing" or not.

And I have another note - there are civilians, who create their own mining colonies with ground units and their own unit templates, at least, if you didn't create your own. Problem is, as technology advances, civilians will still use the old technology that was designed quite long ago. Making these civilian ground units obsolete don't seem to solve the issue...
Are there going to be ways to make civilian spawned ground units upgrade-able some way? Or, at least, so when they create new civilian mining colonies with ground units, will there be a way to make them spawn with the new "racial" technologies, rather the the ones, which were created close to the game start (Duranium tech)?
Title: Re: C# Suggestions
Post by: Andrew on June 14, 2021, 07:12:55 AM
For the ship combat screen Filter targets to armed ships.
I am trying to kill a few escorts hiding among over a hundred unarmed merchant ships, it takes time and effort to find and target them it would be nice if I could restrict the list to just ships which are armed, even better if I could use auto-target limited to just those armed ships
Title: Re: C# Suggestions
Post by: serger on June 14, 2021, 08:24:48 AM
Are there going to be ways to make civilian spawned ground units upgrade-able some way?
Or, at least, so when they create new civilian mining colonies with ground units, will there be a way to make them spawn with the new "racial" technologies, rather the the ones, which were created close to the game start (Duranium tech)?
We can do it now (v1.13).
Set Show Civilian in Formation Templates on, edit Civilian Garrison template - and they will spawn with edited template.
(Yes, you can abuse it, but it's quite easier to abuse Aurora with SM if you want to cheat with yourself, so I like this feature: it's a government's competence to set what type of police force civilian companies must field to get their mandates.)
Title: Re: C# Suggestions
Post by: serger on June 14, 2021, 08:29:49 AM
For the ship combat screen Filter targets to armed ships.
It will be very possible to have target-rich environment with no info about enemy weapons at any of those targets, so with this filter you can get very counterintuitive result.
Title: Re: C# Suggestions
Post by: Black on June 14, 2021, 10:18:16 AM
For the ship combat screen Filter targets to armed ships.
It will be very possible to have target-rich environment with no info about enemy weapons at any of those targets, so with this filter you can get very counterintuitive result.

Yeah, filtering with engine type would be most likely be better in such situation, unless the player plays both sides and use warship with commercial engines.
Title: Re: C# Suggestions
Post by: Andrew on June 14, 2021, 12:07:28 PM
Your intelligence reports list all armed enemy ships that you know about, using that as the filter would be sensible. I have no expectation that I would shoot at unidentified armed vessels,
Title: Re: C# Suggestions
Post by: Nori on June 18, 2021, 04:50:47 PM
Not really sure how to best ask this as I'm not sure what goes on behind the scenes, but I recently lost a decent amount of gameplay as I apparently hadn't saved the game in a while. I've tried to be better about saving since then, but the biggest issue is once you get a game going it can take a rather large amount of time with the game locked up to saved. My games is 131 years in and it takes 94 seconds to save on a SSD. Not insurmountable of course, but it lends itself to saving less frequently.

Anyway, my suggestion is a look at the saving functionality and if there is a way to speed it up a bit.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 19, 2021, 10:51:18 AM
I'd like to suggest a small tweak (bolded below) to the Logistics components for ground forces.

Logistics are a significant demand on ground forces construction, as for any serious (planetary invasion) ground combat campaign logistics requirements are on the order of ~10% of the total force tonnage (see my post in the Mechanics subforum (http://aurora2.pentarch.org/index.php?topic=12587.0) for details on how this can be estimated). As the cost of building so many logistics elements is significant a savvy player will seek to limit this cost as much as possible without compromising tactical or operational (i.e. mouse-clicking) capability.

Presently, the logistics situation is such that we have three options available to us: INF+LOGS (10 tons, 100 GSP, 0.2 BP), INF+LOG (50 tons, 500 GSP, 1.0 BP), and LVH+LOG (62 tons, 500 GSP, 2.48 BP). The distinction between INF and LVH logistics is that the INF logistics can only resupply the formation they are elements of, while the LVH logistics can resupply any formation in their subordinate hierarchy. However, with the 1.12+ changes adding replacement functionality this benefit of LVH is no longer as important, as long as a formation has enough INF logistics to stay supplied for a construction cycle the replacements system will work just as well as LVH for a fraction of the BP cost per GSP. In the past, the ~2.5x BP cost for LVH logistics was a necessary evil as manually replacing logistics elements in large armies was untenable, but now it is unnecessarily expensive since we have a cheaper option that still reduces micromanagement to tolerable levels.

Additionally, the large logistics modules are largely inferior for INF logistics. The smaller modules are cheaper to research, more resilient to enemy fire due to being more numerous, and a bit more flexible if you want to fill out tonnage to boot. The large LOG module for infantry could probably be omitted with no real change in the game.

Thus my suggestion is as follows: Double the GSP value of the large LOG component (but keep the size the same at 50 tons) and make it LVH-only.

In this case we have two options: INF+LOGS (10 tons, 100 GSP, 0.2 BP) and LVH+LOG (62 tons, 1000 GSP, 2.48 BP) which are in roughly equal balance with each other.

This as discussed makes no real difference for infantry, but would make LVH-based logistics more feasible. There is still a +25% premium in BP cost per GSP due to the LVH mount + light vehicle armor, however for that +25% premium the player retains for example the option of not including infantry logistics in front-line formations. At the current +150% premium that option is really not feasible when ~10% of the total force tonnage is needed in logistics units. My suggested change presents an interesting strategic choice to the player which is between more effective frontline formations at greater logistical expense versus frontline formations with greater non-combatant tonnage for the benefit of cheaper overall logistics and slightly lower transport requirements for LOG elements.

EDIT: As pointed out below the transport requirements under this proposal are less for LVH logistics (60% more tonnage-efficient). Admittedly I am not sure if this is a significant balance issue or not. If so, the size of the LOG component can be tweaked until Steve feels the balance of strategic factors is reasonable.
Title: Re: C# Suggestions
Post by: ISN on June 19, 2021, 12:08:44 PM
...My suggested change presents an interesting strategic choice to the player which is between more effective frontline formations at greater logistical expense versus frontline formations with greater non-combatant tonnage for the benefit of cheaper overall logistics and slightly lower transport requirements for LOG elements.

Are you saying here that infantry-based logistics would be more efficient with respect to transportation, or am I misreading this? Because that seems backwards: under your proposed change LVH-based logistics provides ~16 GSP/ton while infantry-based logistics only provides 10 GSP/ton.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 19, 2021, 12:50:11 PM
...My suggested change presents an interesting strategic choice to the player which is between more effective frontline formations at greater logistical expense versus frontline formations with greater non-combatant tonnage for the benefit of cheaper overall logistics and slightly lower transport requirements for LOG elements.

Are you saying here that infantry-based logistics would be more efficient with respect to transportation, or am I misreading this? Because that seems backwards: under your proposed change LVH-based logistics provides ~16 GSP/ton while infantry-based logistics only provides 10 GSP/ton.

You're right, I'll fix it.
Title: Re: C# Suggestions
Post by: ISN on June 19, 2021, 01:48:09 PM
It would be nice if the minimum distance option were available for the Launch Ready Ordnance order. It's a pretty minor thing, but I don't see any obvious reason why it shouldn't be available, and it would've come in handy when I had to set up a large field of sensor buoys recently. Instead I had to set up waypoints wherever I wanted to place a buoy (unless there's a better way I'm not seeing?).
Title: Re: C# Suggestions
Post by: Nori on June 22, 2021, 03:49:38 PM
The last few games I've been playing I do so without jump engines. I just build stabilization ships and only go places that have gates. It slows down exploration, but frees up a lot of space on ships (or frees up a ship type) and it frees up my PP scientists from having to research Jumpy stuff.

Given all that, I was thinking that it would be interesting if gates could be destroyed. Forcing your opponent to use jump engines could be viable. Not sure how the NPRs would decide when a gate should be removed or not and it could be annoying if they snuck into a transit system and destroyed a gate...
Title: Re: C# Suggestions
Post by: Droll on June 22, 2021, 05:27:22 PM
The last few games I've been playing I do so without jump engines. I just build stabilization ships and only go places that have gates. It slows down exploration, but frees up a lot of space on ships (or frees up a ship type) and it frees up my PP scientists from having to research Jumpy stuff.

Given all that, I was thinking that it would be interesting if gates could be destroyed. Forcing your opponent to use jump engines could be viable. Not sure how the NPRs would decide when a gate should be removed or not and it could be annoying if they snuck into a transit system and destroyed a gate...

I wonder how you handle JP assaults without squadron jump, although you could just use a single/couple specialized jump ships for that.
Title: Re: C# Suggestions
Post by: Nori on June 22, 2021, 07:18:04 PM
The last few games I've been playing I do so without jump engines. I just build stabilization ships and only go places that have gates. It slows down exploration, but frees up a lot of space on ships (or frees up a ship type) and it frees up my PP scientists from having to research Jumpy stuff.

Given all that, I was thinking that it would be interesting if gates could be destroyed. Forcing your opponent to use jump engines could be viable. Not sure how the NPRs would decide when a gate should be removed or not and it could be annoying if they snuck into a transit system and destroyed a gate...

I wonder how you handle JP assaults without squadron jump, although you could just use a single/couple specialized jump ships for that.
I haven't really run into any issues. I just do a standard transit for the entire fleet and that's worked just fine thus far.
Title: Re: C# Suggestions
Post by: TMaekler on June 23, 2021, 03:54:10 AM
Some kind of factor for fuel efficiency would be nice to simulate different styles of rocket warfare. This factor would basically increase the fuel demand per engine power unit so the travel distance of ships and rockets would be decreased. Rockets in the Battlestar Universe for example have a way shorter range - and such a thing could be simulated with a global game factor similar to research and all the other factors we now have... .
Title: Re: C# Suggestions
Post by: skoormit on June 23, 2021, 07:44:55 AM
On the Commanders window, could we have a toggle for showing only unassigned commanders (in the filtered list, bottom right; not the full list in the left pane)?
Title: Re: C# Suggestions
Post by: Stormtrooper on June 23, 2021, 04:32:32 PM
Currently if there are two ground formations on the same hierarchy level next to each other and both have hq units inside, if you set up one of the formations to support and try to support the other, you won't be able to do it unless the hq inside formation you try to support is the same size or smaller than the hq inside formation you want to provide support with. If the "supported" formation has higher hq size instead, then your drag will end up in making the other formation subordinate of the supposedly supported one instead of setting support correctly.

I'd be grateful for a toggle as to what drag does (ideally a different way than dragging, but at the very least that), so I can consciously decide whether I want to provide support or attach as a subordinate.
Title: Re: C# Suggestions
Post by: xenoscepter on June 23, 2021, 04:46:23 PM
Currently if there are two ground formations on the same hierarchy level next to each other and both have hq units inside, if you set up one of the formations to support and try to support the other, you won't be able to do it unless the hq inside formation you try to support is the same size or smaller than the hq inside formation you want to provide support with. If the "supported" formation has higher hq size instead, then your drag will end up in making the other formation subordinate of the supposedly supported one instead of setting support correctly.

I'd be grateful for a toggle as to what drag does (ideally a different way than dragging, but at the very least that), so I can consciously decide whether I want to provide support or attach as a subordinate.

 --- I would honestly kill just to have a button that lets me assign support regardless of HQ sizes. I often have smaller, vehicular attack formations that I want to support with larger bombardment formations, but it doesn't work unless I heavily overbuild the HQ. For reference I have large defensive formations to defend them.

 --- Likewise the option to assign a subordinate formation to direct support it's parent formation would be much appreciated. I often find myself just wanting to put another 1,000 tons or so in my formation's HQ to assign a support bombardment unit, so that they get the extra boni from it.
Title: Re: C# Suggestions
Post by: Blogaugis on June 25, 2021, 05:42:58 AM
I find terraforming strategies to be a bit one-sided:

Terraforming facility is generally considered a worse alternative to the terraforming module mounted on a ship (or a station).
The advantages of terraforming on a ship:
You can get bonus from ship commander,
You don't require population to function.
While the only obvious advantage I can see is:
Facility can be built with a construction factory. Thus, saving you a shipyard.

I suggest to improve ground-based facility to either:
Not require population to function, OR
Work better than a single terraforming module on a ship (like, 5 times more powerful).
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 25, 2021, 08:52:28 AM
I find terraforming strategies to be a bit one-sided:

Terraforming facility is generally considered a worse alternative to the terraforming module mounted on a ship (or a station).
The advantages of terraforming on a ship:
You can get bonus from ship commander,
You don't require population to function.
While the only obvious advantage I can see is:
Facility can be built with a construction factory. Thus, saving you a shipyard.

I suggest to improve ground-based facility to either:
Not require population to function, OR
Work better than a single terraforming module on a ship (like, 5 times more powerful).

Compounding the problem is the cost, a terraforming installation costs 600 BP in a factory while the terraforming module costs somewhat less, I want to say 480? BP but don't have Aurora in front of me right now.

This is analogous to orbital mining modules vs automines, however in this case OMMs have an obvious limitation in that they can only mine from very small bodies. Thus the balance between OMMs, automines (2x cost, work everywhere) and manned mines (require population) is reasonable and all options have their use. Terraforming modules have no such limitations aside from the initial research investment into the modules themselves as well as tractor beams for the tugs (although you can put engines on a terraforming ship this forces you to use a shipyard to build it).

That being said I am not sure what a good solution would be. Currently shipborne terraforming modules feel like they are in a good place, so I think it is preferable to buff the ground-based installations instead of nerfing the orbital modules. However any buff to the ground installations is difficult to make as we do not want to make early-game terraforming too easy. If nothing else I think bringing the cost of the ground facilities down to be the same as that of the orbital modules is reasonable, as this allows a strategy of using terraformers to employ the first wave of colonists at a new colony to be competitive with the orbital stations economically.
Title: Re: C# Suggestions
Post by: Blogaugis on June 25, 2021, 09:08:48 AM
Compounding the problem is the cost, a terraforming installation costs 600 BP in a factory while the terraforming module costs somewhat less, I want to say 480? BP but don't have Aurora in front of me right now.

This is analogous to orbital mining modules vs automines, however in this case OMMs have an obvious limitation in that they can only mine from very small bodies. Thus the balance between OMMs, automines (2x cost, work everywhere) and manned mines (require population) is reasonable and all options have their use. Terraforming modules have no such limitations aside from the initial research investment into the modules themselves as well as tractor beams for the tugs (although you can put engines on a terraforming ship this forces you to use a shipyard to build it).

That being said I am not sure what a good solution would be. Currently shipborne terraforming modules feel like they are in a good place, so I think it is preferable to buff the ground-based installations instead of nerfing the orbital modules. However any buff to the ground installations is difficult to make as we do not want to make early-game terraforming too easy. If nothing else I think bringing the cost of the ground facilities down to be the same as that of the orbital modules is reasonable, as this allows a strategy of using terraformers to employ the first wave of colonists at a new colony to be competitive with the orbital stations economically.
Terraforming module:
Cost 500   Size 25,000 tons   Crew 100   HTK 10
Base Chance to hit 100%
Materials Required: Duranium  250    Boronide  250

Terraforming installation:
Wealth: 600
Duranium: 300
Boronide: 300
+ population to function... Do they pay taxes, at least?


I say, that:
Currently, the shipborne terraforming modules feel like in a good place they are too good!!!, to the point of making terraforming installations too much of a hassle.
I mean, sure, you can use a freighter that is sooo big, to transport other installations as well, making it a versatile solution (so that you'd need these freighters whether you use terraforming installations or not).
But, still... You'd need infrastructure to transport with it! And even then it sometimes is not enough (some colony costs are so huge, that terraforming installation simply cannot work, no matter how much infrastructure you toss at it - Venus, for example). This population requirement can be bypassed with an orbital habitat... But it will still require a tug, or a separate dockyard to build.
So...
Does anybody even use terraforming installation?
Because I'd rather use a module than an installation. Pretty much, every time.
I guess I can see 1 place where you want taxes even before the planet is terraformed, but... Do they pay taxes?
Title: Re: C# Suggestions
Post by: Garfunkel on June 25, 2021, 09:21:55 AM
Different tools for different situations, my friend.

I use TF facilities for Mars and other CC2 planets, as the need for infra is small. TF stations, meanwhile, are used on CC4+ planets. Because they are built by different facilities (CF vs SY), it can be beneficial to utilize both. But especially in early game, when SY space is at premium, it's worth it to have TF facilities even if you eventually phase them out and only use TF stations/ships.
Title: Re: C# Suggestions
Post by: ISN on June 25, 2021, 09:25:16 AM
Here's a random thought: what if ground-based terraformers could add water directly to the hydrosphere, rather than going by way of atmospheric water vapor? The idea being that, since they're on the ground, they can just dump out liquid water or whatever rather than injecting water vapor into the atmosphere. (Not sure where all that water is coming from, but that's a separate issue.) I find that waiting for water vapor to condense out of the atmosphere can in certain cases (depending on planet size, temperature, etc.) add somewhat to the time it takes to terraform a planet, so letting ground-based terraformers shortcut that could make for an interesting tradeoff between them and orbital terraformers -- although orbital terraformers would probably still be better in most cases without further rebalancing, since water condensation typically doesn't take that much longer. The biggest issue I see with this is that it would require reworking the terraforming user interface, since currently it only allows for adding atmospheric gasses. But there have been various discussions about improving the terraforming UI anyway, so maybe that's not the worst thing.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 25, 2021, 09:29:28 AM
Currently, the shipborne terraforming modules feel like in a good place they are too good!!!, to the point of making terraforming installations too much of a hassle.

To clarify my point: I feel like orbital terraforming modules, by themselves, feel like a good balance. The rate at which they can be built, deployed, and terraform a planet feels reasonable at least in the early to mid game...many players claim terraforming is too fast in the late game but that's a different discussion.

The planetary installations feel decidedly weak by comparison because their cost is greater and their use is more restrictive, but I do not think the answer is to nerf the orbital modules, rather the ground-based facilities need some improvements. Bringing their cost into line with the orbital modules is at least a good first step, or maybe a bit less. Even equal cost at 500 BP I think is fine, but since orbital modules are so much more flexible a slight discount at, say, 480 BP might make more sense.

Quote
I mean, sure, you can use a freighter that is sooo big, to transport other installations as well, making it a versatile solution (so that you'd need these freighters whether you use terraforming installations or not).
But, still... You'd need infrastructure to transport with it! And even then it sometimes is not enough (some colony costs are so huge, that terraforming installation simply cannot work, no matter how much infrastructure you toss at it - Venus, for example). This population requirement can be bypassed with an orbital habitat... But it will still require a tug, or a separate dockyard to build.

I can't speak for other players, but I will usually use infrastructure to establish new colonies particularly in frontier systems and place a population of ~10m at a CC2.0 world in a system I want to eventually expand and terraform in. In this case it can make some sense to ship out the ground-based terraforming facilities to give that population something to do, so the population requirement is not always a hindrance especially if the planet itself has relatively poor mining prospects.

Quote
So...
Does anybody even use terraforming installation?
Because I'd rather use a module than an installation. Pretty much, every time.

If I'm playing with a low-pop start and don't have the RPs to research terraforming modules with instant research I'll usually build some installations to get started on terraforming Luna/Mars since I'll colonize those bodies without having any real jobs for the populations to be doing. Once orbital modules and tractor beams are available though there is not much point, though I will still use the facilities I already built as they don't cost any more to operate...

Quote
I guess I can see 1 place where you want taxes even before the planet is terraformed, but... Do they pay taxes?

Yes. All employed workers pay taxes, and terraforming installations are no exception.

Different tools for different situations, my friend.

I use TF facilities for Mars and other CC2 planets, as the need for infra is small. TF stations, meanwhile, are used on CC4+ planets. Because they are built by different facilities (CF vs SY), it can be beneficial to utilize both. But especially in early game, when SY space is at premium, it's worth it to have TF facilities even if you eventually phase them out and only use TF stations/ships.

I think the issue is that after the early game, once you have terraforming modules (5000 RP) and tractor beams (5000 RP), plus a few tugs built...there is no economical reason to build the ground-based facilities. The orbital modules are cheaper (500 BP vs 600 BP for the ground-based facilities) and logistically not any more complicated (freighters vs tugs is a wash even neglecting the need for colonists to be shipped around as I assume this will happen anyways).

It's reasonable to say that the installations are intended to be the early-game option and the orbital modules for the rest of the game but personally I dislike having a mechanic or feature in the game which is completely useless after a certain point in time.

That said I think only a small adjustment to the build cost is needed, just enough to make ground facilities competitive instead of clearly overpriced and uneconomical.
Title: Re: C# Suggestions
Post by: Blogaugis on June 25, 2021, 10:17:53 AM
Different tools for different situations, my friend.

I use TF facilities for Mars and other CC2 planets, as the need for infra is small. TF stations, meanwhile, are used on CC4+ planets. Because they are built by different facilities (CF vs SY), it can be beneficial to utilize both. But especially in early game, when SY space is at premium, it's worth it to have TF facilities even if you eventually phase them out and only use TF stations/ships.
But you still phase them out... Meaning, they are viable only fairly early, or with specific limitations and role-play reasons...

To clarify my point: I feel like orbital terraforming modules, by themselves, feel like a good balance. The rate at which they can be built, deployed, and terraform a planet feels reasonable at least in the early to mid game...many players claim terraforming is too fast in the late game but that's a different discussion.

The planetary installations feel decidedly weak by comparison because their cost is greater and their use is more restrictive, but I do not think the answer is to nerf the orbital modules, rather the ground-based facilities need some improvements. Bringing their cost into line with the orbital modules is at least a good first step, or maybe a bit less. Even equal cost at 500 BP I think is fine, but since orbital modules are so much more flexible a slight discount at, say, 480 BP might make more sense.
Yeah, and that's what I also suggested, albeit even further:
Remove population requirement for terraforming installations (so that you can also use them on Venus), Or make them more effective than a ship module, like, 2 times more effective at the very least.
Quote
I can't speak for other players, but I will usually use infrastructure to establish new colonies particularly in frontier systems and place a population of ~10m at a CC2.0 world in a system I want to eventually expand and terraform in. In this case it can make some sense to ship out the ground-based terraforming facilities to give that population something to do, so the population requirement is not always a hindrance especially if the planet itself has relatively poor mining prospects.
Considering that in my game Luna and all those worlds near Jupiter (and Titan near Saturn) have no minerals, I suppose a facility may not be entirely without merit...
Quote
If I'm playing with a low-pop start and don't have the RPs to research terraforming modules with instant research I'll usually build some installations to get started on terraforming Luna/Mars since I'll colonize those bodies without having any real jobs for the populations to be doing. Once orbital modules and tractor beams are available though there is not much point, though I will still use the facilities I already built as they don't cost any more to operate...
I chose to not have any instant research points in my game, and yet still waited for a module... A terraforming station with 10 modules seems like a fairly quick solution.
Quote
Yes. All employed workers pay taxes, and terraforming installations are no exception.
Which means that an installation has 1 more advantage over a module...
So, a wealth sensitive civilization may choose to go with installation.
Though, I don't think it is enough.
Quote
I think the issue is that after the early game, once you have terraforming modules (5000 RP) and tractor beams (5000 RP), plus a few tugs built...there is no economical reason to build the ground-based facilities. The orbital modules are cheaper (500 BP vs 600 BP for the ground-based facilities) and logistically not any more complicated (freighters vs tugs is a wash even neglecting the need for colonists to be shipped around as I assume this will happen anyways).

It's reasonable to say that the installations are intended to be the early-game option and the orbital modules for the rest of the game but personally I dislike having a mechanic or feature in the game which is completely useless after a certain point in time.

That said I think only a small adjustment to the build cost is needed, just enough to make ground facilities competitive instead of clearly overpriced and uneconomical.
Well, at least we agree on the same problem, though we offer different solutions...
But, yes, I agree that the cost should be the same, if not less (at least, if the workers still remain on it, can they at least do things, that reduce the facility's cost..?)
Though, if we remove the workers, we also remove the advantage it has over a module...
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 25, 2021, 10:56:37 AM
Well, at least we agree on the same problem, though we offer different solutions...
But, yes, I agree that the cost should be the same, if not less (at least, if the workers still remain on it, can they at least do things, that reduce the facility's cost..?)
Though, if we remove the workers, we also remove the advantage it has over a module...

I think we are taking different approaches to a solution.

Your proposals, though I may be misunderstanding, strike me as trying to make the ground facilities and orbital modules basically equal in all situations. For example removing the population requirements (and setting the BP costs equal) means that the only real difference between the two types is whether you use freighters or tugs to move them into place.

Whereas what I prefer is a setup where both types have different uses so one or the other is preferable, for example the orbital modules are more flexible but also slightly costlier, while the ground facilities are a bit cheaper (I suggested 480 BP but you could go even lower if necessary) but require population so they are better for some situations but not all. This leads to a strategy where you want to build mostly the orbital modules but also some ground facilities for the cases where they are a stronger option - which leads to a necessity to assess how many of each you should expect to need and try to build up accordingly.
Title: Re: C# Suggestions
Post by: Blogaugis on June 25, 2021, 11:21:01 AM
I think we are taking different approaches to a solution.

Your proposals, though I may be misunderstanding, strike me as trying to make the ground facilities and orbital modules basically equal in all situations. For example removing the population requirements (and setting the BP costs equal) means that the only real difference between the two types is whether you use freighters or tugs to move them into place.

Whereas what I prefer is a setup where both types have different uses so one or the other is preferable, for example the orbital modules are more flexible but also slightly costlier, while the ground facilities are a bit cheaper (I suggested 480 BP but you could go even lower if necessary) but require population so they are better for some situations but not all. This leads to a strategy where you want to build mostly the orbital modules but also some ground facilities for the cases where they are a stronger option - which leads to a necessity to assess how many of each you should expect to need and try to build up accordingly.
Yeah...
At least, the key problem - installations have very little point to be used currently. You will use modules after you research tractor beam and terraforming module.

We want to give installations something that makes them useful even in late game, like, making them work better than modules, or be the same as modules without requiring population - at least, make them even. Rather than a tug, you can use a cargo ship to terraform a planet.

We also need to solve a bit of a problem with some high colony cost planets - can you terraform Venus with only terraform facilities and infrastructure? Answer is no. If you use orbital habitats - yes.
If terraforming facilities did not require population - the answer becomes yes. This will solve a problem.

But, okay, perhaps we can leave that 'require population'...
What other advantages the installation could have over a module?
I suggest making it more powerful than a module, like, 2 times more powerful, or maybe 50% more powerful.
That way, even if it cannot be used to terraform Venus-like planets (without orbital habitats), it can still be useful even in late game, as it is more efficient than a module (unless you have a very skilled navy commander with insane terraform buffs...).
Title: Re: C# Suggestions
Post by: skoormit on June 25, 2021, 11:46:01 AM
I find terraforming strategies to be a bit one-sided:
...
I suggest to improve ground-based facility to either:
Not require population to function, OR
Work better than a single terraforming module on a ship (like, 5 times more powerful).

The differences between a TFI and a module are:

TFI requires 250k workers.
TFI costs 20% more (600 vs 500).
TFI requires 5 times the tonnage to transport (125kt of cargo holds vs 25kt of module size).
TFI gets planetary/sector governor bonuses, module gets ship commander and NAC bonuses.
TFI must be built by factories. Modules can be built in factories or in shipyard.
TFI generates tax income.

As it stands, I never build TFI.
The only relative advantage is the tax income, but the long-run economic bottleneck is always population, and I would get the same tax income by using those workers in other installations.

If you remove the population requirement from TFIs, then I might actually use them.
To be worthwhile, I'd have to have a governor with a significant TF bonus, a large and long-term TF project, freighter capacity surplus to anticipated requirements for quite a while (perhaps after having completed a large migration effort), and enough fuel production that I don't mind spending five times the fuel to transport them (compared to moving the equivalent modules instead).

Honestly, I think the answer is to make the installation/module dynamic equivalent to that for mines/automines.

Make TFIs cost 250 (half the cost of a module), require 50k workers, and require 25kt cargo space.
That way modules offer the same economic tradeoff for installations that automines offer for mines (twice the cost in exchange for not needing workers), instead of being a much, much better deal like they are now.
Title: Re: C# Suggestions
Post by: Blogaugis on June 25, 2021, 12:31:47 PM
New suggestion - in ground forces order of battle screen, change the color (to red or orange) if the formation attached to a hierarchy cannot receive officers bonuses (like, lacks HQ).
Title: Re: C# Suggestions
Post by: Garfunkel on June 25, 2021, 01:24:08 PM
Correct me if I'm misunderstanding you but it seems that you're trying to bring BALANCE to Aurora and that's not going to work :P

But you still phase them out
No, you skipped over the rest of my post. I wrote that even in the case that they are phased out, they were useful in early game. But they always remain useful and there is no need to phase them out. If your surveyors find a steady stream of planets to terraform, there will never be a situation where you want less terraforming ability.

Even if that's not the case and there's a mathematical most efficient way, it doesn't really matter. Because Aurora is all about options and possibilities - if TF facilities are only useful in early game and then might not be used by few/some/many players after that, doesn't mean that they are wasted. It's 100% fine if something isn't viable/efficient throughout the game - we already have this with weapons. There is no need to make any changes here.

The only relative advantage is the tax income, but the long-run economic bottleneck is always population
Only if you do 500M pop default starts. If you do a 7B pop United Earth start, you won't be bottlenecked by population.

If you remove the population requirement from TFIs, then I might actually use them.
But then how am I telling a story of maintaining a frontier colony that's desperately trying to terraform their planet?

To be worthwhile
I disagree because all you're proposing here is to increase the mathematical formula for achieving maximum effectiveness vs investment while removing options. I don't want Aurora to become yet another 4X game where there's only one true way to play. We already have Paradox and Matrix for that.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 25, 2021, 02:14:57 PM
Correct me if I'm misunderstanding you but it seems that you're trying to bring BALANCE to Aurora and that's not going to work :P

Truer words are rarely spoken.  :P

In my view there are two kinds of balance. One is I think what most people think of which is to make every option for everything equally viable in a futile quest to eliminate any and all One True Answer scenarios, which is not only an impossible pursuit but tends to make games feel very overbalanced and bland.

The other, better kind of balance is one which tries to create a useful role for all elements of the gameplay even if some of those roles are relatively niche. This is a much more achievable goal in practice because it really only requires Steve to make everything usable, not powerful. However this does still require some work in some cases, but on the whole I think this is the kind of balance Aurora strives for much to the chagrin perhaps of many players.  :)

In the case of terraformers, I think the core issue is that right now ground-based 'formers are only usable in the technical sense - you can build them and they function - and once 10k RP has been invested into the 'former module and tractor beam techs, ground facilities are inferior in every way except for generating tax money. Primarily this is because they cost 600 BP while orbital 'formers only cost 500 BP a pop, plus a bit more for structural materials and crew quarters.

It is I think important to separate this point from the others. Yes, ground 'formers have a lot of limitations such as requiring population to operate or more shipping capacity to move around. These things are perfectly fine. However, the fact that they are significantly more expensive to construct is a serious problem - while "there will never be a situation where you want less terraforming ability", I will virtually always prefer to spend 500 BP than 600 BP to get the same effective terraforming ability.

Quote
Even if that's not the case and there's a mathematical most efficient way, it doesn't really matter. Because Aurora is all about options and possibilities - if TF facilities are only useful in early game and then might not be used by few/some/many players after that, doesn't mean that they are wasted. It's 100% fine if something isn't viable/efficient throughout the game - we already have this with weapons. There is no need to make any changes here.

I think there is a little bit of a difference between "mathematically most efficient way" and "one way is almost strictly worse than the other AND more expensive by 20% to boot".

I think comparing to ship weapons actually supports the point here. For example, plasma carronades are, let's be honest, generally a third-tier weapon system at best in terms of performance, however they are very cheap to research (partially due to changes made in C# to bring balance!) and still have niche uses such as JP defense and ground unit attack boosting. Early in the game plasma can be a very strong weapon, but later on while it does drop off it retains some good uses. Now if plasma carronades cost more than, say, particle lances(!) we would have a serious balance problem, building plasma ships would be not merely suboptimal but in fact a cripplingly bad decision. Similarly, 10cm railguns are excellent point defense in the early game, while Gauss eventually pulls up even after ~20k+ RPs and only becomes clearly superior for PD after another ~50k RPs. However the railguns remain quite useful even if they are not as good as pure PD due to cheapness of BP and RP as well as being better for volume of anti-ship fire in a close brawl, plus they are better for beam PD fighters due to relatively small size. Basically my point is that while different weapons are more or less powerful in different game eras they all remain viable even in niche roles, no weapon is completely eclipsed by another in nearly every way.

Point being, while it is fine for something to be viable early and then drop off I think it is preferable for that something to be at least worth using in some sense throughout the game if possible, and I support the need to make a change where this can be accomplished without undue work... changing the ground terraforming facilities from even 600 BP to 500 BP I think falls under this category. Orbital modules will still be generally superior but ground facilities can still present a case to be built even after those 10k RP have been spent and a tug fleet constructed.

E: To be clear, I do think all this talk about halving the cost, quintupling the efficiency, or removing the population requirement is several bridges too far. I just don't think a simple adjustment to bring the costs into line between the two options is a bad idea, in fact I think it is a good one.
Title: Re: C# Suggestions
Post by: skoormit on June 25, 2021, 02:22:51 PM
To be worthwhile
I disagree because all you're proposing here is to increase the mathematical formula for achieving maximum effectiveness vs investment while removing options. I don't want Aurora to become yet another 4X game where there's only one true way to play. We already have Paradox and Matrix for that.

You skipped the rest of my post?
What I am proposing is to alter the cost of one of the two options so that the choice between the two is interesting in and of itself (so that you don't need "roleplay" to justify using one of them).
Title: Re: C# Suggestions
Post by: Blogaugis on June 25, 2021, 03:38:13 PM
Correct me if I'm misunderstanding you but it seems that you're trying to bring BALANCE to Aurora and that's not going to work :P
Probably, it is what the suggestions forum is for, is it not?
Quote
No, you skipped over the rest of my post. I wrote that even in the case that they are phased out, they were useful in early game. But they always remain useful and there is no need to phase them out. If your surveyors find a steady stream of planets to terraform, there will never be a situation where you want less terraforming ability.
But You still phase them out...
Yeah, but I wasted 50Xamount of installations constructed Duranium and 50Xamount of installations Boronide! I gave extra jobs for folks, I guess...
But here's the thing - people and wealth are renewable. Trans-newtonian elements are not.
Quote
Even if that's not the case and there's a mathematical most efficient way, it doesn't really matter. Because Aurora is all about options and possibilities - if TF facilities are only useful in early game and then might not be used by few/some/many players after that, doesn't mean that they are wasted. It's 100% fine if something isn't viable/efficient throughout the game - we already have this with weapons. There is no need to make any changes here.
I'd like options that have each their own strengths and perhaps niches, not 2 options, one of which is superior in every aspect and other is... Just there.
Seriously, how am I supposed to believe that a module, requiring just a 100 people to function, is somewhat on even terms with an installation requiring more resources and 2500 times more people to function?
The only relative advantage is the tax income, but the long-run economic bottleneck is always population
Quote
Only if you do 500M pop default starts. If you do a 7B pop United Earth start, you won't be bottlenecked by population.
I go with 10B start and still prefer modules.
If you remove the population requirement from TFIs, then I might actually use them.
Quote
But then how am I telling a story of maintaining a frontier colony that's desperately trying to terraform their planet?
Is the population requirement necessary for Your story?
To be worthwhile
Quote
I disagree because all you're proposing here is to increase the mathematical formula for achieving maximum effectiveness vs investment while removing options. I don't want Aurora to become yet another 4X game where there's only one true way to play. We already have Paradox and Matrix for that.
What? No, I want actual 2 ways to terraform things, that each have their +'es and -'es. Right now, we have 2 ways to play, with 1 being superior in almost every aspect.
Title: Re: C# Suggestions
Post by: RougeNPS on June 25, 2021, 04:05:56 PM
What would be the viability of adding a module for interdicting jumps?

To explain further: Attaching this module to a ship would temporarily, within the radius of the activated module on the ship prevent/interdict enemy vessels from using jumppoints.

Unless this already exists and i am blind.
Title: Re: C# Suggestions
Post by: xenoscepter on June 25, 2021, 05:38:00 PM
 --- So, regarding the ongoing discussion of Terraforming Installations, I think it's important to note that the Ship-Board Modules are basically superior in any situation that isn't terribly contrived. I'll mention Maintenance Modules here to point out that they are NOT superior to the Maintenance Facilities on account of the latter being able to actually produce MSP, while the former cannot. One other thing which might help, on top of the doubled rate, is allowing Planetary Terraformers and Ship-Based Terraformers to work separately, that is on different gases. Flavor wise the arbitrary two things only limit could be fluffed as being imposed by the gravity of the world itself. The C# version's mechanics already indirectly support his theory, since smaller worlds are terraformed faster than larger worlds. Regardless of surface area / gravity being the caused, both are tied together (loosely) and by extension this could help prop up the in-universe justification.

 --- As for making Terraforming Installations not suck, which they totally do and if you disagree with that opinion I would love to hear why... seriously, I love the niche / "bad" stuff and even I avoid these like the plague. Moreso, actually... I sometimes go grocery shopping despite the plague. :P At any rate, I feel that simply doubling the output of a Terraforming Installation would effectively solve the issue.

 --- My reasoning is as such; currently there is no reason mechanically speaking, role-play excluded, to use the Terraforming Installations over the Terraforming Modules. As it was in VB6, the installation is beat out by tugs with Terraforming Stations (which is further buffed in C# by way of Structural Shell) and also beat out by actual proper Terraforming Ships. They have no upside over these two options with the sole exceptions of wealth generation and governor stacking.

 --- Thusly, doubling the output of a Terraforming Installation changes them from being a pure detriment mechanically, or in other words "shooting off your own foot" (though that's an exaggeration, admittedly) into an expensive way to maximize your terraforming effort. If you want the absolute highest output, you'll need to build these and potentially spend the resources to ship them around. They're still the only way to stack governor boni, and likewise they also produce wealth, ergo doubling their output would give you a reason to build these and the freighters to move them, over a ship / station containing 5 terraforming modules.

 --- I compared one Installation to 5 modules on the grounds that one module is 1/5th the mass. However, one Large Cargo Bay requires much less crew than five Terraforming Modules. Likewise, ships don't gain any benefit from the planetary governor and ergo cannot stack boni with their own commanders. By extension, while 5x Modules over a single Installation is still 250% as effective, the freighter used to move said installation is big enough to move plenty of other things and by extension has greater utility than a dedicated ship. The tug / station flavor would still not have this benefit over the freighter, brining the Terraforming Installation from useless to a niche / luxury option to maximize Terraforming Speed.
Title: Re: C# Suggestions
Post by: Kiero on June 26, 2021, 08:25:52 AM
I would like to see more ways to get a weapon lock, including a passive lock.

So it would be possible to create a missile that will lock to the strongest thermal signature or EM emission.
Title: Re: C# Suggestions
Post by: Droll on June 26, 2021, 11:42:27 AM
I would like to see more ways to get a weapon lock, including a passive lock.

So it would be possible to create a missile that will lock to the strongest thermal signature or EM emission.

This is a great idea in general, passive locks could be such that you can use passives to stealthily fire weapons at the cost of targeting freedom. You'll always lock the strongest EM/TM signature and cannot choose to lock smaller ones at the same location as a larger signature. That way you can choose which enemy fleet to target but not specific ships.

Also great for self-guided missiles, you could make missiles that'll prioritize targeting the big EM signature of actives so that you can eliminate the big scouts.
Title: Re: C# Suggestions
Post by: QuakeIV on June 26, 2021, 12:42:32 PM
I don't really like that mechanic, it sounds contrived and weird.
Title: Re: C# Suggestions
Post by: Droll on June 26, 2021, 01:40:00 PM
I don't really like that mechanic, it sounds contrived and weird.

I cri  :'(
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 26, 2021, 01:48:42 PM
I would like to see more ways to get a weapon lock, including a passive lock.

So it would be possible to create a missile that will lock to the strongest thermal signature or EM emission.

This is a great idea in general, passive locks could be such that you can use passives to stealthily fire weapons at the cost of targeting freedom. You'll always lock the strongest EM/TM signature and cannot choose to lock smaller ones at the same location as a larger signature. That way you can choose which enemy fleet to target but not specific ships.

Also great for self-guided missiles, you could make missiles that'll prioritize targeting the big EM signature of actives so that you can eliminate the big scouts.
I don't really like that mechanic, it sounds contrived and weird.

I also admittedly do not love the mechanic, as the ability to fight an enemy fleet without active targeting would be to say the least exceptional in Aurora, and likely would be horribly imbalanced.

That said, "Aurora is not balanced"™ and I think this mechanic was in VB6 at least for thermal-seeking missiles, so it is not contrived and arguably not weird either as the heat-seeking missile is not a novel invention even in the real world.

This could lead to an interesting countermeasure at least for player fleets where a missile with a higher thermal signature than the largest ship in a fleet could be launched to divert the heat-seeking missiles, which would be extremely hilarious.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on June 26, 2021, 05:50:58 PM
Will it not at least be worth considering TFI in 1.14 where you potentially have raiders that come and blow your terraforming stations up (or captures them perhaps). Ground based facilities might be easier to defend with that in mind.

Otherwise I agree... I would like for TFI to be the most viable on decently low colony cost planets and that terraforming stations are mainly for really high cost planets or if population is at a premium, but overall terraforming modules should be more expensive to build.
Title: Re: C# Suggestions
Post by: Blogaugis on June 27, 2021, 03:56:18 PM
Getting back to the modules versus installations debate about terraformers - There is 1 thing I noticed about modules:
They require crew. 100 per module. Since, I typically design an entire station, with 10 of these modules, I get a crew requirement above 1000...
And it may not be a problem late game, when you have plenty of academies and populations... But it can be early game - building just 4 of such stations depletes your crewmen and junior officers fast. And subsequently, grade goes down...

So there is yet another hidden advantage to the installations - they don't "eat up" your crew...

Regardless, my point still stands - there has to be more advantages to the installations to make them feasible.
Title: Re: C# Suggestions
Post by: Droll on June 27, 2021, 04:13:42 PM
Getting back to the modules versus installations debate about terraformers - There is 1 thing I noticed about modules:
They require crew. 100 per module. Since, I typically design an entire station, with 10 of these modules, I get a crew requirement above 1000...
And it may not be a problem late game, when you have plenty of academies and populations... But it can be early game - building just 4 of such stations depletes your crewmen and junior officers fast. And subsequently, grade goes down...

So there is yet another hidden advantage to the installations - they don't "eat up" your crew...

Regardless, my point still stands - there has to be more advantages to the installations to make them feasible.

Except that the crew count is irrelevant because there is a button labelled "conscript" which when checked, makes such stations not take crew from the officer/crew pool. Also for completeness, crew grade does not improve the productivity of modules so gameplay wise there is no reason not to check a terraformer as a conscript ship.

The only crew based argument is the CO officer, but that's also relevant because you just set the officer priority to 0, this means that ground based installations just have the governor bonus advantage, which is more than closed by the cost gap between ground and orbital.
Title: Re: C# Suggestions
Post by: QuakeIV on June 27, 2021, 05:11:05 PM
Yeah you don't need navy grade crew for the terraformers so its not the same.
Title: Re: C# Suggestions
Post by: db48x on June 28, 2021, 05:49:25 AM
Forgive me if this is a duplicate; I have about 20 pages of suggestions to catch up on!

An NPR generated when I was playing on 260% difficulty 80 years in.

I get that the size of NPR populations is dependent on the above factors in order to give some sort of challenge.
But what just happened is that the game spawned 30bn aliens on a world that can only accommodate 8bn population (they have 100% population density).

I think what should happen is either:
- Game respects the carrying capacity of the body
- Game creates designs of colossal orbital habitats in such a way that the carrying capacity + orbital capacity is sufficient to house the population.


EDIT: I should also mention this world had dangerous levels of CO2 as well which I had to SM replace with aesthesium.
EDIT: For the problem I pointed out in the edit, the game should, once it's decided that the planet in question will have an NPR, modify the body to actually have 0 cost for whatever alien it's decided to put there.

SJW: Max pop for NPR will now be the capacity of the planet. Also fixed dangerous gas problem.

This was a reasonable bug fix, but I suggest that this would be a nice place for future enhancement. If the population would be larger than the planetary capacity, then the game could give the new NPR extra colonies on nearby planets. Find some planets with reasonable colony costs and give them infrastructure and facilities. If they have minerals, move a few mines to them, otherwise financial centers or research labs or something. This should give a new NPR a lot more life.
Title: Re: C# Suggestions
Post by: Droll on June 28, 2021, 05:52:18 AM
Forgive me if this is a duplicate; I have about 20 pages of suggestions to catch up on!

An NPR generated when I was playing on 260% difficulty 80 years in.

I get that the size of NPR populations is dependent on the above factors in order to give some sort of challenge.
But what just happened is that the game spawned 30bn aliens on a world that can only accommodate 8bn population (they have 100% population density).

I think what should happen is either:
- Game respects the carrying capacity of the body
- Game creates designs of colossal orbital habitats in such a way that the carrying capacity + orbital capacity is sufficient to house the population.


EDIT: I should also mention this world had dangerous levels of CO2 as well which I had to SM replace with aesthesium.
EDIT: For the problem I pointed out in the edit, the game should, once it's decided that the planet in question will have an NPR, modify the body to actually have 0 cost for whatever alien it's decided to put there.

SJW: Max pop for NPR will now be the capacity of the planet. Also fixed dangerous gas problem.

This was a reasonable bug fix, but I suggest that this would be a nice place for future enhancement. If the population would be larger than the planetary capacity, then the game could give the new NPR extra colonies on nearby planets. Find some planets with reasonable colony costs and give them infrastructure and facilities. If they have minerals, move a few mines to them, otherwise financial centers or research labs or something. This should give a new NPR a lot more life.

This is inline with a previous suggestion that shouldn't be too far back that suggested that TN NPRs could be generated as interstellar empires.
Title: Re: C# Suggestions
Post by: db48x on June 28, 2021, 05:56:17 AM
These two bugs, now fixed, are related by a common factor:

Got what seemed like a couple hundred errors during system generation jumping into a new JP. Function #2608, #222, #224, #2339 in that order, and then repeating. Over and over.

According to a quick peek in the database, this is a new NPR (not a spoiler race) and they have been generated with the "pre-industrial" flag.

Edit: So, I don't know if this is intended or not, but when I approached their planet I discovered that they have two separate empires for the same NPR race on the planet. I'm only detecting STO and ground forces for one of them.

Update on the strike-through text: This system actually spawned with both a 1) Pre-industrial NPR, and 2) Rakhas on the same body. That seems like a bug, although it's an interesting situation with roleplay implications. Also, apparently they're not hostile to each other even after time progresses. I don't think they can detect each other. Maybe this bug created an interesting enough situation not to fix it. (Except for all the error messages I originally got above on system gen)

I don't know, because I never saw the aliens five hops away. My ship was destroyed by unknown, unseen ships and STO weapons.
I neglected to add a thermal sensor to my geo survey ships, and now I pay the price.

However, I started the game with no NPRs, so I don't see how these two races could be the same race. They certainly didn't hop from Cadbury to Mabel without me seeing them. And they couldn't have grown from Mabel to Cadbury: Mabel didn't exist (i.e., I did not discover it) until years and years after Cadbury.

If they are both the same spoiler race, it is odd that one has ships and STO weapons but the other does not.

I am guessing, but I think what happened was as follows
  • Cadbury population is Rakhas but doesn't have either STO weapons or tracking stations.
  • You land in Cadbury but the Rakhas don't detect your ground forces and therefore don't have an alien race record for your race.
  • Mabel population is also Rakhas but this one does have STO weapons.
  • Mabel population detects your survey ship and destroys it with STO weapons.
  • Rakhas now have an alien race record and classes you as hostile
  • Rakhas in Cadbury launch an assault because they now know you exist and ground combat doesn't actually need a sensor contact
I'll add at least one tracking station to Rakhas to prevent that situation (assuming my guess is correct).

They both involved populations that exist on the same body but that cannot detect each other. I suggest that some thought be given to how this could be resolved. The easiest way is for there to be immediate mutual detection, but with different text in the logs than for detecting ships. A more creative way might be to allow for a degree of stealth; it might be quite interesting to stealthily land on a planet with Rakhas or a pre–industrial race with no capability of detecting ships, and try to study them from afar.
Title: Re: C# Suggestions
Post by: Blogaugis on June 28, 2021, 11:46:38 AM

Except that the crew count is irrelevant because there is a button labelled "conscript" which when checked, makes such stations not take crew from the officer/crew pool. Also for completeness, crew grade does not improve the productivity of modules so gameplay wise there is no reason not to check a terraformer as a conscript ship.

The only crew based argument is the CO officer, but that's also relevant because you just set the officer priority to 0, this means that ground based installations just have the governor bonus advantage, which is more than closed by the cost gap between ground and orbital.
Yeah you don't need navy grade crew for the terraformers so its not the same.
Well then...
So that's what the 'conscript' means... Thank you.

I guess then it is somewhat relevant if you are creating a multi-purpose station with armor and weapons and a terraforming module, but it is rather ineffective.
Otherwise, the same. Installations need to be improved.
Title: Re: C# Suggestions
Post by: QuakeIV on June 30, 2021, 04:26:56 AM
I personally think its not really critical, but yeah terraforming installations are inferior in pretty much every way.
Title: Re: C# Suggestions
Post by: Lord Solar on June 30, 2021, 12:50:57 PM
I've played for a bit, and the weapon I find really lackluster is mesons. This weapon needs a direct buff; this could be addressed through the "Meson Armor Retardation Chance" tech line so that the Meson has much greater chance to penetrate armor. The chance should at least scale with armor rather than being left behind so mesons actually get worse at higher tech levels.
Buff Mesons
please
Title: Re: C# Suggestions
Post by: Droll on June 30, 2021, 03:02:39 PM
I've played for a bit, and the weapon I find really lackluster is mesons. This weapon needs a direct buff; this could be addressed through the "Meson Armor Retardation Chance" tech line so that the Meson has much greater chance to penetrate armor. The chance should at least scale with armor rather than being left behind so mesons actually get worse at higher tech levels.
Buff Mesons
please

Honestly all you'd need would be to make it be % chance to ignore armor as opposed to % chance to ignore each layer of armor. Right now at max meson retardation (7% chance to be absorbed per layer), ships of armor level 10+ become virtually immune to mesons.

I think mesons were meant to be an anti-small weapon and not be very powerful against large ships, but they get completely superseded by AMMs in the anti-small role.
Title: Re: C# Suggestions
Post by: Bremen on June 30, 2021, 03:11:57 PM
I've played for a bit, and the weapon I find really lackluster is mesons. This weapon needs a direct buff; this could be addressed through the "Meson Armor Retardation Chance" tech line so that the Meson has much greater chance to penetrate armor. The chance should at least scale with armor rather than being left behind so mesons actually get worse at higher tech levels.
Buff Mesons
please

Honestly all you'd need would be to make it be % chance to ignore armor as opposed to % chance to ignore each layer of armor. Right now at max meson retardation (7% chance to be absorbed per layer), ships of armor level 10+ become virtually immune to mesons.

I think mesons were meant to be an anti-small weapon and not be very powerful against large ships, but they get completely superseded by AMMs in the anti-small role.

I actually think the main preciptator of the change was Steve having visions of thousands of STO mesons blasting entire armadas out of the sky. I do agree that the nerf hit them too hard and they no longer have much of a role, though.

The change I'd like to see would actually be for larger mesons to do multiple points of damage and each failed armor penetration roll would reduce the damage by 1. So if you had a heavy meson that did 3 damage, and it failed its 7% (or whatever) chance, it does 1 damage to the armor and the remaining two points continue rolling to penetrate the rest of the armor.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 30, 2021, 04:36:12 PM
Honestly all you'd need would be to make it be % chance to ignore armor as opposed to % chance to ignore each layer of armor. Right now at max meson retardation (7% chance to be absorbed per layer), ships of armor level 10+ become virtually immune to mesons.

I think mesons were meant to be an anti-small weapon and not be very powerful against large ships, but they get completely superseded by AMMs in the anti-small role.

Actually for a 7% retardation chance, 10 layers of armor would block about 50% of meson shots, as (1-0.07)^10 = 0.484. So mesons are a bit less bad than they seem but still pretty bad given that this is the max tech and at the same tech level ten layers of armor is really a bit light if anything.

In my view a big problem with mesons is that they are RP-intensive (not ideal for a specialized weapon with limited applications), and two of the techs are both purely +range effects and are quite redundant as a result. That said, I don't think having a flat %chance to ignore all armor is a good buff, as it is too extreme and basically brings back the VB6 mesons (very problematic) with a side helping of RNG which can only add frustration. Frankly the current state feels like a harsh nerf intended to remove mesons from the game without actually removing mesons from the game since people like the flavor but the actual concept is problematic.

I think any solution is going to have to come from giving the caliber/focal size tech line a better effect, which is tricky as any new effect needs to scale so as not to become a perfect anti-armor weapon at high tech levels while being passably useful at lower tech levels. One thought would be to have the caliber techs specify the number of armor layers which can be passed through by (1-x)% chance where x is the retardation tech level. For balance this may need to be something like sqrt(caliber/10) with a minimum of 1 (10 cm) and maximum of 2.83 (80 cm).

Then the formula for the %chance a meson shot penetrates changes from (1-x)^n, where n is the number of armor layers, to (1-x)^(n/c) where c=sqrt(caliber/10) is the number of armor layers bypassed by each check and fractional values are preserved. In this case at max tech level a meson can penetrate about 28 layers of armor about 50% of the time, rather than 10, which is I think reasonable given the cost, size, and ROF for such a large weapon. At base tech level nothing has changed, so much like shields a few levels of research are needed to produce a useful weapon. A mid-tech meson cannon with 25 cm caliber and 24% retardation will have a 50% chance to penetrate 4 layers of armor, which sounds maybe a bit frightening but this is already possible with a 9-damage laser that also does armor damage so I think it is fine.
Title: Re: C# Suggestions
Post by: xenoscepter on June 30, 2021, 04:49:21 PM
I've played for a bit, and the weapon I find really lackluster is mesons. This weapon needs a direct buff; this could be addressed through the "Meson Armor Retardation Chance" tech line so that the Meson has much greater chance to penetrate armor. The chance should at least scale with armor rather than being left behind so mesons actually get worse at higher tech levels.
Buff Mesons
please

Honestly all you'd need would be to make it be % chance to ignore armor as opposed to % chance to ignore each layer of armor. Right now at max meson retardation (7% chance to be absorbed per layer), ships of armor level 10+ become virtually immune to mesons.

I think mesons were meant to be an anti-small weapon and not be very powerful against large ships, but they get completely superseded by AMMs in the anti-small role.

I actually think the main preciptator of the change was Steve having visions of thousands of STO mesons blasting entire armadas out of the sky. I do agree that the nerf hit them too hard and they no longer have much of a role, though.

The change I'd like to see would actually be for larger mesons to do multiple points of damage and each failed armor penetration roll would reduce the damage by 1. So if you had a heavy meson that did 3 damage, and it failed its 7% (or whatever) chance, it does 1 damage to the armor and the remaining two points continue rolling to penetrate the rest of the armor.

 --- I made this exact same suggestion myself, not so very long ago... :)
Title: Re: C# Suggestions
Post by: Froggiest1982 on July 01, 2021, 10:41:56 PM
Would be nice under the Empire Mining Tab of the Economic vie to have a further column for the total access.

Currently, you have minerals in the stockpile and the stockpile change. Adding the total mineral we have access to between all colonies will help to identify immediately if there is a mineral we are going to need soon.

Eventually, a stockpile change filter by time (same as the wealth) could be also appreciated.
Title: Re: C# Suggestions
Post by: Kiero on July 02, 2021, 12:49:57 PM
I would love to see a fighter size ship that can operate without a crew, like a drone.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 02, 2021, 02:12:04 PM
I would love to see a fighter size ship that can operate without a crew, like a drone.

It's worth noting why this isn't currently possible, because it makes an easy (if partial) fix available:

Currently, it is actually possible to design a ship with a single crew member (box launcher missile bomber with a small/slow enough engine), however it is not possible to get down to zero crew on a self-propelled ship because engines have a required minimum crew of 1. However, above this minimum the required crew is just the engine size (in HS) times the EP boost modifier, rounded to the nearest integer. Thus the only change required would be to allow rounding to zero in the engine crew calculation.

This would allow zero-crew fighters to be possible at least for box launcher designs, without adding a weird exception in the C# code for a separate "drone" class which Steve would probably not want to do as part of the design approach to C# is eliminating weird exceptions like that.

For beam fighters I don't know if there are any beam weapons which can be built with no crew requirement (even 1/4 size railguns require 3 crew, though I don't remember is 0.5-HS Gauss has a requirement or not?).
Title: Re: C# Suggestions
Post by: Kiero on July 02, 2021, 02:28:27 PM
The solution might be another "crew quarters" module that would fulfill all ship crew requirements but would provide 0 crew.
Title: Re: C# Suggestions
Post by: QuakeIV on July 02, 2021, 04:09:09 PM
I don't personally like the idea of 'crew module but actually not' as an unmanned solution.  Id argue to fully implement that you would need to design 'auotnomous' parts that are heavier, but not require a crew quarters.  Additionally, perhaps maintenance failures just stay broken.
Title: Re: C# Suggestions
Post by: Droll on July 02, 2021, 04:38:30 PM
Additionally, perhaps maintenance failures just stay broken.

This alone would make them a small-craft only thing as the way failure rates work you wouldn't be able to stop a large autonomous ship from detonating in orbit. Unless you add a special "repair droid garage" component that is 250-500t which enables autonomous repairs.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 02, 2021, 04:50:42 PM
If we must have robotic crews, maybe just a new checkbox for that in the class design window is sufficient - check the box, and there is no change other than the crew is robots instead of humans/aliens. Crew quarters, etc. remain identical (call them something else, or just RP the change). The downside would be that robotic crews receive no crew/fleet training or commander benefits, thus being starkly inferior to even level 1 trained crews but better out of the box than conscript crews, although even those can train up fairly easily.

This way robotic crews are generally a weak option, but can be useful in a pinch if you need to build a lot of ships quickly and don't have enough crew to fill them (an ideal role for drone fighters). I think the big danger of robotic crews is that if they are "too viable" they remove one of the resource-management aspects of the game (crew management), but this should render them relatively innocuous as they are only better than even conscripted crews on very short notice.
Title: Re: C# Suggestions
Post by: QuakeIV on July 02, 2021, 04:52:52 PM
I don't really agree with those tradeoffs, usually mass automation is not an option you exercise at the last second in a pinch, like 'oh dang im running low on trained crew people i guess ill just quickly engineer automatons that can perform every function a human can as a stopgap measure'.  Its frankly usually the opposite of that where its much easier and quicker to find some way to do a job with a human, and then later as the job gets more developed machines start to take over, which is usually much more work.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 02, 2021, 05:40:23 PM
I don't really agree with those tradeoffs, usually mass automation is not an option you exercise at the last second in a pinch, like 'oh dang im running low on trained crew people i guess ill just quickly engineer automatons that can perform every function a human can as a stopgap measure'.  Its frankly usually the opposite of that where its much easier and quicker to find some way to do a job with a human, and then later as the job gets more developed machines start to take over, which is usually much more work.

I think that is kind of the problem, though, if automated crew is able to effectively replace human crews then that would remove the gameplay of managing crew (academy training level, crew and fleet training, etc.) not to mention probably ship commanders. Steve generally doesn't seem to be big on adding new mechanics that trivialize other mechanics, particularly when we can just use our imaginations instead.

I might also suggest that while what you say is true for mass industrial automation, it may not be true for ship crews depending on how one chooses to roleplay, as a lot of human intuition, initiative, and decision-making comes into play which robotic crews wouldn't have. A Star Wars-themed campaign for example might place droids and humans/aliens on a more even footing.
Title: Re: C# Suggestions
Post by: QuakeIV on July 02, 2021, 06:41:19 PM
I suggest none of those things, I am saying those tradeoffs don't really make sense.  In addition, it being one checkmark away from regular human crew and generally being slightly worse would add a small amount of fluff only and in effect be identical to conscripts.  Conscripts in that case making a lot more sense for the intended role of emergency replacement crew anyways.

In my opinion things in games should make logical sense and be generally somewhat reflective of real problem solving, not be some weird contrived thing that exists purely to achieve some game mechanics related goal, with everything else about it being loose fluff to ignore.
Title: Re: C# Suggestions
Post by: Density on July 02, 2021, 10:41:04 PM
My opinion is that a robot crew is still a crew. Right now, you can RP that your ships are run by robots: academy training = construction, programming, and testing; crew quarters = repair bays and recharge stations. Even training and grade isn't a stretch if you assume some amount of AI and/or fuzzy logic algorythms.

But the suggestion that sparked this conversation wasn't asking for robot crew, it was asking for drones.

If I had a choice on how to implement that, I'd add a checkbox or dropdown on the project screen to make the component design have 0 crew, with the trade-off being higher wealth and mineral costs and/or higher displacement. Then there'd be a wider choice of options in designs (that is you could put some autonomous components on a crewed ship instead of an all or nothing approach that would happen if this were handled at the class design step), and it wouldn't create a "fighter-only" special case.
Title: Re: C# Suggestions
Post by: Kiero on July 04, 2021, 04:29:48 PM
I also would like to see an option to set up a colony for a species that you've researched. So that you can unload a population from captured colony transport.
To create a prison colony... Yes I'm playing an evil empire.
Title: Re: C# Suggestions
Post by: serger on July 05, 2021, 03:22:07 AM
It is now rather boring to simulate or pretend that a space itself is rather dangerous place - that space ships and stations usually have significant chances to face a disaster like navigational crash or meteor strike, or critical inner system failure even with ideal crew and maintenance. In addition, it makes multirole large ship designs rather nonsensical aside of pure RP: it's significantly more efficient to have several specialized ships, compared to one multirole, just because of the ability to combine specialized ships depending on the situation.

So, my suggestion is to implement unremovable probability of critical (non-reparable-instantly) failure accident for both commercial and military components. They have to be rare (to not be more bothersome than their absence), though inevitable and invigorating.

It will be inevitably more dangerous for smaller and cheaper ships and stations, because of lesser duplication, so it will be more sense for players in larger designs, and so less drawing in micromanagement maelstrom late game.

Of course, it have rather be switchable in game options.
Title: Re: C# Suggestions
Post by: serger on July 05, 2021, 03:34:15 AM
UPD to the previous:

To take away most boring micro load, this feature have to affect only those ships that are not parked at mainteinance location or inside hangar.
Title: Re: C# Suggestions
Post by: TMaekler on July 05, 2021, 05:19:48 AM
UPD to the previous:

To take away most boring micro load, this feature have to affect only those ships that are not parked at mainteinance location or inside hangar.
There is a general game option to play without maintenance... or am I missing something?
Title: Re: C# Suggestions
Post by: serger on July 05, 2021, 05:41:55 AM
There is a general game option to play without maintenance... or am I missing something?

I think it will be better if a player will have an option to turn maintenance off and cricical failures (i.e. my suggestion) on - some players use maint. modules and installations, just do not bother with supply tenders.
Title: Re: C# Suggestions
Post by: TMaekler on July 05, 2021, 07:03:50 AM
There is a general game option to play without maintenance... or am I missing something?

I think it will be better if a player will have an option to turn maintenance off and cricical failures (i.e. my suggestion) on - some players use maint. modules and installations, just do not bother with supply tenders.
How do you want to manage the amount of failures? I guess they "just happen" depending of a low random number, independent of any maintenance value?!?
Title: Re: C# Suggestions
Post by: serger on July 05, 2021, 08:29:18 AM
How do you want to manage the amount of failures? I guess they "just happen" depending of a low random number, independent of any maintenance value?!?

There might be some dependance on maintenance value (and/or on tech levels or time from the beginning of extraterrestial ops - RP that it's your race is gaining exp in building more fail-safe components), but it's not mandatory.

And I'm not sure if I understand what do you mean on "to manage". smeg happens. It must only be rarely enough that most of player's ships and stations will never suffer from critical failures (so it will not be boring to deal with those failures all the time). In those cases they suffer - you'll maybe need tugs or carrier-docks, or just abandon their mission and return to base under its own power, or repair damage if this ship/station can do it.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 05, 2021, 10:57:07 AM
I dislike this idea. Randomly getting screwed by unavoidable RNG with no counterplay whatsoever is not fun gameplay - it may be realistic in some sense but that is not sufficient grounds for including a mechanic. The result of the mechanic is nothing fun at all - you lose a ship at what is likely an inconvenient time, and have to find a spare tug or tanker or whatever to conduct a frankly boring recovery operation. Random breakdowns are not really good storytelling either, not to say nothing can be done with it but IMO a better story for the player comes when, e.g., a ship is limping back to base having expended all its MSP to keep afloat, with the tension of knowing that one bad turn of luck could lead to an irrepairable engine failure - or worse an explosion. With just a random chance for this to happen all the time the tension is permanent which removes all excitement and just makes it more stressful.

Frankly I don't think large, multirole ships need help. Smaller specialized ships may give better performance, but they are also easier to target and destroy so that an enemy can eliminate that capability from your fleet. With a large ship the entire ship must be destroyed to remove its capabilities which is a harder task. Combined with RP reasons I think this is a sufficient balance to justify ships of both kinds, though even then I do still think a large ship should have a primary role to be most effective - a supercarrier for example should be first optimized for fighter operations, but can also have command facilities including long-range sensors and hefty point defenses.
Title: Re: C# Suggestions
Post by: serger on July 05, 2021, 12:45:38 PM
Randomly getting screwed by unavoidable RNG with no counterplay

The counterplay, obviously, if to have spare tugs/docks, tankers and bases. That's more deepness in the sky.

Random breakdowns are not really good storytelling either

Frankly I'm very surprised that smb thinks like this, because for me it's surprizes that makes game more like a story.
Because now I know that nearly every case my ship was caught by critical failure - it was my failure, my stupidity or carelessness, and just I cannot forget about it, and it's therefore not a story at all.

Frankly I don't think large, multirole ships need help. Smaller specialized ships may give better performance, but they are also easier to target

I think it's obviously the opposite - they are harder to target, especially with missiles. But, yes, they are also easier to kill when hit.
For combat ships it's now nearly balanced (considering also a build time), but for auxiliries and commerce ships it is not very much so.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 05, 2021, 01:30:26 PM
The counterplay, obviously, if to have spare tugs/docks, tankers and bases. That's more deepness in the sky.

If the "counterplay" is "more micromanagement", I cannot say I am in favor of it. Presently we do need all of these things, in some degree or another, for good mechanical reasons that make sense. Saying "okay, but now you need more because of RNG" does not make sense, at least from the perspective of good gameplay.

Quote
Frankly I'm very surprised that smb thinks like this, because for me it's surprizes that makes game more like a story.
Because now I know that nearly every case my ship was caught by critical failure - it was my failure, my stupidity or carelessness, and just I cannot forget about it, and it's therefore not a story at all.

I don't understand this. If my ship runs out of MSP or suffers a critical failure due to something I did - poor design, pushing it beyond its operating limits, and so on - then it is my failure, and knowing this is a possibility makes the decisions that lead to those cases interesting. There is a tangible story which has led to this, or which could have led to this. It's not "my failure" if my engine blows up due to a random dice roll. While I can make up a narrative on the spot about a surprise meteor shower or something, it's not interesting to me as a story - something randomly happened, and I have to make up a post-fact reason for it. A good narrative IMO has a meaningful cause and effect which feeds back to the gameplay.

I would liken to something Steve said about why he doesn't just "simulate" the NPRs to prevent increment slowdowns. There is a difference in the game narrative between jumping into a new system, seeing a wreck, and thinking "oh, the game has generated a random wreck for me to loot" versus seeing a wreck and knowing that some mysterious battle has gone on here. The former requires the player to make something up to cover the game mechanics, the latter places the player into the story being told by the game which is more immersive and emergent.

Quote
Frankly I don't think large, multirole ships need help. Smaller specialized ships may give better performance, but they are also easier to target

I think it's obviously the opposite - they are harder to target, especially with missiles.

I misspoke slightly, I mean that small specialized ships are easier to single out and destroy to eliminate a key capability.

Of course smaller ships are harder to target on sensors, but I think usually when we talk about such ships we are talking about sizes >100 HS at which point sensor resolutions usually tend to not matter very much, as ~100 is a pretty typical largest resolution, so even then the difference is not great. For ships below 100 HS I think the efficiency losses from such small size become significant enough that the discussion is quite different.

I do agree that things are generally balanced as it is. I'm not sure that auxiliary and commercial ships are very relevant to that discussion though, the design of such ships should always follow the needs of the fleet, frankly a gigantic multi-role auxiliary ship seems to me absurd unless you need such a thing to support an even bigger capital ship, and I don't think new mechanics are needed to make such a thing viable. The current paradigm makes much sense IMO.
Title: Re: C# Suggestions
Post by: QuakeIV on July 05, 2021, 07:54:09 PM
I'm not personally against the possibility of failures that cant be fixed without depo maintenance.

They should be a minority of all failures IMO, and probably should be rarer for bigger modules, but I generally like that aspect at least.  I say they should be a minority because it seems to me that it should be much easier to break something in a way that only requires replacing one or two parts than it should be to more or less totally destroy the thing.

I dunno if I like the general premise of enforcing redundancy per se though.  For instance, if I was allowed to have a small backup thruster on a ship, then that is not nearly as big of a deal, but I am forced to have all engines be the same size, which would effectively be cutting max engine size in half.  I am less a fan of that personally.
Title: Re: C# Suggestions
Post by: Droll on July 05, 2021, 08:03:39 PM
I dunno if I like the general premise of enforcing redundancy per se though.  For instance, if I was allowed to have a small backup thruster on a ship, then that is not nearly as big of a deal, but I am forced to have all engines be the same size, which would effectively be cutting max engine size in half.  I am less a fan of that personally.

There used to be a bug in the previous version in the game that allowed engines of different sizes to be added to the same design (can't remember if it also allowed mixed types, that obviously shouldn't happen). I was quite sad that Steve decided to fix that bug as I thought having multiple sizes of engine was quite a cool thing. My suggestion would be to reintroduce that bug with the engine sizes.
Title: Re: C# Suggestions
Post by: Droll on July 05, 2021, 08:08:02 PM
I will also add that random arbitrary unrepairable failures is going to be more frustrating than engaging, especially since the people who play aurora to make AARs are a minority and that seems to be the primary intention of that suggestion.
It would be less frustrating to have temporary failures that don't cost anything to resolve other than time. Can still be catastrophic if the FC farts out at the wrong time or the engines suffer a 30 sec flameout and IMO would still be arbitrary and annoying as opposed to providing a good story to tell.

I will however add that damage that cannot be repaired isn't a bad idea as a whole if there is some reason behind the damage other than random. For example, overkilling a component could result in that component being damaged in a way that requires drydock. Alternatively, components might have a minimum damage control rating, if a ship doesn't meet that need, then damage control cannot even make attempts at repairing the damaged component. Effectively making the player choosing between more space to damage control facilities vs mission tonnage.
Title: Re: C# Suggestions
Post by: QuakeIV on July 05, 2021, 08:18:08 PM
I will add that movies and shows tend to time 'random' mechanical failures to the beat of the plot and tend to make it into this whole carefully presented dramatic extravaganza that really adds to the narrative.  Usually this failure was necessary in order to make something that was otherwise unlikely happen.  (i personally usually dont like it very much as a plot device personally but admittedly it can work)

This tends to skew perception of such things, as when they are actually random they are usually just annoying.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 05, 2021, 08:21:43 PM
It would be less frustrating to have temporary failures that don't cost anything to resolve other than time. Can still be catastrophic if the FC farts out at the wrong time or the engines suffer a 30 sec flameout and IMO would still be arbitrary and annoying as opposed to providing a good story to tell.

Honestly I wish the maintenance system overall worked this way, though I understand why it doesn't, but it is more flavorful for a repair to take time and other than the occasional slowdown of a traveling fleet due to a ship blowing an engine out isn't terribly inconvenient. I will admit it also doesn't add anything to the game, though.

I will add that movies and shows tend to time 'random' mechanical failures to the beat of the plot and tend to make it into this whole carefully presented dramatic extravaganza that really adds to the narrative.  Usually this failure was necessary in order to make something that was otherwise unlikely happen.  (i personally usually dont like it very much as a plot device personally but admittedly it can work)

This tends to skew perception of such things, as when they are actually random they are usually just annoying.

Yes, this.
Title: Re: C# Suggestions
Post by: serger on July 06, 2021, 04:00:36 AM
If the "counterplay" is "more micromanagement", I cannot say I am in favor of it.

Some small scope of it, as a tradeoff.

As it is now - most of our bases are just skeletons of the bases, because we really need no harbor tugs and tenders, nor tankers aside of major fleet operations and (not always) deep survey.
With my suggestion implemented - we'll need some stable harbor ship composition, but we'll not need to use it frequently - we'll need just to have it in place or to humble about some losses for the god of Void. And it will be meaningfull choice in most cases: you'll need to choose better places for your bases, balance your support infrastructure, but it will be one-time decision for nearly every base, no boring every year routine as with combat ships overhauls and cargo flows; you'll need constant flow (building) of tugs, tankers and tenders, but it will be a flow of nearly the same classes (maybe with some modernizations from time to time), so no need to retool your shipyards serially (or look at an idle one and make yourself believe forcefully that it's ok to have lazy governors in this scope), when you have done a series of tankers and now you need no such ships for the age, but now you need several tugs, and several years later your yards are idle again, because now you need no tugs any more for ages... That's the micro! That is a dilemma between boring and disbelievable!

So the game will benefit from being more deep and steady.

Look at it in the same light as at commanders'' accidental deaths. There are some small chances that any commander can be killed in accident. Is it adding a micro? Yes, in some small scope. But it's adding a deepness both in your personnel policy and in your story.

Ships are the same.

If my ship runs out of MSP or suffers a critical failure due to something I did - poor design, pushing it beyond its operating limits, and so on - then it is my failure, and knowing this is a possibility makes the decisions that lead to those cases interesting. There is a tangible story which has led to this, or which could have led to this. It's not "my failure" if my engine blows up due to a random dice roll.

You have nearly no chance to such random dice roll now, if your design is not skimpy and your orders are just not feckless (aside of combat conditions). You have ZERO chances to this random dice roll with all commercial designs - they are now ideally trouble-free and everlasting, and there is no option to have some balanced variant: your choices are just "have failures and MSP" (and so micro) or "trouble-free and everlasting" (and so disbelieve).

So, I think it will be good to have an option to set more balanced rule.
If you have no such desire - don't turn it on.
The same as for new spoilers (those are very much in the same deepness-in-the-sky flavour).
 
A good narrative IMO has a meaningful cause and effect which feeds back to the gameplay.

It is so for the short story or the play (theatrical). It is obviously not so for novel-scope story. And Aurora is making novel-scope stories undoubtedly; there is a univerce-scope scenery, not a chamber-scope. Universe is a place, where accidents are inevitable everywhere and they are forming the structure of civilization. My strong preference is to play with more scope, though, again, it have to be optional feature, because, yes, there are players that will prefer lean stories.

I think usually when we talk about such ships we are talking about sizes >100 HS

I'm talking also about sizes from FACs (that are often somehow decennary-autonomous) to frigate-size deep surveyors (nearly everlasting because why not, isn't it?), missile and PD ships.

But it's not a main point. More important that now we are not paying much for overspecialization (because nearly no chance, that some accident will take down, say, PD half of your squadron and so you're a toast), and therefore we are getting sucked in more-and-more-combat-ships-because-it-is-the-only-efficient-way micromanagement maelstrom, where you'll have nearly the same dilemma: to pretend that it's an accident probability where game-wise there is no (and to make accidents to youself manually, just to have a story coherent), or to play with rules you have and be more and more sucked in late game micro.

I do agree that things are generally balanced as it is.

The problem, I think, that it's balanced with seemings, not with decision-making dynamics.
With new spoilers it can become more apparent.
Title: Re: C# Suggestions
Post by: Blogaugis on July 06, 2021, 07:37:56 AM
Some small scope of it, as a tradeoff.

As it is now - most of our bases are just skeletons of the bases, because we really need no harbor tugs and tenders, nor tankers aside of major fleet operations and (not always) deep survey.
With my suggestion implemented - we'll need some stable harbor ship composition, but we'll not need to use it frequently - we'll need just to have it in place or to humble about some losses for the god of Void. And it will be meaningfull choice in most cases: you'll need to choose better places for your bases, balance your support infrastructure, but it will be one-time decision for nearly every base, no boring every year routine as with combat ships overhauls and cargo flows; you'll need constant flow (building) of tugs, tankers and tenders, but it will be a flow of nearly the same classes (maybe with some modernizations from time to time), so no need to retool your shipyards serially (or look at an idle one and make yourself believe forcefully that it's ok to have lazy governors in this scope), when you have done a series of tankers and now you need no such ships for the age, but now you need several tugs, and several years later your yards are idle again, because now you need no tugs any more for ages... That's the micro! That is a dilemma between boring and disbelievable!

So the game will benefit from being more deep and steady.

Look at it in the same light as at commanders'' accidental deaths. There are some small chances that any commander can be killed in accident. Is it adding a micro? Yes, in some small scope. But it's adding a deepness both in your personnel policy and in your story.

Ships are the same.
I'm not really in favor of this, but okay. Let's try to guess how this would work.
So, what you're essentially asking for, is that commercial ships also suffer maintenance failures? Stations included?
Do the maintenance failures occur when in deep space?
Are they safe when above a 50,000+ colonist-having body? Or do they have to have a maintenance facility? A shipyard?

With the possible locations on where it could happen set, what actually happens? The ship becomes immobilized? Station gets destroyed? Tugs and salvagers are basically what we'll need, to clean up the mess? Or do we need to move just some extra maintenance supplies?

I might be more willing to accept that entities with engines suffer maintenance failures... But stations? I mean sure, they could suffer problems too, but... I don't think they should be that severe - if anything, abandoning a ship/station should be the last resort.

And about how to fight it... You're basically asking to double if not triple (and +1) our current Tug, Maintenance Carrier and Salvager fleets?


Commander accidental deaths can be disabled with 'story character' setting.
You have nearly no chance to such random dice roll now, if your design is not skimpy and your orders are just not feckless (aside of combat conditions). You have ZERO chances to this random dice roll with all commercial designs - they are now ideally trouble-free and everlasting, and there is no option to have some balanced variant: your choices are just "have failures and MSP" (and so micro) or "trouble-free and everlasting" (and so disbelieve).

So, I think it will be good to have an option to set more balanced rule.
If you have no such desire - don't turn it on.
The same as for new spoilers (those are very much in the same deepness-in-the-sky flavour).
But there is a chance, even if a very small one. And that automatically warrants spending yet another batch of minerals to T/MC/S fleets...

The alternative, of course, would be to not build ships at all.
Hey also - would civilian ships also suffer from this?
It is so for the short story or the play (theatrical). It is obviously not so for novel-scope story. And Aurora is making novel-scope stories undoubtedly; there is a univerce-scope scenery, not a chamber-scope. Universe is a place, where accidents are inevitable everywhere and they are forming the structure of civilization. My strong preference is to play with more scope, though, again, it have to be optional feature, because, yes, there are players that will prefer lean stories.
Ehhh... I dunno. I prefer to see the consequences of my actions, rather than... random encounters..?

But then again, there are accidents with ships in real world. I suppose it would be realistic, from a certain point of view.
But, if this would ever be a thing, can we at least get salvager, maintenance and tractor beam modules technologies as a free starting technology, upon developing trans-newtonian technology?
I'm talking also about sizes from FACs (that are often somehow decennary-autonomous) to frigate-size deep surveyors (nearly everlasting because why not, isn't it?), missile and PD ships.

But it's not a main point. More important that now we are not paying much for overspecialization (because nearly no chance, that some accident will take down, say, PD half of your squadron and so you're a toast), and therefore we are getting sucked in more-and-more-combat-ships-because-it-is-the-only-efficient-way micromanagement maelstrom, where you'll have nearly the same dilemma: to pretend that it's an accident probability where game-wise there is no (and to make accidents to youself manually, just to have a story coherent), or to play with rules you have and be more and more sucked in late game micro.
With how maintenance-inefficient large all-in-1 ships are, it is tempting to turn off maintenance requirements - to satisfy your megalomaniac-ish desires...
The problem, I think, that it's balanced with seemings, not with decision-making dynamics.
With new spoilers it can become more apparent.
What?
There are basically 2 choices with numerous compromises in between:
Create 1 huge commercial shipyard for a 1 design of huge multi-purpose mothership to support your entire fleet.
Create several commercial shipyards for several designs, (1 collier, 1 tanker, 1 maintenance ship)... each with it's own specialization.

With your idea of making civilian ships suffer maintenance failures, mechanically game shifts towards numerous designs and numerous different ships.
Or is it that failures are disabled when a ship has a maintenance module?
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 06, 2021, 08:59:15 AM
As it is now - most of our bases are just skeletons of the bases, because we really need no harbor tugs and tenders, nor tankers aside of major fleet operations and (not always) deep survey.

It is clear that we play the game very differently. I usually work to maintain a substantial auxiliary fleet both in ports and to support my large military fleets, and to build up large bases at suitable distances away from Sol or other core worlds. Never have I felt like Aurora somehow discouraged me from doing so, made managing logistics in any way a subpar decision, and certainly have not felt that if only I suffered more random failures my logistics arm would be able to justify its existence.

But even so, if experience is that one can build a fleet in such a way that the needed logistics arm is minimal, I think it is better than Aurora has this flexibility and the players can choose. I do not think adding mechanics expressly to encourage a specific playstyle is a good addition to the game and there are many other things I would personally rather see Steve focusing on, not that my opinion on Steve's time management matters one bit of course.

Quote
Look at it in the same light as at commanders'' accidental deaths. There are some small chances that any commander can be killed in accident. Is it adding a micro? Yes, in some small scope. But it's adding a deepness both in your personnel policy and in your story.

There is very rarely micro due to auto-assignments in my experience, and frankly an important commander's accidental death does not really add any deepness to the story, just another event that happened. "Depth" and "more things" are not synonymous.

Quote
If you have no such desire - don't turn it on.

This is always true but is not relevant for the discussion of whether a proposal is worth the time and work to be added to the game.
 
Quote
It is so for the short story or the play (theatrical). It is obviously not so for novel-scope story. And Aurora is making novel-scope stories undoubtedly;

If you think I play Aurora for short stories I have an AAR for you to read.

Quote
and therefore we are getting sucked in more-and-more-combat-ships-because-it-is-the-only-efficient-way micromanagement maelstrom,
[...]
The problem, I think, that it's balanced with seemings, not with decision-making dynamics.

Not sure what this is about. Aurora is in terms of genre a 4X game, and one of those Xs is "expand". The point of the game is to get bigger, you may of course choose to play it otherwise but that is how the game is designed. If the need to build more ships is taken as a fundamental flaw of the game the issues run much deeper than an RNG accident mechanic can fix. Frankly I think there is an excellent balance of decision-making in most areas of the game including ship design, many different paradigms are viable (although not all may be optimal - this is not a problem) for all areas of a fleet. If I want to build FACs, this is viable. If I want to build 50,000-ton capital ships, this is viable. If I want 20 specialized auxiliaries, this is viable. If I want a handful of mega-auxiliaries with all capabilities on one hull, this is viable. The key is to allow decisions to be driven by flavor, roleplay, and a sense of what is fun in a campaign, not only what is optimal. If we seek the optimal, there will inevitably always be one and only one optimal path by definition; it is useless to try to circumvent this immutable fact with new (and annoying) mechanics.

Ehhh... I dunno. I prefer to see the consequences of my actions, rather than... random encounters..?

This is the crux of it. RNG is good when it leads to the game interacting with the player to pose an interesting challenge or situation, then the player's choices and actions in response have meaning and emergent storytelling. If RNG is just Zeus throwing a lightning bolt at random to screw the player over, that isn't fun gameplay nor a terribly interesting story after the first few times. Maybe it is realistic, but real life does not make for the best game otherwise we would not play games in the first place.
Title: Re: C# Suggestions
Post by: serger on July 06, 2021, 09:35:27 AM
So, what you're essentially asking for, is that commercial ships also suffer maintenance failures? Stations included?
Do the maintenance failures occur when in deep space?
Are they safe when above a 50,000+ colonist-having body? Or do they have to have a maintenance facility? A shipyard?

They have to be fully safe at sufficient maintenance location - it can be maintenance facilities (colonial base) or modules (orbital or deep space base) or hangar - reflecting that a vessel, that is sitting maintained at her base, just probably isn't doing anything and so it's much, much lesser chance that there can be some critical accident).

To lessen a bothersome easy-to-fix problems - it can be additional rule, that free sheepyards are making their locations safe too (RP - there can be accidents, still without report to the highest level, because they were momentary repaired). Though I'd prefer to just fix these manually, because it isn't going to be nearly as much bother as patrolling routine or fixing broken training fighters (that's a bother really!), and I'd feel it as some sort of the pulse of empire, instead of rolling my eyes when there are only training fighters that are breaking restlessly despite being at maint return every month, while all other ships seems to be immune to breaks for decades.

With the possible locations on where it could happen set, what actually happens?

The same as if a component was damaged by enemy fire.
(It can be fatal - big power plant blown up, for example, but it's very unlucky. In most cases it will be "possibly mission kill" and so a need to change course to base or send a help. Or just add an order to do smth after the current mission, if there is no vital need to fix it. Or just ignore, if it's an old ship, that is trudging for her scrap location.)

And about how to fight it... You're basically asking to double if not triple (and +1) our current Tug, Maintenance Carrier and Salvager fleets?

Yep.
More auxiliary commercial ships sitting calmly at their bases most of their time - and bigger, more balanced (in the sense of non-specialized) and less numerous military ships instead - like the Bismark and the Tirpitz with several raiding and patrolling cruisers + escorts, instead of a bunch of beam ships, a bunch of missile ships and a bunch of PD ships of different sizes.
Or just turn this off and play as it is now if you like it more.

Commander accidental deaths can be disabled with 'story character' setting.

You can set several characters as story characters, but it will not save you from constant flow of accidental deaths of commanders.
(And when you make so - you have to watch manually for the age of your characters, if you are not playing with some sort of immortal mutants.)

Hey also - would civilian ships also suffer from this?

They have their own management and their own abstracted repair facilities, so I see no point.

Ehhh... I dunno. I prefer to see the consequences of my actions, rather than... random encounters..?

Ok, so you will not turn it on.
I think that if this suggestion will face no enthusiasm - it will not be implemented, and if will suddenly face some (positive) enthusiasm and be implemented - you just will not turn it on, so you will not suffer in any case.

I really don't understand a point of expressing dislike to optional feature.
Just don't turn it on if it will be implemented!

But, if this would ever be a thing, can we at least get salvager, maintenance and tractor beam modules technologies as a free starting technology, upon developing trans-newtonian technology?

You can get any tech with several clicks in Space Master mode.
It's a simple once-only action (no micro at all) and it's a way you are expected to play Aurora.

With your idea of making civilian ships suffer maintenance failures, mechanically game shifts towards numerous designs and numerous different ships.

?

Or is it that failures are disabled when a ship has a maintenance module?

If a ship is able to fully maintain herself... well, it's not very often design, but I think it's tolerably to consider them failure-free just to make no exception of general micro-lessening rule.
Title: Re: C# Suggestions
Post by: serger on July 06, 2021, 09:57:21 AM
I do not think adding mechanics expressly to encourage a specific playstyle is a good addition to the game and there are many other things I would personally rather see Steve focusing on, not that my opinion on Steve's time management matters one bit of course.

Well, I don't see how it's only to encourage a specific playstyle (I have made some other explanations about what is this for), but even if it's so - what are you doing by repeatedly expressing a dislike to suggested optional feature?

Again: if this suggestion will face no enthusiasm - it just will not be implemented, and if it will suddenly face some (positive) enthusiasm and will be implemented - those who dislike it just will not turn it on, so you will not suffer in any case.

What is the point of arguing about personal preferences in this case?
Title: Re: C# Suggestions
Post by: Blogaugis on July 06, 2021, 11:23:01 AM
With your idea of making civilian ships suffer maintenance failures, mechanically game shifts towards numerous designs and numerous different ships.

?

Or is it that failures are disabled when a ship has a maintenance module?

If a ship is able to fully maintain herself... well, it's not very often design, but I think it's tolerably to consider them failure-free just to make no exception of general micro-lessening rule.
Or, actually...
Is failure rate % per ship? or a %, divided across all the ships?
Since, if it is Per Ship then it may be better to go for fewer amount of ships actually...
If % across all the ships, then more ships are better, with different roles and backups.


I do not think adding mechanics expressly to encourage a specific playstyle is a good addition to the game and there are many other things I would personally rather see Steve focusing on, not that my opinion on Steve's time management matters one bit of course.

Well, I don't see how it's only to encourage a specific playstyle (I have made some other explanations about what is this for), but even if it's so - what are you doing by repeatedly expressing a dislike to suggested optional feature?

Again: if this suggestion will face no enthusiasm - it just will not be implemented, and if it will suddenly face some (positive) enthusiasm and will be implemented - those who dislike it just will not turn it on, so you will not suffer in any case.

What is the point of arguing about personal preferences in this case?
I personally prefer to see genetic modification tree working, Terraforming installations buffed and ground combat HQs having an option to give bonuses to units on different worlds and ships.  :)
Commercial failure additions... are kind of... secondary thing.
Title: Re: C# Suggestions
Post by: serger on July 06, 2021, 12:13:55 PM
Is failure rate % per ship? or a %, divided across all the ships?

Per component - the same as with other failures.
Title: Re: C# Suggestions
Post by: SerBeardian on July 08, 2021, 04:52:36 AM
1. Measure wall clock time on the turn and if it takes less than, say 0.1 seconds IRL, have the game just delay for a bit if auto turns is enabled

Pfff, just open up different game windows until the game is slowed to your liking. No need for forcible slowdown code since some people (like me) can handle letting it rip flat out.

Edit: WOW I'm late/was not paying attention.

Anyway, an actual suggestion:
With 1.14 adding the ability to transfer ships, I would very much like the ability to transfer other things too specifically:
- Inter-colony cross-species stuff transfer, like being able to hand over installations, minerals, population, wealth, etc. to colonies on the same body.
- tech/design transfer to other species

Letting player empires interact with other player empires without needing to hack a solution together out of SM mode and DB editing would be very, very good.
Title: Re: C# Suggestions
Post by: TMaekler on July 08, 2021, 07:54:18 AM
And I'm not sure if I understand what do you mean on "to manage". smeg happens.
Sorry, I am from Germany and I think I used our understanding of "Managen" for that word... . So I meant basically what you described. I dislike the idea of it being completely random. You as the player should be able to "manage" the chance of how often the failures can happen by choosing how much you want to invest in such failsafe systems. As you are now able to. The amount of maintenance use can vary greatly depending on your designs. And due to increase in size of the ship these things affect the rest of its function as well... . Wouldn't like to loose that feature.
Title: Re: C# Suggestions
Post by: serger on July 08, 2021, 10:15:59 AM
I dislike the idea of it being completely random. You as the player should be able to "manage" the chance of how often the failures can happen by choosing how much you want to invest in such failsafe systems. As you are now able to. The amount of maintenance use can vary greatly depending on your designs. And due to increase in size of the ship these things affect the rest of its function as well... . Wouldn't like to loose that feature.

Well, absolutely the same as I am!
That's why my suggestion is not to remove MSP and normal failures as they are now, but to add some small (and optional) probability of "smeg happens", that cannot be removed.
Again: even with this option on you'll be able to manage failure rates with nearly all of it's present range of values - just will not be able to lower critical failure probability downto zero and nearly-zero levels, as you easily can do now (aside of combat environment) with commercial designs and MSP for military designs.

And, again, it's not to compel for some specific gameplay: primarily it have to be optional setting anyway, and even if it's on - you'll have an option to ignore a risk of critical failures, and smth about 3 of 4 games it might be that you'll suffer no really-critical-criticals and will be able to nearly ignore those criticals you'll get (an engine blown at some freighter? well, at 80% speed she'll do her job nonetheless). It have to be more an RP-reminder, than smth compelling (though not RP only - it's better to have RP and minimax aspects deeply intersecting, not strictly separate).
Title: Re: C# Suggestions
Post by: gpt3 on July 09, 2021, 11:22:38 PM
I just now noticed that larger planets' and moons' diameters always seem to be nice multiples of 100.  This makes generated systems feel a bit less realistic: for example, in my current game there is a gas giant that has three moons each with a diameter of exactly 2,800 km.

Would it be feasible to add some random noise (say, +/- 10%) to bodies' diameters during system creation?
Title: Re: C# Suggestions
Post by: serger on July 10, 2021, 02:28:21 AM
I think it's really not a less realistic, because a diameter of celestial body is not a simple and reliably accurate thing. Planets really are not spherical - there are crust platforms, mount ranges, large craters and so on even for planets with solid surface, and for gas giants it's really very questionable what is their surface to calculate a diameter.

That's why astronomers are ok with rounding diameters.
Title: Re: C# Suggestions
Post by: TMaekler on July 10, 2021, 03:07:29 AM
That's why my suggestion is not to remove MSP and normal failures as they are now, but to add some small (and optional) probability of "smeg happens", that cannot be removed.
I misunderstood your idea as removing the actual system. Hmmm, additionally then... .
Title: Re: C# Suggestions
Post by: Droll on July 10, 2021, 10:13:31 AM
I just now noticed that larger planets' and moons' diameters always seem to be nice multiples of 100.  This makes generated systems feel a bit less realistic: for example, in my current game there is a gas giant that has three moons each with a diameter of exactly 2,800 km.

Would it be feasible to add some random noise (say, +/- 10%) to bodies' diameters during system creation?

To add to serger's response you'll notice that in the sol system bodies do actually have more accurate diameter measurements. It's all down to us being able to measure close by objects with more precision than ones millions of light years away.
Title: Re: C# Suggestions
Post by: QuakeIV on July 10, 2021, 12:54:10 PM
That doesn't really make sense, once the body is survey scanned we should pretty much know down to the millimeter.

I'm fine with rounding personally, seems like a minor inconsistency that Sol doesn't match that.
Title: Re: C# Suggestions
Post by: Droll on July 10, 2021, 01:20:27 PM
That doesn't really make sense, once the body is survey scanned we should pretty much know down to the millimeter.

I'm fine with rounding personally, seems like a minor inconsistency that Sol doesn't match that.

I should have clarified that this isn't necessarily an in game thing but more of an IRL thing. We don't have accurate readings on planets that aren't in the solar system so there's no point in trying to generate planets that have exact dimensions in aurora when the rounded ones work just fine.

Sol doesn't match this because we have IRL measurements for the planets in the solar system so you can use real life data when creating Sol. Can't do that with exo-planets.
Title: Re: C# Suggestions
Post by: QuakeIV on July 10, 2021, 02:28:29 PM
But the generated ones aren't supposed to be real anyhow, and you would have accurate measurements of those just fine?
Title: Re: C# Suggestions
Post by: TMaekler on July 11, 2021, 05:01:32 AM
Many players include certain information in the name of the ship modules. For example: S6 W9 M14 R2.5mkm - are usually added by me for missiles, and I have seen many players doing similar things. It would be a nice QoL if that information could be added by the game automatically - but we have a way of defining what we want to have "auto-generated"... .
Title: Re: C# Suggestions
Post by: Borealis4x on July 12, 2021, 04:26:51 AM
I'd love if the game kept track of the ships number and designation somewhere.

I.e., it says CV-12 for your 12th carrier vessel. Even better if you could tick a box to include it in the name.
Title: Re: C# Suggestions
Post by: Warer on July 12, 2021, 11:05:36 AM
Group by class in Naval Organization, with a pop up when drag and dropping for how many of that group to move, to minimize fighter micro especially for micro-fighters. Failing that box select and drag and drop if at all possible.

Thought I`m suspecting this isn`t possible for some reason, as due to being so obvious it would be in the game if it was.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 12, 2021, 11:41:53 AM
Group by class in Naval Organization, with a pop up when drag and dropping for how many of that group to move, to minimize fighter micro especially for micro-fighters. Failing that box select and drag and drop if at all possible.

Thought I`m suspecting this isn`t possible for some reason, as due to being so obvious it would be in the game if it was.

Doesn't the window already group ships by class, within a fleet or subfleet of course?

If you select a fleet, in the ship list window on the right side you can use Shift+click and Ctrl+click to select a group of ships. I always use this to arrange my fighters at game start. The "Create Subfleet" button will operate on a selection made in this way allowing you to easily create fighter squadrons from a large fleet of fighters.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 12, 2021, 11:54:35 PM
In the Naval Organization Window, Ship Overview top tab, Ordnance Template bottom tab:

Currently "SM: Fill Ship" and "SM: Fill Class" only fill the selected ship, using the ship or class template loadout, respectively. It would be nice to have an additional button which would fill all ships of a class with the class ordnance template, to assist in making corrections especially at game start. Alternatively the current "SM: Fill Class" button could be changed to have this function since I imagine it gets very little use compared to "SM: Fill Ship".
Title: Re: C# Suggestions
Post by: TMaekler on July 13, 2021, 02:45:10 AM
Traditional Navymen: It happens ever so often that kids of famous military men also join the services. It could be a nice addition if Aurora kept track of successful Generals and Admirals and would join age-fitting new recruits so they could also go for a successful military career. Those new recruits obviously would have a high score in political relations and will increase in rank even if they are total loosers. When these kids join military it would be nice if the game sends a fitting message to the log. "New promising officer: The son/daughter of General Miller has joined your ranks as a Lieutenant."
Title: Re: C# Suggestions
Post by: QuakeIV on July 13, 2021, 03:09:32 AM
This is a highly entertaining idea and I like it.
Title: Re: C# Suggestions
Post by: serger on July 13, 2021, 05:35:36 AM
1. Make Build Points / Wealth Cost for all components square rooted from their sizes (the same as Research Points now) instead of linear.
2. Add a modifier to Hit Chance, square rooted from the target size (with x1 point at 1000 tons as a natural watershed between spacecraft and starships).

(Side note: square root isn't the best as realistical approximation, yet it's simple, and it's too exciting for before dinner to tweak formulas with intersections between average target effective projection and gaussian distribution of impact trajectories, where this gaussian isn't flat enough to pretend it's even.)

Light combat ships and fighters will become less vulnerable, yet relatively more expensive, so overall balance might be preserved, with a shift to more elite-like fighter forces and recon role for light military ships.
Title: Re: C# Suggestions
Post by: kingflute on July 13, 2021, 05:41:53 AM
Allow for ships to power down their engines, to reduce their thermal signature massively at the expense of having access to passive sensors only, no fire control, shields or weapons during this state. Possibly including a time to bring full power back, which could be affected by no. of reactors, engines and engineering skill of captain/officers.
Title: Re: C# Suggestions
Post by: TMaekler on July 13, 2021, 07:29:47 AM
Fleet movements on a map are best visualised by dots and lines. Where is the ship now compared to where it has been 15, 30, 45 minutes ago. Based on that one can develop strategies and tactics. I was wondering if we could get lines between waypoints. Maybe lines with directional indicators? I think it would be an interesting addition for pictures used in AARs.
Title: Re: C# Suggestions
Post by: serger on July 13, 2021, 09:11:45 AM
A suggestion, that cannot be implemented easily, and I don't think it will face some enthusiasm, yet... you never know.

A thing that is even more disbelievable for me, than a linear laws of cost and so on from the previous my suggestion - is crew needs.

Now we have very strange situation, where nearly barebone freighter (1 standart hold, 1 bay, 4 low-tech commercial engines and 1 large fuel tank) requires 73 of crew members, most of them for engine support. Basic refuelling module requires 20 of crew members alone, so a tanker will eat even more human souls.

Large modern seafaring freighters and tankers usually have crews less then 10 men. The biggest ones - from 10 to 50 men security personnel including. They require no more then several men to support their giant engines.
What are doing those tens of space mariners for every standart commercial engine in Aurora?

It's not just about engines - some other component types are even more strange in this aspect.

So I think it will be great to revise in some future version all crew needs for components to drastically reduce both commercial and military crew needs aside of such components as luxury passenger accommodations, diplomacy modules and so on, that are really personnel-devouring by their inevitable nature.
Title: Re: C# Suggestions
Post by: Droll on July 13, 2021, 09:57:54 AM
A suggestion, that cannot be implemented easily, and I don't think it will face some enthusiasm, yet... you never know.

A thing that is even more disbelievable for me, than a linear laws of cost and so on from the previous my suggestion - is crew needs.

Now we have very strange situation, where nearly barebone freighter (1 standart hold, 1 bay, 4 low-tech commercial engines and 1 large fuel tank) requires 73 of crew members, most of them for engine support. Basic refuelling module requires 20 of crew members alone, so a tanker will eat even more human souls.

Large modern seafaring freighters and tankers usually have crews less then 10 men. The biggest ones - from 10 to 50 men security personnel including. They require no more then several men to support their giant engines.
What are doing those tens of space mariners for every standart commercial engine in Aurora?

It's not just about engines - some other component types are even more strange in this aspect.

So I think it will be great to revise in some future version all crew needs for components to drastically reduce both commercial and military crew needs aside of such components as luxury passenger accommodations, diplomacy modules and so on, that are really personnel-devouring by their inevitable nature.

Well these are deep space vessels so I understand to some extent why the engines need more crew. IMO components like reactors should need more crew and beam weapons should need a lot less crew.

For me its more important to maintain the balance between the crew requirements of various ship types. As it stands, freighters/tankers need much less crew than warships despite being much larger than them, this is good.

My main problem occurs with respect to missile warships/beam warships. I find it really weird how missiles require so much less crew than beam weapons - my 21,600 ton missile cruiser which does not use box launchers and even has it's own self-defense beam weapons (15cm particle lance and gauss PD) still has less crew (525) than my beam focused 13,930 ton light cruiser (533).
Title: Re: C# Suggestions
Post by: serger on July 13, 2021, 10:20:36 AM
Well these are deep space vessels so I understand to some extent why the engines need more crew. IMO components like reactors should need more crew and beam weapons should need a lot less crew.

I'm not going to say that beam weapons should need more crew, but... what are you supposing to do with shipboard reactor? Houl nuclear fuel into it's burner with shovels? Rake slags out with pinch-bars? Repair with hammers and tape?

Really, the bigger and the more complex some mechanism is - usually the less you can do with it ouside of good repair facility. Yet shipboard reactor is especially the thing you are supposed to watch (1-2 operators, no more, if it's not semi-experimental model that needs more research) and don't ever touch... even - and rather especially - when it needs repair.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 13, 2021, 11:41:53 AM
1. Make Build Points / Wealth Cost for all components square rooted from their sizes (the same as Research Points now) instead of linear.

Why? The change to component RP made good sense, but I don't understand how this makes sense. If a component is 10x larger, it should also take 10x more material to build, yes? Obviously there are many possible complications to that, but for a simple model linear makes the most sense.

Quote
2. Add a modifier to Hit Chance, square rooted from the target size (with x1 point at 1000 tons as a natural watershed between spacecraft and starships).

I don't think this makes sense either. Given that beam combat takes place at ranges of 10,000s or 100,000s of km, the size of a ship is a rounding error at most in accuracy calculations. Even something like a Star Wars Star Destroyer or MC Cruiser which is ~1 km in size is a fraction of a fraction of a %CTH compared to the effect of such long range.

Allow for ships to power down their engines, to reduce their thermal signature massively at the expense of having access to passive sensors only, no fire control, shields or weapons during this state. Possibly including a time to bring full power back, which could be affected by no. of reactors, engines and engineering skill of captain/officers.

We can already do this by controlling fleet speeds. The minimum thermal signature is 5% of the ship size in HS (or 1/1000 the tonnage) which is due to waste heat emissions (which corresponds to a speed of 50 km/s). For a 10,000-ton ship this is a signature of 10 which is fairly difficult to detect. Not sure why I would want to do the same thing but at the cost of losing engines, sensors, weapons, etc. in the process.

A suggestion, that cannot be implemented easily, and I don't think it will face some enthusiasm, yet... you never know.

I think we can all agree that crew needs could be rebalanced, but no two of us will agree on how much or in which direction.  ;)

For example I don't agree that having only 1-2 crew to run a giant nuclear engine makes sense...a real-life nuclear reactor does have as much automation as possible but still requires many more than 1-2 people to operate and monitor, this is very different from a wet-navy cargo hauler. They may not be shoveling nuclear coal into the boiler, so to speak, but there are many ancillary tasks and monitoring duties to run such a thing. However obviously this can depend a lot on RP, for example if one's RP culture doesn't care much about engine safety then maybe just 1-2 people to monitor the system and tell the captain when the engine is inevitably about to blow up makes more sense. On the other hand, one might want to RP that TN tech is quite complicated and requires even more crew to operate.

This is why I say no two will agree. I think the current approach is a reasonable balance, 73 crew for a 35,000-ton container ship may not be accurate but it is much less than the crew needed for a military ship of similar size, which I think is the most salient detail. It is not hard I think to RP the crew size however you want to, since freighters and other commercial ships should use "conscript" crews anyways so the actual effect on trained crew numbers is nonexistent.  :)

My main problem occurs with respect to missile warships/beam warships. I find it really weird how missiles require so much less crew than beam weapons - my 21,600 ton missile cruiser which does not use box launchers and even has it's own self-defense beam weapons (15cm particle lance and gauss PD) still has less crew (525) than my beam focused 13,930 ton light cruiser (533).

This one I agree with, although it is a matter of opinion as I said. However I do find it hard to believe that even a single-shot 49-ton 10cm railgun requires 3 crew to operate. It is maybe not unbelievable but it does make my dreams of tiny one-man beam fighters impossible to achieve. With Gauss cannons the two smallest sizes have only a 1-man requirement but this is such a poor weapon...anyways I digress.
Title: Re: C# Suggestions
Post by: Andrew on July 13, 2021, 11:50:46 AM
Why encourage small ships? I prefer large ships so a move to favour smaller ships would be a bad idea from my point of view . Larger ships are in mu opiniom more realistic. Of course prefering the use of small ships is an equally valid opinion
Title: Re: C# Suggestions
Post by: serger on July 13, 2021, 12:50:35 PM
1. Make Build Points / Wealth Cost for all components square rooted from their sizes (the same as Research Points now) instead of linear.

Why? The change to component RP made good sense, but I don't understand how this makes sense. If a component is 10x larger, it should also take 10x more material to build, yes? Obviously there are many possible complications to that, but for a simple model linear makes the most sense.

Material - yes, operations time - absolutely no.
Look at real factories and shipyards production stats.

And, aside of disbelieve reduction - there are players, that are complaining, that large ships are way too slow-building, and, in the same time, small ships are out of yards the next week from the order. That's obviously not very playable (too much waiting on the one shoulder - too much micro on the opposite shoulder) as well as absolutely not realistic.

I don't think this makes sense either. Given that beam combat takes place at ranges of 10,000s or 100,000s of km, the size of a ship is a rounding error at most in accuracy calculations. Even something like a Star Wars Star Destroyer or MC Cruiser which is ~1 km in size is a fraction of a fraction of a %CTH compared to the effect of such long range.

Cross section is cross section even if it's close to rounding error and there is absolutely no rounding error, when an impact is closing.
Just believe if you are not a specialist in relevant field - and you are not, obviously.
(My military training specialization - however second-grade and distant in time - is yet radio- and fire control systems and procedures, AA missile systems including, and I'm very familiar with math, physics, electronics and sensors aside of military training time.)
Title: Re: C# Suggestions
Post by: serger on July 13, 2021, 12:53:50 PM
Why encourage small ships?

To balance other part of my suggestion, which is favoring big ships.
(Again, aside from realistics and disbelieve aspects.)
Title: Re: C# Suggestions
Post by: TMaekler on July 13, 2021, 02:36:44 PM
QoL feature: Viewing and Editing text messages send from fleets to the log  :D
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 13, 2021, 03:11:46 PM
Material - yes, operations time - absolutely no.
Look at real factories and shipyards production stats.

So in that case, it sounds like a more reasonable approach would be to have build time and cost decoupled? On the factories side (pre-building components) I'm not sure how this would work since construction doesn't take place on a per-factory basis in Aurora, only as a fraction of aggregate capacity.

On the shipyards side however, the build rate is linear with shipyard size as a+bx where 'a' and 'b' depend on tech level, so build time for large ships does increase somewhat (due to the 'a' factor) but it is not as if a ship 10x larger takes 10x longer to build - unless you are building both out of the same shipyard (which is inefficient, again due to the 'a' factor, compared to building the smaller ship at a properly-sized SY with 10x slipways). In this case I think the difference between BP/material cost and build time is already reasonable, bigger ships should take longer to build (check), but it should not be linear with size (check), and a balance between bigger yards and more slipways is reached (check).

Quote
Cross section is cross section even if it's close to rounding error and there is absolutely no rounding error, when an impact is closing.
Just believe if you are not a specialist in relevant field - and you are not, obviously.
(My military training specialization - however second-grade and distant in time - is yet radio- and fire control systems and procedures, AA missile systems including, and I'm very familiar with math, physics, electronics and sensors aside of military training time.)

I'm not denying the physics of cross section, and I don't mean to cast any doubt on anyone's experience, military or otherwise, which might be relevant to the discussion at hand or any other - and to be blunt I would thank you and anyone else to take a similar approach. It doesn't benefit the discussion in this thread to dismiss other perspectives on the basis of perceived expertise or lack thereof.

What I am trying to say is that in a game like Aurora with such extreme combat ranges and speeds, I don't think the size of the target is an appreciable consideration in comparison. For example I would imagine the inertialess evasive maneuvers all ships are surely executing have a much greater effect, as a ship suddenly firing an inertialess thruster and displacing 100s if not 1000s of km from where it was a second ago would have a much greater effect on accuracy than whether the ship is 100m or 150m in length. And yet, my BFCs can still achieve high accuracy under such conditions, so I have no trouble at all believing that my science-fiction weapons can have the precision to hit ships of different sizes equally well.

While I certainly understand an interest in realism, it is important to ask "realistic compared to what?" as there is a salient difference between "realism" and "believability" or perhaps a better term is self-consistency. Aurora is just not a game to replicate modern naval or air combat mechanics in. It is better to have simple mechanics which are clear in how they function, which the player can then layer their own RP story on top of, instead of trying to tweak mechanics to be "more realistic" in a sci-fi game with magic super-minerals and inertialess spaceships.  :)
Title: Re: C# Suggestions
Post by: serger on July 13, 2021, 10:38:29 PM
Material - yes, operations time - absolutely no.
Look at real factories and shipyards production stats.

So in that case, it sounds like a more reasonable approach would be to have build time and cost decoupled?

Nope.
Main material cost (TN minerals) is already paid for (separately) in Aurora, and a cost of building (from those materials) isn't and would not be coupled strictly with needed materials cost.

On the shipyards side however, the build rate is linear with shipyard size as a+bx

Nevertheless, what I said above remains as it is.
To fix it with only SY mechanics change - is to fix half a problem with approximately the same time spent and make model curve to one side.
To fix it with component cost mechanics change (regarless of being produced by SYs or factories of any type) - is to fix a problem itself with approximately the same time spent and more consistent model as a result.

I'm not denying the physics of cross section
...
so I have no trouble at all believing that my science-fiction weapons can have the precision to hit ships of different sizes equally well.

Well, you are not denying the physics of cross section in the first string and you are completely and absolutely denying the physics of cross section in the second string.

The only case, where you can forget about cross section of target - is when your convex impact's cross section of guaranteed destruction is bigger then a cross section of convex target by an order of magnitude and, in the same time, your target lock is reliable irrespective of target's cross section. That is, if your gun is tossing 10-kilometer black holes at 1-kilometer ship and your target has absolutely no chance to hide itself in noise even for microsecond - well, cross section will be irrelevant.
That's absolutely not the case for Aurora combat model.

While I certainly understand an interest in realism, it is important to ask "realistic compared to what?" as there is a salient difference between "realism" and "believability" or perhaps a better term is self-consistency.

Yep.
I think my suggestion will make Aurora more realistic, more believable and more self-consistent for the same time.
Because for missiles velocity in Aurora is a factor, and ships are now suddenly not from the same universe.
Title: Re: C# Suggestions
Post by: serger on July 13, 2021, 10:51:54 PM
P.S.
Just for example.
Production time of average modern fighter (smth about 0.02kt) is only about 2 or 3 times shorter then building time of 100kt supercarrier.
Compare to Aurora Build Time for the same scope of sizes.
Title: Re: C# Suggestions
Post by: serger on July 14, 2021, 12:30:36 AM
Because for missiles velocity in Aurora is a factor, and ships are now suddenly not from the same universe.

My brain is gone some other universe himself with this sentence.
I'll try to explain later, possibly with some math and pictures.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 14, 2021, 12:37:45 AM
To fix it with component cost mechanics change (regarless of being produced by SYs or factories of any type) - is to fix a problem itself with approximately the same time spent and more consistent model as a result.

This brings me back to the point - I don't understand how this proposed model is at all consistent.

In general, for most components the cost in minerals scales proportionally with size. This makes sense. If I build a 50-ton component, I need 50 tons of materials. If I build a 500-ton component, I need 500 tons of materials. Granted, in Aurora one ton of component is not equal to one ton of minerals - I think we can assume that a large amount of cheap, conventional materials are used e.g. steel, aluminum, carbon-fiber, etc. However this basic relationship makes sense and is entirely consistent.

Quote
Well, you are not denying the physics of cross section in the first string and you are completely and absolutely denying the physics of cross section in the second string.

Denying - not at all. My statement is that I don't think target cross section is relevant because of the other factors I mentioned coupled with the hand-waving of TN technology.

I can understand the concept of cross section perfectly fine, and at the same time believe that the fire controls and weapons in Aurora can have sufficient precision that cross section effects are much less important, even negligible, compared to extreme range, speed, evasion, and so forth which characterizes the Aurora universe.

We could by similar tokens, for example, say that beam dispersion should be a mechanic, and the damage profile of beam weapons should become more spread out at longer ranges. However, this is needlessly complex and it is not difficult to believe or RP that our Aurora TN tech can focus a beam onto an area of ~1 m^2 at 100,000 km ranges. Anyone who works with beam optics of any sort will tell you that this is utterly impossible - with modern technology or anything analogous. However with Aurora's TN tech this is not a problem, or at least it does not have to be unless one's RP setting demands it.

I think at this point the best course is to agree to disagree, as it is clear we do not have any disagreements on physics but rather RP considerations, and it is of course useless to argue RP considerations.

Quote
Because for missiles velocity in Aurora is a factor, and ships are now suddenly not from the same universe.

Once again I do not understand this statement. Velocity is a factor for both beam and missile weapons, and ships and missiles broadly are subject to the same physics in Aurora (however oversimplified they may be) at least in terms of propulsion.

I see you've posted below so I can wait for the brain to return to this universe.  ;)

P.S.
Just for example.
Production time of average modern fighter (smth about 0.02kt) is only about 2 or 3 times shorter then building time of 100kt supercarrier.
Compare to Aurora Build Time for the same scope of sizes.

A quick Google search reveals the following:
For a F-35A the required amount of labor is around 40,000 man-hours, as of 2017/2018. Of course this has likely decreased since then but it is a good rough number.
For a Nimitz-class CVN, 40 million man-hours are required, a factor of 1,000x greater. The new Ford class seems to be trending toward a similar figure with greater complexity balanced by improvements in shipbuilding in recent decades.
In real life, the difference is that far more people can work on a CVN at any one time than can work on a fighter plane - the factor of 2-3 times in real time from start to finish is due to this factor.

Further checking suggests that the cost of a fighter jet is around $80m while the Nimitz carriers were around $9b, roughly a factor of 100, which in my experience broadly correlates to how cost differences are between such disparate classes in Aurora, roughly, although of course Aurora fighters are ~0.2 kt, not ~0.02 kt.

It seems to be that mechanically, the "issue" is that fighter factories are much more efficient than shipyards because they can operate as an aggregate unit. Something similar to how GFTFs work would probably be more reasonable if the goal is to model real-life production more closely. I would not be opposed to such a change but I do worry it could have similar issues as the current GFTFs which people have complained about, where building something of larger size/cost can take several years due to only using one facility per task.

In any case, to bring it back around - it seems that the issue has more to do with the mechanic of using aggregate resources to build components, fighters, etc. and not with the mechanics of BP/mineral costs or shipyards. In this case if a change is needed it would be to limit or eliminate the use of aggregate resources for components, fighters, etc. and to leave cost and shipyard mechanics more or less as they are. Of course this change would introduce additional gameplay complexity and possibly micromanagement, so whether it should be done is open to question, but certainly I can readily see benefits to that complexity in terms of gameplay decisions so there are merits to the idea.
Title: Re: C# Suggestions
Post by: serger on July 14, 2021, 05:10:23 AM
In general, for most components the cost in minerals scales proportionally with size.

I'm not about the cost in minerals, I'm about the cost in build points.

I can understand the concept of cross section perfectly fine, and at the same time believe that the fire controls and weapons in Aurora can have sufficient precision that cross section effects are much less important, even negligible, compared to extreme range, speed, evasion, and so forth which characterizes the Aurora universe.

Yet the basics of cross section concept is that range and speed are completely incapable to negate target's cross section effect. The only thing that IS capable to negate target's cross section - is impact's cross section. But in Aurora our damage model is inconsistent with a supposition, that impact's cross section is much bigger then target's cross section. While impact's cross section is less then (or comparable to) target's cross section - range and speed are only multipliers, relative to target's cross section in ANY equation of hit chance (well, higher math is about stochastic distributions, not sections, but it's only difference is that distributions are not plain, all other factors remaining nearly the same).

You can move your target within millions of km2 section of probable positions - and yet a target with 1m2 cross section will be still 100 times less likely to be hit comparing to a target with 100m2 cross section with the same cross section of probable positions (that is speed and time), if you are trying to hit it with an impact, that is less then 1m2. Your hit chance may become astronomically low, yet a target with 1m2 cross section will remain still 100 times less likely to be hit comparing to a target with 100m2 cross section. Your hit chance may become rounding to zero with your processing system, but it's irrelevant to those situations, where you have observable (and so not rounding to zero) hit chances.

Anyone who works with beam optics of any sort will tell you that this is utterly impossible

That's why my personal lore is that in Aurora combat space is a projective 2-dimensional space with compressed effective distances (i.e. Aether).
An alternative solution is to rename all relevant tech and branch names throughout the DB, but it's tough, while projective space lore is easy and amusing.

Though no math that I can imagine will negate cross section effect. It's much more fundamentally rooted concept - it cannot be outflanked by some imagination I can do, it have to be just "deunderstanded", and I just cannot do such a thing.

A quick Google search reveals the following:
For a F-35A the required amount of labor is around 40,000 man-hours, as of 2017/2018. Of course this has likely decreased since then but it is a good rough number.
For a Nimitz-class CVN, 40 million man-hours are required, a factor of 1,000x greater.

That's very different workhours - most of SY works are drastically more robust, needs more unskilled workforce (you can see it with your numbers - 1000 times more WF and still only 100 times more in wealth, and it's with scale effect). So what we have to balance - is some abstracted BPs.

It will open also a way to model scale effect with cycled operations (serial mass production).

It seems to be that mechanically, the "issue" is that fighter factories are much more efficient than shipyards because they can operate as an aggregate unit. Something similar to how GFTFs work would probably be more reasonable if the goal is to model real-life production more closely.

That's really very close problem: the same as with fighters vs warships we have a swing between nearly momentary start of production for small formations (so you have to remember to manually delay your production or stockpiles every time, if you want to RP, and if you are not - it will be a mess of forgotten tasks and stopped production), while bigger ones (like STO guns) are disproportionally slow and costly. With linear law for BP it will be nearly impossible to fix this - we'll have to jump from one shoulder of this swing to the opposite inevitably. With slower BP general law (smth like square root) it will be possible to easily fix the second end of this problem in the next iteration - by adding preliminary operations (~building prototypes and production lines as an abstracted, automated, yet tangible background). Thereafter we'll have a combination of not-so-slow build time for small-number large-scale objects and in the same time a slow start for serial mass production. It will be more consistent (one cost law for any production type) and much more player-friendly (united pools of industrial facilities without unnerving too-quick-ending small tasks).
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 14, 2021, 11:42:12 AM
words about cross section
Quote
That's why my personal lore is that in Aurora combat space is a projective 2-dimensional space with compressed effective distances (i.e. Aether).

This amuses me, because on one hand you say there is no possible physics handwaving that could convince you (personally) to ignore cross sections, but you have no problem personally handwaving beam dispersion.

To me this is the opposite, because beam dispersion under present physical understanding has an absolute lower limit (tied to caliber) which guarantees 100x to 1000x divergence - and this is a lower limit! However it is easy to handwave with TN tech and claim this limit is eliminated by TN magic.

This is why I say:
Quote
I think at this point the best course is to agree to disagree, as it is clear we do not have any disagreements on physics but rather RP considerations, and it is of course useless to argue RP considerations.

The choice of which "real" physics we do or do not handwave becomes intractible as RP is by nature inarguable.  :)

Quote
That's really very close problem: the same as with fighters vs warships we have a swing between nearly momentary start of production for small formations (so you have to remember to manually delay your production or stockpiles every time, if you want to RP, and if you are not - it will be a mess of forgotten tasks and stopped production), while bigger ones (like STO guns) are disproportionally slow and costly. With linear law for BP it will be nearly impossible to fix this - we'll have to jump from one shoulder of this swing to the opposite inevitably. With slower BP general law (smth like square root) it will be possible to easily fix the second end of this problem in the next iteration - by adding preliminary operations (~building prototypes and production lines as an abstracted, automated, yet tangible background). Thereafter we'll have a combination of not-so-slow build time for small-number large-scale objects and in the same time a slow start for serial mass production. It will be more consistent (one cost law for any production type) and much more player-friendly (united pools of industrial facilities without unnerving too-quick-ending small tasks).

I'm not sure having sqrt() build cost/time will work as neatly when turning back to the shipyards part of the expression. At the least a significant revision of shipyard build time mechanics would be needed to retain a similar balance to what we have now which is fairly effective, as previously discussed.

There's also the fact that the current linear BP cost is a fairly good model for most of the spectrum, e.g. the difference in cost between a 100-kt CV and a 10-kt CG is a factor of 10, which is fairly close to what you see in the present day. The linear costs really only breaks down for the "edge case" of real-world fighters, and in Aurora our space fighters are much larger than modern-day jet fighters so this is not really a problem within Aurora-space.

Thus I think probably a better approach would be to rework fighter factories, so that the mechanics are otherwise kept consistent (as presently they work fine in most areas) but fighter build times can be made more believable. Something like for example dedicated production lines, similar to shipyards but with fighter factories, would be interesting. For example such a system could involve a new tab or a new category on the shipyards tab, where the player groups a number of fighter factories together as a production line and assigns a particular class of fighters to be built. This would allow for a retooling mechanic, representing the lead time to convert for new construction, and limit build speeds for single fighter classes while production for a large number of fighters and classes keeps roughly the same balance. As a bonus these lines could also be used to do refits - fighter refits are a much-requested feature so this would be a great bonus.

This leaves the issue of component and space station build times, but I think the former can be left as it is since usually some measure of bulk production happens which abstracts the problem and in any case it is consistent with how factories work presently, and the latter I think in practice works out reasonably even if it could be exploited in the edge cases.
Title: Re: C# Suggestions
Post by: Droll on July 14, 2021, 11:45:31 AM
Thus I think probably a better approach would be to rework fighter factories, so that the mechanics are otherwise kept consistent (as presently they work fine in most areas) but fighter build times can be made more believable. Something like for example dedicated production lines, similar to shipyards but with fighter factories, would be interesting. For example such a system could involve a new tab or a new category on the shipyards tab, where the player groups a number of fighter factories together as a production line and assigns a particular class of fighters to be built. This would allow for a retooling mechanic, representing the lead time to convert for new construction, and limit build speeds for single fighter classes while production for a large number of fighters and classes keeps roughly the same balance. As a bonus these lines could also be used to do refits - fighter refits are a much-requested feature so this would be a great bonus.

Sounds slightly like equipment production in HOI IV. Would be interesting to see something similar maybe for ground unit construction as opposed to a simple aggregation.
Title: Re: C# Suggestions
Post by: Borealis4x on July 14, 2021, 11:52:05 AM
I've suggested this a lot, but I'd still like the ability to make more custom beam weapons by choosing how large each component in the beam is like with Missiles. I'd do away with spinal tech, power plants, and focal sizes and just let the player make as big a gun as they want.

I'd rather have one or two very large guns for my biggest ship than a dozen or so smaller ones.
Title: Re: C# Suggestions
Post by: serger on July 14, 2021, 12:42:16 PM
This amuses me, because on one hand you say there is no possible physics handwaving that could convince you (personally) to ignore cross sections, but you have no problem personally handwaving beam dispersion.

Yep, I have no problem with consistent, however intricate, explanation that is just reducing effective distances, and I have big problems with your explanation that is based on obvious (for me) error and I cannot build even partly consistent fix for this error.

To me this is the opposite, because beam dispersion under present physical understanding has an absolute lower limit (tied to caliber) which guarantees 100x to 1000x divergence - and this is a lower limit! However it is easy to handwave with TN tech and claim this limit is eliminated by TN magic.

Again, it can be easy for some player, that is not good with math because math error will not be obvious for them, yet it's not easy for me - I'll see an error and I will not be able to unsee it. (And it was not an elimination, it was a leveling. The limit is here, the same Aether space limit is there, but all ranges in Aether are much, much smaller, so when you see 1mkm distance - it's 1mkm distance of our space, and not of Aether space - it's much lesser distance there, and so much lesser divergence.)
Title: Re: C# Suggestions
Post by: TMaekler on July 15, 2021, 12:32:37 AM
Linking map labels to a system - so the moment you move the system around, all attached labels move with it  :o 8) 8)
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 15, 2021, 04:04:56 AM
P.S.
Just for example.
Production time of average modern fighter (smth about 0.02kt) is only about 2 or 3 times shorter then building time of 100kt supercarrier.
Compare to Aurora Build Time for the same scope of sizes.

In Aurora smaller ships ARE faster to build per population and minerals put into Shipyard construction.

10 slipways of 1000t will produce a total of 2400 BP versus one shipyard of 10.000t has 600 BP. It takes the same amount of minerals and population to run both facilities. So in practice small ships already build allot faster than large ships. You might build a larger ship faster per ton but compared to a singular ship, but in total small ships outproduce large ships with quite a margin.

Building allot of small ships can be a perfectly good way to ruin yourself economically but is quite a viable strategy during a war where building super large ships will seem slow in comparison.
Title: Re: C# Suggestions
Post by: serger on July 15, 2021, 04:11:47 AM
In Aurora smaller ships ARE faster to build per population and minerals put into Shipyard construction.

That IS a part of problem I have tried to explain.
Though already lost a hope to succeed.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 15, 2021, 05:16:55 AM
In Aurora smaller ships ARE faster to build per population and minerals put into Shipyard construction.

That IS a part of problem I have tried to explain.
Though already lost a hope to succeed.

To be honest I think the current method are pretty realistic to be honest... a modern 10.000t ship will take roughly 4 years to build and a 100.000t super carrier will take roughly 12 years to build. In Aurora the same rough difference is exactly the same. If a 10.000t ship cost 1/10 that of a 100.000t ship then the difference in time built is 4 years for the 10.000t and 10 years for the 100.000t ship.

To be honest I don't see a problem with this method at all. As larger ships are way more efficient per ton and you are likely limited to a certain amount of ship to maintain anyway then production efficiency is not always the most important thing. If you build too small ships and build too many of them you can often end up with too many ships and drag down your economy. Instead you build larger ships over a larger timeframe and get more efficient ships for less overall cost and maintenance over time.

The fact that you can build 5.7 times more BP of 1000t ships rather than 100.000t ships is not a problem and is quite realistic too in general.
Title: Re: C# Suggestions
Post by: QuakeIV on July 16, 2021, 01:44:32 AM
Generally larger ships dont have nearly as much complexity per ton.
Title: Re: C# Suggestions
Post by: TMaekler on July 16, 2021, 07:30:06 AM
Hide Fleets in Orbit - I think that idea could be expanded. Thinking of making it individual per fleet. The option then just toggles the view on or off (on means check the fleet-individual setting and apply them - off means the fleets are shown all as they are now).

There are fleets that I would like to know about if they are stationed in orbit of a planet - for example cargo/fuel/troop fleets without an actual mission. So when they are orbital the visible name could indicate to me that it is without any orders. But whilst this fleet is underway I don't care much about it - so it simply could be a moving dot.

On the other hand any warship fleet whilst stationed in orbit I don't really care about its name or sensor range. So turn them off. But whilst they are underway I would very much like to know which dot is what. So show the name.

So I would like to have this "show fleet" - "show name" dependent upon the settings of each fleet rather than having them visible always or not at all when in orbit around a planet.
Title: Re: C# Suggestions
Post by: TMaekler on July 19, 2021, 12:46:03 AM
Skip Lagrange Point: If a ship is on a cycle move order and the next order is to move to a Lagrange Point the game should check if the distance to the LP and the distance to the following destination is really shorter than the direct route to the following destination. Due to orbital mechanics it can happen that the direct distance becomes shorter. Would be nice if that could be checked by the game somehow and those LP moves be auto-skipped. At least for cycle moves I think this would make sense.
Title: Re: C# Suggestions
Post by: Borealis4x on July 23, 2021, 09:48:20 PM
I think ground support fighters should be built as ground equipment instead of as space fighters.

It would be less time-consuming by having them baked into a formation to support from the start like artillery is. Having them under the Army's direct command also makes more sense, as would their reduced size. The smallest GSF I could build was still 50-75 tons, and even that seems too large for a bomber/fighter meant to operate in atmosphere.

Only problem then is simulating GSFs operating from space-borne carriers. Perhaps they have to be loaded in to a new type of hangar and then provide air support automatically when its mothership is over a world?
Title: Re: C# Suggestions
Post by: Droll on July 23, 2021, 09:55:51 PM
I think ground support fighters should be built as ground equipment instead of as space fighters.

It would be less time-consuming by having them baked into a formation to support from the start like artillery is. Having them under the Army's direct command also makes more sense, as would their reduced size. The smallest GSF I could build was still 50-75 tons, and even that seems too large for a bomber/fighter meant to operate in atmosphere.

Only problem then is simulating GSFs operating from space-borne carriers. Perhaps they have to be loaded in to a new type of hangar and then provide air support automatically when its mothership is over a world?

No need for a new type of hangar, just use troop transport bays except they don't unload like the rest. Especially since if they're ground equipment like the rest of the army you shouldn't have to worry about MSP, repairs etc. normally associated with what is otherwise a fun sized spaceship. Don't forget that with spoilers you don't necessarily have all ground battles happening under a significant atmosphere, hell there might not be an atmosphere on the body at all.

Edit: Honestly I'm happy with what space fighters are, just that they seem too hard to micromanage at any significant number that can influence the tide of battle. You can probably manage about 60-100 fighters without going completely insane but those fighters are going up against 1000s of AA units, which limits their usefulness by a lot.
Title: Re: C# Suggestions
Post by: TMaekler on July 24, 2021, 10:57:22 AM
Adding the actual name of the fleet that sends a message can be helpful sometimes in distinguishing which fleet has sent the message - especially in systems with multiple fleets doing the same routine jobs. Or would it be possible if you could add some kind of variable that includes the name of the fleet in the message? So you can write the following message: "Fleet %fleetname% has entered the Hoth System" where %fleetname% is replaced with the actual name of the fleet?
Title: Re: C# Suggestions
Post by: Droll on July 26, 2021, 05:09:24 PM
Right now when terraforming bodies and removing gasses, when that gas is completely removed the game automatically sets the active gas to "none" to prevent issues. This is the desired outcome for every gas, except one:

Water vapor.

The problem I have happens with a lot of terraformers and/or small bodies where the terraform speed is too damn high. What this means that in every 5 day increment, all the water vapour gets sucked out of the atmosphere, which sets the active gas to "none", but I still want to drain the swamp which means that advancing the game becomes quite excruciating given how long draining a swamp usually takes.

My suggestion is to make water vapor an exception to the auto-stop terraforming rule so that terraformers can automatically remove the new vapor that is forming after the previous got sucked out.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 26, 2021, 05:34:38 PM
Right now when terraforming bodies and removing gasses, when that gas is completely removed the game automatically sets the active gas to "none" to prevent issues. This is the desired outcome for every gas, except one:

Water vapor.

The problem I have happens with a lot of terraformers and/or small bodies where the terraform speed is too damn high. What this means that in every 5 day increment, all the water vapour gets sucked out of the atmosphere, which sets the active gas to "none", but I still want to drain the swamp which means that advancing the game becomes quite excruciating given how long draining a swamp usually takes.

My suggestion is to make water vapor an exception to the auto-stop terraforming rule so that terraformers can automatically remove the new vapor that is forming after the previous got sucked out.

If an exception is not desirable, it should be sufficient to have the vapor/liquid/solid conversion step happen after the gas is added/removed, but before the terraformers check if the gas is removed. This should mean that additional water vapor is added to the atmosphere before the 'formers check if they should shut off, rather than after.
Title: Re: C# Suggestions
Post by: Garfunkel on July 26, 2021, 08:30:29 PM
That is a much better solution as otherwise there's a risk of killing colonists by causing a drought. Not enough water, CC cost goes up, people die.
Title: Re: C# Suggestions
Post by: QuakeIV on July 27, 2021, 12:19:19 AM
It may or may not be practical to re-order the calculations like that, if its easily possible thats definitely the right way to go however.

Would be kindof nice to be able to set a target surface water percentage though.  This would also be an exception but in my opinion a logical one.
Title: Re: C# Suggestions
Post by: Garfunkel on July 27, 2021, 04:36:53 AM
It may or may not be practical to re-order the calculations like that, if its easily possible thats definitely the right way to go however.

Would be kindof nice to be able to set a target surface water percentage though.  This would also be an exception but in my opinion a logical one.
Once Steve has the time to redo the terraforming interface, we'll hopefully get a "target atmosphere and water level" window and then just leave the TF stations to do their business.
Title: Re: C# Suggestions
Post by: Froggiest1982 on August 01, 2021, 07:35:46 PM
The Create Project under the Research Lab should be changed as the Create Project window is actually different. Furthermore, the Create Project window should also be accessible via the research screen.

I suggest the current Create Research button to be changed into Start Research (or project) and to add a new button called Create Project linked to the correct window.



CURRENT

(https://i.imgur.com/RmKN77u.png)



SUGGESTED

(https://i.imgur.com/OBJY3uX.png)


Eventually, I would still at least change the Create Research button into Start Research (or project) for clarity.
Title: Re: C# Suggestions
Post by: Elminster on August 02, 2021, 02:44:22 AM
Make the "Matching Scientists Only" checkbox checked as default.


In fact you always do this click, and then again when you don't have a matching scientist.
Title: Re: C# Suggestions
Post by: serger on August 02, 2021, 05:52:28 AM
Off-topic:

Current Russian naming scheme (that's on screenshot) looks rather funny for native Russian:

1) A lot of first names in diminutive forms (Pasha, Fedya, Jasha), some of them double diminutive (Boryenka, Stepka), and that's for the culture, that is nearly never using diminutives in official context, even to convey a pejorative sense - and that's the only sense in which diminutive forms are applicable in Russian aside of friendly/family context; it was really a norm up to XVIII century to use diminutives as a rank denotation (that is: a monarch using diminutives when referring to any of their subject; a nobleman - to a serf, etc.), yet it's a completely dead ancient norm.

2) Some surnames among/instead of given names (Petrov, Dmitreeva).

3) Strictly-feminitive surnames paired with strictly-male given names (the only way to approximate a Russian norms in Aurora naming scheme is to use male surname form only).

4) Non-Russian given names that are not and was not in use as popular foreign names in Russia (Marko, Derzhena).

5) Some orthographic mistakes (Shashenka instead of Sashenka, though it's intimate double diminutive inacceptible in official context too).

I'll edit and upload smth like "Russian, modern edition" naming scheme if you need it.
Title: Re: C# Suggestions
Post by: Platys51 on August 02, 2021, 02:28:58 PM
Suggestion:
Variable cargo space/cryo pods/ground troop transport.
Simply cargo space you could design as a component of variable size.
Would be especially useful for boarding pods, rescue fighters and RP. Its cost/HS could be that of whatever cargo space is next down. So, 26kt would have cost of 25kt + whatever extra kt would add rounded up while 200kt would have that of 125kt +75 extra rounded up.
Title: Re: C# Suggestions
Post by: Kiero on August 03, 2021, 02:26:13 AM
I would like to see another option (the those that are in Naval organization->Ship Overview->Ship Design Display tab) for "tankers":
"Refuel own Refueling Hub".
Title: Re: C# Suggestions
Post by: Blogaugis on August 03, 2021, 10:04:08 AM
Suggestion:
Variable cargo space/cryo pods/ground troop transport.
Simply cargo space you could design as a component of variable size.
Would be especially useful for boarding pods, rescue fighters and RP. Its cost/HS could be that of whatever cargo space is next down. So, 26kt would have cost of 25kt + whatever extra kt would add rounded up while 200kt would have that of 125kt +75 extra rounded up.
Add up to that, how about making engineering spaces, maintenance storage, fuel storage, cargo space, cryogenic and ground troop transport components design-able? I much prefer them to be able to design them (from the get-go, Conventional start) rather than research them. Making them design-able during conventional start could also allow us to play some interesting scenarios, set in home system as well.
Also... I do find it a bit odd with the ground troop transport component - I understand that the simple cargo space component is not really designed to be with full-fledged life support, but, do we really have to have a separate component for troop transport? We already have drop bays and boarding bays...
Title: Re: C# Suggestions
Post by: MasonMac on August 03, 2021, 11:33:02 AM
Instead of completely disabling shipping lines, would it be possible to just impose a cap on them? I would like to have the shipping lines upgrade their ships to be honest.
Title: Re: C# Suggestions
Post by: Elminster on August 03, 2021, 01:03:35 PM
Quote from: Blogaugis link=topic=10640. msg154051#msg154051 date=1628003048
Also. . .  I do find it a bit odd with the ground troop transport component - I understand that the simple cargo space component is not really designed to be with full-fledged life support, but, do we really have to have a separate component for troop transport?
I always think that the troop transport component also includes training facilities, briefing rooms, small maintenance equipment, even shooting ranges and gyms.  So the troops can perform some training and preparations during the voyages.
Title: Re: C# Suggestions
Post by: Blogaugis on August 03, 2021, 01:11:54 PM
I always think that the troop transport component also includes training facilities, briefing rooms, small maintenance equipment, even shooting ranges and gyms.  So the troops can perform some training and preparations during the voyages.
And it is made, so that the troops being transported actually retain their capability to be combat-effective...
Alright, I guess I can understand that.

Although... would cryogenic transport be able to... be a makeshift troop transport component, at least, in some instances?

I mean, do we really need so many different types of transport components? Can we simplify it from:
3+ (cryogenic, cargo, troop with boarding and drop) to 2+ (cargo not requiring a life support, cargo requiring life support with boarding and drop)?
Title: Re: C# Suggestions
Post by: Density on August 03, 2021, 01:29:20 PM
Also... I do find it a bit odd with the ground troop transport component - I understand that the simple cargo space component is not really designed to be with full-fledged life support, but, do we really have to have a separate component for troop transport? We already have drop bays and boarding bays...

The troop transport bay is cheaper and uses less displacement than the drop and boarding bays of the same size. Even if the player has all the varieties researched, they have the option to make cheap ship classes for moving garrisons and defensive troops. That is, ships that aren't overdesigned for their role in terms of speed, defenses, and the bay itself.

You may prefer less options in this regard, others prefer more.
Title: Re: C# Suggestions
Post by: Garfunkel on August 03, 2021, 10:52:21 PM
Yeah, agreed with Density here. I always make three different transports:

1. Slow and cheap garrison hauler that moves units from Earth to colonies during time of peace.
2. Big and armoured landing juggernaut that drops armoured regiments on enemy planets.
3. Fast and expensive assault shuttle that commits boarding actions.

And I could see situations where I have different varieties of those three as well. Troop transport modules also include life support and training facilities for the troops as Elminster said, so that they maintain their combat capability despite long voyages.

What I would like to see is emergency carry capability:

If a ship and/or fleet has both cargo capability and cryogenic capability, then it can carry ground units with some ratio between the two- this would allow for emergency transportation in early game or crisis situation, where the soldiers are shoved into cryo-pods like colonists are while all their gear is packed away in the cargo holds. The ship/fleet could not commit boarding or drop actions, only unloading that would take 2x the usual amount. That way you would still want to make purpose-built troop transports.

Instead of completely disabling shipping lines, would it be possible to just impose a cap on them? I would like to have the shipping lines upgrade their ships to be honest.
There are caps to them and they definitely do upgrade their ships. What sort of numbers are you seeing currently?
Title: Re: C# Suggestions
Post by: nuclearslurpee on August 03, 2021, 11:44:17 PM
I mean, do we really need so many different types of transport components? Can we simplify it from:
3+ (cryogenic, cargo, troop with boarding and drop) to 2+ (cargo not requiring a life support, cargo requiring life support with boarding and drop)?

In VB6 at least for some time, the boarding and drop capabilities were part of the same component, which led to fairly silly situations where full assault battalions were used to capture ships. Separating the two is much more reasonable in terms of the resulting behavior.

As far as cryogenic transport goes it would be rather tricky since the tonnage of a formation is not purely (or, depending on how you roleplay, even mostly) the tonnage of actual soldiers. Equipment, supplies, etc. are in my mind the majority of troop tonnage and a cryogenic module does not really make sense to reduce the transport size of a main battle tank for example. Overall I think the three variations we have are entirely suitable, really I just wish they weren't split into three techs as it makes designing troop transports in the early game a rather annoying process since there is not enough free RP to build every type without seriously compromising in another area.
Title: Re: C# Suggestions
Post by: nuclearslurpee on August 04, 2021, 12:01:41 AM
Apologies for double post, but I also have a suggestion which I think should be separated from the above discussion:

Currently, a number of quantities which scale with starting population at game start have hard limits beyond which they do not scale. The most obvious of these is research points and research labs which are both capped at 200,000 and 50 respectively (corresponding to 1.25b population). Similarly the number of starting officers is capped at, IIRC, 200 (where the default is 150 officers at 500m pop) which tends to be not enough at high populations with a lot of free BPs.

I would suggest that these and any other hard caps are removed and the scaling with population is directly proportional for all populations, possibly with a minimum for very low-pop starts.

While it is trivial for the player to change these quantities at game start, the bigger issue in my mind is the NPR balance. Additionally I think removing particularly the 50 Labs hard cap would help generated NPRs in the later game period remain competitive, as right now it is possible for the player to easily exceed the generated NPR starting tech levels once they have 75 or 100 labs and a few levels of RP boosting tech since new NPRs are still limited to 50 labs on spawning.

Of course players may still want to do e.g. 8b pop starts and the like, for which NPRs starting with 1.28 million RP might be a bit excessive, but I think it is best to enable the NPRs to scale effectively under a wide range of conditions and then trust the player to adjust the start as needed to reach their preferred balance (i.e., by starting with a smaller population and manually scaling up as desired themselves).
Title: Re: C# Suggestions
Post by: Kiero on August 04, 2021, 12:11:56 PM
An idea for a new feature:
The naming theme for ships. Created automatically from retained characters' names, after their death or retirement.
Title: Re: C# Suggestions
Post by: MasonMac on August 04, 2021, 01:10:38 PM
Yeah, agreed with Density here. I always make three different transports:

1. Slow and cheap garrison hauler that moves units from Earth to colonies during time of peace.
2. Big and armoured landing juggernaut that drops armoured regiments on enemy planets.
3. Fast and expensive assault shuttle that commits boarding actions.

And I could see situations where I have different varieties of those three as well. Troop transport modules also include life support and training facilities for the troops as Elminster said, so that they maintain their combat capability despite long voyages.

What I would like to see is emergency carry capability:

If a ship and/or fleet has both cargo capability and cryogenic capability, then it can carry ground units with some ratio between the two- this would allow for emergency transportation in early game or crisis situation, where the soldiers are shoved into cryo-pods like colonists are while all their gear is packed away in the cargo holds. The ship/fleet could not commit boarding or drop actions, only unloading that would take 2x the usual amount. That way you would still want to make purpose-built troop transports.

Instead of completely disabling shipping lines, would it be possible to just impose a cap on them? I would like to have the shipping lines upgrade their ships to be honest.
There are caps to them and they definitely do upgrade their ships. What sort of numbers are you seeing currently?

Ah, right now there are probably around 30+ civ ships in total?
Title: Re: C# Suggestions
Post by: Stormtrooper on August 04, 2021, 05:31:53 PM
Less of a suggestion, but more of a question: Steve, when do you plan to implement black holes, nebulae and genetics? At this point I'm literally obsessed with black holes, I want to see them so badly
Title: Re: C# Suggestions
Post by: Borealis4x on August 04, 2021, 05:35:54 PM
Suggestion:
Variable cargo space/cryo pods/ground troop transport.
Simply cargo space you could design as a component of variable size.
Would be especially useful for boarding pods, rescue fighters and RP. Its cost/HS could be that of whatever cargo space is next down. So, 26kt would have cost of 25kt + whatever extra kt would add rounded up while 200kt would have that of 125kt +75 extra rounded up.

Ehhh. Cargo space is it is cuz everything you haul other than minerals are multiples of 2500. If this was an options I'd probably just design that same sized cargo pods.

I also think its important to keep ground troops transport sizes defined as it helps guide totally nooby players figure out how large to make their forces. So having a defined 5000 size cargo bay means I make my base units 5000 tons each. It gives you something to go on from nothing.
Title: Re: C# Suggestions
Post by: Garfunkel on August 04, 2021, 08:00:12 PM
Ah, right now there are probably around 30+ civ ships in total?
Sorry but you're going to have to live with a few more until they start upgrading ships instead of buying new ones. But it won't get to hundreds per shipping line like it used to.
Title: Re: C# Suggestions
Post by: Elminster on August 05, 2021, 12:39:40 PM
It would be nice to have more control over maintenance production.
In the early game you have to build many maintenance facilities to support your ships. But later you have research to increase the production rate for maintenance. At some point it could be that you may have way more production than usage, which is eating through your minerals (especially Gallicite).

While you could stop production entirely, you can also easily forget about it and be out of maintenance entirely when needed.

I suggest an adjustable percentage value, so you can tune down the production during peace time and crank it up again when needed.
Title: Re: C# Suggestions
Post by: nuclearslurpee on August 05, 2021, 12:55:40 PM
It would be nice to have more control over maintenance production.
In the early game you have to build many maintenance facilities to support your ships. But later you have research to increase the production rate for maintenance. At some point it could be that you may have way more production than usage, which is eating through your minerals (especially Gallicite).

While you could stop production entirely, you can also easily forget about it and be out of maintenance entirely when needed.

I suggest an adjustable percentage value, so you can tune down the production during peace time and crank it up again when needed.

I would like to both second and third this, but cloning technology has not yet been implemented in Aurora so I can only second this.
Title: Re: C# Suggestions
Post by: Droll on August 05, 2021, 05:35:39 PM
It would be nice to have more control over maintenance production.
In the early game you have to build many maintenance facilities to support your ships. But later you have research to increase the production rate for maintenance. At some point it could be that you may have way more production than usage, which is eating through your minerals (especially Gallicite).

While you could stop production entirely, you can also easily forget about it and be out of maintenance entirely when needed.

I suggest an adjustable percentage value, so you can tune down the production during peace time and crank it up again when needed.

I would like to both second and third this, but cloning technology has not yet been implemented in Aurora so I can only second this.

I also like this, especially if you do the same for fuel (though admittedly less essential as very few components use raw sorium)
Title: Re: C# Suggestions
Post by: Froggiest1982 on August 05, 2021, 05:41:26 PM
It would be nice to have more control over maintenance production.
In the early game you have to build many maintenance facilities to support your ships. But later you have research to increase the production rate for maintenance. At some point it could be that you may have way more production than usage, which is eating through your minerals (especially Gallicite).

While you could stop production entirely, you can also easily forget about it and be out of maintenance entirely when needed.

I suggest an adjustable percentage value, so you can tune down the production during peace time and crank it up again when needed.

I would like to both second and third this, but cloning technology has not yet been implemented in Aurora so I can only second this.

I also like this, especially if you do the same for fuel (though admittedly less essential as very few components use raw sorium)

Agreed, I think that both Fuel and Maintenance should be handled in the production tab same as the Ordnance (on a dedicated dropdown menu).

Eventually, the Maintenance and Fuel start-stop buttons should be extended with a Factory one where when you stop, you are shutting down the production as it was in VB6, saving also workers that could be relocated elsewhere then. A cooldown restart would be also appreciated (again as it was already in VB6).
Title: Re: C# Suggestions
Post by: Droll on August 05, 2021, 09:41:43 PM
Eventually, the Maintenance and Fuel start-stop buttons should be extended with a Factory one where when you stop, you are shutting down the production as it was in VB6, saving also workers that could be relocated elsewhere then. A cooldown restart would be also appreciated (again as it was already in VB6).

This works well with the fuel refineries but is more difficult with maintenance facilities since they still have the function of maintaining military tonnage in orbit. Granted the same "problem" was in VB6 too but it's something to think about, shutting down MSP production doesn't necessarily make maintenance facilities idle.
Title: Re: C# Suggestions
Post by: nuclearslurpee on August 05, 2021, 10:19:59 PM
Fuel, as long as we're adding buttons we may as well, but I think it is less crucial since we can set a reserve of sorium which will not be converted to fuel. For MSP it is trickier since the minerals involved are a good deal more widely used than sorium.
Title: Re: C# Suggestions
Post by: Froggiest1982 on August 06, 2021, 11:02:12 PM
It may be said already, but starting to feel the need for a Standing Orders Template

Also, the more I think about it and the more I realize that being the same for essentially every race and ship, such templates could be exported, imported and shared through the entire database.

I think I could spare something like 100/200 clicks and repetitions.
Title: Re: C# Suggestions
Post by: Black on August 07, 2021, 07:09:29 AM
Can we get SM command to change field of the Ancient Constructs? I have 7 Constructs in my current game and 4 are Power and Propulsion and 2 are Sensors. And it is kind of disappointing.
Title: Re: C# Suggestions
Post by: Gabrote42 on August 07, 2021, 05:31:51 PM
Currently, a number of quantities which scale with starting population at game start have hard limits beyond which they do not scale. The most obvious of these is research points and research labs which are both capped at 200,000 and 50 respectively (corresponding to 1.25b population). Similarly the number of starting officers is capped at, IIRC, 200 (where the default is 150 officers at 500m pop) which tends to be not enough at high populations with a lot of free BPs.

I would suggest that these and any other hard caps are removed and the scaling with population is directly proportional for all populations, possibly with a minimum for very low-pop starts.

While it is trivial for the player to change these quantities at game start, the bigger issue in my mind is the NPR balance. Additionally I think removing particularly the 50 Labs hard cap would help generated NPRs in the later game period remain competitive, as right now it is possible for the player to easily exceed the generated NPR starting tech levels once they have 75 or 100 labs and a few levels of RP boosting tech since new NPRs are still limited to 50 labs on spawning.
[snip]
This needs to be hard doubleplussed in my opinion. I am sure there are a lot of people who can't take the micro of manning multiple player races and this would be great for them. While I don't want to dismiss the other suggestions I think this needs to be mentioned.
Title: Re: C# Suggestions
Post by: Droll on August 07, 2021, 08:06:21 PM
It may be said already, but starting to feel the need for a Standing Orders Template

Also, the more I think about it and the more I realize that being the same for essentially every race and ship, such templates could be exported, imported and shared through the entire database.

I think I could spare something like 100/200 clicks and repetitions.

This would be great for multi-class survey ships as you could swap out their geosurvey templates for gravsurvey templates and vice versa. A useful extension of this would be to have a default template, not unlike what ground formations have, that way you could spam out 10 geosurvey ships and they'd immediately get to work once built.
Title: Re: C# Suggestions
Post by: db48x on August 07, 2021, 09:49:02 PM
It’s always bothered me a little that ships in Aurora cannot predict the course of a planet and adjust their own heading to minimize the trip time, so I made a little toy program to see how hard it would be. Here’s a video of the result:

http://db48x.net/Aurora/four different ways of plotting a course in Aurora-2021-08-07_18.33.48.webm (http://db48x.net/Aurora/four%20different%20ways%20of%20plotting%20a%20course%20in%20Aurora-2021-08-07_18.33.48.webm)

(If anyone knows of a way to embed this in the post without uploading it to Youtube or Vimeo, let me know.)

The simplest thing to implement is what Aurora does; each ship simply heads directly towards the planet at every tick. These ships are shown in red, and as you can see they fall behind the planet and must catch up just as ships do in Aurora.

The next thing to do is make a simple measurement of the time it will take to reach the planet, then head for the place where the planet will be in that amount of time. These ships are shown in orange–red. Unfortunately this simple strategy overcompensates and causes the ships to get ahead of the planet before turning towards it.

Since neither of these strategies is amazing, perhaps we need something more sophisticated. A key observation is that we are trying to find an initial heading that minimizes the distance between the ship and the planet; ideally the ship should be zero pixels away from the planet in order to land.

We can easily search this space by considering the distance between the ship and planet at a grid of points in space, and finding the one that gets us the closest. These are the orange ships; you can see that they rarely find a heading that gets them close enough to land, so most of them miss. This is easy to write but rather imprecise in practice. Note that these ships only calculate their course once, on the frame that they are spawned.

For reference, here is a screenshot showing all the points that it considered; the coarseness of this grid is why the ships usually miss. Making the grid finer can make the ships miss less frequently, but at a higher runtime cost. Still, my toy prototype maintains 60fps…

(http://db48x.net/Aurora/Screenshot%20from%202021-08-07%2019-01-54.png)

To do better than this we can use a little calculus. Instead of considering points on a fixed–size grid that will always be either too coarse or too expensive, we should adjust the point based on the slope of the function we are minimizing. This search strategy is called “gradient descent”, and the white ships use it. You can see from the debug output that the search always stops once it gets within half a pixel of the planet, and that it usually only takes a couple of dozen steps to find this point. Occasionally it takes many more, but even so it doesn’t blow the frame budget. Like the grid search ships, these only need to calculate their course once.

I suggest that Aurora should have better navigation. My prototype shows that it is entirely feasible; I didn’t even have to implement gradient descent myself; I just used an open–source library for that.

However, I do want to point out that my prototype does have some flaws, which I have arranged not to show off in this video.

If the jump point is very near the orbit, then the gradient descent search goes a little off the rails. It still finds a good solution, but it can take seconds instead of milliseconds. That’s terrible in a 60fps game, but it would be completely unnoticeable in Aurora. Also, it’s probably just a bug in my code rather than an inherent problem with gradient descent.

One thing that is a problem with gradient descent is that sometimes it finds a solution in the past. These solutions only work if the ship and the planet both run backwards, which would be silly. The gradient descent algorithm just looks for minima of the function you give it, and this one has more than one of them. In fact, it has infinitely many since the angle wraps around. Mostly those aren’t a problem, though it is funny to see it pick an optimal heading of 16.622303 or −46.64971 radians. I’ve partly solved this problem with an exponential penalty for negative time values and with a better guess for the starting conditions for the search, but it isn’t perfect. I think that if I picked those initial conditions using a simple grid search (like the third type of ship uses), then it would go away entirely.

The third problem is that my collision detection just looks for ships that are within 1px of a planet. That usually works, but if the planet and ship are headed towards each other then they can move past each other between frames and the ship never lands. That’s easy to fix, I just didn’t do it. We’ll just pretend that the captain was napping and the crew didn’t want to wake him.

Another limitation is that I have not yet written the code to do these computations for moons, moons of moons, etc. This would be quite trivial to do for the first three algorithms, and should only be moderately annoying for the gradient descent search. For that one I have to actually compute the derivative of the distance function; luckily I don’t have to do that by hand.

I put my code on GitLab (https://gitlab.com/db48x/fuliginous-echinodon) in case any one is interested in taking a look or running it themselves.
Title: Re: C# Suggestions
Post by: nuclearslurpee on August 08, 2021, 12:06:05 AM
Some interesting work here. I do have a quick question: does your algorithm account for the fact that planetary/body motion in Aurora takes place only on the construction increments? It seems like that should make an algorithm much easier, since you can basically loop over a limited set of body positions instead of solving a problem in continual dimensional space.

This would require pathfinding to be aware of the time until the next increment, which I don't know if it currently is, but otherwise would be simpler and not require more complex algorithms. I think particularly this may be important as I doubt Steve wants to use other libraries to write his code for him, since Aurora is a coding hobby project as much as a game for him.
Title: Re: C# Suggestions
Post by: QuakeIV on August 08, 2021, 02:45:24 AM
There shouldnt be any actual need for a solver to calculate this.  Im pretty sure in particular given that the orbits are perfectly circular there is a calculable way to find the intercept without iterating.
Title: Re: C# Suggestions
Post by: Steve Walmsley on August 08, 2021, 09:12:06 AM
There shouldnt be any actual need for a solver to calculate this.  Im pretty sure in particular given that the orbits are perfectly circular there is a calculable way to find the intercept without iterating.

Funny you should make that post today :)

In Newtonian Aurora, I had a problem of a missile intercepting a ship from a billion kilometres away. Unfortunately, both were accelerating and both were burning fuel, which meant constant changes in mass and therefore rate of acceleration. After tackling the complex math, I hit on a much simpler solution. The missile guessed a direction, then plotted what happened. Based on that information, it made a better guess and then repeated until it picked the right course. No complex math and hit every time :)

I could write some code to calculate the intercept, even with the new eccentric orbits, but it would add processing time. I'm not sure how much without coding it, but movement is the already the largest time-sink. It would also require the necessary enthusiasm from me to solve a problem that isn't really a major issue.

In summary, the reason that ships don't intercept planets is not due to an inability to solve the problem, but rather a question of priority and enthusiasm.
Title: Re: C# Suggestions
Post by: Droll on August 08, 2021, 09:18:58 AM
There shouldnt be any actual need for a solver to calculate this.  Im pretty sure in particular given that the orbits are perfectly circular there is a calculable way to find the intercept without iterating.
The missile guessed a direction, then plotted what happened. Based on that information, it made a better guess and then repeated until it picked the right course. No complex math and hit every time :)

So your saying that the missile knows where it is, and also where it isn't.
Title: Re: C# Suggestions
Post by: serger on August 08, 2021, 11:43:19 AM
With new Eccentric Orbits - is it possible to show in Galactic Map an upper half of planet's circle in a colour of current CC and a lower half in a colour of max CC?
Title: Re: C# Suggestions
Post by: unkfester on August 08, 2021, 12:06:39 PM
quantum missiles
Title: Re: C# Suggestions
Post by: db48x on August 08, 2021, 12:50:15 PM
Some interesting work here. I do have a quick question: does your algorithm account for the fact that planetary/body motion in Aurora takes place only on the construction increments? It seems like that should make an algorithm much easier, since you can basically loop over a limited set of body positions instead of solving a problem in continual dimensional space.

This would require pathfinding to be aware of the time until the next increment, which I don't know if it currently is, but otherwise would be simpler and not require more complex algorithms. I think particularly this may be important as I doubt Steve wants to use other libraries to write his code for him, since Aurora is a coding hobby project as much as a game for him.

Thank you :)

I completely ignored that problem. In my program, the positions of objects are entirely computed based on the number of seconds since the program started up. I didn’t even add a way to pause the simulation!

Incidentally, since planetary motion is so cheap, I also suggest that it ought to be decoupled from the construction cycle.
Title: Re: C# Suggestions
Post by: db48x on August 08, 2021, 12:52:29 PM
There shouldnt be any actual need for a solver to calculate this.  Im pretty sure in particular given that the orbits are perfectly circular there is a calculable way to find the intercept without iterating.

I thought so too, at first. I spent some time over the last couple of months trying to find a closed–form solution with no luck. Of course that doesn’t mean that it doesn’t exist; I did discover how much calculus I had forgotten over the last 20 years. I would be quite willing to be proven wrong on that point!
Title: Re: C# Suggestions
Post by: db48x on August 08, 2021, 03:04:25 PM
There shouldnt be any actual need for a solver to calculate this.  Im pretty sure in particular given that the orbits are perfectly circular there is a calculable way to find the intercept without iterating.

Funny you should make that post today :)

In Newtonian Aurora, I had a problem of a missile intercepting a ship from a billion kilometres away. Unfortunately, both were accelerating and both were burning fuel, which meant constant changes in mass and therefore rate of acceleration. After tackling the complex math, I hit on a much simpler solution. The missile guessed a direction, then plotted what happened. Based on that information, it made a better guess and then repeated until it picked the right course. No complex math and hit every time :)

An interesting point. Should missiles even be able to take into account the fuel state of their target?

I could write some code to calculate the intercept, even with the new eccentric orbits, but it would add processing time. I'm not sure how much without coding it, but movement is the already the largest time-sink. It would also require the necessary enthusiasm from me to solve a problem that isn't really a major issue.

In summary, the reason that ships don't intercept planets is not due to an inability to solve the problem, but rather a question of priority and enthusiasm.

One good thing about doing the work to find the exact correct course is that it only needs to be done once, when you start working on a new order. It also gives you an exact time of arrival, so you could schedule a sub–pulse for exactly that time.
Title: Re: C# Suggestions
Post by: ISN on August 08, 2021, 03:08:50 PM
With the new changes to system generation, it would be particularly useful to have a "Redo system bodies" button in SM mode that reruns the entire system body generation process (unless there's already some way of doing this that I'm missing. I know you can just delete the system and explore the JP again, but you'll likely end up with a different star, which isn't always desirable, and using the "Create System" button to pick the star means you have to set up the JP connections to your other systems manually). Previously if I wanted to customize a system I would just add and remove bodies as desired. But with the new eccentricity rules, twin planets, and gas giant effects I feel it would be difficult to make by hand a system that fits in with the procedurally generated systems. For instance, if I want a system with a terrestrial planet thrown into an eccentric orbit by a gas giant, it would be much easier to simply rerun the process until I get what I want rather than try to design it manually. This button would be useful even if you don't care about the new system generation features, though: it would make generating the systems you want much easier in general.
Title: Re: C# Suggestions
Post by: serger on August 09, 2021, 07:50:22 AM
I have made some Ground Weapon tinkering sugestion in a separate thread (http://aurora2.pentarch.org/index.php?topic=12687.0), so posting this here as a note just in case that Steve will have someday a time and inspiration for.
Title: Re: C# Suggestions
Post by: TMaekler on August 09, 2021, 12:59:06 PM
Kyle added "current location" to the options for orders in Quasar4x. I think I would like to see that feature in C#-Aurora as well  ;D Very handy... ;)
Title: Re: C# Suggestions
Post by: TMaekler on August 10, 2021, 02:19:53 AM
I was wondering if there is a way for Steve to create some kind of automation for sub fleets. I am thinking along this line. Sending out an attack fleet that contains a fleet tanker set to refill the attack fleet constantly. Once that tanker goes below a certain % of its fuel it searches for a reachable refuel station, detaches its own sub fleet to refill at that refuel station, and auto returns to the attack fleet, and joins as a sub fleet, and continues refueling it. Possible?

Something similar for Deep Space Fuel Depots would be nice. At strategic points, I have placed Fuel Depots close to jump points at which certain fleets can refuel to extend their range. Usually cargo fleets. Those depots get drained over time and if they could generate a refuel request to certain fleets in the area to be restocked automatically when they get below a certain % of their capacity would be awesome.
Title: Re: C# Suggestions
Post by: db48x on August 10, 2021, 02:40:18 PM
For the new eccentric orbits, I suggest coloring the orbit of the selected body based on colony cost instead of the current table of numbers. You already have a mode for drawing the orbit of just one body. All you would need to add is one or more color schemes and a visible key. I suggest having a color scheme based on the absolute colony cost, so that going from 0.0 to a positive colony cost, as well as going above and below 2.0, is easy to see. I also suggest having a color scheme based on changes relative to the current colony cost which will emphasize changes for an orbit like Pluto’s where the orbit would be almost the same color all the way around.
Title: Re: C# Suggestions
Post by: idefelipe on August 13, 2021, 04:28:11 AM
Would it be possible for officers who are on a ship, but who are not the commanders, to add the accomplishments they achieved while on the ship?

For example, a science officer could add stellar objects he discovers with minerals, or new systems he discovers, to his achievement record.

An executive officer, tactical officer, CAG, etc. could add the tons of ships destroyed, ground units destroyed, etc.

In this way, the character's entire career would be recorded.

Thanks Steve!
Title: Re: C# Suggestions
Post by: nuclearslurpee on August 13, 2021, 09:56:42 AM
Would it be possible for officers who are on a ship, but who are not the commanders, to add the accomplishments they achieved while on the ship?

For example, a science officer could add stellar objects he discovers with minerals, or new systems he discovers, to his achievement record.

An executive officer, tactical officer, CAG, etc. could add the tons of ships destroyed, ground units destroyed, etc.

In this way, the character's entire career would be recorded.

Thanks Steve!

It would also be nice if medals were awarded in the same way. For survey fleets for example, if I jump an entire fleet of GSVs into a new system to explore it, only the senior commander of the fleet receives the medal, and no science officer does. Ideally all officers of all ships in the fleet would receive a medal since they jumped in at the same time...
Title: Re: C# Suggestions
Post by: ISN on August 13, 2021, 10:30:25 AM
While we're on the subject of medals, I would like to point out that currently as far as I can tell there is no way to award a medal to officers rescued from lifepods (besides going through the officer list manually). I like to award medals to fleets that participate in major battles, and I consider it a travesty that rescued officers -- who deserve the nation's highest honors! -- don't receive these campaign medals.

I know the game stores the officers on the ships that rescued them, even though they don't seem to be listed anywhere I can see, because if the rescuing ship is itself destroyed the officers that were previously rescued by it may die or end up in the lifepods again. So it should be possible to add an option for rescued officers to the Award Medals screen.
Title: Re: C# Suggestions
Post by: TMaekler on August 13, 2021, 10:35:31 AM
Planets and Moons which have an orbit that lasts only days or weeks "jump around" a lot because their position is only calculated every 5 days. I was wondering if it would be possible to add an extra layer of position calculations for objects which have an orbital turnaround of fewer than 30 days (or whatever number makes sense)? The position for these objects should then be calculated every 1 day... .
Title: Re: C# Suggestions
Post by: Droll on August 13, 2021, 02:42:48 PM
Planets and Moons which have an orbit that lasts only days or weeks "jump around" a lot because their position is only calculated every 5 days. I was wondering if it would be possible to add an extra layer of position calculations for objects which have an orbital turnaround of fewer than 30 days (or whatever number makes sense)? The position for these objects should then be calculated every 1 day... .

There is, in the game settings you can change the length of the production increment - this is also the time that is used when calculating orbits. I've started always playing on 1 day increments so the jumping around problem is much less pronounced for me.
Title: Re: C# Suggestions
Post by: Froggiest1982 on August 13, 2021, 05:03:33 PM
Planets and Moons which have an orbit that lasts only days or weeks "jump around" a lot because their position is only calculated every 5 days. I was wondering if it would be possible to add an extra layer of position calculations for objects which have an orbital turnaround of fewer than 30 days (or whatever number makes sense)? The position for these objects should then be calculated every 1 day... .

There is, in the game settings you can change the length of the production increment - this is also the time that is used when calculating orbits. I've started always playing on 1 day increments so the jumping around problem is much less pronounced for me.

How do you find performances? Also what about failures on ships but especially on fighters? Still acceptable or more "risky"?
Title: Re: C# Suggestions
Post by: Droll on August 13, 2021, 05:30:03 PM
Planets and Moons which have an orbit that lasts only days or weeks "jump around" a lot because their position is only calculated every 5 days. I was wondering if it would be possible to add an extra layer of position calculations for objects which have an orbital turnaround of fewer than 30 days (or whatever number makes sense)? The position for these objects should then be calculated every 1 day... .

There is, in the game settings you can change the length of the production increment - this is also the time that is used when calculating orbits. I've started always playing on 1 day increments so the jumping around problem is much less pronounced for me.

How do you find performances? Also what about failures on ships but especially on fighters? Still acceptable or more "risky"?

Maintenance failure chance is I think also based on the size of increments so it wouldn't overall affect maintenance costs/life for standard ships.

As for fighters, I usually have a fighter maintenance storage onboard, but only if the fuel time of the fighter is longer than 24 hours, if the fighter spends less then a production increment out of a hangar then you don't have to worry about maintenance on it.

Game performance wise, it's the same pretty much, a single 1 day increment is only slightly faster than a single 5 day increment. Only thing to note that doing 5 1 day increments takes longer than doing 1 5 day increment.

Another benefit of 1 day increments are when terraforming really small bodies and/or with lots of terraforming modules/facilities. 1 day increments allow you to avoid situations where you "overterraform" and have to rectify/SM fix the mangled atmosphere.
Title: Re: C# Suggestions
Post by: Froggiest1982 on August 13, 2021, 06:05:29 PM
Planets and Moons which have an orbit that lasts only days or weeks "jump around" a lot because their position is only calculated every 5 days. I was wondering if it would be possible to add an extra layer of position calculations for objects which have an orbital turnaround of fewer than 30 days (or whatever number makes sense)? The position for these objects should then be calculated every 1 day... .

There is, in the game settings you can change the length of the production increment - this is also the time that is used when calculating orbits. I've started always playing on 1 day increments so the jumping around problem is much less pronounced for me.

How do you find performances? Also what about failures on ships but especially on fighters? Still acceptable or more "risky"?

Maintenance failure chance is I think also based on the size of increments so it wouldn't overall affect maintenance costs/life for standard ships.

As for fighters, I usually have a fighter maintenance storage onboard, but only if the fuel time of the fighter is longer than 24 hours, if the fighter spends less then a production increment out of a hangar then you don't have to worry about maintenance on it.

Game performance wise, it's the same pretty much, a single 1 day increment is only slightly faster than a single 5 day increment. Only thing to note that doing 5 1 day increments takes longer than doing 1 5 day increment.

Another benefit of 1 day increments are when terraforming really small bodies and/or with lots of terraforming modules/facilities. 1 day increments allow you to avoid situations where you "overterraform" and have to rectify/SM fix the mangled atmosphere.

I'll give it a go then. I am enjoying my current setup with reduced growth for realistic pop, capped mines based on body size, 5% survey, 10% terraforming and DB edited for infrastructures produced only by colonies over 500 million pop. I was about to post some findings about it but the 1 day increment sounds nice addition.
Title: Re: C# Suggestions
Post by: TMaekler on August 13, 2021, 06:45:36 PM
There is, in the game settings you can change the length of the production increment - this is also the time that is used when calculating orbits. I've started always playing on 1 day increments so the jumping around problem is much less pronounced for me.
I wanted to avoid the game performance loss - but it is viable this way, yes.

Another benefit of 1 day increments are when terraforming really small bodies and/or with lots of terraforming modules/facilities. 1 day increments allow you to avoid situations where you "overterraform" and have to rectify/SM fix the mangled atmosphere.
I didn't know that. Interesting... . Maybe Steve should take this into consideration and "fix" it.

I'll give it a go then. I am enjoying my current setup with reduced growth for realistic pop, capped mines based on body size, 5% survey, 10% terraforming and DB edited for infrastructures produced only by colonies over 500 million pop. I was about to post some findings about it but the 1 day increment sounds nice addition.
Where can you edit that into the DB? Only produce when over 500 mill pop?
Title: Re: C# Suggestions
Post by: Froggiest1982 on August 13, 2021, 11:24:39 PM
Where can you edit that into the DB? Only produce when over 500 mill pop?

Trade Goods DIM. Change from the default value to 500 or any other number that suits you best
Title: Re: C# Suggestions
Post by: Garfunkel on August 14, 2021, 12:34:01 AM
I've been using 1-day production cyclen with 1-day increments since Day 1 of C# and it works well for me, I'd definitely suggest switching to it. In fact, it should probably be the default now.
Title: Re: C# Suggestions
Post by: Froggiest1982 on August 15, 2021, 07:05:47 PM
I've been using 1-day production cyclen with 1-day increments since Day 1 of C# and it works well for me, I'd definitely suggest switching to it. In fact, it should probably be the default now.

Quick one. In my current game, I seem not to be able to change the production cycle. Is it possible only at the start?

Also, the current cycle of 5 days is 430,000 while it should be 432,000. Eventually, should I do just 430,000/5 (86,000)?

Looking at the DB and modifying there directly works, maybe a bug?

Thanks

EDIT: I am going for 1 day x 24 hours x 60 minutes x 60 seconds (total cycle 86,400). But would like to know how you have set it up.
Title: Re: C# Suggestions
Post by: Froggiest1982 on August 15, 2021, 07:17:04 PM
It would be nice to have a flag for NO Civilian Mining Colonies.
Title: Re: C# Suggestions
Post by: serger on August 15, 2021, 11:26:45 PM
In my current game, I seem not to be able to change the production cycle. Is it possible only at the start?

Just edit, Save Settings, save the game and restart - you'll see changes. It's minor interface bug, it was already reported IIRC.
Title: Re: C# Suggestions
Post by: idefelipe on August 22, 2021, 05:21:12 AM
Hey Steve.

Would be possible to add a checkbox in the officers screen to show only those that are unnassigned? That would be a great QoL improve for those, as me, enjoy the officers assigment, organizing, moving, etc. part of the game.

Also, I'm thinking how to improve the auto-assigment in order to make it much more efficient and avoid ships without CO and officers free of assigment. Nnow it assigns those officers with an specific skill to specific ship, minning for minners, survey for explorations, etc.
Title: Re: C# Suggestions
Post by: Elminster on August 22, 2021, 08:28:39 AM
So, we have a mechanic to automatically assign Governors to colonies.

Slight issue though, as my Sector Commander is reassigned as a colony governer every time I hit "Reassign all governers". Please make Sector Commander excluded from auto-assigning.

Also, I wish there was the same mechanic to automatically assign Sector Commanders, Academy Leaders and Naval Command officers.
Alternatively there should be an interrupt in the events for when assigned personnel is no longer available.
Title: Re: C# Suggestions
Post by: nuclearslurpee on August 22, 2021, 09:18:37 AM
Also, I'm thinking how to improve the auto-assigment in order to make it much more efficient and avoid ships without CO and officers free of assigment.

The auto-assignment already does this about as well as it can. Ship commands are always preferred over auxiliary positions (XO, Chief Engineer, Tactical Officer, etc.).

The main "limitation" left is that officers with no relevant skills will not be assigned to any role, or if their only relevant skills are for roles that aren't open they will not fill that role. It's a bit of an open question whether or not this is the best approach, but in my observation officers will usually after sitting around for a few years pick up some kind of useful bonus and earn an assignment, or else continued fleet expansion will provide the necessary job openings.
Title: Re: C# Suggestions
Post by: idefelipe on August 23, 2021, 10:19:41 AM
The main "limitation" left is that officers with no relevant skills will not be assigned to any role, or if their only relevant skills are for roles that aren't open they will not fill that role.

This is what I am talking about. I can't understand that a very expensive organization as the navy will have just one officer, that needed a lot of money to be totally educated, sat in a chair filling sudokus. I guess the navy would assign him/her to any vacancy available.
Title: Re: C# Suggestions
Post by: nuclearslurpee on August 23, 2021, 12:04:09 PM
The main "limitation" left is that officers with no relevant skills will not be assigned to any role, or if their only relevant skills are for roles that aren't open they will not fill that role.

This is what I am talking about. I can't understand that a very expensive organization as the navy will have just one officer, that needed a lot of money to be totally educated, sat in a chair filling sudokus. I guess the navy would assign him/her to any vacancy available.

I agree from a flavor point of view, but from a gameplay point of view this makes sense, as (1) the officers with no relevant skill will not have any effects, and (2) leaving the position vacant allows a later-generated officer to immediately fill the role - if the role is filled by an unqualified officer then whenever a new officer is generated the game must check every command to see if an unqualified officer should be removed, which sounds like a huge mess to try and implement.

I think it is fine, because Aurora is not detailed enough to model this as well as we might like - we also lack many of the junior officer desk jobs or staff officer roles in administrative positions (and in the ground forces for that matter) which is needed to have truly realistic officer corps. Given this I think erring on the side of gameplay was the right decision. Plus it is always possible to assign an officer manually if you feel it is needed.
Title: Re: C# Suggestions
Post by: Elminster on August 23, 2021, 02:03:10 PM
You are all missing an important point.

For example, take a modern Carrier (say the Nimitz). You have the Captain (I don't know if he's even higher in rank, doesn't matter), the XO, CAG, maybe an Engineering Officer. All this is also present in Aurora. But... on the Nimitz there are hundreds of additional Lieutenant, Lt. Cmdr., Commander for various roles which are not represented in Aurora.

So, every Officer not assigned to an active command post in Aurora could just fullfil one of those hundreds of unnamed positions.
If they get some actual skills, they will eventually get an important position. ;)
Title: Re: C# Suggestions
Post by: nuclearslurpee on August 23, 2021, 02:29:28 PM
You are all missing an important point.

For example, take a modern Carrier (say the Nimitz). You have the Captain (I don't know if he's even higher in rank, doesn't matter), the XO, CAG, maybe an Engineering Officer. All this is also present in Aurora. But... on the Nimitz there are hundreds of additional Lieutenant, Lt. Cmdr., Commander for various roles which are not represented in Aurora.

So, every Officer not assigned to an active command post in Aurora could just fullfil one of those hundreds of unnamed positions.
If they get some actual skills, they will eventually get an important position. ;)

This is kind of what I was implying. I implicitly assume all of my unassigned officers are at Naval HQ sitting at desks pushing pencils and arguing about particle beams.  :P
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on August 23, 2021, 05:54:18 PM
You are all missing an important point.

For example, take a modern Carrier (say the Nimitz). You have the Captain (I don't know if he's even higher in rank, doesn't matter), the XO, CAG, maybe an Engineering Officer. All this is also present in Aurora. But... on the Nimitz there are hundreds of additional Lieutenant, Lt. Cmdr., Commander for various roles which are not represented in Aurora.

So, every Officer not assigned to an active command post in Aurora could just fullfil one of those hundreds of unnamed positions.
If they get some actual skills, they will eventually get an important position. ;)

This is kind of what I was implying. I implicitly assume all of my unassigned officers are at Naval HQ sitting at desks pushing pencils and arguing about particle beams.  :P

Are they pushing pencils or stabbing each other with them?
Title: Re: C# Suggestions
Post by: nuclearslurpee on August 23, 2021, 05:55:07 PM
You are all missing an important point.

For example, take a modern Carrier (say the Nimitz). You have the Captain (I don't know if he's even higher in rank, doesn't matter), the XO, CAG, maybe an Engineering Officer. All this is also present in Aurora. But... on the Nimitz there are hundreds of additional Lieutenant, Lt. Cmdr., Commander for various roles which are not represented in Aurora.

So, every Officer not assigned to an active command post in Aurora could just fullfil one of those hundreds of unnamed positions.
If they get some actual skills, they will eventually get an important position. ;)

This is kind of what I was implying. I implicitly assume all of my unassigned officers are at Naval HQ sitting at desks pushing pencils and arguing about particle beams.  :P

Are they pushing pencils or stabbing each other with them?

"Or"?  ;)
Title: Re: C# Suggestions
Post by: Elminster on August 24, 2021, 12:45:24 AM
You are all missing an important point.

For example, take a modern Carrier (say the Nimitz). You have the Captain (I don't know if he's even higher in rank, doesn't matter), the XO, CAG, maybe an Engineering Officer. All this is also present in Aurora. But... on the Nimitz there are hundreds of additional Lieutenant, Lt. Cmdr., Commander for various roles which are not represented in Aurora.

So, every Officer not assigned to an active command post in Aurora could just fullfil one of those hundreds of unnamed positions.
If they get some actual skills, they will eventually get an important position. ;)
This is kind of what I was implying. I implicitly assume all of my unassigned officers are at Naval HQ sitting at desks pushing pencils and arguing about particle beams.  :P
Officer's Mikado (pick-a-stick), whoever moves first has lost.  ;D
Title: Re: C# Suggestions
Post by: ISN on August 24, 2021, 01:18:26 PM
I had some ideas regarding ground forces that might give players more interesting options when designing their troops. They're largely focused on making infantry and other small unit types more useful. (There are a number of other higher-priority balance and QOL improvements that could be made to ground forces, but those have been discussed extensively elsewhere.)

One idea is a new infantry-only capability called "Infiltration" or "Commando Tactics" or something like that which would double the unit's breakthrough probability (that is, it would negate the 50% reduction in breakthrough probability that infantry have relative to vehicles).

A more extensive addition would be to add new technologies that allow the larger anti-vehicle weapons to be used by smaller unit types, kind of like the compact and small craft ECM/ECCM tech lines. So after researching SHAV, for instance, you would unlock a tech that allows HAV weapons to be used by smaller vehicles and then eventually by infantry. (For the sake of balance I think you'd probably want them to be the same size as the standard weapons, although miniaturizing them for infantry use does make more sense than having infantry somehow dragging around a giant gun.) After all, if the US could deploy tactical nuclear weapons to infantry units in the Cold War, I imagine Trans-Newtonian militaries will find all sorts of new and creative ways of putting massive firepower into the hands of their grunts. :)

Both these additions would give infantry a more useful place on the front lines and allow for more variety and RP opportunities in ground forces design. The first idea is likely easier to implement and balance than the second, but I think they could both probably be made to work.
Title: Re: C# Suggestions
Post by: nuclearslurpee on August 24, 2021, 01:42:37 PM
I had some ideas regarding ground forces that might give players more interesting options when designing their troops. They're largely focused on making infantry and other small unit types more useful. (There are a number of other higher-priority balance and QOL improvements that could be made to ground forces, but those have been discussed extensively elsewhere.)

words

Both these additions would give infantry a more useful place on the front lines and allow for more variety and RP opportunities in ground forces design. The first idea is likely easier to implement and balance than the second, but I think they could both probably be made to work.

I'm confused - in what way are infantry or small unit types not useful? I will concede that the SHV/UHV types are excessively effective against NPRs, but this is because the NPRs are not able to adapt their formations and tactics to handle them. Even so, infantry and smaller unit types are still very much effective in their intended roles - infantry for instance may not be as durable as a SHV but they are much cheaper/quicker to build and allow putting the maximum amount of firepower into the field per ton/BP due to having a zero base weight.

The only real problem I can think of is the better tonnage efficiency of VEH versus LVH, but this is at least partly counteracted by the relative fragility of VEH in a sustained battle so I am not sure if it is a problem or not. If so, an easy fix is to adjust the tonnages of the base types slightly (say, 10/20/40 instead of 12/18/36) which is an easy DB edit.

Quote
One idea is a new infantry-only capability called "Infiltration" or "Commando Tactics" or something like that which would double the unit's breakthrough probability (that is, it would negate the 50% reduction in breakthrough probability that infantry have relative to vehicles).

Infantry is already very efficient, and need to have some significant limitations compared to vehicles. Eliminating the breakthrough probability weakness for infantry would eliminate this key limitation and actually make vehicles much worse in comparison. There is probably a price point at which this is "balanced" but it is a very sensitive balance and not one I could see Steve wanting to spend a lot of time searching for.

Quote
A more extensive addition would be to add new technologies that allow the larger anti-vehicle weapons to be used by smaller unit types, kind of like the compact and small craft ECM/ECCM tech lines. So after researching SHAV, for instance, you would unlock a tech that allows HAV weapons to be used by smaller vehicles and then eventually by infantry. (For the sake of balance I think you'd probably want them to be the same size as the standard weapons, although miniaturizing them for infantry use does make more sense than having infantry somehow dragging around a giant gun.) After all, if the US could deploy tactical nuclear weapons to infantry units in the Cold War, I imagine Trans-Newtonian militaries will find all sorts of new and creative ways of putting massive firepower into the hands of their grunts. :)

I am not sure why this is really necessary? We can already put the heavier weapon types (except for AC - which would be a simple DB mod if it is bothersome) into a STA base, which is intended to represent such heavy weapons that require more infrastructure to operate than just a couple of guys carrying them. Despite the perhaps misleading name, "Static" units are not intended to be limited to only heavily fortified gun emplacements, bunkers, etc. but really represent anything that is not easily foot-mobile. For example, a STA+MB unit can be thought of as a 40-ton bombardment component plus a 12-ton unarmored truck to tow the gun into position. Imagination need not be limited by the name of things in the game interface.

And mechanically, for the added 12 tons one gains triple the HP compared to an infantry weapon which is very much worth it for a heavy bombardment or AV weapon, so there is little gain from making MB/HB/HAV/etc. "foot-mobile" in game terms.
Title: Re: C# Suggestions
Post by: Borealis4x on August 24, 2021, 01:43:56 PM
It would be nice to have a flag for NO Civilian Mining Colonies.

You could just make an empty colony on any planet you want exclusive mining rights in, couldn't you?
Title: Re: C# Suggestions
Post by: Density on August 24, 2021, 02:49:37 PM
It would be nice to have a flag for NO Civilian Mining Colonies.

You could just make an empty colony on any planet you want exclusive mining rights in, couldn't you?

Yes. But it would still be nice to have a flag for it to remove the micromanagement involved in doing this.
Title: Re: C# Suggestions
Post by: MrHuman on August 25, 2021, 11:38:00 AM
Not sure if this has been suggested before, but I have an idea for civilian colonist transport.  Under the current system civilian colony ships can remove more population from a colony than you want them to or sometimes even completely empty out the closest available "source" colony, which then gets set to a "destination" colony since it is below the 10m minimum for a population source, so the civilian fleet will now continually deliver more colonists there.

My suggestion to fix this is to be able to set a target population that the civilian shipping aims to fulfill.  Set the target of e. g.  Luna to 50m, the civilian shipping will start by shipping people there until the population reaches 50m, and then as the population grows naturally ship them off to other colonies but never below the target that was set.  This target number could even be set to match the current worker requirement of the colony.
Title: Re: C# Suggestions
Post by: ArcWolf on August 25, 2021, 05:29:20 PM
Not sure if this has been suggested before, but I have an idea for civilian colonist transport.  Under the current system civilian colony ships can remove more population from a colony than you want them to or sometimes even completely empty out the closest available "source" colony, which then gets set to a "destination" colony since it is below the 10m minimum for a population source, so the civilian fleet will now continually deliver more colonists there.

My suggestion to fix this is to be able to set a target population that the civilian shipping aims to fulfill.  Set the target of e. g.  Luna to 50m, the civilian shipping will start by shipping people there until the population reaches 50m, and then as the population grows naturally ship them off to other colonies but never below the target that was set.  This target number could even be set to match the current worker requirement of the colony.

Might be nice, i would also be in favor of a check that would stop civilian colony ships from pulling population off a world if it would put the production sector into negative workforce.
Title: Re: C# Suggestions
Post by: Elminster on August 26, 2021, 02:24:14 AM
My suggestion to fix this is to be able to set a target population that the civilian shipping aims to fulfill.  Set the target of e. g.  Luna to 50m, the civilian shipping will start by shipping people there until the population reaches 50m, and then as the population grows naturally ship them off to other colonies but never below the target that was set.  This target number could even be set to match the current worker requirement of the colony.
Might be nice, i would also be in favor of a check that would stop civilian colony ships from pulling population off a world if it would put the production sector into negative workforce.
Aside from this, a checkbox for "Emergency Evacuation" would be nice. So the civilian sector and government colony ships on "Standing Order"-duty prioritize pulling population.
Maybe with a dropdown for preferred destination.
Title: Re: C# Suggestions
Post by: TMaekler on August 27, 2021, 12:39:15 AM
A QoL suggestion: getting a reminder that after finishing certain research the development of a new planned component is possible would help in managing ones empire. Let me give an example:

I designed a new research project as a prototype with "Next Tech". It is marked as FP for "Future Prototype". Now I first have to research the base techs to switch it from FP to P - so I can research that Prototype. But due to all the other stuff I have to manage, when the base techs are finished I forget to research the Future Prototype. So If any FP switches from FP to P it would be nice if the game could send that info to the event log. Something like: "Research of Future Prototype ... is now possible."

As a bonus, if all prototypes for a ship class are finished it would also be nice to get a reminder into the event log that that ship class can now be locked and build.
Title: Re: C# Suggestions
Post by: mike2R on August 27, 2021, 05:26:52 AM
Something I'd like would be a game setting that let me change the refit cost for ships - eg make it 150% of standard cost or whatever, but leave construction of new ships unchanged.

I'd like to make big refits less attractive in my games, so I'd need to put more thought into what components to modernise, and incentivise keeping older types around for second line roles.
Title: Re: C# Suggestions
Post by: Borealis4x on August 27, 2021, 02:16:11 PM
It would be nice to have a flag for NO Civilian Mining Colonies.

You could just make an empty colony on any planet you want exclusive mining rights in, couldn't you?

Yes. But it would still be nice to have a flag for it to remove the micromanagement involved in doing this.

Wouldn't it be the same amount of micro-managment to check a box saying 'No Civilian Mining Colonies' as it is to press a button saying 'Create Colony'?

Perhaps you don't want it cluttering up the colony screen, but if you are restricting a planet from being used by civilians I assume you intend to use it yourself anyways.
Title: Re: C# Suggestions
Post by: QuakeIV on August 27, 2021, 03:18:02 PM
I think he means no civilian colonies period.
Title: Re: C# Suggestions
Post by: Malorn on August 27, 2021, 03:52:57 PM
I think he means no civilian colonies period.

Perhaps a flag by system would be a good method.
Title: Re: C# Suggestions
Post by: ArcWolf on August 27, 2021, 06:23:49 PM
I think he means no civilian colonies period.

Like the game settings to toggle Civilian shipping/harvesting
Title: Re: C# Suggestions
Post by: Density on August 27, 2021, 09:25:13 PM
It would be nice to have a flag for NO Civilian Mining Colonies.

You could just make an empty colony on any planet you want exclusive mining rights in, couldn't you?

Yes. But it would still be nice to have a flag for it to remove the micromanagement involved in doing this.

Wouldn't it be the same amount of micro-managment to check a box saying 'No Civilian Mining Colonies' as it is to press a button saying 'Create Colony'?

Perhaps you don't want it cluttering up the colony screen, but if you are restricting a planet from being used by civilians I assume you intend to use it yourself anyways.

I can't speak for froggie, but what I want is a global flag on the game settings screen for this. One click, no CMCs. As ArcWolf pointed out, we already have them for civ shipping and civ fuel harvesters.
Title: Re: C# Suggestions
Post by: Froggiest1982 on August 27, 2021, 11:45:56 PM
It would be nice to have a flag for NO Civilian Mining Colonies.

You could just make an empty colony on any planet you want exclusive mining rights in, couldn't you?

Yes. But it would still be nice to have a flag for it to remove the micromanagement involved in doing this.

Wouldn't it be the same amount of micro-managment to check a box saying 'No Civilian Mining Colonies' as it is to press a button saying 'Create Colony'?

Perhaps you don't want it cluttering up the colony screen, but if you are restricting a planet from being used by civilians I assume you intend to use it yourself anyways.

I can't speak for froggie, but what I want is a global flag on the game settings screen for this. One click, no CMCs. As ArcWolf pointed out, we already have them for civ shipping and civ fuel harvesters.

Correct.
Title: Re: C# Suggestions
Post by: ArcWolf on August 28, 2021, 12:20:20 AM


I can't speak for froggie, but what I want is a global flag on the game settings screen for this. One click, no CMCs. As ArcWolf pointed out, we already have them for civ shipping and civ fuel harvesters.

I personally would probably never use it, but I know other would and more options is never a bad thing.
Title: Re: C# Suggestions
Post by: Black on August 28, 2021, 02:48:14 AM
Could we get some kind of checkbox for our missile fire controls to not engage enemy size 1 missiles? Most likely for Ship Combat window in Naval Organization. It would remove a bit of micro when we deal with massed AMM strikes used in offensive mode.
Title: Re: C# Suggestions
Post by: Peregrine on August 28, 2021, 08:44:44 AM
A heatmap for the tactical system map screen showing the overlapping active/passive sensor coverages for certain resolution/signatures.  Right now, all of the individual overlapping sensor coverages are drown at the same time, making it hard to read when using a distributed DSTS network for example.  A simple two-colour overlay should work for this.

Alternatively/additionally, allow us to toggle the sensor labels drown over the specific sensor's coverage.
Title: Re: C# Suggestions
Post by: TMaekler on September 02, 2021, 06:01:26 AM
Specialized and DeSpecialized Industry

Usually my fighter and ammunition factories don't do a lot. They just exist in case they are needed.
I was wondering if it would make sense to allow normal construction factories to produce fighters and ammunition as well - much like prebuilding ship components with them - but of course at a slower production rate than specialised industries.

This would additionally give the option to switch industries to specialised industries as a preparation for war to be able to quickly produce the then needed fighters and ammunition - and later after the war build them back into normal industries. A little bit like it is handled in Hearts of Iron 4 - where you can switch normal industry to war production industry and vice versa.

This could also be used as a political indicator. A country which switches its industry to war production will likely go to war - and can be handled as such. This of course needs to be visible through elint for example.
Title: Re: C# Suggestions
Post by: Foxxonius Augustus on September 02, 2021, 01:19:45 PM
Specialized and DeSpecialized Industry

Usually my fighter and ammunition factories don't do a lot. They just exist in case they are needed.
I was wondering if it would make sense to allow normal construction factories to produce fighters and ammunition as well - much like prebuilding ship components with them - but of course at a slower production rate than specialised industries.

This would additionally give the option to switch industries to specialised industries as a preparation for war to be able to quickly produce the then needed fighters and ammunition - and later after the war build them back into normal industries. A little bit like it is handled in Hearts of Iron 4 - where you can switch normal industry to war production industry and vice versa.

This could also be used as a political indicator. A country which switches its industry to war production will likely go to war - and can be handled as such. This of course needs to be visible through elint for example.

I really like this idea. It would fit really well with the other instances of converting one structure into another. It would also be a new and interesting way to interact with your industry.

As an additional suggestion, a new kind of specialized industry that is specifically used for building ship components. It could work the same way that normal factories work now when building ship components while the normal factories could still do it they would be much slower. Even if there was no way to connect them in-game it could be really cool for RP revolving around ship component companies.
Title: Re: C# Suggestions
Post by: TMaekler on September 02, 2021, 03:42:42 PM
Whilst playing Quarar4x I stumbled upon this:

When your production chain breaks due to mineral shortages your nation gains massive amounts of money due to the workers still producing wealth that is no longer used by the production. Since the workers are basically on short work should not any slowed production also minimize the income of wealth? Those people cannot pay taxes anymore... .

I think this is the same in C# Aurora is it not?
Title: Re: C# Suggestions
Post by: seinwave on September 03, 2021, 09:10:25 AM
I'm guessing this has been discussed and rejected before, but if so I haven't seen it.

Would there be a way to have a 'capped' Known Stars game? I like having real-world stars populate the galaxy map but a game with a max of 4,400 stars has a frame-death bullet with its name on it from the start. I'd imagine there are complexities to doing this while pulling from the star catalog.
Title: Re: C# Suggestions
Post by: nuclearslurpee on September 03, 2021, 11:30:01 AM
I'm guessing this has been discussed and rejected before, but if so I haven't seen it.

Would there be a way to have a 'capped' Known Stars game? I like having real-world stars populate the galaxy map but a game with a max of 4,400 stars has a frame-death bullet with its name on it from the start. I'd imagine there are complexities to doing this while pulling from the star catalog.

Play with real stars up to some point (you can keep track of the total number of systems generated by checking the DB periodically), then switch to random stars with the selected cap value. This should prevent any more systems from generating and cause all unexplored jump points to link to known systems.
Title: Re: C# Suggestions
Post by: TMaekler on September 04, 2021, 10:06:18 AM
Aurora is meant to be able to tell stories. Most of our stories are single-player against different kinds of AI. A few attempts have been made to create a multi-player experience and AARs thereof. So I was thinking why so few multi-player ones? Because it is quite a stretch for a game master to manage so many factions and keep the game rolling. What are ways to change this?

If Aurora could export all settings for one race of a game and reimport it into a blank database a single file could be generated for all participants of a multiplayer game. People could import that into their local Aurora and generate all commands and changed they want to do, export these and send them to the game master for re-importing. Sure that involves some programming part on Steves side to not get the live database corrupted. But I think it might be worth it. Who wouldn't want to engage in a fight with another human opponent?
Title: Re: C# Suggestions
Post by: unkfester on September 05, 2021, 07:34:37 AM
Aurora is meant to be able to tell stories. Most of our stories are single-player against different kinds of AI. A few attempts have been made to create a multi-player experience and AARs thereof. So I was thinking why so few multi-player ones? Because it is quite a stretch for a game master to manage so many factions and keep the game rolling. What are ways to change this?

If Aurora could export all settings for one race of a game and reimport it into a blank database a single file could be generated for all participants of a multiplayer game. People could import that into their local Aurora and generate all commands and changed they want to do, export these and send them to the game master for re-importing. Sure that involves some programming part on Steves side to not get the live database corrupted. But I think it might be worth it. Who wouldn't want to engage in a fight with another human opponent?


Maybe play by email type of thing
Title: Re: C# Suggestions
Post by: nuclearslurpee on September 06, 2021, 09:42:51 AM
Seeing the last couple of 1.14 changes brings to mind another change that I think would be appreciated.

A common frustration with Real Stars games is that the galactic map always comes out looking fairly similar, that is to say it tends to have a lot of long branches and chains with not very many loops (a few, but not many so they are usually quite special to find). For configurability we have Random Stars games but this is admittedly not always as flavorful, in some RP settings it is just not the same without Alpha Centauri after all.

Perhaps a reasonable and easily-implemented change would be to add a game setting for a multiplier to JP generation chance, such that the default is 1.0x as we have now. This would allow at least some superficial variation in how a Real Stars galaxy looks, for example one could set the multiplier to 2.0x for a dense JP network with a greater amount of loops, etc. or one could set the multiplier to 0.5x for a more maze-like galaxy with a lot of long chains and dead ends.

Obviously it is a bit of a use-at-own-risk option but one I think would keep the galaxy fresh for many players.
Title: Re: C# Suggestions
Post by: serger on September 06, 2021, 12:18:36 PM
I'd like also to have an option of setting JPs to be generated more of less long in light years (in average).

(Mostly I like to see JPs leading to the closest stars, yet I know some players like the opposite, therefore the option.)
Title: Re: C# Suggestions
Post by: pwhk on September 07, 2021, 09:55:00 AM
Currently, all leaders start with age 21 (afair). Not just that this is not completely realistic, it causes a wave of retirements for civil admins and scientists after 40 years into the game.
Could we randomize starting ages of leaders?
Title: Re: C# Suggestions
Post by: Drakale on September 07, 2021, 02:08:21 PM
That would be nice. Maybe weighted toward lower age with a logarithmic scale.

In peacetime armies/navies it's pretty rare to get promotion from NCO to CO, but in an active war it's actually fairly common so it would make sense that even military officiers can start their careers(at least the CO part) at a more advanced age.
Title: Re: C# Suggestions
Post by: TMaekler on September 11, 2021, 04:16:03 AM
Military or Civilian?

We have a clear distinction between Military and Civilian ships - mostly so that we don't die in micromanaging a bunch of civilian ships. Whilst I generally agree with this, some separations seem to me to be too arbitrary. I was wondering if we could change how maintenance is calculated for engines. At the moment we have a clear distinction: Any engine below size 25 is military, any engine above engine power x0.50 is military. This leads to most of my designs being at the opposite side of these spectrums - very view engines are someplace in the middle.

So how about maintenance below engine power x0.50 stays at zero, then from x0.50 to x1.00 it increases linear and from x1.00 onwards we have the same calculations as we do now. With this linear grade, we could gain the additional option of "fast mid-range transports" that do need maintenance but have superior speed over the non-maintenance transports. Or also some kind of "lower maintenance small military ships". I think adding this option might open up some design options... .

I don't know if doing the same kind of grade with engine size would make sense. But I think it would with engine power factor. All ships from x0.55 upwards stay military, but between x0.55 to x0.95 they have a lower maintenance need... .
Title: Re: C# Suggestions
Post by: nuclearslurpee on September 11, 2021, 08:34:39 AM
Military or Civilian?

We have a clear distinction between Military and Civilian ships - mostly so that we don't die in micromanaging a bunch of civilian ships. Whilst I generally agree with this, some separations seem to me to be too arbitrary. I was wondering if we could change how maintenance is calculated for engines. At the moment we have a clear distinction: Any engine below size 25 is military, any engine above engine power x0.50 is military. This leads to most of my designs being at the opposite side of these spectrums - very view engines are someplace in the middle.

So how about maintenance below engine power x0.50 stays at zero, then from x0.50 to x1.00 it increases linear and from x1.00 onwards we have the same calculations as we do now. With this linear grade, we could gain the additional option of "fast mid-range transports" that do need maintenance but have superior speed over the non-maintenance transports. Or also some kind of "lower maintenance small military ships". I think adding this option might open up some design options... .

I don't know if doing the same kind of grade with engine size would make sense. But I think it would with engine power factor. All ships from x0.55 upwards stay military, but between x0.55 to x0.95 they have a lower maintenance need... .

This already happens to a degree, because EP modifiers below 1.0x apply as a multiplier to the cost in addition to the usual behavior. So if you have, say, a size-20 ion drive (12.5 EP/HS), at a 1.0x multiplier your engine has 250 EP and 125 BP cost. As a 0.8x multiplier, your engine has 200 EP but rather than the 100 BP you would expect, it is only 80 BP because the cost is additionally multiplied by that 0.8x. Since maintenance cost is tied to BP cost this also affects maintenance requirement.

Midrange EP modifiers do already have their place, for example large engines with sub-1.0x multipliers are useful for large capital ships to reduce fuel demands, MSP consumption, cost, etc. Another example is that frequently a multiplie of, say, 0.75x is good for survey ships which already have maintenance requirements, to allow faster surveying but still sufficient fuel efficiency.

Basically I would worry that applying an additional modifier for 0.5x to 0.95x multipliers will open some rather exploitable design space with designs that already have a valid place in Aurora. The current system may be a bit questionable in its verisimilitude but it does work quite well for what it needs to accomplish.
Title: Re: C# Suggestions
Post by: Andrew on September 15, 2021, 04:27:56 AM
Ability to send troops to help one of your own ships which has been boarded. Probably just allow a boarding equipped ship to transfer troops to a ship with a boarding action underway regardless of it it is neutral , freindly or hostile
Title: Re: C# Suggestions
Post by: TMaekler on September 15, 2021, 05:01:40 AM
This already happens to a degree, because EP modifiers below 1.0x apply as a multiplier to the cost in addition to the usual behavior. So if you have, say, a size-20 ion drive (12.5 EP/HS), at a 1.0x multiplier your engine has 250 EP and 125 BP cost. As a 0.8x multiplier, your engine has 200 EP but rather than the 100 BP you would expect, it is only 80 BP because the cost is additionally multiplied by that 0.8x. Since maintenance cost is tied to BP cost this also affects maintenance requirement.
I See and agree that this could go to levels of exploitation. The idea was to have a finer degree between military and civilian - not this abrupt "arbitrary" line at size 25 / engine modifier 0.5x. It would be interesting to see how small maintenance would get if all engines would be military. Is there an option to switch the calculations to all engines being military? I don't think so... well, will take a look into how this all is calculated (oh dear, what am I putting myself into here  ;D ::) ).

Addendum: can't find anything in the C# change list overview. Any ideas where the engine calculations are documented?
Title: Re: C# Suggestions
Post by: TMaekler on September 15, 2021, 05:10:53 AM
Is there an easy way (I guess not) for Steve to add a kind of "preserve orders" functionality? Idea is automation. With any resupply/refuel ship you basically have to join the target fleet and let the internal function of the now-sub-fleet refuel the main fleet. However when the target fleet is filled up one can only manually remove that sub-fleet and set up new orders to continue. So if it could be possible to "preserve orders" when a fleet goes "sub-fleet" and automatically detaches when their internal function is fulfilled and those orders would "reappear" in that new born fleet... it would help with some automations and easy micromanagement.
Title: Re: C# Suggestions
Post by: nuclearslurpee on September 15, 2021, 09:56:30 AM
I See and agree that this could go to levels of exploitation. The idea was to have a finer degree between military and civilian - not this abrupt "arbitrary" line at size 25 / engine modifier 0.5x. It would be interesting to see how small maintenance would get if all engines would be military. Is there an option to switch the calculations to all engines being military? I don't think so... well, will take a look into how this all is calculated (oh dear, what am I putting myself into here  ;D ::) ).

There is not an option, but you can easily make all ships military simply by mounting a non-commercial component on every ship. 55-ton sensors, compact ECM, non-CIWS defensive weapons, size-1 box launchers loaded with a "distress beacon" or "courier drone", small defensive shield generators... lots of possibilities. It's important to remember that the engines are really only one part of what defines a "commercial ship".

Personally I do not find it a problem. It is not difficult IMO to say that "commercial" designations are those which the government has said that civilian contractors can service in a maintenance dock, and "military-grade" technology must be serviced by military service docks, for example.
Title: Re: C# Suggestions
Post by: TMaekler on September 18, 2021, 05:02:38 AM
An idea for a multiplayer setup.

ATM we can't send the aurora DB around because even with a password everyone could simply look into the DB to see anything or just remove the password to be able to see all. We could prevent this if we could get an option for Aurora to be able to open a DB on an online drive. It should not be possible to download that DB via the link; but if we could let Aurora open that online DB it would make Multiplayer Games a bit more accessible.

If all players are set up with a password no one could look into what the others are doing and the SpaceMaster could make the DB available to the players so in case they want to or have to do something they could do it in the online DB. It would be nice if the time progression buttons would be disabled when an online DB is accessed so no one accidentally progresses time. Once all players have done their changes the SpaceMaster can continue time progression.

Don't know where such files could be uploaded that no one could download them except the Aurora-Program... . Also if multiple players would want to edit their empires they would need to coordinate so only one player at a time is editing his empire and no data will be lost.
Title: Re: C# Suggestions
Post by: QuakeIV on September 18, 2021, 11:33:22 AM
The biggest issue with that is likely dealing with concurrent access to the DB.  Time progression is not necessarily the only issue there.
Title: Re: C# Suggestions
Post by: nuclearslurpee on September 18, 2021, 11:37:32 AM
It's not a bad suggestion, but I want to point out that this would essentially require Steve to code multiplayer code (painful) and put together some kind of Aurora server to host these remote-access DBs (painful + $$$), so I highly doubt any kind of multiplayer functionality would happen even though it would be really cool.
Title: Re: C# Suggestions
Post by: TMaekler on September 18, 2021, 11:48:35 AM
As far as I can oversee this, the functionality Steve would need to add is a) the blocking of the time progression if the DB comes from a server and b) some kind of remote access to a DB that is not in the game folder but rather on some kind of web address. I originally thought that anyone could host the file for example on google drive - but it is not possible to block downloads from there. But maybe there are other services that could host that file but make it so that it can only be accessed by a private Aurora User and therefore keep it from being downloaded (and spied upon).

For anything else the players are responsible - meaning - only one player at a time. Otherwise: data garbage.

Title: Re: C# Suggestions
Post by: TMaekler on September 19, 2021, 04:10:56 AM
We need that asteroid  ;D

Title: Re: C# Suggestions
Post by: Destragon on September 25, 2021, 10:46:48 PM
About the "Surveyed Bodies" option in the display settings for the system map, wouldn't it make more sense if it did the opposite and highlighted the unsurveyed bodies instead of the surveyed ones? It would just mean less visual clutter on the system map. You don't really need to see these circles around every body in a system that you surveyed 100 years ago. I know you can just turn it off, but my point is that if it highlighted the unsurveyed bodies instead, then you wouldn't need to turn it off, since the visual clutter would automatically disappear once the system has been surveyed.
Unless I guess maybe people like having the circles around every body to make it easier to see what's a body and what isn't.
Title: Re: C# Suggestions
Post by: Fistandantillus7 on September 26, 2021, 10:41:36 PM
Krypton
Xenon
…Because the moon and mars lose oxygen, nitrogen and water vapour to space IRL but might hold on to Xenon. The graph on the top right of this Wikipedia page (https://en.wikipedia.org/wiki/Atmospheric_escape) shows that gases above a planetary dot are that are likely to be lost and those below are likely to be retained.

Radon
Oganesson
…For our radiation eating alien allies
Title: Re: C# Suggestions
Post by: nakorkren on September 30, 2021, 07:54:44 PM
I know we can now make fake infirmaries and instant them in, but would it be possible to get infirmaries with a real function, i.e. reduce battle casualties?
Title: Re: C# Suggestions
Post by: Stryker on October 01, 2021, 09:29:20 PM
An optional auto pause feature that is player definable.  For example, once per year I like to check my colonies, fleets, research, production, etc.  Other players may want to do it more or less often.  Or not at all (thus the optional aspect).
Title: Re: C# Suggestions
Post by: Droll on October 02, 2021, 06:33:05 PM
So I just had an NPR generate in a system in my current game but there is a problem, aside from overpopulation and dangerous gasses on their homeworld which are known and fixed in the next version, their home system in general can be incredibly resource poor.

I only noticed this because my espionage ship just managed to tease out the system geo survey from the NPR and I realized that aside from the NPR homeworld which doesn't have much resources (that's fine), the rest of the system had basically nothing. No additional gallicite, no additional duranium, no additional sorium whatsoever. One body had a quarter mil uridium deposit but that was all.

Thanks to my intel I was able to fix this by sm rerolling planets around the system until their home system actually had decent resources in most essentials (still no extra mercassium) however I would have had no idea this problem even existed if it wasn't for my cloaked ELINT ship.

My suggestion is that when an NPR is generated mid-game, the game should go through the system and ensure that there is something extra for the NPR to work with. Yes, in a sol start you aren't guaranteed abundance but you are as the player guaranteed to get something on the other bodies of the solar system beyond the poor resources of earth. Especially since NPRs are bad at resource management this might help them be a little more competitive.

Also re-suggesting multi-system NPR generation to spice up those random NPRs.
Title: Re: C# Suggestions
Post by: nuclearslurpee on October 02, 2021, 06:37:11 PM
My suggestion is that when an NPR is generated mid-game, the game should go through the system and ensure that there is something extra for the NPR to work with. Yes, in a sol start you aren't guaranteed abundance but you are as the player guaranteed to get something on the other bodies of the solar system beyond the poor resources of earth. Especially since NPRs are bad at resource management this might help them be a little more competitive.

Adding to this, it may be worth giving NPRs a larger starting stockpile of resources (if they don't already, I have not checked) to account for the fact that, especially on higher-population starts, important minerals may be depleted in only 5-10 years and the NPRs often struggle to establish a robust offworld supply of key minerals. This doesn't solve the problem but it does provide a bit more of a buffer for the NPRs to keep their industry and shipbuilding functional while a crunch is resolved.
Title: Re: C# Suggestions
Post by: RaidersOfTheVerge on October 02, 2021, 08:28:08 PM
I've been playing with tech in upper part of the middle third or so.  Solid Core AM engines and stuff about that level.  AFR and MSP requirements seem to skyrocket.  It would be great if there were some researchable tech mitigation to this inflation.  Maybe advanced engine rooms, maint.  bays that can store more MSP per HS,  or just researching general tech that lowers MSP needed per repair.  I. e Base Repair Method; repair cost = 1. 2 x base MSP, Improved Repair Method 1. 0, Advanced Repair Methods 0. 8, Predictive Repair Methods 0. 6, etc.
Title: Re: C# Suggestions
Post by: ArcWolf on October 03, 2021, 01:03:43 AM
An optional auto pause feature that is player definable.  For example, once per year I like to check my colonies, fleets, research, production, etc.  Other players may want to do it more or less often.  Or not at all (thus the optional aspect).

Until something like this is added I suggest creating a small station around your capital and give it a repeating "send message" order to your capital every 365 days. This will in-effect pause your game once a year.

I personally have it set up to cycle 3 -365 and once 366 day orders to account for leap year some my game "auto-pauses" every Jan 1st.
Title: Re: C# Suggestions
Post by: Kristover on October 03, 2021, 10:46:14 AM
This is a minor request for us roleplayer types but I really liked the miscellaneous component feature in the last update and I used it specifically to ‘specialize’ my ships.  I felt it a good compromise solution for those that didn’t want to micro didn’t have to engage with it and for those that wanted it, it added to their game.

I was wondering if we could have something similar in this update for colony installations?  I would like to add ‘flavor’ to my colonies.  A easily constructed installation that has no gameplay function (people don’t have to engage with it) but us micro-RPers could add? 

Thanks and looking forward to next update!
Title: Re: C# Suggestions
Post by: Droll on October 03, 2021, 05:36:29 PM
I do not know the specific lore of active sensors and how they do their sensing but I thought that it would be cool if the fleets that have multiple ships in them would have their crosssection "combine" in some way, which would obfuscate the amount/size of ships but instead give you the overall size of the fleet. As you draw closer (maybe depending on sensor resolution in some way) individual ships in the fleet can be resolved and you'll get a better idea of the number of ships instead of just overall fleet tonnage.

This would also be interesting for stealth ships, making it preferable for them operate alone (very interesting for the new pirates) and also making it harder to just have massive fleets with 95% reduction to their active signatures as they're small signatures would all combine into one larger one.

It also opens up strategies with the cloaking bay. Having larger ships with cloaking bays means that uncloaked escort ships can effectively screen for them against not just missiles but maybe even beam weapons. Alternatively you can use this to "hide" your smaller screens and obfuscate your PD ability.

Or just cheese it with a cloaked fleet and a massive slab of uncloaked armor.

The way I'm thinking is that the combined tonnage cant be targeted by weapons. The only exception being self-guided missiles. In-fact such missiles become much more valuable as when they close, they'll be able to detect individual ships hidden in the "mass", targeting them and giving you intel about fleet composition.

Also the idea of a "mass" of tonnage being spotted works really well with the star swarm

Edit: You could also do something similar with thermal and EM signatures. Finding ships in orbit of a large colony for example could be quite difficult this way as their thermal and EM signatures would be hidden within the populations signature. Alternatively you don't need to change thermal and EM, since an active lock is needed to target and fire on enemies the suggestion still holds meaning with current passive detection.
Title: Re: C# Suggestions
Post by: Stryker on October 04, 2021, 07:25:14 AM
An optional auto pause feature that is player definable.  For example, once per year I like to check my colonies, fleets, research, production, etc.  Other players may want to do it more or less often.  Or not at all (thus the optional aspect).

Until something like this is added I suggest creating a small station around your capital and give it a repeating "send message" order to your capital every 365 days. This will in-effect pause your game once a year.

I personally have it set up to cycle 3 -365 and once 366 day orders to account for leap year some my game "auto-pauses" every Jan 1st.

Good idea.  I never thought of using a message in this way.
Title: Re: C# Suggestions
Post by: Stryker on October 04, 2021, 07:28:04 AM
Would it be possible to get the color schemes back for sectors.  Currently it's red, which is also the color of unfinished jump point surveys.
Title: Re: C# Suggestions
Post by: Kristover on October 04, 2021, 07:56:24 AM
One other feature that I think would be cool is ministries.  In my longer games, I tend to have a lot of civilian administrators and scientists with nothing to do.  I think resurrecting a variant of the old ‘staff’ function that we had with VB6 naval administrations would be cool.  Attach it to Sectors and put it in a new tech line (admin tech) and have something like an economics, justice, defense, science and education minister, or so forth that you can assign to those roles and they would offer a fraction of their bonus to their area.  For that matter, you could re-add the naval staffs with a similar setup.
Title: Re: C# Suggestions
Post by: alex_brunius on October 04, 2021, 03:02:01 PM
So, currently an issue I perceive with the game is that it's quite alot of tedious Micromanagement to mine out those asteroids, yet they do contain easily accessible minerals that would be neat to get access to, and that lore wise probably would be lucrative for civilians to go after...

How hard would it be to add some civilian ships that work a bit like sorium harvesters but instead they swoop around our colonized systems and stripmine asteroids for us, so we can just visit a single location and buy all those juicy minerals once they have filled those cargo holds for us with minerals from dozens of asteroids?
Title: Re: C# Suggestions
Post by: Droll on October 04, 2021, 04:07:00 PM
So, currently an issue I perceive with the game is that it's quite alot of tedious Micromanagement to mine out those asteroids, yet they do contain easily accessible minerals that would be neat to get access to, and that lore wise probably would be lucrative for civilians to go after...

How hard would it be to add some civilian ships that work a bit like sorium harvesters but instead they swoop around our colonized systems and stripmine asteroids for us, so we can just visit a single location and buy all those juicy minerals once they have filled those cargo holds for us with minerals from dozens of asteroids?

Your basically asking for civilians to get orbital miners in addition to the sorium harvesters they can already get. As long as people can turn it off I have no qualms with this and it would push civies to completeness.
Title: Re: C# Suggestions
Post by: xenoscepter on October 04, 2021, 04:11:05 PM
So, currently an issue I perceive with the game is that it's quite alot of tedious Micromanagement to mine out those asteroids, yet they do contain easily accessible minerals that would be neat to get access to, and that lore wise probably would be lucrative for civilians to go after...

How hard would it be to add some civilian ships that work a bit like sorium harvesters but instead they swoop around our colonized systems and stripmine asteroids for us, so we can just visit a single location and buy all those juicy minerals once they have filled those cargo holds for us with minerals from dozens of asteroids?

 --- I'd add in here the ability for Civilian Shipping Lines to be told to collect from CMCs with the addition that CMCs would build a Cargo Shuttle Station for the purpose of loading / unloading them.
Title: Re: C# Suggestions
Post by: nuclearslurpee on October 04, 2021, 04:25:42 PM
--- I'd add in here the ability for Civilian Shipping Lines to be told to collect from CMCs with the addition that CMCs would build a Cargo Shuttle Station for the purpose of loading / unloading them.

A Cargo Shuttle Station shouldn't be necessary, I'm fairly sure the civilian ships come with their own cargo shuttle bays - otherwise they wouldn't be able to ship things to most colonies that actually need stuff.
Title: Re: C# Suggestions
Post by: alex_brunius on October 05, 2021, 03:44:31 AM
Your basically asking for civilians to get orbital miners in addition to the sorium harvesters they can already get. As long as people can turn it off I have no qualms with this and it would push civies to completeness.

Pretty much yeah. I would consider civies in a more complete state when:
- They can do asteroid mining ( as suggested above )
- Civilian tankers ( and a few relevant trade goods they can ship ) are added
- All mined minerals & fuel from sites & harvesters are automatically delivered by civies to the systems largest colony ( once enough to be worth a freighter/tanker trip is in place at extraction site )
- All mined minerals & fuel end up in a civilian open market on that colony that you can conveniently buy from ( should probably also decay with about 2-5% yearly to account for civilian use unless there is some "buy all of it" option like for CMC currently )
- You can request civilian contracts for mineral & fuel delivery in addition to installations ( potentially also automated to maintain certain reserve levels that you have set )
- Ability to tax civilians by type of activity if you feel certain types of civilian growth are getting out of hand ( even raising their taxes taxing them to death if you want to )
- Ability to prioritize civilian freighter activity between infrastructure delivery, other trades, contracts and mineral fetching ( potentially connected to above taxation levels )


I agree it's not for everyone, and that it could potentially lead to alot of extra computation and slowdowns so being able to limit them or turn it off would be great. But I think it would greatly help with automating the maintanance of larger empires. The way I look at civies is that I would rather the CPU spend 30 seconds extra on calculations while I read some more Aurora fiction instead of me having to spend 300 seconds on tedious repetetive tasks in the game to accomplish a similar result.
Title: Re: C# Suggestions
Post by: Droll on October 05, 2021, 03:17:01 PM
My suggestion is that when an NPR is generated mid-game, the game should go through the system and ensure that there is something extra for the NPR to work with. Yes, in a sol start you aren't guaranteed abundance but you are as the player guaranteed to get something on the other bodies of the solar system beyond the poor resources of earth. Especially since NPRs are bad at resource management this might help them be a little more competitive.

Adding to this, it may be worth giving NPRs a larger starting stockpile of resources (if they don't already, I have not checked) to account for the fact that, especially on higher-population starts, important minerals may be depleted in only 5-10 years and the NPRs often struggle to establish a robust offworld supply of key minerals. This doesn't solve the problem but it does provide a bit more of a buffer for the NPRs to keep their industry and shipbuilding functional while a crunch is resolved.

I'm replying to these as it is relevant to the discussion around NPRs being bad at empiring. One of my NPRs just ground my game to a halt because I made the grave error of allowing NPRs to trigger precursors, leading them to find one of their outposts. Said NPR won that engagement which is cool, but they then decided to bombard the world they fought over with 1000s of AMMs (I did power through the 5s increments thankfully).

The problem of being stuck in 5s increments due to this is well known and documented, but it also exemplifies a flaw in the AI and the way it treats potentially valuable worlds. This planet was a very good potential colony candidate for their empire and thanks to hostile presence was probably not surveyed. The spoilers in question usually guard valuable planets in general but now this NPR, through AMM bombardment has given it 2200 radiation and 4400+ dust, effectively rendering it un-colonizable in the foreseeable future.

Now if you read the spoilers you know the type of spoiler race we are dealing with, so my suggestion is along the lines of  - "why doesn't the NPR even attempt to launch a ground invasion to preserve the planet?" and if it does want to bombard the planet, why is it using AMMs? can NPRs at least try to use enhanced radiation or larger ASM missiles so that we don't have to sit through potentially hours of 5 sec increments?

This was made even worse because the garrison's PD STOs were shooting down 80 of 85 AMMs per 5 secs.
Title: Re: C# Suggestions
Post by: nuclearslurpee on October 05, 2021, 04:03:20 PM
This was made even worse because the garrison's PD STOs were shooting down 80 of 85 AMMs per 5 secs.

This is probably why. The NPRs are not clever enough to figure out how to attack a planet with a lot of STOs in any other way besides hurling missiles at it until it breaks. Or firing lasers at it until it breaks, as the case may be. This is in spite of the fact that NPRs always build a number of massive assault transports with several systems' worth of armor for the express purpose of making such an opposed landing.
Title: Re: C# Suggestions
Post by: Destragon on October 06, 2021, 10:13:20 AM
I'm not sure if Steve personally makes lots of use of the wealth screen, but for me I would kinda like it if the wealth button on the map screen was replaced with one to bring up the shipyard screen.
Title: Re: C# Suggestions
Post by: Fistandantillus7 on October 06, 2021, 05:40:01 PM
I'm not sure if Steve personally makes lots of use of the wealth screen, but for me I would kinda like it if the wealth button on the map screen was replaced with one to bring up the shipyard screen.
No matter what tab I want on the economics window I simply press the research button, it is bright cyan and my mouse gets there without me looking. If we are going to have four buttons to that window, shipyards makes more sense than wealth/trade. Moving the Fleet/Naval Organization window button to follow next would make more sense too; having it in the middle of the various design buttons is an odd choice.
Title: Re: C# Suggestions
Post by: nakorkren on October 07, 2021, 08:05:10 AM
I would dearly love a "refuel fleet evenly" button, for those situations where I need to split the fuel I have in a tanker across a fleet to maximize the range of the fleet because I don't have enough to totally refuel the fleet. As it stands now, I have to manually designate each ship high refuel priority, advance time until they have the right amount, change that ship's priority back to 0, then do the next one, etc.
Title: Re: C# Suggestions
Post by: Stryker on October 07, 2021, 05:34:22 PM
Steve, when a civilian mining colony plays out, there is an event to tell you and then the colony shuts down.

However, a player's own mining colonies are different.  Right now you have to go through each colony one by one periodically to make sure they are still up and running.

If when a player's mining colony plays out, the name of that colony on the mining tab of the economics screen could be highlighted in red, that would pop right out at the player and make identifying empty mining colonies much easier.
Title: Re: C# Suggestions
Post by: Droll on October 07, 2021, 06:41:43 PM
Minor suggestion that may have been made before.

Split the current "fleet fire at will" into "fleet BFC fire at will" and "fleet MFC fire at will". The names should make it obvious, but I find it annoying in beam-oriented fleets that have AMM escorts, as the escort AMMs will be also set to fire using the current command and I have to turn off every single MFC very often.
Title: Re: C# Suggestions
Post by: serger on October 08, 2021, 02:33:25 AM
If when a player's mining colony plays out, the name of that colony on the mining tab of the economics screen could be highlighted in red, that would pop right out at the player and make identifying empty mining colonies much easier.

It is also a thing, that both CMC and "governmental" mining colony could (and nearly every one would) run into inefficient mode, where remaining accessibility is too low to continue mining really.

For "governmental" colonies we have an option to remove it, but it's not an available option for CMC.

So, I think it will be very cool to have 2 new simple mechanics:

1) Yellow and/or orange color indicators for any mining colony (both commercial and governmental) running at low and/or very low accessibility levels.

and

2) An obligatory or optional (by button) closing of CMC and moving it's complexes to another, more abundant sites.
Title: Re: C# Suggestions
Post by: Garfunkel on October 08, 2021, 11:54:58 PM
A universal tick box for commanders that stops them from being relieved of their current post after promotion. I like to manually assign all my commanders and it's annoying having to put them back in their positions after a promotion.
Title: Re: C# Suggestions
Post by: papent on October 09, 2021, 04:08:21 PM
An option that will force commanders on to ships, regardless of skill mismatch. I would prefer for my Junior naval leaders to work as subpar XO's or command freighters than not have a job at all.
Title: Re: C# Suggestions
Post by: nuclearslurpee on October 09, 2021, 04:14:25 PM
An option that will force commanders on to ships, regardless of skill mismatch. I would prefer for my Junior naval leaders to work as subpar XO's or command freighters than not have a job at all.

This would require also a functionality to replace unqualified officers with new ones when new officers are generated or promoted, otherwise your 125 crew training LCDR may not be able to get an XO job because some nugget with no skills and 45 political rating is loafing on the job instead.
Title: Re: C# Suggestions
Post by: papent on October 09, 2021, 10:09:30 PM

This would require also a functionality to replace unqualified officers with new ones when new officers are generated or promoted, otherwise your 125 crew training LCDR may not be able to get an XO job because some nugget with no skills and 45 political rating is loafing on the job instead.

I'm legitimately okay with not replacing underqualified officers and surely anybody else that clicked that option because like myself they just want bodies in seats.
Title: Re: C# Suggestions
Post by: ArcWolf on October 10, 2021, 01:10:38 AM

This would require also a functionality to replace unqualified officers with new ones when new officers are generated or promoted, otherwise your 125 crew training LCDR may not be able to get an XO job because some nugget with no skills and 45 political rating is loafing on the job instead.

I'm legitimately okay with not replacing underqualified officers and surely anybody else that clicked that option because like myself they just want bodies in seats.

also, officers will gain experience where they are stationed, so a "nugget" with no tactical skill serving as a tactical officer after a year may very well have a 5-10% tac skill.
Title: Re: C# Suggestions
Post by: Density on October 10, 2021, 02:59:05 AM

This would require also a functionality to replace unqualified officers with new ones when new officers are generated or promoted, otherwise your 125 crew training LCDR may not be able to get an XO job because some nugget with no skills and 45 political rating is loafing on the job instead.

I'm legitimately okay with not replacing underqualified officers and surely anybody else that clicked that option because like myself they just want bodies in seats.

also, officers will gain experience where they are stationed, so a "nugget" with no tactical skill serving as a tactical officer after a year may very well have a 5-10% tac skill.

I have yet to see a serving Chief Engineer or Tactical Officer gain experience in their respective skills (nor have I seen a CO gain Engineering or Tactical). As far as I can tell, those skills are only trained by Naval Admins that use the skill in question, or by academy commandants and unassiged commanders getting random skill training.

Meanwhile, I have a naval officer who picked up Xenoarchaeology while waiting for an XO position, and the top officer of my ground forces learned Diplomacy and Intelligence during his stint running an academy.
Title: Re: C# Suggestions
Post by: ArcWolf on October 10, 2021, 07:16:00 AM

also, officers will gain experience where they are stationed, so a "nugget" with no tactical skill serving as a tactical officer after a year may very well have a 5-10% tac skill.

I have yet to see a serving Chief Engineer or Tactical Officer gain experience in their respective skills (nor have I seen a CO gain Engineering or Tactical). As far as I can tell, those skills are only trained by Naval Admins that use the skill in question, or by academy commandants and unassiged commanders getting random skill training.

Meanwhile, I have a naval officer who picked up Xenoarchaeology while waiting for an XO position, and the top officer of my ground forces learned Diplomacy and Intelligence during his stint running an academy.

I don't keep track of every officer skill increase, in fact i usually hide them from the event log because it clutters it up, but i've defiantly seen officers serving as COs of Minning/Terraforming stations gain skill in that field while on station. I assume that is true for all officer roles.
Title: Re: C# Suggestions
Post by: Garfunkel on October 10, 2021, 08:42:51 AM
The question is, do they need to have that skill or not.

It's true and easily verifiable that any officer in a command position will gain relevant skill if they already have it. Thus, captain with survey 5% will have survery 40% after they've commanded a survey vessel long enough. But can you put a captain with no survey skill in the same position and eventually they learn it? This I am unsure of.
Title: Re: C# Suggestions
Post by: Borealis4x on October 10, 2021, 01:40:53 PM
A universal tick box for commanders that stops them from being relieved of their current post after promotion. I like to manually assign all my commanders and it's annoying having to put them back in their positions after a promotion.

Or at least only promote commanders not current out in 'the field' so they don't teleport back to Earth while in the middle of exploring the far reaches of space.
Title: Re: C# Suggestions
Post by: Droll on October 10, 2021, 02:11:15 PM
A universal tick box for commanders that stops them from being relieved of their current post after promotion. I like to manually assign all my commanders and it's annoying having to put them back in their positions after a promotion.

Or at least only promote commanders not current out in 'the field' so they don't teleport back to Earth while in the middle of exploring the far reaches of space.

This is the worst when I intercept NPR commercial shipping and a bunch of them surrender and the production increment rolls over. Now I have to go to every surrendered commercial ship and teleport out all the officers that just teleported in because if I press "abandon ship" I then have to rescue these dumbass commanders.

I just want to have an "exclude class from auto-assignment" button for ships so I don't have to worry about this.
Title: Re: C# Suggestions
Post by: Density on October 10, 2021, 04:30:33 PM

also, officers will gain experience where they are stationed, so a "nugget" with no tactical skill serving as a tactical officer after a year may very well have a 5-10% tac skill.

I have yet to see a serving Chief Engineer or Tactical Officer gain experience in their respective skills (nor have I seen a CO gain Engineering or Tactical). As far as I can tell, those skills are only trained by Naval Admins that use the skill in question, or by academy commandants and unassiged commanders getting random skill training.

Meanwhile, I have a naval officer who picked up Xenoarchaeology while waiting for an XO position, and the top officer of my ground forces learned Diplomacy and Intelligence during his stint running an academy.

I don't keep track of every officer skill increase, in fact i usually hide them from the event log because it clutters it up, but i've defiantly seen officers serving as COs of Minning/Terraforming stations gain skill in that field while on station. I assume that is true for all officer roles.
It's a reasonable assumption (and it's reasonable to hide experience spam in the log). But I didn't say on-the-job training isn't a thing, I specifically called out Engineering and Tactical because I expected it to work in those two cases and I haven't seen it do so.
Title: Re: C# Suggestions
Post by: Density on October 10, 2021, 04:51:09 PM
The question is, do they need to have that skill or not.

It's true and easily verifiable that any officer in a command position will gain relevant skill if they already have it. Thus, captain with survey 5% will have survery 40% after they've commanded a survey vessel long enough. But can you put a captain with no survey skill in the same position and eventually they learn it? This I am unsure of.
I haven't tried it with survey, so I can't verify that specifically (and survey clearly works differently than other skills; +1 vs +5 or 10, and science officers don't seem to get trained in CO skills while other secondary posts do).
But in general, they don't need the skill to get it. This is probably most common with Reaction and Crew Training, where officers get posts from some other skill (logistics for freighters, etc) and eventually they'll get one or both of those skills from being a CO even when they didn't start with them.
Title: Re: C# Suggestions
Post by: ArcWolf on October 10, 2021, 10:28:24 PM

It's a reasonable assumption (and it's reasonable to hide experience spam in the log). But I didn't say on-the-job training isn't a thing, I specifically called out Engineering and Tactical because I expected it to work in those two cases and I haven't seen it do so.

Fair enough, i have not seen it happen with them either.
Title: Re: C# Suggestions
Post by: Garfunkel on October 13, 2021, 06:37:24 PM
Any chance of adding this big chonker in the game? More comets!
https://en.wikipedia.org/wiki/C/2014_UN271_(Bernardinelli-Bernstein) (https://en.wikipedia.org/wiki/C/2014_UN271_(Bernardinelli-Bernstein))
Title: Re: C# Suggestions
Post by: nuclearslurpee on October 13, 2021, 07:16:37 PM
Any chance of adding this big chonker in the game? More comets!
https://en.wikipedia.org/wiki/C/2014_UN271_(Bernardinelli-Bernstein) (https://en.wikipedia.org/wiki/C/2014_UN271_(Bernardinelli-Bernstein))

Seconded as a replacement for that obnoxious comet 200 billion km away that taunts my impotent survey fleets every game until I SM survey it for 100% completion.
Title: Re: C# Suggestions
Post by: Stormtrooper on October 16, 2021, 07:53:30 AM
I would like to see a bunch of early game research projects. It always bothered me how much stuff you get for free after only TN tech research or now, with the addition of some more conventional components, for free. You get cryogenic berths, entertainment centers, passenger transports, cargo shuttles, all without corresponding research. On one hand, this game has this nice feature that allows you to start with Earth and humanity as it is today. On the other hand, you get a bunch of stuff that feel like they'd require some research first. So I'd like it to be a thing for the sake of greater immersion.
Title: Re: C# Suggestions
Post by: TMaekler on October 19, 2021, 03:06:58 PM
When your empire grows a lot, setting up routes becomes a bit tedious. Especially when the galaxy becomes more like a cross-grid where you can go from one point to another by several routes, not remembering which one is the quickest. I thought to circumvent this by saving a route order template with just the jump points - but that of course doesn't help because you have to save it in the destination system - to which you have no access in the source system.

Is there a way to make this possible?
Title: Re: C# Suggestions
Post by: nuclearslurpee on October 19, 2021, 03:15:52 PM
When your empire grows a lot, setting up routes becomes a bit tedious. Especially when the galaxy becomes more like a cross-grid where you can go from one point to another by several routes, not remembering which one is the quickest. I thought to circumvent this by saving a route order template with just the jump points - but that of course doesn't help because you have to save it in the destination system - to which you have no access in the source system.

Is there a way to make this possible?

The feature coming in v2.0 to mark certain jump links to be avoided can be used to eliminate the need to remember the efficient route. You should only need to determine the more efficient branch once and then mark the other to be avoided and after that you can forget all about it. It is a manual approach but it should work fine.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on October 20, 2021, 06:10:23 AM
Something I have wanted for some time which I currently resolve with SM is the ability to convert Regular Industry to Ordnance or Fighter Factories. I usually make the conversion at around 20% of the original cost. So basically I produce 10 Ordnance/Fighter factories and then remove 50 Construction factories and add 40 Ordnance or Fighter factories instead.

I feel it is realistic that we can switch industry back and forth like that based on our needs.

I do feel that refineries and regular industry is different enough that you should not be able to refit them like that, or maintenance facilities for example. But Ordnance and Fighter factories are just factories more or less just more specialized.

So conversions should be

Construction Factory <--> Ordnance Factory
Construction Factory <--> Fighter Factory

You should not be able to convert Ordnance into Fighter factories just from regular industry or back again with a 20% conversion cost.

I know there is an issue with them not using the same resources so you can skirt the rules by incurring some penalties in production cost and an overall 20% increase in cost if you run tight on some resources. But I think that is a minor issue not worth caring much about and probably not a real problem at all to be honest but a trade off.
Title: Re: C# Suggestions
Post by: TMaekler on October 20, 2021, 06:17:09 AM
When your empire grows a lot, setting up routes becomes a bit tedious. Especially when the galaxy becomes more like a cross-grid where you can go from one point to another by several routes, not remembering which one is the quickest. I thought to circumvent this by saving a route order template with just the jump points - but that of course doesn't help because you have to save it in the destination system - to which you have no access in the source system.

Is there a way to make this possible?

The feature coming in v2.0 to mark certain jump links to be avoided can be used to eliminate the need to remember the efficient route. You should only need to determine the more efficient branch once and then mark the other to be avoided and after that you can forget all about it. It is a manual approach but it should work fine.
In general, it would help - though not for jump sequences above 4 systems apart; as well as the blocking can only be used as a general tool. It might be that on a local level of one or two systems apart the jump point needs to be open, but  the longer route might be way shorter via another system, and I don't think that "blocking" can differentiate that.
Title: Re: C# Suggestions (Third time is the charm!)
Post by: hostergaard on October 21, 2021, 12:29:36 PM
I really liked being able to subsidize civilian corporations as I enjoyed having a significant civilian sector. I hope it will return, my suggestion is related to that. Generally speaking I would enjoy seeing a more active and civilian sector able to handle various tasks automatically.


Suggestion: ability to subsidize the creation of civilian mining colonies.

One way would be to pay a given cost to have on created on a body immediately, but that might be too powerfull, instead I suggest that the player should be able to select a body in the system view screen and put a chosen amount of wealth on that body (without creating a colony or anything). This then affects the chance of a mining colony being established on the body, giving it a bonus depending on the wealth placed there. The player can add and remove the wealth as they please, but when a civilian colony is created that money disappears as it is paid out to the mining corporation established.  Similarly, one could consider being able to subsidize the expansion of mining colonies in a similar manner.


Suggestion: Civilian whatever

Generally speaking, there is a high level of entry to this game, and there is also people who enjoy them. To ease that and enable people to focus on parts they prefer, and also making larger empire management easier, make automated civilian solutions a thing so people can select what aspects they want to personally solve and work on and what they want the game to take care of.  It should not be too difficult as there is already a basis for it in the game, with how civilian mining colonies are created with armies, and you can generate ship design and armies at game start. To expand:


- Civilian security/Private armies

Simply like the armies generated for the mining colonies, a player can elect, for a wealth cost, to have civilian armies generated on the planet to take care of defending the planet and policing it. Of course, they are not so finely tuned as a player designed army could be, but at least you don't have to learn the system in its entirety to make viable armies. In the simplest form it could be a checkbox at the beginning in the game that decide for the entire empire that you can uncheck at any time, a checkbox for each colony under the ground units that decide if has a private army.


The exact details of balancing it of course needs to be tested. Fx, the armies don't just appear or disappear immediately but take some time to do so and while costing wealth to simulate time to hire/train/transport individuals. Perhaps there would be some mineral requirements. They player could let the game completely generate armies on their own, or you could give them an option to decide certain aspect on their own like, size, police strength, what they should be able to defend against, etc.

Or perhaps more simple, private security companies could generate various armies of different sizes according to colony size. Possibly then you could ship private armies from populated colonies to unpopulated colonies if necessary.

- Civilian Fleets

Similarly civilian fleets could be generated tough likely with both wealth and mineral costs. The level of control the player have needs to be balanced, either by selection on game start, trough science or the same. Furthermore, how much the player can control the design and at what granularity would have to be figured out, but basically its so new players can have the option of just generating fleets that work more like NPR fleets that works for the player. However, it can enable roleplaying and give the ability for the player to design empires with more interesting government types. An interesting consequence would be that privateer fleets could be generated, basically independent fleets, with no or little colonies, that can be given letters of marquee to raid enemies of civilisations. Or just good old pirate ships :D Tough, of course, a checkbox to generate such things or should be there at game creation like the spawning of civilian fuel harvesters.

--Civilian defence bases (or rather, civilian PPV)

More or less extension of the previous suggestion, but limited to creating fleets for defensive purposes of a planet/system to fulfil PPV. So probably just bases of various kinds.

- Civilian designed ships

Again to make things easier for new players who wants to make their own fleet, but not yet delve into designing ships, this is more of a functionally thing, they can have ship design be automatically generate classes of ships with current technology. And again, at various level of granularity ranging from, generate cruiser, to ant-ship destroyer to more exact specification like ship size, engangement range and so on.

- Civilian racial tech

I remembered I made a similar suggestion once, so I found the link here:

http://aurora2.pentarch.org/index.php?topic=9630.msg103714#msg103714

- Investing in Civilian companies

This more for roleplaying sake than anything, let be able to buy stocks in the companies. Owning a company completely would give you all of its profits, and costs. This way, players with communist civilisation could use the system, but not have it conflict with their roleplaying. Then its more civilian iniatives rather than companies.

- Civilian government of planets

The idea for me at first was roleplay, its a common trope for galactic civilisations to have planets sold or governed by private companies. So you could offload various responsibilities to a civilian government, ranging from specific responsibilities like constructions to everything like armies, PPV fleets and so on. You could set various targets for them to meet at various level of granularity, say, pop size, construction ability and so on and they will try to meet them with the recourses available. One could expand this to also be defined on a system and sector basis

- Subject Empires

At this point if you have entire, planets systems and sectors be civilian controlled with civilian armies and fleets, you are reaching a point where they are basically non-player vasal empires. So why not give the player ability to make them independed actual vasals empires if they so choose. The level of independence could of course be defined of various level of granularity, from near independed paying a tite of wealth and minerals possibly, to near integrated where they player can direct colonies, armies and fleets more or less as they please. This would also allow you to concur enemy races as have them become vasals instead of being completely destroyed.
Title: Re: C# Suggestions
Post by: Stormtrooper on October 21, 2021, 01:48:15 PM
I know this probably was suggested already, but I just want to make sure it doesn't get lost... Could Invaders also be made to improve their tech and ships over time like pirates do? I love them so much and I want to play with them, but it gets old and pointless really fast when past some point they turn from a threat and interesting addition to mild irritation after they can't harm you anymore. If they were improving, they'd have the chance to become the ultimate AI enemy that can keep up with the player through, if not whole, at least most of the game.
Title: Re: C# Suggestions
Post by: xenoscepter on October 21, 2021, 02:20:27 PM
 --- Internal Armor: In the Class Design Window, I'd like to see a second box for "Internal Armor". This would function just like Turret Armor, adding HtK per layer for each component added to the ship. So a ship with say, 5 Crew Quarters, an Engine and some smattering of other parts would have more HtK with 1 layer of Internal Armor over the exact same ship with 0, and so on and so forth. They would be heavier and more expensive than a ship without of course. :)

 --- "Bunker / Transport / Transport - Small" Ground Modules: For Static units only, Bunker modules would be a component that could apply the Static Unit's extra armor to all units either in the same formation as itself or those directly supporting it. It would have a specified tonnage much like an HQ module and would give diminishing returns much like an HQ module if more units than it can handle are added. Transport Modules would work the same way, but would only be for vehicles. Bunker modules would also confer their Hit Mod, that being of a Static unit as well as all other limitations of a Static unit to it's formation and any assigned to directly support it. Transport Modules would confer the Vehicle's armor and Hit Mods as well along with the Armor bonus for breakthroughs to any unit within it's formation. Transport modules would also differ from Bunker modules in that they would need to be directly support a formation to confer their bonus to it if not actually within the formation itself, while Bunkers would need to have formations assigned to directly support them instead. Transport - Small Modules would be smaller than regular Transport Modules, but would only count infantry. All three modules would confer their Terrain / Environment bonuses to units alongside their Hit Mod, Armor and other imitations, but only at half the rate. A new Ground Commander Trait, "Mechanized Operations" or something like that, could increase this... maybe up to like... 75% or something, idk.

 --- Missile Batteries: An STO unit that draws from the planet's own stockpiles. Missile Batteries use existing Missile Launchers, much like regular STOs, but any launcher used in them has double the fire rate. Missile Batteries consume ordinance from the planet's stockpiles, using missiles that are specified for them via some new UI element.
Title: Re: C# Suggestions
Post by: Droll on October 21, 2021, 02:47:58 PM
--- Internal Armor: In the Class Design Window, I'd like to see a second box for "Internal Armor". This would function just like Turret Armor, adding HtK per layer for each component added to the ship. So a ship with say, 5 Crew Quarters, an Engine and some smattering of other parts would have more HtK with 1 layer of Internal Armor over the exact same ship with 0, and so on and so forth. They would be heavier and more expensive than a ship without of course. :)

 --- "Bunker / Transport / Transport - Small" Ground Modules: For Static units only, Bunker modules would be a component that could apply the Static Unit's extra armor to all units either in the same formation as itself or those directly supporting it. It would have a specified tonnage much like an HQ module and would give diminishing returns much like an HQ module if more units than it can handle are added. Transport Modules would work the same way, but would only be for vehicles. Bunker modules would also confer their Hit Mod, that being of a Static unit as well as all other limitations of a Static unit to it's formation and any assigned to directly support it. Transport Modules would confer the Vehicle's armor and Hit Mods as well along with the Armor bonus for breakthroughs to any unit within it's formation. Transport modules would also differ from Bunker modules in that they would need to be directly support a formation to confer their bonus to it if not actually within the formation itself, while Bunkers would need to have formations assigned to directly support them instead. Transport - Small Modules would be smaller than regular Transport Modules, but would only count infantry. All three modules would confer their Terrain / Environment bonuses to units alongside their Hit Mod, Armor and other imitations, but only at half the rate. A new Ground Commander Trait, "Mechanized Operations" or something like that, could increase this... maybe up to like... 75% or something, idk.

 --- Missile Batteries: An STO unit that draws from the planet's own stockpiles. Missile Batteries use existing Missile Launchers, much like regular STOs, but any launcher used in them has double the fire rate. Missile Batteries consume ordinance from the planet's stockpiles, using missiles that are specified for them via some new UI element.

I like all of these, internal armor would have to be incredibly expensive (tonnage and resource-wise) for it to be balanced IMO and also unavailable for stations that use structural shells.
Your bunker/transport idea is interesting because it allows infantry to better play a much larger role in offensives and also allows the player to explicitly define APCs/IFVs that transport troops.
Title: Re: C# Suggestions
Post by: xenoscepter on October 21, 2021, 03:09:51 PM
~snip snip~

I like all of these, internal armor would have to be incredibly expensive (tonnage and resource-wise) for it to be balanced IMO and also unavailable for stations that use structural shells.
Your bunker/transport idea is interesting because it allows infantry to better play a much larger role in offensives and also allows the player to explicitly define APCs/IFVs that transport troops.

 --- The Internal Armor wouldn't really need to be any more or less expensive in terms of resources or tonnage than Turret Armor already is. For one, since it adds HtK to everything mounted, this scales up tonnage wise quite quickly indeed. Secondly, since more armor already costs more anyway, you might as well just make it cost whatever that many layers would. Finally, HtK requires more repairs to fix and such is rather balanced in the sense that an Internally Armored ship may survive, but will be out of action while it undertakes repairs.
Title: Re: C# Suggestions
Post by: TMaekler on October 23, 2021, 06:20:16 AM
Wouldn't it be nice to build a space station hidden somewhere in your system, tow a shipyard there and begin building your dark ops section 31 ships there?  ;D
Title: Re: C# Suggestions
Post by: Platys51 on October 24, 2021, 06:43:52 AM
"colonise all mineral rich bodies" and "purge all empty colonies" buttons for using mining ships without developing carpal tunnel.
If possible, "gather minerals from colonies in system" would be nice too, or add it as part of the mining ship routine to gather them before moving on.
Title: Re: C# Suggestions
Post by: ArcWolf on October 24, 2021, 10:32:50 AM
"colonise all mineral rich bodies" and "purge all empty colonies" buttons for using mining ships without developing carpal tunnel.
If possible, "gather minerals from colonies in system" would be nice too, or add it as part of the mining ship routine to gather them before moving on.

FYI: there is already a button to delete all empty colonies. Under the Econ screen -> Summary Screen, at the bottom of the screen there are a few buttons, one is "Rename Pop". The last button on the right is 'Delete empty" Which will do half of what you a looking for.
Title: Re: C# Suggestions
Post by: Platys51 on October 24, 2021, 02:03:38 PM
FYI: there is already a button to delete all empty colonies. Under the Econ screen -> Summary Screen, at the bottom of the screen there are a few buttons, one is "Rename Pop". The last button on the right is 'Delete empty" Which will do half of what you a looking for.
Will it keep colonies that still have minerals on them?
Title: Re: C# Suggestions
Post by: Droll on October 24, 2021, 02:09:27 PM
FYI: there is already a button to delete all empty colonies. Under the Econ screen -> Summary Screen, at the bottom of the screen there are a few buttons, one is "Rename Pop". The last button on the right is 'Delete empty" Which will do half of what you a looking for.
Will it keep colonies that still have minerals on them?

If by minerals you mean mineral stockpiles you've mined then yes, if you just mean minerals still in the ground then no.

However, there is a button to exempt colonies from auto-deletion, so for every empty colony with minerals you can exempt them from the auto-delete process, which unfortunately needs to be done for every planet. Also if you completely mine out one of these worlds and want it to be deleted once empty you'll have to un-exempt it from this status.
Title: Re: C# Suggestions
Post by: nuclearslurpee on October 24, 2021, 02:17:59 PM
FYI: there is already a button to delete all empty colonies. Under the Econ screen -> Summary Screen, at the bottom of the screen there are a few buttons, one is "Rename Pop". The last button on the right is 'Delete empty" Which will do half of what you a looking for.
Will it keep colonies that still have minerals on them?

No.

It sounds as if you are trying to find a micro-free way to prevent CMCs from spawning. While this doesn't really exist, unless you have a roleplay reason you should not be afraid to allow CMCs to spawn. They are an extremely efficient way to acquire resources (wealth is not a pressing issue in Aurora beyond the very early game, usually) and there is nothing that stops you from also placing your own mines on the same body if you need those specific minerals faster than the CMC is providing them to you.

I usually designate 1-3 of the choice bodies as "strategic reserves" which I focus all of my mines on (usually enough to ensure high rates of duranium, corundium, and gallicite acquisition) and leave the rest for the CMCs, and this works quite well for the early Sol years.
Title: Re: C# Suggestions
Post by: Ektor on October 26, 2021, 08:25:27 PM
Quasar has added standing order that allow player built ships to act as civilian freighters that can transport trade goods. I know this is pretty low on priority but I'd LOVE to see this added, I'd love to have a game with all military ships where I need to maintain my freight lines, including "civilian" ones. A small scale game so I won't go insane from micro, but this would be so nice to have in C#!

Edit: I apparently misunderstood this. The order only lets them fulfill civilian contracts you set for installations, it would still be useful.
Title: Re: C# Suggestions
Post by: Pury on November 01, 2021, 04:11:04 PM
I would suggest changing Support unit Defensive calculations from using just Fortification to dynamic system, where it uses Fortification if it supports Units in defence, and to Hit mod if it supports units during attack.   It might better reflect combat for role play, as Artillery (Without colossal range, represented in game with Heavy Arty in rear echelons) would have to move with the attacking units, thus leaving the comfort of their entrenched positions.   Also it would give more reason to Mechanize your Arty, as now the Hit mod would help them avoid getting hit while Supporting the front line. 

Edit.  This would be especially Helpful during planetary assaults, where theoretically there is not much time to dig in your arty.
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 01, 2021, 04:31:50 PM
I would suggest changing Support unit Defensive calculations from using just Fortification to dynamic system, where it uses Fortification if it supports Units in defence, and to Hit mod if it supports units during attack.   It might better reflect combat for role play, as Artillery (Without colossal range, represented in game with Heavy Arty in rear echelons) would have to move with the attacking units, thus leaving the comfort of their entrenched positions.   Also it would give more reason to Mechanize your Arty, as now the Hit mod would help them avoid getting hit while Supporting the front line. 

Edit.  This would be especially Helpful during planetary assaults, where theoretically there is not much time to dig in your arty.

This would be nice, as currently LVH artillery is strictly inferior to STA artillery. While I do generally subscribe to the philosophy that not every element of the game needs to be equally viable, given the obvious use for modeling real-world military equipment it would be nice if "traditional" SP howitzers were not clearly inferior to their towed counterparts.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on November 01, 2021, 06:16:36 PM
I would suggest changing Support unit Defensive calculations from using just Fortification to dynamic system, where it uses Fortification if it supports Units in defence, and to Hit mod if it supports units during attack.   It might better reflect combat for role play, as Artillery (Without colossal range, represented in game with Heavy Arty in rear echelons) would have to move with the attacking units, thus leaving the comfort of their entrenched positions.   Also it would give more reason to Mechanize your Arty, as now the Hit mod would help them avoid getting hit while Supporting the front line. 

Edit.  This would be especially Helpful during planetary assaults, where theoretically there is not much time to dig in your arty.

This would be nice, as currently LVH artillery is strictly inferior to STA artillery. While I do generally subscribe to the philosophy that not every element of the game needs to be equally viable, given the obvious use for modeling real-world military equipment it would be nice if "traditional" SP howitzers were not clearly inferior to their towed counterparts.


I think the entire system needs some adjustments as defending forces should not really be engaging each other at all.

I think there are a few conceptual things that should eventually be looked at... which are formation compositions and units supporting each other in a meaning full way.

A concept of attack and defense on planets, especially important for multi-faction role-play where you need to actually attack someone to damage them and where defensive forces can't engage each other directly.

There also should be a maximum of numbers (or size) than may engage in any 8 hour combat resolution based on the number of defensive/offensive numbers of the opponent. You only can squeeze so much frontline forces at the enemy defensive line on one go, that would also make reserves and support units, including air support more meaningful too.

But all of this should probably come later when Steve take a new closer look at the ground combat mechanic some times in the future.
Title: Re: C# Suggestions
Post by: Froggiest1982 on November 02, 2021, 03:07:49 AM
For RP purposes and for the "Endgame" feature I would like to have a NULL tech to research forever or a NO research button somewhere like for maintenance and fuel.

This could help with the tedious message and interruption of having no labs assigned to any research.

I know you currently can pause any project and freeze your research and even when everything has been researched you can create a small component and pause the research but still, you'll have to do it for every planet with research labs.

Eventually, if we get the NO research function we also avoid reassigning them once the scientists inevitably die.
Title: Re: C# Suggestions
Post by: ArcWolf on November 03, 2021, 11:19:07 AM
For RP purposes and for the "Endgame" feature I would like to have a NULL tech to research forever or a NO research button somewhere like for maintenance and fuel.

This could help with the tedious message and interruption of having no labs assigned to any research.

I know you currently can pause any project and freeze your research and even when everything has been researched you can create a small component and pause the research but still, you'll have to do it for every planet with research labs.

Eventually, if we get the NO research function we also avoid reassigning them once the scientists inevitably die.

alternatively, the option to turn on or off specific interrupts would be nice.
Title: Re: C# Suggestions
Post by: smoelf on November 06, 2021, 08:10:09 AM
An option to play a sound effect when auto-turns are interrupted. That way you can easily put Aurora to run in the background and do other stuff without worrying too much about checking often to see if there is an interrupt.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on November 06, 2021, 08:12:58 AM
For RP purposes and for the "Endgame" feature I would like to have a NULL tech to research forever or a NO research button somewhere like for maintenance and fuel.

This could help with the tedious message and interruption of having no labs assigned to any research.

I know you currently can pause any project and freeze your research and even when everything has been researched you can create a small component and pause the research but still, you'll have to do it for every planet with research labs.

Eventually, if we get the NO research function we also avoid reassigning them once the scientists inevitably die.

alternatively, the option to turn on or off specific interrupts would be nice.

I think you can use the DB to define which type of message interrupts the auto turns... but you can't define new message types.
Title: Re: C# Suggestions
Post by: QuakeIV on November 06, 2021, 11:41:00 PM
For RP purposes and for the "Endgame" feature I would like to have a NULL tech to research forever or a NO research button somewhere like for maintenance and fuel.

This could help with the tedious message and interruption of having no labs assigned to any research.

I know you currently can pause any project and freeze your research and even when everything has been researched you can create a small component and pause the research but still, you'll have to do it for every planet with research labs.

Eventually, if we get the NO research function we also avoid reassigning them once the scientists inevitably die.

alternatively, the option to turn on or off specific interrupts would be nice.

http://aurora2.pentarch.org/index.php?topic=11780.0 (http://aurora2.pentarch.org/index.php?topic=11780.0)

I did make a tool for this (it says 1.12 but it still works fine).
Title: Re: C# Suggestions
Post by: ArcWolf on November 07, 2021, 02:28:03 AM

http://aurora2.pentarch.org/index.php?topic=11780.0 (http://aurora2.pentarch.org/index.php?topic=11780.0)

I did make a tool for this (it says 1.12 but it still works fine).

Nice, i'll give it a try with my next campaign. Still does not mean we can't ask for it to be integrated into the game.
Title: Re: C# Suggestions
Post by: Pury on November 07, 2021, 02:37:36 PM
I suggest to connect Crew grade and Boarding combat, as more experienced crews should be better at defending their ship. I would consider it in at least one of the following:

-Decrease chance for the ship to sustain dmg from boarding combat.

-Increase Crew survival ability, by giving them some fortification Bonus.

Title: Re: C# Suggestions
Post by: QuakeIV on November 07, 2021, 03:09:59 PM

http://aurora2.pentarch.org/index.php?topic=11780.0 (http://aurora2.pentarch.org/index.php?topic=11780.0)

I did make a tool for this (it says 1.12 but it still works fine).

Nice, i'll give it a try with my next campaign. Still does not mean we can't ask for it to be integrated into the game.

Concur I would prefer it be in the base game and hope that my tool here will justify it as a fairly safe and good feature to add
Title: Re: C# Suggestions
Post by: Velociranga on November 10, 2021, 11:47:54 PM
I hope this hasn't been brought up before but I have a suggestion around the supply ship toggle.

As per my current understanding (and please correct me if I am wrong) for a ship to supply another ship it needs to have both the supply ship box check and at least one cargo shuttle.

However a ship with the supply ship box ticked can not be supplied by another supply ship, it must take MSP from a colony.

This isn't a huge deal for mobile supply ships as it fits there role.  However it currently makes space stations unusable as forward operation bases as far as supply goes.  The station can either dole out supplies or receive them but not both.  I believe this is due to the way supply is handled by aurora and I understand it might be a bit difficult to fix.  But perhaps changing the way supply works for space stations/orbital habitats, that way its possible to create FOB's away from planets.  Without affecting how mobile supply ships currently function.
Title: Re: C# Suggestions
Post by: ArcWolf on November 12, 2021, 12:29:36 AM
I hope this hasn't been brought up before but I have a suggestion around the supply ship toggle.

As per my current understanding (and please correct me if I am wrong) for a ship to supply another ship it needs to have both the supply ship box check and at least one cargo shuttle.

However a ship with the supply ship box ticked can not be supplied by another supply ship, it must take MSP from a colony.

This isn't a huge deal for mobile supply ships as it fits there role.  However it currently makes space stations unusable as forward operation bases as far as supply goes.  The station can either dole out supplies or receive them but not both.  I believe this is due to the way supply is handled by aurora and I understand it might be a bit difficult to fix.  But perhaps changing the way supply works for space stations/orbital habitats, that way its possible to create FOB's away from planets.  Without affecting how mobile supply ships currently function.

It is not ideal, but you can resupply Forward Operating stations from supply ships. Have the supply ship rendezvous with the station, do no merge the fleets. Then give the fleet with the Station the movement order to "Resupply from stationary Supply Ship". It might take a few tries, but it does work. Both Station and Ship are set to "Resupply Own Fleet" incase that makes any difference.
Title: Re: C# Suggestions
Post by: somebody1212 on November 13, 2021, 04:43:36 PM
Consistency in displaying the number of shots that a weapon fires for Gauss, Railguns and Turrets.

Currently:
Gauss indicates the number of shots they fire next to the RoF:
Damage Output 1      Rate of Fire 6 / 5s     Range Modifier 60 000
Max Range 60 000 km     Size 1 HS  (50 tons)    HTK 1


Railguns indicate the number of shots they fire next to the damage:
Damage Per Shot (4) 16     Rate of Fire 25 seconds     Range Modifier 80 000
Max Range 1 280 000 km     Railgun Size 13.0 HS  (650 tons)    Railgun HTK 6
Power Requirement 48    Recharge Rate 10


Turrets do neither, and since the rate of fire isn't stated in the default Gauss naming scheme this has been catching a lot of newer players out:
Damage Output 1    Rate of Fire 5 seconds     Range Modifier 60 000
Max Range 60 000 km     Turret Size 4.26 HS  (213 tons)     HTK 4


This has come up quite a few times on the Discord, usually from people who have just upgraded their Gauss rate of fire, designed a new turret and are confused as to why they appear to have two copies of the same module, since they can't see the rate of fire until they add the turrets to their ship and if the names have been left at the defaults the two turrets both have the same name.
Title: Re: C# Suggestions
Post by: Velociranga on November 15, 2021, 06:56:34 PM
Quote from: ArcWolf link=topic=10640. msg156721#msg156721 date=1636698576
Quote from: Velociranga link=topic=10640. msg156697#msg156697 date=1636609674
I hope this hasn't been brought up before but I have a suggestion around the supply ship toggle. 

As per my current understanding (and please correct me if I am wrong) for a ship to supply another ship it needs to have both the supply ship box check and at least one cargo shuttle. 

However a ship with the supply ship box ticked can not be supplied by another supply ship, it must take MSP from a colony. 

This isn't a huge deal for mobile supply ships as it fits there role.   However it currently makes space stations unusable as forward operation bases as far as supply goes.   The station can either dole out supplies or receive them but not both.   I believe this is due to the way supply is handled by aurora and I understand it might be a bit difficult to fix.   But perhaps changing the way supply works for space stations/orbital habitats, that way its possible to create FOB's away from planets.   Without affecting how mobile supply ships currently function.

It is not ideal, but you can resupply Forward Operating stations from supply ships.  Have the supply ship rendezvous with the station, do no merge the fleets.  Then give the fleet with the Station the movement order to "Resupply from stationary Supply Ship".  It might take a few tries, but it does work.  Both Station and Ship are set to "Resupply Own Fleet" incase that makes any difference.

I'll give that a try but I was sure even doing it that way it didn't resupply.  I tried a couple of different ways to reduce the micromanagement but trying to get the different fleets orders to line up with travel and resupply time made my head hurt.  Either way I feel like we really need a way to initiate the resupply from the supply ship side without joining the fleet you want it to resupply. 
Title: Re: C# Suggestions
Post by: Impassive on November 16, 2021, 05:29:33 AM
Quote from: ArcWolf link=topic=10640. msg156721#msg156721 date=1636698576
Quote from: Velociranga link=topic=10640. msg156697#msg156697 date=1636609674
I hope this hasn't been brought up before but I have a suggestion around the supply ship toggle. 

As per my current understanding (and please correct me if I am wrong) for a ship to supply another ship it needs to have both the supply ship box check and at least one cargo shuttle. 

However a ship with the supply ship box ticked can not be supplied by another supply ship, it must take MSP from a colony. 

This isn't a huge deal for mobile supply ships as it fits there role.   However it currently makes space stations unusable as forward operation bases as far as supply goes.   The station can either dole out supplies or receive them but not both.   I believe this is due to the way supply is handled by aurora and I understand it might be a bit difficult to fix.   But perhaps changing the way supply works for space stations/orbital habitats, that way its possible to create FOB's away from planets.   Without affecting how mobile supply ships currently function.

It is not ideal, but you can resupply Forward Operating stations from supply ships.  Have the supply ship rendezvous with the station, do no merge the fleets.  Then give the fleet with the Station the movement order to "Resupply from stationary Supply Ship".  It might take a few tries, but it does work.  Both Station and Ship are set to "Resupply Own Fleet" incase that makes any difference.

I'll give that a try but I was sure even doing it that way it didn't resupply.  I tried a couple of different ways to reduce the micromanagement but trying to get the different fleets orders to line up with travel and resupply time made my head hurt.  Either way I feel like we really need a way to initiate the resupply from the supply ship side without joining the fleet you want it to resupply.

What I currently do is move the resupply ship to the space station, then get the space station to resupply from the ship. So it's possible to do but without a transfer supplies option for the resupply ship it can't currently be automated unless I'm missing something.

Is there anyway to fill up fuel and maintenance on a planet to a stockpile like minerals? This would also allow the automation of logistics for these to colonies.
Title: Re: C# Suggestions
Post by: Velociranga on November 17, 2021, 06:53:30 PM
Quote from: Impassive link=topic=10640. msg156809#msg156809 date=1637062173
Quote from: Velociranga link=topic=10640. msg156804#msg156804 date=1637024194
Quote from: ArcWolf link=topic=10640.  msg156721#msg156721 date=1636698576
Quote from: Velociranga link=topic=10640.  msg156697#msg156697 date=1636609674
I hope this hasn't been brought up before but I have a suggestion around the supply ship toggle.   

As per my current understanding (and please correct me if I am wrong) for a ship to supply another ship it needs to have both the supply ship box check and at least one cargo shuttle.   

However a ship with the supply ship box ticked can not be supplied by another supply ship, it must take MSP from a colony.   

This isn't a huge deal for mobile supply ships as it fits there role.    However it currently makes space stations unusable as forward operation bases as far as supply goes.    The station can either dole out supplies or receive them but not both.    I believe this is due to the way supply is handled by aurora and I understand it might be a bit difficult to fix.    But perhaps changing the way supply works for space stations/orbital habitats, that way its possible to create FOB's away from planets.    Without affecting how mobile supply ships currently function. 

It is not ideal, but you can resupply Forward Operating stations from supply ships.   Have the supply ship rendezvous with the station, do no merge the fleets.   Then give the fleet with the Station the movement order to "Resupply from stationary Supply Ship".   It might take a few tries, but it does work.   Both Station and Ship are set to "Resupply Own Fleet" incase that makes any difference. 

I'll give that a try but I was sure even doing it that way it didn't resupply.   I tried a couple of different ways to reduce the micromanagement but trying to get the different fleets orders to line up with travel and resupply time made my head hurt.   Either way I feel like we really need a way to initiate the resupply from the supply ship side without joining the fleet you want it to resupply. 

What I currently do is move the resupply ship to the space station, then get the space station to resupply from the ship.  So it's possible to do but without a transfer supplies option for the resupply ship it can't currently be automated unless I'm missing something. 

Is there anyway to fill up fuel and maintenance on a planet to a stockpile like minerals? This would also allow the automation of logistics for these to colonies.

I can confirm that this works, the supply ship just has to be outside the fleet with the supply ship you are trying to resupply.  And it is theoretically possible to automate it.  You would just have to calculate the time to resupply the fleet and travel time for the supply ship and have the resupply from stationary supply ship order delayed by that time.  However having tried to do this the math was hurting my brain.

I'm not sure on the stockpile for fuel and supplies.  Honestly if we just get an order to resupply a target fleet with a fleet that will keep me happy.
Title: Re: C# Suggestions
Post by: pwhk on November 18, 2021, 05:40:47 AM
Not sure if it has been mentioned elsewhere, but...
The "Unload Survivors" order should be available on a fleet after making a "Rescue Survivor" order. It does not show up currently and we need to wait for the ship to have actually rescued the survivors before able to make the unload order.
Title: Re: C# Suggestions
Post by: pwhk on November 18, 2021, 05:44:01 AM
Another suggestion, double click on "Events" window goes to where it happens on the main screen. However, this does not apply when clicking on events happening on other races, which can be seen with SM option "Show All Races" on. Would be nice if it does, changing the active race.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on November 18, 2021, 10:23:54 AM
I would like to have some form of special forces operations groups that we could use for special missions to planets, such as acting as FOB or to locate and help taking out ground to orbit batteries, perhaps by making it easier to hit them with ships in orbit.

I'm sure we could find other interesting things for special forces to do on a planets surface during conflicts. We probably could also insert them during peace time as well and activate them if there is a conflict, in the mean time they simply perform Intel operations.

There obviously should be some way to combat special forces, perhaps your own special forces... there also could be stealth technologies available to help these forces stay hidden and provide Intel on potential enemies.

Special forces are extremely important in the modern battle-space, I would say even more important than regular forces in many regards as intelligence and as a force multiplier for indirect weapons and air support is very effective against conventional forces.

At least I would like to see some expanding on the concept of special forces in Aurora.
Title: Re: C# Suggestions
Post by: ArcWolf on November 18, 2021, 01:42:52 PM
Currently in SM mode, in the System Gen & Display we can add a "Random Ruin" to a planet/body. It would be nice if there were an additional button for "Specify Ruin" which would bring up a drop-down where we can select the type of ruin/construct & % bonus. This would make setting up stories/events less tedious.

So 2 buttons, 'Random Ruin", because sometimes you just want it to be random, and "Specify Ruin".
Title: Re: C# Suggestions
Post by: Abridal on November 20, 2021, 02:45:52 AM
Add a "No Armour" Type in Unit Class Design. Probably should be exclusive for infantry.

Reduces unit cost by half of the default cost, thus where for a example a PWL with light infantry armor would cost 0.06 per unit an authentic imperial guard(TM) would cost only 0.03, with of course 0 Armour regardless of Tech Level. Maybe the cost reduction should be even bigger than 50% to make it something that can be seriously considered as a strategic option.

(https://i.ibb.co/KL6tD6Y/Guardsman.jpg)

In addition to becoming standard issue for forces the image above depicts accurately, it also would be choice for genetically engineered berserkers.
Title: Re: C# Suggestions
Post by: Blogaugis on November 20, 2021, 02:51:17 AM
Add a "No Armour" Type in Unit Class Design. Probably should be exclusive for infantry.

Reduces unit cost by half of the default cost, thus where for a example a PWL with light infantry armor would cost 0.06 per unit an authentic imperial guard(TM) would cost only 0.03, with of course 0 Armour regardless of Tech Level. Maybe the cost reduction should be even bigger than 50% to make it something that can be seriously considered as a strategic option.

(https://i.ibb.co/KL6tD6Y/Guardsman.jpg)

In addition to becoming standard issue for forces the image above depicts accurately, it also would be choice for genetically engineered berserkers.
Hilarious, but...
Hm... Considering that pirates are in plans, how about technicals - vehicles that are basically shopping carts from Walmart with an engine and a 50Cal?
Title: Re: C# Suggestions
Post by: Jorgen_CAB on November 20, 2021, 07:19:10 AM
While we are talking about ground combat... I would propose to remove the Logostics module from Infantry or do some mechanic where you must have them and then make vehicle supply modules more efficient than infantry supply units.

Currently there is NO reason to ever use vehicle based supply units as Infantry ones are cheaper. You just use the reserve mechanic to replace the infantry ones when they are consumed or destroyed. They are way more efficient and thus cheap to use than vehicle supply units. I always ban the use of infantry based supply units in my games unless they fit the theme such as a special forces unit meant to operate independently or something.

You should be able to use zero armor for vehicles as well, but that might need some consideration for balancing cost of certain units such as construction, supply etc... In general I think the armour perhaps should not be zero but half probably are more realistic, even Imperial Guards in 40k have flak armour which are similar to modern body armour.
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 20, 2021, 09:46:32 AM
Add a "No Armour" Type in Unit Class Design. Probably should be exclusive for infantry.

Reduces unit cost by half of the default cost, thus where for a example a PWL with light infantry armor would cost 0.06 per unit an authentic imperial guard(TM) would cost only 0.03, with of course 0 Armour regardless of Tech Level. Maybe the cost reduction should be even bigger than 50% to make it something that can be seriously considered as a strategic option.

It is difficult to overstate how tremendously OP this would be. Base ARM 1 on infantry is already usually ineffective unless you out-tech the enemy, as no weapon except for PWL has less than 1.0 penetration, so making infantry even cheaper by giving them "no armor" would make what are already a very efficient class of units incredibly dominant just due to how cheap and spammable they will be.

It is better to understand that ARM 1 is the base army uniform which gives whatever minimal armor level is appropriate for your setting, and go from there.

While we are talking about ground combat... I would propose to remove the Logostics module from Infantry or do some mechanic where you must have them and then make vehicle supply modules more efficient than infantry supply units.

Currently there is NO reason to ever use vehicle based supply units as Infantry ones are cheaper. You just use the reserve mechanic to replace the infantry ones when they are consumed or destroyed. They are way more efficient and thus cheap to use than vehicle supply units. I always ban the use of infantry based supply units in my games unless they fit the theme such as a special forces unit meant to operate independently or something.

I have found a good balance by modding the DB so that the large LOG component provides 1000 GSP (instead of 500) and restricting it only to LVH.

As it stands in the vanilla settings, there is never any reason for infantry to use the 50-ton module over the 10-ton module - they provide the same GSP per ton or per BP, but the smaller module allows more individual units and thus is more resilient to enemy fire. Thus, removing the INF+LOG (leaving only INF+LOG-S unit from the game is no loss at all. Doing this allows increasing the value of the large LOG component without upsetting the balance of infantry logistics.

This makes the LVH+LOG a tonnage-efficient way of deploying supplies (62 tons per 1,000 versus 100 tons for infantry logistics), but still only 80% as cost-efficient as infantry logistics (2.48 BP per 1,000 versus 2.0 BP for 10x infantry logistics units), so that there is an interesting and useful tradeoff between the two unit types. With this change I usually have a practice of using INF logistics for organic supply of frontline or other combat formations (e.g., artillery) and LVH logistics in rear-echelon HQs for resupply. Both have their advantages and disadvantages which IMO is how it should be - and was prior to 1.12 albeit in a rather contrived way.
Title: Re: C# Suggestions
Post by: serger on November 20, 2021, 03:41:29 PM
I think INF+LOG are quite vulnerable in frontline formations, especially when attacking, so 62 log-tons on the rear can be still better of 100 log-tons on the front.
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 20, 2021, 11:42:12 PM
I think INF+LOG are quite vulnerable in frontline formations, especially when attacking, so 62 log-tons on the rear can be still better of 100 log-tons on the front.

The problem is the build cost, 2.48 BP/500 GSP versus 1.0 BP/500 GSP is not even a competition. With the replacements system in 1.12+ you can lose front-line formation logistics elements from enemy fire, in addition to supply consumption, and replenish them from a supply dump in the rear echelon and still save a lot of build points compared to vehicle-based logistics.

With the replacements system you only need enough supply units to last about 20 rounds of combat, which is enough to fight for 5 days plus some extra to cover losses, and then the replacements will arrive at the construction increment. For most formations this is perhaps only 5% of the total tonnage and as non-combat units the logistics have 1/4 the usual chance to be targeted, so losses are not really very high except in cases of bad RNG.
Title: Re: C# Suggestions
Post by: alex_brunius on November 22, 2021, 02:00:02 PM
In the spirit of the Additional conventional systems (http://aurora2.pentarch.org/index.php?topic=12523.msg155095#msg155095) change, it might be a good idea to make the Fighter pod techs a bit cheaper than 5000 RP each as well ( maybe 500 or 1000 ) to promote the use of conventional fighters and ground support?

Both from a plausibility standpoint and a gameplay standpoint ( since you have a bit of fighter production capacity as a conventional empire ) it feels strange to me that empires transition to TN tech without air-support typically.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on November 22, 2021, 08:24:43 PM
In the spirit of the Additional conventional systems (http://aurora2.pentarch.org/index.php?topic=12523.msg155095#msg155095) change, it might be a good idea to make the Fighter pod techs a bit cheaper than 5000 RP each as well ( maybe 500 or 1000 ) to promote the use of conventional fighters and ground support?

Both from a plausibility standpoint and a gameplay standpoint ( since you have a bit of fighter production capacity as a conventional empire ) it feels strange to me that empires transition to TN tech without air-support typically.

I usually play with very reduced research cost and I always reduce the cost of certain technologies like this as the cost of certain techs become a bit prohibitive in that context in my opinion. I also increase the amount of technology you can research in other categories up to about 30 levels from 10-15 levels om most technologies and reduce the step in each as well. I probably should just play on normal tech progression as I practically change almost every technology in the tree anyway.   ;)
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 22, 2021, 10:40:34 PM
Both from a plausibility standpoint and a gameplay standpoint ( since you have a bit of fighter production capacity as a conventional empire ) it feels strange to me that empires transition to TN tech without air-support typically.

I honestly think it would be better to get rid of ground support fighters as they currently stand and have them be another ground unit type in the same style as STOs - design a weapon pod, choose it in the unit creation window, and get a ground support fighter with some minimal engine/MFC/sensor tonnage in the same manner as we currently design STOs. Build them into a formation (again, just like STOs) and assign them to support a formation with FFD following the same rules as presently. There could be a new base unit class for these (in which case we could just do away with fighter pods entirely, but I digress) or you could choose from the available vehicle classes to customize HP and armor.

This would reduce the insane micromanagement that currently plagues ground support fighters, make the fighters scale much better with AA weapons (plus, reworking AA damage calculations would allow Steve to fix the stupid issue where LAA is useless until racial weapon strength is 10 or more), and frankly this makes much more flavor sense since air fighters and space fighters are not going to be designed similarly in most cases anyways.

Regular fighters can still do orbital fire support in the same way as any other ship for those who want to keep that kind of flavor, although given the micro involved I'm not sure there's more than 2-3 people in the entire playerbase who actually care about it presently.
Title: Re: C# Suggestions
Post by: Garfunkel on November 23, 2021, 06:52:28 AM
That's a pretty good idea and would solve the issue with them pretty neatly.
Title: Re: C# Suggestions
Post by: alex_brunius on November 23, 2021, 08:26:28 AM
and frankly this makes much more flavor sense since air fighters and space fighters are not going to be designed similarly in most cases anyways.

I don't quite agree with that as we should remember hybrid Space/Atmosphere fighters see quite extensive use in a large number of Sci-Fi universes even if I agree that it doesn't make much sense scientifically. Id like it if Aurora can expand flexibility to play out as many stories as possible and I'm not sure removing such flexibility where already implemented makes much sense, even if it would make "scientific" sense to do so.

I honestly think it would be better to get rid of ground support fighters as they currently stand and have them be another ground unit type in the same style as STOs - design a weapon pod, choose it in the unit creation window, and get a ground support fighter with some minimal engine/MFC/sensor tonnage in the same manner as we currently design STOs. Build them into a formation (again, just like STOs) and assign them to support a formation with FFD following the same rules as presently. There could be a new base unit class for these (in which case we could just do away with fighter pods entirely, but I digress) or you could choose from the available vehicle classes to customize HP and armor.

This would reduce the insane micromanagement that currently plagues ground support fighters, make the fighters scale much better with AA weapons (plus, reworking AA damage calculations would allow Steve to fix the stupid issue where LAA is useless until racial weapon strength is 10 or more) ...

Regular fighters can still do orbital fire support in the same way as any other ship for those who want to keep that kind of flavor, although given the micro involved I'm not sure there's more than 2-3 people in the entire playerbase who actually care about it presently.

That would be cleaner but also require a pretty extensive rework of fighter mechanics. Especially if we envision this new type of ground unit doing all current fighter missions with lots of special rules for targeting and resolution ( Support, CAP, Search & Destroy and Flak Suppression ). It would also require specific rules for situations like how to handle if one side only has fighters left and the other side have no AA or fighters left ( so they can't attack them ).

Space fighters being limited to regular orbital ground support would also remove one of the main reasons to use them if I understand things correctly as they wouldn't be immune to enemy STO weapons.

A solution that would probably require less work and benefit more areas while also keeping the freedom to design and use hybrid Space/Atmosphere fighters would be to work on the micromanagement issues instead. VB6 Aurora had specific controls to manage fighters in Squadrons, and also had the ability to move a selection of ships from one fleet to another with a single click. Something similar in C# would be greatly helpful here to cut down micro IMO.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on November 23, 2021, 09:13:53 AM
But we could still use box launchers to stick the pods into and make our space to space bombers into space to ground fighters.

I would be in favour of making the air war on planets integrated into the ground forces as that makes much more sense. There could also be unit formation which have only ground fighters in them that can perform orbital support from ships as well. So... a ground unit you can stuff into a hangar OR transport hold. If in the hangar it can operate like if it was on the ground... good for preforming air suppression missions or just general bombardment prior to dropping the troops on the ground. They also could receive some benefit while operating from space rather than ground while directed by FFD.
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 23, 2021, 09:18:55 AM
It would also require specific rules for situations like how to handle if one side only has fighters left and the other side have no AA or fighters left ( so they can't attack them ).

The rest are good points, but to address this one I think it is sufficient to make fighters difficult for regular ground forces to target (e.g. high hit modifier for the base class) so that the primary means of destroying fighters would be AA weapons but ground forces shooting their guns in the air can still do something (as has been done historically).

Alternatively, this may not be a huge issue - if a ground force doesn't bring necessary weapons and then loses as a result, this is a logical consequence of poor preparation. If Steve were to consider such a change this would probably be a decision to be made one way or the other.
Title: Re: C# Suggestions
Post by: alex_brunius on November 23, 2021, 10:46:16 AM
The rest are good points, but to address this one I think it is sufficient to make fighters difficult for regular ground forces to target (e.g. high hit modifier for the base class) so that the primary means of destroying fighters would be AA weapons but ground forces shooting their guns in the air can still do something (as has been done historically).

Alternatively, this may not be a huge issue - if a ground force doesn't bring necessary weapons and then loses as a result, this is a logical consequence of poor preparation. If Steve were to consider such a change this would probably be a decision to be made one way or the other.

The issue would be silly examples like if 500k+ ton of cheap militia would win a battle but the enemy side had say 5 fighters left that can't be hit resulting in the militia being unable to win despite the given logical result would be them simply overrunning the airbases. Giving regular forces a miniscule chance to hit could work but might not be trivial to do either due to issues with rounding for extremely small numbers, and it being tricky to balance ( you would need to answer questions like can a super heavy bombardment artillery gun hit fighters better than a militia rifle or an AT gun or Mortar can? ).

I'm not saying it's impossible to solve, just that it would probably add complexity to handle edge cases and need some extra effort.
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 23, 2021, 10:58:46 AM
If we add a new FTR base type with something like 0.01 hit modifier (for example), it would be sufficiently hard to hit that AA weapons would be preferable, but 500,000 militia firing randomly into the air should be able to down 5 fighters before they get brrrrt'd to death.

There would definitely be a lot of complications required to implement this, for example how should fighters interact with formation settings (front line attack/defense, support, etc.)? However if Steve wants to deal with such questions and the programming involved I think it would be a good change for the ground combat system.
Title: Re: C# Suggestions
Post by: xenoscepter on November 23, 2021, 12:31:37 PM
 --- I feel it prudent to point out that many GSFs will be traveling 100~500x the speed of the rocket that put a man on the Moon IRL. Half a million militia may well still be insufficient against even a measly five fighters...
Title: Re: C# Suggestions
Post by: serger on November 23, 2021, 01:13:33 PM
I think it's easy and natural to add a rule, that you need some quantity of frontline units to control a colony, or your installations will leak to enemy's colony proportionally to this lack of units in the frontline.
Maybe even use different units with different multipliers (smth like stationary x1, inf x2, vehs x4) to represent, that mobile units are able to control more territory.
Title: Re: C# Suggestions
Post by: ArcWolf on November 23, 2021, 03:13:37 PM

...Especially if we envision this new type of ground unit doing all current fighter missions with lots of special rules for targeting and resolution ( Support, CAP, Search & Destroy and Flak Suppression ). It would also require specific rules for situations like how to handle if one side only has fighters left and the other side have no AA or fighters left ( so they can't attack them ).


why not make those combat missions be the fighters equivalent to rear echelon, support, Front line defence/Attack?

Title: Re: C# Suggestions
Post by: Jorgen_CAB on November 23, 2021, 04:54:06 PM
If we add a new FTR base type with something like 0.01 hit modifier (for example), it would be sufficiently hard to hit that AA weapons would be preferable, but 500,000 militia firing randomly into the air should be able to down 5 fighters before they get brrrrt'd to death.

There would definitely be a lot of complications required to implement this, for example how should fighters interact with formation settings (front line attack/defense, support, etc.)? However if Steve wants to deal with such questions and the programming involved I think it would be a good change for the ground combat system.

Why would we just not make it so that if fighters is targeted by a ground force as a regular attack the fighters defend as if they are on the ground and not flying... you are overrunning the fighter base and will likely cripple a few of them before they retire to another airbase... this is just like attacking any other unit on a breakthrough attack or when in the offensive line.

There would be no problem if there are only fighters left, they are the only targets and will die pretty fast.
Title: Re: C# Suggestions
Post by: alex_brunius on November 23, 2021, 05:12:10 PM
why not make those combat missions be the fighters equivalent to rear echelon, support, Front line defence/Attack?

My point was that software development is tricky, and the more you increase complexity, the more likely stuff will go wrong and it takes longer time to develop it. It's not a bad idea to reuse the same dropdown used for ground unit Field Positions for different things, but to illustrate my point that is what Steve did when selecting a new research field for Scientist, and results are not always what you expect them to be...  ::)

(https://i.imgur.com/cdQhSx7.png)

Now this discussion escalated offtopic... again... so I'm sorry for that Steve/Mods.  ::)
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 23, 2021, 05:38:59 PM
Do we even have mods? I thought we just had a bunch of well-behaved people and then sometimes Erik does techy magicks.  :P
Title: Re: C# Suggestions
Post by: ArcWolf on November 23, 2021, 05:45:54 PM
Do we even have mods? I thought we just had a bunch of well-behaved people and then sometimes Erik does techy magicks.  :P

well you know what they say, 'if you do your job right, no one will even know you did anything." :D

Seriously though, i do think GSF as a ground unit could work quite well.
Title: Re: C# Suggestions
Post by: Garfunkel on November 23, 2021, 09:31:12 PM
Do we even have mods? I thought we just had a bunch of well-behaved people and then sometimes Erik does techy magicks.  :P
Due to how forum software works, us three "bug mods" are actually "global mods". But it's not like we need to do much aside from occasionally approving a post from a non-registered poster.
Title: Re: C# Suggestions
Post by: Migi on November 24, 2021, 09:19:06 AM
As a small QOL enhancement can we have the ship class abbreviation (CL, TG, FTR) displayed when you go to build ships, stations and fighters?
In the Industry tab, when selecting which Space Station or Fighters to build, it only shows the class name.
Likewise in the Shipyards tab, under the shipyard retooling and the various yard tasks only show the class name.
Title: Re: C# Suggestions
Post by: alex_brunius on November 27, 2021, 12:52:35 PM
A small wishlist for more things to show up in the Race Comparison window (because who doesn't love more data  ;D):

- Manufacturing Population
- Manufacturing Employed Population
- Manufacturing Available Workers

- Current Wealth
- Annual Income
- Annual Expenditure

- Ground Force Total Cost
- Ground Force Total Units
- Ground Force STO Size
- Ground Transport Capacity on Ships (tons)

- Naval Shipyard Slipways
- Commercial Shipyard Slipways
Title: Re: C# Suggestions
Post by: Tavik Toth on November 28, 2021, 06:29:08 PM
I can't remember if someone else has already suggested this, but the ability to design conventional tech beam and kinetic weapons (even if it is just lasers and railguns) to complement conventional missiles. Maybe have them be half of what the first TN laser and railgun techs can do?
Title: Re: C# Suggestions
Post by: nakorkren on November 28, 2021, 09:39:44 PM
Minor quality of life improvement: would it be possible to add a text field on the Mining tab, directly below the Mass Driver Destination drop down, that displays the current (or average, if that's computationally easier) "trip time" for a mineral packet sent to that destination? It would help players avoid setting destinations orbiting other stars, i.e. situations where the minerals you purchased will arrive in a few decades unless you turn off the mass driver and just pick up the minerals with a cargo courier ship.

*cough* Asking for a friend *cough*.
Title: Re: C# Suggestions
Post by: Steve Walmsley on November 29, 2021, 11:21:06 AM
Minor quality of life improvement: would it be possible to add a text field on the Mining tab, directly below the Mass Driver Destination drop down, that displays the current (or average, if that's computationally easier) "trip time" for a mineral packet sent to that destination? It would help players avoid setting destinations orbiting other stars, i.e. situations where the minerals you purchased will arrive in a few decades unless you turn off the mass driver and just pick up the minerals with a cargo courier ship.

*cough* Asking for a friend *cough*.

Added for v2.0.
Title: Re: C# Suggestions
Post by: Steve Walmsley on November 29, 2021, 12:03:46 PM
As a small QOL enhancement can we have the ship class abbreviation (CL, TG, FTR) displayed when you go to build ships, stations and fighters?
In the Industry tab, when selecting which Space Station or Fighters to build, it only shows the class name.
Likewise in the Shipyards tab, under the shipyard retooling and the various yard tasks only show the class name.

Added for v2.0.
Title: Re: C# Suggestions
Post by: nakorkren on November 29, 2021, 09:01:55 PM
It would be really cool if mineral packets could be intercepted by a ship. This would allow a weaker civ to practice piracy (flavor!) as well as potentially impose a sort of blockade of a planet, separating it from its mining colonies without having to fight the garrisons and capture said colonies.

This could be tied together with other prior requests to let ships behave like (or mount) mass drivers, or it could be an option available to any ship with a cargo shuttle and cargo bay.

Not sure how this would be implemented in the game, maybe as a as a standing order to "Capture mineral packets near a rendezvous point" or something like that.
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 29, 2021, 10:03:41 PM
This would allow a weaker civ to practice piracy (flavor!) as well as potentially impose a sort of blockade of a planet, separating it from its mining colonies without having to fight the garrisons and capture said colonies.

It really wouldn't.

Aurora in general doesn't really allow for a lot of complexity at the level of single-system warfare, because the vast majority of fleet engagements happen at or near jump points. Simply put, you're not going to get a pirate fleet into the enemy system to steal their mineral packets without fighting their JP defense fleet, destroying it, and securing the JP for yourself. Unless you use some very off-normal settings, jump point topography simply is the dominant terrain of strategic warfare in Aurora

To be fair, I have managed to do limited commerce raiding in my own campaigns, but this always happens after the enemy fleet is reduced to scattered escorts, and it is less commerce raiding and more chasing down their remaining commercial fleet at that point. The roleplay ideal of piracy and raiding to weaken an alien empire is largely incompatible with how Aurora actually works in practice.

This is why the new Raider spoilers will be such a good addition to the game, as their mechanics will be really the only ones that actually allow this kind of economic warfare in practical terms.
Title: Re: C# Suggestions
Post by: smoelf on November 30, 2021, 07:00:53 AM
Add a conditional order for salvage fleets to unload all installations, components, and minerals at nearest colony when cargo hold is full.
Title: Re: C# Suggestions
Post by: LuuBluum on December 01, 2021, 09:21:12 AM
Add a checkbox to prevent officers from teleporting to and from their destinations upon (re)assignment. We have the option to shuttle them around, after all; it'd be nice if it could be forced.
Title: Re: C# Suggestions
Post by: Steve Walmsley on December 01, 2021, 09:58:18 AM
Add a checkbox to prevent officers from teleporting to and from their destinations upon (re)assignment. We have the option to shuttle them around, after all; it'd be nice if it could be forced.

That is how it used to work in the early versions of VB6. It ended up as tedious micromanagement without any meaningful decisions involved, so I removed it for C#.
Title: Re: C# Suggestions
Post by: Vandermeer on December 01, 2021, 10:58:48 AM
Add a checkbox to prevent officers from teleporting to and from their destinations upon (re)assignment. We have the option to shuttle them around, after all; it'd be nice if it could be forced.
I like it better as it is now, since you can actually do the RP part still and assign officers to transfer shuttles if you want to. One of the first big Aurora Let's Plays had that rule, though I forgot the name.
Title: Re: C# Suggestions
Post by: LuuBluum on December 01, 2021, 11:13:46 AM
Ah, yeah, I can just assign naval officers to shuttle commanding or a ground unit officer to command a headquarter-only unit and then transport the unit. I'll just have to remember to disable auto-promotion whenever there's a vacancy that I care about shuttling the officer over to to fill.
Title: Re: C# Suggestions
Post by: ArcWolf on December 01, 2021, 01:46:28 PM
Question & Suggestion:

In the DB under FTC_ShippingLines there is a column maned "MaxAssets". Am i right to assume that means the maximum number of ships the shipping line can have?

If so can we have that added as a setting so we can adjust? I had a campaign recently where one shipping line had well over 100 ships, and i had 11 shipping lines in total numbering well over 800 ships. IF we could limit the Number of ships a line could have and possibly the number of shipping lines per empire it could help with late game slowdowns.
Title: Re: C# Suggestions
Post by: Garfunkel on December 01, 2021, 06:52:18 PM
You can just disable civilian shipping lines once they are big enough for your purposes. You can even toggle them back on later if you wish and even later you can turn them off again.
Title: Re: C# Suggestions
Post by: Steve Walmsley on December 02, 2021, 05:06:46 AM
In the DB under FTC_ShippingLines there is a column maned "MaxAssets". Am i right to assume that means the maximum number of ships the shipping line can have?

Its the most total assets (cash plus ships) that the shipping line has ever had.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on December 02, 2021, 06:04:42 AM
Question & Suggestion:

In the DB under FTC_ShippingLines there is a column maned "MaxAssets". Am i right to assume that means the maximum number of ships the shipping line can have?

If so can we have that added as a setting so we can adjust? I had a campaign recently where one shipping line had well over 100 ships, and i had 11 shipping lines in total numbering well over 800 ships. IF we could limit the Number of ships a line could have and possibly the number of shipping lines per empire it could help with late game slowdowns.

Make sure that you always SM the fuel efficiency technology so it is at minimum 0.5 after you research it. This makes the civilian build more expensive but more efficient ships so will have less of them but are a bit more efficient. This will help with overall performance... it does require some micromanagement as you need to SM in the actual level of efficiency that you researched when designing a more efficient engines for your commercial designs, but can be worth it for overall game performance.

I pretty much do this all the time now in my games. Your civilian fleet will develop a bit slower but it is probably worth it overall from a game performance perspective.

I would like if there were an option in the game that civilian ships always built their ships with the more expensive 0.5 engine as that will save game resources so I did not need to deal with this manually. I know it might not be realistic and they should use the more fuel efficient engine. But mechanically it does not really matter as they don't consume fuel anyway and game performance is more important.
Title: Re: C# Suggestions
Post by: xenoscepter on December 03, 2021, 01:24:54 AM
Question & Suggestion:

In the DB under FTC_ShippingLines there is a column maned "MaxAssets". Am i right to assume that means the maximum number of ships the shipping line can have?

If so can we have that added as a setting so we can adjust? I had a campaign recently where one shipping line had well over 100 ships, and i had 11 shipping lines in total numbering well over 800 ships. IF we could limit the Number of ships a line could have and possibly the number of shipping lines per empire it could help with late game slowdowns.

Make sure that you always SM the fuel efficiency technology so it is at minimum 0.5 after you research it. This makes the civilian build more expensive but more efficient ships so will have less of them but are a bit more efficient. This will help with overall performance... it does require some micromanagement as you need to SM in the actual level of efficiency that you researched when designing a more efficient engines for your commercial designs, but can be worth it for overall game performance.

I pretty much do this all the time now in my games. Your civilian fleet will develop a bit slower but it is probably worth it overall from a game performance perspective.

I would like if there were an option in the game that civilian ships always built their ships with the more expensive 0.5 engine as that will save game resources so I did not need to deal with this manually. I know it might not be realistic and they should use the more fuel efficient engine. But mechanically it does not really matter as they don't consume fuel anyway and game performance is more important.

 --- I'd like it a lot more if the Civilians were always a tech behind. So at Fuel Efficiency 1, they'd be at well, 1... BUT at 0.9 they'd still be at 1, only going to 0.9 when the player researches 0.8! Likewise with engines, armor and the like, so they'd develop more slowly. I'd also like to see Fuel / Mineral requirements added, with a tick box at gamegen to turn it off, of course. :) The player would be able to set aside a portion of Fuel production for the civvies, whilst Civilian Fuel Harvesters which the player isn't buying from would be able to add to this. They wouldn't track nor consume Fuel, but rather the player would simply produce less and the overall range / number of ships would depend on how much is available. Minerals would work the much the same, determining what mineral expenditures the Civilian Lines could afford. Wealth would limit the total BP, while the Civilian Lines could make use of older tech to get around the mineral limits to some degree. Likewise it would ideally be tracked planet to planet with the player being able to designate some planets to be excluded, presumably via the existing "Military Only" restriction. Then the Civilian Lines could build tankers and even fuel depots / "bases" replete with mineral haulers and shipyards to "build" their ships. CMCs not selling to the player would make their minerals available to these shipping lines, so CMCs and Civilian Fuel Harvesters would give those lines something else to spend the wealth on. Bringing back subsidizing, but as a general % of overall wealth made available to the Shipping Lines and with the option for the player to further prioritize what percent of that available wealth would be available to what shipping lines on a line per line basis would also be really net and really complete the package.
Title: Re: C# Suggestions
Post by: dsedrez on December 03, 2021, 06:51:43 AM
Question & Suggestion:

In the DB under FTC_ShippingLines there is a column maned "MaxAssets". Am i right to assume that means the maximum number of ships the shipping line can have?

If so can we have that added as a setting so we can adjust? I had a campaign recently where one shipping line had well over 100 ships, and i had 11 shipping lines in total numbering well over 800 ships. IF we could limit the Number of ships a line could have and possibly the number of shipping lines per empire it could help with late game slowdowns.

Make sure that you always SM the fuel efficiency technology so it is at minimum 0.5 after you research it. This makes the civilian build more expensive but more efficient ships so will have less of them but are a bit more efficient. This will help with overall performance... it does require some micromanagement as you need to SM in the actual level of efficiency that you researched when designing a more efficient engines for your commercial designs, but can be worth it for overall game performance.

I pretty much do this all the time now in my games. Your civilian fleet will develop a bit slower but it is probably worth it overall from a game performance perspective.

I would like if there were an option in the game that civilian ships always built their ships with the more expensive 0.5 engine as that will save game resources so I did not need to deal with this manually. I know it might not be realistic and they should use the more fuel efficient engine. But mechanically it does not really matter as they don't consume fuel anyway and game performance is more important.

I'm not sure I understand. Jorgen. You're not referring to fuel consumption, because it doesn't affect engine cost, right? Is it engine power, then? I've stopped researching lower EP ratings when I noticed the civ lines abusing it... newer ships were *slower* than the earlier ones because they "upgraded" the engines.
Are you saying to mod civ commercial engines to be, say, 0.7 engine power rather than 0.5 where they start? So they're faster but also more expensive? How can I do that with SM? Can I SM edit the civ designs?
Title: Re: C# Suggestions
Post by: Migi on December 03, 2021, 06:53:15 AM
I'd like infantry to be able to carry the light autocannon and statics to mount all autocannons. Unless there is a reason why they can't at the moment?
Title: Re: C# Suggestions
Post by: xenoscepter on December 03, 2021, 08:33:20 AM
I'd like infantry to be able to carry the light autocannon and statics to mount all autocannons. Unless there is a reason why they can't at the moment?

*casually lifts 20mm Chain Gun* Yeah, what he said.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on December 03, 2021, 08:39:29 AM
Question & Suggestion:

In the DB under FTC_ShippingLines there is a column maned "MaxAssets". Am i right to assume that means the maximum number of ships the shipping line can have?

If so can we have that added as a setting so we can adjust? I had a campaign recently where one shipping line had well over 100 ships, and i had 11 shipping lines in total numbering well over 800 ships. IF we could limit the Number of ships a line could have and possibly the number of shipping lines per empire it could help with late game slowdowns.

Make sure that you always SM the fuel efficiency technology so it is at minimum 0.5 after you research it. This makes the civilian build more expensive but more efficient ships so will have less of them but are a bit more efficient. This will help with overall performance... it does require some micromanagement as you need to SM in the actual level of efficiency that you researched when designing a more efficient engines for your commercial designs, but can be worth it for overall game performance.

I pretty much do this all the time now in my games. Your civilian fleet will develop a bit slower but it is probably worth it overall from a game performance perspective.

I would like if there were an option in the game that civilian ships always built their ships with the more expensive 0.5 engine as that will save game resources so I did not need to deal with this manually. I know it might not be realistic and they should use the more fuel efficient engine. But mechanically it does not really matter as they don't consume fuel anyway and game performance is more important.

I'm not sure I understand. Jorgen. You're not referring to fuel consumption, because it doesn't affect engine cost, right? Is it engine power, then? I've stopped researching lower EP ratings when I noticed the civ lines abusing it... newer ships were *slower* than the earlier ones because they "upgraded" the engines.
Are you saying to mod civ commercial engines to be, say, 0.7 engine power rather than 0.5 where they start? So they're faster but also more expensive? How can I do that with SM? Can I SM edit the civ designs?

I was talking about engine power yes, not fuel efficiency technology... the engine power effect fuel efficiency though.

So... what I meant was that you use SM to keep your engine power level at a minimum of 0.5, this make civilian ships more expensive but faster, so more efficient. The civilians otherwise use cheaper and slower ships.

This way you  reduce the amount of civilian ships your civilians build, ut they also are more efficient as they will be faster.

I then use SM whenever I myself design an engine based on what I researched. I then SM back to 0.5 engine power technology at minimum so the civilians keep using that technology.
Title: Re: C# Suggestions
Post by: Migi on December 03, 2021, 08:59:07 AM
I'd like infantry to be able to carry the light autocannon and statics to mount all autocannons. Unless there is a reason why they can't at the moment?

*casually lifts 20mm Chain Gun* Yeah, what he said.
You can have infantry with a light anti tank or CAP, why is the light autocannon different? The tonnage indicates there is a whole team operating it, not just a single person.
Title: Re: C# Suggestions
Post by: cdrtwohy on December 03, 2021, 09:25:13 AM
Quote
You can have infantry with a light anti tank or CAP, why is the light autocannon different? The tonnage indicates there is a whole team operating it, not just a single person.

we also have Power armour in the game so you could lock the autocannon abhind that as well

by the way as for CAP or AT a always just assumed light AT were LAWs or AT4s or some equivalent man portable system like that (same with LAA bing stingers) and CAP being the equivalent of a M240B
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 03, 2021, 10:32:49 AM
I'd like infantry to be able to carry the light autocannon and statics to mount all autocannons. Unless there is a reason why they can't at the moment?

*casually lifts 20mm Chain Gun* Yeah, what he said.
You can have infantry with a light anti tank or CAP, why is the light autocannon different? The tonnage indicates there is a whole team operating it, not just a single person.

While waiting for this suggestion (or if it never happens), this is a very simple DB mod to implement on your own - in the table DIM_GroundComponentType (or similar name) you only need to change a 0 to 1 in a single column to unlock a weapon type for a base unit type. In case anyone would like to do this...

we also have Power armour in the game so you could lock the autocannon abhind that as well

Actually not, with the way ground units are implemented in Aurora the choice of components is limited only by the base type and cannot interact with armor. Changing this is theoretically possible but would require considerably complicating the DB entries in a way that would make adding additional armor types as a DB mod basically impossible - in addition to complicating the code and likely introducing bug potential for ground unit creation.
Title: Re: C# Suggestions
Post by: cdrtwohy on December 03, 2021, 10:37:11 AM
Quote
Actually not, with the way ground units are implemented in Aurora the choice of components is limited only by the base type and cannot interact with armor.  Changing this is theoretically possible but would require considerably complicating the DB entries in a way that would make adding additional armor types as a DB mod basically impossible - in addition to complicating the code and likely introducing bug potential for ground unit creation.

true I guess i ment more from an RP perspective, we could let infantry have LACs but from an RP not use them unless either you had PA or genetically engineered supersoldiers, I have no issue with allowing Infantry access to LAC, my point was more there are ways around the " 20mm chain gun is to heavy so don't let infantry have ACs) argument 
Title: Re: C# Suggestions
Post by: LuuBluum on December 03, 2021, 06:19:39 PM
Would it be possible to change the population growth rate from the current system (I think it's like the minimum of 20/P^(1/3) and 0.1 up to a third of the population capacity, at which point it is a linear fall-off) to a logistic equation? Wouldn't be much more complicated than the current method. Would be simply r*P*(1-P/K), where P is the current population, r is a growth rate constant (that variable we put in per species, fudged a bit to make population grow sufficiently fast for a 4x game), and K is the population capacity (calculated the same as currently). That way instead of current (where colonies have crazy-fast growth rate at first until leveling off), it would be a nice logistic curve: slow to start, fast in the middle, and then smoothing out at the end. Plus this accounts for if the population exceeds the population capacity; at that point the equation becomes negative.

Actually... in the same suggestion, would it be possible to replace population capacity in that equation with min(population capacity of planet, population supported by infrastructure)? That way colonies don't outpace the infrastructure being put in place, and actually account for it in their growth.

Computationally-speaking, I think this should actually be cheaper to calculate given that it avoids that cubic root.

This should also play nicely with the "colony cost range" effect of the new eccentric orbits, given that the population supported by infrastructure would vary as well, and that this equation can handle going negative just fine.


If you want a good estimate for the current actual human population growth rate, assuming that the equation is working with millions of population as a unit, r should be about 0.00037. That should give roughly a population growth rate of 1 for 7.9 billion people where the population capacity is 12 billion: where we are now.
Title: Re: C# Suggestions
Post by: dsedrez on December 03, 2021, 06:53:11 PM
Make sure that you always SM the fuel efficiency technology so it is at minimum 0.5 after you research it. This makes the civilian build more expensive but more efficient ships so will have less of them but are a bit more efficient. This will help with overall performance... it does require some micromanagement as you need to SM in the actual level of efficiency that you researched when designing a more efficient engines for your commercial designs, but can be worth it for overall game performance.

I pretty much do this all the time now in my games. Your civilian fleet will develop a bit slower but it is probably worth it overall from a game performance perspective.

I would like if there were an option in the game that civilian ships always built their ships with the more expensive 0.5 engine as that will save game resources so I did not need to deal with this manually. I know it might not be realistic and they should use the more fuel efficient engine. But mechanically it does not really matter as they don't consume fuel anyway and game performance is more important.

I'm not sure I understand. Jorgen. You're not referring to fuel consumption, because it doesn't affect engine cost, right? Is it engine power, then? I've stopped researching lower EP ratings when I noticed the civ lines abusing it... newer ships were *slower* than the earlier ones because they "upgraded" the engines.
Are you saying to mod civ commercial engines to be, say, 0.7 engine power rather than 0.5 where they start? So they're faster but also more expensive? How can I do that with SM? Can I SM edit the civ designs?

I was talking about engine power yes, not fuel efficiency technology... the engine power effect fuel efficiency though.

So... what I meant was that you use SM to keep your engine power level at a minimum of 0.5, this make civilian ships more expensive but faster, so more efficient. The civilians otherwise use cheaper and slower ships.

This way you  reduce the amount of civilian ships your civilians build, ut they also are more efficient as they will be faster.

I then use SM whenever I myself design an engine based on what I researched. I then SM back to 0.5 engine power technology at minimum so the civilians keep using that technology.

Ok. I thought you were referring to SM-editing the civ designs to put, say, a 0.7 engine in place of the one they've used originally. I tested and yes, you can do that. It seems the designs aren't even locked. What I didn't do was try the game in this configuration: I don't know if the civ will build new ships, if they'd work correctly etc. Maybe a test for later.
Maybe I *can* add some sensors, something I've wanted to do for a long time... though it has to be checked whether their output will be shown to the player.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 03, 2021, 09:20:12 PM
[math]
That way instead of current (where colonies have crazy-fast growth rate at first until leveling off), it would be a nice logistic curve: slow to start, fast in the middle, and then smoothing out at the end. Plus this accounts for if the population exceeds the population capacity; at that point the equation becomes negative.

It's important to note that this is actually a significant change to the game economy, as right now an important motive for colonization is that smaller populations grow more quickly and population soon becomes a critical resource for a mid-game empire. If you shift the curve to make small colonies grow slowly, the game's economics have to be completely reevaluated. It is one of those cases where making the game "more realistic" might not be good for gameplay. It can certainly work but it would involve a lot of rebalancing work to make sure it works right and doesn't break the core economic mechanics.
Title: Re: C# Suggestions
Post by: LuuBluum on December 03, 2021, 09:53:49 PM
[math]
That way instead of current (where colonies have crazy-fast growth rate at first until leveling off), it would be a nice logistic curve: slow to start, fast in the middle, and then smoothing out at the end. Plus this accounts for if the population exceeds the population capacity; at that point the equation becomes negative.

It's important to note that this is actually a significant change to the game economy, as right now an important motive for colonization is that smaller populations grow more quickly and population soon becomes a critical resource for a mid-game empire. If you shift the curve to make small colonies grow slowly, the game's economics have to be completely reevaluated. It is one of those cases where making the game "more realistic" might not be good for gameplay. It can certainly work but it would involve a lot of rebalancing work to make sure it works right and doesn't break the core economic mechanics.
Fair. For what its worth, the growth rate exceeds that of the current mechanic (with that r constant) at about 275 million. You can fudge the constant, of course, if you want it to be a faster or slower growth, and doing so is proportional to when that overlap happens. Take the rate x10, and it exceeds at 27 million; x100, and at 2 million.

Of course, since growth is effectively exponential until halfway to the population capacity, doing such a thing makes the population shoot off into the stratosphere pretty quick. I agree that it's a hard thing to balance; my goal isn't realism here but just to smooth out the lower end. Which... well, the straightforward one for that is the logistic equation. Issue is as you mentioned, that it creates a population crunch for the midgame until you manage to hit that critical population blow-up point. Which... well, moving 300 million people isn't exactly trivial.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 03, 2021, 10:01:59 PM
I'm definitely not opposed to it on principle, because encouraging the kind of "medium"-size hundreds-of-millions population colonies is good for roleplay in my opinion. Presently the balance seems to be toward the extremes, with low-pop colonies to breed more colonists and high/max-pop colonies as major hub worlds. It's just that such a key element of the game economy has to be handled carefully.
Title: Re: C# Suggestions
Post by: LuuBluum on December 03, 2021, 10:14:39 PM
Yeah, the big change would be that supporting a colony with colonists from well-inhabited main worlds would be the main way to encourage their growth, by exploiting the high growth rate of mid-populated planets. Colony ships would increase in volume for sure.
Title: Re: C# Suggestions
Post by: ArcWolf on December 04, 2021, 02:10:27 AM


I was talking about engine power yes, not fuel efficiency technology... the engine power effect fuel efficiency though.

So... what I meant was that you use SM to keep your engine power level at a minimum of 0.5, this make civilian ships more expensive but faster, so more efficient. The civilians otherwise use cheaper and slower ships.

This way you  reduce the amount of civilian ships your civilians build, ut they also are more efficient as they will be faster.

I then use SM whenever I myself design an engine based on what I researched. I then SM back to 0.5 engine power technology at minimum so the civilians keep using that technology.

ahh, that makes sense, i had no idea what you were saying either. Not something i have to worry about though, i never research the tech for lower ep then .5, i see no reason to (i also play on 15-20% research speed, so i have more important techs to worry about).
Title: Re: C# Suggestions
Post by: H11F on December 05, 2021, 09:37:58 AM
Kind of a random thought I had earlier today when looking at medals, and some of the conditions - it felt like it would be better if some of the medals could be assigned to the ship instead.   Not sure of the work required, but it would be interesting to grant decorations to the ship instead of officers crewing it, or even just the ability to add notes to a ship.

(http://https://www. pacificbattleship. com/wp-content/uploads/2018/03/Iowa_Service_Awards. jpg)
Title: Re: C# Suggestions
Post by: cdrtwohy on December 05, 2021, 01:41:30 PM
so was thinking about something, Population Capacity is defined as the Capacity of a population giving its current Food, Water and other Necessities usage and production, given that humans (and im going to assume other Sapient and industrial creatures) can change the carrying capacity by more efficient farming methods and other environmental things id like to propose the idea of a research that increases the Max population of a planet to represent things like conventional orbital industry, improvements in Farming tech based on the TN mats, and improved energy production also based on the discovery of the TNs, 
Title: Re: C# Suggestions
Post by: ArcWolf on December 05, 2021, 03:01:27 PM
Ya, that is 1 thing that annoys me about aurora. I understand you need to put a pop cap on a planet, but earth is capable of supporting 10s to 100s of times more population then the cap in game.

Just to give you an idea, We could fit the entire population of the USA and Canada into the state of New York and still have about 20% of the land area of that state left unpopulated if we lived at New York City levels of population density. New Jersey is the most densely populated state in the US (1,200 per sq. Mile). We could fit the entire US population in the state of Texas and still have room at that density. And we could fit the world population in the area of the US (including Hawaii & Alaska) and China leaving the rest of the world 100% devoid of human life.

The biggest use of land is agriculture. Roughly 1.43 mil sq. miles of the US is farm land and that can support roughly 570,000,000 people. But were talking about a game where we can feed 10s of millions if not 100s on a planet with no atmosphere, meaning we would have to have extensive aeroponics and hydroponics infrastructure which would increase the productivity/sq. mile by easily 10x if not more.
Title: Re: C# Suggestions
Post by: QuakeIV on December 05, 2021, 04:33:58 PM
Ya, that is 1 thing that annoys me about aurora. I understand you need to put a pop cap on a planet, but earth is capable of supporting 10s to 100s of times more population then the cap in game.

Just to give you an idea, We could fit the entire population of the USA and Canada into the state of New York and still have about 20% of the land area of that state left unpopulated if we lived at New York City levels of population density. New Jersey is the most densely populated state in the US (1,200 per sq. Mile). We could fit the entire US population in the state of Texas and still have room at that density. And we could fit the world population in the area of the US (including Hawaii & Alaska) and China leaving the rest of the world 100% devoid of human life.

The biggest use of land is agriculture. Roughly 1.43 mil sq. miles of the US is farm land and that can support roughly 570,000,000 people. But were talking about a game where we can feed 10s of millions if not 100s on a planet with no atmosphere, meaning we would have to have extensive aeroponics and hydroponics infrastructure which would increase the productivity/sq. mile by easily 10x if not more.

This is true.
Title: Re: C# Suggestions
Post by: Density on December 05, 2021, 05:21:14 PM
so was thinking about something, Population Capacity is defined as the Capacity of a population giving its current Food, Water and other Necessities usage and production, given that humans (and im going to assume other Sapient and industrial creatures) can change the carrying capacity by more efficient farming methods and other environmental things id like to propose the idea of a research that increases the Max population of a planet to represent things like conventional orbital industry, improvements in Farming tech based on the TN mats, and improved energy production also based on the discovery of the TNs,

I've been thinking for a while that it'd be cool to have a pop density tech line and a growth rate tech line to bulk out Bio/Gen.
Title: Re: C# Suggestions
Post by: Droll on December 05, 2021, 05:35:59 PM
It would also allow the hydrosphere to potentially play a bigger role in carrying capacity as well. Species could have a minimum hydro for colony cost but also an ideal hydro for the purposes of carrying capacity.

This would also allow for aquatic species to become a thing more easily (IIRC there was an entire thread about this).
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 05, 2021, 11:46:33 PM
Kind of a random thought I had earlier today when looking at medals, and some of the conditions - it felt like it would be better if some of the medals could be assigned to the ship instead.   Not sure of the work required, but it would be interesting to grant decorations to the ship instead of officers crewing it, or even just the ability to add notes to a ship.

On this note, it would also be nice if conditional medals were assigned to all ships in a fleet which accomplished some task, not just the "first ship" in the fleet. Example of this: "Discover N Star Systems" is awarded to only one officer even if a whole fleet jumped into the system to do a survey. This should be awarded not only to commanding officers of all ships but also any sub-commanding officers. Similarly, medals for destroying N tons should be awarded to sub-command officers - which would make the higher conditions more achievable and commander careers as told by medals more interesting.
Title: Re: C# Suggestions
Post by: ArcWolf on December 06, 2021, 03:00:13 AM
Kind of a random thought I had earlier today when looking at medals, and some of the conditions - it felt like it would be better if some of the medals could be assigned to the ship instead.   Not sure of the work required, but it would be interesting to grant decorations to the ship instead of officers crewing it, or even just the ability to add notes to a ship.

On this note, it would also be nice if conditional medals were assigned to all ships in a fleet which accomplished some task, not just the "first ship" in the fleet. Example of this: "Discover N Star Systems" is awarded to only one officer even if a whole fleet jumped into the system to do a survey. This should be awarded not only to commanding officers of all ships but also any sub-commanding officers. Similarly, medals for destroying N tons should be awarded to sub-command officers - which would make the higher conditions more achievable and commander careers as told by medals more interesting.

Agreed, i would also like to add having ground commanders in the command hierarch get some form of recognition for tonnage destroyed. My LTG leading the invasion is going to stay in the Rear echelon and probably have 0 kills during the combat, but they are heading the army, and if that army destroys some 1mil tons, he should get some credit other then the campaign ribbon i make and award to all officers involved.
Title: Re: C# Suggestions
Post by: ArcWolf on December 06, 2021, 01:24:11 PM
So, i was thinking about the idea of adding GSFs as a ground element and how that might get set up  and this is what i got. 3 different weight classes of fighters.

1) Light fighter: Weighs roughly 20 tons, can only mount light armour (like a light vehicle) and can only mount 1 weapon, either light Auto-Cannon or Light Bombard. Low HP pool.

2) Medium Fighter: Like medium vehicles, can mount light/medium armour. Has 1 or 2 weapon mounts (up for discussion) and can mount light/medium versions of Auto-cannons or Bombard. Weighs about 40 Tons. Medium HP Pool.

3) Heavy fighters (think more along the lines of a B-52 stratofortress): Can mount light-heavy armour, can mount any weight of weapon system. Has 2 weapon mounts. weights about 100 tons. large HP pool.


In addition, a rework of Fire directors would be needed. I was thinking, if the amount of FFD on the front line (and only front line) were equal or greater then a set ratio, lets say 6:1 (fighters:FFD) then the fighters would either get an accuracy bonus during their combat phase OR get a second "Free" attack run during their phase. This phase could take place before or after ground combat (preferably before) but after artillery bombardment phase.

Title: Re: C# Suggestions
Post by: nuclearslurpee on December 06, 2021, 03:23:50 PM
So, i was thinking about the idea of adding GSFs as a ground element and how that might get set up  and this is what i got. 3 different weight classes of fighters.

1) Light fighter: Weighs roughly 20 tons, can only mount light armour (like a light vehicle) and can only mount 1 weapon, either light Auto-Cannon or Light Bombard. Low HP pool.

2) Medium Fighter: Like medium vehicles, can mount light/medium armour. Has 1 or 2 weapon mounts (up for discussion) and can mount light/medium versions of Auto-cannons or Bombard. Weighs about 40 Tons. Medium HP Pool.

3) Heavy fighters (think more along the lines of a B-52 stratofortress): Can mount light-heavy armour, can mount any weight of weapon system. Has 2 weapon mounts. weights about 100 tons. large HP pool.


In addition, a rework of Fire directors would be needed. I was thinking, if the amount of FFD on the front line (and only front line) were equal or greater then a set ratio, lets say 6:1 (fighters:FFD) then the fighters would either get an accuracy bonus during their combat phase OR get a second "Free" attack run during their phase. This phase could take place before or after ground combat (preferably before) but after artillery bombardment phase.

I would probably want the system to be simpler than this. I don't think there is a big need for three different kinds of air unit base type, particularly since I would not want to see so much complexity in the "air game" added to what is already a complex system of ground units. I think a single unit type is fine, and the differentiation in size between, say, a light fighter and a B-52 can be made by the type of weapon mounted.

My suggestion would be a 12-ton base class, either with 2/3 armor/HP matching the current LVH or 3 HP and 1/2/3 armor matching the current STA options. The size is admittedly arbitrary but I think staying in line with the existing LVH and STA base classes makes sense. Mechanically I think a very low hit modifier (as low as 1% even) makes sense, and then AA weapons negate this so they retain a useful niche. Fighters should still be very vulnerable to AA weapons, otherwise they are just blatantly superior to artillery. Of course, air fighters cannot fortify appreciably. One challenge with this is that the current Support/Rear echelons force the use of fortification rather than evasion, so another stance may be needed.

For weapons we have two options: one would be to use the existing fighter pods as weapons, which I think could be interesting. It seems a little silly to have a while set of researchable components for a single class of ground units but I do like the idea of customizing the size and power of the weapons. Probably a simpler approach which is still very robust would be to use the same weapon set that LVH, VEH, etc. have, minus the non-combat components (FFD, LOG, HQ, etc.) and including up through the heavy variants.

Mechanically, I think we can have similar mechanics to artillery. If a fighter formation is assigned to support a front-line formation they will conduct ground attack missions. Otherwise, similarly to the artillery counterbattery mechanic an "unassigned" fighter formation will default to either CAP or AA suppression missions - I would be fine if only CAP/air intercept was a mission type as AA weapons should be dangerous enough to fighters that trying to suppress them would be challenging at best.

As far as FFD I think it should remain as it is, but only useful for requesting orbital fire support. Fighter formations should be able to support any front-line formation in their hierarchy by simple click-and-drag just as artillery does currently. Maybe we change the name of the FFD component to something more descriptive?
Title: Re: C# Suggestions
Post by: xenoscepter on December 06, 2021, 04:01:59 PM
So, i was thinking about the idea of adding GSFs as a ground element and how that might get set up  and this is what i got. 3 different weight classes of fighters.

1) Light fighter: Weighs roughly 20 tons, can only mount light armour (like a light vehicle) and can only mount 1 weapon, either light Auto-Cannon or Light Bombard. Low HP pool.

2) Medium Fighter: Like medium vehicles, can mount light/medium armour. Has 1 or 2 weapon mounts (up for discussion) and can mount light/medium versions of Auto-cannons or Bombard. Weighs about 40 Tons. Medium HP Pool.

3) Heavy fighters (think more along the lines of a B-52 stratofortress): Can mount light-heavy armour, can mount any weight of weapon system. Has 2 weapon mounts. weights about 100 tons. large HP pool.


In addition, a rework of Fire directors would be needed. I was thinking, if the amount of FFD on the front line (and only front line) were equal or greater then a set ratio, lets say 6:1 (fighters:FFD) then the fighters would either get an accuracy bonus during their combat phase OR get a second "Free" attack run during their phase. This phase could take place before or after ground combat (preferably before) but after artillery bombardment phase.

 --- Can we just, ya know... not? I personally like GSF creation, but just hate the micromanagement. A re-work of how AA and GSF interact might be needed for balance, but still. I hate the idea of GSFs being ground units. Instead of all of this, let's just have a window like VB6 for squadrons, alongside an organizational tool to build to them.

 --- I'll elaborate, yeah? The window would allow you to create a "Squadron" comprising of whatever mix of ships you'd want. A textbox would let you specify how many, while a dropdown would let you specify what kind. A button would allow you to add another field for squadrons of mixed types. So if I wanted a "Squadron" of 15 ships, with 12 Bombers, 2 Sensor Spotters and 1 Command Fighter, I'd put 12 in the textbox, use the dropdown to select my Bomber class, then hit the button to add a field. Then I'd put 2 in the new textbox, followed by selecting the Sensor Spotter from the dropdown, then hit the button to add a field one more time. Now I'd put a 1 in that textbox and select the Command Fighter from the dropdown. Then I'd use another textbox to name it, and when I was done naming it I'd hit the button to save it.

 --- Additionally, this window would allow me to hit a checkbox that would allow a certain "Squadron" to be automatically deployed as a fleet when built. The Industry Window would get a checkbox or button saying "Toggle Squadrons" for Fighter production somewhere, so the fighter production would list squadrons as a build option under the "Fighters" field instead of the fighter classes themselves. The Squadron window would allow for naming conventions like the Ship Design Window and would furnish a field to manage Fighter-Only Fleets, Fighter-Only Sub-Fleets and further filter to exclude fighters other than Ground Support Fighters, namely those with fighter pod bays versus those without.

 --- FFDs could be told to auto-assign fighters or ships, while "Squadrons" of GSFs could have mission types whitelisted or blacklisted with checkbox fields like "No CAP" and such from the Squadron Window. GSFs that are auto-assigned to FFDs will try to distribute themselves evenly and carry out missions that are whitelisted or not blacklisted. Space fighters could have a separate set of conditional orders from the main fleet, allowing them to have priorities for missiles, fighters or just ships within a Minimum / Maximum tonnage range. These priorities would depend on sensor data available. Likewise, for scouts, a conditional order of "Flee from enemy contacts" or for a beam fighter, "Engage at Range" with a field to specify what range in km.

 --- I'll flesh this out more later, my baby boy is crying for food and my keyboard is half busted with my wife having borrowed the good one for work. Needless to say, I heartily disagree with GSFs becoming a ground unit and think this solution would be far better for GSFs and regular fighters alike. :)
Title: Re: C# Suggestions
Post by: Jorgen_CAB on December 06, 2021, 04:16:26 PM
So, i was thinking about the idea of adding GSFs as a ground element and how that might get set up  and this is what i got. 3 different weight classes of fighters.

1) Light fighter: Weighs roughly 20 tons, can only mount light armour (like a light vehicle) and can only mount 1 weapon, either light Auto-Cannon or Light Bombard. Low HP pool.

2) Medium Fighter: Like medium vehicles, can mount light/medium armour. Has 1 or 2 weapon mounts (up for discussion) and can mount light/medium versions of Auto-cannons or Bombard. Weighs about 40 Tons. Medium HP Pool.

3) Heavy fighters (think more along the lines of a B-52 stratofortress): Can mount light-heavy armour, can mount any weight of weapon system. Has 2 weapon mounts. weights about 100 tons. large HP pool.


In addition, a rework of Fire directors would be needed. I was thinking, if the amount of FFD on the front line (and only front line) were equal or greater then a set ratio, lets say 6:1 (fighters:FFD) then the fighters would either get an accuracy bonus during their combat phase OR get a second "Free" attack run during their phase. This phase could take place before or after ground combat (preferably before) but after artillery bombardment phase.

 --- Can we just, ya know... not? I personally like GSF creation, but just hate the micromanagement. A re-work of how AA and GSF interact might be needed for balance, but still. I hate the idea of GSFs being ground units. Instead of all of this, let's just have a window like VB6 for squadrons, alongside an organizational tool to build to them.

 --- I'll elaborate, yeah? The window would allow you to create a "Squadron" comprising of whatever mix of ships you'd want. A textbox would let you specify how many, while a dropdown would let you specify what kind. A button would allow you to add another field for squadrons of mixed types. So if I wanted a "Squadron" of 15 ships, with 12 Bombers, 2 Sensor Spotters and 1 Command Fighter, I'd put 12 in the textbox, use the dropdown to select my Bomber class, then hit the button to add a field. Then I'd put 2 in the new textbox, followed by selecting the Sensor Spotter from the dropdown, then hit the button to add a field one more time. Now I'd put a 1 in that textbox and select the Command Fighter from the dropdown. Then I'd use another textbox to name it, and when I was done naming it I'd hit the button to save it.

 --- Additionally, this window would allow me to hit a checkbox that would allow a certain "Squadron" to be automatically deployed as a fleet when built. The Industry Window would get a checkbox or button saying "Toggle Squadrons" for Fighter production somewhere, so the fighter production would list squadrons as a build option under the "Fighters" field instead of the fighter classes themselves. The Squadron window would allow for naming conventions like the Ship Design Window and would furnish a field to manage Fighter-Only Fleets, Fighter-Only Sub-Fleets and further filter to exclude fighters other than Ground Support Fighters, namely those with fighter pod bays versus those without.

 --- FFDs could be told to auto-assign fighters or ships, while "Squadrons" of GSFs could have mission types whitelisted or blacklisted with checkbox fields like "No CAP" and such from the Squadron Window. GSFs that are auto-assigned to FFDs will try to distribute themselves evenly and carry out missions that are whitelisted or not blacklisted. Space fighters could have a separate set of conditional orders from the main fleet, allowing them to have priorities for missiles, fighters or just ships within a Minimum / Maximum tonnage range. These priorities would depend on sensor data available. Likewise, for scouts, a conditional order of "Flee from enemy contacts" or for a beam fighter, "Engage at Range" with a field to specify what range in km.

 --- I'll flesh this out more later, my baby boy is crying for food and my keyboard is half busted with my wife having borrowed the good one for work. Needless to say, I heartily disagree with GSFs becoming a ground unit and think this solution would be far better for GSFs and regular fighters alike. :)

While I don't think the idea of aircraft as ground units is a bad idea, they are basically ground units and they are useless in space anyway... I do agree that the current mechanic of micromanagement of support weapons as a whole could be improved. I also think this includes artillery as well.

In my opinion artillery should for example automatically support front line units in their hierarchy automtically, no actions needed by the player at all, I find this need to assigning them to be unnecessary. They can just support randomly those front line formations, that would probably make almost zero difference from how they work now.

The same with aircraft (or orbital support)... you simply would assign them to what role you want them to perform and if assigned to close air support mission they randomly support wherever you have FFD units in place.

If someone really wants to deal with it just leave the option of assigning them manually, but if you don't they just randomly support as needed. I also believe this would make nearly zero difference from how it works now.

Please also make the other missions more useful, especially the AA suppression mission which are more or less pointless if AA is not spread out in most formations. If you have AA units in separate formations the AA suppression mission are more or less pointless if I understand the mechanics of how it works. Fighters on a AA suppression mission pick a random unit and then fire on the AA in that unit. If that unit have no AA if will not fire, but any AA eligible to fire IF that unit was attacked get to fire back regardless, this make AA suppression missions pretty worthless if that is how it works. We need the AA suppression mission to be meaningful to perform. Currently it only work if we build the unit hierarchy in a certain way and even then not that great.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 06, 2021, 04:34:42 PM
--- Can we just, ya know... not? I personally like GSF creation, but just hate the micromanagement. A re-work of how AA and GSF interact might be needed for balance, but still. I hate the idea of GSFs being ground units. Instead of all of this, let's just have a window like VB6 for squadrons, alongside an organizational tool to build to them.

The problem is really one of scale, not only micromanagement. To be of any real use GSFs need to be fielded by the hundreds if not thousands, otherwise the impact is too little and the fighters are destroyed in only a few rounds by AA - the NPRs at least field frankly excessive amounts of AA, but even a modest allocation of ~10 AA units per formation means that easily several hundred to thousands of AA guns are present at any significant planetary battle. To effectively counter this requires much more than just several squadrons of GSFs, we really need to start thinking in terms of WWII-esque air wings of ~100 planes each.

So...we have a need for hundreds, even thousands of specialized ships which are only usable for ground combat. At that scale it is completely impractical to populate them with commanders for each ship, so we either just don't do this or we introduce a new mechanic just for GSFs to have commanders on a squadron basis instead. As far as ship design, AFAIK the speed of GSFs has no bearing on combat, so the only things that matter are the weapon and armor (and the latter is very much arguable as others have shown).

So we have a "ship" type which is only usable in ground combat, needs to be built by the hundreds, is too small and numerous for individual commanders, and has no relevant design parameters aside from the weapon and armor. At that point, this perfectly describes a ground unit class. Why not just take the logic to its conclusion, in the process using mechanics which are 90% preexisting to simplify the implementation for Steve?

Frankly the only reason I can see to preserve the current GSFs is roleplay as some people are very attached to the "aerospace fighter" concept. However, as much as I value supporting RP in Aurora, it cannot support every possible RP setting equally and mechanically the current system just doesn't work - for many more reasons than just micromanagement hell.

If someone really wants to deal with it just leave the option of assigning them manually, but if you don't they just randomly support as needed. I also believe this would make nearly zero difference from how it works now.

Actually, leaving the artillery un-assigned is currently what causes them to execute counter-battery fire, IIRC. Some players do deliberately leave artillery unassigned for this reason. I'm not opposed to this proposal but there would need to be some way to preserve that functionality, ideally something that fits with the current UI and does not involve cramming an extra dialog into the UI.
Title: Re: C# Suggestions
Post by: xenoscepter on December 06, 2021, 04:39:48 PM
--- Can we just, ya know... not? I personally like GSF creation, but just hate the micromanagement. A re-work of how AA and GSF interact might be needed for balance, but still. I hate the idea of GSFs being ground units. Instead of all of this, let's just have a window like VB6 for squadrons, alongside an organizational tool to build to them.

The problem is really one of scale, not only micromanagement. To be of any real use GSFs need to be fielded by the hundreds if not thousands, otherwise the impact is too little and the fighters are destroyed in only a few rounds by AA - the NPRs at least field frankly excessive amounts of AA, but even a modest allocation of ~10 AA units per formation means that easily several hundred to thousands of AA guns are present at any significant planetary battle. To effectively counter this requires much more than just several squadrons of GSFs, we really need to start thinking in terms of WWII-esque air wings of ~100 planes each.

So...we have a need for hundreds, even thousands of specialized ships which are only usable for ground combat. At that scale it is completely impractical to populate them with commanders for each ship, so we either just don't do this or we introduce a new mechanic just for GSFs to have commanders on a squadron basis instead. As far as ship design, AFAIK the speed of GSFs has no bearing on combat, so the only things that matter are the weapon and armor (and the latter is very much arguable as others have shown).

So we have a "ship" type which is only usable in ground combat, needs to be built by the hundreds, is too small and numerous or individual commanders, and has no relevant design parameters aside from the weapon and armor. At that point, this perfectly describes a ground unit class. Why not just take the logic to its conclusion, in the process using mechanics which are 90% preexisting to simplify the implementation for Steve?

Frankly the only reason I can see to preserve the current GSFs is roleplay as some people are very attached to the "aerospace fighter" concept. However, as much as I value supporting RP in Aurora, it cannot support every possible RP setting equally and mechanically the current system just doesn't work - for many more reasons than just micromanagement hell.

 --- I don't see the problem here, or rather, why the problem is one of scale rather than balance. Either AA needs to be nerfed, GSFs needed to be buffed, or both. I just see turning them into ground units as throwing the baby out with bath water, so to speak. NOW, being able to DESIGN them as ships, but BUILD them as Ground Units, with stats reflective of their class... not too dissimilar to how STOs currently work... THAT I could (begrudgingly) get behind. But I really, really, really detest anything that takes a nuanced, characterful mechanic and turns it into "Build more of X to Y". As long as we avoid that... I'll be at least content.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 06, 2021, 05:23:59 PM
--- I don't see the problem here, or rather, why the problem is one of scale rather than balance.


Considering that ground combat happens at the scale of multi-million ton armies (100,000s to millions of soldiers, depending how you fluff your units), basically world war scales, I don't think its unreasonable to think that fighters should be able to operate on the ~1,000s scale. Beyond that I think I will let others who have used GSFs more than me address the practical reasons in more detail.

That being said...

Quote
NOW, being able to DESIGN them as ships, but BUILD them as Ground Units, with stats reflective of their class... not too dissimilar to how STOs currently work... THAT I could (begrudgingly) get behind.

I think this is also fine and my original suggestion was basically this. The problem with GSFs really boils down to needing them to operate in line with ground combat mechanics, not naval combat mechanics (which they currently do) - if we can accomplish this while preserving the flavor of GSFs and allowing unique class designs to flourish that is only a good thing IMO.
Title: Re: C# Suggestions
Post by: ArcWolf on December 06, 2021, 05:42:40 PM

Frankly the only reason I can see to preserve the current GSFs is roleplay as some people are very attached to the "aerospace fighter" concept. However, as much as I value supporting RP in Aurora, it cannot support every possible RP setting equally and mechanically the current system just doesn't work - for many more reasons than just micromanagement hell.


Frankly, they can't even do that now in the current system. My favorite anime growing up was Macross/Robotech. There is no way to recreate that currently. "Fighters" are 2x the size and 4x the crew of the Rocinante from The Expanse.

The most efficient fighter, and only one really worth using is a set of box launchers with an engine.

I would love to have a legit Macross or Battlestar galactica inspired campaign, but the extent i would have to "suspend belief" would just ruin the whole mood of the campaign to the point i'd probably quit it before i've played for an hr.
Title: Re: C# Suggestions
Post by: xenoscepter on December 06, 2021, 06:21:54 PM
--- I don't see the problem here, or rather, why the problem is one of scale rather than balance.


Considering that ground combat happens at the scale of multi-million ton armies (100,000s to millions of soldiers, depending how you fluff your units), basically world war scales, I don't think its unreasonable to think that fighters should be able to operate on the ~1,000s scale. Beyond that I think I will let others who have used GSFs more than me address the practical reasons in more detail.

That being said...

Quote
NOW, being able to DESIGN them as ships, but BUILD them as Ground Units, with stats reflective of their class... not too dissimilar to how STOs currently work... THAT I could (begrudgingly) get behind.

I think this is also fine and my original suggestion was basically this. The problem with GSFs really boils down to needing them to operate in line with ground combat mechanics, not naval combat mechanics (which they currently do) - if we can accomplish this while preserving the flavor of GSFs and allowing unique class designs to flourish that is only a good thing IMO.

 --- Ya know, having Ground Support Fighters be their own type of unit, like Fighters and Stations, might solve this problem neatly AND simply.

Consider the following:

 -
Code: [Select]
This design is classed as a Ground Support Fighter for production, combat and planetary interaction -
Code: [Select]
This design is classed as a Ground Support Fighter for auto-assignment purposes
 --- Imagine this in the Class Design Window for a moment. GSFs are already flagged as such for the purposes of combat and planetary interaction, so why not production and auto-assignment as well? Having a GSF specific bonus for Ground Officers to use with FFDs would help alleviate the officer issue at the ~1,000s scale if implemented alongside some changes to how FFDs work. Having as GSF specific bonus for Naval Officers, and perhaps a Command & Control component for GSFs specifically would further alleviate this. As for production... why not have them flagged as a separate class, but built at Fighter Factories anyway? A separate designation means that a special Hangar type can be used for them, perhaps one that uses Number of GSFs rather than the total Tonnage of GSFs to alleviate the issue of actually fielding them.

 --- Likewise, GSFs having a separate designation from regular fighters means they don't need to drain fuel from the carrier. But that would make sensor equipped GSFs the ultimate scout, since they would need no fuel support. However, since they don't need sensors to do their job, nor does having sensors actually do anything anyway for Ground Combat we can safely prohibit them from having the special GSF designation if they equip any kind of sensor. Since they also don't suffer firing failures, nor contribute to naval combat, we may as well go whole hog and say that they also don't drain any MSP to restock themselves. They SHOULD however, still consume fuel as well as MSP, since Ground Combat is an 8-Hour affair, and time on station should be an important consideration.

 --- What about combat though? GSFs are, again, already flagged differently from regular fighters. That's how they avoid provoking STO fire on Ground Missions after all... at least I assume as much to be the case. So why not give them more HtK and Armor? Say double the Armor and HtK? And while we're at it why not reduce or outright remove their vulnerability to shock damage as well? AA guns do no shock damage to Ground Forces, so this would if nothing else help make that aspect of Ground Combat more consistent rather than less. To let the player know, add a little line in the Class Design Window that let's them know that not only yes, this design qualifies as a Ground Support Fighter for production, combat and planetary interaction, but also it gets special boni to Armor, HtK, Shock Damage or whatever.

 --- To my knowledge, these changes would accomplish several things at once. They would let the player know that the Class they have designed is considered a GSF. Currently, it takes some diving into the forum or Wiki to know, so this would be an improvement even if it was the only change made and merely cosmetic to boot. Next, by not requiring the player to spend Fuel an MSP to support their GSFs, the burden of fielding large quantities of them is greatly eased. However, by requiring the GSFs to spend fuel and MSP like normal ships do, and further by prohibiting them from benefiting from this if they mount sensors... or indeed any non-GSF components, you effectively remove the ability to exploit this. Of course, it would be prudent to allow things like Bridges, Engineering Spaces, etc... Kill the exploits, but preserve the flavor ya' know? Furthermore, by allowing GSFs to have a special class of their own, the addition of a special Hangar that tracks GSFs and ONLY GSFs, and tracks them by number of craft, rather than total tonnage of craft, would go even further towards facilitating such massive scales. Finally, allowing the GSF boni to HtK, Armor, Shock Damage or perhaps other things; WHILE telling the player of this via the Class Design Window would allow AA to be nerfed enough to make GSFs more useful.

 --- In conclusion, with regards to the HtK, Armor and other such boni; I think that best place to start would be either the reduction of, or an outright immunity to Shock Damage specifically from AA would not only help GSFs, but also give more consistency to Ground Combat. I could see a newbie thinking "Hey~ AA does Shock Damage... Time to exploit this against enemy Ground Units!" and being a bit miffed when they find out it only works against GSFs. Other buffs should only be placed as needed, if needed. As a further note, GSFs should also be eligible to be Fighters too; with any boni only applying to pure GSFs. This would allow players to RP multi-role fighters without being mechanically pigeonholed into having them be one or the other. As well, GSF / Fighter hybrids should drain Fuel and MSP from their carrier. In a similar vein, even pure GSFs should remain eligible for the regular Hangars that we already have, counting total tonnage of craft according to the existing rules when doing so. This affords the player some tactical flexibility and doesn't needlessly or arbitrarily reduce functionality. A player can RP that GSFs need "special" equipment that only GSF Hangars have if they wish. The Class Design Window should classify GSF / Fighter hybrids as Fighters, and instead of the line showing GSF exemptions and boni (if any) it will instead inform the player that this Fighter can perform Ground Missions.

 --- That's my full suggestion. I personally think it'd be a rather minimum effort solution overall, since GSFs already have some sort of code marking them as special and as you mentioned before they already function completely differently to Naval Ships. Adding one or a few components, while granting them some logistical exemptions I feel is the important change while resistance / immunity to Shock Damage from AA is important more for the sake of consistency than for the sake of buffing or nerfing. As always, feedback is welcome. ;D
Title: Re: C# Suggestions
Post by: xenoscepter on December 06, 2021, 06:25:24 PM

Frankly the only reason I can see to preserve the current GSFs is roleplay as some people are very attached to the "aerospace fighter" concept. However, as much as I value supporting RP in Aurora, it cannot support every possible RP setting equally and mechanically the current system just doesn't work - for many more reasons than just micromanagement hell.


Frankly, they can't even do that now in the current system. My favorite anime growing up was Macross/Robotech. There is no way to recreate that currently. "Fighters" are 2x the size and 4x the crew of the Rocinante from The Expanse.

The most efficient fighter, and only one really worth using is a set of box launchers with an engine.

I would love to have a legit Macross or Battlestar galactica inspired campaign, but the extent i would have to "suspend belief" would just ruin the whole mood of the campaign to the point i'd probably quit it before i've played for an hr.

 --- Yeah, though to be fair, Aurora tends to be unfriendly towards Science Fantasy anyway. Star Wars, BSG, Superdimensional Fortress Macross, Gundam... just about anything with sufficiently large quantities of Handwavium tends to not mix well with Aurora. 40K and Battletech do though, almost as if the creator has some kind of bias towards one of them or something. Hmmmm...
Title: Re: C# Suggestions
Post by: Migi on December 06, 2021, 06:57:33 PM
--- Imagine this in the Class Design Window for a moment. GSFs are already flagged as such for the purposes of combat and planetary interaction, so why not production and auto-assignment as well?
(snip)
GSFs are, again, already flagged differently from regular fighters. That's how they avoid provoking STO fire on Ground Missions
I've never seen a ship classed as a GSF before, only as a Fighter. Or are you extrapolating?

Mechanically the fact that fighters are not targeted by STOs when participating in combat is probably a flag applied to a fleet, or specific ships inside a fleet.
If you apply it to a ship class then you would have an untouchable ground unit killing machine, park it 15k from the planet and just plink away forever (or until it dies from breakdowns).

Personally I don't think ship design and ground unit design mesh very well together, so I think it would be better if things which operate in  ground combat should be designed via the ground combat design screen. Trying to interpret a ship design into a ground unit is essentially 'compressing' the information into a very small number of mechanics and I just don't see how you do it both automatically and well.
Title: Re: C# Suggestions
Post by: xenoscepter on December 06, 2021, 07:14:08 PM
--- Imagine this in the Class Design Window for a moment. GSFs are already flagged as such for the purposes of combat and planetary interaction, so why not production and auto-assignment as well?
(snip)
GSFs are, again, already flagged differently from regular fighters. That's how they avoid provoking STO fire on Ground Missions
I've never seen a ship classed as a GSF before, only as a Fighter. Or are you extrapolating?

Mechanically the fact that fighters are not targeted by STOs when participating in combat is probably a flag applied to a fleet, or specific ships inside a fleet.
If you apply it to a ship class then you would have an untouchable ground unit killing machine, park it 15k from the planet and just plink away forever (or until it dies from breakdowns).

Personally I don't think ship design and ground unit design mesh very well together, so I think it would be better if things which operate in ground combat should be designed via the ground combat design screen. Trying to interpret a ship design into a ground unit is essentially 'compressing' the information into a very small number of mechanics and I just don't see how you do it both automatically and well.

 --- I said "Imagine this in the Class Design Window for a moment." How could I have expressed any clearer that there is no such class and that I'm asking you to imagine that there is for a moment? Now, mechanically speaking, I have no idea, nor any care at all, how or to what that flag is applied to. Nor does it matter all that much. In practice, there exists flags separating GSFs from regular ships. That is to say, all GSFs are ships, but not all ships are GSFs and the game has code to make that happen. This only matters insomuch as that code might provide a convenient way to make the proposed changes. Thats it. Nothing more.

 --- I do not understand how you came to the idea that GSFs would become unstoppable ground unit killing machines. I'm left wondering if you actually bothered to read through the proposal or just skimmed through and jumped to conclusions? If these changes were implemented, GSFs would still be able to be shot at by AA. They could not and would not plink away forever at anything. GSFs are only immune to STOs when they are on Ground Missions like CAS or CAP... this is already a thing. While they plink away at STOs they're still getting rammed by AA like always. At what point during my suggestion did you assume I meant that the EXACT flag which gave GSFs immunity to STOs specifically when they fly Ground Support Missions should be applied to a class of ship to provide full immunity to... well everything I guess since you said unstoppable. At what point did I mention a 15,000 kilometer range? I mentioned that the HYPOTHETICAL design class of GSF be prohibited from ship weapons and even sensors if it wants to benefit from the changes.

*Edited for tone.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 06, 2021, 07:19:47 PM
Personally I don't think ship design and ground unit design mesh very well together, so I think it would be better if things which operate in  ground combat should be designed via the ground combat design screen. Trying to interpret a ship design into a ground unit is essentially 'compressing' the information into a very small number of mechanics and I just don't see how you do it both automatically and well.

I tend to agree. While I do agree with xenoscepter that it would be best to preserve as much of the unique flavor of GSFs as possible, I have a very hard time seeing what in terms of mechanics a unique GSF class accomplishes that merits separating GSFs from ground units and ground combat mechanics. If we are going to create a unique ship class which cannot participate in naval combat or naval operations, while having distinctive HTK, armor, and other mechanical bonuses that make it behave unlike any other class of ship (and would preclude it being usable for anything other ships can do, except for ground combat, for obvious balance reasons)... at that point we have a ground unit that goes in a special hangar. Why not just call it what it is? If we need a special mechanic to allow ground formations composed entirely of GSFs to ride in hangars instead of transport bays that's fine, but there's no reason to call these "ships" if they don't walk like a ship, talk like a ship, quack like a ship...

Look at it from the opposite angle: let's say we have a GSF ground unit type which we can design in a ship-like manner, similar to STOs but a bit more involved so we can really customize our GSFs. Set it up to work with the ground combat mechanics but with special rules for fighters so they are vulnerable to AA but resistant to other ground units. For the full nine yards, add a new troop transport - hangar bay which can only transport GSF units and can deploy them from orbit. Sprinkle some automation on top and voila!

Now, looking at this, what do we gain from making this GSF ground unit a special type of "ship" - which cannot do anything another type of "ship" can except for being stuffed into hangars and siphoning off LCDRs? I can't see any reason why GSFs being a "ship" is beneficial - so why keep it that way just because that's how it already is? Sometimes a change is good.

The only benefit I can think of is that these could be built with fighter factories instead of GFTCs, which is admittedly a fair point. An exception could be made, but ultimately I would prefer that GFTCs be reworked to function like any other planetary industry instead of the silly 1 GFTC = 1 formation at a time restriction.
Title: Re: C# Suggestions
Post by: Droll on December 06, 2021, 07:23:10 PM
--- Can we just, ya know... not? I personally like GSF creation, but just hate the micromanagement. A re-work of how AA and GSF interact might be needed for balance, but still. I hate the idea of GSFs being ground units. Instead of all of this, let's just have a window like VB6 for squadrons, alongside an organizational tool to build to them.

The problem is really one of scale, not only micromanagement. To be of any real use GSFs need to be fielded by the hundreds if not thousands, otherwise the impact is too little and the fighters are destroyed in only a few rounds by AA - the NPRs at least field frankly excessive amounts of AA, but even a modest allocation of ~10 AA units per formation means that easily several hundred to thousands of AA guns are present at any significant planetary battle. To effectively counter this requires much more than just several squadrons of GSFs, we really need to start thinking in terms of WWII-esque air wings of ~100 planes each.

So...we have a need for hundreds, even thousands of specialized ships which are only usable for ground combat. At that scale it is completely impractical to populate them with commanders for each ship, so we either just don't do this or we introduce a new mechanic just for GSFs to have commanders on a squadron basis instead. As far as ship design, AFAIK the speed of GSFs has no bearing on combat, so the only things that matter are the weapon and armor (and the latter is very much arguable as others have shown).

So we have a "ship" type which is only usable in ground combat, needs to be built by the hundreds, is too small and numerous or individual commanders, and has no relevant design parameters aside from the weapon and armor. At that point, this perfectly describes a ground unit class. Why not just take the logic to its conclusion, in the process using mechanics which are 90% preexisting to simplify the implementation for Steve?

Frankly the only reason I can see to preserve the current GSFs is roleplay as some people are very attached to the "aerospace fighter" concept. However, as much as I value supporting RP in Aurora, it cannot support every possible RP setting equally and mechanically the current system just doesn't work - for many more reasons than just micromanagement hell.

 --- I don't see the problem here, or rather, why the problem is one of scale rather than balance. Either AA needs to be nerfed, GSFs needed to be buffed, or both.

The most GSF fighters I've ever used a single planetary invasion was 60 and I had a MASSIVE tech advantage over the enemy. I play a modded DB which means that the advantages were stacked even more in my favor than otherwise. Specifically, my fighters had 27 shields and 9 armor layers.

Aside from mothership assignment at construction, I have to individually assign every single one to a formation to provide support for which takes a good while.

During combat my fighters were actually able to survive getting hit. Most of the time, this resulted in the incapacitation of the fighter. Every time this happens, I have to order the fighter(s) to dock at the carrier, then increment by 5 secs to dock them at the carrier. If the fighter isn't incapacitated, its even worse. Because now I have dock at the carrier again (if I want it to survive) and then check the carrier to see if it's armor has been repair so I can detach, then re-add to the fighter wing. Oh and I also have to reassign its supported formation.

This formation of 60 fighters were able to destroy, give or take 2-3k of the enemy forces using triple S12 autocannons that could penetrate both infantry and light armor. The battle was more than 10m+ tons of ground forces.

This is where the problem of scale arises, the damage I think is fine but there is no feasible way for me to handle any substantial amount of GSFs without dying of old age. Theoretically, there is nothing stopping me from fielding 1000s of GSFs but the micromanagement of having to both assign their supports and then babysit them during combat makes them completely unfeasible. 

I don't think the problem is that of AA being too powerful or GSFs being too weak, we just cannot field an equivalent force of fighters against their AA counterparts. There's no point discussing AA balance if we've got 20k+ AA tanks and even more AA infantry firing on 60 GSFs. Of course the AA is going to have a massive advantage.
Title: Re: C# Suggestions
Post by: xenoscepter on December 06, 2021, 07:32:02 PM
Personally I don't think ship design and ground unit design mesh very well together, so I think it would be better if things which operate in  ground combat should be designed via the ground combat design screen. Trying to interpret a ship design into a ground unit is essentially 'compressing' the information into a very small number of mechanics and I just don't see how you do it both automatically and well.

I tend to agree. While I do agree with xenoscepter that it would be best to preserve as much of the unique flavor of GSFs as possible, I have a very hard time seeing what in terms of mechanics a unique GSF class accomplishes that merits separating GSFs from ground units and ground combat mechanics. If we are going to create a unique ship class which cannot participate in naval combat or naval operations, while having distinctive HTK, armor, and other mechanical bonuses that make it behave unlike any other class of ship (and would preclude it being usable for anything other ships can do, except for ground combat, for obvious balance reasons)... at that point we have a ground unit that goes in a special hangar. Why not just call it what it is? If we need a special mechanic to allow ground formations composed entirely of GSFs to ride in hangars instead of transport bays that's fine, but there's no reason to call these "ships" if they don't walk like a ship, talk like a ship, quack like a ship...

Look at it from the opposite angle: let's say we have a GSF ground unit type which we can design in a ship-like manner, similar to STOs but a bit more involved so we can really customize our GSFs. Set it up to work with the ground combat mechanics but with special rules for fighters so they are vulnerable to AA but resistant to other ground units. For the full nine yards, add a new troop transport - hangar bay which can only transport GSF units and can deploy them from orbit. Sprinkle some automation on top and voila!

Now, looking at this, what do we gain from making this GSF ground unit a special type of "ship" - which cannot do anything another type of "ship" can except for being stuffed into hangars and siphoning off LCDRs? I can't see any reason why GSFs being a "ship" is beneficial - so why keep it that way just because that's how it already is? Sometimes a change is good.

The only benefit I can think of is that these could be built with fighter factories instead of GFTCs, which is admittedly a fair point. An exception could be made, but ultimately I would prefer that GFTCs be reworked to function like any other planetary industry instead of the silly 1 GFTC = 1 formation at a time restriction.

 --- Well, for one we already have them in the ship design window. Why are we throwing that out? I can launch GSFs from outside of orbit, so they are space faring ships. When not on Ground Support Missions, they can be fired on by STOs and ships... like ships. They can attack other GSFs when on CAP, like ship to ship combat. They use a form of missile as a weapon, which uses ship mechanics. All this stuff already exists, why are we gutting it? For what? Why not use it instead of throw it away?

 --- What do we lose? Well for one thing, we can't deploy our GSFs from outside of STO range, so now you have to bring the carrier in range or kill of the STOs before you deploy any GSFs. You cannot have a design for an assault ship that can tank and a design, potentially Commerical, which hangs back and deploys fighters. For another, an FFD is only 60 Tons of Ground Unit. You can quite easily stuff several of those into a fighter's Troop Transport Bays AND fit Fighter Pod Bays. They need to be a ship for all of that to work... or perhaps a better way to say it would be, it needs a bigger re-write to NOT need that to work.

 --- I could say more, but frankly at this point I'm one trying to argue. I feel like no one is listening and I'm getting hot under the collar. Whether no is listening or is has become irrelevant, I need to go chill.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 06, 2021, 08:06:02 PM
--- Well, for one we already have them in the ship design window. Why are we throwing that out? I can launch GSFs from outside of orbit, so they are space faring ships. When not on Ground Support Missions, they can be fired on by STOs and ships... like ships. They can attack other GSFs when on CAP, like ship to ship combat. They use a form of missile as a weapon, which uses ship mechanics. All this stuff already exists, why are we gutting it? For what? Why not use it instead of throw it away?

This the point I'm trying to get at - just because we already have something doesn't mean we should keep it. I am asking - if we did not already have GSFs as a space-faring ship type, what reason would we have to make them so. If there is no good reason (and that's an open question), then there is no reason to keep them this way either - if a better alternative exists, which I believe there does.

Quote
--- What do we lose? Well for one thing, we can't deploy our GSFs from outside of STO range, so now you have to bring the carrier in range or kill of the STOs before you deploy any GSFs. You cannot have a design for an assault ship that can tank and a design, potentially Commerical, which hangs back and deploys fighters. For another, an FFD is only 60 Tons of Ground Unit. You can quite easily stuff several of those into a fighter's Troop Transport Bays AND fit Fighter Pod Bays. They need to be a ship for all of that to work... or perhaps a better way to say it would be, it needs a bigger re-write to NOT need that to work.

This is a fair point. From a mechanical perspective, I could argue that in this situation the correct way to deploy would be to use a transport bay (normal, or a new 'hangar' type) the same way as one would otherwise use an armored assault drop transport to deliver troops to the ground (and we do need to do this - while GSFs can do missions without ground units to provide FFD, I believe only the direct ground support mission precludes STO fire - someone else can confirm?). Flavor-wise, however, this does seem to be a small loss since the flavor of a carrier-to-ground assault is certainly interesting (otherwise no one would care about GSFs). I don't have a good answer for that right now, admittedly.

However, in an effort to speak positively for my own opinion, I do think there are a lot of flavor gains from converting air units to function as ground units instead of ships. One of my personal big motivations is that right now, we don't have a good unit class to model things like the US Army combat aviation brigades (and similar formations in other armies), or for that matter the entire US Air Force even if one could argue that an air force might be obsolete in the TN Space Era (arguable, IMO!). Particularly for conventional starts this is a piece of flavor I miss and have no good way to model to my satisfaction, since LVH, VEH, etc. are vulnerable to entirely the wrong types of weapons and not vulnerable to the AA weapons a helicopter or air fighter should be. Droll's examples of the scaling problems are also important IMO, a proper air fighter force really should be 100s to 1,000s of planes, not several dozen arranged into a few squadrons.

I do also think this kind of change would be very helpful for NPRs since they can use a new ground unit type much more easily than teaching them how to use fighters. The AA components would then become much more relevant for the player against NPRs, which I think is a huge flavor win as currently AA weapons are just dead weight against NPRs yet any modern army deploys many SAMs, etc.

Quote
--- I could say more, but frankly at this point I'm one trying to argue. I feel like no one is listening and I'm getting hot under the collar. Whether no is listening or is has become irrelevant, I need to go chill.

Hopefully now we are all seeing each other's sides more clearly.  :)
Title: Re: C# Suggestions
Post by: alex_brunius on December 07, 2021, 12:17:27 AM
This the point I'm trying to get at - just because we already have something doesn't mean we should keep it. I am asking - if we did not already have GSFs as a space-faring ship type, what reason would we have to make them so. If there is no good reason (and that's an open question), then there is no reason to keep them this way either - if a better alternative exists, which I believe there does.

I think I've written this before and at risk of repeating the previous discussion IMO the main ( possibly only? ) reason to keep the hybrid space/atmospheric fighters around is to support Sci Fi stories and universes which more often than not have space capable fighters support ground units in combat.


Another question that might be interesting to asking is, would there be room for both?

In reality just because it's possible to design a space capable hybrid fighter doesn't mean it's not also possible to design cheaper models that are more numerous but only capable of atmospheric flight and acts more like ground units. This new type could also include helicopters and other vehicles faster and more agile than light vehicles like say star wars speeder bikes, hoverbikes and various tiltrotors. Potentially it could also be split up in different mechanics for long range versions ( support ) and direct fire ( normal ground unit ) depending on what you arm them with.

It would be a bit messy/tricky to code when they start interact with hybrid fighters and AA for sure so might take alot of effort to get it right, that's the main downside I can imagine, but on the other hand completely rewriting current fighter mechanics is no simple task either.
Title: Re: C# Suggestions
Post by: smoelf on December 07, 2021, 04:24:23 AM
So...we have a need for hundreds, even thousands of specialized ships which are only usable for ground combat. At that scale it is completely impractical to populate them with commanders for each ship, so we either just don't do this or we introduce a new mechanic just for GSFs to have commanders on a squadron basis instead. As far as ship design, AFAIK the speed of GSFs has no bearing on combat, so the only things that matter are the weapon and armor (and the latter is very much arguable as others have shown).

So we have a "ship" type which is only usable in ground combat, needs to be built by the hundreds, is too small and numerous for individual commanders, and has no relevant design parameters aside from the weapon and armor. At that point, this perfectly describes a ground unit class. Why not just take the logic to its conclusion, in the process using mechanics which are 90% preexisting to simplify the implementation for Steve?

I'm a bit late to the discussion, but just wanted to comment that speed does affect combat. For ground-based AA-fire: "The chance to hit is (10% x (Tracking Speed / Aircraft Speed) x (Morale / 100)) / Environment Modifier." (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Ground-based_AA_Fire (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Ground-based_AA_Fire)). I'm currently preparing to invade the Rahkas with 200 fighters where I have increased the speed from 9.500 to 15.000 and reduced the number of fighter pods from 2 to 1 to see if the survivability outweighs the lower fire power.

I also disagree that the commander issue is really a problem. You can set the priority of the fighters really low, so they fill up last. Sure, you won't get the bonus of a commander, but I don't get that anyway now because I have way too many fighters for my commander production. I think we would also need to see how the latest change to commander production and assignment affects this before making any drastic changes.

For me, all I really need is a way to auto-assign GSF to units with FFD's OR implement a sub-fleet system for the ground combat window and assign by dragging a sub-fleet. I like the ability to design various types of GSF's and while I wouldn't oppose a rework of the system, I would really want it to still offer the possibilities and flexibility of the current system, where you have a series of interesting choices regarding engine power, size of fighter pod, number of fighter pods etc.

I used it rather effectively against Rahkas, where the existence of 100 fighters significantly reduced my ground unit losses. Because I was behind in tech, I could design some fighter pods manually that exceeded the armor and hitpoints of the enemy and thus ensure kills that my ground units could not get. (See also: http://aurora2.pentarch.org/index.php?topic=11545.msg156253#msg156253 (http://aurora2.pentarch.org/index.php?topic=11545.msg156253#msg156253))

--- Well, for one we already have them in the ship design window. Why are we throwing that out? I can launch GSFs from outside of orbit, so they are space faring ships. When not on Ground Support Missions, they can be fired on by STOs and ships... like ships. They can attack other GSFs when on CAP, like ship to ship combat. They use a form of missile as a weapon, which uses ship mechanics. All this stuff already exists, why are we gutting it? For what? Why not use it instead of throw it away?

This the point I'm trying to get at - just because we already have something doesn't mean we should keep it. I am asking - if we did not already have GSFs as a space-faring ship type, what reason would we have to make them so. If there is no good reason (and that's an open question), then there is no reason to keep them this way either - if a better alternative exists, which I believe there does.

The system has been designed to that you can repurpose 'real' fighters to GSF's by loading fighter pods into box launchers. That current interaction between space fighters and GSF's would be lost entirely if it was reworked to a pure ground unit system. Now, I haven't done this yet, but I imagine there is a reason behind it if Steve made sure that fighter pods could be loaded into box launchers.

This is all with the caveat that I haven't yet invaded an NPR, but the increase in scale of production and assignment from spoiler races to NPR is going to be the same for ground units and GSF's.
Title: Re: C# Suggestions
Post by: KriegsMeister on December 07, 2021, 05:08:02 AM
If you compare the tonnage of modern aircraft to our current in-game fighters, there is a massive lopsidedness.  Even the smallest built aurora fighter is going to be well over a 100Tons since it's very difficult until endgame tech to make an even usable design less than that.  This would put even the smallest fighters in the strategic bomber weight class in today's world, a B-52 stratofortress weighs ~200T with payload (and yes I know Aurora tonnage isn't literal gross mass, but it's close enough).

To represent a modern/futuristic atmospheric fighter or attack helicopter would need to be well below that 100 Ton mark and would ve better as a build able "ground" unit, for example an AH-64 apache sits around ~10 T and an F-35 Lightning II at ~30 T combat loads.

I would keep our space borne craft, but remove the fighter pods, and just use normal missiles and beam weapons as strategic strike craft.  Could maybe use engineless all warhead designs as cheap atmospheric bombs.  Then let's add air units that utilize ground weapons to represent the air superiority fighters and attack heli's. 

I would also add, they should not be able to use vehicle armor and would use the current racial infantry armor, since even the largest aircraft with the strongest engines can only carry a very small bit of armor plate to protect the cockpit and maybe the engines.  This makes air targets hard to hit but easy to destroy as a decent game design balance.
Title: Re: C# Suggestions
Post by: cdrtwohy on December 07, 2021, 05:29:47 AM
Personally it think fighters in general need a redo for a myriad of reasons starting with the fact that to be really useful (IMHO) you need ton of them meaning a ton of micro, add the fact that our officer corps doesn't fully represent jr officers being able to "command" ships in a concrete way ( technically we can say unassigned ships are commanded by Jr officers), Fighters are too big in size and crew, have to long of a deployment time and require a dedicated warship to carry them that needs a shipyard to build that would be better used for other offensive warships .

I personally don't think even with an RP element that Fighters are worth the investment based on the amount of hassle that they are. in fact I only build them for RP reasons as cheap PPV cover in the Core systems but with the pirate faction coming in 2.0 that might have to stop
Title: Re: C# Suggestions
Post by: Jorgen_CAB on December 07, 2021, 08:19:47 AM
I think the general consensus is that ground support fighters are OK in terms of balance but is made unusable because of micromanagement issues, they simply take up too much time to deploy in the numbers you generally would need to have them.
Title: Re: C# Suggestions
Post by: Scout1 on December 07, 2021, 08:33:51 AM
Quote from: Jorgen_CAB link=topic=10640. msg157575#msg157575 date=1638886787
I think the general consensus is that ground support fighters are OK in terms of balance but is made unusable because of micromanagement issues, they simply take up too much time to deploy in the numbers you generally would need to have them.

It is very difficult to make a fighter that's even vaguely cost-efficient at killing things on the ground, even assuming you have FFD and they're specifically in a micromanaged support role.

The only good thing about them is that AA fire seems to be rate-limited, so if you threw 1000+ fighters at a ground formation at once you could attrite them faster than you.
Title: Re: C# Suggestions
Post by: serger on December 07, 2021, 08:55:15 AM
I think the general consensus is that ground support fighters are OK in terms of balance but is made unusable because of micromanagement issues, they simply take up too much time to deploy in the numbers you generally would need to have them.

That's... pointlessly averaged, let's say, statement.
Against lowest tech AA (smth like early conventional-start or lowest TN start multifaction game) GSFs are absolutely overpowered in some sense, because lowest AA just cannot pierce anything, and so GSFs are invulnerable.
Against any other opponent they are very vulnerable and quite underpowered at the same time, if you don't use huge ugly fat behemoth "fighters", armoured enough to withstand single average AA hit, at which point they became quite balanced at the cost of both more and more manic micromanagement and disbelieve because of compelled game mechanics abuse.
Yet in average of these extremes they'll be OK balanced, yes.
Title: Re: C# Suggestions
Post by: Iceranger on December 07, 2021, 09:47:02 AM
I'm a bit late to the discussion, but just wanted to comment that speed does affect combat. For ground-based AA-fire: "The chance to hit is (10% x (Tracking Speed / Aircraft Speed) x (Morale / 100)) / Environment Modifier." (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Ground-based_AA_Fire (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Ground-based_AA_Fire)). I'm currently preparing to invade the Rahkas with 200 fighters where I have increased the speed from 9.500 to 15.000 and reduced the number of fighter pods from 2 to 1 to see if the survivability outweighs the lower fire power.

I recall earlier tests showed the AA tracking and fighter speed interaction isn't properly implemented, right now AA has very high accuracy against fighters AFAIK.
Title: Re: C# Suggestions
Post by: DawnMachine on December 07, 2021, 10:02:30 AM
It would be great to be able to mark the system on the main screen.  So that such systems are at the top of the drop-down list.
Title: Re: C# Suggestions
Post by: Droll on December 07, 2021, 10:32:07 AM
I think the general consensus is that ground support fighters are OK in terms of balance but is made unusable because of micromanagement issues, they simply take up too much time to deploy in the numbers you generally would need to have them.

That's... pointlessly averaged, let's say, statement.
Against lowest tech AA (smth like early conventional-start or lowest TN start multifaction game) GSFs are absolutely overpowered in some sense, because lowest AA just cannot pierce anything, and so GSFs are invulnerable.
Against any other opponent they are very vulnerable and quite underpowered at the same time, if you don't use huge ugly fat behemoth "fighters", armoured enough to withstand single average AA hit, at which point they became quite balanced at the cost of both more and more manic micromanagement and disbelieve because of compelled game mechanics abuse.
Yet in average of these extremes they'll be OK balanced, yes.

The tech threshold where fighters become obsolete is the point where enemy AA can reliably do shock damage to a 500t craft. At that level your point about "...armored enough to withstand single average AA hit..." is rendered moot, as shock damage effectively bypasses armor and if not destroy, will render the fighter incapacitated.

The only reason my fighters in an above posted example were able to survive anything was because of shields in a highly modded DB.
Title: Re: C# Suggestions
Post by: serger on December 07, 2021, 10:42:20 AM
The tech threshold where fighters become obsolete is the point where enemy AA can reliably do shock damage to a 500t craft. At that level your point about "...armored enough to withstand single average AA hit..." is rendered moot, as shock damage effectively bypasses armor and if not destroy, will render the fighter incapacitated.

Well, yes, this upper extreme is (in vanilla) very thin thing too.
Yet it's only a reinforcement of my main point: there is no general consensus that ground support fighters are OK in terms of balance, if you don't use the term with very pointlessly averaged sense, and it's more like there is nearly general consensus that ground support fighters are underpowered even if you are manic enough to use them in significant numbers.
Title: Re: C# Suggestions
Post by: smoelf on December 07, 2021, 11:46:00 AM
I'm a bit late to the discussion, but just wanted to comment that speed does affect combat. For ground-based AA-fire: "The chance to hit is (10% x (Tracking Speed / Aircraft Speed) x (Morale / 100)) / Environment Modifier." (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Ground-based_AA_Fire (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Ground-based_AA_Fire)). I'm currently preparing to invade the Rahkas with 200 fighters where I have increased the speed from 9.500 to 15.000 and reduced the number of fighter pods from 2 to 1 to see if the survivability outweighs the lower fire power.

I recall earlier tests showed the AA tracking and fighter speed interaction isn't properly implemented, right now AA has very high accuracy against fighters AFAIK.

If that is the case, then I see why excessive AA severely limits the effectiveness of GSF's, but it also means that we don't really have a way of evaluating them properly if they aren't implemented completely yet. At the very least it shows that speed should be a design parameter if a rework is to be done. That would also speak to the above points about armor. If you can't increase survivability by increasing speed, but only through armor, then shock damage at higher tech levels become debilitating.
Title: Re: C# Suggestions
Post by: Migi on December 07, 2021, 12:08:25 PM
I would like 2 extra steps added to the BFC range options:
2.5x range and 3.5x range
I'd also like it if range dropdown was sorted in order, like the range dropdown.
Title: Re: C# Suggestions
Post by: DawnMachine on December 07, 2021, 12:43:19 PM
I would like to be able to group the contacts of missiles located at one point.  So that minefields can be used.  I also did not find a way to hide the missile contacts.
Title: Re: C# Suggestions
Post by: Droll on December 07, 2021, 12:54:00 PM
I'm a bit late to the discussion, but just wanted to comment that speed does affect combat. For ground-based AA-fire: "The chance to hit is (10% x (Tracking Speed / Aircraft Speed) x (Morale / 100)) / Environment Modifier." (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Ground-based_AA_Fire (http://aurorawiki.pentarch.org/index.php?title=C-Ground_Combat#Ground-based_AA_Fire)). I'm currently preparing to invade the Rahkas with 200 fighters where I have increased the speed from 9.500 to 15.000 and reduced the number of fighter pods from 2 to 1 to see if the survivability outweighs the lower fire power.

I recall earlier tests showed the AA tracking and fighter speed interaction isn't properly implemented, right now AA has very high accuracy against fighters AFAIK.

If that is the case, then I see why excessive AA severely limits the effectiveness of GSF's, but it also means that we don't really have a way of evaluating them properly if they aren't implemented completely yet. At the very least it shows that speed should be a design parameter if a rework is to be done. That would also speak to the above points about armor. If you can't increase survivability by increasing speed, but only through armor, then shock damage at higher tech levels become debilitating.

The problem I have with speed and GSFs is what happens with planets that have atmospheres. You can very easily get GSFs with comparable speed to missiles way beyond the racial tracking which I assume AA will use. How would you model the effect of atmospheric pressure on the top speed / effective evasive ability of GSFs? Would you even gain anything mechanically from modelling that? There isn't really a way to design the aerodynamic profile of fighters, all we know is that they can land/takeoff from planets that may or may not have atmospheres.

And this is completely ignoring the whole issue of air-to-air combat, which has not been a part of the GSF discussions for the obvious reason of NPRs don't use fighters.
Title: Re: C# Suggestions
Post by: xenoscepter on December 07, 2021, 03:00:11 PM
he problem I have with speed and GSFs is what happens with planets that have atmospheres. You can very easily get GSFs with comparable speed to missiles way beyond the racial tracking which I assume AA will use. How would you model the effect of atmospheric pressure on the top speed / effective evasive ability of GSFs? Would you even gain anything mechanically from modelling that? There isn't really a way to design the aerodynamic profile of fighters, all we know is that they can land/takeoff from planets that may or may not have atmospheres.

And this is completely ignoring the whole issue of air-to-air combat, which has not been a part of the GSF discussions for the obvious reason of NPRs don't use fighters.

 --- GSFs are Trans-Newtonian, they don't fully exist in our reality, so it makes some sense that the laws of aerodynamics as we know them might not fully apply to them or indeed even apply at all.
Title: Re: C# Suggestions
Post by: Droll on December 07, 2021, 03:57:28 PM
he problem I have with speed and GSFs is what happens with planets that have atmospheres. You can very easily get GSFs with comparable speed to missiles way beyond the racial tracking which I assume AA will use. How would you model the effect of atmospheric pressure on the top speed / effective evasive ability of GSFs? Would you even gain anything mechanically from modelling that? There isn't really a way to design the aerodynamic profile of fighters, all we know is that they can land/takeoff from planets that may or may not have atmospheres.

And this is completely ignoring the whole issue of air-to-air combat, which has not been a part of the GSF discussions for the obvious reason of NPRs don't use fighters.

 --- GSFs are Trans-Newtonian, they don't fully exist in our reality, so it makes some sense that the laws of aerodynamics as we know them might not fully apply to them or indeed even apply at all.

How does the TN lore fit into ground wars? Are all infantrymen fighting in the aether because the power armor they wear are at least partially made of vendarite? Is it the same with their weapons? What about the tanks?

If they are somewhat in the aether then why does dominant terrain even have an effect on combat? Surely the fighting must still happen in our reality because of that as I am not aware of the aether being affected by planetary topology.

Also how does a fighter flying through the aether attack things on the surface of a planet? Do bombs and missiles just vanish from their bomb-bays and teleport to the correct spatial coordinate? Even so does a GSF flying at 60k km/s have the ability to even be targeted by ground AA? After all this thing could drop a bomb beyond the horizon and then disappear beyond AA range but they obviously can't since they have to be at the planet to run CAS missions. Would such a fighter even be able to attack with any degree of accuracy? Does it have to slow down during the attack run?

At least with space ships and STO weapons fire they are all existing in the aether so you don't need shots to effectively be trans-dimensional but I think the deliberately vague TN lore kind of fails in the context of planetary warfare.
Title: Re: C# Suggestions
Post by: Density on December 07, 2021, 04:24:40 PM
And this is completely ignoring the whole issue of air-to-air combat, which has not been a part of the GSF discussions for the obvious reason of NPRs don't use fighters.
That's a thing I've been thinking about while reading this discussion. If there were air units that were built as ground units, those should be much easier to implement for NPRs than GSF.

That being said, I do kinda like alex's "why not both?" suggestion. That is, add air units that are designed and built as ground units to represent tiny (in Aurora scale) atmo-only aircraft, while leaving GSF like they are now. There would still, idealy, be some rework to GSF, starting with addressing the micromanagement problem; either some way of autoassigning them or some other change to how they interact with ground combat so they don't have to be assigned one at a time in the first place.
Title: Re: C# Suggestions
Post by: Garfunkel on December 07, 2021, 09:12:13 PM
The problem with Xenoscepter's suggestion on how to improve existing GSF is that it introduces several new special rules, which is a thing that Steve has wanted to get away from. In fact, reading your post makes the new GSF sounds very much like the old PDC, in that they are a ship but, on a planet, and with a bunch of exceptions affecting them.

The scale issue is certainly real and for that purpose, as well as the ability to better portray current, past, and near-future conventional armies, I'd love to see GSF become a 'proper' ground unit, especially if auto-assignment is introduced.

For all the reasons other people have already explained, keeping the space and the ground parts separate is probably for the best.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on December 08, 2021, 03:33:43 AM
I have always thought that fighters should have been a ground unit type. You could make them able to operate from space as a special ability, add a special module you can put into a ship or simply allow fighters to be transported in hangars as well as in troop transports or something.

In my opinion as already said, the current fighter mechanic have the same issues as the former PDC mechanic.

If we can't use box-launcher fighters as make shift ground support craft that is not a big loss because they are pretty bad at it anyway, especially as such craft rarely have any armour and would be destroyed even by light AA with little effort. The current fighter mechanic scale weirdly with increases technology as ground and space units use different mechanics for to hit and damage purposes.

Make ground fighters a ground unit and "fix" add some auto assignment of all types of support units be them artillery, fighters or ship bombardment. I also think all of these weapons should use FFD to target properly but should be able to support without.

Also make these support weapons have more impact on morale and not just damage to make them more worth while than they currently are. They probably also should increase the chance of breakthrough happening.

But then again I want ground units to have more combined arms effect in general so combat become a bit more dynamic and interesting. It currently is a bit one dimensional.
Title: Re: C# Suggestions
Post by: DEEPenergy on December 08, 2021, 07:56:00 AM
Grouping civilian contacts like we can group other contacts. So if you have a bunch of civilian ships sitting on earth it would look like Civilian Freight (x32) instead of listing them all.
Title: Re: C# Suggestions
Post by: Scout1 on December 08, 2021, 10:56:37 AM
Pretty sure this has been mentioned before but it came up in the community discord and I realized it's still missing from C#:

Galaxy map zoom levels.  Zoom in! Zoom out! Especially zoom out!
Title: Re: C# Suggestions
Post by: ArcWolf on December 08, 2021, 01:28:29 PM
Grouping civilian contacts like we can group other contacts. So if you have a bunch of civilian ships sitting on earth it would look like Civilian Freight (x32) instead of listing them all.

would be great to see. One issue is civilian ships almost never form a fleet, so you wind up with 100s of single ship fleets. Having them group up would be nice too.
Title: Re: C# Suggestions
Post by: cdrtwohy on December 08, 2021, 03:28:16 PM
Grouping civilian contacts like we can group other contacts. So if you have a bunch of civilian ships sitting on earth it would look like Civilian Freight (x32) instead of listing them all.

would be great to see. One issue is civilian ships almost never form a fleet, so you wind up with 100s of single ship fleets. Having them group up would be nice too.

letting Civs build a fleets would help with late game slow down as well having 100s of objects to check every update is a lot of work on the code too.
Title: Re: C# Suggestions
Post by: Migi on December 08, 2021, 09:33:40 PM
I would like the option to hide comets and comet names for the tactical map. Sol is lousy with them and AFIK they are the only thing you can't hide.
Title: Re: C# Suggestions
Post by: serger on December 09, 2021, 03:26:06 AM
Also make these support weapons have more impact on morale and not just damage to make them more worth while than they currently are. They probably also should increase the chance of breakthrough happening.

Yep, because that's why they are effective IRL both for blitzkrieg and attrition strategies, despite their very bad cost / fire performance comparing to arty: you can concentrate nearly all of your air forces to support on narrow breakthrough area even without relocation, yet usually you cannot do it with arty.

And for the attrition strategy - I think air strikes without FFD might have twice or more better chances to hit non-combat and rear units comparing to arty, because air units are partly FFDs for themselves by their nature.

But then again I want ground units to have more combined arms effect in general so combat become a bit more dynamic and interesting. It currently is a bit one dimensional.

I think the most generalized interpretation of combined arms effect is that there are inevitable local random conditions of different nature for every combat episode, and some of that conditions are very advantageous or disadvantageous for different unit types, and so if you have no units of currently advantageous type - you have to forfeit in this episode, you cannot avoid it because it's random and unpredictable. And it's the natural way to represent this effect ingame: instead of the same local conditions for every round and every formation, it's possible and not very hard to implement conditions with random distributions, dependant on dominant terrain type. I think it will be enough to have only two conditions: close and ranged combat, where first is halving both evasion (too close to evade) and armor (close enough to aim at inevitable weak points). More hard terrain - more probable close combat conditions are.
Title: Re: C# Suggestions
Post by: serger on December 09, 2021, 08:56:13 AM
Ow, I have forgoten to write down the second half of my suggestion: disadvantageous elements become temporarily non-combat. So, vehicles will hide behind infantry during close combat (if there is any infantry for them to hide behind), while infantry will hide behind vehicles during ranged combat (again, if there is any vehicles for them to hide behind).
Title: Re: C# Suggestions
Post by: Jorgen_CAB on December 09, 2021, 09:02:41 AM
Ow, I have forgoten to write down the second half of my suggestion: disadvantageous elements become temporarily non-combat. So, vehicles will hide behind infantry during close combat (if there is any infantry for them to hide behind), while infantry will hide behind vehicles during ranged combat (again, if there is any vehicles for them to hide behind).

Adding some different unit behaviour based on type and terrain would probably work and make different unit types more distinct and interact with each other. It is important that there is not one perfect unit formation strategy in the game. Clearly vehicles would be allot stronger on a barren moon landscape and require much less infantry support, only infrastructure (urban areas) would require some infantry in large quantities in such places. Unit types could also have different roles as well, or rather weapon type influence the role of the type etc...
Title: Re: C# Suggestions
Post by: kilo on December 09, 2021, 10:02:15 AM
Is it possible to add automatic naming for space stations, habitats, mining bases and so on? Right now every station, which is constructed by construction factory is named class name + number. This is quite unfitting for a mighty terraforming base for instance.
Title: Re: C# Suggestions
Post by: Migi on December 09, 2021, 01:55:17 PM
Is it possible to add automatic naming for space stations, habitats, mining bases and so on? Right now every station, which is constructed by construction factory is named class name + number. This is quite unfitting for a mighty terraforming base for instance.
You should be able to do this by assigning that class a name theme in the Class Design window, under the Miscellaneous tab.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 09, 2021, 02:06:47 PM
Is it possible to add automatic naming for space stations, habitats, mining bases and so on? Right now every station, which is constructed by construction factory is named class name + number. This is quite unfitting for a mighty terraforming base for instance.
You should be able to do this by assigning that class a name theme in the Class Design window, under the Miscellaneous tab.

Right now this only works for ships built out of shipyards. If you build fighters or stations with planetary industry, they are not named according to the selected naming scheme.
Title: Re: C# Suggestions
Post by: Migi on December 10, 2021, 02:08:29 PM
Is it possible to add automatic naming for space stations, habitats, mining bases and so on? Right now every station, which is constructed by construction factory is named class name + number. This is quite unfitting for a mighty terraforming base for instance.
You should be able to do this by assigning that class a name theme in the Class Design window, under the Miscellaneous tab.

Right now this only works for ships built out of shipyards. If you build fighters or stations with planetary industry, they are not named according to the selected naming scheme.
Then it isn't a suggestion, it needs to be reported as a bug.
Title: Re: C# Suggestions
Post by: Migi on December 11, 2021, 06:59:06 PM
Suggestion/Tweak:
When a ground survey reveals a new source of minerals, currently the message doesn't tell you the accessibility, I would like it if it did.
When a ground survey increases the number of minerals available, I would like it if it specifically told you that the accessibility was unchanged and what the accessibility currently is.
Title: Re: C# Suggestions
Post by: TMaekler on December 12, 2021, 04:27:14 PM
Factory Ratio:

How about a change in Factory Production? As we have it now, there is a "fixed" number of factories doing "general production", other doing "fighter production" and the rest is doing "ammunition production". All have fixed numbers of workers who don't do anything when you don't need new fighters or produce ammunition. So how about reducing the types of factories to one and having a three-split ratio as to how the factories are configured? In times of peace, you lower the % of fighter and ammunition production and in times of war, you need to increase it. This refit should of course cost some minerals, but this way one could manage industry more efficiently.
Title: Re: C# Suggestions
Post by: xenoscepter on December 12, 2021, 10:51:06 PM
Factory Ratio:

How about a change in Factory Production? As we have it now, there is a "fixed" number of factories doing "general production", other doing "fighter production" and the rest is doing "ammunition production". All have fixed numbers of workers who don't do anything when you don't need new fighters or produce ammunition. So how about reducing the types of factories to one and having a three-split ratio as to how the factories are configured? In times of peace, you lower the % of fighter and ammunition production and in times of war, you need to increase it. This refit should of course cost some minerals, but this way one could manage industry more efficiently.

 --- Now this? This I like. Maybe keep the existing ones as "specialized" industry that can only be used for one type.
Title: Re: C# Suggestions
Post by: alex_brunius on December 13, 2021, 03:57:13 AM
Factory Ratio:

How about a change in Factory Production? As we have it now, there is a "fixed" number of factories doing "general production", other doing "fighter production" and the rest is doing "ammunition production". All have fixed numbers of workers who don't do anything when you don't need new fighters or produce ammunition. So how about reducing the types of factories to one and having a three-split ratio as to how the factories are configured? In times of peace, you lower the % of fighter and ammunition production and in times of war, you need to increase it. This refit should of course cost some minerals, but this way one could manage industry more efficiently.

Reusing somewhat existing mechanics I can see two ways to do this.

1.) Adding conversion industry tasks similar to with conventional industry between the 3 ( for maybe somewhere around 5-20 cost per factory vs 120 for a new ).
2.) A functionality similar to the disable industry functionality where you can toggle between 3 states instead of just on/off where the 3:ed state is "peacetime" having the ammo/fighter factories work as maybe something like 80% normal TN factories and 20% ammo/fighter factories ( with something like 90-180 days ramp up or conversion time when they produce only 20% ammo/fighters while the TN factories are undergoing conversion ).
Title: Re: C# Suggestions
Post by: Blogaugis on December 13, 2021, 04:07:00 AM
I think the planetary industry needs a rework - I think factories should be more universal, than have 3... 4 separate installations (Construction factories, fighter factories, ammunition factories and ground force training facilities). Oh, and shipyards too (we have 3 different of these as well! Military shipyard, Civilian Shipyard and repair yard!  ;D )... Though, I suppose shipyards can stay.
The factories are a problem. Or rather, the so numerous types of them, and not really a proper way to cenvert them...
Oh and... I'd like conventional industry to be buildable too - though, perhaps this can be circumvented by Data Base editing?
Title: Re: C# Suggestions
Post by: ArcWolf on December 13, 2021, 04:30:57 AM

Oh and... I'd like conventional industry to be buildable too - though, perhaps this can be circumvented by Data Base editing?

yes, very easy to do, but you have to give them a cost because they have no material requirements. I did 40/40/40 Deranium/neutronium/Corundium to be "fair".
Title: Re: C# Suggestions
Post by: alex_brunius on December 13, 2021, 09:44:55 AM
1.) Adding conversion industry tasks similar to with conventional industry between the 3 ( for maybe somewhere around 5-20 cost per factory vs 120 for a new ).

Well this one was surprisingly easy to add through DB edit and appears to work fine when advancing time too...

(https://i.imgur.com/Eatu6k4.png)
( DIM_PlanetaryInstallation and add a row for each conversion )
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 13, 2021, 10:06:39 AM
1.) Adding conversion industry tasks similar to with conventional industry between the 3 ( for maybe somewhere around 5-20 cost per factory vs 120 for a new ).

Well this one was surprisingly easy to add through DB edit and appears to work fine when advancing time too...

(https://i.imgur.com/Eatu6k4.png)
( DIM_PlanetaryInstallation and add a row for each conversion )

If it is this trivial to implement I see no reason why this shouldn't be added as long as the costs are appropriately balanced so that there is not too much ability to cheese mineral costs by building + converting.

It may make sense to change the fighter and ordnance factory costs to be 60 duranium + 60 vendarite/tritanium (from 120 of the latter), and the conversion cost between the types can be 30 neutronium/vendarite/tritanium + 30 BP, that seems reasonable.
Title: Re: C# Suggestions
Post by: xenoscepter on December 13, 2021, 11:36:39 PM
 --- Can we add a firing delay for FCS, preferably for both Beam & Missile FCS, but definitely for Missile ones. As well as a stagger option for turrets that's does the same thing.

 ---The logic being that if I want a steady stream of DPS with say a 10-15 second reload... I can mount three and stagger them. Thus I could also knowingly underpower a ship since weapons only begin charging when they fire.

 - Likewise, can we have turrets for missiles? Give them a crew reduction and maybe a reload increase, but at the expense of having to fire all of them at once so they waste some ammo compared to individual tubes. This would make sensor missiles a trade-off for use with these, since they would re-target after impact if they saw anything.
Title: Re: C# Suggestions
Post by: Blogaugis on December 14, 2021, 09:48:20 AM

yes, very easy to do, but you have to give them a cost because they have no material requirements. I did 40/40/40 Deranium/neutronium/Corundium to be "fair".
Facepalms and sighs...
Dude, it's CONVENTIONAL INDUSTRY, meaning - made when TNs were not known!
Why should You add a mineral cost to that!?

Although, let me guess - bugs, right? Or the A.I. going nuts with it and building them in infinite numbers?
Title: Re: C# Suggestions
Post by: alex_brunius on December 14, 2021, 09:52:59 AM
Facepalms and sighs...
Dude, it's CONVENTIONAL INDUSTRY, meaning - made when TNs were not known!
Why should You add a mineral cost to that!?

Although, let me guess - bugs, right? Or the A.I. going nuts with it and building them in infinite numbers?
No... Because if there was no resource cost attached to it you would be able to pay just 20 resources to convert them to full TN Construction Factories worth 120 resources.
Title: Re: C# Suggestions
Post by: Blogaugis on December 14, 2021, 09:59:27 AM

No... Because if there was no resource cost attached to it you would be able to pay just 20 resources to convert them to full TN Construction Factories worth 120 resources.
Ah!
So in order to make it fair, you could make it, that conversion basically costs the same as a full construction factory.

My goal wasn't really fairness though, my goal was to find a way to make some asteroids and planetoids useful for more than just slow accumulation of population and (low gravity) infrastructure...

As for NPRs building them... they won't?
Title: Re: C# Suggestions
Post by: dsedrez on December 14, 2021, 02:40:21 PM

No... Because if there was no resource cost attached to it you would be able to pay just 20 resources to convert them to full TN Construction Factories worth 120 resources.
Ah!
So in order to make it fair, you could make it, that conversion basically costs the same as a full construction factory.

My goal wasn't really fairness though, my goal was to find a way to make some asteroids and planetoids useful for more than just slow accumulation of population and (low gravity) infrastructure...

As for NPRs building them... they won't?

I enabled building CI's in my latest game, with a rule that every colony with more than 10m *must* have at least one per 1m pop (currently to a max of 2 per million), can't build in excess beyond pop growth, and can only convert into other things in case, say, you're under attack. And must be rebuilt asap once the threat is over - though I'm not there yet to see how that would work out.

But I put a cost of only 40 BP/wealth, considering I want them built everywhere without minerals. I first tried a cost of 200 but then they never managed to follow pop growth or were too much a detriment for normal development. Since CIs are way less than 50% as productive as TN facilities, this cost seems adequate as long as it's not abused, giving them a 2.5% growth rate for basic tech (if all they do is build new ones). It made things interesting with every little colony having something to do. But I'm playing with very low tech: if you play higher tech and want CIs to be interesting, maybe you should either increase their cost or reduce their factory value (default is 10% of a TN factory).

I even gave them a very small maintenance stat so they could help maintain a small scout or fighter parked over them. It makes sense that even a non-military colony could do that on a small scale, and it enriches the story to use them as pit-stops for my patrol ships. Though I'm always turning off MSP production (and fuel as well) since most places will never have use for these (or don't have the minerals) and I'd rather fire off the minerals somewhere else for better use. So they don't make proper fleet bases.

And no, I didn't observe NPRs trying to build them. Probably because they're not programmed to do so. Though I've only seen a single NPR so far, and the war was too brief and bloody to even consider converting CIs to anything else.



Title: Re: C# Suggestions
Post by: Barkhorn on December 14, 2021, 04:00:11 PM
Suggestion: Allow industry to help with fortification.  In VB6 (and maybe still in C#?) construction brigades can be used as factories.  Why not the inverse as well?

This would make sense from a removing-special-rules perspective, and from a historical perspective as well; many fortifications were built with civilian or forced labor.  The Atlantic Wall, for example, in WW2 was built by slave labor.
Title: Re: C# Suggestions
Post by: Migi on December 14, 2021, 09:08:37 PM
Suggestion: Allow industry to help with fortification.  In VB6 (and maybe still in C#?) construction brigades can be used as factories.  Why not the inverse as well?

This would make sense from a removing-special-rules perspective, and from a historical perspective as well; many fortifications were built with civilian or forced labor.  The Atlantic Wall, for example, in WW2 was built by slave labor.

In C# construction brigades can be used as factories, but I think they need to finish fortifying everything first.
I think the suggestion makes sense, but for balance reasons it should appear as an option in the construction menu rather than happening automatically.
Title: Re: C# Suggestions
Post by: nakorkren on December 15, 2021, 09:24:37 PM
Rather than have training occur when you put a fleet under a Training Admin Command, make training a Movement Order similar to how overhaul works. That way you could set a duration for the training, with other orders like refuel/resupply/wait to burn down deployment/actually overhaul since you've used up maintenance life, then set it on Cycle Orders and voila! you've solved the training micromanagement problem.

You could still of course put the fleet in a Training Command, which would be led by someone with high Crew Training, to get that bonus.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 15, 2021, 11:28:22 PM
Rather than have training occur when you put a fleet under a Training Admin Command, make training a Movement Order similar to how overhaul works. That way you could set a duration for the training, with other orders like refuel/resupply/wait to burn down deployment/actually overhaul since you've used up maintenance life, then set it on Cycle Orders and voila! you've solved the training micromanagement problem.

You could still of course put the fleet in a Training Command, which would be led by someone with high Crew Training, to get that bonus.

This is a great idea. Personally, I would rather get rid of the Training Command entirely and just use a Naval Command with a high-training officer. Fleet Training frankly happens rather fast currently so reducing the effect of the command bonus is not a big problem in my opinion, particularly since the effect of fleet training is so strong as to be almost game-breaking - in my campaigns now I usually avoid doing fleet training because of how it trivializes Reaction and order delay mechanics.

As a benefit to doing Training under a Naval Command, the Engineering skill can matter for limiting breakdowns and MSP consumption during training.
Title: Re: C# Suggestions
Post by: Garfunkel on December 17, 2021, 10:27:18 PM
Just a reminder that, if possible, ground formations should consume supply units even after combat so that their supply goes back to 100% as it's not obvious to new players that everything is fine if they have supply units available even though the percentage is at 0% plus this would make it easier to resume new invasions afterwards because the formations again carry their own internal supply.
Title: Re: C# Suggestions
Post by: Zook on December 21, 2021, 12:04:07 AM
I'm almost sure it's been suggested before, but anyway:

In the combat menu, allow dragging a missile onto a fire control and thereby assign it to all launchers under that control.
(Or is there a faster way already and I haven't gotten the memo?)
Title: Re: C# Suggestions
Post by: Zook on December 21, 2021, 02:40:43 AM
What about auto-ceasefire for ships landing on a carrier? I just launched a squadron that fired immediately after leaving the hangar bay, because you don't get an auto-5-second-interrupt if the ship has Open Fire orders but no more ammo, and I forgot to order cease fire.

edit: Actually I think it went like this: I unassigned half the box launchers on each fighter, fired the other half, then assigned them all back and fired the first half, then clicked Cease Fire and flew back to the carrier. They took on the few reloads available and detached from the carrier again. At that point the fighters should have had a Cease Fire order (or I would have had to return to the carrier in 5-second increments), but instead they fired immediately.
Title: Re: C# Suggestions
Post by: trabber Shir on December 21, 2021, 02:55:31 AM
I would like to echo something several pages back. A standing order to get your freighters to fulfill your contracts similar to what has been done on Quazar would be an incredibly valuable quality of life upgrade.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 21, 2021, 10:32:18 AM
I'm almost sure it's been suggested before, but anyway:

In the combat menu, allow dragging a missile onto a fire control and thereby assign it to all launchers under that control.
(Or is there a faster way already and I haven't gotten the memo?)

Doesn't this already work in exactly this way? I'm fairly certain I just did this last night...

What about auto-ceasefire for ships landing on a carrier? I just launched a squadron that fired immediately after leaving the hangar bay, because you don't get an auto-5-second-interrupt if the ship has Open Fire orders but no more ammo, and I forgot to order cease fire.

Pretty sure you can use Cease Fire Fleet in the combat tab to do this with one click, although this would be a nice QoL addition anyways.
Title: Re: C# Suggestions
Post by: Droll on December 21, 2021, 11:29:02 AM
I'm almost sure it's been suggested before, but anyway:

In the combat menu, allow dragging a missile onto a fire control and thereby assign it to all launchers under that control.
(Or is there a faster way already and I haven't gotten the memo?)

Doesn't this already work in exactly this way? I'm fairly certain I just did this last night...

I think it depends on the "assign all" checkbox, or is that only for target assignment?
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 21, 2021, 11:38:31 AM
I think it depends on the "assign all" checkbox, or is that only for target assignment?

I think the latter, it definitely doesn't work for PD mode assignment, which gets annoying when I want to turn my AMM cruisers on/off to manage ammo...

We really need a checkbox for "Assign All of Type" - which works with PD assignment and missile loading while we're at it.
Title: Re: C# Suggestions
Post by: nakorkren on December 22, 2021, 11:54:00 AM
It would be great to have a "Send demand to surrender" command to have one fleet send to another, with the likelihood of the enemy surrendering being based on relative strength of the two fleets, any other fleets in the area which could intervene in a reasonable timeframe, damage of the ship being asked to surrender, and xenophobia + militancy.

I thought of this because I often use carriers carrying 1kton fast boarding shuttles with marines on them, which is really enjoyable from an RP perspective but a total micromanagement pain in the behind due to all the loading and unloading of individual units onto and back off of individual enemy ships. E.g. right now I'm in the process of capturing 45 commercial ships, with a giant fleet on my side and no enemy military ships in sight, but there's no way to demand the enemy surrender or be boarded/blown up, as would be totally logical/reasonable.

Alternately, an option to "Attempt boarding with all formations, and pick up the formations afterward if successful" would be just as helpful and probably less open to abuse.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 22, 2021, 12:30:21 PM
It would be great to have a "Send demand to surrender" command to have one fleet send to another, with the likelihood of the enemy surrendering being based on relative strength of the two fleets, any other fleets in the area which could intervene in a reasonable timeframe, damage of the ship being asked to surrender, and xenophobia + militancy.

Supported. In practice, what "works" presently is to fire a round of low-damage shots (10cm railgun or Gauss turret usually works), which may induce the enemy ships to surrender. However it is annoying to micromanage this extra step especially having to open fire and cease fire after the first round of shots since surrender happens on the following increment (as I've discovered only after blowing up surrendering ships more than once...). It would be nice to just broadcast a surrender demand to the remnants of the enemy fleet, and if they choose death I can just give it to them in one swift blow instead of playing the poke-with-railguns game to see who feels lucky today.
Title: Re: C# Suggestions
Post by: Sebmono on December 22, 2021, 03:19:35 PM
I think it depends on the "assign all" checkbox, or is that only for target assignment?

I think the latter, it definitely doesn't work for PD mode assignment, which gets annoying when I want to turn my AMM cruisers on/off to manage ammo...

We really need a checkbox for "Assign All of Type" - which works with PD assignment and missile loading while we're at it.

This reminds me of one thing I'd love to see which I keep forgetting to drop here - add fire control and missile assignment as a template to the ship design screen, similar to the ordnance template. In 99% of situations I will want all builds of a given class to have the same FC assignments and I invariably forget to do the assign all step at some point, especially with fighters, so just stating at the ship design level how I want FCs to be assigned would be an amazing QoL addition.
Title: Re: C# Suggestions
Post by: Droll on December 22, 2021, 07:53:47 PM
I think it depends on the "assign all" checkbox, or is that only for target assignment?

I think the latter, it definitely doesn't work for PD mode assignment, which gets annoying when I want to turn my AMM cruisers on/off to manage ammo...

We really need a checkbox for "Assign All of Type" - which works with PD assignment and missile loading while we're at it.

This reminds me of one thing I'd love to see which I keep forgetting to drop here - add fire control and missile assignment as a template to the ship design screen, similar to the ordnance template. In 99% of situations I will want all builds of a given class to have the same FC assignments and I invariably forget to do the assign all step at some point, especially with fighters, so just stating at the ship design level how I want FCs to be assigned would be an amazing QoL addition.

Yeah even a simple "default" template would work, though for missile ships the ideal might be to have the ability to make multiple templates that you can swap to depending on what missiles you want to be firing.
Title: Re: C# Suggestions
Post by: Sebmono on December 23, 2021, 09:41:16 AM
Yeah even a simple "default" template would work, though for missile ships the ideal might be to have the ability to make multiple templates that you can swap to depending on what missiles you want to be firing.
A default is all I was thinking of as a first cut, to keep things simple. Setting FC assignments does feel like something I'd expect to do as part of the design process.
Title: Re: C# Suggestions
Post by: nakorkren on December 23, 2021, 09:01:44 PM
2nd'ed (or 4th'ed, or what ever) on making a default FC/weapon template as part of the design phase.

Another suggestion regarding boarding/troop loading: Make fleets with multiple ships capable of loading troops execute troop loading/unloading manuevers in parallel, or alternately make the per-unit load time depend on how many units are queued to load and how many ships are able to load. Would probably be easiest/best to implement this just like the option to "Unload all", by giving a "Load ALL Ground Units from Stationary Fleet" option. That said, I don't know whether the current "Unload all" option reflects having multiple ships in a fleet unloading simultaneously unloading.

The reason I bring this up is that right now if you have multiple ships capable of loading troops within the same fleet, and you're loading one (or some) units onto each ship, there's no way to take advantage of that fact to speed up loading. I.e. I have two ground units, and two shuttles, but if the shuttles are in the same fleet, that fleet has to set up two "Load Ground Unit from Stationary Fleet" orders, which will be processed serially. If you split the two ships apart into two fleets, each can execute a single loading action, and hence finish in half the time. Not a big deal with two units/two ships, but when you're talking a reasonable number of boarding shuttles to be effective during combat, and it becomes a BIG time-suck to split the fleet apart, and if you don't, you get a hugely longer loading time. In my specific situation, I have 16 units, one on each of 16 boarding shuttles. So if I split my fleet into 16 fleets, I can load all troops in an hour. If I don't, it takes 16 hours.
Title: Re: C# Suggestions
Post by: nakorkren on December 23, 2021, 09:56:55 PM
Another suggestion: On the fleet Movement Orders tab, make the orders able to be moved up or down the queue of orders, similar to research/industry.

I suspect this isn't as easy as it seems, since the orders available depend on what orders precede it, but within a system it would be really helpful. An example use case is you're following a fleet at a fixed range while hammering it with weapons. As their ships blow up, you want to collect the life pods, so right now each time you have to clear the current "follow" order, order pickup of the lifepod, then reorder the follow at a fixed distance.
Title: Re: C# Suggestions
Post by: Garfunkel on December 24, 2021, 09:50:43 AM
Another suggestion: On the fleet Movement Orders tab, make the orders able to be moved up or down the queue of orders, similar to research/industry.

I suspect this isn't as easy as it seems, since the orders available depend on what orders precede it, but within a system it would be really helpful. An example use case is you're following a fleet at a fixed range while hammering it with weapons. As their ships blow up, you want to collect the life pods, so right now each time you have to clear the current "follow" order, order pickup of the lifepod, then reorder the follow at a fixed distance.
This has been suggested before but Steve always shoots it down because it is really easy to introduce logic errors that will break the orders and/or the game.

For your case, either collect the lifepods after the battle - they will survive long enough - or detach a ship with that as a special task.
Title: Re: C# Suggestions
Post by: Kristover on December 26, 2021, 10:18:12 AM
Suggestion:  The Addition of 'Air Forces'

I have thought about it a bit and the current implementation of Ground Support Fighters is a noble attempts to add something cool and interesting to the game - truly, I love the attempt at the feature. But right now is only partially implemented and so unwieldy that I doesn't seem many players use it.  But it leaves an obvious gap in the ground combat game of no 'air-breathing' air support/combat which almost would surely be there.

My proposed solution is to introduce specialized air units to the ground construction module.  They would use the existing vehicle base size types with a check box that would indicate if this is an air unit or not.  The characteristics of the air units would be as such:

1. Air Units cost double the vehicle base size type selected.

2. Air Units use double the supply that an equivalent unit would use.  This couple with #1 means that it is expensive to maintain air forces.

3. Air Units don't contribute any occupation value to a colony - you can't use only air forces to occupy a planet. 

4. Air Units can use any weapon type that a ground vehicle unit can.

5. Air Units can only be attacked by ground air defense weapons or weapons mounted on another air unit - this simulates air to air combat.

6. Air Units can support or target ground units in a fashion similar to artillery/bombardment units. 

7.  FFD components in forward units can supply bonuses to Air Units in a similar fashion to artillery/bombardment units.

8.  Air Units cannot be assigned 'capabilities' like Jungle Fighting/Desert Fighting etc. This is not to make them overpowered.

This is kind of a baseline solution which can be discussed for refinement purposes.  As for the existing ground support fighters, I would argue rather than eliminating them repurpose them into orbital/sub-orbital support.  They will occupy a niche where they can be extremely useful if space/orbital control is uncontested - you will still want them for a well rounded invasion force - but they are still hideously vulnerable to enemy air defenses and if space control is contested.

In the end I think this is a good starting point for air units - they are powerful and if the enemy doesn't have air units or robust ground air defense capabilities, they will utterly dominate so you can't afford the ignore them.  Also they are expensive to build and expensive to maintain so you can't overbuild them - and if you don't have sufficient supply, they quickly become useless.
Title: Re: C# Suggestions
Post by: Kristover on December 26, 2021, 10:31:23 AM
Suggestion:  Additional of 'Ministers'

One problem I have in games is that I always wind up with a massive surplus of governors/civilian administrators.  I think it would be interesting if we could add in a second layer of administration to each colony and sector governor with the following positions:

Finance Minister:  Utilizes Wealth Creation or Logistics

Defense Minister:  Shipbuilding or Ground Unit Construction Speed

Industry Minister: Production or Mining

Science Minister: Terraforming and/or Population Control

A governor still remain the most important administrator to have on a colony because he contributes his full value but these other ministers contribute a fraction (25-50% sounds about right) of their bonus to the colony/sector and can be powerful multipliers.  They also have the ability to grow their skills - but JUST the skill for the ministry they hold - so that when existing governors die/retire you have qualified and experiences ministers ready to take over.



Title: Re: C# Suggestions
Post by: papent on December 26, 2021, 12:18:26 PM
Piggyback off of the last suggestion,

Suggestion: System governors
an additional admin level between colony and sectors, provides part of their bonuses to all colonies in their planetary system.
Title: Re: C# Suggestions
Post by: Sebmono on December 26, 2021, 12:51:24 PM
A couple ground forces related suggestions that have been on my mind:
Title: Re: C# Suggestions
Post by: nakorkren on December 26, 2021, 10:37:12 PM
Back to everyone's favorite punching bag... ground combat.

I thought perhaps Heavy Bombard units could ignore (or partly ignore) fortification, with the intent that it would make them particularly useful when assaulting homeworlds which tend to be fully fortified. The game rationale is now you have a reason to bring Heavy Bombard units, the "real-life" rationale is that heavy artillery is one of the main ways you deal with enemy's fortifications.

As a corollary, we could then have fighters ignore (or partly ignore) evasion, making them more effective against vehicles on the attack. This would give defenders some buff to counteract the benefit to attackers of artillery, and again provide a reason to bring them to a fight, and would DEFINITELY jive with real life. Doesn't matter much how fast a ground unit is going, because relative to an aircraft with missiles (or even guns), you're still pretty dang slow.
Title: Re: C# Suggestions
Post by: nakorkren on December 26, 2021, 10:38:20 PM
QoL request... could we get a filter for the Commanders window to only show commanders who are unassigned?
Title: Re: C# Suggestions
Post by: nakorkren on December 26, 2021, 10:41:57 PM
Would it be possible for the events to NOT have a pre-defined "Word Wrap" length, and instead let it be defined by window size? On the main window I often have events that take up two lines because it wraps the last few words around to a new line even though my window is big enough to show the whole thing on a single line.

On a related note, it would be great if when the Event window maximizes to fullscreen, the text display area also got bigger, with the same result requested above that text would wrap based on the real size available. This just makes it so much easier to read Events when you're in a big battle and dozens of ships are reporting.
Title: Re: C# Suggestions
Post by: nuclearslurpee on December 27, 2021, 01:10:14 AM
Suggestion:  The Addition of 'Air Forces'

Something very similar has been proposed in several forms in this very thread... rummages around... starting from this comment. (http://aurora2.pentarch.org/index.php?topic=10640.msg157552#msg157552)

I link this as the discussion went for several pages and was heated at times, so hopefully we can avoid talking in circles by repeating it and in the process keep blood pressures low for the holiday season.  :)

A couple ground forces related suggestions that have been on my mind:Ground Force Admin Commands - just like we have now for Naval Admin Commands, will give things to do for higher level ranks and also allow flexible organizing of units into larger groups(like Armies or Corps) for RP and tracking purposes, without having to build incredibly costly and enormous HQs.

I'd honestly prefer this to the current system. Once you get to the highest HQ hierarchy levels the leadership should really be administrative, not based on field formations. I tend to feel like I build a 2-4 layer formation hierarchy, depending on tech level and doctrine, and then have to build repeated formations of the HQabignumbermillion + 15,285 LVH-LOG for every higher level to give my high-ranking generals a job. The current system also sucks because HQ cost scales infinitely so you have to spend several tank divisions' worth of BP for a high-level HQ to say nothing of the research costs especially for conventional/low-tech games.

Quote
Named GF Construction Factories - just like we have now for shipyards, primarily for RP purposes.

As far as the GFCFs go, I'd rather have them reworked to function like every other planetary factory in the game, i.e., building ground units with a percentage of capacity rather than one formation per facility.

Back to everyone's favorite punching bag... ground combat.

I thought perhaps Heavy Bombard units could ignore (or partly ignore) fortification, with the intent that it would make them particularly useful when assaulting homeworlds which tend to be fully fortified. The game rationale is now you have a reason to bring Heavy Bombard units, the "real-life" rationale is that heavy artillery is one of the main ways you deal with enemy's fortifications.

A few issues with this: first, it would require adding an exception to the ground combat rules, and Steve has generally trended towards eliminating exceptions to the rules in the VB6 --> C# transition; second, this assumes a specific RP for the HB component which is not necessarily reflective of how all players use it (in a WH40K setting for example, siege mortars are actually relatively short-ranged compared to field artillery - not realistic, but there you go for a popular example); third, it doesn't solve the main reason players avoid using HB which is the massive collateral damage that results compared to using lighter artillery (indeed, for some players even MB/MBL is too damaging), and v2.0 purports to solve this with an 80% reduction of collateral damage so we will have to see if that works well enough.

Also, IMO HB works fine mechanically, the main problem is that it is overkill against NPRs which use very limited ground forces templates. In a multiple-player-race setting where the player races actually use HVH and heavier classes the 6 base damage of HB (and, in v2.0 the 9 base damage of SHB) become useful against armor-heavy forces and thus is (are) a good defensive option at the very least.

Quote
As a corollary, we could then have fighters ignore (or partly ignore) evasion, making them more effective against vehicles on the attack. This would give defenders some buff to counteract the benefit to attackers of artillery, and again provide a reason to bring them to a fight, and would DEFINITELY jive with real life. Doesn't matter much how fast a ground unit is going, because relative to an aircraft with missiles (or even guns), you're still pretty dang slow.

This is sensible but would have very little impact. Usually evasion is only relevant for attacking formations and usually it is the attacker in a planetary battle who has fighter support, if anyone. Although if we took the above suggestion for make GSFs a ground unit class then defending forces would actually be able to use (aero) fighters practically - another argument in favor which I don't think came up in the last discussion (@Steve plz!).
Title: Re: C# Suggestions
Post by: Migi on December 27, 2021, 04:45:41 PM
QoL request... could we get a filter for the Commanders window to only show commanders who are unassigned?
I want this so much.
Title: Re: C# Suggestions
Post by: ArcWolf on December 27, 2021, 08:56:08 PM
Suggestion:  Additional of 'Ministers'

One problem I have in games is that I always wind up with a massive surplus of governors/civilian administrators.  I think it would be interesting if we could add in a second layer of administration to each colony and sector governor with the following positions:

Finance Minister:  Utilizes Wealth Creation or Logistics

Defense Minister:  Shipbuilding or Ground Unit Construction Speed

Industry Minister: Production or Mining

Science Minister: Terraforming and/or Population Control

A governor still remain the most important administrator to have on a colony because he contributes his full value but these other ministers contribute a fraction (25-50% sounds about right) of their bonus to the colony/sector and can be powerful multipliers.  They also have the ability to grow their skills - but JUST the skill for the ministry they hold - so that when existing governors die/retire you have qualified and experiences ministers ready to take over.

I was thinking about this the other day, and you pretty much beat me to it. One addition i would make is have a "Leader" for your entire empire also. They would apply a bonus, like colonial governor & sector command, but for everything. To use the USAs political structure to help illustrate. Leader = President, Sector Command = State Governor, and Colonial Governor = Mayors.

This could also be combined with a "bureaucratic/administrative officer" building, like sector/fleet commands, that have 5 levels (i.e. 5 max can be built on a body). Each "level" would have a population requirement (if possible, else, employ a large number of pops), 0 pops for lvl 1, 10 mil for lvl 2, 50 mil for lvl 3... or something along those lines. Each "level" would give part of the Leaders & Ministers bonus to the colony ( in 20% increments).

An example would be Earth has a lvl 5 Admin, and therefor gets the full 100% from Leader & ministers, but your new Mars colony is only lvl 2, and only gets 40% of their bonus.
Title: Re: C# Suggestions
Post by: Bluebreaker on December 27, 2021, 09:09:07 PM
QoL
I think it would be usefull to have buttons to display only colonies with Construction factories / Shipyards / Research Labs
Title: Re: C# Suggestions
Post by: Voltbot on January 01, 2022, 04:00:36 PM
I think adding some kind of airport would be nice.

As far as I understand planetary invasions (I might be wrong), you would attack after you destroyed enemy defence fleet.  That leaves defenders without any ability of using fighters in ground combat (because they probably won't have any carriers nearby).
In VB you had PDC.  Despite the fact, that fighters weren't able to support ground forces, you had possibility to launch them from a planet.  My idea is the installation, that would be able to hold some fighter tonnage (for example 5000 tons per level/installation), perhaps giving researchable tonnage per level/installation increase, and allow to launch them.  At the time, when fighters are on ground, the might not even be using MSP and won't be using maintenance facilities, because of that.

If someone suggested that earlier: I'm sorry.  I'm simply too lazy to check for it in over 158 pages of posts.

I probably made a lot of grammar mistakes, so sorry for any of these.
Title: Re: C# Suggestions
Post by: alex_brunius on January 01, 2022, 05:16:58 PM
  At the time, when fighters are on ground, the might not even be using MSP and won't be using maintenance facilities, because of that.

Are you sure about that? When I tested recently fighters seemed to worked just fine using normal maintenance facilities…
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 01, 2022, 08:33:18 PM
  At the time, when fighters are on ground, the might not even be using MSP and won't be using maintenance facilities, because of that.

Are you sure about that? When I tested recently fighters seemed to worked just fine using normal maintenance facilities…

Currently fighters work like normal ships when not in a hangar, so they require maint facilities and consume MSP like every other military ship. I think the suggestion would imply that fighters in a hangar would not use MSP at all, which would be more like VB6 but I think a rather poor idea for C# given the design goal of unifying the mechanics instead of adding exceptions.

I don't particularly like the idea of planetside hangars, as it doesn't add anything mechanically (removing MSP consumption would take away something mechanically, if anything) and doesn't really solve the problem as any defensive fighters will just be blown up by an attacking fleet when they do leave the hangars, wither GSFs or space fighters. I would rather see a more elegant solution to the GSF problem such as making GSFs into a ground unit class and unifying those mechanics.
Title: Re: C# Suggestions
Post by: GodEmperor on January 05, 2022, 06:20:09 PM
I have no idea if anyone suggested that but having "loadouts" profiles for ammo/fighters could be cool.

At this time you have to change the missiles loadouts in design screen and then you have every ship of this class change it - having an option to customize it on at least individual fleet basis would be cool.
Some of the X Class destroyers could benefit from loading the faster more agile but weaker missiles to deal with Y NPR spamming fighters and FAC's while the X class destroyers on other end of your Empire would still load the usual bigger heavy hitting missiles because Z NPR running around their backyard is using capital ships.
Same with fighters.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 05, 2022, 07:01:17 PM
You can actually do this to a degree already. When viewing a single ship in the Naval Organization window, you have the option to set a ship-specific loadout on the ordnance tab, which IIRC can be copied to other ships of that class in a fleet as well. It is not quite having multiple profiles that can be swapped around but it is something useful.
Title: Re: C# Suggestions
Post by: GodEmperor on January 06, 2022, 05:25:54 AM
You can actually do this to a degree already. When viewing a single ship in the Naval Organization window, you have the option to set a ship-specific loadout on the ordnance tab, which IIRC can be copied to other ships of that class in a fleet as well. It is not quite having multiple profiles that can be swapped around but it is something useful.
Really? Never noticed that, i guess i have to check it out.
Still - proper loadouts would be cool thing to have.
Title: Re: C# Suggestions
Post by: Kiero on January 06, 2022, 03:09:21 PM
Since in 2.0 there will be an option to retain dead or retired commanders. It would be cool to have an option medal setup that would automatically change DNR status.

That way if someone did something significant he/she will be retained automatically.
Title: Re: C# Suggestions
Post by: Warer on January 08, 2022, 05:52:45 PM
Additional Internal HTK to Ships/Stations Component ie Bulkheads/Structural Reinforcement

A component to help make more durable ships without having to add armor/shields, the trade-off being since their internal components they don`t block damage to vital components merely give the enemy nonvitals to shoot.
Title: Re: C# Suggestions
Post by: ArcWolf on January 08, 2022, 06:39:00 PM
Additional Internal HTK to Ships/Stations Component ie Bulkheads/Structural Reinforcement

A component to help make more durable ships without having to add armor/shields, the trade-off being since their internal components they don`t block damage to vital components merely give the enemy nonvitals to shoot.

would be nice, though you can already do something like this by making miscellaneous components. an actual bulkhead component could be more space efficient then a miscellaneous component but also more expensive in duranium.
Title: Re: C# Suggestions
Post by: Froggiest1982 on January 11, 2022, 03:48:54 AM
Introduce the option to remove Orbits also to Stars, not only Planes, Moons, and Asteroids.

Reasons here: http://aurora2.pentarch.org/index.php?topic=12886.msg158058#msg158058
Title: Re: C# Suggestions
Post by: Garfunkel on January 11, 2022, 03:53:53 AM
Introduce the option to remove Orbits also to Stars, not only Planes, Moons, and Asteroids.

Reasons here: http://aurora2.pentarch.org/index.php?topic=12886.msg158058#msg158058
And before anyone misunderstands, Froggiest means orbits of stellar companions as the main star of course never has an orbit.
Title: Re: C# Suggestions
Post by: Bluebreaker on January 13, 2022, 12:49:32 PM
I think it would be useful to have class prefix of the ships clases on the Shipyards panel when Retoling Shipyard and all the shipyard tasks (Construction, Refit, Repair, Scrap, Autorefit)
Currently these only show the class name without the prefix, while assigned class does show the prefix.

(https://i.postimg.cc/Mv46vVMY/shipyards.png) (https://postimg.cc/Mv46vVMY)
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 13, 2022, 01:13:22 PM
I think it would be useful to have class prefix of the ships clases on the Shipyards panel when Retoling Shipyard and all the shipyard tasks (Construction, Refit, Repair, Scrap, Autorefit)
Currently these only show the class name without the prefix, while assigned class does show the prefix.

From the 2.0 changes list (http://aurora2.pentarch.org/index.php?topic=12523.0):
Quote
Hull abbreviation for classes and ships shown in construction options on Shipyard and Industry tabs of Economics window.
Title: Re: C# Suggestions
Post by: xenoscepter on January 13, 2022, 07:17:45 PM
  At the time, when fighters are on ground, the might not even be using MSP and won't be using maintenance facilities, because of that.

Are you sure about that? When I tested recently fighters seemed to worked just fine using normal maintenance facilities…

Currently fighters work like normal ships when not in a hangar, so they require maint facilities and consume MSP like every other military ship. I think the suggestion would imply that fighters in a hangar would not use MSP at all, which would be more like VB6 but I think a rather poor idea for C# given the design goal of unifying the mechanics instead of adding exceptions.

I don't particularly like the idea of planetside hangars, as it doesn't add anything mechanically (removing MSP consumption would take away something mechanically, if anything) and doesn't really solve the problem as any defensive fighters will just be blown up by an attacking fleet when they do leave the hangars, wither GSFs or space fighters. I would rather see a more elegant solution to the GSF problem such as making GSFs into a ground unit class and unifying those mechanics.

 --- I'd like to see a planetside hangar personally, but not for defense of the planet it's on, so much as defense of the system it's in. As for fighters in it not using MSP, I think that's fine so long as the facilities themselves at least do. At any rate, the reason I want them for this and not "just use hangars lol" is that they wouldn't show up on sensors if planetside, so you could scatter these around a few planetoids / asteroids with a DSTS or two and have an effective anti-piracy network that can also respond to light attacks. Mechanically I see no reason these couldn't be reworked to allow missile bases as well, creating yet another way to protect a system and making invasion potentially that much more dangerous after the initial jump assault.
Title: Re: C# Suggestions
Post by: nakorkren on January 13, 2022, 09:38:07 PM
Would it be possible to let the user specify how frequently to send mass driver packets, rather than have it hardcoded to occur at each production tick (as I believe it currently works)? It's not really an issue at 5day production ticks, but if you play with shorter ones, you end up with a lot of mineral packages floating around that I suspect may impact performance. If I'm wrong and the number of mineral packets doesn't really matter for performance, feel free to ignore this suggestion.

I play with 1 day production ticks, which means 5x as many mineral packets as there would otherwise be.
Title: Re: C# Suggestions
Post by: nakorkren on January 13, 2022, 09:44:19 PM
Not sure if this is a bug or just a suggestion, but when you have a research bonus due to an Ancient Construct, it is reflected on your current research projects, but not on projects in your research queue, even though once those projects transition to being active projects, they do indeed correctly get the bonus applied. It would be helpful if the completion time in years was accurately calculated using the bonus for items in the research queue.
Title: Re: C# Suggestions
Post by: Platys51 on January 14, 2022, 02:49:18 PM
Suggestion to make Plasma little more versatile: Reduced size/reduced range tech line. Maybe with 4 techs from 0.9 to 0.5. This change would allow realistically deploying fighters and maybe high caliber small ships that could provide shock damage before withdrawing or gave large battleships ability for secondary high DMG burst weapons to deploy point-blank once or twice per fight.
Title: Re: C# Suggestions
Post by: Kristover on January 14, 2022, 05:19:44 PM
Been playing a bit of Quasar while waiting for 2.0 and it is excellent piece of work.  One quality of life feature the developer put in there is a button that restricts whether a particular colony can refuel or not.  I think this would be a great idea for C#.  I make a lot of use of conditional orders and I hate when an exploration ship with a large fuel tank conditionally returns to the nearest spaceport/hub which has a tiny bit of fuel there for a fighter squadron and drains all the fuel from it when what I really wanted for them to do was to return to my larger central hub with loads of fuel.  I would propose a toggle switch on each colony that toggles whether they can be a fuel source or not. 
Title: Re: C# Suggestions
Post by: nakorkren on January 15, 2022, 12:56:08 PM
If/when there is a diplomacy update, I would love to see the ability to negotiate conditions for sharing a system. E.g.:

"Let's agree to share this system because we're on good terms, but we won't let anyone else settle here" i.e. claims that do not exclude Friendly aliens
"Let's agree to share access to this system's resources, but no military ships or units allowed" or
"This system will be a buffer between us; no military or civilian use at all by either side" or
"This system can be used as a route to and from other places, but no one is allowed to have a presence in the system for more than 5% of the year"
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 15, 2022, 11:16:30 PM
If/when there is a diplomacy update, I would love to see the ability to negotiate conditions for sharing a system. E.g.:

"Let's agree to share this system because we're on good terms, but we won't let anyone else settle here" i.e. claims that do not exclude Friendly aliens
"Let's agree to share access to this system's resources, but no military ships or units allowed" or
"This system will be a buffer between us; no military or civilian use at all by either side" or
"This system can be used as a route to and from other places, but no one is allowed to have a presence in the system for more than 5% of the year"

"Look, mate: your home system is through this jump point, our home system is through that jump point, neither of us wants next door neighbors, so let's just be cool, yeah?"

The NPRs really, really, really need some concept of a buffer system if the diplomacy mechanics are going to be functional for any kind of realistic RP setting.
Title: Re: C# Suggestions
Post by: Droll on January 16, 2022, 12:21:01 PM
If/when there is a diplomacy update, I would love to see the ability to negotiate conditions for sharing a system. E.g.:

"Let's agree to share this system because we're on good terms, but we won't let anyone else settle here" i.e. claims that do not exclude Friendly aliens
"Let's agree to share access to this system's resources, but no military ships or units allowed" or
"This system will be a buffer between us; no military or civilian use at all by either side" or
"This system can be used as a route to and from other places, but no one is allowed to have a presence in the system for more than 5% of the year"

"Look, mate: your home system is through this jump point, our home system is through that jump point, neither of us wants next door neighbors, so let's just be cool, yeah?"

The NPRs really, really, really need some concept of a buffer system if the diplomacy mechanics are going to be functional for any kind of realistic RP setting.

How would the buffer work though, would you be allowed to sensor buoy the JPs without too much fuss?
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 16, 2022, 12:25:50 PM
How would the buffer work though, would you be allowed to sensor buoy the JPs without too much fuss?

I think probably the easiest thing to do would be to allow diplo ships (up to 11,000 tons as currently) and civilian shipping traffic if applicable, i.e., if a trade agreement is in place. Basically it would function like a claimed system except that both sides "recognize the claim" of the other and agree not to colonize, militarize, etc. (which the NPR wouldn't do unless Steve added a chance to be duplicitous, and the player could choose to violate and risk consequences if desired, as usual).
Title: Re: C# Suggestions
Post by: TMaekler on January 18, 2022, 05:27:21 AM
Dynamic Range for Missiles:
I was wondering if it would be possible to add a factor for the flight range calculations of missiles. Something like the factor for research. The idea behind this is to create games which have a more shorter range for missiles like in the Battlestar or Star Wars Universe.
Title: Re: C# Suggestions
Post by: nakorkren on January 20, 2022, 09:18:08 PM
Would it be possible to have demand and supply under the Civilian Economy tab set for the different mineral types, such that civilian freighters would move your minerals around?
Title: Re: C# Suggestions
Post by: ArcWolf on January 21, 2022, 12:32:42 PM
Dynamic Range for Missiles:
I was wondering if it would be possible to add a factor for the flight range calculations of missiles. Something like the factor for research. The idea behind this is to create games which have a more shorter range for missiles like in the Battlestar or Star Wars Universe.

Can you elaborate? I do not see the point. If you want shorter ranged missiles, make shorter ranged missiles.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 21, 2022, 12:36:52 PM
Can you elaborate? I do not see the point. If you want shorter ranged missiles, make shorter ranged missiles.

I think the idea is to have a global multiplier which also affects the other races, mainly NPRs. Personally I would not use this as it would cause balance issues with AMM and sensor ranges to just have a flat multiplier but for some the RP setting is more valuable than balanced mechanics and I would not argue with them.
Title: Re: C# Suggestions
Post by: Noble713 on January 22, 2022, 03:21:03 AM
Small QoL request:

Truncate the days and months displayed in all of the subwindows (primarily Fleet, Ship, Research, and Industry screens). Reduce days to 2-3 letters and months to 3 letters, such as:

Thursday, December 20, 2085 ---> (Th/Thu), Dec 20, 2085

I can almost never see the day and year when something is supposed to finish as the column for dates is never wide enough. I'm at 1920x1080 so it shouldn't be a display resolution issue either...
Title: Re: C# Suggestions
Post by: Steve Walmsley on January 22, 2022, 07:32:41 AM
Not sure if this is a bug or just a suggestion, but when you have a research bonus due to an Ancient Construct, it is reflected on your current research projects, but not on projects in your research queue, even though once those projects transition to being active projects, they do indeed correctly get the bonus applied. It would be helpful if the completion time in years was accurately calculated using the bonus for items in the research queue.

Changed for v2.0.
Title: Re: C# Suggestions
Post by: Steve Walmsley on January 22, 2022, 07:54:31 AM
Been playing a bit of Quasar while waiting for 2.0 and it is excellent piece of work.  One quality of life feature the developer put in there is a button that restricts whether a particular colony can refuel or not.  I think this would be a great idea for C#.  I make a lot of use of conditional orders and I hate when an exploration ship with a large fuel tank conditionally returns to the nearest spaceport/hub which has a tiny bit of fuel there for a fighter squadron and drains all the fuel from it when what I really wanted for them to do was to return to my larger central hub with loads of fuel.  I would propose a toggle switch on each colony that toggles whether they can be a fuel source or not.

Added for v2.0
Title: Re: C# Suggestions
Post by: Vandermeer on January 22, 2022, 10:19:58 AM
In the ground battle result log, perhaps rename "shots" into "attacks" or "strikes" or something similar. It is more ambiguous on what happened and thus helps with roleplay vision. E.g., what if I would field some Klingon melee berserkers or lab-grown bio horror bugs? Those wont use "shot", hmm, unless I rebrand it as "Seriously Hurtful Offensive Treatment" or something.
Title: Re: C# Suggestions
Post by: Kristover on January 22, 2022, 10:43:01 AM
Thanks for the fuel/conditional order change.  That addresses one of my biggest pains!
Title: Re: C# Suggestions
Post by: Garfunkel on January 22, 2022, 10:51:30 PM
Small QoL request:

Truncate the days and months displayed in all of the subwindows (primarily Fleet, Ship, Research, and Industry screens). Reduce days to 2-3 letters and months to 3 letters, such as:

Thursday, December 20, 2085 ---> (Th/Thu), Dec 20, 2085

I can almost never see the day and year when something is supposed to finish as the column for dates is never wide enough. I'm at 1920x1080 so it shouldn't be a display resolution issue either...
Change your Long Form Date setting in Windows. Aurora pulls the date setting from Windows so that's the culprit. These are the ones:
(https://i.imgur.com/7ivQXpN.png)

And it's found in:
Settings - Time & Language - Date. time & regional formatting - Change data formats
Title: Re: C# Suggestions
Post by: Scandinavian on January 23, 2022, 01:49:10 AM
And if the default options don't match your preference, you can go down to the bottom of the list of settings and pick "administrative options" (or suchlike name). A good date format is DDD, d, MMM, YYYY (which gives you "Wed. 1 Jan 2022")
Title: Re: C# Suggestions
Post by: ISN on January 23, 2022, 08:39:44 AM
Currently if a ship is boarded it's very easy to deny it to the enemy by abandoning ship once you're sure it's lost. This makes boarding as a mechanic much less fun: you don't get to fight against your own captured ships, and if you also control the faction doing the boarding, you don't get to play with the enemy's ships. Because of this I usually play with the house rule that you can only make one attempt to abandon ship, which has a probability of success weighted by the relative strengths of the attackers and defenders. It would be nice if a mechanic like this were added for the game; for instance, if each boarding combat round there's a chance for a "capture the bridge" event that disables the abandon ship button for that ship until boarders are defeated. This would make for a more interesting choice between abandoning ship early to deny it to the enemy or waiting to see how combat plays out and risking the ship being captured.
Title: Re: C# Suggestions
Post by: Barkhorn on January 23, 2022, 04:57:25 PM
Currently if a ship is boarded it's very easy to deny it to the enemy by abandoning ship once you're sure it's lost. This makes boarding as a mechanic much less fun: you don't get to fight against your own captured ships, and if you also control the faction doing the boarding, you don't get to play with the enemy's ships. Because of this I usually play with the house rule that you can only make one attempt to abandon ship, which has a probability of success weighted by the relative strengths of the attackers and defenders. It would be nice if a mechanic like this were added for the game; for instance, if each boarding combat round there's a chance for a "capture the bridge" event that disables the abandon ship button for that ship until boarders are defeated. This would make for a more interesting choice between abandoning ship early to deny it to the enemy or waiting to see how combat plays out and risking the ship being captured.
What if abandoning ship didn't make it self-destruct, but rather just spawned lifepods equal to the remaining crew and set the ship's crew to 0?  I mean the button IS abandon ship, not scuttle ship.
Title: Re: C# Suggestions
Post by: Garfunkel on January 23, 2022, 05:03:45 PM
Or just don't click the abandon ship button?
Title: Re: C# Suggestions
Post by: Droll on January 23, 2022, 08:02:48 PM
Or just don't click the abandon ship button?

I must press the big red button that says DO NOT PRESS
Title: Re: C# Suggestions
Post by: Vandermeer on January 24, 2022, 03:37:13 AM
Or just don't click the abandon ship button?

I must press the big red button that says DO NOT PRESS
(https://abload.de/img/screenshot2022-01-241tcj2h.jpg)
Title: Re: C# Suggestions
Post by: drakonbane on January 24, 2022, 05:35:05 AM
A suggestion to have STOs contribute to planetary protection rating instead of police force.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 24, 2022, 09:14:05 AM
A suggestion to have STOs contribute to planetary protection rating instead of police force.

PPV is calculated system-wide, not per-planet, so this wouldn't work unless the underlying calculation was rewritten.
Title: Re: C# Suggestions
Post by: ArcWolf on January 24, 2022, 08:18:36 PM
What if abandoning ship didn't make it self-destruct, but rather just spawned lifepods equal to the remaining crew and set the ship's crew to 0?  I mean the button IS abandon ship, not scuttle ship.

I too would like an actual "abandon ship" button to go along with the current "Self destruct' button.
Title: Re: C# Suggestions
Post by: drakonbane on January 25, 2022, 07:01:12 AM
Quote from: nuclearslurpee link=topic=10640. msg158259#msg158259 date=1643037245
Quote from: drakonbane link=topic=10640. msg158258#msg158258 date=1643024105
A suggestion to have STOs contribute to planetary protection rating instead of police force.

PPV is calculated system-wide, not per-planet, so this wouldn't work unless the underlying calculation was rewritten.

How is PPV calculated? and is it the same as it was in VB6?
Title: Re: C# Suggestions
Post by: Vandermeer on January 25, 2022, 08:05:24 AM
A suggestion to have STOs contribute to planetary protection rating instead of police force.

PPV is calculated system-wide, not per-planet, so this wouldn't work unless the underlying calculation was rewritten.
It is weird that it is called PPV though if actual planetary protection does not contribute, and only ship-type movable assets are considered. An orbital beam base contributes to all planets, but the just-as-movable, freighter dependent STO does not? Shady.
Title: Re: C# Suggestions
Post by: xenoscepter on January 25, 2022, 12:31:47 PM
A suggestion to have STOs contribute to planetary protection rating instead of police force.

PPV is calculated system-wide, not per-planet, so this wouldn't work unless the underlying calculation was rewritten.
It is weird that it is called PPV though if actual planetary protection does not contribute, and only ship-type movable assets are considered. An orbital beam base contributes to all planets, but the just-as-movable, freighter dependent STO does not? Shady.

 --- The answer is simple. The orbital beam platform has engines, the STO doesn't. Of course the colonists don't know that engine is made of cardboard since we've convinced them that all of the cardboard is used up on making the totally faked birds and stuff. It works out well since it doubles as a cover for the fact that birds are actually bird-shaped drones used for spying on people. Those dank memes aren't going to steal themselves ya know!
Title: Re: C# Suggestions
Post by: DEEPenergy on January 25, 2022, 04:54:02 PM
I know its been suggested before but some way to retool or upgrade ground units & templates to use new racial weapon and armor techs as they unlock would be awesome
Title: Re: C# Suggestions
Post by: Garfunkel on January 25, 2022, 09:44:43 PM
I know its been suggested before but some way to retool or upgrade ground units & templates to use new racial weapon and armor techs as they unlock would be awesome
Button to update your existing unit templates to use the latest racial weapon and armour tech while also renaming them with a running number scheme that can be edited by player like prefix and suffix for ships, which the player can then research at their convenience.

You'll end up with:

Cannon 21
Cannon 22
Cannon 23
Cannon 24

and so on. This way there wouldn't be multiple units with same name and no need for player to manually create units. Players would still need to research them so it isn't a cheat button, just a QoL change.

Formations don't need to be automated because we have unit series already.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 25, 2022, 10:05:53 PM
I know its been suggested before but some way to retool or upgrade ground units & templates to use new racial weapon and armor techs as they unlock would be awesome
[...]
Formations don't need to be automated because we have unit series already.

I'd honestly prefer to have the Unit Series system be automated so that units of the same design (base class, weapons, etc.) are automatically placed into a series together and formations are built out of unit series rather than specific units. With that done, upgrading can be as simple as paying for the difference in stats from one unit in the series to the next with some premium similar to ship refitting.
Title: Re: C# Suggestions
Post by: M_Gargantua on January 26, 2022, 08:40:25 AM
To go along with the 1. 13 Ordinal numbering (which I love):

To be in line with way armies speak either put the number first, or after a comma.  eg IV Infantry Division or Infantry Division, IV

Also, I'd like to see a slightly larger change; instead of per template add a template design "class" similar to ship design.  Ground unit class can be anything user defined, but anything that shares the same class gets numbered together.  Such that if I had three templates "Expeditionary Corps", "Armored Corps", and "Example" all under one class it would create "I Expeditionary Corps", "II Armored Corps", and "III Example", or "1st Expeditionary Corps", "2nd Armored Corps", and "3rd Example".

Similarly if you wanted two formations to have independent numbering sequences you could put them under separate class.  Formations "EX1" and "EX2" with classes of "(COM) Company" and "(COM) Marine Company", would create "1st EX1" and "1st EX2" on creation.

Class could also be set to set the default abbreviation and rank for a new template.
Title: Re: C# Suggestions
Post by: SevenOfCarina on January 27, 2022, 08:17:04 AM
I think I've suggested this before, but whatever : make missile warheads increase in efficiency with size, like shields do now. Use this formula instead of the current one:
Warhead Strength = (Warhead Size in MSP) * (Warhead Strength per MSP) * SQRT(Warhead Size in MSP)

I've tested this before (by editing the DB after finalising missile designs), and it seems to work pretty well at making larger missiles more effective and at addressing the AMM spam problem at high tech. An AMM with a levitated-pit implosion warhead would need ~0.4 MSP for the warhead instead of 0.25 MSP, while one with an antimatter warhead would need ~0.14 MSP instead of 0.05 MSP. This penalises warheads that are too small and provides strong advantages to going larger, which should hopefully offset some of the issues with large missiles doing poor damage against strong point-defence.
Title: Re: C# Suggestions
Post by: Garfunkel on January 27, 2022, 05:52:34 PM
To go along with the 1. 13 Ordinal numbering (which I love):

To be in line with way armies speak either put the number first, or after a comma.  eg IV Infantry Division or Infantry Division, IV

Also, I'd like to see a slightly larger change; instead of per template add a template design "class" similar to ship design.  Ground unit class can be anything user defined, but anything that shares the same class gets numbered together.  Such that if I had three templates "Expeditionary Corps", "Armored Corps", and "Example" all under one class it would create "I Expeditionary Corps", "II Armored Corps", and "III Example", or "1st Expeditionary Corps", "2nd Armored Corps", and "3rd Example".

Similarly if you wanted two formations to have independent numbering sequences you could put them under separate class.  Formations "EX1" and "EX2" with classes of "(COM) Company" and "(COM) Marine Company", would create "1st EX1" and "1st EX2" on creation.

Class could also be set to set the default abbreviation and rank for a new template.
While this is a good suggestion in general, the fact is that armies have a bewildering array of naming conventions. These include Roman and Arabic numerals and letters, using a comma or a period or nothing, using commander names instead of numbers, and so on. For example:

1st Armored Division "Old Ironsides"
1. Panzer-Division
1st (United Kingdom) Armoured Division
Panssaridivisioona
1re Division Blindée

these are all technically the same formation but there is no way to have an automated system to be able to name them logically.

The current system is good enough as it is, letting you switch between Roman and Arabic numerals. What I would like to see is a way to rename multiple formations at the same time following the same principle using wildcards, like was possible back in MS-DOS days for files. This way it's easy enough to rename series of formations the way you want without needing to have a cumbersome automated system that will never be 100% accurate anyway. Something like Ctrl/Shift click several formations, click Rename button and then use * and $ (and $$, $$$, $$$$$ and so on) to use parts of the original name and to have a running number.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 27, 2022, 05:54:54 PM
I think I've suggested this before, but whatever : make missile warheads increase in efficiency with size, like shields do now. Use this formula instead of the current one:
Warhead Strength = (Warhead Size in MSP) * (Warhead Strength per MSP) * SQRT(Warhead Size in MSP)

I've tested this before (by editing the DB after finalising missile designs), and it seems to work pretty well at making larger missiles more effective and at addressing the AMM spam problem at high tech. An AMM with a levitated-pit implosion warhead would need ~0.4 MSP for the warhead instead of 0.25 MSP, while one with an antimatter warhead would need ~0.14 MSP instead of 0.05 MSP. This penalises warheads that are too small and provides strong advantages to going larger, which should hopefully offset some of the issues with large missiles doing poor damage against strong point-defence.

This is a pretty good and simple solution. I think this could easily be introduced into the game without that many complications. Some changes to NPR designs might be needed as lower tech AMM will likely become larger if they want to hit anything. The exact formula can brobably beb debated but the solution would be pretty solid.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 27, 2022, 06:38:19 PM
I think I wouldn't want to make AMM warheads too much larger as this would significantly reduce AMM performance particularly at low tech levels while having minimal impact at higher tech levels. 0.4 MSP versus 0.25 MSP is quite extreme as it would reduce speed and thus, approximately, AMM hit rate by nearly 25%. If we scale it to the MSP required for a 1-damage warhead (which is just 1/tech level), then we can use an expression like (Size*Strength per MSP)^(3/2) which is perhaps not so intuitive for players but makes higher-damage missiles more feasible while preserving AMM capabilities.

A better way to pull back high-tech AMMs would be to reduce the missile agility gain per tech level. Currently it is something quite ridiculous: 20 per MSP, then 32, then 48, then 64... basically the early levels increase very quickly and then agility is inflated for all the tech levels. In my modded DB I have adjusted the early levels to 20, 25, 32, 40, ... in the same pattern as most numerical-valued techs in the game, and agility caps out at 250 per MSP which is not quite enough to create 100% hitrate AMMs at MaxTech without sacrificing ECCM (I think you can reach about 80-85% from a quick calculation; of course you can reach 100% without ECCM, but then ECM makes your AMMs useless). The impact is not too great at lower techs because most of the AMM hit rate comes from the engine techs until you reach the middle tiers anyways, so on balance coupled with the above change to damage it should work fairly well.
Title: Re: C# Suggestions
Post by: Desdinova on January 28, 2022, 10:16:00 AM
I like to use multiple name themes to represent a united Earth government. It would be nice to be able to export/import commander name themes and weights the way we do medals and event text colors.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on January 28, 2022, 04:47:11 PM
I think I wouldn't want to make AMM warheads too much larger as this would significantly reduce AMM performance particularly at low tech levels while having minimal impact at higher tech levels. 0.4 MSP versus 0.25 MSP is quite extreme as it would reduce speed and thus, approximately, AMM hit rate by nearly 25%. If we scale it to the MSP required for a 1-damage warhead (which is just 1/tech level), then we can use an expression like (Size*Strength per MSP)^(3/2) which is perhaps not so intuitive for players but makes higher-damage missiles more feasible while preserving AMM capabilities.

A better way to pull back high-tech AMMs would be to reduce the missile agility gain per tech level. Currently it is something quite ridiculous: 20 per MSP, then 32, then 48, then 64... basically the early levels increase very quickly and then agility is inflated for all the tech levels. In my modded DB I have adjusted the early levels to 20, 25, 32, 40, ... in the same pattern as most numerical-valued techs in the game, and agility caps out at 250 per MSP which is not quite enough to create 100% hitrate AMMs at MaxTech without sacrificing ECCM (I think you can reach about 80-85% from a quick calculation; of course you can reach 100% without ECCM, but then ECM makes your AMMs useless). The impact is not too great at lower techs because most of the AMM hit rate comes from the engine techs until you reach the middle tiers anyways, so on balance coupled with the above change to damage it should work fairly well.

The point about changing the strength of the warhead really have nothing to do with AMM... but changing the agility and flatten the curve will fix AMM, I do that with DB all the time. I like to have AMM be roughly equally valuable throughout an entire game. I tend to flatten the agility per MSP around 100... starting out at around 80 and end around 125... that produce AMM with hit rates around 25-40% depending on tech levels and if you need ECCM in them or not.

Starting Agility at 20 is a joke in my opinion as it is completely useless for AMM purposes, no point in using AMM at that point... AMM don't start to produce any result until at least above 60 per MSP. If you also need ECCM you need a bit more agility as well for the same hit rates.
Title: Re: C# Suggestions
Post by: Desdinova on January 29, 2022, 02:03:21 PM
Super minor thing but does anyone else think some of the medal award criterias are a bit optimistic? Specifically the "Discover 100 new systems" and "Discover 1000 system bodies with minerals" conditions. Careers just don't last long enough to achieve those unless you start with a very high tech level and/or make your survey captains story characters and never reassign them.
Title: Re: C# Suggestions
Post by: xenoscepter on January 29, 2022, 02:49:18 PM
Kinetic Missile Warhead:
 --- A warhead which requires no MSP, but provides a Strength equal to Missile Size, down to a minimum Strength of 1.
Title: Re: C# Suggestions
Post by: ArcWolf on January 29, 2022, 06:49:41 PM
Kinetic Missile Warhead:
 --- A warhead which requires no MSP, but provides a Strength equal to Missile Size, down to a minimum Strength of 1.

so a size 2 missile would do 2 damage and a size 6 would do 6?

I mean it's a cool idea, but then it's essentially long range, slow firing beam weapons with limited ammo. Would you keep the missile damage pattern or change it to something like laser damage pattern?
Title: Re: C# Suggestions
Post by: Droll on January 29, 2022, 08:33:36 PM
Kinetic Missile Warhead:
 --- A warhead which requires no MSP, but provides a Strength equal to Missile Size, down to a minimum Strength of 1.

so a size 2 missile would do 2 damage and a size 6 would do 6?

I mean it's a cool idea, but then it's essentially long range, slow firing beam weapons with limited ammo. Would you keep the missile damage pattern or change it to something like laser damage pattern?

Having good armor penetration at missile ranges would definitely be a new capability. Probably wouldn't be too unbalanced given that the price you are paying is incredible damage inefficiency. Even at base tech 1 MSP warhead is 3 damage.

On the other hand you'd need something to pad out missile size for this to make sense and be anywhere close to cost-viable. Some sort of field for empty hull in MSP. Otherwise you are forced to put fuel that's not going to get burned at combat ranges.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 29, 2022, 11:38:22 PM
Super minor thing but does anyone else think some of the medal award criterias are a bit optimistic? Specifically the "Discover 100 new systems" and "Discover 1000 system bodies with minerals" conditions. Careers just don't last long enough to achieve those unless you start with a very high tech level and/or make your survey captains story characters and never reassign them.

Yes. I mod these to reasonable values and also add several more steps to most criteria.

Kinetic Missile Warhead:
 --- A warhead which requires no MSP, but provides a Strength equal to Missile Size, down to a minimum Strength of 1.

There are several problems:
Overall it is not a suggestion I could support.

On the other hand you'd need something to pad out missile size for this to make sense and be anywhere close to cost-viable. Some sort of field for empty hull in MSP. Otherwise you are forced to put fuel that's not going to get burned at combat ranges.

Not sure where this is going...if you take out the warhead, the empty space would be filled by some combination of engine/agility/fuel MSP to reach a desired performance characteristic. Honestly, about the only use cases I can imagine beyond low-tech (when kinetic warheads are strictly the best) would (1) extreme long-range missiles (low damage is counterbalanced by striking from well beyond range of any retaliation or (2) AMMs (blatantly OP, please do not do this).
Title: Re: C# Suggestions
Post by: Desdinova on January 30, 2022, 01:10:17 PM
Suggestion: Industrial command and control modules. Like a mining control center that allows a junior officer to apply their mining bonus, with a similar module for terraforming modules.
Title: Re: C# Suggestions
Post by: linkxsc on January 31, 2022, 12:11:58 AM
Tiny little thing.

1 of a couple patches ago (I don't really remember), there were a series of "command" modules added to the game, such as the Auxiliary Control, Combat Information Center, or the Science Department and etc. When these modules are added to a ship, they give the ship 3 letter tags in it's ship design readout.

Could you please add these tags (and a description of what they do to a ship) to the "Glossary" tab of the ship design window, to bring these tags in line with the other ship design tags (BP. TCS, AFT and etc).
Title: Re: C# Suggestions
Post by: alex_brunius on January 31, 2022, 08:26:15 AM
Id love to see an option to display either tonnage or % strength left vs template listed in the ground forces OOB tab list. So that you can quickly see which units are damaged, might be lacking supplies or have units added to them bringing them over nominal strength.
Title: Re: C# Suggestions
Post by: Borealis4x on January 31, 2022, 10:59:43 AM
Suggestion: Industrial command and control modules. Like a mining control center that allows a junior officer to apply their mining bonus, with a similar module for terraforming modules.

Would love this. The more officer slots we can add the better. I already put a Science module in terraforming platforms for RP purposes.
Title: Re: C# Suggestions
Post by: nuclearslurpee on January 31, 2022, 11:03:30 AM
Suggestion: Industrial command and control modules. Like a mining control center that allows a junior officer to apply their mining bonus, with a similar module for terraforming modules.

Would love this. The more officer slots we can add the better. I already put a Science module in terraforming platforms for RP purposes.

How the Hell do you people have extra officers sitting around and I can't buy enough captains for my fleets with all the money in the empire??
Title: Re: C# Suggestions
Post by: Desdinova on January 31, 2022, 11:38:55 AM
Currently I have to manually promote people with good mining/terraforming bonus. I like to have senior officers command my mining/terraforming space stations so they have longer careers and accrue bigger industrial bonuses.
Title: Re: C# Suggestions
Post by: serger on February 01, 2022, 10:27:09 AM
Just noticed in Colonial AAR thread, that light green color of neutral contacts is quite close to slightly darker green color of orbits, therefore it's quite difficult to find those contacts in the orbital space of some multi-body system if you have not-so-good color vision or just a sun blinking at your monitor.
Maybe it will be nice to change light green neutral contact color to white or light grey or smth?
Title: Re: C# Suggestions
Post by: Platys51 on February 01, 2022, 02:57:04 PM
Offloading fire control from fighters.
You can already gather sensor data with different ship then feed them to fire controls on board of fighters to calculate firing solutions.
Wouldnt it make more sense to do all the heavy lifting calculations on board of carriers and instead of sensor data, just feed them firing solutions directly?
It could be a module that would act as fire control for a certain number of ships docked to the mothership while said ships would only need a receiver on board.

This would take weight and cost away from fighters, making beam fighters perform better without needing any special rules for them.
Title: Re: C# Suggestions
Post by: alex_brunius on February 02, 2022, 04:52:47 AM
The difference in cost between adding a new slipway to a fresh shipyard ( doubling capacity ) and building a new shipyard from scratch feels like it doesn't make much sense.

I understand it's a limitation with tooling of all slipways being to the same ship, but it feels like this limitation shouldn't reduce the cost to less than 10% compared to building a fresh new shipyard.
Title: Re: C# Suggestions
Post by: kingflute on February 02, 2022, 06:54:41 AM
The difference in cost between adding a new slipway to a fresh shipyard ( doubling capacity ) and building a new shipyard from scratch feels like it doesn't make much sense.

I understand it's a limitation with tooling of all slipways being to the same ship, but it feels like this limitation shouldn't reduce the cost to less than 10% compared to building a fresh new shipyard.
Dont forget that a shipyard isnt just the slipways. It includes the storage, logistics, manufacturing/assembly facilities and the trained workers. Expanding an existing shipyard requires less work as fewer new facilities need to be built, and the workforce can be distributed to reduce the training required to staff the facilities
Title: Re: C# Suggestions
Post by: alex_brunius on February 02, 2022, 07:15:28 AM
Dont forget that a shipyard isnt just the slipways. It includes the storage, logistics, manufacturing/assembly facilities and the trained workers. Expanding an existing shipyard requires less work as fewer new facilities need to be built, and the workforce can be distributed to reduce the training required to staff the facilities

I'm not asking for them to be equal in cost, just questioning if it's balanced right when about +5-10% of the investment can buy you +100% more output.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 02, 2022, 10:11:25 AM
The balance is not in the relative costs, it is in the fact that a shipyard is built with planetary construction factories, but expanded only by its own innate construction capability which is much slower even if much cheaper. This is a good balance as it encourages shipyard expansion due to being cheaper, otherwise if the costs were equal building new yards would be nearly always the optimal decision as it is usually better to have more shipyards than to have more slipways on fewer yards. As it currently stands, the decision between new shipyards and shipyard expansion is very meaningful, since you must build new yards in order to build the many different kinds of ships your space empire needs and interbuilding between similar classes will only get you so far.
Title: Re: C# Suggestions
Post by: alex_brunius on February 02, 2022, 12:50:14 PM
The balance is not in the relative costs, it is in the fact that a shipyard is built with planetary construction factories, but expanded only by its own innate construction capability which is much slower even if much cheaper.
That depends on the situation, you play in a conventional start where you have only 500 BP/year available, then a shipyard is not faster at all, it takes almost 5 years to complete, while adding a slipway can be done in exactly 1 year.

...otherwise if the costs were equal...
Did you read the post your responding to?
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 02, 2022, 02:49:52 PM
The balance is not in the relative costs, it is in the fact that a shipyard is built with planetary construction factories, but expanded only by its own innate construction capability which is much slower even if much cheaper.
That depends on the situation, you play in a conventional start where you have only 500 BP/year available, then a shipyard is not faster at all, it takes almost 5 years to complete, while adding a slipway can be done in exactly 1 year.

A conventional start is balanced around converting your starting CI into TN industry before you spend a lot of resources expanding your shipyards, using your initial yards to start your expansion (which is enough to launch a survey ship from the naval yard plus colony/cargo ships from the commercial yard). TN construction factories are 10x as efficient as CI so you can get a shipyard into orbit in a year or two if you want to once you've done the conversions.

That being said, I did make an error. Shipyards are not especially slower than planetary factories; they do produce much less "BP" than planetary industry but this is balanced out by the lower cost of expanding the yard compared to building a fresh one planetside. Here I misspoke as I meant to address the difference in BP production which is not the most useful measurement anyways.

That aside, the substance of my point is the same, they are two different kinds of costs paid by two different kinds of build mechanics. Expanding shipyards is cheaper and preferable in a vacuum. Building new yards is necessary to build more ship classes in a useful amount of time, but is and should be more expensive so that it is not greatly preferable to adding new slipways to existing yards. I think in terms of the gameplay it is very reasonable, in practice I tend to find that working my shipyards at full expansion capacity makes the expense comparable to planetary industry and actual shipbuilding so I would not want to upset that balance very much in either direction.

Quote
...otherwise if the costs were equal...
Did you read the post your responding to?

No, I just happened to type a post that coincidentally was on the same topic in a freak accident of probability.  ;)
Title: Re: C# Suggestions
Post by: alex_brunius on February 02, 2022, 03:04:10 PM
A conventional start is balanced around converting your starting CI into TN industry before you spend a lot of resources expanding your shipyards, using your initial yards to start your expansion (which is enough to launch a survey ship from the naval yard plus colony/cargo ships from the commercial yard).

I very rarely start my conventional games with any shipyards. Doesn't make any logical sense at all to be able to get a 10000 ton facility into space without TN tech IMHO.

And it doesn't make much sense either that the second slipway I get into space can cost 10 times as much if I want it to be able to build a different class of ships...

but is and should be more expensive so that it is not greatly preferable to adding new slipways to existing yards.

That they should be more expensive is not something I ever disagreed with. What I disagree with is if they need to be 10 times or more expensive to be balanced?
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 02, 2022, 03:25:46 PM
but is and should be more expensive so that it is not greatly preferable to adding new slipways to existing yards.

That they should be more expensive is not something I ever disagreed with. What I disagree with is if they need to be 10 times or more expensive to be balanced?

It is a question of gameplay vs verisimilitude, personally I prefer to err on the former side and not pay too much attention to the numbers under the hood so long as I understand the mechanics involved, but others approach the game quite differently. As I said, in practice I have found shipyard expansion to be suitably costed compared to other major expense categories. Increasing the cost of shipyard expansion would slow things down considerably as players will lack the economic means to expand very quickly, while decreasing the cost of building new yards makes it a lot quicker and cheaper to put yards into orbit. Neither of these are strictly bad things, but they do shift the game economy balance so making a significant change can have perhaps undesired knock-on effects.

The good news is that both of these quantities should be easily moddable if you want to test some changes, although the changes might not be easy to reflect in the GUI. For shipyards it is easy, just change the build costs in DIM_PlanetaryInstallations to whatever value you think is reasonable (I'd probably start by halving the costs - don't forget repair yards!). For shipyard expansions it is a bit of a hack, but in FCT_TechSystem you can modify the Shipyard Operations techs to effectively increase the costs by some factor. The vanilla values are 1.0, 0.95, 0.9, ... so you could change these to 2.0, 1.9, 1.8, ... and double the time and build costs associated with shipyard operations.
Title: Re: C# Suggestions
Post by: papent on February 02, 2022, 03:33:56 PM

Would love this. The more officer slots we can add the better. I already put a Science module in terraforming platforms for RP purposes.

I agree that we should put as many officers as possible on ships, I suggested something similar
A minor suggestion and an expansion of the Misc component Idea

Miscellaneous Ship Officer Stations
You design the components on the Create Research Projects window by:
  • Choosing a size (from 1 HS to 10)
  • giving the component a name
  • Choosing an Officer Type ( Naval, Ground, Admin, Scientist)
  • Choosing an Officer Skill That will be the Primary selection Criteria
  • For Naval/Ground/Admin only: Rank Required (Racial Min +0/1/2/3/4)

Cost is equal to size in HS and the mineral requirements are split between 20% Duranium and 80% Corbomite. The HTK is equal to the square root of the size. additional the officer improves the skill required by the ship station up to 1% or 1 per year per HTK of the component. [ballparking some figures]

two example Officer Stations

Code: [Select]
Internal Security Control
Cost 100   Size 100 tons   Crew 15   HTK 1
Officer: Ground Force Officer
Rank: Major
Skill: Ground Combat Defence
Base Chance to hit 100%
Materials Required: Duranium  20    Corbomite  80   

Code: [Select]
Civil Logistic Liaison
Cost 200   Size 200 tons   Crew 30   HTK 2
Officer: Civilian Administrator
Rank: Admin Rating 1
Skill: Logistics
Base Chance to hit 100%
Materials Required: Duranium  40    Corbomite  160   

thoughts?

Edited: Change Rank Idea with RougeNPS input.
Title: Re: C# Suggestions
Post by: ArcWolf on February 04, 2022, 09:46:55 PM
Can we have a hybrid "Know Star Systems" setting? This way we can have earth, proximal centari, etc, but also get pulsars, nebula etc after a set distance in either LY or after a set number of jumps.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 04, 2022, 11:42:04 PM
Can we have a hybrid "Know Star Systems" setting? This way we can have earth, proximal centari, etc, but also get pulsars, nebula etc after a set distance in either LY or after a set number of jumps.

Sorry to disappoint you, but thus far we don't even have pulsars, nebulae, black holes, etc. in C#, so this would need to come before such a change could be considered.
Title: Re: C# Suggestions
Post by: Steve Walmsley on February 05, 2022, 05:11:44 AM
Can we have a hybrid "Know Star Systems" setting? This way we can have earth, proximal centari, etc, but also get pulsars, nebula etc after a set distance in either LY or after a set number of jumps.

Sorry to disappoint you, but thus far we don't even have pulsars, nebulae, black holes, etc. in C#, so this would need to come before such a change could be considered.

I do have some ideas around new 'star' types, but I plan to release v2.0 before making any more significant changes.
Title: Re: C# Suggestions
Post by: ArcWolf on February 05, 2022, 05:30:22 AM
Can we have a hybrid "Know Star Systems" setting? This way we can have earth, proximal centari, etc, but also get pulsars, nebula etc after a set distance in either LY or after a set number of jumps.

Sorry to disappoint you, but thus far we don't even have pulsars, nebulae, black holes, etc. in C#, so this would need to come before such a change could be considered.

never play on anything other then know star systems, so i did not realize they were not yet implemented in C#.
Title: Re: C# Suggestions
Post by: alex_brunius on February 05, 2022, 07:18:59 AM
I do have some ideas around new 'star' types, but I plan to release v2.0 before making any more significant changes.

Would be great with even more variation for sure! ( Beyond what we will get from Eccentric Orbits )
I loved the pulsars, nebulae and black holes in vb6 Aurora and miss how they added some unique systems  :)
Title: Re: C# Suggestions
Post by: xenoscepter on February 05, 2022, 05:10:20 PM
 --- I've probably said it before, but I'll say it again. I'd really like to see the ability to assign Direct Support freely, regardless of formation size or HQ size. I'd like the option to have Sub-Ordinate formations assigned to provide Direct Support to the formation it is Sub-Ordinate to. Thank you for coming to my TED Talk.
Title: Re: C# Suggestions
Post by: Migi on February 07, 2022, 08:41:30 PM
1) Could we have a 0.5T Fuel Storage component? We already have a 0.5T maintenance storage bay, but sometimes adding a tiny amount of fuel would be preferable to adding a tiny amount of MSP.

2) I would like a checkbox in the commanders window, so that the 'search box' in the bottom right only shows unassigned commanders.

3) At the moment the auto class assignment doesn't seem to look at deployment time or range for military ships. A ship with weapons over 1000T is always "classed as a c for auto-assignment purposes" (I assume c is a generic warship).
If the deployment time is less than ~3 months and/or range less than ~10b km could it be classed as a system defence vessel? The AI can count it when determining defensive strength and ignore it when counting offensive strength.
Title: Re: C# Suggestions
Post by: xenoscepter on February 08, 2022, 06:15:58 PM
 --- Weird idea just hit me out of the blue: Deployment Ships. Ships with modules that let them extend the deployment of fleets. Unlike Rec Modules these ships wouldn't provide effectively infinite Deployment and the components to create them would be Military rather than Commercial.
Title: Re: C# Suggestions
Post by: Kiero on February 10, 2022, 08:19:36 AM
Ground Units:

Ability to produce units as replenishment ones (no formation number tracking).
Ability to filter units in "Formation Templates" window (by type / components and so on).
Title: Re: C# Suggestions
Post by: Geeptoon on February 10, 2022, 03:27:53 PM
A Quality of life improvement.   Templates for setting Mineral reserve amounts for colonies.   Or at least a set reserve for all minerals button.   Unless I'm missing this already.
Title: Re: C# Suggestions
Post by: papent on February 10, 2022, 04:16:17 PM
A Quality of life improvement.   Templates for setting Mineral reserve amounts for colonies.   Or at least a set reserve for all minerals button.   Unless I'm missing this already.

Something that makes the reserve equal to consumption?
Title: Re: C# Suggestions
Post by: Garfunkel on February 11, 2022, 01:11:30 AM
Conventional Small Tug Clamps

and

Conventional Large Tug Clamps

CSTC would be a 100-ton component that allows ship to 'clamp' into another ship. As it is using physical connection for tugging instead of TN-based tractor beam, it can only maintain connection if the masses in question are 1000-tons or less and speed is 100 km/sec or less.

CLTC is similar but takes up little bit more space (maybe 500 tons) to simulate it is more comprehensive and larger clamping system, that allows same speed but larger sizes.

Especially the first one would allow a more comprehensive conventional-era play. We can now have a fighter/FAC-level game going on with cargo, colonists, and fuel being able to move transferred but if something bad happen, there's no tugs to help things out. So, this would allow one fighter or FAC to tug another fighter or FAC, while the larger variant would make space stations movable before TN-tech.
Title: Re: C# Suggestions
Post by: ArcWolf on February 11, 2022, 02:24:52 AM

CSTC would be a 100-ton component that allows ship to 'clamp' into another ship. As it is using physical connection for tugging instead of TN-based tractor beam, it can only maintain connection if the masses in question are 1000-tons or less and speed is 100 km/sec or less.


combined mass or max mas per vessel?
Title: Re: C# Suggestions
Post by: Garfunkel on February 11, 2022, 07:43:55 AM
For the small, it could be combined - so a fighter tugging a fighter is all you can do. Then the larger would allow FAC tugging a FAC or even bigger. But it might be easier to just restrict them at per ship as that's the sort of limits used elsewhere.
Title: Re: C# Suggestions
Post by: TMaekler on February 12, 2022, 01:13:20 PM
A Quality of life improvement.   Templates for setting Mineral reserve amounts for colonies.   Or at least a set reserve for all minerals button.   Unless I'm missing this already.
I think you can set a planetary reserve level for each mineral by double-clicking on the number in the reserve column in economics - mining tab. Is that what you are searching for?
Title: Re: C# Suggestions
Post by: Geeptoon on February 12, 2022, 04:39:29 PM
I was wanting a way to set the planetary reserves faster so you don’t have to click on each mineral on each planet.
Title: Re: C# Suggestions
Post by: RaidersOfTheVerge on February 12, 2022, 08:51:16 PM
Could we have 2 "Move to" items in the movement order list?
1) Move to 0 - always moves to 0 km distance to the target selected
2) Move to distance - this uses the distance in the minimum distance box

thanks
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 13, 2022, 12:01:14 AM
Could we have 2 "Move to" items in the movement order list?
1) Move to 0 - always moves to 0 km distance to the target selected
2) Move to distance - this uses the distance in the minimum distance box

thanks

Why? We already have this behavior, case (1) is what happens if you set the distance to zero which is the default. Why have two orders when one already does the job perfectly?
Title: Re: C# Suggestions
Post by: Migi on February 13, 2022, 05:21:40 PM
Could you make it so that "hide fleets in orbit" only hides fleets that have no orders?
That way ships which are doing a survey don't disappear while they are in orbit, but busy.
Title: Re: C# Suggestions
Post by: chrislocke2000 on February 13, 2022, 05:31:39 PM
A couple of suggestions

- In the system display tab add a button to allow the highlighted body to have a waypoint added to it. Very helpful when picking through which planets you want to fire a sensor probe towards without then having to go to the map and create the waypoint from there

- Add an escort order which acts as a follow order but will also follow target ships through a jump point if they can jump. Can see that being very useful when escorting civ shipping and you don't want to attach the military ship to the civ task group
Title: Re: C# Suggestions
Post by: Migi on February 13, 2022, 08:18:32 PM
- In the system display tab add a button to allow the highlighted body to have a waypoint added to it. Very helpful when picking through which planets you want to fire a sensor probe towards without then having to go to the map and create the waypoint from there
I like this, but what if there was an option to target bodies directly?
Simply add a checkbox called "Target System Bodies" in the Ship Combat tab, it hides all contacts, then displays all system bodies and jump points, and you just assign them the same way as normal?
You might still need to use waypoints in systems with a bazillion asteroids.
Title: Re: C# Suggestions
Post by: ArcWolf on February 14, 2022, 05:46:01 PM
With 1.13 you added miscellaneous components, While i have not use them much, they are great for RP. So can we expand this?
1) Miscellaneous Buildings: Designed like a component, you can chose the size (for transport) the amount of population they use, and how many can be built per planet. This way we can RP things like Planetary Administrations, etc.

2) Miscellaneous Techs: Same premise, you 'design' them like a component, giving it a name, category & RP value and they you can research them.

I know both can be done through a DB edit, however having them available, even if only in SM mode, without having to worry about DB edits would be great.
Title: Re: C# Suggestions
Post by: Kristover on February 14, 2022, 09:48:04 PM
With 1.13 you added miscellaneous components, While i have not use them much, they are great for RP. So can we expand this?
1) Miscellaneous Buildings: Designed like a component, you can chose the size (for transport) the amount of population they use, and how many can be built per planet. This way we can RP things like Planetary Administrations, etc.

2) Miscellaneous Techs: Same premise, you 'design' them like a component, giving it a name, category & RP value and they you can research them.

I know both can be done through a DB edit, however having them available, even if only in SM mode, without having to worry about DB edits would be great.

I'll double down on this one.  I personally would like to have some more 'vertical' options for developing colonies but in the absence of that, this seems like a nice low cost/effort way to satisfy the roleplayers among us.  I already make good use of the misc. components to add 'flavor' to my ships.  This seems like a logical progression.
Title: Re: C# Suggestions
Post by: Garfunkel on February 16, 2022, 05:02:27 AM
Oh, and Steve, back before the release of C#, we talked about being able to export/import ground forces, designs and OOBs, for the purpose of creating historically accurate national armies and sharing them with other players. Is that functionality something you could add to 2.0 or is it too complicated? If complete OOBs are not possible, would just unit designs and formation designs be possible to import/export? Would be grand if possible!
Title: Re: C# Suggestions
Post by: Steve Walmsley on February 16, 2022, 05:22:57 AM
Oh, and Steve, back before the release of C#, we talked about being able to export/import ground forces, designs and OOBs, for the purpose of creating historically accurate national armies and sharing them with other players. Is that functionality something you could add to 2.0 or is it too complicated? If complete OOBs are not possible, would just unit designs and formation designs be possible to import/export? Would be grand if possible!

This is something I have been pondering the last few days. I think it is possible, but it would done at the component level and use whatever tech was available, rather than having exact copies.
Title: Re: C# Suggestions
Post by: Desdinova on February 16, 2022, 12:12:06 PM
Oh, and Steve, back before the release of C#, we talked about being able to export/import ground forces, designs and OOBs, for the purpose of creating historically accurate national armies and sharing them with other players. Is that functionality something you could add to 2.0 or is it too complicated? If complete OOBs are not possible, would just unit designs and formation designs be possible to import/export? Would be grand if possible!

This is something I have been pondering the last few days. I think it is possible, but it would done at the component level and use whatever tech was available, rather than having exact copies.

Having new-built units automatically be constructed with the current armor and weapons tech would be a great QOL feature. You could increase the initial research costs for each unit to compensate.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 16, 2022, 09:26:33 PM
Oh, and Steve, back before the release of C#, we talked about being able to export/import ground forces, designs and OOBs, for the purpose of creating historically accurate national armies and sharing them with other players. Is that functionality something you could add to 2.0 or is it too complicated? If complete OOBs are not possible, would just unit designs and formation designs be possible to import/export? Would be grand if possible!

This is something I have been pondering the last few days. I think it is possible, but it would done at the component level and use whatever tech was available, rather than having exact copies.

Having new-built units automatically be constructed with the current armor and weapons tech would be a great QOL feature. You could increase the initial research costs for each unit to compensate.

This would be a big disincentive to develop new unit types, as not only would the research cost be more expensive but the existing unit classes would be upgraded freely so it becomes silly to develop replacement classes. Additionally from a roleplay standpoint if GU classes automatically upgrade I couldn't have incremental models (Mark I, II, III...) unless I wanted to spend a bunch of extra RP for zero in-game benefit (again - at the new, higher cost).

What would make sense is some ability to select an existing class and create a research project for a class with the same configuration but the latest armor and attack techs. This would eliminate a lot of the micromanagement involved in upgrading ground units but still preserve the existing mechanics and research costs for upgrading. Ideally, this could be folded into a revamped, automatic Unit Series mechanic which I've suggested elsewhere so that new classes can be generated from templates in the Unit Series tab.
Title: Re: C# Suggestions
Post by: Scandinavian on February 17, 2022, 04:52:04 PM
Personally, the top of my ground unit QoL wishlist is the ability to design formations with subordinate formations and stance and support relationships baked in. So I can design my divisional structure in the formation planner and have the individual elements slot into the ToOE as they are constructed.

On the mechanics side, I'm very much in favor of converting ground unit training into a system that works more like industrial production, but with minimum training times for specific units (similar to how the build queue works in Hearts of Iron). As it is now, using multiple GFTFs to train a large formation involves breaking down the formation template into individual sub-formations and fiddling with the construction costs until they are about equal, then training them separately and combining at the end. This is tedious and error-prone, and makes IMO only limited sense.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 17, 2022, 05:39:11 PM
On the mechanics side, I'm very much in favor of converting ground unit training into a system that works more like industrial production, but with minimum training times for specific units (similar to how the build queue works in Hearts of Iron). As it is now, using multiple GFTFs to train a large formation involves breaking down the formation template into individual sub-formations and fiddling with the construction costs until they are about equal, then training them separately and combining at the end. This is tedious and error-prone, and makes IMO only limited sense.

This has been a frequent request, and Steve has acknowledged the need but not yet developed a solution as far as we know.

I think a large part of the issue is that when Steve developed the ground forces system, he probably had in mind that battalions would be the base formation size (~2,500 to 5,000 tons) as in VB6 (you can see this in the rank themes as well). With this assumption, the ground forces training works without too much trouble as a 5,000-ton infantry battalion can be built in about 5 months at the base training speed tech level, and a similarly-sized armored battalion in 3-4 times that. Once you start developing the training techs these times go down and more expensive units (heavily armored or with added capabilities) can be trained in roughly a year to provide a natural progression of sorts.

The problem has been that the ratio of ground force leaders to number of formations with such small formations is not favorable, and so the equilibrium tends to settle closer to 15,000 to 25,000 tons regiments/brigades as the base size which take multiple years to train. Steve has noticed this, as NPRs tend to use ~15,000 tons as their base formation size, but a change for ground unit construction has not yet come. There is some hope that the doubling of naval and ground commander birth rates in 2.0 can help with this, maybe reducing the needed formation sizes to ~10,000 tons which is more manageable once you research a few levels of the training tech, but it's not going to be a real solution.
Title: Re: C# Suggestions
Post by: Scandinavian on February 17, 2022, 11:49:57 PM
On the mechanics side, I'm very much in favor of converting ground unit training into a system that works more like industrial production, but with minimum training times for specific units (similar to how the build queue works in Hearts of Iron). As it is now, using multiple GFTFs to train a large formation involves breaking down the formation template into individual sub-formations and fiddling with the construction costs until they are about equal, then training them separately and combining at the end. This is tedious and error-prone, and makes IMO only limited sense.

This has been a frequent request, and Steve has acknowledged the need but not yet developed a solution as far as we know.

I think a large part of the issue is that when Steve developed the ground forces system, he probably had in mind that battalions would be the base formation size (~2,500 to 5,000 tons) as in VB6 (you can see this in the rank themes as well). With this assumption, the ground forces training works without too much trouble as a 5,000-ton infantry battalion can be built in about 5 months at the base training speed tech level, and a similarly-sized armored battalion in 3-4 times that. Once you start developing the training techs these times go down and more expensive units (heavily armored or with added capabilities) can be trained in roughly a year to provide a natural progression of sorts.

The problem has been that the ratio of ground force leaders to number of formations with such small formations is not favorable, and so the equilibrium tends to settle closer to 15,000 to 25,000 tons regiments/brigades as the base size which take multiple years to train. Steve has noticed this, as NPRs tend to use ~15,000 tons as their base formation size, but a change for ground unit construction has not yet come. There is some hope that the doubling of naval and ground commander birth rates in 2.0 can help with this, maybe reducing the needed formation sizes to ~10,000 tons which is more manageable once you research a few levels of the training tech, but it's not going to be a real solution.
Personally, I don't so much mind having to spend a year standing up an infantry brigade. That seems a little long, but not outside the realm of reasonableness (in our own reality, infantry that is mobilized in less than that time tends to be pretty use-impaired anyway - this is why you can tell a lot about an army's state of readiness from the length of its tours of duty).

But the two years I have to wait for that twelve-gun STO battery I ordered seems a little out of whack with the pace at which my shipyards can crank out the same guns when I wrap them in an engineless papier-mache hull and slap a bridge on them.
Title: Re: C# Suggestions
Post by: Droll on February 18, 2022, 09:31:27 AM
But the two years I have to wait for that twelve-gun STO battery I ordered seems a little out of whack with the pace at which my shipyards can crank out the same guns when I wrap them in an engineless papier-mache hull and slap a bridge on them.

This is honestly the core of the issue for me. It seems so wildly inconsistent especially since your building the same guns at a much faster rate for spaceships.
Title: Re: C# Suggestions
Post by: alex_brunius on February 19, 2022, 04:42:22 PM
Allow instant moving a Ground Force Formation from one body to another via drag and drop if SM mode is active:
( Disable this check )

(https://i.postimg.cc/2SjBMv1n/image.png)
Title: Re: C# Suggestions
Post by: Platys51 on February 21, 2022, 05:12:04 AM
Make sun selectable object in fleet movement window. Clicking colonize on it would made colony on all bodies in system with minerals, orbital mining option would plot route trough all bodies eligible for this and used "load all minerals" before leaving for next place.

Would work well with new deep space cargo transfers as you could have ships take contents of mining ship cargo hold mid mission.

Also, star could be used to issue general system wide commands that could be executed with one click.
Title: Re: C# Suggestions
Post by: nakorkren on February 21, 2022, 09:22:13 AM
Consider having shields and active sensors require power to operate, with the amount of power based on their strength. This would create several new gameplay dynamics relating to power management during combat. This would definitely require some serious thought to balancing, since it would make shields weaker (relative to armor) due to the need for additional hull space for power, but I think the various trade-offs to be considered during ship design and combat would be a lot of fun.

My apologies if this has been debated or considered previously, but I didn't see anything on the forum to this effect, other than the fact that shields used to consume fuel, which is different.
Title: Re: C# Suggestions
Post by: Black on February 21, 2022, 01:30:07 PM
I noticed that when Administrator reaches highere admin rating it is not shown in their history in Commanders window. Would it be possible to add this feature?
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 21, 2022, 02:05:54 PM
Small RP suggestion, in two parts:
Title: Re: C# Suggestions
Post by: Black on February 21, 2022, 02:32:27 PM
Small RP suggestion, in two parts:
  • For single-star systems, it would be nice if the star and body names would not include the "-A" in their designations. It's a small thing, but "Epsilon Eridani II" looks neater than "Epsilon Eridani-A II".
  • The ability to name stars in a multiple-star system independently. The current behavior is a fine default, but sometimes it makes sense to name each star separately especially for races which start in a binary+ system.

That would be nice, we could rename the stars in Alpha Centauri to Rigil Kentaurus and Toliman with this feature.
Title: Re: C# Suggestions
Post by: Migi on February 21, 2022, 05:51:23 PM
A spaceport is needed to build 'space stations' (the type with no armour).

To make this more flavourful, can the spaceport be renamed the space elevator?
Title: Re: C# Suggestions
Post by: Garfunkel on February 23, 2022, 04:29:34 AM
A spaceport is needed to build 'space stations' (the type with no armour).

To make this more flavourful, can the spaceport be renamed the space elevator?
Even better, make it so that once spaceport hits level 5, it becomes space elevator.

Or, alternatively, make space elevator a separate facility that acts as five levels of space sport.
Title: Re: C# Suggestions
Post by: Black on February 23, 2022, 05:18:47 AM
I don't think that spaceports stack anymore.
Title: Re: C# Suggestions
Post by: TMaekler on February 23, 2022, 08:10:17 AM
Thinking about "moveable jump point stabilisers", mostly for RP purposes. The idea is to construct stations that can transfer ships at jump points. Basically manual jump point stabilisers. Depending on their purposes, they can be equipped with RP modules like "Warp Point Communications Relay" (They basically allow ships to communicate with the empire directly through the relay, rather than having to jump to the other system, to deliver messages).

But also functional modules like:
a) Refuel Equipment
b) Maintenance Storage & Facilities
c) Recreation Facilities
etc.

I was wondering if we could get a new module that can act like the jump point stabilisation does, except it is build into a station. Such a ship could move to another jump point, but it would need to stay at a new jump point location for an amount x of days until it can provide the service of stabilising the jump point.

Additionally it would only allow allied ships to pass through, and, it could be destroyed. So new options for war and politics... .
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on February 23, 2022, 08:14:06 AM
Thinking about "moveable jump point stabilisers", mostly for RP purposes. The idea is to construct stations that can transfer ships at jump points. Basically manual jump point stabilisers. Depending on their purposes, they can be equipped with RP modules like "Warp Point Communications Relay" (They basically allow ships to communicate with the empire directly through the relay, rather than having to jump to the other system, to deliver messages).

But also functional modules like:
a) Refuel Equipment
b) Maintenance Storage & Facilities
c) Recreation Facilities
etc.

I was wondering if we could get a new module that can act like the jump point stabilisation does, except it is build into a station. Such a ship could move to another jump point, but it would need to stay at a new jump point location for an amount x of days until it can provide the service of stabilising the jump point.

Additionally it would only allow allied ships to pass through, and, it could be destroyed. So new options for war and politics... .

Most of what you want here is achieved by putting a jump drive on a station and parking it at the jump point.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 23, 2022, 10:14:06 AM
Thinking about "moveable jump point stabilisers", mostly for RP purposes. The idea is to construct stations that can transfer ships at jump points. Basically manual jump point stabilisers. Depending on their purposes, they can be equipped with RP modules like "Warp Point Communications Relay" (They basically allow ships to communicate with the empire directly through the relay, rather than having to jump to the other system, to deliver messages).

But also functional modules like:
a) Refuel Equipment
b) Maintenance Storage & Facilities
c) Recreation Facilities
etc.

I was wondering if we could get a new module that can act like the jump point stabilisation does, except it is build into a station. Such a ship could move to another jump point, but it would need to stay at a new jump point location for an amount x of days until it can provide the service of stabilising the jump point.

Additionally it would only allow allied ships to pass through, and, it could be destroyed. So new options for war and politics... .

Most of what you want here is achieved by putting a jump drive on a station and parking it at the jump point.

I think the only thing that can't be achieved with this is allowing Civilian traffic through the jump point, since they require a stabilized JP to travel through.
Title: Re: C# Suggestions
Post by: Sebmono on February 24, 2022, 10:14:14 AM
I would really love it if civies could build jump capable ships and not require stabilized jump points for inter-system trade/transport. This combined with a "no stabilization" game setting option would be very interesting to play with for me, although I'm guessing that NPRs would have a harder time managing their fleets and empires under this additional constraint.
Title: Re: C# Suggestions
Post by: Borealis4x on February 24, 2022, 11:55:05 AM
Instead of killing off excess populace, exceeding capacity for a planet should cause unrest and slow natural growth down to a trickle, with civilian colony ships naturally using it as a pick-up point to reflect the strong emigration push away from the overcrowded planet.
Title: Re: C# Suggestions
Post by: TMaekler on February 25, 2022, 12:18:22 AM
Thinking about "moveable jump point stabilisers", mostly for RP purposes. The idea is to construct stations that can transfer ships at jump points. Basically manual jump point stabilisers. Depending on their purposes, they can be equipped with RP modules like "Warp Point Communications Relay" (They basically allow ships to communicate with the empire directly through the relay, rather than having to jump to the other system, to deliver messages).

But also functional modules like:
a) Refuel Equipment
b) Maintenance Storage & Facilities
c) Recreation Facilities
etc.

I was wondering if we could get a new module that can act like the jump point stabilisation does, except it is build into a station. Such a ship could move to another jump point, but it would need to stay at a new jump point location for an amount x of days until it can provide the service of stabilising the jump point.

Additionally it would only allow allied ships to pass through, and, it could be destroyed. So new options for war and politics... .

Most of what you want here is achieved by putting a jump drive on a station and parking it at the jump point.

I think the only thing that can't be achieved with this is allowing Civilian traffic through the jump point, since they require a stabilized JP to travel through.
I thought that any station with a jump drive is capable to jump ships of its own kind, i.e. if I put a civilian jump drive in the station it could jump any civilian ship to its max jump size. Same with a military jump drive. So my idea would circumvent having two jump stations (one civilian, one military) on each jump point.

I also didn't want to have stations there which would need to get an overhaul every once and then...

Or did you mean that civilian companies can't use those stations?
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 25, 2022, 09:10:08 AM
Or did you mean that civilian companies can't use those stations?

Yes. Such a station could be used for commercial ships (player-controlled) just fine, but without stabilizing the jump point civilian ships (AI-controlled) would not be able to function for interstellar transport. I think this is a big reason why we pretty rarely see players actually use jump stations - this, and the theoretical downside of stabilized jump points (the enemy can use them too) in practice doesn't matter very much, since NPRs usually have jump ships in their fleets anyways and a stabilized jump point can be defended as well as an unstabilized one, especially with the change to jump shock mechanics in 2.0.
Title: Re: C# Suggestions
Post by: nakorkren on February 27, 2022, 04:03:16 PM
This has come up before, so I don't know that mentioning it again with make it any more likely to happen, but...

I would LOVE to see customizable conditional orders (similar to how we have order templates). This would hugely increase the amount of automation available, but still make it feel like you're engaged in that automation because you have to create your own custom automation, if that makes sense. I understand that fully customizable standing orders is a big ask, as there's a lot of programming and debugging. Would it be possible to just get customization for standing orders that already exist and have numeric values?

As an example of why this is useful, in early game I usually have two survey ships in Sol that have a conditional order to return to refuel when they hit 50% fuel. Given that conditional order, you'd think they should never run out, because they spend half their fuel, then they come home. Except that someone moved home base, i.e. Earth moved on its orbit, and how it takes more than 50% of their fuel to get home, so they routinely run out of fuel. I can't fix this (other than tediously keeping an eye on them), because the conditional orders are all for 50% or LESS in the fuel take, i.e. 40%, 30%, etc. What I need is 60%, or maybe 70%. If the conditional orders were customizable, I could set that ot what ever number works for that particular system/area/situation.
Title: Re: C# Suggestions
Post by: Garfunkel on February 27, 2022, 11:09:19 PM
The idea itself has merit though I doubt its feasilibty, but the fix to your current problem is to have more fuel in your surveyors and/or better fuel efficiency in your engines. A surveyor should never run out of fuel because of orbital mechanics of Earth itself because the distances in inner system are minuscule compared to the outer system and the Oort cloud. Survey ships should always have low-power / high-efficiency engines to enable massive ranges, or you're asking for trouble.
Title: Re: C# Suggestions
Post by: nuclearslurpee on February 28, 2022, 07:34:17 AM
I would LOVE to see customizable conditional orders (similar to how we have order templates). This would hugely increase the amount of automation available, but still make it feel like you're engaged in that automation because you have to create your own custom automation, if that makes sense. I understand that fully customizable standing orders is a big ask, as there's a lot of programming and debugging. Would it be possible to just get customization for standing orders that already exist and have numeric values?

I would not love to see this, however the reason is not because it is a bad suggestion. Rather, if conditional orders are changed so that each one has a user-input number attached, the process of setting up conditional orders especially for multiple ships at once will become even more time-consuming and annoying. It is already a bit of a pain to give several survey ships the same standing orders - survey next five bodies, refuel at 20%, etc. etc.... it would be even more painful if I had to input the numbers every time for each ship.

I think for this kind of thing to work we also need standing order templates, so that once we have the numbers set to satisfaction it takes only one click for each other ship to replicate the orders. Even without this, having such templates would be very useful on their own.
Title: Re: C# Suggestions
Post by: nakorkren on February 28, 2022, 01:03:19 PM
Garfunkel: I came to that conclusion as well, and detuned the engines. I was just spoiled concerning survey ship speed coming off my last game and starting over in a new game.

Nuclearslurpee: I didn't make it clear in my original post, but I was assuming that setting the number would create a new standard order, i.e. we'd be able to edit the standing orders from the standing order list, ad they would stay that way until you edit them again, not have a pop-up each time you try to use one, which as you said would add a LOT of additional clicks to setting up new fleets orders. That is different from templates, which would save a complete set of standing orders, which would also be very nice!
Title: Re: C# Suggestions
Post by: papent on February 28, 2022, 01:05:36 PM
Being able to set default standing orders/conditional order on the class design screen. but i'm pretty sure that would be complex to do as it would involve ships having some notion of fleet orders.
Title: Re: C# Suggestions
Post by: Migi on February 28, 2022, 04:26:26 PM
Being able to set default standing orders/conditional order on the class design screen. but i'm pretty sure that would be complex to do as it would involve ships having some notion of fleet orders.
You could have a button/dropdown that overwrites the fleet's current standing/conditional orders with the s/co from a class within that fleet.
But thinking about it a bit more, that would just be a more complex way of having a set of saved s/co that you can load (like the current order templates).
Title: Re: C# Suggestions
Post by: Garfunkel on February 28, 2022, 05:20:27 PM
I would really love it if civies could build jump capable ships and not require stabilized jump points for inter-system trade/transport. This combined with a "no stabilization" game setting option would be very interesting to play with for me, although I'm guessing that NPRs would have a harder time managing their fleets and empires under this additional constraint.

I would not like this as the current situation allows me to control with 100% accuracy when civilians get access to a system. I know I could use the military restriction button but that is per system-basis. Though I admit that a completely no-stabilized-jump-point game would be interesting.
Title: Re: C# Suggestions
Post by: Black on March 05, 2022, 02:46:57 AM
Could we get a button that would set an individual fire control to not be involved in Fleet Fire at Will command? Some of my ships have specialized launcher and FC to launch various probes and I have to manually disable them every time I use Fleet Fire at Will command.
Title: Re: C# Suggestions
Post by: Scandinavian on March 05, 2022, 06:44:12 AM
I would really love it if civies could build jump capable ships and not require stabilized jump points for inter-system trade/transport. This combined with a "no stabilization" game setting option would be very interesting to play with for me, although I'm guessing that NPRs would have a harder time managing their fleets and empires under this additional constraint.

I would not like this as the current situation allows me to control with 100% accuracy when civilians get access to a system. I know I could use the military restriction button but that is per system-basis. Though I admit that a completely no-stabilized-jump-point game would be interesting.

From the next version you should be able to civilian-restrict individual jump points, no?
Title: Re: C# Suggestions
Post by: Sebmono on March 05, 2022, 08:31:28 AM
I would really love it if civies could build jump capable ships and not require stabilized jump points for inter-system trade/transport. This combined with a "no stabilization" game setting option would be very interesting to play with for me, although I'm guessing that NPRs would have a harder time managing their fleets and empires under this additional constraint.

I would not like this as the current situation allows me to control with 100% accuracy when civilians get access to a system. I know I could use the military restriction button but that is per system-basis. Though I admit that a completely no-stabilized-jump-point game would be interesting.

From the next version you should be able to civilian-restrict individual jump points, no?
I thought so too, but I might be misremembering the change that was being added. As a compromise alternative, maybe if we were able to make versions of civilian ships ourselves which they would then use, then this would.be I'm the hands of the player to control. Although it wouldn't change things for NPRs, so less than optimal.
Title: Re: C# Suggestions
Post by: gpt3 on March 13, 2022, 09:03:00 AM
Would it be possible to have factory-built fighters and space stations use their classes' ship naming theme instead of the default "$CLASS_NAME $NUMBER"?

Right now, if I build a few dozen fighters from my fighter factories and wish to give them roleplay names (e.g. Laura (https://en.battlestarwiki.org/Blackbird)), then I have to either:
Title: Re: C# Suggestions
Post by: Bluebreaker on March 13, 2022, 02:24:18 PM
Would it be possible to have factory-built fighters and space stations use their classes' ship naming theme instead of the default "$CLASS_NAME $NUMBER"?

Right now, if I build a few dozen fighters from my fighter factories and wish to give them roleplay names (e.g. Laura (https://en.battlestarwiki.org/Blackbird)), then I have to either:
  • Manually name them one-by-one.
  • Use the bulk "rename all" tool. However, this also changes the names of existing fighters.
You can uncheck the "Select Random Name from Theme" which almost does what you want when you use "rename all"
Title: Re: C# Suggestions
Post by: nuclearslurpee on March 13, 2022, 04:52:55 PM
Would it be possible to have factory-built fighters and space stations use their classes' ship naming theme instead of the default "$CLASS_NAME $NUMBER"?

Right now, if I build a few dozen fighters from my fighter factories and wish to give them roleplay names (e.g. Laura (https://en.battlestarwiki.org/Blackbird)), then I have to either:
  • Manually name them one-by-one.
  • Use the bulk "rename all" tool. However, this also changes the names of existing fighters.

Seconded!


You can uncheck the "Select Random Name from Theme" which almost does what you want when you use "rename all"

This only works if you want the names in the same order as the name theme, which is a pretty severe restriction - especially since many of the themes have names listed in alphabetical order which looks silly if you don't select at random.
Title: Re: C# Suggestions
Post by: Kamilo on March 14, 2022, 02:15:31 PM
A method to transport minerals from one colony to another would be pretty nice. It could work like the already existing civilian contracts.

The demanded minerals could be set on one colony. This could work like demand x amount of mineral y.
The colony which provides these minerals could be set on supply x amount of mineral y.

The already existing civilian lines will transport the mineral from one colony to another.

Possible problems are maybe negative difference of the minerals on the supplying planet and message like mineral y can't be loaded etc. Through the continuous mining this shouldn't happened if amounts are set correctly. Demanding/supplying the mineral on more than one colony shouldn't be a problem either, or not more than with infrastructure.

What do you think of this new function?
Title: Re: C# Suggestions
Post by: mtm84 on March 14, 2022, 02:34:05 PM
I believe you can already set this up using standing orders and setting mineral limits at colonies, it just requires a little more front end management to set it up.  I don't think Steve would be interested in letting the player automate such a system outright though.
Title: Re: C# Suggestions
Post by: nuclearslurpee on March 14, 2022, 03:00:10 PM
I believe you can already set this up using standing orders and setting mineral limits at colonies, it just requires a little more front end management to set it up.  I don't think Steve would be interested in letting the player automate such a system outright though.

I think what is being requested is a way to have the civilian freighter lines handle this instead of player-built freighters, which wouldn't be unwelcome though maybe since we have mass drivers it is not very necessary?
Title: Re: C# Suggestions
Post by: Droll on March 14, 2022, 03:30:57 PM
I believe you can already set this up using standing orders and setting mineral limits at colonies, it just requires a little more front end management to set it up.  I don't think Steve would be interested in letting the player automate such a system outright though.

I think what is being requested is a way to have the civilian freighter lines handle this instead of player-built freighters, which wouldn't be unwelcome though maybe since we have mass drivers it is not very necessary?

Mass drivers help but what I want is to have the option of having the civilian sector handle the interstellar transportation of minerals and focus the state transports on moving critical military infrastructure.

So IMO it is pretty necessary though my time on this forum has revealed there are plenty who don't agree.
Title: Re: C# Suggestions
Post by: Kamilo on March 14, 2022, 04:03:37 PM
I believe you can already set this up using standing orders and setting mineral limits at colonies, it just requires a little more front end management to set it up.  I don't think Steve would be interested in letting the player automate such a system outright though.

I think what is being requested is a way to have the civilian freighter lines handle this instead of player-built freighters, which wouldn't be unwelcome though maybe since we have mass drivers it is not very necessary?

Mass drivers help but what I want is to have the option of having the civilian sector handle the interstellar transportation of minerals and focus the state transports on moving critical military infrastructure.

So IMO it is pretty necessary though my time on this forum has revealed there are plenty who don't agree.

It is true that mass drivers help with local transport of minerals. Interstellar transport has to done manual (the order has to be set up to be be made kind of automatic). It would be nice to have even though it is fully understandable to not like/want it. In situations where you want to transport minerals from a contested the civilian lines would probably come to its limits, plus the rp aspect of it is respectively important.
Title: Re: C# Suggestions
Post by: Droll on March 14, 2022, 10:21:46 PM
I believe you can already set this up using standing orders and setting mineral limits at colonies, it just requires a little more front end management to set it up.  I don't think Steve would be interested in letting the player automate such a system outright though.

I think what is being requested is a way to have the civilian freighter lines handle this instead of player-built freighters, which wouldn't be unwelcome though maybe since we have mass drivers it is not very necessary?

Mass drivers help but what I want is to have the option of having the civilian sector handle the interstellar transportation of minerals and focus the state transports on moving critical military infrastructure.

So IMO it is pretty necessary though my time on this forum has revealed there are plenty who don't agree.

It is true that mass drivers help with local transport of minerals. Interstellar transport has to done manual (the order has to be set up to be be made kind of automatic). It would be nice to have even though it is fully understandable to not like/want it. In situations where you want to transport minerals from a contested the civilian lines would probably come to its limits, plus the rp aspect of it is respectively important.

Yes it makes sense that civies would only really transport minerals in the event a "core" sector gets established where routes are all well defended and secure. That's what's nice about it as it lets the player focus on the areas that really need attention even in a large game.
Title: Re: C# Suggestions
Post by: mtm84 on March 15, 2022, 02:51:44 AM
I fear I did not fully understand what was being asked, and that's my fault. I think it would be a good addition if we had a mechanism for telling Civilian ships to move minerals around in the same manner that we can ask for installations to be moved.  This still limits Civilians to built gates but that's nothing new and a reasonable trade off for "free" transport.  Might not be exactly fully automated but would be inline with a currently existing mechanism.
Title: Re: C# Suggestions
Post by: unkfester on March 15, 2022, 04:36:55 AM
 I think it would be a good addition if we had a mechanism for telling Civilian ships to move minerals around in the same manner that we can ask for installations to be moved.  I like this idea
Title: Re: C# Suggestions
Post by: skoormit on March 15, 2022, 08:12:51 AM
I often give fleet orders that consume more than 80% of a fleet's fuel before refueling.
This causes a lot of not-useful Low Fuel messages in the Events window.
I can suppress those messages for all ships of a given design by marking that design as a Tanker and specifying 0 minimum fuel.
But that's overkill. I don't want to never get those messages for a given design; I just don't want to get those messages when I have knowingly given orders that will cause a fleet to drop low on fuel before refueling.

So, suggestion: A per-fleet option to disable the Low Fuel event.

This seems like a small amount of coding (to someone who hasn't actually seen the code) for a non-trivial QOL improvement.
One new fleet property bound to one new checkbox bound to one new DB field.
One new condition when checking for the Low Fuel event.
One new statement when completing a Refuel order.




Title: Re: C# Suggestions
Post by: nuclearslurpee on March 16, 2022, 09:28:14 PM
I am once again asking for your financial support Steve to remove the caps on numbers of starting installations at race creation.

Mainly because I'm really just tired of playing high population/high starting tech games where the NPRs are not any threat because they can only develop up to maybe Ion Drive tech, if that, because they are capped at 50 labs no matter what their starting population is (or for that matter the difficulty level - if I want a difficult game, shouldn't the difficulty level...work?). Frankly I cannot see any reason for a cap on the numbers of any installation which is proportional to population - minimums perhaps, but not caps.

Please, Steve, the NPRs need the help. Won't someone think of the poor NPRs?  :P
Title: Re: C# Suggestions
Post by: Vandermeer on March 18, 2022, 10:55:44 AM
I am once again asking for your financial support Steve to remove the caps on numbers of starting installations at race creation.
[...]
Please, Steve, the NPRs need the help. Won't someone think of the poor NPRs?  :P
(https://abload.de/img/external-content.duckluj7r.jpg)

-----
I also have one suggestion regarding civilian tech advance. Whenever you reach a new age of engine tech, civilians seem to adapt it pretty rapidly. Given that the player needs additional time to both research the new tech as engines, and then build and train ships with it, I don't quite like that all the pioneer work is suddenly falling into the hands of citizen science.
In short, I would just like to see like an era of 'secret military tech' where your government and navy actually leads while the economy catches up with the solar panels and eye surgery lasers etc. some (potentially many) years later. Just an RP thing I guess.
Title: Re: C# Suggestions
Post by: Steve Walmsley on March 18, 2022, 03:03:52 PM
I am once again asking for your financial support Steve to remove the caps on numbers of starting installations at race creation.

Mainly because I'm really just tired of playing high population/high starting tech games where the NPRs are not any threat because they can only develop up to maybe Ion Drive tech, if that, because they are capped at 50 labs no matter what their starting population is (or for that matter the difficulty level - if I want a difficult game, shouldn't the difficulty level...work?). Frankly I cannot see any reason for a cap on the numbers of any installation which is proportional to population - minimums perhaps, but not caps.

Please, Steve, the NPRs need the help. Won't someone think of the poor NPRs?  :P

The 50 RL limit is intended to avoid making research too fast for a player in the early game, but can be overridden. I've removed the limit for NPRs in v2.0.
Title: Re: C# Suggestions
Post by: Steve Walmsley on March 18, 2022, 03:20:28 PM
Would it be possible to have factory-built fighters and space stations use their classes' ship naming theme instead of the default "$CLASS_NAME $NUMBER"?

Right now, if I build a few dozen fighters from my fighter factories and wish to give them roleplay names (e.g. Laura (https://en.battlestarwiki.org/Blackbird)), then I have to either:
  • Manually name them one-by-one.
  • Use the bulk "rename all" tool. However, this also changes the names of existing fighters.

Currently, the name for a ship is chosen at the point you decide to build it and that naming step doesn't exist for fighters or space stations. Therefore, when you build a fighter using fighter factories or a space station using construction factories in v2.0, it will run the same code that generates a suggested name for a new ship in the Shipyard tab. In other words, v2.0 will use the class theme for naming fighters and space stations.
Title: Re: C# Suggestions
Post by: Steve Walmsley on March 18, 2022, 03:27:25 PM
Allow instant moving a Ground Force Formation from one body to another via drag and drop if SM mode is active:
( Disable this check )

(https://i.postimg.cc/2SjBMv1n/image.png)

Added for v2.0
Title: Re: C# Suggestions
Post by: Steve Walmsley on March 18, 2022, 03:54:39 PM
Small RP suggestion, in two parts:
  • For single-star systems, it would be nice if the star and body names would not include the "-A" in their designations. It's a small thing, but "Epsilon Eridani II" looks neater than "Epsilon Eridani-A II".
  • The ability to name stars in a multiple-star system independently. The current behavior is a fine default, but sometimes it makes sense to name each star separately especially for races which start in a binary+ system.

I've added part 1. The "-A" annoyed me too :)

Part 2 involves messing with the DB so I will do that at some point in the future. I am trying to finish v2.0, so I am only tackling a few minor changes for now.
Title: Re: C# Suggestions
Post by: Steve Walmsley on March 18, 2022, 03:57:55 PM
Could you make it so that "hide fleets in orbit" only hides fleets that have no orders?
That way ships which are doing a survey don't disappear while they are in orbit, but busy.

'Hide Fleets' only hides fleets with no ships, so they should have no orders anyway.
Title: Re: C# Suggestions
Post by: Migi on March 19, 2022, 11:44:50 AM
Could you make it so that "hide fleets in orbit" only hides fleets that have no orders?
That way ships which are doing a survey don't disappear while they are in orbit, but busy.

'Hide Fleets' only hides fleets with no ships, so they should have no orders anyway.
I think you misunderstood my post. I'm talking about the setting in the main window, display tab.

At the moment when "hide fleets in orbit" is active, you can see geosurvey ships when they move between bodies, but they disappear when they arrive and start work. This means you can have a system of busy ships but not see any of them, until you change the setting. This causes me to change the setting quite frequently.

I thought the easiest way of resolving this was adding an exception for fleets which have orders.
But having thought a little bit more, it would also affect loading/unloading ships as well, so maybe it would be better as an additional option rather than changing the existing setting.
Title: Re: C# Suggestions
Post by: Steve Walmsley on March 19, 2022, 12:01:32 PM
Could you make it so that "hide fleets in orbit" only hides fleets that have no orders?
That way ships which are doing a survey don't disappear while they are in orbit, but busy.

'Hide Fleets' only hides fleets with no ships, so they should have no orders anyway.
I think you misunderstood my post. I'm talking about the setting in the main window, display tab.

At the moment when "hide fleets in orbit" is active, you can see geosurvey ships when they move between bodies, but they disappear when they arrive and start work. This means you can have a system of busy ships but not see any of them, until you change the setting. This causes me to change the setting quite frequently.

I thought the easiest way of resolving this was adding an exception for fleets which have orders.
But having thought a little bit more, it would also affect loading/unloading ships as well, so maybe it would be better as an additional option rather than changing the existing setting.

You're correct. I thought that checkbox hid empty fleets but it really does hide everything in orbit. It probably makes sense to hide only inactive fleets, but I'll give it some thought first.
Title: Re: C# Suggestions
Post by: Aloriel on March 19, 2022, 07:17:18 PM
Back in VB6, we had the ability to give out titles to our commanders. I'd like to see a return of that for RP reasons! If my government simulation elects someone as Secretary-General of the UN, I should be able to mark that in game somehow :)
Title: Re: C# Suggestions
Post by: nakorkren on March 19, 2022, 11:16:25 PM
Please consider changing Formation Templates to be populated with Unit Series, rather than specific Units. That way new formations are always built with the latest and greatest Unit in the series. Right now, if you research a new Unit (e.g. because your armor tech increased) you can't start incorporating them into your Formations (by updating the Formation Template) until you are done building any Formations presently under construction.
Title: Re: C# Suggestions
Post by: papent on March 20, 2022, 02:23:05 AM
Please consider changing Formation Templates to be populated with Unit Series, rather than specific Units. That way new formations are always built with the latest and greatest Unit in the series. Right now, if you research a new Unit (e.g. because your armor tech increased) you can't start incorporating them into your Formations (by updating the Formation Template) until you are done building any Formations presently under construction.

why not both or better yet:
Title: Re: C# Suggestions
Post by: Platys51 on March 21, 2022, 11:03:55 AM
With the talk of deep space populations and mobile repair yards, some work around pops will have to be done anyway, I would like to ask for little automation around future repair yards and mining ships.

Mainly for mobile repair yards to check for materials and if none are present, check for them in its own cargo hold before throwing out error, perhaps dumping required amount if resources do need to be on the colony and for mining ship, once the source is mined out, collecting stuff left behind if free cargo space is available.

Automating mining ships completely would be the best and would probably see many more ppl use them too, simply making new colony on closest viable object with minerals, moving there and collecting everything once fully mined out, deleting colony if it's left empty and moving on.

Would be especially nice thanks to new deep-space cargo transfer as mining ships could roam mineral-rich systems for decades without bothering players with undue amounts of micro for little gain.
Title: Re: C# Suggestions
Post by: ropedog on March 25, 2022, 01:12:09 PM
Quote from: TMaekler link=topic=10640. msg132606#msg132606 date=1589268935
A special warning message when a story character dies.

Since gameplay is so much quicker in C# Aurora and since commander health is not differenciated from commander death, I quite often happen to miss when my planetary governors die and leave important positions vacant - until I happen to stumble upon it in the planetary display. . .  .

So it would be nice to get a separate warning message for story characters when they die off.  That way I can ensure "immediate new elections" :-)

Yes please!  I would like to see that the auto turns are interrupted when an important character dies and leaves a vacant position.   I think this is what checking "Story Character" should do, instead of making them immortal - a bit immersion breaking.
Title: Re: C# Suggestions
Post by: Droll on March 25, 2022, 02:26:36 PM
Quote from: TMaekler link=topic=10640. msg132606#msg132606 date=1589268935
A special warning message when a story character dies.

Since gameplay is so much quicker in C# Aurora and since commander health is not differenciated from commander death, I quite often happen to miss when my planetary governors die and leave important positions vacant - until I happen to stumble upon it in the planetary display. . .  .

So it would be nice to get a separate warning message for story characters when they die off.  That way I can ensure "immediate new elections" :-)

Yes please!  I would like to see that the auto turns are interrupted when an important character dies and leaves a vacant position.   I think this is what checking "Story Character" should do, instead of making them immortal - a bit immersion breaking.

Nono please keep the immortality thing I actually like that and it makes late-game flag officer management much less of a nightmare for me.

However important character death should certainly be marked. I think naval admin commanders, academy commandants and planetary governors on planets marked as "important" by the player should throw interrupts and generate an "important commander death" event.
Title: Re: C# Suggestions
Post by: Aloriel on March 25, 2022, 06:49:05 PM
I would like to see a separation between messages when a character gets a disease and a character dies. If they die, I have to replace them. If they get a disease, they might live on for years.

I would also like to see the ability to suppress messages about officers dying when they are unassigned, as I often have a LOT more officers than I need.
Title: Re: C# Suggestions
Post by: skoormit on March 26, 2022, 06:18:16 AM
Currently, if I have a tanker Fleet A and a target Fleet B that needs fuel, I can only give an order to Fleet B to take fuel from Fleet A.

I would like to be able to give an order to Fleet A to give fuel to Fleet B.

This would allow me to completely automate the topping-up of my numerous fuel stations, saving a lot of time and clicks.

Title: Re: C# Suggestions
Post by: Pury on March 27, 2022, 03:11:42 PM
I think it would be cool if we could gather some research points/improved versions of particular weapon systems from using weapon systems in combat. It would simulate first practical usage of weapons, witch would contribute to advancing research of particular technology or in providing better designed equipment.

As I recall, there are already improved versions of ground combat units (although not tied to actual combat of said units IIRC) With new optional research rules that significantly slow down research improved spaceships components might see some use, as completely new technologies will take much more time to develop. (bonuses might also include reduced cost of production) We could also improve the used module itself, but this change would only accrue after overhaul of the ship in order to not just improve modules from ship in the middle of the battle and/or far from friendly planets.

It might be interesting to both include the new improved versions of components, and some limited RP for technologies used in combat. for example 200% of RP cost of the used module would be the max RP bonus for related technology.
Title: Re: C# Suggestions
Post by: alex_brunius on March 28, 2022, 04:41:25 AM
(bonuses might also include reduced cost of production)

I think it would make more sense to reduce cost of production based on how many of certain modules that has been produced, rather than if they were used or not in combat.

Some sort of gearing up bonus is used in alot of other games ( where fighter #200, tank #500 or missile #2000 becomes much cheaper and faster to produce than the first prototype ). This provides a very interesting tradeoff if you want to swap to new tech ASAP but lose production inertia, or keep building slightly out of date equipment in massive numbers instead.

Spaceships already has this partially built in thanks to retooling mechanics ( but it's all frontloaded as an extra cost before production can start at all instead ).
Title: Re: C# Suggestions
Post by: Sebmono on March 28, 2022, 09:00:37 AM
RP suggestion: optional ability to assign parts/tech Company Names to individual scientists and then any equipment that scientist completes research on is automatically given that company name.

Would use the same functional bits as the 'Company Name' but in the part design form but removes chance of forgetting to name something and makes it easier to maintain thematic continuity, especially with the new limited research option encouraging use of more scientists, can make sure that e.g. all my engines are produced by the same group of Propulsion scientists and therefore the same set of company names.
Title: Re: C# Suggestions
Post by: nuclearslurpee on March 28, 2022, 09:16:32 AM
removes chance of forgetting to name something

FYI if you don't know, you can rename a component to have the desired company name if you forget to add it during the design step. No need to ask me how I know this.

This aside, I would at least appreciate the ability to save and re-use company names, as once I have a couple dozen it can be hard to keep them all straight without an external file or Google sheet.
Title: Re: C# Suggestions
Post by: cdrtwohy on March 28, 2022, 09:22:42 AM
Can we have titles back? im currently using medals to signify peerage in my empire but would totally like something else, maybe something a little less manual too? Maybe make a title system kinda like the Naval admin system not sure just spitballing here.
Title: Re: C# Suggestions
Post by: Sebmono on March 28, 2022, 06:45:10 PM
removes chance of forgetting to name something

FYI if you don't know, you can rename a component to have the desired company name if you forget to add it during the design step. No need to ask me how I know this.

This aside, I would at least appreciate the ability to save and re-use company names, as once I have a couple dozen it can be hard to keep them all straight without an external file or Google sheet.

Yeah that's a good reminder, in my case though I probably should've described it as "too lazy to remember or go correct"  ;D
Title: Re: C# Suggestions
Post by: alex_brunius on March 29, 2022, 02:04:36 AM
RP suggestion: optional ability to assign parts/tech Company Names to individual scientists and then any equipment that scientist completes research on is automatically given that company name.
Id prefer to have the company name saved to a specific component type in the design dropdown ( all engines are named with company name X, all active sensors Y, all launchers Z and so on )
Title: Re: C# Suggestions
Post by: wedgebert on March 29, 2022, 08:22:25 AM
What I thought would be interesting is if you can either configure some companies ahead of time or the game would spawn them like civilian shipping lanes.

Then when you go to design a tech, you have the option of sending out an RFP instead of directly researching it. After a certain amount of time, some of those companies would return with their version of the component, but each with slight variations. Company X's engine might get a +2% fuel efficiency over your specs, but cost 3% more resources. Company Y might provide a little extra engine power at the cost of being a little more bulky.

As time goes on, those same companies could produce civilian designs (where applicable) that the shipping lines would use in their ships. And maybe even automatically design newer models as compete for business. So after a few years of use, maybe they develop a Mk2 engine that get's an additional 0.05% fuel efficiency or whatnot.

None of the bonuses or maluses would be very big, but it'd be a nice little bit of variety. The corporations could have finances like shipping lanes, pay taxes based on sales to those shipping lanes, and have a small wealth cost when you use a design in your ship. Maybe they could even build the components for you at a higher cost, freeing your industry up for other things.

Plus it'd add a nice RP bit in. Especially if corporations had headquarters/facilities on other planets/moons/etc where they'd demand their own PPV and be possible targets for enemies/pirates.

Also, you'd get some minor choices in terms of things like "Do I bring these ships in on their next refit and replace their sensor arrays with the newest model for an extra few thousand km of range?"
Title: Re: C# Suggestions
Post by: Sebmono on March 29, 2022, 09:12:51 AM
I really like this idea, although imagine it would be complex to implement and would require a rebalancing of all research since we'd essentially be relegating our Scientists to only theoretical work and farming out the application research. I do love the idea of making something like R&D less deterministic and feel like this could create good stories.

I could even see it being fun to extend a bit into ship construction itself, where everytime a ship is built there is a chance for "Quirks" to occur, just small things like 1% more fuel efficient or 'fearsome' which would increase policing points more than usual, etc.
Title: Re: C# Suggestions
Post by: KriegsMeister on March 29, 2022, 08:52:38 PM
Perhaps a new "Name List" category for component companies like ships, systems and officers. Could maybe have one for shipyards as well thats or may not overlap
Title: Re: C# Suggestions
Post by: wedgebert on March 29, 2022, 09:34:03 PM
I really like this idea, although imagine it would be complex to implement and would require a rebalancing of all research since we'd essentially be relegating our Scientists to only theoretical work and farming out the application research. I do love the idea of making something like R&D less deterministic and feel like this could create good stories.


I suppose you could always do the research yourself, maybe even with the same modifiers, but you'd be stuck with what you got. That way you could RP a communist or other centrally planned economy where the government is doing all the work. The advantage of doing it yourself would be not having to pay the extra wealth cost to buy/license it from the corporations.

Quote

I could even see it being fun to extend a bit into ship construction itself, where everytime a ship is built there is a chance for "Quirks" to occur, just small things like 1% more fuel efficient or 'fearsome' which would increase policing points more than usual, etc.

Careful suggesting ship quirks. You might trigger some people's (like me) disappointing memories of Sword of the Stars 2
Title: Re: C# Suggestions
Post by: Garfunkel on March 30, 2022, 07:33:47 AM
I'm sorry but ship quirks are a terrible idea. I know it's an extremely popular trope of both naval fiction and sci-fi that ships develop quirks over time but for a strategy game it's a really bad feature. I don't want one DD to be 1% faster or one BB to consume 1% more fuel for no reason. It's a bit of good fluffy fun for a story focusing on a single ship, but annoying for a story focusing on an empire with dozens or hundreds of ships.

The saving and automatic re-using of companies is a good idea and having them to the applied research can work as well, as long as it is optional - as you said, some players will RP different types of governments and races, where outsourcing component development would not fit.
Title: Re: C# Suggestions
Post by: Drakale on March 30, 2022, 09:02:01 AM
I think quirk could work if they are applied to a whole class, but this would require a whole new mechanics where a ship need to be researched/engineered after the initial design is completed. Rule the waves has a system that works kinda like that and I find it interesting. When you get a quirk that is unsuitable you can always call for a redesign of the class. I agree that a per-ship quirk system is terrible.
Title: Re: C# Suggestions
Post by: wedgebert on March 30, 2022, 09:17:13 AM
At least in SotS2, it wasn't that individual ships developed quirks, it was the design itself worked better (or sometimes worse) than anticipated. However, being a 4X game, those quirks were a lot more powerful and drew from a fixed list. Less 1% faster and more and more +25% range with ballistic weapons or -10% turn speed and thrust speed.

I agree though that ships themselves probably shouldn't have those kinds of attributes. But I would think that a related thing would be possible, that of ship reputations.

If a ship either did well in a particular battle, survived overwhelming odds to escape, or even sacrificed itself to save a civilian fleet, that ship could gain a reputation and gain a small crew morale bonus because that crew is serving the THE HMS Victory which is a prestigious posting.

You could even go as far as something like from the Honor Harrington series where these ships have their honors passed down to the next ship such that there's always an HMS Nike in service, so even 300 years later, it's still THE battlecruiser everyone wants to serve on. But to do that, you have to decommission the first ship and transfer its name and honors to the next.

Now to make the code simple, maybe just let the player decide which ships have these reputations. I'd hate to try to figure out what counts as a heroic sacrifice or anything. Just limit the player the number of distinguished ships the player can have before some sort of penalty is applied. After all, if all ships are special, then none of them are.
Title: Re: C# Suggestions
Post by: Migi on March 30, 2022, 01:14:51 PM
At least in SotS2, it wasn't that individual ships developed quirks, it was the design itself worked better (or sometimes worse) than anticipated. However, being a 4X game, those quirks were a lot more powerful and drew from a fixed list. Less 1% faster and more and more +25% range with ballistic weapons or -10% turn speed and thrust speed.
I assume this was added because the devs wanted to make ship design less predictable and harder to converge on a single powerful design. It echoes the semi-randomised tech tree. The problem is that it compounds unpredictability and punishes the player for bad luck.

Now to make the code simple, maybe just let the player decide which ships have these reputations.
Then it's a case of "player applies small bonus to ship (or ship class)" which is frankly not an interesting game mechanic.
You could apply it via conditions/milestones like medals, but that's still not very interesting.

In any case balance is still an issue, it's very easy to be too large and overpowering, or too small to be interesting.
None of the proposals acknowledge the existing systems of commander bonuses, crew training and fleet training, so it just becomes an extra thing bolted on top.

I'm not convinced that Aurora has any business trying to be unpredictable via 'quirks'. Most of Aurora is deterministic, you can calculate the exact missile hit chance if you know 3 parameters, the missile speed, MR, and target speed.
Title: Re: C# Suggestions
Post by: Droll on March 30, 2022, 01:18:38 PM
At least in SotS2, it wasn't that individual ships developed quirks, it was the design itself worked better (or sometimes worse) than anticipated. However, being a 4X game, those quirks were a lot more powerful and drew from a fixed list. Less 1% faster and more and more +25% range with ballistic weapons or -10% turn speed and thrust speed.
I assume this was added because the devs wanted to make ship design less predictable and harder to converge on a single powerful design. It echoes the semi-randomised tech tree. The problem is that it compounds unpredictability and punishes the player for bad luck.

Now to make the code simple, maybe just let the player decide which ships have these reputations.
Then it's a case of "player applies small bonus to ship (or ship class)" which is frankly not an interesting game mechanic.
You could apply it via conditions/milestones like medals, but that's still not very interesting.

In any case balance is still an issue, it's very easy to be too large and overpowering, or too small to be interesting.
None of the proposals acknowledge the existing systems of commander bonuses, crew training and fleet training, so it just becomes an extra thing bolted on top.

I'm not convinced that Aurora has any business trying to be unpredictable via 'quirks'. Most of Aurora is deterministic, you can calculate the exact missile hit chance if you know 3 parameters, the missile speed, MR, and target speed.

I think having ships be differentiated in an emergent way through their history is a much better way. We kind of have that through the way the game tracks history.

However, it might be a cool idea to be able to award medals to ships themselves, like the USN service stars or whatever they're called.
Title: Re: C# Suggestions
Post by: wedgebert on March 30, 2022, 02:04:11 PM
Then it's a case of "player applies small bonus to ship (or ship class)" which is frankly not an interesting game mechanic.
You could apply it via conditions/milestones like medals, but that's still not very interesting.

In any case balance is still an issue, it's very easy to be too large and overpowering, or too small to be interesting.
None of the proposals acknowledge the existing systems of commander bonuses, crew training and fleet training, so it just becomes an extra thing bolted on top.

I'm not convinced that Aurora has any business trying to be unpredictable via 'quirks'. Most of Aurora is deterministic, you can calculate the exact missile hit chance if you know 3 parameters, the missile speed, MR, and target speed.

Except Aurora markets itself as a story generator first and 4X second. That's why we have fluff like commander medals or political reliability. Neither aids the player in running their empire, they're there to help with roleplaying.

Yeah, I'm talking about adding small bonuses that would probably go unnoticed in the grand scheme of things, but they're all meant as a way to make the narrative aspect stronger. Or in the case of the civilian corporation designing components with minor variations, adding a bit more flavor to the world.

Giving an individual ship a 5% morale bonus (or even ground formations, picture a well known formation like the 101st Airborne Division compared to the lesser known 82nd) isn't going to change much. Or maybe it's a 5% crew training bonus to reflect that only the best crew members get assigned to that ship. What you have is a ship that's just a little more likely to survive. It's not much, but it can help the player get a little more attached beyond just saying "I like that ship best, so I'll favor it".

It's more interesting to the player to wonder if they lost their storied HMS Nike when it was unable to escape after an engine malfunction in enemy territory when you purposely used the Astro-Yugo Mk3 Ion Engine because it gave 3% extra power but had a 2% higher chance to break. Was it just bad luck? Or would a different manufacturer's engine have not broken down and the Nike would have escaped with the rest of its squadron?
Title: Re: C# Suggestions
Post by: Kamilo on March 31, 2022, 01:18:13 AM
It would be helpful if it were possible to limit the number of the population. Currently, it is possible for a planet that serves as a source of colonists to go down to 0 population. However, if it were possible to specify that a colonist limit of, say, 25 million "must" remain on the colony, then only so many colonists could be transported away until the 25 million was reached. The same applies to the destination of the colonists. It could be specified that, for example, 100 million colonists should be transported to a colony.
Title: Re: C# Suggestions
Post by: Garfunkel on March 31, 2022, 04:19:27 AM
It would be helpful if it were possible to limit the number of the population. Currently, it is possible for a planet that serves as a source of colonists to go down to 0 population. However, if it were possible to specify that a colonist limit of, say, 25 million "must" remain on the colony, then only so many colonists could be transported away until the 25 million was reached. The same applies to the destination of the colonists. It could be specified that, for example, 100 million colonists should be transported to a colony.
These would be good options to have. I once accidentally almost emptied Earth thanks to super active civilian shipping.
Title: Re: C# Suggestions
Post by: Kiero on March 31, 2022, 05:56:14 AM
In Ground Forces -> Unit Series tab. Ability to hide obsolete units.
Title: Re: C# Suggestions
Post by: Droll on March 31, 2022, 09:18:55 AM
In Ground Forces -> Unit Series tab. Ability to hide obsolete units.

I read this as absolute units instead for some reason and was somewhat confused for a moment.
Title: Re: C# Suggestions
Post by: nuclearslurpee on March 31, 2022, 10:21:13 AM
In Ground Forces -> Unit Series tab. Ability to hide obsolete units.

This would rather defeat the purpose of the unit series tab, since the whole idea is that you can use it to replace your obsolete units with newer ones more easily (though still not super easily). I can't think of any case where I would want to hide obsolete units on the series tab.
Title: Re: C# Suggestions
Post by: papent on March 31, 2022, 11:45:16 AM
In Ground Forces -> Unit Series tab. Ability to hide obsolete units.

This would rather defeat the purpose of the unit series tab, since the whole idea is that you can use it to replace your obsolete units with newer ones more easily (though still not super easily). I can't think of any case where I would want to hide obsolete units on the series tab.

You are on your tenth tank design and would like to hide the p previous 8 designs, just like in the ship designer.
Title: Re: C# Suggestions
Post by: nuclearslurpee on March 31, 2022, 12:07:24 PM
In Ground Forces -> Unit Series tab. Ability to hide obsolete units.

This would rather defeat the purpose of the unit series tab, since the whole idea is that you can use it to replace your obsolete units with newer ones more easily (though still not super easily). I can't think of any case where I would want to hide obsolete units on the series tab.

You are on your tenth tank design and would like to hide the p previous 8 designs, just like in the ship designer.

I reiterate - why?

In the series tab, all of the series are collapsed by default. Unlike the formations tab (which does hide obsolete units), you don't ever need to view or interact with the older versions of your units - just drag and drop the new ones into the corresponding series and move on with your day. The only reason to actually expand a specific unit series is to see what older units are/were in it - which, as I said, would be rather defeated if you hid all the obsolete units.

Unless people are somehow trying to use the unit series to organize their ground unit classes? Which is weird and not the intended use but okay I guess.
Title: Re: C# Suggestions
Post by: nakorkren on April 02, 2022, 01:16:18 AM
Rather than set demand and supply, set a target qty in a field next to each installation type on that colony, with a check box to turn that target on or off. If the target is on, and you have more than the target, it is treated as available supply. If you have less, it is treated as demand. If you turn the target off, you have no demand or supply for that type on that colony, regardless of the number filled into the target field.

In addition to requiring less clicks/time to set up supply and demand, it resolves any issues with accidental oversupply as sometimes happens now when multiple ships try to bring in supplies, or you are simultaneously using civ shipping and your own ships to bring installations to a colony.
Title: Re: C# Suggestions
Post by: Vandermeer on April 02, 2022, 06:28:00 AM
I would like if armor weight rounded better. Currently it seems to detail to at least 4 digits after the zero, while the smallest module the player can build is a minimum size reactor, which is 0.01 (=0.5t). This means that you basically always get weird total sizes for your ships, like 179.998, which you can't perfect. On larger designs it can be overlooked, because the small fraction of total mass usually isn't enough to impact the final speed, but once you create fighters, you will see you can never actually get to a round number.(the issue is generally more prominent the faster ship, but small size dominates in causing this)
Example here:
(https://i.ibb.co/9hNhqB6/20950810-A-new-Eurofighter-modell-enters-production.jpg)
Adding up the sizes, you'd get to 7.99, which means another "Emergency Exhaust Vent" (=0.5t reactor) should make it exactly 8. However, the armor hides 0.0033 mass behind invisible digits, hence the mass in the upper right corner of 7.9933. If I were to add said reacter, it would overshoot to 401t and have less than 15kps speed, so I cannot actually get to exactly 15kps.
Sad, because the range is already perfectly 4b, and all other ships and missiles in that fleet fly perfect round numbers.

Of course this is only an OCD problem, but VB6 always let us indulge in such sparkle finish fantasies. Reducing the armor accuracy to 0.5t as a minimum grid would instantly absolve this while I think not really taking anything away from design efficiency. On the other hand, maybe personal components could be of down to 0.0001 size, although having 5kg components seems kind of ridiculous.(can I now not only add a kitchen, but also detail it down to the individual coffee machines?)
Title: Re: C# Suggestions
Post by: xenoscepter on April 02, 2022, 11:02:54 AM
~snip snip~
Reducing the armor accuracy to 0.5t as a minimum grid would instantly absolve this while I think not really taking anything away from design efficiency. On the other hand, maybe personal components could be of down to 0.0001 size, although having 5kg components seems kind of ridiculous.(can I now not only add a kitchen, but also detail it down to the individual coffee machines?)

 --- What if instead of this there was just a button on the Class Design or something that let you force the game to round up to the nearest ton? Anything smaller isn't modeled at the Shipyard level so even rounding to a half ton loses you that infinitesimal amount of production. Ergo, rounding up to the nearest full ton let's you have the sparkle finish AND not "waste" production.
Title: Re: C# Suggestions
Post by: Vandermeer on April 02, 2022, 01:38:15 PM
--- What if instead of this there was just a button on the Class Design or something that let you force the game to round up to the nearest ton? Anything smaller isn't modeled at the Shipyard level so even rounding to a half ton loses you that infinitesimal amount of production. Ergo, rounding up to the nearest full ton let's you have the sparkle finish AND not "waste" production.
Whatever solution lets me have my round speed numbers, I will take it.
Title: Re: C# Suggestions
Post by: Density on April 03, 2022, 08:12:04 AM
Rather than set demand and supply, set a target qty in a field next to each installation type on that colony, with a check box to turn that target on or off. If the target is on, and you have more than the target, it is treated as available supply. If you have less, it is treated as demand. If you turn the target off, you have no demand or supply for that type on that colony, regardless of the number filled into the target field.

In addition to requiring less clicks/time to set up supply and demand, it resolves any issues with accidental oversupply as sometimes happens now when multiple ships try to bring in supplies, or you are simultaneously using civ shipping and your own ships to bring installations to a colony.
From my point of view, this suggestion would make keeping track of what I expect the civs to move harder. Right now, I can set up supply and demand orders for equal amounts (and if it goes wrong, I know why). If this were implemented, any time the civs are moving things in a way I didn't expect, I'd have to go through all my colonies to see where the target numbers are wrong or if a target is on/off when it's supposed to be the other. I expect the way I would use this system would be to usually have everything off, and only turn specifics on at source and destination colonies in order to replicate the current system.

If the impetus of this suggestion is to fix the accidental oversupply problem, then I appreciate the effort to make the game better. However,
http://aurora2.pentarch.org/index.php?topic=12523.msg151550#msg151550 (http://aurora2.pentarch.org/index.php?topic=12523.msg151550#msg151550)
Title: Re: C# Suggestions
Post by: Migi on April 03, 2022, 02:42:46 PM
Wealth bug

I've been running a (relatively) longer campaign and found a ruin and began exploiting it. However I noticed that the wealth didn't seem to reflect the gains from the ruins. It also made me remember that the wealth recovered from scrapped ships and components were strange as well, and that my reported annual wealth gains didn't seem to be fully reflected on my wealth balance. I don't remember ever reading a bug report about it (though I might have missed it). So I started a new game in an unmodded DB to check for it. Mostly default settings (no NPR), added a ruin to Earth, SM-built a Xeno brigade and a number of Construction brigades.

In C# there was a change for the wealth balance to be limited to double annual wealth (http://aurora2.pentarch.org/index.php?topic=8495.msg111163#msg111163). It looks like the ruin is allowing you to go over the limit (which is 37836, according to your annual wealth of 18918), but then being corrected on the next tick.

Based on this exchange in the bugs thread, can you change wealth rewards from ruins?

I think it would be easiest to remove the wealth reward, and instead have a chance of getting some financial centres.

Alternatively, if wealth is 'full' when the reward is triggered, it runs a check to found or expand a CMC. This represents the wealth being fed back into the civilian economy triggering an expansion in civilian activity.

(I'm not personally enamoured of CMCs, but I thought this was a good way to provide a concrete reward and avoid doing weird things like releasing the wealth over a long period)
Title: Re: C# Suggestions
Post by: alex_brunius on April 04, 2022, 01:50:56 AM
In C# there was a change for the wealth balance to be limited to double annual wealth (http://aurora2.pentarch.org/index.php?topic=8495.msg111163#msg111163). It looks like the ruin is allowing you to go over the limit (which is 37836, according to your annual wealth of 18918), but then being corrected on the next tick.

Based on this exchange in the bugs thread, can you change wealth rewards from ruins?

I think it would be easiest to remove the wealth reward, and instead have a chance of getting some financial centres.

Alternatively, if wealth is 'full' when the reward is triggered, it runs a check to found or expand a CMC. This represents the wealth being fed back into the civilian economy triggering an expansion in civilian activity.

(I'm not personally enamoured of CMCs, but I thought this was a good way to provide a concrete reward and avoid doing weird things like releasing the wealth over a long period)

Or just remove the Wealth cap as Steve himself suggested after doing a few other changes down the line?

http://aurora2.pentarch.org/index.php?topic=8495.msg112448#msg112448

Quote
4) The planned wealth reserve cap can be removed.
Title: Re: C# Suggestions
Post by: Migi on April 04, 2022, 01:35:56 PM
Or just remove the Wealth cap as Steve himself suggested after doing a few other changes down the line?
That's certainly an option, although I'm not sure that this situation is a strong argument on its own to change the system.



(new topic)
I've been thinking a bit about ground combat due to the recent discussion in the 12 Colonies thread.

I think part of the issue comes from the naming system.
For the frontline, you have a binary option of attack and defence. Within this context, I don't think it's unreasonable for people to expect that defence means the unit is passive until it gets attacked, and does not seek out enemies to engage.
However, as repeatedly noted, units in frontline defence will seek out and attack the enemy, indeed you can wage a whole war in this position.
Therefore it might make sense to simply rename those positions. I'm pretty bad at thinking of names, but frontline defence could become "limited offensive", "cautious offence", "offensive - trench warfare" or something better that someone else comes up with.
Frontline offence could become "all-out offensive", "blitz", "manoeuvrer warfare" or something better.


I think the other part of the issue is that the current mechanics mix where a unit is positioned within the army with whether the unit has an offensive or defensive posture.
Frontline, support and rear echelon are positions within an overall army. However under the current system you can't stop a frontline unit from attacking, your only option is to move it into a support or rear position. The position system is therefore being used to control whether the unit should attack or not.
I can think of 2 ways to resolve this: first by splitting posture from positioning and having them as 2 separate properties, the second is to add more positions to account for different combinations.
The former would require at least a partial re-think of how systems like fortification interact with posture and positioning separately. I haven't done this, so I don't have a whole new system to propose, but it might inspire other people to do so.

As a more limited change using the second option, I think that adding a frontline position which doesn't attack at all, but does return fire if attacked, might address the main complaints. You could call it "total defence", or "static defence", or "frontline - return fire", or something better.
Title: Re: C# Suggestions
Post by: skoormit on April 05, 2022, 09:20:10 AM
Rather than set demand and supply, set a target qty in a field next to each installation type on that colony, with a check box to turn that target on or off. If the target is on, and you have more than the target, it is treated as available supply. If you have less, it is treated as demand. If you turn the target off, you have no demand or supply for that type on that colony, regardless of the number filled into the target field.

I love this idea.
Probably code-intensive,
but still--I love it.


From my point of view, this suggestion would make keeping track of what I expect the civs to move harder. Right now, I can set up supply and demand orders for equal amounts (and if it goes wrong, I know why). If this were implemented, any time the civs are moving things in a way I didn't expect, I'd have to go through all my colonies to see where the target numbers are wrong or if a target is on/off when it's supposed to be the other. I expect the way I would use this system would be to usually have everything off, and only turn specifics on at source and destination colonies in order to replicate the current system.

That is a fair concern.
Aurora often does not present the information we want in the way we find most useful.

To work around this, I use Excel to execute a few db queries I have written (and display/aggregate the data in the ways I find useful).
In fact, I have a query that gets all current installation shipping tasks in progress (my freighters or civs).

If this feature were implemented, I would write another query to show all installation target numbers across my empire.
In Excel I would then add a new sheet that cross references, for each population, the target numbers, the in-progress shipping tasks, any queued installation production jobs (probably with completion ETA), and of course the number of installations already in place.

I'm always happy to share. Especially if one of you front-end gurus is keen on making a UI to show all the data.
Title: Re: C# Suggestions
Post by: nakorkren on April 06, 2022, 09:49:05 AM
Very minor nit, but when one of your colonies has some amount of unrest, it causes a message that
"Unrest Increasing: System Name      Unrest is rising on Planet Name due to overcrowding. Political Stability now at XX.X%".

This message is the same whether unrest is rising or falling, and you just have to remember what unrest was the last tick to understand which direction it's moving.

I would suggest performing a check vs last tick's unrest level and either not creating a message when unrest is non-zero but falling, or changing to have one message text for rising and one for falling.
Title: Re: C# Suggestions
Post by: nakorkren on April 06, 2022, 11:12:00 PM
Suggest that the NPR AI should be updated to recognize that ships which are operating at hugely reduced efficiency due to being recently captured via boarding are not a significant threat and should not be prioritized for targeting.

Alternately, ships which are captured should become neutral (or untargetable?) and uncontrollable for a short duration. This would represent the time during which the boarders are done fighting and starting to figure out how to fly this alien spaceship, and the fact that the prior owners may not be sure whether the boarders won or their people just lost comms and are still fighting, and hence the ship should not be fired upon.

Alternately-alternately, could ship reaction time/firing time be penalized as a function of ratio of boarders (or boarder firepower) to crew? This would represent the fact that the crew are too busy fighting the boarders to do their normal jobs, including on nearby ships that might otherwise fire at a recently captured neighboring ship.

Any of the ideas above would reduce the incidence of captured ships being blown up a few ticks after capture by their nearest prior friend, which really disincentivizes the use of boarding outside of mopping up after a battle.
Title: Re: C# Suggestions
Post by: Garfunkel on April 07, 2022, 04:48:05 AM
That would be a really great change!
Title: Re: C# Suggestions
Post by: unkfester on April 07, 2022, 07:31:31 AM


Alternately, ships which are captured should become neutral (or untargetable?) and uncontrollable for a short duration. This would represent the time during which the boarders are done fighting and starting to figure out how to fly this alien spaceship, and the fact that the prior owners may not be sure whether the boarders won or their people just lost comms and are still fighting, and hence the ship should not be fired upon.

Alternately-alternately, could ship reaction time/firing time be penalized as a function of ratio of boarders (or boarder firepower) to crew? This would represent the fact that the crew are too busy fighting the boarders to do their normal jobs, including on nearby ships that might otherwise fire at a recently captured neighboring ship.

Any of the ideas above would reduce the incidence of captured ships being blown up a few ticks after capture by their nearest prior friend, which really disincentivizes the use of boarding outside of mopping up after a battle.
It would be nice if Enemy ships can't fire while boarded
So you could multiple ships at same time and they don't fire on you as you win ships.
Title: Re: C# Suggestions
Post by: Warer on April 09, 2022, 07:22:31 AM
Inverse Damage Fall off Weapon
Some kind of weapon system that has an inverted damage curve, ie it does the most damage at Max range and minimal or zero damage at short/point blank range.

Potentially even an inverted to hit chance.

Honestly mostly had this idea since the best long range weapon in game is the particle beam/lance and I kind of don`t like how their range mechanics work, and the various other weapons energy aren`t any good for long range slap fights beam duels. The idea of a weapon that gets less effective at closer range is also just interesting to me, though the balance would be a whole nother kind of interesting I admit. 
Title: Re: C# Suggestions
Post by: Migi on April 09, 2022, 10:42:54 AM
Inverse Damage Fall off Weapon
Some kind of weapon system that has an inverted damage curve, ie it does the most damage at Max range and minimal or zero damage at short/point blank range.

IIRC Sword of the Stars had something like that.
The torpedo weapons were big balls of plasma that got stronger the further they travelled. They acted more like missiles than beam weapons though. They could be weakened and destroyed by point defence and they moved pretty slowly, but they did follow targets.


Quote
an inverted to hit chance.

This would make sense for a weapon that can't track quickly. However Aurora doesn't model weapon tracking in degrees, it uses ship speed or turret speed. Adding that would be a big change.
Title: Re: C# Suggestions
Post by: KriegsMeister on April 09, 2022, 02:19:28 PM
I could see a slight redesign to lasers working for that idea. IRL lasers suffer from beam divergence, which in game is represented by losing damage at range, but would better be represented by that damage spreading to cover more area as the same amount of energy is being transmitted whether its in a single point or if the diameter is as wide as a ship. So rather than a 6 damage laser having a profile of [1 4 1] up close and dropping down to [1 4], then [4], [3] and so on and so on until it hits 0, it would look more like [6], [1 5], [2 4], [3 3], [1 2 3], [2 2 2], all the way to [1 1 1 1 1 1] before hits would be to dissipated to damage armor.

Additionally because the beam gets wider the chance to hit could proportionally increase with range, or probably better just have reduced penalty at range. A shotgun with 4in pattern at X yards might have an 8in pattern at 2X but doesn't mean it'll necessarily be twice as accurate at hitting that target.

Would probably be best to juggle and rename laser design parts with wavelength being the same but now being the base date modifier, and changing focal size to something like divergence focal array or something similar that adjust range by way of "tightening" the spread of the laser.
Title: Re: C# Suggestions
Post by: nuclearslurpee on April 09, 2022, 11:24:49 PM
A small suggestion for ground forces headquarters units:

Presently, headquarters units are a bit awkward since they do not increase in component size beyond HQ50 (=250 tons). This is fine for pretty much any single formation a player would create (I've yet to see anyone seriously propose a >50,000-ton ground formation on these forums) and for simple formation hierarchies with small-to-medium (5,000 or 10,000 tons) basic formations. However, if the player wants to use larger formations in a hierarchy (e.g., a corps with 4 subordinate brigades of 20,000-ton formation size) or more complex hierarchies with several layers, the hard cap on HQ size seems rather awkward - a headquarters controlling a million tons of ground units (~100k soldiers or so) should have a pretty sizable staff and facilities, probably requiring much more than 250 tons of transportation capacity.

I'd like to suggest that instead, HQ functionality is split into two parts: As now, the HQ## capability would indicate the size of formation which can be controlled, and would work as presently. However, the ability to control subordinate formations would be based on the number of HQ components included in a superior formation. For example, a corps HQ formation controlling four brigade formations, each of 20k, would require a total of five HQ20 components (one for itself + four for the brigades) instead of a single HQ100 component.

I would note a couple of tricky parts in implementing such an idea:
While there are some intricacies to work out, I think this could be a much more interesting and engaging way to handle HQs and hierarchies, which offers I think a bit more of a roleplay connection between HQ formation design and reflecting the actual hierarchical structure the player chooses.

E: I almost forgot to mention a huge practical benefit of this - no need to research multiple very expensive HQ types to support a complex hierarchy. Research costs for high-level HQs are obscene and one of my least-favorite parts of the ground forces experience in Aurora, particularly given the irksome contrast between the relative lack of necessity for a complex ground forces hierarchy and the lack of auto-assignment jobs for high-ranking officers without a multi-layered hierarchy.
Title: Re: C# Suggestions
Post by: skoormit on April 10, 2022, 06:43:37 AM
For fleets, we have checkboxes (on the Miscellaneous tab) to control if sensors and/or weapon ranges for this fleet are displayed on the tactical map.

It would be nice to have a similar checkbox to control if this fleet is displayed on the galactic map (when the "All Fleet Locations" option is enabled on the map).

Reasoning: I usually leave small jump tender stations and/or sensor platforms in just about every system I explore. This makes the "All Fleet Locations" option non-useful, since I have a fleet in every system. If I could hide those, then that map option could show me where my actual fleets of concern are.
Title: Re: C# Suggestions
Post by: Droll on April 10, 2022, 10:52:58 AM
A game setting that can manipulate the spawn chance and magnitude of spoilers I'm thinking specifically precursors. Idk if the difficulty setting does anything regarding spoilers.
Title: Re: C# Suggestions
Post by: Andrew on April 10, 2022, 11:30:44 AM

I'd like to suggest that instead, HQ functionality is split into two parts: As now, the HQ## capability would indicate the size of formation which can be controlled, and would work as presently. However, the ability to control subordinate formations would be based on the number of HQ components included in a superior formation. For example, a corps HQ formation controlling four brigade formations, each of 20k, would require a total of five HQ20 components (one for itself + four for the brigades) instead of a single HQ100 component.

While not opposed in Principle ....
Some problems
1) None standard Sub units at a division level I may have larger Planatery defense brigades, with smaller infantry or armoured units and a division may be  different selections of sub units depending on the Divisions mission. ( so 120,000 ton Division may have 5 20,000 ton sub units or 1 40,000 and 3 20,000 etc)
2) A corp may have several division and also an allowance for independent regiment brigades assigned at corp level and again these may vary between High level HQ Units (600,000 ton corp has 4 120,000 ton Divisions, 2 20,000 ton brigades and 6 10,000 ton logistics regiments or maybe a 40,000 ton PDC Brigade and 2 10,000 ton logistics regiments)
3)I do occassionally produce 50,000 ton sub units normally Super or Ultra heavy armour units (Titan Legions)
Title: Re: C# Suggestions
Post by: Kristover on April 10, 2022, 11:48:56 AM

I'd like to suggest that instead, HQ functionality is split into two parts: As now, the HQ## capability would indicate the size of formation which can be controlled, and would work as presently. However, the ability to control subordinate formations would be based on the number of HQ components included in a superior formation. For example, a corps HQ formation controlling four brigade formations, each of 20k, would require a total of five HQ20 components (one for itself + four for the brigades) instead of a single HQ100 component.

While not opposed in Principle ....
Some problems
1) None standard Sub units at a division level I may have larger Planatery defense brigades, with smaller infantry or armoured units and a division may be  different selections of sub units depending on the Divisions mission. ( so 120,000 ton Division may have 5 20,000 ton sub units or 1 40,000 and 3 20,000 etc)
2) A corp may have several division and also an allowance for independent regiment brigades assigned at corp level and again these may vary between High level HQ Units (600,000 ton corp has 4 120,000 ton Divisions, 2 20,000 ton brigades and 6 10,000 ton logistics regiments or maybe a 40,000 ton PDC Brigade and 2 10,000 ton logistics regiments)
3)I do occassionally produce 50,000 ton sub units normally Super or Ultra heavy armour units (Titan Legions)

I second Nuclear’s suggestion about HQ.  The research and construction times for top level HQs to command several Divisions and enablers requires a decade (or more) to research and a decade (or more) to build at low tech levels.  Almost nothing else ship or ground wise takes as long.  In my games, HQ units are the one thing that I SM research and build because of the out of whack costs. Since we don’t have an HQ layer for high commands like we for Space Forces, a tweaked version of this seems like a good solution to research and build HQ units.

But please save it for 2.1.  Getting antsy to play 2.0 already!  I’ll SM my HQs in the meantime.
Title: Re: C# Suggestions
Post by: nuclearslurpee on April 10, 2022, 12:04:29 PM
While not opposed in Principle ....
Some problems
1) None standard Sub units at a division level I may have larger Planatery defense brigades, with smaller infantry or armoured units and a division may be  different selections of sub units depending on the Divisions mission. ( so 120,000 ton Division may have 5 20,000 ton sub units or 1 40,000 and 3 20,000 etc)

I think there is potentially an interesting gameplay decision here, in the choice of "overbuilding" an HQ formation to have more flexibility at greater expense (e.g., 5xHQ40), or to build a more precise and rigid structure for a cheaper cost (e.g., 4xHQ20 + 1xHQ40). However, I can recognize that this might be more detailed formation management than some players want, and also that trying to manage multiple different HQ component sizes in a single formation may be tricky for Steve to program.

I know that I personally tend to overbuild my HQs presently to allow flexibility to attach an extra formation, but I would not want to force this on other players who prefer a more rigid but optimized structure.


Quote
2) A corp may have several division and also an allowance for independent regiment brigades assigned at corp level and again these may vary between High level HQ Units (600,000 ton corp has 4 120,000 ton Divisions, 2 20,000 ton brigades and 6 10,000 ton logistics regiments or maybe a 40,000 ton PDC Brigade and 2 10,000 ton logistics regiments)

This along with the previous point would probably suggest that a superior formation having only the HQs needed to control direct subordinates is the preferable solution.


Quote
3)I do occassionally produce 50,000 ton sub units normally Super or Ultra heavy armour units (Titan Legions)

I think this is fine. The "problem" is more when you have HQs for a million tons that are still only size 250 or so which looks kind of silly. I wouldn't be opposed to just removing the size cap in principle but I think that would cause its own problems and imbalances, without addressing the issue of obscene RP and BP costs for those elements.
Title: Re: C# Suggestions
Post by: nakorkren on April 10, 2022, 10:33:33 PM
With the upcoming changes to fighter management likely to make fighters much less micro-intensive, I am using fighters in my current 1.13 game to learn the ropes. One thing I've noticed is really tedious is having to manually set each and every fighter to "Automated Damage Control", as they apparently all start with that unchecked.

Would it be possible to make the default for "Automated Damage Control" to be checked? Or in the Ship Design window, add an option under the Misc tab to toggle the default for Damage Control behavior to be automated or not on a class-wide basis, which when toggled would overwrite any individual ship settings? That would allow people to make mass changes with a minimum of tedium, while still permitting granular control by ship if desired.
Title: Re: C# Suggestions
Post by: nuclearslurpee on April 10, 2022, 10:43:06 PM
Or in the Ship Design window, add an option under the Misc tab to toggle the default for Damage Control behavior to be automated or not on a class-wide basis, which when toggled would overwrite any individual ship settings?

This one please.
Title: Re: C# Suggestions
Post by: TMaekler on April 11, 2022, 07:49:28 AM
Useable Planet Size

I think that the maximum amount of population for a body misses one feature - at least for role play: Scorched Earth. Not all areas of a planet can be used as living space for population. A lot of AARs have devastated Earth and start with a small number of people. But they grow like crazy because of the maximum possible on Earth. So a limiting factor like scorched Earth could help limiting pop growth to a more "realistic" factor; as well as limiting the maximum of people being able to live on earth. If Europe, Asia and Africa are scorched, we wouldn't be able to regrow world population to 8 Billion or more.

So if we could add a parameter to each world; something like: scorch percentage...
Title: Re: C# Suggestions
Post by: Garfunkel on April 11, 2022, 06:48:16 PM
2) A corp may have several division and also an allowance for independent regiment brigades assigned at corp level and again these may vary between High level HQ Units (600,000 ton corp has 4 120,000 ton Divisions, 2 20,000 ton brigades and 6 10,000 ton logistics regiments or maybe a 40,000 ton PDC Brigade and 2 10,000 ton logistics regiments)

This along with the previous point would probably suggest that a superior formation having only the HQs needed to control direct subordinates is the preferable solution.
It would also be more accurate to modern day militaries - a general commanding a division doesn't worry about the condition of the infantry companies despite them belonging to him, he worries about the regiments or brigades. The commanders of those worry about battalions, and the BN commanders worry about companies and so on. So, it would be best if each level only needs the HQ capacity for itself and its direct subordinates.

And not only is it realistic, it's more intuitive for players when building their armies, plus this way your army can grow organically without having the need to plan multiple levels beforehand.

Though the only problem I have with the current system is the crazy cost (in RP and BP) of high-level HQ's. Somehow the size has never bothered me!
Title: Re: C# Suggestions
Post by: Iceranger on April 14, 2022, 07:56:29 PM
Not a gameplay related suggestion, but is it possible to make the tactical map center in the window properly when the window is resized? Right now it is always centered as if the window is full screen even after resized. This is extremely painful on ultrawide monitors...
Title: Re: C# Suggestions
Post by: Sebmono on April 15, 2022, 05:40:44 AM
It would also be more accurate to modern day militaries - a general commanding a division doesn't worry about the condition of the infantry companies despite them belonging to him, he worries about the regiments or brigades. The commanders of those worry about battalions, and the BN commanders worry about companies and so on. So, it would be best if each level only needs the HQ capacity for itself and its direct subordinates.

And not only is it realistic, it's more intuitive for players when building their armies, plus this way your army can grow organically without having the need to plan multiple levels beforehand.

Though the only problem I have with the current system is the crazy cost (in RP and BP) of high-level HQ's. Somehow the size has never bothered me!
Yes please, a thousand times this. Not having to wait decade to build a top-level HQ unit, just because I want to have a 4 layer OOB of 25k units would be amazing, and the flexibility to grow the armies more organically while also having more variation within would be fantastic.
Title: Re: C# Suggestions
Post by: Aloriel on April 19, 2022, 03:53:39 PM
Add an RIO seat that provides similar bonuses as a tactical station, but only for fighters.
Title: Re: C# Suggestions
Post by: Migi on April 20, 2022, 11:18:46 AM
Add an RIO seat that provides similar bonuses as a tactical station, but only for fighters.

Unless you provide some new rationale, Steve has already considered and excluded this idea.

Quote
I don't plan to scale the modules to ship size or add extra crew. That would add extra complexity and make designing ships more difficult. For small ships, most command and control modules won't be used, and once you get past a certain size of ship, they will probably all be used. I am not trying to create a decision as to whether a battleship should have a CIC or Main Engineering, but rather to create meaningful choices for mid-range ships.

http://aurora2.pentarch.org/index.php?topic=8495.msg101818#msg101818
Title: Re: C# Suggestions
Post by: xenoscepter on April 21, 2022, 06:55:04 PM
 --- What if, instead of requiring an engine to be at least 1,250 Tons and at most 50% Power to be considered Commercial, it was changed to a drop down that let you choose between Military and Commercial with Commerical doubling the tonnage and halving the power? Crew would scale to as normal, half power = half crew and whatnot. Commercial engines would still get the bonus to fuel efficiency same as they do now.
Title: Re: C# Suggestions
Post by: nuclearslurpee on April 21, 2022, 07:43:44 PM
--- What if, instead of requiring an engine to be at least 1,250 Tons and at most 50% Power to be considered Commercial, it was changed to a drop down that let you choose between Military and Commercial with Commerical doubling the tonnage and halving the power? Crew would scale to as normal, half power = half crew and whatnot. Commercial engines would still get the bonus to fuel efficiency same as they do now.

Two problems with this:

1. This makes the definition of a commercial engine murky, confusing, exploitative, and pointless. For example, if I understand this correctly I could make a 200% boost engine and click the "commercial" checkbox to have a 100% boost engine at 2x the size... I've designed a standard military engine that reads as commercial on sensors?? You could avoid such silliness by changing the suggestion to say that any engine with 50% boost is commercial, but in that case all we are doing is removing the size restriction which has already been put in place for a game design reason.

2. This requires making an "exception" in the game rules, when the design thrust of C# has been to reduce or eliminate such exceptions.

It is also worth noting - commercial engines do not get a special bonus to fuel efficiency in C#, whatsoever. The improvement in fuel efficiency for a low EP boost modifier is the same regardless of the engine classification.

I'm also unsure what problem this suggestion is trying to solve? We will always have an arbitrary commercial vs. military designation in Aurora, because the mechanics of it are too essential to the gameplay and frankly necessary to keep the level of logistics micromanagement down to reasonable levels. Given that, having a simple and clear distinction between what does and doesn't count as commercial makes much more sense than having a complicated mechanic just for...what reason?
Title: Re: C# Suggestions
Post by: Aloriel on April 21, 2022, 09:07:39 PM
Make certain that passive sensors trigger the same interrupts as active sensors.

Basically, I have a series of passive sensor satellites designed to detect enemy ships. It turns out, this is a waste because they don't generate interrupts, or even detection messages sometimes (I suspect this latter bit might be a glitch, because I can clearly see the hostile ships with no message in the log). The advantage of passive sensors is that the enemy won't notice them unless they're on top of them or using active sensors themselves. This makes for a very survivable monitoring system.
Title: Re: C# Suggestions
Post by: nuclearslurpee on April 21, 2022, 09:33:20 PM
Make certain that passive sensors trigger the same interrupts as active sensors.

I believe this is being fixed in v2.0. The problem has been that event notifications for neutral or hostile contacts only fire for "new" contacts, so if a sensor (passive or active) happens to detect a contact in the same state as when that contact was last seen it will not fire an interrupt or an event notification.
Title: Re: C# Suggestions
Post by: Migi on April 22, 2022, 11:23:37 AM
I'm also unsure what problem this suggestion is trying to solve?

The problem, such as I intuit it, is that commercial ships cannot be small, because commercial engines cannot be small, and commercial ships cannot be relatively fast, because commercial engines have low EP per ton. The latter also limits the pulling power of Tugs.


Two problems with this:

I disagree with almost everything you said.

--- What if, instead of requiring an engine to be at least 1,250 Tons and at most 50% Power to be considered Commercial, it was changed to a drop down that let you choose between Military and Commercial with Commerical doubling the tonnage and halving the power? Crew would scale to as normal, half power = half crew and whatnot. Commercial engines would still get the bonus to fuel efficiency same as they do now.

As far as I can see you could make a (numbers are illustrative) 500 EP commercial engine and a 500 EP military engine, but the commercial engine would need to be 2 (or 4, I'm not quite clear) times as big.
This would add a new distinction to military vs commercial engines, because the EP per ton would be lower for commercial engines.
It would make commercial ships slower if they used the same % engine, or larger and more expensive to add power.

You could make a commercial engine twice as big as the technology engine size limit.
How would the size change interact with the fuel efficiency from engine size?
Title: Re: C# Suggestions
Post by: xenoscepter on April 22, 2022, 11:35:19 AM
--- What if, instead of requiring an engine to be at least 1,250 Tons and at most 50% Power to be considered Commercial, it was changed to a drop down that let you choose between Military and Commercial with Commerical doubling the tonnage and halving the power? Crew would scale to as normal, half power = half crew and whatnot. Commercial engines would still get the bonus to fuel efficiency same as they do now.

Two problems with this:

1. This makes the definition of a commercial engine murky, confusing, exploitative, and pointless. For example, if I understand this correctly I could make a 200% boost engine and click the "commercial" checkbox to have a 100% boost engine at 2x the size... I've designed a standard military engine that reads as commercial on sensors?? You could avoid such silliness by changing the suggestion to say that any engine with 50% boost is commercial, but in that case all we are doing is removing the size restriction which has already been put in place for a game design reason.

2. This requires making an "exception" in the game rules, when the design thrust of C# has been to reduce or eliminate such exceptions.

It is also worth noting - commercial engines do not get a special bonus to fuel efficiency in C#, whatsoever. The improvement in fuel efficiency for a low EP boost modifier is the same regardless of the engine classification.

I'm also unsure what problem this suggestion is trying to solve? We will always have an arbitrary commercial vs. military designation in Aurora, because the mechanics of it are too essential to the gameplay and frankly necessary to keep the level of logistics micromanagement down to reasonable levels. Given that, having a simple and clear distinction between what does and doesn't count as commercial makes much more sense than having a complicated mechanic just for...what reason?

 --- If Commercial Engines get no fuel efficiency bonus above and beyond the typical, then that's fine, but the point is that a Commercial Engine can be used Commercial-y. It is valid for no maintenance designs. The Military Engine with 200% doesn't have this ability, while the commercial engine does, but trades away the power and instead gives that mass over to the ability to be No Maintenance when on a Commercial Design. Using Commercial Engines on a Military Ship thus have no utility anymore, since the No Maintenance is wasted.

 --- This streamlines the how and why, since we can assume the how is that whatever is being used to make the Military one go 200% is halved or being used to the effect of making a smaller one at 100%, while using that space saved to add the Magic Doesn't Break Smoke that makes Commercial Engines do their thing. Likewise, the arbitrary engine size and power limit is no longer an arbitrary limit, but a flexible one with a simple toggle that asks the player: "Is this for a Warship or Not?" Another problem it solves is not being able to make tiny Commercial Ships... or even FAC sized ones, to be honest. Currently every Commercial ship MUST exceed 1,250 Tons... before Crew Quarters, Fuel and the lot.

 --- What will this be used for? Currently Fighter-sized cryo is bugged since Fighters still can't land on planets to offload colonists... so that's of no use. However, the addition of Small Craft Refueling System means a No Maintenace FAC tanker sees a good benefit from this change. Likewise with Deep Space Populations and the renamed Orbital Habitats... a centralized Colonist supply could be established with Commercial FACs / Fighter scale colonist shuttles refilling the "stock" Tiny FAC sized or smaller scouts receive a good benefit from this, since they would need no maintenance and no additional deployment for their missions, being able to relocate under their own power and hang around forever.

 --- Finally, this does not create an exception to the rules at all. Commercial Engines are ALREADY an exception made more exceptional by the arbitrary limits. Jump Drives ALREADY use a toggle to this end, but regular engines don't. Such a toggle streamlines, simplifies and brings regular engines into line with the Jump Engines that they mechanically interact with. This eliminates a special mechanic rather than makes it more complex. A toggle is straightforward, highly visible and not confusing to a new player who wouldn't realize it's 50% or lower AND has to be AT LEAST 1,250 Tons.

 --- Hell, while we're at it, why not do the same for sensors? Give it a dropdown to tag it as Commercial, same size, but half the strength... but putting it on a ship doesn't make it military?

Title: Re: C# Suggestions
Post by: Droll on April 22, 2022, 11:42:21 AM
--- What if, instead of requiring an engine to be at least 1,250 Tons and at most 50% Power to be considered Commercial, it was changed to a drop down that let you choose between Military and Commercial with Commerical doubling the tonnage and halving the power? Crew would scale to as normal, half power = half crew and whatnot. Commercial engines would still get the bonus to fuel efficiency same as they do now.

Two problems with this:

1. This makes the definition of a commercial engine murky, confusing, exploitative, and pointless. For example, if I understand this correctly I could make a 200% boost engine and click the "commercial" checkbox to have a 100% boost engine at 2x the size... I've designed a standard military engine that reads as commercial on sensors?? You could avoid such silliness by changing the suggestion to say that any engine with 50% boost is commercial, but in that case all we are doing is removing the size restriction which has already been put in place for a game design reason.

2. This requires making an "exception" in the game rules, when the design thrust of C# has been to reduce or eliminate such exceptions.

It is also worth noting - commercial engines do not get a special bonus to fuel efficiency in C#, whatsoever. The improvement in fuel efficiency for a low EP boost modifier is the same regardless of the engine classification.

I'm also unsure what problem this suggestion is trying to solve? We will always have an arbitrary commercial vs. military designation in Aurora, because the mechanics of it are too essential to the gameplay and frankly necessary to keep the level of logistics micromanagement down to reasonable levels. Given that, having a simple and clear distinction between what does and doesn't count as commercial makes much more sense than having a complicated mechanic just for...what reason?

 --- If Commercial Engines get no fuel efficiency bonus above and beyond the typical, then that's fine, but the point is that a Commercial Engine can be used Commercial-y. It is valid for no maintenance designs. The Military Engine with 200% doesn't have this ability, while the commercial engine does, but trades away the power and instead gives that mass over to the ability to be No Maintenance when on a Commercial Design. Using Commercial Engines on a Military Ship thus have no utility anymore, since the No Maintenance is wasted.

 --- This streamlines the how and why, since we can assume the how is that whatever is being used to make the Military one go 200% is halved or being used to the effect of making a smaller one at 100%, while using that space saved to add the Magic Doesn't Break Smoke that makes Commercial Engines do their thing. Likewise, the arbitrary engine size and power limit is no longer an arbitrary limit, but a flexible one with a simple toggle that asks the player: "Is this for a Warship or Not?" Another problem it solves is not being able to make tiny Commercial Ships... or even FAC sized ones, to be honest. Currently every Commercial ship MUST exceed 1,250 Tons... before Crew Quarters, Fuel and the lot.

 --- What will this be used for? Currently Fighter-sized cryo is bugged since Fighters still can't land on planets to offload colonists... so that's of no use. However, the addition of Small Craft Refueling System means a No Maintenace FAC tanker sees a good benefit from this change. Likewise with Deep Space Populations and the renamed Orbital Habitats... a centralized Colonist supply could be established with Commercial FACs / Fighter scale colonist shuttles refilling the "stock" Tiny FAC sized or smaller scouts receive a good benefit from this, since they would need no maintenance and no additional deployment for their missions, being able to relocate under their own power and hang around forever.

 --- Finally, this does not create an exception to the rules at all. Commercial Engines are ALREADY an exception made more exceptional by the arbitrary limits. Jump Drives ALREADY use a toggle to this end, but regular engines don't. Such a toggle streamlines, simplifies and brings regular engines into line with the Jump Engines that they mechanically interact with. This eliminates a special mechanic rather than makes it more complex. A toggle is straightforward, highly visible and not confusing to a new player who wouldn't realize it's 50% or lower AND has to be AT LEAST 1,250 Tons.

 --- Hell, while we're at it, why not do the same for sensors? Give it a dropdown to tag it as Commercial, same size, but half the strength... but putting it on a ship doesn't make it military?

Not sure how I feel about large civilian sensors, sure they're less powerful for balance and I assume still expensive to build but having maintenance free mega-radar seems a bit off given how sensitive and delicate sensor equipment is supposed to be.

With engines though I'm kind of onboard with the idea of having a commercial toggle that is equivalent to current power/mass/fuel efficiency ratio to allow for commercial "fighters".
Title: Re: C# Suggestions
Post by: xenoscepter on April 22, 2022, 11:43:08 AM
~~snippy snippy~~
You could make a commercial engine twice as big as the technology engine size limit.
How would the size change interact with the fuel efficiency from engine size?

 --- I failed to communicate this, and I'm sorry for that, but my assumption was the Engine Size tech was still the upper limit for what you could choose as a base. So a 200% Military Engine that was 1,250 tons would indeed become a 100% Commercial Engine of 2,500 Tons. I deemed that mostly irrelevant since it confers no advantage, however with consideration of larger engines being more fuel efficient than smaller per hullsize that might not actually be the case.

 --- I'd say there's a few ways to address that:
  -   Keep the engine boost penalty, but apply the efficiency bonus derived from the doubled size on top of it.
  -   Tweak nothing and just allow Commercial exceed the Engine tech size, since you still couldn't build a 200% Military engine of 2,500 tons w/o said tech and thus not devaluing the tech.

I'd go for the second one personally since it's internally consistent with other things in Aurora, namely the shipyards It'd likewise retain some value in a Commerical Engine for Military Applications. Verisimilitude is always nice.  :)
Title: Re: C# Suggestions
Post by: xenoscepter on April 22, 2022, 11:46:06 AM
Not sure how I feel about large civilian sensors, sure they're less powerful for balance and I assume still expensive to build but having maintenance free mega-radar seems a bit off given how sensitive and delicate sensor equipment is supposed to be.

With engines though I'm kind of onboard with the idea of having a commercial toggle that is equivalent to current power/mass/fuel efficiency ratio to allow for commercial "fighters".

 --- Yeah, I'm iffy on the sensor bit myself, but figured I'd throw it in because it illustrates a place where gameplay could be simplified and wasn't, thus undermining simplification as an objection to the implementation of my suggestion... at least standing alone w/o other reasons.
Title: Re: C# Suggestions
Post by: nuclearslurpee on April 22, 2022, 01:00:46 PM
The problem, such as I intuit it, is that commercial ships cannot be small, because commercial engines cannot be small, and commercial ships cannot be relatively fast, because commercial engines have low EP per ton. The latter also limits the pulling power of Tugs.

I disagree that this is a problem; I think these are fair and valid tradeoffs for the lack of maintenance requirement.


--- If Commercial Engines get no fuel efficiency bonus above and beyond the typical, then that's fine, but the point is that a Commercial Engine can be used Commercial-y. It is valid for no maintenance designs. The Military Engine with 200% doesn't have this ability, while the commercial engine does, but trades away the power and instead gives that mass over to the ability to be No Maintenance when on a Commercial Design. Using Commercial Engines on a Military Ship thus have no utility anymore, since the No Maintenance is wasted.
--- I failed to communicate this, and I'm sorry for that, but my assumption was the Engine Size tech was still the upper limit for what you could choose as a base. So a 200% Military Engine that was 1,250 tons would indeed become a 100% Commercial Engine of 2,500 Tons. I deemed that mostly irrelevant since it confers no advantage, however with consideration of larger engines being more fuel efficient than smaller per hullsize that might not actually be the case.

There is actually a significant advantage, not so much because of the larger engines possible (although I do think it is a problem still), but because a ship with effectively military engines will appear to the sensors of other races to have commercial engines. Thus as long as I have the necessary techs (and engine boost tech is both cheap and necessary for any fleet which uses missiles, so this is quite probable), I have no reason to ever design, say, a 100% military engine when I could instead design a "200% + commercial" engine of half the size, with exactly the same performance characteristics and the ability to prevent my opponents from identifying which of my ship classes are military or commercial... currently to undertake such a deception requires significant sacrifice of efficiency.

We can discuss separately if it makes sense to have this distinction from sensor readings (personally I think it makes not much sense), but as it is the current game mechanic we have to consider such a change in light of that mechanic.

Another significant ramification, not yet discussed, is that commercial jump engines become able to jump military ships with military-speed engines. This is a significant point of balance (as always, in the Aurora sense of balance), because even though commercial jump drives are somewhat larger they are much cheaper to build and maintain.


Quote
--- This streamlines the how and why, since we can assume the how is that whatever is being used to make the Military one go 200% is halved or being used to the effect of making a smaller one at 100%, while using that space saved to add the Magic Doesn't Break Smoke that makes Commercial Engines do their thing. Likewise, the arbitrary engine size and power limit is no longer an arbitrary limit, but a flexible one with a simple toggle that asks the player: "Is this for a Warship or Not?" Another problem it solves is not being able to make tiny Commercial Ships... or even FAC sized ones, to be honest. Currently every Commercial ship MUST exceed 1,250 Tons... before Crew Quarters, Fuel and the lot.

Again I do not think this is a problem, although I do concede that there is a certain design space which is closed off (as you expand on following this block).

That said, I am not on principle opposed to enabling small commercial craft, but it needs to be done carefully or a design space for interesting decisions can be lost as well.  For example, if 500-ton commercial colony ships or tankers are possible, that's well and good, but does that also enable constructing commercial scouts in the same tonnage range? In many of my campaigns I make regular use of 250-ton scouts based from boat bays, but if those scouts are 'commercial' I no longer need to provide boat bays to transport them as I can just build several dozen of them and scatter them everywhere even without fleet support.

Whereas under the current rules, I can still access this maintenance-free ship-based scouting and monitoring capability, if I want it, but there is a tradeoff as such a ship will be >1,250 tons in size - I have done exactly this in my Duranium Legion AAR as a matter of fact. Thus there is a place for both types of designs as each has important tradeoffs and capabilities. This is the kind of interesting decision-making space the current commercial/military mechanic creates quite effectively, and which I am very hesitant to give up just for tanker FACs (to phrase a bit glibly).

If it was not for considerations like this, I would honestly be fine with just saying any engine with 0.5x or lower boost is commercial (unless it has thermal reduction, of course). However, in practice the implications for small-craft design are not those which I would be happy with, so I prefer the current system.


Quote
--- Hell, while we're at it, why not do the same for sensors? Give it a dropdown to tag it as Commercial, same size, but half the strength... but putting it on a ship doesn't make it military?

Because frelloff huge, maintenance-free sensor platforms or ships are a really bad idea for Aurora gameplay.


Verisimilitude is always nice.  :)

Not always, there is such a thing as trying to be too realistic at the cost of good gameplay. Every game with such a level of detail must be careful not to cross such a line lest we end up requiring Italian spaceships to carry 25% more water to boil their pasta.  :P

----

Overall, to sum up a bit my perspective: an arbitrary commercial vs. military divide is necessary for Aurora's style of gameplay. The current rule of 50% boost and size >= 25 may not cover every case someone might wish for, but it is simple enough to be easily understood as a rule (it is literally documented in the component design screen, it is not arcane hidden knowledge) and it creates interesting design decisions which is a fundamental imperative of Aurora's gameplay.

In my mind, any suggestion to change the commercial vs. military mechanics, whether for engines or more generally, needs to demonstrate not that it is "more realistic" but that it preserves and creates interesting gameplay decisions in line with the current mechanics.
Title: Re: C# Suggestions
Post by: Froggiest1982 on April 22, 2022, 05:33:35 PM
You forgot the extra cargo space to bring our mandolinos....
Title: Re: C# Suggestions
Post by: Indefatigable on April 23, 2022, 04:16:20 AM
Construction Cycle Time
Order Delay


Instead of inputting the amount in seconds only, which can be big values in the hundreds of thousands or even millions, in addition one could type for example:

7d for 7 days, which the code would convert into 604800 seconds
3m for 3 months
1y for 1 year etc.
Title: Re: C# Suggestions
Post by: Destragon on April 25, 2022, 08:03:19 PM
I have a small suggestion that would probably be very useful:
On the left side of the Class Design window, where it lists all your ship designs, put in brackets an "(o)" next to the names of classes that use components that are marked as obsolete.
Alternatively, the names of the ships with obsolete components could be given a colour like red or yellow and when clicking on one of those ships and then on the "class components" tab, the obsolete components could also be highlighted in that colour. That would be nice, too.

Edit:
Similarly, unlocked class designs should also have either an "(u)" next to their name or have a different colour for their name.
Title: Re: C# Suggestions
Post by: nuclearslurpee on April 25, 2022, 09:04:21 PM
I have a small suggestion that would probably be very useful:
On the left side of the Class Design window, where it lists all your ship designs, put in brackets an "(o)" next to the names of classes that use components that are marked as obsolete.
Alternatively, the names of the ships with obsolete components could be given a colour like red or yellow and when clicking on one of those ships and then on the "class components" tab, the obsolete components could also be highlighted in that colour. That would be nice, too.

Coloring the class name would be a great addition. Maybe also a different color for classes with "design issues" in the lower-right pane?
Title: Re: C# Suggestions
Post by: alex_brunius on April 26, 2022, 05:54:13 AM
Orbital Commerce and Finance Module:
- A new ship module along the lines of others but with the purpose of generating wealth ( Same function as Financial Center but for large commercial stations )


Other loosely related ideas to wealth and trade:
- It could be cool to have some tradegoods generation and demand in some way connected to wealth generated by Financial Centers instead of population. For example high demand of Luxury tradegoods in colonies with a strong Financial Center base.
- Maybe instead of transporting pointlessly small numbers of population the Civilian Luxury Liners could have a seperate category of "cargohold" the only ones capable of transporting a new type of trade goods "Business Travelers" from and to Financial Centers and other colonies in these small fast luxury liners, these would be paying a high premium tax for the fast trip.
- Overall more dynamic tradegoods for flavor and story ( colonies with lots of Industry generating things like construction material, machinery and personal transports, while mining colonies generate more things like precious metals or chemicals ).
- Exotic unique tradegoods that can be discovered in planets ( and will only be added as a demand to all other planets after discovered ). Think stuff like a delicious animal or fun pet (luxury from habitable planet) or useful unique material (mining colony) or cultural unique tradegood ( one per alien race homeworld ).
Title: Re: C# Suggestions
Post by: skoormit on May 01, 2022, 08:24:12 AM
ELINT ships tend to be deployed for many years at a time, following an NPR population at a large distance--just close enough for the ELINT sensors to detect the EM signature of the population.

Sometimes, the EM signature of an NPR population decreases.
When this happens, the ELINT ship can lose contact with the population.
As a result, the ELINT ship is no longer gathering intel, and this can continue for years, since the player is not made aware when this happens.

It would be nice if an ELINT losing contact with an enemy population caused an event log message to appear.
Title: Re: C# Suggestions
Post by: Garfunkel on May 02, 2022, 12:02:41 AM
ELINT ships tend to be deployed for many years at a time, following an NPR population at a large distance--just close enough for the ELINT sensors to detect the EM signature of the population.

Sometimes, the EM signature of an NPR population decreases.
When this happens, the ELINT ship can lose contact with the population.
As a result, the ELINT ship is no longer gathering intel, and this can continue for years, since the player is not made aware when this happens.

It would be nice if an ELINT losing contact with an enemy population caused an event log message to appear.
Hear hear, this would be very useful!
Title: Re: C# Suggestions
Post by: xenoscepter on May 11, 2022, 12:10:25 PM
 Would it be possible for Artillery, when being subjected to Counter-Battery Fire, would use the higher of their two "evasion" stats? So the higher of Hit Mod or Fortification. This I think would make representing a vehicle's ability to "shoot and scoot" over a Static pieces in-ability better represented w/ minimal effort. Since it happens in the Bombardment phase, which I assume is distinct from the regular Attack / Defend phase, this might be simple~ish to execute.
Title: Re: C# Suggestions
Post by: boolybooly on May 12, 2022, 03:01:23 AM
Top of my suggestion list would be edit for orders.

I know it would be harder than it sounds as the orders are contextual, one following on from the context of the preceding order, but I think it might be possible to edit at a pointer in the order stack to insert or remove an order based on the preceding order as context and then remember the rest of the stack and add them back one by one when the edit is done with a context check on each as it is added back using the existing context subroutines. If a context is detectably broken, then the order would go red and if a break occurs during gameplay then you get the same as is currently the case and a message saying ShipX cannot complete order.

Would also be nice (in C#) to be able to add / insert chunks of template based on the preceding order context rather than current context of the ship being ordered, which I recall was different in VB6 so I am sure you know what I mean. Must be practicalities I am not aware of but just thought I would mention it.

Its just giving orders is such a substantial part of the way Aurora plays it strikes me it would be worth adding order queue edit and imagine that Steve would enjoy the result for his own QoL, so just airing the thought since this is the suggestions thread. :)
Title: Re: C# Suggestions
Post by: skoormit on May 12, 2022, 09:37:47 AM
Top of my suggestion list would be edit for orders....

I would love this so much.
Inserting a new order in the middle of a list costs me many, many clicks per hour of play.

I would also appreciate a "Refresh Lagrange Point Usage" feature that would re-check all the intra-system movement for Lagrange shortcuts.
Title: Re: C# Suggestions
Post by: Scandinavian on May 12, 2022, 11:32:19 AM
I would also appreciate a "Refresh Lagrange Point Usage" feature that would re-check all the intra-system movement for Lagrange shortcuts.
And the ability to put it in as an order too, so you can re-plot course every time you enter a system on a looping order.
Title: Re: C# Suggestions
Post by: alex_brunius on May 13, 2022, 04:39:54 AM
In addition to game setup options for Speeds ( Research, Terraforming and Survey ) it could be interesting to be able to easily modify some of the larger posts of wealth income/expenses in a similar manner for a tailored experience.

You could for example set up a game like this:
Income from Population tax = 50%
Income from Financial Centers = 400%
Income from Civilians = 600% ( CMC + all different shipping )
Production Expense = 200%
Research Expense = 400%
Army Expense = 200% ( construction + maintenance )
Navy Expense = 300% ( shipbuilding + MSP prod + others )

...to tailor an experience where building tall instead of wide is more promoted ( main limitation for growth/tech isn't population but wealth instead ). Could also be a fun way to experiment with how potential future tweaks to baseline wealth would feel/play without needing code changes once it's set up.

Title: Re: C# Suggestions
Post by: skoormit on May 25, 2022, 09:30:53 AM
How about a Fighter Shipyard?

Half the cost and workers of a normal Naval Shipyard, but has only 500t capacity.

I would use them mainly for refitting fighters.
Title: Re: C# Suggestions
Post by: Demetrious on May 25, 2022, 03:01:52 PM
This thread (https://aurora2.pentarch.org/index.php?topic=12977.msg160180) has an interesting conversation regarding Terraforming Installations and their utility compared to the ship-based component. Long story short, Terraforming Installations are wretched as they're a logistical nightmare (5 cargo holds per installation + infrastructure required for the population to run them) as opposed to orbital stations, which can be tugged into place much quicker and easier. The fact they cost more is just insult to injury.

I'd like to propose that the cost of Terraforming Installations be slashed, anywhere from one-half to one-quarter their current value. This would create an actual trade-off for the logistical headache they pose for use anywhere outside of Sol. It'd also be a lore-friendly way to explain how it takes a million people on the planet to do what a crew of hundreds can accomplish in orbit - i.e. automation. And as Jurassic Park taught us, that kind of automation is neither easy, nor cheap.  :)

Would it be possible for Artillery, when being subjected to Counter-Battery Fire, would use the higher of their two "evasion" stats? So the higher of Hit Mod or Fortification. This I think would make representing a vehicle's ability to "shoot and scoot" over a Static pieces in-ability better represented w/ minimal effort. Since it happens in the Bombardment phase, which I assume is distinct from the regular Attack / Defend phase, this might be simple~ish to execute.

I'll second this. I've been building Self-Propelled Guns for my invasion units specifically because mobility is their only defense when they're the ones attacking (i.e. dropping onto the planet with no prep time to dig in.) If they don't get that benefit specifically in the bombardment phase, that's rather unintuitive.

Title: Re: C# Suggestions
Post by: ArcWolf on May 25, 2022, 06:01:39 PM
This thread (https://aurora2.pentarch.org/index.php?topic=12977.msg160180) has an interesting conversation regarding Terraforming Installations and their utility compared to the ship-based component. Long story short, Terraforming Installations are wretched as they're a logistical nightmare (5 cargo holds per installation + infrastructure required for the population to run them) as opposed to orbital stations, which can be tugged into place much quicker and easier. The fact they cost more is just insult to injury.

I'd like to propose that the cost of Terraforming Installations be slashed, anywhere from one-half to one-quarter their current value. This would create an actual trade-off for the logistical headache they pose for use anywhere outside of Sol. It'd also be a lore-friendly way to explain how it takes a million people on the planet to do what a crew of hundreds can accomplish in orbit - i.e. automation. And as Jurassic Park taught us, that kind of automation is neither easy, nor cheap.  :)


As a counter point (as i said in the aforementioned post) making ground based terraformers more efficient or space based ones less efficient could be a good alternative.
Title: Re: C# Suggestions
Post by: xenoscepter on May 25, 2022, 08:13:21 PM
 --- How about a type of Countermeasure for GSFs? Or two types, even! One that reduces the accuracy of incoming fire, like an ECM and one that increases a GSFs weighting for the random target allocation? So this way we can use the firs type of countermeasure to make our GSFs more survivable versus ground fire, while the second kind can be used to make "Wild Weasels" either with lots of speed and armor for tanking, or maybe with a powerful countermeasure system of the former type! Or perhaps even some blend of these attributes.
Title: Re: C# Suggestions
Post by: nuclearslurpee on May 25, 2022, 11:49:27 PM
--- How about a type of Countermeasure for GSFs? Or two types, even! One that reduces the accuracy of incoming fire, like an ECM and one that increases a GSFs weighting for the random target allocation? So this way we can use the firs type of countermeasure to make our GSFs more survivable versus ground fire, while the second kind can be used to make "Wild Weasels" either with lots of speed and armor for tanking, or maybe with a powerful countermeasure system of the former type! Or perhaps even some blend of these attributes.

While I'm sure there's some potentially terrible way this breaks the game, I'm in favor of expanding the representation for non-combat ground force capabilities, and this would be a good tool to represent modern-style SIGINT or EWAR stuff.
Title: Re: C# Suggestions
Post by: skoormit on May 28, 2022, 08:49:35 AM
Suggestion:
Add a "Pause When Complete" checkbox on the Movement Orders pane that controls the auto-turn interrupt behavior for a fleet's current orders.
The box is ticked by default (upon fleet creation, and whenever a fleet completes all orders in its list).



Reasoning:
When a fleet completes all orders in its list, an auto-turn interrupt event occurs (with some exceptions).
Most of the time the interrupt is welcome, because I want to give the fleet subsequent orders (or take some other knock-on action).

Often, however, the interrupt is needless, because I do not immediately want to give the fleet subsequent orders.

Most of the time when giving orders to a fleet, I already know if I would prefer an auto-turn interrupt to occur upon conclusion.
Title: Re: C# Suggestions
Post by: xenoscepter on May 28, 2022, 04:16:27 PM
--- How about a type of Countermeasure for GSFs? Or two types, even! One that reduces the accuracy of incoming fire, like an ECM and one that increases a GSFs weighting for the random target allocation? So this way we can use the firs type of countermeasure to make our GSFs more survivable versus ground fire, while the second kind can be used to make "Wild Weasels" either with lots of speed and armor for tanking, or maybe with a powerful countermeasure system of the former type! Or perhaps even some blend of these attributes.

While I'm sure there's some potentially terrible way this breaks the game, I'm in favor of expanding the representation for non-combat ground force capabilities, and this would be a good tool to represent modern-style SIGINT or EWAR stuff.

 --- I realize now that I omitted an important detail, that these countermeasures would be for GSFs versus AA.
Title: Re: C# Suggestions
Post by: TMaekler on May 30, 2022, 07:21:24 AM
Top of my suggestion list would be edit for orders.
Speaking in general terms: ways to make repeatable command queues easier to handle as well as making templates more versatile - with the goal in mind to minimise the effort to maintain a larger empire, I would be in for that, too. That it is simply too much effort to maintain multiple and larger empires is one of the few aspects that keeps me from diving too deep into this fantastic story telling device.
Title: Re: C# Suggestions
Post by: nakorkren on June 04, 2022, 12:37:19 PM
Would the mechanics allow setting up a queue of ships to be scrapped? Right now when I capture a number of enemy ships, I have to individually go to each shipyard and assign it a ship to scrap, then repeat that several times over the course of a few years to scrap all the captured ships. It would be great if you could queue up scrapping (and production!) at a given shipyard. Alternately, maybe coding-wise it would be easier to add a fleet order that let's you pick a shipyard to scrap the fleet at, and all ships in that fleet would enter a "scrap" conditon similar to overhaul, except they'd progress through it x ships at a time based on the number of slipways at that shipyard.

Would be really helpful for anyone who's playstyle includes a significant amount of boarding and capturing enemy ships, whether combat or civvies.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 04, 2022, 04:51:18 PM
Suggestion: Amend the "Refuel at Refueling Hub (All)" and "Refuel from Colony or Hub" conditional orders to also refuel from stationary tankers.

This would make it much easier to support mostly-automatic survey fleets with basic tankers instead of having to place colonies for refueling stations and/or develop the Refueling Hub (10,000 RP).
Title: Re: C# Suggestions
Post by: nakorkren on June 05, 2022, 12:06:38 PM
In the Unit Series area, it would be helpful if clicking on the units on the left side (within the series) displayed that unit's description, so you could compare the units in the series to know which one is newer. Right now it continues to display the last unit you clicked from the list of un-placed units on the right.
Title: Re: C# Suggestions
Post by: nakorkren on June 11, 2022, 06:03:10 PM
It would be helpful if the fleet order queue had time estimates for each step in the queue. I assume this data is already being estimated, since there's a total time estimate at the top, and it would be great to know how long each step is going to take even if it's a rough estimate.
Title: Re: C# Suggestions
Post by: skoormit on June 12, 2022, 09:27:22 AM
It would be helpful if the fleet order queue had time estimates for each step in the queue. I assume this data is already being estimated, since there's a total time estimate at the top, and it would be great to know how long each step is going to take even if it's a rough estimate.

That would be nice, but I don't think that estimates are being calculated for each step.
The total estimate is just the total distance traveled divided by the speed of the fleet.
Time required for non-movement orders (refueling, loading/unloading, etc) is not included in the time estimate, nor is any time added to the estimate for orders that have time delays.
Title: Re: C# Suggestions
Post by: boolybooly on June 12, 2022, 03:32:57 PM
Suggest removing the star system name for moons and planets in the second field of the mineral search.

Currently the first field in the row provides star system name which is then repeated for every planet and moon, squashing out the detail identifying the body so you cannot see the actual number of the moon or whether it already has a colony.

If the redundant repetition of the star system name was removed from default generated names there would be enough room to see the relevant detail, if not then there is enough spare width to make the field a bit bigger too.

Title: Re: C# Suggestions
Post by: nakorkren on June 17, 2022, 10:28:51 AM
Suggest adding the ability to offer civilian shipping lines a bonus (costs the player wealth) to focus on colonizing (moving colonists and infrastructure trade goods) or fulfilling cargo move requests (Demands and Supplies on the Civilian Economy tab). This would enhance the utility of civilian shipping lines, without turning them into a fully player directed set of fleets. It would also give the player a way to subsidize growth of the civilian lines.

In a similar vein, and I think I've suggested this before, but please add the ability to have civilian lines move minerals, both a fixed amount as per normal for the Civilian Economy and on a recurring basis based on the mineral reserve limits. This would be hugely useful for large empires, not to mention realistic.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 17, 2022, 11:03:30 AM
Suggest adding the ability to offer civilian shipping lines a bonus (costs the player wealth) to focus on colonizing (moving colonists and infrastructure trade goods) or fulfilling cargo move requests (Demands and Supplies on the Civilian Economy tab). This would enhance the utility of civilian shipping lines, without turning them into a fully player directed set of fleets. It would also give the player a way to subsidize growth of the civilian lines.

Related, I've found that an issue I tend to have is that I can't really give the civilians multiple contract orders as they will only take the quickest and thus most profitable shipping run. E.g., if I want to ship 5,000 infra to Mars and 5,000 infra to Luna, the civs will ship all 5,000 infra to Luna before the first bit of infra for Mars is touched. This makes civilians require added micromanagement as I have to assign the goods demands in small increments.
Title: Re: C# Suggestions
Post by: nakorkren on June 17, 2022, 12:15:09 PM
I just had a single survey location result in two new unexplored jump gates. After exploring, they led to two different systems, but it got me thinking. It would be cool if some systems had two jump gates between them, to different points in the systems, i.e. system A and system B have two jump gates each that lead between them. This would probably by a very minor amount of impact to the game, but would add flavor/uniqueness and very rarely might reduce the effectiveness of jump gates as a choke point.
Title: Re: C# Suggestions
Post by: ZimRathbone on June 18, 2022, 06:33:34 AM
I just had a single survey location result in two new unexplored jump gates. After exploring, they led to two different systems, but it got me thinking. It would be cool if some systems had two jump gates between them, to different points in the systems, i.e. system A and system B have two jump gates each that lead between them. This would probably by a very minor amount of impact to the game, but would add flavor/uniqueness and very rarely might reduce the effectiveness of jump gates as a choke point.

I have seen this before, both systems were within the local cluster range (10 IIRC), the first one had only 2 WP initially, but the second one had seven, one of which opened a third WP back in the first system.
.
In my last game i also had two WP connected to each other in the same system, which sometimes allowed for a bit of a short cut, like LPs. 
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 18, 2022, 10:47:45 AM
I just had a single survey location result in two new unexplored jump gates. After exploring, they led to two different systems, but it got me thinking. It would be cool if some systems had two jump gates between them, to different points in the systems, i.e. system A and system B have two jump gates each that lead between them. This would probably by a very minor amount of impact to the game, but would add flavor/uniqueness and very rarely might reduce the effectiveness of jump gates as a choke point.

I have seen this before, both systems were within the local cluster range (10 IIRC), the first one had only 2 WP initially, but the second one had seven, one of which opened a third WP back in the first system.
.
In my last game i also had two WP connected to each other in the same system, which sometimes allowed for a bit of a short cut, like LPs.

Yep. As far as I know there's nothing that prevents these kinds of things from happening, at least in Random Stars games (using Real Stars you have a different method for new system generation). You can probably see such things more often by tweaking the local system generation chance and range if you really want to.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 18, 2022, 11:39:09 AM
Suggestion: Add heading option for movement orders.

Currently, for certain kinds of orders including Move and Follow, it is possible to set a minimum distance. My suggestion is that we are also able to set a preferred heading relative to the target of that order. This will make much easier a number of basic orders that currently require clumsy workarounds using Waypoints, which are imprecise and not suitable when working with moving targets.
Title: Re: C# Suggestions
Post by: ArcWolf on June 18, 2022, 12:41:19 PM
Some Sol System Updates:
1) Ultima Thule is now named 486958 Arrokoth.
2) Currently only Earth and Mars have any water present at game start. We know Enceladus & Europa are "ice Shell" worlds with "planet" spanning sub-surface oceans. Ganymede likewise has a subsurface ocean that is estimated to contain more water then Earth. Ceres is about 30% water by mass.
3) additionally, Pluto, while it's surface is 98% Nitrogen Ice, the crust is water ice and may have a liquid water ocean sub-surface. It also has a nitrogen atmosphere, although that is only .000001 atm.

I know there are many others that i did not cover, but it would be nice to see the larger Sol systems bodies that are colonization candidates have both hydrosphere and atmospheres that they posses in reality.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 18, 2022, 01:40:17 PM
Some Sol System Updates:
1) Ultima Thule is now named 486958 Arrokoth.

I like the old name better personally.

Quote
2) Currently only Earth and Mars have any water present at game start. We know Enceladus & Europa are "ice Shell" worlds with "planet" spanning sub-surface oceans. Ganymede likewise has a subsurface ocean that is estimated to contain more water then Earth. Ceres is about 30% water by mass.
3) additionally, Pluto, while it's surface is 98% Nitrogen Ice, the crust is water ice and may have a liquid water ocean sub-surface. It also has a nitrogen atmosphere, although that is only .000001 atm.

Would be nice to have just a little more reason to colonize and terraform any body in Sol besides Luna and/or Mars if that.
Title: Re: C# Suggestions
Post by: Garfunkel on June 18, 2022, 08:33:03 PM
Hey, allow tankers to move water between worlds. It would be faster than pumping in water vapor and allowing that to condense.
Title: Re: C# Suggestions
Post by: TheTalkingMeowth on June 18, 2022, 08:59:15 PM
Hey, allow tankers to move water between worlds. It would be faster than pumping in water vapor and allowing that to condense.
Would it be faster?

Earth's water is estimated at 1E18 metric tons, or basically the same # in cubic meters of volume as a liquid. 1 "ton" of cargo space is really 11 m^3 of volume, yes? So to move an Earth equivalent amount of water, we need 9E16 tons of lift, or 1.8E12 standard cargo holds. It takes, what, 11 days to unload a standard bay with conventional shuttles? We thus require 5.7E10 module-years just to unload, not counting travel OR loading time.

By contrast, it takes 1.775 atm of water vapor to condense 71% coverage. This is 7100 module-years at base tech.
Title: Re: C# Suggestions
Post by: nakorkren on June 18, 2022, 10:34:31 PM
It would be really fun and flavorful to be able to play aquatic and/or "aero" races (ala the Qanska from the book "Manta's Gift"), with the associated changes to planet pop cap calculations and infrastructure need calculations.

E.g. an aquatic race wouldn't care (much) about atmospheric makeup, just temperature and % hydrosphere, and planet pop cap would be linear with % hydrosphere instead of decreasing at high % hydro. Likewise an "aero" race that drifts within the dense gas clouds wouldn't care about % hydrosphere.

I think adding a check-box during race setup to enable those two "templates" in addition to normal land-dwellers would add some variety to what types of planets are of interest to those races and how they terraform planets that are close to tolerable.
Title: Re: C# Suggestions
Post by: Garfunkel on June 19, 2022, 04:50:26 AM
Hey, allow tankers to move water between worlds. It would be faster than pumping in water vapor and allowing that to condense.
Would it be faster?

Earth's water is estimated at 1E18 metric tons, or basically the same # in cubic meters of volume as a liquid. 1 "ton" of cargo space is really 11 m^3 of volume, yes? So to move an Earth equivalent amount of water, we need 9E16 tons of lift, or 1.8E12 standard cargo holds. It takes, what, 11 days to unload a standard bay with conventional shuttles? We thus require 5.7E10 module-years just to unload, not counting travel OR loading time.

By contrast, it takes 1.775 atm of water vapor to condense 71% coverage. This is 7100 module-years at base tech.
Ah I didn't meant to transport the equivalent mass of Earth's water, but using tankers when they aren't busy to transport water from Europa, for example, to Mars in early game.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 19, 2022, 09:06:26 AM
Ah I didn't meant to transport the equivalent mass of Earth's water, but using tankers when they aren't busy to transport water from Europa, for example, to Mars in early game.

I think the gist was that the mass of water required is so many orders of magnitude beyond what tankers can realistically move that it doesn't make a lot of sense. You'd end up implementing a feature that could make maybe 0.000001% difference in your terraforming ability.
Title: Re: C# Suggestions
Post by: Sebmono on June 19, 2022, 01:43:12 PM
You'd end up implementing a feature that could make maybe 0.000001% difference in your terraforming ability.
On that note, if we wanted to talk about adding something !fun! that could still impact terraforming, let us attach engines to asteroids/comets and crash them into planets to transfer water ice and other minerals  ;D
Title: Re: C# Suggestions
Post by: Garfunkel on June 19, 2022, 07:12:53 PM
Yeah, using asteroids for terraforming would be sweet.

I think the gist was that the mass of water required is so many orders of magnitude beyond what tankers can realistically move that it doesn't make a lot of sense. You'd end up implementing a feature that could make maybe 0.000001% difference in your terraforming ability.
Yeah I guess, I hadn't crunched the numbers at all.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 19, 2022, 08:32:46 PM
You'd end up implementing a feature that could make maybe 0.000001% difference in your terraforming ability.
On that note, if we wanted to talk about adding something !fun! that could still impact terraforming, let us attach engines to asteroids/comets and crash them into planets to transfer water ice and other minerals  ;D

Every time someone suggests this, someone else comes in and talks about why even the smallest asteroids in Aurora are too massive to be propelled by race-constructible engines within any realistic timeframe. Fortunately for me, it is usually someone else so I do not have to do the math.  8)
Title: Re: C# Suggestions
Post by: xenoscepter on June 23, 2022, 01:41:29 AM
 --- Multiplayer feature suggestion: SM Password Additions. So, basically, players could add something onto the SM Password, thus facilitating the ability for each player to possess only a piece of the complete SM Password. Thusly, the SM could also play the game themselves and remain impartial, since anything requiring SM privileges would require every piece of the code and it could then... presumably, be reset afterwards.
Title: Re: C# Suggestions
Post by: KriegsMeister on June 25, 2022, 10:05:56 AM
Could we get non-Gregorian Calender options, ideally in the form of a fully editable time system. The game already calculates all time as just chunks of seconds so allowing us to decide what those chunks are. Would be great for Non-sol/earth or alien species games, or maybe a future earth government just decided on a more sensible Calender of 30 day months and a 5 day holiday between December 30th and January 1st, or if someone wanted an ancient Greek or Egyptian start.

I could see merit in keeping minutes, hours, and days as fixed to not have to change the time step buttons, but giving us the ability to rename and edit the months and year would be great.

Title: Re: C# Suggestions
Post by: skoormit on June 25, 2022, 01:47:40 PM
For a civilian shipping delivery that starts and ends in the same system, the shipping line pays tax equal to half the single-hop amount.
This is too much.
The typical distance between large populations in a single system is much less than half the typical distance per hop between large populations in separate systems.
It's probably closer to one tenth.
As a result, the number of easy colony locations in your starting system has an outsized impact on your wealth development.
Systems like Sol, which have multiple low-cost, easily terraformable colony prospects, generate so much early wealth via civilian shipping that the player's strategic decisions for the entire game are only very rarely impacted by wealth concerns. The player gets rich fast by developing those home system colonies, and then never has to worry about wealth again.
If you start in a system without easy colony prospects, you don't enjoy this early source of easy wealth, and as a result you actually do have to manage your spending wisely, and devote non-trivial research and production to increasing your tax income.

I suggest dropping the intra-system civ tax to either 10% or 20% of the single-hop rate.
Title: Re: C# Suggestions
Post by: nuclearslurpee on June 25, 2022, 02:31:10 PM
For a civilian shipping delivery that starts and ends in the same system, the shipping line pays tax equal to half the single-hop amount.
This is too much.
The typical distance between large populations in a single system is much less than half the typical distance per hop between large populations in separate systems.
It's probably closer to one tenth.
As a result, the number of easy colony locations in your starting system has an outsized impact on your wealth development.
Systems like Sol, which have multiple low-cost, easily terraformable colony prospects, generate so much early wealth via civilian shipping that the player's strategic decisions for the entire game are only very rarely impacted by wealth concerns. The player gets rich fast by developing those home system colonies, and then never has to worry about wealth again.
If you start in a system without easy colony prospects, you don't enjoy this early source of easy wealth, and as a result you actually do have to manage your spending wisely, and devote non-trivial research and production to increasing your tax income.

I suggest dropping the intra-system civ tax to either 10% or 20% of the single-hop rate.

I don't see this as a problem.

The way things work presently, CSL taxes provide a useful incentive to develop single systems instead of expanding to as many systems as possible with only 1-2 major colonies and automated/asteroid mining operations in each one. Without such an incentive, rapid expansion is clearly the best decision as much as your empire can support it. Turtling up in a single system means leaving a lot of galactic exploration up to the NPRs and leaving yourself open to discovery by an advanced race before you are ready to expand, so there should be some real benefits. This is especially true if you start in Sol, which is programmed by Steve to have fewer minerals than other similar systems as a way to push the player away from Sol sooner rather than later.

Personally, I support having mechanics which avoid creating a single optimal strategy and instead create interesting decisions, even if those mechanics might not be perfectly "realistic". I do also consider having to adapt a different strategy for different starting conditions a key part of Aurora's gameplay, so I don't consider that having a system with worse colonization prospects forces the player to devote points towards income increase a problem at all. To me this is like saying that if a race starts in a system with JPs 10b km apart they have to put more fuel into their ships than a race starting in a system with JPs 500m km apart - this is true, and it's arguably even unfair, but it's part of the Aurora DNA to have to adapt to such circumstances.
Title: Re: C# Suggestions
Post by: skoormit on June 25, 2022, 04:17:42 PM
To me this is like saying that if a race starts in a system with JPs 10b km apart they have to put more fuel into their ships than a race starting in a system with JPs 500m km apart - this is true, and it's arguably even unfair, but it's part of the Aurora DNA to have to adapt to such circumstances.

The difference is that having JPs close together in your home system does not completely obviate all fuel constraints for the rest of the game. It's a big advantage, no doubt, but you will still have to make interesting decisions about fuel production, consumption, and ship design throughout the game.

With the current tax rate on intra-system civ deliveries, if you start your game with multiple CC 2.0 colonies in your home system, you will probably almost never have to think about wealth in this game.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on June 29, 2022, 03:32:38 AM
Two things...

1. Please make it possible to edit total empire Wealth using SM. Could place that button on the "Wealth/Trade" screen. When you play multi-faction gamed Wealth can be used as method of payment for many things.

2. Please add a dynamic Waypoint connected to a fleet. That is a Waypoint you put on the map that moves in relation to a specific fleet. This would be very useful for having a patrolling escort around a fleet as it moves along. There could be two types. One that orient itself depending on what course the fleet have and another that just is in relation to the fleet as it is placed no matter what direction it moves at.
Title: Re: C# Suggestions
Post by: GrandNord on June 29, 2022, 05:27:54 AM
For the 2 you can already do that with fleet formation.  You can attach a fleet to another one in system and choose its distance and angle compared to the target fleet, as well as some conditions in which the fleet will go in the specified formation (a threat in the system for example). 
Title: Re: C# Suggestions
Post by: Jorgen_CAB on June 29, 2022, 06:50:20 AM
For the 2 you can already do that with fleet formation.  You can attach a fleet to another one in system and choose its distance and angle compared to the target fleet, as well as some conditions in which the fleet will go in the specified formation (a threat in the system for example).

I know you can do that with fleet formations... it is not really the same thing though... I want to be able to patrol between points and still follow a fleet. It will also be easier to make controlled patrol orders around a fleet that way. With automatic docking and undocking as part of a patrol pattern etc.. You could automate rotational patrol by several different recon crafts in a way you currently can't do.
Title: Re: C# Suggestions
Post by: hostergaard on June 29, 2022, 07:48:56 AM
Construct all components for ship option

Quality of life feature: Add an option under the industry, either in the components selection or preferably as its own separate  list that allows you to simply construct all components for a given ship class. This so you don't have to constantly go trough and figure out what components is needed and individually build them.

Title: Re: C# Suggestions
Post by: Steve Zax on July 01, 2022, 06:22:33 AM
Quote from: hostergaard link=topic=10640. msg160499#msg160499 date=1656506936
Construct all components for ship option

Quality of life feature: Add an option under the industry, either in the components selection or preferably as its own separate  list that allows you to simply construct all components for a given ship class.  This so you don't have to constantly go trough and figure out what components is needed and individually build them.
i USED to do that for EVRY ship of EVERY class, then EVERY ship of warship classes, then the FIRST run of every warship class. . . .
i rarely do it now.  just too many other things i need to do with the industry instead of letting the shipyard do it.  I know its "quicker," I'm pretty sure its not cheaper on resources, maybe its cheaper on wealth, but I doubt it, but BOY HOWDY is it more on micromanagement ( especially if you want each component to be ready on time , and not early).
Title: Re: C# Suggestions
Post by: Scandinavian on July 01, 2022, 12:59:36 PM
It's only faster in terms of keellaying-to-deployment. Not in terms of vessels per year per unit of TN capital investment.

It's potentially very useful if you are waiting on a specific new component before laying a bunch of keels for a new class, that you need really urgently. E.g. pre-building the engines for a class that you can't lay keels for because the fire control designs are not ready yet, or pre-building components while you tool up the yards. But in terms of sustained production, you are better off expanding yard capacity than factory capacity.

There is some tradeoff in that factories typically have higher utilization than yards (you can use factories for other things when not in a shipbuilding program), so if you tend to build your ships in spurts with long idle periods for your yards, it can be worth it to take the higher up-front cost of capital to end up with lower levelized cost through higher utilization. But building that kind of models is a thing I insist on getting paid for, so I usually don't break out the spreadsheets and instead just eyeball it.

Which, actually now that I think about it...

... why not let shipyards perform overhauls? That would let us use unused yard slips to free up maintenance facilities, and would certainly be a thing you would do in the real world during a shipbuilding downturn.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 01, 2022, 01:06:22 PM
It's only faster in terms of keellaying-to-deployment. Not in terms of vessels per year per unit of TN capital investment.

It's potentially very useful if you are waiting on a specific new component before laying a bunch of keels for a new class, that you need really urgently. E.g. pre-building the engines for a class that you can't lay keels for because the fire control designs are not ready yet, or pre-building components while you tool up the yards. But in terms of sustained production, you are better off expanding yard capacity than factory capacity.

There is some tradeoff in that factories typically have higher utilization than yards (you can use factories for other things when not in a shipbuilding program), so if you tend to build your ships in spurts with long idle periods for your yards, it can be worth it to take the higher up-front cost of capital to end up with lower levelized cost through higher utilization. But building that kind of models is a thing I insist on getting paid for, so I usually don't break out the spreadsheets and instead just eyeball it.

This is generally correct, in times of no great need the most efficient use of planetary industry will be to build up shipbuilding industry rather than using it to rush-order ships. IMO, the major use case for building components is as wartime industry when you need every one of tomorrow's hulls in space yesterday - although against NPRs this is admittedly a rare occurrence. Otherwise I occasionally use component build to rush one or two ships that I have an urgent need for, e.g., a diplo ship if I have none available to make good relations with a NPR I don't want to fight (yet).

Quote
Which, actually now that I think about it...

... why not let shipyards perform overhauls? That would let us use unused yard slips to free up maintenance facilities, and would certainly be a thing you would do in the real world during a shipbuilding downturn.

I don't think maintenance facilities are "taken up" for overhauls, so you're not freeing up any capacity, thus there isn't a mechanical reason to implement this.
Title: Re: C# Suggestions
Post by: Scandinavian on July 01, 2022, 01:21:17 PM
Maintenance facilities are taken up by maintaining the ship during overhaul - if you have an idle slip, two 6,000 ton patrol boats, and 15,000 tons of maintenance facilities, then both your non-overhauling patrol boats will start to accrue maintenance clock when you bring in your third patrol boat for overhaul.

It didn't use to work that way in VB6, because maintenance facilities had unlimited capacity subject to a size cap. But in C# maintenance facilities provide tonnage capacity, not berth size.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 01, 2022, 01:32:06 PM
Maintenance facilities are taken up by maintaining the ship during overhaul - if you have an idle slip, two 6,000 ton patrol boats, and 15,000 tons of maintenance facilities, then both your non-overhauling patrol boats will start to accrue maintenance clock when you bring in your third patrol boat for overhaul.

It didn't use to work that way in VB6, because maintenance facilities had unlimited capacity subject to a size cap. But in C# maintenance facilities provide tonnage capacity, not berth size.

Okay, I can see where there might be some reason. Honestly, I always try to keep my maintenance facilities numerous enough to support my entire fleet so I can keep them at base when not doing navy business, plus I rotate deployments frequently so the number of ships at home base is fairly constant, so this is never a problem for me. Do other folks frequently outbuild their maintenance capacity?
Title: Re: C# Suggestions
Post by: KriegsMeister on July 01, 2022, 02:43:48 PM
It would be nice to be able to utilize component stockpiles for repairs rather than just construction and refits. Possibly with a reduction of MSP costs and a significant time reduction. Depending on components it may  not be materially advantageous such as gallicite for engines, but would quite useful for times of war having forward bases stocked up for rapid repairs to get ships back in the fight.
Title: Re: C# Suggestions
Post by: Scandinavian on July 01, 2022, 06:19:05 PM
Honestly, I always try to keep my maintenance facilities numerous enough to support my entire fleet so I can keep them at base when not doing navy business, plus I rotate deployments frequently so the number of ships at home base is fairly constant, so this is never a problem for me. Do other folks frequently outbuild their maintenance capacity?
I frequently end up overbuilding my shipyard capacity during my fleet renewal programs, after which they fall into idleness because I don't have the minerals to fully utilize them. If (to take an implementation that would not add to micro) idle naval slipways would add some percentage of their tonnage to maintenance capacity, I could build fewer maintenance facilities. (The same thing happens with commercial yards, but I always imagine them churning out ships for the civilian liners, so that is less of an imposition on suspension of disbelief.)
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 01, 2022, 07:12:21 PM
Isn't there always this balance of what we want and what we need... ;)

I generally try to keep my Naval yards to reasonable levels of capacity as I don't want to waste materials too rashly. You sometimes just thing that you have to expand your yards capacity none stop, either size or more yards just because you can.

In general I don't think that yards should build itself, I think industry on the planet should do that. It becomes weird when a yard can both build ships and expand at the same time.
Title: Re: C# Suggestions
Post by: idefelipe on July 03, 2022, 05:51:11 AM
Hey Steve.

How difficult would it be to implement a system that would allow a ship component to change ownership? I personally would like to encourage RP between nations (trade exchanges) or to create small nations to simulate companies (and build for other larger nations components) or for multiplayer games (like the one we are playing here (http://aurora2.pentarch.org/index.php?topic=12895.0)).

Thanks!

Title: Re: C# Suggestions
Post by: Steve Walmsley on July 03, 2022, 06:04:12 AM
2. Please add a dynamic Waypoint connected to a fleet. That is a Waypoint you put on the map that moves in relation to a specific fleet. This would be very useful for having a patrolling escort around a fleet as it moves along. There could be two types. One that orient itself depending on what course the fleet have and another that just is in relation to the fleet as it is placed no matter what direction it moves at.

This ability is already provided by the escort functionality on the Naval Organization window.
Title: Re: C# Suggestions
Post by: skoormit on July 03, 2022, 06:11:45 AM
2. Please add a dynamic Waypoint connected to a fleet. That is a Waypoint you put on the map that moves in relation to a specific fleet. This would be very useful for having a patrolling escort around a fleet as it moves along. There could be two types. One that orient itself depending on what course the fleet have and another that just is in relation to the fleet as it is placed no matter what direction it moves at.

This ability is already provided by the escort functionality on the Naval Organization window.

Sort of. I think OP is asking for an option for having an escort position that moves relative to the anchor fleet, rather than is fixed in position relative to the anchor.

For example, a forward scout position that moves back and forth, at some distance from the anchor, between anchor heading +30 and anchor heading -30.
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 03, 2022, 06:12:28 AM
1. Please make it possible to edit total empire Wealth using SM. Could place that button on the "Wealth/Trade" screen. When you play multi-faction gamed Wealth can be used as method of payment for many things.

I've added an SM-only Edit Wealth button to the Wealth/Trade tab of the economics window.
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 03, 2022, 06:14:25 AM
2. Please add a dynamic Waypoint connected to a fleet. That is a Waypoint you put on the map that moves in relation to a specific fleet. This would be very useful for having a patrolling escort around a fleet as it moves along. There could be two types. One that orient itself depending on what course the fleet have and another that just is in relation to the fleet as it is placed no matter what direction it moves at.

This ability is already provided by the escort functionality on the Naval Organization window.

Sort of. I think OP is asking for an option for having an escort position that moves relative to the anchor fleet, rather than is fixed in position relative to the anchor.

Aren't they the same thing? With formation orders, if the Anchor fleet moves, the escort fleet moves either relative to the Anchor fleet or to maintain position between the Anchor fleet and a chosen target, depending on the orders.
Title: Re: C# Suggestions
Post by: skoormit on July 03, 2022, 06:15:12 AM
2. Please add a dynamic Waypoint connected to a fleet. That is a Waypoint you put on the map that moves in relation to a specific fleet. This would be very useful for having a patrolling escort around a fleet as it moves along. There could be two types. One that orient itself depending on what course the fleet have and another that just is in relation to the fleet as it is placed no matter what direction it moves at.

This ability is already provided by the escort functionality on the Naval Organization window.

Sort of. I think OP is asking for an option for having an escort position that moves relative to the anchor fleet, rather than is fixed in position relative to the anchor.

Aren't they the same thing? With formation orders, if the Anchor fleet moves, the escort fleet moves either relative to the Anchor fleet or to maintain position between the Anchor fleet and a chosen target, depending on the orders.

I edited my post above and added an example to clarify.
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 03, 2022, 06:16:12 AM
I edited my post above and added an example to clarify.

Yes, I understand now after reading a subsequent post in the thread. Thanks.
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 03, 2022, 07:00:04 AM
Some Sol System Updates:
1) Ultima Thule is now named 486958 Arrokoth.
2) Currently only Earth and Mars have any water present at game start. We know Enceladus & Europa are "ice Shell" worlds with "planet" spanning sub-surface oceans. Ganymede likewise has a subsurface ocean that is estimated to contain more water then Earth. Ceres is about 30% water by mass.
3) additionally, Pluto, while it's surface is 98% Nitrogen Ice, the crust is water ice and may have a liquid water ocean sub-surface. It also has a nitrogen atmosphere, although that is only .000001 atm.

I know there are many others that i did not cover, but it would be nice to see the larger Sol systems bodies that are colonization candidates have both hydrosphere and atmospheres that they posses in reality.

I agree this would add some extra dimension to exploring Sol. However, bodies such as Enceladus, Ceres and Pluto have too little gravity in Aurora terms (< 0.1G) to hold an atmosphere so the presence of water wouldn't help. I will add some water to Europa and Ganymede though.

Also, at the moment Aurora will not generate a hydrosphere without at least a trace atmosphere. I may add some chance of frozen water on cold bodies above 0.1G even if they have no atmosphere.
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 03, 2022, 08:00:21 AM
It would be helpful if the fleet order queue had time estimates for each step in the queue. I assume this data is already being estimated, since there's a total time estimate at the top, and it would be great to know how long each step is going to take even if it's a rough estimate.

That would be nice, but I don't think that estimates are being calculated for each step.
The total estimate is just the total distance traveled divided by the speed of the fleet.
Time required for non-movement orders (refueling, loading/unloading, etc) is not included in the time estimate, nor is any time added to the estimate for orders that have time delays.

Yes, that's correct.
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 03, 2022, 08:14:29 AM
Suggest removing the star system name for moons and planets in the second field of the mineral search.

Currently the first field in the row provides star system name which is then repeated for every planet and moon, squashing out the detail identifying the body so you cannot see the actual number of the moon or whether it already has a colony.

If the redundant repetition of the star system name was removed from default generated names there would be enough room to see the relevant detail, if not then there is enough spare width to make the field a bit bigger too.

I've removed the star system name for moons and planets in the second field of the mineral search as suggested.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 03, 2022, 08:38:53 AM
2. Please add a dynamic Waypoint connected to a fleet. That is a Waypoint you put on the map that moves in relation to a specific fleet. This would be very useful for having a patrolling escort around a fleet as it moves along. There could be two types. One that orient itself depending on what course the fleet have and another that just is in relation to the fleet as it is placed no matter what direction it moves at.

This ability is already provided by the escort functionality on the Naval Organization window.

Sort of. I think OP is asking for an option for having an escort position that moves relative to the anchor fleet, rather than is fixed in position relative to the anchor.

Aren't they the same thing? With formation orders, if the Anchor fleet moves, the escort fleet moves either relative to the Anchor fleet or to maintain position between the Anchor fleet and a chosen target, depending on the orders.

Yes... the intention would be to have a scout or recon move between two or several points as a fleet moves along in a pattern. Instead of having them just move in relation to the fleet at one particular spot.

I play "Command: Modern Operations" and they have something similar that is very useful for operating recon aircraft or helicopters in relation to a task-group of ships. In that game you can select to have points that is either moving in relation with the fleet at a fixed offset of the fleet no matter the direction the fleet is heading or the point is always in a direction in relation to the direction the fleet is moving, both are useful for different reasons.

In "Command: Modern Operations" you can designate a zone where helicopters are searching for submarines for example. Or you designate a radar plane to conduct patrol between two points.

Another thing that might be good in the future would be if escorts (who are attached to a mothership) around fleets could automatically refuel and go back to its previous orders too, so you don't have to constantly babysit them. Or, that you can designate three scout craft to a mission but only have one of them on station at any one time, when one is either out of fuel or deployment time it returns and send out another one.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 03, 2022, 08:42:23 AM
Hey Steve.

How difficult would it be to implement a system that would allow a ship component to change ownership? I personally would like to encourage RP between nations (trade exchanges) or to create small nations to simulate companies (and build for other larger nations components) or for multiplayer games (like the one we are playing here (http://aurora2.pentarch.org/index.php?topic=12895.0)).

Thanks!

You could do this in the old VB Aurora, I hope Steve will add something similar to C# eventually. I use this all the time in my game. One faction might build a certain component and the export that to other factions. You also should be able to transfer the component technology so other factions can license build those components.

You can still do it in C# Aurora but you have to use SM to get all the needed tech, design the component and then delete the tech the factions don't actually have. The other faction then produce the components and you use SM to destroy them and add them to the correct faction. It could be made allot simpler.
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 03, 2022, 11:22:32 AM
Hey Steve.

How difficult would it be to implement a system that would allow a ship component to change ownership? I personally would like to encourage RP between nations (trade exchanges) or to create small nations to simulate companies (and build for other larger nations components) or for multiplayer games (like the one we are playing here (http://aurora2.pentarch.org/index.php?topic=12895.0)).

Thanks!

You could do this in the old VB Aurora, I hope Steve will add something similar to C# eventually. I use this all the time in my game. One faction might build a certain component and the export that to other factions. You also should be able to transfer the component technology so other factions can license build those components.

I've added component and ordnance transfers for v2.0.

The component tech itself might be abusable, because you could build the component and then disassemble it.
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 03, 2022, 12:34:07 PM
Top of my suggestion list would be edit for orders.

I know it would be harder than it sounds as the orders are contextual, one following on from the context of the preceding order, but I think it might be possible to edit at a pointer in the order stack to insert or remove an order based on the preceding order as context and then remember the rest of the stack and add them back one by one when the edit is done with a context check on each as it is added back using the existing context subroutines. If a context is detectably broken, then the order would go red and if a break occurs during gameplay then you get the same as is currently the case and a message saying ShipX cannot complete order.

Would also be nice (in C#) to be able to add / insert chunks of template based on the preceding order context rather than current context of the ship being ordered, which I recall was different in VB6 so I am sure you know what I mean. Must be practicalities I am not aware of but just thought I would mention it.

Its just giving orders is such a substantial part of the way Aurora plays it strikes me it would be worth adding order queue edit and imagine that Steve would enjoy the result for his own QoL, so just airing the thought since this is the suggestions thread. :)

This is massively more complex than it sounds and I would spend years encountering related bugs for situations I hadn't considered. I'm not going into all the complexities here, but suffice to say despite the regular requests, this is extremely unlikely to happen.
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 03, 2022, 01:15:28 PM
I have a small suggestion that would probably be very useful:
On the left side of the Class Design window, where it lists all your ship designs, put in brackets an "(o)" next to the names of classes that use components that are marked as obsolete.
Alternatively, the names of the ships with obsolete components could be given a colour like red or yellow and when clicking on one of those ships and then on the "class components" tab, the obsolete components could also be highlighted in that colour. That would be nice, too.

Edit:
Similarly, unlocked class designs should also have either an "(u)" next to their name or have a different colour for their name.

I've added a change on these lines:
http://aurora2.pentarch.org/index.php?topic=12523.msg160549#msg160549

There is a new checkbox that will highlight classes with obsolete components in orange. This will likely be a large majority of classes in most cases which is why I included the checkbox.
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 03, 2022, 01:31:56 PM
With the upcoming changes to fighter management likely to make fighters much less micro-intensive, I am using fighters in my current 1.13 game to learn the ropes. One thing I've noticed is really tedious is having to manually set each and every fighter to "Automated Damage Control", as they apparently all start with that unchecked.

Would it be possible to make the default for "Automated Damage Control" to be checked? Or in the Ship Design window, add an option under the Misc tab to toggle the default for Damage Control behavior to be automated or not on a class-wide basis, which when toggled would overwrite any individual ship settings? That would allow people to make mass changes with a minimum of tedium, while still permitting granular control by ship if desired.

I've made Automated Damage Control the default for new ships. It can be unset by players as needed for detailed control.
Title: Re: C# Suggestions
Post by: Snoman314 on July 03, 2022, 01:40:14 PM
Quote from: hostergaard link=topic=10640. msg160499#msg160499 date=1656506936
Construct all components for ship option

Quality of life feature: Add an option under the industry, either in the components selection or preferably as its own separate  list that allows you to simply construct all components for a given ship class.  This so you don't have to constantly go trough and figure out what components is needed and individually build them.

The hours that this would save! Yes please! I could retire my spreadsheet where I manually enter the components for each class, and the planned construction for each class, to work out how many of each component I need!

I'd just add that I'd want to be able to enter a number of ships to get multiples of the required components.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 03, 2022, 05:42:50 PM
Hey Steve.

How difficult would it be to implement a system that would allow a ship component to change ownership? I personally would like to encourage RP between nations (trade exchanges) or to create small nations to simulate companies (and build for other larger nations components) or for multiplayer games (like the one we are playing here (http://aurora2.pentarch.org/index.php?topic=12895.0)).

Thanks!

You could do this in the old VB Aurora, I hope Steve will add something similar to C# eventually. I use this all the time in my game. One faction might build a certain component and the export that to other factions. You also should be able to transfer the component technology so other factions can license build those components.

I've added component and ordnance transfers for v2.0.

The component tech itself might be abusable, because you could build the component and then disassemble it.

Abusing it really is not a problem when you play against yourself...  ;)

Some faction might actually do that, happens in the real world too. But they have to live with the consequences of breaking contract etc...
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 03, 2022, 11:37:10 PM
I've added component and ordnance transfers for v2.0.

The component tech itself might be abusable, because you could build the component and then disassemble it.

Imperial Japanese license building intensifies

Great changes to see coming down the pipeline, simple QoL that will make gameplay a lot smoother!
Title: Re: C# Suggestions
Post by: Coleslaw on July 04, 2022, 10:55:40 AM
Something I suggested somewhere but don't remember where:

Could Fire At Will automatically reassign a new target once it destroys its current target? I'm not the kind of player who likes to micromanage massive battles (especially when hundreds of fighters are involved.) I tend to tick the Fire At Will box and pretend that everything the fleet is doing is the admiral's orders.  However, every time a ship on Fire At Will destroys its target, it's out of the fight so to speak because it doesn't re-target, and when there's lots of ships, it's hard to tell who is and isn't firing like they should be.

Also, in a fleet's ship combat screen, could identical components be stacked? I.e., rather than a ship combat screen reading:

Beam Fire Control
  Twin Laser Turret
  Twin Laser Turret
  Twin Laser Turret
  Twin Laser Turret
  Twin Laser Turret
  Twin Laser Turret

It instead reads:

Beam Fire Control
  x6 Twin Laser Turret

There could also be option that allows you to assign a specific number to a fire control, kind of like how you can assign a specific number of units from ground formations. This would especially help with missile ships that have to have a massive amount of missiles launchers to be effective.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 04, 2022, 11:29:50 AM
Something I suggested somewhere but don't remember where:

Could Fire At Will automatically reassign a new target once it destroys its current target? I'm not the kind of player who likes to micromanage massive battles (especially when hundreds of fighters are involved.) I tend to tick the Fire At Will box and pretend that everything the fleet is doing is the admiral's orders.  However, every time a ship on Fire At Will destroys its target, it's out of the fight so to speak because it doesn't re-target, and when there's lots of ships, it's hard to tell who is and isn't firing like they should be.

Also, in a fleet's ship combat screen, could identical components be stacked? I.e., rather than a ship combat screen reading:

Beam Fire Control
  Twin Laser Turret
  Twin Laser Turret
  Twin Laser Turret
  Twin Laser Turret
  Twin Laser Turret
  Twin Laser Turret

It instead reads:

Beam Fire Control
  x6 Twin Laser Turret

There could also be option that allows you to assign a specific number to a fire control, kind of like how you can assign a specific number of units from ground formations. This would especially help with missile ships that have to have a massive amount of missiles launchers to be effective.

Completely agreed.

Additionally, it would generally be preferable if the automatic FC assignment only assigned one type of weapon per FC, since this is the usual way of managing multiple-weapon ships. I keep having to fix auto-assignments where, say, 6 particle beams and 10 railguns are split between 4 fire controls in a 6PB/2PB+2RG/4RG/4RG split when I really want 3PB/3PB/5RG/5RG.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 04, 2022, 02:15:47 PM
Something I suggested somewhere but don't remember where:

Could Fire At Will automatically reassign a new target once it destroys its current target? I'm not the kind of player who likes to micromanage massive battles (especially when hundreds of fighters are involved.) I tend to tick the Fire At Will box and pretend that everything the fleet is doing is the admiral's orders.  However, every time a ship on Fire At Will destroys its target, it's out of the fight so to speak because it doesn't re-target, and when there's lots of ships, it's hard to tell who is and isn't firing like they should be.

I also want to use this feature as much as possible as I find it a bit unrealistic to have perfect coordination in most beam combat situations. Some manual targeting is OK, but I think that mostly "Fire at Will" are the best way to go. It also reduce micromanagement which is a bonus.

I also think that "Fire at Will" needs to be able to re-target even if the original target is not destroyed. The situation may change as the target ship retreats and other ships close in.
Title: Re: C# Suggestions
Post by: Destragon on July 04, 2022, 02:41:34 PM
I have a small suggestion that would probably be very useful:
On the left side of the Class Design window, where it lists all your ship designs, put in brackets an "(o)" next to the names of classes that use components that are marked as obsolete.
Alternatively, the names of the ships with obsolete components could be given a colour like red or yellow and when clicking on one of those ships and then on the "class components" tab, the obsolete components could also be highlighted in that colour. That would be nice, too.

Edit:
Similarly, unlocked class designs should also have either an "(u)" next to their name or have a different colour for their name.

I've added a change on these lines:
http://aurora2.pentarch.org/index.php?topic=12523.msg160549#msg160549

There is a new checkbox that will highlight classes with obsolete components in orange. This will likely be a large majority of classes in most cases which is why I included the checkbox.
Hell yeah, thanks Steve.

Construct all components for ship option

Quality of life feature: Add an option under the industry, either in the components selection or preferably as its own separate  list that allows you to simply construct all components for a given ship class. This so you don't have to constantly go trough and figure out what components is needed and individually build them.
I've wanted this, too. I may have also suggested it in the past.
Title: Re: C# Suggestions
Post by: Sebmono on July 04, 2022, 10:01:27 PM
Completely agreed.

Additionally, it would generally be preferable if the automatic FC assignment only assigned one type of weapon per FC, since this is the usual way of managing multiple-weapon ships. I keep having to fix auto-assignments where, say, 6 particle beams and 10 railguns are split between 4 fire controls in a 6PB/2PB+2RG/4RG/4RG split when I really want 3PB/3PB/5RG/5RG.
I actually wouldn't like a change in behavior of the auto FC assignment in this way, as in most of my large multi-weapon platforms I do want even distribution across FCs so that I can apply the same groupings of firepower to multiple targets at once and reduce target switching. Not to say that my way is "right" or preferable, just that changing this behavior would probably move the cheese for some others.

As an alternative I would re-raise a request I've made before to add the ability to specify FC-weapom assignment at the design template level, much like we can define missile and parasite loadouts already. This would essentially remove the need for the auto assign FC micro and allow us to do it up front just once for each design. It would also still leave the option of multiple FC configurations per design if the player so chooses, just by making an identical copy where the only difference is the FC assignment.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 05, 2022, 12:36:22 AM
Completely agreed.

Additionally, it would generally be preferable if the automatic FC assignment only assigned one type of weapon per FC, since this is the usual way of managing multiple-weapon ships. I keep having to fix auto-assignments where, say, 6 particle beams and 10 railguns are split between 4 fire controls in a 6PB/2PB+2RG/4RG/4RG split when I really want 3PB/3PB/5RG/5RG.
I actually wouldn't like a change in behavior of the auto FC assignment in this way, as in most of my large multi-weapon platforms I do want even distribution across FCs so that I can apply the same groupings of firepower to multiple targets at once and reduce target switching. Not to say that my way is "right" or preferable, just that changing this behavior would probably move the cheese for some others.

I appreciate the alternative take, but I have to ask - does the auto-FC assignment work this way anyways? If I have, say, 3 BFCs, 3 particle beams, and 6 railguns, I don't think the auto-assign button would set it up to be three sets of 1PB+2RG? Ideally the behavior should be something sensible, whether in line with your playstyle or mine I don't think is too important, but either way is more sensible than what currently happens.

I will say that I have also noticed an issue when using spinal lasers and a SW fire control, often the spinal laser will be grouped under a multi-weapon BFC and a "regular" laser assigned to the SW fire control - I think the algorithm should be smart enough to tell the difference between SW and regular fire controls and make the assumption here.
Title: Re: C# Suggestions
Post by: TallTroll on July 05, 2022, 01:20:35 PM
>> I think the algorithm should be smart enough to tell the difference between SW and regular fire controls and make the assumption here.

How about having default assignments set at the class level? Overridden by any manual or automated assignment for a ship in live combat, because sometimes there are situational circumstances, but at the time of class design, you know what the standard assignments you will want are
Title: Re: C# Suggestions
Post by: Voltbot on July 05, 2022, 06:42:00 PM
Idea - booster.
   Component, that is basically an engine, that can be put in addition to normal engines and can be turned off to not affect fuel usage, but is stupidly ineffective, like 3x fuel consumption.
Idea is, this component can be mounted on warships to make them rather fuel efficient when not in combat, but have good speed when in combat.
   I know I can do this with tugs or carriers, but it would be great for patrol ships, tat needs some combat power, while being cheap to produce.
   To make it even less attractive to put on every warship it could be able to overheat (get destroyed) after some time of constant usage.
   For programming simplicity it could be created, that it isn't throttable (I don't know if this is right word. It's used in KSP in this context) i.e. It can either be turned off, or work at 100%. It couldn't be able to be set to other values, like 50%.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 05, 2022, 08:27:54 PM
Idea - booster.
   Component, that is basically an engine, that can be put in addition to normal engines and can be turned off to not affect fuel usage, but is stupidly ineffective, like 3x fuel consumption.
Idea is, this component can be mounted on warships to make them rather fuel efficient when not in combat, but have good speed when in combat.
   I know I can do this with tugs or carriers, but it would be great for patrol ships, tat needs some combat power, while being cheap to produce.
   To make it even less attractive to put on every warship it could be able to overheat (get destroyed) after some time of constant usage.
   For programming simplicity it could be created, that it isn't throttable (I don't know if this is right word. It's used in KSP in this context) i.e. It can either be turned off, or work at 100%. It couldn't be able to be set to other values, like 50%.

It might be too complicated and/or "ship-focused" for Aurora (I think Steve has said he prefers the game to be focused on fleets more than individual ships, though I could very well be incorrect), but I also would like something like this. I would love to see something that resembles the military/commercial engine split in Starfire which I thought made for some interesting strategic/tactical tradeoffs and decision making in ship designs.

Maybe a good approach for the boosters (which could even be added to engine design as another option) would be to apply a similar overboost rule as missile engines, up to double the design EP modifier but with a linear fuel penalty up to 5x in addition to the usual -5/2 power factor for EP modifier.
Title: Re: C# Suggestions
Post by: ArcWolf on July 05, 2022, 10:05:44 PM
Idea - booster.
   Component, that is basically an engine, that can be put in addition to normal engines and can be turned off to not affect fuel usage, but is stupidly ineffective, like 3x fuel consumption.
Idea is, this component can be mounted on warships to make them rather fuel efficient when not in combat, but have good speed when in combat.
   I know I can do this with tugs or carriers, but it would be great for patrol ships, tat needs some combat power, while being cheap to produce.
   To make it even less attractive to put on every warship it could be able to overheat (get destroyed) after some time of constant usage.
   For programming simplicity it could be created, that it isn't throttable (I don't know if this is right word. It's used in KSP in this context) i.e. It can either be turned off, or work at 100%. It couldn't be able to be set to other values, like 50%.

It might be too complicated and/or "ship-focused" for Aurora (I think Steve has said he prefers the game to be focused on fleets more than individual ships, though I could very well be incorrect), but I also would like something like this. I would love to see something that resembles the military/commercial engine split in Starfire which I thought made for some interesting strategic/tactical tradeoffs and decision making in ship designs.

Maybe a good approach for the boosters (which could even be added to engine design as another option) would be to apply a similar overboost rule as missile engines, up to double the design EP modifier but with a linear fuel penalty up to 5x in addition to the usual -5/2 power factor for EP modifier.

Sounds good, but the "boosters" EP multiplier should be researchable levels. a flat 5x i think would be too much, but if you start with a 2.5x and research in .25 increments i think it could work quite well.

edit: additional thought, if it is possible to add boosters, could we get the agility to use multiple engine designs on one ship? Example would be using a 50HS engine as my "main" engine on capital ships, with 10 or 15 HS engines to tailor the speed that i want.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 05, 2022, 10:30:18 PM
Sounds good, but the "boosters" EP multiplier should be researchable levels. a flat 5x i think would be too much, but if you start with a 2.5x and research in .25 increments i think it could work quite well.

To clarify, the 5x is in reference to fuel efficiency. The idea is to mirror the missile boost rule, where missiles can have up to 2x the racial tech maximum for EP boosting, but going over the racial tech level incurs an extra penalty which maximizes at 5x. For example, if the racial boost tech level is 2.0x, a missile with 4.0x EP boost will have a 1/5 penalty to fuel efficiency in addition to the usual inefficiency of boosted engines. A missile with 3.0x boost will have a 2/5 extra penalty, and so on.

In this case I would suggest that you could install a boost of up to 2x the baseline engine power, but with the same overboost penalty as missiles already use. The other question is how to balance costs since otherwise this is a tactically superior option to normal boosted engines since fuel use in combat is usually pretty minimal.
Title: Re: C# Suggestions
Post by: ArcWolf on July 06, 2022, 12:57:41 AM
Sounds good, but the "boosters" EP multiplier should be researchable levels. a flat 5x i think would be too much, but if you start with a 2.5x and research in .25 increments i think it could work quite well.

To clarify, the 5x is in reference to fuel efficiency. The idea is to mirror the missile boost rule, where missiles can have up to 2x the racial tech maximum for EP boosting, but going over the racial tech level incurs an extra penalty which maximizes at 5x. For example, if the racial boost tech level is 2.0x, a missile with 4.0x EP boost will have a 1/5 penalty to fuel efficiency in addition to the usual inefficiency of boosted engines. A missile with 3.0x boost will have a 2/5 extra penalty, and so on.

In this case I would suggest that you could install a boost of up to 2x the baseline engine power, but with the same overboost penalty as missiles already use. The other question is how to balance costs since otherwise this is a tactically superior option to normal boosted engines since fuel use in combat is usually pretty minimal.

ah, i get what you mean.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 06, 2022, 04:01:10 AM
Sounds good, but the "boosters" EP multiplier should be researchable levels. a flat 5x i think would be too much, but if you start with a 2.5x and research in .25 increments i think it could work quite well.

To clarify, the 5x is in reference to fuel efficiency. The idea is to mirror the missile boost rule, where missiles can have up to 2x the racial tech maximum for EP boosting, but going over the racial tech level incurs an extra penalty which maximizes at 5x. For example, if the racial boost tech level is 2.0x, a missile with 4.0x EP boost will have a 1/5 penalty to fuel efficiency in addition to the usual inefficiency of boosted engines. A missile with 3.0x boost will have a 2/5 extra penalty, and so on.

In this case I would suggest that you could install a boost of up to 2x the baseline engine power, but with the same overboost penalty as missiles already use. The other question is how to balance costs since otherwise this is a tactically superior option to normal boosted engines since fuel use in combat is usually pretty minimal.

Why not allow us to use whatever engines on a ship that we like and allow us to decide which engine is primary. Probably should not be that much more complicated. You either decide one engine type that is used, based on the ship type, all ships have a primary engine. Or you can switch the individual ship to ALL engines, just like turning on sensors or shields.

Also, while speaking of sensors, I would like to have the same thing with active sensors, they should also be able to be turned on individually and not as a whole. It is quite irritating when I must turn on my 100 resolution active if the only thing I want is to use my resolution 1 sensor. The current way this work just means that I rarely put bigger active on ships than resolution 5, everything else are in small scout crafts.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 06, 2022, 04:27:23 AM
In order to make civilian ships take a bit less resources I would change how the fuel efficiency technology impact civilian shipping.

In my games I always have my factions stay at 50% minimum efficiency and only lower it with SM when designing ships after investing the research necessary and record each factions actual tech level on an excel sheet or other document.

The thing is that ships are more expensive and they build less but they go way faster so are more efficient. The lower price of the engines is not really good for the game and the ships speed is important for how efficient they are.

I would make some adjustment to how many civilian ships are built and how the fuel efficiency technology impact the civilian fleet. I would have civilian ships always use 50% fuel efficiency engines and instead increase the wealth generation by a small amount for each delivery. I might also increase the cost of the ships by a some amount (for the companies to buy them) to reduce the civilian ships to some degree overall. But they also would earn more money so it will eventually even itself out.

The effect would be less civilians ships but more efficient ones.

I also think that the civilians should build bigger and bigger ships over time, this would also reduce the amount to a certain agree. At least a bit bigger than the largest civilians currently. Some smaller civilians are still good, but bigger ships should also try to find pickups that matches their cargo space and not try to pick up half their cargo space. That would leave the smaller ones to take the contracts that is small or planets with low luxury generation. The bigger ships will generally traffic the routes where there are more cargo to be transported.

As it is, the lower efficiency engines makes the civilian fleet worse and they are able to buy more ships. As they don't actually use fuel there should be some different rule how the efficiency makes civilians ships better. not cheaper and worse. This would to some degree help with game slowdowns later on as well.
Title: Re: C# Suggestions
Post by: Voltbot on July 06, 2022, 04:47:34 AM
edit: additional thought, if it is possible to add boosters, could we get the agility to use multiple engine designs on one ship? Example would be using a 50HS engine as my "main" engine on capital ships, with 10 or 15 HS engines to tailor the speed that i want.

It would depend on how (if) Steve would program this. He could make system to add multiple engine types on one ship. However I can see at least one easier way to implement booster. The thing that I said about programming simplicity. If that would be a thing, then booster simple can add their speed bonus on top and that's it. But if Steave would make system for multiple engine types he would get a problem, that is not max speed. Because if ship is not at max speed, then how to process it? Do we turn off only most inefficient engines? That would make awful calculations.

So. It is possible, but I think it's not probable.
Title: Re: C# Suggestions
Post by: Voltbot on July 06, 2022, 04:50:20 AM
In order to make civilian ships take a bit less resources I would change how the fuel efficiency technology impact civilian shipping.

In my games I always have my factions stay at 50% minimum efficiency and only lower it with SM when designing ships after investing the research necessary and record each factions actual tech level on an excel sheet or other document.

The thing is that ships are more expensive and they build less but they go way faster so are more efficient. The lower price of the engines is not really good for the game and the ships speed is important for how efficient they are.

I would make some adjustment to how many civilian ships are built and how the fuel efficiency technology impact the civilian fleet. I would have civilian ships always use 50% fuel efficiency engines and instead increase the wealth generation by a small amount for each delivery. I might also increase the cost of the ships by a some amount (for the companies to buy them) to reduce the civilian ships to some degree overall. But they also would earn more money so it will eventually even itself out.

The effect would be less civilians ships but more efficient ones.

I also think that the civilians should build bigger and bigger ships over time, this would also reduce the amount to a certain agree. At least a bit bigger than the largest civilians currently. Some smaller civilians are still good, but bigger ships should also try to find pickups that matches their cargo space and not try to pick up half their cargo space. That would leave the smaller ones to take the contracts that is small or planets with low luxury generation. The bigger ships will generally traffic the routes where there are more cargo to be transported.

As it is, the lower efficiency engines makes the civilian fleet worse and they are able to buy more ships. As they don't actually use fuel there should be some different rule how the efficiency makes civilians ships better. not cheaper and worse. This would to some degree help with game slowdowns later on as well.

It depends on fuel cost. If civilians don't have to pay for fuel, then you're right. But if they have to pay for it, then it can be more problematic.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 06, 2022, 05:58:37 AM
It depends on fuel cost. If civilians don't have to pay for fuel, then you're right. But if they have to pay for it, then it can be more problematic.

They don't pay for fuel, that is the point. The other point is that it would reduce the amount of civilian ships and that would also be good for game performance.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 06, 2022, 06:35:02 AM
Another thing I might want to have for performance reasons are able to decide how long log data should be stored in the database. If I want to purge all log data that are older than a year I should. I also would like to have a quick delete button for clearing the log of all combat logs, things like ground combat logs can severely slow the game down if it drags out as it creates a huge amount of data quickly.
Title: Re: C# Suggestions
Post by: ArcWolf on July 06, 2022, 11:14:21 AM
Another thing I might want to have for performance reasons are able to decide how long log data should be stored in the database. If I want to purge all log data that are older than a year I should. I also would like to have a quick delete button for clearing the log of all combat logs, things like ground combat logs can severely slow the game down if it drags out as it creates a huge amount of data quickly.

just being able to decide which log data you delete and manually be able to delete (possibly with SM) would be great.
Title: Re: C# Suggestions
Post by: Scandinavian on July 06, 2022, 04:36:43 PM
Idea - booster.
   Component, that is basically an engine, that can be put in addition to normal engines and can be turned off to not affect fuel usage, but is stupidly ineffective, like 3x fuel consumption.
Idea is, this component can be mounted on warships to make them rather fuel efficient when not in combat, but have good speed when in combat.
   I know I can do this with tugs or carriers, but it would be great for patrol ships, tat needs some combat power, while being cheap to produce.
   To make it even less attractive to put on every warship it could be able to overheat (get destroyed) after some time of constant usage.
   For programming simplicity it could be created, that it isn't throttable (I don't know if this is right word. It's used in KSP in this context) i.e. It can either be turned off, or work at 100%. It couldn't be able to be set to other values, like 50%.
Allowing slow steaming (http://aurora2.pentarch.org/index.php?topic=8107.msg105075#msg105075) seems like a more elegant solution than bolting an SRB onto the engine. To me, at least.
Title: Re: C# Suggestions
Post by: Snoman314 on July 07, 2022, 12:32:10 AM
Quote from: Jorgen_CAB link=topic=10640. msg160578#msg160578 date=1657098070
Also, while speaking of sensors, I would like to have the same thing with active sensors, they should also be able to be turned on individually and not as a whole.  It is quite irritating when I must turn on my 100 resolution active if the only thing I want is to use my resolution 1 sensor.  The current way this work just means that I rarely put bigger active on ships than resolution 5, everything else are in small scout crafts.

I too would like to be able to control active sensors individually.
Title: Re: C# Suggestions
Post by: Erik L on July 07, 2022, 05:53:31 PM
I'd like to see the ages of the initial officer corps increased. Seems a bit off to have a 21 year old Rear Admiral. Possibly increase the age 2-3 years per promotion?
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 07, 2022, 06:09:37 PM
I'd like to see the ages of the initial officer corps increased. Seems a bit off to have a 21 year old Rear Admiral. Possibly increase the age 2-3 years per promotion?

It is in the next update (http://aurora2.pentarch.org/index.php?topic=12523.msg157428#msg157428).  :)

Title: Re: C# Suggestions
Post by: Erik L on July 07, 2022, 11:22:14 PM
I'd like to see the ages of the initial officer corps increased. Seems a bit off to have a 21 year old Rear Admiral. Possibly increase the age 2-3 years per promotion?

It is in the next update (http://aurora2.pentarch.org/index.php?topic=12523.msg157428#msg157428).  :)

Steve needs to get 2.0 out soon then :P
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 08, 2022, 02:51:49 PM
Rework shields for balance vs armor and better roleplay

Currently: Shield strength scales with the generator size in HS as Size^(3/2). This causes the efficiency of shields per HS relative to armor to increase a lot from one tech level to another, with Epsilon Shields (16k RP) being 40% as efficient as Laminate Composite Armour (20k RP), Theta Shields having 48% relative efficiency, and continuing to increase to a maximum of 75% relative efficiency at high tech levels. In practice, a ship with reasonably thick armor will begin taking internal damage once armor is degraded by about 50%, so a shield which is relatively ~50% as effective as armor is in practice superior against any weapon except mesons, and often is preferable even at lower tech levels against lasers or particle lances which penetrate armor effectively.

On the flip side, small shield generators in the few-HS range are very inefficient to the point of being basically useless. This means that putting shield generators on fighters, FACs, or other smaller ships is usually not practical, despite being a very common fixture in sci-fi settings. While the previous point by itself is okay, since it's fine for newer tech systems to change the combat balance, in my opinion the game mechanics should not limit roleplay in this way.


Suggested change: Rework shields so that regeneration rate scales as Size^(3/2) and generator strength scales linearly with size. This means there is still a tactical advantage to building larger shield generators rather than spamming a lot of small ones, but shield generators of any size will remain viable and shielded fighters or FACs will not be suicide booths like they are now. Shield scaling vs armor will be less extreme as well (i.e. closer to a flat line than a steep sloped curve).

Additionally, to keep shields competitive with armor, the shield strength tech line should be changed to omit the 1.5 and 2.5 values, adding 20 and 25-point values to the end of the tech line. The result would look like this:

    Alpha Shields: 1
    Beta Shields: 2
    Gamma Shields: 3
    Delta Shields: 4
    Epsilon Shields: 5
    Theta Shields: 6
    Xi Shields: 8
    Omicron Shields: 10
    Sigma Shields: 12
    Tau Shields: 15
    Psi Shields: 20
    Omega Shields: 25

For all but the last 3 tech levels the relative efficiency of shields is less than 50% that of armor, so there is an interesting design decision at most tech levels. By the end of the tech line, relative shield efficiency versus armor caps out at 56% which is probably superior to armor but close enough that the choice is not nearly as forced.
Title: Re: C# Suggestions
Post by: Lightning on July 08, 2022, 03:13:57 PM
I'd like to see the ages of the initial officer corps increased. Seems a bit off to have a 21 year old Rear Admiral. Possibly increase the age 2-3 years per promotion?
I'd also like to see a modifier to increase lifespan of officers. Just because we only have a 75-80 year life span doesn't mean that a TN race will too :)
I like the realistic promotions, but it isn't unusual to see them die or retire before earning many medals when it is used. I know you can manually prevent it on an individual basis, but I would prefer to just give them longer life spans.

Also, perhaps more triggers for medals like assignment to a given task, ie assigned 1st officer, assigned science officer, etc. Basically a ticket punching mechanism to give promotion points to officers that have been used & also increase the number of medals for the more experienced & higher ranking officers.
Title: Re: C# Suggestions
Post by: Erik L on July 08, 2022, 06:06:24 PM
I'd like to see the ages of the initial officer corps increased. Seems a bit off to have a 21 year old Rear Admiral. Possibly increase the age 2-3 years per promotion?
I'd also like to see a modifier to increase lifespan of officers. Just because we only have a 75-80 year life span doesn't mean that a TN race will too :)
I like the realistic promotions, but it isn't unusual to see them die or retire before earning many medals when it is used. I know you can manually prevent it on an individual basis, but I would prefer to just give them longer life spans.

Also, perhaps more triggers for medals like assignment to a given task, ie assigned 1st officer, assigned science officer, etc. Basically a ticket punching mechanism to give promotion points to officers that have been used & also increase the number of medals for the more experienced & higher ranking officers.

I wouldn't mind seeing rank "medals". As they rank up, they receive their new rank insignia.
Title: Re: C# Suggestions
Post by: Kristover on July 08, 2022, 07:08:01 PM
I second rank insignia.  Allow users to attach a rank image to each rank level, make it visible on the commander screen, and it changes every time they get promoted.
Title: Re: C# Suggestions
Post by: papent on July 08, 2022, 11:18:49 PM
Also on the topic of medals can all officers crewing the ship receive the medal when it's an automatic award for meeting a set criteria i.e. new system discovered or ships destroyed.

P.S. Can the Ship also receive medals either automatic awards or manual? would love to see a storied and long lived ship with a big rack of ribbons and citations.
Title: Re: C# Suggestions
Post by: Garfunkel on July 08, 2022, 11:43:25 PM
Rework shields for balance vs armor and better roleplay

Currently: Shield strength scales with the generator size in HS as Size^(3/2). This causes the efficiency of shields per HS relative to armor to increase a lot from one tech level to another, with Epsilon Shields (16k RP) being 40% as efficient as Laminate Composite Armour (20k RP), Theta Shields having 48% relative efficiency, and continuing to increase to a maximum of 75% relative efficiency at high tech levels. In practice, a ship with reasonably thick armor will begin taking internal damage once armor is degraded by about 50%, so a shield which is relatively ~50% as effective as armor is in practice superior against any weapon except mesons, and often is preferable even at lower tech levels against lasers or particle lances which penetrate armor effectively.

On the flip side, small shield generators in the few-HS range are very inefficient to the point of being basically useless. This means that putting shield generators on fighters, FACs, or other smaller ships is usually not practical, despite being a very common fixture in sci-fi settings. While the previous point by itself is okay, since it's fine for newer tech systems to change the combat balance, in my opinion the game mechanics should not limit roleplay in this way.


Suggested change: Rework shields so that regeneration rate scales as Size^(3/2) and generator strength scales linearly with size. This means there is still a tactical advantage to building larger shield generators rather than spamming a lot of small ones, but shield generators of any size will remain viable and shielded fighters or FACs will not be suicide booths like they are now. Shield scaling vs armor will be less extreme as well (i.e. closer to a flat line than a steep sloped curve).

Additionally, to keep shields competitive with armor, the shield strength tech line should be changed to omit the 1.5 and 2.5 values, adding 20 and 25-point values to the end of the tech line. The result would look like this:

    Alpha Shields: 1
    Beta Shields: 2
    Gamma Shields: 3
    Delta Shields: 4
    Epsilon Shields: 5
    Theta Shields: 6
    Xi Shields: 8
    Omicron Shields: 10
    Sigma Shields: 12
    Tau Shields: 15
    Psi Shields: 20
    Omega Shields: 25

For all but the last 3 tech levels the relative efficiency of shields is less than 50% that of armor, so there is an interesting design decision at most tech levels. By the end of the tech line, relative shield efficiency versus armor caps out at 56% which is probably superior to armor but close enough that the choice is not nearly as forced.

That looks quite interesting!
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 09, 2022, 06:02:51 PM
I probably would agree with the issue of how the shields works. Bigger generators probably should increase the rate of regenerations rather than the amount of strength the shield produce. The strength is very easy to compare with armour where regeneration is a mechanic that armour really can't compare in the same way. Small shields are very bad currently, they are not great in linear rates either but at least usable to some degree.
Title: Re: C# Suggestions
Post by: QuakeIV on July 09, 2022, 06:24:56 PM
Seems like shield capacitor vs shield generator should be separate tech.
Title: Re: C# Suggestions
Post by: Jeltz on July 10, 2022, 07:30:56 AM
Seems like shield capacitor vs shield generator should be separate tech.

Yes, agreed
-J-
Title: Re: C# Suggestions
Post by: kingflute on July 10, 2022, 04:31:38 PM
Also on the topic of medals can all officers crewing the ship receive the medal when it's an automatic award for meeting a set criteria i.e. new system discovered or ships destroyed.

P.S. Can the Ship also receive medals either automatic awards or manual? would love to see a storied and long lived ship with a big rack of ribbons and citations.

Or could we see the medals and awards being passed onto a sucessor ship with the same name?
Title: Re: C# Suggestions
Post by: ArcWolf on July 11, 2022, 03:41:26 PM
*snip* Small shields are very bad currently, they are not great in linear rates either but at least usable to some degree.

I agree, personally i do not use any shields until i reach Delta shields.
Title: Re: C# Suggestions
Post by: GodEmperor on July 20, 2022, 08:21:57 AM
Small suggestion - for starting options we have "Allow human NPR" . I propose additional setting "Only Human NPR's" for that classic hard sf feel.
Title: Re: C# Suggestions
Post by: hostergaard on July 22, 2022, 09:00:40 AM
Make player able to buy the output of civilian refinery ships like the civilian mines

I consider Civilian Fuel Harvesters pesky parasites as they seem to only lower the sorium of gas giants without any benefit to me. I wish I could tell them to offload all fuel to my colonies for a payment instead of it simply disappearing by being sold of to the civilian economy.

Title: Re: C# Suggestions
Post by: hostergaard on July 22, 2022, 09:03:18 AM
Make civilian transport ships able to ferry minerals for the player

Particularly, it would be nice to be able to have them mantain the reserve levels and ship minerals towards certain destinations. Maybe make the player able to set up shipping routes that the civ transports can elect to ship along?
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 22, 2022, 09:16:15 AM
Make player able to buy the output of civilian refinery ships like the civilian mines

I thought we already could do this? Just order tankers to transfer fuel from the civilian harvesters and the wealth is transferred automatically?
Title: Re: C# Suggestions
Post by: hostergaard on July 22, 2022, 10:01:10 AM
Yeah, but that is different, when they get full they sell off all the fuel, if you don't have a fleet of tankers ready at all times, it causes the fuel to be lost. I would like for them to offload their fuel at my bases instead of selling
Title: Re: C# Suggestions
Post by: Scandinavian on July 22, 2022, 05:25:45 PM
Make player able to buy the output of civilian refinery ships like the civilian mines

I thought we already could do this? Just order tankers to transfer fuel from the civilian harvesters and the wealth is transferred automatically?
If you set tankers to repeat this, you need to go in and modify the order list every time the civvies launch or decommission a harvester. You also don't get warnings when civilian harvesters are nearing capacity.

It seems reasonable enough that you have to provide your own tankers, rather than expect the harvester to wander all the way to your nearest colony. But there would be merit to some additional automation options for tanker routing.

Or just civilian tankers to move fuel, but I guess that would be more a feature for a wider civilian economy overhaul.
Title: Re: C# Suggestions
Post by: skoormit on July 22, 2022, 06:03:26 PM
You also don't get warnings when civilian harvesters are nearing capacity.

You actually do get such a warning (at least, I have), but new civ harvs launch with a full tank, and you'll never get a warning for it until you've taken the fuel out of it. I guess because it's never "nearing" capacity--it's already at capacity.
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 23, 2022, 04:53:39 AM
You also don't get warnings when civilian harvesters are nearing capacity.

You actually do get such a warning (at least, I have), but new civ harvs launch with a full tank, and you'll never get a warning for it until you've taken the fuel out of it. I guess because it's never "nearing" capacity--it's already at capacity.

I've changed automated harvester and tanker design to set a minimum fuel level of 10%.
Title: Re: C# Suggestions
Post by: Garfunkel on July 23, 2022, 05:44:32 AM
In that vein, it would be grand if all harvesters stopped working when their tanks are full.
Title: Re: C# Suggestions
Post by: Steve Walmsley on July 23, 2022, 05:57:03 AM
In that vein, it would be grand if all harvesters stopped working when their tanks are full.

That is already the case. Harvesters with full fuel tanks are ignored during the harvester mining phase.
Title: Re: C# Suggestions
Post by: hostergaard on July 23, 2022, 07:01:43 AM
Thinking of it, some said they would not like civilian harvesters to fly of to to colonies when full, so maybe there can be civilian fuel shipping lines that ship fuel instead?

Could even make the whole civilian trading and the universe come more alive. I remember in the previous aurora shipping lines bought new ships with money they earned. So how about something like this:

Have the fuel harvester civilian corporation that spawn fuel harvesters, they will just harvest fuel and do nothing when full. Oil rigs if you will. Then we have the fuel shipping lines, the oil tankers, they will fly around and buy fuel from civilian harvesters and then fly it back to the nearest colony. When they reach the nearest colony it either get sold to the civilian population which earns you tax income, or the player buys it automatically depending on settings. Or the oil tankers and rigs can be all be spawned within the same civilian line. Dunno what would work best.

Now how you set it is a bit of a question. Although, setting it on a per planet basis works well with minerals, so I guess you could say something like buy all sorium from this gas giant or sell to civs.

Now if you really wanna make it interesting, have it so friendly aliens and players can trade fuel, so they can set to buy fuel from aliens they have trade pacts with. And if you wanna make it really really interesting start simulating the price of sorium according to supply and demand. A harvester that is almost full will likely sell it of cheaper to get rid of it, while a planet with plenty of fuel won't pay as much, but a planet with low supply might pay high prices.
Title: Re: C# Suggestions
Post by: Warer on July 25, 2022, 04:30:11 PM
Kinetic Weapon Ammo
-To give other weapons similar design depth to missiles Railguns and/or Gauss Cannon, or "just" limiting their ammo to give Energy weapons another advantage. Also giving Railguns more "character"/flavour.

Simple
Railguns and or Gauss Cannons have ammunition similar to missiles but no design is needed, they just require one of three preset gun magazines that provide a fixed amount of ammo.

Complex
Railguns and or Gauss Cannons have special munitions, either preset or designed ala missiles, that grant some kind of bonus to damage, accuracy etc.
Title: Re: C# Suggestions
Post by: Erik L on July 25, 2022, 06:07:51 PM
Kinetic Weapon Ammo
-To give other weapons similar design depth to missiles Railguns and/or Gauss Cannon, or "just" limiting their ammo to give Energy weapons another advantage. Also giving Railguns more "character"/flavour.

Simple
Railguns and or Gauss Cannons have ammunition similar to missiles but no design is needed, they just require one of three preset gun magazines that provide a fixed amount of ammo.

Complex
Railguns and or Gauss Cannons have special munitions, either preset or designed ala missiles, that grant some kind of bonus to damage, accuracy etc.

I like the idea, but that's a lot of micro ;)
Title: Re: C# Suggestions
Post by: Ship Research Modules on July 26, 2022, 10:27:30 AM
since DSP can't have ground installations some ship modules that replace these ground installations would be good to provide more use for DSP and to allow more RP Nomad scenarios. 

Since maintenance modules, mining modules and terraforming modules add to the population amounts, could something similar be done with research modules?

balance:

A the same amount of workers and the same/similar price/size as they are now except on a ship seems fair and less cheeseable in low population games.

Or

A much higher price than normal labs would be needed if it's not possible/easy to make ship components require workers on the population they orbit.


Similar modules for fighter/ordnance/Financial center/Ground forces/Academies would be nice too but less important IMO.   
Title: Re: C# Suggestions
Post by: Garfunkel on July 26, 2022, 05:52:58 PM
Please register your account for future use so that we don't have to manually approve of each post you make.
Title: Re: C# Suggestions
Post by: trainhighway on July 27, 2022, 01:57:57 AM
Quote from: Erik L link=topic=10640. msg160769#msg160769 date=1658790471
Quote from: Warer link=topic=10640. msg160768#msg160768 date=1658784611
Kinetic Weapon Ammo
-To give other weapons similar design depth to missiles Railguns and/or Gauss Cannon, or "just" limiting their ammo to give Energy weapons another advantage.  Also giving Railguns more "character"/flavour.

Simple
Railguns and or Gauss Cannons have ammunition similar to missiles but no design is needed, they just require one of three preset gun magazines that provide a fixed amount of ammo.

Complex
Railguns and or Gauss Cannons have special munitions, either preset or designed ala missiles, that grant some kind of bonus to damage, accuracy etc.

I like the idea, but that's a lot of micro ;)

Seeing as maintenance can be toggled off on the start menu, I'm sure a system like this could also be disabled for those who do not enjoy this.  I think the need to deal with the manufacture of and supply of ammunition for kinetic weapons systems adds an interesting element, though some changes might have to be made to keep them balanced with energy weapons. 
Title: Re: C# Suggestions
Post by: Black on July 27, 2022, 04:09:38 AM
Problem is that if you make ammo for gauss/railgun optional, you would also have to make balancing changes for beam weapons optional with it. So Steve would have to continue to think about two sets of beam weapons for any future changes and additions.

It would also heavily change the use of railguns for fighters/FACs as they would have to carry ammo as well.
Title: Re: C# Suggestions
Post by: trainhighway on July 27, 2022, 07:08:59 AM
I hadn't considered the difficulty of maintaining two differently balanced weapon options, which is obviously an unreasonable amount of work for steve. 
I still think that it would be interesting to add the need for ammunition for kinetic weapons, maybe associated with kinetics having faster firing rates or damage amounts.  As they stand I think the differences between the kinetic beam weapons and the energy beam weapons is kind of meaningless and adding ammunition would make them noticeably different.
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 27, 2022, 07:30:50 AM
If we need to differentiate between beam and kinetic weapons (do we though?), I'd rather see a mechanical change instead of a micromanagement change. Right now I think most people are fine with considering MSP as ammo.
Title: Re: C# Suggestions
Post by: trainhighway on July 27, 2022, 07:44:27 AM
I hadn't considered that MSP could be viewed as ammo, that's a pretty good point.  It probably isn't necessary for beam and kinetic to be differentiated, but I think if it were done with the right mechanics it would make the decision between an energy weapon or kinetic weapon more interesting in the ship design process. 
Title: Re: C# Suggestions
Post by: nuclearslurpee on July 27, 2022, 08:07:33 PM
I occasionally entertain the idea of reworking armor so that beam weapons ablate armor while kinetic weapons penetrate armor, but this would be a significant rework so I doubt such a thing could ever happen in Aurora.
Title: Re: C# Suggestions
Post by: nakorkren on July 29, 2022, 04:17:35 PM
I looked around the forum but couldn't find anything on this already, so:

Allow hangar decks to be pre-built via industry. Currently can't be, but other comparable ship modules (i.e. not designed like Cryo transport, Diplomacy module, Cargo Shuttle Bay, etc) can be built. Also noticed that the various sizes of cargo bay can't be pre-built either. Wondering if that's intentional, or an oversight?
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 29, 2022, 07:54:03 PM
I occasionally entertain the idea of reworking armor so that beam weapons ablate armor while kinetic weapons penetrate armor, but this would be a significant rework so I doubt such a thing could ever happen in Aurora.

Don't be so sure... Steve did toy with the idea if changing how weapons worked when he was working on Aurora 2 version of the game a few years back. It could happen...

Both shields and armour worked in a more realistic way and most weapons impacted these things in different ways. Shields did not always completely stop incoming rounds or energy beams either.
Title: Re: C# Suggestions
Post by: Jorgen_CAB on July 29, 2022, 07:59:30 PM
I looked around the forum but couldn't find anything on this already, so:

Allow hangar decks to be pre-built via industry. Currently can't be, but other comparable ship modules (i.e. not designed like Cryo transport, Diplomacy module, Cargo Shuttle Bay, etc) can be built. Also noticed that the various sizes of cargo bay can't be pre-built either. Wondering if that's intentional, or an oversight?

I think the point is that the part of a ship you mention are more part of the hull structure rather than some isolated component, that is why you can't pre build them.
Title: Re: C# Suggestions
Post by: Warer on July 30, 2022, 06:29:48 AM
Hmm maybe a Pre Built Hanger Deck Module? Something like a Hangar deck but its 1100-1250 tons and maybe more expensive but you can build it with industry to speed up carrier construction.
Title: Re: C# Suggestions
Post by: nakorkren on July 31, 2022, 03:58:44 PM
Would it be possible to give fighters (sub 500 tons) the ability to "land" in the form of significantly reduced signature when at a body? This would open up the ability to "hide" fighters on an asteroid or other body and ambush enemy naval forces, which would be AWESOME flavor-wise.

No idea how that'd work code-wise, and presumably there would need to be some way to toggle it where they can't shoot until they "take off" thereby giving up the signature reduction.
Title: Re: C# Suggestions
Post by: Demetrious on August 01, 2022, 10:04:42 AM
Would it be possible to give fighters (sub 500 tons) the ability to "land" in the form of significantly reduced signature when at a body? This would open up the ability to "hide" fighters on an asteroid or other body and ambush enemy naval forces, which would be AWESOME flavor-wise.

No idea how that'd work code-wise, and presumably there would need to be some way to toggle it where they can't shoot until they "take off" thereby giving up the signature reduction.

Seems to me this could be implemented by using the already existing ground-support mechanics, as fighters on ground-support missions can't be targeted normally by space assets (including STOs.)
Title: Re: C# Suggestions
Post by: Aloriel on August 01, 2022, 12:04:58 PM
Speaking of wealth changes (as per the 2.0 changes list)...

Would it be possible to get a simple line graph that could show a history of our wealth over the last few years or so?

Similarly, would it be possible to get graphs of our mineral stockpile status on a selected planet? This one would be best served by being able to select the different minerals (or all of them), and the graph scaling to fit the data.

I ask for these because it is often somewhat challenging to see the change of minerals/wealth over time with just numbers.
Title: Re: C# Suggestions
Post by: skoormit on August 01, 2022, 01:14:15 PM
Speaking of wealth changes (as per the 2.0 changes list)...

Would it be possible to get a simple line graph that could show a history of our wealth over the last few years or so?

Similarly, would it be possible to get graphs of our mineral stockpile status on a selected planet? This one would be best served by being able to select the different minerals (or all of them), and the graph scaling to fit the data.

I ask for these because it is often somewhat challenging to see the change of minerals/wealth over time with just numbers.

Allow me to introduce Marvin (http://aurora2.pentarch.org/index.php?topic=12233.0).
Title: Re: C# Suggestions
Post by: hostergaard on August 01, 2022, 02:04:38 PM
A checkbox to prevent commander re-assignment for specific commanders

Mostly cause administrators assigned to my academies keeps getting reasigned.

Automatic assignment for Admin commands and ability to choose how its assigned and prioritized like colony administrators

Cause I a tired of micro managing it every time someone gets promoted or something.
Title: Re: C# Suggestions
Post by: Steve Walmsley on August 01, 2022, 06:05:06 PM
A checkbox to prevent commander re-assignment for specific commanders

Mostly cause administrators assigned to my academies keeps getting reasigned.

Automatic assignment for Admin commands and ability to choose how its assigned and prioritized like colony administrators

Cause I a tired of micro managing it every time someone gets promoted or something.

Admin Commands is already in the changes list
http://aurora2.pentarch.org/index.php?topic=12523.msg156310;topicseen#msg156310

Academy commanders being re-assigned was a bug that is already fixed.
Title: Re: C# Suggestions
Post by: RaidersOfTheVerge on August 01, 2022, 07:53:59 PM
A way to designate equal refuel from a designated tanker fleet.

I.e battle fleet refueling from one tanker so that the first ships get 100% fuel and the last one only gets the remainder and is still only at 22%

Or tanker goes to refuel from harvesters and the first few have 0% while the last ones still have 90%+
Title: Re: C# Suggestions
Post by: unkfester on August 02, 2022, 04:24:29 AM
A way to designate equal refuel from a designated tanker fleet.

I.e battle fleet refueling from one tanker so that the first ships get 100% fuel and the last one only gets the remainder and is still only at 22%

Or tanker goes to refuel from harvesters and the first few have 0% while the last ones still have 90%+
  I second this.  When you got a big fleet, I would rather have then all fueled to 10% than have one at 100% and the rest still empty
Title: Re: C# Suggestions
Post by: Aloriel on August 04, 2022, 02:33:32 PM
Speaking of wealth changes (as per the 2.0 changes list)...

Would it be possible to get a simple line graph that could show a history of our wealth over the last few years or so?

Similarly, would it be possible to get graphs of our mineral stockpile status on a selected planet? This one would be best served by being able to select the different minerals (or all of them), and the graph scaling to fit the data.

I ask for these because it is often somewhat challenging to see the change of minerals/wealth over time with just numbers.

Allow me to introduce Marvin (http://"http://aurora2.pentarch.org/index.php?topic=12233.0").
Marvin would be great if I didn't have to save each time for it to update... This is why I suggest these things in Aurora itself. (also, your link doesn't work ;) I found it anyway, but thought you should know)
Title: Re: C# Suggestions
Post by: nakorkren on August 04, 2022, 03:57:30 PM
Would it be possible for the event screen so be resizeable? It's the one window that I most often wish I could resize, and since it's just text display with minimal buttons/fields, it seems like it should be amenable to resizing. I often wish it was just a little wider so an event would only fill one line, instead of spilling onto the 2nd line, particularly when there are a LOT of the same event over and over, as in combat, and those events take up twice as many rows to display. Likewise it would be nice to resize it vertically to fill whatever space is available, and again displaying more or less rows of text seems like it should be a minimal coding change (but I am not a SW developer, so I could easily be wrong about that).
Title: Re: C# Suggestions
Post by: TallTroll on August 05, 2022, 10:11:20 AM
Allowing the combat events screen to overrun the window size instead/as well would do that too
Title: Re: C# Suggestions
Post by: TMaekler on October 05, 2022, 06:36:26 AM
In that vein, it would be grand if all harvesters stopped working when their tanks are full.

That is already the case. Harvesters with full fuel tanks are ignored during the harvester mining phase.
Wouldn't it be best if a harvester is only ignored when all fuel tanks in the fleet are full?
Title: Re: C# Suggestions
Post by: nuclearslurpee on October 05, 2022, 07:30:52 AM
We have a new suggestions thread for v2.0: http://aurora2.pentarch.org/index.php?topic=13020.0 (http://aurora2.pentarch.org/index.php?topic=13020.0)
Title: Re: C# Suggestions
Post by: Jorgen_CAB on November 03, 2022, 08:58:18 PM
One thing that I really miss is an option for a transport to wait on a planet until it can fill its cargo with something you order it to Load, instead of just failing to pick up something.

This would make it easier to make cycling orders for pickup of installation as you don't need to calculate how much you produce and inserting wait orders so the planet never have anything to pick up.

Sure... you can end up with a transport sitting there indefinitely as it tries to pick up something that will never be built, but that would be a trade-off I'm willing to take as it would be an optional order type.

There would need to be a check if multiple fleets are waiting for the same thing as only one such fleet should load something at the same time.
Title: Re: C# Suggestions
Post by: nuclearslurpee on November 03, 2022, 11:16:12 PM
We have a new suggestions thread for v2.0: http://aurora2.pentarch.org/index.php?topic=13020.0 (http://aurora2.pentarch.org/index.php?topic=13020.0)

I swear it is like shouting into the void around here sometimes.

Jorgen makes a good suggestion though. Particularly this would make early-game colonization less irritating especially in Sol, as you will struggle to produce enough infrastructure faster than you can ship it to Mars or wherever so a cycle order just wastes fuel unless you use very few freighters.
Title: Re: C# Suggestions
Post by: Garfunkel on November 04, 2022, 12:16:10 AM
I'll lock the thread so this doesn't happen again.