Author Topic: C# Suggestions  (Read 272854 times)

0 Members and 1 Guest are viewing this topic.

Offline skoormit

  • Rear Admiral
  • **********
  • Posts: 804
  • Thanked: 324 times
Re: C# Suggestions
« Reply #2535 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.
« Last Edit: April 05, 2022, 09:25:17 AM by skoormit »
 

Offline nakorkren

  • Lt. Commander
  • ********
  • n
  • Posts: 217
  • Thanked: 194 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
Re: C# Suggestions
« Reply #2536 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.
 

Offline nakorkren

  • Lt. Commander
  • ********
  • n
  • Posts: 217
  • Thanked: 194 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
Re: C# Suggestions
« Reply #2537 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.
 
The following users thanked this post: Garfunkel, DawnMachine, ISN

Offline Garfunkel

  • Registered
  • Admiral of the Fleet
  • ***********
  • Posts: 2794
  • Thanked: 1054 times
Re: C# Suggestions
« Reply #2538 on: April 07, 2022, 04:48:05 AM »
That would be a really great change!
 

Offline unkfester

  • Silver Supporter
  • Warrant Officer, Class 1
  • *****
  • Posts: 78
  • Thanked: 1 times
  • Discord Username: unkfester
  • Silver Supporter Silver Supporter : Support the forums with a Silver subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2023 Supporter 2023 Supporter : Donate for 2023
    2024 Supporter 2024 Supporter : Donate for 2024
Re: C# Suggestions
« Reply #2539 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.
 

Offline Warer

  • Lieutenant
  • *******
  • Posts: 177
  • Thanked: 73 times
Re: C# Suggestions
« Reply #2540 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. 
 

Offline Migi

  • Captain
  • **********
  • Posts: 465
  • Thanked: 172 times
Re: C# Suggestions
« Reply #2541 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.
 
The following users thanked this post: Warer

Offline KriegsMeister

  • Chief Petty Officer
  • ***
  • K
  • Posts: 35
  • Thanked: 22 times
Re: C# Suggestions
« Reply #2542 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.
 

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2986
  • Thanked: 2245 times
  • Radioactive frozen beverage.
Re: C# Suggestions
« Reply #2543 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:
  • Complex formation hierarchies could be handled in a few different ways. The above could simply be extended - e.g., an Army formation controlling four of the above Corps would require 21xHQ20 components. This could become unwieldy and insufficiently abstract/flexible for complex hierarchies, however. Another possibility is to only require enough HQ components to control direct subordinate formations, which isn't completely unrealistic and allows considerable flexibility - an Army with 10xHQ20 could control itself and nine Corps, or itself + 3 Corps + 6 support brigades, and so on. Other possibilities exist but these are the simplest implementations and I think simplicity is desirable here.
  • How to handle destruction of a HQ component in a formation with multiple HQ components is also open-ended. Either some kind of ordering of subordinate formations would be needed (ideally not requiring player intervention to set up, which would be tedious), or command capacity could be reduced based on number of attached formations versus actual capability - for example, a Corps which is reduced to 4xHQ20 would be able to control itself and four subordinate brigades with only 80% effectiveness.
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.
« Last Edit: April 09, 2022, 11:33:28 PM by nuclearslurpee »
 
The following users thanked this post: Kristover, BAGrimm

Offline skoormit

  • Rear Admiral
  • **********
  • Posts: 804
  • Thanked: 324 times
Re: C# Suggestions
« Reply #2544 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.
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1704
  • Thanked: 599 times
Re: C# Suggestions
« Reply #2545 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.
 
The following users thanked this post: Warer

Offline Andrew

  • Registered
  • Commodore
  • **********
  • Posts: 695
  • Thanked: 130 times
Re: C# Suggestions
« Reply #2546 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)
 

Offline Kristover

  • Gold Supporter
  • Lt. Commander
  • *****
  • K
  • Posts: 259
  • Thanked: 135 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: C# Suggestions
« Reply #2547 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.
« Last Edit: April 10, 2022, 12:18:38 PM by Kristover »
 

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2986
  • Thanked: 2245 times
  • Radioactive frozen beverage.
Re: C# Suggestions
« Reply #2548 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.
 

Offline nakorkren

  • Lt. Commander
  • ********
  • n
  • Posts: 217
  • Thanked: 194 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
Re: C# Suggestions
« Reply #2549 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.
 
The following users thanked this post: El Pip, papent, BAGrimm, ArcWolf, nuclearslurpee