Aurora 4x

C# Aurora => C# Aurora => Topic started by: sloanjh on February 21, 2018, 12:15:53 PM

Title: C# Aurora v0.x Suggestions
Post by: sloanjh on February 21, 2018, 12:15:53 PM
Starting a suggestions thread per Steve's request.

Please be sure to post all suggestions for C# Aurora to this thread; this will help Steve keep track of them.  Any suggestions posted elsewhere are likely to be "lost" by Steve after he has read them the first time.

If discussions balloon (more than a few back-and-forth rounds) and/or go off-topic (into long historical, philosophical, reasonableness, etc. exchanges), please start a new thread and post a reference to that thread here.  Since Steve will be using this thread as his "suggestion database", we should try to keep the signal (specific suggestions) to noise (discussions thereof) down so that he can easily browse/find the suggestions.

If you suspect you're posting a controversial and/or major suggestion that will generate a lot of discussion, please start a new thread and post a synopsis and reference to that thread here.  That being said, please be conscious of the fact that Steve often starts new threads on specific topics to ask for input; we don't want to knock such threads off the front page by starting a bunch of small threads that don't generate a lot of discussion.

Thanks, and have fun!!

John
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on February 21, 2018, 12:28:06 PM
I would like to suggest a new way to exploit distant binary systems.

As we know, hyperdrive didn't really work that well and was removed. Frankly, I do not want to see it back, it would probably still be problematic. That, and having to have a new, different engine for all ships required to make the trip between the distant companions would be problematic.

I think a much more elegant and "realistic" solution would be, after researching an appropriate technology, the possibility to build in-system gates between stars. You could justify it as a technology that "replicates the natural lagrange points", only that because of the imperfect results due to it being artificial, it requires the mass of a star.

Mechanically, it would be similar to the already present gate constructors. You would build a "lagrange constructor" ship, with the appropriate module. Send it to a star. Order a "build gate to <other star in system>" command, and then wait until it is complete. That would create a one-way gate, as for the other normal type of system-to-system gates. If you want  a two-way artificial lagrange point, you would send the constructor to the other side and build the gate on that side as well.

I hope that this solution would be relatively simple to implement, and once it's done it can work with the already present code for routing ships. And it would allow to finally use systems with distant stars companions.
Title: Re: C# Aurora v0.x Suggestions
Post by: Dr. Toboggan on February 21, 2018, 02:28:16 PM
I would like to suggest a new way to exploit distant binary systems.

As we know, hyperdrive didn't really work that well and was removed. Frankly, I do not want to see it back, it would probably still be problematic. That, and having to have a new, different engine for all ships required to make the trip between the distant companions would be problematic.

I think a much more elegant and "realistic" solution would be, after researching an appropriate technology, the possibility to build in-system gates between stars. You could justify it as a technology that "replicates the natural lagrange points", only that because of the imperfect results due to it being artificial, it requires the mass of a star.

Mechanically, it would be similar to the already present gate constructors. You would build a "lagrange constructor" ship, with the appropriate module. Send it to a star. Order a "build gate to <other star in system>" command, and then wait until it is complete. That would create a one-way gate, as for the other normal type of system-to-system gates. If you want  a two-way artificial lagrange point, you would send the constructor to the other side and build the gate on that side as well.

I hope that this solution would be relatively simple to implement, and once it's done it can work with the already present code for routing ships. And it would allow to finally use systems with distant stars companions.

Could it be easier to make it more likely to have jump points have a greater chance of connecting to other systems? I recall that at some point in either The Mote in God's Eye or The Gripping Hand that oftentimes it is easier for ships to take a route through more systems, but the overall distance covered is less.  So instead of trying to go to System-1 B from the jump point right next to System-1 A, you could go through System-2, which links to System-3, which leads to System-4, which connects to a point right next to System-1 B. 
I would personally just like a greater chance of systems connecting to each other, so that the galactic map is more of a web than a subway system, but I am not sure whether that would be harder to implement than artificial Lagrange points.  It just gets a bit tedious when all paths lead back to Sol.
Title: Re: C# Aurora v0.x Suggestions
Post by: Frank Jager on February 21, 2018, 07:50:24 PM
Re-Posting from the Semi Official 7. x suggestions thread.  (Cleaned up and made relevant to significant changes in Aurora C#)

TL/DR Make Kinetic weapons useful and add a logistical ammunition component into the game. 

I propose a change to the weapons mix that I hope is easy to implement.  This should complement the recent changes to Missile design.

Kinetic Weapons
Railguns
Specifications;
Non Turretable.
Spinal design choice.  2x HS Requirement, but with a 33% increase in BP, increase calibre size by one step.
Long range.
          Able to fire at maximum range with a 4x BFC.
Only produce one projectile per times fired.
Maintain the Missile damage profile.
Calibre and Missile Warhead size damage.
          120mm      5 WH (25 Damage,    5 Layers of Armour Penetration)     10 HS
          150mm      6 WH (36 Damage,    6 Layers of Armour Penetration)     12 HS
          175mm      7 WH (49 Damage,    7 Layers of Armour Penetration)     15 HS
          200mm      8 WH (64 Damage,    8 Layers of Armour Penetration)     17 HS
          250mm      9 WH (81 Damage,    9 Layers of Armour Penetration)     20 HS
          300mm    10 WH (100 Damage, 10 Layers of Armour Penetration)    30 HS
          300mm    11 WH (121 Damage, 11 Layers of Armour Penetration) [Spinal Only]
Firing Rate and Tech Progression.
          Base     120 Seconds
          Double    60 Seconds
          Triple       30 Seconds
          Quadruple 15 Seconds
Require 1 MSP (Missile Size Point) per shot of ammunition.

Gauss Cannon
Specifications;
These weapons should have;
The ability to be turreted.
Barrel Tech Line.
             Single        1 Projectile
             Dual          2 Projectiles
             Tri             3 Projectiles
            Quad          4 Projectiles
Medium range, max range at 2x BFC, accuracy increases with bigger BFCs.
Calibre, Missile Warhead Damage Profile and HS.
                30mm            3 Damage, 1 Layers of Armour Penetration)    3 HS
                40mm            8 Damage, 2 Layers of Armour Penetration)    5 HS
                50mm          15 Damage, 3 Layers of Armour Penetration)    7 HS
                60mm          24 Damage, 4 Layers of Armour Penetration)  10 HS
                70mm          35 Damage, 5 Layers of Armour Penetration)  12 HS
                80mm          48 Damage, 6 Layers of Armour Penetration)  15 HS
Firing Rate and Tech Progression.
          Base       60 Seconds
          Double    30 Seconds
          Triple      15 Seconds
Require 0. 5 MSP (Missile Size Point) per shot of ammunition.

Auto Cannon
Specifications;
Turret-able
Provides CIWS component to allow civilians access to the weapons tech for defensive purposes.
Max Size 1HS.
          Reduction techs.
              100% Size   100% Accuracy
              75% Size      80% Accuracy
              50% Size      60% Accuracy
              25% Size      40% Accuracy
Baseline 10 projectiles per 5 second increment (120 Rounds Per Minute), double and triple fire rate techs
1 Damage per projectile.
Max Range 10km
0. 1 MSP (Missile Size Point) per increment of ammunition. 

Other Considerations
A spinal design tag added to prevent more than a SINGLE spinal weapon regardless of type, similar to the tag given to engines.
A Minimum targetable (Combat) range of 2km, to take advantages of the increase in processor time.  (Ignorant of C# code base, if this is not true please let me know. )

Ammunition
Production.  1 point of Ammunition requires . 25 Duranium and can be produced in ordnance factories.
Types.  There should only be one type of ammunition and it is used universally between the different weapon systems.
(Half Ton slugs of Duranium cut to size on-board the ship)
Transport.  These should only be able to be transported within a magazine, civilian or military.

It doesn't make sense to me that civilian ships can have CIWS missile defenses but not have to pay any cost for the systems. 


Regards

Frank
Title: Re: C# Aurora v0.x Suggestions
Post by: ardem on February 21, 2018, 10:37:49 PM
I believe orbiting space craft should get a 50% or more reduction to their profile, as the background noise of the planet hides their signature, or simulates they are on the other side, this would result in some nice ambushes, in have space terrain involved. The biggest problem with Aurora Sensor ability is it see everything even when terrain features could be used.

(Did not see this new post so posting it here to make sure it added into the suggestions page.)
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on February 22, 2018, 06:28:45 AM
Defining which events break up the time progression cycle

Copy of posting from here:
http://aurora2.pentarch.org/index.php?topic=9835

Would be nice if we could choose which actions stop a time progression cycle early and which don't. At least for some of them I cannot understand why they stop it early.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on February 22, 2018, 08:56:27 AM
Quote from: TMaekler link=topic=9841. msg106753#msg106753 date=1519302525
Defining which events break up the time progression cycle

Copy of posting from here:
hxxp: aurora2. pentarch. org/index. php?topic=9835

Would be nice if we could choose which actions stop a time progression cycle early and which don't.  At least for some of them I cannot understand why they stop it early.

Since this is being reposted, I'll repost my agreement.

Have to agree.    A toggle would be nice, at least for some things.    I want to know if there's a mineral shortage, but if I can't deal with the problem immediately, I don't wan't that shortage preventing me from using the auto feature.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tuna-Fish on February 22, 2018, 10:34:22 AM
So, my current campaign is a bit bogged by micromanagement, and I couldn't help but think that three orders would greatly reduce the necessary amount of clicks.   In order of importance:

1.   Tractor any ships. 

Available on a fleet that contains at least one ship with tractor beams when targeting any other fleet.   When the fleet arrives at the target, every ship with a tractor beam in it attempts to tractor one ship from the target (in any order).   The order succeeds and execution of order list continues if at least one ship was tractored, if no ships were tractored (or target fleet no longer exists, etc) the order list of the fleet is cleared and a message is printed. 

Rationale: Moving 200 terraforming satellites is a total pain currently, as you have to do many clicks per each satellite.   With this, you could set up the target fleet, take your tug fleet, order "tractor any ships at old terraforming fleet -> release tractored ships at new terraforming fleet" and hit repeat and the entire terraforming fleet gets moved (eventually). 

2.   Unload cargo. 

Available for fleets with any cargo space (possibly only if something occupies that space at this point in orders?) when targeting anything with any cargo space or a colony.   Attempts to unload everything from own cargo space to target.   Succeeds if after the order there is nothing in own cargo space (even if there was nothing to start with!), fails with message and order clearing if after this there is still something loaded. 

Rationale: reduces clicks when moving around various stuff.   Allows the use of a single order to guarantee that after that the cargo space is clear.   No more fleets moving minerals with a third of their capacity because you forgot to unload that one jump gate construction module!

3.   Load any ship components

Available for fleets with some cargo space when targeting a colony.   Loads the cargo space full of any ship components (regardless of type) from the colony.   Succeeds if at least one component was loaded, fails with message if none were. 

Rationale: right now, moving a random assortment of ship components takes a lot of clicks. 

Would there be any chance of having something like those for C# Aurora?
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on February 22, 2018, 10:44:12 AM
About Orbital Habitats:

wouldn't it make more sense to chance the "Commander" of a non-military habitat to a "Civil Admin slot" instead of a Naval Commander slot? The example habitat Steve posted today is a pure living station, so a civil commander would be better suited than a military officer.. a miltary station should still need a military commander

Quote
Orbital Habitats

This is a copy of a post in the VB6 7.2 Changes List. I didn't release the updated VB6 version so this is still a change from the released VB6 Aurora.

The population capacity of orbital habitat modules has been increased from 50k to 200k. In combination with the new 'No Armour' option this significantly reduces the cost of building orbital habitats. For example, the habitat shown here supports a population of one million for a cost of 1145 BP. To support one million colonists with infrastructure on a colony cost 2.0 world with acceptable gravity would cost 400 BP, so the colony cost would have to be approaching 6.0 before the Orbital Habitat became cheaper. For low-gravity worlds it is comparable with the cost of low-gravity infrastructure and it is the only option for high gravity worlds or small bodies with low population capacities.

Sidon class Orbital Habitat      1,252,970 tons       162 Crew       1144.7 BP       TCS 25059    TH 0    EM 0
1 km/s      No Armour       Shields 0-0     HTK 132      Sensors 1/1/0/0      DCR 1      PPV 0
MSP 0    Max Repair 200 MSP
Habitation Capacity 1,000,000   
Lieutenant Commander    Control Rating 1   BRG 
Intended Deployment Time: 3 months   

Commercial Active Sensor (1)     GPS 1920     Range 27.3m km    Resolution 120

This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as an Orbital Habitat for construction purposes
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 22, 2018, 10:46:51 AM
About Orbital Habitats:

wouldn't it make more sense to chance the "Commander" of a non-military habitat to a "Civil Admin slot" instead of a Naval Commander slot? The example habitat Steve posted today is a pure living station, so a civil commander would be better suited than a military officer.. a miltary station should still need a military commander

It would add complexity to allow civilians to command naval ships (and give them naval-related bonuses) and I don't think the game play benefit would be worth it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Nori on February 22, 2018, 02:38:59 PM
Just thought of this, could FACs get a minor tracking speed bonus? They are so similar to fighters, but lose the best part (from a direct fire perspective). If they could get a 2x bonus (vs the 4x for fighters).

Can a ship be setup to do something once x is reached at another location? For instance, it'd be great to have a cargo group setup to load materials from a colony once that colony hits a certain level.

Similar to that, can a order template have more flexibility for modifying earlier orders? For instance, if I have a template to pickup mines, it'd be great if I could easily change that to automated mines without redoing the whole template, or changing the final unload location (same system though).
Title: Re: C# Aurora v0.x Suggestions
Post by: swarm_sadist on February 22, 2018, 04:04:02 PM
Just thought of this, could FACs get a minor tracking speed bonus? They are so similar to fighters, but lose the best part (from a direct fire perspective). If they could get a 2x bonus (vs the 4x for fighters).

Perhaps something like a to-hit chance based on the size of the target instead of a fixed, arbituary number. A smaller fighter could just be harder to target than a large fighter, and a larger fighter is harder to hit than an FAC.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 22, 2018, 04:09:21 PM
For instance, it'd be great to have a cargo group setup to load materials from a colony once that colony hits a certain level.

You can already do this one in VB6. The move order is "Load Mineral when X available"

Title: Re: C# Aurora v0.x Suggestions
Post by: Conscript Gary on February 22, 2018, 11:47:12 PM
This is almost more of an idle thought than a fully-weighed suggestion, but-

At present, the only hard distinctions between ship classes are as follows: Whether a ship has military or commercial drives for the purposes of using jump drives, whether a ship is military or civilian for maintenance and morale purposes, and whether a ship is a fighter or literally anything else.

That last one sticks out to me as the most 'arbitrary' of them. Whether you're a conventional empire, a fledgling TN race, or someone with mastery of the stars strong enough to challenge the [spoilers]- a fighter factory can only produce designs up to 500 tons, across the entire span of the game. Your industrial base and shipyard tech might reach the point where you have gargantuan warships as your standard combatants, but a fighter will only ever be 500 tons or less.

So, my suggestion is to add a new tech line that determines the capacity of your fighter factories. It can be an extremely expensive tech, but I feel like allowing even a bit of wiggle room in the flexibility of those factories would jive well with overall progression.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on February 23, 2018, 12:24:32 AM
Initiate Unrest:

For roleplaying reasons it might be nice if the SpaceMaster could initiate (and end) events of unrest on a certain colony.
Example: I conquered an alien race with three planets in one system and decided to relocate all of them to one colony (to repopulate the one I am emptying with my own pop). Doing that in real life would cause some kind of protests - so to simulate this in game it would be nice if the spacemaster can set flags so that the political and economical modifiers would increase.
Title: Re: C# Aurora v0.x Suggestions
Post by: jonw on February 23, 2018, 03:04:52 AM
Could we have multiple tractor units per ship?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 23, 2018, 04:49:58 AM
This is almost more of an idle thought than a fully-weighed suggestion, but-

At present, the only hard distinctions between ship classes are as follows: Whether a ship has military or commercial drives for the purposes of using jump drives, whether a ship is military or civilian for maintenance and morale purposes, and whether a ship is a fighter or literally anything else.

That last one sticks out to me as the most 'arbitrary' of them. Whether you're a conventional empire, a fledgling TN race, or someone with mastery of the stars strong enough to challenge the [spoilers]- a fighter factory can only produce designs up to 500 tons, across the entire span of the game. Your industrial base and shipyard tech might reach the point where you have gargantuan warships as your standard combatants, but a fighter will only ever be 500 tons or less.

So, my suggestion is to add a new tech line that determines the capacity of your fighter factories. It can be an extremely expensive tech, but I feel like allowing even a bit of wiggle room in the flexibility of those factories would jive well with overall progression.

The 500 ton limit has meaning in C# Aurora. Trans-Newtonian ships operate mainly in the Aether dimension, so larger vessels cannot get too close to any real space system bodies due to the latter's disruption of the Aether within a hundred kilometres of their surface. That is why cargo can no longer be transferred to a planet without cargo shuttles and construction factories need a spaceport in order to build space stations. Ships with a small enough mass (500 tons or less) can operate close to system bodies (in support of ground forces) and can even be produced on the surface (by fighter factories).

BTW I really should wrote a full TN technobabble post
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 23, 2018, 04:50:58 AM
Could we have multiple tractor units per ship?

I'm trying to avoid that due to complexities of tractor chains.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on February 23, 2018, 04:59:37 AM
I'm trying to avoid that due to complexities of tractor chains.

I may fail to understand what you mean.

And wouldn't it be possible to declare a ship that is being tractored as unable to tractor something themselves?

And with that, wouldn't it be possible when 1 ship tractors multiple vessels to sum up the total tractored weight for movement calculations?
Title: Re: C# Aurora v0.x Suggestions
Post by: Ranged66 on February 23, 2018, 09:26:27 AM
Been following this game for years but never really got active in the community, great game though!

Would it be possible to have some more overview windows? For example, a general mining report that shows just how much of every mineral all mines in your empire make per year.  Next to it projected usage per year or something.  Would really help with determining if shortages will arrive or what to focus on.  Especially once you start having mining operations on a dozen or so worlds.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on February 23, 2018, 03:21:08 PM
Automatic Naming Patterns for Ships. Is it possible to add a function that enables to define the pattern of auto-naming fighters?
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on February 24, 2018, 03:13:25 AM
Improving the way you set up and edit ship formations plus attendant FACS and fighters would be great. With the sensor changes I’m expecting more us of pickets etc but at present it is quite a lot of effort to set up and then edit. Some flex on deciding which elements will detach from the main TG at any particular point in time would be helpful.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 24, 2018, 05:05:08 AM
Improving the way you set up and edit ship formations plus attendant FACS and fighters would be great. With the sensor changes I’m expecting more us of pickets etc but at present it is quite a lot of effort to set up and then edit. Some flex on deciding which elements will detach from the main TG at any particular point in time would be helpful.

I haven't written the formation code yet but I will make improvements on the VB6 version.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on February 24, 2018, 07:42:37 AM
A way to edit "Plotted Moves" would be nice. Don't know how much effort it would be in C# but having to redo a whole move-chain because you missed something is quite tedious. Another idea would be some kind of automation system for repetitive jobs (moving AMs, MDs etc. from A to B when doing it yourself) and having to "handclick through all the necessary steps" could be done easier with "general templates". You select a general template and then have to select only source and target destination as well as to what should be transported. Then you select how many cycles and the "plotted moves" are then automatically generated by the program.
Also a change in cycle move might be nice - something in the line of marking several steps and define "repeat those three times" - and the once before and after are not "cycled". Just a thought...
Title: Re: C# Aurora v0.x Suggestions
Post by: Tree on February 24, 2018, 10:55:17 AM
I'm not sure how that'd interact with your rework on them, so it's all from VB, I'll admit.
Can you make it so a planet that isn't visited regularly by civilian colony ships slowly becomes more and more attractive to them?

Often when I have one homeworld and say 2 colonies at col cost 0, civilian colony ships will only fly between the homeworld and the closest colony, unless I set it to "stable" for some time. (I suspect even with your change, civilians colony ships would only fly the route that gives them the most wealth/time and forget the rest exists.) So could you make it so if the second, more distant colony hasn't seen civilian colony ships in a while, the reward for civilian colony ships would slowly ramps up until eventually they find it more interesting than the closest colony? It'd slowly go back down as colonists start being unloaded there.
I think it'd be better to make un-flown routes offer more money than make the over-used ones offer less, it'd keep their and your income about constant. You'll likely get a bit more since between the time they decide on their new target that'd bring them just one more wealth and by the time they get there, the reward would have kept going up. If you make their most-used routes less rewarding though they'll go use another, make it less rewarding and keep switching, making all the trade routes less and less rewarding, spiraling down until they're not making any money anymore at all. If there's a hard cap to ensure there's always a decent-ish minimum reward, some routes would still appear less interesting than another's minimum and never be used at all.

I'm not super sure it affects freighters because I only ever get very few of them, but it seems having more trade goods to pick from than just "colonists" helps them fly more randomly and that they might not need incentives to fly to other places.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 24, 2018, 11:00:52 AM
I'm not sure how that'd interact with your rework on them, so it's all from VB, I'll admit.
Can you make it so a planet that isn't visited regularly by civilian colony ships slowly becomes more and more attractive to them?

Often when I have one homeworld and say 2 colonies at col cost 0, civilian colony ships will only fly between the homeworld and the closest colony, unless I set it to "stable" for some time. (I suspect even with your change, civilians colony ships would only fly the route that gives them the most wealth/time and forget the rest exists.) So could you make it so if the second, more distant colony hasn't seen civilian colony ships in a while, the reward for civilian colony ships would slowly ramps up until eventually they find it more interesting than the closest colony? It'd slowly go back down as colonists start being unloaded there.
I think it'd be better to make un-flown routes offer more money than make the over-used ones offer less, it'd keep their and your income about constant. You'll likely get a bit more since between the time they decide on their new target that'd bring them just one more wealth and by the time they get there, the reward would have kept going up. If you make their most-used routes less rewarding though they'll go use another, make it less rewarding and keep switching, making all the trade routes less and less rewarding, spiraling down until they're not making any money anymore at all. If there's a hard cap to ensure there's always a decent-ish minimum reward, some routes would still appear less interesting than another's minimum and never be used at all.

I'm not super sure it affects freighters because I only ever get very few of them, but it seems having more trade goods to pick from than just "colonists" helps them fly more randomly and that they might not need incentives to fly to other places.

In C#, colony ships will always prioritise colonies with no other colony ship inbound over closer colonies that are already colony ship destinations
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on February 24, 2018, 01:48:51 PM
Can we have more ways to sort and/or filter things?  Mostly I'm thinking about the task group list in the task group orders window, and the class list on the class design window.

Right now, it's pretty annoying to constantly have to scroll and search through the list of task groups when I want to issue a new order.  So I suggest making the TG list more of a tree, using the hierarchy set up in the Task Force Organization window.  This way I could keep commercial TG's, survey TG's, and military TG's separate, without being forced to use goofy names to take advantage of the alphabetical order.

I also suggest something similar for any list of ship classes.  Give us a better way to manage them than a single, linear list.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 24, 2018, 01:54:40 PM
Can we have more ways to sort and/or filter things?  Mostly I'm thinking about the task group list in the task group orders window, and the class list on the class design window.

Right now, it's pretty annoying to constantly have to scroll and search through the list of task groups when I want to issue a new order.  So I suggest making the TG list more of a tree, using the hierarchy set up in the Task Force Organization window.  This way I could keep commercial TG's, survey TG's, and military TG's separate, without being forced to use goofy names to take advantage of the alphabetical order.

I also suggest something similar for any list of ship classes.  Give us a better way to manage them than a single, linear list.

You should have a read through the changes thread and the screenshots thread. All of the above is already in C# Aurora :)

http://aurora2.pentarch.org/index.php?topic=8455.0
http://aurora2.pentarch.org/index.php?topic=8495.0

As an example:

(http://www.pentarch.org/steve/Screenshots/FleetTree.PNG)
Title: Re: C# Aurora v0.x Suggestions
Post by: Lazerus on February 24, 2018, 09:05:54 PM
http:aurora2.pentarch.org/index.php?topic=9846.0 (http://aurora2.pentarch.org/index.php?topic=9846.0)

Linking my thread for proposed changes to officers in relation to the upcoming C# model, especially in relation to the changes to admin commands and the new billets on ships.

[EDIT BY JOHN: Fixed link that was mangled due to too few posts by poster]
Title: Re: C# Aurora v0.x Suggestions
Post by: SpaceCowboy on February 26, 2018, 12:40:49 PM
I'll repost a possible change I suggested in the C# discussion thread: that real star systems with known planets in real life generate with those planets.  That is, something like Proxima Centauri will always have a 1. 25 Earth-mass planet orbiting 7. 2 MKm away from it.  All the known planets would exist in a database, and the existing system generation code would be modified to generate other planets and asteroids around the real planets.  So we have Prox Cen b, and then maybe some Jupiter-mass companion and asteroid belts out at 2 AU (or something).

Steve, I'm an exoplanet astronomer by day, and I'd be happy to help compile the planet information for you, suggest modifications to the system generation code, or even help modify it myself.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 26, 2018, 12:56:43 PM
I'll repost a possible change I suggested in the C# discussion thread: that real star systems with known planets in real life generate with those planets.  That is, something like Proxima Centauri will always have a 1. 25 Earth-mass planet orbiting 7. 2 MKm away from it.  All the known planets would exist in a database, and the existing system generation code would be modified to generate other planets and asteroids around the real planets.  So we have Prox Cen b, and then maybe some Jupiter-mass companion and asteroid belts out at 2 AU (or something).

Steve, I'm an exoplanet astronomer by day, and I'd be happy to help compile the planet information for you, suggest modifications to the system generation code, or even help modify it myself.

I have considered this in the past. The issue is that the system generation code is quite complex and it can be hard to adjust it around ensuring certain planets are in the right locations while having everything else make sense. Plus, I am not sure how what is already known about affects what else may be possible. Would there be an undetected gas giant in a system with a detected terrestrial world for example? It might be easier to have some preset systems instead.

One other consideration is the current generation method adds a lot of variety, which would not be there is the same planets are always in the same locations. Doesn't prevent it being an option though.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on February 26, 2018, 01:19:53 PM
I will repost one suggestion from another thread...

Please change the way you implement the wait command fro VB6. In VB6 this was not working great and not working at all with cycled orders, as far as I know.

I think it would be better to just have them as a regular command, three new ones... Wait in seconds, wait in hours, wait in days. You can then just inject these orders as any regular order and it is easily recognized and tracked.
Title: Re: C# Aurora v0.x Suggestions
Post by: gaz on February 27, 2018, 02:10:56 AM

No idea whether this has been mooted before (guessing it has)  - but be awesome to have solar bodies mask / reduce sensor profiles etc.  .  .

ie the possibility for sensor blind spots based on solar bodies - or how about gas clouds etc.  .  .  .   Im thinking Wrath of Khan  star Trek.  .  .  .  .

"The invasion fleet approaching from the dark side of the moon".  .  .  .  .   Defender fleets hiding behind moons etc

Be great - Im guessing would be a ball ache to programme in - but if possible just add a whole new level of depth.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on February 27, 2018, 06:44:42 AM
Please change the way you implement the wait command fro VB6. (...)

I think it would be better to just have them as a regular command, three new ones... Wait in seconds, wait in hours, wait in days. You can then just inject these orders as any regular order and it is easily recognized and tracked.
More options to "wait on a specific action or state" would be nice. E.G.: wait until fleet has joined this fleet, wait until x amount of fuel is in cargo of target fleet (for transporting them from harvesters to a colony), wait until x amount of mineral(s) is at target colony, wait until x amount of installation is at target colony, etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: clement on February 27, 2018, 09:36:31 AM
Steve,

After seeing your screenshot of the named waypoints and specifically the "Fleet Exercise Area" waypoint, would it be possible to assign a waypoint (or other destination) to the Fleet Training action?

If assigned, the fleet would move to that waypoint/location and then stay within a certain distance while performing fleet training exercises?
If unassigned, the fleet would behave as currently designed.

As a secondary item, the UI might need to allow a distance to be added to the order to control how far the fleet ranges from the waypoint. I would require the distance to have a minimum (and default), perhaps the range of the longest ranged missile in the fleet or 25 million KM if no missiles are in the fleet.

Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 27, 2018, 10:13:26 AM
Steve,

After seeing your screenshot of the named waypoints and specifically the "Fleet Exercise Area" waypoint, would it be possible to assign a waypoint (or other destination) to the Fleet Training action?

If assigned, the fleet would move to that waypoint/location and then stay within a certain distance while performing fleet training exercises?
If unassigned, the fleet would behave as currently designed.

As a secondary item, the UI might need to allow a distance to be added to the order to control how far the fleet ranges from the waypoint. I would require the distance to have a minimum (and default), perhaps the range of the longest ranged missile in the fleet or 25 million KM if no missiles are in the fleet.

Yes, I had this in mind when I named that waypoint :)
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on February 28, 2018, 07:20:22 AM
Speaking of training missile warships and fighters it might make sense if they actually had to launch fighters/expend live missiles during training or at least could do so to speed up the progress.

I like to RP that each launcher need to fire at least once and Fighters fly one sortie during training to not have a SM fail chance when used in anger for real the first time.

This could also make spying on enemy training manouvers a thing if implemented well.. or maybe I'm going into unnessecary detail here
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 28, 2018, 09:16:21 AM
Speaking of training missile warships and fighters it might make sense if they actually had to launch fighters/expend live missiles during training or at least could do so to speed up the progress.

I like to RP that each launcher need to fire at least once and Fighters fly one sortie during training to not have a SM fail chance when used in anger for real the first time.

This could also make spying on enemy training manouvers a thing if implemented well.. or maybe I'm going into unnessecary detail here

I guess in that case there should be the option to build cheaper training missiles
Title: Re: C# Aurora v0.x Suggestions
Post by: serger on February 28, 2018, 01:02:39 PM
I guess in that case there should be the option to build cheaper training missiles
Yep, it will be great!
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on February 28, 2018, 01:21:29 PM
I guess in that case there should be the option to build cheaper training missiles

Maybe just making training use MSP then? There doesn't seem to be much point in tracking training specific missiles.

edit: If you do that it might also be a good opportunity to modify how fuel use while training works and can vary based on the speed of the slowest ship in the fleet.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on February 28, 2018, 02:08:20 PM
Please no. I think I'd go insane if I had to even design, build and use training missiles.

If you really want to model training, a maintenance supplies usage will be enough...
Title: Re: C# Aurora v0.x Suggestions
Post by: Graham on February 28, 2018, 02:16:10 PM
I agree with Zincat.

Training already has it's costs and I would rather not have another thing to micro which I don't think will add much game play value.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on February 28, 2018, 03:55:50 PM
Id kindof prefer a training missile item.  Doesn't need to be specially designed by the player but it adds some depth if ships out on training are carrying less live ordnance due to their load of training missiles and get caught by the enemy.  Making even more things just an MSP cost is a terrible cop out that isnt even worth adding imo.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on February 28, 2018, 04:27:02 PM
Can we get a proper fleet combat interface that allows to assign targets to fire controls on an entire fleet instead of having to cycle through each individual ship?

My idea involves fire controls getting set to a fleet fire control channel. These channels then manage all fire controls assigned to them, so you might have a "Beams" channel, a "Beam PD," a "Missile PD", or a "Missile" channel.
Assigning targets (Multiple selection allowed) to a channel means all fire controls will fire on those selected targets.
Channels could have various options, max salvos in flight, max salvos per target in flight, focus fire, spread fire, point defense availability

Target selection would be inherited if a lower formation doesn't override it. So if the channel "Missile" of 1st Fleet targets the enemy battleships, the channel "Missile" of 2nd Squadron of 1st fleet can target an escort, then the Squadron will fire at the escort until it is destroyed, then will switch to the battleships set by the Fleet wide level.

All this would make handling large battles much easier. I don't see anyone having fun assigning each fighter a target when a hundred fighters clash with another hundred.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 28, 2018, 04:53:44 PM
Can we get a proper fleet combat interface that allows to assign targets to fire controls on an entire fleet instead of having to cycle through each individual ship?

My idea involves fire controls getting set to a fleet fire control channel. These channels then manage all fire controls assigned to them, so you might have a "Beams" channel, a "Beam PD," a "Missile PD", or a "Missile" channel.
Assigning targets (Multiple selection allowed) to a channel means all fire controls will fire on those selected targets.
Channels could have various options, max salvos in flight, max salvos per target in flight, focus fire, spread fire, point defense availability

Target selection would be inherited if a lower formation doesn't override it. So if the channel "Missile" of 1st Fleet targets the enemy battleships, the channel "Missile" of 2nd Squadron of 1st fleet can target an escort, then the Squadron will fire at the escort until it is destroyed, then will switch to the battleships set by the Fleet wide level.

All this would make handling large battles much easier. I don't see anyone having fun assigning each fighter a target when a hundred fighters clash with another hundred.

In VB6 you can use the Combat Overview window to assign fleet wide targeting.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on March 01, 2018, 01:53:01 AM
I guess in that case there should be the option to build cheaper training missiles

No I don't think that level of complexity would add much to the game. Just have them fire less real missiles instead ( if training missiles would be 20% cost and you fire 20 of them then mechanically it's the same to fire 4 live missiles ). Leaving it optional so players that really want to micro either for minmax or for RP could "design" their own training missiles using standard tools I think would work better.

Something else I thought would be pretty cool is to be able to use your own uncrewed obsolete ships as training targets, and in the process learn both about their damage resistance and your own weapon efficiency.

Id kindof prefer a training missile item.  Doesn't need to be specially designed by the player but it adds some depth if ships out on training are carrying less live ordnance due to their load of training missiles and get caught by the enemy.  Making even more things just an MSP cost is a terrible cop out that isnt even worth adding imo.

This could maybe be handled by having ships on training not be allowed to use their full munitions load-out but a certain percentage?
Title: Re: C# Aurora v0.x Suggestions
Post by: El Pip on March 01, 2018, 02:19:57 AM
All this talk about training missiles got me thinking, could we have crew experience gain make a bit more sense?

Having crew gain experience when their ships armour is hit, but not when the shields are hit always seemed a bit odd. It also seemed odd that causing damage didn't give the firing crew any experience gain.

A system where the crew can gain grade from firing training missiles (and maybe other crews could get grade from shooting them down) could be interesting and would add a bit more depth to Fleet Training. You could set up fleet exercises, have one portion of your fleet try to sink the other, that sort of thing.

It would give you something to do while you wait for your explorers to find aliens. :)
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on March 01, 2018, 02:52:55 AM
Hopefully a fairly simple suggestion, in the orders list we currently have jump and split task group and also detach non survey craft. Would it be possible to have the reverse of these orders so I can get a survey group to jump and then detach the survey craft instead?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 01, 2018, 04:01:40 AM
All this talk about training missiles got me thinking, could we have crew experience gain make a bit more sense?

Having crew gain experience when their ships armour is hit, but not when the shields are hit always seemed a bit odd. It also seemed odd that causing damage didn't give the firing crew any experience gain.

A system where the crew can gain grade from firing training missiles (and maybe other crews could get grade from shooting them down) could be interesting and would add a bit more depth to Fleet Training. You could set up fleet exercises, have one portion of your fleet try to sink the other, that sort of thing.

It would give you something to do while you wait for your explorers to find aliens. :)

The reason for damage having an impact while firing doesn't is an effort to simulate combat stress. Blowing up helpless enemy ships can't compare to being engaged in heavy combat, so firing doesn't necessarily indicate combat stress, while damage does.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 01, 2018, 04:50:17 AM
A system where the crew can gain grade from firing training missiles (and maybe other crews could get grade from shooting them down) could be interesting and would add a bit more depth to Fleet Training. You could set up fleet exercises, have one portion of your fleet try to sink the other, that sort of thing.

It would give you something to do while you wait for your explorers to find aliens. :)

That is a very interesting idea. The ability to designate part of your own forces as a 'red force' would not only permit training, but allow players to understand combat without losing ships. Perhaps ships could also be set to 'training mode'. If they take damage from friendly ships that are also in training mode, that damage vanishes when they exit training mode (using the assumption it was all simulated damage). Missiles fired in training mode would reappear in magazines (simulated fire). That could even allow allies to train against each other.

Training mode would end automatically if a hostile contact was detected. 
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on March 01, 2018, 05:12:39 AM
That is a very interesting idea. The ability to designate part of your own forces as a 'red force' would not only permit training, but allow players to understand combat without losing ships. Perhaps ships could also be set to 'training mode'. If they take damage from friendly ships that are also in training mode, that damage vanishes when they exit training mode (using the assumption it was all simulated damage). Missiles fired in training mode would reappear in magazines (simulated fire). That could even allow allies to train against each other.

Training mode would end automatically if a hostile contact was detected.

That would be really cool. I also always wanted a better way to test out or "simulate" the performance of my fleets without actually having to risk them or spending hours in spreadsheets & on the wiki. Perhaps some stats could even be unknown or quite inaccurate before you have run weapons through actual tests ( like too hit chance vs certain speeds for example ).
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on March 01, 2018, 07:43:27 AM
Perhaps some stats could even be unknown or quite inaccurate before you have run weapons through actual tests ( like too hit chance vs certain speeds for example ).

Do you mean something like the following by this?

1)  The hit chance when a system is originally designed is a "nominal" value.
2)  The actual value would be NominalValue*RandomMultiplier where random multiplier runs from e.g. 0.5x - 2x (uniformly on a log scale).
3)  The player would originally see the nominal value in dialogs, but as the system gets exercised/tested/used in combat the value would gradually change to actual value.
4)  The value would be tracked on a researched component level.  So e.g. an engine might have the power and fuel consumption adjusted, and would use the same parameters in all classes in which it was used.

On the one hand, I think that's really cool and realistic from the point of view of actual systems no matching design specs (e.g. early WWII US torpedoes).  OTOH it's more micromanagement.  OTGH, it puts a lot more fog of war into component design - minmax players wouldn't be guaranteed that subtly tweaking a design for an extra 5% would actually give them that 5%.  It would make component design more like rolling characters in D&D, with the tweak that you have to do real-life testing of the components to tell if you got a lemon and want to reroll the same design.

John
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 01, 2018, 08:16:05 AM
Training mode would end automatically if a hostile contact was detected.

It might be fun(ny), if it doesn't :-)
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on March 01, 2018, 08:26:04 AM
Do you mean something like the following by this?

1)  The hit chance when a system is originally designed is a "nominal" value.
2)  The actual value would be NominalValue*RandomMultiplier where random multiplier runs from e.g. 0.5x - 2x (uniformly on a log scale).
3)  The player would originally see the nominal value in dialogs, but as the system gets exercised/tested/used in combat the value would gradually change to actual value.
4)  The value would be tracked on a researched component level.  So e.g. an engine might have the power and fuel consumption adjusted, and would use the same parameters in all classes in which it was used.

On the one hand, I think that's really cool and realistic from the point of view of actual systems no matching design specs (e.g. early WWII US torpedoes).  OTOH it's more micromanagement.  OTGH, it puts a lot more fog of war into component design - minmax players wouldn't be guaranteed that subtly tweaking a design for an extra 5% would actually give them that 5%.  It would make component design more like rolling characters in D&D, with the tweak that you have to do real-life testing of the components to tell if you got a lemon and want to reroll the same design.

John

Yes, although instead of actually change to correct value it would "calculate" value derived empirically based on actual data of hits achieved. So if your really lucky with rolls when testing out a weapon it could lead you to thinking the design was much better then it actually is, and so you can't predict in what direction it will move ( if it started moving in one direction that would instantly give away if it was a good or bad "roll" ).

For balance you probably want the distribution of actual values to not be able to go all the way up to 2x ( so that you can't accidentally make an engine that's 3 tech levels more advanced ), but it could go quite far downwards on the scale ( especially for munitions which if untested could be really bad like mentioned US WW2 torpedoes ). The mean value of actual should be same as Nominal display though.

Probably not something practical possible for the game but it's fun to dream :)
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 01, 2018, 08:37:56 AM
How about some kind of "fake buoy" which emits the identical attributes of the ship that launches it. Would be a nice "help" in case you are a lone scout which is encountered by an enemy. So you launch two or three of those buoys into different direction which makes the enemy have to choose which one he wants to follow, or make him having to split up his fleet.

Limits of this buoy: can emit only for a certain amount of time (which might be researchable). 1 hour, then 2 up to 8 at maximum. Also when coming to a certain range and sensor capacity the fake information breaks together and it is identified as a fake buoy.
Title: Re: C# Aurora v0.x Suggestions
Post by: Titanian on March 01, 2018, 11:37:27 AM
1)  The hit chance when a system is originally designed is a "nominal" value.
2)  The actual value would be NominalValue*RandomMultiplier where random multiplier runs from e.g. 0.5x - 2x (uniformly on a log scale).
3)  The player would originally see the nominal value in dialogs, but as the system gets exercised/tested/used in combat the value would gradually change to actual value.
4)  The value would be tracked on a researched component level.  So e.g. an engine might have the power and fuel consumption adjusted, and would use the same parameters in all classes in which it was used.
I really like this although I'd say the ranges have to be smaller.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on March 01, 2018, 03:31:30 PM
In VB6 you can use the Combat Overview window to assign fleet wide targeting.

In the combat overview one can copy either one target to the entire fleet, or get each ship to target a different unit. But this is restricted as far as I can tell to ships of the same class, and has only these few special functions that are available. What I would like to see is a vast expansion of this system, that instead of assigning targets to fire controls on each individual ship assigns weapons to targets on a fleet basis.
Basically a screen that shows all FC in a fleet, all missiles in flight, and controls to assign multiple targets to FCs, and control how many salvos should be fired on each target, how many salvos fired in total. Again if you wanted 100 fighters fire at 50 specific targets, you right now have to assign each individual fire control, instead of selecting all fighters, and the 50 wanted targets and assign them to each other, letting the fighters sort out which one fires at which.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 02, 2018, 03:27:14 AM
To simplify managing bigger empires having civilian trade also transport minerals would be an ideal addition. Maybe in terms of using the "mineral limit" values as a measurement of automating those orders. If on a colony the mineral amount is lower than the minimum this generates a demand for this mineral and the civilians take a look around which planets do have that mineral in abundance (maybe two or three times over the minimum value) and transport that to the target planet.
Title: Re: C# Aurora v0.x Suggestions
Post by: eponymous on March 02, 2018, 07:47:20 AM
user-defined trade good routes

i would like a screen where i could define a trade good route:  mars needs illegal drugs and produces precious metals, alpha centauri 2 produces drugs needs precious metals.   longer cycles would be useful but two-planet ones would suffice i believe.

the computer would look at the smallest of those four numbers (the two annual supply and two shortfall), and would appropriate that much of all four quantities for the "caravan".   computer could auto-assign ships to the route and update the capacity of the route intermittently (as populations expand and productivity tech improves).   conceivably the ships on a route form a single task force (make map nicer and maybe help with processor slowdown), and new ships assigned would be the smallest available class with a speed at least equal to the caravan's current speed.   civvies in a caravan would be unavailable for other hauling duties (as they are in use 100% of the time).
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on March 02, 2018, 08:06:46 AM
To simplify managing bigger empires having civilian trade also transport minerals would be an ideal addition. Maybe in terms of using the "mineral limit" values as a measurement of automating those orders. If on a colony the mineral amount is lower than the minimum this generates a demand for this mineral and the civilians take a look around which planets do have that mineral in abundance (maybe two or three times over the minimum value) and transport that to the target planet.

If we go down that route, I think it would be ideal to have a way to specify which planets/colonies civilian freighters are allowed to consider when they're looking for where to acquire minerals, and maybe even the ability to designate which minerals they're allowed to take from which planets/colonies.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on March 04, 2018, 05:00:29 PM
Following the recent change to cost in civilian contracts, I would like to suggest a clearer, immediately viewable cost for trade contract.

Say that you order 10 mines to be moved from planet A to planet B, I think it would be nice to see the cost just as you give the order. Say, 300 wealth.

This would also be useful because it's kind of hard sometimes to remember the size of certain installations. Would also be nice to see how many trips it takes, which translates into how much time it will take.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on March 04, 2018, 06:08:12 PM
Traders tend to refuse to do long runs in vb6 unless there is no other option, I assume as a marginal cost thing.  Could we offer premium prices to get them to do long hauls?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 04, 2018, 06:58:31 PM
Traders tend to refuse to do long runs in vb6 unless there is no other option, I assume as a marginal cost thing.  Could we offer premium prices to get them to do long hauls?

Will be easier in C#. Long haul installation runs are now higher priority than short-haul trade runs for civilians. Bear in mind you are disrupting the economy though when you do this. Also, you are now paying a lot more for long-haul runs anyway.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on March 05, 2018, 08:41:00 AM
In respect of task group training it would be good if there were some more options to accelerate the time required to get ships trained up such that they no longer get order delays etc in combat. My thought on this is whether military academies could be set to improve initial training rather than provide a bonus. Ie rather than get a 2% increase as a result of reducing rates of training could this be made a 20% bonus to TG training? Alternatively could we have another structure outside of academies that acts as a finishing facility (much in the same way we have land based “ships” such as HMS Collingwood) where we could train batches of crew to higher TG training before they get into a real ship?
Title: Re: C# Aurora v0.x Suggestions
Post by: smoelf on March 05, 2018, 01:04:16 PM
Posted on behalf of Reddit user Kazuar01 (since they seem to have trouble registering; https://www.reddit.com/r/aurora4x/comments/827ois/re_c_aurora_v0x_suggestions_official_board/ (https://www.reddit.com/r/aurora4x/comments/827ois/re_c_aurora_v0x_suggestions_official_board/)):

In VB6 Aurora v7.1, the way empires are represented on the galaxy overview is completly dependent on how the empire in question has setup itself in the Race Details Window; due to random generation for AI empires, this leads to a situation where NPRs and spoilers can end up with confusing combinations e.g:

1) NPR A with an orange flag and a purple system color, and NPR B with a purple flag and an orange system color

2) A hostile NPR has green systems while an allied NPR has red systems

3) Two NPRs end up with very similiar tones of the same color e.g. one with RGB 27/208/228 and the other with RGB 24/220/231.

Furthermore, all NPRs use the same graphic for their fleet, meaning a player can't tell, from a glance, whether an NPR fleet belongs to an ally or an enemy.

Neither of these problems can be solved via SM mode, as that would require access to an NPRs Race Details Window.

While the random generation routines could be worked over to make more sensible "choices" (and to include fleet graphic), my suggestion for C# Aurora would be for the color and fleet graphic choosen in the Race Details Window to only apply to how the empire is represented on its own galaxy map; and for fleet graphics and system color of other empires to "simply" be an editable setting in the Intelligence Window.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 05, 2018, 02:09:40 PM
In the event log there is one statement: Officer Update - which not only shows the progress an officer makes, but also if he retires. However, when I try to keep track of my officers the progress does not interest me, but if they retire. Could these two reports be separated in the log so I can filter out one and still see the other?
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 06, 2018, 12:42:22 AM
Pause Fleet Actions: sometimes it is necessary (e.g. civilian reloaction, fuel shortage) to pause a fleet in doing its cycled or preplanned actions. Having a button which does exactly that (so you don't have to recreate the whole list of fleet actions) would be nice.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on March 06, 2018, 11:02:59 AM
While the random generation routines could be worked over to make more sensible "choices" (and to include fleet graphic), my suggestion for C# Aurora would be for the color and fleet graphic choosen in the Race Details Window to only apply to how the empire is represented on its own galaxy map; and for fleet graphics and system color of other empires to "simply" be an editable setting in the Intelligence Window.

Would probably be better if what's chosen by the race detail window is the defaultv and you're given the option to edit it if you want.  Otherwise in a multi-player-empire game you'd have to make set up the look for each empire multiple times.
Title: Re: C# Aurora v0.x Suggestions
Post by: swarm_sadist on March 06, 2018, 05:16:32 PM
If we go down that route, I think it would be ideal to have a way to specify which planets/colonies civilian freighters are allowed to consider when they're looking for where to acquire minerals, and maybe even the ability to designate which minerals they're allowed to take from which planets/colonies.

Like a source, destination or stable preset for minerals?
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on March 06, 2018, 11:04:48 PM
Like a source, destination or stable preset for minerals?
I'm thinking the colonies would have somewhere in the population/production window (probably in the civilian/ind tab) where you can choose what minerals can be exported from the planet by civilians (if any).  This is only because the initial suggestion seemed to be that supplying the minerals for civilian transport shouldn't be done with the normal civilian contract system (to reduce micromanage, I'd assume).
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 08, 2018, 09:01:06 AM
When working with a multi-faction game I found it to be useful, having an excel sheet open where I then save remarks as to what country has what open tasks, or I need to remind myself of later. This is especially helpful when I pause such a game and come back to it month later.

So why not having that in game? One more SLQ-Table to save yourself some notes on what is going on in your empire(s). Ideally of course, manually sortable (drag&drop) so you can prioritize etc.  ;D
Title: Re: C# Aurora v0.x Suggestions
Post by: Conscript Gary on March 09, 2018, 02:40:14 AM
Bit of an out-there suggestion this time:

Remove the Duranium cost from building Infrastructure, have it purely consume time and money.

Since infrastructure can be created as a trade good, it's already possible to create it without spending resources besides time, technically. You could argue that the ability to prepare it on demand is worth the Duranium cost, but personally I always find myself wanting to take advantage of the 'free' trade good version because TNEs are a nonrenewable resource.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on March 09, 2018, 11:13:30 AM
Bit of an out-there suggestion this time:

Remove the Duranium cost from building Infrastructure, have it purely consume time and money.

Since infrastructure can be created as a trade good, it's already possible to create it without spending resources besides time, technically. You could argue that the ability to prepare it on demand is worth the Duranium cost, but personally I always find myself wanting to take advantage of the 'free' trade good version because TNEs are a nonrenewable resource.
Further, what about it is meant to be futuristic?  We could build dome or tunnel cities right now if we had the shipping to actually get to other planets.  Why does it need the high-tech materials if we could do it in real life?
Title: Re: C# Aurora v0.x Suggestions
Post by: TCD on March 09, 2018, 02:23:24 PM
Further, what about it is meant to be futuristic?  We could build dome or tunnel cities right now if we had the shipping to actually get to other planets.  Why does it need the high-tech materials if we could do it in real life?
That's a very slippery slope Barkhorn! Why should a financial center or a military academy need high-tech materials?

I think you can hand wave it all as saying that in a world of high-tech building materials then it would be considered backwards not to use them. Presumably the Martian settlers want the same mile-high towers, unsupported transport tubes, smart walls with holographic projection etc etc that they enjoyed on post-TN Earth.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on March 09, 2018, 02:54:45 PM
I disagree with the slippery slope thing, the idea of financial centers and military academies not needing them seems quasi reasonable to me, though less so.  You might need high tech materials to build high tech computers in order to run adequately advanced simulations for both the purposes of the academies and the financial centers.

The suggestion that its 'backwards' seems exceedingly iffy an excuse, I mean is that really a reason to stop all colonization ever until some duranium can be obtained?

I had mostly assumed it was just a vague attempt at balance, which was somewhat undermined by the free infrastructure the civilian market produces.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on March 09, 2018, 05:22:28 PM
Maybe civilian mines could actually deliver the duranium they mine which you don't buy and use that to build infrastructure ( and some other trade goods ) with?
Title: Re: C# Aurora v0.x Suggestions
Post by: Dr. Toboggan on March 09, 2018, 06:24:56 PM
Maybe civilian mines could actually deliver the duranium they mine which you don't buy and use that to build infrastructure ( and some other trade goods ) with?

You can already set them to do this. 

I disagree with the slippery slope thing, the idea of financial centers and military academies not needing them seems quasi reasonable to me, though less so.  You might need high tech materials to build high tech computers in order to run adequately advanced simulations for both the purposes of the academies and the financial centers.

The suggestion that its 'backwards' seems exceedingly iffy an excuse, I mean is that really a reason to stop all colonization ever until some duranium can be obtained?

I had mostly assumed it was just a vague attempt at balance, which was somewhat undermined by the free infrastructure the civilian market produces.

It could be argued since all of these buildings are controlled by the player, the buildings themselves have some sort of planetary security designation that requires them to be built out of TN materials.  The duranium cost of infrastructure could be lessened, or even eliminated (but with a higher wealth cost).  If your population can grow (and therefore, continue to build buildings) without consuming TN materials, then I don't see a reason why infrastructure could be cheapened.  Plus, all of the names of the minerals are from Star Trek, and we're always used as special materials rather than everyday building materials.
Title: Re: C# Aurora v0.x Suggestions
Post by: PlasmaXJ on March 09, 2018, 07:57:55 PM
This is just a suggestion, but maybe adding a recycling centers would be nice.  It could break components and missiles into minerals more efficiently.  It would work slowly (could be improved via tech).
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on March 10, 2018, 08:04:28 AM
Maybe civilian mines could actually deliver the duranium they mine which you don't buy and use that to build infrastructure ( and some other trade goods ) with?
I mentioned something like this in the discussion thread when people were talking about economics, and I still like the idea.  I think it might be nice to have civilian mines actually generate a Trans Newtonian Mineral trade good, and since this has been brought up it would certainly make sense for it to play a part in the production of Infrastructure at least.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on March 10, 2018, 08:49:23 AM
New Suggestion:

Adding a new TAB in the "Class Design" window with the "Setup fire controll" of the "Combar Assignments Overview" settings (or something like it) so it would be possible to link the weapons of the new design to fire-controlls etc in the design-phase- all new build ships would be build with this setting as "standart" (can be chanced later anytime like atm).

This would give the "planer" of a design the possibility to see if he has enough fire controll, if the weapons are like he wants etc pp

I really would like to see/plan the fire controll of my designs before building them if possible :)
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on March 10, 2018, 03:35:21 PM
You can already set them to do this. 

No. I am taking about the minerals that you don't buy being used for trade goods -> infra generation which is built for free now.
Title: Re: C# Aurora v0.x Suggestions
Post by: Dr. Toboggan on March 10, 2018, 08:20:26 PM
No. I am taking about the minerals that you don't buy being used for trade goods -> infra generation which is built for free now.

That's a thing? I thought you were talking about "purchase output" from CMC's.
Title: Re: C# Aurora v0.x Suggestions
Post by: Lazerus on March 10, 2018, 11:38:47 PM
Added a new suggestion in my officer changes thread regarding them and the proposed ship modules for officers.

http://aurora2.pentarch.org/index.php?topic=9846.msg107100#msg107100
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on March 11, 2018, 07:16:23 AM
That's a thing?

It's not "a thing" which is why I am suggesting it should be!   ::)

( Because neither duranium vanishing into thin air when you don't buy it nor infrastructure being conjured out of thin air for free makes sense )
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 11, 2018, 07:52:40 AM
It's not "a thing" which is why I am suggesting it should be!   ::)

( Because neither duranium vanishing into thin air when you don't buy it nor infrastructure being conjured out of thin air for free makes sense )

It is a good point. So 'free infrastructure' would only be created based on the Duranium mined by civilian mines (that isn't purchased). Civilian mines can't exist without a large pop in the system so the infrastructure could appear at the system's largest population. Its abstract, but avoids complexity around transportation and production, is much more realistic than now and also slows down the initial civilian growth.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on March 11, 2018, 08:21:48 AM
Considering that civilian mines mine all minerals, and preferentially select for high quality Duranium and Sorium deposits while not selecting low quality deposits of these minerals no matter how large nor deposits of any other materials this doesn't sound like a good idea to me. You'd have to link civilian ship production to mining of other materials as well and work out more of the civilian economical background activity.

It'd be easier to explain Infrastructure as costing no minerals but large amounts of wealth.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 11, 2018, 08:36:49 AM
Considering that civilian mines mine all minerals, and preferentially select for high quality Duranium and Sorium deposits while not selecting low quality deposits of these minerals no matter how large nor deposits of any other materials this doesn't sound like a good idea to me. You'd have to link civilian ship production to mining of other materials as well and work out more of the civilian economical background activity.

I have considered this in the past as well, plus fuelling civilian ships from civilian harvesters. It adds a lot of complexity around civilians though and it is probably not worth it. The proposal about Duranium for infrastructure does add a useful extra dimension though as it slows down civilian growth and adds meaningful decisions for players regarding the construction of infrastructure.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on March 11, 2018, 09:31:27 AM
Cool

Longer term it might be cool to have other minerals be used for production of other trade goods ( weighted so minerals availability influence type goods production ), be able to buy minerals from the civilian market ( price scaled by availability ) and have civilians transport around minerals where a profit can be made.

This could cut out alot of micromanagement of hauling around minerals manually ( you just vacuum the civilian market skyrocketing the price and civilians rush to exploit the opportunity to get their hands on that cash ) and lead to a pretty cool and dynamic supply and demand model.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on March 11, 2018, 02:06:33 PM
I am a bit ambivalent about this. As someone who plays conventional start, it means I will have to devote a LOT of time building infra for new colonies...

Or avoid buying some minerals from CMC, but I'm used to just buying everything, since TN minerals are at a premium when it takes years to leave your home system. And so I generally buy every single scrap of metal they produce.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on March 11, 2018, 03:11:49 PM
I am a bit ambivalent about this. As someone who plays conventional start, it means I will have to devote a LOT of time building infra for new colonies...

Or avoid buying some minerals from CMC, but I'm used to just buying everything, since TN minerals are at a premium when it takes years to leave your home system. And so I generally buy every single scrap of metal they produce.

I kind of like the struggling part of conventional starts. Wish that it was modeled in even more details with chemical rockets ( low fuel / inefficient ) more conventional techs, and so on
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on March 11, 2018, 06:27:37 PM
I have considered this in the past as well, plus fuelling civilian ships from civilian harvesters. It adds a lot of complexity around civilians though and it is probably not worth it. The proposal about Duranium for infrastructure does add a useful extra dimension though as it slows down civilian growth and adds meaningful decisions for players regarding the construction of infrastructure.

It breaks consistency with TN materials not actually being important to civilians and instead more of an abstract that can be used as a cash cow or useful source of minerals. I mean, Civilian Mining Colonies are worth 10 Automated Mines, but Automated Mines cost 120 Duranium and 120 Corundum each so that's 2400 in minerals right there for each CMC. Building civilian ships would require Duranium (structural components), Sorium (fuel, which is not tracked for civilians except for sale to the civilian market), Neutronium (shipyards to build all those ships and bases), Mercassium (Crew quarters/life support) and Gallicite for the engines. And there's those free garrison units that you get in VB6 and most likely will still get in C# which cost Duranium and Neutronium.

It would be easier to explain if (LG-)infrastructure is just expensive to build in terms of wealth and time with no TN material component or by removing it from the player constructed buildings list and instead be allowed only to buy it from the civilian market with transportation orders. For that matter, make acquisition of market acquired infrastructure by civilians cost wealth in general, easily explained as the planetary government subsidizing transportation or local production of infrastructure, and add a button that lets the player decide if a colony is allowed to receive infrastructure in this manner.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on March 13, 2018, 08:55:25 PM
You'd have to link civilian ship production to mining of other materials as well and work out more of the civilian economical background activity.
That would be nice though.  A more robust economic model seams like it should mean the possibility for more differences in the economies of different empires, both in the same game and in different games.

Agreed.  At present, I would argue that Aurora is already extremely unrealistic in terms of the level of detail and control that a single individual (the player) has over the empire.  Even (especially?) autocrats have to cope with bureaucrats who don't do as they're told. 
It seems to me that in any game like this, where the workings of government aren't really explored, the assumption is that you're playing as either the government in general or the nation/empire in general, rather than the president/dictator/king (and in fact, in the case of the Civilization series I'm pretty sure that's explicitly stated).
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 15, 2018, 08:23:54 AM
Whilst the missile loadout for a ship usually does not change that often, it does for ammunition transports. So I suggest to enable ships which function as an ammunition transport to have several loadout variations - and when giving a command to resupply from a stockpile, you can choose which loadout variation should be loaded - would also be helpful if you only use one design of ammunition transport which resupplies all the different classes of ships you have and not having to manually supply on each reload... .
Title: Re: C# Aurora v0.x Suggestions
Post by: Laurence on March 16, 2018, 11:33:16 AM
I kind of like the struggling part of conventional starts. Wish that it was modeled in even more details with chemical rockets ( low fuel / inefficient ) more conventional techs, and so on

I agree on enjoying the Conventional start. I especially like running multiple nations competing as they convert to the new technology, and would also like more options for conventional level technology as well.
Title: Re: C# Aurora v0.x Suggestions
Post by: Shuul on March 16, 2018, 05:28:06 PM
May i suggest to add a fighter/missile/ship production modules, so that they may be added to habitats? I always wanted to play a space-bound civilization with habitats only. Or build ships like GSVs from "Culture" series by Banks.
Title: Re: C# Aurora v0.x Suggestions
Post by: Conscript Gary on March 16, 2018, 05:32:24 PM
Current behavior: Asteroid Mining Modules only operate in orbit of a colony on an asteroid or comet.
Suggestion: Use the gravity of a body to determine whether or not Asteroid mining Modules can extract from it- possibly rename the module, and maybe add a tech line to increase the tolerance.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 17, 2018, 11:43:19 AM
Are there any plans to modify the UI? I am thinking of the system view, where the billions of names of all the objects clutter the readability. How about an option to hide them - and then when you mouseover over a circle, it shows the name... sounds a bit Stellaris? Indeed... But it helps keeping what is visible readable...
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on March 20, 2018, 03:28:07 AM
Following my posts here
http://aurora2.pentarch.org/index.php?topic=9861.msg107310#msg107310
I will re-post my suggestions to improve civilians, in a way that they are more consistent.

Steve's latest changes to civilian trade and movements of installations are a step in the right direction, but in my opinion they are not enough.
IF one plays with the civilians, I do not have that much of a problem with "Phantom fuel and minerals" that the civilians seem to be able to obtain. I too have always roleplayed it as the civilians getting their hands of low-grade TN minerals that the state does not see as "pure enough" to use. Although I don't like it, it's the least "offensive" way to think of the situation.

Specifically however, I think the following capabilities should be added, in order to flesh out the civilians more:
- The ability to ship everything the nation asks for. Minerals, installations, trade goods, ship parts.
- The ability to prioritize a cargo transfer request, if the nation pays more. In that case a civilian ship should ignore other possible routes, and just go and ship that one thing
- The ability to interdict civilians from certain places. If I don't want civilians to go into a system for whatever reason, I should be able to block them. If not, I'll blow them up. Because I refuse to lose my civilization because idiot civilians went into a system with an invader wormhole while I'm trying to lay low. Roleplay is everything.
- The ability to subsidize a planet's production of certain trade goods, if I want to do so, or to avoid the production of certain trade goods. Because when I roleplay an autocratic nation, I should definitely be able to do so.
- A more proportionate civilian fleet, based on the size of the nation / of the number of colonies / of the size of those colonies. Because no matter how rich a shipping line is, it makes no sense for them to create many ships if all I have is a 2 million colony on the Moon. I am unsure if Steve already added something along these lines.
- The existence of "shipping line shipyards". Because it makes no sense that shipping lines can create ships from nothingness. They need to have their own "company shipyard", which can also be blown up. It should cost wealth and time for them to rebuild it if it gets blown up.

I think all these would definitely be steps in the right direction.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on March 21, 2018, 02:26:57 PM
Suggestion, Better flesh out the lives of officers: 

1)  Let them change type in a believable way.  The specific one I'm thinking of is to allow military officers to become civilian administrators.  History is full of examples of military leaders become government officials.  Like Eisenhower going from Supreme Commander of the European Theater to President.  Maybe also allow them to go the other way, so you could have something like Richard the Lionheart on crusade.  Starts as king, becomes a general and goes to war, and if he isn't killed in battle can come home and go back to being king.

2)  Have some officers be the children of other officers.  That's happened plenty of times throughout history too; basically every monarch and plenty of democratic leaders too.  You wouldn't need to keep a whole family tree, we can do that if we want.

3)  Give us a "Memorial Wall" of sorts.  Basically, retain the histories of important officers, and allow us to issue posthumous medals and promotions.  I think a good definition of "important" would be any officer killed in battle or via black hole, any officer who lead any team, any military officer who's ship/unit did damage, any scientist who discovered a tech, and any civilian administrator who lead a colony greater than some population threshold.
Title: Re: C# Aurora v0.x Suggestions
Post by: ardem on March 21, 2018, 09:48:15 PM
I like the idea of a memorial wall. I think this is great sometimes when they die and disappear straight away, I miss the details when I did the fiction, it made it harder.So +1 for a memorial wall.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 22, 2018, 10:30:33 AM
It was discussed some time ago to "transfer" those people who die into a separate DB-table so you can see their final values and experiences for AAR. At the moment it is quite annoying when you read in the log that someone died, so you have to go into a DB backup to see details on that person.
However, I don't recall if that will be in C# or not... Steve?
Title: Re: C# Aurora v0.x Suggestions
Post by: Needler on March 22, 2018, 05:22:50 PM
A small mod for civilian lines, I'd like a Step or Increment function added to transport of installations.

IE: Supply: 5xConstruction Factories Step 1 
           Would put 1 factory in the queue and then upon DELIVERY (not pickup) would put the next factory in the queue.

      Supply: 5xConstruction Factories Step 2 
           Would put 2 factories in the queue and then upon DELIVERY (not pickup) would put the next 2 (or remainder) factories in the queue.

I'm tired of wrecking my civilian trade and infrastructure transport just to move some relatively low priority colony upgrades.
Title: Re: C# Aurora v0.x Suggestions
Post by: TCD on March 23, 2018, 08:30:48 AM
A small mod for civilian lines, I'd like a Step or Increment function added to transport of installations.

IE: Supply: 5xConstruction Factories Step 1 
           Would put 1 factory in the queue and then upon DELIVERY (not pickup) would put the next factory in the queue.

      Supply: 5xConstruction Factories Step 2 
           Would put 2 factories in the queue and then upon DELIVERY (not pickup) would put the next 2 (or remainder) factories in the queue.

I'm tired of wrecking my civilian trade and infrastructure transport just to move some relatively low priority colony upgrades.
For this exact case wouldn't it be easier to just build a cargo ship of your own? Civilian transport is useful but I'm not sure it's supposed to be a full replacement for building your own ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 23, 2018, 10:39:45 AM
For this exact case wouldn't it be easier to just build a cargo ship of your own? Civilian transport is useful but I'm not sure it's supposed to be a full replacement for building your own ships.

Yes, this is true. Civilian traffic is happening alongside your empire. It is not intended to be something over which you have direct control or a replacement for your own shipping. My original aim was to have civilians as a part of your economic base that will require defending if your empire comes under attack. They should be difficult to defend but important enough to require the effort. Plus they are intended to grow all colonies to make your empire more interesting (and again, add defensive responsibilities).

You can offer government contracts, which the civilians will fulfill, but the price you pay beyond the immediate contract cost is the disruption of the civilian economy. Decisions need both advantages and disadvantages or they aren't decisions.

Equally, civilians will avoid a recent war zone but you can't force civilian traffic into a particular area by banning everywhere else. In the real world, you can't close all oceans except the North Atlantic for example. You can effectively enforce trade sanctions by shutting down any trade treaty though.

In summary, I will avoid any measures that give direct or effective control of civilians to the player.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on March 23, 2018, 11:11:55 AM
What about allowing civilians to transport everything the player can, with the possible exception of missiles and ground troops?

In real life, the US military doesn't transport rare earth metals in from Africa, even if they are strategically important.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 23, 2018, 11:24:05 AM
What about allowing civilians to transport everything the player can, with the possible exception of missiles and ground troops?

In real life, the US military doesn't transport rare earth metals in from Africa, even if they are strategically important.

Yes, I may add minerals at some point. It's more a case of not getting around to it yet, rather than any fundamental objection.
Title: Re: C# Aurora v0.x Suggestions
Post by: waresky on March 23, 2018, 02:15:37 PM
What about allowing civilians to transport everything the player can, with the possible exception of missiles and ground troops?

In real life, the US military doesn't transport rare earth metals in from Africa, even if they are strategically important.

+1

Interesting idea.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 25, 2018, 08:20:47 AM
Are there any plans to lift the transport restrictions on some of the buildings? There are few (like the financial centers), but they seem to be arbitrary and an annoyance ingame.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 25, 2018, 09:20:11 AM
Are there any plans to lift the transport restrictions on some of the buildings? There are few (like the financial centers), but they seem to be arbitrary and an annoyance ingame.

Yes, you can move financial centres, and everything else, in C# Aurora. The new code is written to allow any buildings to move (even if I haven't invented them yet), while in VB6 I had to write specific movement orders for different buildings.
Title: Re: C# Aurora v0.x Suggestions
Post by: snapto on March 25, 2018, 07:26:42 PM
The new screenshots of the Ship view/Naval Organization are looking good.  Would it be possible to have a way to identify with a glance at the Naval Org view what ships are damaged (different ship name text color or an '*')?  It's currently sometimes a hassle to go back and forth between the damaged ships screen and the fleet/ship window.
Title: Re: C# Aurora v0.x Suggestions
Post by: TheBawkHawk on March 26, 2018, 12:51:17 AM
The new screenshots of the Ship view/Naval Organization are looking good.  Would it be possible to have a way to identify with a glance at the Naval Org view what ships are damaged (different ship name text color or an '*')?  It's currently sometimes a hassle to go back and forth between the damaged ships screen and the fleet/ship window.

Yes please, if it's not already a thing. I'd prefer different colours for the ship names. How I'm thinking it could work is have one colour for undamaged, a different colour (yellow?) if the ship only has armour damage, and then another colour (red?) if the ship has damaged internal components.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 26, 2018, 06:07:53 PM
Yes please, if it's not already a thing. I'd prefer different colours for the ship names. How I'm thinking it could work is have one colour for undamaged, a different colour (yellow?) if the ship only has armour damage, and then another colour (red?) if the ship has damaged internal components.

I've changed the colour of ships with damaged components to red and those with only armour damage to orange.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 27, 2018, 08:54:48 AM
Has anyone ever heard about virtual components? No? Well, now you have. But what are they?

The idea came to me whilst designing new ships. What I sometimes do is SM a certain component (or maybe three to five variations) to see, if they fit my overall design and how much they affect other components which could lead to designing special components (like a new engine).
If I am happy I basically delete these virtial components and research them the proper way.

So how about a button in the tech designer which does exactly that? Insteat of giving a tech to research it creates a virtual component which can be used in ship design. However, that design can't be locked down as long as it has those components in it. Which leads to the next button in the tech designer. Transfer virtual component to research - which then after proper research converts it to a real component.

These virtual components must be clearly distinguishable, of course.
Title: Re: C# Aurora v0.x Suggestions
Post by: TCD on March 27, 2018, 09:01:22 AM
Has anyone ever heard about virtual components? No? Well, now you have. But what are they?

The idea came to me whilst designing new ships. What I sometimes do is SM a certain component (or maybe three to five variations) to see, if they fit my overall design and how much they affect other components which could lead to designing special components (like a new engine).
If I am happy I basically delete these virtial components and research them the proper way.

So how about a button in the tech designer which does exactly that? Insteat of giving a tech to research it creates a virtual component which can be used in ship design. However, that design can't be locked down as long as it has those components in it. Which leads to the next button in the tech designer. Transfer virtual component to research - which then after proper research converts it to a real component.

These virtual components must be clearly distinguishable, of course.
That would be amazing. Especially for fighters and FACs where component size is so critical.
Title: Re: C# Aurora v0.x Suggestions
Post by: hostergaard on March 27, 2018, 09:44:22 AM
Multiplayer support, SM limiting what each player can see and do according to their role?

So I kinda want to run a "campaing" in my local D&D club. It would be nice if one could have some short of multiplayer support so that each empire can be controlled on separate computers. So you could have various people or even groups of people controlling each empire, but the GM don't have to do everything. Or at the very least, make it so that the SM can disallow empire from taking turns so he could just pass the save around and not worrying about anyone metagaming.

Would be even more nice if perhaps you could make it so each player only know what their person in the game know, so you could have different factions inside an empire doing different things. So the captain of the ship sees the things the ships sees, and what is generally known in the empire. The admiral of the fleet may have a more complete picture, but maybe still not know what the guy in charge of spy ops are up to. Would make for some fun roleplaying.
Title: Re: C# Aurora v0.x Suggestions
Post by: Dr. Toboggan on March 27, 2018, 10:19:28 AM
Could it be possible to add a feature to the Create Research window for engines to input a tonnage, and it would show you the speed you get with one engine? That would remove a lot of the busy work of instant researching a number of engines for a ship, just to see a possible speed.  Or maybe an "add mass" button in Create Ship Design, which would add in a "virtual component" (like TMaekler's post) that would show the speed with your desired number of engines.
Title: Re: C# Aurora v0.x Suggestions
Post by: hostergaard on March 27, 2018, 11:52:09 AM
Reposting my suggestion from 7.x as it seems more appropriate here:

Make us design ship hulls rather than ships. 

That is, instead of designing a complete ship and tooling a shipyard for it we design a hull with various hull spaces, hard points and mounts where ship system appropriate for said spot can mounted.  Have said hull be a racial research, then shipyards can tool for said hull.  After that ship variants can be designed from said hull (and possibly researched), by adding different systems in the appropriate places and all variants can then be build in the shipyard tooled for said hull.

See for example Star Citizen and their hull variation for inspiration. 

More elaborate explanation here (http://aurora2.pentarch.org/index.php?topic=9627.0)
Title: Re: C# Aurora v0.x Suggestions
Post by: hostergaard on March 27, 2018, 11:53:47 AM
Reposting my suggestions from 7.x as it seems more appropriate here:

Civilian contracts for racial tech (and possibly ships)

Instead of having your researcher do the engineering work of researching racial tech have private companies do it by defining system specs (kinda like wedo now) and have civilian companies develop their own designs that varies somewhat in specs, features, cost and so on (partially random, partially according to each company strength and weaknesses, tough they always at minimum add here to the given specs) that they use as a bid on said system specs. The player can then give out various contracts to said companies.

More here (http://aurora2.pentarch.org/index.php?topic=9630.0)
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on March 27, 2018, 02:42:55 PM
You can offer government contracts, which the civilians will fulfill, but the price you pay beyond the immediate contract cost is the disruption of the civilian economy. Decisions need both advantages and disadvantages or they aren't decisions.
Doesn't this lend itself more to the approach of allowing players to take considerable control over the civilian sector at the cost of ever increasing economic inefficiencies?  You can already pick economically totalitarian regimes, so that kind of approach would seem to lend itself to that.


Reposting my suggestion from 7.x as it seems more appropriate here:

Make us design ship hulls rather than ships. 

That is, instead of designing a complete ship and tooling a shipyard for it we design a hull with various hull spaces, hard points and mounts where ship system appropriate for said spot can mounted.  Have said hull be a racial research, then shipyards can tool for said hull.  After that ship variants can be designed from said hull (and possibly researched), by adding different systems in the appropriate places and all variants can then be build in the shipyard tooled for said hull.

See for example Star Citizen and their hull variation for inspiration. 

More elaborate explanation here (http://aurora2.pentarch.org/index.php?topic=9627.0)

That would be a complete conceptual rework of how ships fit together, which doesn't really sound that appealing.
Title: Re: C# Aurora v0.x Suggestions
Post by: Peroox on March 27, 2018, 02:55:29 PM
Don't remember numbers but you can have one "hull" and a lot of variants of them, and every variant can be built in the same shipyard as basic model. 
Title: Re: C# Aurora v0.x Suggestions
Post by: hostergaard on March 27, 2018, 04:21:11 PM
That would be a complete conceptual rework of how ships fit together, which doesn't really sound that appealing.

It would work mostly the same, except that there is a clearer and more logical approach to how ship variants work and more depht.

Don't remember numbers but you can have one "hull" and a lot of variants of them, and every variant can be built in the same shipyard as basic model. 


Issue is, there its based entirely on a somewhat arbitrary number that does not really lend itself making variants. The options are currently extremely limited as the game does not fully understand that you could probably somewhat easily replace certain modules. Sure, you can make many variants, but with very minor changes. As far as I remember, say you design two large engines of same sizes, the game will not let you readily swap the two even if they are close in design because it sees it as a large change, even if its a small one effectively.

But most importantly, its very dissatisfying to work with an arbitrary system of points compared to the depth that the rest of the game works on. Its more fun an engaging to say, hey, I can this hull point here, maybe I can swap this part in here, or maybe this, or maybe, instead and change the ships operation parameters instead of hey, lets see if this is too big a point change to make this tiny change. 
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on March 27, 2018, 04:43:58 PM
It would work mostly the same, except that there is a clearer and more logical approach to how ship variants work and more depht.
You're talking about moving from a system entirely based around the quantity and quality of components in the ship to a system where we have to design hulls with hard-points and hull-spaces and possibly research both them and their variants.  That's significantly different.  The current system of "if they're similar enough the shipyard can build both" works fine.
Title: Re: C# Aurora v0.x Suggestions
Post by: hostergaard on March 27, 2018, 05:26:22 PM
You're talking about moving from a system entirely based around the quantity and quality of components in the ship to a system where we have to design hulls with hard-points and hull-spaces and possibly research both them and their variants.  That's significantly different.  The current system of "if they're similar enough the shipyard can build both" works fine.

Its not particularly different, it would effectively work the same in all aspects except for some added dept. Its so similar in fact that for any player not wanting to design ship variant the ship designing process it could be 100% identical with no changes whatsoever to the current the way of doing it if its absolut necessary for some people to accept it.

And no, the problem is that it does not work fine. Just the opposite. Its an arbitrary and completely uninteresting way to do ship variants with little room for experimentation or variation. The current system works horribly as proven that 99% of the time no one use it. I have read trough so many LPs and AARs and its used next to never in any significant capacity. As is right now its simply not a viable option because its so limited, inflexible and arbitrary.

Edit: Sorry for making this a debate in the suggestion thread, lets discus it further in the separate threat I have made for the suggestion, if anyone want to debate it further.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on March 27, 2018, 07:03:46 PM
Edit: Sorry for making this a debate in the suggestion thread, lets discus it further in the separate threat I have made for the suggestion, if anyone want to debate it further.

Thanks for splitting it out!!!

John
Title: Re: C# Aurora v0.x Suggestions
Post by: davidr on March 30, 2018, 12:43:58 PM
With conditional orders on C# - if there is a similar order to the current  conditional order for Fuel Harvesters " unload 90% fuel at colony " ,  could the new order please include an option that the colony must be one with actual colonists or instead specify a colony by actual name and not just to a colony.

The reason being that on my current game the Fuel Harvesters at Jupiter seem to want to unload 90% of fuel at a passing comet with automated mines , rather than at Earth where my stockpile of fuel is kept. 

DavidR
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 30, 2018, 12:57:16 PM
With conditional orders on C# - if there is a similar order to the current  conditional order for Fuel Harvesters " unload 90% fuel at colony " ,  could the new order please include an option that the colony must be one with actual colonists or instead specify a colony by actual name and not just to a colony.

The reason being that on my current game the Fuel Harvesters at Jupiter seem to want to unload 90% of fuel at a passing comet with automated mines , rather than at Earth where my stockpile of fuel is kept. 

DavidR

The unload 90% fuel will require a colony with either a spaceport or a refuelling station.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on March 30, 2018, 03:38:52 PM
On the combat screen,weapons assigned to fire controls should be green while unassigned ones should be red.  Same goes for missiles.  Also, if a fire control is selected all of it's weapons should be highlighted.

This would make it far easier to assigns and reassign weapons on ships, as it is fairly confusing right now.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 30, 2018, 03:58:21 PM
On the combat screen,weapons assigned to fire controls should be green while unassigned ones should be red.  Same goes for missiles.  Also, if a fire control is selected all of it's weapons should be highlighted.

This would make it far easier to assigns and reassign weapons on ships, as it is fairly confusing right now.

See below for a link to the new combat view. Unassigned weapons have their own section so there should not be any confusion over assignment.

http://aurora2.pentarch.org/index.php?topic=8455.msg103656#msg103656
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on March 30, 2018, 04:42:36 PM
Huh, I'm sorry.  Thought I had read through the changes list too.  Thanks, Steve!
Title: Re: C# Aurora v0.x Suggestions
Post by: GeaXle on April 04, 2018, 06:57:53 AM
Ship and Tech blueprint system

It would be nice to design a tech as a blueprint, that I can use to make a ship blueprint without having to research them. When I am happy with the final ship design I can start to research the tech so that the ship blueprint becomes buildable.

This way I don't have to research multiple sensors with very small changes so that I can finally ensure the ships fits in the size I want it to have.
Title: Re: C# Aurora v0.x Suggestions
Post by: captain_carrot on April 06, 2018, 11:26:53 AM
Not sure if this in the works already, but I didn't see it anywhere.

Besides the bug that creates multiple colonies when sending colonists/cargo to a colony, it would be nice if different species on a single colony were combined under a single tab in the production window.

For example, I first moved some auto mines and infrastructure to Europa while my genetic modification centers on Mars finished up the Jovian Belters species (low base temp, low oxygen requirement, low gravity).   After moving my Jovian Belters to Europa, I now have two colonies:

Europa-Human with 20x automines and all my infrastructure
Europa-Jovian Belters with rising unrest because of no infrastructure

cycling orders to move mines/infrastructure/minerals between the two colonies on the same body using cargo ships didn't seem to work particularly well. . .

also, it would be nice if colonies were sorted by population on the task group orders menu, so I don't have to scroll passed 15 civ mines to find my Europa colony.   That's a minor inconvenience though.

Maybe this is an unintended bug to be fixed rather than a feature to be added, but that's my suggestion.
Title: Re: C# Aurora v0.x Suggestions
Post by: davidr on April 11, 2018, 03:25:27 AM
Steve,

If possible please can rescued friendly NPR crew not be classified as POW's so that they can be repatriated to their own colony if the opportunity arises. At present every NPR crew rescued is treated as a POW no matter what the player relationship is with the NPR.

DavidR
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on April 12, 2018, 09:27:28 AM
Time Progression: I would like to have an option button which, when enabled, progresses time unto a set point in time, depending on the time progression you chose - but not defined by the number of the button, but rather "unto a set point in time".

Well, I quess, it is not obvious, what I mean; so let me explain.
Normally, when you press "30 days" the game just progresses 30 days (if it does not encounter a break event). No matter what the starting time is you always end up 30 days later. But if you beforehand enabled the mentioned "option button" the game will "only" progress until the next set point in time - which for "30 days" could be the 1st day of the next month. So no matter if you press the "30 days" on the 3rd of the month or the 21st, it will always only jump ahead to the 1st of the next month.

I was thinking that for the early game, a time progression of 365 days might be an interesting addition to archive a maximum of possible time progression. But for the way I play it would also be interesting to always land in the 1st day of the next year; no matter what. I of course could archive that by clicking the needed time jump button; but that is a tad annoying. So such an option button for this would be handy... .
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on April 12, 2018, 12:05:53 PM
Space Elevator

A staple of classic sci-fi, the Beanstalk Space Elevator, would be a an expensive installation that cannot be moved, requires X level of spaceport before it can be constructed, but afterwards works equal as to level X+Y spaceport. It should be slightly cheaper and/or faster to construct than equal levels of space ports.

For example, say it requires level 4 space port to build but a space elevator would be equal to level 8 space port. That way you can move those 4 space ports elsewhere after it's constructed.

I know I can just RP that at certain space port level it's actually a Beanstalk, but it would be cool to have an actual construct. Especially now that space ports will become movable in Aurora C#
Title: Re: C# Aurora v0.x Suggestions
Post by: serger on April 14, 2018, 06:54:48 AM
Add a table of variable values, that will represent science, engineering and common knowledge, that race A have about race B, and/or a race variable, that indicates overall xenology knowledge level of this race.
Both levels must have an increase, when your sigint, spies, interrogators, traders, xenologists etc have a success with some race or artifact (the last is a reason for high-tech races to explore low-tech ruins too).
Overall xenology knowledge level have to be a multiplier for the table values increases. Table values have to be multipliers for new sigint, spies and interrogators deals, or even some increase in detection radius and fire accuracy (especially at ground combat).
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on April 16, 2018, 07:02:36 PM

This is more me just putting my thoughts out there, as I don't know how interested Steve is in doing this kind of stuff, but it won't hurt to shareI imagine.

So, Spoilers.  I'm personally very fond of them and thought I would share some ideas I had about possible additions to their roster.

Note that I do reference other Spoilers in these, so the uninitiated should be wary!
Crusaders
Off-Topic: show
So with the big improvements to ground combat, I thought that it would be nice to have an enemy that fully exploits these new new mechanics.  This Spoiler would have a chance of spawning on habitable and near habitable terrestrial worlds/moons.  They start out as a colony with of ground force production centers, enough population to service those centers, and a massive number of ground forces.  They would have the unique feature of being protected by a planetary shield, which are projected by buildings that the player can study after they are defeated.  The planetary shield absorbs damage from weapons fire much like a normal shield, but with far greater recharge rate and strength.  Ground forces and fighters, however, can still be deployed onto the planet.

The big thing with the Crusaders is that they want to fight, and fight honorably.  They consider space combat to be deeply dishonorable, so they will not participate unless forced to.  Their ground based anti-ship batteries will not fire on nearby ships unless fired upon first.  They will have a timer that is reset whenever an empire fights them on the ground, so long as said combat lasts for a little while.  When that timer hits zero several massive troop transports, which are armed with weapons and defenses scary enough to make Invaders wary, will move to the nearest large population and drop off their troops.  If the planet is taken it becomes another Crusader world, where the population will be drafted into their armies and shields erected.  The troop transports will not use their weaponry unless attacked by a onworld weapons batteries or space based enemies.  The message mechanic can be used here to make sure you know not to shoot, as one of their ships can message either your planet or a ship.


Parasites
Off-Topic: show
This is about what you'd expect.  Their whole shtick is taking over ships.  Whenever a parasite ships destroyers something, that ships is, instead of dying, it is instead disabled for a day and then brought back as another Parasite ships, completely healed of all damage.  The Parasite's unique component would be an armor regeneration effect, one not quick enough to be useful in combat but enough that it matters on the strategic scale.  These would be added to all ships that the Parasites take over and could be salvaged from wrecks.

Parasites would spawn much like the Star Swarm does.  It would begin with a small fleet of >20,000t ships with no singular design philosophy (the implication being that it stole those ships) and a big, missile armed behemoth that uses overwhelming volleys of size 1 or 2 ordinance to kill things, the idea being that those missiles are the Parasites themselves. 

Their behavior would pretty simple.  Roam around the galaxy until they find something, when they do find something incorporate it into itself.  This includes the populations of planets, which are harvested by the big Mothership when it enters orbit.  After some number of people are absorbed a new mothership is formed, which created another fleet which acts independently of the other one.  Also, I think that the crew of the Parasite ships should get combat bonuses when it comes to boarding.


Anyways, with both of these I tried to emphasis on unique mechanics and behaviors.  I also really like the Spoilery shields, because they're a really cool reward that makes fighting the Invaders feel meaningful, so I thought I would give each one something useful that seriously changes the way the game is played, but no so much as to break the basic flow.  Thanks Steve for the awesome game, and I hope I gave you some inspiration!
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on April 18, 2018, 06:43:47 AM
An idea for a new technology: Capacitor

Instead of having a bulky reactor onboard, why not having a smaller one, but loading some batteries which "save" energy that then can be "released" when needed. This would give two basic choices of ship designs:

The Default: Your beam weapons need 46 Energy to maintain a 10 sec firing rate. So you build a reactor of power 23.
The Capacitor: Same energy demand, but instead you load up a reactor of power 11.5 and a battery which can store 230 Energy. The gain would be to have a 5 sec firing rate for the first couple of shots, which then, after the battery is used up, slow down to 20 sec firing rate (because of the smaller power reactor). The gain would also be having a lighter ship which would be faster. Whilst the beam weapons are not charged, the energy would go back into the battery.
Title: Re: C# Aurora v0.x Suggestions
Post by: TCD on April 18, 2018, 07:40:05 AM
An idea for a new technology: Capacitor

Instead of having a bulky reactor onboard, why not having a smaller one, but loading some batteries which "save" energy that then can be "released" when needed. This would give two basic choices of ship designs:

The Default: Your beam weapons need 46 Energy to maintain a 10 sec firing rate. So you build a reactor of power 23.
The Capacitor: Same energy demand, but instead you load up a reactor of power 11.5 and a battery which can store 230 Energy. The gain would be to have a 5 sec firing rate for the first couple of shots, which then, after the battery is used up, slow down to 20 sec firing rate (because of the smaller power reactor). The gain would also be having a lighter ship which would be faster. Whilst the beam weapons are not charged, the energy would go back into the battery.
That's a nice idea. I wonder how attractive it would be in reality though? You'd presumably be using up your capacitor charge on long range/low accuracy shots and then be down to slow fire as the range drops and effectiveness increases.

It would be an obvious choice for jump defense/assault though where the early shots are what matter most.
Title: Re: C# Aurora v0.x Suggestions
Post by: El Pip on April 18, 2018, 09:19:13 AM
That's a nice idea. I wonder how attractive it would be in reality though? You'd presumably be using up your capacitor charge on long range/low accuracy shots and then be down to slow fire as the range drops and effectiveness increases.

It would be an obvious choice for jump defense/assault though where the early shots are what matter most.
That's what the AI would do certainly.

As a player, if you had a speed advantage but shorter ranged weapons then it could be useful. You'd try to rush in close while holding your fire, let rip with the rapid shots to try and cripple them, then pull back out of range to recharge. Not sure if that would actually work, or how often you actually have fast ships but shorter range guns, but it would be interesting to try it out.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on April 18, 2018, 12:15:58 PM
I had an idea for capacitors once, but I saw it as an option for weapon design; weapons would by default have capacitor storage for their fire rate, but there would be a box to select additional tonnage for capacitor that would let them charge to a higher max level. How much a capacitor weighed would probably be best based on your weapon recharge tech level.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on April 23, 2018, 10:29:42 AM
Partial maintenance failures.

Right now, as it stands maintenance failures in Aurora are all or nothing. A part fails, and either you have the MSP to repair it, at which point carry on, or you don't, at which point the part is completely inoperable.

What would be cool is if parts can fail partially, and be partially repaired. For example, your drive stops working. You have some MSP, and your engineering crew makes a roll. They get a partial success, so they use less/more/same MSP, and get the drive back online, but your max speed is reduced until you overhaul. Or your fuel efficiency decreases. Or the mean time between failures decreases. Or the MSP needed for future repairs goes up. Or the part simply can't be repaired again. (All until overhaul, where your shipyard crews rip everything out and refurbish it anyway.) Needless to say, the old possibility of complete failure and complete repair should still exist. Chances for a partial repair would be much increased when the ship is low on MSP, as engineers try to conserve spares.

Balanced correctly, I think this would not change the current balance point by making play either easier or harder. However, it would broaden play by creating a space of flexibility and a wealth of new tactical considerations. For example:

Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on April 23, 2018, 11:49:54 AM
Jovus

That should be tied in with damage too.  Incoming fire should be able to cause partial failures as well.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on April 23, 2018, 03:38:19 PM
Definitely!
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on April 24, 2018, 04:17:19 PM
That could be highly amusing, you could have ships typically be partly functional and get weird numbers for a slightly lowered top speed which could both make things look a little more realistic and give you an intuitive sign about when you might want to go in for overhaul.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on April 25, 2018, 05:24:32 AM
A requirement for this would be coding in the concept of "partially functioning" (%) parts and what effect that would have on functionality. For some it is easy:
Engines: Deliver % of engine power.
Jump engines: % of tonnage capacity (this would effectively mean 'non-functioning' unless you overdesigned your jump engines)
Missile launchers: % of firing rate (rounded down?)
Sensors: % of range/sensor strength
Magazines: Increased magazine explosion chance (on hit) (% of non-explosion chance if that makes sense)
etc.

But what impact would it have on a Laser? Reduced range? Reduced rate of fire? Reduced damage? All of the above?
What about a turret? What about a CIWS? What about a fuel tank?

Only once these questions have been answered, can this be implemented. And only once % part functionality is implemented can a fractional maintenance system as you describe really make sense.  However, as a simpler alternative, I can suggest the following:

This doesnt really fit the fractional maintenance system as you suggest, as parts are still only in the binary state of 100% or 0%, but it does make maintenance a bit easier and could tie into a future fractional maintenance system.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on April 25, 2018, 04:48:18 PM

But what impact would it have on a Laser? Reduced range? Reduced rate of fire? Reduced damage? All of the above?
What about a turret? What about a CIWS? What about a fuel tank?


Sure. But I don't see that as a problem so much as extra work. (Of course, I'm not suggesting I do the work, so I don't see it as a problem.) You yourself just gave some good examples, and I can do more. Frankly, in the ideal world where Steve took this suggestion and ran with it (while also not adding to his own workload at all, nor the time to release, because he let his magical basement gremlins do the coding), each relevant part would have multiple partial failure states. Some examples:

Engines:

Sensors:

Fire controls:

Power plants:

Shields:

Lasers (and other beam weapons):

Turrets (which can combine with failures for any turreted weapons, of course):

Flag bridge:

Launchers and magazines:

etc. etc.

On top of all these, I would also include failure states for every part that give it a MSP requirement per production cycle to continue functioning, and a failure state such that it will require increased MSP to recover from any other failure. (These two would be separate, of course, but could both apply to the same part if it partially fails often enough.)
Title: Re: C# Aurora v0.x Suggestions
Post by: TCD on April 26, 2018, 08:10:31 AM
Sure. But I don't see that as a problem so much as extra work. (Of course, I'm not suggesting I do the work, so I don't see it as a problem.) You yourself just gave some good examples, and I can do more. Frankly, in the ideal world where Steve took this suggestion and ran with it (while also not adding to his own workload at all, nor the time to release, because he let his magical basement gremlins do the coding), each relevant part would have multiple partial failure states. Some examples:

<snip>
I think the flaw with your plan I see is that many of these changes would be very annoying for players. Any changes to the weapon ranges/fire rates/fire controls is likely to lead to more micromanagement in battle, for instance. Varying speeds and fuel efficiencies will lead to more fuel management problems. etc etc

You'd have to have a very strong gameplay benefit to counter-balance adding more micro-management, imho.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 26, 2018, 08:29:06 AM
You'd have to have a very strong gameplay benefit to counter-balance adding more micro-management, imho.

Yes, this is the key to any change involving extra detail. Does it add consequential decisions which add game play benefit greater than the additional micromanagement?
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on April 26, 2018, 11:23:06 AM
I think the flaw with your plan I see is that many of these changes would be very annoying for players. Any changes to the weapon ranges/fire rates/fire controls is likely to lead to more micromanagement in battle, for instance. Varying speeds and fuel efficiencies will lead to more fuel management problems. etc etc

You'd have to have a very strong gameplay benefit to counter-balance adding more micro-management, imho.

Yes, this is the key to any change involving extra detail. Does it add consequential decisions which add game play benefit greater than the additional micromanagement?

Exactly true. I do see a potential game-play benefit from such a system, however. Namely, with the current system a ship is either battle-ready or not, whereas with the proposed system, the player has a whole slew of logistical and doctrinal decisions about repair schedule and station time that do not exist under the current system.

The way I envisioned it above is that the 'effective' operating time of a given ship would be increased over the current system, because while mean-time-to-failure would decrease (probably slightly), the definition of failure is not as extreme. Thus, you could (and probably would, in most cases) keep a partially-malfunctioning ship on station.

This opens up the field of decisions for a player with regard to maintenance schedules, station time, and fleet coverage.

The fact that it scratches the realism itch by providing a middle-ground between 'optimal function' and 'catastrophic failure' is just an added benefit.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rogtuok on April 27, 2018, 01:38:12 AM
Not sure if this has been mentioned.

Fleet training

Make it harder to get fleet training.

Have 1 fleet train
Have 2 fleet train and so forth.

Meaning if you have let's say 5 fleets you can designate 1 of them as training target and that target will get better faster then the rest. Many even get some special skill or host after a long time of training similar to HOI.

Ther is probobly more that can be added like skirmish tactics to this as 1 of the fleets is training in that.
And when they have learned it they can be set as fleet tactic later when assaulting or defending and will then use it's fast ships and fighters on hit and run on aprotching fleet/s

This is just a rough thought.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bravo on April 27, 2018, 02:45:06 PM
Amusingly something very similar is already possible.
I made new player nation which I just called "Mars Test Center", gave them a Flag that had the nation flag i the top corner, gave them 0 pop, no res or SY.  So a empty non functional player if you will.  Set the relationship to fixed sum whatever you like(dont think it matters) and make them Allied.
As ships are about to be Mothballed I give them over to this faction and they just hang around.
Usually I will load them with older AMM (sometimes some newer as well) and Training Missiles (Same size and powertrain as my best missiles but with WH to 0 and adjusted with extra fuel. )
AS for testing, Turn each other to hostile and commence exercise. 
You will now be able to test your own systems up against your own missiles, range, intercept %, if Test Center missiles reach through your defences they will indicate hit with 0 damage :)
safe way to find good AAM doctrines and wpns. 

As for non missile units, I either have them attack old cargo ships which are decommissioned,or I plan to make a armoured Ortbital which they can shot at.
Since its hostile they gain combat experience, I found this to be quite useful, In testing my units and stances, detection ranges and so on.

If you salvage enemy components, you can custom build a ship with they components and then test your ships up against their sensor and wpn systems to see if you will get detected.
And having a orbital in each fleet as target, you can even see approx how much damage would be dealt to each side in a gun fight.
Or you could have Livex  ;D
Title: Re: C# Aurora v0.x Suggestions
Post by: Seolferwulf on April 28, 2018, 08:16:41 AM
A repost of my suggestion in the 7.x suggestion thread:

Suggestion: Inverse the effect of the "Show Surveyed Bodies" checkbox on the Minerals-tab.

Reason:
Whenever the checkbox is checked it adds a white ring to every body that has been surveyed, which makes the screen very noisy.
That's why I only check it whenever I want to know which bodies still need to be surveyed.
If the effect is inversed you could simply leave it ticked and have your survey ships remove the noise from your populated systems.

Pros:
+ one option less you have to fumble around with every now and then
+ as an added bonus you have less redundant information on the screen, since the checkbox "Show Mineral Concentrations" already implies what has been surveyed.

Cons:
- people will have to get used to the inversed effect

... feel free to add more to the pros and cons if something comes to mind.
Title: Re: C# Aurora v0.x Suggestions
Post by: Triato on April 28, 2018, 08:40:15 AM
Why not have borh? A button for checking surveyed and another dor unsurveyed.  That way you get les noise at the begining by seing only the surveyed ones and at the end by seing the unsurveyed bodies.
Title: Re: C# Aurora v0.x Suggestions
Post by: Seolferwulf on April 28, 2018, 09:08:57 AM
Why not have borh? A button for checking surveyed and another dor unsurveyed.  That way you get les noise at the begining by seing only the surveyed ones and at the end by seing the unsurveyed bodies.

Both buttons would essentially do the same.
There's no information gain in having an extra button.
Title: Re: C# Aurora v0.x Suggestions
Post by: Triato on April 28, 2018, 12:50:38 PM
They would not do the same. One would mark the surveyed bodies and the other would mark the unsurveyed ones.  Having both of would mark none.  At the begining of the survey you would mark the surveyed ones (minimum noise)  and after half are surveyed you wold mark the unsurveyed ones.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on April 28, 2018, 09:27:31 PM
But if you mark the surveyed bodies, you are also in effect marking the bodies that were not surveyed as well.  The point is that there is a distinction.  It doesn't matter which set gets circled, the same information is displayed.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on April 29, 2018, 02:07:09 AM
He seems to be saying that the whole idea is to make a less noisy display of the information, in which case it does matter which gets circled.
Title: Re: C# Aurora v0.x Suggestions
Post by: Seolferwulf on April 29, 2018, 03:17:08 AM
I guess it depends on the individual.
Personally I wouldn't need the option to mark surveyed bodies along with unsurveyed ones, since I survey everything in sight the moment I discover it.
And at the very beginning, when I still don't have any survey ships, I wouldn't mark anything, since it wouldn't matter yet.
Title: Re: C# Aurora v0.x Suggestions
Post by: Coleslaw35 on April 29, 2018, 10:33:26 PM
What if you could have medals you create be auto-awarded to commanders when certain conditions have been met? I. e.  If a Ground Commander has been in ten separate battles they get Medal A, if a ship commander's vessel destroys a designated number of enemy ships they get Medal B, if a leader's skill rating in a certain field reaches a certain percentage they get Medal C, etc.   

EDIT: And maybe have it as an event as well? That way you know when someone has been awarded one of your medals.     
Title: Re: C# Aurora v0.x Suggestions
Post by: Seolferwulf on May 01, 2018, 09:43:49 AM
What if you could have medals you create be auto-awarded to commanders when certain conditions have been met? I.  e.   If a Ground Commander has been in ten separate battles they get Medal A, if a ship commander's vessel destroys a designated number of enemy ships they get Medal B, if a leader's skill rating in a certain field reaches a certain percentage they get Medal C, etc.

EDIT: And maybe have it as an event as well? That way you know when someone has been awarded one of your medals.

I love that idea.

What I like to do is creating and awarding a medal "First Blood", which pilots reveive when they score a kill against an enemy the empire hasn't fought yet.
Essentially a medal for pilots that fight against the odds of not knowing the enemy.
An event which could automate this, too, would be nice.
Title: Re: C# Aurora v0.x Suggestions
Post by: Coleslaw35 on May 04, 2018, 08:41:28 PM
Would it be possible to give ships and ground units an image, similar to that of the alien race image in the Race Details screen?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on May 05, 2018, 03:48:57 AM
Would it be possible to give ships and ground units an image, similar to that of the alien race image in the Race Details screen?

I have considered this in the past. The problem would be finding the huge variety of images needed for each race to have a consistent but varied set of ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 05, 2018, 07:51:21 AM
One new condition, and two conditional orders:

"Morale < 100%" (or, if you prefer, a few steps, like 80% and 60% as well)

"Take shore leave at nearest colony" and "Overhaul at nearest applicable colony/maintenance ship"
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on May 05, 2018, 08:49:05 AM
Shore leave orders are better if considered from percentage of deployment time.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on May 05, 2018, 12:16:31 PM
There was some talk about Jump Gates in the mechanics sections today, so I'll post an idea I've had for a while.

A blockade component that would allow a ship to stop traffic through a jump gate.  This would not stop ships with jump drivers.  Probably have to make it time limited somehow, perhaps it requires fuel to do it or something similar.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on May 06, 2018, 10:41:57 AM
There was some talk about Jump Gates in the mechanics sections today, so I'll post an idea I've had for a while.

A blockade component that would allow a ship to stop traffic through a jump gate.  This would not stop ships with jump drivers.  Probably have to make it time limited somehow, perhaps it requires fuel to do it or something similar.

This launched a flurry (which is already long and shows no sign of stopping) discussion of ideas for modifying the construction and/or destruction and/or mechanics rules of jump gates.  I've split that off into a separate "Jump Gate Construction/Destruction (split suggestions)" thread here: http://aurora2.pentarch.org/index.php?topic=10035.0

Please post any further ideas/discussion on jump gate mechanics to that thread to avoid cluttering up the main suggestions thread (which Steve uses as a filing cabinet and in which we want to keep signal to noise high).

Thanks,
John
Title: Re: C# Aurora v0.x Suggestions
Post by: waresky on May 08, 2018, 10:48:10 AM
Yes, this is the key to any change involving extra detail. Does it add consequential decisions which add game play benefit greater than the additional micromanagement?

Steve..ive been buy Battletech too..but isnt so "Awesome" than someone think. So stop scrolling dick around..:)

And finish your "Job"...your/our Dream : #C

2020 incoming. Last Call..eheh
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on May 08, 2018, 11:45:27 AM
Don't worry - I was back programming again at the weekend :)

Working on AI at the moment and NPR fleet design themes.
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on May 08, 2018, 12:37:48 PM
Two suggestions

May FACs be assignable to carriers in the class design window.
And may FACs also be assigned to squadrons like fighters.
Just two QOL items
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on May 08, 2018, 05:42:01 PM
If it's not too late, can we get either "Missile Size Points" or "Maintenance Supply Points" renamed to something else?  Or at least, have their abbreviations changed so we don't have two MSPs?

My preference would be to have everything that is currently referenced in M(issile) S(ize) P(oint)s to instead be given in tons, but I could live with MRPs (Maintenance & Repair Points) or Mt (Maintenance) or RSPs (Repair Supply Points) or Quatloos or RoDTs*.


.


*Rolls of Duct Tape
Title: Re: C# Aurora v0.x Suggestions
Post by: Erik Luken on May 08, 2018, 06:55:59 PM
If it's not too late, can we get either "Missile Size Points" or "Maintenance Supply Points" renamed to something else?  Or at least, have their abbreviations changed so we don't have two MSPs?

My preference would be to have everything that is currently referenced in M(issile) S(ize) P(oint)s to instead be given in tons, but I could live with MRPs (Maintenance & Repair Points) or Mt (Maintenance) or RSPs (Repair Supply Points) or Quatloos or RoDTs*.


.


*Rolls of Duct Tape

How about RoQ?

Rolls of Quatloos
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 08, 2018, 07:54:45 PM
Obviously MSPs should be renamed to SSSBs, for Self-Sealing Stem Bolts. Or if we want to keep the abbreviations the same, TSBs for Triple-S Bolts.
Title: Re: C# Aurora v0.x Suggestions
Post by: ReviewDude01 on May 09, 2018, 03:34:32 AM
1.  Please: Make additional tech line of Jump Engines: Personal Only.  (Military only/maybe also commercial)

They would cost 50% of size and cost and tech would reduce that to say 30%.  They could transport only the ship with this engine.
Same rules as other engines (except squadron size obviously).

2.  Rename Beam Fire Control do Direct Fire Control? (It sounds a lot better to me dont know what about the community. )

3.  Make Artillery Cannon (a variation of Railgun, same logic as Particle Lance vs Particle Beam ) only 1 shot, same damage pattern, huge range, big size, low tech rp, slow reload, low energy cost. . . . analogy: Macro Cannon. . . . Just some huge conventional (gas boosted) basic cannons.  Separate Tech researching max size while using railgun launch velocity, (and obviously capacitor recharge rate tech)

Balance wise, it would essentialy work like a long ranged plasma carronade with slower reload and lower damage, and with low-tech cap.

3b: possibility: expand those Artillery Cannon to have possibility to Flak, or Fragmentation Flak.  Logic: it would have a chance to damage a set number of things in 1 group.  Aka: % chance for each shot to damage max X (7) of missiles (fighters).  This could be viable PD, or anti small ship but should be weak vs, Med to larger ships.  Low reload time.  Good counter to swarms of fighters or missiles.

4.  Just rename some weapons (and tech lines) as tech progresses.  Or give players an option to do so:

Example: Microwave beams from tech level 5 (or some tech level where it makes sense, like a bigger jump in efficiency) to Ion Cannon.
Particle Beams later to Neutron, Antiproton, Multi-Particle.   It would be just a new name.  No new functionality.  The best would if players could specify those names before starting play.  This would help imagination a lot making research slightly less tedious.

5.  Please, expand tooltips (text infos) when researching things.  To give (especially new) players more info about what this thing is doing etc.  I believe this is a little work but saves a lot of time googling or browsing wiki for others.



Title: Re: C# Aurora v0.x Suggestions
Post by: ReviewDude01 on May 09, 2018, 03:39:53 AM
For example: The Artillery Cannon or Flak the one could use a warhead tech of missiles.

One last thing: Please, give ability for ships and fighters to equip 2 different types of engines.  The faster one (so the one guzzling more fuel) would be deactivated by default and it would activate only when in combat.  (However This could be a big thing balance-wise)
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on May 09, 2018, 04:30:59 AM
The idea of having two kinds of engines (I am thinking of submarines e.g. stealth ships) might be a venue to go into - one for "silent running" and one which you use to "running away" when you have been detected.

Or expand one engine to be run in two different modes: "Attack" and "Transfer". When you transfer a ship from one base to the other, it runs in transfer mode - which for example expands the range (due to less fuel useage); and when in attack mode, it runs with maximum energy output but also maximum fuel use.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 09, 2018, 05:46:38 AM
4.  Just rename some weapons (and tech lines) as tech progresses.  Or give players an option to do so:

Example: Microwave beams from tech level 5 (or some tech level where it makes sense, like a bigger jump in efficiency) to Ion Cannon.
Particle Beams later to Neutron, Antiproton, Multi-Particle.   It would be just a new name.  No new functionality.  The best would if players could specify those names before starting play.  This would help imagination a lot making research slightly less tedious.

There's nothing stopping you from doing this on a component basis now.
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on May 09, 2018, 04:40:24 PM
There's nothing stopping you from doing this on a component basis now.

This is exactly what I do for a number of my RP games, I like the idea of big space guns, so I name all the 'lasers' as if they were proper slug throwers.

As for stealth or multiple engines, you can just reduce task force speed. Thermal emissions scale with velocity. If fuel efficiency scaled with % of speed as well, to offer some benefit to operating on reduced velocity, that'd cover the latter. As long as its balanced so that its not superior to an engine built to be run at that slower speed, then it shouldn't have a significant effect on game balance.
Title: Re: C# Aurora v0.x Suggestions
Post by: boggo2300 on May 09, 2018, 04:56:17 PM
Working on AI at the moment

Well there goes Steve's sanity, Coding AI is not much better than doing a dermatological inspection of Cthulhu for mental health!



Extremely disturbing that my spellchecker knows the name Cthulhu!
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on May 09, 2018, 07:07:29 PM
I'd like to suggest an "Ignore Colony" button for civilians. There are a lot of times where you need to have a "colony" on a colony cost 0 planet (espionage teams and ground invasions are the main ones) for gameplay purposes but you don't actually want any people sent there.

On a similar but probably more complicated note, I'd also like to suggest allowing multiple species to share the same colony. There are a lot of weird cases in-game right now where you can end up with multiple colonies on the same planet, trying to swap installations, minerals, or ground units between them, and if you try to consolidate them (assuming they are both the same species) into a single colony you risk accidentally deleting something important that you forgot to transfer. I think the biggest issues with this would be infrastructure requirements, but I don't think that would be an insurmountable problem.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on May 10, 2018, 07:14:21 AM
I'd like to suggest an "Ignore Colony" button for civilians. There are a lot of times where you need to have a "colony" on a colony cost 0 planet (espionage teams and ground invasions are the main ones) for gameplay purposes but you don't actually want any people sent there.

On a similar but probably more complicated note, I'd also like to suggest allowing multiple species to share the same colony. There are a lot of weird cases in-game right now where you can end up with multiple colonies on the same planet, trying to swap installations, minerals, or ground units between them, and if you try to consolidate them (assuming they are both the same species) into a single colony you risk accidentally deleting something important that you forgot to transfer. I think the biggest issues with this would be infrastructure requirements, but I don't think that would be an insurmountable problem.

In C# Aurora, civilians will not send colonists to any colony with 0 population. This means you need to start your own populated colonies, but prevents the above situation.

Multiple species can't share the same population due to different environmental requirements, which affects not just infrastructure but other factors such as manufacturing efficiency. They can also have different characteristics in C# such as production and research bonuses.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on May 10, 2018, 08:02:43 AM
Given the changes in species traits, will we be seeing more potential change factors in gene modding? Like traits that let you increase productivity or population density?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on May 10, 2018, 08:36:36 AM
Given the changes in species traits, will we be seeing more potential change factors in gene modding? Like traits that let you increase productivity or population density?

That sounds powerful :) but interesting idea.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on May 10, 2018, 10:38:43 AM
It'd probably need a fair bit of balancing to make it work right, quite possibly up to and including forcing trade offs between productivity and population density.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 10, 2018, 10:40:37 AM
In C# Aurora, civilians will not send colonists to any colony with 0 population. This means you need to start your own populated colonies, but prevents the above situation.

This is actually exactly what I was going to suggest as an easy fix that also gives us a reason to build and use colony ships, so that's nice.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on May 10, 2018, 11:51:17 AM
If fuel efficiency scaled with % of speed as well, to offer some benefit to operating on reduced velocity, that'd cover the latter. As long as its balanced so that its not superior to an engine built to be run at that slower speed, then it shouldn't have a significant effect on game balance.

This is already in place. . .  sort of.  Whether your ship is travelling at 1 km/s or 1000 km/s, it travels just as far on 1 litre of Sorium.  Fuel efficiency is independent of speed -- and should remain so.
Title: Re: C# Aurora v0.x Suggestions
Post by: Retropunch on May 10, 2018, 11:52:39 AM
Quote from: Hazard link=topic=9841. msg108087#msg108087 date=1525957363
Given the changes in species traits, will we be seeing more potential change factors in gene modding? Like traits that let you increase productivity or population density?

I'd love to see more ability to gene mod (with a very, very high price) - it's an interesting 'end game' goal, which I'm sure we'll be running into more now that it's going to be a lot more stable over the long term.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on May 10, 2018, 02:43:25 PM
Multiple species can't share the same population due to different environmental requirements, which affects not just infrastructure but other factors such as manufacturing efficiency. They can also have different characteristics in C# such as production and research bonuses.

Maybe I'm missing something here, but wouldn't it be fairly trivial in theory ( mathematically at least ) to average weighted for size of population?

A 2 million pop colony with a -20% modifier + a 4 million colony with a +10% modifier becomes a 2*0.8+4*1.1 = 6 million colony with a +0% modifier.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kytuzian on May 10, 2018, 02:48:48 PM
Maybe I'm missing something here, but wouldn't it be fairly trivial in theory ( mathematically at least ) to average weighted for size of population?

A 2 million pop colony with a -20% modifier + a 4 million colony with a +10% modifier becomes a 2*0.8+4*1.1 = 6 million colony with a +0% modifier.

My guess would be that while it's easy mathematically, the code isn't written that way, so it'd be a huge change. For example, in the database there's probably a colony table and each row would represent one colony with it's population, species, etc. and making it so that a colony can have multiple species in it would require changing a lot of code. Besides then other things would also probably be more complicated (e.g., picking up colonists--which species do you pick up?) that are easy in theory to fix ("just" add a dropdown to select which species to pick up), but take a lot more programming effort. Just a guess, but my feeling is it's probably accurate.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on May 11, 2018, 04:17:59 AM
An easier way to manage teams would be nice. At the moment I only recognize if a team has lost one of its members by looking at the commanders screen and see that there are open posts. A warning message like "team incomplete" would be nice. And then if you click on the teams-tab you can only see teams, but not who are in them. Maybe I also want to exchange someone - but that is rather difficult to accomplish because I can only see if someone is in a team when I click on his name in the commanders screen.
Title: Re: C# Aurora v0.x Suggestions
Post by: tobijon on May 11, 2018, 05:38:43 AM

An easier way to manage teams would be nice. At the moment I only recognize if a team has lost one of its members by looking at the commanders screen and see that there are open posts. A warning message like "team incomplete" would be nice. And then if you click on the teams-tab you can only see teams, but not who are in them. Maybe I also want to exchange someone - but that is rather difficult to accomplish because I can only see if someone is in a team when I click on his name in the commanders screen.
Teams will not be present in C# aurora right?
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on May 11, 2018, 06:17:54 AM
Teams will be replaced with ground units or ship components IIRC.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on May 11, 2018, 09:16:28 AM
Teams will be replaced with ground units or ship components IIRC.

Yes, that is the plan. Geology teams are already gone. Others will be replaced as I code the relevant areas.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on May 11, 2018, 10:15:27 AM
Yes, that is the plan. Geology teams are already gone. Others will be replaced as I code the relevant areas.

They won't be missed. I recently started a new game, and ferrying around the geology teams... UGH.  ::)
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on May 11, 2018, 12:28:57 PM
Once we get civilians moving minerals around, can we please, please, please get Mass Drivers removed from Civilian Mining Complexes and replaced with auto-generated civilian contracts to move said minerals to the most populous colony in the same system?  I want to raid my enemies' shipping and steal their resources, not watch rocks float past in space with no way to interfere.
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on May 11, 2018, 01:02:15 PM
On that note, it would be interesting to be able to salvage a percentage of the minerals that a destroyed freighter was carrying.
Title: Re: C# Aurora v0.x Suggestions
Post by: Conscript Gary on May 12, 2018, 03:50:48 PM
The ability to target mass driver packets with weaponry could also be interesting, and sidestep that particular issue.
Title: Re: C# Aurora v0.x Suggestions
Post by: Seolferwulf on May 12, 2018, 04:33:46 PM
Being able to create a corridor through nebulae for ships to move at their usual speeds would be nice.
Maybe a new order to clear away space rubble with weaponry could take of this.
It would create a space in weapon range in which ships can use their normal speeds without obstacles.
As a drawback ships with this order would be easier to detect.

Though I'm not sure if this actually makes sense...
Do ships need armor in nebulae to protect against rubble or because of pressure?
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on May 12, 2018, 10:26:06 PM
Being able to create a corridor through nebulae for ships to move at their usual speeds would be nice.
Maybe a new order to clear away space rubble with weaponry could take of this.
It would create a space in weapon range in which ships can use their normal speeds without obstacles.
As a drawback ships with this order would be easier to detect.

Though I'm not sure if this actually makes sense...
Do ships need armor in nebulae to protect against rubble or because of pressure?

A nebula is a big cloud of space dust. I think the reason for restricted speeds is that at high speed, even tiny particles of dust will blow big holes in poorly armoured ships. And you can't just go around firing lasers to clear it out.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on May 12, 2018, 10:58:38 PM
Seems to me you could push it out of the way over time.  I'm not saying that should be added, but it seems excessive to declare it impossible.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on May 13, 2018, 04:02:32 PM
Seems to me you could push it out of the way over time.  I'm not saying that should be added, but it seems excessive to declare it impossible.
It would take an awfully long time to clear an area, and even if you were to do so, the dust in the nebula isn't motionless, so the area will just get filled back in by more dust.
Title: Re: C# Aurora v0.x Suggestions
Post by: ardem on May 13, 2018, 07:30:10 PM
Age of Race

Any chance we can have age changes with Races, that way officers live longer or have alien species living longer then 100 years. A new tech line as well to enhance living age? So instead of hard coding the maximum age you can have it as a fillable field in the Species Tab
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on May 13, 2018, 10:43:46 PM
Age of Race

Any chance we can have age changes with Races, that way officers live longer or have alien species living longer then 100 years. A new tech line as well to enhance living age? So instead of hard coding the maximum age you can have it as a fillable field in the Species Tab
Like with commander gender, this should go both ways too. Maybe my race of hyper-active marsupials only lives 10 years!
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on May 14, 2018, 12:29:21 AM
Age of Race

Any chance we can have age changes with Races, that way officers live longer or have alien species living longer then 100 years. A new tech line as well to enhance living age? So instead of hard coding the maximum age you can have it as a fillable field in the Species Tab
Like with commander gender, this should go both ways too. Maybe my race of hyper-active marsupials only lives 10 years!
Should age correlate with training rates, for balance? If your commanders only live 10 years, you probably need a constant supply of fresh manpower, while with 150 year old commanders you would eventually end up with a huge officer pool at current rates.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on May 14, 2018, 02:03:03 AM
Age of Race

A new tech line as well to enhance living age?

Was thinking about this some time ago too... it would make the "bio" tech sector much more interesting...

it shouldn't be too much of an improvement IMO to not make it too powerful - I was thinking about a tech-line which adds 5 years to live span (and with this employment time too of course) each

so with a 5 level tech line you could add a max of 25 years to your officers...

it also could be locked for the player - to be unlocked with ruin exploration or finding a planet with a special fauna/flora onto it... or interrogating some POWs of a special race etc pp

maybe to further balance it, the % of accidents and the impact of medical problems could be enhanced (which also could lead to an other new tech line which reduces the % of accidents to what it is now...)

Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on May 14, 2018, 05:07:35 AM
The "Quick Question about C# Aurora" thread with its discussion about the beam weapon range limits has given me an idea for handling beam weapons fire outside that increment.

I mean, we would all like to be able to fire at ranges over 1.5m km, even at tiny tiny chances to hit, the only issue is one of displaying it on the main map, if I am not mistaken? If that is the problem, then how about simply *not* displaying it? What I mean is, you create 'projectiles' for lasers the same way you do for missiles. They have a speed, they home like missiles (bear with me), they never change target and they dont go dumb when the ship that fired them dies. And then, you don't show these projectiles to anyone. Not the person who fired them, nor the people who they are being shot at.

Its homing property is simply an abstraction of the quantum hoops the firing ship jumps through to predict where a target is going to be in 10 seconds time. At larger time intervals (1minute plus) I can see how this can become shaky, but as these shots should only ever hit at a maximum of 20 - 30 seconds (4 to 6 ticks) out, I think there should never be any grossly impossible situations. Lorewise, you could fluff it as one ship's computer learning the other's randomization algorithms (and using large area attacks, as in the original Starfire). You could even make heading changes destroy all incoming beam fire (human decisionmaking invalidates learning the ship's evasion pattern to predict its future position) if you dont want the potential immersion breaker of "how could that ship have known to aim there when I didnt even know I was going to be there!".

For detection, you can make the ship that fires them experience a 'heat bloom' with higher thermal signiture the moment it does so that the victim can know they are being shot at even before the shot hits.

This has the advantage of unifying beam and missile behaviour into one set with mechanics, with the only difference being whether or not to actually display the projectiles.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on May 14, 2018, 05:35:39 AM
The issue with longer beam weapon ranges is game-play related.

Currently, if you have two energy-armed fleets and one is faster with longer-ranged weapons, it will win automatically. However, beam ranges are relatively short so a faster fleet with shorter-range weapons will get into range after taking some damage.

Also, a fleet with inherently slower tech could adapt to build speed-optimized (boosted) ships to get into range.

However, if we had beam weapons with significantly more range, the race with the longest range weapons wins, regardless of what the other side does, because they would be torn to pieces trying to close that longer range.

Missiles have great range, but require ammo and can be shot down. Beam weapons can fire forever, with no ammo and no possible defence. Their limitation is range. The five second range is convenient technobabble, but the real reason is to avoid breaking the game by making beam weapons too powerful.

Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on May 14, 2018, 06:05:41 AM
However, if we had beam weapons with significantly more range, the race with the longest range weapons wins, regardless of what the other side does, because they would be torn to pieces trying to close that longer range.

Missiles have great range, but require ammo and can be shot down. Beam weapons can fire forever, with no ammo and no possible defence. Their limitation is range. The five second range is convenient technobabble, but the real reason is to avoid breaking the game by making beam weapons too powerful.

Is that the way it must be though?

Have you thought about the option of splitting up beam weapons into two distinct categories?

Close in ( no ammo ) - For knife fights, Fighters/FAC and PD/CIWS.
Artillery ( ammo ) - For softening up enemy fleets, ranges between that of beams and missiles.


Accuracy could scale with distance such that how early your artillery opens up on the enemy is a tradeoff if it's worth the ammo or your just wasting it, and could be balanced such that larger enemy capital ships are significantly easier to hit at range making them more vulnerable.

I think this could lead to some quite interesting RP and dynamic situations as well. Ammo would ofcourse be much cheaper then missiles ( or even replenished for free ), but does take up part of your mass budget and limit firing time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on May 14, 2018, 06:08:23 AM
In VB6 Aurora, sure. But beam weapons fire a lot more than missiles, and with the changes in C# Aurora, will suffer a lot more failure rates. Plinking at an opposing fleet with 1 damage per shot at the edge of max range will probably result in about 0.7 kills before your laser fails.

On the other hand, the gains to be made with removing this cap is the creation of far more interesting weapon systems that could surpass the limit, albeit at cost of perhaps ammunition (not missiles, things that cant be shot down), reduced accuracy, increased failure, etc. Furthermore, you could even change how beam weapons work so that the fire control becomes the only limiter to maximum range and the only issue with firing at 5m km is the absolutely abysmal hit chance. Now you can get longer range weapons by just slapping a bigger fire control on... but that wont make you in any way likely to hit at those insane ranges before your gun blows up from firing 100 000 shots.

I'll go do some thinking. Maybe I can come up with a vaguely reasonable formula that gives a decent chance to hit at close range with a sharply dropping probability at longer (>5 seconds).

I would not suggest there should be some hard difference between Artillary and Close in. I would rather those functionalities be the natural consequences of specialization in features (like ASM vs AMM).
Title: Re: C# Aurora v0.x Suggestions
Post by: Peroox on May 14, 2018, 06:18:10 AM
Low damage, long range beam could be countered by shields regeneration.  Problem is with focus fire of entire fleet on one ship.  Against missile you can use all yours fleet to shot them down, but against beam each ship stand alone.  In game we can't shield targeted ship with formation so you always lose ship one by one.  Of course with missile you can hope to shot down all enemy ammo and retract targeted ship to have more time (ticks) to destroy enemy missile. 

Maybe ordnance type mass driver with kinetic(maybe also plasma?) projetile could be a solution.  Low damage, long range(in compare to beam/railgun), limmited ammo, only active sensor can detect it(or EM if plasma).  Rather hard to shot down by AMM but beam/kinetic defence can change the trajectory of the flight or destroy that type of projectile(or dissipate energy if plasma ordnance). 
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on May 14, 2018, 07:43:29 AM
Valid, but increased weapon failure due to firing already function as limited "ammunition" (number of shots) for them. If you have 2% chance of failure, roughly half your weapons will have had a failure after 50 shots, reducing your total MSP by the equivalent amount. Once your MSP runs out not only will your weapons stop firing as they fail, but you put yourself in a rather tricky situation with regards to making it back to your nearest resupply base.

I think the accuracy modifier could be rather simple. Just multiply whatever existing accuracy formula there is by an additional factor
(min(Weapon 'Maximum' range/Actual range,1)^2)

That means your actual accuracy will drop by a further 75% if you attempt to shoot at someone twice as far as your weapon's maximum effective range. That is, over and above the existing impact that such a massive range has on accuracy (accuracy IS a function of range at the moment, right?). So if you have a 50% chance to hit someone at your 'max' range of 100kkm, then, depending on the current impact of range on accuracy you will at best have the following probability of hitting at these ranges (assuming no other impacts from range):

200kkm - 12.5%
300kkm - 5.56%
400kkm - 3.13%
500kkm - 2% (note, when your accuracy is the same as your weapon failure chance then its a 50/50 split whether your gun will blow up or you will hit the enemy)
600kkm - 1.39%
700kkm - 1.02%
800kkm - 0.78%

At these kinds of accuracies, it becomes a total waste of MSP to fire at all. Your guns have a larger chance to fail than they do to actually hurt the enemy.

If this conversation is going to go anywhere but a "no" from Steve, then I suggest we move it out into its own thread to not clutter this one up.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 14, 2018, 10:31:26 AM
A button for clearing ammunition from missile launchers, because as far as I know the current workflow is highly unintuitive and throws an error.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 15, 2018, 11:58:19 AM
There should be a field on the Political Relations tab that tells you what government type another race has once you've established communications, since I should think that would be pretty obvious from standard diplomatic protocols and implicit assumptions.

Edit: unrelated but I didn't want to make another reply and have it be three in a row.

On the combat assignments overview screen, there should be a third tab beyond 'setup fire controls' and 'missiles in flight' named something like 'damage report' that shows current armour, damaged subsystems, and DAC. Basically just copy the one in the individual ship screen, so I don't have to go looking for it.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on May 15, 2018, 03:26:45 PM
Quote from: Jovus link=topic=9841.  msg108202#msg108202 date=1526403499
Edit: unrelated but I didn't want to make another reply and have it be three in a row. 

On the combat assignments overview screen, there should be a third tab beyond 'setup fire controls' and 'missiles in flight' named something like 'damage report' that shows current armour, damaged subsystems, and DAC.   Basically just copy the one in the individual ship screen, so I don't have to go looking for it. 
If I'm correct this is all going to under the new OOB screen, anyway
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 15, 2018, 07:05:38 PM
Sure, as long as all the info I need to fight the battle is in one place.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on May 16, 2018, 06:33:59 AM
In C# Aurora there will be a limit to population maximum on celestial bodies. So I was thinking about maybe allowing overcrowding - but not in the old fashion style but rather as a selectable parameter, that then will affect general happyness on that colony. Let's say the default value is the optimal where everybody feels he has enough space to be who he is and happyness is at 100%. But that deminishes when that space is becoming smaller. So if you select in that parameter: crowd density = 120% - that would mean 20% more people allowed on that colony, but also 20% less happyness, which would result in less workforce, etc.
Also the other way around: if you select crowd density = 80% - that would mean only 80% of people allowed but also 20% more happyness, and perhaps better efficiency.

The numbers would have to be tested what would be feasable of course and don't break the general game mechanics... .
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on May 16, 2018, 08:44:10 AM
Having seen the last episodes of "The Expanse", I was wondering if beam weapons could be modified in a way, that the shots are actual objects (like rockets), and that could put them over the 5 seconds range limit, so they could become a little "rangier" than at the moment. Not much, maybe they loose quite an amount of energy when going into their second cycle, and at most into a third. But I think, warfare could benefit a litttle from this... .

Expanse spoiler:
Or it could enable those nice railguns with which Earth destroyed the MCRNs first strike capability. But that would mean that they become very, very costly to fit into Aurora... .
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on May 16, 2018, 10:10:28 AM
Suggestion for Sorium Harvester. At the moment, they can be automated in a way in which they always empty themselves at the nearest colony and then auto return to the gas giant. How about a new command which says, "empty at colony XY and then return to gas giant"?
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on May 16, 2018, 10:11:19 AM
If you want a long range weapon that can deliver a useful energy load your options at space ranges are basically 'use a self guiding missile' and 'use a chunk mass on a carefully aimed trajectory.'

The reasons for this are mostly to do with energy weapons generally being made of, well, high energy particles. It'd be similar to grabbing a handful of marbles and throwing them, sure, you can get some good distance as glass is dense enough to maintain momentum, but most marbles will scatter across a wide area. If you can actually hit you're better off tossing a single stone of the same weight as all those marbles put together because so much more energy is delivered at the target than with the rather more scattershot impact of the particles.

Which is where the chunk of mass comes in; if you throw something that's not likely to be overly influenced at the relevant range due to gravitational influences, the solar wind and electromagnetic fields you are more likely to hit because fewer things are going to influence the shot. And a chunk of mass, especially something made of tungsten or another high density metal that is not ferromagnetic? It's not going to care much about anything so long as it's fired cold, because there's not going to be any evaporating material shifting the trajectory of the shot either.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on May 16, 2018, 12:32:48 PM
I was reminded (http://aurora2.pentarch.org/index.php?topic=9343.msg101162#msg101162 (http://aurora2.pentarch.org/index.php?topic=9343.msg101162#msg101162)) that rescuing life pods (your own, or somebody else's) usually results in wildly varying overages of life support capacity.  I'd like to suggest some sort of "Equalize POWs/survivors across fleet" and "concentrate all POWs/survivors on a single ship" buttons.

Probably based on available life support capacity, so that one's cryo-equipped rescue ship / prisoner transport properly hoards the 150 extra bodies it was designed for.
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on May 16, 2018, 01:21:17 PM
If you want a long range weapon that can deliver a useful energy load your options at space ranges are basically 'use a self guiding missile' and 'use a chunk mass on a carefully aimed trajectory.'

The reasons for this are mostly to do with energy weapons generally being made of, well, high energy particles. It'd be similar to grabbing a handful of marbles and throwing them, sure, you can get some good distance as glass is dense enough to maintain momentum, but most marbles will scatter across a wide area. If you can actually hit you're better off tossing a single stone of the same weight as all those marbles put together because so much more energy is delivered at the target than with the rather more scattershot impact of the particles.

Which is where the chunk of mass comes in; if you throw something that's not likely to be overly influenced at the relevant range due to gravitational influences, the solar wind and electromagnetic fields you are more likely to hit because fewer things are going to influence the shot. And a chunk of mass, especially something made of tungsten or another high density metal that is not ferromagnetic? It's not going to care much about anything so long as it's fired cold, because there's not going to be any evaporating material shifting the trajectory of the shot either.

Sure, if you're trying to shoot enemy ships with a giant spotlight, but the entire point of a laser is that the beam is coherent. And there are more photons in a laser beam than there are marbles in a handful. The problem with any unguided weapon "at space ranges" is that space is big. Realistically a kinetic weapon would be next to useless unless fired at a very very high fraction of c because the target can simply dodge out the way. When firing a laser beam, or a kinetic weapon close to c, anything beyond a few seconds is pointless because even with the best targeting, random movements by the target can throw it off even if they can't see it coming. Personally I think the way "beam" weapons are handled in aurora currently is generally fine and I don't think it needs some great overhaul to achieve a result that would, ultimately, be overly complicated with convoluted rules and either most likely unrealistic or useless and, as steve has pointed out, would be problemtic for gameplay.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on May 16, 2018, 02:59:19 PM
Sure, if you're trying to shoot enemy ships with a giant spotlight, but the entire point of a laser is that the beam is coherent. And there are more photons in a laser beam than there are marbles in a handful. The problem with any unguided weapon "at space ranges" is that space is big. Realistically a kinetic weapon would be next to useless unless fired at a very very high fraction of c because the target can simply dodge out the way. When firing a laser beam, or a kinetic weapon close to c, anything beyond a few seconds is pointless because even with the best targeting, random movements by the target can throw it off even if they can't see it coming. Personally I think the way "beam" weapons are handled in aurora currently is generally fine and I don't think it needs some great overhaul to achieve a result that would, ultimately, be overly complicated with convoluted rules and either most likely unrealistic or useless and, as steve has pointed out, would be problemtic for gameplay.

Funny you mention spotlights.

At space ranges? Even a powerful laser will have diverged considerably even in a vacuum. It might as well be a spotlight.


That said, lasers and other near C speed weapons are inherently more useful in deep space than kinetic weapons because, despite the focus and range issues, your major limitation in combat in space is the ability to locate and predict the enemy's location when firing. Kinetic weapons are practically kings of orbital bombardment though, there's very little a space ship can do when it comes to doing damage down an atmosphere than throwing solid chunks of mass at it at orbital velocities.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on May 16, 2018, 03:52:49 PM
I was reminded (http://aurora2.pentarch.org/index.php?topic=9343.msg101162#msg101162 (http://aurora2.pentarch.org/index.php?topic=9343.msg101162#msg101162)) that rescuing life pods (your own, or somebody else's) usually results in wildly varying overages of life support capacity.  I'd like to suggest some sort of "Equalize POWs/survivors across fleet" and "concentrate all POWs/survivors on a single ship" buttons.

Probably based on available life support capacity, so that one's cryo-equipped rescue ship / prisoner transport properly hoards the 150 extra bodies it was designed for.
I believe Steve has already fixed this, so that lifeboat contents are evenly spread out in a TG. I've brought this issue up several times.
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on May 16, 2018, 05:14:44 PM
Funny you mention spotlights.

At space ranges? Even a powerful laser will have diverged considerably even in a vacuum. It might as well be a spotlight.

Well power isn't going to stop it diverging, it's more a case of how well collimated it is. I don't know the exact useful range it would be feasible to make a laser weapon, but remember we're dealing with sci-fi and applied phlebotinum. I'd say it would be reasonable to assume that trans-newtonian minerals would be able to produce a far tighter beam than what we can practically do with modern technology.

But sure, at some point it'll no longer be harmful. The question really is whether that is before or after it stops being useful due to travel time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 16, 2018, 07:39:18 PM
For ships that have flag bridges, if a task force is located on board, there should be the option (enabled by default, methinks, but whatever) of having the task force commander skippering the ship. It's quite usual for the admiral to be in charge of his flagship.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on May 16, 2018, 11:32:15 PM
Sort of yes, sort of no.

While that's true of commodores, given that's generally not a rank so much as an acknowledgement of a captain in charge of more than 1 ship, admirals are generally not actually in the chain of command for a ship. He's in charge of it, and can tell it where to go, but the captain is responsible for it, and unless the senior staff has issues the captain is really the last authority on the matter.

Mostly this is so the flag ranks can concentrate on the TF's/fleet's job and the captain can focus on making sure his ship helps with that job.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 17, 2018, 05:24:40 AM
He's in charge of it, and can tell it where to go, but the captain is responsible for it, and unless the senior staff has issues the captain is really the last authority on the matter.

This is very much a matter of difference between services, and between the same service at different times. For example, this is the immemorial custom of the Royal (British) Navy, but very much less usual with Age of Sail squadrons in the French and Spanish navies.

Or so I've been lead to believe; I'd be quite happy to learn otherwise.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on May 17, 2018, 06:50:06 AM
I am not sure at the moment if I am wrong about a concept in VB6 Aurora. If so, just ignore this posting. If I am right, then at the moment a rocket that is led to a target via an active sensor, the moment the active sensor gets lost, the rocket gets lost, right? If not, again, just ignore this.
But if so, it would be nice if in C# Aurora the game would automatically create a waypoint for the rockets where the last known position of the target was, the moment the active sensor got lost. So in case the rocket itself has an active sensor it then can engage that at that waypoint and see, if there is an enemy ship nearby.
Title: Re: C# Aurora v0.x Suggestions
Post by: Peroox on May 17, 2018, 07:24:39 AM
Quote from: Person012345 link=topic=9841. msg108230#msg108230 date=1526494877

Sure, if you' Realistically a kinetic weapon would be next to useless unless fired at a very very high fraction of c because the target can simply dodge out the way. 

It's hard to hit something from long range that use combat maneouvers.  To make dodge you need to "see" projectile, and thing is that kinetic projectile don't have any termal or electromagnetic trace.  So it's depends on resoluton and size of active sensor.  Projectile can be smaller than missile size 1 so much more harder to track down.

Should be good weapon for stealth ship.  If enemy don't know that enemy is close kinetic weapon can have almost 100% chance to hit from any range, like against stationary target.  But that will be hard to be programmed.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on May 17, 2018, 02:05:17 PM
I am not sure at the moment if I am wrong about a concept in VB6 Aurora. If so, just ignore this posting. If I am right, then at the moment a rocket that is led to a target via an active sensor, the moment the active sensor gets lost, the rocket gets lost, right? If not, again, just ignore this.
But if so, it would be nice if in C# Aurora the game would automatically create a waypoint for the rockets where the last known position of the target was, the moment the active sensor got lost. So in case the rocket itself has an active sensor it then can engage that at that waypoint and see, if there is an enemy ship nearby.

Last time I checked, a missile WITHOUT on-board sensors would self-destruct if it lost target lock.  A missile WITH on-board sensors would continue on -- no change in direction or speed -- while constantly looking for a new target.

This second action is the main benefit for missiles-with-sensors, and thus will not be extended to non-sensor-equipped missiles.
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on May 17, 2018, 03:29:27 PM
I am not sure at the moment if I am wrong about a concept in VB6 Aurora. If so, just ignore this posting. If I am right, then at the moment a rocket that is led to a target via an active sensor, the moment the active sensor gets lost, the rocket gets lost, right? If not, again, just ignore this.
But if so, it would be nice if in C# Aurora the game would automatically create a waypoint for the rockets where the last known position of the target was, the moment the active sensor got lost. So in case the rocket itself has an active sensor it then can engage that at that waypoint and see, if there is an enemy ship nearby.

Last time I checked, a missile WITHOUT on-board sensors would self-destruct if it lost target lock.  A missile WITH on-board sensors would continue on -- no change in direction or speed -- while constantly looking for a new target.

This second action is the main benefit for missiles-with-sensors, and thus will not be extended to non-sensor-equipped missiles.
That is correct, except I think missiles with sensors will stop at the last location of their target.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on May 17, 2018, 11:36:33 PM
A new command for loading minerals. "Load Minerals when X available". So if the total sum of all minerals is over a certain number, then fill the cargo hold with them.
Title: Re: C# Aurora v0.x Suggestions
Post by: leonidas1283 on May 18, 2018, 06:17:07 AM
Can you make the VB6 saves work with C#?
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on May 18, 2018, 07:41:10 AM
Can you make the VB6 saves work with C#?

The answer will be "no".  Steve only supports previous saves for minor version updates.  C# will have completely different information in the database (and possibly a different database system as well - I don't remember); it would take WAY too much time for him to write a front-porting tool.

John
Title: Re: C# Aurora v0.x Suggestions
Post by: Erik Luken on May 18, 2018, 01:06:47 PM
Can you make the VB6 saves work with C#?

The answer will be "no".  Steve only supports previous saves for minor version updates.  C# will have completely different information in the database (and possibly a different database system as well - I don't remember); it would take WAY too much time for him to write a front-porting tool.

John

Yep, sqlite (if I recall) from MS Access.

Maybe. Maybe he will write a conversion program. Or someone else with knowledge of the databases will.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 18, 2018, 05:41:41 PM
Maybe. Maybe he will write a conversion program. Or someone else with knowledge of the databases will.

I hope not, since instead he could be using that time making Aurora better, or doing something else fun, or walking the dog, or taking a shower...

Basically that's really low on my personal priority list.
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on May 19, 2018, 04:25:41 AM
Even aside from the structural changes in the code, the changes to the mechanics alone would render saves incompatible and in need of some conversion. You couldn't simply slap an old save into the new game and go, what would happen to ground units for instance?
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on May 19, 2018, 06:44:13 AM
Suggestion to separate two different kinds of messages from the event log. "Officer Update" includes every report of change an officer is undergoing (increase in whatsoever, experience gain, etc.). And it also includes "Hans XY has not been given an assignment for the past x years and is deemed surplus", as well as "Peter ABC has retired from service at the age of XY".

Usually I don't care much about the increase in gain, etc., but I would like to see retirements and surplus. But since both are found under "Officer Update" I have to "endure" all the updates in the log or miss out on the retirement-surplus if I switch that group off. So I would love to see them in a separate message group.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on May 19, 2018, 06:47:23 AM
Even aside from the structural changes in the code, the changes to the mechanics alone would render saves incompatible and in need of some conversion. You couldn't simply slap an old save into the new game and go, what would happen to ground units for instance?
Depends on how many changes there are "under the hood". Aurora has quite a large amount of background database stuff, which might make it quite impossible to "translate" a game from VB6 to C#. Nevertheless, when C# comes out, I plan to take a look into this (and then eventually refrain from it totally because of "too complex to do"). We'll see...
Title: Re: C# Aurora v0.x Suggestions
Post by: Needler on May 20, 2018, 12:21:19 AM
As far as a conversion goes, I'd be fine with just getting the Systems, Planets and Warp Connections.  Everything else I can SM recreate, and would prefer to to account for different rules and techs.  Maybe general NPR info (economy, tech level, number of ships) would be nice but not strictly necessary.
Title: Re: C# Aurora v0.x Suggestions
Post by: Coleslaw35 on May 20, 2018, 11:07:13 AM
Some current event log notifications are all or nothing, i. e.  You hear about officers, administrators, and scientists dying/worsening in health, but most of the time they're just some random person you don't care about.  What if you could set certain positions as having high priority notifications so that you can know about the positions you actually care about, i. e.  "Your administrator for the position of Sector Commander of Earth Sector has just died. "
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on May 20, 2018, 06:41:10 PM
Some current event log notifications are all or nothing, i. e.  You hear about officers, administrators, and scientists dying/worsening in health, but most of the time they're just some random person you don't care about.  What if you could set certain positions as having high priority notifications so that you can know about the positions you actually care about, i. e.  "Your administrator for the position of Sector Commander of Earth Sector has just died. "
Seconded. I can't even count the number times I've been confused by my ships not raising their Task Force Training until I find out my TF Commander died a year ago and I've been wasting fuel the whole time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on May 21, 2018, 04:24:45 AM
Following up on what has been posted in the last two posts.
In the officers assignment screen, civilian sector, I would love it if we could sort the colonies by function.

Once you're 25 years in game and you have 30-40 or more between planets, mining colonies and listening posts it's a big mess.

It would be super helpful to be able to choose what to show, much like what happens with military ships. That way, I can chose to see inhabited colonies, or civilian mining colonies/automine colonies, or similar.  And assigning civilian leaders becomes a lot easier and more streamlined.
The "classes" of colonies could be the same that you can see in the "population" screen when you sort by function.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on May 21, 2018, 05:25:04 AM
Or it could just be an assigned function just like the ship classes. Keeps things nice and simple and similar to an existing system.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 21, 2018, 12:13:41 PM
Thanks. That way it works.
Does that "fire missile once you're at that location" make any sense? In what circumstance can that be senseful?

It is useful for dropping sensor buoys or mines.

I should think this could stand re-naming to avoid confusion. I always considered it to be 'launch missiles with this as your target' and simply never thought of it as anything else because I was dropping mines and buoys anyway and they naturally wouldn't move. But were I to try drones or probes, I'd probably follow the same workflow and be surprised.

I'd suggest "Launch missiles from" or even just 'Launch missiles' since you have to choose the location already to get this prompt.

In fact, I'd suggest having both - 'Launch missiles' would just act as it does now, while 'launch missiles from' would pull up a sub-menu that allows you to choose whch launcher and missile you want to use.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on May 21, 2018, 04:48:40 PM
I should think this could stand re-naming to avoid confusion.  <snip>

In fact, I'd suggest having both - 'Launch missiles' would just act as it does now, while 'launch missiles from' would pull up a sub-menu that allows you to choose whch launcher and missile you want to use.

How about "Move to & then Launch" ?
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 21, 2018, 06:44:48 PM
Sure, that could work. Though I like having 'launch' be the first word, because it doesn't overlap with any of the other order possibilities. I could see myself accidentaly clicking or not reading too closely on "Move to and then launch" instead of "Move to" or vice versa.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on May 22, 2018, 07:30:15 PM
Reposting this general idea from the jump gate thread

Given that stations seem like they're going to be significantly more important in Aurora C#, I'd like it if we could build/repair/overhaul stations in space using specialized ships (using minerals and prefabbed parts in the same way shipyards do, of course).  The components used for that would also allow us to basically give developed stations shipyard capabilities.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 22, 2018, 08:20:42 PM
My last C# suggestion is that we all stop posting C# suggestions so Steve's to-do list stops growing.








Hopefully I made at least one of you chuckle.
Title: Re: C# Aurora v0.x Suggestions
Post by: DocSpit on May 23, 2018, 02:16:44 AM
I've spent about 6 hours trying to find where this might have been brought up/discussed, and I haven't managed to; so HOPEFULLY it's a new thing (or I'm blind.   Very possible 8))

ANYWAY!

I am so far LOVING the new way that stations will be implemented, and their viability as forward support locations and fleet support installations in deep space.   Brilliant!

I also recognize that morale for commercial bases and ships is being effectively removed, as it has never actually done anything to degrade performance anyway.   Though I'd be lying if I said it never bothered me seeing those numbers at zero (those poor, bored, harvesting crews!).   However, what I haven't seen is how the morale of MILITARY stations might be addressed?

There's never been a way to actually 'rotate crews' in Aurora, and that's pretty much torpedoed the real possibility of building stationary defense bases to look after jump points (at least, not ones that weren't prohibitively huge and expensive anyway).   This is why mine fields are generally opted for, I feel.   However, I know that I'd much rather use a few genuine space-based forts hovering on a jump point that are more than just a one-and-done line of defense!

I feel that one change being introduced into C# might afford a perfect opportunity to address the issue of military base morale.   Since the lore of the game is being altered to make shuttles the means by which goods and personnel is transported between orbit and the surface of a planet, I'm wondering if either of these solutions is feasible:

1) a station equipped with a shuttle bay, in a system with an appropriate colony world or recreation module-equipped station, would not be subject to morale degradation, denoting the ability of said station to send its crew out on regular leave rotations; or:

2) abstract this by a little by allowing a player to opt for such stations to have a higher annual mineral upkeep in order to represent the associated cost in money and material of using (invisible) commercial shuttles to rotate out crews.

Either case should probably also require that such stations have a higher than normal crew requirement, as both the on-station personnel and those currently on shore leave would be unavailable for assignment on new construction.

Not sure how much other players would want a system like this, or how hard it would be to code; I just know it's something that has always frustrated me a little that I couldn't do, so I figured I'd post it here!

LOVING the game, btw!
Title: Re: C# Aurora v0.x Suggestions
Post by: Renwa on May 23, 2018, 05:00:49 AM
Just a small request.

I would love the ability in the task group window, to able to write notes to specific task groups

Title: Re: C# Aurora v0.x Suggestions
Post by: TCD on May 23, 2018, 09:32:45 AM
<snip>
1) a station equipped with a shuttle bay, in a system with an appropriate colony world or recreation module-equipped station, would not be subject to morale degradation, denoting the ability of said station to send its crew out on regular leave rotations; or:

2) abstract this by a little by allowing a player to opt for such stations to have a higher annual mineral upkeep in order to represent the associated cost in money and material of using (invisible) commercial shuttles to rotate out crews.

Either case should probably also require that such stations have a higher than normal crew requirement, as both the on-station personnel and those currently on shore leave would be unavailable for assignment on new construction.

Not sure how much other players would want a system like this, or how hard it would be to code; I just know it's something that has always frustrated me a little that I couldn't do, so I figured I'd post it here!
I agree that morale limits the long term usefulness of smaller military stations. I like your abstract option 2, but maybe both stations and ships should have a "rotate crew" option that freezes morale in appropriate systems. It could consume MSP and also reduce crew effectiveness (to represent the fact that your key personnel might be off the ship). So you'd have to make a hard decision about whether you cancel shore-leave as a conflict looms. 

Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on May 23, 2018, 10:01:31 AM
-snip-
However, what I haven't seen is how the morale of MILITARY stations might be addressed?

There's never been a way to actually 'rotate crews' in Aurora, and that's pretty much torpedoed the real possibility of building stationary defense bases to look after jump points (at least, not ones that weren't prohibitively huge and expensive anyway).
-snip-
Isn't this what recreational modules are for?
Title: Re: C# Aurora v0.x Suggestions
Post by: TCD on May 23, 2018, 01:59:34 PM
-snip-
However, what I haven't seen is how the morale of MILITARY stations might be addressed?

There's never been a way to actually 'rotate crews' in Aurora, and that's pretty much torpedoed the real possibility of building stationary defense bases to look after jump points (at least, not ones that weren't prohibitively huge and expensive anyway).
-snip-
Isn't this what recreational modules are for?
Sort of, but they are very big. I think it should be possible to maintain a, say, 60kt defense station indefinitely. That's not very viable if you need to add a 100kt recreational module.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on May 23, 2018, 02:37:04 PM
Isn't this what recreational modules are for?
Sort of, but they are very big. I think it should be possible to maintain a, say, 60kt defense station indefinitely. That's not very viable if you need to add a 100kt recreational module.
You could build ships with recreational modules, and have them tour your stations.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on May 23, 2018, 05:06:43 PM
Which basically means you've got a 100kT+ ship moving around your defense perimeter being a target. There's a reason you don't do that in real life and instead shuffle personnel around.
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on May 23, 2018, 05:17:55 PM
Which basically means you've got a 100kT+ ship moving around your defense perimeter being a target. There's a reason you don't do that in real life and instead shuffle personnel around.
Could you explain your analogy to real life here? I can't really think of any strictly analogous situation. Military bases around the world are supplied by a variety of means and I would imagine that at least part of the supply chain includes 100kt ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on May 23, 2018, 05:44:08 PM
Which basically means you've got a 100kT+ ship moving around your defense perimeter being a target. There's a reason you don't do that in real life and instead shuffle personnel around.
Could you explain your analogy to real life here? I can't really think of any strictly analogous situation. Military bases around the world are supplied by a variety of means and I would imagine that at least part of the supply chain includes 100kt ships.

Yes, but if you have a military base in the middle of the ocean, you don't charter a cruise ship to dock up and just let people mess around in the ship facilities for a few weeks. You sail them out to the nearest piece of civilization. If anything, you could probably just rotate leave crew onto those replenishment ships, and they'll drop them off when they return.
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on May 23, 2018, 09:16:02 PM
Which basically means you've got a 100kT+ ship moving around your defense perimeter being a target. There's a reason you don't do that in real life and instead shuffle personnel around.
Could you explain your analogy to real life here? I can't really think of any strictly analogous situation. Military bases around the world are supplied by a variety of means and I would imagine that at least part of the supply chain includes 100kt ships.

Yes, but if you have a military base in the middle of the ocean, you don't charter a cruise ship to dock up and just let people mess around in the ship facilities for a few weeks. You sail them out to the nearest piece of civilization. If anything, you could probably just rotate leave crew onto those replenishment ships, and they'll drop them off when they return.
Ok, but then I don't understand how this demonstrates that you "don't do" having a 100kt ship moving around. Obviously ingame it's a bit of an abstraction and there's absolutely nothing stopping you from imagining that that's what is happening anyway.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on May 23, 2018, 09:52:15 PM
Which basically means you've got a 100kT+ ship moving around your defense perimeter being a target. There's a reason you don't do that in real life and instead shuffle personnel around.
USO tours are basically that. And during WW2 and before it, mobile bordellos were a thing in most armies. A space station is not in combat 24/7 nor is it necessarily sitting in the "frontlines" all the time. Having a recreational ship visit it once a year or two is perfectly reasonable.
Title: Re: C# Aurora v0.x Suggestions
Post by: DocSpit on May 23, 2018, 10:12:51 PM
Quote from: Garfunkel link=topic=9841. msg108423#msg108423 date=1527130335
USO tours are basically that.  And during WW2 and before it, mobile bordellos were a thing in most armies.  A space station is not in combat 24/7 nor is it necessarily sitting in the "frontlines" all the time.  Having a recreational ship visit it once a year or two is perfectly reasonable.

No USO tour I've ever seen has consisted of the equivalent of the Queen Elizabeth 2 pulling into port for a month.   In real life, a couple entertainers fly in on a plane, perform for a couple hours, and then leave almost immediately. 

In that respect, it actually is a lot more true to life to either require a shuttle bay, or abstract that the 'USO tour' flew into the station commercially. 

Granted, even then, this is often on top of the deployed units rotating soldiers back home for a couple weeks of leave throughout the tour. 

I recognize that in the late game, when it's not unreasonable to be employing million ton defensive bases, a la DS9 or B5, this issue effectively becomes moot, because tossing in a rec center is basically an afterthought at that point.  Mostly, my thought is to the early to mid game, where a few 5-20k ton 'watchtowers' are manageable to keep an eye on an unsecured JP, but a 150k pleasure cruiser represents a heck of an investment in shipyard infrastructure at the least. 

I just figured that, since we're making shuttles a part of the general Aurora lore, why not give them some additional meaningful parts to play in it?
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on May 24, 2018, 11:42:09 AM
Quote from: Garfunkel link=topic=9841. msg108423#msg108423 date=1527130335
USO tours are basically that.  And during WW2 and before it, mobile bordellos were a thing in most armies.  A space station is not in combat 24/7 nor is it necessarily sitting in the "frontlines" all the time.  Having a recreational ship visit it once a year or two is perfectly reasonable.
No USO tour I've ever seen has consisted of the equivalent of the Queen Elizabeth 2 pulling into port for a month.
I'm not sure this is a fair comparison.  It seems to me that Ships in Aurora tend to be quite a bit larger than real world ships.  Not only that, but the largest cruise ships today are over 200k tons.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on May 24, 2018, 12:13:44 PM
Early Aurora ships are usually smaller than modern day wet navy ships, due to limits in costs. It takes a few generations of development to get to the point you have the scale needed for that.

I mean, the biggest military ships are supercarriers of about 100 000 tons, and I just don't field ships that big before I get well into fusion engines.
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on May 25, 2018, 01:13:05 PM
I have a suggestion related to the standing orders system: Add a "return to this system" checkbox for standing orders. Whenever a conditional order sends a ship out of a system, this checkbox would automatically append orders to return to the current system. This would be especially useful for survey ships with conditional refuel orders, so that they will refuel and then return to surveying without interruption.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on May 26, 2018, 11:51:49 PM
This sounds like a suggestion to me.

@Steve Walmsley  have you tried or even played MANO (Modern Air Naval Operations) to see how they deal with the display of unit names and vectors? It can be very rapidly a mess, display wise and I think they did a few things right to de-obfuscate/unscramble display. I'm basing my observations on some screenshots, I did not play the game. But for example at a certain zoom level, individuals ships are replaced by a TF icon, and you can tooltip it. Will Aurora C# supports tooltip on the main map?
Title: Re: C# Aurora v0.x Suggestions
Post by: Ranged66 on May 27, 2018, 01:55:18 PM
I'd love a TN Economy Info window

The total empire wide production of every mineral, maybe collapsible to see the biggest production location.
The same for mineral expenditure, and maybe stockpiles.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on May 27, 2018, 05:22:24 PM
Excellent suggestion Ranger.

A summary of empire wide production, empire wide stockpiles, empire wide consumption and the same per system would be really useful. Consolidating mineral stockpiles in system is fairly simple with mass drivers, but shipping minerals around between systems requires a bit more thought, especially once you start establishing industrial centers beyond your starting system.
Title: Re: C# Aurora v0.x Suggestions
Post by: leonidas1283 on May 28, 2018, 12:12:28 AM
can you put a search function for that SM add to add things to a planet so when you have alot of colonys you can search for the colony or system?
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on May 29, 2018, 07:38:28 AM
I'd love a TN Economy Info window

The total empire wide production of every mineral, maybe collapsible to see the biggest production location.
The same for mineral expenditure, and maybe stockpiles.
I don't know how flexible such a thing could be programmed; but I imagine some kind of "universal query system" with which we can create our own "analytical statistics". Especially if you play a multi fraction game, VB6 Aurora lacked quite a bit in giving you the tools to keep everything in overview.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kytuzian on May 29, 2018, 09:08:09 PM
I don't know how flexible such a thing could be programmed; but I imagine some kind of "universal query system" with which we can create our own "analytical statistics". Especially if you play a multi fraction game, VB6 Aurora lacked quite a bit in giving you the tools to keep everything in overview.

Well there is a database for the game, so we could have a screen that display the results of SQL queries on the database, maybe let you save a few different queries so you could easily access multiple reports. That'd be about as much flexibility as you could get.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on May 29, 2018, 09:11:04 PM
He'd also have to be careful to prevent queries from breaking the DB.  Don't want to let anyone run any table drop queries.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kytuzian on May 29, 2018, 09:55:30 PM
He'd also have to be careful to prevent queries from breaking the DB.  Don't want to let anyone run any table drop queries.

Sure, but it's just a singleplayer game, so it's not that big a deal I think. I don't know if sqlite has users/permissions like MySQL/some of the others, but he could set it up so that the user used for these queries only has select privileges or something like that.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on May 30, 2018, 05:02:53 AM
In VB6 it was only possible to shut down a full part of the economy or bring them on also in full (with 180 days of startup time). Would be nice, if the shutdown could be done for parts of an industry (for example if you run into a shortage of sorium mining, you simply shut down 80% of the refineries, until the resupply is going up again).
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on May 30, 2018, 05:05:58 AM
Well there is a database for the game, so we could have a screen that display the results of SQL queries on the database, maybe let you save a few different queries so you could easily access multiple reports. That'd be about as much flexibility as you could get.
That would be something... . Being able to create some queries, which will be updated after time progressions... .
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on June 01, 2018, 02:13:34 PM
Maybe more of a general Aurora suggestion, but I was experimenting with ship design and I noticed the GPS (strength to passive EM sensors) of an active sensor scaled linearly based on the resolution of the sensor, by which I mean a sensor with twice the resolution has twice the GPS. This creates an odd situation since the range of an active sensor does not scale as fast; a resolution 10 sensor doesn't have double the range of a resolution 5 one. This means that low resolutions sensors have vastly longer ranges compared to where they would be "picked up" by passive em sensors while high resolution sensors have the opposite. This doesn't come up as often in VB6 Aurora where long range active sensors tend to dominate the battlefield but will probably be more relevant with the new sensor model.

Instead I'd suggest that either GPS doesn't scale at all (so that equivalent size active sensors would have the same EM signature regardless of resolution) or scale at the same ratio as active sensor range(area in C#) based on resolution, instead of scaling faster.
Title: Re: C# Aurora v0.x Suggestions
Post by: zatomic on June 06, 2018, 12:47:14 PM
Some thoughts after reading the digression into lagrange points in the questions thread:

Rather than deal with a separate jumping mechanic to deal with distant companion stars, why not allow inter-system jump points? I see a couple of ways to approach it. For all, lets assume some arbitrary cutoff is set where if a companion star is more than D distance from the primary where D is farther than is practical to travel with mid-game tech levels, we'll call it a Distant Companion.

Option 1: In the real-stars data-set, just make distant companions into their own systems. Thus you might find the Star A component system, and later discover a route through the jump point network to the Star B component system (or vice-versa). They act as fully separate systems and only the naming shows them as distant members of the same system. (In the random stars mode, just don't generate companions farther than D from the primary)

Option 2 (which I like better): Distant companion stars get their own set of grav survey points with associated jump points to discover. The lore seems to be that stars are more likely to have jump points to nearer stars than more distant ones (based on actual locations in the real-stars data-set and approximated by the clustering percentage for random stars). Thus we can set a specific probably that there will be a jump point from a primary to a distant companion. This could be 100% if we always want a connection or lower (possibly an adjustable parameter). If lower, you may still find a route through the jump network to the distant companion and may even get interesting situations where the primary component is closer to empire A in the jump network and the distant companion is closer to empire B. This could mean that long-hauling between components that don't have a direct jump point link becomes a way to get behind enemy front lines. It may not even be known that an enemy exists on a distant component until you find a route through the network to get there.

Giving distant components their own jump-points but keeping them in the same system map means either allowing jump points to move with the stars orbit, which could be complicated, or disabling orbital motion for distant components. I think assuming D is large enough, disabling motion would not be particularly noticeable since the orbital period of a distant companion would be very long relative to typical game length.
Title: Re: C# Aurora v0.x Suggestions
Post by: TCD on June 06, 2018, 04:47:38 PM
Very interesting suggestion zatomic. Of course logically you're right, it makes perfect sense that every star in a system should have its own potential jump points, rather than just the primary. I assume there is some technical problem with doing that though, maybe around system generation?

I suppose the main problem would be that if the inter-system connection chance is too high then you'd greatly increase the chance that binary/trinary stars are dead ends only connecting to themselves.

You could get around that by stating the opposite to your initial premise, that inter-system connections are banned for hand-wavium reasons. Doesn't help you travel in system to a companion star, but it would make all planets accessible via the jump network eventually.
Title: Re: C# Aurora v0.x Suggestions
Post by: misanthropope on June 07, 2018, 11:01:35 AM
i can attest from personal experience (running Starfire games) that a system with two (or more...) distant components each with valuable real estate and its own jump points is a natural site for major PVP mayhem.  when each component is more accessible to *other systems* than to each other, the stage is set for a pleasingly stable hostile split ownership of the system. 

perhaps aurora is too low-level (micro-intensive, i mean) or solitaire-oriented for the benefits to pertain, but a guy can dream.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on June 11, 2018, 05:26:39 AM
Less of a feature suggestion, more for what Aurora is doing in the background.
C# version will be somehow a lot faster (which I am looking forward to). However, I was thinking in the direction of "using all the resouces". Basically, a turn based game like aurora most of the time sleeps (while the user is working), and then begins to work on all necessary stuff when the user told the game to "do the turn" (in the past, whilst the user was sleeping ;-).

I was wondering if some of the calculations needed could be pre-done in the background whilst the user is working on his move.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on June 11, 2018, 12:20:04 PM
I was wondering if some of the calculations needed could be pre-done in the background whilst the user is working on his move.

Almost certainly some of them could be at least partially pre-done. E.g. when you change your prod queue, calculate right then and there what the prospective 5 (or 30) day turn looks like, and just store that until the prod timer ticks over for real, thus saving apparent time on advancement. Or when a new system is created (discovered) allow the user to work with it while figuring out during user-time how this updates civilian shipping. Or figure out starting bits of NPR response based on 1-day projections whenever you're setting up orders for TGs in their systems and close the TG window. Etc. etc.

However, all that is probably kinda boring to actually code.
Title: Re: C# Aurora v0.x Suggestions
Post by: Triato on June 12, 2018, 03:50:54 PM
I wold like for some companion stars to keep being hard or imposible to acces. It gives us a long term project, a choice to make and a diferent situation. Yes, some are so distant that they only serve as ornaments but even that gives a bit more of flavor to the game I think.

Maybe we could have a new tech branch that allows you to create intrasystem jump points at hi cost.
Title: Re: C# Aurora v0.x Suggestions
Post by: ExChairman on June 13, 2018, 05:39:07 AM
Not sure if its said before, I would like to have an order that works like this: "keep x km´s distance from enemy" So I can stay out of his weapons effective range.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on June 13, 2018, 08:10:37 AM
There is such an order.  A couple, in fact.  There is 'Follow at {distance}' that takes any ship, missile, contact, or task force as a target; along with various 'Formation' options that only accept your own or allied ships as the target, but allow you to specify an offset distance and direction (such as 60 degrees (one-sixth clockwise, if I remember correctly) or 270 degrees (one-quarter counterclockwise)) with respect to the targets' direction of travel.

Combining both, you can chase an enemy TF with your beam escorts five seconds in the lead -- split half-and-half to either side of your formation to guard against sudden lunges by beam-armed enemies -- and your scout/sensor ship tucked safely behind the rest of the fleet by ten or fifteen seconds' flight time.

'Follow' is on the regular orders/movement window (it may only come up if you first select a unit or contact as target).  Formations are on the Task Force / Fleet Organization window.  I think.  I haven't bothered to open the game to check.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on June 13, 2018, 11:24:42 AM
The problem with "follow" is that when you kill the contact you were following, the order stops and your ships stop dead in their tracks.  This can be deadly if you're kiting beam ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on June 13, 2018, 01:55:03 PM
The problem with "follow" is that when you kill the contact you were following, the order stops and your ships stop dead in their tracks.  This can be deadly if you're kiting beam ships.

You should always kill the ship you are following last :)
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on June 13, 2018, 08:50:14 PM
Thats generally how I do it, just follow the guy on the bottom of the list.  It would be quite nice if you had a 'keep x distance from hostiles' order I suppose.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on June 14, 2018, 10:25:19 AM
From what I see STO weapons are currently limited to beam weapons only.
Could we also get STO missile launchers? Without long range missiles an enemy can always park themselves outside of beam range and bombard the planet, without being able to strike back.

Further, having a beam fire control for each STO weapon sounds quite expensive. Would it not make more sense to have the fire control as a separate vehicle, where then one can combine however many guns and fire controls into a battery as you think useful?
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on June 14, 2018, 10:32:56 AM
"Would it not make more sense to have the fire control as a separate vehicle"
That's what they do in real life usually, at least for land-based AA.  Ships tend to all have their own fire control.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on June 14, 2018, 12:17:23 PM
From what I see STO weapons are currently limited to beam weapons only.
Could we also get STO missile launchers? Without long range missiles an enemy can always park themselves outside of beam range and bombard the planet, without being able to strike back.

Further, having a beam fire control for each STO weapon sounds quite expensive. Would it not make more sense to have the fire control as a separate vehicle, where then one can combine however many guns and fire controls into a battery as you think useful?

No missiles, because I want to avoid the complexities of ground units with ordnance, which also require long-range sensors and long-range fire controls. Beams are nice and straightforward. The fire controls are cheaper for ground units. I wanted every ground unit to be self-contained - otherwise it gets complex to track (for the player as well), so this is the same overall cost for separating fire controls without the micromanagement.
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on June 14, 2018, 05:25:14 PM
"Would it not make more sense to have the fire control as a separate vehicle"
That's what they do in real life usually, at least for land-based AA.  Ships tend to all have their own fire control.
Used to be, but a lot of modern ground units incorporate their own tracking systems, especially SPAAGs (which beam weapons would be relatively analogous to).
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on June 15, 2018, 01:52:25 AM
No missiles, because I want to avoid the complexities of ground units with ordnance, which also require long-range sensors and long-range fire controls. Beams are nice and straightforward. The fire controls are cheaper for ground units. I wanted every ground unit to be self-contained - otherwise it gets complex to track (for the player as well), so this is the same overall cost for separating fire controls without the micromanagement.
My PDCs just all used to be massive missile bases, with beam armament for PD only. STO units could draw ordnance from the planetary stockpile directly, and if the sensors are the problem, one could add them to the deep space tracking installations.
I really don't want to be out ranged, and if you are behind in beam tech, you cannot compensate with your missiles
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on June 15, 2018, 02:15:26 AM
You can still build orbital missile bases, and remember with the new entrenchment theoretically the idea is that to wipe out your ground forces with missiles they'd basically have to glass the planet and render it uninhabitable.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on June 15, 2018, 03:37:39 AM
My PDCs just all used to be massive missile bases, with beam armament for PD only. STO units could draw ordnance from the planetary stockpile directly, and if the sensors are the problem, one could add them to the deep space tracking installations.
I really don't want to be out ranged, and if you are behind in beam tech, you cannot compensate with your missiles

Build orbital missile bases. They are available and still very much more efficient than missile ships of similar tonnage. Problem solved.

Really, the fact PDC "broke a thousand rules and needed special code in a hundred places just to work" is one of the reasons why Steve took them out.
Even before, I refused to use them. Way too convenient and unbalanced, both because the lack of maintenance and the fact you could build them with industry rather than shipyards. I always built orbital bases for missile launchers.

By the way, you're mistaking the purpose of STO ground units here. As Persona012345 said, their purpose is: The enemy can either glass the planet at long range (if they can get past your PD), at the cost of most of its infrastructure and population.
Or try to conquer it with its infrastructure still present, a fact that is hard to accomplish because planetary assault is harsh.
And if you're behind in tech, tough luck. Build more orbital missile bases.

The purpose of STO ground units is not to keep a system clean of enemies. For that you use ships or orbital bases...
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on June 15, 2018, 12:24:01 PM
By the way, you're mistaking the purpose of STO ground units here. As Persona012345 said, their purpose is: The enemy can either glass the planet at long range (if they can get past your PD), at the cost of most of its infrastructure and population.
Or try to conquer it with its infrastructure still present, a fact that is hard to accomplish because planetary assault is harsh.
And if you're behind in tech, tough luck. Build more orbital missile bases.
I feel like it's worth pointing out that since in C# you'll be able to target planets with beam weapons, being outranged in beam tech is actually something to worry about.  Unless I'm misremembering how things will work, an enemy with longer range beams could park a beam ship just out of your range, and destroy your STO with its weaponry, with minimal damage to population and infrastructure.
Title: Re: C# Aurora v0.x Suggestions
Post by: TCD on June 15, 2018, 01:05:08 PM
By the way, you're mistaking the purpose of STO ground units here. As Persona012345 said, their purpose is: The enemy can either glass the planet at long range (if they can get past your PD), at the cost of most of its infrastructure and population.
Or try to conquer it with its infrastructure still present, a fact that is hard to accomplish because planetary assault is harsh.
And if you're behind in tech, tough luck. Build more orbital missile bases.
I feel like it's worth pointing out that since in C# you'll be able to target planets with beam weapons, being outranged in beam tech is actually something to worry about.  Unless I'm misremembering how things will work, an enemy with longer range beams could park a beam ship just out of your range, and destroy your STO with its weaponry, with minimal damage to population and infrastructure.
Yes, but I think its a bit more complicated than that because of the new terrain modifier rules. On a flat grassland planet then being outranged is a major worry, but on a mountain or jungle world it will be very difficult for a ship to successfully hit your SFO.
Title: Re: C# Aurora v0.x Suggestions
Post by: DEEPenergy on June 15, 2018, 02:24:13 PM
Weapons have failure rates now as well, to prevent that
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on June 15, 2018, 03:38:07 PM
I feel like it's worth pointing out that since in C# you'll be able to target planets with beam weapons, being outranged in beam tech is actually something to worry about.  Unless I'm misremembering how things will work, an enemy with longer range beams could park a beam ship just out of your range, and destroy your STO with its weaponry, with minimal damage to population and infrastructure.

It is possible, but as stated:
1) If you want to prevent sieges, build more orbital defense stations. Especially if you are out-teched. Do not let the enemy close if at all possible. I don't get this complaint about being outranged. Before, you had PDCs. Now, you're going to have orbital bases. It is the very SAME thing. You can put on your orbital defense bases the same things you had in your PDCs. They are functionally identical. So... what exactly is the problem with orbital defense bases?
2) As said by TCD, Steve's changes should mean that it's going to be very hard hitting troops who are heavily fortified and/or in rough terrain
3) As DEEPenergy said, failure rates. Supposedly, this constant bombardment will cost a TON of maintenance points, and cause a lot of failures. If this is combined to 2), that is if you're sieging a planet with rough terrain and a lot of fortified troops, it might take a long time and be very costly to bombard.
So it should all even out. And, once the orbital defenses have been destroyed, there should be a lot of situations where a ground invasion is just plain better.


... And also, I will be blunt.  If you are out-teched and out-produced by an enemy who has a lot more ships than you, things ARE supposed to be hard. The state of the rules, as they should be, seem balanced enough for me.

If instead the place being attacked is an out-of-the-way planet and your forces are somewhere else, it's a case of being caught with your pants down.

And even more important, Steve did these changes to hit chances from orbit and to failure rates specifically to address these possible issues. Which means that if the numbers are not balanced, I imagine he will tinker with them until they are. I understand that a lot of mechanics are going to be very different and that can cause disconcert... but there's no need to be preemptively pessimistic in my opinion.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on June 15, 2018, 05:37:20 PM
I think the point is less 'its too hard' and more you cant do everything you aught to be able to, which is arficially inflating difficulty there.  IE shooting missiles to at least try to drive away beam warships.  Beam warships even with failures will be highly potent bombardment assets.

I am fully in favor of Steve not working on something if he thinks its going to be too much trouble, but surely it would be nice to have missiles for ground units if it were feasible to do so (and Id suppose that could become a thing one day).
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on June 15, 2018, 06:57:42 PM
It is possible, but as stated:
1) If you want to prevent sieges, build more orbital defense stations. Especially if you are out-teched. Do not let the enemy close if at all possible. I don't get this complaint about being outranged. Before, you had PDCs. Now, you're going to have orbital bases. It is the very SAME thing. You can put on your orbital defense bases the same things you had in your PDCs. They are functionally identical. So... what exactly is the problem with orbital defense bases?
The fact that they aren't STO's.  This matters both because of how significant roleplay is to Aurora and because STO's are mechanically different from orbital bases, such as benefiting from fortification and using ground unit officers.
This can just as easily be turned against STO beams.  If Orbital Defense Stations being just like PDCs means we don't need STO missiles, then why do we need STO beams?  After all, you could just build Orbital Defense Stations with beams on them.

... And also, I will be blunt.  If you are out-teched and out-produced by an enemy who has a lot more ships than you, things ARE supposed to be hard. The state of the rules, as they should be, seem balanced enough for me.
It's not about things being hard, it's about having no response.  If the enemy out-ranges me with beam weapons, and I have no missiles, there is nothing I can do.  This is not the same as being out-ranged with missiles, where I at least have the ability to shoot at incoming missiles.  I understand that, too an extent, weapon failure is intended to deal with this, I feel that a mechanic which involves no player interaction is not a satisfying form of defense.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on June 15, 2018, 07:57:24 PM
That note about roleplaying brought a fun thought to mind.  I always liked the idea of huge ground units being able to bring spacecraft down in flames, but imagine if you had Ordinatus Armageddon tier things that are just gigantic weapons systems which your empire might only be able to build a few of, able to down almost anything?
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on June 15, 2018, 11:50:04 PM
Before, you had PDCs. Now, you're going to have orbital bases. It is the very SAME thing. You can put on your orbital defense bases the same things you had in your PDCs. They are functionally identical. So... what exactly is the problem with orbital defense bases?

This is a real question, not a counterpoint in the argument, which I'm merely watching as an interested observer.

Will we be able to make orbital bases with planetary industry? If not, will we have to dedicate a shipyard to orbital base construction, or is there some third way not in the current version?
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on June 16, 2018, 08:25:00 AM
I haven't seen anything that would imply that construction factories could build anything aside from civilian space stations using the new skin-hull instead of armour, so the answer is probably that you would need to use shipyards. I already use OWPs for planetary PD whereas PDCs handle missiles, so I'm used to having one shipyard at 2000 tons with like ten slipways, that builds FAC/LACs and OWPs. You can make a simplistic 1 GC turret OWP for 950 tons and a pretty decent 4 GC turret one for under 2000 tons. Retooling isn't that much of an issue because you generally don't need to build both at the same time.

Ie, I build ten OWPs, then use tugs to haul them to their new home, retool for FAC, build a batch of 20 or 30, then design new the next generation OWP, retool for it, build new OWPs and rinse and repeat.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on June 16, 2018, 01:07:20 PM
I know you can use OWP for missile bases, but you don't get the fortification for them, and there is the logic of why one should not be able to build it if so wanted.
There is a few concerns I don't know how they are handled, for one can ground CIWS defend orbital bases? Because if they are not (and ship based CIWS only defends itself), you need to set up two sets of CIWS to defend both the planet, and to defend the OWP, while ground based missiles would be covered by ground CIWS units.
Also, can turrets be used as STO weapons, and can those be set to point defense?
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on June 16, 2018, 08:55:04 PM
I'm actually kind of curious about how practical orbital stations would be with shield generators instead of armor, since that would mean (I think) you could build them with industry. But building them with shipyards would be workable too; they still get hefty bonuses compared to ships.

I know in the current version of Aurora PDC beam fire controls get a 50% range bonus, I don't remember if it was mentioned if that gets applied to the new ground based STO beam weapons? But it might help with the worries over being bombarded from out of range.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on June 17, 2018, 02:52:01 AM
I'm actually kind of curious about how practical orbital stations would be with shield generators instead of armor, since that would mean (I think) you could build them with industry. But building them with shipyards would be workable too; they still get hefty bonuses compared to ships.

I know in the current version of Aurora PDC beam fire controls get a 50% range bonus, I don't remember if it was mentioned if that gets applied to the new ground based STO beam weapons? But it might help with the worries over being bombarded from out of range.
I think shield generators qualify as military, which disqualifies them from use on stations.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on June 17, 2018, 05:58:20 PM
I'm actually kind of curious about how practical orbital stations would be with shield generators instead of armor, since that would mean (I think) you could build them with industry. But building them with shipyards would be workable too; they still get hefty bonuses compared to ships.

I know in the current version of Aurora PDC beam fire controls get a 50% range bonus, I don't remember if it was mentioned if that gets applied to the new ground based STO beam weapons? But it might help with the worries over being bombarded from out of range.
I think shield generators qualify as military, which disqualifies them from use on stations.

Space stations can use military components, though. The discussion was whether you could use industry instead of shipyards to build defense stations, which means they'd also have a bunch of guns and missile launchers that would also be military components.

As far as I can tell the only limitation on stations to be built by industry is "no armor"; I don't know if shields instead of armor would be practical, but it seems perfectly rules legal.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on June 17, 2018, 11:57:09 PM
Shielded unarmored defense stations made by factories is an interesting concept, worthy of experimentation in the very least.  (hype for new version intensifies)
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on June 17, 2018, 11:58:40 PM
Space stations can use military components, though. The discussion was whether you could use industry instead of shipyards to build defense stations, which means they'd also have a bunch of guns and missile launchers that would also be military components.

As far as I can tell the only limitation on stations to be built by industry is "no armor"; I don't know if shields instead of armor would be practical, but it seems perfectly rules legal.
http://aurora2.pentarch.org/index.php?topic=8495.msg106758#msg106758
There are two more limitations: No engines, and no military systems to qualify for being a station.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on June 18, 2018, 03:27:15 AM
Space stations can use military components, though. The discussion was whether you could use industry instead of shipyards to build defense stations, which means they'd also have a bunch of guns and missile launchers that would also be military components.

As far as I can tell the only limitation on stations to be built by industry is "no armor"; I don't know if shields instead of armor would be practical, but it seems perfectly rules legal.
http://aurora2.pentarch.org/index.php?topic=8495.msg106758#msg106758
There are two more limitations: No engines, and no military systems to qualify for being a station.

Ah, well, then I guess the discussion is irrelevant. It's not the lack of armor that prevents you using construction factories to build defense bases, it's the fact that they can't have military components at all.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on June 18, 2018, 10:33:52 AM
A small suggestion: Engines, shields, missile launcher, sensor, jump drive system development costs currently all scale linearly in size.
That leads to very expensive projects if you try to build one of the new size 400 drives, while missile engines are ridiculously cheap.

A SQRT(Size/10) scaling would make large components just a tad more attractive, and make missile development a bit more relevant. Also, in real life larger does not necessarily mean more difficult to develop, as certain things get easier if you have the necessary space available compared to cramming everything into the smallest possible compartment.
Title: Re: C# Aurora v0.x Suggestions
Post by: Titanian on June 19, 2018, 07:17:49 AM
Also, in real life larger does not necessarily mean more difficult to develop, as certain things get easier if you have the necessary space available compared to cramming everything into the smallest possible compartment.
But that is already in the game: A larger engine with the same total power is cheaper to develop. And cramming the same engine into a smaller housing (by increasing the power multiplier) increases cost by a lot.

I'd say the larger components are attractive enough the way they currently are, especially low power commercial engines.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on June 19, 2018, 10:45:32 AM
But that is already in the game: A larger engine with the same total power is cheaper to develop. And cramming the same engine into a smaller housing (by increasing the power multiplier) increases cost by a lot.

I'd say the larger components are attractive enough the way they currently are, especially low power commercial engines.
What I mean is that larger engines with the same power density are more expensive to develop, for example using either 8 size 10 engines or 2 size 40 engines with the same total power (same power multiplier) in the same space. Here you are trading off HTK for fuel efficiency.
Power density is what you usually want to keep constant when outfitting your fleet to get the same fleet speed for all ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: Viridia on June 19, 2018, 05:04:23 PM
I've done a quick search and can't find this having popped up before, so I'd like to throw in for the option to put railguns and particle beams in turrets. Also, the opportunity to research more extensions for range for beam fire controls, because right now when taken the extreme line of research, both sides are fairly disproportionate, with beam weapons often possessing a lot more range capability than offered by the fire controls.
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on June 19, 2018, 05:53:29 PM
Turreted railguns would be very overpowered for PD. With the current system, having 4 shots makes them roughly equivalent in PD capability to a laser turret, which has 4 times the chance to hit. Having no turret and a smaller fire control makes them better for their cost and size than anything but mid to late game gauss cannons. Particle beams in turrets would be odd for point defense, given their low ROF and focus on long range, but I could see it making them more viable against FACs or fighters.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on June 20, 2018, 03:06:23 PM
Simple one. A new order for task groups with populations selected: 'refuel and resupply', since we're often doing both when a ship hits port.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on June 21, 2018, 05:53:42 AM
Also useful; a 'stay for shoreleave' command. Especially for large ships you can't build enough maintenance infrastructure to run back the maintenance clock while the crew is enjoying shoreleave, but there's no 'stay here for (x) time' command that would not require you to babysit and keep checking up on which ships are ready for the next leg of their patrol. Doing this would make it a lot easier to build ships that have a smaller deployment time than maintenance time, rather than having it coincide because it's easier on running the logistics of having your ships move around.
Title: Eventinfo: Jump Point stabilized
Post by: King-Salomon on June 24, 2018, 11:55:12 AM
Hi,

just going through a campaign were I am building lots of JG - got the problem that when a JG is finished you only get an Info "XY has completed order" but no "JG as been build at JP XY"

with the chances in C#, would it be possible to include an Info-Event that says something like "JP to XY has been successfully stabilized" ? Just to make the point that a JP is stabilized more eyecatching

EDIT: there is a message that the construction is started, but no message about it beeing finished
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on June 24, 2018, 02:10:16 PM
Mass drivers should have the option of sending a specific number of minerals, instead of just turning them on and remembering a couple years later to stop sending all your stuff to Mars.  Also, the ability to pick and choose which minerals are used.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on June 24, 2018, 03:49:47 PM
Mass drivers should have the option of sending a specific number of minerals, instead of just turning them on and remembering a couple years later to stop sending all your stuff to Mars.  Also, the ability to pick and choose which minerals are used.

IIRC You can currently set stockpile levels and the mass driver wont send minerals unless they're over the amount it's supposed to keep stockpiled.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on June 28, 2018, 10:36:41 AM
Will it be possible to tug a row of ships in C#? (Without the mass calf error of VB6 of course)

Are there commands available to detach certain tugged ships at one colony and then continue to the next planet? I am thinking of General commands, not the absolute specific ones we have at the moment.

My idea is to have a tug going on a cycletour of planets and when it reaches a target Checks if there are certain types of ships waiting to be tugged to a destination, it automatically adds them to itself if the destination is on its tour, and once arrived there untuggs it.

Those ships or containers then perform there own tasks at the destination until they get picked up again by the next tug.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on June 28, 2018, 11:09:59 PM
That sounds like quite a fun feature.
Title: Re: C# Aurora v0.x Suggestions
Post by: Peroox on June 29, 2018, 03:48:37 AM
Multiple containers with box launchers! Sounds like civilian ship that can tugged multiple weapon platform.  It's good because can drag multiple orbital weapon platform to new position, but player could exploit it during battle. 
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on June 29, 2018, 09:05:13 AM
I don't know if this was said already, but would a fabrication module be possible to create missiles on the go and to passively repair the ship in exchange for minerals? It would function like an ordinance/construction/fighter factory all in one.  It would also probably be useful in colony operations to get infrastructure up.
Title: Re: C# Aurora v0.x Suggestions
Post by: Andy8583 on July 05, 2018, 02:45:14 PM
When starting a new game allow the user to 'outlaw' or make unavailable certain technology/technological paths (such as the various weapon paths) so that if the user would like, for example, a more 'Star Wars' experience they can just get rid of missiles and the rest leaving only lasers and mesons.  I imagine this could also apply to shielding /  stealth tech depending on peoples tastes (since I don't think anyone will be wanting to get rid of the production paths etc) but being able to determine the weapon types, and thus the 'meta' of the military in a game could be nice.
Title: Re: C# Aurora v0.x Suggestions
Post by: El Pip on July 05, 2018, 04:43:47 PM
When starting a new game allow the user to 'outlaw' or make unavailable certain technology/technological paths (such as the various weapon paths) so that if the user would like, for example, a more 'Star Wars' experience they can just get rid of missiles and the rest leaving only lasers and mesons.  I imagine this could also apply to shielding /  stealth tech depending on peoples tastes (since I don't think anyone will be wanting to get rid of the production paths etc) but being able to determine the weapon types, and thus the 'meta' of the military in a game could be nice.
Definitely this. As long as you also had the option to remove say missiles and mesons. Because Mesons always seem cheaty and annoying.

But if you could pick the techs, and if we could have a "tiny spinal" mount for lasers (and railguns?), a player could have a Star Destroyer packing laser armed TIE fighters as a viable fleet unit.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on July 05, 2018, 06:39:34 PM
When starting a new game allow the user to 'outlaw' or make unavailable certain technology/technological paths (such as the various weapon paths) so that if the user would like, for example, a more 'Star Wars' experience they can just get rid of missiles and the rest leaving only lasers and mesons.  I imagine this could also apply to shielding /  stealth tech depending on peoples tastes (since I don't think anyone will be wanting to get rid of the production paths etc) but being able to determine the weapon types, and thus the 'meta' of the military in a game could be nice.

This is possible but tricky. The simple implementation would be to flag certain techs as not available. However, those techs affect other parts of the game. For example, removing missiles would require removing techs such as warhead strength or missile agility, but that would leave ordnance factories, ordnance-related logistics installations, the missile design window, ordnance factory options in production, etc. You would also need to remove magazine techs, but they would still be an option in the Create Project window. It isn't as straightforward as ticking techs to exclude. Also, by excluding missiles, you also exclude recon probes, geo-survey probes or sensor buoys, unless you only exclude warheads

In addition, NPRs would have to be able to handle any missing parts of their normal tech, which would not be straightforward at all.

It might be possible at some point to have (for example) a non-missile version as an option for a game, with all the various missile-related elements removed. However, they are an integral part of the game so it would take a while to identify everything that would change. Maybe for a post-launch version.
Title: Re: C# Aurora v0.x Suggestions
Post by: El Pip on July 06, 2018, 01:42:32 AM
This is possible but tricky. The simple implementation would be to flag certain techs as not available. However, those techs affect other parts of the game. For example, removing missiles would require removing techs such as warhead strength or missile agility, but that would leave ordnance factories, ordnance-related logistics installations, the missile design window, ordnance factory options in production, etc. You would also need to remove magazine techs, but they would still be an option in the Create Project window. It isn't as straightforward as ticking techs to exclude. Also, by excluding missiles, you also exclude recon probes, geo-survey probes or sensor buoys, unless you only exclude warheads

In addition, NPRs would have to be able to handle any missing parts of their normal tech, which would not be straightforward at all.

It might be possible at some point to have (for example) a non-missile version as an option for a game, with all the various missile-related elements removed. However, they are an integral part of the game so it would take a while to identify everything that would change. Maybe for a post-launch version.
Is the simple fix just to have a No-missile checkbox that disables warhead techs and tells the NPRs to only use the beam AI schemas?

If that works, and as problems come out during play testing, it could get finessed in later versions.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 06, 2018, 04:36:09 AM
When starting a new game allow the user to 'outlaw' or make unavailable certain technology/technological paths (such as the various weapon paths) so that if the user would like, for example, a more 'Star Wars' experience they can just get rid of missiles and the rest leaving only lasers and mesons.  I imagine this could also apply to shielding /  stealth tech depending on peoples tastes (since I don't think anyone will be wanting to get rid of the production paths etc) but being able to determine the weapon types, and thus the 'meta' of the military in a game could be nice.
Well, there is torpedo tech in the SW universe; they are simply very low range, equal to the beam wepaons (one might argue, that in relation to range, the SW universe is the opposite of the Aurora universe - beams (as we have learned in TFA) can be quite long range ... . However (as we have learned in TLJ), shielding is quite strong over distance - which is the technobabble reasoning for their short range fights ... .
But let's not get off topic...
Title: Re: C# Aurora v0.x Suggestions
Post by: Tree on July 06, 2018, 06:48:11 AM
However (as we have learned in TLJ), shielding is quite strong over distance - which is the technobabble reasoning for their short range fights ... .
Is it? Man I prefer the old EU explanation that EW got so good they're down to having to rely on their own eyes.
Title: Re: C# Aurora v0.x Suggestions
Post by: Agoelia on July 06, 2018, 07:56:36 AM
Quote from: Tree link=topic=9841. msg108839#msg108839 date=1530877691
Quote from: TMaekler link=topic=9841. msg108837#msg108837 date=1530869769
However (as we have learned in TLJ), shielding is quite strong over distance - which is the technobabble reasoning for their short range fights . . .  .
Is it? Man I prefer the old EU explanation that EW got so good they're down to having to rely on their own eyes.

Could easily be both
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on July 06, 2018, 12:48:49 PM
Eh, there isnt really any kind of anti-lidar countermeasure that can defeat proper lidar but eyes can somehow see through it.  Its star wars, the actual details of the space combat are terrible.

e: I'm sure relying on your own eyes will cut right through that:

(https://qph.fs.quoracdn.net/main-qimg-c6952a944bd374081bedef9791f170d2-c)
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on July 06, 2018, 04:44:53 PM
Is the simple fix just to have a No-missile checkbox that disables warhead techs and tells the NPRs to only use the beam AI schemas?
I imagine the new way NPRs will be planning out their ships and fleets prevents it from being that simple.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on July 08, 2018, 01:34:19 PM
Having Mesons turned off is probably simple. It's just 2 techs and one beam among many. Turning missiles completely off is a huge thing. It's dozens of different techs, not only in the MK tree either, and affects the whole ship combat meta massively. It is like ripping out a quarter of the game and expecting everything to just "work" with that hole in it. I can see why someone would love a non-missile game, just that it certainly isn't easy to do properly.

Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on July 09, 2018, 12:02:35 AM
I would very much appreciate an option to turn off Jump Gate Constructors (whatever they will be called in the new version)
There is an option to remove all jump technology and have gates everywhere, but I would very much like to play with jump drives only.
Title: Re: C# Aurora v0.x Suggestions
Post by: ulf on July 09, 2018, 09:19:26 AM
Quote from: Whitecold link=topic=9841. msg108858#msg108858 date=1531112555
I would very much appreciate an option to turn off Jump Gate Constructors (whatever they will be called in the new version)
There is an option to remove all jump technology and have gates everywhere, but I would very much like to play with jump drives only.

Since jump gates are needed for the civilian traffic, wouldn't it be better to restrict it to commercial only?
Title: Re: C# Aurora v0.x Suggestions
Post by: Brian on July 10, 2018, 07:55:58 PM
When I am building ships quickly I try to use planetary industry to build some of the big ticket items so that the ship construction time is reduced.  This ends up being a bit of a pain a lot of times as I am building x engines, y turrets, etc. If we could have some means of putting together several items in a package and selecting the package to be built instead of the individual items it would help.  For example a recent cruiser I built had 4 engines, 3 heavy laser turrets, 4 point defense turrets and 4 different fire controls.  If all of this could be combined into CA1 package it would make using the planetary industry to speed up ship construction much easier.

As a note by prefabricating much of a ships components I was able to take a 30,000 ton ship with a nominal 23 month build time and instead have it finished in 5 months.  Better than 4 times as fast, which can be a big advantage in an emergency.

Brian
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on July 11, 2018, 09:30:59 PM
These are some things I suggest. 
1.   Orbital shields powered by fuel on the surface.  (Perhaps higher fuel usage?)
2.   More efficient fuel (fuel itself)
3.   Renaming shipping lines in sm mode
4.   Having chance for a ground unit to die during unrest
5.   Shipping lines going bankrupt if they have no source of income
6.   Unmanned probes
7.   Area of effect for missiles with radiation
8.   Medical research to increase life span of officers
9.   Having the correct images for the Sol System planets n system view
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on July 12, 2018, 05:51:58 AM
Since jump gates are needed for the civilian traffic, wouldn't it be better to restrict it to commercial only?
I thought I read somewhere that civilians now knew how to deal with jump tenders. I can't find the source though, I am afraid

When I am building ships quickly I try to use planetary industry to build some of the big ticket items so that the ship construction time is reduced.  This ends up being a bit of a pain a lot of times as I am building x engines, y turrets, etc. If we could have some means of putting together several items in a package and selecting the package to be built instead of the individual items it would help.  For example a recent cruiser I built had 4 engines, 3 heavy laser turrets, 4 point defense turrets and 4 different fire controls.  If all of this could be combined into CA1 package it would make using the planetary industry to speed up ship construction much easier.

As a note by prefabricating much of a ships components I was able to take a 30,000 ton ship with a nominal 23 month build time and instead have it finished in 5 months.  Better than 4 times as fast, which can be a big advantage in an emergency.

Brian

Would it not make more sense to have industry being able to directly support shipyards to some extend, reducing build times, instead of fiddling with component stockpiles. Change it so you are able to assign industry to ship construction, and flag shipyards to use industry support, accelerating the project as if it was building the components, without any of the micromanagement.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on July 14, 2018, 02:24:24 PM
More conditional orders (took damage) (if hostile is found) (fire missiles at closest hostile)? And more conditional order slots a,b,c,d. . .
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on July 14, 2018, 03:02:23 PM
Quote
Would it not make more sense to have industry being able to directly support shipyards to some extend, reducing build times, instead of fiddling with component stockpiles. Change it so you are able to assign industry to ship construction, and flag shipyards to use industry support, accelerating the project as if it was building the components, without any of the micromanagement.

Problem is the component mechanic supports and enables ALOT of other game mechanics.

Salvaging of ship components.
Scrapping ship components ( for science and resources ).
Trading of ship components ( rp multi faction games )
Moving of ship components from an industrial planet to a separate dockyard planet.
Repairs and upgrades using ship components.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on July 14, 2018, 03:28:53 PM
Problem is the component mechanic supports and enables ALOT of other game mechanics.

Salvaging of ship components.
Scrapping ship components ( for science and resources ).
Trading of ship components ( rp multi faction games )
Moving of ship components from an industrial planet to a separate dockyard planet.
Repairs and upgrades using ship components.

I agree that these are valid uses of components, building them in factories to accelerate construction however is not one of them in my opinion, because it requires tedious micromanagement.
My suggestion would be to allow industry to support shipyards as if you were microing them, to get the same advantage out without having to place all these orders.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on July 14, 2018, 04:16:31 PM

I agree that these are valid uses of components, building them in factories to accelerate construction however is not one of them in my opinion, because it requires tedious micromanagement.
My suggestion would be to allow industry to support shipyards as if you were microing them, to get the same advantage out without having to place all these orders.

3 of my 5 points are impossible or pointless to do without allowing factories to produce components... So your agreement also becomes a direct contradiction to your own statement/suggestion that follows it.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on July 15, 2018, 09:15:27 AM
Disabling increment adjustment, its really annoying.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on July 15, 2018, 09:46:08 AM

I agree that these are valid uses of components, building them in factories to accelerate construction however is not one of them in my opinion, because it requires tedious micromanagement.
My suggestion would be to allow industry to support shipyards as if you were microing them, to get the same advantage out without having to place all these orders.

3 of my 5 points are impossible or pointless to do without allowing factories to produce components... So your agreement also becomes a direct contradiction to your own statement/suggestion that follows it.

I just read through both of the Whitecold's posts, and I don't find a spot where he clearly says that he wants to rip out the ability of factories to build components (that can then be used in ships) - from my reading (especially of his last sentence) he could be talking about adding an ease-of-use feature that will e.g. take the total cost of factory-buildable components in a SY task, schedule a factory "support this SY" task, and have the factory run the time-to-completion clock more quickly at the appropriate rate to represent the factory building those components (without the components ever showing up).  Sooooo.......

Whitecold: Are you suggesting that Steve rip out the current mechanism of having factories build components that are then used by SY, or are you proposing an additional mechanism that leaves the current one in place?

Thanks,
John
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on July 15, 2018, 10:12:13 AM
Whitecold: Are you suggesting that Steve rip out the current mechanism of having factories build components that are then used by SY, or are you proposing an additional mechanism that leaves the current one in place?

Thanks,
John
Well, ripping it out would solve the discrepancy as well, but my idea would be to leave it in place, and calculating the BP needed for the components which are still missing from a design, and allowing industry to support the shipyards up to that amount of BP.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on July 15, 2018, 12:03:25 PM
Disabling increment adjustment, its really annoying.

It would be more annoying if an NPR destroyed your ships without you ever detecting them :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on July 15, 2018, 12:55:59 PM
Another suggestion of mine: Remove the missile engine component, and revert to designing missile engines along with the missile itself, adding options for boost modifier/engine generation/fuel consumption there.
The missile engine component adds an annoying step to missile design. Unlike regular engines they are very rarely reused, every new missile usually requires a new engine. Furthermore there is no incentive to use multiple engines on a missile if you can use a single one instead, and I don't think there should be one.
Also, I'd suggest to remove the cap on missile engines to 5 MSP, especially with the new incentives to large missiles.
The missile engine only adds unnecessary complications, you should not have to use an external performance calculator to find out which engine size you need in the first place.
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on July 15, 2018, 02:17:57 PM
Well, ripping it out would solve the discrepancy as well, but my idea would be to leave it in place, and calculating the BP needed for the components which are still missing from a design, and allowing industry to support the shipyards up to that amount of BP.

That doesn't address the desire to build components in advance of when you intend to build the ships. Allowing industry to support shipyards actively is great, but sometimes I'm still researching and developing the tech for a new generation of ships, and won't be done for a couple years, but I got the technology to start making the new engines right now. I don't want to lose two years of production time, so I start manufacturing the engines ASAP.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 15, 2018, 02:25:11 PM
Quality of Life suggestion: When one does not select a name pattern for new ships, Aurora automatically counts upward. But that numbering might be off for whatever reasons. Being able to set the next free number would be great.

Or even better: give us the option to create a naming scheme for every ship class, so it not automatically is the class name + increment, but rather something which can be chosen by the user.

Options: <class name>, <number increment>, <letter increment>, <manual text>, etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: Darkminion on July 15, 2018, 03:38:08 PM
Quality of Life suggestion: When one does not select a name pattern for new ships, Aurora automatically counts upward. But that numbering might be off for whatever reasons. Being able to set the next free number would be great.

Or even better: give us the option to create a naming scheme for every ship class, so it not automatically is the class name + increment, but rather something which can be chosen by the user.

Options: <class name>, <number increment>, <letter increment>, <manual text>, etc.

It would also be nice (Read as "Im Lazy") to have an option to choose the ship theme name select at random rather than going down the list alphabetically. Sure you can select the name from the theme list when queuing the ship for construction but I don't think it moves to the next name (at least in 7.2) until you queue one up automatically. Some of the cool names and be quite far down and it would be nice to see some pop up rather than wading through all the names that start with A,B,C,ect. first. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on July 15, 2018, 03:45:56 PM
That doesn't address the desire to build components in advance of when you intend to build the ships. Allowing industry to support shipyards actively is great, but sometimes I'm still researching and developing the tech for a new generation of ships, and won't be done for a couple years, but I got the technology to start making the new engines right now. I don't want to lose two years of production time, so I start manufacturing the engines ASAP.
You should still be able to all do this! The original suggestion was to be able to build packages of components to accelerate ship construction, instead of ordering every single component individually. My suggestion is to automatically calculate BP, not requiring any packages to be ordered but directly construct components in factories as they are needed.
If you want components, you can build components. What I don't like is that placing two dozen orders gets you a ship faster than placing a single order. You should not be spending your time fiddling with construction all the time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on July 15, 2018, 04:09:46 PM
I know I am not responding to every suggestion but I am reading them all. Once I get through with the AI, I will start going through the list properly.
Title: Error messages including what order causes the error
Post by: Triato on July 16, 2018, 12:27:36 PM
In the current Aurora, errors can sometimes be solved simply by changing the orders that caused the error. However, we frequently give docens of orders per turn, making it very hard to find which caused the error. My sugestion is to include which order, fleet or construction caused the error so we can change it. Also, if posible, maybe an order log where we can see the orders made in every turn.

Thank you very much for this game. I love it even though I´ve had to abandon many games due to error messages that made me have to pass minutes pressing enter to continue the game.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on July 16, 2018, 02:45:56 PM
Other random quality of life suggestion: Instead of suggesting random new companies for naming components, have a separate panel where you can save the names of the companies you have in your game (and generate suggestions)
Then you can select the company name in a dropdown menu, as you will be likely be reusing company names.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on July 16, 2018, 08:40:59 PM
Other random quality of life suggestion: Instead of suggesting random new companies for naming components, have a separate panel where you can save the names of the companies you have in your game (and generate suggestions)
Then you can select the company name in a dropdown menu, as you will be likely be reusing company names.

Strongly in favor of this, would hugely help me keep things straight (I might actually start using company names again).
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on July 16, 2018, 11:18:24 PM
Other random quality of life suggestion: Instead of suggesting random new companies for naming components, have a separate panel where you can save the names of the companies you have in your game (and generate suggestions)
Then you can select the company name in a dropdown menu, as you will be likely be reusing company names.

Strongly in favor of this, would hugely help me keep things straight (I might actually start using company names again).

Absolutely in favor, I would *love* to actually keep consistent companies for equipment and ordinance and so forth.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 17, 2018, 11:21:14 AM
Absolutely in favor, I would *love* to actually keep consistent companies for equipment and ordinance and so forth.

Would be interesting to have civilian companies also as additional production capacity - not only handing transport orders to them, but also building equipment... .
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on July 17, 2018, 03:56:28 PM
Another suggestion of mine: Remove the missile engine component, and revert to designing missile engines along with the missile itself, adding options for boost modifier/engine generation/fuel consumption there.
The missile engine component adds an annoying step to missile design. Unlike regular engines they are very rarely reused, every new missile usually requires a new engine. Furthermore there is no incentive to use multiple engines on a missile if you can use a single one instead, and I don't think there should be one.
Also, I'd suggest to remove the cap on missile engines to 5 MSP, especially with the new incentives to large missiles.
The missile engine only adds unnecessary complications, you should not have to use an external performance calculator to find out which engine size you need in the first place.
Maybe add the ability to create missile engines in missile creation without removing missile engines as a component?

Other random quality of life suggestion: Instead of suggesting random new companies for naming components, have a separate panel where you can save the names of the companies you have in your game (and generate suggestions)
Then you can select the company name in a dropdown menu, as you will be likely be reusing company names.
I think that's been discussed before, could be wrong.
Title: Re: C# Aurora v0.x Suggestions
Post by: wedgebert on July 17, 2018, 05:43:54 PM
Absolutely in favor, I would *love* to actually keep consistent companies for equipment and ordinance and so forth.

Would be interesting to have civilian companies also as additional production capacity - not only handing transport orders to them, but also building equipment... .

I was thinking about something like this. Assuming a capitalistic society, what if you had something along the following:

Multiple companies, each with fields of interest (maybe some are like Rolls Royce and focus on engines, other are Intel like and do computers, etc).

Instead of designing a new technology, you instead put out a request to these companies. "I want a 15cm UV laser with 10sec recharge". Then after some time, these companies come back with their prototypes that each have small tweaks to your request.. Maybe the Foobar Corporation's laser does an extra point of damage but takes a little extra material to make. But Barfoo Inc has a model that can fire a little farther. Then you pick the one you want and it becomes a thing to build.


Title: Re: C# Aurora v0.x Suggestions
Post by: Vivalas on July 17, 2018, 11:04:45 PM
Love how C# is coming, reading the long changes thread gets me real hyped.

While the core content is more important, I've always wanted maybe some more details in law enforcement and justice within your empire, and more specifically, details into piracy and rebellion.  Having a system where pirates can form, hijack shipping, form bases and maybe even re-invade your empire would be neat, like a weak (at first) empire that represents individual pirates and how their resources increase over time.  Perhaps things like smuggling as well so you can have parts of your navy dedicated to interdiction.

Rebellions would also be nice, where they start at certain unrest and have stages (planning, covert, overt).  Planning is where rebels gather resources and followers secretly, and then other phases like covert (where they sabotage and steal) and overt (where they outright fight the local governance and law enforcement / military).  Perhaps it could be something like certain buildings and other things on planets get allocated to the rebels in the overt stage, and other special calculations otherwise (money and equipment stolen, rebel leaders, support).

Perhaps tying into this system could be maybe a bit of fluff things, like modelling of population centers on planets and their growth / names / impacts on other mechanics, and maybe small little details like statistics on minor civilian traffic at worlds (things like small shuttles, liners, recreational vessels and such that are too numerous and insignificant to be modeled by the game, but a statistic that could impact smuggling difficulty or tie into other things).  Just some thoughts, and I want to get the idea off even if you don't want to go down that rabbit hole!  :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on July 18, 2018, 04:40:30 AM
Absolutely in favor, I would *love* to actually keep consistent companies for equipment and ordinance and so forth.

Would be interesting to have civilian companies also as additional production capacity - not only handing transport orders to them, but also building equipment... .

I was thinking about something like this. Assuming a capitalistic society, what if you had something along the following:

Multiple companies, each with fields of interest (maybe some are like Rolls Royce and focus on engines, other are Intel like and do computers, etc).

Instead of designing a new technology, you instead put out a request to these companies. "I want a 15cm UV laser with 10sec recharge". Then after some time, these companies come back with their prototypes that each have small tweaks to your request.. Maybe the Foobar Corporation's laser does an extra point of damage but takes a little extra material to make. But Barfoo Inc has a model that can fire a little farther. Then you pick the one you want and it becomes a thing to build.

I have considered something on these lines before (as well as civilian companies building warships for the government). Probably won't in the first version, but will consider for the future.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on July 18, 2018, 07:47:55 AM
Much of this has already been suggested or discussed elsewhere, but I thought I'd put in my two pesos.  Sorry for the wall of text.

1. Fuel
Off-Topic: show

I like the new refuelling orders, especially the minimum reserve.

Please let the reserve be specified in liters.

It wasn't mentioned, but please retain the "Transfer Fuel to Colony to Set Level" order, and/or allow colonies to have a maximum fuel level set.

Allow fuel reserves to be set for non-tankers, especially carriers.  If carriers must be tankers then allow them to be set to only refuel their own parasites.

Allow per-ship fuel limits, with the class limit as default for new ships.  An order to change the limit would also be appreciated.

A "Refuel Until Full" order variant.  If the refuel does not complete, fleet will wait until the next production tick to try again.  No message or interrupt should occur.

A "Wait until (target) fuel < X" order.  Checks should be after production ticks.  Fleet should not need to be at (target) to check it.  This will help with demand-based refueling orders.

2. Cargo
Off-Topic: show

I second the "Unload All Cargo" order, and also suggest a general "Unload Everything" order that unloads cargo, fuel, magazines, survivors, pows, etc, all in one go.
It seems you can't hide a quote.
For instance, it'd be great to have a cargo group setup to load materials from a colony once that colony hits a certain level.

You can already do this one in VB6. The move order is "Load Mineral when X available"
Off-Topic: show

That only applies to a single mineral type.  It doesn't help if you have multiple mineral types of unknown mix, or if you may already have an unknown amount of cargo from a previous stop.

There is a "Load All Minerals" order, but it only has a maximum, not a minimum.  It doesn't wait for a full load.

Suggestions:
"Load All Minerals when X available" for when you want a fixed size load of unknown mix.
"Load All Minerals Until Full" for when your fleet capacity might vary, say by adding or removing ships, or partial loads from previous stops.
-These should start with whichever mineral has the most available.  On failure, sleep until the next production tick and try again.  No message or interrupt should occur.

"Unload X (Mineral)" for metered drop-offs.  Currently you have to unload everything and then load back what you didn't want to drop off.

3. Fighters
Off-Topic: show

5000L tanks are sometimes too large for my smallest scout fighter designs, especially when fine-tuning.

Fuel Storage-Fighter / 1000L / Cost 1 / Size 0.02

0.1HS size increments for engines smaller than 10HS, at least down to 0.5HS.  A 1HS minimum total ship size, like the 1MSP minimum for missiles, may be appropriate.

This is probably pushing it, but a new Fighter hull type that can't self-maintain or repair, but only needs a bridge crew.  It must return to a hangar for all repairs and service and cannot have Engineering Spaces or Damage Control.  Deployment time should be measured in days, instead of months.  A Cockpit module as a smaller alternative to a Bridge.  It seats a Pilot and may seat a Navigator/Sigint or a Gunner/Bombardier.  This new type is not intended to replace current mid to long range 'Ship' type fighters, but gives options for smaller short to medium ranged craft.

4. AoE
Off-Topic: show

Another way to alleviate the Size 1 ASM spam problem is with AoE.  I propose variants of either a MOO2 or MOO3 Lighting Field, which are essentially EMP weapons.  Both are FDF-only.  They could (should?) be advanced Spoiler techs.

Lightning Shield* is an FDF-self ship component that scales with ship size like a Jump Drive.  Only one can be equipped per ship.  It has no firing rate, charge, or speed limits, but has a size based hit chance.  Like a shield it increases EM signature while active.  It should fire before CIWS, with a 1/(1+MSP) chance of killing each incoming missile.  It should also hurt boarding parties attempting to land or breach.

Lightning Emitter* is an FDF-group beam weapon that can engage a single salvo per shot.  It should be a self-contained turret similar to CIWS, with a 1/(1+MSP^2) chance of killing each missile in a single salvo.

Neither weapon makes other beam defences obsolete since larger missiles still get through.

*Sorry, but I suck at naming things.

5. Civilian Trade
Off-Topic: show

Currently, the number of civilian ships built has little to do with actual need.  Keeping the number of freighters and colonizers equal results in a large surplus of idle colonizers.

Suggestion:
The number of civilian ships needs to be workload-limited.  The key indicator is the number of idle ships of each type.

Each yearly build cycle, each company has a 1/(1+Idle) chance of building a new ship of each eligible ship type, capped by available funds.  Replacing existing ships uses the same formula, except Idle is decremented each time a ship is not replaced.  Assuming a 10 year ship lifespan, this should trend towards 4-6 idle ships of each type per company.

Idleness can be instant at time of check, or tracked over time by keeping a running average of idle ships each build cycle, after job assignments.  Average=(Idle+OldAverage*Cycles)/(Cycles+1) where Cycles is the number of build cycles you want to track.

6. Colonization
Off-Topic: show

When creating a new colony, or for existing colonies with no population, it should be possible to specify the intended resident species.

Instead of a fixed 25m threshold, a more flexible dynamic system might be preferable.

Each colony does a population capacity and desirability check.
The greatest of overcrowding, 50% of unemployed, and some factor of Political Stability and emigration subsidy, is always available for export.
(Free Space - Incoming) * 0.8 is always available for import.  The 0.8 is to allow for growth during delivery.
Desirability is calculated from Political stability, crowding, unemployment, and immigration/emigration subsidies.
Population will only consider moving to a planet with higher desirability.

Player set per-colony immigration/emigration subsidies would allow fine-tuning.
Players should be able to forbid immigration regardless of population level.  This plus an emigration subsidy could allow evacuating a colony.

7. Jump Drives
Off-Topic: show

Remove the requirement that a Jump Tender be the maximum size that it can escort, only that it carry a drive that powerful.  This could be limited to standard transit or commercial drives.  Currently, commercial jump tenders require significant padding as well as larger shipyards.

Allow both commercial and military Jump Drives on the same tender.  This would allow a single tender to service both a 50kt commercial salvager and a 1kt military survey ship.

Allow commercial engine tugs pulling military engine ships to use commercial tenders if the tender can tandem-jump them under the tug's power.

8. Tugs and Tractors
Off-Topic: show

Allow disabling the engines on the towed ship.  This can matter when hauling a fast military ship.

Tactical Tractor Beam

A weaponized Tractor Beam.  Only one can be equipped to a ship.  It can be used to Grab an enemy ship within range, or just Counter the target's own TT without Grabbing.  A Grabbed or Countered TT can only Counter.  Multiple attackers can attack the same target.  A TT breaks a standard tractor link, whether used on tug or load.

When Grabbing, the attackers' EP is subtracted from the target's:

If the target still has EP, attacker's weight is added to determine the new speed and the attackers are dragged along behind.  Target loses all speed bonuses against attackers.  Attackers lose 90% of their speed bonuses when defending from target, or each other, but can use target's new speed bonus against anyone else.

If the target is reduced to 0 EP, then it is immobilized.  Attackers must remain in range to maintain lock, and are limited to 10% their maximum speed, but are otherwise mobile.

This would be very helpful in boarding operations and allow new swarming tactics.

Spoilers could use it to catch prey to eat.  Alive.

9. Misc
Off-Topic: show

An "R&R" order to rest crews.
Landing parasites should warn if they can't fully rearm.
*action* at Current Location order variants would be helpful when creating order templates.

10. Spoilers
Off-Topic: show


Amoeba - Monster that occurs in nebulas.  TH only, no EM signature.  Stealth bonus according to nebula level.  No internal components.  Immune to HPM and Meson.  Boarding is suicide.  Anything eaten increases Amoeba mass.  Damage reduces mass, and can spawn small amoebas at further expense of parent mass.  If lured out of the nebula, missiles cause both explosion and radiation damage.  Pseudopod that acts like a Tactical Tractor.  Once target is immobilized, the Amoeba moves in for the kill.

If less than half the size of target, the Amoeba will act like a boarder, and burrow through the hull.  Once inside it will try to eat components and crew from the inside.

If at least twice the size of target, target is enveloped.  Any smaller attached Ameoba will be immediately eaten.  Digestion rate is one hit per 12 columns every 5 seconds, random distribution.  Damage that penetrates results in digestion of ship components and crew, with destroyed components getting eaten rather than exploding.  An enveloped ship can fire any of its weapons with a 100% hit chance.  Missiles and bombs will explode against the ship's hull damaging it as well as the monster.  Abandoning is suicide, since the Amoeba will eat the escape pods.  Self destruct causes high damage, and has a high chance of splitting the Amoeba.  Other ships attacking risks hitting the enveloped ship.

Other ships are too big to swallow, but too small to enter.  The Amoeba will stick to the side and try to eat it anyway.



Snowflake - Has an EM signature, but no TH.  Fires a beam weapon that only kills crew.  Ignores armour, but shields can block it.  Every kill increases mass.  Missile damage risks breaking off pieces that can then attack independently from the mother.  Heaven help you if it reaches a major population.

Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on July 18, 2018, 10:13:47 AM
I have considered something on these lines before (as well as civilian companies building warships for the government). Probably won't in the first version, but will consider for the future.

I think the best way to approach Civilian assistance is to focus on the less exiting parts of empire building.

For example mining expansions, civilian minerals market in industrial locations, demand/supply like moving population from where there is unemploynent to colonies where lots of open jobs exist. Or moving minerals from where there is excess to where alot of demand exists, as well as salvaging.

Id like each system to have a taxation level of various civilian activities so you can control how much freedom they have and their growth ( or decline by overtaxation ).
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on July 18, 2018, 03:06:17 PM
Another suggestion from my side:
Area Defense PD mode right now is quite useless, as many missiles can skip through the entire PD range in a single increment. I'd suggest to make all Area PD beams also get in a Final PD shot. (The Area PD should first try to engage final inbound after all Final PD weapons fired, if none are available, engage one in range if possible)
Thus beams would get at least 1 shot in, possibly 2, depending on range. This would make longer range on PD more appealing, as currently there is little advantage for any of the range upgrades, because all the shots are fired at 10k range anyway.
Title: Re: C# Aurora v0.x Suggestions
Post by: Triato on July 18, 2018, 03:31:08 PM
Civilians don´t spend fuel right now. Expanding civilian activities to much would decrease the fuel scarcity push towards colonizing new worlds or conquering them.  If civilians used fuel, they would frequently end reserves without the player being able to do much about it. Maybe they should use fuel with players being able to limit their consumption?, this with a rebalancing of the typical ammounts of fuel found on default empire planets.
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on July 18, 2018, 05:54:36 PM
Civilians don´t spend fuel right now. Expanding civilian activities to much would decrease the fuel scarcity push towards colonizing new worlds or conquering them.  If civilians used fuel, they would frequently end reserves without the player being able to do much about it. Maybe they should use fuel with players being able to limit their consumption?, this with a rebalancing of the typical ammounts of fuel found on default empire planets.

Perhaps it could be treated as them buying government produced fuel. Civilian ships consume fuel stockpiles, and give wealth. The player can disable this, but civilian lines will significantly slow down as they are forced to consume from the civilian fuel market that is implied, strangling their throughput. I'm not certain we'd still need or want that though. I usually found the cap of my fuel infrastructure was my ability to refine and distribute it, not just mine it. Reducing the amount of fuel I have after refining and distribution doesn't really encourage me to colonize more so much as it encourages me to reduce those fuel costs. 20mil+ Sorium gas giants are fairly common in my experience, and that'll last me quite a while with intelligent use.
Title: Re: C# Aurora v0.x Suggestions
Post by: DIT_grue on July 19, 2018, 01:51:45 AM
A Cockpit module as a smaller alternative to a Bridge.  It seats a Pilot and may seat a Navigator/Sigint or a Gunner/Bombardier.  This new type is not intended to replace current mid to long range 'Ship' type fighters, but gives options for smaller short to medium ranged craft.

Any ship of 1000 tons or less can leave the Bridge off altogether. (Unless that's been changed and I've forgotten?) Did you mean to engage the new Command & Control (http://aurora2.pentarch.org/index.php?topic=8495.msg101818#msg101818) rules? Because at first glance this suggestion looks seriously imbalanced in that context, to the extent of undercutting stated design goals.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on July 19, 2018, 03:50:30 AM
Civilians don´t spend fuel right now. Expanding civilian activities to much would decrease the fuel scarcity push towards colonizing new worlds or conquering them.  If civilians used fuel, they would frequently end reserves without the player being able to do much about it. Maybe they should use fuel with players being able to limit their consumption?, this with a rebalancing of the typical ammounts of fuel found on default empire planets.

Civilians can harvest their own fuel. So why not just let them keep doing this and ship it home to the systems main colony to build a separate civilian fuel stockpile. If demand and supply works here civilians build more harvesters if their activities consume fuel at a faster rate than it's harvested since price of fuel increase and harvesters become more profitable.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on July 19, 2018, 07:53:20 PM
A Cockpit module as a smaller alternative to a Bridge.  It seats a Pilot and may seat a Navigator/Sigint or a Gunner/Bombardier.  This new type is not intended to replace current mid to long range 'Ship' type fighters, but gives options for smaller short to medium ranged craft.

Any ship of 1000 tons or less can leave the Bridge off altogether. (Unless that's been changed and I've forgotten?) Did you mean to engage the new Command & Control (http://aurora2.pentarch.org/index.php?topic=8495.msg101818#msg101818) rules? Because at first glance this suggestion looks seriously imbalanced in that context, to the extent of undercutting stated design goals.
Engaging the new rules is exactly what I was hoping for.  What I was suggesting is a small ship that only has a bridge crew, limited to a pilot and possibly one other officer, like a modern two-seat fighter.  It also has the natural vulnerability that a single hit to the cockpit is an instant kill, since that is the only crew on board.  I fully understand if Steve doesn't go for it, but I'd love to be able to build X-wing fighters.

Civilians don´t spend fuel right now. Expanding civilian activities to much would decrease the fuel scarcity push towards colonizing new worlds or conquering them.  If civilians used fuel, they would frequently end reserves without the player being able to do much about it. Maybe they should use fuel with players being able to limit their consumption?, this with a rebalancing of the typical ammounts of fuel found on default empire planets.
Expanding the player hauling orders so set-and-forget automatic hauling routes can be set up would eliminate the need for civilian inter-system mineral and fuel hauling, rendering the entire question moot.  It would also allow regular supply lines to the new deep-space orbitals to be created.  The new fuel orders are a good start, but don't quite go far enough.  This is the single biggest item on my wish list, since there is currently no actual way to do it, and it gets very micro-managy very quickly.

Off-Topic: show

Automated mineral hauling is just plain broken, and supply hauling could use some love too.  Supply ships can be military, so they should be able to set reserve supplies, just like tankers now have reserve fuel.  Carriers need to distinguish between their own resources and those available to parasites.

The same base logic applies in all cases, so a general approach might be more productive.  A single ship might carry more than one resource type, and players often need to treat multiple mineral types as a single resource, so generic "All" and "All Minerals" resource types are needed.

Source-limited hauling is easy, since a "Load (resource), repeat until full" order covers the most common use case.  Demand-limited hauling can likewise be supported by an "Unload (resource), repeat until empty" order, as long as the destination has a maximum capacity or a soft cap* can be set.  More complex cases can be handled with minimum and maximum amounts and an option to top-up to reserve in addition to the requested amount.  Retry vs pause and warn vs ignore should also be an option.

"Wait for (resource) at (target) to be (above/below) (limit)" allows a hauler to wait at a source location while watching a destination, or at a rest stop while watching either.  It can also allow a hauling route to be metered by another resource.

*Currently we can specify a cap as part of an "Unload Fuel to Colony" order, but it must be specified for each tanker and requires rebuilding the order lists if the cap changes.  There is no cap for minerals, just a reserve.  I suggest both a reserve and a soft cap be settable at a colony for each resource type.  Mass drivers are free to ignore the caps of course, but unload orders should respect them.


Another thought that came to mind is a few Task Group orders that would help with upgrading static haulers using the new TG rules.
An order to wait for a specific task group to not be empty.
An order to take a ship/subgroup from another TG.
An order to exchange ships/subgroups with another TG.
An order to transfer a ship/subgroup to another TG.

Off-Topic: show

Consider the following set of Task Groups:

New25kFreighters
Transfer25k
ScrapMe
Auto25k{1-25}

New25kFreighters is attached to a shipyard and receives new 25k freighters.
ScrapMe is attached to a shipyard, possibly the same one, and receives outdated ships for scrapping.
Auto25k are 25 automatic freight haulers throughout my empire.
Transfer25k is an empty group with the following orders, once for each Auto25k group, on cycle:

-Wait for New25kFreighters not empty
-Take 1 ship from New25kFreighters
-Swap ship with Auto25k1
-Give ships to ScrapMe
*
*
*
-Wait for New25kFreighters not empty
-Take 1 ship from New25kFreighters
-Swap ship with Auto25k25
-Give ships to ScrapMe

To upgrade my freighters to a new model, I would queue 25 new ship builds at the shipyard and Transfer25k would cycle through each task group, delivering the new ship and returning the old one.  To add a new task group, I could just add it to the end of the queue.  Removing an old taskgroup is trickier, since it requires rebuilding the list.
Title: Re: C# Aurora v0.x Suggestions
Post by: ardem on July 19, 2018, 09:46:35 PM
The idea of a killed crew but the ship not blowing up is a cool idea for cockpit modules. It means the possibility of intact ships for salvage and technical specs available. You could still make it a salvage operation but when you pick up you get the whole craft.



Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 22, 2018, 02:41:50 PM
It would be nice if you could add a command which "waits" for Overhaul to be completed, so a ship could then depart directly after overhaul.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 23, 2018, 08:56:30 AM
I also would suggest to rework transport commands; especially in the area of transferring a certain amount of industrial complexes to other planets.

What happens most of the time is, that I transfer AutoMines to new locations when a planet has gone exhaust. Which means setting up one cycle of transport and then repeating or set it to cycle move. But lets say I want to transfer 120 AMs to Planet X and 90 to Planet Y. Then I have to set up two task forces and be exact with the repetitions. But later down the line another transport task group finishes and I simply want to add those ships to transfer to Planet X also. I then have to either recreate everything after merging or set up another task group but reduce the original group. If the task group simply would have an order stack of

a) load AMs on Planet A
b) unload AMs on Planet B
c) refuel on Planet E
d) Cycle until 120 AMs have been transferred (auto reduce after every load command)

then I just could join the new ships to that task group and have an easier micromanagement.
Additionally, if the route to the target would be recalculated each time (and if Lagrande Points could be included), it would use those points when usefull, otherwise not. In VB6 if you have set up such a cycle with LGPs and they move around, the trip might become longer than necessary.

Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on July 24, 2018, 02:03:13 AM
I also would suggest to rework transport commands; especially in the area of transferring a certain amount of industrial complexes to other planets.

What happens most of the time is, that I transfer AutoMines to new locations when a planet has gone exhaust. Which means setting up one cycle of transport and then repeating or set it to cycle move. But lets say I want to transfer 120 AMs to Planet X and 90 to Planet Y. Then I have to set up two task forces and be exact with the repetitions. But later down the line another transport task group finishes and I simply want to add those ships to transfer to Planet X also. I then have to either recreate everything after merging or set up another task group but reduce the original group. If the task group simply would have an order stack of

a) load AMs on Planet A
b) unload AMs on Planet B
c) refuel on Planet E
d) Cycle until 120 AMs have been transferred (auto reduce after every load command)

then I just could join the new ships to that task group and have an easier micromanagement.
Additionally, if the route to the target would be recalculated each time (and if Lagrande Points could be included), it would use those points when usefull, otherwise not. In VB6 if you have set up such a cycle with LGPs and they move around, the trip might become longer than necessary.
This is what civilian shipping orders are designed for.  Hopefully the rework that is going into C# will make it more stable than VB.
Title: Re: C# Aurora v0.x Suggestions
Post by: Alucard on July 24, 2018, 12:12:31 PM
Can we get some statistics about how many of our people died (of unnatural causes) and from what reason?
Eg. : 1000 people died in battle this month/year/decade/all time (setting above)
       2000000 people died being bombed from orbit
       7000 people died due to anti-terraforming

I would love it for role-playing reasons.
Title: Re: C# Aurora v0.x Suggestions
Post by: joeclark77 on July 24, 2018, 01:17:55 PM
I'd like to suggest automated terraforming: as soon as you install terraforming bases or move them into orbit, they should automatically add or remove gases until the planet is suitable for life.  The algorithm would be simple in most cases: if the temperature cost is greater than 2.0, add greenhouse or anti-greenhouse gas until it's <= 2.0, then add or remove oxygen until that's at an acceptable level, then finish adjusting the temperature if necessary.

It would be one less thing to have to micromanage, and less calculation/guesswork to have to do.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on July 25, 2018, 01:53:01 AM
An idea for reimplementing laser warheads:
Laserheads are a designable component, with one technology increasing the base range, and variable size, which changes the strength of the laser head. Size would scale as x^3/2 with the damge output. The laser warheads can be chosen as upper stage of the missile. The separation range gives the firing range of the warhead, which also is the range any final PD will fire at it.
The warhead of the missile must be strong enough to pump all the laserheads, and the damage profile will be like the laser's profile.

This would lead to several interesting dynamics:
-They form a hard counter to gauss based missile defense, requiring missiles or lasers as PD weapons.
-Laserheads will be large missiles, and thus also very likely to mount ECM, encouraging possibly even larger AMM equipped with ECCM
-Laserhead missiles will themselves have a tradeoff of more smaller hits with small laserheads or a few larger laser hits with less overall damage output.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 25, 2018, 08:01:45 AM
This is what civilian shipping orders are designed for.  Hopefully the rework that is going into C# will make it more stable than VB.
Yes. I think it would be a nice feature, if you could do what the civilians are doing, with your own ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 25, 2018, 08:11:08 AM
In situations where you explore a new system, it can happen at times that you have refuel a ship. I tend to do that with the automated commands. However, to be on the save side, there is only the option to give the automated command by using 50% fuel rule; otherwise you could end up with a stranded ship and have to micromanage.

Suggesion: a new command which calculates the distance to the nearest fuel ship and determines how much fuel reserve would be needed to get back to the mother ship and refuel. The calculated number + 5% should then be the point at which the explorer returns to the fuel ship.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on July 25, 2018, 06:51:14 PM
I'd like to suggest automated terraforming: as soon as you install terraforming bases or move them into orbit, they should automatically add or remove gases until the planet is suitable for life.  The algorithm would be simple in most cases: if the temperature cost is greater than 2.0, add greenhouse or anti-greenhouse gas until it's <= 2.0, then add or remove oxygen until that's at an acceptable level, then finish adjusting the temperature if necessary.

It would be one less thing to have to micromanage, and less calculation/guesswork to have to do.
I'm not against this as an option, but the ability to manually set gas levels has both strategic and RP value, in making a planet suitable for more than one species (who aren't necessarily all present), deciding how much work I want put in to making the planet inhabitable, and making a blockaded planet unsuitable for the enemy.

The only real problem is that the terraformers always overshoot their goal, which can be frustrating.  It would be convenient if species tolerances were shown in the terraforming window, and a job queue would reduce the player workload to once-per-colony.  The calculations themselves are quite simple, just needing the common calculator that comes with modern operating systems.

This is what civilian shipping orders are designed for.  Hopefully the rework that is going into C# will make it more stable than VB.

Yes. I think it would be a nice feature, if you could do what the civilians are doing, with your own ships.
Good point, I'm just not sure how that could be implemented with the current order style.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 26, 2018, 03:48:36 AM
Terraforming would be easier (meaning less micro) if you could set a target composition of the desired atmosphere (that screen will tell you the final temperatures etc.); and once you have set the target, the TFs work towards that goal. So basically not having to do it by your own step by step, meaning gas by gas... .
Title: Re: C# Aurora v0.x Suggestions
Post by: Rich.h on July 27, 2018, 12:27:18 PM
Terraforming would be easier (meaning less micro) if you could set a target composition of the desired atmosphere (that screen will tell you the final temperatures etc.); and once you have set the target, the TFs work towards that goal. So basically not having to do it by your own step by step, meaning gas by gas... .

I like this idea and will throw out an expansion on it. Taking the classic Earth type in the current game, you could simply enter an end result of 0.79 Nitrogen atm, 0.20 Oxygen atm and 35C. The game can then just do a simple work through process. So first it would look at each gas in the total gases list and then begin either an addition or subtration to ensure that gas meets the end goal, move to the next gas and repeat until the list is complete. Keep the greenhouse/anti greehouse gases on a seperate list and then look at those two again conducting addition/subtration as required until the target temperature is met.

This would mean you only ever have to order a task group to the location, or setup the planet based facilities. Set your end goal targets and just wait. A simple message system that informs you at each gas stage "The requirements of Argon for planet X have been met" is all that would be needed to give some feedback without overloading the events log.
Title: Re: C# Aurora v0.x Suggestions
Post by: snapto on July 27, 2018, 02:38:33 PM
Apologies if this has been suggested before but it would be great if the admin and TG names on the new naval org screen also had what system they were located in (maybe in parenthesis). Also, would it be possible to link the TG names so that clicking would take you to the system the TG is located in? Loving the changes so far!
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on July 28, 2018, 07:34:05 AM
A suggestion for ground combat:
So far there is little interaction between different components of a formation. If you separate out each in a different formation, or keep them all together does not matter. I would like to see more incentive to design combined arms formations.
My idea to accomplish this is to introduce a weight to targeting, depending on the skill of the defending formation commander. This weight is against hitting the priority target of the weapon, instead hitting a different unit in the same formation.
This would represent the commander employing the right units, tanks giving cover to infantry from machine guns, infantry covering the flanks of armor, and give a benefit to employing different types of units in the same formation.

A further expansion would be to also consider the mobility of a formation as a whole, instead of only individual units. Each unit would receive a modifier to mobility depending on the most immobile unit in a formation. This would encourage to keep assault formations and garrison formations separate, and also encourage producing mobile HQs for mobile formations.
It would further allow to have a purpose for a transport component. This component can be slotted on a vehicle, and allows it to increase the mobility of a certain amount of infantry in the same formation to the level of the vehicle. APCs and IFV are part of modern combat that is currently not getting represented in the combat system without any transportation requirements. This way you can add mechanized infantry to support your tank brigades, with a clear game play benefit.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 29, 2018, 03:56:39 AM
Suggestion for the Commanders Screen: In the assignment of planetary governors, it would be very helpful when some kind of abbreviation for the type of colony would be shown in the "potential assignments" window. Something like this:

A6 Governor of Earth Sector
A4 Governor of Earth
A1 Governor of LP Ceres
A0 Governor of AST Hippo
A0 Governor of CMT Encke

The abbreviations are
AMC = Automated Mining Colony
CMC = Civilian Mining Colony
LP = Listening Post
AD = Archeological Dig
TS = Terraforming Site

AST = Asteroid
CMT = Comet

In that way, assigning fitting commanders is easier when the list grows quite big.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 29, 2018, 08:37:30 AM
The message "Refuelling of <FleetName> could not be completed" would be more helpful, if it tells one, how much fuel is now loaded in the fleet.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 30, 2018, 08:38:31 AM
Variable size for stuff like:
- Crew Quarters
- Hangar Space
- Maintenance Space
- Maintenance Storage
- Fuel Storage
etc.

Instead of having to research or having available 6 different fixes sizes, I think it would make more sense to be able to tell the program how much it should add to the ship and the overall size and material use of that module is calculated based on that size.

Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on July 30, 2018, 09:04:21 AM
Variable size for stuff like:
- Crew Quarters
- Hangar Space
- Maintenance Space
- Maintenance Storage
- Fuel Storage
etc.

Instead of having to research or having available 6 different fixes sizes, I think it would make more sense to be able to tell the program how much it should add to the ship and the overall size and material use of that module is calculated based on that size.

Larger fuel modules (for example) are more efficient in terms of cost while you may want multiple smaller modules to allow for redundancy. Otherwise life support or fuel could be lost all at once. The variation is to allow player choice. BTW I think for C# the smaller life support systems are all available without research (not at home at the moment so can't check).
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on July 30, 2018, 11:07:57 AM
Quote from: Steve Walmsley link=topic=9841. msg109141#msg109141 date=1532959461
Quote from: TMaekler link=topic=9841. msg109140#msg109140 date=1532957911
Variable size for stuff like:
- Crew Quarters
- Hangar Space
- Maintenance Space
- Maintenance Storage
- Fuel Storage
etc.

Instead of having to research or having available 6 different fixes sizes, I think it would make more sense to be able to tell the program how much it should add to the ship and the overall size and material use of that module is calculated based on that size.

Larger fuel modules (for example) are more efficient in terms of cost while you may want multiple smaller modules to allow for redundancy.  Otherwise life support or fuel could be lost all at once.  The variation is to allow player choice.  BTW I think for C# the smaller life support systems are all available without research (not at home at the moment so can't check).
Why not instead have both a number for how many tanks its held in? I. E set the fuel to 1. 5 million tons in 6 tanks, with each tank taking up equal space and holding equal amounts of fuel.  Perhaps even have a field for smaller tanks, if you really want too.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on July 30, 2018, 12:53:46 PM
Quote from: Steve Walmsley link=topic=9841. msg109141#msg109141 date=1532959461
Quote from: TMaekler link=topic=9841. msg109140#msg109140 date=1532957911
Variable size for stuff like:
- Crew Quarters
- Hangar Space
- Maintenance Space
- Maintenance Storage
- Fuel Storage
etc.

Instead of having to research or having available 6 different fixes sizes, I think it would make more sense to be able to tell the program how much it should add to the ship and the overall size and material use of that module is calculated based on that size.

Larger fuel modules (for example) are more efficient in terms of cost while you may want multiple smaller modules to allow for redundancy.  Otherwise life support or fuel could be lost all at once.  The variation is to allow player choice.  BTW I think for C# the smaller life support systems are all available without research (not at home at the moment so can't check).
Why not instead have both a number for how many tanks its held in? I. E set the fuel to 1. 5 million tons in 6 tanks, with each tank taking up equal space and holding equal amounts of fuel.  Perhaps even have a field for smaller tanks, if you really want too.
That way leads to unrepresentable fractional numbers, which are best avoided.  On the other hand, specifying the number of tanks and the number of liters per tank would work nicely.  An HTK option like we have for magazines, representing compartmentalized or self-sealing tanks would work, too.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on July 30, 2018, 03:15:37 PM
Sometimes you want one big tank then a couple backups.  In fact that's common for me.  Current system enables that, maybe some way to design tanks of player-defined sizes would be handy if that's pretty easy to add.  Otherwise I ask it be left as-is
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 31, 2018, 10:16:17 AM
Thinking about ECM / ECCM etc. The actual system in Aurora is, in the end, not very reflective of what happens on the real battlefield. And you basically rush through the research and that's it.

What I propose would be a mixed system:
a) An advance in technology as we have it today
b) an individual implementation based on b.1) weapon and b.2) enemy experience

Both of the B-Parts are "software" and will be implemented fleetwide, once researched. A is still the usual physical part.
Once you create a new wepaon that uses ECM or ECCM you have to start with Tech 1 ECM or ECCM. Once you have researched it you can do the "software" research for Tech 2, etc. for each weapon. Such you advance the effectiveness of the ECM / ECCM system step by step.

Additionally on your first encounter with an enemy, your ECM and ECCM system will be very ineffective. But through the battle you gain battle experience, which then creates another research option for "racial software ECM Tech 2" etc. So depending on your battle experience your ECM and ECCM systems become more effective against the races with which you do battle.

This would give incentive for two things:
a) little scirmishes to gain battle experience
b) espionage to "steal" battle experience to stregthen your ECM / ECCM even before your first battle... .
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on July 31, 2018, 11:44:24 AM
Quote from: Steve Walmsley link=topic=9841. msg109141#msg109141 date=1532959461
Quote from: TMaekler link=topic=9841. msg109140#msg109140 date=1532957911
Variable size for stuff like:
- Crew Quarters
- Hangar Space
- Maintenance Space
- Maintenance Storage
- Fuel Storage
etc.

Instead of having to research or having available 6 different fixes sizes, I think it would make more sense to be able to tell the program how much it should add to the ship and the overall size and material use of that module is calculated based on that size.

Larger fuel modules (for example) are more efficient in terms of cost while you may want multiple smaller modules to allow for redundancy.  Otherwise life support or fuel could be lost all at once.  The variation is to allow player choice.  BTW I think for C# the smaller life support systems are all available without research (not at home at the moment so can't check).
Why not instead have both a number for how many tanks its held in? I. E set the fuel to 1. 5 million tons in 6 tanks, with each tank taking up equal space and holding equal amounts of fuel.  Perhaps even have a field for smaller tanks, if you really want too.
That way leads to unrepresentable fractional numbers, which are best avoided.  On the other hand, specifying the number of tanks and the number of liters per tank would work nicely.  An HTK option like we have for magazines, representing compartmentalized or self-sealing tanks would work, too.

Armor and crew quarters for now just nicely round any fractional numbers. I would go on and propose to overhaul the interface for designing ships, instead of clicking items many times, add to each row a number field where you can type in a number. For launchers, beams, fire controls this would simply be the amount requested, while for fuel it could be capacity, or for engineering spaces the desired maintenance time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tuna-Fish on July 31, 2018, 02:04:21 PM
Larger fuel modules (for example) are more efficient in terms of cost while you may want multiple smaller modules to allow for redundancy. Otherwise life support or fuel could be lost all at once. The variation is to allow player choice. BTW I think for C# the smaller life support systems are all available without research (not at home at the moment so can't check).

The only kink in this is that due to the way the game handles 0htk components, all of the smaller-than-s1 components are both more expensive and make your ship weaker. Would it be possible to make them somehow less of a liability to keep the tradeoff between expensive but more durable vs cheaper but more fragile?

Giving them all 1 htk would probably make it too easy to flood your dac with expendable stuff. Would some kind of fractional htk system work?
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on July 31, 2018, 05:14:26 PM
Just a minor suggestion, "Conventional Steel" should probably be called Rolled Homogeneous Armour (RHA) as that is more specific and technical and perhaps the middle conventional armour tech can be Explosive Reactive Armour (ERA) with the top tech being Composite Armour before we get to duranium (though those two are more debatable and there's probably not too much of a problem with "composite" and "advanced composite").
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on July 31, 2018, 11:59:11 PM
Quote from: Steve Walmsley link=topic=9841. msg109141#msg109141 date=1532959461
Quote from: TMaekler link=topic=9841. msg109140#msg109140 date=1532957911
Variable size for stuff like:
- Crew Quarters
- Hangar Space
- Maintenance Space
- Maintenance Storage
- Fuel Storage
etc.

Instead of having to research or having available 6 different fixes sizes, I think it would make more sense to be able to tell the program how much it should add to the ship and the overall size and material use of that module is calculated based on that size.

Larger fuel modules (for example) are more efficient in terms of cost while you may want multiple smaller modules to allow for redundancy.  Otherwise life support or fuel could be lost all at once.  The variation is to allow player choice.  BTW I think for C# the smaller life support systems are all available without research (not at home at the moment so can't check).
Why not instead have both a number for how many tanks its held in? I. E set the fuel to 1. 5 million tons in 6 tanks, with each tank taking up equal space and holding equal amounts of fuel.  Perhaps even have a field for smaller tanks, if you really want too.
That way leads to unrepresentable fractional numbers, which are best avoided.  On the other hand, specifying the number of tanks and the number of liters per tank would work nicely.  An HTK option like we have for magazines, representing compartmentalized or self-sealing tanks would work, too.

Armor and crew quarters for now just nicely round any fractional numbers. I would go on and propose to overhaul the interface for designing ships, instead of clicking items many times, add to each row a number field where you can type in a number. For launchers, beams, fire controls this would simply be the amount requested, while for fuel it could be capacity, or for engineering spaces the desired maintenance time.
Desired maintenance time isn't the only consideration.  For example, some of my survey/recon ships have short rated maintenance times because they don't have enough MSP to repair their sensors, but the AFR is low enough they usually get back for overhaul before they actually experience a failure.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on August 01, 2018, 12:29:47 PM
Desired maintenance time isn't the only consideration.  For example, some of my survey/recon ships have short rated maintenance times because they don't have enough MSP to repair their sensors, but the AFR is low enough they usually get back for overhaul before they actually experience a failure.
It is not about if maintenance times catches all aspects, it is about what parameter is the most convenient to control. 12 months maintenance time tells you something, 5 engineering spaces may be anything or nothing. Similar to how you want to control the number of armor layers rather than the total amount of armor.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on August 01, 2018, 12:57:26 PM
Just a minor suggestion, "Conventional Steel" should probably be called Rolled Homogeneous Armour (RHA) as that is more specific and technical and perhaps the middle conventional armour tech can be Explosive Reactive Armour (ERA) with the top tech being Composite Armour before we get to duranium (though those two are more debatable and there's probably not too much of a problem with "composite" and "advanced composite").

A counterpoint:

I am very strongly in favour of all non-TNE tech retaining (or gaining) the word "conventional" in its name.  "Conventional Rolled Homogeneous Armour" might be too long.  I would suggest Conventional Homogeneous, or Conventional Reactive, or Conventional Ferro-Ceramic.
Title: Re: C# Aurora v0.x Suggestions
Post by: Shuul on August 01, 2018, 05:54:33 PM
Hi Steve, I have a suggestion, but im not sure if it was proposed already some time ago.
It always looked a bit strange for me that meeting aliens all we can do is diplomacy, so I think that it would be great that, lets say, after meeting aliens "Tau" we will get some custom research project.
Possible projects:
Tau ship design - shows up after first ship seen and helps identify their ships better, or even prohibits full identification until researched
Tau physiology - appears after first tau are either captured/killed in ground combat or when trading agreement is reached. Can give some modifier for fighting them or just provide some insights for diplomacy.
Tau Culture - appears after good relations are established, increases diplomacy rating.
Tau technology - appears after first tau ship salvaged - gives more info on ships and maybe some bonuses to other staff.

etc. many things can be done here.

I believe this will enrich interaction methods with NPR.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on August 01, 2018, 06:07:44 PM
How about a mobile refit module that can repair ships?
x1 Mobile Refit Module = 1,000 Tons Maximum
They also need a cargo hold (can be itself or another ship in the taskgroup) to hold the minerals for the refit/repair.  They can also repair ship wrecks. 
That brings me to my second suggestion, how about tugging wrecks to a shipyard or mobile refit ship to repair them? You'd have to salvage atleast one ship of the class to repair a wreck.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on August 03, 2018, 05:42:22 AM
For roleplay reasons would it be nice if the SpaceMaster could add and remove special events to certain colonies. Events which could decrease or increase several values of the planet (like unrest, dust, radioactive fallout, composition of atmosphere).
Title: Re: C# Aurora v0.x Suggestions
Post by: snapto on August 03, 2018, 01:03:08 PM
It would be great to have an indication of the lift capacity needed to move each installation - especially with the new and existing installations that we will now be able to move. It looks like the lift capacity for the new land units are provided but I didn't see anything similar for installations. Maybe in the mineral requirements for each installation on the industry tab?  Cheers.
Title: Re: C# Aurora v0.x Suggestions Tractor Beams
Post by: SimonS3 on August 03, 2018, 02:03:39 PM
Not sure if anyone has discussed this before ( actually I am sure they have but I can't find it ;) ) but I rely very heavily on tugs in my universe to move around  Mining, Defense, and Terra-forming platforms, what would be great is if you could link up multiple tugs to a larger platform and use their combined thrust to move larger units faster ( moving my Terra-forming Orbital habitats  takes forever :) )

cheers 
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on August 06, 2018, 12:51:52 PM
How about building Ring Worlds like in Halo?
Title: Re: C# Aurora v0.x Suggestions
Post by: Frank Jager on August 06, 2018, 01:23:27 PM
As for crew requirements.

Further down the line could we have computer effeciency ylyechs which reduce the amount of crew needed, while making the ship exorbitantly expensive.

We could then make things like the Honorverses Recon Drones and Missile Pods, which don't have any crew at all but can be retargeted and flown like an Aurora ship.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on August 06, 2018, 03:14:50 PM
How about actual rebellion that happens at 100% unrest.   Each ground unit has a 20% of becoming a rebel.  The space units also will have rebellion action on it, kinda like boarding.  And the rebellion will cause slight unrest throughout your colonies.   .
Title: Re: C# Aurora v0.x Suggestions
Post by: Peroox on August 06, 2018, 04:06:10 PM
Quote from: Frank Jager link=topic=9841. msg109255#msg109255 date=1533579807
As for crew requirements.

Further down the line could we have computer effeciency ylyechs which reduce the amount of crew needed, while making the ship exorbitantly expensive.

We could then make things like the Honorverses Recon Drones and Missile Pods, which don't have any crew at all but can be retargeted and flown like an Aurora ship.

For now you can only create a missile drone.  It will be fine to create a system of no crew ship that can be hacked by enemy if discovered.  Then stealth technology will be even more important, because that drone can be very small, and with new sensor system that have much more sense.  And also more electronic warfare :)

P. S For roleplay AGI civilisation it could be technology that make ship less depends on robots/cyborgs. 
Title: Re: C# Aurora v0.x Suggestions
Post by: SimonS3 on August 06, 2018, 10:08:32 PM
Quote from: Peroox link=topic=9841. msg109257#msg109257 date=1533589570
Quote from: Frank Jager link=topic=9841.  msg109255#msg109255 date=1533579807
As for crew requirements. 

Further down the line could we have computer effeciency ylyechs which reduce the amount of crew needed, while making the ship exorbitantly expensive. 

We could then make things like the Honorverses Recon Drones and Missile Pods, which don't have any crew at all but can be retargeted and flown like an Aurora ship. 

For now you can only create a missile drone.   It will be fine to create a system of no crew ship that can be hacked by enemy if discovered.   Then stealth technology will be even more important, because that drone can be very small, and with new sensor system that have much more sense.   And also more electronic warfare :)

P.  S For roleplay AGI civilisation it could be technology that make ship less depends on robots/cyborgs. 
   I actually use Drones and missile pods, remove everything from a fighter hull and stick a big passive sensor on it , then set it deployment time to 200 months and you have an early warning drone you can deploy anywhere without getting spotted easily ( just put it some distance away from anything so nothing fly's to close.  same with missile pods remove the engines from a fighter, put the deployment time to 200 again  and if you deploy tractors to your ships you have a missile pod,  could also make variants like Missile defense pods etc.   and keeping them small you can take advantage of your fighter production resources. .  :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Frank Jager on August 07, 2018, 05:04:09 AM
I actually use Drones and missile pods, remove everything from a fighter hull and stick a big passive sensor on it , then set it deployment time to 200 months and you have an early warning drone you can deploy anywhere without getting spotted easily ( just put it some distance away from anything so nothing fly's to close.  same with missile pods remove the engines from a fighter, put the deployment time to 200 again  and if you deploy tractors to your ships you have a missile pod,  could also make variants like Missile defense pods etc.   and keeping them small you can take advantage of your fighter production resources. .  :)

While I actually use missile bouys in a seperate missile bus and your idea is a solid "workaround" I would still like to use fighter factories to actually produce fighters while continuing to use ordanamce factories to make my ordanamce including things like drones.
From an RP perspective your reconfigured fighters still use crew, which is another resource I would rather use on ships and fighters because I run with maximum crew training rate, which produces better crew grades and reduces the pool of crew available. It also means that you have a bunch of those crew members stuck on pods and drones that can't then be used elsewhere. You could force those designs to use conscripts and not touch the pool but it still seems wierd that a drone ejects lifepods on destruction. You also need fighter bays to deploy those missile pods and drones instead of magazine space. Meaning that my parasite capacity is all forms of screwed up.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on August 07, 2018, 10:23:12 AM
I really like the idea of better control over mines if just to avoid the horrible micro management of trying to set up tons of waypoints to try and force mines to trigger in a difference pattern to all at once. Perhaps just giving them some parameters about what to target would be a balance v full control.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on August 10, 2018, 04:10:43 PM
I think that DSTS should require one million population per installation.  As it stands you can, for very little cost, get almost complete ckverage of everythkng important.  Making it so you can't just plop them on an asteroid makes sense for pickets actually useful while maintaining the home turf advantage you get from full DSTS coverage in established systems.  You can still make the outposts but it would no longer be invisible or almost free to do, but intelligence becomes harder to come by and more involved without adding much micro at all.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on August 10, 2018, 04:57:24 PM
How about bigger Railguns to get weapons like the MAC gun from Halo?
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on August 10, 2018, 05:24:41 PM
I think that DSTS should require one million population per installation.  As it stands you can, for very little cost, get almost complete ckverage of everythkng important.  Making it so you can't just plop them on an asteroid makes sense for pickets actually useful while maintaining the home turf advantage you get from full DSTS coverage in established systems.  You can still make the outposts but it would no longer be invisible or almost free to do, but intelligence becomes harder to come by and more involved without adding much micro at all.

I don't think this makes sense. Why not just make DSTS less effective?

I'd actually think it'd be interesting to make sensors in general less effective across the board. Mid-tier sensors can sweep half a system
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on August 10, 2018, 07:07:03 PM
I think that DSTS should require one million population per installation.  As it stands you can, for very little cost, get almost complete ckverage of everythkng important.  Making it so you can't just plop them on an asteroid makes sense for pickets actually useful while maintaining the home turf advantage you get from full DSTS coverage in established systems.  You can still make the outposts but it would no longer be invisible or almost free to do, but intelligence becomes harder to come by and more involved without adding much micro at all.

I don't think this makes sense. Why not just make DSTS less effective?

I'd actually think it'd be interesting to make sensors in general less effective across the board. Mid-tier sensors can sweep half a system

They are less effective in C# Aurora.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on August 10, 2018, 09:53:13 PM
Can you have higher racial training levels cause less recruits, because I don't know why you'd ever want it on anything other than 5 if it gives you the best stuff for the same amount of recruits. It wouldn't make sense for the same amount of soldiers to pass into the navy/army either if the training is more difficult. Thats why there are fewer Special Ops than regular soldiers.
Title: Re: C# Aurora v0.x Suggestions
Post by: DIT_grue on August 11, 2018, 01:01:30 AM
Can you have higher racial training levels cause less recruits, because I don't know why you'd ever want it on anything other than 5 if it gives you the best stuff for the same amount of recruits. It wouldn't make sense for the same amount of soldiers to pass into the navy/army either if the training is more difficult. Thats why there are fewer Special Ops than regular soldiers.

... But it always has reduced recruitment? Off the top of my head, I think it's (1000 divided by Training Level) crew per Academy.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 11, 2018, 01:22:51 AM
I suppose I could see a bell curve sort of deal where the reduction in crew output is much more drastic for the higher levels, to sortof vaguely model how competency tends to be distributed.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on August 11, 2018, 11:54:16 AM
Huh... I stand corrected, thanks.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on August 13, 2018, 06:14:17 AM
Shields are great. They regenerate on their own, you always have to shoot through the ENTIRE shield before doing any damage to the ship (as opposed to X layers) and they don't get bigger as your ship does.

The downsides are a consumption in fuel - negligible in a combat situation and a massively reduced HP/HS compared to armor. Even if you can just detect when you are in combat and switch shields on, their fuel use can be reasonably easily compensated for. The issue is, the efficiency of early shields (Alpha/Beta) is so bad that they simply are not worth putting on any ship when additional armor of similar weight adds far, far more effective hits to the ship. However, the HP/HS efficiency of shields cannot be increased because it competes directly with armor and is very likely to make armor obsolete if it has sufficient efficiency.

I propose adding a "thickness" attribute to shields and making that the primary increase in tech. Alpha = 1, Beta = 2, etc. Thickness would indicate the maximum amount of damage that the shield can absorb from a single hit. All excess damage would spill over and strike the armor.

Example:
Beta shields with 12hp.
Attacked by Laser doing 4 damage.
Beta shields take 2 damage = 10hp left.
Armor takes 2 damage in laser damage pattern.

Gameplay benefits:
- Better synergy with armor: Trimming 2 damage off 6 hits is better than stopping 3 hits fully and then taking full damage from the other 3 for the purposes of preventing armor penetration, even though the same amount of total damage gets through.
- Shield efficiency of HP/HS can now be safely increased to the point where it is viable without making armor obsolete as it no longer fulfills the same purpose as armor.
- As HP/HS is no longer the primary technology driver, the improvement with new techs can be made more gradual.
- Shield efficiency (HP/HS) can be split out into a seperate tech tree running parallel with existing shield tech
- Gives more options for designing shields
- Gives incentives to build non-square missile warhead numbers (square + shield pen amount)
- This is a defence system that is more effective against AMM spam and less effective against larger ASMs instead of equally effective against both (current shields) or the reverse (AMMs and CIWS)
- This follows in the line of the "shock damage" mechanic introduced to encourage larger warheads.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on August 13, 2018, 04:17:16 PM
Rabid_cog, there have been some changes to shields already. They no longer consume fuel, and are now variable in size, with larger shields getting improved shield points per HS.

I like the idea of leaky shields, primarily as it does require them to be combined with armor, and also I would like if both sides in an engagement take some damage, and one side does not come off entirely intact due to shielding. So making it damage mitigation instead of damage prevention helps there.
However I don't see the first levels being not very useful as too big a downside. Some technologies coming in as they advance is quite nice.
Overall you still need to change SP per HS as tech increases to keep up with armor, else it is too powerful or useless at one end of the tech tree or the other.
Further, basing penetration entirely on tech is not desirable, as currently shields are a 'big ship' toy. They get linear scaling in shield thickness, compared to x^2/3 of armor thickness. They should still get an advantage of mounting large, heavy shielding compared to tiny ships mounting just a single shield. However if you instead had a penetration depth of SQRT(SP/5), where SP are the max number of SP on the ship (only working shield generators) you would get a shield that does again require a significant hull to be effective.
Title: Re: C# Aurora v0.x Suggestions
Post by: CheaterEater on August 14, 2018, 11:06:52 AM
How about instead of shield levels reducing damage, shields could act like armor instead. Shield points would be distributed over the armor like layers, just as armor is. So if e.g. you have 30-wide armor (of however many layers) and 60 shield points, you would have a 2 layer deep shield on top of the armor. As the shield layers get damage they would fill in gaps but the overall depth would be reduced. If a layer is incomplete the partial layer could recenter onto the incoming damage, or it could be a random distribution of extra shield points (e.g. 30-wide armor, 10 shield points, then each box has a 1/3 chance to be filled subject to summing to 10 boxes).

I think this would be fairly intuitive, and you can just look at your ship's armor stat and see that there are X many layers of shield on top of the armor. This would also make shields better versus small damage weapons (AMMs, gauss) and worse against high-damage and high-penetration weapons (big missiles, lasers). It also has the benefit of graduated  leaking as your shield loses more points and more damage makes it through.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on August 14, 2018, 11:21:11 AM
Perhaps not a bad idea for the functionality of the damage reduction, actually. Instead of using max SP, use remaining SP as a function of ship size to determine damage stopped. Of course that changes shields from being a Big Ships tool to being something usable on all ships.

I guess I just generally like the idea of shields not competing with armor for defensive ability, but that there is some synergy between the two that makes it advantageous to put both on your ship.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on August 14, 2018, 01:25:35 PM
Perhaps not a bad idea for the functionality of the damage reduction, actually. Instead of using max SP, use remaining SP as a function of ship size to determine damage stopped. Of course that changes shields from being a Big Ships tool to being something usable on all ships.

I guess I just generally like the idea of shields not competing with armor for defensive ability, but that there is some synergy between the two that makes it advantageous to put both on your ship.
That makes shields way too similar to armor. They would need a massive buff in efficiency to make up for the loss of protective ability at low strength, putting them in conflict with armor.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on August 14, 2018, 03:01:43 PM
What if you combine the leaking shield concept with the way it works now?  Shields would deteriorate as they get hit, and as they deteriorate they absorb less and less damage per hit.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on August 14, 2018, 03:27:19 PM
What if you combine the leaking shield concept with the way it works now?  Shields would deteriorate as they get hit, and as they deteriorate they absorb less and less damage per hit.
I am afraid that makes them too similar to armor. Also, with leakage determined by FULL shield strength, HTK of shield generators become important. Getting a hit through that causes shock damage blowing up a shield generator would be the reason to mount redundant generators. Also, I'd rather have consistent leakers instead of a cliff edge where you either beat shield regen, and break the shield to nothing or do only superficial damage because the shield stays at close to full strength.
Having a higher rate of leakers but independent of current shield strength ensures the stronger party takes some damage as well, which is what the leakers should mostly accomplish.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on August 15, 2018, 04:51:19 PM
What if you combine the leaking shield concept with the way it works now?  Shields would deteriorate as they get hit, and as they deteriorate they absorb less and less damage per hit.
I am afraid that makes them too similar to armor. Also, with leakage determined by FULL shield strength, HTK of shield generators become important. Getting a hit through that causes shock damage blowing up a shield generator would be the reason to mount redundant generators. Also, I'd rather have consistent leakers instead of a cliff edge where you either beat shield regen, and break the shield to nothing or do only superficial damage because the shield stays at close to full strength.
Having a higher rate of leakers but independent of current shield strength ensures the stronger party takes some damage as well, which is what the leakers should mostly accomplish.

I disagree that this makes it too much like armor.  As has been brought up in discussions, a shield covers the entire ship, how penetrating or widespread the weapon's damage pattern is doesn't matter to a shield, which means that weapons that operate one way against armor operate differently against shields that deteriorate, whereas with consistent leaky shields, it's just a dampener on the damage done to the armor.

Leaky shields makes HTK on shield generators matter, full stop.  Damage that leaks through and disables a shield generator would weaken or disable the shield.  Whether the shield also deteriorates doesn't really affect that.  Additionally, not being able to beat the shield regeneration only results in superficial damage if the shield is of a certain strength.  At that strength, a shield that doesn't deteriorate would ALSO result in superficial damage.

Being the stronger party does not automatically mean deteriorating shields would prevent anything more than superficial damage.  That is also determined, among other things, by how much damage the shield blocks.  In fact, if shields do not deteriorate, then depending on how strong they can be made, it could be very much possible to make a "leaky" shield that prevents anything other than superficial damage when facing a weaker opponent, with the enemy simply not able to put out enough damage to do more than dent your armor, and thus having no ability to damage the shield generator (other than mesons, mesons, which some NPR's very likely won't use, based on how Steve is designing them).  If the shield also deteriorates, however, that gives the weaker side the ability to still whittle down the shield until significant damage is passing through.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 15, 2018, 10:24:33 PM
On the one hand, I don't particularly agree with the notion shields should be 'balanced' with armor, why is that in any way desirable?  Things change as tech advances, is that not both expected and fine?  Why should late and early game ships be virtually identical in terms of tradeoffs and general design except with bigger numbers?

On the other, I do like the general concept.  You could have a much more complicated idea of shielding, for instance 'thickness', 'regeneration', and 'capacity' characteristics.  You have shield generators that keep the shields charged, which are very expensive and bulky, capacitors which are relatively cheap and light weight and determine the maximum amount of damage the shields can block without regeneration, and projectors that add layers to the shield and set a maximum amount of damage the shields can block before it punches through.

Perhaps the shields lose points equal to (ship mass / 1000) * thickness, so each projector leaks a certain amount of energy depending on ship size and adding more projectors means stronger shields that require more generators to keep them going even under nominal conditions.

The above rules for shield leakage are pretty made up and arbitrary and mainly meant to allow for the idea of generators as a separate component from the rest of the shielding apparatus so a generator gets blown up but the shields dont fail right away.  Overall this sounds kindof fun to me, if potentially being a bad idea to add in at this stage.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on August 16, 2018, 03:46:07 AM
Frankly, I like shields as they are.
I completely dislike the notion of "leaky" shields. I can't think of a single sci-fi setting I liked that had "leaky" shields like that.

The concept of shields, to me, is that you have to go through them completely. The moment shields get "leaky", I'll stop using them completely. I am not interested in having some piece of garbage component over my ships that can get "leaky" and stop less and less damage over time. That is called taking a chance, and I don't with my ships.

The tradeoff with shields has always been that they give you less bang for your bucks compared to armor in terms of mass etc. BUT, unlike armor, they can be applied anywhere the damage goes. And they get better once you actually tech up a lot.
What's wrong with that? It makes perfect sense that you move from a "low tech" solution (armor) to a "very high tech solution" (shields) as your technology improves by leap and bounds.

Also, since when did Aurora need to make sure that fleets should be able to do some damage even against more technologically advanced fleets? If your tech is so far behind that you can't break through your enemy's shields, that's your fault for being behind. I don't get why THAT bothers people.

Space is NOT fair. It's cold, dark, and if you are weak you die. I see no reason why Aurora needs to ensure that both sides in an engagement take some damage. If you are the weak nation in a conflict, you die screaming.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on August 16, 2018, 07:07:34 AM
For a ship of a fixed size with a fixed amount of HS devoted to defence, shields and armor compete for the same hull space. This is not a conditional, they do at all times. They both perform the same function, which is to say keeping your ship alive.

Any given HS of Armor's contribution to the effective number of hits we can take without dying or being crippled is a function of ship size (bigger is generally worse) and the the penetration of the enemy hits (so their damage profile) with shallower damage profiles being better and deeper damage profiles being worse. And of course a technology based armor efficiency constant.
Armour absorption = f(ShipSize,Penetration)*Tech(Armor)

Any given HS of Shield Generator's contribution to the effective number of hits we can take without dying or being crippled is a function of a combination of time between attacks and regeneration speed, but restricted to a certain minimum (shields have 0 time to regenerate) and a certain maximum (shields regenerate to full in between volleys), both based on a technology based efficiency variable.
Shield absorption = g(TimeBetweenAttacks,RegenerationSpeed)*Tech(Shield) with g() being constrained as mentioned above.

(Shipsize is fixed under our assumptions. RegenerationSpeed is also related to technology and can therefore be assumed to be fixed for a given technology level. Penetration is under our enemy's control, but also depends on combat distance, etc. Regardless, we can figure out a general damage profile we want the maximum defence against (2-3 penetration earlier on, with more later) and we know attacks will likely hit one of the two extremes for g(): too fast to regenerate (Beams/AMMs) or slow enough to allow full regen (ASMs).)

Note that neither value depends on either how much shield or armor you already have. That means that if you have 2 HS available for defence, and your calculations reveal that for the 1st HS, Armor is a better option, then for the 2nd HS armor will STILL be a better option since none of the factors changed. If anything, shield synergizes slightly with itself.

In summary, it doesnt actually matter which one of these win in any given situation. The point is that ONE OF THEM WINS. And either Shield Absorption is always better, or Armor Absorption is always better and it only depends on your tech level.

The reason "Leaky shield" overcomes this, is it makes the value of armor related to the number of shield layers you have (penetration becomes penetration - shield layers) and shield value related to the amount of armor you have (your shield only has value if you dont DIE before it is fully depleted). The optimal solution is therefore moved away from the extremes, towards the centre of a combination of shields and armor for defence which, and this is purely my opinion and you are welcome to disagree, I feel leads to more interesting gameplay decisions.



Title: Re: C# Aurora v0.x Suggestions
Post by: wedgebert on August 16, 2018, 05:18:09 PM
Why not just have two types of shield generators? The current ones and ones that have a higher strength but let some damage leak through?
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 16, 2018, 09:15:08 PM
I kind of think people threatening to never use the different shield concept because they 'dont take chances' shouldn't really be a huge factor in whether to make them that way or not.  If they actually aren't worthwhile steve could just make them cheaper in mass and resouces to balance them.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on August 16, 2018, 11:38:58 PM
Why not just have two types of shield generators? The current ones and ones that have a higher strength but let some damage leak through?
The buffering effect of reducing strikes means the leaky shields will be more survivable. 10 half strength hits do much less damage to armor than 5 full strength ones in armor penetration.
You take more armor damage early on in an engagement, but your shields last longer, and each individual hit is weaker, so your armor gets sandblasted at first. So if your ship has some armor to soak up the leakage, the leaky ones are strictly superior.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 16, 2018, 11:45:41 PM
Thats also a good point.
Title: Re: C# Aurora v0.x Suggestions
Post by: Peroox on August 17, 2018, 04:41:22 AM
Still we need both.  If someone want to use shielded fighter/FAC he rather choose current one.  More choice = more interesting game.  Thing is to make both choice viable and easy to do. 
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on August 17, 2018, 06:56:28 AM
Like the idea of a mix of shields but would want to make sure there is no simple optimal solution so that every race just moves to that position as it takes a lot of the diversity out of the game and removes some of the scope to have different flavours of AI / race type. I think pure armour should be just as feasible as pure shields or a mix of both in much the same way you don't want a single weapon system dominating the game.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on August 18, 2018, 07:20:31 AM
What do you think about the ability to equip fighters with different payload? Like you can do in real life. So one would be able to us a plane depending on the situation it would be needed for..
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on August 18, 2018, 09:03:33 AM
What do you think about the ability to equip fighters with different payload? Like you can do in real life. So one would be able to us a plane depending on the situation it would be needed for..

As far as I am aware,this is the current thinking on fighters in relation to ground combat (where different roles are relevant): http://aurora2.pentarch.org/index.php?topic=9792.msg106084#msg106084

Unless I've missed something this is still the idea for ground support roles. If you mean being able to swap out the missile launchers on a fighter for lasers or whatever on a whim then that is something else (not something I'd be in favour of personally).
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 18, 2018, 12:57:23 PM
I think reactors probably shouldn't be possible to put into a pod, but it might be fun to put lasers, missiles, sensor, EW, or fire control pods onto fighters interchangeably.  It would also be more or less consistent with modern multiroles to some extent, which also tend to do that sort of thing.

Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on August 18, 2018, 03:45:25 PM
I think reactors probably shouldn't be possible to put into a pod, but it might be fun to put lasers, missiles, sensor, EW, or fire control pods onto fighters interchangeably.  It would also be more or less consistent with modern multiroles to some extent, which also tend to do that sort of thing.
That does not make much sense, a single laser is already 3HS, which is a massive investment in tonnage. A laser mount on a fighter is more a spinal mount than an underwing gunpod. Also, how would you penalize flexible mounts compared to permanent ones, and what is there left to design on a fighter but the engine?
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 18, 2018, 05:44:28 PM
Make the modular pods take up more room, and have pod components not be behind the ships armor.

Other than that, you'd also have to design reactors for fighters generally speaking.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on August 19, 2018, 01:55:00 PM
Loadout flexibility on real-world combat aircraft is mostly limited to mounting different kinds of bombs, missiles, and enhanced sensor packages, not interchangeability between bomb/missile and cannons or machine guns, or between machine guns and large-caliber autocannons. This is a level of flexibility that standard box launchers already have in Aurora.

It's not that you couldn't in principle mount a machine gun on a missile hardpoint - the interfacing itself is not that difficult an engineering problem - but an airframe optimized for missile combat is going to suck at strafing and vice versa. People who try to build an airframe that can cater to both air superiority, installation strikes, and close air support tend to come to grief. (Or rather, the people who pay for the experiment do - the people who build it usually do quite well out of the project...)
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 19, 2018, 04:16:06 PM
I could point to the harrier for instance to show that to be not particularly true: https://en.wikipedia.org/wiki/GAU-12_Equalizer

Both better sensors and various kinds of weapons have been put onto multirole fighters for ages.  Yes a given aircraft is generally specialized to some degree, but they still have some ability to mount gun pods, sensor pods, EW pods, and various kinds of missiles and bombs.  The whole value of multiroles is your air superiority aircraft can help out with air strikes, and thusly you can have more capability in both roles by having more flexible aircraft.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on August 19, 2018, 10:53:10 PM
But Harrier is a terrible fighter plane and was mainly used due to its VTOL capability, that allowed "mini-carriers" to ferry them to combat zones. The plane lacks an integral gun and thus the need to carry a gun-pod like the Equalizer. So it kinda proves the point Scandinavian was making.

The space weaponry is so, so, so much larger in Aurora when compared to air-to-air or air-to-ground weaponry in current use, that the swappable pod concept for fighters in space combat really doesn't fly. I'll use the Equalizer as an example: it weights 122 kgs and a Harrier weighs 6,340 kg. That's less than 2%.

Even the smallest lasers (10cm Focal Size) are 150 tons. With Reduced-size you can bring it down to 100 tons but then you have to accept quadrupled recharge times. That's still 20% of your 500 ton fighter, or even a higher percentage if you're making a faster interceptor-type fighter. To me, swapping something that is twenty percent of the mass of a fighter does not sound doable. Even the B-52, that could carry 31 tons of bombs, couldn't just swap those bombs with some other weapon, because it was purpose-built to carry bombs in its cavernous bomb bays and nothing else.

So replacing weapon pods for ground support sounds reasonable and that's already in. Swapping space combat weapons like pods does not sound reasonable, as long as we're using current sizes (and if lasers or box launchers can suddenly be miniaturized even further, it has serious ramifications to ship-to-ship combat too).
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 19, 2018, 11:01:08 PM
I'd point out the lower laser size limit is totally arbitrary at the moment.  I do however agree that something like that in particular souldn't be swappable for a fighter sized thing.

Also, the equalizer was a perfectly effective weapon (it let the thing destroy tanks for heck sakes), and the harrier was quite useful for the fact that it was very flexible, despite its overall low speed.  It performed fine in the Falklands war for instance.

I could see lasers as they are now not being particularly swappable for fighter sized things, but that doesn't mean hardpoints shouldn't be possible period.  It would be terrible if it was a system that only applied to fighter sized vessels arbitrarily, so lasers could easily just only be swappable for much larger vehicles.  And then fighters have reduced multi mission capability purely off of the fact they are so small.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on August 20, 2018, 09:24:35 AM
I'd point out the lower laser size limit is totally arbitrary at the moment.  I do however agree that something like that in particular souldn't be swappable for a fighter sized thing.

Also, the equalizer was a perfectly effective weapon (it let the thing destroy tanks for heck sakes), and the harrier was quite useful for the fact that it was very flexible, despite its overall low speed.  It performed fine in the Falklands war for instance.

I could see lasers as they are now not being particularly swappable for fighter sized things, but that doesn't mean hardpoints shouldn't be possible period.  It would be terrible if it was a system that only applied to fighter sized vessels arbitrarily, so lasers could easily just only be swappable for much larger vehicles.  And then fighters have reduced multi mission capability purely off of the fact they are so small.

I'd like to point out that  any change in minimum beam weapon size will be immediately picked up as PD weapon. There it likely has a larger impact than for beam fighters.
The entire hard point system seems overly complicated, all these things need to be separately produced, stored in magazines... We already have refits to make small modifications. We could add a refit module that allows very limited refits away from a population, assuming all required components are available, the refit is cheap enough.
That way you avoid all the additional overhead of hard points, and dealing with items outside armor, and what exactly can be placed there.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on August 20, 2018, 10:54:01 AM
The discussion on training and order delays has had me thinking again about general crew readiness for combat. It's always bugged me that you can have a ship sit on a warp point for three years doing nothing and then suddenly be all guns blazing within the space of a five second increment. That level of readiness just seems odd to me.

I know its something as a player you can just RP by not firing straight away but I'd be interested in seeing some mechanic in the game to address this although accept that for the small number of times it would have an impact it may be a bit much. As to how that could work I was thinking about 2-3 states for the crew to be at that impact delays to initial but not subsequent orders such as:

- Normal Watch: CIWS no delays, beams short delays, missile batteries longer delay, fighter launch etc longest delay - no impact
- High Alert: As above but with no delays on wider range of actions and reduced delays on fighter launch etc - 2 times rate on deployment time
- Red Alert: Basically then just use normal command delays where applicable based on crew training etc - 5 times rate on deployment

So basically if you want to travel you are on normal alert, if you are worried you go to Amber and then its a decision as to when you go to Red Alert. It clearly makes jump point defence more of a logistical challenge and might make the investment in stealth ships more interesting if it means you have a better chance of catching an enemy out. Probably one for the AI to ignore though.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on August 20, 2018, 11:01:05 AM
I'd point out the lower laser size limit is totally arbitrary at the moment.  I do however agree that something like that in particular souldn't be swappable for a fighter sized thing.

Also, the equalizer was a perfectly effective weapon (it let the thing destroy tanks for heck sakes), and the harrier was quite useful for the fact that it was very flexible, despite its overall low speed.  It performed fine in the Falklands war for instance.

I could see lasers as they are now not being particularly swappable for fighter sized things, but that doesn't mean hardpoints shouldn't be possible period.  It would be terrible if it was a system that only applied to fighter sized vessels arbitrarily, so lasers could easily just only be swappable for much larger vehicles.  And then fighters have reduced multi mission capability purely off of the fact they are so small.

I'd like to point out that  any change in minimum beam weapon size will be immediately picked up as PD weapon. There it likely has a larger impact than for beam fighters.
The entire hard point system seems overly complicated, all these things need to be separately produced, stored in magazines... We already have refits to make small modifications. We could add a refit module that allows very limited refits away from a population, assuming all required components are available, the refit is cheap enough.
That way you avoid all the additional overhead of hard points, and dealing with items outside armor, and what exactly can be placed there.

The only thing I would suggest is a fuel tank variant of a missile. Build it as a normal missile and equip it then have total fuel capacity added to your fighter for a way to vary range but trade off firepower. Just a shame that Aurora does not track used ordnance to deal with the changes in speed.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on August 20, 2018, 02:23:16 PM
As far as I am aware,this is the current thinking on fighters in relation to ground combat (where different roles are relevant): http://aurora2.pentarch.org/index.php?topic=9792.msg106084#msg106084

Unless I've missed something this is still the idea for ground support roles. If you mean being able to swap out the missile launchers on a fighter for lasers or whatever on a whim then that is something else (not something I'd be in favour of personally).
This cover most of what I was thinking about. Happy...
One point which was included also in my thoughts was the ability to have fighters which can change ordonance Koadjutors for ‚normal‘ battle usage ase in VB6 aurora. At the moment everything is limited to the size of the missile launchers. So if I would want a multi combat role fighter I would have to design every missile fitting to one launcher size. What I would like to have added would be an option to load for example
a) either 9 S6 missile for space to space combat (total of 54)
b) or 4 S13 missiles for space to ground bombardment (total of 52)
when using box launchers.
So with a S6 box launcher (because they are mounted on the outside of the ship), it would also be possible to mount a lesser number of missiles which could be bigger in size, up to the sum of all box launchers x number of them (54 in the example above, 9 x 6).
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on August 20, 2018, 03:23:33 PM
I'd point out the lower laser size limit is totally arbitrary at the moment.  I do however agree that something like that in particular souldn't be swappable for a fighter sized thing.

Also, the equalizer was a perfectly effective weapon (it let the thing destroy tanks for heck sakes), and the harrier was quite useful for the fact that it was very flexible, despite its overall low speed.  It performed fine in the Falklands war for instance.
Oh I completely agree that all the weapon sizes in Aurora are arbitrary, but the system as-it-is seems fairly balanced to me in ship-to-ship combat. Any change to weapon sizes would have far more impact on the far more important aspect of the game (ship-to-ship combat) rather than in fighter combat, and would thus be a major change.

And this is really getting off-topic, but the Harrier really was a terrible plane in air superiority, was only decent in air support role, and the two reasons why it performed as well as it did in the Falklands were that the training levels of Fleet Air Arm pilots was vastly better than their Argentinian counterparts (and before deployment, they got to practice flying against French Mirages) and that the Argentinian planes (especially their Mirage III interceptors) operated at the extreme limit of their range. Oh and the fact that the Argentinian Air Force lacked modern Air-to-Air missiles. Even with such handicaps, the Argentinians kept contesting the air space over Falklands for an impressively long time.

The discussion on training and order delays has had me thinking again about general crew readiness for combat. It's always bugged me that you can have a ship sit on a warp point for three years doing nothing and then suddenly be all guns blazing within the space of a five second increment. That level of readiness just seems odd to me.

I know its something as a player you can just RP by not firing straight away but I'd be interested in seeing some mechanic in the game to address this although accept that for the small number of times it would have an impact it may be a bit much. As to how that could work I was thinking about 2-3 states for the crew to be at that impact delays to initial but not subsequent orders such as:

- Normal Watch: CIWS no delays, beams short delays, missile batteries longer delay, fighter launch etc longest delay - no impact
- High Alert: As above but with no delays on wider range of actions and reduced delays on fighter launch etc - 2 times rate on deployment time
- Red Alert: Basically then just use normal command delays where applicable based on crew training etc - 5 times rate on deployment

So basically if you want to travel you are on normal alert, if you are worried you go to Amber and then its a decision as to when you go to Red Alert. It clearly makes jump point defence more of a logistical challenge and might make the investment in stealth ships more interesting if it means you have a better chance of catching an enemy out. Probably one for the AI to ignore though.
Wow. This is such an great idea and seems fairly easy to implement. Maybe on TG/Fleet basis and not ship basis? Two thumbs up.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on August 20, 2018, 06:42:21 PM
The discussion on training and order delays has had me thinking again about general crew readiness for combat. It's always bugged me that you can have a ship sit on a warp point for three years doing nothing and then suddenly be all guns blazing within the space of a five second increment. That level of readiness just seems odd to me.

I know its something as a player you can just RP by not firing straight away but I'd be interested in seeing some mechanic in the game to address this although accept that for the small number of times it would have an impact it may be a bit much. As to how that could work I was thinking about 2-3 states for the crew to be at that impact delays to initial but not subsequent orders such as:

- Normal Watch: CIWS no delays, beams short delays, missile batteries longer delay, fighter launch etc longest delay - no impact
- High Alert: As above but with no delays on wider range of actions and reduced delays on fighter launch etc - 2 times rate on deployment time
- Red Alert: Basically then just use normal command delays where applicable based on crew training etc - 5 times rate on deployment

So basically if you want to travel you are on normal alert, if you are worried you go to Amber and then its a decision as to when you go to Red Alert. It clearly makes jump point defence more of a logistical challenge and might make the investment in stealth ships more interesting if it means you have a better chance of catching an enemy out. Probably one for the AI to ignore though.

I think there was something on these lines in an early version of Aurora but it was removed. The issue was that the defender needed to keep checking the far side of the jump point with scouts (fighter sized) to ensure they had the right alert level, which added a lot of micromanagement.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on August 20, 2018, 07:58:06 PM
As far as I am aware,this is the current thinking on fighters in relation to ground combat (where different roles are relevant): http://aurora2.pentarch.org/index.php?topic=9792.msg106084#msg106084

Unless I've missed something this is still the idea for ground support roles. If you mean being able to swap out the missile launchers on a fighter for lasers or whatever on a whim then that is something else (not something I'd be in favour of personally).
This cover most of what I was thinking about. Happy...
One point which was included also in my thoughts was the ability to have fighters which can change ordonance Koadjutors for ‚normal‘ battle usage ase in VB6 aurora. At the moment everything is limited to the size of the missile launchers. So if I would want a multi combat role fighter I would have to design every missile fitting to one launcher size. What I would like to have added would be an option to load for example
a) either 9 S6 missile for space to space combat (total of 54)
b) or 4 S13 missiles for space to ground bombardment (total of 52)
when using box launchers.
So with a S6 box launcher (because they are mounted on the outside of the ship), it would also be possible to mount a lesser number of missiles which could be bigger in size, up to the sum of all box launchers x number of them (54 in the example above, 9 x 6).
You can already do that with MIRVed missiles. You pay an overhead for the missile bus and are limited to having to fire the entire hardpoint at once and at the same target, but those seem like very reasonable kinds of costs. In your example, you'd mount four size 13 boxes and each of them would load either a size 13 bombardment weapon or a size 1 bus wrapped around two size 6 shipkillers. You only get 8 shipkillers instead of the 9 you would get on a dedicated platform, and you have to fire them in pairs rather than singletons. That trades a 12 % reduction in loadout and barely perceptible reduction in targeting flexibility for the strategic flexibility of multiple loadout configurations, which does not seem like an onerous level of trade-off.

You get in trouble when you try to mount AMMs that way, because they need the targeting granularity that you lose when MIRVing them. But AMMs probably shouldn't be interchangeable with shipkillers without taking some non-trivial performance hit.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on August 22, 2018, 12:37:19 PM
When you close the window that selects the game, please don't have it automatically open the default game. If I wanted that game, I would have opened it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Caplin on August 22, 2018, 12:50:39 PM
As per discussion in this thread (http://aurora2.pentarch.org/index.php?topic=10154.0), it would be nice if the intelligence window could maintain a list of previously-detected populations. It stands to reason that populations would be less mobile than ships, and would be the kind of thing any half-competent intelligence staff would keep records about.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 22, 2018, 04:29:40 PM
MIRVS don't really provide that kind of flexibility unless you want to SM in every combo you want as needed.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on August 22, 2018, 05:11:31 PM
MIRVS don't really provide that kind of flexibility unless you want to SM in every combo you want as needed.
That's because you shouldn't be able to strap five missiles onto four hardpoints just because the total mass comes to the same number, unless you go to the trouble of building a custom system like a MIRVed warhead. You can't just wake up in the morning and decide that you want to load fifty Stingers on your missile destroyer instead of the five cruise missiles it's designed for (or eight Sidewinders on your fighter-bomber in place of the two 2000 pound bombs it's designed to carry), just because the total displacement would be the same. What you might be able to do is attach a purpose-built missile pod, but you'd still need to manufacture that pod and get it to your staging area. Effectively a fire-and-forget launch platform wrapped around a number of missiles, which in Aurora would be represented by a two-stage system with multiple warheads.

What you should reasonably be able to do with full flexibility is attach a smaller missile to a hardpoint designed for a larger one, and the box launcher already lets you do that out of the box (you should pardon the, pun) with no need for workarounds.
Title: Re: C# Aurora v0.x Suggestions
Post by: DEEPenergy on August 22, 2018, 05:25:06 PM
Hi Steve, if it's possible could NPR missile firings not reduce the game to 5 second increments? I'm sure there's a reason behind it but I don't like that it gives away what the enemy is doing. 
Title: Re: C# Aurora v0.x Suggestions
Post by: swarm_sadist on August 22, 2018, 08:15:38 PM
MIRVS don't really provide that kind of flexibility unless you want to SM in every combo you want as needed.
That's because you shouldn't be able to strap five missiles onto four hardpoints just because the total mass comes to the same number, unless you go to the trouble of building a custom system like a MIRVed warhead. You can't just wake up in the morning and decide that you want to load fifty Stingers on your missile destroyer instead of the five cruise missiles it's designed for (or eight Sidewinders on your fighter-bomber in place of the two 2000 pound bombs it's designed to carry), just because the total displacement would be the same. What you might be able to do is attach a purpose-built missile pod, but you'd still need to manufacture that pod and get it to your staging area. Effectively a fire-and-forget launch platform wrapped around a number of missiles, which in Aurora would be represented by a two-stage system with multiple warheads.

What you should reasonably be able to do with full flexibility is attach a smaller missile to a hardpoint designed for a larger one, and the box launcher already lets you do that out of the box (you should pardon the, pun) with no need for workarounds.
Why? There is no engineering problem with this. There are even an example of modern nuclear submarines that can carry multiple surface to air missiles packed into a single VLS designed for a ballistic missile. They even have small diametre quad packs of bombs that can go on a single hardpoint for aircraft. Sure a dedicated platform designed to fire those missiles would be much more effective, but a little penalty in mass or loadout is well worth the versatility allowed.

But Harrier is a terrible fighter plane and was mainly used due to its VTOL capability, that allowed "mini-carriers" to ferry them to combat zones. The plane lacks an integral gun and thus the need to carry a gun-pod like the Equalizer. So it kinda proves the point Scandinavian was making.
The harrier was used for two purposes:
1) To give the assault ships and helicopter carriers more "teeth" than helicopters allowed, and to be able to provide bare minimum air superiority in the area and
2) To allow the Royal Air Force to maintain a presence even in heavy mountains, forests, and nuked cities (remember, cold war).

For a first generation VTOL jet with no computer assisted flying, the Harrier did everything needed. It was never going to compete with land based air superiority fighters, not even catapult launched aircraft can compete with a contemporary land based aircraft. Honestly, the Harrier wasn't THAT bad.

Quote
Even the smallest lasers (10cm Focal Size) are 150 tons. With Reduced-size you can bring it down to 100 tons but then you have to accept quadrupled recharge times. That's still 20% of your 500 ton fighter, or even a higher percentage if you're making a faster interceptor-type fighter.
Which is equivalent to a large missile box launcher. Also, pretty sure there are much more extreme reduced-size options available.

Quote
To me, swapping something that is twenty percent of the mass of a fighter does not sound doable. Even the B-52, that could carry 31 tons of bombs, couldn't just swap those bombs with some other weapon, because it was purpose-built to carry bombs in its cavernous bomb bays and nothing else.
Again, why not? A B-52 can carry 31 bombs, or it could carry 60 smaller bombs, or 1 giant bomb, or guided bombs, or standoff bombs with 200 mile range, or cruise missiles with nuclear tips. Hell, pretty sure they have ballistic missiles that can be fired from bombers. Nothing is stopping someone from putting 100 sidewinders in a B-52, there just isn't a reason why you would.

I would like to suggest bomb bays, although I'm sure that has been suggested before.

Hi Steve, if it's possible could NPR missile firings not reduce the game to 5 second increments? I'm sure there's a reason behind it but I don't like that it gives away what the enemy is doing. 
That is because the computer still has to calculate damage and weapon use, even when the player cannot see. If it didn't pause, you could have hour long turns with no feedback into what is happening. Don't worry, I'm sure C# Aurora will be quicker.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 22, 2018, 09:20:06 PM
Swarm sadist made a lot of the points I was going to make moments before reading them in his post.  Hardpoints work exactly in the way that Scandinavian claimed they dont.  In general airframes have a maximum payload weight, which can be split any which way among its hardpoints into various different weapons, so long as the load is balanced and you don't run out of hardpoint space.  I can fully understand the point made earlier about it potentially not being worth the added complexity, but its nonsensical to say you shouldn't be allowed to do it.

(http://runway.cz/img/zbr/aim120_2.jpg)
(https://qph.fs.quoracdn.net/main-qimg-dd835e629652cea10cacec057d179d52-c)
(https://www.globalsecurity.org/military/systems/aircraft/images/fa-18c_navy1390.jpg)
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on August 23, 2018, 12:30:19 AM
@QuakeIV: The biggest problem I see is from a gameplay perspective, what is the difference to box launchers? Box launchers already have a chance to explode on being hit now, making them extremely dangerous to get caught with missiles still unfired.
All you get is a box launcher that no longer cares about size of individual launcher cells. Being outside of armor might make it even better for early fighters, since it reduces the size inside armor, and the armor on these fighters is mostly dead weight anyway. So you just end up with out any interesting trade off for your new system.

You can easily argue with the box launcher containing essential equipment to launch a missile which would not be easily possible at a hardpoint, or starting drives damaging each other if they are not properly shielded from each other, requiring separate cells.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on August 23, 2018, 01:08:59 AM
There are even an example of modern nuclear submarines that can carry multiple surface to air missiles packed into a single VLS designed for a ballistic missile. They even have small diametre quad packs of bombs that can go on a single hardpoint for aircraft. Sure a dedicated platform designed to fire those missiles would be much more effective, but a little penalty in mass or loadout is well worth the versatility allowed.
Yes, there are examples of building a custom weapons package that lets multiple missiles be packed into a single larger tube. This still has to be purpose-built, it's not a minor hot works you can decide to make on the fly as you load the ordnance for deployment.

Quote
Nothing is stopping someone from putting 100 sidewinders in a B-52,
For transportation, sure. But you can also do that with box launchers (they provide full magazine capacity equal to their max missile size).

Quote
I would like to suggest bomb bays, although I'm sure that has been suggested before.
A system that could launch ordnance that doesn't require active targeting, such as buoys or bombs, would make excellent sense. If done right it could also be used to greatly simplify the micro around minelaying. Which is badly needed at the moment.
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on August 23, 2018, 10:53:27 AM
Bear in mind that "fighters" in aurora are still the size of large patrol ships and small corvettes (the only things of their size in the air today are fully laden mega-transports) and serve a function closer to what a patrol boat might rather than a modern fighter. The weaponry that can typically be swapped around on aircraft is generally things like bombs, missiles, external fuel tanks, rockets, things of that nature, things that swap it between an air-to-air role and an air-to-ground role, something that is already represented by ground combat pods as proposed. When you're talking about missiles, you're not talking about a launcher, you're talking about a rail. Yes there's a lot of cross compatibility there because you're swapping the hard points which are just things to which the missile is attached. This is quite a different proposition than launch tubes which is more along the lines of what I think aurora is supposed to represent. Someone mentioned a system that allows for mutliple missiles to be loaded into a single larger tube, but are they really just stuffing a bunch of missiles in a single tube or is there some sort of system, some sort of container, that allows them to be fired that way? Unless I'm mistaken there aren't a lot of hard limits that multi-stage missiles have to be built around in aurora, could you not make something that is essentially just a case that holds several missiles in a larger launcher? Maybe not quite as efficient, but it probably shouldn't be, in fact it's probably not in real life. I might be wrong with that I haven't experimented too much with multi-stage missiles.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on August 24, 2018, 02:07:40 PM
The SSBN's were never intended to be hot-swapped for differing munitions, the subs were pretty much built around a given missile, and would keep it pretty much until the end, not exactly modular.  So naturally, there wasn't a lot of wiggle room in making them functional with another weapon system, so their tubes received a more rigorous re-design to accommodate the tomahawks and wiring to control each.  Enough that they got redesignated as SSGN's, and can't easily return to SSBN duties without similar reworking.   

Mk-41 VLS for US and allied warships however was built with modularity in mind.  Every visit to port could see a different weapon placed in the same cell if there were reason to change it out/reload.  Effectively box launchers coming in sets of 5 or 8 per module, each receiving an encased munition allowing a common interface for multiple weapon types, the wiring and adaptation of the interface to any given munition occurs inside the weapon canister—the ship only ever talks to canisters, the canisters translate/relay to the weapon/ship—, which slots neatly into the cells/"box launchers" and serves as launch tube for the weapon within.   

That brings me to RIM-162 ESSM, those fit four to a canister, and required zero alteration of the Mk-41 vls hardware to accommodate.  They fit into a standard canister, the canister fits the VLS.     On any given voyage they will decide if they will sail with the standard set of munitions, or if they need to change it up a bit.  Often the ships are not completely stocked these days, no need, but there is literally nothing stopping an arleigh burke destroyer from going to sea with 96 tomahawks or 384 ESSM, other than a desire to have a mix of munitions available at all times.  The change between is literally a crane lifts one canister out, and lowers the other into place.   

As far as I'm concerned, so long as there is no sharing of capacity between cells/boxes —2 size 15 box launchers cannot fit 5 size 6 missiles, only 4— , and commonality of munition within each box launcher, I don't see an issue with it.  But only for box launchers.  Standard launchers are an entirely different beast.

Its no great leap to assume standardised canisters are utilised to simplify training of ordnance personnel, transportation, and warehousing of munitions.  So long as you obey the canister's dimensions, anything goes.   

I would expect there to be some minor loss of capacity in building the separators between cells for multiple munitions, but not significant, just enough to say you can't fit 5 size 3 rounds into a size 15 launcher, but could probably get 2 size 7's into it.  I would expect that the more munitions loaded, the more is lost to dividers, such that if you could just get 2 size 7's into a size 15 launcher, you'd never fit 14 size 1's as well, but maybe 10-12.   

see here: https://www. alternatewars. com/BBOW/Weapons/VLS_Baselines. pdf
and here: https://en. wikipedia. org/wiki/Mark_41_Vertical_Launching_System
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on August 24, 2018, 03:21:27 PM
Depending on the type of nation one plays, it would be nice to handle civilian shipping individually. I am thinking of a multi nation start on earth; one a western democracy with no restrictions on civilian shipping. The other a communist country with all restrictions on civilian shipping applied. Possible?
Title: Re: C# Aurora v0.x Suggestions
Post by: Darkminion on August 24, 2018, 07:33:08 PM
The SSBN's were never intended to be hot-swapped for differing munitions, the subs were pretty much built around a given missile, and would keep it pretty much until the end, not exactly modular.  So naturally, there wasn't a lot of wiggle room in making them functional with another weapon system, so their tubes received a more rigorous re-design to accommodate the tomahawks and wiring to control each.  Enough that they got redesignated as SSGN's, and can't easily return to SSBN duties without similar reworking.   

Mk-41 VLS for US and allied warships however was built with modularity in mind.  Every visit to port could see a different weapon placed in the same cell if there were reason to change it out/reload.  Effectively box launchers coming in sets of 5 or 8 per module, each receiving an encased munition allowing a common interface for multiple weapon types, the wiring and adaptation of the interface to any given munition occurs inside the weapon canister—the ship only ever talks to canisters, the canisters translate/relay to the weapon/ship—, which slots neatly into the cells/"box launchers" and serves as launch tube for the weapon within.   

That brings me to RIM-162 ESSM, those fit four to a canister, and required zero alteration of the Mk-41 vls hardware to accommodate.  They fit into a standard canister, the canister fits the VLS.     On any given voyage they will decide if they will sail with the standard set of munitions, or if they need to change it up a bit.  Often the ships are not completely stocked these days, no need, but there is literally nothing stopping an arleigh burke destroyer from going to sea with 96 tomahawks or 384 ESSM, other than a desire to have a mix of munitions available at all times.  The change between is literally a crane lifts one canister out, and lowers the other into place.   

As far as I'm concerned, so long as there is no sharing of capacity between cells/boxes —2 size 15 box launchers cannot fit 5 size 6 missiles, only 4— , and commonality of munition within each box launcher, I don't see an issue with it.  But only for box launchers.  Standard launchers are an entirely different beast.

Its no great leap to assume standardised canisters are utilised to simplify training of ordnance personnel, transportation, and warehousing of munitions.  So long as you obey the canister's dimensions, anything goes.   

I would expect there to be some minor loss of capacity in building the separators between cells for multiple munitions, but not significant, just enough to say you can't fit 5 size 3 rounds into a size 15 launcher, but could probably get 2 size 7's into it.  I would expect that the more munitions loaded, the more is lost to dividers, such that if you could just get 2 size 7's into a size 15 launcher, you'd never fit 14 size 1's as well, but maybe 10-12.   

see here: https://www. alternatewars. com/BBOW/Weapons/VLS_Baselines. pdf
and here: https://en. wikipedia. org/wiki/Mark_41_Vertical_Launching_System

I like the idea that if allowed to fit smaller munitions into larger capacity box launchers there should be diminishing returns. Maybe have a range of possible missile sizes a certain sized box launcher can accept rather than giving a player carte blanche with what can be stuffed in there. This would help with say building an aurora equivalent of the F15 Global Strike Eagle to min-max possible load outs. Although personally I'm not sure I would want smaller explosions :P
(https://lh3.googleusercontent.com/-qbXYwcETqKE/V7KkKtQyPZI/AAAAAAAAIcY/TnEUsfF8yLQ/s1600/F-15GSE12.jpg)
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.560.4885&rep=rep1&type=pdf (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.560.4885&rep=rep1&type=pdf)
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on August 24, 2018, 10:36:52 PM
Quote from: Darkminion link=topic=9841. msg109515#msg109515 date=1535157188
Maybe have a range of possible missile sizes a certain sized box launcher can accept rather than giving a player carte blanche with what can be stuffed in there.

What about something like this?

Code: [Select]
maximumMunitions=INT(launcherSize^0.6)*2
maximumMunitionSize=INT(launcherSize*(1-0.015*(munitions-1))/munitions)

All munitions must

So size 15, raised to the power 0. 6 is 5. 0778, 5 when truncated to integer, 10 when doubled.   The hardlimit on munition quantity is 10.

To quad pack it, determine the munitions size limit,
Code: [Select]
INT(15*(1-0.015*(4-1))/4)
INT(15*(1-0.015*3)/4)
INT(15*(1-0.045)/4)
INT(15*0.955/4)
INT(14.325/4)
INT(3.58125)
3

So if you wanted to quad pack, they can't be larger than size 3, netting an effective capacity of size 12, for a 20% loss.   Nothing stops you quad packing size 1 in the same scenario, but you can't quad pack size 3. 75 and get the full 15 MSP.

To walk it in the other direction, if you planned to be able to quad pack with size 4, you need a launcher of at least:
Code: [Select]
roundup(size*packing/(1-0.015*(packing-1)),0)
roundup(4*4/(1-0.015*(4-1)),0)
roundup(16/(1-0.015*(4-1)),0)
roundup(16/(1-0.045),0)
roundup(16/0.955,0)
roundup(16.754,0)
17
Size 17, so you're wasting 1 MSP to quad pack with size 4.

You could quad pack a size 6 launcher, but it only with size 1's, wasting 33% of the launcher capacity.

The complete set for size 15 is 1 munition at size 15, 2 munitions @s7, 3 @s4, 4 @s3, 5 to 6 @s2, 7 to 10 @s1.

Size 100, 1@s100, 2@s49, 3@s32, 4@s23, 5@s18, 6@s15, 7@s13, 8@s11, 9@s9, 10@s8, 11@s7, 12 to 13@s6, 14 to 15@s5, 16 to 18 @s4, 19 to 22 @s3, 23 to 29 @s2, and 30 @s1.

So while there are 17 different packing options at size 100, you lose 70% of the overall capacity trying to max out on size 1's

This should keep a damper on excessive packing choices, yet still allow you to when necessary.   

That sound reasonable enough?
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on August 25, 2018, 12:31:14 PM
There is no engineering problem with this...
All the examples you gave and really, all the examples there exist, are just that - purpose-built engineering solutions. They already exist by the fact that any launcher will accept any missile as long as it fits. What QuakeIV and TMaekler were suggesting isn't that, it's much more because it would mean free swapping of all weapon systems with any other weapon system "on the fly". And that is not possible today, nor is it something that seems to be possible in the near future. And it shouldn't be brought into Aurora because it opens a massive can of worms with the combat model.

...for a first generation VTOL jet with no computer assisted flying, the Harrier did everything needed. It was never going to compete with land based air superiority fighters, not even catapult launched aircraft can compete with a contemporary land based aircraft. Honestly, the Harrier wasn't THAT bad...
That wasn't the argument. The Harrier was used as an example by QuakeIV to justify his suggestion that multirole fighters work and are great. You merely reinforced my earlier counter-point: that the Harrier, as capable as it was to perform a wide variety of tasks from a wide variety of bases, was NOT a great plane. It would always lose out to a dedicated specialist plane. I'd rather take an A-10 or SU-25 for ground support, and an F-15 or MiG-29 for air combat, or an AH-64 or a Mi-24 to operate from an improvised landing strip. Harrier's strength was that instead of 3 different platforms, you only needed to buy one.

Which is equivalent to a large missile box launcher. Also, pretty sure there are much more extreme reduced-size options available.
Box launchers, however, can get down to 50 tons. Lasers, even with the half-size reduction, which is the best there is, are still at least 100 tons. You're probably mixing it with GC that can be reduced down to 25 tons. That's still a lot more than 2% of platform mass.

Again, why not? A B-52 can carry 31 bombs, or it could carry 60 smaller bombs, or 1 giant bomb, or guided bombs, or standoff bombs with 200 mile range, or cruise missiles with nuclear tips. Hell, pretty sure they have ballistic missiles that can be fired from bombers. Nothing is stopping someone from putting 100 sidewinders in a B-52, there just isn't a reason why you would.
Because a weapon system does not exist in a vacuum. B-52 bomb bays were built to accommodate very few, very specific bombs. The specs of those bombs were then built into the bombsight. Every time the USAF wanted to get the B-52 to utilize a new weapon system, it had to modify or rebuild the bomb bays as well as the bombsight, and later the targeting computer(s). That's one reason why "smart kits" were invented, allowing mechanics to just slap them on "dumb" iron bombs, which in turn enabled bombers to drop semi-smart bombs without the need to modify the plane itself. The program to get the B-52 to fire cruise missiles was a big and costly one, requiring the design of purpose-built cruise missile for them, as well as a new version of the bomber itself to support it. So only the B-52G and H models can fire the AGM-86 ALCM, not any other model of B-52.

So again, either a platform is built for a specific weapon system, or a weapon system is built for a specific platform. Sometimes a weapon system can be used by multiple platforms, and a platform can generally use multiple weapon systems, but these are always built for the purpose, not something that is hot-swapped on a carrier deck. The external bomb racks on the wings of an F-16 cannot carry ANY type of weapon. No, they have a very finite list of weapons that they can put there.

We already have the ability to use missile launchers to shoot any type of missile as long as it fits. The ability to just swap-on-the-fly missile launchers with lasers or of violating launcher sizes as long as some arbitrary "total" isn't surpassed, goes against my sense of realism and immersion, nor does it seem like something that is really needed.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on August 25, 2018, 06:22:03 PM
Quote from: Garfunkel link=topic=9841. msg109520#msg109520 date=1535218274
We already have the ability to use missile launchers to shoot any type of missile as long as it fits.  The ability to just swap-on-the-fly missile launchers with lasers or of violating launcher sizes as long as some arbitrary "total" isn't surpassed, goes against my sense of realism and immersion, nor does it seem like something that is really needed.

Mostly agreed.   I think the modularity concept can get you as far as box launchers, by their nature a self contained empty space meant only to speak to an adapter which relays to a munition, where the munition is all stages of attack by itself, requiring the launcher only to turn on, get told who to attack, and when to begin.   We have modern examples of quadpacking VLS launchers from numerous nations now, across multiple weapons systems, requiring no physical alteration of a design that predated the new munition.

The modularity exists within the canister, you engineer your munition to play nice inside a canister, and the vls system doesn't care very much after that. 

It is realistic to accept that a large enough box launcher could receive an insert for two or more smaller munitions per box launcher, the US navy has been doing operationally it for almost 15 years.

As for anything not a box launcher, its a complete logistical train, involving generation/storage of ammunition, transfer of ammunition to the launch point, a re-loadable mechanism to fire more than once, and a complete wiring interface to communicate what stage of this process it is at when queried.

Gun pods on external pylons?  Not without torsional stress tests for the mount, modification of wiring to support the needed functions of the new weapon pod such as ammunition remaining.   And those wiring changes will need to be extended from the pylon/mount point to the central computer system, and from there to the cockpit for the pilot can be aware of what it is doing/control it.

Missiles?  The F-14 could haul around the much larger AIM-54(460kg), yet never could fire the AIM-120(160kg).  Instead it had the AIM-7 sparrow, also heavier than the AIM-120 at 225kg.   It wasn't wired in a way compatible with the AIM-120, the on board computer didn't know what it was, and the firecontrol couldn't talk to it.

The F/A-18 Growlers are literally just F/A-18F's with a few extra microwave generators and receivers bolted on.   A carrier at sea cannot perform the task of uprating another F to the G model.   they can overhaul the engines, perform complete engine swaps.   Can't uprate the model from F to G, there's too much involved for it to be a field task, much less a hot swap, it is a workshop task, a refit.

Just because ah-64's can have 4 4x racks(16) of hellfires doesn't mean you can go hang a rack on each of the 11 pylons under an A-10 to go play tag with tanks in a couple of hours-not wired for the missile at all, nor can you load 11 mavericks, despite the A-10's being wired for it--on some pylons.

In Aurora, we already get greater freedom than this, the software/firecontrol updates being abstracted away when you load the newest in a series of missiles.   Just have a missile fire control, have a suitable launcher, and the weapon in the magazines, and the weapon will work.

For warships larger than fighters perhaps then?

No naval vessel has ever seen its gun armament altered as easily as reloading ammunition.  There are logistical and structural issues with the weapon to account for.  The closest naval ships get to this capability are the littoral combat ships.   Even they are not quite hot swap.   Its a days in port sort of task.   They've done it in 96 hours before during rimpac in 2012.   Effectively a non-destructive, reversible refit.

No naval vessel with rail launchers has ever hotswapped its missile armament to missiles it wasn't designed for initially.   The Oliver hazard perry frigates lost their missile armaments as a cost cutting measure, in large part because they were limited to the outdated SM-1 missiles.   By the time they were stripped of their missile armament, the US was testing anti ballistic missile missiles like SM-6.   Their magazines may have been able to hold the larger missiles, but the reload mechanism, and the rail launcher couldn't, and uprating the launcher to be the same as that on the Tico's was deemed too much effort, because it would be quite a sizeable overhaul.

MK-41 VLS could UNREP at sea at a rate of 3 canisters per hour.  https://www. dtic. mil/dtic/tr/fulltext/u2/1032180. pdf .   Lifting one out is considerably easier - no need to perfect alignment before lifting, just be close enough.   Call it 30 minutes to perform a cell unload/load operation.   90 cells, in two banks(29 and 61) that can both be in progress simultaneously, you can rearm the ship in 31 hours.

In replacing a canister, you also replace the insert contained within the canister, which means you can hot swap from single weapon of one size, to quad packed weapons that are smaller.  2+ cells of complete mission/armament change/reload per hour at sea seems to fit the bill, if slow.

Its not a weight or attachment issue, its an everything else issue.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 25, 2018, 09:28:03 PM
I'd point out a lot of the lack of flexibility on legacy aircraft such as the f-14 and a-10 is due to exceedingly old electronics and non standardized connectors, issues which are both not nearly as much of an issue on newer platforms using newer missiles.

In general, the harrier was a good aircraft because it could do the job of a multirole fighter while constrained to the tiny deck of a british aircraft carrier, perhaps a better example of a multirole that isn't under such constraints would be the f-15 strike eagle or most of the newer f-16 variants (or for that matter the f-18 superhornet) all of which can carry a fairly wide variety of munitions with a good degree of flexibility, while also being hugely dangerous air-to-air threats capable of supersonic flight.  With respect to the growler refit, thats true that a carrier cant do that, but you can put generic electronic warfare pods onto fighters just fine, they just arent as good as a dedicated EW bird such as the growler (which has quite a lot done to it other than simply bolting a couple EW pods on).  In general the navy tends towards growlers covering formations of fighters because that is more effective for them, but that doesn't actually stop them from getting very minor f-18 modifications that would let them all carry less powerful EW devices if they were so inclined.

Here is an f-16 carrying an electronic warfare pod on its belly:
(https://thaimilitaryandasianregion.files.wordpress.com/2016/02/f-16-brimstone-mbdainc.jpg?w=625)

Yes I would agree that in general missile launchers are more specialized than aurora makes them out to be, but in a lot of the earlier magazine based ships that got brought up by mentioning the oliver hazard perry, there was absolutely no consideration for standardization and flexibility for those ships.  The perry class was practically one of the first production missile destroyers ever made.  The current missile destroyer and cruiser family in the USN all have complete flexibility in how they load their box launchers.  Yes it takes time to re-arm a particular cell, but the time it takes isn't particularly influenced by what kind of cell you are loading.  I don't see any particular reason why magazines couldn't also be standardized to some degree in the future, if anyone ever felt inclined to go back to using those.

With respect to the assumed modular mass ratio of 2% or whatever, an f-16 loaded with fuel weighs 12000kg, and can carry up to 7700kg of additional payload for a total of 19700kg.  7700/19700 = circa 40% of the final mass, which is quite a lot.

Finally, with respect to lasers, thats a good point about wiring.  It would be a huge stretch to say that you could run the huge amount of wiring needed to direct reactor power to generic mounting points with any reasonable degree of effeciency or flexibility.  I'll concede the laser point as kindof ridiculous on that basis.

e:  I also don't particularly mind the concept of fitting different weapons or targeting/EW/sensor pods costing MSP and such for instance.  I also think it would be reasonable to say that fighter box launchers or hardpoints or what have you should have their full carrying capacity included in the base fighter mass, so that you aren't getting to move components outside of the armor to save on armor weight.  As far as I know part of why everything has to have at least one armor layer is so that it has the robust structure required to pull hard maneuvers.  Obviously that should apply to hardpoints as well, which would have to be quite reinforced I would think.  And then the hardpoints have the downside of the payloads existing outside of the armor regardless.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on August 25, 2018, 09:37:35 PM
The 2% thing was just a left over from an earlier comparison. It really is meaningless - the point was to show the size/mass difference between a Harrier gun pod IRL and an Aurora laser.

I agree that more modern planes are designed with modality in mind, but that's a result of 50+ years of development. Same with the EW warfare pods - the planes had their computer systems upgraded so that they could actually take advantage of the pods. That's the thing, all of this modularity and multi-use is the result of decades of design work, and all the components involved were purpose-built to be modular and multi-use. If we can replicate that process in Aurora, then I'm 100% for it. But if we can't, then it's just another method for the human player to curb stomp the NPR.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 25, 2018, 09:41:03 PM
I mean, only if the NPR is unable to make use of this stuff.  Mind you, I agree that conventional AIs have so far done horribly in environments with lots of options that have complicated implications.  I'm also not really sure why a tech curve would help the NPRs against this, it seems like that would only delay the inevitable if they are bad at it regardless.

Also, I'd note that these modularity concepts would most likely apply to trans-newtonian stuff as well (having implicitly been developed prior to the TN tech), though I agree they would probably require a fair bit of additional technology to deal with all the new trans-newtonian physics factors.  I don't necessarily think its a good idea to add those techs since I don't see what that complexity would bring to the table.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on August 26, 2018, 12:06:18 AM
Agreed on modularity being a feature of the future.   Logistics wins wars, and simplifying your logistics with a singular model versus several dedicated, if capable enough, can yield enormous gains.

I'd note that even today's latest and greatest can't field everything though, F-35's currently have no HARM capability, starting with the point that the missile won't fit its internal bay - given the objective of stealth and the penalties of carrying externally, its not wired to even try.  AIM-120's have external mounting capabilities though, no reason to hobble it in lower threat environments.   Even as modular as they are, weaponry included, the ever present issue of aerodynamic and torsional stresses, wiring/connectivity and internal software/awareness of the munitions envelop remain a thing, though we certainly do try harder to keep it an option.   Fortunately for the concept, this is the sort of detail aurora abstracts away entirely, absolving us of needing to dwell on it, once sure we don't consider it too large a hurdle.

I also agree that it may be difficult to balance well, and especially the AI using it effectively.   Though an AI effectively abusing this could have very capable carriers.   An entire fighter wing that can launch with the right armament to best make you suffer, and then be completely different for its next engagement?

I would contend it should not be possible to internally mount a complete weapon system, and still be able to later swap it out like a munition - once inside the armor, that's that.   Something mounted outside the main hull may be open to a little more variability, but you lose the advantages full integration would have allowed.   This tradeoff would naturally be in one of two forms for gameplay reasons, either a loss of performance for same mass, or a growth in mass for same performance.   Given the intent to mount these on fighters, the loss of performance for same mass seems the better candidate.   So for the same mass, you get a somewhat inferior, but more flexible weapon system.

In the interests in achieving reasonable fire control range, the fire control should not be in the mount, it should be hosted by the parent craft.

Now, on to energy supply.   Under the assumption that modular mounting of lasers or particle weapons is a thing, should the power be in its own pod, part of the external mount, or mounted in the parent craft?  I'm partial to requiring they be internally mounted, and suffer a penalty to delivery efficiency, perhaps a simple percentage loss of power at the mount, requiring a larger generator for same system, or the more explosive flavour for similar/same size.

This leaves you deficient compared to a dedicated system in a couple ways.   One, the weapon system will not have the advantage of armor - not that fighters have much anyways.   Two, it will lack the performance of a dedicated system.    Three, even when not mounted, you have mass spent on the no unnecessary power generators.  Four, the expense of design and construction should be larger, its one thing to integrate the weapon, its another to run it from a mounting, the design considerations change.

In an all up fight, the fighter with permanent mounts should perform better and cost less - it sacrificed flexibility to get those advantages.   There are many efficiencies you can leverage when you can optimise for a specific system rather than generalising.

There is one serious caveat to this line of thought, and QuakeIV already mentioned it.   If it is reasonable to mount a weapons system, why would it not be reasonable to do something less challenging: mount active or passive sensors, ECM, or ECCM?  What about even simpler things like fuel tanks?  Could fighters end up serving as emergency tugs dragging out a podded tractor beam?

Personally, I think its much harder to justify the can of worms for full weapon systems, much less difficult for subdivided box launchers.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on August 26, 2018, 01:49:36 AM
Agreed on modularity being a feature of the future.   Logistics wins wars, and simplifying your logistics with a singular model versus several dedicated, if capable enough, can yield enormous gains.
This is peacetime logic.

Once you start taking double digit casualty rates in each engagement, you need to start counting the cost of replacing attrition. Any capability you're using less often than your attrition rate is on average better off being split off to a dedicated specialist platform. And you will see double digit attrition rates if you ever go up against someone who can shoot back: Since the early 1940s the ability of a weapon platform to inflict damage has grown much faster than the ability to equip the same platform to endure damage, and there is no sign that this trend will break any time soon.

For wars against people who can't shoot back - colonial punitive expeditions and counterinsurgency warfare - you don't need multirole platforms either, because you don't need most of the roles they provide. Bringing next-generation air superiority capabilities to a counterinsurgency is like bringing a thousand dollar golf club to a back-alley brawl. I'm sure it's a very nice golf club, and in a pinch you could hit a guy over the head with it, but you're better off bringing a ten dollar knife and a lack of sportsmanship.

(Also, the supposed savings from multirole platforms tend not to be realized, but that is mostly a matter of political dysfunctions in the armaments procurement bureaucracies of the countries that have that design doctrine. And Aurora does not model the political economy of the military-industrial complex.)
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 26, 2018, 02:25:25 AM
I think you are saying that multirole capability is wasted if the expected statistical outcome for the vehicle is to be destroyed before it can use every capability.  Therefore, leave out the unused capabilities and just send specialist units to perform their one mission and then die.  I will try to argue mathetically, which is probably a mistake given how late in the night it is for me.

I don't fully agree that this applies to multirole vehicles when for any given mission they are able to leave the useless parts of their multimission capability behind.  Yes they are somewhat less capable at each role, but for instance you don't need to bring your expensive multispectral targeting system on an air to air mission, nor do you need to bring every possible needed EW capability at the same time.  You can just leave the un-needed bits in storage, and then they are still there and useful to go do their thing even after loss of vehicle.

This allows for siginificant economy of force in that you can for instance potentially send quite a lot more air to air capability up against the enemy than they can respond with (all other things being equal), since they have specialized vehicles of which only a fraction can engage with your own vehicles.  So, unless the cost to produce some arbitrary x air to air capability in multirole vehicles plus the weighted average of their mission equipment (weighted by the optimal balance of equipment) is nearly as expensive as the weighted average cost of every possible specialized vehicle (weighted by the optimal balance of equipment) then the multirole would generally come out on top because you could exert more force in any given role with the resources at hand.

e: There is less total multirole capability, but the total in any specific environment is higher.

This is ignoring the economy of scale amram mentioend in his logistics argument, wherein you could have significant economy of scale by mass producing a lot of the same thing.  Though, I think that working out would be dependent on the common multirole vehicle being the majority of the cost or something like that.

He may also have just been pointing out that there is the logistical upshot of always having the right equipment in the right place at the right time (though this would only be fully true if you could afford to have a full complement of gear to go with every vehicle), rather than having a bunch of ground attackers and SEAD somewhere where you need air to air for instance.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on August 26, 2018, 03:35:59 AM
You're assuming that the integration overhead of the platform itself is negligible, which is not true.

You're further only looking at initial strike capabilities, not the economics of sustained attrition. The cost of sustaining a particular amount of battle-winning ability in a given theater over the course of a long conflict against a capable enemy is heavily tilted toward the cost of replacing expended equipment, not the cost of maintaining the readiness of unused equipment.

If maintaining readiness in peacetime is already straining your logistics train, then your doctrine doesn't matter because your tail will break the moment you actually have to fight a serious shooting war. This is one of the five 'C's - the big five reasons even large, well-funded militaries fall on their face when they stumble into a war after a long period of peace: Coups, Counterinsurgency, Conscripts, Corrupt procurement, and Civilian logistics.
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on August 26, 2018, 04:23:35 AM
Agreed on modularity being a feature of the future.   Logistics wins wars, and simplifying your logistics with a singular model versus several dedicated, if capable enough, can yield enormous gains.
This is peacetime logic.
No, logistics is an immensely important part of warfare and is often the make-or-break factor in real life war. Having equipment that can do the job, albeit less well, is always preferable to not having the equipment to do the job at all. Having for example one type of multirole plane doesn't just mean that you have the equipment though, even if more can't be delivered. It also means that you only need to produce replacement components, fuel, mechanics and everything else that goes along with operating a plane, for that single type of plane and that they are compatible with every plane there. This immensely simplifies the production chain and allows you to ramp up production faster, and simplifies the logistics of delivering these things where they need to go.

Better equipment wins battles, better logistics wins wars.Obviously there's wiggle room here, with sufficient logistics and sufficiently advanced equipment the equipment will be more likely to win enough battles to sway it, but history has pushed us in a general direction.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on August 26, 2018, 05:43:36 AM
Quote from: Person012345 link=topic=9841. msg109535#msg109535 date=1535275415
Quote from: Scandinavian link=topic=9841. msg109532#msg109532 date=1535266176
Quote from: amram link=topic=9841. msg109531#msg109531 date=1535259978
Agreed on modularity being a feature of the future.    Logistics wins wars, and simplifying your logistics with a singular model versus several dedicated, if capable enough, can yield enormous gains.
This is peacetime logic.
No, logistics is an immensely important part of warfare and is often the make-or-break factor in real life war. 

. . . snip. . .

Better equipment wins battles, better logistics wins wars. . . .

Bingo.   If you field more models of equipment, with a force structure that is equivalent in performance to an adversary which meets you in quantity and quality through a single model, they hold a significant advantage.

Take air combat.   two forces.   One has 30 fighters and 30 attack planes.   The other has 60 multirole.   The fighters are superior and will maintain a 3v2 kill ratio.  After the initial combat, they lost their 30 fighters, you lost 45 multirole.   Your 15 remaining multirole easily murder the attack aircraft and now only you have aircraft.

Another approach, assume the 30 fighters can fire first, pk 0. 7 per shot, the multiroles pk 0. 3 per shot.   The 60 multirole will win with 15 survivors.   Even 30 fighters and 45 multirole, with 0. 6 and 0. 45 pk, the multirole win with 4 survivors.

Multirole flexibility allows sudden swings in your total force in a given role, instead of only 30 aircraft on CAP, you can have 45-60.   Quantity is a quality all its own.

It simplifies your logistics allowing the entire force structure to utilise any given supply, improves supply delivery since how much of what devolves to as many of one thing as fits.   Its better to have 4 spare engines for all your craft than none for the model that needs one now.   Ditto for ammunition, in some cases even fuel.

Production benefits as well, less competition for limited resources means the quantity of the stock will be increased.   Distribution, warehousing, acquisition, everything benefits.

Aurora multirole fighters could make for a very powerful airwing provided the selected armaments are on point.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on August 26, 2018, 06:39:57 AM
If you field more models of equipment, with a force structure that is equivalent in performance to an adversary which meets you in quantity and quality through a single model, they hold a significant advantage.
If you use two models and his single model is three times as expensive in manufacturing time and supply chain complexity, he will have to outspend you by fifty per cent just to have parity in quantity and quality.

Standardization works when the cost of standardization is lower than the cost of redundancy. Agreeing on only using two or three ammunition calibers is very nearly costless (though notice that even here the cost of standardizing on a single caliber was deemed excessive - while squad-support rifles can assault rifles use interchangeable munitions, you still have different, non-interchangeable munitions between squad support and full machine guns and marksman's rifles).

Agreeing to use only one airframe instead of three, on the other hand, raises unit cost by a factor of ten or twenty (compare the F-35 to a fleet of mixed F-16/A10/Predator drones), and then the economics don't work.

Quote
Take air combat.   two forces.   One has 30 fighters and 30 attack planes.   The other has 60 multirole.
That will never be the force structure of the two opposing sides in your hypothetical. The side that uses dedicated planes will always field a force more heavily weighed toward air superiority on day one, because once one side has established air superiority it is very hard to take it back, while flying CAS can clearly wait a few days for reinforcements to be brought up from rear echelons (if it could not, you would not be able to fly all of your fleet in the air superiority configuration during your alpha strike). At a 3:2 kill rate, they only need a 45:15 split to wipe out your whole force on the first day, at which point you will never recover the attrition game (assuming equivalent total production capabilities, and that they produce air superiority planes at a 3:1 rate to ground attack), and they are free to fly CAS with impunity.

And assuming equivalent budget instead of equivalent numbers, you're even worse off, because your multiroles are individually more expensive than his dedicated planes.

(Of course in reality, the defending side would have surface to air missiles, and the force mix in the air would not matter, because all aircraft on the attacking side would be blasted out of the sky on the first day.)

Quote
Production benefits as well, less competition for limited resources means the quantity of the stock will be increased.   Distribution, warehousing, acquisition, everything benefits.
Yes, I've also read Lockheed's advertising copy.

Let me know if you find an airforce anywhere in the world that has ever been able to cut their budget without losing readiness after buying Lockheed. Because that would be a first.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on August 26, 2018, 09:05:16 AM
Hey gang, can we please take this to another thread?  Steve is pretty conversant with modern military technology, and the suggestion (and objection) has been made. 

Please remember that Steve uses the Suggestions thread as a filing cabinet/issue database, so forcing him to scroll through a lot of back and forth when he reviews the thread six months from now to find unique suggestions is not doing him a favor.

Thanks,
John
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on August 26, 2018, 09:45:37 AM
Thinking about it last night, I came up with what I think is the single most important change for C# that I haven't seen discussed anywhere else.

In C#, the bitmask that occasionally changes officer sex to YES!! should be retained. Furthermore, the miniscule chance should be multiplied by some coefficient of deployment time, so that officers on long deployments are more likely to display it. Furthermore, there should be another coefficient multiplier based on crew morale, so that officers on deployments so long that the shipboard amenities are running low are even more likely to display it.

This seems to me to be a critical issue, without which we simply can't consider C# complete.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 26, 2018, 06:04:54 PM
Not sure how this forum works with regards to the difficulty of thread splitting, would you be willing to split off the debate of that particular suggestion into its own thread?

starts here: http://aurora2.pentarch.org/index.php?topic=9841.msg109413#msg109413
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on August 26, 2018, 09:17:04 PM
Not sure how this forum works with regards to the difficulty of thread splitting, would you be willing to split off the debate of that particular suggestion into its own thread?

starts here: http://aurora2.pentarch.org/index.php?topic=9841.msg109413#msg109413

I know how to split out a thread, except it involves going back through the posts and deciding one by one whether they get pulled into the now topic (which is why I didn't do it earlier - I just didn't have the energy).  I don't know how to move posts back and forth between two threads though.  Since you've already made a branch (thank you!!) I'm just going to leave it alone.

Thanks,
John
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on August 27, 2018, 12:55:55 AM
Some ideas on event update messages:

I'd like getting an event update when I, lets say have 5 MDs on a planet (which has a send to target set) and the mineral production of that planet goes over or under the sending capacity (in this case 20.001-25.000t per year). If it gets below 20.000t, I would like to get a message stating that I have unused MDs on a planet, or if it goes above 25.000t, it should read: cannot send all produced minerals via MDs on planet XY.


I usually set up mineral transports for transportation through jump points. Every now and then I check if the transport still can carry all collected minerals of the starting planet and either increase the number of transports or increase the traveling speed of them. So a message like "could not pick up all stored minerals on a planet" would make my life a little easier doing that... .
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on August 27, 2018, 01:02:44 AM
Fuel Report window: being able to exclude selected ships in this view would help getting rid of unnecessary clutters (I do have lots of sorium harvesters which I really don't need to see in this window). So an option box for every entry which when enabled would exclude that ship from showing in this list (with an option button at the top of course to enable showing them) would be nice.

Alternatively having a general option button in the class design window which sets this flag for the whole class might be a less micromanage alternative.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on August 27, 2018, 01:06:32 AM
Foreign Aid - can also be used for "war reparations payment". But what population would like that, right? Maybe there could be an "make pop angry" option added to this feature, if the amount of payment exceeds a certain amount of income percentage ...
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on August 27, 2018, 12:26:00 PM
Fuel Report window: being able to exclude selected ships in this view would help getting rid of unnecessary clutters (I do have lots of sorium harvesters which I really don't need to see in this window). So an option box for every entry which when enabled would exclude that ship from showing in this list (with an option button at the top of course to enable showing them) would be nice.

Alternatively having a general option button in the class design window which sets this flag for the whole class might be a less micromanage alternative.

Civilian ships also show up on this window, which is unnecessary, as they don't use fuel and wouldn't be managed by the player anyway, so it would be nice if those could be removed from the list by default.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on August 27, 2018, 02:28:49 PM
Improvement on TG/Fleet loading logic.

Currently, in VB6 Aurora, a TG ships load one by one. Once the topmost transport is full, then it starts loading the next transport and so on down the list. This isn't much of a concern with cargo freighters until very late in the game when you might have a TG of 20+ super-freighters, at which point the loading and unloading times get really noticeable. Or you don't use Cargo Handling Systems for some reason.

But with troop transports, this becomes noticeable way earlier. As an example, I have a TG of 8 ships, each capable of carrying a full division. I ordered the TG to load 2 divisions, a bunch of REP and GAR units and a whole load of CBs. The TG has been loading units forever and is still going strong. Because it takes about 27 days to load one CB. I forgot to check how long the individual battalions or the divisions took. Next time, I'll just create individual TGs for each troop transport, it's not a problem.

But for C#, ensuring that each ship in the Fleet/Sub-fleet loads concurrently instead of consecutively, would be an awesome improvement. 
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 03, 2018, 06:19:41 AM
For roleplaying reasons: many AARs are played in a way that messages have to travel via the limits of lightspeed. Usually you would have to manually calculate the lag time and then perform your planned actions. So how about a new dialog in which you could calculate the distance between the two objects you want to sent the message to (Rigel 9 to Wormhole Sol System, Wormhole to Earth - So Rigel 9 to Earth) and see the time it would take. This dialog then could add an event which will occour right at the time when the message arrives. So you get reminded in the event log.

Or if we want to get fancy, Steve could add a whole technology branch "subspace communication speed", which begins with lightspeed and provides several development steps to increase the speed; and then adds the option for "send message to XY" into the fleet command list. That way we could automate it completly...  :D
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on September 03, 2018, 10:11:52 AM
Improvement on TG/Fleet loading logic.

Currently, in VB6 Aurora, a TG ships load one by one. Once the topmost transport is full, then it starts loading the next transport and so on down the list. This isn't much of a concern with cargo freighters until very late in the game when you might have a TG of 20+ super-freighters, at which point the loading and unloading times get really noticeable. Or you don't use Cargo Handling Systems for some reason.

Snip

Very much agree with this, it’s also very acute if you do it with loading troops from transport bays to drop pods.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on September 03, 2018, 10:48:31 AM
Improvement on TG/Fleet loading logic.

Currently, in VB6 Aurora, a TG ships load one by one. Once the topmost transport is full, then it starts loading the next transport and so on down the list. This isn't much of a concern with cargo freighters until very late in the game when you might have a TG of 20+ super-freighters, at which point the loading and unloading times get really noticeable. Or you don't use Cargo Handling Systems for some reason.

But with troop transports, this becomes noticeable way earlier. As an example, I have a TG of 8 ships, each capable of carrying a full division. I ordered the TG to load 2 divisions, a bunch of REP and GAR units and a whole load of CBs. The TG has been loading units forever and is still going strong. Because it takes about 27 days to load one CB. I forgot to check how long the individual battalions or the divisions took. Next time, I'll just create individual TGs for each troop transport, it's not a problem.

But for C#, ensuring that each ship in the Fleet/Sub-fleet loads concurrently instead of consecutively, would be an awesome improvement.

All freighters load together in VB6 Aurora, if they are loading the same type of installation. If you have different installations to load, they are done sequentially because they are different orders (although you can split the freighters before loading to avoid that). Troop transports usually load sequentially because different units are loaded with different orders. You can avoid that by using the option to load subordinate units, or by splitting the transports up.

I will be adding some combination orders to C#, although orders will still be executed in sequence.
Title: Re: C# Aurora v0.x Suggestions
Post by: Haji on September 05, 2018, 03:19:55 PM
Due to the insane length I haven't even tried to read this topic. As such my apologies if any of my suggestions have already been made and commented on/discarded.

1. Please allow us to modify characteristics of various stellar bodies or, even better, add custom ones. I quite often start outside the Sol system and for roleplaying reasons want something rather specific forcing me to reroll systems again and again. Not only it is tedious but it did cost me dozens, maybe even hundreds of hours when I was setting up my games.
2. System generation algorithm should be modified in my opinion. Back when I started playing Aurora, Sol was fairly average system, but after that a lot more bodies were added - without changing how other systems were generated. By now it is next to impossible to find system larger and richer than Sol, and I really mean next to impossible. In fact I'm not sure when was the last time I've seen one (please note I'm talking overall larger. It is possible, though still very, very rare, to find system with either more planets or more asteroids or more comets, but combination of those? One in a million chance or so).
3. Missile agility has to be modified. Late fusion/early anti-matter era anti-missiles have 50%-80% interception chances all due to agility which cannot be countered with intelligent missile design. One option would be to discard it completely (although the starting interception chances would have to be increased as otherwise anti-missiles would have like 20% interception chance) while another would be to allow missiles to use agility to avoid interception. The second option would be more interesting in my opinion but would require more balancing work as it should also impact point defences.
And yes, I know there are changes coming to missiles, but agility is pure interception chance with no counter, so I don't think it will solve the issue.
4. At the moment repeatable missile launchers are flat out useless, as demonstrated in Steve's own colonial campaign. A way to possibly solve the issue would be to create a new technology that would reduce the impact of miniaturised launchers, which currently receive large penalty to fire rate. Obviously such technology should not, by itself, make miniaturised launchers as fast as full sized ones, but after playing dozens of campaigns I simply cannot find use for repeatable launchers as they are very, very easily countered by turreted gauss cannons.
Admittedly simply removing gauss cannons would also solve the issue, at least in mid to late game, after railguns are no longer effective.
5. While I appreciate better automation of weapon to fire control assignment, there is one small addition I'd like to request. I'd like to be able to select a type of weapon, type of fire control and then tell the game how many of armed weapons I'd like to assign per fire control. This would help enormously with box launchers when I don't want to use their full power.
As an example I had a battleship with at thousand box launchers, twenty fire controls and I had to target gunboats. With the current changes I would end up with fifty missiles per fire control, which would be overkill, forcing me to assign weapons manually. That's a lot of unpleasant work.
6. Several times now I attempted to create a merchant powers, small nations which relied on trade income to function. I failed every time. The coming changes to trade will help a lot, but the main issue is that shipping lines always build colony ships - even when there is nothing to colonise (small nation don't do much of it after all). Which means their income is spent on useless ships, making it much more difficult for them to grow (they can even fail completely) and creating less taxes. As such I'd love to see an option to prevent shipping lines from building a specific type of ship, so that they would build only what's profitable.
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on September 05, 2018, 11:46:59 PM
6. Several times now I attempted to create a merchant powers, small nations which relied on trade income to function. I failed every time. The coming changes to trade will help a lot, but the main issue is that shipping lines always build colony ships - even when there is nothing to colonise (small nation don't do much of it after all). Which means their income is spent on useless ships, making it much more difficult for them to grow (they can even fail completely) and creating less taxes. As such I'd love to see an option to prevent shipping lines from building a specific type of ship, so that they would build only what's profitable.
I feel like this could be solved by better AI and I believe I have proposed logic that would help with this somewhere, though it's possible I just meant to post it then forgot to. In any case, with the multi-leveled AI coming in C# aurora I feel like there are plenty of possibilities to make the AI smarter when it comes to choosing what ships to build. I wouldn't even mind if it was deliberately imperfect, for example basing it's purchasing decisions heavily on prior income - IRL, markets usually take time to adapt to sudden changes after all - rather than having it be predictive, but I do think there needs to be some mechanism to push companies towards the demand rather than it being fairly arbitrary. It also might result in companies tending to specialise which might be cool to see.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on September 05, 2018, 11:56:38 PM
6. Several times now I attempted to create a merchant powers, small nations which relied on trade income to function. I failed every time. The coming changes to trade will help a lot, but the main issue is that shipping lines always build colony ships - even when there is nothing to colonise (small nation don't do much of it after all). Which means their income is spent on useless ships, making it much more difficult for them to grow (they can even fail completely) and creating less taxes. As such I'd love to see an option to prevent shipping lines from building a specific type of ship, so that they would build only what's profitable.
I feel like this could be solved by better AI and I believe I have proposed logic that would help with this somewhere, though it's possible I just meant to post it then forgot to. In any case, with the multi-leveled AI coming in C# aurora I feel like there are plenty of possibilities to make the AI smarter when it comes to choosing what ships to build. I wouldn't even mind if it was deliberately imperfect, for example basing it's purchasing decisions heavily on prior income - IRL, markets usually take time to adapt to sudden changes after all - rather than having it be predictive, but I do think there needs to be some mechanism to push companies towards the demand rather than it being fairly arbitrary. It also might result in companies tending to specialise which might be cool to see.

I think the problem could be far better solved by limiting all Civilian Shipping Lines to a single category of ships (so cargo only, or colony only, or luxury passengers only ((Also, please bring back Luxury Passenger Ships.)) or fuel harvester only, etc.)  That way, only the types of civilians actually being used would make money and thus build more ships.

We would end up with Wilson Cargo Lines, and Phillips Fuel Services, and Chynna Colony Company, and eventually Wilson Luxury Cruises, etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 06, 2018, 05:28:02 AM
1. Please allow us to modify characteristics of various stellar bodies or, even better, add custom ones.
2. System generation algorithm should be modified in my opinion.
A dialog where one can select several parameters as to a rough category of system that should be created would help much.

5. While I appreciate better automation of weapon to fire control assignment, there is one small addition I'd like to request. I'd like to be able to select a type of weapon, type of fire control and then tell the game how many of armed weapons I'd like to assign per fire control. This would help enormously with box launchers when I don't want to use their full power.
Would make sense.

6. Several times now I attempted to create a merchant powers, small nations which relied on trade income to function. I failed every time. The coming changes to trade will help a lot, but the main issue is that shipping lines always build colony ships - even when there is nothing to colonise (small nation don't do much of it after all). Which means their income is spent on useless ships, making it much more difficult for them to grow (they can even fail completely) and creating less taxes. As such I'd love to see an option to prevent shipping lines from building a specific type of ship, so that they would build only what's profitable.
I think the civilians will be better in building new ships, depending on the needs of the empire. Steve wrote about that not so long ago. Although, being able to "select" which areas are made accessable for civilians would be a) nice, and b) make it easier to simulate different kinds of societies.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on September 06, 2018, 10:38:47 AM
3. Missile agility has to be modified. Late fusion/early anti-matter era anti-missiles have 50%-80% interception chances all due to agility which cannot be countered with intelligent missile design. One option would be to discard it completely (although the starting interception chances would have to be increased as otherwise anti-missiles would have like 20% interception chance) while another would be to allow missiles to use agility to avoid interception. The second option would be more interesting in my opinion but would require more balancing work as it should also impact point defences.
And yes, I know there are changes coming to missiles, but agility is pure interception chance with no counter, so I don't think it will solve the issue. Flattening out the Agi tech curve would help as well, especially since shipkillers are usually not using much agi.
4. At the moment repeatable missile launchers are flat out useless, as demonstrated in Steve's own colonial campaign. A way to possibly solve the issue would be to create a new technology that would reduce the impact of miniaturised launchers, which currently receive large penalty to fire rate. Obviously such technology should not, by itself, make miniaturised launchers as fast as full sized ones, but after playing dozens of campaigns I simply cannot find use for repeatable launchers as they are very, very easily countered by turreted gauss cannons.
Admittedly simply removing gauss cannons would also solve the issue, at least in mid to late game, after railguns are no longer effective.
For 3. I think ECM will at least alleviate the problem somewhat, as loosing 30 or 40% interception chance is quite painful, and ECCM uses up 25% of a 1 MSP countermissile.
4. I think it is a serious problem. It could however be fixed with making box launchers larger.
Per msp missile size if you have 3 HS giving you 2 launchers + 1 HS magazine you can fit in 16+2 missiles at 80% efficiency. The same size in box launchers fits you 20! missiles, more than the re-loadable solution.
Dropping 0.25 reloadable launchers and making box launchers 0.3HS per msp would give you an actual trade-off between launchers and magazine size.
As for gauss cannons, one possibility to make smaller missile sizes viable would be to limit the amount of shots that can be fired on the same missile. The reason would be that due to your fire controls and sensors being correlated, if you localize a missile where it is not, more shots will miss as well, and you don't get time to fix your error. Only allowing 2 shots per missile max would give you a finite but low leaker rate for your gauss defense.
Title: Re: C# Aurora v0.x Suggestions
Post by: Haji on September 06, 2018, 11:05:56 AM
I feel like this could be solved by better AI

That is true however I have decided to propose a single tickbox for several reasons. First it will take much less coding. Second even though C# Aurora will be much faster I'm still worried about resource usage. Third at the beginning shipping lines have only enough money to buy a couple of ships and they usually buy a single type of ship, so they may still end up failing without subsidies as they usually build one type of ship at the beginning.

I think the problem could be far better solved by limiting all Civilian Shipping Lines to a single category of ships (so cargo only, or colony only, or luxury passengers only ((Also, please bring back Luxury Passenger Ships.)) or fuel harvester only, etc.)  That way, only the types of civilians actually being used would make money and thus build more ships.

The reason I dislike the idea is due to potential clutter. In many cases I found myself using basically no colony ships, either because the nation was small or because I had large nation that didn't need to move people around for both practical and RP reasons. Not only that but fuel harvesters generate almost no money so I'm not even sure you could have a shipping line operating those exclusively. This would lead to whole lines being essentially useless but still cluttering the UI.

Also the lines currently do build liners (you as a player can't build them though) and they are absolutely broken, generating insane amount of money in some circumstances. Too bad lines build very few of them.

1. Please allow us to modify characteristics of various stellar bodies or, even better, add custom ones.
2. System generation algorithm should be modified in my opinion.
A dialog where one can select several parameters as to a rough category of system that should be created would help much.


I have to admit that a simple screen to, for example, select number and general type of bodies (dwarf planets, terrestrial planets, gas giants, asteroid, comets) would already be a vast improvement, and something much easier to code. Would definitely be happy with just that. By the same token I'm an empire builder and a full scale customisation would allow me to, for example, simulate turning gas giants into miniature stars, or towing asteroid to a new position and turning it into garganutan fortress (though now that PDCs are gone it will no longer be possible). For that matter with the ability to fully customise location and so on of objects and if we had PCS back it would be very easy to simulate having a death star.

I think the civilians will be better in building new ships, depending on the needs of the empire. Steve wrote about that not so long ago. Although, being able to "select" which areas are made accessable for civilians would be a) nice, and b) make it easier to simulate different kinds of societies.

I've checked the official changes list and all it said about civilian shipping lines building AI is that they will be building more even numbers of freighters and colony ships, which is exactly what is causing me problems right now. It's possible something was mentioned in other topics, but I haven't seen that.

For 3. I think ECM will at least alleviate the problem somewhat, as loosing 30 or 40% interception chance is quite painful, and ECCM uses up 25% of a 1 MSP countermissile.

I'm not sure it will help as we will now be able to build fractional size missile launchers (1.1 HS for example) which will allow construction of larger, but still far smaller than 2 MSP counter missiles. This makes ECCM not that difficult to build in, while still leaving very, very large space for agility. In fact those fractional launchers may even make the matter worse as it may end up being possible to build an anti-missile that is 1.3-1.6 MSP that has 90% interception chance or so. It's difficult to say without having access to the finished game, but this is what I fear.

4. I think it is a serious problem. It could however be fixed with making box launchers larger.
Per msp missile size if you have 3 HS giving you 2 launchers + 1 HS magazine you can fit in 16+2 missiles at 80% efficiency. The same size in box launchers fits you 20! missiles, more than the re-loadable solution.


I'm afraid you forgot that capacity has to be divided by missiles size. 1HS magazine will give you 16 capacity allowing you to carry five missiles, for a total of seven. However I would argue that your example isn't really that good, for in that situation you could five only three times per launcher. If you build them to fire 7+ salvoes magazines are much more efficient way to store missiles than box launchers. So box launchers are already a tredeoff - lower total ammunition capacity in exchange for firing all of it at once.

As for gauss cannons, one possibility to make smaller missile sizes viable would be to limit the amount of shots that can be fired on the same missile.

I"m afraid you're forgetting "bonus tracking vs missiles" tech. Gauss cannons are very, very accurate and it's very rare for them to need to fire more than two shots to take down incoming shipkillers of equivalent technology level. At least I think so, can't be bothered to do the math right now.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 06, 2018, 12:55:05 PM
In VB6, civilians tend to build mining colonies on their own. While nice, I would like to have more control over, where they are allowed to do that. The game I guess has several parameters as to what would be ideal for the civis to build such a base. Maybe making these available and editable might be enough control. If not, the ideal is always body-individual rights-setting  ;)
Title: Re: C# Aurora v0.x Suggestions
Post by: Kytuzian on September 06, 2018, 03:08:02 PM
Regarding civilians, it would be cool if there were more types of civilian ships (e.g., terraformers, jump gate constructors, asteroid miners (though I realize this partially filled by civilian mining colonies), etc.) which we could support/influence via government contracts for some amount of money.

Also it would be nice if we could get civilian fuel harvesters to automatically drop off the fuel at colonies so we don't have to send our ships out to them, which I personally find annoying.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on September 06, 2018, 03:08:14 PM
I'm afraid you forgot that capacity has to be divided by missiles size. 1HS magazine will give you 16 capacity allowing you to carry five missiles, for a total of seven. However I would argue that your example isn't really that good, for in that situation you could five only three times per launcher. If you build them to fire 7+ salvoes magazines are much more efficient way to store missiles than box launchers. So box launchers are already a tredeoff - lower total ammunition capacity in exchange for firing all of it at once.
No, I did not. Assuming size n missiles and you invest 3*n HS into 2 launchers and n HS magazine space, you end up with the 16+2 missiles for launchers vs 20 for box launchers. I am arguing that the trade off is just way off, assuming 9 salvos vs firing the same all at once it is always better to have the box launchers.
Quote
I"m afraid you're forgetting "bonus tracking vs missiles" tech. Gauss cannons are very, very accurate and it's very rare for them to need to fire more than two shots to take down incoming shipkillers of equivalent technology level. At least I think so, can't be bothered to do the math right now.
Yeah, that would also need to be nerfed to make low salvo sizes of missiles more useful. Maybe also increase the range at which missiles are engaged by final PD as their speed increases.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on September 06, 2018, 05:43:55 PM
Was just looking back over the rules changes and the new ground units. What has struck me as odd is the need to attach large lumbering tanks to all larger units in order to fit in the HQ component. This is going to look particularly odd if you have a bunch of for example jungle trained troops who then end up with something that would not exactly be fit for such terrain. I was therefore wondering if a split version of these units could be created as an alternative such that a series of light vehicles could do the job of one large mounted unit. I expect along with this you would have to deal with partial damage to the units / loss of some but not all but would think you could have some simple rules that noted if you lost more than 25% or so of units the HQ bonus would cease to function. Hopefully that would be a lot of overhead to maintain some more balanced unit templates.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on September 07, 2018, 01:51:45 AM
Was just looking back over the rules changes and the new ground units. What has struck me as odd is the need to attach large lumbering tanks to all larger units in order to fit in the HQ component. This is going to look particularly odd if you have a bunch of for example jungle trained troops who then end up with something that would not exactly be fit for such terrain. I was therefore wondering if a split version of these units could be created as an alternative such that a series of light vehicles could do the job of one large mounted unit. I expect along with this you would have to deal with partial damage to the units / loss of some but not all but would think you could have some simple rules that noted if you lost more than 25% or so of units the HQ bonus would cease to function. Hopefully that would be a lot of overhead to maintain some more balanced unit templates.

While I agree on principle that large vehicle might not be suitable for jungle combat we assume that these vehicles are like tanks today. We could easily immagine them as hovering vehicles with limited flight capabilities that can skimmer over trees and hide pretty much anywhere among the top of the trees and act as artillery for soldiers or lighter vehicles on the ground. I could see future tanks be a cross between a tank and a helicopter more or less with anti-gravity technologies.

Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on September 07, 2018, 12:14:35 PM
Was just looking back over the rules changes and the new ground units. What has struck me as odd is the need to attach large lumbering tanks to all larger units in order to fit in the HQ component. This is going to look particularly odd if you have a bunch of for example jungle trained troops who then end up with something that would not exactly be fit for such terrain. I was therefore wondering if a split version of these units could be created as an alternative such that a series of light vehicles could do the job of one large mounted unit. I expect along with this you would have to deal with partial damage to the units / loss of some but not all but would think you could have some simple rules that noted if you lost more than 25% or so of units the HQ bonus would cease to function. Hopefully that would be a lot of overhead to maintain some more balanced unit templates.
Are you sure vehicles are required at all? In the rules post example (http://aurora2.pentarch.org/index.php?topic=8495.msg105832#msg105832) I can see infantry HQ units only one level below the highest tank-based HQ.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on September 07, 2018, 12:32:12 PM

In VB6, civilians tend to build mining colonies on their own. While nice, I would like to have more control over, where they are allowed to do that. The game I guess has several parameters as to what would be ideal for the civis to build such a base. Maybe making these available and editable might be enough control. If not, the ideal is always body-individual rights-setting  ;)
If the issue is that the mines are popping up in poor places, economically soaking, I think reworking the system for determining where they open is a better solution, though I'd like to see an economic overhaul in general.

6. Several times now I attempted to create a merchant powers, small nations which relied on trade income to function. I failed every time. The coming changes to trade will help a lot, but the main issue is that shipping lines always build colony ships - even when there is nothing to colonise (small nation don't do much of it after all). Which means their income is spent on useless ships, making it much more difficult for them to grow (they can even fail completely) and creating less taxes. As such I'd love to see an option to prevent shipping lines from building a specific type of ship, so that they would build only what's profitable.
With the economy as simplistic as it is, I don't think you'll manage to do much even with such a change.

I think the game would benefit significantly from a more robust economic model, including things such as tracking the wealth/prosperities of individual colonies, tracking TN minerals sent to the civilian economy as a trade good, requiring shipping lines to purchase TN minerals fur ships, requiring the civilian economy to expend TN minerals to create civilian mining complexes, more robust AI to handle this kind of thing.  Any kind of economy overhaul would require a serious amount of work, however, and at this point I wouldn't want to see it delay the initial release of C#.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on September 07, 2018, 12:40:44 PM
Was just looking back over the rules changes and the new ground units. What has struck me as odd is the need to attach large lumbering tanks to all larger units in order to fit in the HQ component. This is going to look particularly odd if you have a bunch of for example jungle trained troops who then end up with something that would not exactly be fit for such terrain. I was therefore wondering if a split version of these units could be created as an alternative such that a series of light vehicles could do the job of one large mounted unit. I expect along with this you would have to deal with partial damage to the units / loss of some but not all but would think you could have some simple rules that noted if you lost more than 25% or so of units the HQ bonus would cease to function. Hopefully that would be a lot of overhead to maintain some more balanced unit templates.
Are you sure vehicles are required at all? In the rules post example (http://aurora2.pentarch.org/index.php?topic=8495.msg105832#msg105832) I can see infantry HQ units only one level below the highest tank-based HQ.

They aren't needed. You can create infantry HQs.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on September 07, 2018, 01:53:20 PM
Was just looking back over the rules changes and the new ground units. What has struck me as odd is the need to attach large lumbering tanks to all larger units in order to fit in the HQ component. This is going to look particularly odd if you have a bunch of for example jungle trained troops who then end up with something that would not exactly be fit for such terrain. I was therefore wondering if a split version of these units could be created as an alternative such that a series of light vehicles could do the job of one large mounted unit. I expect along with this you would have to deal with partial damage to the units / loss of some but not all but would think you could have some simple rules that noted if you lost more than 25% or so of units the HQ bonus would cease to function. Hopefully that would be a lot of overhead to maintain some more balanced unit templates.
Are you sure vehicles are required at all? In the rules post example (http://aurora2.pentarch.org/index.php?topic=8495.msg105832#msg105832) I can see infantry HQ units only one level below the highest tank-based HQ.

They aren't needed. You can create infantry HQs.

Ah ok so if I have a large infantry formation that needs say 10000 tons of control I can meet this with infantry based hq units? Sorry was not clear to me from the original post.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on September 08, 2018, 05:47:07 AM
Ah ok so if I have a large infantry formation that needs say 10000 tons of control I can meet this with infantry based hq units? Sorry was not clear to me from the original post.

Yes, you can do that. You can use the single infantry component slot for any size of HQ.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 08, 2018, 08:55:06 AM
I think the game would benefit significantly from a more robust economic model, including things such as tracking the wealth/prosperities of individual colonies, tracking TN minerals sent to the civilian economy as a trade good, requiring shipping lines to purchase TN minerals fur ships, requiring the civilian economy to expend TN minerals to create civilian mining complexes, more robust AI to handle this kind of thing.  Any kind of economy overhaul would require a serious amount of work, however, and at this point I wouldn't want to see it delay the initial release of C#.
The focus of Aurora is the unit design - and we will get a lot of that in C#. And I fully agree that Aurora does not need a delay because of economics rework. If Steve would be interested in an later economics rework, there could be a separate thread created for discussions about it.

The main idea for my initial post was, preventing them from grabbing the ones I would like to mine myself. But I learned since, that I simply need to establish an empty colony there, then they would ignore it.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 08, 2018, 09:03:21 AM
I was wondering if the collected intelligence points of alien populations should decrease over time if no active intelligence is done? It sounded to me that the points stay at the level they once gained forever, but that sounds a bit off to me... . Although a very nice solution in general for espionage.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on September 08, 2018, 09:19:42 AM
I was wondering if the collected intelligence points of alien populations should decrease over time if no active intelligence is done? It sounded to me that the points stay at the level they once gained forever, but that sounds a bit off to me... . Although a very nice solution in general for espionage.

There are pros and cons both ways. For example, it might be odd from a player perspective if you knew there were 100 factories on a planet last time you checked but now you have no idea because you dropped below the level where that information is available. Either way, it is a compromise.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 08, 2018, 09:28:44 AM
I was wondering if the collected intelligence points of alien populations should decrease over time if no active intelligence is done? It sounded to me that the points stay at the level they once gained forever, but that sounds a bit off to me... . Although a very nice solution in general for espionage.

There are pros and cons both ways. For example, it might be odd from a player perspective if you knew there were 100 factories on a planet last time you checked but now you have no idea because you dropped below the level where that information is available. Either way, it is a compromise.
I see. Maybe you can save the ‚time gone‘ since last active intelligence and every new beginning has to first overcome ‚re-contact-phase‘ and then have full access to previous data. The length of that ‚re-contact-phase‘ could be like 1/10th of ‚time gone‘, capped by a maximum of 6 month.
So gone for 2 years would mean 2.4 month re-contact-Phase, etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 08, 2018, 09:39:43 AM
AI empires will be more versatile in C# Aurora. It although would be nice for Spacemasters to give an AI empire a general direction from time to time. To steer global events... :-)
Would that be possible?
Title: Re: C# Aurora v0.x Suggestions
Post by: mtm84 on September 08, 2018, 12:55:21 PM
Just saw the ELINT addition, sounds great, but how about a reduced effectiveness fighter only sized module as well?
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on September 08, 2018, 01:00:55 PM
I was wondering if the collected intelligence points of alien populations should decrease over time if no active intelligence is done? It sounded to me that the points stay at the level they once gained forever, but that sounds a bit off to me... . Although a very nice solution in general for espionage.

There are pros and cons both ways. For example, it might be odd from a player perspective if you knew there were 100 factories on a planet last time you checked but now you have no idea because you dropped below the level where that information is available. Either way, it is a compromise.
I see. Maybe you can save the ‚time gone‘ since last active intelligence and every new beginning has to first overcome ‚re-contact-phase‘ and then have full access to previous data. The length of that ‚re-contact-phase‘ could be like 1/10th of ‚time gone‘, capped by a maximum of 6 month.
So gone for 2 years would mean 2.4 month re-contact-Phase, etc.

I like this idea. It'd be rather... odd if you had data on a planet/population from 20 years ago and instantly get a complete update on the vastly changed economy of the planet just because an ELINT craft got vaguely close.

I'm not sure I like the idea of having the modules act as EM sensors. I'd rather they used the vessel's EM sensor rating instead as that avoids having to choose between having a large EM sensor to pick up foreign vessels and populations or a large number of ELINT modules to gather intelligence from great range.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on September 08, 2018, 01:18:51 PM
There are pros and cons both ways. For example, it might be odd from a player perspective if you knew there were 100 factories on a planet last time you checked but now you have no idea because you dropped below the level where that information is available. Either way, it is a compromise.

Could it be handled the same way you do with legacy data?

"The information regarding a specific population will remain static if ELINT monitoring ends but will be updated once an ELINT ship is back in range."

Ideally if you drop below the level where it's displayed what could happens is you still see the latest known amount but with some note after it saying something like "( old data from year X month Y )"
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on September 08, 2018, 01:41:20 PM
I'm not sure I like the idea of having the modules act as EM sensors. I'd rather they used the vessel's EM sensor rating instead as that avoids having to choose between having a large EM sensor to pick up foreign vessels and populations or a large number of ELINT modules to gather intelligence from great range.

It is to avoid the situation of detecting ELINT emissions from something that hasn't been detected any other way. By making them EM sensors too, that can't happen. Also provides a useful backup if the primary sensors go down.

I don't want ELINT to use the ship's primary sensors as that would make ELINT too powerful. Currently it is 1/10th of normal EM capability.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on September 08, 2018, 01:41:53 PM
There are pros and cons both ways. For example, it might be odd from a player perspective if you knew there were 100 factories on a planet last time you checked but now you have no idea because you dropped below the level where that information is available. Either way, it is a compromise.

Could it be handled the same way you do with legacy data?

"The information regarding a specific population will remain static if ELINT monitoring ends but will be updated once an ELINT ship is back in range."

Ideally if you drop below the level where it's displayed what could happens is you still see the latest known amount but with some note after it saying something like "( old data from year X month Y )"

Yes, after I posted it struck me I could probably do this.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on September 08, 2018, 04:34:30 PM
It is to avoid the situation of detecting ELINT emissions from something that hasn't been detected any other way. By making them EM sensors too, that can't happen. Also provides a useful backup if the primary sensors go down.

I don't want ELINT to use the ship's primary sensors as that would make ELINT too powerful. Currently it is 1/10th of normal EM capability.

This can be handled by 1) making it impossible to gather ELINT without the ship receiving EM sensor readings and by an 'efficiency' modifier that restricts the ELINT module from operating above an effective 1/10th the ship's sensor rating.

Of course, I've no idea how you are programming ships to interact with their own parts so I don't know if this sort of dependency is possible.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on September 08, 2018, 05:41:38 PM
I don't want ELINT to use the ship's primary sensors as that would make ELINT too powerful. Currently it is 1/10th of normal EM capability.

I agree, IMO this makes alot of sense logically as well. Regardless of what type of sensor you use your not going to be learning much about a sensor contact at absolute maximum range where you pick up a signal that's just faint enough for you to even be able to tell that something is there.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on September 08, 2018, 07:12:02 PM
Is there any way we could have the ability to detect/estimate weapon loadouts?  There are lots of other things that would be nice to detect in addition to that, but I'd argue that would be one of the most useful ones.

Alternatively, maybe have the intel rating be an empire wide thing, and it decays as a result of new sensor designs or techs?  I think its reasonable to say that an empire would generally follow certain design motifs, and thusly it would be fair to say that if you have seen most of their sensors for a time, you have effectively seen all of them.

As it is I find it hard to see myself making much use out of the ELINT modules, unless the stealth bonus is really really massive.  Because as it is it kindof sounds like the enemy not using certain sensors most of the time, or spending a month developing some new one, could completely invalidate your intel gathering efforts.  I tend not to use my really big sensors most of the time even as it is unless I passively detect a reason to turn them on, to avoid making a target out of the sensor ships.

e:  regarding using regular sensors as the intel modules, perhaps the ELINT modules are these big old analysis computer banks you have to add in addition to the sensors they use?  then they gather intel based on what sensors are detecting the enemy, and the quality of the intel is based on how well you are detecting the enemy.  for instance, perhaps a percentage of how much your sensor is overkill for a particular detection.  it sounds more elegant to me, but I freely admit that I could be wrong on that.  im a bit sleep deprived you see.

e2: ok done editing
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on September 09, 2018, 07:07:25 AM
There are pros and cons both ways. For example, it might be odd from a player perspective if you knew there were 100 factories on a planet last time you checked but now you have no idea because you dropped below the level where that information is available. Either way, it is a compromise.

Could it be handled the same way you do with legacy data?

"The information regarding a specific population will remain static if ELINT monitoring ends but will be updated once an ELINT ship is back in range."

Ideally if you drop below the level where it's displayed what could happens is you still see the latest known amount but with some note after it saying something like "( old data from year X month Y )"

I've updated the original rules post with the following:

The intelligence points for a specific population will reduce at approximately 25% per year if ELINT monitoring ends. The information that was gained while intelligence points were at their highest point will remain and is shown in red when viewing the alien population on the Diplomacy window. Current information is shown in green.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on September 10, 2018, 06:38:28 AM
Really like the ELINT plans although must admit I will miss the old teams on the ground; have had some good RP fun with them in the past. A couple more thoughts on the current rules:

- Not done any looking at the maths of relative EM emissions of a decent planet versus their typical thermal detection range but with revisions to passive sensor range I'm wondering how practical it will really be to get a ship able to collect points without being readily detected by the hostile planet. Look forward to seeing how that works on playtesting.

- Are you considering a ground installation version of this or to have it as a ground unit type? I could happily see people wanting to drop of units or an installation on an out of the way asteroid somewhere to be able to snoop on other races and would hope that also changes the interplay on thermal detection range and sensor range per the above point.

- Whilst probably not wanting to get into the world of encryption I wonder if a very high tier of points could be classed as you having cracked their communications and hence be able to obtain a chance of seeing orders issued to ships or units.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on September 10, 2018, 06:56:11 AM
Really like the ELINT plans although must admit I will miss the old teams on the ground; have had some good RP fun with them in the past. A couple more thoughts on the current rules:

- Not done any looking at the maths of relative EM emissions of a decent planet versus their typical thermal detection range but with revisions to passive sensor range I'm wondering how practical it will really be to get a ship able to collect points without being readily detected by the hostile planet. Look forward to seeing how that works on playtesting.

- Are you considering a ground installation version of this or to have it as a ground unit type? I could happily see people wanting to drop of units or an installation on an out of the way asteroid somewhere to be able to snoop on other races and would hope that also changes the interplay on thermal detection range and sensor range per the above point.

- Whilst probably not wanting to get into the world of encryption I wonder if a very high tier of points could be classed as you having cracked their communications and hence be able to obtain a chance of seeing orders issued to ships or units.

I am considering ground and installation versions of ELINT.

I also considered having encryption and decryption research projects, but for the moment decided that was too much micromanagement. The modification based on Xenophobia is intended to simulate that races concerned about aliens would invest into more secure communications and restrict public information. If I get back into government types, I might use that instead.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on September 10, 2018, 10:27:22 AM
Really like the ELINT plans although must admit I will miss the old teams on the ground; have had some good RP fun with them in the past. A couple more thoughts on the current rules:

- Not done any looking at the maths of relative EM emissions of a decent planet versus their typical thermal detection range but with revisions to passive sensor range I'm wondering how practical it will really be to get a ship able to collect points without being readily detected by the hostile planet. Look forward to seeing how that works on playtesting.

- Are you considering a ground installation version of this or to have it as a ground unit type? I could happily see people wanting to drop of units or an installation on an out of the way asteroid somewhere to be able to snoop on other races and would hope that also changes the interplay on thermal detection range and sensor range per the above point.

- Whilst probably not wanting to get into the world of encryption I wonder if a very high tier of points could be classed as you having cracked their communications and hence be able to obtain a chance of seeing orders issued to ships or units.

I am considering ground and installation versions of ELINT.

I also considered having encryption and decryption research projects, but for the moment decided that was too much micromanagement. The modification based on Xenophobia is intended to simulate that races concerned about aliens would invest into more secure communications and restrict public information. If I get back into government types, I might use that instead.
Is not Electronic a misnomer both for ELINT and EM sensors? Active sensors are FTL, and so seems to be interstellar communication.
I doubt much electronic information can be gathered from a single planet, as any advanced civilization will likely put as much as possible of their internal communications into optical fibers, or short range radios that are highly focused on satellites for uplink, and pointed at the planet from satellites to ground.
This only really leaves communications between systems to be intercepted, but at these ranges, you likely aim at the entire system, and not anything in particular in it. Also, since every unit has comm gear that can pick up interstellar communication, it does not seem like you need special antennas for picking up that kind of transmission.
Title: Re: C# Aurora v0.x Suggestions
Post by: TCD on September 10, 2018, 12:49:03 PM
Is not Electronic a misnomer both for ELINT and EM sensors? Active sensors are FTL, and so seems to be interstellar communication.
I doubt much electronic information can be gathered from a single planet, as any advanced civilization will likely put as much as possible of their internal communications into optical fibers, or short range radios that are highly focused on satellites for uplink, and pointed at the planet from satellites to ground.
This only really leaves communications between systems to be intercepted, but at these ranges, you likely aim at the entire system, and not anything in particular in it. Also, since every unit has comm gear that can pick up interstellar communication, it does not seem like you need special antennas for picking up that kind of transmission.
That's one technobabble interpretation, but there are many others. If TN comms tech has the advantage of FTL communication speeds then advanced civilizations might ditch fibre optic entirely and move everything into TN space for the speed advantage, opening themselves up to interception. Heck, maybe the entire internet goes TN wireless, and ELINT systems are mostly listening to facebook messages, and trying to deduce useful intelligence from that.
Title: Re: C# Aurora v0.x Suggestions
Post by: DEEPenergy on September 10, 2018, 09:36:56 PM
I'd like to suggest some way of one sided language translation, by ELINT or otherwise.  Monitoring alien communications with stealthed ships to translate their language to enhance interrogations sounds very fun.
Title: Re: C# Aurora v0.x Suggestions
Post by: TCD on September 11, 2018, 08:45:31 AM
I'd like to suggest some way of one sided language translation, by ELINT or otherwise.  Monitoring alien communications with stealthed ships to translate their language to enhance interrogations sounds very fun.
My problem is always how do you get the stealthed ships into the system? I don't think I've read anything to suggest that stealthed ships will be any better at getting past a jump picket in C#.

Maybe that could be tied into having a certain level of intelligence points? "Your advanced knowledge of Ebu sensor techniques improves stealth efficiency by a further X%."

Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on September 11, 2018, 11:45:37 AM
Even improved stealth efficiency can't get past a picket. I think it would be interesting to be able to design special jump engines that have a huge jump radius (maybe starting at around 10m km and getting higher with tech?) that can only jump one ship (no assisted transits or squadron jumps). Other downsides could be increased size, as is done with commercial drives, and a smaller maximum size. This would allow a stealth ship to jump in outside point-blank sensor range, or allow a fast, PD-equipped ship to escape more quickly. Obviously, these would be trapped in enemy territory, but that is a danger with any stealth ship design.
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on September 12, 2018, 12:25:53 AM
Is not Electronic a misnomer both for ELINT and EM sensors? Active sensors are FTL, and so seems to be interstellar communication.
I doubt much electronic information can be gathered from a single planet, as any advanced civilization will likely put as much as possible of their internal communications into optical fibers, or short range radios that are highly focused on satellites for uplink, and pointed at the planet from satellites to ground.
This only really leaves communications between systems to be intercepted, but at these ranges, you likely aim at the entire system, and not anything in particular in it. Also, since every unit has comm gear that can pick up interstellar communication, it does not seem like you need special antennas for picking up that kind of transmission.
EM sensors pick up electromagnetic radiation produced by electrial systems. ELINT might be a misnomer (though ELINT doesn't so much refer to picking up communication signals, in this case it could be the analysis of electro-magnetic signatures to figure things out) dpending on your particular scenario, but who cares, it's not exactly uncommon to keep using a term for the same practice even if the term gets technically outdated. And this is heavily dependent ont he scenario you are RPing.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on September 12, 2018, 03:47:31 AM
Even improved stealth efficiency can't get past a picket. I think it would be interesting to be able to design special jump engines that have a huge jump radius (maybe starting at around 10m km and getting higher with tech?) that can only jump one ship (no assisted transits or squadron jumps). Other downsides could be increased size, as is done with commercial drives, and a smaller maximum size. This would allow a stealth ship to jump in outside point-blank sensor range, or allow a fast, PD-equipped ship to escape more quickly. Obviously, these would be trapped in enemy territory, but that is a danger with any stealth ship design.

This sort of Jump Drive design could also be relevant if you want piracy or raiding ( AKA Space Submarines ) to be relevant weapons. ( If they can't get around jump point pickets they are not going to reach the rear lines ).

These Jump drives would need to take up big enough space to be prohibitive for use on your main warships, but small enough to still allow you to run stealth modules and some cheap reduced sized launcher weapon systems that can quickly and efficiently destroy freighters or civilian ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on September 12, 2018, 06:34:32 AM

This sort of Jump Drive design could also be relevant if you want piracy or raiding ( AKA Space Submarines ) to be relevant weapons. ( If they can't get around jump point pickets they are not going to reach the rear lines ).

These Jump drives would need to take up big enough space to be prohibitive for use on your main warships, but small enough to still allow you to run stealth modules and some cheap reduced sized launcher weapon systems that can quickly and efficiently destroy freighters or civilian ships.
Currently a jump drive and a cloak are pretty much taking up an entire ship already. I think regular jump drives need a buff in HS requirement first to make room a long range, larger jump drive. Also such a drive should work both ways (jumping into a point from afar, jumping out a good distance away), to not make any jump into enemy territory a suicide mission.
Maybe some other limits are possible to make them unsuitable for regular ships, maybe a maximum speed a cloak works at, or not improving the efficiency of the long range jump drive, but just its maximum size, and thus the maximum size of ship it can be used on.
For "submarines" improved handling of passive detectors would also help. A missile fire control should be able to guide a homing missile close enough to a target to have a 0.25 msp sensor on top of the missile pick up the target for final acquisition.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on September 12, 2018, 08:30:38 AM
Currently a jump drive and a cloak are pretty much taking up an entire ship already.

Only at the very first levels. ( First level is Efficiency 3 for both meaning you have 33% left for all other systems if you equip both )

At for example 5:th tech level you will have Efficiency 8 on both meaning you can make a ship with 75% left for all other systems if both are equipped. Basically you could even equip all your warships with it ( even if it would be costly it is within reach ).

At max tech levels ( Efficiency 15 ) You would need to allocate just 13% of your ship to both these systems leaving the remaining 87% free.

For balance any "Raiding" or "Scouting" Jump drive or what you want to call it would need to have a much flatter progression curve in tech, or be made so much significantly more expensive in resources that it's not feasible to equip large parts of your fleet with it.

For "submarines" improved handling of passive detectors would also help. A missile fire control should be able to guide a homing missile close enough to a target to have a 0.25 msp sensor on top of the missile pick up the target for final acquisition.

That's a good idea, and one that I have suggested before. The tricky question is how you don't make it unbalanced ( Basically what prevents everyone from always using just passive targeting? ). It needs to have some serious downsides too besides requiring a 0.25 msp sensor in each missile.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on September 12, 2018, 08:58:46 AM
It would save on a lot of clicking if we could issue the same orders to multiple task forces (or whatever they are now called) at the same time. Specifically I'm thinking of cases where you have multiple fighter squadrons or fac squadrons and you want them all to be heading to a new waypoint or all returning and refueling etc. I know you can save a set of orders and copy over currently but that is still quite fiddly if you want to do for a group of say 10 squadrons and you are regularly updating their orders. Was wondering is some sort of shift click to highlight multiple task forces would be possible.
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on September 12, 2018, 06:50:37 PM
If you wanted to give a serious downside to self targeting missiles, gives CIWS a significant bonus to hit against sensor equipped missiles. Something about how they're lighting themselves up with the sensor package pinging off. Then you could justify buffing the effective range of missile sensors. So for your big warships, if you want to get your warheads through a heavy missile defense in a proper fleet, you guide them in from a directed fire control. But if your picking off a lone merchant ship, or a handful of troop ships in a surprise attack, the trade off of using more missiles to achieve the same effective damage may be worth it.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 13, 2018, 01:02:41 AM
It would save on a lot of clicking if we could issue the same orders to multiple task forces (or whatever they are now called) at the same time. Specifically I'm thinking of cases where you have multiple fighter squadrons or fac squadrons and you want them all to be heading to a new waypoint or all returning and refueling etc. I know you can save a set of orders and copy over currently but that is still quite fiddly if you want to do for a group of say 10 squadrons and you are regularly updating their orders. Was wondering is some sort of shift click to highlight multiple task forces would be possible.
I guess, with the new system, you put them as subfleets in one fleet, send that to the waypoint and there split them up in subfleets again.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on September 13, 2018, 02:17:28 AM
Only at the very first levels. ( First level is Efficiency 3 for both meaning you have 33% left for all other systems if you equip both )

At for example 5:th tech level you will have Efficiency 8 on both meaning you can make a ship with 75% left for all other systems if both are equipped. Basically you could even equip all your warships with it ( even if it would be costly it is within reach ).

At max tech levels ( Efficiency 15 ) You would need to allocate just 13% of your ship to both these systems leaving the remaining 87% free.

For balance any "Raiding" or "Scouting" Jump drive or what you want to call it would need to have a much flatter progression curve in tech, or be made so much significantly more expensive in resources that it's not feasible to equip large parts of your fleet with it.
I still think the Jump drive needs a buff (Move it up a tech level or two) to make room for the second drive early enough if you want it available somewhere in the midgame where cloaks become available. The cloak progression line could also be flattened out, with a size reduction for less efficient cloaks. So you can build small, reduced efficiency cloaks.

Quote
That's a good idea, and one that I have suggested before. The tricky question is how you don't make it unbalanced ( Basically what prevents everyone from always using just passive targeting? ). It needs to have some serious downsides too besides requiring a 0.25 msp sensor in each missile.
For one active sensors should outrange thermal sensors, and if you fire at an EM target, your enemy always may turn off their emissions. A further downside could be that your homing missiles pick their targets themselves, any they can detect, which may not be the one you intended. So in a fleet battle this will lead to very poor focus firing.
If you want, you could also give missiles a to-hit modifier depending on the sensor strength and range, but for consistency MFC should be affected by this too. So active sensor head missiles would be more accurate than passive sensor head missiles, and active ship targeting should be more accurate than sensor head missiles, and combined active ship targeting+ sensor head would be most accurate. Please note if you throw in ECCM and ECM on a missile, you are already using up 0.75 MSP, which will definitely push up missile size. ECCM seems like a must, you cannot accept a -20 or -30 % hit chance decrease.

If you wanted to give a serious downside to self targeting missiles, gives CIWS a significant bonus to hit against sensor equipped missiles. Something about how they're lighting themselves up with the sensor package pinging off. Then you could justify buffing the effective range of missile sensors. So for your big warships, if you want to get your warheads through a heavy missile defense in a proper fleet, you guide them in from a directed fire control. But if your picking off a lone merchant ship, or a handful of troop ships in a surprise attack, the trade off of using more missiles to achieve the same effective damage may be worth it.
Passive sensors don't light up, by definition of passive sensors. I also really dislike the idea of giving CIWS a bonus compared to other missile defenses. I for one only install CIWS on civilians, supply ships, my warships have dedicated firecontrol+sensor+guns arrangements for defense.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on September 14, 2018, 08:28:36 AM
A few more thoughts

A ground forces summary screen which shows the location of all ground forces and condition in one place, sortable both by the unit groupings but also location (when you get larger forces working out which planet they are on or what's in transit and to where can be a bit of a headache).

Replace the current fleet detachments UI with a micro map and a click and drag of ships into a desired location. Mini map could also show weapon and sensor ranges so you can make sure you have coverage. With the changes in sensors I think people will have to be detaching pickets and re-organising them far more often so something that makes this less of a fiddle would be great.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on September 14, 2018, 08:59:03 AM
A ground forces summary screen which shows the location of all ground forces and condition in one place, sortable both by the unit groupings but also location (when you get larger forces working out which planet they are on or what's in transit and to where can be a bit of a headache).

Already got this one :)

I don't think I have shown a screenshot yet but this is on a tab of the Ground Forces window. You can show a hierarchy by command structure regardless of location, or the hierarchy at each location (in a tree view). I'll add a screenshot when I get home.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 14, 2018, 03:00:39 PM
Thinking about the planetary production - especially the area when you have shortages in manpower. There is but little control over where the workers go; just the genral shut down of the different areas - and you can only shut them down completly or let them run fully.
I know that the production efficiency value provides a simple calculation for the entire industry - but I think C# can handle a little more over where the workers go during a shortage, so a little more control might be nice... like being able to control how much of an industry area is going to be shut down (mabye in 10 or 20% steps?).
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 14, 2018, 03:40:13 PM
I guess, space stations will be completly stationary, as they were in VB6 Aurora. Although it might be nice to have a station rotate around another object at a given speed... . At a cost of certain amount of fuel... .
Title: Re: C# Aurora v0.x Suggestions
Post by: Tree on September 14, 2018, 04:49:47 PM
I guess, space stations will be completly stationary, as they were in VB6 Aurora. Although it might be nice to have a station rotate around another object at a given speed... . At a cost of certain amount of fuel... .
Man, I hope the Moon never runs out of fuel. Would be annoying if it fell back on Earth.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 15, 2018, 04:07:24 PM
I guess, space stations will be completly stationary, as they were in VB6 Aurora. Although it might be nice to have a station rotate around another object at a given speed... . At a cost of certain amount of fuel... .
Man, I hope the Moon never runs out of fuel. Would be annoying if it fell back on Earth.
The idea with the fuel came from the base, that propulsion through TN engines happens outside of normal spacetime, and once you stop that engine, the ship stops... :-)
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 16, 2018, 05:46:36 AM
Quality of Life: Older Modules like "Geological Survey Sensors" should be excludable in the class design window, once the improved versions are available.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on September 16, 2018, 06:09:00 AM
Quality of Life: Older Modules like "Geological Survey Sensors" should be excludable in the class design window, once the improved versions are available.

You can make them obsolete and they won't appear (in VB6 and C#).
Title: Re: C# Aurora v0.x Suggestions
Post by: Rich.h on September 16, 2018, 10:03:56 AM
To throw an extra cog in the wheels of jump drives, how about a third type approach? So have a stealth jump drive that has the huge range and single ship capacity, but allow it to only work on "stealth" drives. I am guessing it wouldn't take much to add in a new drive engine type, just make them have a low power thrust output, with larger sizes than standard military and smaller than current commercial drives.

To avoid them being put onto a commercial vessel, just make them give error flags if they are used with components such as cargo bays etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on September 16, 2018, 03:51:17 PM
Actually, you can already make 'stealth' engines in Aurora. You just need to research and implement the lower thermal signature tech line on that drive.

It drives up the cost of the engine though.
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on September 16, 2018, 04:35:48 PM
Actually, you can already make 'stealth' engines in Aurora. You just need to research and implement the lower thermal signature tech line on that drive.

It drives up the cost of the engine though.

He is talking about a special jump drive like the one I suggested a couple pages back, not a regular engine.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on September 16, 2018, 05:27:09 PM
Seems more like he's mixing up engines with jump drives.
Title: Re: C# Aurora v0.x Suggestions
Post by: DIT_grue on September 17, 2018, 02:15:02 AM
To throw an extra cog in the wheels of jump drives, how about a third type approach? So have a stealth jump drive that has the huge range and single ship capacity, but allow it to only work on "stealth" drives. I am guessing it wouldn't take much to add in a new drive engine type, just make them have a low power thrust output, with larger sizes than standard military and smaller than current commercial drives.

To avoid them being put onto a commercial vessel, just make them give error flags if they are used with components such as cargo bays etc.

Actually, you can already make 'stealth' engines in Aurora. You just need to research and implement the lower thermal signature tech line on that drive.

It drives up the cost of the engine though.

He is talking about a special jump drive like the one I suggested a couple pages back, not a regular engine.

Seems more like he's mixing up engines with jump drives.

Rich.h was clearly talking about adding a third category of both engines and jump drives with a parallel restriction to the existing division: as commercial jump drives can't move ships with military engines, the stealth jump drive could only move ships with stealth engines (rather than military jump drives that can move anything). Hazard is of course correct that using Thermal Reduction in the role of 'stealth engine' would make more sense than adding another tech line for the purpose.

As for my own initial reaction, I think it looks extremely game-arbitrary without any obvious technobabble logic for why it works that way. (There are obvious reasons you might want to combine the two on a ship, but not why TN physics should insist they must be). While I am tempted by the idea of having an option other than 'frontal assault' or 'survey until you find a back door' for breaking past a defended jump point, I'm not convinced this would be a useful way to try and balance it. (And when I phrase it that way, the dilemma is very iconic Starfire, so it mostly depends whether Steve actually wants to break from that or not - I think either way could turn out to be fun or frustrating depending on the player and the game.)
Title: Re: C# Aurora v0.x Suggestions
Post by: Rich.h on September 17, 2018, 04:11:31 AM
I think the issue with altering tech lines is that you would quickly loose the speciality of something like a stealth engine. Sure enough you can extend a part of the jump engine tech line so that eventually you get engines that can do a jump 50-100mkm away from the jump point. But then if you have the industrial capacity, why not just make every single military drive a super stealth version and gain the ability to jump entire fleets straight past a JP blockade.

At least with a thrid line of thrust drives & jump drives, it keeps an element of strategic planning for ships types rather than the "one does all"
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 17, 2018, 07:56:55 AM
Quality of Life: Older Modules like "Geological Survey Sensors" should be excludable in the class design window, once the improved versions are available.

You can make them obsolete and they won't appear (in VB6 and C#).
I can't find that in VB6. Any tips where I can do that?
Title: Re: C# Aurora v0.x Suggestions
Post by: Rich.h on September 17, 2018, 08:14:28 AM
Quality of Life: Older Modules like "Geological Survey Sensors" should be excludable in the class design window, once the improved versions are available.

You can make them obsolete and they won't appear (in VB6 and C#).
I can't find that in VB6. Any tips where I can do that?

Button is on the F5 screen as shown in the attachment.
Title: Re: C# Aurora v0.x Suggestions
Post by: mandalorethe1st on September 18, 2018, 11:15:01 AM
Will missiles be able to be cloaked and have  thermally reduced engines?  I see this as a way to defeat the late game missile deadlock.   They will also be useful for space submarines, encouraging very large, very hard to find torpedoes with correspondingly large warheads.   
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on September 19, 2018, 02:08:16 PM
I had an additional idea for ground combat. Preferential targeting during combat leads to favoring monolithic unit compositions and army compositions to minimize damage, but I was thinking what about preferential targeting against optimal weapon matches during the formation targeting phase, but unweighted targeting during the actual combat phase?
This would represent commanders picking good matches for engaging formations, and it would lead to favor mixing up units, as otherwise your tanks will face mostly heavy guns, while your infantry runs into heavy machineguns. For mixed formations, there is no obvious optimal match.
The bonus could scale with commander skill, making well led armies taking better engagements.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on September 19, 2018, 04:37:30 PM
I had an additional idea for ground combat. Preferential targeting during combat leads to favoring monolithic unit compositions and army compositions to minimize damage, but I was thinking what about preferential targeting against optimal weapon matches during the formation targeting phase, but unweighted targeting during the actual combat phase?
This would represent commanders picking good matches for engaging formations, and it would lead to favor mixing up units, as otherwise your tanks will face mostly heavy guns, while your infantry runs into heavy machineguns. For mixed formations, there is no obvious optimal match.
The bonus could scale with commander skill, making well led armies taking better engagements.

This ends up having its own problems as well, either insuring that you want completely homogenous units (IE every formation having the same ratio of tanks to infantry) or else never wanting to mix different types of units on the same front line (if all of your front line forces are light vehicles, preferential targeting doesn't matter).

People keep suggesting preferential targeting and I think it's a bad idea. Random targeting is both keeping things simple and the best way to encouraged combined arms units.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on September 19, 2018, 05:23:19 PM

This ends up having its own problems as well, either insuring that you want completely homogenous units (IE every formation having the same ratio of tanks to infantry) or else never wanting to mix different types of units on the same front line (if all of your front line forces are light vehicles, preferential targeting doesn't matter).

People keep suggesting preferential targeting and I think it's a bad idea. Random targeting is both keeping things simple and the best way to encouraged combined arms units.
I don't see how random encourages combined armies, I don't see any synergy effect that makes combined arms. I am looking for some way to punish all tank formations, or any other single unit type formation, and I don't see how to do it without there being some difference if some units are in the same formation or somewhere else.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on September 19, 2018, 06:04:50 PM

This ends up having its own problems as well, either insuring that you want completely homogenous units (IE every formation having the same ratio of tanks to infantry) or else never wanting to mix different types of units on the same front line (if all of your front line forces are light vehicles, preferential targeting doesn't matter).

People keep suggesting preferential targeting and I think it's a bad idea. Random targeting is both keeping things simple and the best way to encouraged combined arms units.
I don't see how random encourages combined armies, I don't see any synergy effect that makes combined arms. I am looking for some way to punish all tank formations, or any other single unit type formation, and I don't see how to do it without there being some difference if some units are in the same formation or somewhere else.

Infantry are better at some things and tanks are better at some things, so all things being equal, you'd generally prefer to have armies be a mix of both. However, if units preferentially target what they're good at hurting, then that's a reason not to have both tanks and infantry available as targets - preferential targeting increases your effectiveness if an enemy has both infantry and tanks but does nothing if the enemy is all tanks or all infantry.

I don't see why you're particularly interested in making sure a combined arms army isn't a formation of tanks and a formation of infantry as opposed to two formations of both, though. I think a major point of the combat system so far is that for formations assigned to the same position it doesn't really matter if the formations are big or small or how they're organized.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on September 19, 2018, 09:49:17 PM
You punish single unit formations with your own single unit formations.  If someone has all tank formations, you bring nothing but anti-tank guns.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on September 20, 2018, 02:08:19 AM
You punish single unit formations with your own single unit formations.  If someone has all tank formations, you bring nothing but anti-tank guns.
No. You cannot adjust your unit composition on the fly. That leaves all the advantage to the attacker. The defender cannot know what kind of units an invader will bring, so he cannot make single unit formations, else they can be hard countered. The defender thus needs mixed units, which should be able to defeat any single unit formation that possibly attacks them to make it even worthwhile to attempt a defense.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on September 20, 2018, 07:35:31 AM
You punish single unit formations with your own single unit formations.  If someone has all tank formations, you bring nothing but anti-tank guns.
No. You cannot adjust your unit composition on the fly. That leaves all the advantage to the attacker. The defender cannot know what kind of units an invader will bring, so he cannot make single unit formations, else they can be hard countered. The defender thus needs mixed units, which should be able to defeat any single unit formation that possibly attacks them to make it even worthwhile to attempt a defense.

Can we please move this to the "C# Ground Combat" thread?  It looks like a revisit of previous discussions that Steve has already made a decision about, and it's showing all the signs of having a long back-and-forth that will distract from the suggestions thread.  The Ground Combat thread was introduced as a forum for that sort of discussion.

More generally, I think that everyone should keep in mind that Steve spent a LOT of time deciding on the ground combat mechanics, and that it has already delayed the C# Aurora release by several months.  So I would suggest that people try to focus on suggestions for "tweaks" or "refinements" to the system that he's decided on (and that can be decided on and coded up relatively quickly) rather than changes that would cause him to revisit the whole system, leading to further significant delay. 

If you still feel it's important to make such a suggestion, please put it in the Ground Combat thread and post a link in Suggestions, so that any back-and-forth that it generates doesn't fill up the Suggestions thread.  Remember that Steve uses the Suggestions thread as a "filing cabinet", so we want to make it easy to find unique suggestions by browsing the thread.

Thanks,
John
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on September 21, 2018, 12:48:20 AM
At the moment all of our ground forces and our enemies fight to the bitter end no matter what the odds. It would be great to see a bit of a morale overlay to this that means this is not always the case. At a very simple level I was thinking that when morale drops below a certain grade then there is a check each cycle as to whether the unit will seek to do one of several things:
- Cease to attack
- Look to move from a front line position to a rear position
- In very low morale surrender to the enemy creating PoWs and the potential to capture combat units such as tanks and artillery.

This is obviously pretty simplistic and I'm sure the rules could be expanded to cover items such as:
- Units with morale failures impacting the morale of other units - potentially leading to a rout
- Different modifiers on morale checks for elite units or the ability to create fanatical units that will fight to the death / robotic units that have no morale checks
- Higher morale losses when faced with overwhelming forces against you - could be a good reason not to reduce your unit size down too far to play with the mechanics.
- A system for dealing with PoWs including a similar interrogation system as with the Navy with chance to identify OOB of troops in theatre, details of weapon systems etc.
- Ability to surrender a very badly damaged unit in the hopes you might recover the PoWs at a later stage.

Hopefully this would mean no fighting to the bitter end in most circumstances.
Title: Re: C# Aurora v0.x Suggestions
Post by: hubgbf on September 21, 2018, 04:44:45 AM
At the moment all of our ground forces and our enemies fight to the bitter end no matter what the odds. It would be great to see a bit of a morale overlay to this that means this is not always the case. At a very simple level I was thinking that when morale drops below a certain grade then there is a check each cycle as to whether the unit will seek to do one of several things:
- Cease to attack
- Look to move from a front line position to a rear position
- In very low morale surrender to the enemy creating PoWs and the potential to capture combat units such as tanks and artillery.

This is obviously pretty simplistic and I'm sure the rules could be expanded to cover items such as:
- Units with moral failures impacting the morale of other units - potentially leading to a route
- Different modifiers on morale checks for elite units or the ability to create fanatical units that will fight to the death / robotic units that have no morale checks
- Higher morale losses when faced with overwhelming forces against you - could be a good reason not to reduce your unit size down too far to play with the mechanics.
- A system for dealing with PoWs including a similar interrogation system as with the Navy with chance to identify OOB of troops in theatre, details of weapon systems etc.
- Ability to surrender a very badly damaged unit in the hopes you might recover the PoWs at a later stage.

Hopefully this would mean no fighting to the bitter end in most circumstances.

And for the winner, ability to take prisonner (who said xenophobe?)
An ennemy not willing to take prisonner will certainly drive his opponent to a fight to the end, isn't it?
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on September 21, 2018, 11:50:33 AM
That reminded me of Halo
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 26, 2018, 11:27:30 AM
Quality of Life: Reduction of Micromanagement: adding tonnage to shipyards as well as adding slipways, should be easier. How about: Reducing it to One function where you type in the number of tonnage to add as well as the number of slipways. Time needed to build should be ‚easy enough‘ for the program to calculate.

Task Force commands: when a TF finishes it’s list, that causes a time progression break. Good feature. However, not all finishing does need that (e.g. transferring a fleet of mining ships to a new location. Nice to see, that they have arrived, but that does not need to break time progression). An option field in the task screen where you can select ‚don’t break time progression at end of list‘ would be nice. Default is off, and if you don’t want a break, you have to activate it. When list s done it is automatically set off again. So next time if needed it would break again by default.

We do have mass drivers for easier mineral harvesting. How about an additional research tech for a frozen fuel slingshot? Fuel harvested at a gas giant could be ‚frozen‘ and then slingshotted to a target planet as well. Would make fuel harvesting as easy as mineral harvesting...

VB6 does not calculate the additional tonnage of a tugged ship into the time calculus of the TUG travel time. Will we get that in C#? Also, what will happen when we Tug a Tug a Tug... I guess the VB6 bug is no longer useable, right?

For long term planning of mineral harvesting it would be nice to have more statistics which could show ‚mineral usage of production over past x month‘. It is nice to see, that I have 540.000t of storage as well as seeing, that I gain 5.600t a year. But if that 5.600t is the tip of a +205.600t Mining and a 200.000t useage per year, I would want to have a bigger buffer rather than ‚only‘ 540.000t.

What is not possible as of yet, would be something in the line of ‚total war like in the last world war‘, where production efforts were more and more switched to military use. I am thinking of a system like in HOI4, where when transferred to Aurora, 75% work in service industries, that number could be changed. Switching them from service to manufacturing to go ‚mass production‘ for a total war, but loosing morale and general happiness of your population.
Such a system would need some thinking to make it balanced (so maybe for a later version of Aurora). What do you think? Worth implementing?
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on September 27, 2018, 03:48:20 PM
I don't like the fuel slingshot idea because the fuel harvester already refines raw gaseous Sorium into usable fuel. We have tankers and with the new refueling rules, fuel economy becomes more important, so I think such a feature would take away some of the importance of paying attention to your fuel harvesting and routing.

That TF progression break button is a great idea, as is the shipyard size thing, same for tug estimated time.

Mineral production is difficult because the system cannot know if you add stuff to production. We already have the bare minimum needed for ship maintenance per colony per year shown on the Industrial tab. Showing how many minerals were consumed last month is kinda useless since it depends so much on player actions. Ship maintenance via minerals is going away as well, so in C# there are, to my understanding, no constant mineral drains - it all depends on how much and what your colony is doing.

Agreed on forcibly changing service sector percentage, it just needs to have hefty enough penalties so that running with minimal service sector indefinitely does not become the obvious go-to solution. On the other hand, it would allow playing as more Hivemind-like races and worrying about how players "cheat" or not in a single-player game is kinda pointless.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on September 30, 2018, 08:28:12 PM
I would love a 'Bug Button' -- something we can click to 'Add Hive Mind NPR' to our game.  Whether it be Heinlein's original literary Bugs, or Starship Trooper's more B-movie sci-fi version, or Weber & White's deadly serious technologically adept Arachnid Omnivoractiy.  Ideally they would exist on a continuum of such, and vary from game to game (or even within games, if one were adventurous enough to add multiple such races).

I suppose what I'm asking for is half-spoiler race, half starting NPR.  To me the important part is the flavour -- massive overpopulation, massive industrial production, suicidal tactics, stunted technological growth, ground forces that are basically ten billion armoured infantry, the ability to consume other races' biomass for food, fuel, or whatever. . .
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on October 01, 2018, 04:35:06 AM
Now we have some serious logistics considerations in place I was thinking it would be good to also have some control on how this gets burned. Perhaps have three rates on use of supplies based on how intense you want to fight, ie low intensity, normal, high intensity. Low intensity would give penalties to hit but reduce the rate of supplies used, normal would be as is and high would increase chance to hit but drastically increase supplies usage as well.

I'd also suggest that the attacker would drive the rate of supplies used so if they were low intensity then the defending side would also be low intensity and if both attacked then the highest intensity selected by wither side would be the intensity of the battle.

You might use different rates if holding on for reinforcements or on the opposite side may look to up the ante to win before reinforcements arrived or if there was time pressure on the objective.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on October 01, 2018, 12:10:16 PM
I would love a 'Bug Button' -- something we can click to 'Add Hive Mind NPR' to our game.  Whether it be Heinlein's original literary Bugs, or Starship Trooper's more B-movie sci-fi version, or Weber & White's deadly serious technologically adept Arachnid Omnivoractiy.  Ideally they would exist on a continuum of such, and vary from game to game (or even within games, if one were adventurous enough to add multiple such races).

I suppose what I'm asking for is half-spoiler race, half starting NPR.  To me the important part is the flavour -- massive overpopulation, massive industrial production, suicidal tactics, stunted technological growth, ground forces that are basically ten billion armoured infantry, the ability to consume other races' biomass for food, fuel, or whatever. . .

I already plan to add this half-spoiler, half NPR concept to Aurora, although I hadn't mentally categorised it in those terms. NPRs have design themes that affect their entire approach, while species have characteristics that affect production, growth, research, etc.. I have also set it up so that different design themes will have different considerations for AI. For example, 'normal' AIs may withdraw from a system when badly outgunned while precursors will fight to the death. Different design themes also have different approaches to the composition of their ground forces.

I've been creating the scope for this flexibility because at some point I plan to run a WH40k campaign and I wanted to have the flavour of the various hostile races, some of which will be a spoiler-style menace and some will be more 'normal' NPRs. It will take a LOT of setup in terms of DB and code, but I can add new design themes and race types over time within the framework I've created.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on October 01, 2018, 12:10:55 PM
Now we have some serious logistics considerations in place I was thinking it would be good to also have some control on how this gets burned. Perhaps have three rates on use of supplies based on how intense you want to fight, ie low intensity, normal, high intensity. Low intensity would give penalties to hit but reduce the rate of supplies used, normal would be as is and high would increase chance to hit but drastically increase supplies usage as well.

I'd also suggest that the attacker would drive the rate of supplies used so if they were low intensity then the defending side would also be low intensity and if both attacked then the highest intensity selected by wither side would be the intensity of the battle.

You might use different rates if holding on for reinforcements or on the opposite side may look to up the ante to win before reinforcements arrived or if there was time pressure on the objective.

I will probably have something on these lines at some point, although perhaps not for the initial release.
Title: Re: C# Aurora v0.x Suggestions
Post by: db48x on October 04, 2018, 03:57:14 PM
On your recommendation I've just read the first chapter of Supplying War, and I'm compelled to ask if you've thought about armies plundering supplies from enemy territory at all? I suppose we could officially have gotten over that sort of thing, but when you're on an alien planet light-years from home and the round-trip time for your supply ships is measured in months... On the other hand, it is an alien biome.

Also, the new Sednoid 2015 TG387 would be fun to add to the game, if only because it's such a ridiculous distance away most of the time (it varies from ~65 AU to ~2000 AU).
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on October 06, 2018, 08:06:38 AM
Along with the new forces summary it would be helpful to have a munitions summary so you can see ammo stocks on various planets or perhaps various task groups in one place to help with planning.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on October 06, 2018, 09:49:58 AM
Not sure if added/suggested yet (probably was)

Preset orders for ships so you don't have to manually put the same orders for every ship, its a pain to do so.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on October 06, 2018, 10:35:19 AM
Not sure if added/suggested yet (probably was)

Preset orders for ships so you don't have to manually put the same orders for every ship, its a pain to do so.

Do you mean weapon assignments? Orders are at the fleet level.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on October 06, 2018, 12:13:47 PM
Not sure if added/suggested yet (probably was)

Preset orders for ships so you don't have to manually put the same orders for every ship, its a pain to do so.

Do you mean weapon assignments? Orders are at the fleet level.

No I meant conditional orders such as refueling/surveying.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on October 06, 2018, 12:57:05 PM
Do you mean weapon assignments? Orders are at the fleet level.

No I meant conditional orders such as refueling/surveying.

They are also at the fleet level.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on October 06, 2018, 01:48:27 PM
Not per fleet. Like say I wanted two fleets that survey individual systems, that should have the same conditional orders, I could simply select a preset of conditional orders, so like.

Code: [Select]
"Geo-Survey Preset"

Default Orders:
>Survey nearest body

Conditional Order A:
>If fuel is under 30%, refuel

And so I could apply it to each fleet.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on October 07, 2018, 08:09:58 AM
A fleet consisting of 25 14.000t Asteroid Miners is detected at the same distance as a single 14.000t Asteroid Miner. I think there should be some ‚penalty‘ for large assemblies of ships in terms of detectability. EM value accumulates for a civilization. Likewise it should for larger fleets. Not in a 1 to 1 scale, but something like: 10 ships a 14.000t  should be detectable like 1 ship a 28.000t.
Title: Re: C# Aurora v0.x Suggestions
Post by: tobijon on October 07, 2018, 08:21:29 AM
A fleet consisting of 25 14.000t Asteroid Miners is detected at the same distance as a single 14.000t Asteroid Miner. I think there should be some ‚penalty‘ for large assemblies of ships in terms of detectability. EM value accumulates for a civilization. Likewise it should for larger fleets. Not in a 1 to 1 scale, but something like: 10 ships a 14.000t  should be detectable like 1 ship a 28.000t.
This has a big problem when going by fleet: you can simply put all of the ships in different fleets, which would then be at the same location without increasing the detectable range. If you go by ships on one exact spot, that can be easily solved by letting all of the ships get near each other instead of on the sames spot. If you go by distance on the other hand, it would be very complicated calculation when which ship would be detected. In any case, i dont see how this could realisticly be implemented.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on October 07, 2018, 10:15:18 AM
This has a big problem when going by fleet: you can simply put all of the ships in different fleets, which would then be at the same location without increasing the detectable range. If you go by ships on one exact spot, that can be easily solved by letting all of the ships get near each other instead of on the sames spot. If you go by distance on the other hand, it would be very complicated calculation when which ship would be detected. In any case, i dint see how this could realistically be implemented.

Well, you are right that the player could game the system like you wrote ... the AI would not as it would not know how.. so it would only be a problem if the player wants to "game the system" himself.. as it is a singleplayer game and no MP I don't see a problem.. if the player whats to game the system in C# let him.. his/her loose...

I like the point TMaekler had... a fleet with more than 1 ship should have a higher energy output... 

but I guess this should wait till the next version of C# - I could think about a reason or two to have to re-balance the detection range again (lower again) than it is planed in C# so would just like to see how it works in C# as it is/is supposed to be
Title: Re: C# Aurora v0.x Suggestions
Post by: Peroox on October 07, 2018, 12:36:51 PM
Will be good to have more complexity in passive detection and electronic warfaree.  Imagine to use a bouy that generate passive footprint of ship and only a active scan can reveal that (or player because of ship behaviour).  There is a lot of things that can be add laterin C# version, but they are less important now. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on October 07, 2018, 03:17:51 PM
Ground combat morale as it is currently implemented is just an amplifier, as the stronger side gains morale for successful kills, and the weaker side loses morale for taking more damage.
That in itself is not very interesting, as it is essentially HP all over again. It would be way more interesting if only morale losses were amplified on front line attack, or units would even take morale damage for being on front line attack regardless of opposition, to simulate the strain of assault, and troops getting successively more disorganized, and not having time to rest and get their gear sorted out and repaired.

The interesting situations this could lead to is a stronger attacker wearing itself out to the point the defender can counterattack and defeat a stronger, low morale opponent. So for a successful attack you need to be quick enough, rotate your offensive formations, or let them recover, as currently there does not seem to be much incentive where you would ever want to stall a fight as the stronger force.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on October 07, 2018, 05:00:11 PM
Ground combat morale as it is currently implemented is just an amplifier, as the stronger side gains morale for successful kills, and the weaker side loses morale for taking more damage.
That in itself is not very interesting, as it is essentially HP all over again. It would be way more interesting if only morale losses were amplified on front line attack, or units would even take morale damage for being on front line attack regardless of opposition, to simulate the strain of assault, and troops getting successively more disorganized, and not having time to rest and get their gear sorted out and repaired.

The interesting situations this could lead to is a stronger attacker wearing itself out to the point the defender can counterattack and defeat a stronger, low morale opponent. So for a successful attack you need to be quick enough, rotate your offensive formations, or let them recover, as currently there does not seem to be much incentive where you would ever want to stall a fight as the stronger force.
This is a very good suggestion and something that has happened in actual military history. Morale could represent both the mental willingness to fight, as well as the general organization and cohesion of the unit, as well as their fatigue level. So repeated combat brings it down, being on defensive keeps it static, staying in the rear increases it slowly and being out of combat zone altogether makes it go up fast.
Title: Re: C# Aurora v0.x Suggestions
Post by: jonw on October 07, 2018, 08:03:02 PM
Ground combat morale as it is currently implemented is just an amplifier, as the stronger side gains morale for successful kills, and the weaker side loses morale for taking more damage.
That in itself is not very interesting, as it is essentially HP all over again. It would be way more interesting if only morale losses were amplified on front line attack, or units would even take morale damage for being on front line attack regardless of opposition, to simulate the strain of assault, and troops getting successively more disorganized, and not having time to rest and get their gear sorted out and repaired.

The interesting situations this could lead to is a stronger attacker wearing itself out to the point the defender can counterattack and defeat a stronger, low morale opponent. So for a successful attack you need to be quick enough, rotate your offensive formations, or let them recover, as currently there does not seem to be much incentive where you would ever want to stall a fight as the stronger force.

Seconded - isn't this kind of how it works in the gary grigsby games, with attack value (=morale) something you spend to attack, and which gets decreased by any attack, whether succesful or not?
Title: Re: C# Aurora v0.x Suggestions
Post by: Adseria on October 08, 2018, 07:08:09 AM
Ground combat morale as it is currently implemented is just an amplifier, as the stronger side gains morale for successful kills, and the weaker side loses morale for taking more damage.
That in itself is not very interesting, as it is essentially HP all over again. It would be way more interesting if only morale losses were amplified on front line attack, or units would even take morale damage for being on front line attack regardless of opposition, to simulate the strain of assault, and troops getting successively more disorganized, and not having time to rest and get their gear sorted out and repaired.

The interesting situations this could lead to is a stronger attacker wearing itself out to the point the defender can counterattack and defeat a stronger, low morale opponent. So for a successful attack you need to be quick enough, rotate your offensive formations, or let them recover, as currently there does not seem to be much incentive where you would ever want to stall a fight as the stronger force.

It could also mean that it would be worth keeping front line units in reserve, rather than just throwing everything you have at the enemy right at the start; that way, when the troops in the front line start to get worn down, you can pull them back and replace them with reserves, exactly the way it's happened throughout history.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on October 08, 2018, 07:51:42 AM
Ground combat morale as it is currently implemented is just an amplifier, as the stronger side gains morale for successful kills, and the weaker side loses morale for taking more damage.
That in itself is not very interesting, as it is essentially HP all over again. It would be way more interesting if only morale losses were amplified on front line attack, or units would even take morale damage for being on front line attack regardless of opposition, to simulate the strain of assault, and troops getting successively more disorganized, and not having time to rest and get their gear sorted out and repaired.

The interesting situations this could lead to is a stronger attacker wearing itself out to the point the defender can counterattack and defeat a stronger, low morale opponent. So for a successful attack you need to be quick enough, rotate your offensive formations, or let them recover, as currently there does not seem to be much incentive where you would ever want to stall a fight as the stronger force.
This is a very good suggestion and something that has happened in actual military history. Morale could represent both the mental willingness to fight, as well as the general organization and cohesion of the unit, as well as their fatigue level. So repeated combat brings it down, being on defensive keeps it static, staying in the rear increases it slowly and being out of combat zone altogether makes it go up fast.

I've been giving this some thought. What I am calling 'morale' is more like troop quality, improved by both training and combat experience but also potentially reduced by losses. What is described in the suggestion above as 'morale' is  a combination of combat fatigue and organizational disruption.

Both versions of 'morale' have an impact on fighting ability, although the quality aspect is long-term while combat fatigue is short-term and could recover within a few days. Perhaps we should have both with different designations.
Title: Re: C# Aurora v0.x Suggestions
Post by: zatomic on October 08, 2018, 10:25:42 AM
After a few days of thinking based on the Academy thread that became about the requirement for a jump-ship to be at least as big as any other ship it wants to transit (in addition to a big enough jump-drive), I got to thinking about the whole jump-drive system. I've seen lots of threads where players were confused about this requirement and also the military/civilian distinction.

So, my thought is instead of civilian and military jump drives, to instead create two different types of drives based on two different ways to transit a jump point.

1st is the gate-drive. It opens a temporary gate of it's rated size allowing any number of ships of that size or less to pass. Transiting a gate would cause effects similar to a standard transit under the current rules, or whatever effects are desired to make a gate transit unappealing when potentially heading into combat. Gate-drives would be cheap for their size like current rules civilian jump drives. There would be no requirement on the size of the ship carrying the drive other than being less than or equal to the drive capacity. The effects could be consolidated with the current jump-gate functionality, where a gate-stabilization ship can create an arbitrarily large permanent gate allowing any ship to gate-transit.

2nd is the jump-drive. It functions like the current rules military jump drive able to move a number of ships each with a size up to it's rating in a squadron jump with minimal negative effects, ideal for opposed jump-point assaults and general military operations in unsecured territory where ambushes are possible.

In summary, the gate-drive and stabilized gates allow something like the current standard transit while the jump-drive allows something like current squadron transits, all without any need to worry about the civ/mil distinction.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on October 08, 2018, 12:18:07 PM
Both versions of 'morale' have an impact on fighting ability, although the quality aspect is long-term while combat fatigue is short-term and could recover within a few days. Perhaps we should have both with different designations.
Hearts of Iron 3 solved this with using Strength and Organization values for each units. Strength was literally the Hit Points of an unit - the game did not model individual soldiers or equipment - where as Organization was a catch-all for all non-physical elements of a unit. So a high-quality, well-trained unit would have a higher Organization than a low-quality, poorly-trained one. What made the system really work was the "hidden" attribute of Morale, that determined how fast Organization could be recovered after a battle. So while the military doctrines of a country might allow the training of units with high Organization values, without the investment in propaganda etc that improved Morale, the units would only fight a single battle, and then require days if not weeks to recover. Units, no matter how much Strength they had left, would be immediately routed when their Organization hit zero and if they could not path to safety, would surrender.

In the Operational Art of War series, which did model individual pieces of equipment and squads of soldiers, each unit had a numerical Quality rating, determined by scenario designer, that could improve during the game, but it affected literally everything. How well the unit did in combat, how easily it could recover after combat, would it fight to death or retreat quickly, and so on. There was no morale check, rather unit quality was checked against its orders when the unit suffered casualties, to see whether it would keep following the orders or not, and on defence whether it would stand still or retreat. This was separate from Supply altogether.

The Gary Grigsby games used Quality as a catch-all value for units, that represented training level, morale, organization and more, and again it affected everything that the unit did except for movement rate. Units had to be ordered to Train to improve their Quality, though as the differences between good and bad units could be massive, this wasn't always useful. Quality decreased after new recruits were used to replenish losses in units, and could not be regained on its own. Though I think at very low levels it did improve slowly on its own.

Anyway, some food for thought there. Personally I think that renaming Morale to Quality and adding a Cohesion value would probably be the best system for Aurora C#. The Quality will only slowly increase due to Commander Training and combat, replenishing losses would bring it down, but otherwise it would be static. Cohesion value would be static in peace time, go automatically down in combat, recover slowly when unit is part of a campaign but not at front lines, and recover fast when unit is completely out of the war zone. The benefits of this system would be that it encourages players to rotate their combat units instead of just dropping a massive DOOM STACK on a planet, which makes ground campaigns more immersive. There would be a solid mechanical reason to create a R&R ship(s) or stations, where mauled ground units could be replenished and recover their Cohesion before being sent back to the meat grinder. And Cohesion could be something that would allow flavour between races - a Psychic Hive Mind could have insanely high Cohesion values when compared to Humans.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on October 08, 2018, 01:29:17 PM
Anyway, some food for thought there. Personally I think that renaming Morale to Quality and adding a Cohesion value would probably be the best system for Aurora C#. The Quality will only slowly increase due to Commander Training and combat, replenishing losses would bring it down, but otherwise it would be static. Cohesion value would be static in peace time, go automatically down in combat, recover slowly when unit is part of a campaign but not at front lines, and recover fast when unit is completely out of the war zone. The benefits of this system would be that it encourages players to rotate their combat units instead of just dropping a massive DOOM STACK on a planet, which makes ground campaigns more immersive. There would be a solid mechanical reason to create a R&R ship(s) or stations, where mauled ground units could be replenished and recover their Cohesion before being sent back to the meat grinder. And Cohesion could be something that would allow flavour between races - a Psychic Hive Mind could have insanely high Cohesion values when compared to Humans.

Yes, that sounds like a good approach. The way that morale currently works, it could be renamed to Quality with minor changes to functionality. Cohesion would be added on top.

Combat would only increase Quality (for the survivors) while Cohesion would fall based on a base rate for being in combat, modified by losses. Quality would decrease as a result of replacements being added (as morale does now), but would still move up to 100 relatively quickly (about 100 per year) and above 100 more slowly, again per the current morale rules. Rather than cohesion being higher for a 'hive mind', maybe it would just fall much more slowly.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on October 08, 2018, 02:58:35 PM
Well, if you are going to redo the Morale system, I've a few suggestions.


I'd say that ground forces have 3 non-physical stats. These stats are Morale, Cohesion and Training.


Morale would have a linear connection with casualties; although more severe losses will cause more severe morale loss, the real threat to morale is slow attrition. Likewise, although inflicting losses on enemy forces raises morale, it does not raise it as much as taking the same losses does in damage. Units in Support and Rear Echelon positions take worse morale hits when engaged and recover less when inflicting losses. Units that have been engaged in combat during a construction increment do not recover morale. This would encourage players to cycle forces, but the time spent should be something reasonable. Morale normally doesn't exceed the Formation's maximum value, but a properly skilled CO can increase the cap and/or recovery as currently in the rules.

It should be noted that, during WW2, the Americans reckoned a soldier could remain on station for nearly 3 months at a time, while the British cycled their troops every 12 to 14 days, giving them 4 days of leave.


Cohesion would have an exponential connection with casualties; constantly bleeding a few troops every combat round will slowly decrease Cohesion, taking a large number of casualties for the formation all at once drastically impacts its Cohesion and ability to provide a united front. Likewise is the loss of an HQ unit in the formation or the CO due to a combat injury something that can cause potentially heavy hits to Cohesion, but if they've got non-generic COs under them the hit is less (on the presumption that the chain of command keeps going), while the loss of an HQ has limited effect as long as it's not the last HQ. Having more than 1 HQ in the formation is a boost for Cohesion, if one with strongly diminishing returns, as is a commander with the right skills.

Generally speaking a military unit can cope quite well with the slow loss of troops; it's something they train and prepare for because losses are inevitable in war. Losing command and coordination, as would happen if the HQ of the unit is lost or a large chunk of its personnel is killed in a short amount of time is far more devastating.Putting down Cohesion as an explicit value does mean that you can get an idea how likely it is a given unit is going to falter and enable an enemy Breakthrough. High Cohesion also translates into having a high chance of performing a Breakthrough though.


Training would take the place of the current Morale value. I would say it's much more stratified than the current system, with the levels of Conscript, Green, Trained, Regular, Veteran and Elite. GFTF's on a planet can be instructed to train formations to a certain standard, which impacts the time and wealth it takes to train. Minerals is independent and only cares for the end equipment. Conscript troops train quickly and cheaply but take severe maluses to Morale and Cohesion, Trained troops have standard Morale and Cohesion, and Elites have high Morale and Cohesion but take a long time and are expensive to train and maintain. A CO with the proper skills can get even the worst Conscript unit up to Elite eventually, but that will take a lot of time of money in comparison to just selecting Elite training in the GFTF.

Training is something that's accumulated not unlike the way crew skill levels are. And like with crew skill levels, it's something that's averaged between all members of the unit. You can absolutely shove Green troops into an Elite formation, it just means the unit becomes on the average less skilled and may lose a level of Training depending on how much the unit is expanded from current size, but likewise can you shove some Elite or Veteran troops into a much less skilled unit as a cadre to stiffen them up a bit.

I deliberately picked some tresholds so as to let you pick a few values for each level instead of having to insert a calculation system that can get... odd as skill point values become more extreme.


I've got more ideas for the ground combat system, although I'll admit I'd basically shamelessly plunder Paradox grand strategy games for ideas.
Title: Re: C# Aurora v0.x Suggestions
Post by: Adseria on October 09, 2018, 07:35:02 AM
Well, if you are going to redo the Morale system, I've a few suggestions.


I'd say that ground forces have 3 non-physical stats. These stats are Morale, Cohesion and Training.


Morale would have a linear connection with casualties; although more severe losses will cause more severe morale loss, the real threat to morale is slow attrition. Likewise, although inflicting losses on enemy forces raises morale, it does not raise it as much as taking the same losses does in damage. Units in Support and Rear Echelon positions take worse morale hits when engaged and recover less when inflicting losses. Units that have been engaged in combat during a construction increment do not recover morale. This would encourage players to cycle forces, but the time spent should be something reasonable. Morale normally doesn't exceed the Formation's maximum value, but a properly skilled CO can increase the cap and/or recovery as currently in the rules.

It should be noted that, during WW2, the Americans reckoned a soldier could remain on station for nearly 3 months at a time, while the British cycled their troops every 12 to 14 days, giving them 4 days of leave.


Cohesion would have an exponential connection with casualties; constantly bleeding a few troops every combat round will slowly decrease Cohesion, taking a large number of casualties for the formation all at once drastically impacts its Cohesion and ability to provide a united front. Likewise is the loss of an HQ unit in the formation or the CO due to a combat injury something that can cause potentially heavy hits to Cohesion, but if they've got non-generic COs under them the hit is less (on the presumption that the chain of command keeps going), while the loss of an HQ has limited effect as long as it's not the last HQ. Having more than 1 HQ in the formation is a boost for Cohesion, if one with strongly diminishing returns, as is a commander with the right skills.

Generally speaking a military unit can cope quite well with the slow loss of troops; it's something they train and prepare for because losses are inevitable in war. Losing command and coordination, as would happen if the HQ of the unit is lost or a large chunk of its personnel is killed in a short amount of time is far more devastating.Putting down Cohesion as an explicit value does mean that you can get an idea how likely it is a given unit is going to falter and enable an enemy Breakthrough. High Cohesion also translates into having a high chance of performing a Breakthrough though.


Training would take the place of the current Morale value. I would say it's much more stratified than the current system, with the levels of Conscript, Green, Trained, Regular, Veteran and Elite. GFTF's on a planet can be instructed to train formations to a certain standard, which impacts the time and wealth it takes to train. Minerals is independent and only cares for the end equipment. Conscript troops train quickly and cheaply but take severe maluses to Morale and Cohesion, Trained troops have standard Morale and Cohesion, and Elites have high Morale and Cohesion but take a long time and are expensive to train and maintain. A CO with the proper skills can get even the worst Conscript unit up to Elite eventually, but that will take a lot of time of money in comparison to just selecting Elite training in the GFTF.

Training is something that's accumulated not unlike the way crew skill levels are. And like with crew skill levels, it's something that's averaged between all members of the unit. You can absolutely shove Green troops into an Elite formation, it just means the unit becomes on the average less skilled and may lose a level of Training depending on how much the unit is expanded from current size, but likewise can you shove some Elite or Veteran troops into a much less skilled unit as a cadre to stiffen them up a bit.

I deliberately picked some tresholds so as to let you pick a few values for each level instead of having to insert a calculation system that can get... odd as skill point values become more extreme.


I've got more ideas for the ground combat system, although I'll admit I'd basically shamelessly plunder Paradox grand strategy games for ideas.

I definitely like the idea of separating off training. The way it works at the moment, where training just increases morale, is kinda stupid (though not completely; I suppose troops with lots of training might be more confident in their abilities).
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on October 09, 2018, 12:45:46 PM
Well, if you are going to redo the Morale system, I've a few suggestions.

<SNIP>

Training would take the place of the current Morale value. I would say it's much more stratified than the current system, with the levels of Conscript, Green, Trained, Regular, Veteran and Elite.

<snip>

I deliberately picked some thresholds so as to let you pick a few values for each level instead of having to insert a calculation system that can get... odd as skill point values become more extreme.

I really HATE a stratified level system.  I hate that a force that is 1 XP short of Veteran counts the same as a force 1 XP above Green.  I would much rather have a scale of 50 to 150 -- probably with a significant bell curve -- than fixed 50%, 75%, 100%, 125%, 150% categories.

My computer can handle nine decimal places easily.  Please give us a morale system that (theoretically) accounts for when my troops get double dessert rations versus when they don't.
Title: Re: C# Aurora v0.x Suggestions
Post by: space dwarf on October 09, 2018, 02:15:09 PM
Quote from: Steve Walmsley link=topic=9841. msg110228#msg110228 date=1539023357
Combat would only increase Quality (for the survivors) while Cohesion would fall based on a base rate for being in combat, modified by losses.  Quality would decrease as a result of replacements being added (as morale does now), but would still move up to 100 relatively quickly (about 100 per year) and above 100 more slowly, again per the current morale rules.  Rather than cohesion being higher for a 'hive mind', maybe it would just fall much more slowly.

If a goal of the 'hive mind' is to have a different feel of play when encountered, you could do something more out-there and differentiated by making their Cohesion directly based off of unit strength/hp/survivors (maybe not a 1:1, but it just seems like a cool concept)
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on October 09, 2018, 04:32:19 PM
I really HATE a stratified level system.  I hate that a force that is 1 XP short of Veteran counts the same as a force 1 XP above Green.  I would much rather have a scale of 50 to 150 -- probably with a significant bell curve -- than fixed 50%, 75%, 100%, 125%, 150% categories.

My computer can handle nine decimal places easily.  Please give us a morale system that (theoretically) accounts for when my troops get double dessert rations versus when they don't.

I'm not in disagreement, but it's something that's easy to read and interpret.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on October 09, 2018, 04:47:55 PM
Do we really need both hp and cohesion? I know they're different things, but it seems like the actual strategic impact would be minimal outside increasing micromanagement.

In the end, this is ground combat in Aurora, not a new game entirely, so I'm kind of wary of over-complicating an addition that will already be much more complicated then what it's replacing.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on October 09, 2018, 05:31:55 PM
Do we really need both hp and cohesion? I know they're different things, but it seems like the actual strategic impact would be minimal outside increasing micromanagement.

In the end, this is ground combat in Aurora, not a new game entirely, so I'm kind of wary of over-complicating an addition that will already be much more complicated then what it's replacing.

This is a valid view too. If I change Morale to Quality and add Cohesion, the actual game-play change would be moving formations in and out of the front-line to manage cohesion. While more realistic, that might get tedious fast. It could be better to have less 'realism', but smoother game play. Although Aurora should have a lot of variety and choice, it should not have micromanagement where that detracts from game play.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on October 09, 2018, 09:00:57 PM
Well, currently ground combat is fire & forget, unlike space combat which is very micro heavy.

Even in C#, it is largely fire & forget, because while you will spend more time designing your units and formations, the only real concern you have to worry about is ensuring supplies & replacement are delivered to the planet. You select front and rear formations, ground-support fighters (if any) and then let the game proceed. With the proposed change, a player would have to monitor ground combat, making it more like space combat in the amount of player attention it requires.

Having said that, I can totally understand that for some players, the ground combat is a tasteless side salad whereas the space combat is the fat t-bone slathered in gravy and spraying thousand islands sauce over the salad will not improve the dining experience for them.  :D
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on October 09, 2018, 09:44:59 PM
Well, currently ground combat is fire & forget, unlike space combat which is very micro heavy.

Even in C#, it is largely fire & forget, because while you will spend more time designing your units and formations, the only real concern you have to worry about is ensuring supplies & replacement are delivered to the planet. You select front and rear formations, ground-support fighters (if any) and then let the game proceed. With the proposed change, a player would have to monitor ground combat, making it more like space combat in the amount of player attention it requires.

Having said that, I can totally understand that for some players, the ground combat is a tasteless side salad whereas the space combat is the fat t-bone slathered in gravy and spraying thousand islands sauce over the salad will not improve the dining experience for them.  :D
It's more that simply moving formation in and out of the front line when they get low cohesion is tedious and pointless, without much in the way of actual decision-making in the vast majority of cases, rather than people not wanting deeper ground play. Just busy work. Unlike most aspects of space combat where actual decisions need to be made. And whilst it could be automated, that begs the question of why even implement the mechanic in the first place if you're just going to automate it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on October 10, 2018, 01:50:29 AM
Do we really need both hp and cohesion? I know they're different things, but it seems like the actual strategic impact would be minimal outside increasing micromanagement.

In the end, this is ground combat in Aurora, not a new game entirely, so I'm kind of wary of over-complicating an addition that will already be much more complicated then what it's replacing.

This is a valid view too. If I change Morale to Quality and add Cohesion, the actual game-play change would be moving formations in and out of the front-line to manage cohesion. While more realistic, that might get tedious fast. It could be better to have less 'realism', but smoother game play. Although Aurora should have a lot of variety and choice, it should not have micromanagement where that detracts from game play.

That depends on how you do it I believe... If you set a formation to defensive front line duty it would fall back to support when cohesion fall too much and automatically back in front formation when it regained a certain amount of cohesion. Say it will fall back to support when cohesion get below 50 but can not get on the front line if cohesion is less than 75... once cohesion is 75 it will automatically go to the front lines again.

The same could go for support and attacking units.

Say you need 100 cohesion to begin attacking and fall back to defensive front lines at 75 cohesion. You need 75 cohesion to go to the defensive front line and fall back to support at 50. You need 50 cohesion to move to support lines and fall back to rear echelon at 25 cohesion... etc...

You only set what place you prefer that formation to be at and the game handle the rest for you... this way you get a dynamic combat model that is both realistic and relatively micro free. I think this will make combat last much longer... I feel that combat in general seem to conclude way too fast, especially if one side is more powerful than the other since there are no mechanic to mitigate numbers.

You could micro this if you want to but you would not need to and there would be rules for when a unit is able to take up possition in Attack, Defense, Support & Rear.

Perhaps also add something such as allowing a max of certain number of formation to engage another formation too so uneven combats will take some time and produce at least some losses to the aggressor.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on October 10, 2018, 01:52:10 AM
Well, currently ground combat is fire & forget, unlike space combat which is very micro heavy.

Even in C#, it is largely fire & forget, because while you will spend more time designing your units and formations, the only real concern you have to worry about is ensuring supplies & replacement are delivered to the planet. You select front and rear formations, ground-support fighters (if any) and then let the game proceed. With the proposed change, a player would have to monitor ground combat, making it more like space combat in the amount of player attention it requires.

Having said that, I can totally understand that for some players, the ground combat is a tasteless side salad whereas the space combat is the fat t-bone slathered in gravy and spraying thousand islands sauce over the salad will not improve the dining experience for them.  :D

I am with you...

the main point I see, the new Ground Combat chances are really big and a lot of work to do.. so all the work would be wasted if the Ground Combat itself would stay as it is atm - with "click and forget"...

all the good ideas and work that went into the new system should result in a new way to PLAY the Ground Combat - make it more complex (and so micro heavier than atm) like the Space Combat...

It could be better to have less 'realism', but smoother game play. Although Aurora should have a lot of variety and choice, it should not have micromanagement where that detracts from game play.

Well, Space Combat has 5sec turns .. ground combat 6h turns even in C# if I am not wrong.. so I see no problem.. Aurora is played by players who are getting "distracted" from the game every time a tiny conflict in space occurs with sometimes 100s of 5s turns... shouldn't be so much a problem to get a few 6h turns in between... it COULD be a problem when your testgames shows that you need 3-6 month of 6h turns to conquer a planet and the player has to micro 500x per planet but as long as it is not too much I am in favor...

also ground combat is something that is much more rare (even with the new systems than space combat - and can be avoided by the player in let's say nearly every time if he wants (just bombard an alien planet to kingdom come/don't defend/ignore attacks at your own planets at all
only the defending spoilers are a "fight you have to do" maybe but even than the player can ignore ruins etc... so...

---

With all the time, work and thinking which went into the new ground combat it is much more "fleshed out" as in VB6 - which results in the point that it also deserves much more "love" from the player... it shouldn't be too micro right but should be more micro than atm...

also as I said, ground combat is something the player can avoid nearly completely if he wishes... space combat he can not...
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on October 10, 2018, 02:09:21 AM
I also forgot to mention army capitulation could be automatic when there are no more units able to hold the defensive line, or a chance for capitulation.

You could also add in the chance of an army dispersing and starting to conduct asymmetric warfare. We all know how important this has been in history from disrupting a conqueror from gaining control of an area and can enable a garrison force to hold on for a good while until reinforcement arrive against overwhelming odds.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on October 10, 2018, 02:10:26 AM
With all the time, work and thinking which went into the new ground combat it is much more "fleshed out" as in VB6 - which results in the point that it also deserves much more "love" from the player... it shouldn't be too micro right but should be more micro than atm...

also as I said, ground combat is something the player can avoid nearly completely if he wishes... space combat he can not...

I would point out that not all player interaction is micromanagement. It becomes micro heavy if you have to do tasks that are not meaningful decisions. Do you attack, do you retreat are important questions, which should matter.
Firing 100 missiles from box launchers in 20 5 missile salvos at 20 swarmers is currently a micro heavy task. If you need to select each ground unit individually and change it to attack, that is micro heavy, but changing a stance every few hours, that is just paying attention to what you are actually doing.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on October 10, 2018, 07:29:59 AM
I would point out that not all player interaction is micromanagement. It becomes micro heavy if you have to do tasks that are not meaningful decisions. Do you attack, do you retreat are important questions, which should matter.
Firing 100 missiles from box launchers in 20 5 missile salvos at 20 swarmers is currently a micro heavy task. If you need to select each ground unit individually and change it to attack, that is micro heavy, but changing a stance every few hours, that is just paying attention to what you are actually doing.

Just to plant the agent seed again:  It would be REALLY nice if the same agent that the AI uses to run the micro (or even macro) level of a particular ground combat were available for the player to use.  That way those who don't want to consume their attention (whether through disinterest or wanting to roleplay working at a higher level of command) could just pick a "let the AI run the combat" option and let it go on auto-pilot.  Ditto for picking fire distribution for naval weapons.

John
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on October 10, 2018, 10:17:43 AM
I'd agree that having the ground combat a bit more interactive and having options to both initiate and react to different developments would be great. As said previously its just balancing this with the micro management piece.

More broadly I think all the extra logistics and costs of invading a planet needs to be appropriately rewarded to make sure it does not become simple better sense to put all that effort into growing your own industrial base and resources and just glass the opposition rather than trying to take it from them. Not sure if that means lowering the relative costs to launch such an invasion or give some method to increase the speed by which you can get a hostile planet fully contributing again or something else.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on October 10, 2018, 03:40:42 PM
I *love* all the new formation and ground unit options.  I can finally have the style(s) of army that I want, in all the different historically-inspired ways I desire.  The front-defense-support-rear setup seems like it will fulfill my desire to tinker with fighting doctrine.  I don't need a 'Field Marshal Simulator' with which to run 3h ground combat chunks -- if it's not too onerous, I don't mind having one.  I'll probably start looking for the AI assist after two or three battles.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rich.h on October 11, 2018, 05:20:26 AM
I may have missed someoe else already putting similar ideas forward, but had a few thoughts about spoilers today. For me personally I tend to find two spoilers somewhat boring and they become nothing more than a hump in the road in one case, and a micromanagement annoyance in the other. As such I will address each seperately.

So first up then is the Star Swarm, the general method by which they work with workers building more ships is great, but lacks anything else. Once you discover them and design a class of ship to take out the fighters with little to no damage the queen becomes a simple matter of long range missiles (and lots of them). If you encounter them again at any point it is a simple rinse and repeat. So a couple of ideas:

1. Have a missile type craft in the swarms arsenal, something like a bio missile that functions in the same manner as mesons (skipping shields and armour). This means you now have another tactical layer to consider, and could be quite the shock when you think you are safe using a mob of AMM against the meson fighters and suddenly a whole lot of fast blips appear.

2. Since the basic goal of all life is to procreate and spread, have the Star Swarm follow suit. So to start with a swarm will be found in a system, they will have a queen, a few constructors and the fighters. More than often first contact is the case of you  quickly loosing the craft that discovered them to the fighter onslaught. Instead of however having the Swarm being reactive make them proactive, so they could have a fleet breakdown as such:

A queen (one only ever in a system
Jump capable "princesses" that move to an ajoining system and turn into new queens with a small amount of resources
Workers that gather materials
Missile type larger drones to defend the queen
Soldiers as they are now.

With this makeup the swarm could follow a simple method. The queen lays eggs of X number of soldiers, then lays worker & drone eggs in a set ratio. Once the total number of Soldiers + Drones + Workers reaches a set amount the queen lays a special egg, this hatches and jumps to an ajoining system through an explored JP. The young new queen then grows up and using a small stockpile hatches out a minimal force of Workers and Soldiers, she then continues as a normal queen. Once a queen finds she has no explored JP's left without that do not contain a swarm, she stops hatching young queens and goes into a cycle of maintaing her swarm at peak condition.

Doing this would mean that if you do not activley work on wiping out the swarm in a system you run the risk of them spreading and causing major problems for all in the galaxy, with NPR's activating spoilers this could easily result in you happening upon a massive nest spread over many systems.


Ok and the second spoiler race.

The Invaders, here is a race I no longer use in Aurora, simply for how annoying they end up becoming. Not dangerous just annoying, much like the Star Sawrm you can develop very effective designs build to wipe out the Invaders without much trouble, but the wormhole system means you end up with a lot of micromanagement of systems with wormholes. Now I understand what a huge task it would be to have a method of traversing the wormholes and taking the fight to the Invaders, so how about a method where you can at least plug the gaps as such.

So currently you get a wormhole appear and assuming you win the battle with no major problems, you now have to have something nearby to monitor and deal with any future threats. How about to begin with with have a tech line branched off the jump tech line somewhere mid way in advancment that unlocks, this allows you to develop either the means to get rid of the wormhole, or we could have some device that renders them inert but still present. We have jump gates that stabalise a JP so the opposite perhaps, a gate that destabalises the wormhole, rendering it unpassable, yet it could be taken down in future if you decided to try and farm the Invaders technology or such. Also both of these device types would mean the system in question would be unable to have a new wormhole open up inside it.

That deals with the problems inside your boarders, so outside of them then we need a change in Invader behaviour. The Wiki always descived them as bogey men who just want to wipe everything out, so they should act as such. Currently they seem to act a little random, a ship comes through the wormhole shoots at things and may decide to then fly oout of the system on another task. Let's have them build up forces and properly purge  8) So a wormhole opens, and a few smaller vessels come through, they attack anything inside a set radius of the wormhole position then return to the wormhole and wait (If they endup being destroyed then the counter for this system stays set at "bring in small ships"). A counter then moves onto the next stage and in time brings in larger vessels, these do exactly the same thing but in a wider radius (again the counter stays the same should they be destroyed). Finally the counter moves up and in time we get big nasty death machines, these proceed to wipe out everything owned by anybody in the entire system (again a counter reset).

Once this phase is complete the force then joins up leaving the initial scout force to stay at the wormhole. This force then heads out through the nearest explored JP and attacks everything it finds in this system, then moves on and so on. In this way they are laying waste to everything they can find. If they get destroyed then the original counter resets back to the second phase back at the entry wormhole, and once again we get a force build up. If we look at this from an NPR activation it could be possible they wipe out the entire NPR and find themselves with no explored JP's. In this case the force returns to the wormhole and waits until a new JP network connection is made then moves towards it and continues onward.

In this scenario it would make sense to have a set limit on the number of wormholes allowed to be active at any one time in the galaxy, for nothing else other than CPU power and the devestation multiple forces could create. But it would mean you have the chance of occasionally coming across entire worlds that have been glassed, with mountains of wrecks in system from where the Invaders swept aside an NPR in their purge. In addition there would be genuine reasons to try and find any active wormholes and develop access traties with an NPR if you happen to have the technology to close them, for both your civilizations benefit.


I think these methods could give an interesting dynamic to both these spoilers and force you to have very different ways of dealing with them, in addition I don't think either requires a massive overhaul of the code they already use, just a small expansion on them. As for the final spoiler race I don't think much needs to be done, curently they fit their role and lore well and looking at the second idea changes it makes perfect sense with how often they are encountered.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on October 11, 2018, 06:39:19 AM
Something I have thought a about several times are the mineral report.

It is showing at the end "Projected Usage"... this is all nice and such but I really would like to have Yearly Projected Usage" this would be much better to know the rate at which minerals are consumed over one year versus the incoming minerals to that site.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on October 12, 2018, 04:44:36 AM
I had a few thoughts about spoilers today.

<SNIP>



I quite like your idea of Star Swarm 'Princesses' spreading to neighbouring systems, but I would hate to see the Swarm start using missiles.  They're pretty much the only faction that don't, and I want more non-missile-users, not less.

As for the Invaders, I haven't encountered them enough to form a really solid opinion.  Generally when I find a wormhole it means the death of my exploration cruiser, so that system gets marked 'off limits'.  On the extremely rare occasions when a wormhole opens in one of my inner systems, half my fleet (or more) is immediately stationed there to kill anything that comes through.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on October 12, 2018, 05:30:31 AM
I will be revisiting every spoiler race to make them more interesting, plus I plan to add new spoiler races. Some details below for the existing spoiler changes if you want them:

1) Precursors now have 'real' ground forces rather than the pop-up robots. They are still robotic but now you will be fighting Centurions and Praetorian Combat Mechs (plus other types). You will also be able to damage abandoned installations so wiping them out from orbit will no longer be a good option. Because the AI needs to worry about fuel, Precursors may also deploy harvesters and logistics infrastructure to support their forces. Finally, they will have a more consistent approach to the composition of the forces, which will vary by game. This is all coded.

2) Swarm will be expanded to include more ship types, although still no missiles. Eventually, they may become similar to Tyranids from WH40k. They will also have ground forces, which will probably use vast numbers of low quality units on front-line attack, supported by occasional very powerful units.

3) Invaders, which were inspired by Andromedans from SFB will move more in that direction. They will have a consistent plan, rather than being a random menace, and will have bases that support their inter-galactic invasion, rather than wormholes. You will be able to defeat that invasion by destroying the bases.


Title: Re: C# Aurora v0.x Suggestions
Post by: Ranged66 on October 15, 2018, 05:45:33 AM
A suggestion on the ground combat:

Population could contribute some troops/strength as well, depending on the loyalty and happiness of the planet.  A planet that loves its empire will have many patriotic citizens taking up arms themselves to help fend off the invaders, while a planet that already hates the ruling empire might even aid the invaders in getting captured.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on October 17, 2018, 02:35:21 AM
Quote from: Ranged66
A suggestion on the ground combat:

Population could contribute some troops/strength as well. . . snip. . .
I would tend to agree that some of the citizenry would volunteer if it seemed to them there was a need to.   

A few questions come to mind if we consider the citizenry rising up to join the fight:

Perhaps none of that matters at all and it all simply hides behind abstractions, and you get 'given' a number of civilian combat units presumed to have equal traits but lesser abilities than standard soldiers, at the cost of some population loss, and what you do with them is up to you.   Presumably once the battle is over any surviving volunteers auto disband and rejoin the population.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on October 17, 2018, 04:03:10 AM
A suggestion on the ground combat:

Population could contribute some troops/strength as well, depending on the loyalty and happiness of the planet.  A planet that loves its empire will have many patriotic citizens taking up arms themselves to help fend off the invaders, while a planet that already hates the ruling empire might even aid the invaders in getting captured.

The 19th century was the time when conscription ruled, and it was all about who could get the most men into the field, but since then, total manpower became less and less important compared to the amount of weapons you can afford, which is why we have many more professional armies again.
In Aurora the cost of equipment and weapons is likely only to rise, and the value of people without the proper equipment and the proper training to use it will fall.
Loyalty might matter in how easy it is to pacify a planet, but generally I'd consider the value of untrained volunteers nil, and if you do want to train a militia, you can spam large quantities of PWL equipped light infantry to fit the bill.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on October 17, 2018, 05:55:32 AM
The 19th century was the time when conscription ruled, and it was all about who could get the most men into the field, but since then, total manpower became less and less important compared to the amount of weapons you can afford, which is why we have many more professional armies again.

Isn't that just because there have been very few straight up actual wars between large modern forces of similar powers?

I mean sure you can point to things like Desert Storm or the 2003 Invasion of Iraq but desert warfare is a bit special and tend to disproportionately favoring the side with a technological edge and air-supremacy, since there is nowhere to hide.

I don't think the Modern US forces would have done equally well if they had to go back into the jungles in Vietnam for example and fight man to man against an enemy that for all intents and purposes can afford to arm somewhere in the ballpark of 100-1000 men for the same $ price as getting a single US soldier there costs. And this holds true pretty much no matter how advanced weapons or how much firepower you have. The limitation isn't in either firepower, range or accuracy of weapons if you will be fighting close range combat in low visibility conditions.

The combat ability of untrained men also depends greatly on morale and motivation. If your fighting in defense of your home for the survival of your race against alien slime scum your probably a bit more motivated than if your fighting for a corrupt middle eastern dictator that hides in a bunker and expects you to die so he can conquer more oil and become even richer.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on October 17, 2018, 05:57:41 AM
A suggestion on the ground combat:

Population could contribute some troops/strength as well, depending on the loyalty and happiness of the planet.  A planet that loves its empire will have many patriotic citizens taking up arms themselves to help fend off the invaders, while a planet that already hates the ruling empire might even aid the invaders in getting captured.

The 19th century was the time when conscription ruled, and it was all about who could get the most men into the field, but since then, total manpower became less and less important compared to the amount of weapons you can afford, which is why we have many more professional armies again.
In Aurora the cost of equipment and weapons is likely only to rise, and the value of people without the proper equipment and the proper training to use it will fall.
Loyalty might matter in how easy it is to pacify a planet, but generally I'd consider the value of untrained volunteers nil, and if you do want to train a militia, you can spam large quantities of PWL equipped light infantry to fit the bill.

True... but increase in weapon power have also shown that asymmetric warfare have become way more dangerous as well. In fact asymmetric warfare are extremely dangerous today, what if they could be supplied things like nukes and the like. Just the introduction of the regular gun with its ease of use and lethality have shown how powerful or difficult it is to fight an enemy that have no uniform and defend no particular ground, tanks are virtually useless as are air-force and the like.

I think Aurora could simulate asymmetric warfare as well as regular warfare since they are both equally important.

Problem with asymmetric warfare is that it is purely a political, cultural or ethical driven and you can only defend against it with force and fight it with soft methods.

Aurora currently only deal with conventional warfare. The more powerful weapons get the more dangerous asymmetric warfare will become.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on October 17, 2018, 11:02:37 AM
It has always been difficult to fight against an enemy that has no uniform, nor needs to defend any particular ground.

This is true today, it'll be true tomorrow and it has been true in history.

Historically that has been fought either through law enforcement efforts or flat out genocide. The only way to fight such an enemy is by denying them anything to hide behind, and you can do that by convincing the general population that they're better served ratting them out, or by ensuring there's no general population left to support them.

The gun has not really changed this fact. A war still needs the resources to pursue that war.

The only thing that has changed in this equation is that people in general have grown less tolerant of genocide and similar tactics to pursue the conclusion of an asymmetrical war.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on October 19, 2018, 03:45:15 PM
Thinking about ground combat again:

maybe combat in deadly environment (pressure, temperature, breathable air) should be much more deadly than fighting in an earth-like environment..

I mean, a simple hole in a pressure-armour would kill the soldier in these while it would maybe just scratch or wound him on earth... you can train you troops for better fighting in theses areas but that does not result in a less deadly environment if the breather/suit/vehicle is penetrated

to add these in combat looses could make fighting in not earth-like environments much more interesting (and would give some races with other environment stats more exclusive pro/cons) nothing too strange but maybe something like this would work : factor for casualties = 1 + colony costs of the planet   [with  colony costs capmax 2)   so there would be up to 3 times more looses in a deadly environment when fighting the same battle as on earth...

wouldn't make much difference when colony cost is for both sides the same, but attacking a high pressure species (or maybe spoilers) on their high pressure home planet would be much of an achievement...
Title: Re: C# Aurora v0.x Suggestions
Post by: Ranged66 on October 20, 2018, 04:41:44 AM
In Aurora VB, civilian spaceliners act like colony ships with low capacity.  They won't move unless there are destinations that normaly colony ships would visit too available.

Small change suggestion: Make civilian spaceliners able to ferry their tourists between stable planets too.  This could add some other interesting elements like beauty/tourism scores for planets.  A world with large rings or moons of gas giants could be great destinations for those luxury liners because of the spectacle in the skies above.

Could even make them travel between uncolonised worlds in gated systems to act like cruise ships, loiter around a bit in orbit with a beautiful view before leaving again.  Or add the possibility to make luxury bases/space stations at those beautiful locations that luxury liners will ferry tourists to and from.

It's little fluff stuff like this that makes me love space 4x games when they do it.  Distant Worlds has part of these too and you can make some decent income by maintaining your empire's wealthiest citizens with resort bases.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on October 20, 2018, 12:12:57 PM
Quote from: Ranged66
A suggestion on the ground combat:

Population could contribute some troops/strength as well. . . snip. . .
I would tend to agree that some of the citizenry would volunteer if it seemed to them there was a need to.   

A few questions come to mind if we consider the citizenry rising up to join the fight:
  • Can they leave the infrastructure that supports them in hostile environments to go fight?
  • Are they self armed in entirety, or to some percentage?
    • If not self armed, can the soldiers arm them and if so, how many guns can they distribute? Presumably 100k soldiers do not have enough guns to arm 4 million volunteers.   You have probably already lost the orbitals so good luck shipping in more guns before the fight is over.
    • If they are self armed, do all civilians possess a gun or only some fraction.  Does the fraction that volunteer apply only to the armed percentage, or the total population yielding both armed and unarmed volunteers
    • What value, if any, might unarmed volunteers hold?  Some bonus to recovery/replacement rates for lost personnel?
  • Should player government and/or commander traits and/or administrator traits be used to influence the expectation/willingness to accept/seek out volunteers?
  • Is there a limit to how many will be useful at any given task?  Absurd example, 1 million civvies trying to do the work that was done by 100 personnel will probably get nothing done, just get in each other's way.
    • Is there a tipping point?  Seems reasonable that while too many would be detrimental, too few would benefit from adding some more.
    • Are there any roles they might be a viable substitute?  Seems plausible that for any such role, while too few and too many both don't get enough done, the optimal quantity might also not get enough done.
  • Should they be affected by research as if they were a ground force unit?  I would think yes, today we can buy guns far better than we could have in the 1800's, research tends to advance what we can obtain.
  • Can they leave the infrastructure to venture out into the hostile atmosphere to be resistance fighters?
    • If not, you won't be doing much resisting staying bottled up in the domes
    • If you can leave the dome to resist, how likely are people to resist knowing the hostiles can simply vent every dome they encounter and let your supplies run out to end you.
    • If its a breathable atmosphere, then resistance in any taken populated areas seems plausible.   Outright combat or just a modifier to efficiencies?
  • Is there really a point where the civvies would be so disloyal as to turn on you?
    • The grass would have to be known, not thought, but known to be greener on the other side of the fence before they turn on you.   Wealthier, benevolent, and have treated conquered planets well already?  The civvies might just try to trade you in for a better life.
    • xenophobia, biological/environmental compatibility, and ability to even communicate is likely to be a factor.   Even if the grass is greener, do they leave the planet suitable for you, or terraform it to them and leave you restricted to infrastructure in perpetuity?
    • if you know the grass is definitely greener right here, then its a choice between helping and apathy, not rebellion.   If the invaders are known to mistreat the conquered, apathy is less likely, if they are known to exterminate it seems absurd, and in both cases, rebellion/assisting the invaders seems incredibly unlikely.

Perhaps none of that matters at all and it all simply hides behind abstractions, and you get 'given' a number of civilian combat units presumed to have equal traits but lesser abilities than standard soldiers, at the cost of some population loss, and what you do with them is up to you.   Presumably once the battle is over any surviving volunteers auto disband and rejoin the population.
No matter how advanced the weapons get, conscripts will always be useful.  Maybe not on the front line, but there's always room for more workers behind the lines.  This is likely to only get MORE true as combat units require more and more supplies.  These conscripts can be building and operating logistics infrastructure; driving trucks, paving roads, laying rail lines.  They can also be building emplacements; you don't need Navy SEALS and laser guns to pour concrete.
Title: Re: C# Aurora v0.x Suggestions
Post by: DEEPenergy on October 20, 2018, 02:08:00 PM
I think this has been talked about before but remove the restriction that jump engines can only jump ships as large as the ship they are mounted on. In other words a 4000 ton ship should be able to jump an 8000 ton ship if the jump engine is rated for that size.
Title: Re: C# Aurora v0.x Suggestions
Post by: Shuul on October 20, 2018, 05:01:01 PM
I wonder if it is possible to add some tooltips with C# aurora?
Title: Re: C# Aurora v0.x Suggestions
Post by: Ranged66 on October 21, 2018, 12:13:48 PM
Suggestion: possibility to make civilians haul minerals on contract too.

Suggestion 2: civilian mineral harvesters that go after comets/roids/moons.  We already have fuel harvesters so why not!
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on October 21, 2018, 02:25:42 PM
Suggestion: Remove Refit costs associated with changing the size of space stations, as they don't have any armor that needs to be rebuilt.
This would make growing, sprawling space stations possible. At that point it would also be really cool if shipyards could be integrated into space stations, to make supermassive orbiting structures. (The yards would still need the population)
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on October 21, 2018, 07:09:17 PM
Suggestion 2: civilian mineral harvesters that go after comets/roids/moons.  We already have fuel harvesters so why not!
How would that differ from CMCs aside from the fact that instead of automines on a colony, there are asteroid miners on a colony?
Title: Re: C# Aurora v0.x Suggestions
Post by: Dr. Toboggan on October 23, 2018, 01:02:12 PM
Any possibility of the scrollwheel being usable in more windows?
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on October 23, 2018, 02:55:55 PM
It would be nice to be able to replace a scientist on a project without having to cancel the research project...

canceling will delete the Queue too and replacing a Scientist (because of an error or a new one came up) is a pain in the a.. if you have set up a research queue for him...
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on October 23, 2018, 03:57:50 PM
Being able to assign a 'replacement scientist' would be nice yes. If the head scientist dies while researching the same thing happens.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on October 23, 2018, 04:14:09 PM
I hope the research system is redesigned at some point. It is way to linear and not that interesting as a mechanic at the present.

Technologies which boost industry, research and economy should work very different from engineering and theoretical development. I think labs should be dedicated to a certain field but you should be able to convert them at a lower cost.

Scientist bonuses should not be immediately applicable to research projects but accumulated over time so there is a real choice between long term and short term planning. Instead of administration being a restriction on number of labs it could be a faster growth of science bonuses or some such.

I certainly don't want this to happen before C# Aurora is launched but at least that it perhaps is considered in some way down the line. The current system are a bit "gamey", you can role-play some restrictions of course, the same with industry.

I would love for industry construction to behave in a similar way where you can make long term plans or short term investment. Sort of like production lines in HoI 4 with a gearing bonus towards different projects. If you produce lots of things of a specific item you will produce that thing more and more efficiently over time... up to a certain limit based on technology or engineering skills.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on October 24, 2018, 04:47:50 AM
I hope the research system is redesigned at some point. It is way to linear and not that interesting as a mechanic at the present.

Technologies which boost industry, research and economy should work very different from engineering and theoretical development. I think labs should be dedicated to a certain field but you should be able to convert them at a lower cost.

Scientist bonuses should not be immediately applicable to research projects but accumulated over time so there is a real choice between long term and short term planning. Instead of administration being a restriction on number of labs it could be a faster growth of science bonuses or some such.

I certainly don't want this to happen before C# Aurora is launched but at least that it perhaps is considered in some way down the line. The current system are a bit "gamey", you can role-play some restrictions of course, the same with industry.

I would love for industry construction to behave in a similar way where you can make long term plans or short term investment. Sort of like production lines in HoI 4 with a gearing bonus towards different projects. If you produce lots of things of a specific item you will produce that thing more and more efficiently over time... up to a certain limit based on technology or engineering skills.

Yes this is something I would love as well in the far future.

I think Research and Industry construction could use similar mechanics. Basically start any new factory/lab at low efficiency (5-20%) and have them gradually, over some years build up proficiency in the area or category they work until a maximum of 100%

This means you want to make a long term plan that feels more realistic and resemble real limits rather than put 30/30 labs or 600/600 of your factories on a single project that you rush. It also means that you want to try to have some stuff building/researching in most categories in case you need something urgent from that category.

In fact I would much rather prefer if some of the leader bonuses ( which for Scientists can be massive ) is built into such a system rewarding long term planning and commitment into a tech field without getting lost because a random event decided it was time for that scientist to go.

HoI4 also have a diminishing returns built in here so that the first 10% of efficiency is gained much faster than the last 10% and that works really well to balance it out and reward very long term commitments.
Title: Re: C# Aurora v0.x Suggestions
Post by: space dwarf on October 24, 2018, 01:28:30 PM
To be fair, Hoi 4 is using Grit-and-grease man-powered assembly lines instead of super-hightech space-age omnifactories that use physics-defying elements
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on October 24, 2018, 04:32:06 PM
To be fair, Hoi 4 is using Grit-and-grease man-powered assembly lines instead of super-hightech space-age omnifactories that use physics-defying elements

So you mean in the future that experience and knowledge is not going to advance so efficiency rise over time? Every project you start will have all the kinks and problems already solved and fixed, that sound more like clairvoyance type stuff to me... ;)
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on October 24, 2018, 04:40:46 PM
I hope the research system is redesigned at some point. It is way to linear and not that interesting as a mechanic at the present.

Technologies which boost industry, research and economy should work very different from engineering and theoretical development. I think labs should be dedicated to a certain field but you should be able to convert them at a lower cost.

Scientist bonuses should not be immediately applicable to research projects but accumulated over time so there is a real choice between long term and short term planning. Instead of administration being a restriction on number of labs it could be a faster growth of science bonuses or some such.

I certainly don't want this to happen before C# Aurora is launched but at least that it perhaps is considered in some way down the line. The current system are a bit "gamey", you can role-play some restrictions of course, the same with industry.

I would love for industry construction to behave in a similar way where you can make long term plans or short term investment. Sort of like production lines in HoI 4 with a gearing bonus towards different projects. If you produce lots of things of a specific item you will produce that thing more and more efficiently over time... up to a certain limit based on technology or engineering skills.

Yes this is something I would love as well in the far future.

I think Research and Industry construction could use similar mechanics. Basically start any new factory/lab at low efficiency (5-20%) and have them gradually, over some years build up proficiency in the area or category they work until a maximum of 100%

This means you want to make a long term plan that feels more realistic and resemble real limits rather than put 30/30 labs or 600/600 of your factories on a single project that you rush. It also means that you want to try to have some stuff building/researching in most categories in case you need something urgent from that category.

In fact I would much rather prefer if some of the leader bonuses ( which for Scientists can be massive ) is built into such a system rewarding long term planning and commitment into a tech field without getting lost because a random event decided it was time for that scientist to go.

HoI4 also have a diminishing returns built in here so that the first 10% of efficiency is gained much faster than the last 10% and that works really well to balance it out and reward very long term commitments.

I also don't see why the same efficiency system could not apply to shipyards as well. Every time you change a yard its efficiency lowers based on how much it need to change. If you change it to a completely different type of ships the efficiency goes down quite allot... if it is just a slight adjustment to an existing ship not so much. Over time efficiency rise to 100%.

This could have a realistic impact on ship design in a relatively easy and straight forward way. It will be way more expensive (or time consuming) to build highly specialized ships especially if they are large until you have a sufficiently large and advance economy.

I also think that efficiency should effect not only time but also cost of building things... so building allot of the same stuff should ultimately make it somewhat cheaper to produce... at least from a wealth perspective not necessarily resource perspective.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on October 24, 2018, 05:27:15 PM
Actually, if historical production schedules are anything to go by?

You are likely to see the 'mass produced' ships, the small ships, to get regular design updates and irregular complete redesigns of the types of ships. Because these ships are produced in large enough numbers that such a standardized design is desirable and it's practical to update regularly. The medium size ships? That's the point where an entire class is designed and allocated all at once. Sure the entire class is standardized, and given the time it takes to go from design to ship if the entire class doesn't get constructed at once (it won't be) you're likely to see new builds using refined designs and newer equipment while their older siblings languish with older stuff until a fleet wide update program.

But the big ships?

Big ships are bespoke. All of them. The US build ten of its Nimitz class carriers, but it took from 1968 to 2006 to build all of them. Which means that basically every time a carrier was getting build the US had the time to look at what was working, what was not and redesigning and refining the Nimitz class with every new ship. You could make a decent argument that calling it the Nimitz class is mistaken as each ship could be considered a subclass of the design by the time the keels got laid down.


There's a point in production, especially when the R&D cycle is running fast, where creating a factory for serial production optimization is not profitable, because it takes too long to build even a single item to even consider producing a second with the same setup when it's already obsolete.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on October 24, 2018, 06:14:29 PM
Actually, if historical production schedules are anything to go by?

You are likely to see the 'mass produced' ships, the small ships, to get regular design updates and irregular complete redesigns of the types of ships. Because these ships are produced in large enough numbers that such a standardized design is desirable and it's practical to update regularly. The medium size ships? That's the point where an entire class is designed and allocated all at once. Sure the entire class is standardized, and given the time it takes to go from design to ship if the entire class doesn't get constructed at once (it won't be) you're likely to see new builds using refined designs and newer equipment while their older siblings languish with older stuff until a fleet wide update program.

But the big ships?

Big ships are bespoke. All of them. The US build ten of its Nimitz class carriers, but it took from 1968 to 2006 to build all of them. Which means that basically every time a carrier was getting build the US had the time to look at what was working, what was not and redesigning and refining the Nimitz class with every new ship. You could make a decent argument that calling it the Nimitz class is mistaken as each ship could be considered a subclass of the design by the time the keels got laid down.


There's a point in production, especially when the R&D cycle is running fast, where creating a factory for serial production optimization is not profitable, because it takes too long to build even a single item to even consider producing a second with the same setup when it's already obsolete.

And that is the type of decision making I'm after. Do I build a good multi-purpose ship so I can keep updating it cheap or do I do for extreme specialization but suffer the efficiency when I need to swap out half the ship in one go.

Smaller ships have the benefit of having more an numerous yards and slipways so can still be built and upgraded relatively fast but you still suffer if you change their design too much and essentially make them new ships.

The reason why smaller ships are upgraded and change more is because they are cheaper and less complex. This will work same in Aurora if you keep their components decently small and not too specialized. In Aurora terms an upgrade of a sensor or a new engine is something rather different from most of the things we do to ships today. If ships engines was 25-30% of a ships weight today these would not be upgraded very often. That would be like upgrading the nuclear engine to a brand new one on a carrier for example, probably not very practical. Minor upgrades are too small for Aurora.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on October 24, 2018, 09:40:48 PM
I could see a system of rnd-ing existing designs to a new variant that benefits at a loss (so not fully benefitting from) from say higher EM tech for sensors. Then you can retrofit existing ships to the new spec without huge retooling.  That would have to be it's whole own new feature though.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on October 25, 2018, 03:21:47 AM
The retooling cost is intended to simulate the cost difference between building another ship of the same type, or designing a new class.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on October 25, 2018, 04:19:42 AM
With modern day computers the cost of designing a new ship is pretty much entirely just money and time. This is admittedly in no small part because there are massive databases with known materials and their behaviours that can be referred to when designing and simulating a new ship, obviating much of the need for prototypes and small scale tests that are later scrapped.

TN materials don't have this advantage, not early on, but as the knowledge of TN materials and their physics grows and develops this will become true of them as well. Because of this it might be more accurate to render the cost of retooling to nearly nothing except for some time and money but make research eat TN minerals. Of course, that would be a major shift in the game mechanics...
Title: Re: C# Aurora v0.x Suggestions
Post by: El Pip on October 25, 2018, 08:52:08 AM
With modern day computers the cost of designing a new ship is pretty much entirely just money and time. This is admittedly in no small part because there are massive databases with known materials and their behaviours that can be referred to when designing and simulating a new ship, obviating much of the need for prototypes and small scale tests that are later scrapped.

TN materials don't have this advantage, not early on, but as the knowledge of TN materials and their physics grows and develops this will become true of them as well. Because of this it might be more accurate to render the cost of retooling to nearly nothing except for some time and money but make research eat TN minerals. Of course, that would be a major shift in the game mechanics...
You've already got the Shipyard Operations tech which makes re-tooling cheaper and faster, that does a decent job of covering the idea of learning about how to make ships out of TN material and building up such databases of parts and properties.

Having to either ship minerals out to R&D planets, or put automines next to them, sounds like additional micro without any real gameplay benefit. Not unless R&D sucked up huge amounts of minerals (comparable to shipbuilding say) and it was something else that might cause a resource crash.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on October 25, 2018, 10:36:13 AM
With modern day computers the cost of designing a new ship is pretty much entirely just money and time. This is admittedly in no small part because there are massive databases with known materials and their behaviours that can be referred to when designing and simulating a new ship, obviating much of the need for prototypes and small scale tests that are later scrapped.

Retooling = Ordering and installation of tools needed to make high end ( military or aerospace grade ) products today is a huge part in the cost and time delays of anything you want to make that's larger than a cellphone...

Probably even bigger than it was in the old times when sub mm precision was not needed, and when your tools were not manufactured on the other side of the globe by some specialists...



If you want a more accurate or realistic cost of retooling and shipyard flexibility what you could do is the following:
- Each generic ship component gets a "re-usability" stat value which represents how much of previous ship designs can be reused.
- All player designed ship components have say 95% re-usability value ( As long as you re-use the same component retooling is super cheap )
- The cost of retooling from one ship design to the next then is calculated by using the ( 1 - [re-usability %] )

Example:
You swap from a ship using 250 ton of crew quarters that have a re-usability value of say 70%, to a new design that need 450 tons of crew quarters. Since you already have the tooling required to make 70% of what's needed you only need to pay for 30% of those 450 tons of crew quarters retooling impact. This is then applied for every component in the ship, until the final cost of retooling or a true average % is arrived at.
Title: Re: C# Aurora v0.x Suggestions
Post by: Conscript Gary on October 25, 2018, 05:08:34 PM
Suggestion: A new ground combat order for fighters called Combat Orbit Patrol (COP). When active, a fighter with that order is protected from naval combat and operates much like an STO unit- capable of firing its onboard weapons at ships in orbit, being detected as a separately-targetable category of unit, and being vulnerable to ground-based fire and bombardment.

This would both model typical sorties from ground-based craft that have the reach to touch ships in orbit, and bring back a way to have pseudo missile bases if you were to design a fighter with no engines and suitable weapons.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on October 25, 2018, 05:20:06 PM
This is more of just an RP thing, but i'd like a codex of all the individual ships that were build/destroyed with their history as well. Just to give a sort of "funeral" to ships that pioneered space travel.
Title: Re: C# Aurora v0.x Suggestions
Post by: Ranged66 on October 26, 2018, 02:33:22 AM
This is more of just an RP thing, but i'd like a codex of all the individual ships that were build/destroyed with their history as well. Just to give a sort of "funeral" to ships that pioneered space travel.

This would be pretty good. Maybe some kind of historical records too, listing how many kills it got, how many missiles it shot down. Systems explored, bodies surveyed, jump points found... Stats for ships would be pretty neat.
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on October 26, 2018, 11:38:36 AM
This is more of just an RP thing, but i'd like a codex of all the individual ships that were build/destroyed with their history as well. Just to give a sort of "funeral" to ships that pioneered space travel.

This would be pretty good. Maybe some kind of historical records too, listing how many kills it got, how many missiles it shot down. Systems explored, bodies surveyed, jump points found... Stats for ships would be pretty neat.

Just write it down as it happens.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on October 26, 2018, 03:35:04 PM
This is more of just an RP thing, but i'd like a codex of all the individual ships that were build/destroyed with their history as well. Just to give a sort of "funeral" to ships that pioneered space travel.

This would be pretty good. Maybe some kind of historical records too, listing how many kills it got, how many missiles it shot down. Systems explored, bodies surveyed, jump points found... Stats for ships would be pretty neat.

Just write it down as it happens.

It'd be more convenient to have all the information located in one window and auto logged for us.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on November 02, 2018, 03:40:45 AM
Mineral accessability above 1.0, perhaps even with no limit. This can create worlds that are super valuable due to their extremely rich values in one or two minerals, despite not having any others. As opposed to at the moment, where the most valuable worlds are the ones with low accessability to a lot of minerals. Adds a bit to game dynamics I think. Encourages "outposts" that are non-self sustaining and makes the micromanagement worthwhile.

Some possible rules:
* Probability of accessability above 1.0 is lower the higher it is. Statistics is not my strongest suit, but I can try to find a nice distribution to use if you want.
* Accessability drops extra fast above 1.0. Perhaps with an extra modifier.
* Having more than 1 or max 2 minerals above 1.0 on a body should be near impossible.

Couple of potential options for implementing:
* Just change the current range from 0-1.0 to 0-2.0 but keep initial homewoorld generation to 0-1.0 (simplest)
* Change the distribution of accessability generation to something with a tail of lower probability.
* Randomly generate 0,1 or 2 "High access" minerals on a body and give them a random +0.5 to +1 accessability.

I actually like the first option.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on November 03, 2018, 05:57:05 PM
Have riots occur at high unrest where you lose wealth and buildings are damaged.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 03, 2018, 05:59:19 PM
Have riots occur at high unrest where you lose wealth and buildings are damaged.

I'm actually considering having insurgents / rebels / partisans / freedom fighters (choose as need) appear at higher unrest levels. The fighting will cause collateral damage and they might even win and take over the population.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on November 03, 2018, 06:03:01 PM
If they win and take over a population, could you give them all the same abilities as any other NPR, like building ships, training ground troops, and building colonies?
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on November 03, 2018, 06:50:45 PM
Have riots occur at high unrest where you lose wealth and buildings are damaged.

I'm actually considering having insurgents / rebels / partisans / freedom fighters (choose as need) appear at higher unrest levels. The fighting will cause collateral damage and they might even win and take over the population.

As long as we have some choice as to how this new empire behaves, I'd love this.

I could see it being Rebels becoming full NPR's, which would be fun for the one empire solo players. Or an option for them to become a sort of Shallow NPR, where they don't expand or colonize, but build ships and ground forces to attempt to hold their planets. A final option should be for them to become a player controlled empire, for when your going full multi-empire roleplay.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on November 03, 2018, 06:55:40 PM
I personally think it would be best if the player had some way to take control of the rebels from a SM perspective, otherwise I think they should be a full NPR on the assumption that would be both the simplest and most logical solution.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 03, 2018, 06:56:28 PM
If they win and take over a population, could you give them all the same abilities as any other NPR, like building ships, training ground troops, and building colonies?

This is not straightforward but might be possible - probably not in the first version though.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on November 03, 2018, 08:00:32 PM
Casualties after ships go beyond their deployment time? Because I have this ship thats been out for 127 years and somehow it still has the same crew.
Title: Re: C# Aurora v0.x Suggestions
Post by: Breadabix on November 04, 2018, 07:01:56 PM
I would like to see the range of ship commands extended.  For example the survey nearest object order, it has a range of 10 billion km which in most circumstances is ok, then you come across a system where theres planets/asteroids, sometimes hundreds of them, that are 50 billion km away, sometimes more.  Maybe have this as something that is extended as you research better technology, and/or add more survey parts to a ship.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 04, 2018, 08:12:13 PM
I would like to see the range of ship commands extended.  For example the survey nearest object order, it has a range of 10 billion km which in most circumstances is ok, then you come across a system where theres planets/asteroids, sometimes hundreds of them, that are 50 billion km away, sometimes more.  Maybe have this as something that is extended as you research better technology, and/or add more survey parts to a ship.

I'm pretty sure the 10 Terameter limit is a relic of VB6's performance issues.  C# Aurora's search algorithm can likely handle much longer distances, and may even have already been modified to do so.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tree on November 05, 2018, 02:42:51 AM
Since we're on surveys, would it possible to add a "survey next five planets/moons" order? Sometimes there's just too many asteroids and I want to survey planets first, so I can't give the "5 bodies" order, but "survey nearest planet or moon" is noticeably slower if you go by 5-days turns. I guess once a ship finishes its survey order, it waits for the end of the 5 days increment to generate its new survey order, while the ships with "survey next five system bodies" have a list to go through and don't waste as much time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 05, 2018, 03:15:04 AM
I would like to see the range of ship commands extended.  For example the survey nearest object order, it has a range of 10 billion km which in most circumstances is ok, then you come across a system where theres planets/asteroids, sometimes hundreds of them, that are 50 billion km away, sometimes more.  Maybe have this as something that is extended as you research better technology, and/or add more survey parts to a ship.

I'm pretty sure the 10 Terameter limit is a relic of VB6's performance issues.  C# Aurora's search algorithm can likely handle much longer distances, and may even have already been modified to do so.

Performance isn't the main concern. With a much higher limit, geo survey ships potentially will go sailing off into the middle of nowhere and then run out of fuel. A better option might be for me to introduce a distance option for standing orders at the fleet level or perhaps have 'survey within 10m', 'survey within 25m', etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 05, 2018, 03:16:07 AM
Since we're on surveys, would it possible to add a "survey next five planets/moons" order? Sometimes there's just too many asteroids and I want to survey planets first, so I can't give the "5 bodies" order, but "survey nearest planet or moon" is noticeably slower if you go by 5-days turns. I guess once a ship finishes its survey order, it waits for the end of the 5 days increment to generate its new survey order, while the ships with "survey next five system bodies" have a list to go through and don't waste as much time.

OK, sounds like a good idea.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on November 05, 2018, 03:39:17 AM
Since we're on surveys, would it possible to add a "survey next five planets/moons" order? Sometimes there's just too many asteroids and I want to survey planets first, so I can't give the "5 bodies" order, but "survey nearest planet or moon" is noticeably slower if you go by 5-days turns. I guess once a ship finishes its survey order, it waits for the end of the 5 days increment to generate its new survey order, while the ships with "survey next five system bodies" have a list to go through and don't waste as much time.
You can circumvent this easily by using 1-day turns and Auto-Turns ON options.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 05, 2018, 03:45:51 AM
Steve.... did you give any more thoughts into changing the Jump Drive requirement and size of the jump ship?

I think there are many changes in favour of smaller ships and I think this could be one good change in favour of bigger ships. It sometimes feel a bit restrictive to build bigger ships at low to mid tech levels because you also need to match them with an equal ship to jump them through jump point. It would open up some more strategic possibilities if we could use smaller jump ships to ferry larger military ships to their destinations.

I mostly end up adding the cheapest things possible to these ships so they require as little build material possible unless I can make a proper command ship out of it. But with increasing size I run out of good command equipment to put in that ship and are left with hangar space to fill them out which is cheap and versatile.

But in general I would like the option to build dedicated jump ships without having to add stuff to it just to make it bigger.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 05, 2018, 03:53:16 AM
Steve.... did you give any more thoughts into changing the Jump Drive requirement and size of the jump ship?

I think there are many changes in favour of smaller ships and I think this could be one good change in favour of bigger ships. It sometimes feel a bit restrictive to build bigger ships at low to mid tech levels because you also need to match them with an equal ship to jump them through jump point. It would open up some more strategic possibilities if we could use smaller jump ships to ferry larger military ships to their destinations.

I mostly end up adding the cheapest things possible to these ships so they require as little build material possible unless I can make a proper command ship out of it. But with increasing size I run out of good command equipment to put in that ship and are left with hangar space to fill them out which is cheap and versatile.

But in general I would like the option to build dedicated jump ships without having to add stuff to it just to make it bigger.

Although I haven't made the change yet, I think I am going to remove the ship size limitation and just go with jump drive capability.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tree on November 05, 2018, 04:05:35 AM
Since we're on surveys, would it possible to add a "survey next five planets/moons" order? Sometimes there's just too many asteroids and I want to survey planets first, so I can't give the "5 bodies" order, but "survey nearest planet or moon" is noticeably slower if you go by 5-days turns. I guess once a ship finishes its survey order, it waits for the end of the 5 days increment to generate its new survey order, while the ships with "survey next five system bodies" have a list to go through and don't waste as much time.
You can circumvent this easily by using 1-day turns and Auto-Turns ON options.
I don't know about others, but auto-turns are kinda painful for me to stop. Takes several tries everytime, and occasionally the system map window slips back behind every other window, it's not too bad if I set it to 2 minutes while NPRs are fighting and it ends up taking me 30 in-game minutes to finally manage to stop the autoturns, but with 1-day, I'd lose a lot of time.
Plus, IIRC, it's still slower for 5 1-day autoturns than a single 5 days turn.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 05, 2018, 04:49:45 AM
Performance isn't the main concern. With a much higher limit, geo survey ships potentially will go sailing off into the middle of nowhere and then run out of fuel. A better option might be for me to introduce a distance option for standing orders at the fleet level or perhaps have 'survey within 10m', 'survey within 25m', etc.

Easily compensated with a 'refuel at 50%' conditional order.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on November 05, 2018, 08:01:25 AM
Some QoL improvements I haven't seen any mention of is a little more autonomy, especially for survey ships.  In my current game, I've just finished solidifying control over my local systems from some persistent and aggressive spoilers and can begin hunting down the NPR I started the game with.  To that end, I currently have over 70 survey ships in full swing and that number is growing.  Keeping them all busy, and ever expanding my horizons is rapidly becoming all I do from turn to turn.

A few things come to mind for ship movement automation and fuel to ease player workload in managing large numbers of ships with automated standing orders.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on November 05, 2018, 09:18:09 AM
If they win and take over a population, could you give them all the same abilities as any other NPR, like building ships, training ground troops, and building colonies?
For roleplaying options, it might be most interesting of the SM can choose what kind of player it will become, when it happens. In a multiplayer game he can offer the new position to a potential new player who then plays them as a player - or if no interest, he can set them to NPR.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on November 05, 2018, 09:34:31 AM
Steve, in your posting "Tactical map in background" you wrote: "C# does not have a starting menu bar in the same way as C#." I think the latter C# was meant to be VB6... .
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on November 05, 2018, 09:41:27 AM
Unrest should increase when unemployment rate is too high. People do want jobs! - Or if unemployment rises over a certain percentage, the civilian sector will begin employing those people into service industries. Takes them away from you if you later need them for production. However, if it switches around and you begin to have need of workers, and service industries do have more people empoloyed than they per game rules should have, they will (slowly) release those people which then will fill up your empty industries.

This would mostly be for cosmetics - maybe there should be a reasonable punishment for your "service overemployments" applied. But I have no idea at the moment what could be reasonable. Maybe people get lazy and the overall productivity reduces.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on November 05, 2018, 10:20:03 AM
Any plans of adding resource silos for TN materials, which then can be attacked by the new ground forces... ? Rather then invading a planet for takeover one could then raid the planet to destroy its depots and cripple the enemy this way... .

Also would open a way for small infiltration units for sabotage or piracy...
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 05, 2018, 10:22:33 AM
Steve, in your posting "Tactical map in background" you wrote: "C# does not have a starting menu bar in the same way as C#." I think the latter C# was meant to be VB6... .

Thanks - will fix.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on November 05, 2018, 10:59:31 AM
Unrest should increase when unemployment rate is too high. People do want jobs! - Or if unemployment rises over a certain percentage, the civilian sector will begin employing those people into service industries. Takes them away from you if you later need them for production. However, if it switches around and you begin to have need of workers, and service industries do have more people empoloyed than they per game rules should have, they will (slowly) release those people which then will fill up your empty industries.

This would mostly be for cosmetics - maybe there should be a reasonable punishment for your "service overemployments" applied. But I have no idea at the moment what could be reasonable. Maybe people get lazy and the overall productivity reduces.
This isn't a good thing because Aurora does not model commercial sector and non-TN industrial sector requiring work force. Logically, either there is a massive invisible population that produces trade goods, or those goods are actually produced by the unemployed population. This also doesn't mesh well with RP-scenarios where a nation only uses a portion of its real population for TN - for example I usually cut down 3rd world populations to simulate the general low education level as well as a balance measure.

Thus Steve would need to add a fourth sector to each colony - environment, service, commercial and TN-industry, and the relevant mechanism for populations to switch jobs. After all, not many nations can just command people to quit their day job at the mobile phone assembly line and instead start making missiles.

I think this is something that should be part of a larger population and economy overhaul, far down the line.

I don't know about others, but auto-turns are kinda painful for me to stop. Takes several tries everytime, and occasionally the system map window slips back behind every other window, it's not too bad if I set it to 2 minutes while NPRs are fighting and it ends up taking me 30 in-game minutes to finally manage to stop the autoturns, but with 1-day, I'd lose a lot of time.
Plus, IIRC, it's still slower for 5 1-day autoturns than a single 5 days turn.
Five 1-day turns might take a little longer than a single 5-day turn, but the auto-turns stop automatically when construction cycle runs, or something else that interrupts it, like a hostile contact, happens. So you won't lose out on production or research.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 05, 2018, 11:12:33 AM
The problem with this is that at least early on in the game it's impossible to keep up with population growth on your home world, never mind on your far more reproductively active colonies.

I mean, at game start a Construction Factory produces 10 BP per year, and it takes 120 BP to construct 1 Construction factory. This would imply that, roughly speaking you can double your construction capacity every 12 years, and a population growth of about 6% per year. But you aren't building just the construction factory.

You also need mines to fuel those factories, and those either cost 120 BP, or 240. Luckily the 120 BP ones require an equal amount of personnel, but they don't have equal production. You are very unlikely to get a planet with .5 Duranium, .25 Tritanium and .25 Vendarite after all. So you probably need an uncertain amount of more mines because that's just how Aurora rolls, and that's if you don't need to import materials from a place you can't mine except with an automated mine.

And automated mines? They triple the effective BP cost of running your ever expanding economy. And a 2 percent population growth is something even your homeworld is likely to exceed in the early game. Which I repeat, renders it impossible to keep up with your ever expanding economy.

You need to invest enough research in mining and construction speed boosting technologies to keep up. As this analysis doesn't even consider the costs of building all the other things you need to create an empire, just the things you need to keep building it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 05, 2018, 11:16:17 AM
Any plans of adding resource silos for TN materials, which then can be attacked by the new ground forces... ? Rather then invading a planet for takeover one could then raid the planet to destroy its depots and cripple the enemy this way... .

Also would open a way for small infiltration units for sabotage or piracy...

I have considered this for both minerals and fuel, although it would have to be extended to missiles, ship components, etc. It would be a lot of extra work/management/UI. The question is whether that game play benefit would be worth it.

Another enhancement I have long considered is whether power to run everything should be required, from ground-based solar (distance from sun), geothermal (on high tectonic), TN reactors like those on ships, orbital solar collectors or even stations near the sun, etc. and whether power can be beamed and at what efficiency. That adds an extra layer of complexity and new infrastructure to be defended, but again it is a case of management vs game play benefit.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 05, 2018, 11:25:29 AM
This isn't a good thing because Aurora does not model commercial sector and non-TN industrial sector requiring work force. Logically, either there is a massive invisible population that produces trade goods, or those goods are actually produced by the unemployed population. This also doesn't mesh well with RP-scenarios where a nation only uses a portion of its real population for TN - for example I usually cut down 3rd world populations to simulate the general low education level as well as a balance measure.

Thus Steve would need to add a fourth sector to each colony - environment, service, commercial and TN-industry, and the relevant mechanism for populations to switch jobs. After all, not many nations can just command people to quit their day job at the mobile phone assembly line and instead start making missiles.

I think this is something that should be part of a larger population and economy overhaul, far down the line.

Actually, this can be considered part of the 'Services' sector. 25% is just what's available, theoretically speaking, is available for government provided jobs, while the remainder is dedicated to maintaining the basic needs (agriculture) and the whole consumer goods thing.

Any plans of adding resource silos for TN materials, which then can be attacked by the new ground forces... ? Rather then invading a planet for takeover one could then raid the planet to destroy its depots and cripple the enemy this way... .

Also would open a way for small infiltration units for sabotage or piracy...

I have considered this for both minerals and fuel, although it would have to be extended to missiles, ship components, etc. It would be a lot of extra work/management/UI. The question is whether that game play benefit would be worth it.

Another enhancement I have long considered is whether power to run everything should be required, from ground-based solar (distance from sun), geothermal (on high tectonic), TN reactors like those on ships, orbital solar collectors or even stations near the sun, etc. and whether power can be beamed and at what efficiency. That adds an extra layer of complexity and new infrastructure to be defended, but again it is a case of management vs game play benefit.

It'd involve an entirely new overhaul of the ground combat system too. It's better to wait for a new iteration of the game.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 05, 2018, 11:52:01 AM
Any plans of adding resource silos for TN materials, which then can be attacked by the new ground forces... ? Rather then invading a planet for takeover one could then raid the planet to destroy its depots and cripple the enemy this way... .

Also would open a way for small infiltration units for sabotage or piracy...

I have considered this for both minerals and fuel, although it would have to be extended to missiles, ship components, etc. It would be a lot of extra work/management/UI. The question is whether that game play benefit would be worth it.

Another enhancement I have long considered is whether power to run everything should be required, from ground-based solar (distance from sun), geothermal (on high tectonic), TN reactors like those on ships, orbital solar collectors or even stations near the sun, etc. and whether power can be beamed and at what efficiency. That adds an extra layer of complexity and new infrastructure to be defended, but again it is a case of management vs game play benefit.

I think it is worth a consideration AFTER C# is launched to us...  :)

It would also mean that you could use Sorium for other purposes than as fuel. Perhaps large power plants and solar reflection arrays give out abnormal amounts of heat so you might want to use Sorium based power in some military installations... perhaps you can block or disrupt power distribution with fleets in some way which also mean Solium based power generation can be important for military purposes.

I would also like for all ship components to require power as well as weapons. Ships should then have both reactors and generators and could use Sorium for power as well as the reactors... or reactors should perhaps use Sorium to run things on the ships entirely and the reactor is the amount of Sorium you can burn and generators the amount of energy you can store.

Anyway... there are allot more things that could be done with energy in general in the game. Fuel and Sorium is important but would make the game even more important to manage if it was to be expanded in that way.
Title: Re: C# Aurora v0.x Suggestions
Post by: Brian on November 05, 2018, 01:40:23 PM
Would it be possible to set a limit on the shipyards continuous capacity expansion.  For example I want to build the shipyard up to 80,000 ton capacity I can either set it to continuous expansion and monitor when this is reached, or I can use several commands over time to build up to the eventual size required.  If instead when I start the continuous expansion I set a limit of 80,000 and then have the shipyard stop expanding, It would be simpler and cause less micromanagement as well.

Brian
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on November 05, 2018, 03:21:12 PM
I *think* Steve mentioned that at some point because it was asked for earlier. It would be a very useful Quality of Life improvement. "Continual Capacity Expansion" opens a new sub-menu where you can write in the size.
Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on November 05, 2018, 04:29:34 PM
Any plans of adding resource silos for TN materials, which then can be attacked by the new ground forces... ? Rather then invading a planet for takeover one could then raid the planet to destroy its depots and cripple the enemy this way... .

Also would open a way for small infiltration units for sabotage or piracy...

I have considered this for both minerals and fuel, although it would have to be extended to missiles, ship components, etc. It would be a lot of extra work/management/UI. The question is whether that game play benefit would be worth it.

Another enhancement I have long considered is whether power to run everything should be required, from ground-based solar (distance from sun), geothermal (on high tectonic), TN reactors like those on ships, orbital solar collectors or even stations near the sun, etc. and whether power can be beamed and at what efficiency. That adds an extra layer of complexity and new infrastructure to be defended, but again it is a case of management vs game play benefit.
I would be happy if reactor power was required to run ship components, weapons, etc. Though it can always be surmised that the weight of reactor is already calculated when you add components, just like life support is, and the actual location of that reactor and its potential to be damaged is just abstracted away since its minor compared to the energy requirements of energy weapons. Though shields should need reactor power :p
Oh, and reactors should burn through fuel.
Title: Re: C# Aurora v0.x Suggestions
Post by: ardem on November 05, 2018, 05:00:57 PM
Suggestion: Organisational Number - Ground Combat

Not sure is there have been a  suggestion on this, one thing I never liked about Ground Forces was the ability to continue to fight day after day, as long as they have supplies without rest. This mean combat instead of lasting months really on every last about a month total, no matter the size of the fights.

What I would love to see is something like an organisational number (very similar to HOI), which reduced each time the element is is combat. These numbers replenish over time, this stop the continual attack and allows combat to be a longer process then the current system. Or the very least swap out formations on the attack

The organisational number is an arbitrary number which describes a unit capabability over the length of time it fights, it is suppose to take into account combat fatigue, maintainence, continual combat degrades communications and organisational structure making commands slower.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 05, 2018, 05:37:02 PM
Suggestion: Organisational Number - Ground Combat

Not sure is there have been a  suggestion on this, one thing I never liked about Ground Forces was the ability to continue to fight day after day, as long as they have supplies without rest. This mean combat instead of lasting months really on every last about a month total, no matter the size of the fights.

What I would love to see is something like an organisational number (very similar to HOI), which reduced each time the element is is combat. These numbers replenish over time, this stop the continual attack and allows combat to be a longer process then the current system. Or the very least swap out formations on the attack

The organisational number is an arbitrary number which describes a unit capabability over the length of time it fights, it is suppose to take into account combat fatigue, maintainence, continual combat degrades communications and organisational structure making commands slower.

This will probably happen anyway due to the high supply requirements of ground combat. Eventually both sides will slow down to non-supplied combat rates until fresh supplies can be assembled.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on November 05, 2018, 05:53:26 PM
Suggestion: Organisational Number - Ground Combat

Not sure is there have been a  suggestion on this, one thing I never liked about Ground Forces was the ability to continue to fight day after day, as long as they have supplies without rest. This mean combat instead of lasting months really on every last about a month total, no matter the size of the fights.

What I would love to see is something like an organisational number (very similar to HOI), which reduced each time the element is is combat. These numbers replenish over time, this stop the continual attack and allows combat to be a longer process then the current system. Or the very least swap out formations on the attack

The organisational number is an arbitrary number which describes a unit capabability over the length of time it fights, it is suppose to take into account combat fatigue, maintainence, continual combat degrades communications and organisational structure making commands slower.

I'm opposed. It would do nothing but add makework with switching formations from front line to rear and back.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on November 05, 2018, 06:17:58 PM
Shipyards should be able to be detooled for either no or minimal cost, to stop you from having functionally useless shipyards that will never have a new class assigned to them due to retooling costs.
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on November 05, 2018, 09:45:41 PM
I *think* Steve mentioned that at some point because it was asked for earlier. It would be a very useful Quality of Life improvement. "Continual Capacity Expansion" opens a new sub-menu where you can write in the size.

This, it would be incredibly nice to not have to issue ten seperate "Add 10,000 Tons" capacity expansions to bring my civilian shipyards up to grade. Being able to simply say "Grow to X Tonnage" with X being specified would be incredibly convenient for when I spool out extra yards.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on November 06, 2018, 01:54:54 AM
I agree and in fact if possible that would be a vastly superior alternative to the old system.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 06, 2018, 03:17:13 AM
Shipyards should be able to be detooled for either no or minimal cost, to stop you from having functionally useless shipyards that will never have a new class assigned to them due to retooling costs.

Even in VB6 Retooling cost is never higher than it would be for an empty shipyard. The cost is checked for empty or converting from the current tooled class. If converting is cheaper than empty, then that number is used. Otherwise empty is used.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on November 06, 2018, 05:59:11 AM
I didn't realize. Thank you for clarifying!
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on November 06, 2018, 06:24:52 AM
Unrest should increase when unemployment rate is too high. People do want jobs! - Or if unemployment rises over a certain percentage, the civilian sector will begin employing those people into service industries. Takes them away from you if you later need them for production. However, if it switches around and you begin to have need of workers, and service industries do have more people empoloyed than they per game rules should have, they will (slowly) release those people which then will fill up your empty industries.

This would mostly be for cosmetics - maybe there should be a reasonable punishment for your "service overemployments" applied. But I have no idea at the moment what could be reasonable. Maybe people get lazy and the overall productivity reduces.
This isn't a good thing because Aurora does not model commercial sector and non-TN industrial sector requiring work force. Logically, either there is a massive invisible population that produces trade goods, or those goods are actually produced by the unemployed population. This also doesn't mesh well with RP-scenarios where a nation only uses a portion of its real population for TN - for example I usually cut down 3rd world populations to simulate the general low education level as well as a balance measure.

Thus Steve would need to add a fourth sector to each colony - environment, service, commercial and TN-industry, and the relevant mechanism for populations to switch jobs. After all, not many nations can just command people to quit their day job at the mobile phone assembly line and instead start making missiles.

I think this is something that should be part of a larger population and economy overhaul, far down the line.

It's been a while since I played aurora, been waiting for the update since it was called 7.2, but I'm fairly convinced I remember that only a small proportion of the workforce was available for TN pursuits whilst the rest went into "services" or something of the sort. I assumed this modelled the civilian economy. It doesn't have to literally just be services.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on November 06, 2018, 09:26:46 AM
Would it be possible to set a limit on the shipyards continuous capacity expansion.  For example I want to build the shipyard up to 80,000 ton capacity I can either set it to continuous expansion and monitor when this is reached, or I can use several commands over time to build up to the eventual size required.  If instead when I start the continuous expansion I set a limit of 80,000 and then have the shipyard stop expanding, It would be simpler and cause less micromanagement as well.

Brian
Such an option would be great - and would make obsolete all prefixed value. Just imput target size and no of slipways - voila.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on November 06, 2018, 11:37:15 AM
Even in VB6 Retooling cost is never higher than it would be for an empty shipyard. The cost is checked for empty or converting from the current tooled class. If converting is cheaper than empty, then that number is used. Otherwise empty is used.

Wasn't VB6 retooling free for the first time you did it, assuming it was part of the shipyards initial construction cost to build it in such a way that the first design could be built?

( I don't agree it should be, unless the desired class of ship is locked at an early stage ).
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on November 06, 2018, 11:58:50 AM
It was and it is. I don't think Steve is changing it for C#
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on November 06, 2018, 12:38:57 PM
That was more to model the the shipyard being "built for spec" the first time. In effect, the cost of retooling for your first ship is included in the cost of the shipyard itself.

In other words, working as intended  :P
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 06, 2018, 01:08:49 PM
That was more to model the the shipyard being "built for spec" the first time. In effect, the cost of retooling for your first ship is included in the cost of the shipyard itself.

In other words, working as intended  :P

Yes, that's correct.
Title: Re: C# Aurora v0.x Suggestions
Post by: Titanian on November 07, 2018, 06:16:13 AM
I am strongly opposed to that feature. In the end, that means that tooling a new shipyard to a freighter first, and then a terraformer wastes lots of materials compared to doing it the other way around, which makes no sense. For expensive commercial designs (terraforming, maintainence), it even means that building a new shipyard is only marginally more expensive than retooling, and has the added benefit of having an additional shipyard.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on November 07, 2018, 09:22:29 AM
Almost as expensive as building a new shipyard AND spending about 5 years increasing its size to where it can build your expensive ship? Somehow I doubt it.

Regardless, now that you put it that way, it sounds quite realistic and as if it adds depth to the game, forcing you to plan your construction a bit ahead.

Not only working as intended, but already in the game as well.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tree on November 11, 2018, 10:21:27 AM
Would it be possible to add shipyard complexes activities to the "Player Race Production Overview" window? Adding slipway constructions, retoolings and the 1000/5000/10000/etc buildups to the "Shipbuilding" tab would be nice, along with the continual expansion up to a certain cap if you implement that, of course.

Since you're adding variant starts rules now, how about one that turns Jupiter into a small red dwarf, making the galilean moons inhabitable or close to? Oops, typing it now I remember how different are secondary stars treated from planets, might not be the easiest addition.
Title: Re: C# Aurora v0.x Suggestions
Post by: Marski on November 13, 2018, 04:06:39 PM
Has the military recruitment been talked about yet? Being able to choose if your armed forces are conscripts or volunteer-based professional military force, that sort of thing.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 13, 2018, 05:07:54 PM
Has the military recruitment been talked about yet? Being able to choose if your armed forces are conscripts or volunteer-based professional military force, that sort of thing.

Naval Crew and Officer academies will still have an 'experience level' setting, so your empire can produce much fewer high-quality Crew personnel, or a large number of standard-experience Crew.

There has been no discussion of applying the same system to ground force training, and thus being able to take longer to produce higher XP (or Morale, or whatever) units.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on November 14, 2018, 05:10:50 PM
A small change to the missile design UI:
Currently they are rated by hit chances against targets at certain speed. This is inconvenient most of the time, much more meaningful would be stating the target speed a missile achieves 10%, 50% and 100% hit chance for example.
Sure, the values are easily convertible enough, but 10kkm/s is far below the target speed of any  AMM
Title: Re: C# Aurora v0.x Suggestions
Post by: misanthropope on November 15, 2018, 11:10:50 AM
On the ordnance factory page, i'd love to have a button to mash that would compute a "missile census", counting the existing missiles by type as well as aggregating the loadout specs of my ships (including those building) by missile type.  if displaying all that data is a pita, just getting supply and demand numbers for one type (via dropdown?) would still be pretty godlike.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 15, 2018, 01:12:25 PM
On the ordnance factory page, i'd love to have a button to mash that would compute a "missile census", counting the existing missiles by type as well as aggregating the loadout specs of my ships (including those building) by missile type.  if displaying all that data is a pita, just getting supply and demand numbers for one type (via dropdown?) would still be pretty godlike.

The NPRs are doing all of the above in C# Aurora, so they know what missile types to build. Would be relatively easy to show to players too.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on November 15, 2018, 01:50:05 PM
Some ideas for tech development:
-Components can be added to design as soon as they are designed. The design cannot be built or locked until all the components have been researched, to you can essentially design a ship, tailor your components in one go and then submit all the projects for research.
-Themes should be able to contain default naming schemes for components. So you can specify your Missile Launchers to be named S{} Torpedo Tube by default, or turn Particle Beams into photon torpedoes. This would also be useful for foreign language themes, and all that is required is a bit of string formatting with the component parameters.
-Components should be able to be used as template for new components, like missiles currently work.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on November 15, 2018, 04:25:09 PM
It might be a good idea to make info the AI uses as inputs visible to players in general (when the info would be useful to the player), that way there is a way higher chance of noticing if its getting miscalculated (or noticing if the calculations ever break), which would hopefully lead to more reliable AI over the long term.
Title: Re: C# Aurora v0.x Suggestions
Post by: Agoelia on November 16, 2018, 04:29:28 AM
Quote from: QuakeIV link=topic=9841. msg111049#msg111049 date=1542320709
It might be a good idea to make info the AI uses as inputs visible to players in general (when the info would be useful to the player), that way there is a way higher chance of noticing if its getting miscalculated (or noticing if the calculations ever break), which would hopefully lead to more reliable AI over the long term.

Could you make an example out of that? I'm not really sure what you mean.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 16, 2018, 01:31:51 PM
I was thinking the other day about the new command structure of Aurora and about Ground Generals and Space Admirals. I really think that we should use the same Admin Command structure for both of these branches so Admin Commands should be able to hold both High Ranking generals or Fleet admirals. This I think are quite realistic because at the high end of things you will have both of these commands intertwined since they are both equally important and they will need to coordinate their efforts anyway.

Most skills should also work within both branches but that a General give slightly more bonus to ground forces and Admirals slightly more to fleet assets. But at strategic levels I think that both of these should be more or less equally important and competent.

In this way Armies would act as Fleets and you then have as many sub armies/fleets you can attach to each army or fleet. Both Fleets and Armies should be able to have sub fleets and sub army units attached to them, the only difference is that Fleets can only be commanded by Admirals and Armies only commanded by Generals and they both give less of their bonuses to any sub units that is not of their type.

But you should only be able to have Ships in a Sub-Fleet and Ground units in a Sub-Army but you could have a Sub-Army in a Sub-Fleet if you wish.

The point being if I want to simulate a typical US Marin Corp task force I would want to have both ships and ground troops in them. You could have a Sub-Fleet of Assault carriers with a few squadrons of fighters and a full marine brigade of troops. Such a Task-Force would then comprise a Fleet if Assault Carriers with their escorts and support ships attached to an Admin Command led by a Ground Commander. The Sub Fleet would be led by an Admiral and each brigade led by a Brigadier General as a Sub Army Unit attached to the Assault Sub-Fleet.

Might make the power structure a bit more complex but even more fun from RP and also sort of realistic. Do you want your generals or admirals in charge of a specific operation... probably depends on what their objectives are.

Each Admin command could just be designated as Naval or Ground and the game would attach the most appropriate rank to that position. Who outranks who within Navy or Ground is only important due to where they are in the tree... otherwise they are just added based on the command structure of their own internal organisation. This would mean that a Fleet Admiral can be led by a General in one place while commanding a General in another but never at the same time.

Thoughts?!?
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on November 19, 2018, 06:56:28 AM
On the ordnance factory page, i'd love to have a button to mash that would compute a "missile census", counting the existing missiles by type as well as aggregating the loadout specs of my ships (including those building) by missile type.  if displaying all that data is a pita, just getting supply and demand numbers for one type (via dropdown?) would still be pretty godlike.

The NPRs are doing all of the above in C# Aurora, so they know what missile types to build. Would be relatively easy to show to players too.
Hmmm, thinking about a reverse command. In the Fleet command window you can give a fleet the order to replenish missing missiles from planetary (or whatever) stockpile. Calculating, that the stockpiles wouldn't be enough, is easy for the computer. Auto-generating a production task which builds the missing missiles - would be a nice addon ;-)
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on November 20, 2018, 01:32:25 PM
Suggestion:

Make terraforming less braindead.  Right now, the terraforming system is really detailed, but it always boils down to the same actions as far as the player is concerned.  Add 0.1atm oxygen, remove poisons, add greenhouse/anti-greenhouse gas, remove excess pressure.  It's cool that the atmospheres are actually tracked and all, but there's no choices being made here.

I propose making terraforming actually involve some choices or trade-offs.  Maybe Mercury would be better not terraformed; solar panels work better with no atmosphere in the way.  Titan is better with it's cold and dense atmosphere; computation is more efficient the colder it is, thanks to Landauer's Limit, so a thick, cold atmosphere makes a great heatsink.  Make us have to choose between a habitable planet or a planet that's good for supercomputers or solar panels.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on November 20, 2018, 03:24:02 PM
Suggestion:

Make terraforming less braindead.  Right now, the terraforming system is really detailed, but it always boils down to the same actions as far as the player is concerned.  Add 0.1atm oxygen, remove poisons, add greenhouse/anti-greenhouse gas, remove excess pressure.  It's cool that the atmospheres are actually tracked and all, but there's no choices being made here.

I propose making terraforming actually involve some choices or trade-offs.  Maybe Mercury would be better not terraformed; solar panels work better with no atmosphere in the way.  Titan is better with it's cold and dense atmosphere; computation is more efficient the colder it is, thanks to Landauer's Limit, so a thick, cold atmosphere makes a great heatsink.  Make us have to choose between a habitable planet or a planet that's good for supercomputers or solar panels.
I would not bother too much about that. If anything terraforming should become more detailed in terms of opportunities. You should need some way to bind/extract harmful gasses, and you need something to release useful gasses to build up an atmosphere, instead of producing gas out of nothing.
So some planets may be inhospitable, but have the right resources to make them hospitable, while others might just be chunks of rocks you cannot possibly give an atmosphere.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 20, 2018, 03:34:53 PM
There are a number of changes in C# that affect terraforming, including hydrosphere requirements, planetary capacities, speed dependent on planet size, tide-locked planets have different temperature effects, etc.. While the mechanics are similar except for evaporation/condensation, there are a lot more factors in the decision of where to terraform.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 20, 2018, 04:24:13 PM
Still hoping for the inclusion of biosphere requirements and adjustment.

That, the hydrosphere and the atmosphere are all surface based. Messing with the magnetosphere would be... complex.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on November 20, 2018, 07:34:28 PM
There are a number of changes in C# that affect terraforming, including hydrosphere requirements, planetary capacities, speed dependent on planet size, tide-locked planets have different temperature effects, etc.. While the mechanics are similar except for evaporation/condensation, there are a lot more factors in the decision of where to terraform.
That just changes what planets are worth it though, there's still basically no decisions being made during the terraforming process.  Once a player has decided to terraform a world, the process is the same as it was on VB6.  Some worlds might take longer, some might be quicker, but the point is that there is still going to be an optimum way to terraform.  I am suggesting that there be trade-offs.  For example thinning Titan's atmosphere and warming it up will make it better for human habitation, but worse for running super-computers or any industry that generates a lot of waste heat.  There is a trade-off going on here that doesn't happen in either the old system or the new system.  It wouldn't just be "Do I terraform this world?" but rather "Do I terraform this world, and if so, in what way?"
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on November 20, 2018, 08:23:13 PM
Can we get two additional settings for Point Defence Modes? 

Specifically minimum salvo count per increment, and a minimum salvo size.

Right now, if I setup a missile defence with say,  (1v1 PD Mode 1270), then I literally spend one missile per inbound, even if there is just one inbound, and I have dozens of gauss turrets.  I waste missiles, lose fights I should have won.

I can not use the system at all, and manually fire on large/excess salvos so that the gauss defences can handle what remains.  This is incredibly tedious and not fun, but effective and I survive larger/longer attacks.

Could we just take the tedium almost entirely out and allow specifying how many salvos must be incoming before the FC cares, or how many missiles must be in any given salvo?

If I had gauss turrets that reliably stop 9+ per salvo, and enough turrets to engage 8 salvos per increment, then I really only need missiles for salvos larger than 9, or more numerous than 8 for any given increment.

Its not OP, because nothing stops me from stacking an ungodly amount of gauss and running a single stack formation - I get missile immunity with no ammunition expenditure at all.  Game the system with a very enticing civilian hull with an absurd amount of CIWS perhaps.

It just enables a more hands off approach to missile defence, letting the ships defend themselves with an efficiency closer to if you were fully hands on, minus the tedium.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on November 21, 2018, 07:37:27 AM
For example thinning Titan's atmosphere and warming it up will make it better for human habitation, but worse for running super-computers or any industry that generates a lot of waste heat.  There is a trade-off going on here that doesn't happen in either the old system or the new system.  It wouldn't just be "Do I terraform this world?" but rather "Do I terraform this world, and if so, in what way?"
But that makes absolutely no sense. It does not matter how much more solar energy you get on Mercury without atmosphere or how much easier it is to run supercomputer on Titan if humans would still need specialized infrastructure to live there. Any savings you get on energy or cooling would be offset by the cost of having to import infra to accommodate colonists. The value of a colony cost 0 world is priceless. I do understand what you're proposing, making the details of terraforming a decision, but there already is a decision on whether to terraform a body in the first place and with the additional new rules, that decision is a bit more complicated than before.
Title: Re: C# Aurora v0.x Suggestions
Post by: Person012345 on November 21, 2018, 09:30:33 AM
There are a number of changes in C# that affect terraforming, including hydrosphere requirements, planetary capacities, speed dependent on planet size, tide-locked planets have different temperature effects, etc.. While the mechanics are similar except for evaporation/condensation, there are a lot more factors in the decision of where to terraform.
That just changes what planets are worth it though, there's still basically no decisions being made during the terraforming process.  Once a player has decided to terraform a world, the process is the same as it was on VB6.  Some worlds might take longer, some might be quicker, but the point is that there is still going to be an optimum way to terraform.  I am suggesting that there be trade-offs.  For example thinning Titan's atmosphere and warming it up will make it better for human habitation, but worse for running super-computers or any industry that generates a lot of waste heat.  There is a trade-off going on here that doesn't happen in either the old system or the new system.  It wouldn't just be "Do I terraform this world?" but rather "Do I terraform this world, and if so, in what way?"
I don't think wht you're asking for makes that much sense. I wouldn't mind a little more detail to the process, but realistically I've only ever really seen terraforming proposed as making a planet more habitable. Indeed, there's a hint in the very word,"terraforming". I haven't seen it seriously argued that it might be a good idea to turn planet earth into a giant snowball or getting rid of all the atmosphere and I don't think this would really add much to gameplay to make this decision. You'd end up just having a bunch of template planets for specific purposes and the process would be identical.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 21, 2018, 12:48:43 PM
Actually, dumping dangerous substances into an atmosphere actually has a purpose in this game.

It's basically chemical warfare writ large. With the mass civilian casualties that comes with such a thing.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on November 26, 2018, 11:15:56 AM
With ground combat as it is now, I don't imagine that you're planning on any new components, but I would humbly suggest the ability to have infantry equipped as suicide bombers. Large amounts of damage, but the infantry dies when used. Perhaps a mechanic where you can make them out of population for cheap or something
Title: Re: C# Aurora v0.x Suggestions
Post by: Tree on November 26, 2018, 03:42:22 PM
If we're really going for "excess wealth is invested into improving the lives of citizens", could you make it so having excess wealth decreases unrest (or dampens unrest increases) and speeds up the political status change of conquered populations when you've reached your maximum?
And since now financial centers are going to be more useless than ever, maybe make it so they increase the maximum wealth you can accumulate (and by a lot more than they would now by providing yearly wealth). Which would at least make them vaguely useful to accumulate money and for civilian mining expansions, assuming it's still a roll of a 1-million-sided die versus your wealth and trying to roll under.
Title: Re: C# Aurora v0.x Suggestions
Post by: Erik Luken on November 26, 2018, 06:02:40 PM
I'd still like to see some facility to test designs outside of combat and workarounds such as gifting them to another race.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 26, 2018, 07:10:44 PM
And since now financial centers are going to be more useless than ever. . .

Do you heavily subsidize civilian shipping lines?  Do you exploit the heck out of the Earth-Luna infrastructure run?  Do your games last long enough to exhaust your home system minerals, and do you then move your heavy industry to colony worlds?  Do you even build imperial freighters?

I've never found Financial Centres to be useless.  In fact, I have always considered them essential.  They are literally the first thing I build, every game (since they don't require TN tech).  Turning resource-poor, population-rich worlds into banking havens is an essential step towards galactic conquest, and a fine retirement plan for Earth / Homeworld / forge worlds.

* * *

I, for one, would certainly prefer to try Steve's 'solution' to 'the Conv/TN Wealth problem' before suggesting a dozen or more 'improvements' to it.  Presonally, I've never found the wealth cushion to be a problem, but I've also never thought about it much.  Steve is exactly right when he says "This removes wealth as a consideration for many years and takes away meaningful decisions."  Until now, I considered that a good thing; I congratulated myself for my empire's sound financial planning.
Title: Re: C# Aurora v0.x Suggestions
Post by: Coleslaw35 on November 26, 2018, 07:27:46 PM
Would it be possible for shipping lines to also be able to deploy unarmed, unarmored troop transports? Then you could do what you do with civilian freighters and submit contract orders for different populations.    For example, Earth has 5 medium tank formations.   Earth also has an order to "provide" 3 of those formations.   Mars has an order to "request" 3 medium tank formations.   Civilian troop transports will transport those 3 formations to Mars.   If none of the active troop transports have the capacity to transport a formation, the shipping line may deploy a new model of transport that can hold all of the formation(s).   That way you wouldn't have to worry about smaller transports only being able to move parts of one formation at a time and having to track them throughout their journey, etc.

EDIT: Also, why is this post getting extra spaces in places I definitely am not putting them?     
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 26, 2018, 10:25:08 PM
EDIT: Also, why is this post getting extra spaces in places I definitely am not putting them?     

Because you don't have 10 legitimate posts yet, so you might be a spam 'bot.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tree on November 27, 2018, 01:28:10 AM
Do you heavily subsidize civilian shipping lines?  Do you exploit the heck out of the Earth-Luna infrastructure run?  Do your games last long enough to exhaust your home system minerals, and do you then move your heavy industry to colony worlds?  Do you even build imperial freighters?

I've never found Financial Centres to be useless.  In fact, I have always considered them essential.  They are literally the first thing I build, every game (since they don't require TN tech).  Turning resource-poor, population-rich worlds into banking havens is an essential step towards galactic conquest, and a fine retirement plan for Earth / Homeworld / forge worlds.

Population growth on its own does it all for free, cheaper and eventually faster than you can build financial centers. I'd rather use my resources, workforce and factory time on something else. Oh, and of course, wealth, too. I had completely forgotten financial centers also cost wealth when typing this.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on November 27, 2018, 03:03:10 AM
Population growth on its own does it all for free, cheaper and eventually faster than you can build financial centers. I'd rather use my resources, workforce and factory time on something else. Oh, and of course, wealth, too. I had completely forgotten financial centers also cost wealth when typing this.

If you can't grow your research & industry faster than your population can grow I think your either not expanding industry/research as aggressively as many of us do when we play, not play the game for as long or your much more active in colonizing, or a combination of them.

If you try and play an Empire where most population is on large worlds with low pop growth ( or keep them on the core homeworld ) you can grow your industry and research many times as fast as your population grows... which does inevitably lead to wealth shortage when you rely on only population taxes.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 27, 2018, 04:23:40 AM
Also leads to personnel shortages. There's now a cap on how large your planetary populations can grow after all.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tree on November 27, 2018, 06:05:27 AM
If you can't grow your research & industry faster than your population can grow I think your either not expanding industry/research as aggressively as many of us do when we play, not play the game for as long or your much more active in colonizing, or a combination of them.

If you try and play an Empire where most population is on large worlds with low pop growth ( or keep them on the core homeworld ) you can grow your industry and research many times as fast as your population grows... which does inevitably lead to wealth shortage when you rely on only population taxes.
I always run a deficit in the first few years, being in negative wealth is the norm. I solve it with a lot of colonies and conquests. Financial centers have never helped me one bit.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 27, 2018, 11:27:04 AM
There has been allot of talk about wealth and economics and one thing I would consider going forward is to give a production efficiency bonus for building the same type of ship in high quantities. This would represent more streamlined production routines, reduced cost of mass production of components, spare parts and tools.

Smaller ships should perhaps get a slight benefit in this process but not linear to its size... so a 1000t ship should not get double the efficiency reduction for every ship build than a 2000t ship.

This would intriduce a couple of more realistic choices in ship design and compromises you will need to do. It would also not make new technology a must to incorporate accross your entire fleets. You will have to seriously consider the reduced efficiency of modifying existing designs versus keep running older models a little longer.

This efficiency should also effect maintenance costs of ships. The more experience and efficient the production of a certain ship is the cheaper and more accessible spare parts, expertise etc becomes.

Production efficiency should then be reduced by the amount a ship is changed when you upgrade them. The more you change a design them more of the production efficiency you loose.

There could then be two new technologies. One that decide the maximum efficiency rate, this could start at 150% and go down to 50% where all ships start at 200% efficiency for a completely new ship model, which meant double the production cost.
The other technology would be the rate at which you gain production efficiency.

This technology and mechanics should impact fighters, ship components, ground units and ships built in shipyards.

It would hopefully not be too difficult to code and should not be too difficult to balance either.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 27, 2018, 12:00:17 PM
I don't disagree with anything you're asking for, and I would appreciate the added realism of such a system.  If we could wish it into existence tomorrow, I'd say "Go for it!"  My problem is a lot less tangible -- it's "what other thing are we not getting, because Steve only has so much programming time?"  If Production Efficiency modifiers crop up in C# Aurora 1.3, or 1.4, then great -- but I wouldn't want to delay C# Aurora 1.00 by a month (or even a week) to get them in.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 27, 2018, 03:12:55 PM
If anything, ship production bonuses should be based on how long it takes to build a ship and how long ago the previous ship was launched in such a case. Ships with long production times tend to get far less benefit from the builder's familiarity with the design than a ship that's build in a couple of weeks on a single slip.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on November 27, 2018, 03:41:06 PM
If anything, ship production bonuses should be based on how long it takes to build a ship and how long ago the previous ship was launched in such a case. Ships with long production times tend to get far less benefit from the builder's familiarity with the design than a ship that's build in a couple of weeks on a single slip.

I don't think this is really necessary. Ships themselves are not mass produced in assembly lines, and overall it will be just a buff to small units. They already have a massive buff that it is far easier to create small shipyards than to create massive ones. The cost of retooling already incentivises to keep building the same ships, simply increasing that cost would be the easiest way to achieve the same result instead of a complicated system to calculate when what was built.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 27, 2018, 03:50:59 PM
The way that I imagine it is that it will be based both on time to build and size. Bigger size also means you can automate and trim the production more, but smaller size should be slightly favored since you produce more ships in total numbers.

This would produce the effect that you can get a faster production efficiency with smaller ships BUT you will also tend to lose more efficiency when you upgrade smaller ships because they also tend to be more specialized and thus lose more efficiency when upgraded.

I also don't suggest this to be part of 1.0 release of C#... more as something to think about down the line.

In my opinion it would add some more interesting options of how you go about organizing ships not just based on direct efficiency of the components but also on future maintenance and production efficiency in the long term.

Both small and large ships will have different benefits to such a system.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 27, 2018, 03:56:20 PM
If anything, ship production bonuses should be based on how long it takes to build a ship and how long ago the previous ship was launched in such a case. Ships with long production times tend to get far less benefit from the builder's familiarity with the design than a ship that's build in a couple of weeks on a single slip.

I don't think this is really necessary. Ships themselves are not mass produced in assembly lines, and overall it will be just a buff to small units. They already have a massive buff that it is far easier to create small shipyards than to create massive ones. The cost of retooling already incentivises to keep building the same ships, simply increasing that cost would be the easiest way to achieve the same result instead of a complicated system to calculate when what was built.

It would also effect maintenance of the ships as well, so it would have many different applications.

As I said above it would not just give a bonus to small ships it would also give a different kind of bonus to larger hulls in a different way.

The retooling cost is sort of different. This would not really add much complexity but just be a modifier on ship cost AND maintenance. This would make expansive super specialist ships in low quantities not just expensive to build but also very expensive to maintain and this would make a different impact than just changing the retooling cost.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on December 04, 2018, 03:10:13 PM
Nebulae in C# Aurora

As someone who pretty much never plays 'Real Stars', I run into Nebulae in virtually every game.  Nebulae are awesome -- while the likelihood of inhabitable planets is lower, all bodies in a Nebula have increased chances of TNE minerals.  The downside is that everything (other than beam weapons) has its speed reduced by the nebula's strength and capped by its own armour.

1.  Will Nebulae be in C# Aurora v0.00?

2.  Will they still cap unit speed based on Nebula level & unit armour?

3.  In VB Aurora, unarmoured missiles were supposed to be destroyed upon launch in Nebluae, and armoured missiles slowed & speed-capped identically to ships/fighters/etc.  Due to various bugs & other reasons, this code was never implemented and missiles were flagged "can't fire in Nebulae."  How will C# Aurora v0.00 handle missiles in nebulae (or is that something for a later update)?

4.  If I am reading the new Ground Combat changes correctly, STO units will suffer the same penalties for firing through atmosphere as ship-based weapons.  Will they also suffer Nebula penalties?*

5.  On a side note, the last time I checked CIWS functioned normally in/through atmosphere, but regular Gauss Cannons did not - even in PD mode.  Would it be possible to give them some sort of bonus -- for example, have them ignore the first 1.1 atmospheres before taking penalties?

*(I don't quite remember what the nebula penalties to beam weapons are -- range and/or sensor reductions I think?)
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 04, 2018, 03:17:33 PM
At the moment I haven't coded Nebulae into C# Aurora (mainly because I almost always play real stars so they were low priority). However, I have setup the necessary framework up to add the code when I get to them.

Because of the above I haven't given any thought yet to whether they will be implemented differently.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on December 04, 2018, 06:05:27 PM
Suggestions/questions about Boarding Combat:

Will boarding parties be able to call in fire support from friendly ships?

I also suggest that ships being boarded gain/lose functionality as different compartments change hands.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 04, 2018, 06:11:34 PM
Suggestions/questions about Boarding Combat:

Will boarding parties be able to call in fire support from friendly ships?

I also suggest that ships being boarded gain/lose functionality as different compartments change hands.

I've not written boarding party combat yet but I probably won't add direct fire support. If ships could fire that accurately to help boarding parties, it would create the question of why they don't fire to knock out specific systems in normal combat.

While I won't track which system is in the hands of each combatant, I think it would be safe to say that boarding could cause collateral damage and that it would affect the performance of the ship being boarded.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 05, 2018, 12:43:18 AM
Suggestions/questions about Boarding Combat:

Will boarding parties be able to call in fire support from friendly ships?

I also suggest that ships being boarded gain/lose functionality as different compartments change hands.

I've not written boarding party combat yet but I probably won't add direct fire support. If ships could fire that accurately to help boarding parties, it would create the question of why they don't fire to knock out specific systems in normal combat.

While I won't track which system is in the hands of each combatant, I think it would be safe to say that boarding could cause collateral damage and that it would affect the performance of the ship being boarded.

While it should perhaps not be possible to hit most things specifically in combat I think that engines should be one exception since they are very big and produce the majority of the heat. Especially heat guided missiles should have a greater chance of hitting the engines and you should also have a decently good chance of targeting engines with normal weapons as well. Of course the overall chance of hitting the target should go down if you try to hit something specific... but still could be fun.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on December 05, 2018, 12:59:40 AM
While it should perhaps not be possible to hit most things specifically in combat I think that engines should be one exception since they are very big and produce the majority of the heat. Especially heat guided missiles should have a greater chance of hitting the engines and you should also have a decently good chance of targeting engines with normal weapons as well. Of course the overall chance of hitting the target should go down of you try to hit something specific... but still could be fun.
Heat guided missiles being more likely than normal to hit engines and EM guided missiles being more likely than normal to hit active sensors that have been turned on, could be neat, but I don't think the game needs a system for generally being able to target various components.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 05, 2018, 01:27:33 AM
While it should perhaps not be possible to hit most things specifically in combat I think that engines should be one exception since they are very big and produce the majority of the heat. Especially heat guided missiles should have a greater chance of hitting the engines and you should also have a decently good chance of targeting engines with normal weapons as well. Of course the overall chance of hitting the target should go down of you try to hit something specific... but still could be fun.
Heat guided missiles being more likely than normal to hit engines and EM guided missiles being more likely than normal to hit active sensors that have been turned on, could be neat, but I don't think the game needs a system for generally being able to target various components.

Something simple such as if you have at least 0.25 MSP of either passive Heat, EM those components counts as bigger than they actually are. Perhaps engines counts as twice the size and active sensors as five times the size or something... or perhaps a ratio based on passive strength versus the radiating power of the sensor in some way which functions as the size multiplier.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on December 05, 2018, 06:39:48 PM
Not sure if its already in the game - but would it be possible to use a list of star names for custom systems?

Ex:

Bear Galaxy
Creative names I know. But you get the concept right? You upload the list of names into aurora like with the ship names and aurora creates systems with these names without real systems.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on December 06, 2018, 11:31:42 AM
a question/suggestion about ground-unit logistics (hope it wasn't answered already)
Quote
For example, a formation element of 10 tanks engaged in combat is part of an armoured formation with a brigade HQ formation above it and a division HQ formation above that. The tanks will check for a vehicle-based logistics element within the division formation first, then a vehicle-based logistics element within the brigade formation and finally either type of logistic element within their own parent formation. If no logistic elements are available, the tanks will use their inherent supply, although they can only use that inherent supply for ten combat rounds, unless resupplied. If a unit does not require a full resupply (for example, it still has sufficient inherent supply for eight combat rounds), it will only draw an appropriate fraction of its normal GSP requirement (in this case 20%).

If I understand it correctly it is only possible to get supply from "higher tier" units in the same hierarchy - which will result in REALLY big HQ formations to have the potential supply units for it's "underlings" (the higher the HQ-tier, the more underformations it has, so expotentiell bigger the formation...)

Is this correct?

If so, wouldn't it be an idea to add something like "pure logictic formations" (most likely battalions) which are not part of any hq-formation but direct under it in the hierarchy and would be the "first to get supply from"?

Meaning something like this with the example from above: 

Tank formation (company) of 10 tanks - part of a brigade which has 5 tank companies and 2 pure logistic companies - which is part of a division with 2 pure logistic "brigades"

The tanks will check for a pure vehicle-based logistics formation directly under the division formation first (the 2 logistic brigades) - than in the division formation second if necessary.
Then a pure vehicle-based logistics formation under it's brigade formation (the 2 logictic companies), later within the brigade formation.
Finally either type of logistic element within their own parent formation. If no logistic elements are available, the tanks will use their inherent supply, although they can only use that inherent supply for ten combat rounds, unless resupplied.

Even after all the time I am still not sure about my understanding of "formation" and "element".. so maybe I am just confused...

but having pure logistic formations for resupply would have 2 advantages:
a) more flexible HQ-formations which don't have to be "really big" for logistic reasons and getting smaller later by "consuming" the logistic-trucks - not sure I want to think about formation size for an army-corps or whole "war theater" hq formation which even just has supply units for a few days as reserve...
b) easier way to "restock" the supply formations - as you just have to rebuild the supply formations and attach new one to the HQ-formations
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on December 06, 2018, 01:31:31 PM
That's a bit misleading as while you're correct that units get supply only from other units higher in their HQ hierarchy, you CAN put supply units on multiple levels of the HQ hierarchy. For example, I have planned to have them on battalion and regiment and divisional level. That helps that each individual HQ level doesn't need to grow massively. Remember also that you can just drag'n'drop units and formations around, so nothing prevents you from building units that are literally nothing but 100x supply vehicles and then restock your actual fighting formations when necessary with just few clicks.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 06, 2018, 02:50:45 PM
Although I don't think I have mentioned it yet, a formation element can draw supply from an independent logistics formation that is directly attached to a formation in its own hierarchy, including its immediate parent formation.

An 'independent logistics formation' is defined as a formation with at least two thirds of its size dedicated to logistics and with no subordinate formation. This is all coded. Supply will be drawn from the independent logistics formation before the formation to which it is attached.

This is all optional and, as stated above, it is probably just as easy to drag and drop on to the HQ formations where you need the supply.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on December 06, 2018, 02:58:56 PM
That's great, so now my army corps can include a supply force that will automatically supply all the divisions attached to the corps. Great!
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on December 06, 2018, 03:11:40 PM
really great :) was 100% what I was asking for :)

but quick question about this Steve...

will such a logistic formation be flagged as such for the whole battle running? I mean if I have a formation with 75% logistic size - after a few battle turns the logistic units are "used up", some destroyed by combat and there is only a ratio of 55% left (so under 2/3) but the fighting is going on...

will it still be a "logistic formation" for this rule or just a weak combat formation as it was with a lot of logistic units into?  (which would mean it would be better to go 90% or even 95% in the beginning to be sure)
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 06, 2018, 04:48:38 PM
really great :) was 100% what I was asking for :)

but quick question about this Steve...

will such a logistic formation be flagged as such for the whole battle running? I mean if I have a formation with 75% logistic size - after a few battle turns the logistic units are "used up", some destroyed by combat and there is only a ratio of 55% left (so under 2/3) but the fighting is going on...

will it still be a "logistic formation" for this rule or just a weak combat formation as it was with a lot of logistic units into?  (which would mean it would be better to go 90% or even 95% in the beginning to be sure)

Yes, that is a problem that would have to be addressed. In practical terms though, you would probably create a very logistic heavy formation and then merge with an HQ once it was very small. I need some form of check on logistic size though or the code would start using logistic units from 'normal' formations on the assumption they were logistic formations. Another option is I simply allow the player to flag logistics formations in the same way as supporting formations.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on December 06, 2018, 05:26:44 PM
really great :) was 100% what I was asking for :)

but quick question about this Steve...

will such a logistic formation be flagged as such for the whole battle running? I mean if I have a formation with 75% logistic size - after a few battle turns the logistic units are "used up", some destroyed by combat and there is only a ratio of 55% left (so under 2/3) but the fighting is going on...

will it still be a "logistic formation" for this rule or just a weak combat formation as it was with a lot of logistic units into?  (which would mean it would be better to go 90% or even 95% in the beginning to be sure)

Yes, that is a problem that would have to be addressed. In practical terms though, you would probably create a very logistic heavy formation and then merge with an HQ once it was very small. I need some form of check on logistic size though or the code would start using logistic units from 'normal' formations on the assumption they were logistic formations. Another option is I simply allow the player to flag logistics formations in the same way as supporting formations.
You may also have the reverse situation in some cases, in which a combat formation loses more combat elements than logistics elements and suddenly becomes a logistics formation.

I propose just sidestepping the whole issue and adding a flag that designates a formation as a logistics formation, like how tankers and colliers are designated.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on December 06, 2018, 05:27:50 PM
Or make it a special modifier similar to the various training changes. It just only works for formations made up of HQs and Logistics units and nothing else. Could even make for relatively cheap units; large scale logistics dumps have historically been run by second line units IIRC.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on December 07, 2018, 11:59:01 AM
Manual toggle is probably the best option. Sure, there will be times when players forget to toggle it, but it avoids the headache of coding for a multitude of different and rare situations that might crop up.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on December 07, 2018, 07:31:39 PM
Or make it a special modifier similar to the various training changes. It just only works for formations made up of HQs and Logistics units and nothing else. Could even make for relatively cheap units; large scale logistics dumps have historically been run by second line units IIRC.

Please don't.  As far as I'm concerned, the whole point to the revised ground unit system is the flexibility it offers.  I don't want "formations made up of HQs and Logistics units and nothing else."  I want the freedom to build whatever units I want -- maybe Ranch Hands (infantry) and Cowboys (cavalry) and Chuck Wagons (logistics vehicles).

Maybe I think every unit should include Jawa Bearers (LOG INF) or that my Tusken Raider Supply Companies need four Armoured Banthas (LAV LV) to guard the ten, twelve, or seventeen Transport Banthas (LOG LV).  (Tusken Raider Supply Companies always travel single file, to hide their numbers.)

My point is, don't backslide to "Supply Companies" and "Logistics Brigades" or any other sort of fixed unit types and/or sizes.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 08, 2018, 01:59:32 PM
Steve... one thing I always wanted to have in Aurora which should not be too difficult would be a tech cost multiplier for each game.

Sometimes I like to start with large populations and if you do then tech cost will not really matter for a very long time because you speed through the technology tree way too fast. It also might make scientists administrative skill matter a fair bit more in general which to some might be interesting.

So being able to just set a tech multiple cost when you start the game would go a long way to customize how quickly you want to be able to progress through the technology tree.

It should only effect the amount of point you need to research something, the actual costs of things should otherwise stay the same.
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on December 08, 2018, 02:29:28 PM
Already in: (http://aurora2.pentarch.org/index.php?topic=8495.msg106373#msg106373)

Quote from: Steve Walmsley
New Game Settings

This is a placeholder for Game-level modifiers

1) Percentage modifier for Research Speed (for all races)
2) Percentage modifier for Terraforming Speed (for all races)
3) Percentage modifier for starting minerals on Sol.
4) Flag for Active Civilian Shipping Lines. When this is disabled, shipping lines will not produce ships.
5) Flag for recovering tech due to conquest. You can disable this so no new tech is gained via conquest.
6) LY entry to limit Starting NPR Locations to within a specific range of Sol: http://aurora2.pentarch.org/index.php?topic=8495.msg108824#msg108824
7) Option for Planet X in the Sol System: http://aurora2.pentarch.org/index.php?topic=8495.msg109206#msg109206

You can specify a number of Earth-based player races on the Game Setup window. You will cycle through a number of Race Creation windows equal to the number of races selected. You will still need to create any non-Earth-based races after the main game creation process.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 09, 2018, 06:02:51 AM
Awesome... I missed that part!!!

Thanks!
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on December 10, 2018, 05:00:09 PM
just looking at your test-game screenshots Steve - great :)

but with the last one (ground unit) - would it be possible to add a colom to show for how many batleturns/hours/days (something like this) the selected formation (including its sub-formations when it is a division etc) has supply for?

In your screenshot, there are 4 resupply infanterie units (LG2) - but it would be great to see for how long the "1.PDR" could be fight with this...

this would help the player for his own units a lot if this screen would show how long the supply (units) would last
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 10, 2018, 05:32:30 PM
just looking at your test-game screenshots Steve - great :)

but with the last one (ground unit) - would it be possible to add a colom to show for how many batleturns/hours/days (something like this) the selected formation (including its sub-formations when it is a division etc) has supply for?

In your screenshot, there are 4 resupply infanterie units (LG2) - but it would be great to see for how long the "1.PDR" could be fight with this...

this would help the player for his own units a lot if this screen would show how long the supply (units) would last

The supply column is how long you can fight. 100% indicates 10 rounds of combat. The GSP number is the amount used for a full resupply. Not all units use supply. and those that don't will have a dash instead of a percentage. Each logistics unit provides 500 GSP, so the LG2 means 2000 points. So in this case, the elements in the formation that require supply will last about 50 rounds (integral supply plus four reloads), assuming average rolls on supply, no use of AA vs aircraft, no losses in the formation, no losses to the logistics units and no use of logistics from higher up the supply chain.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on December 11, 2018, 08:01:44 AM
Having seen the lates AI reports, an idea came into my mind.
One limitation to tell large scale stories is the amount of detail work you have to do with multiple nations. So how about different levels of control?

One: Full AI Empire - the AI controls all levels of this empire
Two: High Level Human - The human player can issue general decisions (negotiate peace, go to war, explore jump point XY, settle in system / on planet ABC); but everything below that is controlled by the AI
Three: Medium Level Human - The human player can issue additional commands like construct new ships or facilities, move fleets to XYZ, etc.
Four: Human Empire - The human player controls everything

What also would be interesting: to be able to switch between modes. For example control an empire on L2 until it goes to war, then switch to L4 and control all aspects of the war, when it is done switch back to L2... .
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 11, 2018, 10:45:33 AM
Having seen the lates AI reports, an idea came into my mind.
One limitation to tell large scale stories is the amount of detail work you have to do with multiple nations. So how about different levels of control?

One: Full AI Empire - the AI controls all levels of this empire
Two: High Level Human - The human player can issue general decisions (negotiate peace, go to war, explore jump point XY, settle in system / on planet ABC); but everything below that is controlled by the AI
Three: Medium Level Human - The human player can issue additional commands like construct new ships or facilities, move fleets to XYZ, etc.
Four: Human Empire - The human player controls everything

What also would be interesting: to be able to switch between modes. For example control an empire on L2 until it goes to war, then switch to L4 and control all aspects of the war, when it is done switch back to L2... .

This only works if the human is prepared to follow the same constraints as the AI in setting up his colonies and forces (creating the correct types of ground forces, forming the right operational groups, designing and building the required ship classes with the required capabilities). The C# AI will be a lot better at handling unexpected situations or even using captured ships than in VB6, but it would not be difficult for human intervention to confuse the AI, even if only temporarily.

Some more basic form of human assistant might be possible on a limited scale (in fact, you already have that to a degree with standing orders). However, I would not want to restrict the AI code in order to have an on/off option for human intervention.

What I hope with C# Aurora, is that I can play a reasonable multiple start with one player and multiple AIs, that will not inevitably turn into a free-for-all Armageddon :)
Title: Re: C# Aurora v0.x Suggestions
Post by: boggo2300 on December 11, 2018, 02:20:30 PM
What I hope with C# Aurora, is that I can play a reasonable multiple start with one player and multiple AIs, that will not inevitably turn into a free-for-al