Aurora 4x

C# Aurora => Development Discussions => 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: Coleslaw 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: Coleslaw 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 L 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 L 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: Coleslaw 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 Neumann 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 Neumann 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 L 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: Coleslaw 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-all Armageddon :)

Then don't include a Chinese faction...
Title: Re: C# Aurora v0.x Suggestions
Post by: tobijon on December 11, 2018, 02:23:08 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-all Armageddon :)

Then don't include a Chinese faction...

or america
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on December 13, 2018, 06:11:19 AM
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).
My main idea is to have some minor nations in a multi-nation start being AI, but also being given general alliance orders but not having to micromanage every one of them. So, yes, if that would be possible with the restrictions you mentioned, why not... . Let's see how your AI performs and reserve this idea maybe for a later release.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on December 13, 2018, 10:57:18 AM
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).
My main idea is to have some minor nations in a multi-nation start being AI, but also being given general alliance orders but not having to micromanage every one of them. So, yes, if that would be possible with the restrictions you mentioned, why not... . Let's see how your AI performs and reserve this idea maybe for a later release.

I presume the AI has some flags/internal codes to know what ship types are used for. That could be exposed in a semi-AI mode, if you design a custom ship for it, you can tell the AI what it is good for, if it cannot figure it out itself.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on December 13, 2018, 12:53:19 PM
Paradox and Firaxis have, in their later games, shown how extremely difficult it is to get a helper-AI to work competently. In both games, it is far more useful to have player to control everything manually and if the AI is ever given permission to handle something even temporarily, the time-savings are lost when the player takes control back and has to fix the mess that the AI has done.

Perhaps better would be to allow SM to force a permanent alliance between a player faction and an NPR-faction IF that faction was created by a human player and not the game itself.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on December 13, 2018, 07:41:58 PM
Paradox and Firaxis have, in their later games, shown how extremely difficult it is to get a helper-AI to work competently. In both games, it is far more useful to have player to control everything manually and if the AI is ever given permission to handle something even temporarily, the time-savings are lost when the player takes control back and has to fix the mess that the AI has done.

Perhaps better would be to allow SM to force a permanent alliance between a player faction and an NPR-faction IF that faction was created by a human player and not the game itself.
Distant Worlds let's you more or less set whatever part of the game you don't want to be involved in to AI control, and as far as I'm aware it works quite well.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on December 13, 2018, 10:32:57 PM
Paradox and Firaxis also couldn't AI their way out of a wet paper bag.  I mean, they show its not easy at the very least, but they don't necessarily show much about whats hard.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on December 14, 2018, 04:17:37 AM
Paradox and Firaxis also couldn't AI their way out of a wet paper bag.  I mean, they show its not easy at the very least, but they don't necessarily show much about whats hard.

Part of the problem with AI is that some people expect it to read their minds and do EXACTLY what they would have done. Yes, stellaris sector AI could have been smarter, but the way some people are trying to micromanage it instead of leaving it chugging along at good enough is to some degree their own fault.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on December 14, 2018, 11:53:32 AM
It's okayish as of 2.1 (appears to have blown up again in 2.2) but it was almost useless for a long time there.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on December 14, 2018, 11:57:30 AM
Of course the AI blew up with Stellaris 2.2

I mean, it's not as if the entire economical system of the game just got reworked.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on December 14, 2018, 12:02:33 PM
I agree, and I think the fact that you see decent AI from them right out of the gate as a borderline impossibility shows that on some level you agree with me.

People have done fairly clever AI right off the bat since Warcraft 3 at the very least.  It's not easy but it can be done.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on December 14, 2018, 03:29:24 PM
Warcraft 3 also had a lot less interdependent moving parts. The 2.2 Stellaris AI has to manage food, minerals, energy, influence, unity and 3 different not interchangeable research resources as the basic empire wide stockpileable resources. It also has to cope with the more advanced resources, of which consumer goods and alloys are the simplest, have different purposes and are both manufactured from minerals and minerals alone, the advanced resources which can be made from minerals at great cost or mined directly, the planetary populations and relevant happiness factors, the planetary housing and amenity availability, the planetary stability and criminality scores, the soft empire size cap, the soft military unit cap, the soft starbase cap...

The list continues. Extensively. And that's just the resources involved, we're not even talking about unit design, fleet composition, diplomacy, expansion of the empire or a multitude of other factors.

Warcraft 3 only had gold and wood and a hard unit cap. Although Warcraft's combat mechanics are rather more involved than Stellaris', its economical factors are in comparison rather trivial in complexity and interaction.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on December 14, 2018, 11:41:52 PM
I was more talking about the helper-AI in Hearts of Iron 3 who was supposed to manage your troops for you, while the player focused on diplomacy, research and production. And the governor-AI in Civ4 that was supposed to take city-micro away from the game.

Both cases were terrible disasters.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 16, 2018, 10:47:10 AM
I presume the AI has some flags/internal codes to know what ship types are used for. That could be exposed in a semi-AI mode, if you design a custom ship for it, you can tell the AI what it is good for, if it cannot figure it out itself.

Rather than knowing what a ship is used for, the AI is given a role to fill and designs a ship to meet that role. The design philosophy and design theme provided to the AI provide a framework for all of its designs, so the interaction of those with the intended role is what creates the ship design. The AI also has a set of operational groups, each with a combination of different ship roles. In fact, the operational group setup for a particular theme is how the AI knows what ship roles it needs to fill. So it isn't just a case of the AI knowing what a ship is supposed to so - it also needs to know how that fits into its overall operational group framework. To use the NPR-AI, a human player would have to add that higher-level framework before telling the AI what ships to use for each role. Because the AI setup is more complex in C# Aurora, it isn't straightforward to use parts of it for a human, because it is all inter-connected.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on December 18, 2018, 08:50:09 AM
A quick update on NPR Research.

There have been problems in VB6 with NPRs duplicating research or not following sensible research strategies. Therefore, each NPR design theme in C# Aurora has a built-in tech progression. This consists of many tech groups, each of which contains one or more tech types. For example, a group might simply contain armour, or it may contain a group of energy weapon related tech types, including the major components for the NPR's preferred weapon plus beam fire control techs. An engine-related tech group may contain reactor, engine and fuel consumption tech types. The NPR may have the same tech group multiple times in its design theme progression.

An NPR will check the total research cost for the tech group, based on the next tech within each tech type, and then dedicate all research in its empire toward achieving that total. For example, if the tech group is engines (reactor, engine, fuel consumption) and the NPR already has ion tech, it will total Stellarator Fusion Reactor (12,000), Magneto-plasma Drive Technology (20,000) and Fuel Consumption: 0.6 Litres per Engine Power Hour (8000) for a total of 40,000 RP. Once the total is hit, it gains all the techs in that tech group. Certain tech groups will trigger a redesign for NPR ship types and/or ground forces.

Each tech group has an associated research field based on the majority field within the group. Progression will be based on either the best scientist for that field, regardless of admin rating, or the best overall scientist if that bonus exceeds 4x the specialist bonus.

This gives some advantages over players (no admin limit) and some disadvantages (less flexible). Most importantly, this should provide a much more cohesive NPR research strategy and make NPRs more challenging as they improve their technology. This code has been working since before the current campaign.

This sounds great. What I would like in addition is variation in the AI research assignment weights, if possible. For example, let's say one NPR's racial idea of research is 'get powerful weapons, worry about fire controls later,' and so it would end up with high-tech weapons but its BFCs (or MFCs, as appropriate) might lag behind. Or, of course, in reverse. Similarly an NPR might worry about power generation more than beam research, because its racial AI figures advanced powergen (and drives) are more useful and it's ok lagging behind with only visible light lasers while it has magneto-pulse, for example.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 18, 2018, 08:55:03 AM
A quick update on NPR Research.

There have been problems in VB6 with NPRs duplicating research or not following sensible research strategies. Therefore, each NPR design theme in C# Aurora has a built-in tech progression. This consists of many tech groups, each of which contains one or more tech types. For example, a group might simply contain armour, or it may contain a group of energy weapon related tech types, including the major components for the NPR's preferred weapon plus beam fire control techs. An engine-related tech group may contain reactor, engine and fuel consumption tech types. The NPR may have the same tech group multiple times in its design theme progression.

An NPR will check the total research cost for the tech group, based on the next tech within each tech type, and then dedicate all research in its empire toward achieving that total. For example, if the tech group is engines (reactor, engine, fuel consumption) and the NPR already has ion tech, it will total Stellarator Fusion Reactor (12,000), Magneto-plasma Drive Technology (20,000) and Fuel Consumption: 0.6 Litres per Engine Power Hour (8000) for a total of 40,000 RP. Once the total is hit, it gains all the techs in that tech group. Certain tech groups will trigger a redesign for NPR ship types and/or ground forces.

Each tech group has an associated research field based on the majority field within the group. Progression will be based on either the best scientist for that field, regardless of admin rating, or the best overall scientist if that bonus exceeds 4x the specialist bonus.

This gives some advantages over players (no admin limit) and some disadvantages (less flexible). Most importantly, this should provide a much more cohesive NPR research strategy and make NPRs more challenging as they improve their technology. This code has been working since before the current campaign.

This sounds great. What I would like in addition is variation in the AI research assignment weights, if possible. For example, let's say one NPR's racial idea of research is 'get powerful weapons, worry about fire controls later,' and so it would end up with high-tech weapons but its BFCs (or MFCs, as appropriate) might lag behind. Or, of course, in reverse. Similarly an NPR might worry about power generation more than beam research, because its racial AI figures advanced powergen (and drives) are more useful and it's ok lagging behind with only visible light lasers while it has magneto-pulse, for example.

All that is possible. There is a master list for progression but different design themes can choose which parts they include and there are alternate paths already built into the progression (and more can be added).
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on December 19, 2018, 05:17:28 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 :)

What I would like to see is some SM options to handle NPRs better ( and also make providing feedback easier ).

1.) A SM option to view a specific NPR, but not touch anything. Basically you can go into all the interfaces like it was a normal race, but all action buttons are grayed out.
2.) A SM option to irreversibly convert a specific NPR to become a player controlled empire instead. Disables all AI functions and you now need to play it, could be helpful if the game get stuck due to some NPR/AI bug and you really want to continue it, or if you see the NPR AI doing something incredibly stupid and you want to take control to play out the "what if" scenario.

The first option is probably quite a bit of work, but I think it could be very helpful to provide feedback and improvement suggestions if we are able to observe the AI play "in action" so to speak. It could also be really cool to see some AARs written from the NPR perspective or detailing NPR vs NPR wars. Perhaps having a fully hands off start mode where you only can observe one or multiple NPRs could help with speeding up AI development and testing.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tree on December 19, 2018, 06:55:04 AM
Since we're talking about SM option wishes: could you add the option to let us modify a planet's characteristics as SM? Things like size, albedo, mass, density, gravity, etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 19, 2018, 08:42:11 AM
Since we're talking about SM option wishes: could you add the option to let us modify a planet's characteristics as SM? Things like size, albedo, mass, density, gravity, etc.

The UI to make such a change is straightforward but the interactions are not. The density will affect mass and gravity (and vice versa), size will also affect mass and gravity while albedo will change the temperature (and therefore potentially the atmosphere, hydrosphere, dominant terrain and colony cost).

Changing the atmosphere by itself is fine as the code will react to that, but changing the more basic physical characteristics is trickier. Even when generating NPR home worlds in C# Aurora, I keep generating systems until I find a suitable planet/moon and then just adjust the atmosphere. I don't mess with the planets themselves post-generation.

Title: Re: C# Aurora v0.x Suggestions
Post by: joeclark77 on December 19, 2018, 09:26:31 AM
You mentioned that you're coming up with new ideas for spoilers.  I'd like to suggest space pirates.  These would be NPC combat dropships that come out of nowhere, capture your commercial and civilian ships, then (like an infection) they add a combat drop capability to those captured ships.  By "coming out of nowhere" I suggest they're either very stealthy (disguised as commercial ships?), or they hide out in nebulas and on the unwatched sides of jump gate to strike where you might be vulnerable.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tree on December 19, 2018, 09:52:11 AM
The UI to make such a change is straightforward but the interactions are not. The density will affect mass and gravity (and vice versa), size will also affect mass and gravity while albedo will change the temperature (and therefore potentially the atmosphere, hydrosphere, dominant terrain and colony cost).
Aw I thought that'd be the problem.

Changing the atmosphere by itself is fine as the code will react to that, but changing the more basic physical characteristics is trickier. Even when generating NPR home worlds in C# Aurora, I keep generating systems until I find a suitable planet/moon and then just adjust the atmosphere. I don't mess with the planets themselves post-generation.
Then would it be possible to have a new button (or whatever else is convenient)? Something like "create home system", as opposed to "create system", generating systems until it makes up something suitable for an NPR, but doesn't actually spawn an NPR? Though with how fast system generation no doubt is in C#, it might become entirely useless, unlike in VB where it can take some RL time to get an inhabitable system only because generation itself takes so long.
Didn't NPR use to have fixed starting systems in VB instead and skipping the system generation entirely, by the way?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 19, 2018, 09:56:40 AM
What I would like to see is some SM options to handle NPRs better ( and also make providing feedback easier ).

1.) A SM option to view a specific NPR, but not touch anything. Basically you can go into all the interfaces like it was a normal race, but all action buttons are grayed out.
2.) A SM option to irreversibly convert a specific NPR to become a player controlled empire instead. Disables all AI functions and you now need to play it, could be helpful if the game get stuck due to some NPR/AI bug and you really want to continue it, or if you see the NPR AI doing something incredibly stupid and you want to take control to play out the "what if" scenario.

The first option is probably quite a bit of work, but I think it could be very helpful to provide feedback and improvement suggestions if we are able to observe the AI play "in action" so to speak. It could also be really cool to see some AARs written from the NPR perspective or detailing NPR vs NPR wars. Perhaps having a fully hands off start mode where you only can observe one or multiple NPRs could help with speeding up AI development and testing.

At the moment I am using the 'designer mode' option to reveal all NPRs, although all the buttons are active. Unlike VB6 I can actually give the NPR fleets orders in some cases, although they may be overridden if the fleet is a type of operational group that is periodically reviewed by a higher level AI (the interval between reviews is dependent on operational group type and whether hostile forces are nearby). It would be a lot of work to disable everything as there are a LOT of potential buttons to press. Theoretically, it would be easier to leave designer mode as is and warn people not to touch anything because it could cause errors, although I suspect some people would not be able to resist and then I end up with bug reports that aren't real :).

Converting an NPR to a player race would not be difficult, as it would just be a case of removing the AI. There is an AI object in each NPR Race, System, Fleet, Ship and Population object (composition rather than inheritance). If I take those out and flip the Race level 'NPR' flag, the NPR will suddenly be a player race.

Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 19, 2018, 10:02:11 AM
Then would it be possible to have a new button (or whatever else is convenient)? Something like "create home system", as opposed to "create system", generating systems until it makes up something suitable for an NPR, but doesn't actually spawn an NPR? Though with how fast system generation no doubt is in C#, it might become entirely useless, unlike in VB where it can take some RL time to get an inhabitable system only because generation itself takes so long.
Didn't NPR use to have fixed starting systems in VB instead and skipping the system generation entirely, by the way?

An option to 'Create Home System' would be easy, as the NPRs already have that function. Yes, there are a number of fixed starting systems in VB6 for NPRs created at game start. That doesn't exist in C# - everything is created from scratch. It only take a second or two to generate and discard all the unsuitable systems until a suitable home system is generated. Every NPR starting system is unique.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on December 19, 2018, 11:02:32 AM
An idea for a new Spoiler Race or a "special and rare NPR":

A race with a specially ability/tech which shields from missiles to 100% - somethink like a craft field which let's detonate missiles in a save distant

This would lead the Player to get "0 damage" results in the overview as his missiles detonate so he might miss the fact that his missiles are useless the first few times...

to balance this, the Spoiler/NPR itself is not allowed to have missile launcher itself too but would need to have fast ships...

so it would bring a race into the game which must be attacked/defended against with other weapons than missiles - and give the player a nasty suprise if he encounter them the first time... no more "missile only" battles/research... but it should be rare enough to suprise the player

the tech for these (if not coded as a Spoiler-ability but added as a ship module) is strictly non-player ... which means even if it is a ship module it can't be research by the player but it MIGHT (very rare!!) be salvaged but will not give tech or research when disassembled (just some message "the tech is too alien to get any usefull information" and the module is destroyed)

This would allowthe player to - very rare - build it into one of his ships but only these modules he has luckily found in wracks... but the same rule (no missile launchers of any kind) would also go for a player ship with these modules

a module could come in different variants (100t for a 1000t ship, 500t for a 5000t ship, 1000t for a 10000t ship etc...)

the modules I am not sure about but the possibility to meet an alien Race which is invulnerable to missiles in very rare possibilities could be really fun - especially as it would be a shock for the military and would bring them "around" to review there battleline in view of the new thread...
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on December 19, 2018, 01:29:28 PM
You mentioned that you're coming up with new ideas for spoilers.  I'd like to suggest space pirates.  These would be NPC combat dropships that come out of nowhere, capture your commercial and civilian ships, then (like an infection) they add a combat drop capability to those captured ships.  By "coming out of nowhere" I suggest they're either very stealthy (disguised as commercial ships?), or they hide out in nebulas and on the unwatched sides of jump gate to strike where you might be vulnerable.
Where are they coming from? Are they spawned by your own civilization? Are they spawned by competing human factions? Are they spawned by NPRs? How will they interact with spoilers? If they are created from your own faction, then how can a player prevent their creation in the first place? How can a player eradicate them completely? Where are they getting their ships and crew and missiles and maintenance supplies and fuel? Does a space empire need to be X size before they appear? How many military ships need to be in a system to prevent their spawning? How can they scout things out? Are they completely nullified the moment a player puts down a heavily armed defensive station on a jump point?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 19, 2018, 01:48:01 PM
An idea for a new Spoiler Race or a "special and rare NPR":

A race with a specially ability/tech which shields from missiles to 100% - somethink like a craft field which let's detonate missiles in a save distant

This would lead the Player to get "0 damage" results in the overview as his missiles detonate so he might miss the fact that his missiles are useless the first few times...

to balance this, the Spoiler/NPR itself is not allowed to have missile launcher itself too but would need to have fast ships...

so it would bring a race into the game which must be attacked/defended against with other weapons than missiles - and give the player a nasty suprise if he encounter them the first time... no more "missile only" battles/research... but it should be rare enough to suprise the player

the tech for these (if not coded as a Spoiler-ability but added as a ship module) is strictly non-player ... which means even if it is a ship module it can't be research by the player but it MIGHT (very rare!!) be salvaged but will not give tech or research when disassembled (just some message "the tech is too alien to get any usefull information" and the module is destroyed)

This would allowthe player to - very rare - build it into one of his ships but only these modules he has luckily found in wracks... but the same rule (no missile launchers of any kind) would also go for a player ship with these modules

a module could come in different variants (100t for a 1000t ship, 500t for a 5000t ship, 1000t for a 10000t ship etc...)

the modules I am not sure about but the possibility to meet an alien Race which is invulnerable to missiles in very rare possibilities could be really fun - especially as it would be a shock for the military and would bring them "around" to review there battleline in view of the new thread...


I don't mind having an NPR which is particularly resistant to missiles, but it should come from an extension or advancement of in-game tech. I don't want a situation where an alien has what is effectively a 'magic' weapon or defence that the player cannot even come close to duplicating at any point.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 19, 2018, 01:52:46 PM
You mentioned that you're coming up with new ideas for spoilers.  I'd like to suggest space pirates.  These would be NPC combat dropships that come out of nowhere, capture your commercial and civilian ships, then (like an infection) they add a combat drop capability to those captured ships.  By "coming out of nowhere" I suggest they're either very stealthy (disguised as commercial ships?), or they hide out in nebulas and on the unwatched sides of jump gate to strike where you might be vulnerable.

The reason there are currently no 'space pirates' in Aurora is that it is very difficult to create any form of in-game justification for them. An NPR that raids other races may be possible (and is on my list) but they need the infrastructure to support that effort, some form of safe harbour or well-protected base (which needs an economic base to build it) and an economic or political justification for that behaviour.

At the moment, Precursors and Swarm fill the pirate niche (a localised enemy with a reason to fight).
Title: Re: C# Aurora v0.x Suggestions
Post by: clement on December 19, 2018, 06:40:18 PM
What I would like to see is some SM options to handle NPRs better ( and also make providing feedback easier ).

1.) A SM option to view a specific NPR, but not touch anything. Basically you can go into all the interfaces like it was a normal race, but all action buttons are grayed out.
2.) A SM option to irreversibly convert a specific NPR to become a player controlled empire instead. Disables all AI functions and you now need to play it, could be helpful if the game get stuck due to some NPR/AI bug and you really want to continue it, or if you see the NPR AI doing something incredibly stupid and you want to take control to play out the "what if" scenario.

The first option is probably quite a bit of work, but I think it could be very helpful to provide feedback and improvement suggestions if we are able to observe the AI play "in action" so to speak. It could also be really cool to see some AARs written from the NPR perspective or detailing NPR vs NPR wars. Perhaps having a fully hands off start mode where you only can observe one or multiple NPRs could help with speeding up AI development and testing.

At the moment I am using the 'designer mode' option to reveal all NPRs, although all the buttons are active. Unlike VB6 I can actually give the NPR fleets orders in some cases, although they may be overridden if the fleet is a type of operational group that is periodically reviewed by a higher level AI (the interval between reviews is dependent on operational group type and whether hostile forces are nearby). It would be a lot of work to disable everything as there are a LOT of potential buttons to press. Theoretically, it would be easier to leave designer mode as is and warn people not to touch anything because it could cause errors, although I suspect some people would not be able to resist and then I end up with bug reports that aren't real :).

Converting an NPR to a player race would not be difficult, as it would just be a case of removing the AI. There is an AI object in each NPR Race, System, Fleet, Ship and Population object (composition rather than inheritance). If I take those out and flip the Race level 'NPR' flag, the NPR will suddenly be a player race.

Steve, two possible solutions.
1. When a user gives a command to an NPR, set a global flag in the game that is included in the bug report so you can weed those out.

2. Extend the WPF Button class and add a check to see if the game is in SM mode && selected race flag is NPR, then disable the button. Buttons would still be active for you in designer mode assuming the game treats that as a distinct mode from SM.

Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on December 19, 2018, 07:20:04 PM
At the moment, Precursors and Swarm fill the pirate niche (a localised enemy with a reason to fight).

Another idea for spoilers: a nomadic (like Swarm) 'race' that cannibalizes other resources for growth and movement, also much like the swarm. The difference is, while the swarm will eat your ships out of space (and bomb you into the Stone Age? Iono.) these guys focus primarily on landing ground troops and cannibalizing your colonies and/or mining operations. They'd have a respectable presence in space, but nothing special - perhaps a little nastier than the Precursors, but not much. But if they manage to land troops, on the ground they're truly nasty.

Of course the question would be how are these different from a particularly aggressive NPR with an advanced start, but methinks you could make their internal mechanics quite distinct. For example, instead of mining and building infrastructure to build ships and ground troops, they would instead consume infrastructure and convert it into ships and ground troops, eventually leaving a planet de-colonized (with, perhaps, some minor ruins) before moving on.

It would also give you a chance to showcase the newly reworked ground combat and organization system.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rich.h on December 20, 2018, 02:30:43 AM
A quick idea for a sort of medical system, if feasible then how about a method of medical emergencies/plagues? At it's most basic this could work on a simple percentage calculator, each year a colony has X% to contract a medical emergency, the further out from the capital system the higher the change of such. To simulate contagious passengers and the like, have a modifier for systems with an existing emergency, so they get an increase in the chance to contract an emergency. To couteract this have a new installation that simply generates "medical points", if there is no current emergency then this installation reduces the chance of one happening by a set percentage per installation, and if an emergency if currently happening then there is a set percentage chance of curing the emergency per installation. As with construction brigades, have a ground unit capable of generating medical points so that you can cure emergencies on colonys with no installations etc. To prevent this being simply paying lip service to the medical services, make the Installations and ground units both expensive to create in the first place, and also consume a large amount of upkeep. This would mean most installations would end up being shutdown for much of the time unless a healthy supply of minerals is fed to them.

So if a colony develops an emergency then what? My thinking is to begin with an ever increasing reduction in population growth, say on a yearly basis. Also the same for unrest and construction. This way it will not instantly cripple a colony, but can be debilitating to new small colonies, and if left long enough can wipe out even a homeworld

Thinigs that come to mind on this that may or may not be doable.

1. Make the distance factor not due to just how many systems, but inside a system also. So an Earth based start would factor in colonies out on Titan as a higher risk factor than Earth.

2. If a colony is set to a destination of colonists then it gets an increase in the chance of emergency, this replicate possible lower standards of quarantine in various civillian shipping lines.

3. Have the emergency as something that is fixed to the planet itself. A colony with So if a colony contracted an emergency it will gain "disease points" each year. The medical installations will remove an amount of points equal to their combined rating for the number of installations/ground units. Once all the disease points are removed the eergency is over and cured. But assuming this did not happen and the colony got wiped out. The disease points would stay fixed onto the planet and then slowly dissipate in a way similar to current radiation and dust. This means you could not simply ship in a set of new colonists and start over without first curing the emergency. Doing so would just start up the disease point increase once more.

4. A database of various diseases, essentially they each act in the same way but can occur in multipe instances. Let us say colony A has plague A and colony B has plague B. On the next cycle colony A fails its check and contract plague B. This means it now has both plagues and suffers 2X the amount of penalties, as well ass generating 2X the number of disease points each year. Both plagues are logged seperately for the purpose of curing, and both now together contribute double the amount of check increases to neighbouring systems/colonies. In this way an unchecked emergency could cause devestation across an empire.

5. Allow for cross species contamination, to begin with I am not sure if genetically creating a new species means they are logged in the database as an entirely new species or a subspecies. However allow emergencies to cross into other empires that have made contact with each other. If they are at war then reduce the chance, if the have any kind of agreements then incrase the chance for each one. Have this start lower than the normal inter empire chance, and maybe go upto this basic rate once the two empires are both best of friends. As far as species go, if an entirely different species then say 1/4 of the spreading chance, and a subspecies 1/2 chance. This would simulate different physiologies etc.

6. A new research line in biology, this would work similar to the ones for research and construction and simply allow medical installations to generate more points per installation.

7. The obvious progression from the previous two points is a tech line of research to create new diseases for use in bio warfare. But I think this could get very complicated very fast.


Overall I think this could add a nice new dynamic of parts to keep an eye on in empire management, in addition it has the potential to create new "ruins" planets. Perhaps an NPR colony could get wiped out by some disease but never bother or be unable to claim back the colony. Another empire could then find a planet with what appeared as a ghost colony on the surface, perhaps still with a tiny amount of the contagion still left alive ready to spring back up should no precautions be taken. It would also mean carefully looking at potential new allies, sure those squid guys seem friendly enough, but they seem to be under developed and have tiny colonies. Would opening the trade lanes to them also open a doorway to tentacle diseases?
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on December 20, 2018, 06:51:04 AM
The reason there are currently no 'space pirates' in Aurora is that it is very difficult to create any form of in-game justification for them. An NPR that raids other races may be possible (and is on my list) but they need the infrastructure to support that effort, some form of safe harbour or well-protected base (which needs an economic base to build it) and an economic or political justification for that behaviour.
Maybe a corporation that has grown too big, can channel some of its money in funding a pirate branch... (idea not inspired by Megacorp in any way, shape or form :) ).
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 20, 2018, 07:00:15 AM
At the moment, Precursors and Swarm fill the pirate niche (a localised enemy with a reason to fight).

Another idea for spoilers: a nomadic (like Swarm) 'race' that cannibalizes other resources for growth and movement, also much like the swarm. The difference is, while the swarm will eat your ships out of space (and bomb you into the Stone Age? Iono.) these guys focus primarily on landing ground troops and cannibalizing your colonies and/or mining operations. They'd have a respectable presence in space, but nothing special - perhaps a little nastier than the Precursors, but not much. But if they manage to land troops, on the ground they're truly nasty.

Of course the question would be how are these different from a particularly aggressive NPR with an advanced start, but methinks you could make their internal mechanics quite distinct. For example, instead of mining and building infrastructure to build ships and ground troops, they would instead consume infrastructure and convert it into ships and ground troops, eventually leaving a planet de-colonized (with, perhaps, some minor ruins) before moving on.

It would also give you a chance to showcase the newly reworked ground combat and organization system.

The updated Star Swarm in C# will have a significant ground-based component.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on December 20, 2018, 11:37:25 AM
The updated Star Swarm in C# will have a significant ground-based component.

Sssshh! No spoilers!
Title: Re: C# Aurora v0.x Suggestions
Post by: Bughunter on December 20, 2018, 11:38:34 AM
The reason there are currently no 'space pirates' in Aurora is that it is very difficult to create any form of in-game justification for them. An NPR that raids other races may be possible (and is on my list) but they need the infrastructure to support that effort, some form of safe harbour or well-protected base (which needs an economic base to build it) and an economic or political justification for that behaviour.

They could split off from your own civilian sector. Justified simply by that some enterprising individuals find a more profitable way by mounting lasers on their ships. Pirate bases are created similar to CMC:s, on planets, asteroids or anything really. I don't think they would need much supporting economy as they would simply be a hidden site to keep their ships and transfer stolen goods. The pirates are otherwise economically part of your empire and make use of your civilian infrastructure. The economy part of it could be abstracted by saying stolen cargo finds it way back into the civilian economy through black market channels and pays for pirate ship fuel/maintenance and even upgrades. Which means the longer they survive the more military hardware they can manage to get their hands on (out of your own designs, or from whoever else they manage to raid?).

Done like this they would be unlikely to be any serious military threat, they would rather be a reason for you to do some patrolling. And they should try to establish themselves in interesting places. Like in the outer part of an empty system where freighter traffic is passing. Or somewhere in the borderlands between two empires.

Just thinking that if you want to work some pirates in I'm sure we can find a way.
Title: Re: C# Aurora v0.x Suggestions
Post by: tobijon on December 20, 2018, 12:54:13 PM
pirates could also be the result of unrest in your empire, a chance of a pirate faction spawning based on the unrest at a planet
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on December 20, 2018, 03:20:40 PM
Why would a corporation establish a pirate branch? It's the Lex Luthor problem - he can make all the money he wants with his genius inventions, but instead, he wastes his time and money by fighting Superman.

And my earlier questions still stand unanswered. The current spoilers have valid reasons for existing and provide a military challenge to overcome that is somewhat different from NPRs. If pirate faction can be neutralized as easily as taking care of PPV unrest on colonies (ie having patrol ships in a system), then what's the point of wasting Steve's time in coding it in? If they are a serious challenge that will interfere with civilian shipping, then there must be methods to prevent their creation in the first place - what if I'm playing a hivemind race or a totalitarian dictatorship that rules everything with an iron fist through a telepathic KGB - as well as a logical method for wiping them out, meaning bases that can be discovered and occupied, as well as ships that can be destroyed. How are they getting designs for weapons and where are they building them? Are my shipyards just leaving 19cm spinal lasers lying around? Are my research labs handing out blueprints for active sensors to anyone who asks? Maybe there be a mechanism that pirates have access to stuff 2 levels behind the cutting edge, which could be a reasonable thing, as that's the point when technologies are leaked between factions sharing the same homeworld.

Currently, if I need space pirates in my game for story/RP reasons, I can SM them into existence easily enough and then handwave the rest as per story needs. Anyone can do the same. I'm all for putting in more content to the game but we should be wary of throwing things willy-nilly into it because one of the best things about Aurora is how it's so flexible with regards to the details. You can make it work for almost any sci-fi universe or story setting. At the very least pirates should be toggleable on/off like spoilers and NPRs are.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on December 20, 2018, 04:54:49 PM
Pirates shouldn't be a spoiler race.  They should appear naturally from your own, or neighboring civilizations, like they did in real life.  Pirates in real life are not a nation, they're organized criminals.  They have no economy, they don't build their own ships, they have no ground units, they have no research apparatus.

Pirates in Aurora should spawn on/near colonies with poor oversight by the central government.  Their ships should look like cargo ships until you get really close and can see how well armed they are.

Ship detection really should reveal less information about contacts.  How is it that I know what faction a particular active sensor contact is from?
Title: Re: C# Aurora v0.x Suggestions
Post by: joeclark77 on December 20, 2018, 09:43:58 PM
You mentioned that you're coming up with new ideas for spoilers.  I'd like to suggest space pirates.  These would be NPC combat dropships that come out of nowhere, capture your commercial and civilian ships, then (like an infection) they add a combat drop capability to those captured ships.  By "coming out of nowhere" I suggest they're either very stealthy (disguised as commercial ships?), or they hide out in nebulas and on the unwatched sides of jump gate to strike where you might be vulnerable.

The reason there are currently no 'space pirates' in Aurora is that it is very difficult to create any form of in-game justification for them. An NPR that raids other races may be possible (and is on my list) but they need the infrastructure to support that effort, some form of safe harbour or well-protected base (which needs an economic base to build it) and an economic or political justification for that behaviour.

I think the core of my suggestion is the "viral" nature of the proposed enemy.  The image in my head is that certain areas of space would gradually get more and more dangerous if left unchecked, as more and more ships are captured/converted.  Your military ships wouldn't really be threatened, but your freighters and things would be vulnerable, so you might want to give them weapons or at least make them fast enough to outrun any civilian designs.  The civilian shipping companies might react in a realistic way, by paying ransoms to the pirates, by building civilian armed escorts, or by traveling in convoy and requesting your protection.

As for justification, the pirates would be primarily doing it for the ransoms (a protection racket).  They might pick a remote planet or moon as their base, so non-trivial to detect... this would be particiularly troublesome in those binary systems where the B component is a zillion miles away with no LP shortcuts.
Title: Re: C# Aurora v0.x Suggestions
Post by: joeclark77 on December 20, 2018, 09:47:23 PM
Another suggestion: can we get an option to use miles instead of kilometers, knots instead of km/s, and gallons instead of litres?  The metric system implies a dystopian future and I prefer to imagine a future where the good guys win.  ;)
Title: Re: C# Aurora v0.x Suggestions
Post by: Seolferwulf on December 20, 2018, 10:07:29 PM
If a corporation doesn't make much profit because too many rivals take the juicy contracts then they may resort to contracting mercenaries to make trouble for the other shipping lines.
The mercenaries of course would disguise themselves as pirates to not reveal themselves and their contractor.
Another possibility could be for the corporation to establish a private military branch and do some pirating themselves, if security is lax.
Crime only needs motivation and an oportunity.

Another type of pirates would be destroyed civs, or rather the remnants of one.
If an NPR has no colonies left its remanining ships could be converted to vengful pirates, which would try to sneak into your populated systems, establish some kind of outpost inside an asteroid belt and start harassing and capturing civilian ships.
If they manage to take one they would suicide ram it into military ships and colonies.

Edit:
Another suggestion: can we get an option to use miles instead of kilometers, knots instead of km/s, and gallons instead of litres?  The metric system implies a dystopian future and I prefer to imagine a future where the good guys win.  ;)

It's only a matter of time.
The metric system will eventually replace the imperial one.
Surrender yourself, resistance is futile.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on December 21, 2018, 04:39:25 AM
for me pirates make sense for one thing (and an important one) - to bring the player to patrole even save systems with some mobile forces...

I would suggest pirates could be implemented as this:

part of the "requested protection level" - but that the player is not allowed to create this protection level with ground units only but to have a mix of ground unit and warships...
the more wealth a system generates the more "protection request" it has for mobile units

these mobile units have to be given a command "patrole system" which let's them auto-patrole the shipping lanes, refuel, rest, resupply etc (so no micro for the player)

if the "protection request" for mobile units is not reached, there is no "planetary unrest" but a significant cut in the system-wealth creation..

no ship looses as pirates are not "strong" enough to destroy/threaten actual starships but are strong enough to own shuttles for small criminal intention (like docking on a trader and getting some of it's cargo without notice, smuggling, stealing at offloading etc)

the longer the time the protection level was not reached, the longer it will be in the future to reduce the "pirate influence" on the economy

so no "pirate fraction" is needed but the player has to do something even in secure systems...

I would depend the "protection request" for mobile units on system-wealth, body's in system with population in system (more pop body's - even or especially small ones - means more hidding/possibilities for pirates), number of jumppoints in system (a system with is poor but acts as a "highway for rich systems" is made for piratecreation)... maybe even more factors...

maybe it wold make sense to reduce global wealth as well as system wealth if the system is a "highway system" with main shipping lanes going through it...

this would add to the game:

- pirates for role playing and something to look at
- the need for the player to actually "patrole" his systems with is realistic - instead of just parking ships or PDC or ground-units somewhere in the system
- a choice for the player if he is "taking the wealth hit" for a medium/long time in a war where he needs to order the "patrole ships" out of the system - or letting the ships to patrole and going to war with less ships
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 21, 2018, 04:58:39 AM
I have no problem with the idea of a threat that requires the player to actively patrol systems. However, there needs to be an in-game rationale and capability for that threat to exist. For 'pirates' to exist they need:

1) A shipyard to build their ships
2) Maintenance facilities to support them
3) Fuel Production facilities
4) Ordnance factories if they are missile-armed
5) Some way of building or acquiring all of the above and transporting/towing them to their destination
6) Population to man all of the above.
7) An economic rationale for their activity - why not use their ships for trade instead? Why is piracy more profitable or desirable when the potential (and likely) downside is destruction of their ships and loss of their lives?

It will be easier in C# Aurora to hide such facilities (due to reduced sensor ranges), but they still need to be created and moved to their destination. Also, the easiest way to destroy the 'pirates' would be to locate and destroy their support infrastructure so they would need defences for that too. I know 'Civilians' have support infrastructure we don't see but that infrastructure is not an active threat (and could be logically added if really needed).

BTW we aren't talking about a few guys in a skiff using RPGs to threaten a tanker. The 'pirates' in Aurora would be operating in deep space within the constraints of the Aurora economic model. Also, even if we draw parallels with Somali pirates, in the Aurora-verse the Western Powers would likely solve the problem by nuking the entire Somali coast.

I do have some ideas about spoilers or NPRs that will fulfill a 'raiding' function, using a logical rationale for their behaviour and with an economic support structure. However, having pirates in the classical sense is difficult to envision within the logical constraints of the game.
Title: Re: C# Aurora v0.x Suggestions
Post by: Panopticon on December 21, 2018, 05:05:20 AM
The main issue I see with pirates is that they don't make a ton of sense under the rules of Aurora, you need a source of minerals to build, repair, and maintain ships, a shipyard and/or maintenance for same, a way to pay for it, and a population to man those installations.

I like the idea of sort of having them in an abstracted form like described above, as a sort of passive drain on resources on improperly secured shipping routes, at least from a role-playing perspective but I gotta ask exactly what benefit does it bring to the game? It adds a lot of micromanagement but doesn't bring in a ton of fun I don't think, especially when you can just SM those same consequences yourself.

Since pirates need a base to operate from, that suggests a couple options that might be fun though, let's say, as was mentioned earlier, a civilian corporation wants to get into the more direct acquisition of wealth, we already have a mechanic for them building ships, so having them launch a ship that registers as a freighter until it is feels safe enough to go raiding might be fun, it could hit your civilian shipping, or maybe even that of your allies or other factions. Maybe we could have an additional function of ECM be to penetrate that deception so you can root them out.

Another option is mutiny, currently morale on ships only really matters to military vessels, and even then they can still function with low morale, what if we have ships with low enough morale have a chance to defect to another faction? Say your sentry picket who you forgot about on station for three years gets fed up and decides to rehome to the civ you've been having it keep an eye on, incidentally providing that civ your sensor data or research, or your poor overworked freighter who has been shipping automines from Sol to your newest outpost eight jumps away without a break for sixteen months decides likewise and makes a gift of it's cargo to a (hopefully) grateful new employer? Those could actually be fun and make an impact on the game, while still taking advantage of mechanics that already exist.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on December 21, 2018, 05:22:52 AM
this would add to the game:

- pirates for role playing and something to look at
We already have this.  The player can SM in a few ships and fight it out themselves, or SM an entire civilization for Aurora to run by AI rules.
  --  Choose the system body you want to base the pirates on
  --  Add an Oxy-Nitrogen or Methane atmosphere
  --  use the Add NPR button to create an empire there, setting its strength to reflect the level of threat you want
Quote from: King-Salomon
- the need for the player to actually "patrole" his systems with is realistic - instead of just parking ships or PDC or ground-units somewhere in the system
THE ONLY PERSON STOPPING YOU FROM PATROLLING YOUR SYSTEMS IS YOU.  I already have system patrols in my game.  If your empire is "just parking ships or PDC or ground-units somewhere in the system" then it is doing so because YOU chose to have it do so.  Aurora reflects the level of realism you choose to put into it.
Quote from: King-Salomon
- a choice for the player if he is "taking the wealth hit" for a medium/long time in a war where he needs to order the "patrole ships" out of the system - or letting the ships to patrole and going to war with less ships
Again, this is solved by THE PLAYER choosing to operate their empire realistically,* or by exploiting the minimum requirements forced upon them by the software.  Since literally nothing is stopping you from running your empire the way you want, what you are asking for is to 'stop those other people from having their fun the wrong way.'


*THE BEST FEATURE of Aurora is the near-total ability of the player to decide what is 'realistic' for their empire.  It's almost the only reason to play.

Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on December 21, 2018, 05:30:53 AM
We already have this.  The player can SM in a few ships and fight it out themselves, or SM an entire civilization for Aurora to run by AI rules.

...

*THE BEST FEATURE of Aurora is the near-total ability of the player to decide what is 'realistic' for their empire.  It's almost the only reason to play.

sorry, but with this argument - while not false - you never need any feature or Ai - only the game mechanics and SM... why bother with an AI and NPR...
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on December 21, 2018, 06:09:43 AM
For 'pirates' to exist they need:

1) A shipyard to build their ships
2) Maintenance facilities to support them
3) Fuel Production facilities
4) Ordnance factories if they are missile-armed
5) Some way of building or acquiring all of the above and transporting/towing them to their destination
6) Population to man all of the above.
7) An economic rationale for their activity - why not use their ships for trade instead? Why is piracy more profitable or desirable when the potential (and likely) downside is destruction of their ships and loss of their lives?

Here is how a rationell could go:
Criminals would threaten the personell of civilian or player mining colonies. They would then provide either resources / maintenance / hidden shipyards for ship construction and repair.
1) The shipyard could be hidden in an extension of a civilian mining colony or one of a players automated mining sites.
2) likewise for maintenance
3) likewise for fuel production if they can afford it and don't steal enough
4) likewise for missile production
5) towing capacities are not needed this way
6) manpower will be provided by the civilian or player facilities
7) it could be state supported piracy (a player who wants to weaken another player but not attack him openly could support pirate activity), or freedom wishes. Maybe a colony with "low morale" wants to be independend but are not granted. They could resort to piracy (or more politically correct: rebellions).
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 21, 2018, 06:44:19 AM
Here is how a rationell could go:
Criminals would threaten the personell of civilian or player mining colonies. They would then provide either resources / maintenance / hidden shipyards for ship construction and repair.
1) The shipyard could be hidden in an extension of a civilian mining colony or one of a players automated mining sites.
2) likewise for maintenance
3) likewise for fuel production if they can afford it and don't steal enough
4) likewise for missile production
5) towing capacities are not needed this way
6) manpower will be provided by the civilian or player facilities
7) it could be state supported piracy (a player who wants to weaken another player but not attack him openly could support pirate activity), or freedom wishes. Maybe a colony with "low morale" wants to be independend but are not granted. They could resort to piracy (or more politically correct: rebellions).

If all that was true, why can't players or NPRs benefit from the shipbuilding, maintenance facilities, fuel production, missile production and manpower of a civilian mining colony?
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on December 21, 2018, 06:52:17 AM
On a somewhat related and possibly prerequisite note, an idea is perhaps some non-commercial civilian ships. Police frigates, pleasure yachts, bounty hunters, mercenaries, corporate guards, etc, some of which may be armed. They perform no actual function, just fly from place to place. They fight if hostile ships come in range, but dont go seeking enemies. They are armed with outdated tech (maybe 1-3 tech levels behind current tech, only created if the result > 0).

If they get destroyed, they cause a temporary small malus to wealth generation of colonies in nearby systems.

The function of these ships gameplay wise?
Battlefield terrain to use up attackers resources or forces them to avoid these ships (or get shot at)
Things for enemies to attack that hurts you less than a full nuclear assault on a homeworld or a lost fleet.
Raiding targets for small fleets
Hooks for potential future development such as pirates (Pirates dont build ships, they steal/buy these and use em till they break)

With regards to the pirates, I dont think pirates appearing to be civilian ships is going to work very well unless they only appear to be that way while inside sensor range. Can still be a bit noticable if they are off conventional trade routes.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on December 21, 2018, 07:21:26 AM
I have no problem with the idea of a threat that requires the player to actively patrol systems. However, there needs to be an in-game rationale and capability for that threat to exist. For 'pirates' to exist they need:

1) A shipyard to build their ships
2) Maintenance facilities to support them
3) Fuel Production facilities
4) Ordnance factories if they are missile-armed
5) Some way of building or acquiring all of the above and transporting/towing them to their destination
6) Population to man all of the above.
7) An economic rationale for their activity - why not use their ships for trade instead? Why is piracy more profitable or desirable when the potential (and likely) downside is destruction of their ships and loss of their lives?

It will be easier in C# Aurora to hide such facilities (due to reduced sensor ranges), but they still need to be created and moved to their destination. Also, the easiest way to destroy the 'pirates' would be to locate and destroy their support infrastructure so they would need defences for that too. I know 'Civilians' have support infrastructure we don't see but that infrastructure is not an active threat (and could be logically added if really needed).

BTW we aren't talking about a few guys in a skiff using RPGs to threaten a tanker. The 'pirates' in Aurora would be operating in deep space within the constraints of the Aurora economic model. Also, even if we draw parallels with Somali pirates, in the Aurora-verse the Western Powers would likely solve the problem by nuking the entire Somali coast.

Devil's advocating here:  I suspect very few pirates in the classic era (covered by the ultimate reference Sid Meier's Pirates! :) ) built their own ships.  Haven't done a lot of reading on it, but I suspect piracy was very much centered on non-aligned/un-incorporated population centers, which in turn is coupled to force deployment difficulty.  Or, as someone said, piracy is a criminal activity, not a nation-state activity (which is covered by privateering). 

So for piracy to be realistic, the government structure of Aurora would need to change to have much less of a "hive mind" model (referring to a conversation a year or so back about how much micro-ing players should do and how much control they should have over details of the empire - hive mind is 100% centralized control/microing) for the parts of the civilization - the pirates would "swim in the populace".  In this model, civilians would have exploration ships that would search for habitable worlds, and when they found them the civies would start their own colonies, with or without government assistance.  Those colonies wouldn't be part of your empire unless regularly visited by your military forces, and would act against the empire's interest if the player's back is turned.  A lot of this centers on communication time, sensor reach, ability to fingerprint a ship with sensor data, and transit time - if all ships in the empire are tracked in real time or if a merchant can transmit an ID of a raider, a pirate ship can't vanish back into the populace after striking.  It also probably requires a lot more small ship traffic, e.g. fighter or LAC size, in the civilian economy - I think most of the new world pirates were still a bunch of guys in skiffs (who would close and board rather than getting into broadside duels). 

So I see pirates as being in a small fast ship (that might be small enough able to be built in a factory rather than shipyard) that might have a popgun on board and/or has ability to land boarders.  This would lead civvies to also mount minimal weapons (to shoot the skiffs), which would give the opportunity for another type of pirate - the rogue merchant, which would be a well-armed merchie that would take other merchies.  This would also give them the excuse for showing up in a regular port which cargo of questionable origin - as long as the port authorities didn't examine the paper trail to well (lack of hive mind again) they could sell the cargo and take advantage of civvie maintenance facilities in the usual way.  Privateers would also fit into this model - they'd either be merchies with a letter of marque or custom-built light raiders.

As someone mentioned up-thread, piracy would be suppressed by having government forces exert control of populations through military or security forces, which would require changes to Aurora.

The problem with the above is that this isn't the way the civvie sector in Aurora is set up, because the game is set up with a high "hive mind" level.  Per the previous discussion, that's what a lot of players want, even if IMO it's unrealistic - a game where the player doesn't have any affect isn't a game, it's a simulation that you watch, so this is a gameplay/game fun decision.  The civvie sector in Aurora is also fairly highly simplified IMO - I suspect in a "real" Aurora civilization there's be a LOT more small intra-system small craft, and also a lot of short range inter-system craft that took advantage of the jump gate network.  It would be a lot of effort for Steve to set up the code to manage all this, along with the code to track criminality levels based on level of policing etc.

So while I think pirates are possible/likely using Aurora physics, I don't think the game's civvie simulation is rich enough yet to avoid having them seem like magic (appearing out of thin air).  Actually, if the civvie ships weren't track individually but were statistically generated it would make pirates a lot easier (they'd simply be another flavor of civvie generated), but that goes against where Steve wants to go with civvies.

John
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on December 21, 2018, 07:23:48 AM
On a somewhat related and possibly prerequisite note, an idea is perhaps some non-commercial civilian ships. Police frigates, pleasure yachts, bounty hunters, mercenaries, corporate guards, etc, some of which may be armed. They perform no actual function, just fly from place to place. They fight if hostile ships come in range, but dont go seeking enemies. They are armed with outdated tech (maybe 1-3 tech levels behind current tech, only created if the result > 0).

If they get destroyed, they cause a temporary small malus to wealth generation of colonies in nearby systems.

The function of these ships gameplay wise?
Battlefield terrain to use up attackers resources or forces them to avoid these ships (or get shot at)
Things for enemies to attack that hurts you less than a full nuclear assault on a homeworld or a lost fleet.
Raiding targets for small fleets
Hooks for potential future development such as pirates (Pirates dont build ships, they steal/buy these and use em till they break)

With regards to the pirates, I dont think pirates appearing to be civilian ships is going to work very well unless they only appear to be that way while inside sensor range. Can still be a bit noticable if they are off conventional trade routes.

This is the sort of change I'm talking about for intra-system traffic in my previous post.

John
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on December 21, 2018, 08:14:45 AM
I have no problem with the idea of a threat that requires the player to actively patrol systems. However, there needs to be an in-game rationale and capability for that threat to exist. For 'pirates' to exist they need:

1) A shipyard to build their ships
2) Maintenance facilities to support them
3) Fuel Production facilities
4) Ordnance factories if they are missile-armed
5) Some way of building or acquiring all of the above and transporting/towing them to their destination
6) Population to man all of the above.
7) An economic rationale for their activity - why not use their ships for trade instead? Why is piracy more profitable or desirable when the potential (and likely) downside is destruction of their ships and loss of their lives?

It will be easier in C# Aurora to hide such facilities (due to reduced sensor ranges), but they still need to be created and moved to their destination. Also, the easiest way to destroy the 'pirates' would be to locate and destroy their support infrastructure so they would need defences for that too. I know 'Civilians' have support infrastructure we don't see but that infrastructure is not an active threat (and could be logically added if really needed).

BTW we aren't talking about a few guys in a skiff using RPGs to threaten a tanker. The 'pirates' in Aurora would be operating in deep space within the constraints of the Aurora economic model. Also, even if we draw parallels with Somali pirates, in the Aurora-verse the Western Powers would likely solve the problem by nuking the entire Somali coast.

I do have some ideas about spoilers or NPRs that will fulfill a 'raiding' function, using a logical rationale for their behaviour and with an economic support structure. However, having pirates in the classical sense is difficult to envision within the logical constraints of the game.

I totally agree that for piracy to make any sort of sense there are alot more other features that need to be in place first.

- Expanded Civilian trade, instead of a few large shipping companies that move bulk trade we need to have smaller civilian traffic that pirates can "hide" in or start small to take over smaller spaceships, which can be retrofitted to military
- Blurred lines betwen Civilian and Military ships, or at least the ability to convert between them.
- Expanded Civilian Economy, where flow of goods, people, wealth and raw materials as well as creation and consumption of goods/materials outside government control is better modeled.
--- ( part of above ) Civilian shipyards, so that pirates can buy or upgrade civilian ships into smaller military ships.
--- ( part of above ) Civilians that consume fuel and fuel trade, so that pirates can buy fuel outside of government control.
--- ( part of above ) Civilians that consume arms and arms trade, so that pirates can buy arms outside of government control.
--- ( part of above ) Civilians that need maintenance, so that pirates can buy maintenance services outside of government control.
--- ( part of above ) Civilian land combat units, so that pirates can recruit/gain control of such in use of boarding. ( Could also be very nice to have for uprisings )
- Colonies outside of government control, and the whole spectrum from lawful heavily protected core worlds to "wild west" fringe colony worlds where little to no government presence and control exists outside the main strategic mining operations.
- A way to raid and get past jump point blockades. If pirates are limited to a single system it won't be hard for a large Empire to flush them out. This is also needed if you want government raiding with "submarine style" military ships that can operate behind enemy lines and sap their supply-lines.
- A way for pirates to board Civilian freighters that is less risky and safe enough that they can be mostly guaranteed to be able to secure it's cargo.


The conclusion I draw is that the game needs to develop into a very performance heavy and likely micromanage heavy direction with a lot of civilian more activities modeled that might not be desirable for the playability of the game, if we want it to support a universe where piracy can happen. I see uprisings from unrest and long distance to capital / minimal government military presence as more realistic and fun and achievable goals on the road in this direction.

Ofcourse you can also just fudge it all and spawn free military ships for pirates, but I don't think that's a solution Steve or many of the fans of Aurora would like.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on December 21, 2018, 08:26:43 AM
Or, as someone said, piracy is a criminal activity, not a nation-state activity (which is covered by privateering).

Now there's a beautiful idea that would fulfill the 'space pirate' niche while making it make sense.

Pirates in Aurora don't exist. However, privateers do.

NPRs (and the player! very important!) can choose to, in a sense, subsidize piracy. These would definitely be civilian ships, and you'd start this by paying some money and clicking a toggle on at least one of your civilian shipping lines. Then, said shipping lines would be enabled to build military ships (and maybe salvagers?) that remain under civilian control, with the designs based on your current research in the same way as civ ships currently are.

These privateers (operating under a set of dedicated AIs handling formations, targets, naval philosophy, etc.) would then go about targeting vessels of other civilizations (prioritizing commercial or civilian vessels) with whom you are at war, costing you some small amount of funding every time they destroy an enemy ship (or maybe gaining you funds from plunder if we like that instead) to simulate your Admiralty board approving lawful prizes, head money, etc.

Why do this instead of building up your own navy? A couple of reasons

- first, these guys are cheap. They're primarily financed by private concerns (namely those shipping lines) rather than your global wealth, and primarily make money for those global shipping lines (rather than you)
- second, and quite important, NPRs with whom you have established communications would consider acts of privateering far lesser provocation than sending an actual war fleet. It's not nothing, but on the high seas of the liquid dimension letters of marque are an understood political category. At least usually, depending on their racial AIs.

If we wanted to get really fancy, we could maybe also, in a vague way, assign areas of operation for these privateers. Nothing so specific as 'only work in this system' but we might be able to specifically forbid privateering in a handful of systems based on our largest sector capital level. Or we could, costing us more money than leaving them at loose ends because we have to make up the expected difference in prize money, contract them to provide escorts for civilian or commercial shipping in a system. Or plenty of other options, none of which are essential to the idea.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on December 21, 2018, 09:07:47 AM
Devil's advocating here:  I suspect very few pirates in the classic era (covered by the ultimate reference Sid Meier's Pirates! :) ) built their own ships.  Haven't done a lot of reading on it, but I suspect piracy was very much centered on non-aligned/un-incorporated population centers, which in turn is coupled to force deployment difficulty.
Also, mutineers taking over a naval vessel and setting up their own protection racket. In the Auroraverse, spaceship crew is relatively small, presumably reasonably well paid and treated as skilled professionals. In the era of tall ships, crews were huge, considered not quite full-membership humans, and treated rather shabbily. So sometimes the sailors would realize that they were a long way away from anywhere that was expecting them to come back, in an era when ships could feasibly simply go missing due to some happenstance misfortune, there were a whole lot more of them on the vessel than there were officers and marines, and those officers and marines were really not doing anything to endear themselves. At which point there would be a short round of fragging (usually richly deserved; 16th and 17th century military officers were generally swine that needed gutting), a quick repainting of the vessel name and ditching of official insignia, and a freshly minted freelance vessel available for local trade, smuggling, or the odd spot of remunerated violence.

Further, the glory days (if that is the right phrase) of piracy was a period where civilian vessels could feasibly be (and often were) outfitted with military grade weapons and protections. While there were dedicated warships built, the line between merchant vessel or civilian conversion warship and purpose built ship of the line was neither as wide from a technical perspective, nor so rigidly enforced from a cultural one as it would become in the 19th and 20th centuries. So the difference between a merchantman and a raider would sometimes come down to how many cannon his next port of call had, or how well disposed the locals were toward his particular vessel and crew. Also, vessels could more easily mask their identity and affiliations in an age before real-time vessel tracking. And many more vessels were independently owned and operated, where today civilian vessels have huge on-shore supporting organizations that governments can express their annoyance toward if their vessels get up to naughty things.
Title: Re: C# Aurora v0.x Suggestions
Post by: DEEPenergy on December 21, 2018, 12:55:46 PM
I dont think that pirates in a conventional sense make sense logistically in the Aurora universe due to the massive logistical restraints placed on the fielding of ships. Aurora pirates, if they existed, would never prey on deep space civilian freighters when it makes much more sense to prey on the cargo shuttles that supply them, meaning pirates would likely never stray too far from the surface of a planet. Pirates make much more sense as an NPR theme, one focused on breaching ships and capturing cargo, ships, and passengers then it does as swashbuckling in space.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on December 21, 2018, 02:03:59 PM
Though swashbuckling in space is so cool, I fondly recall Spelljammer  ;D
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on December 21, 2018, 02:21:19 PM
I dont think that pirates in a conventional sense make sense logistically in the Aurora universe due to the massive logistical restraints placed on the fielding of ships. Aurora pirates, if they existed, would never prey on deep space civilian freighters when it makes much more sense to prey on the cargo shuttles that supply them, meaning pirates would likely never stray too far from the surface of a planet. Pirates make much more sense as an NPR theme, one focused on breaching ships and capturing cargo, ships, and passengers then it does as swashbuckling in space.
Preying on cargo shuttles doesn't make a lot of sense for a few reasons.  First, you're so close to the planet that you're easily visible.  Who will buy the goods they just saw you steal?  Theft in deep space is much easier to hide.  Second, if cargo shuttles are abstract, why wouldn't there be abstract police forces?

A big benefit piracy adds is that it could provide NPR's or players with a plausibly deniable way to attack each other; privateers.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on December 21, 2018, 07:51:36 PM
I don't know if that makes sense, since they are in reach of relatively cheap and potentially prolific planetary armed forces that could murder their cargo raiding vessels.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on December 22, 2018, 04:41:45 AM
I have to say I’m not a fan of the space pirate thing. Does not seem an easy fit with the Aurora scheme of things. If you wanted to push patrols etc perhaps adding a system level defence requirement on top of a planet level defence requirement would be a way to do that. Points would come of mobile ships and you would need minimum levels before which merchant ships would be happy to trade. If that defence value deteriorated over a period of time rather than just drop when ships were not present then a patrol system would then become a key way of meeting this. To my mind though I don’t think that really adds anything much to the game play and is more of a faff.
Title: Re: C# Aurora v0.x Suggestions
Post by: totos_totidis on December 23, 2018, 09:22:39 AM
I have an idea for a new spoiler.  What about some sort of high tech npr (maybe maxtech?) with no jump drive technology.  They are a localized threat and the only way for them to gain jump drive would be to reverse engineer it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on December 23, 2018, 11:26:45 AM
I have to say I’m not a fan of the space pirate thing. Does not seem an easy fit with the Aurora scheme of things. If you wanted to push patrols etc perhaps adding a system level defence requirement on top of a planet level defence requirement would be a way to do that. Points would come of mobile ships and you would need minimum levels before which merchant ships would be happy to trade. If that defence value deteriorated over a period of time rather than just drop when ships were not present then a patrol system would then become a key way of meeting this. To my mind though I don’t think that really adds anything much to the game play and is more of a faff.
The problem with that is that it's just as easy to exploit as PPV currently is.  In VB6, I deal with PPV by shipping non-functional, super-cheap PDC's made of nothing but the cheapest missile launchers I can build.  I would just do the same thing to get by this system; super-cheap hulks made of just cheapo missile launchers.

But if pirates are a real threat that actually fly ships around, I'll have to build real, functional ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on December 24, 2018, 07:20:45 PM
Why don't you just SM the ships then?

I mean, I understand where you're coming from, but you're willfully exploiting the system. Every gaming system is, to some extent, open to exploitation. Aurora already gives us SM, that allows us to cheat us as much possible. Why should we worry about non-obvious exploits? I'm all for closing obvious exploits, the sort of stuff that will happen during "normal" gameplay, but there is little point in trying to close abnormal loopholes, the sort of stuff that people need to search for. Those things will always be present in a system as complicated as Aurora is, and since it's a singleplayer game, there really is no need to prevent the player from exploiting, if the player is adamant on exploiting.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 25, 2018, 07:36:04 AM
The way that Aurora is built I don't think a pirate functionality make much sense since we are in control of pretty much everything and it is a platform for role-play rather than traditional gaming.

There are no point in exploiting the game mechanics in any way, i would rather say that doing the reverse is the way to go.

You should instead create a specific player controlled faction that act as the pirates and actually make them a threat. You don't need very efficient or good ships in order to take on civilian ships and this will force you to have a patrolling force to deal with them.

If you don't have the patience to do this then just imagine the pirates and build the patrol ships that you need and go from there. Use the PPV values as a guideline and build proper patrol ships and set them on different patrol patterns as a simulation of policing the civilian traffic.

I also find it quite amusing that people feel it necessary to abuse game mechanic in a game like Aurora since you can just SM yourself anything you want at any time anyway and it is not cheating either since you are the only one there anyway. While setting up restrictions actually will make things more interesting and challenging overall.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on December 25, 2018, 11:54:41 AM
Why have any mechanics at all then?  I mean, what is the purpose of anything in the game if you can just SM or imagine it all?

I'm happy SM is a feature, but the more mechanics Aurora supports on its own, the better.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 26, 2018, 04:23:26 AM
Why have any mechanics at all then?  I mean, what is the purpose of anything in the game if you can just SM or imagine it all?

I'm happy SM is a feature, but the more mechanics Aurora supports on its own, the better.

To be honest I would rather like to have a good civilian mechanic before we get anything close to a pirate mechanic. As long as there are no real civilian mechanic in Aurora any pirate mechanic would just feel very artificial.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on December 26, 2018, 06:26:39 AM
What Jorgen said. Frankly as the game is now, there's simply no way you can justify the presence of pirates.
And as Steve said before, you'd basically have to make them a mini faction, with shipyards, facilities, habitats/colonies and such.

Pirates in a sci-fi setting only work if the setting is huge, with hundreds of worls/systems at the very least. Thousands is better to be even remotely plausible. Anything smaller, and you cannot justify piracy because there's simply not enough trade to justify piracy, not enough explored systems to justify the military not finding such pirates, and just no reason for pirates to exist. Let's say Pirate Group A harasses a trade ship and steals trade commodities. So what? What are they going to do with that? Keep it all to themselves? Come to your worlds to sell it? How are they even going to hide, considering there's literally a few hundred ships at MOST in the entire space? What are they goign to eat, were are they going to buy necessities and spare parts?

You just cannot say: Oh look, somehow military ships from our race appeared. And yes, we have a grand total of three shipyards, so who knows who built them. They just magically came into existance somehow. And they're pirates! YARRRR.

Piracy can work in something like Star Wars, because you have literally hundreds of millions of inhabited systems and millions of billions of starships flying around between them. Also, all of this has been around for millennias. So it is plausible that there's hidden bases around, or hijacked ships, or places where you can sell stolen goods. And that pirates can hide and pretend to be traders in order to smuggle goods, because once again, they can simply "hide" most of the time amongst normal traders and such. And in fact a setting like Star Wars, huge as it is, also has semi independet enclaves, mercenaries and the like. And that can be justified, because once again the sheer size and age of the settings makes it plausible.

In Aurora you have a civilization that has been around at most for a few decades, and that maybe produced 2-300 ships total. The scale of the game does not allow for realistic pirates.
What you could possibily justify is a colony/system that went rogue and seceded from the home planet, and wages low-intensity war on its homeworlds by harassing from time to time. All the while, being careful they don't ever become a problem big enough to justify the homeworlds coming in guns blazing and reconquering the secessionists.
But such a scenario cannot and should not be just a random "chance". At the moment and with the structure of Aurora it's truly best modeled via SM.
Title: Re: C# Aurora v0.x Suggestions
Post by: misanthropope on December 26, 2018, 08:54:22 AM
choke points and stupid huge detection ranges make pirates IMO untenable in aurora, but the shipyard claim is demonstrably false.  civilian shipping originates from secret shipyards, and given the rapid response to subsidizing the civvies, that shipyard network is extensive and advanced.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on December 26, 2018, 11:55:23 AM
About detection ranges, in real life pirates aren't hard to stop because you can't spot their ships.  They're hard to stop because you can't tell which ships are pirate ships and which ships are civilian.

I've said it before, but I think Aurora really could benefit from having multiple levels of detection.  Just because you can see a ship shouldn't give you exactly what class it is.
Title: Re: C# Aurora v0.x Suggestions
Post by: joeclark77 on December 26, 2018, 01:44:26 PM
So for piracy to be realistic, the government structure of Aurora would need to change to have much less of a "hive mind" model (referring to a conversation a year or so back about how much micro-ing players should do and how much control they should have over details of the empire - hive mind is 100% centralized control/microing) for the parts of the civilization - the pirates would "swim in the populace".  In this model, civilians would have exploration ships that would search for habitable worlds, and when they found them the civies would start their own colonies, with or without government assistance.  Those colonies wouldn't be part of your empire unless regularly visited by your military forces, and would act against the empire's interest if the player's back is turned. 

I do really like the idea of civilians independently building colonies that the government doesn't control.  I find that in my games I like to be quite deliberate in which systems I expand to, so I can place maintenance facilities, PDCs, fuel harvesters, etc., and defend the border as I move it forward.  Civilians would mess up my plans by settling in any old system that had a 2.0 world, adding to the challenge by reducing my control.  Maybe it's not Aurora but it would be a neat game.
Title: Re: C# Aurora v0.x Suggestions
Post by: joeclark77 on December 26, 2018, 01:45:54 PM
Another suggestion: can we get an option to use miles instead of kilometers, knots instead of km/s, and gallons instead of litres?  The metric system implies a dystopian future and I prefer to imagine a future where the good guys win.  ;)

It's only a matter of time.
The metric system will eventually replace the imperial one.
Surrender yourself, resistance is futile.

Remind me... whose 3x5-foot flag is on the moon?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 26, 2018, 02:12:20 PM
Another suggestion: can we get an option to use miles instead of kilometers, knots instead of km/s, and gallons instead of litres?  The metric system implies a dystopian future and I prefer to imagine a future where the good guys win.  ;)

You can display miles on the VB6 system view. I might add the same for C#

I grew up with the Imperial system and understand it in detail. All the road signs here are in miles, not kilometres. Body weight is measured in Stones (14 Pounds per Stone). BTW did you know a cricket pitch is 22 yards long because that is a Chain? 10 Chains in  Furlong, 8 Furlongs in a mile.

However, having said that, the metric system is so much easier to work with than Imperial, so I suspect that long-term, regardless of nostalgia for Imperial, metric is going to win out. Besides, even if I did use Imperial, I would use English tons and English gallons, not Americans tons or American gallons :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on December 27, 2018, 04:11:24 AM
Resistance is futile, all will be assimilated to the Metric-Borgness.

Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on December 27, 2018, 10:41:27 AM
I do really like the idea of civilians independently building colonies that the government doesn't control.  I find that in my games I like to be quite deliberate in which systems I expand to, so I can place maintenance facilities, PDCs, fuel harvesters, etc., and defend the border as I move it forward.  Civilians would mess up my plans by settling in any old system that had a 2.0 world, adding to the challenge by reducing my control.  Maybe it's not Aurora but it would be a neat game.

Maybe going for the planets is the wrong approach. But I could see civilians building infrastructure in any system you have a colony, or is between systems you have a colony. Various industrial plants/asteroid miners going for iron/non-transnewtonian resources, small utility craft/yachts/engieering vessels flying between these sites...
these could all generate wealth, and would present raiding targets, or a backdrop for pirates/privateers. (you should have a flag to ban commercial activity in a system)
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on December 27, 2018, 01:56:45 PM
Suggestion: Some kind of forward observer module for fighters.  In real life, air assets are often used to direct fire support.  Why not in Aurora?
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on December 27, 2018, 03:19:29 PM
Mechanically that would allow you to operate an effective independent air arm. The better part of a century of military history suggests that this is a pipe dream. And not for lack of trying either - peacetime air forces tend to resent doctrines that center their role around close air support, because they see it as placing them in a subordinate position to mere infantry.
Title: Re: C# Aurora v0.x Suggestions
Post by: backstab on December 28, 2018, 03:36:07 AM
Can we have an option to SM in spoiler races ..
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 28, 2018, 07:39:30 AM
Can we have an option to SM in spoiler races ..

Yes, that sounds like a good idea for testing too :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Agoelia on December 28, 2018, 07:48:42 AM
Quote from: joeclark77 link=topic=9841. msg111505#msg111505 date=1545853554
Quote from: Seolferwulf link=topic=9841. msg111408#msg111408 date=1545365249
Quote from: joeclark77 link=topic=9841. msg111407#msg111407 date=1545364043
Another suggestion: can we get an option to use miles instead of kilometers, knots instead of km/s, and gallons instead of litres?  The metric system implies a dystopian future and I prefer to imagine a future where the good guys win.   ;)

It's only a matter of time.
The metric system will eventually replace the imperial one.
Surrender yourself, resistance is futile.

Remind me. . .  whose 3x5-foot flag is on the moon?


The USA flag.  Which got there using metrics, not imperials (Nasa mainly uses metrics, and once even lost a probe due to the imperial system inherently complicated conversions).
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on December 28, 2018, 08:01:11 AM
The USA flag.  Which got there using metrics, not imperials.

Untrue. NASA used Imperial (American) units and to get to the Moon, and in fact still largely uses them today (much to my chagrin).

This isn't an argument that Imperial or Revolutionary units are better. I'm staying out of that fight, except to mention that as a physicist I prefer the latter for ease of use.
Title: Re: C# Aurora v0.x Suggestions
Post by: prophetical on December 28, 2018, 01:33:50 PM
I was wondering if there is a system to limit the number of commanders who can hold specific ranks.  I understand that I can make ranks with such prohibitively high promotion scores and just manually assign people, but I was wondering if we can automate that somehow.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on December 28, 2018, 01:49:58 PM
I was wondering if there is a system to limit the number of commanders who can hold specific ranks.  I understand that I can make ranks with such prohibitively high promotion scores and just manually assign people, but I was wondering if we can automate that somehow.

It's already automated by proportion -- either 1/3 or 1/2 the next lowest rank, but if you mean a way to ensure that your rank of 'Supreme Grand High Sky Marshal of the Galactic Battle Fleet, Survey Fleet, and Support Fleet' only ever has one person in it, then no, there isn't currently such an option.  I, too, would be happy to see a cap I could set to limit the maximum number of officers in a specific rank, so that my "Council of Twelve" would in fact have twelve members and not fifteen.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on December 28, 2018, 02:01:38 PM
I would like to request from Steve more terrifying galactic invaders. They are really needed in my opinion.

In current Aurora, they're not very high tech level. Sure, if they come very soon by chance, they are not winnable. Especially with conventional start, which I always use. But I want to feel... TERROR... when they arrive :)

I have three possible suggestions for ways to do this:

1) Choose at game start how BRUTAL they are.
2) Have them reliably better than the players when they appear. In tech level, but also with better designs. This is my least favorite options, as it would not reward at all the player who invests a lot in tech research
3) ... who said there's only one race of galactic invaders? Maybe they have a fractured "nation", with different factions or similar. And if you do repel one.... another stronger faction will come knocking later on, with a lot of new and exciting toys  ;D

P.S. Precursors need better ship designs as well :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 28, 2018, 03:39:32 PM
I would like to request from Steve more terrifying galactic invaders. They are really needed in my opinion.

In current Aurora, they're not very high tech level. Sure, if they come very soon by chance, they are not winnable. Especially with conventional start, which I always use. But I want to feel... TERROR... when they arrive :)

I have three possible suggestions for ways to do this:

1) Choose at game start how BRUTAL they are.
2) Have them reliably better than the players when they appear. In tech level, but also with better designs. This is my least favorite options, as it would not reward at all the player who invests a lot in tech research
3) ... who said there's only one race of galactic invaders? Maybe they have a fractured "nation", with different factions or similar. And if you do repel one.... another stronger faction will come knocking later on, with a lot of new and exciting toys  ;D

P.S. Precursors need better ship designs as well :)

All the spoiler races are getting an overhaul and I will be creating additional spoiler type races.
Title: Re: C# Aurora v0.x Suggestions
Post by: prophetical on December 28, 2018, 04:12:23 PM
Quote from: Father Tim link=topic=9841. msg111685#msg111685 date=1546026598
Quote from: prophetical link=topic=9841. msg111682#msg111682 date=1546025630
I was wondering if there is a system to limit the number of commanders who can hold specific ranks.   I understand that I can make ranks with such prohibitively high promotion scores and just manually assign people, but I was wondering if we can automate that somehow.

It's already automated by proprotion -- either 1/3 or 1/2 the net lowest rank, but if you mean a way to ensure that your rank of 'Supreme Grand High Sky Marshal of the Galactic Battle Fleet, Survey Fleet, and Support Fleet' only ever has one person in it, then no, there isn't currently such an option.   I, too, would be happy to see cap I could set to limit the maximum number of officers in a sepcific rank, so that my "Council of Twelve" would in fact have twelve members and not fifteen.

Yes, I do indeed want a GHSM of GBFSF&SF.  Is that so wrong?  ;)

But you did explain it well that a specific cap is what I am interested in.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 28, 2018, 04:27:27 PM
Yes, I do indeed want a GHSM of GBFSF&SF.  Is that so wrong?  ;)

But you did explain it well that a specific cap is what I am interested in.

That is straightforward. I will try to pick it up when I run back through the suggestion thread closer to release.
Title: Re: C# Aurora v0.x Suggestions
Post by: Seolferwulf on December 28, 2018, 07:32:04 PM
An idea for another spoiler race, or rather just a trap installed in a system.
Whenever a black hole is generated instead of a regular system there would be a chance for a contraption to be installed on top of it.
The contraption is orbiting around the black hole and when ships enter the system it uses high tech tractor beams to pull them closer to the center until they can't escape anymore.
Ways to get away are either to destroy the contraption or its sensor or tractor beam components.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kurt on December 28, 2018, 09:03:40 PM
If you are taking suggestions for spoilers - how about Saberhagen's classic Berserkers?  Huge automated warships left from some ancient war like minefields.  Activated when ships move too close.  Might have battle damage from ancient battles.  Might be a Berserker base capable of building or repairing Berserkers.  Will destroy biological life unmercifully, but inherently unpredictable. 

Hmmm...might be too powerful. 

Kurt
Title: Re: C# Aurora v0.x Suggestions
Post by: Erik L on December 28, 2018, 09:44:19 PM
Could take a page from Star Trek and have space-faring alien life forms. Space whales, etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: Conscript Gary on December 28, 2018, 10:42:55 PM
Suggestion: Modify retooling costs for a shipyard based on how similar the class designs are, similarly to how class similarity is determined for building from the same yard and for refit cost. If you change tooling from one freighter to a slightly more advanced freighter, it would take less time than changing the tooling from a destroyer to a fleet carrier.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on December 29, 2018, 01:41:49 AM
A suggestion for an improvement to conditional and standing orders:

Split it up into two screens: One is entirely called conditional orders, where you can assign triggers with actions to be taken, and save them under a custom name.
Multiple orders can be joined, to make for example a 'standard refuel and maintenance policy'
Orders here could also be customized, for example limit which specific maintenance locations are eligible, or which sites should be supplied with autominers, or colonists.

Fleets themselves would just sign up to the previously defined standing order sets. If you later on change the standing and conditional orders, it will change them for any fleet that were assigned that order set.

This would prevent a lot of repetition, and allow for future expansion of more interesting and advanced conditional behavior.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 29, 2018, 06:54:04 AM
Could take a page from Star Trek and have space-faring alien life forms. Space whales, etc.

Yes, I keep considering space whales :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 29, 2018, 06:54:34 AM
Suggestion: Modify retooling costs for a shipyard based on how similar the class designs are, similarly to how class similarity is determined for building from the same yard and for refit cost. If you change tooling from one freighter to a slightly more advanced freighter, it would take less time than changing the tooling from a destroyer to a fleet carrier.

That is how it works in VB6 and C# Aurora :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 29, 2018, 06:56:50 AM
A suggestion for an improvement to conditional and standing orders:

Split it up into two screens: One is entirely called conditional orders, where you can assign triggers with actions to be taken, and save them under a custom name.
Multiple orders can be joined, to make for example a 'standard refuel and maintenance policy'
Orders here could also be customized, for example limit which specific maintenance locations are eligible, or which sites should be supplied with autominers, or colonists.

Fleets themselves would just sign up to the previously defined standing order sets. If you later on change the standing and conditional orders, it will change them for any fleet that were assigned that order set.

This would prevent a lot of repetition, and allow for future expansion of more interesting and advanced conditional behavior.

Interesting idea. I won't tackle it right now as I want to concentrate on getting ready for the new campaign, but I will take a look when I go through the suggestion list later.
Title: Re: C# Aurora v0.x Suggestions
Post by: Iceranger on December 29, 2018, 09:42:28 AM
A few mostly QoL suggestions on components:

1, a 0. 02HS 'micro' fuel tank after the tiny fuel tank research.  This is mostly to be used on fighters.  It should find its usefulness as ship engines can be smaller than 1HS in C#.  (Currently the only component <0. 1HS is the fighter crew module, which is 0. 04HS, and when it is used, the fighter tonnage will end up with xx2 or xx7 ton, which can be an eyesore for some players. )

2, larger cargo holds for research, maybe a large cargo hold = 5x standard cargo hold, and a huge one = 50x standard cargo hold.
Title: Re: C# Aurora v0.x Suggestions
Post by: somebody1212 on December 29, 2018, 01:07:16 PM
Following some discussion on the Discord, would it be possible to have a setup option to enable ramming for players?
(I understand you don't want it as a default option)
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 30, 2018, 11:59:43 AM
A few mostly QoL suggestions on components:

1, a 0. 02HS 'micro' fuel tank after the tiny fuel tank research.  This is mostly to be used on fighters.  It should find its usefulness as ship engines can be smaller than 1HS in C#.  (Currently the only component <0. 1HS is the fighter crew module, which is 0. 04HS, and when it is used, the fighter tonnage will end up with xx2 or xx7 ton, which can be an eyesore for some players. )

2, larger cargo holds for research, maybe a large cargo hold = 5x standard cargo hold, and a huge one = 50x standard cargo hold.

I've added the 0.02 HS fuel tank, which costs 0.5 BP and holds 1000 litres.

I've also added a Cargo Hold - Large, which is 5x larger than the standard cargo hold. Size 2500 HS, Cost 200 BP.
Title: Re: C# Aurora v0.x Suggestions
Post by: Up_down66 on December 30, 2018, 04:57:30 PM
Just read about the new boarding, sounds awesome, inching ever closer to finally being able to play.  Anyways had a idea for a new ship component? A sort of boarding defense system, outfitting the ship with smaller turrets or other types of automated defenses.  I think this would allow ships to defend better against a boarding heavy race without having to carry around their own units in their ship, or support the already defending units by adding some variety.  The defense unit it self could be considered a unit that fights like everything else.  It would need a a sort of command room in the ship so if it's destroyed in ship combat or in the boarding combat I suppose the turrets would just turn off.

 It's an idea, don't know if it's good or not but might add a little something fighting automated defenses and the crew and any actual units in the halls and rooms of a ship.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on December 30, 2018, 10:44:19 PM
While that sounds like a great justification flavour-wise, wouldn't it mechanically be just an increase to the 'fortification rate' of the defenders in a boarding action?  If you want your ship to be better at repelling boarders, then you should either add extra crew (for low cost, low effectiveness fighters) or outright Infantry formations.  A 50-ton 'Infantry' unit of crew-served anti-personnel weapons isn't much different from 1 Hull Space of 'automated turrets' and the computers & crewpower to maintain and run them.
Title: Re: C# Aurora v0.x Suggestions
Post by: Up_down66 on December 30, 2018, 11:10:33 PM
Quote from: Father Tim link=topic=9841. msg111785#msg111785 date=1546231459
While that sounds like a great justification flavour-wise, wouldn't it mechanically be just an increase to the 'fortification rate' of the defenders in a boarding action?  If you want your ship to be better at repelling boarders, then you should either add extra crew (for low cost, low effectiveness fighters) or outright Infantry formations.   A 50-ton 'Infantry' unit of crew-served anti-personnel weapons isn't much different from 1 Hull Space of 'automated turrets' and the computers & crewpower to maintain and run them.

Having defenses be different from infantry and just crew members I think would be important, like how vehicles and aircraft are different from infantry.  It would need to have trade offs for why have automated defenses rather then having a garrison or vice visa.

 You can't repair dead bodies but you can repair something automated.  And if a small ship is boarded, chances are it's gonna lose the fight, but having a h. s or two of defenses along side some crew members it really gonna annoy the opposition if they have to fight something that can't surrender on every little ship.  Might buy some time for another fleet to come in or might wear down smaller marine forces to make them even if only a little less of a threat next fight.  And the smaller the ship the less the chance of you putting any thing other then crew on it, although I suppose the smaller the ship the less the chance of it being boarded.

 Idk I doubt boarding will be common place enough to warrant a new component just to help defend against it but if it does become more common place having the option to have a more cost effective defenive force that you only have build instead of train and house might be interesting
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on December 31, 2018, 02:55:20 AM
Having defenses be different from infantry and just crew members I think would be important, like how vehicles and aircraft are different from infantry.  It would need to have trade offs for why have automated defenses rather then having a garrison or vice visa.

From pure logical and technobable point of view you are correct, automatic defence systems in a ship would be a great addition...

but from the game point of view I am against it... it would just make boarding "more expensive" ... boarding is something most players don't do in VB6 (as far as I see it) because it is not profitable enough to do instead of killing the target... you have to invest in troopbays, troops, have to risk your ships to get close to a vessel which might be "dead in the water" but could still have (or repair) some weapons etcpp

to add intern ship defence systems other than troops it would mean to add the systems to NPR ship-design .. so you can count on it to get into them if you try to board.. which just makes the boarding more expensive again...

I think marine detachments to defend your ships are fine for RP and if they are added into NPR ship design it's OK as I hope that the AI in C# might be smart enough to use them to board itself instead of just killing...

defence systems that only rise the cost of boarding are logical, fun to read and realistic but as long as boarding a ship is not more profitable I don't see a point in adding them...
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 31, 2018, 03:26:57 AM
I think marine detachments to defend your ships are fine for RP and if they are added into NPR ship design it's OK as I hope that the AI in C# might be smart enough to use them to board itself instead of just killing...

Yes, some types of NPR will use boarding tactics.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on December 31, 2018, 11:26:02 AM
While that sounds like a great justification flavour-wise, wouldn't it mechanically be just an increase to the 'fortification rate' of the defenders in a boarding action?  If you want your ship to be better at repelling boarders, then you should either add extra crew (for low cost, low effectiveness fighters) or outright Infantry formations.  A 50-ton 'Infantry' unit of crew-served anti-personnel weapons isn't much different from 1 Hull Space of 'automated turrets' and the computers & crewpower to maintain and run them.
The big difference I see is that those automated turrets are attached to the ship.  You can't drop them on a planet or move them to a different ship.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on January 02, 2019, 03:29:25 AM
I've added the 0.02 HS fuel tank, which costs 0.5 BP and holds 1000 litres.

I've also added a Cargo Hold - Large, which is 5x larger than the standard cargo hold. Size 2500 HS, Cost 200 BP.
How about a general change of all "cargo" modules? A system where you specify the amount of space/fuel/maintenance you want - as well as the amount of subdivisions (so that not the whole fuel gets lost when the fuel module is hit/destroyed - and the game simply calculates how much HS that would take.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 02, 2019, 04:40:14 AM
A suggestion for missiles in C# if not too complicated.

Since the new sensor system might make self guiding missiles a bit more interesting and viable how about allowing munition inside a large missile being able to use the active or passive sensor of the parent missile. You could add a small 0.25 MSP electronic guidance system or something to control them. I honestly don't remember how it worked in VB6 with mines and stuff, I rarely used mines, but I'm sure the sub munition could not use the parent sensors.

This could be interesting to build hit and run type ships or engage in sort of submarine style fighting.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on January 02, 2019, 10:41:48 AM
Suggestion about seeing "previous designs" with engine designing:

I would suggest a feature in the ship module designer (like engine maybe scanner etc) were I can "load" a previous design and chance the parameters for a new design with better tech like it is possible with missile design...

in most of my games I go with 4-6 different ship engines which I update as tech progresses but the "character" of the engine is unchanged... for example most of the time the HS of the engine stays the same but output is higher and fuel consumption is lower...

So it would be great addition if I could load a previous design of the "now" engine to chance the design of it without having to write the specifics of all 6 different engines on a piece of paper after researching enough tech to design new engines...

it would be a great QoL (for me) to be able to do that - the same would be true for scanner tech etc as most of the time HS and resolution for an "old" design stay the same too with new sensor strength... maybe some of the other designs (magazine, weapons..) could profit from this too...

not sure how work intensive it would be to add something like the "previous missile design loading" for the other design-buildings but it would be great to add...
Title: Re: C# Aurora v0.x Suggestions
Post by: Iceranger on January 02, 2019, 11:12:54 AM
Quote from: Jorgen_CAB link=topic=9841. msg111814#msg111814 date=1546425614
A suggestion for missiles in C# if not too complicated.

Since the new sensor system might make self guiding missiles a bit more interesting and viable how about allowing munition inside a large missile being able to use the active or passive sensor of the parent missile.  You could add a small 0. 25 MSP electronic guidance system or something to control them.  I honestly don't remember how it worked in VB6 with mines and stuff, I rarely used mines, but I'm sure the sub munition could not use the parent sensors.

This could be interesting to build hit and run type ships or engage in sort of submarine style fighting.
If I recall correctly, currently in VB6 sub munitions do use their parent stage sensors.  Mines do not require sensors on the sub munitions.

I agree that for submarine style fighting, we could use a easier way of firing self-guided missiles at a TH/EM contact other than calculating the way point ourselves.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on January 03, 2019, 11:03:22 AM
The thread about drop ships got me thinking about the civilian/military classification system, and how to overcome it with something that is still convenient. While I am aware this is a big idea, and unlikely to make it into the first release, I would like to get this idea out never the less.

Maintenance Size
Each component gets two new attributes, that is the maintenance size, and maintenance cost. It is based as before on cost and size of the component, times a modifier.
For weapons and sensors, this will usually be 1. For something easy to maintain as cargo holds, these would be much smaller, 100 000t of cargo holds might only take 1000t of maintenance capacity, and cost only 10% of their BP.
Armor on the other hand might be cheap to maintain, but take up more than its weight in maintenance capacity, since armor makes any other system on a ship less accessible.
The general trend of civilian versions of magazines/hangars will be less space efficient and/or less able to take damage, but more efficient and affordable in maintenance.
Similarly, large engines/shields/reactors might have lower maintenance than smaller engines, as 20 5HS engines have a lot more parts that can fail than 2 50 HS engines.
Lower power modifier will also result in easier to maintain engines due to lower stresses.

Engineering spaces will work on their percentage relative to effective maintenance size, so a single engineering space on a freighter will be much more effective than on a battleship

A special case would be work platforms. These are orbital habitats, miners, fuel extractors, terraformers, maintenance facilities, these will be considered as having maintenance facilities for themselves built in. Given enough supplies, they can maintain themselves infinitely, plus perhaps a bit spare to also cover some fuel tanks/small engines to make self propelled versions of them.

Overhauls
Every ship would now eventually need to undergo overhaul. Except for work platforms, which should be self maintaining, every ship will eventually return to a port anyway.
A standing order "Overhaul if arriving at a port with high maintenance clock" should automate most of that requirement.

Maintenance Supplies
C# already uses only maintenance supplies for all maintenance purposes, so all that is really needed is a way to automatically supply them. If you can set a tender to 'resupply nearest maintenance location' and have maintenance locations able to either request or supply the needed maintenance supplies, again a few ships should be able to distribute the needed supplies.

Shipyards
Shipyards will get a second property, a complexity limit. This is the maximum maintenance cost of a ship that can be built in a shipyard, representing the yards capability to handle high-tech components.
Increasing complexity costs additional resources, thus a yard that can build freighters will be a lot cheaper than one for supercarries. Thus you still get a variety in either complex, smaller yards for military craft, simpler large yards for tankers and such, and expensive, large complex yards for true capital ships.

Jump Drives
Jump Drives would need a change, as now there is no clear cut difference between military and commercial engine. However this is not the best anyway, since you can also jump towed ships, so the engine does not seem strictly required for a jump.
A replacement to still allow civilian jump drives would be to add a property "Jump Delay," which controls how long a ship is frozen after a jump. For a commercial tender, a full hour will still be acceptable, but a combat ship will want something faster.


This overall would allow for some more flexibility in ship design, as maintenance is now determined by all components, not the presence of a single one. If you want 2HS sensors on all your freighters, you can do it now. Similarly, Q-ships would be possible now, or equipping a 100kton freighter with some ELINT as a spy ship.
It would also allow to go for true mixed designs, putting some AMM systems on your colliers and tankers if you want, or channel the 18th century completely (or any of a number of ScFi franchises with armed merchantmen) and arm all your ships if you want. While I doubt that is optimal, it would certainly be a fun read.
Title: Re: C# Aurora v0.x Suggestions
Post by: zatomic on January 03, 2019, 01:26:43 PM
I had been thinking along similar lines to Whitecold regarding overhauls and the military/commercial division.

Currently a ships maintenance is based on components breaking down and requiring parts to repair combined with a maintenance life that causes the rate of breakdowns to increase the longer it's been since the last overhaul. My thought is that when a ships maintenance life hits certain criteria, it is treated as able to do 'continuous self overhaul', meaning that while it still has failures and uses supplies, the rate of failure never increases from the baseline. To avoid making it to easy to have military ships meet this criteria, I would base it on something like (with all numbers being just suggestions and adjustable for balance):

Maintenance life greater than 5 yrs.
Maintenance supply capacity greater than 4-times largest component usage.
Maintenance space equal to 20% of total HS of fail-able components(meaning that cargo holds, armor, and probably a few other things don't contribute to this size).

Thus, for a traditional cargo ship, you might need a few more engineering spaces, but those are cheap and since the cargo bays don't count towards the fail-able component mass, you get a ship that never needs overhaul and consumes a small trickle of maintenance supplies (which can be topped up every time it refuels). If you wanted to add a little bit bigger sensor or a small gauss turret, you just need a little more engineering space to meet the criteria.

For a combat ship, where most of the components are fail-able, 20% space to engineering spaces would be a big sacrifice in terms of size and impact on speed, and thus while possible, would not be as effective as a ship designed to be overhauled every few years. On the other hand, maybe for your death-star, not needing overhaul is worth the extra space just so you don't need a facility capable of doing an overhaul on your bazillion ton doom ship.

Another interesting case would be military space stations. Something not designed to move (or move much since it could have a few engines to slowly move into position, or be towed by tugs), the extra space might be worth not having to move it, or, if it's large, having a facility capable of overhauling it. Of course, your space station would still need regular deliveries of supplies as it would still have breakdowns at a steady rate.

All that said, I haven't yet had a good idea on how to handle military vs. commercial shipyards without going down a similar path to Whitecold with 2 different 'sizes' for shipyards based on total bulk size and 'fail-able' component size. One option might be to say that a shipyard doesn't have to completely enclose the ship it's building, and so make only the 'fail-able' components count (or the effective maintenance size in Whitecold's version).

In fact, taking Whitecold's suggestion and just adding my criteria for a ship not requiring overhauls (continuous self overhaul) would also be a good solution. (Having to overhaul freighters, even with an automatic order, would be tedious, especially if a whole task group gets held up or split because one freighter was due for overhaul. Having an option for military space stations to not require overhaul as well is also nice).
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on January 03, 2019, 03:03:16 PM
If we want to get really fancy, we could give each individual component a separate clock:
- Sensors and fire controls run up maintenance clock very slowly but continuously whether they are in use or not (as the passive sensor component decays/misaligns/needs to be calibrated by your resident Turian).
- Active sensors run up wear faster when in use, at a rate of [sensor maintenance intensity] x [sensor power] / [sensor size].
- Engines run up maintenance clock by being used (at a rate of [engine maintenance intensity] x [engine power delivered] / [engine size]).
- Shields from being on, and faster when (re)charging/reloading.
- Shuttle bays, fuel and ordnance transfer systems, and hangars/flight decks would accumulate wear from the relevant cargo operations, resp. reloading, repairing, resupplying, or reducing maintenance or deployment clocks on parasites.
- Weapons from charging their capacitors, replacing the current failure scheme (and maybe at a slower rate from holding charge on their capacitors - forcing people to make choices regarding state of readiness of, e.g. jump point defense forces).
- Mining, terraforming, refinery, maintenance, etc. modules do not accumulate failure rate or maintenance clock, as they are assumed to be continuously overhauled on-site, but have a baseline failure rate that ensures they must still be kept in supply. And maybe a higher failure rate when in use than when idle.
- Reactor maintenance would be abstracted into weapon capacitor maintenance, because turning reactors on and off separate from weapons would be tedious.
- Magazines are assumed to be dumb cargo space, with all the movable parts being baked into the launcher, and so would need maintenance but not accumulate failure rate.
- Life support, engineering spaces, damage control, bridge, fuel tanks, etc., would have supply consumption but not escalating failure rates. Jump engines should probably also go here, because allocating maintenance cycles to them in a transparent and reasonable way gets tricky when they act as jump tenders for non-jump-capable vessels.

Further, instead of failing catastrophically as components do now, have them fail at a rate of [base rate] x [size in HS, min 1] but only costing [base cost] / [size in HS, min 1] supplies to fix each time (so maintaining a 50 HS engine requires you to replace a sprocket every week instead of hot swapping the whole thing once a year).

Finally, have failure rate only begin to increase after a certain amount of time on the maintenance clock (could be tech dependent, could be fixed for a given component class, could be a design parameter), and cap failure rates at, e.g., 10x baseline rate.

The cap on failure rate would ensure that vessels which have a very low baseline supply consumption, such as jump point pickets, freighters, tankers, colliers, jump tenders, fuel harvesters, terraformers, etc. could effectively opt out of overhauls. This could be explained as vessels for which this is practical to do having been optimized for on-site maintenance - which would also be true from a mechanical perspective.
Title: Re: C# Aurora v0.x Suggestions
Post by: Lucifer, the Morning Star on January 03, 2019, 03:44:49 PM
Hey Steve, I was hoping for some fixes to PD in C#. Currently, and I know that this doesn't effect you as much, but PD falls off pretty hard in the late game. From some number crunching, it appears that the new missiles changes don't fix this issue either. Would it be possible to get a better PD balance in the late game to compensate for this?
Title: Re: C# Aurora v0.x Suggestions
Post by: Lucifer, the Morning Star on January 03, 2019, 03:45:38 PM
Also, from what I can recall, tracking speed bonuses against missiles currently don't function at all. Is there any news on if/when that will be fixed?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 03, 2019, 05:36:23 PM
Hey Steve, I was hoping for some fixes to PD in C#. Currently, and I know that this doesn't effect you as much, but PD falls off pretty hard in the late game. From some number crunching, it appears that the new missiles changes don't fix this issue either. Would it be possible to get a better PD balance in the late game to compensate for this?

Can you provide some numbers for how it falls off?
Title: Re: C# Aurora v0.x Suggestions
Post by: Cyborg29 on January 03, 2019, 05:38:48 PM
Hello, I would like to suggest the addition of an option to shut down individual shipyard slipways, or simply the shipyards themselves (possibly by adding new options to the industrial sector shutdown screens). 
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 03, 2019, 06:02:13 PM
Hello, I would like to suggest the addition of an option to shut down individual shipyard slipways, or simply the shipyards themselves (possibly by adding new options to the industrial sector shutdown screens).

You can shutdown shipyards in VB6 by towing them to a nearby moon. C# at the moment doesn't have the code to shut down anything. I'll look at various options when I get to this area. I've wondering if the ability to just shut down large sections of industry and then re-open them is a little too easy and there should be other options for handling a lack of workers.
Title: Re: C# Aurora v0.x Suggestions
Post by: Lucifer, the Morning Star on January 03, 2019, 06:41:43 PM
Hey Steve, I was hoping for some fixes to PD in C#. Currently, and I know that this doesn't effect you as much, but PD falls off pretty hard in the late game. From some number crunching, it appears that the new missiles changes don't fix this issue either. Would it be possible to get a better PD balance in the late game to compensate for this?

Can you provide some numbers for how it falls off?

I came prepared. More specifically, PD gets worse than AMMs. It also makes a lot of sense that the first time AMMs are better than PD is the tech level after you said generally stop playing (Magneto-Plasma).

Not sure if Image links work, but I'll try it

This assumes the "best" AMM and the "best" PD for that tech level

Without any ECCM on the AMMs: https://cdn.discordapp.com/attachments/402321466839793664/530507553273020426/unknown.png

With 0.25 MSP ECCM on the AMMs: https://cdn.discordapp.com/attachments/402321466839793664/530507750179078154/unknown.png

This tracks the maximum target speed that an AMM or PD can hit whilst still retaining a 100% hit rate.

At early levels (convential-Ion) PD dominates, with over 2x the maximum speed possible to hit than AMMs at Ion (7022.7 km/s for AMMs, 16000 km/s for PD.) At Magneto-Plasma, AMMs over double in speed, jumping to 14694.44 km/s, not far off from the PDs maximum of 20000 km/s. Since this is where you said you generally stop, it seems pretty balanced. However, If you go to the next tech level (Internal Confinement), AMMs once again double in max speed, jumping to 28518.75 km/s, as compared to PDs 25000 km/s maximum.

AMMs only continue to grow more powerful, gaining roughly 50% speed per tech level afterwards (46k, 74k, 118k, 172k, 244k) capping out at 299k km/s at Beam Core Anti-matter. PD, comparatively, gains exponential growth, but at an extremely slow rate.

 At Magnetic Confinement, PD has a max speed of 32k, then 40k, 50k, 64k, 80k, and 100k at Beam Core Anti-matter. As you can see, PD is nearly 3x as slow as AMMs at the higher techs.

 Now I know that AMMs have to deal with ammunition, but I have never found it particularly hard to keep my missile ships supplied, and even with that constraint 3x speed seems a bit ridiculous. It also doesn't help that the racial Tracking Speed Bonus vs. Missiles techs do absolutely nothing as of right now.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 03, 2019, 06:59:10 PM
The tracking speeds roughly keep pace with engine power, otherwise it would become easier to hit opposing ships with beam weapons. It seems to be that AMMs benefit from increased agility at higher TLs, more than PD is penalised. Also, missiles in general gain from the ramp up in max power mod after the early levels.

Increasing tracking speed would make it very easy to build beam-only fleets that are immune to missiles (which is already not that difficult). AMMs should become less effective anyway in C# Aurora due to the missile ECM changes, so I think I need to see how that works out in practice before looking at any agility reductions. I might also lower the RP costs for the power boosts to give early AMMs some help.

Title: Re: C# Aurora v0.x Suggestions
Post by: Lucifer, the Morning Star on January 03, 2019, 07:03:24 PM
The tracking speeds roughly keep pace with engine power, otherwise it would become easier to hit opposing ships with beam weapons. It seems to be that AMMs benefit from increased agility at higher TLs, more than PD is penalised. Also, missiles in general gain from the ramp up in max power mod after the early levels.

Increasing tracking speed would make it very easy to build beam-only fleets that are immune to missiles (which is already not that difficult). AMMs should become less effective anyway in C# Aurora due to the missile ECM changes, so I think I need to see how that works out in practice before looking at any agility reductions. I might also lower the RP costs for the power boosts to give early AMMs some help.

We've had some discussions and crunched some numbers with what we know about missiles in C#, and from what Iceranger has found it doesn't seem to impact AMMs much, if at all. I agree that increasing tracking speed as a whole would make beam fleets really good, but a buff to only PD would be very helpful. Like I've said, the tracking speed bonus vs. missiles currently doesn't do anything, so that's a big hit to non-AMM PD. Things like that, things that can only apply to PD, could make PD better as a whole.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 03, 2019, 07:07:40 PM
We've had some discussions and crunched some numbers with what we know about missiles in C#, and from what Iceranger has found it doesn't seem to impact AMMs much, if at all. I agree that increasing tracking speed as a whole would make beam fleets really good, but a buff to only PD would be very helpful. Like I've said, the tracking speed bonus vs. missiles currently doesn't do anything, so that's a big hit to non-AMM PD. Things like that, things that can only apply to PD, could make PD better as a whole.

Given that AMMs need on-board ECCM now to be fully effective against ECM-equipped missiles (which are better than in VB6), I'm not sure how it doesn't impact them.

Before I make any significant changes to point defence or tracking speeds, I need to play test. A lot has changed.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on January 03, 2019, 07:16:18 PM
I'm not sure "max speed for 100 % hit chance" is the relevant scaling condition.

It seems like what you want is more like "total HS needed to give >= 95 % chance of interdicting a missile of same tech level with 50 % of mass devoted to engines and max missile ECM." For that scaling, you also need to consider fire rate (scales for gauss PD with capacitor recharge rate, not for missile PD beyond lvl. 6 where a size 1 launcher has a 5 s cycle rate). (In principle also size of weapon and fire control, but those change very slowly if at all relative to the other parameters.)

And tracking time vs. missiles not working seems like a bug, not a feature. Assuming that's fixed, that should be a significant help to beam PD, particularly at higher tech levels. (Also, how is it supposed to work? Is the tracking bonus additive to the hit chance, or multiplicative?)

Re: ECCM not showing up in Lucy's and Iceranger's calculations: ECCM requirements for AMMs impact absolute efficiency, but because ECCM caps at 0.25 MSP, my intuition is (though I have not proven) that in optimal AMM composition ECCM + warhead package converges on 0.25 MSP in the high-tech limit, and the closer you get to that limit, the less it impacts the scaling properties. So you should be seeing the same basic progression even if the absolute numbers change.
Title: Re: C# Aurora v0.x Suggestions
Post by: Lucifer, the Morning Star on January 03, 2019, 07:22:30 PM
I'm not saying that the tests are the "best" way to prove it, but it at least puts numbers behind the claim. As a general rule, the more tech lines a weapon has, the better it is at each tech level, and since missiles have the most options it makes sense that they are more powerful as a base line. Since I don't think Steve is planning on adding modularity to non-missiles, missiles still hold the edge in that category. My point was simply that PD needs a buff. That can be as simple as fixing the tracking speed bug, but since I haven't seen a mention of it in the listed changes I felt it necessary to bring up.

Edit: I believe the tracking speed is supposed to be additive, as it's 20%, 40%, etc. Also, the missile charts with ECCM were there to show how missiles fare with the new missile update, and they still hold an overwhelming advantage. (Each missile came with 0.25 ECCM)
Title: Re: C# Aurora v0.x Suggestions
Post by: clement on January 03, 2019, 10:01:15 PM
Hello, I would like to suggest the addition of an option to shut down individual shipyard slipways, or simply the shipyards themselves (possibly by adding new options to the industrial sector shutdown screens).

You can shutdown shipyards in VB6 by towing them to a nearby moon. C# at the moment doesn't have the code to shut down anything. I'll look at various options when I get to this area. I've wondering if the ability to just shut down large sections of industry and then re-open them is a little too easy and there should be other options for handling a lack of workers.

You could allow the prioritization of industry with workers being allocated based on that list. With some minimum percentage of workers going to each industry. There will always be works at that fuel refinery but if it is lowest priority it may only get 10%, while mines, factories and ship yards are all within a few percentage points of 100% since they are at the top of the list.
Title: Re: C# Aurora v0.x Suggestions
Post by: Iceranger on January 03, 2019, 10:32:21 PM
We've had some discussions and crunched some numbers with what we know about missiles in C#, and from what Iceranger has found it doesn't seem to impact AMMs much, if at all. I agree that increasing tracking speed as a whole would make beam fleets really good, but a buff to only PD would be very helpful. Like I've said, the tracking speed bonus vs. missiles currently doesn't do anything, so that's a big hit to non-AMM PD. Things like that, things that can only apply to PD, could make PD better as a whole.

Given that AMMs need on-board ECCM now to be fully effective against ECM-equipped missiles (which are better than in VB6), I'm not sure how it doesn't impact them.

Before I make any significant changes to point defence or tracking speeds, I need to play test. A lot has changed.

Hi Steve, just want to point out that in the second table https://cdn.discordapp.com/attachments/402321466839793664/530507750179078154/unknown.png (https://cdn.discordapp.com/attachments/402321466839793664/530507750179078154/unknown.png) shown in Lucifier's post, the AMMs are assumed to have 0.25MSP dedicated to ECCM based on C# change list. Due to this, overall the AMM effectiveness is tuned down. They still have much better tracking speed than turrets at higher tech level, and it increases drastically in later tech levels.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on January 03, 2019, 10:33:51 PM
The tracking speeds roughly keep pace with engine power, otherwise it would become easier to hit opposing ships with beam weapons. It seems to be that AMMs benefit from increased agility at higher TLs, more than PD is penalised. Also, missiles in general gain from the ramp up in max power mod after the early levels.

Increasing tracking speed would make it very easy to build beam-only fleets that are immune to missiles (which is already not that difficult). AMMs should become less effective anyway in C# Aurora due to the missile ECM changes, so I think I need to see how that works out in practice before looking at any agility reductions. I might also lower the RP costs for the power boosts to give early AMMs some help.

If there is a need, perhaps it could be balanced in the other end by having sufficiently advanced PDs shrink in size per shot increasing their effective volume of fire to compensate.

Gauss cannons already have a max Rate of Fire of 6, and I'm not sure how that impacts the numbers here.

But basically make reduced size lasers more competitive ( so that high enough recharge allows fitting several of them in the same space still on a 5 second reload ) or something like that.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on January 04, 2019, 01:15:24 AM
hmm... maybe it would be wiser to re-balance just AMM's instead of beam-weapons if Steve's test-games show that it really should be rebalanced...

maybe something like this:

1) missiles are not able to intercept other missiles as they are too small and too fast to be controlled from a ship and be able to hit a moving (and maneuvering) object as small and fast as a missile

2) missiles with an extra 0.25 or 0.5 MSP (question of balancing) sensormodule (or targeting AI etc... no special tech, just a module) are able to intercept other missiles

3) the electronic in the special module does not interact well with warheads, so a AMM (aka with the special module) is not allowed to have a warhead and so has no use against ships at all

4) missiles being positive intercepted are destroyed even if the AMM does not have a warhead

...

I am no expert in Aurora but I guess this would lead to

a) less chance to hit or less range in AMM (depending on how much space the special module uses even after reducing the warhead) - I guess  this might lead to 2 different types of AMM's - a longer range "first line of defence" AMM with low accuracy and a second "final line of defence" AMM with low range and higher accuracy (stronger engine, less fuel)
(this might mean that size 2 AMM's might come up but I am ok with this as this would result in lesser (but more potent) AMM beeing launched per salvo - maybe resulting in "first line of defence" size 2 AMM and escorts and "final line of defence" size 1 AMM escorts... who knwos...)

b) no use of AMM's as offensive weapon - with also would lead to 2 different type of missiles - AMM's and special Size 1 offensive missiles

this would not reduce (likely even make it worse) the high increase of usability for AMM's with higher tech but I am OK with this as low tech AMM's really should be not really that powerful and even with high tech AMM's would be less good as now.
as they might be than unbalanced (weaker) to other PD systems I am thinking: AMM-tech does not require any (much) research for itself.. it is mostly a byproduct of missile research so I would have no problem they being weaker as PD as this would make the other weapon-techs even more worthwile as they might be in C# at the moment

...

but as I said, I am no expert in Aurora so I might be completly wrong... guess depends on Steve's inside and how his testing looks like in practice and not only the numbers on paper...
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on January 04, 2019, 01:48:56 AM
It is not the shrinking warhead size that leads to the big improvement in AMM performance. Shipkillers don't need much agility usually, but it increases counter missile performance a lot. By flattening out the AGI tech curve you can decrease performance without introducing any new concepts.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 04, 2019, 05:41:07 AM
Fixing the AMM imbalance might be acheived by removing Missile Agility entirely.  The increasing engine power at higher tech levels should keep missile hit chances versus ships reasonable, but missile v missile numbers would drop considerably.  It also has the added benefit of no longer needing an Excel sheet or Python program to calculate (efficient) new missile designs.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 04, 2019, 07:09:00 AM
Fixing the AMM imbalance might be acheived by removing Missile Agility entirely.  The increasing engine power at higher tech levels should keep missile hit chances versus ships reasonable, but missile v missile numbers would drop considerably.  It also has the added benefit of no longer needing an Excel sheet or Python program to calculate (efficient) new missile designs.

Yes, I think might be the simplest answer, plus probably making engine boost modifiers cheaper or maybe even free to improve low-level AMMs.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on January 04, 2019, 07:42:45 AM
Fixing the AMM imbalance might be acheived by removing Missile Agility entirely.  The increasing engine power at higher tech levels should keep missile hit chances versus ships reasonable, but missile v missile numbers would drop considerably.  It also has the added benefit of no longer needing an Excel sheet or Python program to calculate (efficient) new missile designs.

Yes, I think might be the simplest answer, plus probably making engine boost modifiers cheaper or maybe even free to improve low-level AMMs.
Removing it might be too drastic. It also no longer gives any options to build anti-fighter/anti-FAC missiles.
Title: Re: C# Aurora v0.x Suggestions
Post by: Iceranger on January 04, 2019, 09:14:59 AM
Fixing the AMM imbalance might be acheived by removing Missile Agility entirely.  The increasing engine power at higher tech levels should keep missile hit chances versus ships reasonable, but missile v missile numbers would drop considerably.  It also has the added benefit of no longer needing an Excel sheet or Python program to calculate (efficient) new missile designs.

Yes, I think might be the simplest answer, plus probably making engine boost modifiers cheaper or maybe even free to improve low-level AMMs.

Based on my napkin math, we should be careful about changing the AGI values.

TLDR: giving agility tech a higher starting value and a lower growth speed might be enough nerf for high tech missiles.

I experimented with some adjusted AGI tech levels. It seems to me increasing the starting value, and slow the growth down looks reasonable (at least for AMM, where warhead keeps shrinking with tech levels).
(https://cdn.discordapp.com/attachments/402321466839793664/530510438237077524/unknown.png)

They also only holds for the situation where warhead strength is kept constant (so warhead size keeps shrinking). For other types of missiles, I expect their tracking capabilities does not grow as significantly as AMMs. For example, this table shows if the warhead is kept 0.2MSP (20% of the total missile size), the growth of the tracking with the same new AGI tech values as above. It might be good enough for a light anti-ship missile, but probably not good enough for anti fighter/FAC roles.
(https://cdn.discordapp.com/attachments/402321466839793664/530765092464099328/unknown.png)

Below is a chart comparing different scenarios. I included some rule of thumb ship speed (slow = EP/HS rating x 250, fast = EP/HS rating x 500, fighter = EP/HS x 1000) for comparison.
(https://cdn.discordapp.com/attachments/402321466839793664/530774372651106324/unknown.png)
Note that with adjusted AGI values, S1 missiles with 0.25MSP ECCM and 0.2MSP warhead can barely track the fighter speed of equivalent tech. Given this is the theoretical max value, S1 might not be a good missile size for anti-fighter role any more.

Zoomed in to lower tech levels:
(https://cdn.discordapp.com/attachments/402321466839793664/530774402355167263/unknown.png)

Giving engine boost tech to missiles at lower tech levels will definitely bring their performance on par with beam weapons.

Keep in mind that the numbers shown above are theoretical max values, meaning 0 fuel, max engine boost, and maximizing tracking speed by adjusting engine/AGI ratio. Thus in both VB6 and C#, the practical values will decrease (except for rounding errors on very short ranged missiles). The decrease will be more significant in C# due to max boosted engines consume more fuel. In fact, based on the ship/missile optimizer I created based on C# formulas, max boosted engines are not the optimal choice for even very short ranged missiles. Thus in C# the practical performance will definitely be lower than these values.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 04, 2019, 10:29:44 AM
There are other factors as well. You have to build and distribute the AMMs, which is a major factor in campaigns and a downside to AMMs. On the other hand, they can engage at much longer ranges than beam weapons, so you have multiple AMMs attempts vs usually a single beam attempt, although that itself is affected by technology and design decisions re sensors, so you can't make single shot comparisons. On that basis, giving low tech AMMs extra capability beyond possibly cheaper (in research terms) engine boosts is not necessarily a good idea.

Also, with the changes in active and passive detection of fighters, reducing the ability to kill fighters with cheap missiles is probably fine.

In this situation, there are just so many competing factors, that you can't really calculate what is going to happen. You can make an educated guess (as per my gut feel that reducing or eliminating agility is probably the way to go), but it is usually easier to test and see what happens.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on January 04, 2019, 10:53:52 AM
I'm not sure how the sensor changes hurt fighters, since the small low-res fighter sensors now are much closer in range to the large high-res sensors on a large ship.
And against missile fighters, beams on large ships are not an option. I for one would like to keep the possibility of specializing the missile against fighters instead of having one capital standard missile that is getting chucked at everything that is not a missile.
Title: Re: C# Aurora v0.x Suggestions
Post by: Iceranger on January 04, 2019, 10:56:43 AM
There are other factors as well. You have to build and distribute the AMMs, which is a major factor in campaigns and a downside to AMMs. On the other hand, they can engage at much longer ranges than beam weapons, so you have multiple AMMs attempts vs usually a single beam attempt, although that itself is affected by technology and design decisions re sensors, so you can't make single shot comparisons. On that basis, giving low tech AMMs extra capability beyond possibly cheaper (in research terms) engine boosts is not necessarily a good idea.

Also, with the changes in active and passive detection of fighters, reducing the ability to kill fighters with cheap missiles is probably fine.

In this situation, there are just so many competing factors, that you can't really calculate what is going to happen. You can make an educated guess (as per my gut feel that reducing or eliminating agility is probably the way to go), but it is usually easier to test and see what happens.

Steve, as a side request, is it possible for you to share a few missile design screens from C#? Any missile would be fine, preferably with different design parameters so I can check if my missile calculator is correct/accurate.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 04, 2019, 11:10:42 AM
I'm not sure how the sensor changes hurt fighters, since the small low-res fighter sensors now are much closer in range to the large high-res sensors on a large ship.
And against missile fighters, beams on large ships are not an option. I for one would like to keep the possibility of specializing the missile against fighters instead of having one capital standard missile that is getting chucked at everything that is not a missile.

You could still have a fast missile with a small warhead vs fighters compared to slower with larger warhead vs ships (or maybe a two-stage missile with a very fast second stage). Lowering or removing agility wouldn't remove the ability to use different strategies against fighters.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 04, 2019, 11:13:31 AM
There are other factors as well. You have to build and distribute the AMMs, which is a major factor in campaigns and a downside to AMMs. On the other hand, they can engage at much longer ranges than beam weapons, so you have multiple AMMs attempts vs usually a single beam attempt, although that itself is affected by technology and design decisions re sensors, so you can't make single shot comparisons. On that basis, giving low tech AMMs extra capability beyond possibly cheaper (in research terms) engine boosts is not necessarily a good idea.

Also, with the changes in active and passive detection of fighters, reducing the ability to kill fighters with cheap missiles is probably fine.

In this situation, there are just so many competing factors, that you can't really calculate what is going to happen. You can make an educated guess (as per my gut feel that reducing or eliminating agility is probably the way to go), but it is usually easier to test and see what happens.

Steve, as a side request, is it possible for you to share a few missile design screens from C#? Any missile would be fine, preferably with different design parameters so I can check if my missile calculator is correct/accurate.

http://aurora2.pentarch.org/index.php?topic=8495.msg102804#msg102804

I highly recommend reading through the changes thread as it contains a lot of information about C#, including several different missile-related posts.
Title: Re: C# Aurora v0.x Suggestions
Post by: Iceranger on January 04, 2019, 11:33:13 AM
There are other factors as well. You have to build and distribute the AMMs, which is a major factor in campaigns and a downside to AMMs. On the other hand, they can engage at much longer ranges than beam weapons, so you have multiple AMMs attempts vs usually a single beam attempt, although that itself is affected by technology and design decisions re sensors, so you can't make single shot comparisons. On that basis, giving low tech AMMs extra capability beyond possibly cheaper (in research terms) engine boosts is not necessarily a good idea.

Also, with the changes in active and passive detection of fighters, reducing the ability to kill fighters with cheap missiles is probably fine.

In this situation, there are just so many competing factors, that you can't really calculate what is going to happen. You can make an educated guess (as per my gut feel that reducing or eliminating agility is probably the way to go), but it is usually easier to test and see what happens.

Steve, as a side request, is it possible for you to share a few missile design screens from C#? Any missile would be fine, preferably with different design parameters so I can check if my missile calculator is correct/accurate.

http://aurora2.pentarch.org/index.php?topic=8495.msg102804#msg102804

I highly recommend reading through the changes thread as it contains a lot of information about C#, including several different missile-related posts.

I have been lurking on the forum without an account for a few years, and have been following the change log closely ;)

The missile calculator I was talking about had been verified based on the 2 engine parameters in the change log. If possible, I would like to verify the whole missile parameters (speed/range/accuracy and so on), so I can make sure my understanding/interpretation of the changes is correct.

Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 04, 2019, 11:47:03 AM
The missile calculator I was talking about had been verified based on the 2 engine parameters in the change log. If possible, I would like to verify the whole missile parameters (speed/range/accuracy and so on), so I can make sure my understanding/interpretation of the changes is correct.

I am about to start my 3rd test campaign, this time with a human TN race, 2 NPRs and Precursors and Swarm active. I'll post the screenshots as I progress.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on January 04, 2019, 12:00:55 PM
I'm not sure how the sensor changes hurt fighters, since the small low-res fighter sensors now are much closer in range to the large high-res sensors on a large ship.

That's exactly how. Since the gains in range from high resolution are considerably smaller with the new sensor model compared to the old, you are very much encouraged to just build a big low-res sensor to detect both small craft and large, rather than specializing your sensor resolutions and potentially allowing fighters to get much closer because your low-res sensor is secondary.

However, this is primarily an academic consideration, since I doubt NPRs are going to design that way.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 04, 2019, 12:18:26 PM
I'm not sure how the sensor changes hurt fighters, since the small low-res fighter sensors now are much closer in range to the large high-res sensors on a large ship.

For active sensors, you can detect fighters at a greater distance with a resolution 5 sensor than you could before for sensors sizes less than 8 HS. The advantages are much larger for small sensors, so now it is worth having fighter-detection on much smaller ships, including small picket ships that the fighters may not even detect on approach because their own sensors need to be high resolution to try to maintain distance.

Equally, passive sensors are MUCH more effective against small thermal contacts, and the increase is huge for small passive sensors, which makes it easier to detect fighters on passive.

http://aurora2.pentarch.org/index.php?topic=8495.msg102701#msg102701
http://aurora2.pentarch.org/index.php?topic=8495.msg103085#msg103085
Title: Re: C# Aurora v0.x Suggestions
Post by: Lucifer, the Morning Star on January 04, 2019, 12:40:08 PM
Hey Steve, coming w/ another bug. I love the Fleet Organization screen, but it has a tendency to just disappear whole Task Forces. I've had 28 ships and 300 fighters all vanish from me trying to organize ships. I've found it to happen most often when working with carriers/nested ships. Most commonly when organizing fighters inside of a carrier into different groups while a carrier is in another group. Is it possible to get that fixed?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 04, 2019, 12:43:50 PM
Hey Steve, coming w/ another bug. I love the Fleet Organization screen, but it has a tendency to just disappear whole Task Forces. I've had 28 ships and 300 fighters all vanish from me trying to organize ships. I've found it to happen most often when working with carriers/nested ships. Most commonly when organizing fighters inside of a carrier into different groups while a carrier is in another group. Is it possible to get that fixed?

Fleet Organization is completely different now so any bugs should have vanished. It is all explained in the changes log.
Title: Re: C# Aurora v0.x Suggestions
Post by: Lucifer, the Morning Star on January 04, 2019, 12:49:56 PM
Hey Steve, coming w/ another bug. I love the Fleet Organization screen, but it has a tendency to just disappear whole Task Forces. I've had 28 ships and 300 fighters all vanish from me trying to organize ships. I've found it to happen most often when working with carriers/nested ships. Most commonly when organizing fighters inside of a carrier into different groups while a carrier is in another group. Is it possible to get that fixed?

Fleet Organization is completely different now so any bugs should have vanished. It is all explained in the changes log.

Have you tested it w/ fighters yet? I.e. if I have ships docked inside another ship, and I put the nested ships in a group that the mothership isn't in, and, say, detach the subfleet with the nested ships, what happens? In VB6 it tends to just delete everything.
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on January 04, 2019, 12:54:22 PM
Have you tested it w/ fighters yet? I.e. if I have ships docked inside another ship, and I put the nested ships in a group that the mothership isn't in, and, say, detach the subfleet with the nested ships, what happens? In VB6 it tends to just delete everything.

It is highly unlikely that the exact same bug would appear in a completely new and different piece of code.
Title: Re: C# Aurora v0.x Suggestions
Post by: Lucifer, the Morning Star on January 04, 2019, 01:01:28 PM
Have you tested it w/ fighters yet? I.e. if I have ships docked inside another ship, and I put the nested ships in a group that the mothership isn't in, and, say, detach the subfleet with the nested ships, what happens? In VB6 it tends to just delete everything.

It is highly unlikely that the exact same bug would appear in a completely new and different piece of code.

Not saying the same bug, just asking if he's tested that in case of a different bug. It seems like something that could break.
Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on January 05, 2019, 03:56:36 AM
Well, there are some 'bugs' which hopefully will make quite an impactful appearance, despite being new code. :p
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 05, 2019, 04:00:19 AM
One thing that I would like to have in C# which I hope would not be too difficult or time consuming for you to add would be the possibility to transfer captured or transferred rescued crew from one ship to another in space.

You might send out a small rescue shuttle to pick up some survivors from a ship and then you want to get back to the carrier and drop them of to go and get some other people to rescue. Or you want to transfer people from your carrier to a hospital ship you keep with you logistical tail or you meet up with a small rescue ship to transfer them there and go to the nearest populated planet.

In C# you also can have commercial hangars so a rescue ship can now keep their own rescue shuttles to go and pick up crew, but you would like to transfer the people to the hospital ship itself after you picked them up. You don't really want to put the ship itself in harms way. I could see a proper hospital ship using both cryo and luxury facilities to represent the medical facilities you might need for fleets on long journeys in space.

In VB6 it is sometimes a bit rigid (and a problem) that you can't move people around once you picked them up on a ship.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on January 06, 2019, 02:44:25 AM
Suggestion based on the new screenshots for your new test-game Steve:

on the "Class Design Screen" (and all screens like it) : new order of the check-boxes on the right side (collier, tanker, obsolete etc) to

sorted by function (Collier, Supply Ship, Tanker etc) - 1 row space - sorted by feature (consript, no armor etc) - 1 row space - sorted by display (Obsolute, Size in tonns etc)

that would make it a small QoL improvement as it would be easier to see if something is not checked which should be checked...
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 06, 2019, 06:57:44 AM
Suggestion based on the new screenshots for your new test-game Steve:

on the "Class Design Screen" (and all screens like it) : new order of the check-boxes on the right side (collier, tanker, obsolete etc) to

sorted by function (Collier, Supply Ship, Tanker etc) - 1 row space - sorted by feature (consript, no armor etc) - 1 row space - sorted by display (Obsolute, Size in tonns etc)

that would make it a small QoL improvement as it would be easier to see if something is not checked which should be checked...

Yes, good idea. Changed as suggested.

(http://www.pentarch.org/steve/Screenshots/ClassDisplay001.PNG)
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on January 06, 2019, 09:37:27 AM
If possible, I'd like a way to remove ship hull classes. There was a natural bloat in VB Aurora from campaigns, both yours, Steve, and every individual player's, over time, and I found it to get slowly annoying if I would change ship classification scheme or abbreviation method from one campaign to the next to have it all cluttered up. Even worse, if I typoed the addition of a hull class, that mistake would haunt me in perpetuity - at least until I downloaded a fresh database.

I understand that at least part of the reason why we couldn't before was because NPRs need certain classes to function and you didn't want to deal with people deleting them and then complaining their games didn't work. That's completely understandable, and if it's still the case, could we at least get the ability to hide selected hull classification types from the player so they don't show up in the ship building menu?

Thanks.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 06, 2019, 04:12:44 PM
If possible, I'd like a way to remove ship hull classes. There was a natural bloat in VB Aurora from campaigns, both yours, Steve, and every individual player's, over time, and I found it to get slowly annoying if I would change ship classification scheme or abbreviation method from one campaign to the next to have it all cluttered up. Even worse, if I typoed the addition of a hull class, that mistake would haunt me in perpetuity - at least until I downloaded a fresh database.

I understand that at least part of the reason why we couldn't before was because NPRs need certain classes to function and you didn't want to deal with people deleting them and then complaining their games didn't work. That's completely understandable, and if it's still the case, could we at least get the ability to hide selected hull classification types from the player so they don't show up in the ship building menu?

Thanks.

Oh, yes please.  Plus one!  etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on January 06, 2019, 05:47:02 PM
If possible, I'd like a way to remove ship hull classes. There was a natural bloat in VB Aurora from campaigns, both yours, Steve, and every individual player's, over time, and I found it to get slowly annoying if I would change ship classification scheme or abbreviation method from one campaign to the next to have it all cluttered up. Even worse, if I typoed the addition of a hull class, that mistake would haunt me in perpetuity - at least until I downloaded a fresh database.

I understand that at least part of the reason why we couldn't before was because NPRs need certain classes to function and you didn't want to deal with people deleting them and then complaining their games didn't work. That's completely understandable, and if it's still the case, could we at least get the ability to hide selected hull classification types from the player so they don't show up in the ship building menu?

Thanks.

Yes yes yes yes yes please XD
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 06, 2019, 06:00:06 PM
Yes, the hull types have grown over time :)

When I get around to it, I'll add a specific window for managing them.
Title: Re: C# Aurora v0.x Suggestions
Post by: DEEPenergy on January 08, 2019, 11:46:29 AM
This is more a suggestion for a later release date, but could there be the option to put space stations and ships into orbit around a star or planet so they revolve around it?
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 08, 2019, 12:51:29 PM
This is more a suggestion for a later release date, but could there be the option to put space stations and ships into orbit around a star or planet so they revolve around it?

VB6 Aurora has this.  It unfortunately doesn't get used much as orbiting at even 1 km means no loading, unloading, refueling, etc. is allowed.  Ships still run up their maintenance clocks and crew deployment time.

Hopefully C# Aurora will implement all these functions for orbits at a reasonable distance (perhaps determined by the body's gravity) as well as for 'Move to' commands.
Title: Re: C# Aurora v0.x Suggestions
Post by: zatomic on January 09, 2019, 04:17:07 PM
An option to 'Create Home System' would be easy, as the NPRs already have that function. Yes, there are a number of fixed starting systems in VB6 for NPRs created at game start. That doesn't exist in C# - everything is created from scratch. It only take a second or two to generate and discard all the unsuitable systems until a suitable home system is generated. Every NPR starting system is unique.

A possibly simple addition to a 'Create Home System' function would be to allow the player to set some criteria and then generate and discard systems until one that meets the criteria is found. Possible simple criteria might be:


This way, if wanting to do something like a multi-faction multi-planet start in a large complex system, you could easily generate systems with the desired number of homeworlds and some larger minimums to ensure a big complex system. An option to abort in case the criteria are too strict and it just keeps running without a match would be good, or even an auto-fail after some (large, I assume it will go pretty fast) number of tries.

More complex criteria would be like min. potential homeworlds around a single gas giant, min. stars w/ at least 1 homeworld orbiting (to create a binary system with a homeworld around each component), or optional tighter homeworld criteria (like for a particular species if you want multiple homeworlds for human factions, not just good enough to generate a species that matches the homeworld). I'm sure I and others could think of many criteria, but even a fairly basic set would be useful.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 09, 2019, 05:23:15 PM
An option to 'Create Home System' would be easy, as the NPRs already have that function. Yes, there are a number of fixed starting systems in VB6 for NPRs created at game start. That doesn't exist in C# - everything is created from scratch. It only take a second or two to generate and discard all the unsuitable systems until a suitable home system is generated. Every NPR starting system is unique.

A possibly simple addition to a 'Create Home System' function would be to allow the player to set some criteria and then generate and discard systems until one that meets the criteria is found. Possible simple criteria might be:

  • Min/Max stars
  • Min/Max planets
  • Min/Max moons
  • Min/Max asteroids
  • Min/Max asteroid belts
  • Min potential homeworlds (acceptable gravity and base temperature; atmospheric adjustments can be made by the player)
  • Min/Max distance to furthest system body

This way, if wanting to do something like a multi-faction multi-planet start in a large complex system, you could easily generate systems with the desired number of homeworlds and some larger minimums to ensure a big complex system. An option to abort in case the criteria are too strict and it just keeps running without a match would be good, or even an auto-fail after some (large, I assume it will go pretty fast) number of tries.

More complex criteria would be like min. potential homeworlds around a single gas giant, min. stars w/ at least 1 homeworld orbiting (to create a binary system with a homeworld around each component), or optional tighter homeworld criteria (like for a particular species if you want multiple homeworlds for human factions, not just good enough to generate a species that matches the homeworld). I'm sure I and others could think of many criteria, but even a fairly basic set would be useful.

it isn't easy to do what you suggest. The system generation uses a lot of science to create 'realistic' systems, including separation of planets, limits to where they can form, types of worlds likely at certain distance, etc. so you can't simply choose how many home worlds you want for example. These are an early form of the rules I use for Aurora's system generation (I can't find the latest version online anywhere). It took about a year to code this for the VB6 version (a lot faster in C#).

http://sol.trisen.com/downloads/wg.pdf
Title: Re: C# Aurora v0.x Suggestions
Post by: zatomic on January 09, 2019, 09:16:46 PM
My apologies, I may not have been clear. The idea is that it would generate a random system precisely as it does now, and then simply compare it to the criteria. If it matches, it's done. If it doesn't match, it throws it out and tries again. If I understand what you've said previously, that's how it works now to create NPR homeworlds. Since C# is so much faster, it can just keep generating and tossing systems till it gets one with a suitable body to use as a homeworld. I'm just proposing additional criteria the player can set.

Obviously, if I tell it I want exactly 576 asteroids and 17 habitable planets, it will probably run forever (hence the need for an abort or to auto fail after, say, 1000 tries or 1 minute or something). But if I tell it I want a binary system with at least 200 asteroids and at least 2 habitable planets, it will likely find one (eventually). It just automates the process of clicking 'generate system' and then looking to see if it meets your needs, then either deleting and trying again, or keeping it. (at least the needs that are easily definable and check-able by the computer).
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on January 09, 2019, 09:34:10 PM
it isn't easy to do what you suggest. The system generation uses a lot of science to create 'realistic' systems, including separation of planets, limits to where they can form, types of worlds likely at certain distance, etc. so you can't simply choose how many home worlds you want for example. These are an early form of the rules I use for Aurora's system generation (I can't find the latest version online anywhere). It took about a year to code this for the VB6 version (a lot faster in C#).

http://sol.trisen.com/downloads/wg.pdf

So your saying that when I get a garbage star system, I can blame reality instead of you?

Either way, impressive. I knew Aurora used some pretty hard logic to gen the systems, but I didn't realize you based it off something this thorough.
Title: Re: C# Aurora v0.x Suggestions
Post by: rhiwaow on January 10, 2019, 12:01:25 AM
some things i've been sorely missing in 7.  10: when designing tech, you can have a random (or custom) company name prefix to the tech, and also the tech name is autogenerated (even when changing specs, it gets re-generated)
what i'd love to have is
a) a selection of previous company names used with this tech, ideally with a little bit of customizable information like civilian/security/military grade hardware company
b) when i modified the name, i'd prefer aurora to keep the name even if i modify the specs afterwards; maybe an additional button "autogenerate" which gets enabled/disabled by the same flag storing the "customized name" state could be added for that
c) for autogenerating names, i'd love to be able to modify the naming convention; for example, i didn't much care for the power need on energy weapons, but the recharge time instead. 
d) when designing ships (and at many other places relevant to combat), the component names column was too small, and the relevant information wasn't visible (especially when it came to fire controls and sensors, it got tricky to distinguish between the point defense systems and the anti-ship/long range systems produced by the same company); edit: maybe add a tooltip with the full name?

apologies if i missed some/all of these changes already having been discussed, or even better implemented.   there's been so many beautiful changes for c# version, i might have missed them :)
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on January 10, 2019, 04:20:33 AM
Would it be possible to see some kind of "projection" as to how much minerals (in production and maintenance) and fuel demand a certain size of fleet does have (other than manually calculating them in an excel sheet for myself)? Would be nice to have a dialog in Aurora where I can insert the planned size of a fleet or army and I can see how much the total production cost & time would be, as well as the maintenance for that over a certain time periode. For fleets it would also be interesting to see how much fuel such fleet would need if it would be driving around permanently (to see how long it would take until one runs out of fuel).
Title: Re: C# Aurora v0.x Suggestions
Post by: tobijon on January 10, 2019, 06:35:59 AM

it isn't easy to do what you suggest. The system generation uses a lot of science to create 'realistic' systems, including separation of planets, limits to where they can form, types of worlds likely at certain distance, etc. so you can't simply choose how many home worlds you want for example. These are an early form of the rules I use for Aurora's system generation (I can't find the latest version online anywhere). It took about a year to code this for the VB6 version (a lot faster in C#).

http://sol.trisen.com/downloads/wg.pdf

wow, that is such an awesome document, thank you
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 10, 2019, 06:40:53 AM
http://sol.trisen.com/downloads/wg.pdf

wow, that is such an awesome document, thank you

No problem. It has been invaluable for me and I still have the copy of the updated version that I printed out about 20 years ago. I have shared it before but it deserves as wide an audience as possible.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on January 10, 2019, 07:11:03 AM
b) when i modified the name, i'd prefer aurora to keep the name even if i modify the specs afterwards; maybe an additional button "autogenerate" which gets enabled/disabled by the same flag storing the "customized name" state could be added for that
c) for autogenerating names, i'd love to be able to modify the naming convention; for example, i didn't much care for the power need on energy weapons, but the recharge time instead.
d) when designing ships (and at many other places relevant to combat), the component names column was too small, and the relevant information wasn't visible (especially when it came to fire controls and sensors, it got tricky to distinguish between the point defense systems and the anti-ship/long range systems produced by the same company)
^ This, so much this.

I'd kill for formatting tokens that can be used in the name which pull details from the design specifications, both selected tech and calculated results.

Given the quantity of useful information, perhaps enumerate alphabetically with a-z as tokens or the actual variable names wrapped in angle brackets(<var_name>)?  Something of the sort. Anyways, I'll assume a-z tokens for now.

Then, for engines, perhaps something like what I buried in the OT tag for brevity.
Off-Topic: show
token   variable
a   Engine Technology
b   Power/Efficiency Modifier
c   Fuel Consumption Technology
d   Fuel Use Per Hour
#e   Fuel Use Per Hour - Rounded
f   Fuel Consumption per Engine Power Hour
#g   Fuel Consumption per Engine Power Hour - Rounded
h   Thermal Reduction Technology
i   Thermal Signature
#j   Thermal Signature - rounded
k   Engine Size (HS)
#l   Engine Size (HS) - Padded
m   Engine Size (tons)
#n   Engine Size (tons) - Padded
o   EP
#p   EP - Rounded
q   Engine Technology

Possibly using % as the token identifier?  %% to escape and get a % in the name.  Rounding tokens taking an integer as total digits precision from left most digit.  Padded tokens taking an integer for inserting leading zeroes if necessary to keep them that many digits so they both text align and sort correctly.

Assuming the following tech input for an engine, Magnetic Confinement Fusion, 1.15 Power/Efficiency, 0.3 Fuel Consumption, 0.35 Thermal reduction, 19 hull size.
I could then enter a name such as:
HS:%k P:%b F:%c T:h EP:%o
and I'd get something like :
HS:19 P:1.15 F:0.3 T:0.35 EP:546.25
or

Assuming the following tech input for an engine, Magnetic Confinement Fusion, 0.85 Power/Efficiency, 0.3 Fuel Consumption, 0.35 Thermal reduction, 7 hull size.
I could then enter a name such as:
Vega Mk2 %#2lHS %3eFPH %2pEP Engine
to get:
Vega Mk2 07HS 27.6FPH 150EP Engine
where un-rounded, FPH is 27.64, and EP is 148.75


Or the aforementioned energy weapons, say, laser:
Off-Topic: show
token   variable
a   Focal Size
b   Focal Size - Final
c   Wavelength
d   Capacitor Recharge Rate
e   Reduced Size
f   Energy Weapon Mount
g   Damage Output
h   Rate of Fire
i   Rate of Fire - 5s Increments
j   Range Modifier
k   Max Range
l   Max Range - 10k km
m   Max Range - Practical
n   Max Range - Practical - 10k km
o   Effective Range
#p   Effective Range - 10k km
q   Size (HS)
r   Size (Tons)
s   Power Requirement
t   Power Recharge

Where the practical range is the game restricted maximum range rather than the weapon range, end effective range takes an integer specifying damage to yield range for.

then, assuming the following tech input:
40cm, X-ray, Capacitor 8, Reduced Size 0.75, Spinal
and a name such as the default is:
%bcm C%u %c Laser
or:
50cm C2 X-Ray Laser

alternatively, this name might be used:
%bcm Laser (Spinal %a) ROF-%j D64-16-4=%20p-%10p-%5p k km %rt

50cm Laser (Spinal 40) ROF-32 D64-16-4=7-28-112 k km 600t

Indicating that its a 40cm focal size, uprated to 50cm via spinal, takes 32 increments to recharge, and puts out 64 damage to 70,000km, 16 damage to 280,000km, and 4 damage to 1,120,000km, and masses 600t.

15cm, X-ray, Capacitor 12, Reduced Size 1.0
%bcm Laser ROF-%j D64-16-4=%64p-%16p-%4p k km

15cm Laser ROF-2 D64-16-4=0-2-10 k km


The obvious insertion of flavour is as simple as its ever been under this system, just place raw text as you see fit, and use as few or many tokens as desired.

If we had that, naming schemes other than stock which involve one or more criteria from the design become painless to utilise, rather than an effort to remain consistent with theme/past designs due to having to manually edit the name for every design you ever make, patterned or not.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 10, 2019, 08:48:33 PM
. . .  If we had that, naming schemes other than stock which involve one or more criteria from the design become painless to utilise, rather than an effort to remain consistent with theme/past designs due to having to manually edit the name for every design you ever make, patterned or not.

I would love such a system, though I would note that this is pretty much exactly what I do now, only manually.  Either by including actual summary code (Sz3, Cap3, etc.) or 'tags' corresponding to certain qualities (such as Muzzle Loading, Breech Loading, or Quick-Firing for a general indication of RoF).
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on January 11, 2019, 04:34:23 AM
Will planetary sensor stations still be available in C#? If so, I would suggest to remove them. Having a building that essentially can give you "unlimited" passive sensor range goes contrary to the reduced ranges of the new sensor model, I think.

If I recall correctly, they are needed for an empire to be able to contact other races. I once created two races on one planet without having sensors buildings - and they couldn't see each other - so no communication. Maybe then repurposing this building into a "central radio antenna system". You have to have it once in a system to be able to communicate.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on January 11, 2019, 04:54:57 AM
Will planetary sensor stations still be available in C#? If so, I would suggest to remove them. Having a building that essentially can give you "unlimited" passive sensor range goes contrary to the reduced ranges of the new sensor model, I think.

If I recall correctly, they are needed for an empire to be able to contact other races. I once created two races on one planet without having sensors buildings - and they couldn't see each other - so no communication. Maybe then repurposing this building into a "central radio antenna system". You have to have it once in a system to be able to communicate.

The new sensor formula reduces the benefits of creating large numbers of deep space tracking stations a lot ... so I guess it is just uneconomical to build them in such numbers that they give "unlimited sensor range" http://aurora2.pentarch.org/index.php?topic=8495.msg103085#msg103085
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on January 11, 2019, 06:27:06 AM
Two ideas for the "Game Start Options":

a) Invert "No Maintenance Required". All other options are formulated in the positive - only this one isn't. For logical consistency I suggest to turn it around, and mark is by default: "Maintenance Required" at the start of a new game.

b) Add "(in Years)" after "Truth Countdown". So you know what time increment is meant here.

And one for the "Economics"-Screen:
Show also Population Limit for "Size of Planet" next to "Supported by Infrastructure"
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on January 11, 2019, 11:54:52 AM
About the new "Genetically Enhanced Soldiers" I would suggest that they can only be chosen when a Genetic Modification Center is also on the planet/body.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on January 11, 2019, 02:01:58 PM
About the new "Genetically Enhanced Soldiers" I would suggest that they can only be chosen when a Genetic Modification Center is also on the planet/body.
That seems unnecessary. The GMC is for mass conversion of entire civilian populations. A facility for small scale enhancements on a few thousand soldiers should be possible to fit within a GFTF.

Something else to consider is allowing players to apply subspecies mods to their ground forces, and have colony cost modify their HP (or supply/maintenance consumption). That way you could play gene tweaking as being pioneered in order to harden soldiers against extreme cold or low gravity operational environments, and then rolled out for general civilian deployment in colonist communities.
Title: Re: C# Aurora v0.x Suggestions
Post by: TCD on January 11, 2019, 03:17:49 PM
Something else to consider is allowing players to apply subspecies mods to their ground forces, and have colony cost modify their HP (or supply/maintenance consumption). That way you could play gene tweaking as being pioneered in order to harden soldiers against extreme cold or low gravity operational environments, and then rolled out for general civilian deployment in colonist communities.
While the extra possibilities of that are appealing, at the same time I'd worry about the extra complexity. I mean ground combat is already getting a lot more complicated, it would be easy to get carried away and go too far.

If you wanted to add more genetics/biology options then I'd prefer to see something else. How about "advanced medicine" research that reduced the chance of serious illness/death events for leaders?

Or even biological warfare? W40k is full of viral bombing of planets. Hard to get the balance right. Perhaps a weapon that kills a % of the population but that had be deployed on the ground as a unit weapon rather than from a missile? Then you'd need to at least force a landing, rather than just nuke from space. I'd assume the % starts small and then increases for each extra research level.

The follow up questions would be whether soldiers are also killed, or do we assume them to have sealed battle suits anyway? And would you also create a tech line to reduce the impact? Maybe a "Viral containment unit" vehicle component so that we can have unmarked trucks full of haz-mat suited scientists and soldiers "cleaning up" infected areas.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 11, 2019, 03:30:12 PM
Something else to consider is allowing players to apply subspecies mods to their ground forces, and have colony cost modify their HP (or supply/maintenance consumption). That way you could play gene tweaking as being pioneered in order to harden soldiers against extreme cold or low gravity operational environments, and then rolled out for general civilian deployment in colonist communities.
While the extra possibilities of that are appealing, at the same time I'd worry about the extra complexity. I mean ground combat is already getting a lot more complicated, it would be easy to get carried away and go too far.

If you wanted to add more genetics/biology options then I'd prefer to see something else. How about "advanced medicine" research that reduced the chance of serious illness/death events for leaders?

Or even biological warfare? W40k is full of viral bombing of planets. Hard to get the balance right. Perhaps a weapon that kills a % of the population but that had be deployed on the ground as a unit weapon rather than from a missile? Then you'd need to at least force a landing, rather than just nuke from space. I'd assume the % starts small and then increases for each extra research level.

The follow up questions would be whether soldiers are also killed, or do we assume them to have sealed battle suits anyway? And would you also create a tech line to reduce the impact? Maybe a "Viral containment unit" vehicle component so that we can have unmarked trucks full of haz-mat suited scientists and soldiers "cleaning up" infected areas.

I've been considering biological/chemical warfare for a long time and I will add it as an option at some point, including suitable installations, ship modules, etc.. The agent would have incubation, infection and mortality rates that would vary by species and could alter (or jump species) through mutation. You would need living examples of species for the best understanding and/or effectiveness. I would track infection on population, ships, etc. as there might be infections that are not immediately apparent.
Title: Re: C# Aurora v0.x Suggestions
Post by: Panopticon on January 11, 2019, 03:42:55 PM
I like the idea of targeted biological weapons, perhaps a basic line of research like Bio-Weapon Efficiency 10/20/30 or whatever that sets the default mortality rate of a bio-weapon, then targeted weapons for a race unlock once you have access to a population or a few hundred captured prisoners, allowing for biological warheads to be developed for that race, heck maybe even be deployed by espionage teams?

Perhaps a defensive tech line too that reduces bio-weapon efficiency and allows for targeted vaccines to be produced once the population becomes aware of a virus' existence.

For extra fun(in the Dwarf Fortress meaning of the word) you can have a very small chance of a virus escaping your labs and maybe even mutating once you start researching on it and then it be something you have to deal with on your own, though I imagine the chance of that would have to be very low to make the tech tree worth the risk.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on January 11, 2019, 06:26:24 PM
I've been considering biological/chemical warfare for a long time and I will add it as an option at some point, including suitable installations, ship modules, etc.. The agent would have incubation, infection and mortality rates that would vary by species and could alter (or jump species) through mutation. You would need living examples of species for the best understanding and/or effectiveness. I would track infection on population, ships, etc. as there might be infections that are not immediately apparent.

Well, chemical warfare is already a thing (just put some terraformers in orbit and have them dump some decidedly unsafe substance in the atmosphere), and there's quite frankly nothing that a more aimed chemical weapon deployment can't do that can't be done just by shoving more missiles in orbital bombardment roles at it. Nukes are pretty good at hitting soft targets. The only exceptions to that would be highly specific targets with minimal collateral damage or targets where taking a nuke in is implausible but sufficient poison gas can be sourced locally, which are all ground combat tasks anyway.

Biological warfare would work pretty well with a biosphere implementation. Although plagues directed at the local sophont population is the most obvious, modern societies are actually pretty good at handling pandemics, so planets not subject to unrest should be rather resistant to a plague strike, especially after the first wave of symptomatic patients enter the hospitals. A pathogen aimed at a chunk of the biosphere or a crop blight strike though? It can cause almost as many casualties through famine, just few directly. And much, much harder to detect and thus counter in time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on January 11, 2019, 07:42:17 PM
Probably something for C# 2.0 as it would certainly require new buildings and modules, plus balancing it and finding a niche for chem/bio warfare can be tricky.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 11, 2019, 10:56:18 PM
The problem with Chemical & Biological warfare is that it starts creeping back into "kill 'em all and move in tomorrow" territory.  I think the assumption about B&C is that it kills enemy populations & ground units, but does not harm installations.  In that case, it needs sufficient downside (perhaps in the chance of rendering the entire planet uninhabitable, or covered in "grey goo," or creating Resident Evil-style enhanced monsters).
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on January 12, 2019, 01:28:40 AM
I'd exclude both chemical and biological weapons from scope, though for different reasons.

Chemical weapons are mainly terror weapons, and the political simulation isn't really sophisticated enough to handle terror tactics. They do have some situational tactical use, but only on the same level as things like land mines and cluster bombs, and Aurora does not model weapons design doctrine on that level of detail even in the new ground combat model.

Biological weapons, by contrast, fall off the other end of the scope range - like Father Tim said, they get into colony drop territory. While it's reasonable to think people would develop and use them, it's also reasonable to think people would accelerate large asteroids to the kind of speeds usually associated with mass extinction events and throw them at populated planets. Aurora doesn't model that either, and for much the same reason.

Then there is the question of how the game portrays atrocities in general While glassing a planet from orbit is certainly an atrocity, most of Aurora's audience will be culturally conditioned to not really regard terror bombing by air or naval (and by extension orbital) forces as a war crime. All the more mundane horrors of warfare - artificial famines, mass displacement of the population, pogroms, mistreatment of prisoners, insurgency and counterinsurgency tactics, etc. - are not modeled in Aurora, even though many of them are directly strategically relevant at the scale the simulation takes place at. To the extent that this is a deliberate design decision, biological weapons strike me as off the tone Aurora seems to be aiming for.

As cool as it admittedly would be to have one of your xenoarcheology teams find a crashed ship full of eggs and bring some back for the Company's bioweapons division, I think that works better as a ruins event that eats part of your archaeological expedition than it would as a full game feature.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on January 12, 2019, 03:32:01 PM
And those are really good points too. Chemical weapons are already a mostly obsolete - from military POV - because protection from most of them is easy for an advanced military. The only exception being the advanced nerve agents that require full body protective suits. In Aurora, even such agents would be harmless as the ground units are capable of operating in hard vacuum and toxic atmospheres. Thus it would remain as a method of civilian control by internal security forces, the way it's mostly used today. Unless you want to invent TN-chemicals that eat through power armour while being moved by air currents, and that's not something that is really useful in C#, because large scale use of really dangerous chemical agents has been to deny enemy the use of certain area, for example to isolate a breakthrough zone from reinforcements. And that doesn't matter since C# doesn't model ground terrain control between opposing forces. Tear gas ability could give a ground unit increased Suppression value for pacifying populations, but that's about it IMHO.

Since Aurora doesn't really model food production, that aspect of biological weapons would be useless, leaving us with plagues as a way to terror a population. A weapon that you can launch from a distance that reduces production efficiency, increases unrest and halts population growth temporarily is an interesting option, especially if Steve introduces counter-methods in the form of increased/improved public health facilities, BG tech that improves immune systems of the population and other such things.

Neither one should be a one-button "get rid of enemy units and populations while leaving installations intact" option.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on January 12, 2019, 05:29:42 PM
Actually, there's a number of chemical agents that could work against power armour, most of them extremely high strength oxidizers like FOOF (dioxygen difluoride) and ClF3 (chlorine trifluoride). These substances are intensely aggressive, react with everything including things you'd swear can't burn and often leave large clouds of toxic waste products, like chlorine and fluorine gas.

Any even vaguely sensible munitions or chemical safety expert will tell you only a madman would try and carry these things around rather than produce them in situ from much more controllable substances.
Title: Re: C# Aurora v0.x Suggestions
Post by: Seolferwulf on January 12, 2019, 07:58:07 PM
CIF3 missile warheads sound like fun, melting the opponents crew members if it punches through the hull.
Maybe something to support boarding attempts?
Title: Re: C# Aurora v0.x Suggestions
Post by: drejr on January 13, 2019, 01:06:25 AM
Just because something is dangerous doesn't mean it's a good weapon.

On the subject of biologicals, please don't give the Swarm acid spit or bone guns.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 13, 2019, 04:32:46 AM
How about two data-entry boxes on the New Game Settings window, where we can specify the name we want Aurora to use for Safe Greenhouse Gas, and Anti-Greenhouse Gas.  That way everybody can be happy wth their latin, greek, pseudo-latin, or even proto-Indus names.

(I intend to name mine after a couple of my scientists.)
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on January 13, 2019, 04:33:16 AM
CIF3 missile warheads sound like fun, melting the opponents crew members if it punches through the hull.
Maybe something to support boarding attempts?

The USA once spilled a ton or so of ClF3 while loading it for transport.

It ate the storage tank.

It ate the 1 foot thick concrete floor.

It ate the 1 foot thick layer of gravel beneath the 1 foot thick concrete floor.

It ate another 3 feet or so of dirt beneath the 1 foot thick layer of gravel below the 1 foot thick concrete floor.

The problem with ClF3 is that it's so aggressive that the only thing it won't react with is the fluorine salts of some of the structural metals, like copper and iron. You can make a layer of such salts by carefully exposing the metal to ClF3 fumes, which lets you transport it, but it comes with the disadvantage that if it's scratched off while in contact with ClF3? That's not a careful exposure, it will react, violently, and cause it to melt, exposing more of the metal as the metal-fluorine fire continues and containment failure is certain and imminent.

And having that happen in your ship might actually be more dangerous than a magazine explosion.
Title: Re: C# Aurora v0.x Suggestions
Post by: space dwarf on January 13, 2019, 06:20:32 AM
On the subject of biologicals, please don't give the Swarm acid spit or bone guns.

Oh, this for sure. Its been done so many times that I hope it's not the "new weapons" Steve was talking about
Title: Re: C# Aurora v0.x Suggestions
Post by: Tree on January 13, 2019, 07:39:57 AM
Didn't Steve said the new Swarm would take inspiration from the Tyranids? They definitely use the first, not sure about the second.
Title: Re: C# Aurora v0.x Suggestions
Post by: Seolferwulf on January 13, 2019, 08:41:27 AM
CIF3 missile warheads sound like fun, melting the opponents crew members if it punches through the hull.
Maybe something to support boarding attempts?

The USA once spilled a ton or so of ClF3 while loading it for transport.

It ate the storage tank.

It ate the 1 foot thick concrete floor.

It ate the 1 foot thick layer of gravel beneath the 1 foot thick concrete floor.

It ate another 3 feet or so of dirt beneath the 1 foot thick layer of gravel below the 1 foot thick concrete floor.

The problem with ClF3 is that it's so aggressive that the only thing it won't react with is the fluorine salts of some of the structural metals, like copper and iron. You can make a layer of such salts by carefully exposing the metal to ClF3 fumes, which lets you transport it, but it comes with the disadvantage that if it's scratched off while in contact with ClF3? That's not a careful exposure, it will react, violently, and cause it to melt, exposing more of the metal as the metal-fluorine fire continues and containment failure is certain and imminent.

And having that happen in your ship might actually be more dangerous than a magazine explosion.

I'm not a chemist but wouldn't it be possible to split it into less dangerous components and store them separately?
Just add a mechanism to the warhead to mix the components on impact.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 13, 2019, 09:06:32 AM
re Swarm

There is an element of acid to one of their weapons, although there is a defence against it, and the use of it ties in with another tactic.
Title: Re: C# Aurora v0.x Suggestions
Post by: tobijon on January 13, 2019, 11:40:28 AM

I'm not a chemist but wouldn't it be possible to split it into less dangerous components and store them separately?
Just add a mechanism to the warhead to mix the components on impact.

I'm a chemist and its components (Cl2 and F2) are also dangerous (though not as much). Additionally, the reaction to create it is likely too slow for an actual bomb, it requires heating the gasses to a high temperature for a long time and as such an impact would only produce a small amount in the time it takes for it too cool down, not to mention the gasses escaping away immediately after impact
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on January 13, 2019, 12:20:32 PM
I'm not a chemist but wouldn't it be possible to split it into less dangerous components and store them separately?
Just add a mechanism to the warhead to mix the components on impact.

I'm a chemist and its components (Cl2 and F2) are also dangerous (though not as much). Additionally, the reaction to create it is likely too slow for an actual bomb, it requires heating the gasses to a high temperature for a long time and as such an impact would only produce a small amount in the time it takes for it too cool down, not to mention the gasses escaping away immediately after impact

Also, actually trying to create ClF3 in situ is a waste of energy. Quite frankly you'd be better off putting the same amount of energy directly into the explosion; it'd do more for your purposes.

High power oxidizers aren't like binary poisons or explosives, they don't exploit a quirk of biology to stop a life where either of them alone can't, or stable when separate but react when combined into a more volatile substance that is capable of releasing just as much energy much faster.

They're more of a very high density energy storage medium. There's a reason FOOF and ClF3 were considered as potential rocket fuels, they offer tremendous energy per kilogram of propellant and being fairly heavy atoms also offer good thrust. They just don't get used because they're far, far too difficult to keep controlled and the vast quantities of extraordinarily toxic reaction products they create during combustion.

The most common rocket propellants are basically RP1 (highly purified kerosene) and liquid oxygen for a reason, but swapping the liquid oxygen for either FOOF or ClF3 would create both higher thrust profiles and rocket exhaust composed of chlorine gas, fluorine gas, hydrochloric acid, hydrofluoric acid, chloro(hydro)carbons, fluoro(hydro)carbons and chlorofluoro(hydro)carbons, which are the first chemical warfare agent used on an industrial scale in WW1, chlorine gas' less pleasant cousin that eats your bones and causes your nerves to always be on causing you to be in agony, stuff your body uses to break down everything it consumes, hydrocloric acid's less pleasant cousin, poisonous and carcinogenic, poisonous and carcinogenic and finally poisonous and carcinogenic. And for the latter 3 that's if it doesn't react with the airborne ozone layer and punches a hole in it either as a catalyst or by reacting directly with the ozone.

Frankly, I'll take the reaction products of RP1 and liquid oxygen, which is largely soot, water and carbon dioxide.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on January 13, 2019, 01:21:30 PM
How about a high tech research option or ancient ruin tech that could generate a kind of hub system like in "The Expanse" which can be used as a shortcut to the distant systems of your empire?
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on January 13, 2019, 05:52:04 PM
The problem with Chemical & Biological warfare is that it starts creeping back into "kill 'em all and move in tomorrow" territory.  I think the assumption about B&C is that it kills enemy populations & ground units, but does not harm installations.  In that case, it needs sufficient downside (perhaps in the chance of rendering the entire planet uninhabitable, or covered in "grey goo," or creating Resident Evil-style enhanced monsters).

Yeah I agree. The coolest way to make bio weapons balanced from a "wipe out everything living and keep all installations intact" standpoint is probably if the bio weapon remains dormant after your civilians moving in and can mutate into a form which risks spreading and wiping out your entire race as well. But that needs a way to counter it too, and then we are most likely just back to square one ( if it's too easy to defend against ). I feel there is too much complexity here that isn't necessary benefiting the core Aurora gameplay as much as some other more basic additions could add, and a large risk of just creating a way to wipe out an enemy mostly effortlessly and take all their stuff.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 14, 2019, 01:02:08 AM
I dont personally think it would be very viable to quickly wipe out a population via chemical or biological agents.  I think youd need to steadily bombard them for some time to overcome their containment efforts.  Some hypothetical super high tech race wouldn't neccesarily find it all that hard to hermetically seal things off, but they may still struggle to avoid getting disintegrated by a nuke.

So I mean, higher cost and more time over target but you keep their infrastructure.  That might make chemical/bio weapons into a reasonable tradeoff against nukes and such.
Title: Re: C# Aurora v0.x Suggestions
Post by: dag0net on January 14, 2019, 02:22:07 AM
If you can get into orbit to drop bioweapons it's likely you have some kind of edge over the enemy.   

Besides which, just as with any weapon of war, whilst you might have a theoretical defence against it, deploying that defence is another thing entirely, if such potentials were readily made into actuals there wouldn't be an enemy in orbit dropping bombs on you in the first place.   


  If Steve were to include every manner in which complex lifeforms could be destroyed by other complex lifeforms we'd have to bring in Brandon Sanderson to write 1.  0
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on January 14, 2019, 08:07:33 AM
Brandon Sanderson to write 1. 0

Shall we start a Kickstarter, then?
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 14, 2019, 09:07:41 AM
Well, you can bring in a terraforming station into orbit once you have suppressed the opponents defences properly. That would quickly ruin the living conditions on the planet by releasing toxic gases into the atmosphere. Unless they can build enough infrastructure people will start to die and there will be riots on the ground.

It will not kill of the soldiers or the army but it will certainly be a terror weapon that works in the games right now...
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 14, 2019, 09:54:07 AM
Something I have pondered for a while is pressing civilian shipyards into military production during wartime perhaps should be a thing.

A simple thing could be that a civilian yard could retool to a military ship that are 20 times smaller than the civilian yard and this could be more efficient with technology. The retool cost could also be two times more expensive as would then the time be as well and this could also be made more efficient with technologies.

I'm sort of looking on large scale wars such as say the WW2 where there is time and need for re-purposing civilian industry for wartime production. In peace you have a modest amount of military yards to maintain a decent peace time fleet and in wartime you might want to ramp up the production through converting civilian yards into producing military ships.

Military yards should not have this ability and just able to build whatever ships fit their size the way they do now.

In my own games I have allowed this to some extent and I can easily do it through SM... would just be fun if it could be done through a real mechanic with a bit more cost as a side effect.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on January 14, 2019, 10:56:00 AM
Given that Steve has now dealt with the missile - fighter - ship fuel consumption consistency point I was wondering if a similar exercise could be done for fire controls so we don't have the arbitrary 4x tracking bonus for a fighter in an effort to get something to actually fit within a 500 ton limit. The fighters are using the same ship borne weapons so why have a different rule set for them?

Personally I think fire controls are currently way too large in any case and could do with being shrunk to a fraction of their starting size (from some very brief looks at Wikipedia I can see the old Mk 1 Computer that the US used weighed in at a portly 1.3 tons and subsequent systems that were not mechanical in nature got a lot smaller than that). It also strikes me as odd that I can happily build fighters with MFCs that are a fraction of 50 tons and work very well.

If taking a starting 1x range, 1x tracking to 5 tons and going from there sends shivers down the spine perhaps an alternative would be allow for smaller more expensive fire controls and then large cheaper versions as a way to keep consistent but then practically useable. The small fire control would also be a nice buff to energy weapon combatants.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 14, 2019, 11:46:09 AM
Given that Steve has now dealt with the missile - fighter - ship fuel consumption consistency point I was wondering if a similar exercise could be done for fire controls so we don't have the arbitrary 4x tracking bonus for a fighter in an effort to get something to actually fit within a 500 ton limit. The fighters are using the same ship borne weapons so why have a different rule set for them?

Personally I think fire controls are currently way too large in any case and could do with being shrunk to a fraction of their starting size (from some very brief looks at Wikipedia I can see the old Mk 1 Computer that the US used weighed in at a portly 1.3 tons and subsequent systems that were not mechanical in nature got a lot smaller than that). It also strikes me as odd that I can happily build fighters with MFCs that are a fraction of 50 tons and work very well.

If taking a starting 1x range, 1x tracking to 5 tons and going from there sends shivers down the spine perhaps an alternative would be allow for smaller more expensive fire controls and then large cheaper versions as a way to keep consistent but then practically useable. The small fire control would also be a nice buff to energy weapon combatants.

In that case fire-controls should be completely redone. A small fire-control should say have a rather limited number of object they can control while a larger one can control more missiles and targets. This would naturally make fighter fire-controls small and ship mounted ones larger because you want to control more objects in flight or potential targets.

The whole fire-control and salvo thing is an awkward mechanic that unfortunately sometimes break the immersion. Fire-controls should instead be limited not only by speed but also on what they can track and/or control.

A larger fire control can track more incoming targets or in case of missiles guide more of them to the target or in case of beams how many weapons a specific control can operate and/or targets it can track in terms of PD.

I would like the whole salvo idea to be removed as a concept at some point, this might be a good opportunity to do so if redone and dynamically remove the difference between fighter fire-controls and ship mounted ones.

Thus a fighter that only fire a single volley of four missiles would have a much smaller fire-control than a ship that might potentially fire several volleys of dozens of missiles each against multiple targets. Those fire-control AI and communications/scanning arrays need to be built way differently.

I also think that fire-controls should radiate some EM signals when active, though much less so than regular active scanners.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 14, 2019, 06:02:58 PM
I'd be happy if we could just get Point Defense to track X number of missiles in a small area, rather than number of salvoes.
Title: Re: C# Aurora v0.x Suggestions
Post by: dag0net on January 14, 2019, 06:24:57 PM
Quote from: Jorgen_CAB link=topic=9841.  msg112137#msg112137 date=1547481247
Something I have pondered for a while is pressing civilian shipyards into military production during wartime perhaps should be a thing. 


The same/ilar principle as an economy being limited by private sector generated wealth in a genocidal 'total war' conflict between two species run by monolithic regimes, and whilst the 'features of the engine to automate/enable expanded storytelling' motivation loves the idea, the 'i do hope Steve closes the gap between human and npr capability to exploit the mechanics' part really doesn't ;-)


Whilst I'm typing.  .  .  . 

If the user had a semi-automated(or more automated anyway) method of vessel design, it, or it's results could be co-opted by Steve and the AI.   That is to say that if the user has a set of radio/sliders to play with to design ships based on current/next gen tech and the engine is equipped to generate vessels based on the requirements set.  .  and the ai uses the same set of mechanics then the userbase can be employed to refine ai design mechanics, a capability retained through future issues. 

The system could generate for users a combined package of research for the entirety of the design (as per contract tendering) which results in a completed package, as opposed to researching individual components.   (or retain the same system of individual components ofc.  )

As we can sample from Mr Walmsley's example, the wonders need not cease with the initial release.   I suggest that design revisions (efficiency gains in iterative steps) might be included as a potential r&d step for a fractional gain on components (and/or architectures.  ) Where em6 to 8 gives a third gain, passive em sensor rating 6 size 1 'patch 2' might confer a 5% (or w/e) gain. 

Yahyah, I can bemoan feature creep and suggest it in the same post =)


Re: FC revisions - If any code revision reduced the number of missiles thrown, any performance(engine) loss to more data being tracked per missile/salvo might be gained by limiting the total.   I don't know how well my pc would cope with honor harrington.   Speaking of - wasn't it Weber that had mfc boats that flotillas handed off fire control to?

Data export - Whilst I've seen it referenced many times in a 'gimme mod support' fashion, the ability to export/import certain data (not constituting a save game) would save an awful lot of time. . .  even 'just' extended from what is already there (editable order lists as per templates, fc settings, race/empire starting setups, solar systems) the issue I see is that many paths would require extra work every time the subject of a 'savable' set of data receives revisions.

Sorry if repetitive or whatevs, I do read, but sometimes things go in one eye and out the other =)
Title: Re: C# Aurora v0.x Suggestions
Post by: Ranged66 on January 15, 2019, 09:07:03 AM
Quick simple suggestion:

A checkbox for allowing empty starsystems.


I personally don't like them and always reroll them.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on January 16, 2019, 03:25:07 PM
Suggestion about the Event-Window:

Adding the possibility to Save/Load the colour-coding for the Event Window.

I might be missing something but in VB6 it was possible to set the colors back to "default" but not possible to save the changes and load as a "new default" or "colour set" when you started a new game - as I am playing mostly with the same colours for the same events it would be great to be able to save/load the settings and use them in new gamestarts as well...
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on January 17, 2019, 05:53:12 AM
Suggestion about Conquest in Ground Combat:

I was just thinking about Ground Combat and the "end" of it...

maybe something like this would work (and make it interesting)

- each time there is a "breakthrough" in ground combat, the attacker has a chance to capture some Installations (like factories etc) - they are transferred to him and count for him in all aspects (I guess the game is already be able to do this as ruins can give installations, so it should be the same system - destroying a installation for one race and creating it for an other - instead of a "real transfer"?) The chance for a occupation of installations could depend on the weight of the "loosing formation" in relation to the total weight of it's troops side.

- if one (or all) race does not have any installations at the beginning (like the attacker if he is invading) it get's some kind of "pseudo installation (like Landing Zones etc) - exact numbers are depend on balancing but maybe 1 "landing zone" for each X t of troops as a minimum for both sides

- if a race has lost a % of it's starting installations (not because destroyed by collateral damage but because of conquer/occupation) it (or to make it much more complex: each unit formation; I would suggest total surrender for the beginning) has a chance to surrender (maybe depending on a race specific % in the race setup)

- if a race lost all it's installations/pseudo installations it will surrender

this would mean that an invader has to defend it's landing zones as the defender could force him to surrender just by overrunning the landing zones if he is lucky in breakthroughs

it would also show the progress in a battle - not only by death and blood but by gain and losses of terrain

when the attacker invades with only a small force to build bridgehead, he runs the risk to get "cut off"

the defender has to plan if he wants to dig-in and try to blood the attacker dry in a defence war or try an all-out assault to capture the landing zones (and so destroying the enemy ground forces in total) before more waves arrive on planet

but if the defender is just sitting on defence all the time he can not win - also a attacker that is just attacking might end up loosing his "supply bases/landing zones"

---

this is not fully thought through but I hope you get the "picture" I have in mind... battles would be won by occupying (most of) the planet (or the important locations of it) - the occupation is simulated by occupying "installations"
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on January 17, 2019, 12:59:19 PM
Makes sense.

Also, rubble should count for capture-able installations equal to its previous size.

Maybe instead of counting by captured landing zones formations that fall out of supply should be given a probability of surrender that goes up for each round they have been in combat but out of supply. If we want to be fancy about it, we could even model PoW camps as temporary installations (so surrendered formations can be liberated if reinforcement and resupply arrives in a timely manner).

This way your logistics units and rear echelon HQs essentially carry your flag while in combat, and if people can wipe them the clock starts ticking for your presence on that planet.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on January 17, 2019, 01:28:51 PM
That would make logistics a critical weakness. You burn supplies fast by all appearances, with units carrying enough supplies for 10 rounds (60 hours of combat IIRC) before they run out, and a divisional force in combat can burn several hundred supply per round.

Keep in mind that the largest supply component carries only 500 units of supply.

Outside of the most minor engagements you'd need thousands of units of supply, and as the terrain gets more defensible supply demands per kill skyrocket.

Because of this, the advantage will always lie with the defender because with supply so critical to your chances of forcing surrender a defender will stack massive amounts of supply with his defenses while an attacker has to establish and maintain a steady and sizable supply line or his troops start surrendering. Given that especially early on a single supply run can take months that's... rather punishing and makes planetary assault effectively impossible.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on January 17, 2019, 01:36:29 PM
Why is that system an improvement over the one that Steve currently has? Since it is entirely possible to have combat on bodies with no installations at all.
Title: Re: C# Aurora v0.x Suggestions
Post by: Happerry on January 18, 2019, 07:54:45 PM
The new Genetic Enhancement options are making me wish for equivalent cybernetic enhancements, or at least for the Genetic Enhancements to be renamed so they're easier to fluff as cyborg enhancements.  Or fluff as a mix of both.
Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on January 18, 2019, 09:40:30 PM
Not sure if this has been suggested already, or if maybe its already been added. But It would be nice to be able to recolour jump links so the map can be a little more organized.
When you have a map which contains a lot of criss crossing links it would be nice to colour code links by some system.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on January 20, 2019, 11:21:37 PM
Regarding the conquest discussion:

An attacking unit being able to capture installations definitely makes sense, but I feel like there should also be a chance capture portions of the population, if one exists.

In regards to surrendering, I think it might make sense if there was some chance every set period of time that one side in a ground conflict surrenders, with the chance being based on factors like the current fighting strength of friendly units, on average, (compared to their fighting strength when undamaged, at peak performance, etc.) the current fighting strength of the least damaged friendly units, on average, how many friendly units are present that have little to no damage, etc. while comparing this to a similar analysis of the enemy's strength.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 20, 2019, 11:30:31 PM
You know that could be quite cool.  A ground war ends, but you wind up capturing a portion of the surface of the planet, based on whatever bits your forces managed to grab before the fighting ended.
Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on January 21, 2019, 12:38:40 AM
Units that are almost destroyed can surrender if they're significantly outmatched by the enemy (you need to rotate out those damaged units, or maybe if they've been fighting a long time), captured units basically become forced labor batallions, but need watching else they might revolt. Gotta ship them out to prison worlds or something or they might be recaptured.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on January 21, 2019, 01:32:41 AM
I like the idea that units could be captured or forced to surrender, probably as a potential result as a breakthrough (representing something like the formation in question being outmaneuvered, cut off from the larger friendly force, and surrendering as a result), or through whatever method Steve may have planned for ship crews surrendering during a boarding action, since he mentioned that.  I don't know if just automatically having them become forced labor battalions makes sense, though.  Ideally there would be options on how to treat prisoners, but at the bare minimum I figure captured enemy ground soldiers should be treated the same as captured enemy crew picked up from life pods, serving as a potential source of intelligence (particularly regarding the capabilities of the enemy ground forces).

Being able to capture enemy equipment in this way could also be cool.
Title: Re: C# Aurora v0.x Suggestions
Post by: waresky on January 21, 2019, 10:28:12 AM
TOO (really too..) many questions..possibility and capability.

THIS is a "One-man-program" u r all crazy by submit overwhelming requests.

Since 2016 "C# project" began..NOW its 2019.

Wtf all wanna?

Am desire 1 thing : play. End.
Title: Re: C# Aurora v0.x Suggestions
Post by: Seolferwulf on January 21, 2019, 11:08:00 AM
There's nothing wrong with suggesting ideas :p
If Steve likes them but it's too much for the initial launch he can add it later on whenever he wants.
Title: Re: C# Aurora v0.x Suggestions
Post by: Sirce on January 21, 2019, 08:07:42 PM
TOO (really too..) many questions..possibility and capability.

THIS is a "One-man-program" u r all crazy by submit overwhelming requests.

Since 2016 "C# project" began..NOW its 2019.

Wtf all wanna?

Am desire 1 thing : play. End.

Well, this is a game for Steve that he graciously allow us to play. Unfortunately, he hogging the C# at this time but that is because he can. All the suggestions are ideas Steve can mine and develop when he wants to. Fortunately, he promises Soon(TM) for us to play on C#. Steve, don't get hit by a bus, or something similar, please!
Title: Re: C# Aurora v0.x Suggestions
Post by: Bughunter on January 22, 2019, 05:12:07 AM
Steve, don't get hit by a bus, or something similar, please!

Best suggestion so far, should be on top of the C# priority list  ;D
Title: Re: C# Aurora v0.x Suggestions
Post by: The Forbidden on January 23, 2019, 01:26:04 AM
Quote from: Bughunter link=topic=9841. msg112281#msg112281 date=1548155527
Quote from: Sirce link=topic=9841. msg112278#msg112278 date=1548122862
Steve, don't get hit by a bus, or something similar, please!

Best suggestion so far, should be on top of the C# priority list  ;D

I'd say that assuming that "Not getting killed, maimed or otherwise injured" is pretty high on Steve's priority list is a rather safe bet.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on January 24, 2019, 12:55:37 AM
Why not combine the "resupply" order with the "refuel" order? Usually the two things are done at the same place. And if not, attempting to do both at the same place (fuel dump) won't cause any harm, just result in an "insufficient supplies" issue. It just cuts down on the micromanagement.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 24, 2019, 03:59:14 AM
Why not combine the "resupply" order with the "refuel" order? Usually the two things are done at the same place. And if not, attempting to do both at the same place (fuel dump) won't cause any harm, just result in an "insufficient supplies" issue. It just cuts down on the micromanagement.

http://aurora2.pentarch.org/index.php?topic=8495.msg109597#msg109597
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on January 24, 2019, 04:50:52 AM
Why not combine the "resupply" order with the "refuel" order? Usually the two things are done at the same place. And if not, attempting to do both at the same place (fuel dump) won't cause any harm, just result in an "insufficient supplies" issue. It just cuts down on the micromanagement.

http://aurora2.pentarch.org/index.php?topic=8495.msg109597#msg109597
I'll just show myself out. Door's still over there, same as last time, yes?  ;)
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on January 25, 2019, 05:02:25 AM
Quality of Life idea: Order Patterns. This is something I think could come in handy for transport fleets. Usually when I spread installations around a system, I have to create a similar order flow - pick up A here, move to B, unload, return to A, refuel. Or if it is some kind of mining colony I add a "load minerals on B" after the unload. This goes in two flavors: do it x amount of times or cycle it.

It's a bit annoying to have to create this pattern over and over again. Now, there already is a function in the game which can save such order patterns - although you can't modify them. Having those as general order patterns in which you "simply" add source, destination and what you want to tranfer, flavored with the option to "auto generate shortest jump route" (which was already in VB6-Aurora), would be a nice time and click saving QoL.

Edit: since C# Aurora is a lot quicker at calculating routes, how about a new command „autocalc route to“. By choosing this command instead of manually creating a route each time a fleet comes to this command, it calculates the shortest route to the target.
Idea is, that in some systems, depending on star constellation, it sometimes is quicker to go through a Lagrange point, sometimes not. This would reflect what a ships captain would normally do, instead of flying a pre-given but eventually ineffective course.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on January 28, 2019, 04:29:25 PM
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.
Hi Steve. Don't know if you ever adresses this. Would you think, something of that kind would be possible to realize?
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on January 31, 2019, 03:15:14 AM
would it be possible to have civilian troop transports/a way to contract the shipping lines to move troops around various garrisons?
Title: Re: C# Aurora v0.x Suggestions
Post by: The Forbidden on January 31, 2019, 03:41:22 AM
would it be possible to have civilian troop transports/a way to contract the shipping lines to move troops around various garrisons?

I think the transition of troop bays from military systems to commercial ones should already cover those kind of issues pretty well. After all you won't need to overhaul or maintain your slow, lumbering standard troop transports that move your garrisons around.
Title: Re: C# Aurora v0.x Suggestions
Post by: The Forbidden on January 31, 2019, 03:43:35 AM
Also, quick question Steve, do STOs make orbital defence stations irrelevant ? Since they're hidden unless they fire and apparently possess quite a fair amount of fire power, is there any real insensitive to build them besides having missile launch capability?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 31, 2019, 04:12:07 AM
Also, quick question Steve, do STOs make orbital defence stations irrelevant ? Since they're hidden unless they fire and apparently possess quite a fair amount of fire power, is there any real insensitive to build them besides having missile launch capability?

AMM stations will still be needed. They could be protected by ground-based PD, but I think a combination of ground and space-based PD will still be useful.
Title: Re: C# Aurora v0.x Suggestions
Post by: The Forbidden on January 31, 2019, 04:53:32 AM
Also, quick question Steve, do STOs make orbital defence stations irrelevant ? Since they're hidden unless they fire and apparently possess quite a fair amount of fire power, is there any real insensitive to build them besides having missile launch capability?

AMM stations will still be needed. They could be protected by ground-based PD, but I think a combination of ground and space-based PD will still be useful.

The only thing left to know is if it will be worth the actual cost and shipyards to build them then (I was never one for AMM, using too much ordonnance for sometimes meager results, so I might be slightly pessimistic).
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on January 31, 2019, 05:25:30 AM
AMM stations will still be needed. They could be protected by ground-based PD, but I think a combination of ground and space-based PD will still be useful.

I can see how Space based PD could become useful in case you have either:

1.) A logistical situation that is better suited for it ( lots of tugs or hangar space to haul them around but a shortage of transports for ground units ).
2.) A production situation that is better suited for it ( minerals or factories to build them in surplus but a shortage of minerals or ground unit training ).
Title: Re: C# Aurora v0.x Suggestions
Post by: The Forbidden on January 31, 2019, 06:33:37 AM
AMM stations will still be needed. They could be protected by ground-based PD, but I think a combination of ground and space-based PD will still be useful.

I can see how Space based PD could become useful in case you have either:

1.) A logistical situation that is better suited for it ( lots of tugs or hangar space to haul them around but a shortage of transports for ground units ).
2.) A production situation that is better suited for it ( minerals or factories to build them in surplus but a shortage of minerals or ground unit training ).

Wait, I thought factories could only be used to build civilian space stations in C# Aurora.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on January 31, 2019, 06:34:49 AM
Wait, I thought factories could only be used to build civilian space stations in C# Aurora.

That might be the case, I probably thought about Military Space factories aka Shipyards in that case:P

Hard to keep all the changes in your head when you can't play it yet!
Title: Re: C# Aurora v0.x Suggestions
Post by: Ranged66 on January 31, 2019, 06:41:20 AM
QoL economy/industry suggestion:

Mineral overview window

Shows total empire-wide income/expenditure of every mineral.
e.g. showing that there are 1200 tons of Duranium being harvested annually, but 2500 being used up anually.

Can optionally even be broken down into a per system or per planet basis with totals displayed somewhere. This will make it easier to identify resource shortcomings.
Title: Re: C# Aurora v0.x Suggestions
Post by: professorpicke on February 01, 2019, 12:51:17 AM
When moving industry between planets, it can sometimes be more convenient to use the citizen's tab to commission pick ups and drop offs.  The problem is your ships cannot do commissions,  only civilian ships.  Could you add a default order that makes the task group do any available commissions? thanks :)

also, although there is no way you haven't played games like eu4 or hoi4, they are great games to mooch systems off of for say, land combat in case you are looking >. > .  As with everyone else, looking forward to C#!
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on February 01, 2019, 11:54:11 AM
Please no, the combat model in HoI4 is terrible for actually simulating warfare. I was a betatester for HoI2, I've sunk hundreds of hours into HoI3 (as well as HoI1 and HoI2) and I followed closely the development of HoI4 and tried it out. The planetary combat system Steve currently has is pretty good for its intended purpose and cloning any of the HoI combat models wouldn't improve it.

e.g. showing that there are 1200 tons of Duranium being harvested annually, but 2500 being used up anually.
But there is no fixed annual consumption. If you add or remove something from the production queues, the projected consumption will change. If you increase industry somewhere, the projected consumption will change. The production queues can take years or decades to finish. Mineral accessibility can change. So the projections would easily fluctuate and need to be recalculated every production cycle. But maybe C# is so much faster than VB6 that the production cycles would still fly past.
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on February 01, 2019, 02:31:49 PM
Please no, the combat model in HoI4 is terrible for actually simulating warfare. I was a betatester for HoI2, I've sunk hundreds of hours into HoI3 (as well as HoI1 and HoI2) and I followed closely the development of HoI4 and tried it out. The planetary combat system Steve currently has is pretty good for its intended purpose and cloning any of the HoI combat models wouldn't improve it.

e.g. showing that there are 1200 tons of Duranium being harvested annually, but 2500 being used up anually.
But there is no fixed annual consumption. If you add or remove something from the production queues, the projected consumption will change. If you increase industry somewhere, the projected consumption will change. The production queues can take years or decades to finish. Mineral accessibility can change. So the projections would easily fluctuate and need to be recalculated every production cycle. But maybe C# is so much faster than VB6 that the production cycles would still fly past.

There wouldn't be a performance penalty. Since these are just for user display, you don't need to run these calculations every production cycle - just when you open the production window. Yes, building mines and construction factories will affect the figures, but it's a pretty easy differential equation.
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on February 01, 2019, 05:30:46 PM
would it be possible to have civilian troop transports/a way to contract the shipping lines to move troops around various garrisons?

I think the transition of troop bays from military systems to commercial ones should already cover those kind of issues pretty well. After all you won't need to overhaul or maintain your slow, lumbering standard troop transports that move your garrisons around.

Troop bays are already commerical systems in VB6.
The same can be said of any of the other commerical shipping options to do it yourself. I was hoping it to be possible to only have specialized troop transport in the state controlled fleet like assault carriers or other special cases and leave the routine moments to the commercial shipping lines similar to how some members of the community handle movement of facilities or colonization. Jump colony/cargo ships for the state fleet and bulk carriers in the commerical shipping lines.
Title: Jump point to distant stars and star area damage
Post by: Triato on February 02, 2019, 03:14:26 PM
A pair of sugestions that don´t need to be added to the incoming C aurora version, but I wanted to share them anyway so I don´t forget them later.

First one is to have some rare jumpoints that lead to distant stars when using the real stars option. This would allow us to have nebulae and black holes when using sol start (altugh with a low probability). That got me thinking that as I understand, the center of the galaxy has a lot more radiation from denselly packed stars, I don´t know how much that is but I´ve heard it prevents life from being posible there. Perhaps it would be enough to damage our transnewtonian ships? maybe after days/months of exposure?, maybe shieds can prevent this?

The next idea is to have a ´´damage zone´´ close to stars, the size would depend on the star type and the closer the higher the damage. Again, maybe shields can regenerate faster than the damage (depending on distance and regen rate of shields).

I don´t know if the ideas presented are plausible/´´realistic´´ enough for aurora, but I belive they can ad to the strategic aspects of the game. As it is, other than populations and jump points, the ´´terrain´´ doesn´t play an important role in aurora, ideas like these could help divesify the gameplay.
Title: Re: C# Aurora v0.x Suggestions
Post by: IanD on February 03, 2019, 11:03:04 AM
Steve, is it possible to distinguish between search sensors and targeting sensors (fire control)? It would require that each type of sensors be activated individually. search sensors would be relatively non-threating. However should the opposing vessel start using its fire control to target your vessel it would be a definite threat indicating you should take it seriously. This action may or may not result in incoming fire depending on the other sides aggression rating and the sensitivity of the area of space you are in. Detection of the type of sensor being used would depend on the sensitivity of the EM sensor installed and distance to target.

This would enable the sort of scenario seen in the Channel 5 documentary on HMS Duncan in the Black Sea (episode 2, available on My5)) when several Su-27 aircraft flew close to Duncan, using their search radars but not the target acquisition radar. https://www.my5.tv/warship-life-at-sea/season-1/episode-2
Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on February 03, 2019, 05:10:52 PM
With low gravity infrastructure, perhaps now theres a reason to take another look at facilities which don't require population, CMCs in particular perhaps should also have a civilian population and LG infrastructure attached to them (or regular infrastructure if its a normal world), perhaps CMC's only use automated mines though? I might assume that CMCs have a decent level of automation, perhaps only having a quarter the population as the equivalent amount of mines (mostly so the player doesn't get too much free infrastructure) and if the body has too much colony cost (like venus) just assume the whole facility is automated, or give it a placeholder population of 10,000 with no addition as the facility expands.
Also of note is deep space tracking facilities which I imagine should require a significant population, refuelling, ornance transfer and cargo shuttle stations I also suspect should require a population.
Theres others like Military Academy, Naval headquarters and Sector command which are fine as I guess they're only of use in an inhabited colony anyway.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on February 04, 2019, 01:07:14 AM
In general I agree that perhaps the time has come to do away with automines?

Sure its realistic, but so is auto-everything.  Its frankly kindof fun to have a population associated with your labor in a sci fi universe, and maybe extraction of smaller deposits could be taken over by large mining ships instead?
Title: Re: C# Aurora v0.x Suggestions
Post by: The Forbidden on February 04, 2019, 01:14:06 AM
In general I agree that perhaps the time has come to do away with automines?

Sure its realistic, but so is auto-everything.  Its frankly kindof fun to have a population associated with your labor in a sci fi universe, and maybe extraction of smaller deposits could be taken over by large mining ships instead?

Personally I'd prefer keeping the automines, if only to mine high gravity bodies. Plus I really don't want to have to deal with a ton of micro populated colonies everywhere and having to juggle their population around to keep mining those moons.
Title: Re: C# Aurora v0.x Suggestions
Post by: Panopticon on February 04, 2019, 02:40:50 AM
I always RP to myself that automines actually do have a small population associated with them to perform maintenance and such. So doing away with them would be okay but how about changing them instead? have them still cost the same or maybe a bit more, but require something like 1/10 or 1/100 the population(I forget what the original numbers are and refuse to go look them up) maybe they even come with built in infrastructure to house their workers. So you get the choice between cheap mines that need a lot of people, or expensive ones that don't but support the people they need.
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on February 04, 2019, 02:53:11 AM
i also RP and imagine that DST, CMC, and automines have small number of personnel associated with them something in the range of 25~80 people, well below the scale of a population center. like a DEW radar station for DSTs and an oil rig like setup for the mines.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 04, 2019, 03:31:04 AM
i also RP and imagine that DST, CMC, and automines have small number of personnel associated with them something in the range of 25~80 people, well below the scale of a population center. like a DEW radar station for DSTs and an oil rig like setup for the mines.

Yes, this is my assumption as well.

http://aurora2.pentarch.org/index.php?topic=8495.msg110522#msg110522
Title: Re: C# Aurora v0.x Suggestions
Post by: The Forbidden on February 04, 2019, 06:08:50 AM
i also RP and imagine that DST, CMC, and automines have small number of personnel associated with them something in the range of 25~80 people, well below the scale of a population center. like a DEW radar station for DSTs and an oil rig like setup for the mines.

Yes, this is my assumption as well.

http://aurora2.pentarch.org/index.php?topic=8495.msg110522#msg110522

Thanks, oh, and by the way you should update that post with the new workers requirements for shipyards.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 04, 2019, 06:50:39 AM
Thanks, oh, and by the way you should update that post with the new workers requirements for shipyards.

Yes, good point. I will sort that.
Title: Re: C# Aurora v0.x Suggestions
Post by: The Forbidden on February 04, 2019, 09:46:07 AM
Thanks, oh, and by the way you should update that post with the new workers requirements for shipyards.

Yes, good point. I will sort that.

If this goes on you're going to end up spending more time correcting previous statements than actually implementing new features XD.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 04, 2019, 09:58:09 AM
If this goes on you're going to end up spending more time correcting previous statements than actually implementing new features XD.

I do trawl through the change list occasionally to check if anything needs updating :)
Title: Re: C# Aurora v0.x Suggestions
Post by: The Forbidden on February 04, 2019, 10:20:19 AM
A centralized wiki would probably be a better long term idea though (wasn't somebody working on that ?) But for now the change list is still a gold mine of information. By the way, ever had the time to test if the NPR actually properly made and managed it's fleets in your test campaign ? That's one thing that I've been very curious about, especially how they handle a prolonged war with that system.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on February 04, 2019, 10:24:03 AM
A centralized wiki would probably be a better long term idea though (wasn't somebody working on that ?) But for now the change list is still a gold mine of information. By the way, ever had the time to test if the NPR actually properly made and managed it's fleets in your test campaign ? That's one thing that I've been very curious about, especially how they handle a prolonged war with that system.

http://aurorawiki.pentarch.org/index.php?title=Aurora_C
Title: Re: C# Aurora v0.x Suggestions
Post by: The Forbidden on February 04, 2019, 10:36:50 AM
A centralized wiki would probably be a better long term idea though (wasn't somebody working on that ?) But for now the change list is still a gold mine of information. By the way, ever had the time to test if the NPR actually properly made and managed it's fleets in your test campaign ? That's one thing that I've been very curious about, especially how they handle a prolonged war with that system.

http://aurorawiki.pentarch.org/index.php?title=Aurora_C

Thanks ! By the way, the link is broken, the # is missing.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 04, 2019, 11:39:37 AM
By the way, ever had the time to test if the NPR actually properly made and managed it's fleets in your test campaign ? That's one thing that I've been very curious about, especially how they handle a prolonged war with that system.

The NPR did manage its fleets well, including creating new operational groups with the correct mix of ships and building ships to fill gaps. It's combat I need to test now.
Title: Re: C# Aurora v0.x Suggestions
Post by: The Forbidden on February 04, 2019, 05:40:36 PM

The NPR did manage its fleets well, including creating new operational groups with the correct mix of ships and building ships to fill gaps. It's combat I need to test now.

Thanks, and okay, good luck then !
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on February 04, 2019, 10:03:02 PM
Hey, Steve, I was looking at the C# Civilian Economy wiki and noticed this line:

"The number of civilian freighters and colony ships will be kept relatively even."

At least in my own VB games, this strategy tends to result in too many colony ships and not enough freighters.  A more balanced approach would consider actual workload when deciding which ship types to build.  The simplest approach would be for each company to limit production based on the number of idle ships of each type, weighted to prefer types with fewer idlers.  A limit around 5 would probably give the best results.
Title: Re: C# Aurora v0.x Suggestions
Post by: Erik L on February 04, 2019, 11:47:47 PM
I'd like to see a General Quarters type setting for fleets/ships. This would reduce the amount of time to execute orders as the crew is ready for action. Ships could not maintain GQ for extended periods of time (more than 8 hours for example).
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on February 04, 2019, 11:59:30 PM
I'd like to see a General Quarters type setting for fleets/ships. This would reduce the amount of time to execute orders as the crew is ready for action. Ships could not maintain GQ for extended periods of time (more than 8 hours for example).
This could include a morale penalty building up over time, with a cooldown period (and effectiveness penalty) while the crew rests.  Crew training level could increase the benefits while reducing the penalties.  Maybe consume crew deployment time faster while active?
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on February 05, 2019, 12:12:35 AM
. . .  The simplest approach would be for each company to limit production based on the number of idle ships of each type, weighted to prefer types with fewer idlers.

A better approach would be for each compan to build only one type of civilian craft (freighter, colony, fuel harvester, etc.).  That way, companies with types with a higher demand will earn more money and build more ships.  Self-regulating.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on February 05, 2019, 12:25:43 AM
. . .  The simplest approach would be for each company to limit production based on the number of idle ships of each type, weighted to prefer types with fewer idlers.

A better approach would be for each compan to build only one type of civilian craft (freighter, colony, fuel harvester, etc.).  That way, companies with types with a higher demand will earn more money and build more ships.  Self-regulating.
There are two problems with that method:
1) You need both freighters and colonizers in the early game (read: first year) when you only have one company.
2) Even if you limit to a single type per company, you will still overbuild since your idlers are still a percentage of your working ships.

What I'm proposing is closer to how real shipping companies operate, in that if they have idle assets, they don't build more.  It also directly addresses the problem of idle civilian ships cluttering the game.  And frankly, 5/type/company is probably too high.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on February 05, 2019, 05:12:02 AM
I'll also note that civilian fuel harvester mechanics are notably different from civilian transportation mechanics. Fuel harvesters produce wealth for the company operating them dependent on how much fuel they produce, regardless of if it's sold to empires or to the open market (overflow from the storage tanks). The various transport ships need to move between ports with cargo to make money.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on February 05, 2019, 05:43:12 AM
A better approach would be for each compan to build only one type of civilian craft (freighter, colony, fuel harvester, etc.).  That way, companies with types with a higher demand will earn more money and build more ships.  Self-regulating.

I like that approach. It makes sense, feels a bit more plausible than all companies building all types of ships and is probably a good idea for game balance too!
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on February 05, 2019, 07:56:28 AM
I'd like to see a General Quarters type setting for fleets/ships. This would reduce the amount of time to execute orders as the crew is ready for action. Ships could not maintain GQ for extended periods of time (more than 8 hours for example).

I like this idea as well and have suggested it previously. I thought this would be a good way to manage ships sitting on a picket for two years but still being able to react immediately and would also be a way to manage time to launch fighters. I think Steve's view is that this will create too much micro management though and I can see the point but would still like it as an option much as we have the ability to switch on and off crew training etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: misanthropope on February 05, 2019, 10:16:04 AM
usage rate is a reasonable way to allocate between freight and colony, but liners are going to present some problems.  they have zero idle time, ever, and while you're confined to one system (with very short transit times) their ROE is sky high.  weight by usage or profit and you're going to wind up with a lot of liners and a lot of wealth production.  which is actually *correct* given the economics of aurora, but amounts to an exploit since the economics are so underdeveloped.

i imagine you'd see similar behavior vis a vis colony ships for players who use the infinite wealth earth-moon round trip exploit.

would it be so bad just to let the player decide which types of ships subsidy funds are spent on?   make the "profits squandered" portion a bit higher, and call it a day?  youd have to have the designs published before the first one is built, but among other things players can keep the population of small civ units down, which is good in a lot of ways.

the other approach is just an elaboration of StHM's one:  you take the time to make sure you have shipping profits (in particular ROE) really right, and keep track of annual ROE by ship class.  have newer (and larger!) designs assigned tasks preferentially, and where ROE is high you build new ships and where ROE is low you retire.  this is a lot more work and i am not requesting you spend the time... but dare i say it is in the spirit of how aurora is developed and played?   OCD is an ugly disease :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on February 05, 2019, 10:30:52 AM
How about:
New kind of trade good, "Tourists". Special in that Local production cannot satisfy local demand (so you can have both demand and supply on one planet) and requires a special module (liner berths) to transport.

Hey this trade good thing is a hoot. EVERYTHING can be a trade good, from TN minerals to parts of ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on February 05, 2019, 12:03:35 PM
usage rate is a reasonable way to allocate between freight and colony, but liners are going to present some problems.  they have zero idle time, ever, and while you're confined to one system (with very short transit times) their ROE is sky high.  weight by usage or profit and you're going to wind up with a lot of liners and a lot of wealth production.  which is actually *correct* given the economics of aurora, but amounts to an exploit since the economics are so underdeveloped.

i imagine you'd see similar behavior vis a vis colony ships for players who use the infinite wealth earth-moon round trip exploit.

would it be so bad just to let the player decide which types of ships subsidy funds are spent on?   make the "profits squandered" portion a bit higher, and call it a day?  youd have to have the designs published before the first one is built, but among other things players can keep the population of small civ units down, which is good in a lot of ways.

the other approach is just an elaboration of StHM's one:  you take the time to make sure you have shipping profits (in particular ROE) really right, and keep track of annual ROE by ship class.  have newer (and larger!) designs assigned tasks preferentially, and where ROE is high you build new ships and where ROE is low you retire.  this is a lot more work and i am not requesting you spend the time... but dare i say it is in the spirit of how aurora is developed and played?   OCD is an ugly disease :)
You have a solid point about Liners.  They really should be limited by wealth and population.  Rabid_Cog's Tourist trade good idea might work for that.

Player designed civilian ships just add micromanagement to something who's primary benefit is automation.  The lack of direct control is what keeps civilians balanced, game wise.  Civilians are cheap, but they do things on their own schedule, while player built ships are expensive but do what you want when and where you want it done.

Idle time is a good proxy for unexploited profit opportunities, and that actually matters more than current profits when deciding what to build.  If you make $100,000/year and are running off your feet to keep up, you can afford more workers, but if you are making $100,000,000/year and are having trouble keeping all of your workers busy, you stop hiring.


I don't know if Steve still wants Planet X name suggestions, but here goes:
Albus
Argus
Charity
Cuthbert
Filius
Gilderoy
Minerva
Poppy
Rolanda
Quirinus
Horace
Pomona
Remus
Rubeus
Severus
Sybil

I regret nothing.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on February 05, 2019, 12:07:53 PM
How about:
New kind of trade good, "Tourists". Special in that Local production cannot satisfy local demand (so you can have both demand and supply on one planet) and requires a special module (liner berths) to transport.
That's a really good idea and it would prevent the liners from shuttling 500 colonists around constantly while providing both an RP and an in-game mechanical reason for bringing in wealth, plus more traffic in a system.
Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on February 05, 2019, 02:32:18 PM
It would make sense for tourists to be a trade good, but then why can't your regular freighters just stack them into cargo holds like cordwood and dump them off to any colony? :/
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on February 05, 2019, 02:45:38 PM
Because it would require that pre-existing module, luxury berths.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on February 05, 2019, 05:32:35 PM
. . .  The simplest approach would be for each company to limit production based on the number of idle ships of each type, weighted to prefer types with fewer idlers.

A better approach would be for each compan to build only one type of civilian craft (freighter, colony, fuel harvester, etc.).  That way, companies with types with a higher demand will earn more money and build more ships.  Self-regulating.
There are two problems with that method:
1) You need both freighters and colonizers in the early game (read: first year) when you only have one company.
2) Even if you limit to a single type per company, you will still overbuild since your idlers are still a percentage of your working ships.

What I'm proposing is closer to how real shipping companies operate, in that if they have idle assets, they don't build more.  It also directly addresses the problem of idle civilian ships cluttering the game.  And frankly, 5/type/company is probably too high.

You say problem; I say design feature.

If your empire needs something, it should build that thing itself.  I have zero sympathy for the complaint that "the civilians won't pay me to do for me the thing I want them to do."

Frankly, I'd be happier if no civilians at all were generated until one's empire had at least one 10 million pop offworld colony, but I lost that argument a long time ago.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on February 05, 2019, 06:03:19 PM
It would make sense for tourists to be a trade good, but then why can't your regular freighters just stack them into cargo holds like cordwood and dump them off to any colony? :/
Nothing.  That's called 'economy class'.

In seriousness, a case can be made for using overpopulation, unrest, and unemployment to govern migration patterns instead of the current manual control.  The player could then encourage migration to/from certain worlds by paying a migration subsidy.
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on February 05, 2019, 06:43:10 PM
Frankly, I'd be happier if no civilians at all were generated until one's empire had at least one 10 million pop offworld colony, but I lost that argument a long time ago.

Isn't that essentially already implemented? C# requires two populated colonies (including the capital) for freighters and colony ships to be built, and at least two populated systems for passenger liners. Or would the 10 million pop change it significantly?
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on February 06, 2019, 05:23:21 AM
Isn't that essentially already implemented? C# requires two populated colonies (including the capital) for freighters and colony ships to be built, and at least two populated systems for passenger liners. Or would the 10 million pop change it significantly?

Very significantly.  At the moment, the instant the first colonist sets foot on "Moonbase 1" or wherever, the civilians start shipping colonists and free Infrastructure.  As a result, an empire doesn't need lift capacity of its own; one small ship can do the job of creating "designated populations" wherever by dropping off 1 Infrastructure and 0.0001 million population and let the civilians do the rest.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on February 06, 2019, 06:08:37 AM
Frankly, I'd be happier if no civilians at all were generated until one's empire had at least one 10 million pop offworld colony, but I lost that argument a long time ago.

In C# you can set the civilians to "inactive" - after you have the population you want (in your example 10million pop offworld) you set them to active...
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on February 06, 2019, 08:21:19 AM
Isn't that essentially already implemented? C# requires two populated colonies (including the capital) for freighters and colony ships to be built, and at least two populated systems for passenger liners. Or would the 10 million pop change it significantly?

Very significantly.  At the moment, the instant the first colonist sets foot on "Moonbase 1" or wherever, the civilians start shipping colonists and free Infrastructure.  As a result, an empire doesn't need lift capacity of its own; one small ship can do the job of creating "designated populations" wherever by dropping off 1 Infrastructure and 0.0001 million population and let the civilians do the rest.
Not even that. You only need to put down Infrastructure and the civilians will take care of the rest. I haven't built colony ships in years!
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on February 06, 2019, 03:40:59 PM
Isn't that essentially already implemented? C# requires two populated colonies (including the capital) for freighters and colony ships to be built, and at least two populated systems for passenger liners. Or would the 10 million pop change it significantly?

Very significantly.  At the moment, the instant the first colonist sets foot on "Moonbase 1" or wherever, the civilians start shipping colonists and free Infrastructure.  As a result, an empire doesn't need lift capacity of its own; one small ship can do the job of creating "designated populations" wherever by dropping off 1 Infrastructure and 0.0001 million population and let the civilians do the rest.
Not even that. You only need to put down Infrastructure and the civilians will take care of the rest. I haven't built colony ships in years!
And Aurora is balanced for that, both for resource usage and for micromanagement.  There is still room for improvement, but it mostly works as is.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on February 06, 2019, 05:04:19 PM
Isn't that essentially already implemented? C# requires two populated colonies (including the capital) for freighters and colony ships to be built, and at least two populated systems for passenger liners. Or would the 10 million pop change it significantly?

Very significantly.  At the moment, the instant the first colonist sets foot on "Moonbase 1" or wherever, the civilians start shipping colonists and free Infrastructure.  As a result, an empire doesn't need lift capacity of its own; one small ship can do the job of creating "designated populations" wherever by dropping off 1 Infrastructure and 0.0001 million population and let the civilians do the rest.
Not even that. You only need to put down Infrastructure and the civilians will take care of the rest. I haven't built colony ships in years!

C# Aurora will require a population, not just Infrastructure, at the destination to move colonists.  However, it will also give us the ability to move 100 colonists instead of 10,000, so still massively easy to exploit.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on February 06, 2019, 07:00:17 PM
Isn't that essentially already implemented? C# requires two populated colonies (including the capital) for freighters and colony ships to be built, and at least two populated systems for passenger liners. Or would the 10 million pop change it significantly?

Very significantly.  At the moment, the instant the first colonist sets foot on "Moonbase 1" or wherever, the civilians start shipping colonists and free Infrastructure.  As a result, an empire doesn't need lift capacity of its own; one small ship can do the job of creating "designated populations" wherever by dropping off 1 Infrastructure and 0.0001 million population and let the civilians do the rest.
Not even that. You only need to put down Infrastructure and the civilians will take care of the rest. I haven't built colony ships in years!

C# Aurira will require a population, not just Infrastructure, at the destination to move colonists.  However, it will also give us the ability to move 100 colonists instead of 10,000, so still massively easy to exploit.

To be honest I don't think it is an exploit, it is a built in feature and something you want the civilians to do.... why should the state move these items and develop the colonies?!?

The state basically do the initial colonization and spend the upfront resources to do so the civilian economy take care of the rest.

As far as I know the civilians also only move regular infrastructure, if you need other types of infrastructure you need to move it on your own.

There is also a cost in having your civilians move infrastructure which is trade. I don't think you get much wealth if the civilians move infrastructure. At least it would make sense if that would be the case. Them moving the infrastructure is bonus enough in my opinion.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on February 06, 2019, 11:59:21 PM
Isn't that essentially already implemented? C# requires two populated colonies (including the capital) for freighters and colony ships to be built, and at least two populated systems for passenger liners. Or would the 10 million pop change it significantly?

Very significantly.  At the moment, the instant the first colonist sets foot on "Moonbase 1" or wherever, the civilians start shipping colonists and free Infrastructure.  As a result, an empire doesn't need lift capacity of its own; one small ship can do the job of creating "designated populations" wherever by dropping off 1 Infrastructure and 0.0001 million population and let the civilians do the rest.
Not even that. You only need to put down Infrastructure and the civilians will take care of the rest. I haven't built colony ships in years!

C# Aurira will require a population, not just Infrastructure, at the destination to move colonists.  However, it will also give us the ability to move 100 colonists instead of 10,000, so still massively easy to exploit.

To be honest I don't think it is an exploit, it is a built in feature and something you want the civilians to do.... why should the state move these items and develop the colonies?!?

The state basically do the initial colonization and spend the upfront resources to do so the civilian economy take care of the rest.

As far as I know the civilians also only move regular infrastructure, if you need other types of infrastructure you need to move it on your own.

There is also a cost in having your civilians move infrastructure which is trade. I don't think you get much wealth if the civilians move infrastructure. At least it would make sense if that would be the case. Them moving the infrastructure is bonus enough in my opinion.
IIRC, they will move low gravity infrastructure, but only to/from low gravity worlds, which is going to be 'fun' for your first LG colony, and I do believe it still counts as trade.  But as you say, I'm just glad I don't have to pay for it.   :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on February 07, 2019, 03:07:37 AM
Quote from: SpikeTheHobbitMage link=topic=9841.msg112710#msg112710
IIRC, they will move low gravity infrastructure, but only to/from low gravity worlds, which is going to be 'fun' for your first LG colony, and I do believe it still counts as trade.  But as you say, I'm just glad I don't have to pay for it.   :)

I really hope they only move LGI from acceptable-grav worlds, and only to Low-Grav worlds.

Or a lot of Alzairians are going to die.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on February 07, 2019, 10:37:20 AM
Quote from: SpikeTheHobbitMage link=topic=9841.msg112710#msg112710
IIRC, they will move low gravity infrastructure, but only to/from low gravity worlds, which is going to be 'fun' for your first LG colony, and I do believe it still counts as trade.  But as you say, I'm just glad I don't have to pay for it.   :)

I really hope they only move LGI from acceptable-grav worlds, and only to Low-Grav worlds.

Or a lot of Alzairians are going to die.
I may have misread (or misremembered) Steve's post on the matter, but it seemed that only low-grav worlds produce LGI.

That would be a fun bug, in the Dwarf Fortress sense.
Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on February 07, 2019, 08:42:09 PM
So it seems there needs to be a check to see if a population has spare unused LGI capacity before it gets moved. or maybe a toggle in the civilian screen where you can choose if the planet imports of exports LGI in the same vein as the civilian colonization status screen.
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on February 07, 2019, 08:50:36 PM
I'm pretty sure that in VB6 civilians take infrastructure as a trade good and transform it into "actual" infrastructure at the destination, so that there isn't any loss on the source world. If it works the same for LGI in C#, there shouldn't be any issue of mass die-offs.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on February 07, 2019, 09:15:35 PM
I'm pretty sure that in VB6 civilians take infrastructure as a trade good and transform it into "actual" infrastructure at the destination, so that there isn't any loss on the source world. If it works the same for LGI in C#, there shouldn't be any issue of mass die-offs.
Yes, that is exactly how it works.  If you want installed infrastructure moved, you have to pay the shipping fees or move it yourself.  On top of that, trade good infrastructure can't be converted in place.  It must first be loaded onto a civilian freighter to become 'real'.
Title: Re: C# Aurora v0.x Suggestions
Post by: sublight on February 08, 2019, 01:56:29 PM
I always assumed Small tank prices were such to avoid making internal HTK too cheap, but that did leave the Standard fuel tanks feeling over priced. It's nice to see those costs revisited.

The new Tiny/Small/Standard costs look great, but I'm concerned that the bigger tanks now feel too cheap. It feels wrong that the material costs increase even slower than surface area.

So... I guess I'm suggesting the fuel tank costs be tweaked to scale directly with surface area, or size^(2/3).

Fuel Storage - Tiny: 5,000 litres, 0.5 BP
Fuel Storage - Small: 10,000 litres, 0.8 BP
Fuel Storage - Standard: 50,000 litres, 2 BP
Fuel Storage - Large: 250,000 litres, 6 BP
Fuel Storage - Very Large: 1,000,000 litres, 17 BP
Fuel Storage - Ultra Large: 5,000,000 litres, 50 BP
(costs derived at pegging 10,000L as .8, then rounding the other costs down)
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on February 08, 2019, 02:10:59 PM
That seems like a good way to do it to me.
Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on February 08, 2019, 07:09:06 PM
Seems reasonable.
Title: Re: C# Aurora v0.x Suggestions
Post by: KingEdward9830 on February 09, 2019, 01:55:49 AM
I really shouldn't be posting this late at night, but I hope once this rewrite is done you can look into some higher-tier techs.  Just a fun little idea: Super-intelligent AIs could be a bit of a "gamble" type tech, if you create a friendly one it'll enhance research/industry in whatever area it's built for exponentially, but if you create a rogue one(see: paperclip maximizer problem). . .  You're in for a bad time.
Title: Re: C# Aurora v0.x Suggestions
Post by: DEEPenergy on February 13, 2019, 05:53:01 PM
Civilian asteroid miners. Along with the ability to ban them from bodies/systems  :)
Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on February 13, 2019, 08:04:54 PM
That should be an option, if a roll is made for CMCs and the body is suitable for asteroid miners then an equivalent batch of miners could be assembled and launched.
Title: Re: C# Aurora v0.x Suggestions
Post by: procdrone on February 13, 2019, 09:55:49 PM
This is but a simple UI improvement suggestions.

1.  Add a button to galactic map, which allows jumping straight to the currently selected system view.

2.  In Task force UI, remove selecting Task forces from the dropbox(which I find greatly inconvenient, given number of various TFs you gather later in the game), and make a combo box with a full list on the left side of the TF window.
To be fair, the systems list in the system view could be similarly treated.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 14, 2019, 03:37:25 AM
This is but a simple UI improvement suggestions.

1.  Add a button to galactic map, which allows jumping straight to the currently selected system view.

2.  In Task force UI, remove selecting Task forces from the dropbox(which I find greatly inconvenient, given number of various TFs you gather later in the game), and make a combo box with a full list on the left side of the TF window.
To be fair, the systems list in the system view could be similarly treated.

1) You can double-click on systems (in VB6 too) to open the system view.

2) The fleet window is completely different in C# (check the changes or screenshots threads) and has a fleet hierarchy, not a dropdown.
Title: Re: C# Aurora v0.x Suggestions
Post by: procdrone on February 14, 2019, 04:23:05 AM
Quote from: Steve Walmsley link=topic=9841. msg112804#msg112804 date=1550137045
Quote from: procdrone link=topic=9841. msg112799#msg112799 date=1550116549
This is but a simple UI improvement suggestions. 

1.   Add a button to galactic map, which allows jumping straight to the currently selected system view. 

2.   In Task force UI, remove selecting Task forces from the dropbox(which I find greatly inconvenient, given number of various TFs you gather later in the game), and make a combo box with a full list on the left side of the TF window. 
To be fair, the systems list in the system view could be similarly treated.

1) You can double-click on systems (in VB6 too) to open the system view. 

2) The fleet window is completely different in C# (check the changes or screenshots threads) and has a fleet hierarchy, not a dropdown.

Double clicking on a system in the galaxy view only brings up the "F9" (System Generation and Display), and not the System Map, the thing im suggesting.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 14, 2019, 06:54:09 AM
Double clicking on a system in the galaxy view only brings up the "F9" (System Generation and Display), and not the System Map, the thing im suggesting.

Ah, terminology confusion. F9 to me is the System View and what you call the system map is the tactical map (as opposed to the galactic map).
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on February 15, 2019, 04:34:49 PM
In the other thread, people are talking about trading ship components between player races.

I know that the planned diplomacy system is a long ways off, but I'd like to suggest:

Making it possible to trade technologies between NPRs. Currently, you can set it so newly discovered technologies can be shared between friendly/allied NPRs, but it'd be nice to have an option to trade previously discovered technologies with allies or exchange knowledge with neutral races.

Making it possible to trade ship components directly, or to grant a "production license" allowing a race to build components they wouldn't normally have access to.

I'd also like to suggest making it possible to steal component technologies through espionage. This is currently possible with missiles, but not other components. If a race has the prerequisite technology to build it, it should be possible to steal the plans for a component.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on February 15, 2019, 05:05:14 PM
C# has had a bunch of QoL changes that makes certain things a lot easier, but I think a big on is allowing conditional orders to use order presets (i.e go to planet X, moon Y and asteroid Z, transit to system A and refuel at station B) and also, as you considered earlier in the changes list, adding ship level conditional orders. This would let you, say, bring fuel from your homeworld to FoB once it reaches a certain level automatically. One can already have the ship making the trip 24/7 but this would give it some extra finesse and flexibility.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on February 17, 2019, 11:05:19 AM
Importing/exporting ships. They can only be added if the required technology was researched by that player or the player is in sm mode. There are a lot of designs I like in the design bureau but it's a bit inconvenient having to figure out what technology was used for it.
Title: Re: C# Aurora v0.x Suggestions
Post by: tobijon on February 17, 2019, 11:21:39 AM
Importing/exporting ships. They can only be added if the required technology was researched by that player or the player is in sm mode. There are a lot of designs I like in the design bureau but it's a bit inconvenient having to figure out what technology was used for it.
that's a bit of a problem considering the research of components, I don't see a viable way to solve that.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on February 17, 2019, 11:29:02 AM
What I'd imagine is that the data is stored has the components with the technology required and the attributes to it (size/fuel eff.) which the program can parse into a usable ship. Then the ship "class" will just contain all the references to the components and how many of them are in the ship. Though before any of this is parsed, there are checks to make sure that the technology has been researched already by comparing the Empire tech and a list of the minimum technology required to design that ship. What I'm thinking is likely an inefficient form of data storage but it's possible to do.
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on February 17, 2019, 03:06:48 PM
 - How about adding a checkbox that allows the player to determine whether a drive is a Military Engine or a Commercial Engine? Perhaps with a third option for an Intermediate Engine, an option which which might be selected by NOT checking any of the other two? The Military Drives would be heavier than the other two, while having more HTK per tonnage; whilst the Commercial versions would produce better fuel economy than the other two, but suffer from having fewer HTK per tonnage than them. Meanwhile the Intermediate Drives would have balanced stats which served as the baseline. Only Military engines would require Maintenance by default, while Intermediate and Commercial Drives would only require Maintenance if the ship had Military Components.

 - I think that would be a cool idea! It would make things more robust in the balance department, making single engine ships more useful. I think Reactors could benefit from something like this as well; with Military Reactors having more HTK per ton, but also weighing more; while Commercial Reactors create more output than the Military and Intermediate ones, but suffer from less HTK per ton than them. Again, intermediate versions would be a baseline; middle of the road variety. I also think between the Military, Commercial, and Intermediate versions, there should be a difference in the cost to build them. Likewise to this, I'd like to see a "Civil Defense" style of weapons, which would enable Civilian designs to have weapons while being classed as commercial ships, but at the cost of the "Civil" grade weapons being of poor quality. It could even potentially pave the way for export models of weapons and ships.

 - If you were to make Armored Engines and Armored Reactors a thing, then it would become even more robust, allowing the player the ability to trade weight for HTK, overall reducing speed to increase survival rates. This would give players a reason to make single engine ships, as one big engine with armor will be significantly lighter than two big engines without. Coupled to the fuel requirements of larger engines and increased HTK of Military engines, this could make single engine designs quite useful. Likewise, the options are further increased when considering the cost / weight ratio of Intermediate Engines / Reactors with similar or greater Armoring; while the greater cost efficiency and fuel economy of large Commercial Engines might make a heavily armored version desirable for fast and tough ships.

 - Less of a suggestion and more of a request. Can we please mount more than one type of engine on a ship? I understand if it's difficult to program or something, but I just figured I'd ask.

 - EDIT: Also, can we have an option for single man fighters? Perhaps a "Fixed Crew" option which would impose a degraded performance penalty to someone trying to fire, maneuver etc. Maybe dedicated "Fighter" versions of weapons which are much smaller, lighter and cheaper... but can only be mounted on Fighters? Perhaps a dedicated Fighter Training installation to counter the degraded performance, but only for Fighters? Maybe a Fast-Attack Craft class (500-1000 tons) which benefits from that installation? However it needs to work, I really just want to have the ability to control the crew requirements of my Fighters, single man crew, two-man Pilot / Gunner configs, three man Pilot / Gunner / Sensors setup, or even Turret Gunners for big bomber / interdiction craft. That's all. The above are just some suggestions as to how I think such a feature might end up looking like.

 - ANOTHER EDIT: Regarding dedicated "Fighter" components, maybe additional Flight Crew needs for stuff like Lasers, since maintenance is a thing. Or special Fighter Hangars that allocate berths and tonnage to the needed support crews and their equipment. Possibly a component that provides dedicated fuel capacity to Fighter class craft, or one that provides Magazine Capacity for up X number of Fighter ships with Class 1-3 missiles, etc.?
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on February 17, 2019, 03:43:32 PM
That change to engines would mean that Steve would have to rework the engines and their scaling completely, for no good reason.

It is entirely possible to create 1-man fighters already. As for the other fighter stuff, Steve has stated that he wants to move away from special rules as much as possible - this is the reason why PDCs were scrapped in C# and why engines and sensors are now uniform across all sizes and purposes. If you want to create a 1-pilot or 2-pilot fighters, have them with minimal deployment time and using either box launchers or reduced size gauss cannons, and just the fire control with no other sensors.
Title: Re: C# Aurora v0.x Suggestions
Post by: BlueWinds on February 21, 2019, 11:45:22 AM
In VB6 Aurora, I always end up turning off Inexperienced Fleet Penalties for one reason - when a ship is processing new orders, it comes to a dead stop, which is often fatal in the case of dangerous battles.

Would it be possible to have ships continue moving to their previous destinations while processing new orders (or perhaps continue their previous orders entirely, possibly including continuing to shoot)? It seems more realistic - a ship in a firefight (the only time I really care about reaction time) isn't about to just cut its engines and turn into a sitting duck while the officers confer! (and how were the green gunners disciplined enough to cease fire the moment the 'message from command' light blinked?)
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on February 22, 2019, 10:43:11 AM
Option to get get rid of the hull prefix on the name of individual ships? (i.e. gsv, gev).
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on February 22, 2019, 12:12:17 PM
Option to get get rid of the hull prefix on the name of individual ships? (i.e. gsv, gev).

This can be easily worked around by adding a new 'blank' class type, with a three-character abbreviation of three spaces.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on February 24, 2019, 04:56:20 PM
Since its time for AI combat programming, there are two aspects of AI targeting that can serve both player and AI equally well, the first is an improvement to missile PD, the second is an improvement to offensive missile fire.

For missile PDFor offensive use:Miscellaneous QoL



A thought on how to organise a feature such as the salvo size/quantity engagement.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on February 25, 2019, 02:25:45 AM
A few other thoughts on the AMM piece:

- I often find myself with groups of AMM ships where one two have fully expended all of their ammo whilst others in the fleet have full mags which I assume is due to some ships always selected as firing first. This isn't much of an issue in VB6 because of instant ordnance transfer but I can see it becoming a real bug in C#. If the firing order could just be switched to whichever ship has the fullest magazines I think that would go a long way to help.

- On wasted AMMs I think I have mentioned before that having a minimum engagement range for AMMs as well as the current maximum would again help with using layered missile and PD fire.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on February 26, 2019, 01:54:03 AM
Noticed a flaw in how I laid out my concept above.  I didn't adequately consider salvos with no target set.  As described above, your ships wouldn't shoot on passively guided missiles that were sent to a waypoint that will let them see and target you themselves, until such time as they actually target you.  Possibly a valid approach, but liable to get you killed and opens an AI exploit.

Perhaps have missiles with no target register with every task group they could reach with some weighting for their approach angle, and unregister themselves as time goes by and they no longer have the range to reach that task group, or once they go live and pick a target.

The target ships wouldn't shoot on absurdly distant salvos, they can't even detect them probably, and FC/AMM ranges limit their firing, it adds cost, but minor, and ships which can engage, will engage missiles that have no targets set yet.

A few other thoughts on the AMM piece:

- I often find myself with groups of AMM ships where one two have fully expended all of their ammo whilst others in the fleet have full mags which I assume is due to some ships always selected as firing first. This isn't much of an issue in VB6 because of instant ordnance transfer but I can see it becoming a real bug in C#. If the firing order could just be switched to whichever ship has the fullest magazines I think that would go a long way to help.

- On wasted AMMs I think I have mentioned before that having a minimum engagement range for AMMs as well as the current maximum would again help with using layered missile and PD fire.
A round robin engagement pattern would smooth that out considerably, with the assumption that ships not ready to fire are skipped over by those who are.  You'd still run dry in one ship before others, potentially much earlier if their designs aren't well suited to equal expenditure/endurance, but at least it wouldn't be one empty and others full, they'd all be depleted, and if they were the same class, very nearly all depleted together.

I didn't try to sort out the order in which the FC's were evaluated as able/ready to fire above.  If each ship that can engage in missile PD is kept in a queue, then you iterate over the queue, and move any ship which opens fire to the rear, even if its just one FC or many that fired, you could spread the workload across every ship with a capable FC before ever having a ship shoot a second time.

A minimum engagement range would also be very nice, and it would play well with both of my above suggestions, offensive and defensive AI control of weaponry.

I stuck to just the bare minimum I saw to be useful, but the complete set of criteria I'd love to have shared for both PD and offensive firecontrol: Min range, max range, min TCS, max TCS, weapons per engagement.  For PD specific FC, the salvo size and quantity settings to effectively attempt a defence against saturation attacks, as well as a priority, changing the round robin firing queue to a priority queue.

You could then limit AMM fire in ASM roles to anti fighter work for example, or prevent your 200 damage ship killers from being spent on fighters, and can layer your defence so long range and short range AMM is a thing the AI FC respects.

With the priority queue, every ship with a defensive missile might not engage, because a high priority FC might be busy as hell keeping the fleet safe, but those low priority FC's will step in if the high priority FC is ever so busy that there is work left over.

Think modern fleet defense.  If you have 16 missiles, and a single FC channel, you could certainly engage a lone inbound, but if there is a ship with an even better missile than you carry, and/or with much deeper magazines, and more FC channels, and its in a position to offer a better defense than you, they should shoot, not you. You should save your limited defence for when it really matters, saturation attacks.   FC Priorities let the player affect the queue in this way, by causing an 'important' FC to keep cutting in near the front of the line instead of moving to the rear every time it engages, while still spreading the work equally across FC's with equal priorities.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on February 26, 2019, 11:07:24 AM
How would one ship know that it has more missiles left than another ship? Do the ship computers talk to each other automatically or does it require the crew to communicate such decisions? Could networked combat groups be a new research tech and ship module? And what if I want one ship to empty its magazines first, so that it can be detached and sent back for resupply, instead of all AMM escorts running dry at the same time?
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on February 26, 2019, 11:36:05 AM
And what if I want one ship to empty its magazines first, so that it can be detached and sent back for resupply, instead of all AMM escorts running dry at the same time?

Then I think you're stuck transferring munitions after the battle.  Amram's 'priority queue' might deliver what you want; otherwise you'll probably need to handle it manually.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on February 26, 2019, 12:49:27 PM
One other thought on combat around ships dropping out of formation when they suffer engine damage. In many situations I want to keep that damaged ship well within the protection of the larger formation and therefore often end up resetting speeds in order to get them back in formation. Maybe a conditional order that says slow formation to the slowest ship in the group rather than just ejecting it would be possible? You could then have this off if its a case of lose that ship or lose lots more or keep on if you have an overall focus on keeping as many ships alive as possible.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on February 26, 2019, 02:07:02 PM
How would one ship know that it has more missiles left than another ship?
They wouldn't. 

Rather they'd simply take turns engaging.  Every ship is "lined up" in a queue, and the ship occupying the front of the queue gets to shoot next.

Fire one round, back of the line.  Fire 8 rounds, back of the line.  You got to shoot, you go to the back of the line.  If you have 4 ships, with 2 FC's each, and get 4 salvos to fire at, they'd each fire on one salvo with one of the FC's, then move to the back of the line, and the next ship would fire.  Rather than have 2 ships fully spent and two idle that increment, you'd have 4 ships half spent.

It won't entirely "fix" imbalances, but it would fix having one ship sit there and completely deplete its stocks while the others twiddle their thumbs and watch it do all the work.

Your magazine levels would look like armor does after a nasty battle, some completely out, some with a few salvos left, maybe some with a lot left.  But generally speaking, they'd all be spent and low when you ran out.
Do the ship computers talk to each other automatically or does it require the crew to communicate such decisions? Could networked combat groups be a new research tech and ship module?
It would essentially be crew/computers handling it as far as the lore goes.  From a programming perspective, if it were me, it'd be the taskgroup object that handles the taskings, rather than ships trying to work it out amongst themselves. 

I wouldn't be opposed to a dedicated component and/or research offering the capability.  The fire controls are really a very small part of the combat systems on modern warships, so why not, seems a sensible addition.
And what if I want one ship to empty its magazines first, so that it can be detached and sent back for resupply, instead of all AMM escorts running dry at the same time?
The priority queue has you covered. 

If it helps, think of the priorities as a form of "reload" on the firecontrols, which isn't based on time, but on waiting for their turn.  Higher priorities then 'reload more quickly" than lower.

If you want everyone to take fair turns, keep the priorities equal.  Then every ship will wait its turn to use an FC, and when it shoots, it moves to the back* of the queue and doesn't get tasked with firing again until everyone else ahead of it in line has fired.  If everyone else is reloading, whatever ship is not reloading is going to get to shoot again even if it wasn't technically next.

* back of the queue depending on its own priority of course, so it might not be the back, but not the front of the queue either, it depends on the priority.

If you want one ship to fire more often, ensure its priority is higher than the others, either because you lowered theirs, or raised its.  Higher priorities don't go to the very back of the line unless its a very short line, then sometimes they will, but not always.  Its very dependent on the exact implementation of a priority queue as to exactly how it would behave, and how the weightings are applied, but its very possible to have priorities so much higher that you never leave the front of the queue at all, and are first up every single time, or so low you never get to the front and so never get to shoot.

So you raised its priority significantly.  Now that ship is involved in every engagement it possibly can, and the only time another ship fires is if there were too many targets for that one ship to fire on them all in that increment.

The entire point of the priority queue was to provide a means that we players could have an aegis like warship, perhaps a newer model, or has more launchers, or deeper magazines, or some combination of, that takes over the bulk of missile defence, and any lesser missile defence ships in the task force go from active roles, to lest active or even idle until a saturation attack happens, just because they have lower priorities.


This could also be accomplished somewhat using the salvo qty/size controls.  If one ship is configured to a lower threshold for salvo count, or missiles per salvo, it will still be firing when the other ships have decided they have depleted the salvos enough for PD to handle and stopped.

Coercing one ship to outwork the others is very possible with this system, and you'll never have to worry about accidentally forgetting to enable someones firecontrol when that overachiever leaves the taskgroup.

Any other concerns, or perhaps these aren't fully clarified yet?  Seriously, bring it on, a good idea can take it, and i'd like to consider any flaws this has that I haven't thought of.

edit:
currently building a little priority queue firing order demo in python to give an interactive example.  I'll be back.
Title: Re: C# Aurora v0.x Suggestions
Post by: dukea42 on February 26, 2019, 04:59:22 PM
I like what you are saying but a little clarrification from sounding confusing.  What you described doesn't need "significant" priority spacing/raising.   Simply giving your primary the priority '1' and all others priority '2' would accomplish the desired effect as long as the '1' ship can reload faster than the incoming waves.   (And what AMM ship can't load faster than ASM ships. )

The mess of complications is when ships in the '2' queue have a longer range and and shoot sooner.   Do they?
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on February 26, 2019, 08:01:47 PM
the process of selecting the firing ship from the queue should skip over ships which cannot engage, in favour of those that can.

Basically, aurora, right now in 7.1, goes ship by ship, firecontrol by firecontrol, and tries to use each on in turn.  if its busy, damaged, nor loaded, etc, aurora moves on and tries the next on, until everything is shot at.

I would expect the same even with the priority queue.  The difference is in the order in which we let the ships try to shoot.  Rather than pick one ship, and try every FC, or always pick the same ship first, we spread it out across all ships and all FC's, so that each gets a turn, or not depending on priority setting.

If you had only one ship that could shoot right now, range, ammunition, any reason, that ship should shoot, even with the priority queue suggesting its not next in line.  There is no one else ahead of it to select, it is next.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on February 27, 2019, 05:31:38 PM
The script is now ready to demo the concept.

I've launched a separate thread for it over here: http://aurora2.pentarch.org/index.php?topic=10274.0
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on March 01, 2019, 07:48:58 PM
Minor suggestion, but in addition to the min/max NPR generation range setting, would it be possible to add a maximum number of spacefaring NPRs setting?
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on March 01, 2019, 08:16:12 PM
A little too late for this one, but food for though come post-launch.

Shipyards should probably remain planet locked, but a fighter factory module could be an interesting way of adding deep space production capabilities. It would give fighters a major logistical advantage, as replacing them when far away from home would be easier, which would codify their role a little more now that big ships have been noticeable buffed. Perhaps ground force training modules would be interesting as well, letting outposts produce supplies and reinforcements for long ground wars at a slow pace.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on March 01, 2019, 10:43:38 PM
I think a dedicated ship module that has that ability would be ideal.  Think about it, we have salvage modules that can cope with bigger tonnages, whats a fighter to something the size of a huge warship.  We can make hangars vastly larger than any single fighter.

We can have both the industrial ability, and the protected space to work, why not a ship module for that task?

If your carrier can rebuild its fighter wing on its own.....
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on March 02, 2019, 01:15:15 AM
What would we be building fighters out of? TN minerals is an option, but would require either a new, smaller cargo hold or keeping a freighter with the fleet.
The problem is, how much space does this take? If you take all the TN minerals that comprise a 500 ton ship, it weights far less than 500 tons. The logical conclusion is therefore, that while we only consider the TN minerals in the cost of ship construction, the remaining ship mass is taken up by conventional metals that are abstracted away. On a planet that abstraction works, but on a starship? Where do those metals come from?
Alternatively, it can be built out of "fighter parts", a new maintenance parts-like object. These would have to be built on planet and shipped, same as a fighter. At which point, what is the real gain? Slightly increased storage efficiency at best since you need space to store the parts and space for the assembly module, and all that space could have been devoted to having a larger fighter complement ready to fly.

The real problem that I can see, however, is that if it becomes viable to construct/assemble fighters in space... why would it not be viable to construct/assemble missiles in space? And that is a far greater logistical change than building fighters in space.
Title: Re: C# Aurora v0.x Suggestions
Post by: Graham on March 02, 2019, 08:55:30 AM
As stated above, the components to build a fighter must weigh at least as much as the fighter.

The bigger issue I see is that building a fighter with access to all the materials and industry on a planet is very different to building a fighter in a vacuum (excuse the pun). You have to build every processor from the raw silicon. You have to refine polymers for fittings.
The point is a fighter factory is a 25kt object with a huge worker requirement, and it doesn’t have to do any of the above.

You can already set up an orbital habitat (or soon some low g infrastructure) on a small asteroid with some auto mines and produce fighters there. I don’t see the need or sense behind anything more mobile than that.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 02, 2019, 02:08:57 PM
The problem is, how much space does this take? If you take all the TN minerals that comprise a 500 ton ship, it weights far less than 500 tons.

As stated above, the components to build a fighter must weigh at least as much as the fighter.

Incorrect.  Aurora ships are measured by displacement, not by mass.  A "500 ton fighter" is 500 tons because it displaces 500 "tons" of Luminiferous AEther.

Whether the Trans-Newtonian Elements are all there is to an Aurora unit, or if it also includes conventional materials (and if so, how much) is left to the individual player's fiction.

None of which is an argument for or against a space-based module for small craft (and/or munitions) production.  I remember when gate constructors needed five standard-cargo-hold-sized components to build a jump gate, and the myriad problems that caused due to failed delivery, interrupted production, and disappearing components.  About the only JGCSs that functioned reliably were those built with five internal cargo holds and which 'reloaded' their jump gate components at a proper colony after each build.

Would "portable" small craft and/or munitions production be fun?  Probably.  People seemed to like the Machine Shops in Starfire.  Would they add signifcant gameplay decisions?  Maybe.  If they were 100% as efficient as a ground installation at production -- especially if they could manufacture while moving -- they'd be overpowered, even though they'd require significant organizational overhead in terms of delivering (or holding) raw materials.  I'm pretty sure you'd want significant cargo hold capacity on each such unit.

I think such units should be limited to manufacturing out of their own, on-board cargo holds, requiring significant cargo-handling operations to feed.  I don't want to drown the idea in micromanagement, but having just instituted a series a rule changes to fix 'instant reload' and 'instant fuel transfers' and such, it seems a foolish gap to allow full-on production out of an adjacent cargo freighter.
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on March 02, 2019, 03:20:52 PM
I'd really like very small cargo bays, like tiny and fighter sized ones. And maybe the same for Maintenance storage.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on March 02, 2019, 06:28:53 PM
The module would definitely require the fighters worth in minerals, that much is certain. I think that the minerals having to be in the same ships cargo holds would be a good balancing decision. The question becomes how to make the modules less efficient then their ground based counterparts. Less BP per module? Maybe they cost more? I'm not entirely sure, nor am I sure how the U.I would handle it (perhaps the ability to designate ships to be shown in the pop screen? Perhaps using the fleet window?).

As for ordinance production I can see that having a module as well with the same limitations. If more then one construction module existed perhaps there should be a tech line for their efficiency. Honestly I think that most planetary functions should be capable of being outsourced to stations and ships. This is mostly because I want to run a nomadic civilization game at some point where I can't permanently colonize anything. This is more or less impossible under current rules.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 02, 2019, 07:38:48 PM
I would expect the 'efficiency' issue to be handled with a new tech line.  Mobile/module small craft and/or ordnance factories would operate at 10%, 12.5%, 16.667%, 20%, 25%, 33.333%, 50%, 66.667%, 75%, 90%, etc.

Since terraforming, fuel refining, salvaging, asteroid mining, etc. all currently do not function while ships are in motion, I would assume that the new modules also would not.  There is an argument to made that like repairs/damage control this could be carried out underway, but I think game balance on the whole is better served by treating it as impossible.
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on March 02, 2019, 07:48:50 PM
So here's a kind of out-there suggestion for improving performance:

Detection is a major performance bottleneck. Each ship in a system apparently has to check if it detects every other ship in the system every sub-pulse, which is extremely database and computationally expensive. In my multifaction game, turning on sensors in SM mode takes the game from a 20-second 5-day increment to about five minutes. But it's also presumably they same algorithm every time, something like:

for every non-faction ship in the system, subtract this ship's position vector from that ship's position vector, take the magnitude of the result, and compare it against the maximum sensor range for the target ship, which is the sensor size times strength times sensitivity times some exponential that takes into account the sensor resolution and the other ship's mass.

The thing is, every PC has a specialized piece of hardware for doing lots of these kinds of parallel-data vector computations very very quickly - the GPU. Have you ever explored GPU programming? It looks like there are hardware-agnostic GPU programming libraries available. Granted, I have no idea how easy it'd be to incorporate that into a C# winforms program. Just thought I'd throw it out there as something to think about for the future. It could also be used to speed up orbital motion - one of my CS professors showed us a demo once of an n-body gravity simulation with several thousand particles running in real time using GPU programming.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on March 02, 2019, 09:19:53 PM
The problem is, how much space does this take? If you take all the TN minerals that comprise a 500 ton ship, it weights far less than 500 tons.

As stated above, the components to build a fighter must weigh at least as much as the fighter.

Incorrect.  Aurora ships are measured by displacement, not by mass.  A "500 ton fighter" is 500 tons because it displaces 500 "tons" of Luminiferous AEther.

Whether the Trans-Newtonian Elements are all there is to an Aurora unit, or if it also includes conventional materials (and if so, how much) is left to the individual player's fiction.

None of which is an argument for or against a space-based module for small craft (and/or munitions) production.  I remember when gate constructors needed five standard-cargo-hold-sized components to build a jump gate, and the myriad problems that caused due to failed delivery, interrupted production, and disappearing components.  About the only JGCSs that functioned reliably were those built with five internal cargo holds and which 'reloaded' their jump gate components at a proper colony after each build.

Would "portable" small craft and/or munitions production be fun?  Probably.  People seemed to like the Machine Shops in Starfire.  Would they add signifcant gameplay decisions?  Maybe.  If they were 100% as efficient as a ground installation at production -- especially if they could manufacture while moving -- they'd be overpowered, even though they'd require significant organizational overhead in terms of delivering (or holding) raw materials.  I'm pretty sure you'd want significant cargo hold capacity on each such unit.

I think such units should be limited to manufacturing out of their own, on-board cargo holds, requiring significant cargo-handling operations to feed.  I don't want to drown the idea in micromanagement, but having just instituted a series a rule changes to fix 'instant reload' and 'instant fuel transfers' and such, it seems a foolish gap to allow full-on production out of an adjacent cargo freighter.
For ships in real life, displacement equals weight.  The water a ship displaces weighs as much as the ship.  I don't see any reason for this to not be true in Aurora.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 02, 2019, 09:39:48 PM
For ships in real life, displacement equals weight.  The water a ship displaces weighs as much as the ship.  I don't see any reason for this to not be true in Aurora.

Sometimes -- but for ships in real life, displacement doesn't (always) equal displacement.  There's light displacement and full load displacement and standard displacement and Washington displacement and effective displacement and (calculated) waterline displacement . . .

Not to mention net weight or gross weight or deadweight or any of the myriad other means of measuring ships.

Back in the very beginning, Aurora did everything in hull spaces.  But we clamoured for for a more 'realistic' measurement system.  Aurora's armour calculation assumes a perfectly spherical ship, and its engine power-to-speed formula assumes cargo holds (and hangars, and fuel tanks, etc.) impart the same 'drag' on a ship whether full, empty, or somewhere in between.

So units (ships, small craft, ordnance) are technically designed and built in Hull Spaces and then assigned a calculated value for theoretical displacement of Luminiferous AEther. . . listed in 'tons' for convenience sake, but still just as much as violation of the laws of physics as TNEs themselves.
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on March 02, 2019, 10:19:31 PM
The problem is, how much space does this take? If you take all the TN minerals that comprise a 500 ton ship, it weights far less than 500 tons.

As stated above, the components to build a fighter must weigh at least as much as the fighter.

Incorrect.  Aurora ships are measured by displacement, not by mass.  A "500 ton fighter" is 500 tons because it displaces 500 "tons" of Luminiferous AEther.

Whether the Trans-Newtonian Elements are all there is to an Aurora unit, or if it also includes conventional materials (and if so, how much) is left to the individual player's fiction.

None of which is an argument for or against a space-based module for small craft (and/or munitions) production.  I remember when gate constructors needed five standard-cargo-hold-sized components to build a jump gate, and the myriad problems that caused due to failed delivery, interrupted production, and disappearing components.  About the only JGCSs that functioned reliably were those built with five internal cargo holds and which 'reloaded' their jump gate components at a proper colony after each build.

Would "portable" small craft and/or munitions production be fun?  Probably.  People seemed to like the Machine Shops in Starfire.  Would they add signifcant gameplay decisions?  Maybe.  If they were 100% as efficient as a ground installation at production -- especially if they could manufacture while moving -- they'd be overpowered, even though they'd require significant organizational overhead in terms of delivering (or holding) raw materials.  I'm pretty sure you'd want significant cargo hold capacity on each such unit.

I think such units should be limited to manufacturing out of their own, on-board cargo holds, requiring significant cargo-handling operations to feed.  I don't want to drown the idea in micromanagement, but having just instituted a series a rule changes to fix 'instant reload' and 'instant fuel transfers' and such, it seems a foolish gap to allow full-on production out of an adjacent cargo freighter.
For ships in real life, displacement equals weight.  The water a ship displaces weighs as much as the ship.  I don't see any reason for this to not be true in Aurora.

The weight of water displaced by a ship is equal to the ship's mass because the water exerts a buoyant force (https://en.wikipedia.org/wiki/Buoyancy) on the ship. A ship in the aether wouldn't experience this force. It would "displace" an equal volume, not mass of aether. Whether aether has mass at all I don't think is defined.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on March 03, 2019, 02:57:24 AM
After reviewing the actual numbers, it seems the numbers are closer than I first thought.
1 mineral weighs (displaces) 2 tons. The example geosurvey ship in the wiki is 550 tons and 151 BP. 151 BP = 151 minerals total needed for construction. That is raw weight of 302 tons and therefore not unreasonable that the resultant ship displaces 550 tons in the Aetherium.
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on March 03, 2019, 11:22:38 AM
What would we be building fighters out of? TN minerals is an option, but would require either a new, smaller cargo hold or keeping a freighter with the fleet.
The problem is, how much space does this take? If you take all the TN minerals that comprise a 500 ton ship, it weights far less than 500 tons. The logical conclusion is therefore, that while we only consider the TN minerals in the cost of ship construction, the remaining ship mass is taken up by conventional metals that are abstracted away. On a planet that abstraction works, but on a starship? Where do those metals come from?
Alternatively, it can be built out of "fighter parts", a new maintenance parts-like object. These would have to be built on planet and shipped, same as a fighter. At which point, what is the real gain? Slightly increased storage efficiency at best since you need space to store the parts and space for the assembly module, and all that space could have been devoted to having a larger fighter complement ready to fly.

The real problem that I can see, however, is that if it becomes viable to construct/assemble fighters in space... why would it not be viable to construct/assemble missiles in space? And that is a far greater logistical change than building fighters in space.

maybe a  Fighter Assembler Module. provided that you have within the Taskgroup
A) all the major components (prefabricated at a construction facility) of the wanted fighter design
B) MSP equal to max repair of the fighter design
C) hanger space for the fighter to dock after completion
you give the Taskgroup an order to 'Assembly Fighter' then select the design to assembly and the taskgroup starts on the task with 12 hours of task time = 1 BP per Fighter Assembler Module? adjust for taste.

EDIT: for crew members, I was thinking taking from the Rescued survivors (if any) then grabbing from cryogenics/passengers then from the Assembling Ship crew.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on March 03, 2019, 01:45:59 PM
One thing to keep in mind is that making something into a ship module is equivalent to creating an automated version with zero workforce requirement. For fuel refining and orbital mining modules there are particular restrictions on the bodies they can target, but you see it clearly with the terraforming and maintenance modules and VB6 construction brigades. Creating automated fighter factories may or may not be desired behavior.
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on March 03, 2019, 02:33:46 PM
On that note, maybe terraforming installations should be cheaper/smaller/require less population? I think if ship-based fighter or ordnance factories are implemented, they should be less capable in some way, probably BP/cost, than the ground-based alternative.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 03, 2019, 03:37:19 PM
One thing to keep in mind is that making something into a ship module is equivalent to creating an automated version with zero workforce requirement. For fuel refining and orbital mining modules there are particular restrictions on the bodies they can target, but you see it clearly with the terraforming and maintenance modules and VB6 construction brigades. Creating automated fighter factories may or may not be desired behavior.

This is, indeed, why I gave up on building terraforming installations 13 years ago and went exclusively with ship-based modules.  In the earliest days of Aurora my empires were desperately worker-starved, and I relied heavily on automated mines, sorium harvesters, asteroid mining modules, and the like.  Mostly because back then I squeezed out every last Research Facility I could.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on March 04, 2019, 12:37:29 AM
Terraforming small worlds seems like it would be too easy.

Consider the following:  If there is 20% of the gravity, then the air will weigh 80% less and you will need 5x as much air in order to build up a certain level of pressure on the planet (assuming you dont go full gas giant and add enough air to significantly change the gravity of the planet).

This would make terraforming tiny worlds more realistic, in that it should probably be an exceedingly difficult thing to do.

So, divide the terraforming time by the surface gravity.  10 years / 20% surface gravity (0.2) = 50 years.


e: Fiddling with the math, assuming constant planet density the divide-by-surface-gravity balancing approach would result in a very nearly flat rate terraforming cost.  Minding that in reality smaller planets are generally much lower density than larger planets which would probably cause them to spike massively in terraforming cost because lower density = higher radius = lower surface gravity = longer terraforming time if the suggestion is implemented.

graph (x axis is mass, y axis is terraforming time): https://www.desmos.com/calculator/hepyghpcyh



Additionally, it might be fun if you needed to keep some number of terraformers on the planet in order to keep it terraformed.  This would raise the cost in that you can't really re-use infrastructure for that purpose.  I don't have a specific idea of how to balance that one.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on March 04, 2019, 04:39:27 AM
Note that low surface gravity planets, especially if they are already small, are unlikely to hold too strongly onto their atmospheres. Partially because they don't have a magnetosphere to prevent solar flares and such from carrying off chunks of the atmosphere, and partially because the upper reaches of the atmosphere might reach escape velocity if the atmosphere is tall enough and the gravity low enough.

There's a reason Luna sized planetoids lack anything but the most tenuous atmospheres.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 04, 2019, 06:38:51 AM
Shipyards should probably remain planet locked, but a fighter factory module could be an interesting way of adding deep space production capabilities.
I would perhaps think the other way. Make shipyards be able to function next to a deep space station which provides TN materials and workforce for it to perform shipbuilding. Thinking of "Deep Space Black Ops construction sites" ;-)
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on March 04, 2019, 03:45:21 PM
Perhaps a tech that limit the size of the shipyard? There's potential there. But a big problem would be balancing it so that population isn't made completely irrelevant. Shipyards are, at least in my games, the largest section of workforce a lot of the time. Perhaps the ability to  house population on stations and keeping the pop requirements.
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on March 04, 2019, 07:20:25 PM
Perhaps a tech that limit the size of the shipyard? There's potential there. But a big problem would be balancing it so that population isn't made completely irrelevant. Shipyards are, at least in my games, the largest section of workforce a lot of the time. Perhaps the ability to  house population on stations and keeping the pop requirements.

A lot of people enjoy making huge "Battlestar" type fleets, though. This would arbitrarily make that impossible.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on March 04, 2019, 08:13:50 PM
Terraforming small worlds seems like it would be too easy.

Consider the following:  If there is 20% of the gravity, then the air will weigh 80% less and you will need 5x as much air in order to build up a certain level of pressure on the planet (assuming you dont go full gas giant and add enough air to significantly change the gravity of the planet).

This would make terraforming tiny worlds more realistic, in that it should probably be an exceedingly difficult thing to do.

So, divide the terraforming time by the surface gravity.  10 years / 20% surface gravity (0.2) = 50 years.


e: Fiddling with the math, assuming constant planet density the divide-by-surface-gravity balancing approach would result in a very nearly flat rate terraforming cost.  Minding that in reality smaller planets are generally much lower density than larger planets which would probably cause them to spike massively in terraforming cost because lower density = higher radius = lower surface gravity = longer terraforming time if the suggestion is implemented.

graph (x axis is mass, y axis is terraforming time): https://www.desmos.com/calculator/hepyghpcyh



Additionally, it might be fun if you needed to keep some number of terraformers on the planet in order to keep it terraformed.  This would raise the cost in that you can't really re-use infrastructure for that purpose.  I don't have a specific idea of how to balance that one.

We've been here before:

3 is OK, but your formula is off.  While the required atmosphere mass will scale with the surface area, it will be inversely proportional to the surface gravity of the planet.  On a lower-gravity world, you need more stuff above you to get a given pressure.  The surface gravity is proportional to both density and radius, so if each terraformer produces a constant mass of atmosphere, you'll see the yearly atmosphere production proportional to density and inversely proportional to radius. 
The gory math behind this can be found at http://aurora2.pentarch.org/index.php?topic=8107.msg91559#msg91559 (http://aurora2.pentarch.org/index.php?topic=8107.msg91559#msg91559)

The referenced link has a lot of the back and forth.

The short version:  Assuming constant density, a lot of the other observables of a body are dependent on the radius.  Putting all those in, the time should go like R ~ Mass^(1/3), BUT in terms of Aurora this is easier to think about as Area/surface gravity.  In addition (as I just realized) if you think in terms of Area/surface gravity the density should drop out (because these are the direct observables that determine the total mass of air required to create the desired pressure) so you don't need the constant density assumption.   

So I'm hoping that your plot is simply Y = constant*X^(1/3) - if you expressed it in terms of radius rather than mass you'd get linear behavior.  The other thing in the thread that's important is that there's a selection effect for ~1 G planets - we won't want to terraform a 10G planet, so the surface gravity bit should be fairly (within an order of magnitude or two) uniform across interesting planets.

Don't remember what Steve coded up though - didn't see anything down-thread when I reviewed the references.

John
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on March 05, 2019, 12:22:18 AM
Holy smokes, I was around for that but have no memory of witnessing that conversation.  Fricken 2016, it doesn't feel like its been that long since the C# version started being a thing.

Regardless, it seems like it might be a good thing to add at this point, since terraforming is currently getting attention from steve.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 05, 2019, 09:11:39 AM
The referenced link has a lot of the back and forth.

The short version:  Assuming constant density, a lot of the other observables of a body are dependent on the radius.  Putting all those in, the time should go like R ~ Mass^(1/3), BUT in terms of Aurora this is easier to think about as Area/surface gravity.  In addition (as I just realized) if you think in terms of Area/surface gravity the density should drop out (because these are the direct observables that determine the total mass of air required to create the desired pressure) so you don't need the constant density assumption.   

So I'm hoping that your plot is simply Y = constant*X^(1/3) - if you expressed it in terms of radius rather than mass you'd get linear behavior.  The other thing in the thread that's important is that there's a selection effect for ~1 G planets - we won't want to terraform a 10G planet, so the surface gravity bit should be fairly (within an order of magnitude or two) uniform across interesting planets.

So if I am reading this correctly, small planets wouldn't be much easier to terraform than large ones. The moon has 7.4% of the surface area of Earth and about 17% of the gravity, so it would be 7.4% / 17% = 44% of Earth terraform time.

TBH I think I prefer having a faster terraform time for the small bodies, as most of them lack both atmosphere and water, which will be a significant task, plus they have a smaller capacity. I will play for a while with the updated rate and then make a decision.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on March 06, 2019, 08:08:55 AM
So if I am reading this correctly, small planets wouldn't be much easier to terraform than large ones. The moon has 7.4% of the surface area of Earth and about 17% of the gravity, so it would be 7.4% / 17% = 44% of Earth terraform time.

TBH I think I prefer having a faster terraform time for the small bodies, as most of them lack both atmosphere and water, which will be a significant task, plus they have a smaller capacity. I will play for a while with the updated rate and then make a decision.

Correct. 

To give a feel for the change, if we assume constant density then this works out to the time growing like R instead of R^2.  So for the moon, the ratio of radii is 1/4, so the time would be 4x faster (R) instead of 16X faster(R^2), or 25% of Earth time if the densities were the same.  In reality, the moon's density is only 60% of the Earth's ; since G is going to be proportional to density (at constant R) the time should be 0.25/0.6 = 42%, which checks with your number above.  The advantage of the Area/G formula is that you get the right answer without needing to know the density.

John
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on March 06, 2019, 08:37:58 AM
I'm guessing this has been mentioned before, but can we have an option to set the size of the empire's manufacturing sector as a fraction of population at game start? It's probably one of the better ways to actually have a multi-billion population start without resulting in extremely inflated rates of advancement. Although I suppose one can mess wit the manufacturing efficiency sliders ....

On a side note, is there any reason why any increase in the size of the agriculture and environmental sector pulls population only from the manufacturing sector and not the service sector? It should probably result in a proportional decrease in both.

Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on March 09, 2019, 12:34:17 PM
In their present iteration, tractor beams, for all their potential, are rather .... underwhelming. You have a single 500 ton module that, attached to a ship, let's you drag around exactly one entity of arbitrary mass, with no room for building space!trains, or for using stuff like drop tanks or external launchers.

For such a staple of science-fiction, it's .... boring, to say the least.

Let's spice it up a bit, shall we?


The Proposal :

Rather than have a single tractor module, as in the present, it might be better to have them function more like a combination of box-launcher, magazine and hangar, with a new line of techs dictating how much stuff you can drag around per ton of of tractor, what you can drag around, and how much of it you can drag around. The existing tractor module is bifurcated into two different components : the External Attachment System, which acts a a kind of cross with a hangar, and the Tractor Module.

The existing tractor module now serves as an attachment point between two ships, or a ship and a station, and masses 5000 tons, with the cost now being 100 duranium and 300 mercassium. It serves pretty much the same function as before.

To complement this, it might be prudent to introduce another kind of ship : the external module.
What is this, you might ask?

The External Module

This is, effectively, a new type of ship, distinct from the existing classifications.

An external module is unmanned, meaning it has zero crew requirements. It does not require a bridge, a commander, or any other such components, indeed, it cannot have them, and it cannot accept crew in any form.  It is rather similar to a station in many aspects : it has no mass restrictions, it can only be built by construction factories, and it has a structural shell instead of armour.  There are three important differences, though :

An external module cannot be issued orders, unless and until it is hooked up to a ship. It cannot move, it cannot use its sensors, and it certainly cannot shoot at anything.

An external module has no limitation on the types of components it can have. Anything and everything from beam weapons to high power military engines are allowed, though it is mostly intended to house the various storage modules and box launchers. It cannot house an EAS, however.

An external module is subject to standard maintenance rules : if it has only commercial components, it gets flagged as commercial and requires no maintenance, but if it has military components, it is subject to military maintenance rules and consumes MSP at the standard rate. However, it counts as having only one-fifth of its tonnage. That is, a 10,000 ton external module takes up 2,000 tons of maintenance capacity at a maintenance facility.

This does pose a dilemma, however : an external module requires maintenance, but cannot maintain itself. Hence, maintenance needs to be provided by an external source, the External Attachment System.

The External Attachment System

The EAS serves as a sort of external hangar, allowing for external modules to be attached to ships, and follows some basic rules :

1. There can only be one EAS per ship, like there can only be one Jump Drive per ship.
2. A ship with an external module will register as a single contact.
3. The added tonnage of all the external modules attached to a ship will result in a proportional decrease in ship speed.
4. Engines on the external modules will add to ship speed.
5. External modules will bloat the size of a ship and increase its sensor contact size.
6. If the external module has shields, they will also protect the ship itself from damage.
7. If a ship equipped with an external module takes fire, the chances of the external module taking the damage instead of the ship itself
    is [(external module structural shell width)/(ship armour width)] per weapon hit. This is re-rolled for each weapon hit.

There are three parameters to be kept in mind for an EAS : EAS size, EAS efficiency, and module count.

EAS module size is very straight-forward, it can range from 1 HS to a maximum of 5 HS, with a series of techs to increase the maximum EAS size to 80 HS. This represents the size of the EAS module itself.

EAS efficiency is similar to Jump Drive Efficiency, and starts at 2, increasing with techs to a maximum of 10.

The EAS capacity determines the total tonnage of all external modules that can be attached to a ship.
EAS capacity = EAS size * EAS efficiency.
For instance,  100 ton EAS ton EAS with efficiency 5 can support 500 tons of external module attached to it.

Module Count determines the number of external modules that can be attached to one EAS. The baseline is 1, though it can be increased through techs till 20 modules per EAS. If you have module count 5, and EAS capacity 2000 tons, you can attach five 400 ton external modules, or two 1000 ton modules, et cetera.

An EAS can be commercial or military.

A military EAS can attach both military and commercial external modules, and is a military component. The cost of a military EAS is one-fortieth of its capacity in duranium and thrice that in mercassium. The cost of a military EAS with capacity 2000 tons would be 50 duranium and 150 mercassium. The military EAS takes care of the maintenance needs of military external modules, drawing MSP from the ships stores.

A commercial EAS can only attach commercial external modules, however, it is twice as large and has ten times the capacity of an equivalent military EAS module, while having the same cost.


That's .... pretty much it.

I understand that this might be a lot of work for Steve to code in, but this allows us to finally have drop tanks, external missile racks, use-and-forget engines, etc., which I think is worth the effort.

Thoughts?




Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on March 10, 2019, 10:57:06 AM
In their present iteration, tractor beams, for all their potential, are rather .... underwhelming. You have a single 500 ton module that, attached to a ship, let's you drag around exactly one entity of arbitrary mass, with no room for building space!trains, or for using stuff like drop tanks or external launchers.

[SNIP]

Thoughts?

To anyone thinking of replying to this:  SevenOfCarina duplicated this post in a separate thread: http://aurora2.pentarch.org/index.php?topic=10286.0 (http://aurora2.pentarch.org/index.php?topic=10286.0) that already has some replies.  Please reply in that thread, both to keep the Suggestions thread uncluttered and to keep the conversation in one place.  Thanks!

John
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on March 10, 2019, 05:08:13 PM
In the vein of tractor beam revisions, can we get towed vessels to power down their engines if they are not needed for the speed at which they are being towed?

Or even better, power down any engine not needed to maintain vessel speed, in order of highest to lowest fuel consumption per EPH. This would allow for multiple engine types to be fitted on the same vessel, which has always seemed like a strange and artificial limit, given that most real-world vessel classes have main and aux engine of different design (sometimes even from different engine manufacturers).
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 10, 2019, 07:27:51 PM
Or even better, power down any engine not needed to maintain vessel speed, in order of highest to lowest fuel consumption per EPH. This would allow for multiple engine types to be fitted on the same vessel, which has always seemed like a strange and artificial limit, given that most real-world vessel classes have main and aux engine of different design (sometimes even from different engine manufacturers).

Engines only consume fuel for the current speed, not their max speed. This is true for both VB6 and C#.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on March 10, 2019, 08:19:56 PM
Or even better, power down any engine not needed to maintain vessel speed, in order of highest to lowest fuel consumption per EPH. This would allow for multiple engine types to be fitted on the same vessel, which has always seemed like a strange and artificial limit, given that most real-world vessel classes have main and aux engine of different design (sometimes even from different engine manufacturers).

Engines only consume fuel for the current speed, not their max speed. This is true for both VB6 and C#.

But I think the suggestion was that you could potentially have two different engines on one ship and then the ability to choose if you just want to use one of them or both at the same time. This could be interesting for role-play purposes even if the AI would never use it.

You would fit one engine with a decent fuel to power ratio and one fuel guzzling engine with more power to use only when you really need it.

This is a common way to use engines in real life as well.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on March 10, 2019, 09:59:32 PM
Or even better, power down any engine not needed to maintain vessel speed, in order of highest to lowest fuel consumption per EPH. This would allow for multiple engine types to be fitted on the same vessel, which has always seemed like a strange and artificial limit, given that most real-world vessel classes have main and aux engine of different design (sometimes even from different engine manufacturers).

Engines only consume fuel for the current speed, not their max speed. This is true for both VB6 and C#.

But I think the suggestion was that you could potentially have two different engines on one ship and then the ability to choose if you just want to use one of them or both at the same time. This could be interesting for role-play purposes even if the AI would never use it.

You would fit one engine with a decent fuel to power ratio and one fuel guzzling engine with more power to use only when you really need it.

This is a common way to use engines in real life as well.

This is actually kind of an interesting idea, in that it would allow for ships to have both "cruising" and "combat" speeds, at an enormous increase in fuel use (particularly useful if I wanted, say, a long range cruiser squadron to escort my survey ships). However, it's also a pretty major change, and since movement and fuel use is clearly already coded it might be something better tossed out as a potential future feature.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 11, 2019, 05:14:44 AM
This is actually kind of an interesting idea, in that it would allow for ships to have both "cruising" and "combat" speeds, at an enormous increase in fuel use (particularly useful if I wanted, say, a long range cruiser squadron to escort my survey ships). However, it's also a pretty major change, and since movement and fuel use is clearly already coded it might be something better tossed out as a potential future feature.

It would be a major change, given how much balance is involved in this area. Fuel consumption has to be matched against fuel production in order to create interesting decisions. If fuel is too plentiful, it is too easy and if fuel is too scarce, it would be frustrating.

If I did this at some point, then rather than mounting two or more types of engines it would probably be better to have a fuel efficiency curve built into each engine design, perhaps based on the max boost. As you increase speed, the fuel consumption per point of power rises. Having a higher max boost would lift the entire curve. This is a more real-world situation. To maintain decision-making, the top speeds would have to have higher consumption than at the moment and would probably be reserved for combat situations.

The downside is a more UI, more complexity (including for the AI) and more difficulty for the player in comprehending the potential ranges of his ships at different speeds. The question is whether the game play benefit of having cruising speed is worth the complexity.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on March 11, 2019, 12:36:34 PM
This is actually kind of an interesting idea, in that it would allow for ships to have both "cruising" and "combat" speeds, at an enormous increase in fuel use (particularly useful if I wanted, say, a long range cruiser squadron to escort my survey ships). However, it's also a pretty major change, and since movement and fuel use is clearly already coded it might be something better tossed out as a potential future feature.

It would be a major change, given how much balance is involved in this area. Fuel consumption has to be matched against fuel production in order to create interesting decisions. If fuel is too plentiful, it is too easy and if fuel is too scarce, it would be frustrating.

If I did this at some point, then rather than mounting two or more types of engines it would probably be better to have a fuel efficiency curve built into each engine design, perhaps based on the max boost. As you increase speed, the fuel consumption per point of power rises. Having a higher max boost would lift the entire curve. This is a more real-world situation. To maintain decision-making, the top speeds would have to have higher consumption than at the moment and would probably be reserved for combat situations.

The downside is a more UI, more complexity (including for the AI) and more difficulty for the player in comprehending the potential ranges of his ships at different speeds. The question is whether the game play benefit of having cruising speed is worth the complexity.

While that  might be interesting I think just allowing to use two engines in one hull would make thing much simpler. You only have to worry about two fuel consumption levels. So, the fuel consumption would be either A or B or A+B. The power output of the the ship would be wither A or B or A+B.
In realistic terms you would only use two options since you would probably never only use the engine with the highest fuel consumption. It might also be easier to teach the AI to use such engine configurations as well. Since it is more of a binary all or nothing thing.

I also understand that such a change would need to look at an overhaul of the availability of fuel.

In the current version of the game you can already use high efficient engines on tractor tugs to haul combat ships long distances. From an industrial point of view it is a viable way to move ships between naval bases since fuel is often a pretty expensive resource. This would mainly make tugging navies around your empire less of a necessary thing to be sort of competitive against other factions in a multi-faction campaign.
Title: Re: C# Aurora v0.x Suggestions
Post by: serger on March 11, 2019, 03:16:25 PM
If I did this at some point, then rather than mounting two or more types of engines it would probably be better to have a fuel efficiency curve built into each engine design, perhaps based on the max boost. As you increase speed, the fuel consumption per point of power rises. Having a higher max boost would lift the entire curve. This is a more real-world situation. To maintain decision-making, the top speeds would have to have higher consumption than at the moment and would probably be reserved for combat situations.

The downside is a more UI, more complexity (including for the AI) and more difficulty for the player in comprehending the potential ranges of his ships at different speeds. The question is whether the game play benefit of having cruising speed is worth the complexity.

You can set:
1. the only ramscoop cruise engines tech line (max speed limit by power/mass factor and no fuel consumption at all) - usable for both civil and military designs, or, better, civil ones would be cheaper, but bigger and more vulnerable;
and
2. fixed-consumption (as your VB shield generators) military boosters for sprint maneuvres and/or silencers for sneak maneuvres - those would be usable at tactical situations only, and just for military designs.

So there will be no unmanageable range curves, no irritating stuck-w/o-fuel ships any more, and no strange military/civil engines division by some absolutely arbitrary conventional point for all space races of the Universe.

UPD:
http://aurora2.pentarch.org/index.php?topic=10289.msg113138#msg113138 (revised and expanded, not for v0.x for sure)
Title: Re: C# Aurora v0.x Suggestions
Post by: Kurt on March 11, 2019, 06:24:08 PM
This is actually kind of an interesting idea, in that it would allow for ships to have both "cruising" and "combat" speeds, at an enormous increase in fuel use (particularly useful if I wanted, say, a long range cruiser squadron to escort my survey ships). However, it's also a pretty major change, and since movement and fuel use is clearly already coded it might be something better tossed out as a potential future feature.

It would be a major change, given how much balance is involved in this area. Fuel consumption has to be matched against fuel production in order to create interesting decisions. If fuel is too plentiful, it is too easy and if fuel is too scarce, it would be frustrating.

If I did this at some point, then rather than mounting two or more types of engines it would probably be better to have a fuel efficiency curve built into each engine design, perhaps based on the max boost. As you increase speed, the fuel consumption per point of power rises. Having a higher max boost would lift the entire curve. This is a more real-world situation. To maintain decision-making, the top speeds would have to have higher consumption than at the moment and would probably be reserved for combat situations.

The downside is a more UI, more complexity (including for the AI) and more difficulty for the player in comprehending the potential ranges of his ships at different speeds. The question is whether the game play benefit of having cruising speed is worth the complexity.

I kind of like the idea of having a fuel efficiency curve.  To reduce complexity for the programmer (you), you could make it fairly simple, with lower fuel efficiencies at speeds above, say, 80%.  That would give the user a set of decisions to make that he doesn't have now.  Currently, there are only two reasons to go slower than max, either to reduce your thermal profile or to keep your true max speed hidden.  Fuel efficiency would give you another reason to have to consider going slower. 

Although, maybe commercial engines don't have this problem because they are so low powered?

Kurt
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 11, 2019, 11:38:58 PM
Just going to say that Drop Tanks could be simulated by having a new "Ordinance" type that adds to fuel reserves of a ship when in its magazines.

Or -- what seems to me a simpler method -- allowing a unit to transfer fuel from any ordnance its carrying into its own tanks.  This would turn Drop Tanks into something designed via the regular Missile Design window, and would simply be a 'Missile' that was entirely fuel tank.

(Sure, this means that in an emergency a full-size spaceship might end up running its engines on what we're picturing as solid-fuel booster rocket cartridges, but that's a problem for the fiction.)
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on March 11, 2019, 11:44:11 PM
Can't you already do drop tanks with tractor beams and tankers that are nothing more than gigantic fuel tanks?
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 11, 2019, 11:52:26 PM
Can't you already do drop tanks with tractor beams and tankers that are nothing more than gigantic fuel tanks?

If you're talking Space Shuttle-type external fuel tanks, then yes.  If you're thinking Conformal Fuel Tanks (the in-flight-jettisonable ones, anyway), then no.

And if you want to put them on a 500 ton small craft, the mass penalty for a tractor beam is significant.
Title: Re: C# Aurora v0.x Suggestions
Post by: Target Drone on March 12, 2019, 06:33:49 AM
Quote from: Steve Walmsley link=topic=9841. msg113128#msg113128 date=1552299284
The downside is a more UI, more complexity (including for the AI) and more difficulty for the player in comprehending the potential ranges of his ships at different speeds.  The question is whether the game play benefit of having cruising speed is worth the complexity.

I think KISS would be to add an overboost or 'afterburner' mode to engines; similar to how spinals bump the focal size up, overboost rating just boosts the engine power VS efficiency rating up a level or several(maybe research dependent, set in the engine design), but probably with much worse efficiency than would normally be expected(say power goes up by X levels but efficiency loss is 1. 5 or 2x that or something); thus a ship gets a standard and overboost value for speed and range(and thermal sig; a overboosting engine is probably much hotter than it's engine power would suggest), and you have to decide if it's worth investing the research into boostable engines in addition to deciding of it's worth the fuel to use them; not just for speed but also the boost to evasion VS enemy fire.

Simple, straight forward, and uses existing mechanics and concepts already in the game.

Also, I haven't been able to find an answer either way as to existing C# mechanics/plans, so apologies if I've missed it, but I'm hoping atleast some ordinance weapons will be able to do damage in space combat, even if it's really short range and low damage, for consistency and roleplay; I know you can build multirole fighters by putting ordinance pods into box launchers, but it'd be a bit odd if your air superiority fighter can kill enemy fighters all day, but once it's above the atmosphere it's weapons stop working.  And I like the idea of planetary fighter wings launching a desperate counterattack against landing troop ships or a standoff orbital bombardment or the ilk, rather than being completely helpless.  Probably a long shot, but maybe something for the future.
Title: Re: C# Aurora v0.x Suggestions
Post by: Graham on March 12, 2019, 08:19:11 PM
I personally like the idea of adding a fuel efficiency curve to engines, but not enough to delay the C# release, so probably a 1.1 feature :).

It would make a lot of sense, since in fluidic space resistance would increase at higher speeds. Also I think it would add some tactical depth, as fuel consumption at flank speed has been something captains have historically had to deal with, especially for commerce raiders etc.

I would suggest for simplicity that there is no curve on engines below 0.5 modifier.
Title: Link to suggestion for Planetary 'Air Raid Shelters' suggestion.
Post by: Resident Evil on March 19, 2019, 01:52:08 PM
Just a reminder for Steve in the future, that the suggestion was made for the ability to be available to create civilian 'air raid' shelters in some form or other for protection of the civilian population in the event of planetary bombardment.

Here's the link ---->   http://aurora2.pentarch.org/index.php?topic=10300.0 (http://aurora2.pentarch.org/index.php?topic=10300.0)

Cheers

ZG
Title: Re: C# Aurora v0.x Suggestions
Post by: Resident Evil on March 27, 2019, 11:46:20 AM
Hello again.

This is a re-post as I originally posted in the wrong place apparently. nvm :)

I assume that C# is going to implement initiative still so I'd like to make the following observation/suggestion.

At the moment, I have to set Fighter squadrons initiative to a higher setting to get them to dock with the carrier. What is somewhat irritating is that every time they dock and relaunch, the initiative gets set back to 100 again. Now I can get round this by setting the carrier initiative lower than 100; so the fighters can dock. But still, fighters are naturally agile, so it would be nice if the code could be modified so they retain their initiative after docking/launch.

I'm not sure if this is practical, because I suspect the initiative is assigned to the Task Group, and when the fighter dock the Task Group no longer exists. Hmmmm..... Perhaps, rather than defaulting to 100, fighter squadrons could default to their highest possible initiative instead upon creation.

Anyway, just a suggestion. It may be too much trouble to implement.

ZG
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 27, 2019, 11:57:23 AM
Hello again.

This is a re-post as I originally posted in the wrong place apparently. nvm :)

I assume that C# is going to implement initiative still so I'd like to make the following observation/suggestion.

At the moment, I have to set Fighter squadrons initiative to a higher setting to get them to dock with the carrier. What is somewhat irritating is that every time they dock and relaunch, the initiative gets set back to 100 again. Now I can get round this by setting the carrier initiative lower than 100; so the fighters can dock. But still, fighters are naturally agile, so it would be nice if the code could be modified so they retain their initiative after docking/launch.

I'm not sure if this is practical, because I suspect the initiative is assigned to the Task Group, and when the fighter dock the Task Group no longer exists. Hmmmm..... Perhaps, rather than defaulting to 100, fighter squadrons could default to their highest possible initiative instead upon creation.

Anyway, just a suggestion. It may be too much trouble to implement.

ZG

Initiative has been replaced by Reaction Bonus for C#. That won't change due to fighter launch or recovery.

http://aurora2.pentarch.org/index.php?topic=8495.msg97342#msg97342
Title: Re: C# Aurora v0.x Suggestions
Post by: Resident Evil on March 27, 2019, 12:14:08 PM
Will that not still give rise to problems with fighters landing if their reaction bonus is lower than the carriers?? Unless you give a 'reaction bonus' bonus to smaller craft, so they have a higher reaction bonus than the carriers.

I tend to put higher ranked officers in charge of carriers than in fighters (not least because there's just so many more of them).

ZG
Title: Re: C# Aurora v0.x Suggestions
Post by: totos_totidis on March 31, 2019, 08:04:33 AM
I have an idea. What about implementing nuclear artillery? The Damage could scale with warhead technology. The units when in combat could generate a bit of fallout and dust. Tactical nuclear weapons could be useful for ground invasions.
https://en.wikipedia.org/wiki/Nuclear_artillery
https://en.wikipedia.org/wiki/Tactical_ballistic_missile
https://en.wikipedia.org/wiki/Davy_Crockett_(nuclear_device)
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on April 12, 2019, 10:09:04 AM
About components and research from that other thread in the suggestion forum.

It has been suggested a few times that perhaps there could be a way to use components in ship designs before they are actually researched. This would make designing ships a bit simpler without having to resort to SM to research them and then remove the research to research them normally after you decided on what components to use for your designs.

My suggestion is to simply be able to use components for design even if they are not researched. In the design window you should be able to toggle between having the list including both researched and not researched components or only just researched components (should be the default view).

Any ship design that have a none researched component can't obviously be used unless all components in it is properly researched.

This would make it slightly easier to design ships without resorting to SM to test out components.
Title: Re: C# Aurora v0.x Suggestions
Post by: MultiVitamin on April 12, 2019, 12:45:59 PM
About components and research from that other thread in the suggestion forum.

It has been suggested a few times that perhaps there could be a way to use components in ship designs before they are actually researched. This would make designing ships a bit simpler without having to resort to SM to research them and then remove the research to research them normally after you decided on what components to use for your designs.

My suggestion is to simply be able to use components for design even if they are not researched. In the design window you should be able to toggle between having the list including both researched and not researched components or only just researched components (should be the default view).

Any ship design that have a none researched component can't obviously be used unless all components in it is properly researched.

This would make it slightly easier to design ships without resorting to SM to test out components.

So like a blueprint/concept design type of thing?
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on April 15, 2019, 10:16:46 AM
I think I suggesting something in that line a while ago. Basically you design the components you want to experiment with and "virtualize" them with an additional button (instead of sending them to research you send them to the virtual pool). When you then design the ship you can activate "virtual modules" and test around to make your ship fit as you would like, then mark the virtual modules you need and send them to research. Once they are researched you only have to replace them in your ship design - and voila.
Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on April 17, 2019, 09:50:19 PM
Would be cool if you could do exercises with your warship using these blueprints.
Design a ship using tech you don't have or components which arent ready yet and spawn it into a system for wargames, pitting your ships against it will gain them experience and training.
Damage done to your real ships would have to be undone of course, all crew deaths being fake, etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: tobijon on April 18, 2019, 01:49:54 AM
Would be cool if you could do exercises with your warship using these blueprints.
Design a ship using tech you don't have or components which arent ready yet and spawn it into a system for wargames, pitting your ships against it will gain them experience and training.
Damage done to your real ships would have to be undone of course, all crew deaths being fake, etc.

that goes a bit too far I think
Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on April 18, 2019, 05:39:40 AM
Well, you can already do simulated wargames by spawning warships and either blowing them to bits, or having them fire ineffectually at your own ships causing minor damage but massively increasing crew grade with just a few minutes of single points of damage against the armour.
But the first case is annoying to setup, and the second case is obviously exploitative cheese.
Adding an ingame system to do proper wargames for training would be immersive and perhaps reduce player exploits. Though thinking about it perhaps you could have an alternative to 'task force training' with a 'wargame training' button where all ships in a system on training are assigned to different teams and taken over by the AI for simulated assaults against each other. 
Grade increases shouldn't be as high as actual combat, and perhaps be limited to a fraction of what can be achieved with real combat, but it might be a nice feature.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on April 18, 2019, 05:46:45 AM
Id like to see training of missile ships requiring actually firing a few live missiles and training of Carrier require flying the fighters, as well as training containing a few parts of accelerating to maximum speed.

This could have interesting impacts for intelligence if your enemies or future enemies monitoring the system are able to observe capabilities like ship speeds, warhead strength and speed/size of missiles/fighters.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on April 18, 2019, 09:44:58 PM
To be clear, no idea on the viability, but it would be really cool to have to do actual exercises periodically.  Some training missiles to shoot at your point defenses so they can practice with their actual weapons and suchnot.  Would impose a realistic level of cost on doing training, like in real life.
Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on April 18, 2019, 10:51:26 PM
Actually It would be nice if grade training didn't just require being fired at.
Perhaps a simple mixture of sustaining enemy fire + maneuver training + offensive fire training with all 3 being needed to reach a higher grade level.
Title: Re: C# Aurora v0.x Suggestions
Post by: Peroox on April 19, 2019, 08:37:36 AM
It will be also easier to learn combat mechanic for new player.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on April 19, 2019, 07:56:14 PM
To be clear, no idea on the viability, but it would be really cool to have to do actual exercises periodically.  Some training missiles to shoot at your point defenses so they can practice with their actual weapons and suchnot.  Would impose a realistic level of cost on doing training, like in real life.

You will indirectly pay for training by double maintenance costs... so there is a price for it.
Title: Re: C# Aurora v0.x Suggestions
Post by: bugkill on April 19, 2019, 11:28:43 PM
My suggestion has to do the ground units and seeing if it is possible to have a unit type named "Commando"? The unit would be tasked with handling boarding operations (replacing infantry for that op) and have all terrain capabilities ranked moderately high.  It would also be nice to have random intel on high value targets like high ranking enemy officers or other key personnel that may be on ships or a small base on a planet, so that we could quickly deploy a Commando force to either board ships or infiltrate planets by way of dropships to accomplish the mission.  Basically, we would have one unit type that specializes in special operations while the infantry would be tasked for invasions and garrison operations.  Creating a Commando bonus for officers would be nice as well.  Just an idea in my head.  Keep up the great work. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Whitecold on April 20, 2019, 12:30:06 AM
My suggestion has to do the ground units and seeing if it is possible to have a unit type named "Commando"? The unit would be tasked with handling boarding operations (replacing infantry for that op) and have all terrain capabilities ranked moderately high.  It would also be nice to have random intel on high value targets like high ranking enemy officers or other key personnel that may be on ships or a small base on a planet, so that we could quickly deploy a Commando force to either board ships or infiltrate planets by way of dropships to accomplish the mission.  Basically, we would have one unit type that specializes in special operations while the infantry would be tasked for invasions and garrison operations.  Creating a Commando bonus for officers would be nice as well.  Just an idea in my head.  Keep up the great work. 
Fixed unit types are gone, you can make your own custom formation that does this now.
Title: Re: C# Aurora v0.x Suggestions
Post by: bugkill on April 20, 2019, 02:01:33 AM
Oh, yes.  I misread the ground units update in the wiki.  Thanks for the quick reply, Whitecloud. 
Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on April 21, 2019, 01:19:30 AM
It occurs to me that we might like to be able to assign boarding ships to automatically intercept enemy boarding ships when they come into range, counter boarding them so to speak.
Or if they cant get there in time, we should be able to board our own ships to temporarily add extra marine strength to help fend off enemy boarding action.
How long do boarding operations take to resolve anyway?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 21, 2019, 04:03:23 AM
It occurs to me that we might like to be able to assign boarding ships to automatically intercept enemy boarding ships when they come into range, counter boarding them so to speak.
Or if they cant get there in time, we should be able to board our own ships to temporarily add extra marine strength to help fend off enemy boarding action.
How long do boarding operations take to resolve anyway?

One round every minute. At the moment, you can't board your own ships, but it shouldn't be hard to add.
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on April 21, 2019, 06:32:41 AM
Three-way boarding combat confirmed?
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on April 22, 2019, 05:52:48 AM
Well, that's going to be uncomfortable for the sailors; first they get boarded by enemy marines with much better equipment than they've got, and then their own madmen turn their work and living spaces into an even bigger mess.

That said, when counter boarding the force doing the counter boarding probably should take no or lower chances of losing boarding forces by hard maneuvers because, well, those are reinforcements. Of course you are going to help those forces land if at all possible. Exceptions of course apply when certain duty stations have already been taken over, like the bridge or engineering. I don't think the game currently handles ground/boarding combat with that level of granularity, but it could be abstracted by checking the attacker/defender combat rating ratio and letting certain thresholds decide whether or not certain command stations are at risk of getting taken over.
Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on April 22, 2019, 06:32:05 AM
You could assume that 100% of reinforcements land successfully (at least if the boarding ship isn't fired at on the way) and then compare how outnumbered the friendly troops are, if the enemy currently outnumbers friendly crew/marines its likely they hold more than half the ship so there could be a 50/50 chance you board an enemy held area and have to break out under fire.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on April 26, 2019, 05:05:35 PM
I think it would be time for us to be able to build drones... basically any "fighter" should be able to be built as a drone so no crew and no deployment rate needed.

There could eventually also be some rules for controlling them and electronic warfare to combat control of drones.

This way I could actually deploy swarms of beam fighters without the horror of sacrificing good pilots and crew or just sensor stations (or small drone combat stations) with no crew that can be "sacrificial lambs" at jump points etc.

This would make it so much more easy to "mine" jump points with smart mines. As long as you have a control link or ship close by you can decide what to do with them or they simply can act independently by the AI if direct control is severed.

I think there can be many interesting new feature coming from this eventually, especially in terms of electronic warfare which is something I think the game could have a bit more of. But as a start just the ability to build fighters as drones with no crew would be nice.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on April 26, 2019, 07:34:40 PM
I think it would be time for us to be able to build drones... basically any "fighter" should be able to be built as a drone so no crew and no deployment rate needed. . .

I think "no deployment rate" goes too far for game balance, but I do get a little sad inside every time my "fighter" ends up with a crew of 7.  I'd be happy if there was a way to set max crew for small craft, and then every 'required' crew member that wasn't present would cost some amount of wealth & minerals for 'automation'.

As for your 'unmanned' picket ships, may I suggest Conscript Crews and required officer rank of 12 (so that none are assigned) and some cybernetic technobable about how their brains were harvested to make the computer operating system?
Title: Re: C# Aurora v0.x Suggestions
Post by: hostergaard on April 27, 2019, 04:38:33 AM
I have two sugesstions;

1. Various behaviors for NPRs and ability SM them

That is, I think it would be interesting to have NPR with behaviours that you can set. Fx, ability to create NPRs that will not colonize. Or will only colonize their system. Or build heavily defensively, like only PDC. Will only defend planets.

2. More political options and ability to have a wider range of relations

That is, having various forms of vassal, alliances and confederation mechanics with NPRs


All together it would give players the ability to set up wildly different games. Fx, I could make a game where all the nations of earth banded together to form a loose federation whose goal is to provide a common defence against hostile aliens, which is the player. The nations still exist as TN NPRs, but maybe they will only build civilian crafts. Maybe they will also colonize, or its up to the player to colonize for them. Maybe they will build PDC but leave all space based stuff to players. OR maybe they will also have their own fleets for defensive purposes.


I think it would be great fun if you could set up particular forms of relations between players and NPRs and also have behaviors that matches (or you not if you so choose for them to have it)
Title: Re: C# Aurora v0.x Suggestions
Post by: Cavgunner on April 27, 2019, 11:31:44 AM
Hi Steve, is there any possibility that in the future, colonies might possess unique environmental traits, particularly on those worlds that are potentially habitable (or have been terraformed)?  For example a warm ocean world might be home to native sea-dwelling Megafauna, enhancing Luxury Food output.  Meanwhile, a newly-terraformed Mars might suffer from severe storms due to rapid climate change, slowing production capacity by a certain percentage.  Other worlds might be the home of semi-sentient beasts, viral outbreaks, aggressively hostile alien ecosystems, frequent asteroid storms, etc.

Also, when using the empire map will we be able to overlay our own nation's flag onto systems that we wish to designate as under our control?
Title: Re: C# Aurora v0.x Suggestions
Post by: Agoelia on April 27, 2019, 12:20:47 PM
Hi Steve, is there any possibility that in the future, colonies might possess unique environmental traits, particularly on those worlds that are potentially habitable (or have been terraformed)?  For example a warm ocean world might be home to native sea-dwelling Megafauna, enhancing Luxury Food output.  Meanwhile, a newly-terraformed Mars might suffer from severe storms due to rapid climate change, slowing production capacity by a certain percentage.  Other worlds might be the home of semi-sentient beasts, viral outbreaks, aggressively hostile alien ecosystems, frequent asteroid storms, etc.



We already have "unique" stuff on planets that adds research bonuses, and ancient ruins to pillage. I like this idea, it would push players out of their comfort zone: colonize these planet even if it's terribly hot because it has very fertile terrain, or don't colonize that otherwise very inviting moon because it has extremely poisonus plants all over it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on April 27, 2019, 05:54:39 PM
We also already have differing prodcution rates for the various 'trade goods' -- which can adequately represent luxury foods, decorative woods/minerals, and/or rare life forms.  I wouldn't mind the ability to expand and/or rename the trade goods list, but at the same time I wouldn't miss it if we don't get it.
Title: Re: C# Aurora v0.x Suggestions
Post by: littleWolf on April 28, 2019, 03:17:30 AM
How about  "Orbital habitats" witch military purpose ?   This add to game huge battlestations with hangars, manteinance modules, sensors, defensive weapons and etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on April 28, 2019, 04:54:39 AM
I think it would be time for us to be able to build drones... basically any "fighter" should be able to be built as a drone so no crew and no deployment rate needed. . .

I think "no deployment rate" goes too far for game balance, but I do get a little sad inside every time my "fighter" ends up with a crew of 7.  I'd be happy if there was a way to set max crew for small craft, and then every 'required' crew member that wasn't present would cost some amount of wealth & minerals for 'automation'.

As for your 'unmanned' picket ships, may I suggest Conscript Crews and required officer rank of 12 (so that none are assigned) and some cybernetic technobable about how their brains were harvested to make the computer operating system?

Why would it be bad for game balance?!?

This would eventually be coupled with a control mechanism or some such... so you would still have then have a maximum range at which these drones can be controlled and you could never send them into a different star system because that would be impossible to control. Fighters also are quite limited in fuel.

The good thing with this is how you could build minefields using drones fighters instead of dumb missiles that just explode on anything in the vicinity and which can easily be fooled by exploiting the game mechanics.

The drone section itself would probably be larger than a 1 crew compartment anyway, so a 1 crew ship would probably be more space efficient and cheaper too. Just as drones in the real world are more expensive but don't have to risk human lives in dangerous situations. This would be more of a role playing thing than an efficiency thing in general.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 28, 2019, 07:17:32 AM
How about  "Orbital habitats" witch military purpose ?   This add to game huge battlestations with hangars, manteinance modules, sensors, defensive weapons and etc.

You can do that in VB6, although you will have to pay maintenance on it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 28, 2019, 07:19:56 AM
Hi Steve, is there any possibility that in the future, colonies might possess unique environmental traits, particularly on those worlds that are potentially habitable (or have been terraformed)?  For example a warm ocean world might be home to native sea-dwelling Megafauna, enhancing Luxury Food output.  Meanwhile, a newly-terraformed Mars might suffer from severe storms due to rapid climate change, slowing production capacity by a certain percentage.  Other worlds might be the home of semi-sentient beasts, viral outbreaks, aggressively hostile alien ecosystems, frequent asteroid storms, etc.

Also, when using the empire map will we be able to overlay our own nation's flag onto systems that we wish to designate as under our control?

Probably not for the first release, but one of the good things about converting to C# is that it will be a lot easier to add things in the future.

Yes, you can still flag systems as yours or another race. I haven't coded diplomacy yet, but telling other races (including NPRs) which systems you claim will be part of that.
Title: Re: C# Aurora v0.x Suggestions
Post by: littleWolf on April 28, 2019, 02:08:22 PM

You can do that in VB6, although you will have to pay maintenance on it.

Really ?   "orbital habitat" and "military purpose" properties can exist same time ? And i can build this battlestation 100?++   mass as orbital  without naval shipyard, on Factory ?
Say please, how ?

Title: Re: C# Aurora v0.x Suggestions
Post by: Rich.h on April 28, 2019, 04:07:22 PM

You can do that in VB6, although you will have to pay maintenance on it.

Really ?   "orbital habitat" and "military purpose" properties can exist same time ? And i can build this battlestation 100?++   mass as orbital  without naval shipyard, on Factory ?
Say please, how ?

Yes perfectly possible and I have done so before. Simply design the ship you want as per normal then slap on an orbital hab component. Using the industry tab of the F2 page use the drop down menu to select "build PDC/ Orbital Habitat", then select from the list and it will be built fully using your construction factories. Normally I tend to use it for when I happen to design particularly large vessels such as giant terraformers etc that exceed my shipyard capacity by a factor of ten or more. In theory though you could apply it to any type of ship, if you don't need speed etc and have a spare 250k tons going.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on April 28, 2019, 06:01:47 PM
Keep in mind that with an active terraforming effort dealing with a hostile biosphere is... trivial. Just pump in enough chlorine and wait a couple of years. Or, if the biosphere depends on chlorine gas, pump it out. Either way you can collapse a biosphere.

The real challenge would be establishing a biosphere, diversifying its components or maintaining a biosphere in the face of an ongoing terraforming effort. But that would all require a rebuild of the entire terraforming mechanics anyway.
Title: Re: C# Aurora v0.x Suggestions
Post by: littleWolf on April 29, 2019, 03:06:16 AM
ahh ok, thanks.

Simple in "full design info" 
has both records

This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as an Orbital Habitat for construction purposes

OR

only one
This design is classed as a Military Vessel for maintenance purposes
without any words about OH construction..
Title: Re: C# Aurora v0.x Suggestions
Post by: hostergaard on April 29, 2019, 07:51:39 AM
I was reading a bit on the changes to mechanics  post and read the civilian shipping post.

I think its really great that they can act in a smart manner and check each other, gonna be a huge improvement, but you noted that it may impact performance. So maybe an idea would be to add in

Trade routes

That is, to avoid every single civilian ship always checking each other making for a exponential growth in checks for every additional ship the game could check planets against each other and the profits between them and create trade routes accordingly. Then it could assign the needed tonnage of ships to the various trade routes for maximum profit occasionally updating them.

So most civ ships would run these routes without having to do checks against each other. A smaller number of civ ships could then do the free trading where they checks against each other that you have already created (while also respecting the trade reserved for the trade routes so they don't cause disruption for them. That is, it will only consider and use goods that exceed whats needed for the trade routes)

Just an idea. Might not work well, but it could help cut down calculations. And you could give the player ability to mess with them in various ways. Like creating their own costum trade routes that the civs will use. Or hell, subsidize specific trade routes between planets, routes that would normally not be profitable but, say, the player wants the economy and trade of  a backwater planet develop so he helps it by making the more profitable with bonuses.

If the majority of bulk trading went trough this system then you could also have the player set ships to patrol trading lanes, to protect them. Lots of fun things you could do. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on April 29, 2019, 02:43:04 PM
ahh ok, thanks.

Simple in "full design info" 
has both records

This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as an Orbital Habitat for construction purposes

OR

only one
This design is classed as a Military Vessel for maintenance purposes
without any words about OH construction..
It will be even easier in C# because you can make a "modular" starbase. The main part will be commercial and houses all the commercial elements, including maintenance modules, and then you can have much smaller military parts that are tugged to the same location and provide all the military modules.

Keep in mind that with an active terraforming effort dealing with a hostile biosphere is... trivial.
Yeah, this is my issue with "unique" things on planets. As long as we're capable of completely modifying/removing/creating an atmosphere in years or months, there is little point in adding planetary climate/weather/vegetation/animal elements. Because it'll be a minor modifier to colony cost or pop growth or industrial efficiency only until the player has stripped whatever atmosphere existed before and replaced it with something nicer:

"colonize these planet even if it's terribly hot because it has very fertile terrain" -add more anti-GH gas
"don't colonize that otherwise very inviting moon because it has extremely poisonus plants all over it" -remove atmosphere, introduce it again after all plants have died

Some ideas could work as either new Luxury Goods for civilians to trade (like the megafauna on ocean world Cavgunner mentioned) or as a temporary modifier before/during/after terraforming (like the Martian dust storms). Permanent things not so much, and they would have to interact with terraforming, and there should be a player decision involved somehow, like with the new ground combat model - player can decide not to bother with it and just nuke it from the orbit but then they give up the chance of getting loot.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on April 30, 2019, 12:32:35 AM
I do agree that the trade rout path caching is probably a worthwhile investment to help runtime for big maps.  You would potentially have ships taking the most travelled routs rather than the strictly shortest ones anyhow for sake of safety.
Title: Re: C# Aurora v0.x Suggestions
Post by: canius on May 01, 2019, 02:56:01 PM
Would it be possible to add Ringworld Systems? These would be planets which would have extremely high population caps, but likely would not be mineable.  Systems with ringworlds could be finacial bases, research hubs, shipyards, or any other  population intense industry. 

These would be super rare of course, and you could likely represent them on the system map by having several evenly spaced "planets" as the sections.  Maybe with more sections being present on rarer/larger ringworlds.

Systems with Ringworlds would lack all other system bodies, presumably as whoever built the system used all insystem materials in the construction process.

Wrecked Ringworlds could also be a thing, though all they do is provide a huge mineral dump to whoever has the time and ships to salvage the sections.

Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on May 01, 2019, 05:40:18 PM
Would it be possible to add Ringworld Systems? These would be planets which would have extremely high population caps, but likely would not be mineable.  Systems with ringworlds could be finacial bases, research hubs, shipyards, or any other  population intense industry. 

These would be super rare of course, and you could likely represent them on the system map by having several evenly spaced "planets" as the sections.  Maybe with more sections being present on rarer/larger ringworlds.

Systems with Ringworlds would lack all other system bodies, presumably as whoever built the system used all insystem materials in the construction process.

Wrecked Ringworlds could also be a thing, though all they do is provide a huge mineral dump to whoever has the time and ships to salvage the sections.

To be honest... I think this is pretty much outside the scope of the amount of resources you could get in this game to build when you think about how massive a realistic ring world would be. We already have habitats and when you consider how expensive they are a ring world that could house thousands of trillions of people would break the game pretty much. Also, finding the resources to build one yourself would not be possible so the only viable way would be to find an already built one.

The amount of population in a typical Aurora game are simply too small for ring worlds to be used effectively, it just would be a planet with infinity population, you should also be able to mine it for resources since you will never use the entire thing anyway. Or why not simply mine it for resources instead of living there, pretty much infinity resources that way for the scope of the game.

My opinion anyway...
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on May 01, 2019, 07:37:05 PM
As a 'special terrain' random -- probably a Precursor homeworld -- I wouldn't mind a one-in-a-thousand chance of a Ringworld.  Or an Invader Starbase.  Or a moon-sized battlestation.  Leviathan, Juggernaut. . .  any sort of super-weapon or super-fortress -- especially if it's not jump-capable.

It's either my empire's 'end boss' goal, or a giant "NOPE!" sign for space exploration in that direction.  "Thar be Space Dragons!"
Title: Re: C# Aurora v0.x Suggestions
Post by: canius on May 02, 2019, 02:21:48 AM
Quote from: Jorgen_CAB link=topic=9841. msg114153#msg114153 date=1556750418
Quote from: canius link=topic=9841. msg114149#msg114149 date=1556740561
Would it be possible to add Ringworld Systems? These would be planets which would have extremely high population caps, but likely would not be mineable.   Systems with ringworlds could be finacial bases, research hubs, shipyards, or any other  population intense industry.   

These would be super rare of course, and you could likely represent them on the system map by having several evenly spaced "planets" as the sections.   Maybe with more sections being present on rarer/larger ringworlds. 

Systems with Ringworlds would lack all other system bodies, presumably as whoever built the system used all insystem materials in the construction process. 

Wrecked Ringworlds could also be a thing, though all they do is provide a huge mineral dump to whoever has the time and ships to salvage the sections.

To be honest. . .  I think this is pretty much outside the scope of the amount of resources you could get in this game to build when you think about how massive a realistic ring world would be.  We already have habitats and when you consider how expensive they are a ring world that could house thousands of trillions of people would break the game pretty much.  Also, finding the resources to build one yourself would not be possible so the only viable way would be to find an already built one.

The amount of population in a typical Aurora game are simply too small for ring worlds to be used effectively, it just would be a planet with infinity population, you should also be able to mine it for resources since you will never use the entire thing anyway.  Or why not simply mine it for resources instead of living there, pretty much infinity resources that way for the scope of the game.

My opinion anyway. . .

To clarify, I agree that building one would not be a viable option, only finding one.  It would be a way to deal with the population caps of your planets, as presumably your excess pop could get shipped out their.  Mining the structure for materials could be a thing but I was worried about balance. 

I was picturing them as precursor home systems or something similar, with the destroyed ones being the ones hit by the spoilers.
Title: Re: C# Aurora v0.x Suggestions
Post by: Vizzy on May 04, 2019, 04:39:15 AM
Something that has been batting around my head is how Research is too exact, too uniform, and that we can tell before we start exactly how long it will take.  Hence:

Suggestion:
For each piece of research have two values for the Research Cost, one estimate (with the same values as now) and one true value.  This true value could be a random multiplier (say between 0. 5x and 4x) and would also be different for each race.


What you would see on the interface would be the estimate, so you could roughly predict when a research item would finish, but not to the exact date.  It would give a bit more variety in multi race starts and also between campaigns themselves.  I think it would also aid roleplay, simulating (in a basic way) the uncertainties of research such as breakthroughs and setbacks, and lead to a more dynamic feel of the game.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on May 04, 2019, 10:31:04 AM
Something that has been batting around my head is how Research is too exact, too uniform, and that we can tell before we start exactly how long it will take.  Hence:

Suggestion:
For each piece of research have two values for the Research Cost, one estimate (with the same values as now) and one true value.  This true value could be a random multiplier (say between 0. 5x and 4x) and would also be different for each race.


What you would see on the interface would be the estimate, so you could roughly predict when a research item would finish, but not to the exact date.  It would give a bit more variety in multi race starts and also between campaigns themselves.  I think it would also aid roleplay, simulating (in a basic way) the uncertainties of research such as breakthroughs and setbacks, and lead to a more dynamic feel of the game.

While 4x the cost might work for some cheaper ship component techs it would be massively unfair if you get it on a core tech like say propulsion or something. It also isn't uniform ( meaning it would slow down overall research as an unintended consequence ).

How about something like this instead?

Racial techs:
0.5x cost - 4.0x cost span

Core techs:
0.7x cost - 1.3x cost span

That should hopefully allow for things that in reality often go massively over budget like component R&D to do so ingame, but without impacting the core research progression as much.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on May 04, 2019, 03:11:13 PM
I think there should be a consistent base cost and when you assign a scientist their skill picks a multiplier that you cant immediately figure out.

It would require pretty vague progress reports compared to what we have now to really work I think (otherwise people would just spam re-assign them until they got a good multiplier) but I think it could potentially work.  Perhaps research could look a little more like translation efforts.  I think there should be some very vague overall progress indicator, but it should be clear roughly how long something is supposed to take so that you can make judgement calls at some point.

At that point you have introduced an inherent delay before you can decide to re-assign scientists, meaning you could penalize re-assigning by causing a loss in progress every time you do that.  (if there wasn't a delay, they could just spam re-assign at the beginning until they got a good result at no cost)  The researchers then pick a new approach, which results in them having to solve a lot of new problems, basically amounting to a loss of progress but also re-rolling the research multiplier.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on May 04, 2019, 05:21:49 PM
I would not be a fan of this system. Randomness, no matter how realistic, could really spell the end in some situations.

Like deciding to invest in a certain weapon system, only to be unlucky. Say that all the tech related to lasers are 2x for me, and of course I don't know beforehand. I decided to invest in lasers, it will be ages before I have a working weapon system the way I want, or I'll have to stop halfway and switch to something else. And maybe that something is going to be slow for my race as well.

This system has the potential to be game-ending in case I'm racing for something with which I can defend myself.

If you really want randomness.... I think the player should always have an estimate of the maximum amount of time needed. Then the game could add some chance of a "breakthrough" to make the research finish earlier, but at least you know it won't take more than x time. The only time a research could be slowed down is if Steve codes sabotage from other nations. In that case a delay to the research would be justified.

Either way, I'd still prefer a completely fixed time for research, barring sabotage from other nations.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on May 04, 2019, 06:15:27 PM
I don't really like the idea personally that RND would be a stable, reliable thing that you can count on, it seems to me if you don't already have the technology you need to come out on top then you should indeed be seriously worried.

IMO arguments of 'but that would cause me to lose sometimes' shouldn't shape game design because that tends to result in very boring games.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on May 04, 2019, 06:38:28 PM
If we add random length research completion, or for that matter random ship length construction, installation construction, survey times, etc., there has to be some game play enhancement as an objective.

What decisions does this add for example? Would it actually cause more frustration than enjoyment? 

While there is randomness in the game, in terms of system generation, mineral generation, presence of NPRs, etc. these are all things the players can react to by making decisions. There is no decision when a key piece of research drags on. In fact, I've just removed random length ground surveys and replaced with survey points because it caused frustration.

The one thing left I can think of is random length xeno survey, but that doesn't stop the player doing anything. It just means he has to wait for a benefit.

Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on May 04, 2019, 07:03:42 PM
I don't really like the idea personally that RND would be a stable, reliable thing that you can count on, it seems to me if you don't already have the technology you need to come out on top then you should indeed be seriously worried.

IMO arguments of 'but that would cause me to lose sometimes' shouldn't shape game design because that tends to result in very boring games.

My definition of boring is: something I cannot do anything about. If a research takes longer to complete, and I do not know beforehand, I have absolutely no way to change it.

Oh look, I wanted to research lasers, but it took twice the time I thought it would, and twice the time it would have taken to research missiles. How does that improve the gameplay? Does it show that I am a good or a bad player? Could I have improved it someway?
No I could not. Lasers takes twice more time than researching missiles. Even if I build more labs, lasers will still take twice more time than researching missiles. All because of some random number generated at the start of the game.

How is THAT fun? I decided to chase after lasers, and I could not know beforehand it was a losing choice, and now I'm behind compared to the NPR / spoilers or whatever. I don't see how this is fun AT ALL. The way I played did not improve my research time in the least, compared to researching missiles.

Something is fun when I can conceivably make it better. Something is fun when my choices matter. The choice of researching lasers compared to researching missiles did not really matter, because it was a losing choice from the start because of some hidden number I could not know beforehand. That's not fun, it's just extremely frustrating.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on May 04, 2019, 08:06:21 PM
Not sure pure randomness will do much... It had to be small.

I would rather that research moved in smaller steps and that you had to make more long term decisions. There should be a difference between theoretical and applied technology and how you acquire it.

I don't particularly like that you can switch labs and scientists from one day to the next. Skill should decrease if they don't work in a field. Labs should have efficiency that decrease after they are reassigned, by how much depend on the difference of the old and new project they work on. Reaching max efficiency might take a few years in some cases.

I also are not a fan of universal bonuses, every technological breakthrough need to be implemented in some for.. just like you have to design and build ships and upgrade them.

These things would have important in game impact on decisions.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on May 04, 2019, 09:36:22 PM
I feel like you guys didn't read my post, you are attributing things to it that aren't true.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on May 05, 2019, 04:14:49 AM
I feel like you guys didn't read my post, you are attributing things to it that aren't true.

You are correct. In my first post I was answering to Vizzy and Alex_brunius. And in my second post I was assuming that you were defending their idea. I apologize because of the misunderstanding, sorry about that. In my defense it was pretty late at night for me :P

Now I went back and properly read your proposal again. I do not dislike the idea of a variable research cost by itself. Some variation in tech cost in each game could make research more interesting and force people to use different strategies instead of always going with the same things. But I do dislike the not-knowing beforehand. Imo it's still something that does not add much to the game because it actually limits the player choices.

The problem is still the same I think. A component needs many research steps. Just for a laser, I need multiple researches. So... If every single research is subject to variable length, I am left in total uncertainty, and that does not really depend on my choices. I simply cannot know beforehand.
Just to make an example using your system, maybe the laser focal size will go well.... but laser wavelength and capacitor recharge rate are going to be very unlucky, with multiple reassigning needed for each one, resulting in a vastly increased total research time for new functional lasers. And I cannot know beforehand because I have no idea before actually starting to research.

What could work (but it would be a complete redesign of how science RND works and I have no idea if Steve would be intersted in coding) is something like this. Research progress is divided into tiers right now. So...

- You initially do not know the research costs of the various techs. Instead, you have to do explorative research to discover that. Explorative research is target-oriented. For example, you could have an explorative research named: Laser tier 1. If you do research it, you discover the research cost of all the researches that are required for a first tier laser component (the first laser focal size, the first laser wavelength, the first capacitor recharge rate etc). These costs can be random, but after the explorative research you know them. Basically, you have found "a way to research them", and if you use that, you need x research points.

- At this point you can decide that these costs are ok with you, and proceed to research those techs at your own pace

- Or you can decide that missiles look a lot more attractive with the costs their specific techs have

- Or finally, you can redo the explorative research Laser tier 1. At the end of it, you are granted a reroll on the various techs, and if the roll is better than the one you had before you have discovered a less costly way to research a tech. The result is per tech, so it's only picked if it improves the cost of the various techs. Simply put, you tried to do basic research again. And you found a better way to research tech A, while for tech B and C you will still use the first approach you found with the first explorative research.

Something like this would make research less stable and predictable, while still letting the player make meaningful decisions. You can decide that lasers are just not worth it for now. You can decide to roll with it. You can decide to try and improve your research times by rolling the dice again.

And they are informed choices, because you have one precise idea of what a component would cost in the worst situation (with no rerolls) and so, an upper limit of the completion time. And since it is component-oriented, you are not going to be ruined by the fact that the last research you'd need to make lasers keep rolling horrible and takes forever to finish.

Would something like this be worth coding? That is up to steve. At any rate, I'd probably not do it for the first c# aurora release.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on May 05, 2019, 01:07:16 PM
If we add random length research completion, or for that matter random ship length construction, installation construction, survey times, etc., there has to be some game play enhancement as an objective.

What decisions does this add for example? Would it actually cause more frustration than enjoyment? 

Before I start: the following is intended as observations, not criticisms, arguments or complaints.  I understand and accept that I'm coming from a different place than a lot of Aurora players (including Steve) and am ok with it.  I'm just trying to point out a general theme behind these sorts of discussions/decisions. [EDIT] And then when typing it I realized I have a simple idea that might satisfy both parties.  Skip to the "Unless...." to see it.[/EDIT]

I think this is a different instance/aspect of the philosophical "jigsaw spectrum" discussed in this thread: http://aurora2.pentarch.org/index.php?topic=9861.msg107147#msg107147 (http://aurora2.pentarch.org/index.php?topic=9861.msg107147#msg107147)  In particular see the back-and-forth between me and Zincat (who happens to be the prime responder in this instance of the discussion as well :) ).

To summarize: I think there's a spectrum of people in terms of what they enjoy in a game.  On the one hand, you've got mini-maxers, who want to know exactly what the efficiency of any action will be so that they can choose the perfect path to obtain the best outcome in the game.  For example, when I do a conventional start, I look at the mineral accessibilities that the RNG has handed me and decide the optimum ratio of construction factories to mines I should convert into in order to optimize growth of my economy..  I call this a high "jigsaw affinity", since I suspect that such players tend to enjoy other intricate tasks such as doing monster jigsaw puzzles or playing War in the Pacific. (That's the one with crazy level of detail, right?)

On the other hand, you've got "fog-of-war/imperfect control/gambler/realism" people, who think it's more fun/challenging/realistic to have imperfect knowledge of what the consequences of their actions will be.  These are the people who either don't find it realistic to have perfect knowledge and control or who don't want to spend time micro-managing low level decisions, especially if they're not "interesting".  I'm calling this a low jigsaw affinity.  I think Rule the Waves (btw, version 2 that goes through the 50s and has aircraft is supposed to come out this month) is the best example of a game for those people - you're playing the navy minister and so can only recommend budget changes, you can only define research area priorities overall spending, not what results will come out, OOBs and objectives for battles are generated by the computer based on which forces are deployed to a theater, ....

I don't have a gripping hand.

So to answer Steve's question, I think the argument in favor of hiding research is to add "gambling/fog of war" rewards - it adds to the sense of suspense when you don't know exactly when a research project will finish, or which research path is likely to be most effective - you have to take your best shot with imperfect knowledge and see how it plays out.  I also agree it can be frustrating - in my current RtW campaign I've gotten unlucky on discovering all-or-nothing armor, so I'm at a disadvantage relative to others in terms of how much mass I can devote to weapons and engines in my capital ships - but so can magazine explosions.  Even though I would like to see more fog in the research process, I think it would take a fairly major rewrite of the research system along the lines of what QuakeIV and Zincat discussed to do this well, and I don't want to delay the release date to do that.

Unless....  How about doing what RtW does for ship construction?  You know exactly how many months out a ship is scheduled to be completed, but each month there are potential random events that either delay or speed up progress on one or more ships by a month.  In Aurora this would translate into weakening the micro-coupling between research spending and research progress: if you spend R research points on a project, you would achieve R*RandomDoubleUniformBetweenZeroAndTwo*DoubleIndicatingSizeOfVariability.  If the size of the variability is 1.0, then you'd get (evenly) anywhere between 0 and 2*R progress in that increment; if the size was 2.0, you'd literally be in a "two steps forward, one step back" situation where your progress could be anywhere from -R (indicating dead end research paths to 2*R). 

IMPORTANT:  On average, your rate of research progress vs spending would still be 1:1, i.e. on average you get exactly as many progress points in a span of time as if the system wasn't in place, since you're just as likely to roll a 0.5 as a 1.5 (which average to 1.0). 

Also, the bigger the research project (and hence the more rolls) the lower the relative variation between actual and expected.  This is because variation in the average of a large number N of RNG rolls tends to go like 1/sqrt(N).  So if there are 100 rolls over the course of the research, and SizeOfVariability=1.0, you can expect a relative variation of ~10% in the research rates.  The absolute variation for a large project will grow like sqrt(N) = NTimesAsLarge/sqrt(N)_RelativeVariation, so large projects have more absolute risk simply because they're large, but it will still be a smaller relative risk.  Because of this sqrt(N) effect, throwing more research labs at a project (to get it done more quickly) will increase variability by sqrt(NLabs) - if you have 4x as many labs you'll have 4x fewer rolls and so variability goes up by sqrt(4) = 2x but the average progress remains the same.

Why I like this: 

There's actually a small math subtlety that shows up because Aurora allows players to choose the length of the construction cycle.  If I cut the interval by 4x, then I'm making 4x as many rolls and the variation will go down by 2x.  So there should also be a factor of (5Days/UpdateCycleTime)^2 multiplying SizeOfVariability to make the variability insensitive.  So the final proposal is to change ResearchProgressPoints = ResearchPointsSpent to:

ResearchProgressPoints = ResearchPointsSpent*VariabilityStrength*RandomNumberBetweenZeroAndTwo*SomeFactorWeCanCalculate*(DefaultUpdateCycleTime/ActualUpdateCycleTime)^2.

where VariabilityStrength is a non-negative float that the player can set and SomeFactorWeCanCalculate is a constant that I can calculate if you want that controls how many update cycles you need to get a variability of e.g. 10%.  For example, if you want a project that takes 1 cycle to have a variation of 10% it would be 0.1 (with possibly a factor of sqrt(2) thrown in); if you want a project that takes 100 cycles to have a variation of 10% it would be 1.0 (again, there might be a sqrt(2) or something like it floating around)).

John

PS - While typing the above about jigsaw affinity, I had a few random thoughts that I found interesting:
1) While I usual argue for low jigsaw directions in Aurora, I find myself micro-ing a lot of stuff, like survey SoP, the aforementioned construction plan, and city governor functions in the Civ games.  For example I remember when I was a kid wanting to use Richtofen's War to track every plane in a huge WWI air campaign.
2)  I think there's a very strong sense within the wargaming community that high level-of-detail games like WitP are more "realistic".  In the thread I referenced above I argue the opposite - that this implies a lot of omniscience that eliminates fog-of-war on what your own forces are doing.
3)  I strongly suspect Steve has a high jigsaw affinity, but he's also a big fan of poker.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on May 05, 2019, 04:02:46 PM
3)  I strongly suspect Steve has a high jigsaw affinity, but he's also a big fan of poker.

I like games where I have to consider a lot of different factors, which is true for Aurora and poker and my day job :)

Poker, which I played professionally for six years (and is how I had time to develop Aurora), does have 'fog of war' but you have a lot of information with which to understand what is going on. While math is important in poker, reading opponents is vital. You have to consider a lot of different factors about the situation and the opponent(s) and eliminate possibilities until you are left with the range of their likely holding, which could be very narrow, then you look at the potential for exploiting that (while trying to mislead those players trying to do the same to you). So yes I didn't have complete information, but the game is about using complex information to fill in those blanks.

My day job (Analytics Director for a global, online gaming company) requires my department to take all available information about our players and make recommendations about how we spend money to influence those players to benefit the long-term interest of the company (which often involves ensuring the contributing players get value for money). This can be very complex, as it is a complex business, so it is a case of putting all the pieces together and filling in the blanks with experience (like poker) and a lot of informed debate.

So if high Jigsaw affinity means solving complex puzzles, often with incomplete information, then I agree. If it means having complete information I don't think that would necessarily be me.

What I don't enjoy are games where I get penalised or rewarded for things that are completely outside my control. It feels like I don't need to be there. I would rather play something where I feel I can influence the outcome. BTW, this is not the same as min-maxing. In Aurora, I often role-play a particular perspective or philosophy that is detrimental to long-term success, but I try to act from the motivations and knowledge base of the faction involved. It is a lot more fun that way. Even so, those (bad) decisions are still influencing the outcome.

Not sure if that helps, but it is an interesting discussion :)

Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on May 05, 2019, 04:10:25 PM
PacWar and WitP (the latter is the modernized/expanded/remake version of the former) are seen as highly realistic because they have a very high granularity when it comes to detail, and that granularity attempts to simulate actual naval battles and ship design and so on. So instead of an arbitrary mathematical formula to decide how a battle goes (like Paradox does as their battle algorithm has nothing to do with real battles) there are dozens of calculations on whether a shell X fired from cannon Y from a ship Z can penetrate the armour A on a ship B at a location C. Very few strategy games do that as it's cumbersome and requires massive amount of data, which is why it's mostly Steel Panthers, (old) Close Combats and tank/flight simulators which bother with it.

Of course, Hearts of Iron/Rule the Waves is more realistic than PacWar/WitP when it comes to the chain of command, or actual strategic level leadership, because the player cannot micro-manage their ships and task forces but rather has to issue overall direction.

What sloanjh suggests is actually a pretty decent compromise - it is bit jarring that research costs are always the same from game to game and that I can know down to the day when a particular bit of tech will become available, and I can fine-tune my lab assignments on the fly. I wouldn't want a total crapshoot either though, because having no power to mitigate obstacles and problems is just the game showing me the finger - and don't say "well build more research labs" because while that is a valid approach, it's also a really slow process because of the large disparity between strategic direction (industry, research, ship design/construction) that takes several months or years, and the tactical direction (survey, combat) that takes hours or days.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on May 05, 2019, 06:06:18 PM
Are the escort functions from VB6 still present in C#? I was thinking about using detached light cruisers along several axis of my main fleet to extend the detection envelope and realized that I wasn't sure if that would as easy in C# as it is in VB6.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on May 05, 2019, 06:11:19 PM
Are the escort functions from VB6 still present in C#? I was thinking about using detached light cruisers along several axis of my main fleet to extend the detection envelope and realized that I wasn't sure if that would as easy in C# as it is in VB6.

It isn't coded yet, but I will add at some point.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on May 06, 2019, 01:29:32 AM
3)  I strongly suspect Steve has a high jigsaw affinity, but he's also a big fan of poker.
So if high Jigsaw affinity means solving complex puzzles, often with incomplete information, then I agree. If it means having complete information I don't think that would necessarily be me.

Interesting.

I think what I mean by high Jigsaw affinity is "likes solving complex problems that have complete information".  So jigsaw, Sudoku, etc.  I'm personally not a big jigsaw puzzle fan, but I'm totally hooked on Sudoku and get enjoyment out of games like Civ where I'm cycling through the cities trying to eke out the last dregs of efficiency.  I suspect Lego might fall into the same category, although there's an artistic component there.  Interestingly enough, it occurs to me that computer programming might fall into this category too, since (at least in a Turing environment) they're deterministic.  Maybe the best way to phrase it is "detail-oriented".  So are you saying you're not a fan of these sorts of things?

I suspect there might be another axis floating around having to do with completeness of information, but I'm not sure how to formulate it.  If your answer is "no, I don't like working through a solution for the sake of working through the solution" then .... that actually lessens the potential incongruity of you liking poker :)

As for getting penalized or rewarded for things completely outside your control, I think Garfunkel said it really well in his reply:

it is bit jarring that research costs are always the same from game to game and that I can know down to the day when a particular bit of tech will become available, and I can fine-tune my lab assignments on the fly.

So I think the idea of putting some randomness into the results of research results (and by extension other economic activities like ship construction, possibly survey etc) is that having perfectly predictability breaks some people's suspension of disbelief.  I would put it in the same category as rolling random warp networks and star systems - it puts some natural variability/another factor to account for into planning.  The trick is to introduce it in such a way so that it doesn't increase micromanagement burdens on the player when schedules don't quite mesh up (I don't see that happening - I think the tasks are fairly decoupled and the player simply acts when a task is done).  Another bullet that occurred to me after my original post was that it might add more flavor to people's fiction: "Laying down of our new superdreadnaught class was delayed due to a research setback in engine development".

John
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on May 06, 2019, 02:50:11 AM
I think that having fixed time for research is good as it is.

A benefitial system of variable (or unknown) length of research with benefit for gameplay, I could imagine only with a difference in research results. What do I mean? Let's say you research a new tech of laser weapons and a situation arises where it would benefit you greatly that you get it as quickly as possible. You then go down with your demands as to what the final product should have archived; you become willing to let it have some downsides to get the benefit (with a laser for example have it overload and after 5 times of shooting you have to give it a 5 minute break until you can use it again; or whatever negative malus you want to insert here).
Thereby you can use the laser way earlier but have to deal with the side effects.

I don't see that possible easily within the research system of Aurora - and would the gameplay benefit enough to create such a system?
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on May 06, 2019, 03:26:32 AM
To be frank perfectly deterministic system usually means there is only one optimal choice to make... so most often it will remove choice and not add anything.

"Fog of War" or some randomness actually add options... you now are weighting risks of doing something now or later and you don't know exactly when that will be.

You don't want randomness too feel too random either... you need to have a way to mitigate the randomness but you should never make the random so low that it does not matter either so you will then need a fine balance there.

The major beef I have with the research is that it is decoupled with your actions and that it is highly deterministic. Some randomness where you have setbacks and breakthroughs in research might be interesting from a narrative perspective. The skill of scientists could effect this instead of increasing the research points you get every five days. I think the scientist skill impact the project too much anyway. But... a highly skilled scientist are more likely to get a breakthrough rather than a setback.

There should also be different buildings for applied research from theoretical research, this would produce more choices into how to manage your resources long term rather than short term.

As well as some sort of efficiency "bonus" for labs that work with the same type of projects for a long term.

Scientists should loose skills in areas they are not using while gaining skill in areas they do use... I think all leaders and officers should do this. The higher a skill is the more likely they are to loose some and the lower the chance of increasing it depending on how active they are in utilising it.

As is it is extremely frustrating if one faction simply never get a specific scientist in an important area at the start of a game, such as propulsion or construction for example, so there already are random technology progression in that respect. In my opinion scientists impact the rate of tech gain a bit too much with no real economic impact or relation to size and complexity of a specific empire/faction.

There could easily also be a reduction on efficiency of adding labs to project, the more labs you add the less points you should get to encourage to spread your labs around a bit more. Administrative skill of the scientist could then effect this rather than having a fixed max number of labs they can control. This would make this value more useful as this value rarely do much unless rather late in the game, early on you simply don't have enough labs anyway.

There are may ways you could make research more interesting and require more decisions that will have more long term effect or consequences.

Personally I don't like min/max systems and the current tech system is very min/max friendly with rather small long term planning needed outside a plan for in what order you want to get thing. You always want as many labs on one scientist as possible while putting one lab on the rest to train them... this produce effects that for me is immersion breaking. I obviously don't do that in my games and add rules for how labs (and industry) can be distributed among projects.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on May 06, 2019, 07:46:22 AM
So if high Jigsaw affinity means solving complex puzzles, often with incomplete information, then I agree. If it means having complete information I don't think that would necessarily be me.

Interesting.

I think what I mean by high Jigsaw affinity is "likes solving complex problems that have complete information".  So jigsaw, Sudoku, etc.  I'm personally not a big jigsaw puzzle fan, but I'm totally hooked on Sudoku and get enjoyment out of games like Civ where I'm cycling through the cities trying to eke out the last dregs of efficiency.  I suspect Lego might fall into the same category, although there's an artistic component there.  Interestingly enough, it occurs to me that computer programming might fall into this category too, since (at least in a Turing environment) they're deterministic.  Maybe the best way to phrase it is "detail-oriented".  So are you saying you're not a fan of these sorts of things?

I suspect there might be another axis floating around having to do with completeness of information, but I'm not sure how to formulate it.  If your answer is "no, I don't like working through a solution for the sake of working through the solution" then .... that actually lessens the potential incongruity of you liking poker :)

John

Psychoanalysis Online :)

I don't do Sudoku or Jigsaws or Rubik's Cubes, etc.. In fact, I don't really do any sort of fixed puzzles. I did enjoy Civ up to V, although I haven't played a lot of VI. The best games are where am I defending against unrelenting assault from multiple directions :)

I've always enjoyed complex wargames, both board and PC games. I prefer turn-based thinking games to click-fests, although I enjoy single-player RPGs such as Skyrim, particularly with the difficult mods such as Requiem and the survival mods like Hunterborn, Frostfall and Realistic Needs. In fact I like survival-based games in particular, such as Subnautica. Maybe that is why I always explore early in Aurora. Safe is boring :)

Maybe what I actually like is difficult challenges rather than complex puzzles.
Title: Re: C# Aurora v0.x Suggestions
Post by: AlStar on May 06, 2019, 11:17:59 AM
Possible less drastic research change:
Have each race have a random 90% - 110% cost multiplier for each tech line.  Enough to make you think if it might be worth exploring a different weapon system due to lesser RP costs, but not so much that you couldn't go with the more expensive option by throwing more labs at it. 

To borrow from Zincat's idea - maybe there's a 'general studies' tech which could be researched to re-roll your multiplier, taking the better of the two rolls.  These would be priced highly enough that it'd be a major decision if you want to slow down your research activities in the short-term to lower future costs.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on May 06, 2019, 09:18:22 PM
I was reading another discussion (about the possibility of using low tech engines as a source of cheap additional HTK on immobile stations) and I had an idea about a potential new component.

Basically, Duranium/Compressed Carbon/etc "Bulkheads". Internal ship components from the same tech line as armor that did nothing except have a large amount of HTK to absorb damage. Even if their HTK and cost were identical to armor plates of the same tech level I think they might see some minor use as a counter to particle lances/shock damage/potentially mesons. Especially if the nerf to mesons and shock damage got revisted with a counter available. They could also be used on missile ships to try to prevent magazine explosions from being completely catastrophic, potentially replacing the internal armoring option that VB Aurora has for some components. I could also see using them being competitive with armor when penetrating hits are a distinct worry (Such as fighters or FACs where the armor would be spread thin relative to HS).

From a roleplay perspective they'd also allow for the design of ships where combat damage was a much more gradual thing - instead of a ship remaining mostly intact until armor was breached, and then being destroyed quickly, a ship making heavy use of bulkheads would see its combat capabilities gradually degraded by damage. Might make some thematic sense to have them give a bonus against boarding in some way (either providing a "fortification" effect for the defenders, or just overall slowing the boarding combat process for both sides).
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on May 06, 2019, 11:08:58 PM
I was reading another discussion (about the possibility of using low tech engines as a source of cheap additional HTK on immobile stations) and I had an idea about a potential new component.

Basically, Duranium/Compressed Carbon/etc "Bulkheads". Internal ship components from the same tech line as armor that did nothing except have a large amount of HTK to absorb damage. Even if their HTK and cost were identical to armor plates of the same tech level I think they might see some minor use as a counter to particle lances/shock damage/potentially mesons. Especially if the nerf to mesons and shock damage got revisted with a counter available. They could also be used on missile ships to try to prevent magazine explosions from being completely catastrophic, potentially replacing the internal armoring option that VB Aurora has for some components. I could also see using them being competitive with armor when penetrating hits are a distinct worry (Such as fighters or FACs where the armor would be spread thin relative to HS).

From a roleplay perspective they'd also allow for the design of ships where combat damage was a much more gradual thing - instead of a ship remaining mostly intact until armor was breached, and then being destroyed quickly, a ship making heavy use of bulkheads would see its combat capabilities gradually degraded by damage. Might make some thematic sense to have them give a bonus against boarding in some way (either providing a "fortification" effect for the defenders, or just overall slowing the boarding combat process for both sides).

I would rather see Component Armour return in a functional manner than add bulkheads.  I'd prefer to heavily protect one engine and one fuel tank than make my vessel sort-of generally tougher but still almost as likely to be taken out by a single lucky hit.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bughunter on May 07, 2019, 01:25:54 AM
Steves gaming preferences sounds so much like mine it's almost scary. No wonder perhaps that Aurora attracts the kind of people who likes the same things he does  :)
Title: Re: C# Aurora v0.x Suggestions
Post by: space dwarf on May 07, 2019, 04:32:41 AM
Maybe one idea to add some gameplay to randomised project times would be that the better/more experienced your scientist, the more accurate their estimation of the project time is.

Joe Bloggs straight out of the academy might have a wildly optimistic idea of how long it'll take him to lead a team to invent a real working gamma-ray laser.

Dr Einsteinoid Brainiac who's been leading huge research teams for 50 years and has a +40% research modifier on the other hand might have a much more realistic estimation of project times - and gets them done faster to boot.

A way to enhance this gameplay would be the ability to "second" scientists to projects. This would increase their new "project experience" stat alongside the scientist who's actually running the project, but their skills don't contribute to it and they cant do another project at the same time. That way you have the gameplay tradeoff of "Do I train up the new scientists to be good at project management while using my older scientists to research, or do I make my already-good scientists better at the cost of them not being available during the course of the project?"

just a thought off the top of my head
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on May 07, 2019, 04:57:01 AM
Let them add a (very minor) speed up bonus, like 1/10th their base rating, as long as it's a project in their field of specialisation. It'll encourage keeping a stable of well trained scientists on hand rather than dropping everything on that one awesome researcher, only to panic when he dies.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on May 07, 2019, 05:21:57 AM
What I don't enjoy are games where I get penalised or rewarded for things that are completely outside my control. It feels like I don't need to be there. I would rather play something where I feel I can influence the outcome.

Do you enjoy when the randomness in Aurora 4x throws you a streak of lucky / unlucky combat events, like unlucky magazine/engine detonations blowing up one of your or the enemy's capital ship or 10/10 of your missiles being evaded despite them having a 30% chance to hit?

I guess what most people are asking for is that in reality research is almost as unpredictable as combat, so it hurts the immersion to have perfect knowledge and pre-planning of research, just like it would hurt your immersion if combat was only a series of 100% predictable blows until the weaker side ran out of hitpoints.


Even if randomness is added we can still influence research by improving the overall speed or changing priories, just like you can influence combat by reducing the chance of magazine detonations or increasing our hit-chance of missiles, but it having perfect predictability subtracts from the experience IMO.



I like the ideas brought up by sloanjh. Basically have a steady progress but random events can cause setbacks/breakthroughs that overall balance out. This seems to strike a good balance between being easy to implement and balance while also maximizing gameplay benefits of increased immersion and UI. It's could be expanded to cover construction of ships and buildings or if you want some influence over it add more depths to leaders you assign ( methodical personality trait leaders produce more predictable results while chaotic leaders can have progress jump both back and forwards extreme ).
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on May 07, 2019, 06:58:47 AM
I was reading another discussion (about the possibility of using low tech engines as a source of cheap additional HTK on immobile stations) and I had an idea about a potential new component.

Basically, Duranium/Compressed Carbon/etc "Bulkheads". Internal ship components from the same tech line as armor that did nothing except have a large amount of HTK to absorb damage. Even if their HTK and cost were identical to armor plates of the same tech level I think they might see some minor use as a counter to particle lances/shock damage/potentially mesons. Especially if the nerf to mesons and shock damage got revisted with a counter available. They could also be used on missile ships to try to prevent magazine explosions from being completely catastrophic, potentially replacing the internal armoring option that VB Aurora has for some components. I could also see using them being competitive with armor when penetrating hits are a distinct worry (Such as fighters or FACs where the armor would be spread thin relative to HS).

From a roleplay perspective they'd also allow for the design of ships where combat damage was a much more gradual thing - instead of a ship remaining mostly intact until armor was breached, and then being destroyed quickly, a ship making heavy use of bulkheads would see its combat capabilities gradually degraded by damage. Might make some thematic sense to have them give a bonus against boarding in some way (either providing a "fortification" effect for the defenders, or just overall slowing the boarding combat process for both sides).

I would rather see Component Armour return in a functional manner than add bulkheads.  I'd prefer to heavily protect one engine and one fuel tank than make my vessel sort-of generally tougher but still almost as likely to be taken out by a single lucky hit.

Steve should rekindle his ideas from this thread... http://aurora2.pentarch.org/index.php?topic=4329.msg42975#msg42975

This would be great if done to C# Aurora at some point... the weapon part not the Newtonian physics part.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on May 07, 2019, 07:01:22 AM
Let them add a (very minor) speed up bonus, like 1/10th their base rating, as long as it's a project in their field of specialisation. It'll encourage keeping a stable of well trained scientists on hand rather than dropping everything on that one awesome researcher, only to panic when he dies.

Yes... scientists impact research speed too much, the problem i have with it is the cost... they do it for no cost at all. In manpower or resources... this is not really realistic and a bit immersion breaking at times.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on May 07, 2019, 09:04:15 AM
For a more "random" experience in the research area, maybe going into a different direction might be interesting to think about - whilst keeping a "kind of deterministic" system as it is now.

I personally really, really like that individual control you have over your ship designs. It's not like in most games: Destroyer Class I, Class II, etc. But that concept doesn't transfer to the underlying technologies you have to research. They are Tech I, Tech II, etc.

In todays military, if they for example want to have a new type of fighter, they compose a list of ideas, what that fighter should be able to do. Then the underlying research begins (if that is possible and in what areas new technologies or materials would have to be researched). I imagine a similar kind of system for Aurora without the actually given limits of certain weapons, ranges, etc.: You specify what kind of ship you want to have. In a second step the game then shows you a list of needed technologies for that ship type and what research duration each part would need (the duration would of course highly depend upon what you are actually capable of and the bigger the difference to your actual state of technology is, the bigger the duration will be).
You then go back and forth between design wishes and research list until you are happy with the individual research durations (maybe you didn't like the long duration of the new armor research and toned your wishes down to a "reasonable" duration) and give permission to research the modules.

That system would enable you to
a) react to certain situations individually (like in a war you realize that your laser weapons are slighty (5000km range) to short to overwhelm a certain enemy ship type, so you give a quick research order to increase the laser range and refit your ships quickly with the new weapon type; whilst in the actual system you would have to research the next (full) step of technology - which of course would bring your range 50.000km but would also need 18 month to research instead of 3)
b) give long term research jumps a go if your political situation allows for that in peace times
c) can control technology more precisely, be a bit more in control of your research time, etc.

Again, this would be quite an overhaul - don't know if it would be worth it.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on May 09, 2019, 05:41:06 PM
Not sure if already addressed but one common problem I've had in the past with fighter fire control design is that I can often end up with an over engineered and consequently over sized beam fire control which stems from the 4x multiplier to tracking speed. It would be helpful to be able to select a fractional base tracking to speed to both align to fighter speed and also reduce the overall size of the control in the same way you can reduce base range.
Title: Re: C# Aurora v0.x Suggestions
Post by: 01010100 on May 13, 2019, 08:51:16 PM
I'm not sure if these have been addressed already but I'd like to make a couple of suggestions.   

1.  Automated assignment of population governors.  I like to make dozens of small automated mining colonies and it's a bit of chore to make sure they all have proper governors at all times.    For this reason I suggest adding a dropdown box on the population screen where the player can select the desired modifier such as "Mining" or "Shipbuilding" or "Manual" for manual assignment.  Given the desired modifier a similar algorithm could run as is used for assigning ship officers.   

2.  System body modifiers.  Right now system bodies are pretty bland, either you colonize them (perhaps with terraforming) or you don't, but other than that they are basically interchangeable with each other.  The population limit introduced in C# will help differentiate system bodies but only so far.  So I suggest adding system body modifiers, basically a hidden governor but attached to the system body itself.  This would make for much more interesting strategic choices - do I put my shipyards next to the alien system at a planet where it gets +50% shipbuilding rate or do I put them in a more safe location in the middle of my empire but at an efficiency cost because there I've only got +20% shipbuilding rate? - at low effort since presumably the same code which is already in place for creating civilian administrators could be used.   

3.  Remove standing orders and conditional orders and introduce "automatic orders".  Define an automatic order as follows: let TS be the set of possible tasks for standing orders, let CC be the set of possible conditions for conditional orders and let TC be the set of possible tasks for conditional orders, then let an automatic order be a conditional order with possible conditions "CC u true" and possible tasks "TS u TC" where u is set union.  An automatic order is hence of the form "IF condition THEN DO task" where standing orders can be modeled with "IF true THEN DO task. " This way we're not restricted to 2 standing orders and 2 conditional orders, we could have 4 standing orders if we use 4 automatic orders with "true" as the condition or we could have 4 conditional orders by using 4 automatic orders with something other than "true" as the condition or we could mix and match as we want.  It would also be conceptually "cleaner" (and probably easier to maintain code for) by having only 1 type of automatic order that comprises and extends both types we have now, as well as make possible future extensions of the system easier such as letting the player use any number of automatic orders rather than the hardcoded 4 (2 standing + 2 conditional) that we have now.   

3b.  Let taskgroups take automatic/conditional orders from higher up the hierarchy.  For example I like to set all my exploration-type taskgroups (grav survey, geo survey, . . . ) to refuel at 40% fuel.  It would be easier if I could set that order once at the appropriate level in the hierarchy (the command which includes all my exploration taskgroups) rather than for every taskgroup separately, every taskgroup would check its own automatic/conditional orders and then also check up the hierarchy.   

4 Empire-wide research. Right now research is tied to the population so I put all my research labs in one population so as not to have to bother with research being split.  I suggest making the research tab its own top-level window.  The screen could remain as it is, with the number of available labs being the sum over all populations.  That way research labs can be spread out whilst still having all research in a single screen. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 18, 2019, 06:38:15 PM
Would be really cool if in the Empire creation process, when you hand an Empire over to be run by an NPR, if you had an option to specify the kind of AI that would be in charge of its grand strategy and civilizational scope and goals. Something like "suicidally aggressive" or "citadel" or "exploratory" or "xenophilic" or whatever the different AI settings you have in place are. This would let people set up various RP situations (like multi-faction starts) with some assurance that the NPR would develop according to a paradigm they might expect for roleplay purposes.

Should default to random, though, or whatever the current default behaviour is.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on May 19, 2019, 07:51:30 AM
That's already covered by the various government modifiers, which inform the types of actions a given NPR is likely to consider.

Admittedly, it's a little opaque.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jarhead0331 on May 19, 2019, 05:43:38 PM
Is it possible to add something like this for ship design? This is from the game Rule the Waves. Something like this in Aurora would really be awesome to see what your design looks like...

(https://lpix.org/3426459/maxresdefault.jpg)

(https://jasonlefkowitz.net/wp-content/uploads/2016/02/Ship-design_007.png)
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 19, 2019, 09:31:49 PM
Is it possible to add something like this for ship design? This is from the game Rule the Waves. Something like this in Aurora would really be awesome to see what your design looks like...

Can you be more specific? Are you looking for mechanics, or UI, or something else?
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on May 19, 2019, 10:09:25 PM
LINK TO SEPARATE POST HERE ======> http://aurora2.pentarch.org/index.php?topic=10410.0


I like big letters, they're easier to read.  :P

How about making Cloaking Devices a checkbox on the Class Design? Checking it would dedicate a percentage of the ship's tonnage to the Cloak.


The Techs would then be:


Cloaking Efficiency = Same as before.

Mount Efficiency = Reduces the percentage of a ship's tonnage required for a cloaking device.

Minimum Mount = Minimum Tonnage that a Cloak can be mounted on.

Maximum Mount = Maximum Tonnage a Cloak can be mounted on.


Additionally, although this might cause too much bloat, techs could dictate the maximum and minimum size of the device itself. I.E. a 10% Cloak on a 1,000 Ton ship would weight 100 Tons, thus requiring the 100 Ton Minimum Device Size Tech. While the same 10% Cloak on a 100,000 Ton ship would require the 10,000 Ton Maximum Device Size Tech.


So you would have:



Cloaking Efficiency = Same as before.

Mount Efficiency = Reduces the percentage of a ship's tonnage required for a cloaking device.

Minimum Mount = Minimum Tonnage that a Cloak can be mounted on.

Maximum Mount = Maximum Tonnage a Cloak can be mounted on.

Minimum Device Size = Minimum Size of a Cloaking Device in HS.

Maximum Device Size = Maximum Size of a Cloaking Device in HS.


Alternatively Cloaking Efficiency Tech could be a Ratio of Mount Efficiency instead of a flat percentage.So a 1,000 Ton Ship with a 25% Mount Efficiency Tech and a Cloaking Efficiency of 2 to 1 would have a 250-Ton Cloaking Device operating at 50% Efficiency, due to the 250-Ton Cloaking Device being able to completely Cloak up to 500-Tons worth ship, resulting in a 500 Ton TCS. However the same 1,000 Ton ship with a 2 to 1 Cloaking Efficiency and a 10% Mounting Efficiency Tech would be operating a 100-Ton Cloaking Device capable of cloaking only 200-Tons worth of ship, equivalent to an 80% Cloak, or an 800 Ton TCS. A 100,000 Ton ship could do exactly the same, but would simply cost 10x more to do it.

I might suggest a hard cap on efficiency if invisibility is not desirable, maybe 1% or 10% or something, however:

To achieve a TCS of 0 a 1,000 ton ship could use a 10% Mounting Efficiency Tech and a 10 to 1 Cloaking Efficiency Tech. Since Mounting Efficiency would need to start high, like say 75% or more, then drop down; while Cloaking Efficiency would ideally start low at 1 to 1, this would mean such a ship would be at the top [or very nearly the top] of the Tech Tree to do so. Meanwhile a ship of the same tonnage with a 25% Mounting Efficiency and 4 to 1 Cloaking Efficiency Tech could also become invisible, but at a cost of a quarter of all available tonnage. As a matter of fact, tonnage doesn't make a lot of difference under this system, but 1,000 and 100,000 were easy numbers to work with.
  :P


So this would be the tech tree with all of it:


Cloaking Efficiency = Ratio of the Ship's HS Cloaked per HS of the Cloaking Device mounted on the Ship.

Mount Efficiency = Reduces the percentage of a ship's tonnage required for a cloaking device.

Minimum Mount = Minimum Tonnage that a Cloak can be mounted on.

Maximum Mount = Maximum Tonnage a Cloak can be mounted on.

Minimum Device Size = Minimum Size of a Cloaking Device in HS.

Maximum Device Size = Maximum Size of a Cloaking Device in HS.


EDIT:


Addendum, the Techs suggested would scale as follows:


Cloaking Efficiency = Starts at 1 to 1, scales up from there, maybe with 10 to 1 at max or 100 to one if you're feeling a lil' looney. :)

Mount Efficiency = Starts low, maybe 75% or even 80%, then scales down to maybe 10% at max or 1% if you're feeling even loonier. ;D

Minimum Mount = Starts out somewhere between 7,500 to 5,000 or something medium like that, scales down to fighter sized, maybe even Cloaked Missiles! :o

Maximum Mount = Starts out at something modest (again), like between 75,000 and 50,000 or whatever, scales up from there; possibly could end with a No Limit Tech for billion ton invisible Orbital Habitat Super Dreadnoughts or something equally stupid.

Minimum Device Size = Same as Minimum Mount, scales accordingly.

Maximum Device Size = Same as Maximum Mount, scales accordingly.
Title: Re: C# Aurora v0.x Suggestions
Post by: littleWolf on May 20, 2019, 05:09:15 AM
I think about huge "Space Ark" mothership  for "nomads" playstyle, and have 2 suggestions (if possible):

1. Add  "refit" options for Orbital Habitat structures
2. Add factories/shipyards/resear?h modules for Orbital Habitats design.






Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 20, 2019, 07:38:06 AM
An idea:

To make area defense more viable (especially with the removal of laser warheads, which was the only practical use of it before), make it avoid range drop-off penalties. The way I'd see this most naturally happen is if you can flag BFCs for PD during design; this would give them flat accuracy across an envelope defined by the range parameter, but restrict said range and only be useful to fire at missiles.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on May 20, 2019, 08:41:26 AM
An idea:

To make area defense more viable (especially with the removal of laser warheads, which was the only practical use of it before), make it avoid range drop-off penalties. The way I'd see this most naturally happen is if you can flag BFCs for PD during design; this would give them flat accuracy across an envelope defined by the range parameter, but restrict said range and only be useful to fire at missiles.

I think it would be much easier if a weapon could just fire at range AND final fire as well if it is able to recharge it weapons in time for the last 5s. This would make lasers able to shoot two or three times depending on the missile speed and laser technology.

Both railguns and gauss weapons should get some accuracy benefit from the range of their respective guns due to firing multiple shots a turn. The longer the range the sooner the weapon can engage. This bonus (or penalty) should be based on the distance the missile travel during the last 5s and the range of these weapons. A laser or other larger weapon have such long range they don't get any negative or full benefit for range.

CWIS system should be much smaller and cheaper to compensate and in my opinion much cheaper since they are meant for self defence only and is a small self contained system. The Gauss weapon in this system should probably be allot smaller since they only shoot very short ranges. CWIS systems are almost never worth putting on anything but commercial designs which I think is a pity.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on May 20, 2019, 03:34:40 PM
An idea:

To make area defense more viable (especially with the removal of laser warheads, which was the only practical use of it before), make it avoid range drop-off penalties. The way I'd see this most naturally happen is if you can flag BFCs for PD during design; this would give them flat accuracy across an envelope defined by the range parameter, but restrict said range and only be useful to fire at missiles.

I don't really like exception rules. If I can accurately hit a missile at long range, why can't I hit a larger, slower ship?
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on May 20, 2019, 04:47:40 PM
An idea:

To make area defense more viable (especially with the removal of laser warheads, which was the only practical use of it before), make it avoid range drop-off penalties. The way I'd see this most naturally happen is if you can flag BFCs for PD during design; this would give them flat accuracy across an envelope defined by the range parameter, but restrict said range and only be useful to fire at missiles.

I don't really like exception rules. If I can accurately hit a missile at long range, why can't I hit a larger, slower ship?

Obviously both size and speed should matter for targeting purposes as could even some manoeuvring value such as agility that we have on missiles effect the hit chance.

In real life it is nearly impossible to hit things at very large distances that is both small and travel fast AND have the ability to dodge or make combat manoeuvres. That is why you either need a guided projectile like a missile at range and huge volumes of fast firing bullets or a laser at decent distance since that travels so fast.

At least I hope that you at some time come back to this thing about Beam, Missile and agility stuff in the future... I also would love to see that size matters in terms of hit chance. I would also love something closer to your ideas in Newtonian Aurora in terms of damage with armour and shields. But of course for another time.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on May 21, 2019, 07:52:19 AM
Is it possible to add something like this for ship design? This is from the game Rule the Waves. Something like this in Aurora would really be awesome to see what your design looks like...

Are you aware that Rule the Waves 2 came out Friday?  It's got aircraft now and the tech tree extends to 1950 IIRC. 

John
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on May 21, 2019, 09:56:12 AM
Is it possible to add something like this for ship design? This is from the game Rule the Waves. Something like this in Aurora would really be awesome to see what your design looks like...

Are you aware that Rule the Waves 2 came out Friday?  It's got aircraft now and the tech tree extends to 1950 IIRC. 

John


Shhh! Steve might hear you!

In all honesty I've been watching videos. I might pick it up to fill the Aurora niche until C# comes out. And while I remain a true Aurora loyalist, I have to admit the videos have been making me think how incredible Aurora would be with real time (sort of) animated combat.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on May 21, 2019, 10:24:14 AM
Is it possible to add something like this for ship design? This is from the game Rule the Waves. Something like this in Aurora would really be awesome to see what your design looks like...

Are you aware that Rule the Waves 2 came out Friday?  It's got aircraft now and the tech tree extends to 1950 IIRC. 

John
Shhh! Steve might hear you!

In all honesty I've been watching videos. I might pick it up to fill the Aurora niche until C# comes out. And while I remain a true Aurora loyalist, I have to admit the videos have been making me think how incredible Aurora would be with real time (sort of) animated combat.

Too late! I have been watching RTW2 developer updates for a long time and it does look really interesting. I want to play it and I am trying my best not to give in that impulse or Aurora development will probably go on hold for a while  :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on May 21, 2019, 04:43:20 PM
An idea:

To make area defense more viable (especially with the removal of laser warheads, which was the only practical use of it before), make it avoid range drop-off penalties. The way I'd see this most naturally happen is if you can flag BFCs for PD during design; this would give them flat accuracy across an envelope defined by the range parameter, but restrict said range and only be useful to fire at missiles.

I don't really like exception rules. If I can accurately hit a missile at long range, why can't I hit a larger, slower ship?

What if lasers had adjustable beam width? Attacking an armored ship requires a tightly focused beam to burn through armor, but in point defense mode, that energy can be spread over a wider area to kill fragile missiles.

Or what if the laser beam "sweeps" an area of space, burning up any missiles it touches, but only scorching actual armor.
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on May 21, 2019, 05:51:41 PM
New Cloaking Thread Here ====> http://aurora2.pentarch.org/index.php?topic=10413.0

Old Cloaking Thread Here ====> http://aurora2.pentarch.org/index.php?topic=10410.0

[Might Be Deleted]
Title: Re: C# Aurora v0.x Suggestions
Post by: Erik L on May 21, 2019, 06:37:45 PM
New Cloaking Thread Here ====> http://aurora2.pentarch.org/index.php?topic=10413.0

Old Cloaking Thread Here ====> http://aurora2.pentarch.org/index.php?topic=10410.0

[Might Be Deleted]

Don't normally delete threads unless they are spam.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on May 21, 2019, 06:39:44 PM
Or what if the laser beam "sweeps" an area of space, burning up any missiles it touches, but only scorching actual armor.

Then I would immediately armour my missiles.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 21, 2019, 07:47:50 PM
An idea:

To make area defense more viable (especially with the removal of laser warheads, which was the only practical use of it before), make it avoid range drop-off penalties. The way I'd see this most naturally happen is if you can flag BFCs for PD during design; this would give them flat accuracy across an envelope defined by the range parameter, but restrict said range and only be useful to fire at missiles.

I don't really like exception rules. If I can accurately hit a missile at long range, why can't I hit a larger, slower ship?

I agree, so thanks for forcing me to do a little more work fleshing out the idea.

First, it comes from a place of PD being really weak, compared to AMMs, once you get to inertial confinement fusion, or so. The fix to tracking bonus might already change this balance significantly, as might your idea of removing agility from missiles entirely, if you've done that, so it might not be needed.

However, assuming the balance is still substantially the same, I like the idea of rectifying the balance by making PD more flexible than it currently is rather than just boosting stats. Flexibility opens up tactical possibilities, and I believe that flexibility could easily be represented by expanding the effectiveness of area PD, having knock-on effects with various formations and so forth. Area PD in its current incarnation is really weak anyway, since you're always taking an aim penalty compared to final fire, which in turn means you're incentivized to just keep all your ships in one big TG until the enemy is out of missiles. Breaking that incentive leads the way to interesting formation tactics.

But that's not what you asked. How to make this make sense without feeling like a carve-out? A couple of proposals.

1) Make area-PD specialized BFCs capable of targeting ships as well with the same lack of penalty over their entire range. However, APD-BFCs would have extremely restrictive range compared to regular BFCs - still more than final fire, but low enough to make you want regular BFCs for offensive use lest you be hopelessly outranged. This can be justified by saying range is sacrificed for target awareness, or whatever the appropriate term would be. both new APD BFCs and normal BFCs would be capable of final fire PD without penalty.

2) If I remember correctly, missiles are already different from ships in that they used some sort of 'solidified sorium substrate' for fuel instead of the usual liquid sorium (or sorium-enriched LH2). You could say that this much more intense transNewtonian reaction pushes the missiles deeper into the aetheric fluid than ships can go, which in turn leaves a characteristc signature which is easily tracked by a system tuned for it. Much like how we use LLLTV cameras to pick up faint light, but a regular camera is much better at normal light levels because they swamp an LLLTV sensor.

3) (tongue-in-cheek) All transNewtonian civilzations discover and then sign, via their original transNewtoninan Elements research, a war rules contract with the Q which requires them to put IFF transponders on all of their missiles, along with other wartime protocols. Failure to follow these protocols results in John de Lancie personally revoking their TNE privileges. APD BFCs are tuned to read these IFF signatures whereas regular ones are not.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on May 21, 2019, 07:48:17 PM
Then I would immediately armour my missiles.

Not in C# you wouldn't.
Title: Re: C# Aurora v0.x Suggestions
Post by: misanthropope on May 22, 2019, 12:53:31 PM
I think "C# Aurora" should be shortened to "A#"

that is all.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on May 22, 2019, 03:51:13 PM
C#A

It's pronounced 'catcha'.  (Or is it kasha?)
Title: Re: C# Aurora v0.x Suggestions
Post by: Erik L on May 22, 2019, 04:49:14 PM
C#A

It's pronounced 'catcha'.  (Or is it kasha?)

See Pound Ah
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on May 22, 2019, 09:42:04 PM
See Sharp Ah
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on May 23, 2019, 12:12:22 AM
Si, Shar-Pei.
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on May 23, 2019, 12:55:21 AM
I see no Sharpies.  :P
Title: Re: C# Aurora v0.x Suggestions
Post by: littleWolf on May 23, 2019, 03:16:13 AM
I think "C# Aurora" should be shortened to "A#"

that is all.

Sharprora 4x?
Title: Re: C# Aurora v0.x Suggestions
Post by: MJOne on May 23, 2019, 04:19:53 PM
Nordic-lights boomerang pasture
Title: Re: C# Aurora v0.x Suggestions
Post by: Tuna-Fish on May 23, 2019, 06:28:28 PM
Too late! I have been watching RTW2 developer updates for a long time and it does look really interesting. I want to play it and I am trying my best not to give in that impulse or Aurora development will probably go on hold for a while  :)

I strongly recommend waiting for a few bugfix releases before diving in. I used to play a lot of RTW1, and I really like the new core mechanics, but frankly there are currently quite a few issues that need to be fixed before RTW2 is truly great. For example, invasion missions are one of the new core gameplay features, but in many areas the invasion target has been placed inside a hostile minefield, leading to situations where you put in all the time and resources to invade an area and when it finally would be within your grasp, you realize that the mission is just impossible to complete. (Because there is no way to order the transports to enter an enemy minefield.) That can be very frustrating.

In addition to the pure bugs, there are also quite a few balance issues, mainly that you can pull of Kido Butai feats of air assaults, in 1925 with biplanes, which feels wrong in so many ways.

RTW1 had some issues on release too, and they all got fixed, and after the fixes they added a lot of cool new features for free too. So I fully expect that RTW2 will be a truly great game someday. It just isn't quite that today.

And absolutely none of this was motivated by trying to delay your purchase of RTW2 to get aurora C# faster. okay maybe a little.
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on May 23, 2019, 07:38:09 PM
Aur#ra
Title: Re: C# Aurora v0.x Suggestions
Post by: boggo2300 on May 26, 2019, 06:38:35 PM
Too late! I have been watching RTW2 developer updates for a long time and it does look really interesting. I want to play it and I am trying my best not to give in that impulse or Aurora development will probably go on hold for a while  :)

I strongly recommend waiting for a few bugfix releases before diving in. I used to play a lot of RTW1, and I really like the new core mechanics, but frankly there are currently quite a few issues that need to be fixed before RTW2 is truly great. For example, invasion missions are one of the new core gameplay features, but in many areas the invasion target has been placed inside a hostile minefield, leading to situations where you put in all the time and resources to invade an area and when it finally would be within your grasp, you realize that the mission is just impossible to complete. (Because there is no way to order the transports to enter an enemy minefield.) That can be very frustrating.

In addition to the pure bugs, there are also quite a few balance issues, mainly that you can pull of Kido Butai feats of air assaults, in 1925 with biplanes, which feels wrong in so many ways.

RTW1 had some issues on release too, and they all got fixed, and after the fixes they added a lot of cool new features for free too. So I fully expect that RTW2 will be a truly great game someday. It just isn't quite that today.

And absolutely none of this was motivated by trying to delay your purchase of RTW2 to get aurora C# faster. okay maybe a little.

I've spent the last 4 days straight playing RTW2 with zero bugs at all :D just to throw this cat I have into that flock of pigeons :D
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on May 28, 2019, 12:58:14 PM
There was talk on the discord about conditional orders and the conclusion we reached that there are some gaps that could use filling. Given the automation improvements that C# has brought, I though it would a good time to bring it up.

First things first, though, two more conditional slots or so would be a blessing. As of now you can't have a grav survey ship both refuel, resupply and overhaul automatically, which is not pressing but annoying.

Second things second, new orders.

1. Having asteroid miners require player interaction to pick up and deposit their minerals is awkward. It means that very low quantity asteroids never see any use, as it's too much of a hassle to bother with. Having conditions and conditionals for full cargo bays and depositing the contents of said cargo bays at a colony would be great. While we're talking about drop-offs, having the ability to specific a colony to drop off too would be amazing as well. Would certainly make fuel harvesters with engines a more palatable prospect.

2. A condition for detecting maintenance clock length. Certainly better then just waiting for supplies to reach 20%. My first thought is having the conditional activate at one, two and three years, although if you would be the drop off at colony order customizable you might make it the same way here.

3. An automated troop loading system. Doing this one well would be more of a pain, but if could done in a similar way to fighter and missile loads. A ship design has associated formation types that will be loaded when this order is activated. Would come with a "Unfilled troop compartment" condition. Especially useful for small boarding ships, as the micro for loading them can be time consuming.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on May 28, 2019, 06:22:09 PM
I can't speak for the rest, but some sort of "find highest (total) accessibility asteroid, mine, load minerals into cargo, unload at nearest colony" order for asteroid miners would be wonderful.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on May 28, 2019, 06:34:33 PM
I can't speak for the rest, but some sort of "find highest (total) accessibility asteroid, mine, load minerals into cargo, unload at nearest colony" order for asteroid miners would be wonderful.

Unfortunately, it is more complicated than that. How many systems away do you allow the fleet to go? How about an asteroid 100 AU out? How far would you go if there was only 1000 tons of the mineral? What about if it was a long way and only slightly better than the current location? How does the miner know what minerals are important to you? How about systems next to known alien systems? etc.

The AI can deal with those sort of issues for NPRs, because NPRs have strict controls on deployments, what they can and can't build and they assign values to systems and bodies on an empire-wide basis. In many cases, the 'smarter conditional orders' requests have so many caveats they aren't practical unless the player accepts restrictions on behaviour in the same ways as NPRs.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on May 28, 2019, 07:03:32 PM
"Thoughts" for Commanders similar to Dwarf Fortress. So like the President isn't exactly a fan of increased militarization by the fleet admiral and will try to cut funding for shipbuilding etc. Just optional since not everyone will like it I imagine.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on May 29, 2019, 10:15:54 AM
Unfortunately, it is more complicated than that. How many systems away do you allow the fleet to go? How about an asteroid 100 AU out? How far would you go if there was only 1000 tons of the mineral? What about if it was a long way and only slightly better than the current location? How does the miner know what minerals are important to you? How about systems next to known alien systems? etc.

The AI can deal with those sort of issues for NPRs, because NPRs have strict controls on deployments, what they can and can't build and they assign values to systems and bodies on an empire-wide basis. In many cases, the 'smarter conditional orders' requests have so many caveats they aren't practical unless the player accepts restrictions on behaviour in the same ways as NPRs.

Could this not be covered on the same basis as the geo/grav survey conditional orders?

It doesn't really matter if the instruction isn't particularly clever if you can just bar high risk systems like you already can in C#, and otherwise it'll just go for the closest. Anything that's valuable enough as an asteroid mine to really matter would be the sort of thing to get a CMC or an automated mining colony anyway.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on May 29, 2019, 10:20:51 AM
Unfortunately, it is more complicated than that. How many systems away do you allow the fleet to go? How about an asteroid 100 AU out? How far would you go if there was only 1000 tons of the mineral? What about if it was a long way and only slightly better than the current location? How does the miner know what minerals are important to you? How about systems next to known alien systems? etc.

The AI can deal with those sort of issues for NPRs, because NPRs have strict controls on deployments, what they can and can't build and they assign values to systems and bodies on an empire-wide basis. In many cases, the 'smarter conditional orders' requests have so many caveats they aren't practical unless the player accepts restrictions on behaviour in the same ways as NPRs.
Maybe adding mineral demands in the civilian transport-transfer screen might be a solution for this. One then can let the civilians construct asteroid miners and they do the collecting and deliver to those planets.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on May 31, 2019, 03:23:54 AM
Too late! I have been watching RTW2 developer updates for a long time and it does look really interesting. I want to play it and I am trying my best not to give in that impulse or Aurora development will probably go on hold for a while  :)

The developers of RTW/RTW2 have amazing knowledge about the time period and great attention for detail. Unfortunately they don't seem to have an equally deep understand of physics which leads to some very odd calculation under the hood for example for with their armor calculations being all sorts of messed up.

http://nws-online.proboards.com/thread/2341/larger-displacement-result-lighter-armor
http://nws-online.proboards.com/thread/2345/armor-large-ships-scale-volume


That is what I love the best about Aurora 4x. The tight connection to pretty plausible physics which create interesting design trade offs ( Not that RTW2 don't have design trade offs, but it just feels wrong when a 50% larger ship using same armor thickness has half the weight in armor ).
Title: Re: C# Aurora v0.x Suggestions
Post by: 01010100 on May 31, 2019, 06:01:11 AM
Quote from: JustAnotherDude link=topic=9841. msg114704#msg114704 date=1559066294
First things first, though, two more conditional slots or so would be a blessing.  As of now you can't have a grav survey ship both refuel, resupply and overhaul automatically, which is not pressing but annoying.

I think my earlier suggestion of letting taskgroups take standing/conditional orders from higher up the hierarchy solves this problem in a better way.  Suppose you have a command hierarchy like this:

Navy HQ
-Commercial HQ
--Exploration HQ
---Geo Survey HQ
----Geosurvey TG 1
----Geosurvey TG 2
----. . .
---Grav Survey HQ
----Grav survey TG 1
----Grav survey TG 2
----. . .

Then at the Commercial HQ you'd set the refuel order, at the Exploration HQ you'd set the resupply and overhaul order, at the Geo Survey HQ you'd set the geosurvey orders, and at the Grav Survey HQ you'd set the grav survey orders.  The added advantage of this system is that once you've set it up you don't have to bother with it anymore, if you've built a new geosurvey ship then all you'd have to do is assign it to the Geo Survey HQ and it'll automatically pick up the necessary orders.
Title: Re: C# Aurora v0.x Suggestions
Post by: theoderic on May 31, 2019, 06:56:34 AM
Quote from: 01010100 link=topic=9841. msg114732#msg114732 date=1559300471
Quote from: JustAnotherDude link=topic=9841.  msg114704#msg114704 date=1559066294
First things first, though, two more conditional slots or so would be a blessing.   As of now you can't have a grav survey ship both refuel, resupply and overhaul automatically, which is not pressing but annoying. 

I think my earlier suggestion of letting taskgroups take standing/conditional orders from higher up the hierarchy solves this problem in a better way.   Suppose you have a command hierarchy like this:

Navy HQ
-Commercial HQ
--Exploration HQ
---Geo Survey HQ
----Geosurvey TG 1
----Geosurvey TG 2
----.  .  . 
---Grav Survey HQ
----Grav survey TG 1
----Grav survey TG 2
----.  .  . 

Then at the Commercial HQ you'd set the refuel order, at the Exploration HQ you'd set the resupply and overhaul order, at the Geo Survey HQ you'd set the geosurvey orders, and at the Grav Survey HQ you'd set the grav survey orders.   The added advantage of this system is that once you've set it up you don't have to bother with it anymore, if you've built a new geosurvey ship then all you'd have to do is assign it to the Geo Survey HQ and it'll automatically pick up the necessary orders.

Been thinking the exact same thing actually.  Create generalized orders for entire HQ / Taskgroup-command which gets copied (once) for all sub-TGs.  This would have the additional advantages (obvious to me) of setting your entire fleet to go somewhere or do something you want.

Another possibility would be to have an organizational branch TG (special type) that are only used for order creation and management (no ships).  It would also be nice if leaders who are assigned to superior formations give partial bonuses (synergy) to lower formations in the command chain, but that would just require changing how things are now in the game, or is this perhaps already implemented without my knowledge?

(extra cool if leaders with compatible personality types gave better bonuses to eachother imo)
Title: Re: C# Aurora v0.x Suggestions
Post by: 01010100 on May 31, 2019, 07:03:05 AM
Quote from: theoderic link=topic=9841.  msg114734#msg114734 date=1559303794
Been thinking the exact same thing actually.    Create generalized orders for entire HQ / Taskgroup-command which gets copied (once) for all sub-TGs.    This would have the additional advantages (obvious to me) of setting your entire fleet to go somewhere or do something you want.   

I wouldn't actually copy the orders to the lower level TG's since this would run into issues when you add and then again remove TG's from command levels or when you change orders at higher levels, but just in the code where the TG checks its conditional orders also make it check up the hierarchy.   So the orders only ever exist at the command level you've added them to but the TG's also check higher command levels whenever they are checking their standing/conditional orders. 

Quote
Another possibility would be to have an organizational branch TG (special type) that are only used for order creation and management (no ships).   It would also be nice if leaders who are assigned to superior formations give partial bonuses (synergy) to lower formations in the command chain, but that would just require changing how things are now in the game, or is this perhaps already implemented without my knowledge?

Something like this is indeed already being added to C# Aurora with Admin Commands, the suggestion would be to let those Admin Commands contain standing/conditional orders which then apply to the TG's under them.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on June 01, 2019, 03:27:53 AM
While I agree that conditional orders could be improved I'm not sure that nesting them in higher commands is the way to go. I think being able to put conditional orders into the order queue would be better, as then you can do some clever order stacking for partially automating a lot of ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on June 02, 2019, 03:25:43 PM
@Steve Walmsey

Hey Steve, could we have really small engines? Like >1 HS? Maybe 0.1 HS Minimum? The reason for this request is that I'd like some Micro Engines for Fighters. Not that it would make the game better or whatever, but I would just like Micro Engines. If no, then cool.

Cheers!
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on June 02, 2019, 03:28:23 PM
This is already a thing, Xeno.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on June 03, 2019, 01:55:03 PM
You can see the smallest possible engine size here:
http://aurora2.pentarch.org/index.php?topic=8495.msg102620#msg102620

on this chart:
(http://www.pentarch.org/steve/Screenshots/FuelModelV2.PNG)
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on June 04, 2019, 09:16:17 AM
I would like to take a new crack at the mothballing of ships after I have played some with the new Rule the Waves 2 game, a game which share many similarities with Aurora in that it is a ship design game foremost.

I really think that having a similiar system of reserve, active and mothballing would work really well... especially with the new system and how training is handled.

Here is a version I think would add to the game in terms of dedcisions you would need to make.

Mothballing
Any ship in this status will not require maintenance and its clock will slowly degrade over time but will never actually have any failures. This means that if you mothball a ship for a very long time you will have to spend some time to refit and get it ready for duty.

A mothballed ship will quickly loose all its training until you basically only have raw recruit that have to man the ship once you activate it.



Reserve
Any ship in this status will only be doing routine maintenance and the crew will be ordered to service one in a while to do drills or it might be part of the occasional naval exercises.

These ship would pay normal maintenance but would have a slow degrading of fleet training and will over time reach down to raw recruit status but that would take a very long time.

Taking a ship from reserve to active should be equivalent as taking a ship from overhaul into active in the current game.

Calling up a mothballed ship to active service should require the ship to be overhauled to at least a certain degree before brought into service again.


Active
These ships are actively in duty and ready to do battle at any time. They will do regular fleet drills and perform patrol duties.

Maintenance clock of these ship would run maybe 30% quicker than what is normal today.


Age
I also think that old ships should begin to age and its maintenance clock run quicker. If you upgrade the ships some of that effect should be halted but eventually you should need to scrap ships due to age alone. You will never really be able to replace a ships hull structure, should be prohibitively expensive.

I also think armour should be MUCH more expensive to upgrade than it currently is.


I think that ships status could then be selected with the new fleet management system in the same way you handle the fleet training system. It is just that each type Fleet Training, Active, Reserve, Mothball will have different effect on the ships.

There is a real decision to make in what status you want a specific ship to be which is an interesting one, in my opinion any way...
Title: Re: C# Aurora v0.x Suggestions
Post by: Doren on June 15, 2019, 04:06:35 AM
Here's a couple of suggestions from me.

Sizing
Something that irked me in Aurora was how cheap it is to research very small modules which are pretty much always put on fighters and missiles.

Maybe the research cost should start costing more if you are trying to make really small things.  Right now missile and fighter engines are basically free to research since game calculates the cost based on how large the engines is (with addition of the engine power of course).  I think it would make designing fighter engines a bit more interesting since now you would have to think twice if you would research specialized equipment on each design due to research costs.

It kind of makes sense that cutting size of a very powerful engine by half is going to be very difficult process

I would love to see there to be a double curve on equipment size cost calculation.  Even with sensors and fire control.

Missile designing
I have to say that I'm not an expert missile user and I mostly play on Nuclear thermal -> Ion tech so I do not have a lot experience with Mag pulse and later tech.

I think when ever I'm designing a missile I think I've never thought "I should not go max engine power" and I kind of feel like it is a bit problematic that more power seems to be always better for missile designs.  Very fast missiles should have really bad range.

I kind of feel like missiles right now are a bit too much of a all or nothing weapon.  Either you completely annihilate your enemy with them or the opponent has too strong PD and you cannot get through.

I was wondering if missile designs could use some more diversity.  Right now there seems to be 3 types of missiles: “Torpedoes”, Target Missiles and Long range missiles
Torpedoes are basically missiles shot at so close range that VB Aurora does not allow PD to trigger on them on the 5s pulse.  This mechanic is going to change in C# Aurora as far as I've read change log
Targeted Missiles are missiles that are being shot at the enemy who are in range of a sensor and fire control.  These can wary in range from couple million km to a hundreds of million kms.
Long Range Missiles are two-staged missiles being shot at waypoint and have usually billions of kms range.

Most of the designed missiles are Targeted Missiles and range is usually picked by enemy sensor range to out range their missiles.  Depending on opponent's tech level this can be easy with no compromises or it can be hard with a lot of compromises.  Usually a lot of compromises might lead to designing Long Range Missiles.
I kind of feel that it is way too easy to design generic missile with +50m km range with fast speed and good warhead strength.  I feel like it should be a lot harder to break 1-10m range with one staged missiles if they are max power and still have significant warhead.  This would mean that most of the +10m range missiles would have to be two-stage missiles and their launchers would eat a lot more space on the ships or they would have to accept being a lot closer to the enemy ships to be able to mount as many smaller launchers.

So all in all a hefty nerf to missile ranges which would require tweaking the power modifier fuel consumption or perhaps how much each fuel unit would give fuel to missile.  Maybe agility could also play a bit bigger role on the overall hit chance though I'm a bit afraid to touch it due to AMM

I kind of feel like it should be possible to make faster missiles than what you can do now easier but compromising heavily on warhead and range.  (I think range would be in couple hundred thousands of km).  These kind of missiles would be more of a support missiles instead of primary weapon type: fast enough to be very hard to PD down but not strong enough to complelty annihilate opponent just weaken them before closing in for turrets.
I hope to also nerf PD so that they should struggle against very fast but weak missiles or they should take significant amount of research and space on the ship.  I think this is kind of happening right now if you fire AMM missiles at PD ships.

TLDR: missile range should be more heavily restricted on most powerful engines instead of difference being 50m,12km/s vs 70m,10km/s it should be like more like 500k,12km/s vs 10m,10km/s
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on June 15, 2019, 04:27:02 AM
TLDR: missile range should be more heavily restricted on most powerful engines instead of difference being 50m,12km/s vs 70m,10km/s it should be like more like 500k,12km/s vs 10m,10km/s

Missile ranges and fuel calculation have changed in C# Aurora (see the changes list). I'm finding in my campaigns that the only missile designs using max power are short-range AMMs
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on June 15, 2019, 09:45:24 AM
It has probably been brought up before, but this thread is too big for easy searching, so I apologize but I'm going to bring it up again.

It would be unutterably awesome if C# involved some way to customize interrupts without tweaking the DB itself. Turning off maintenance interrupts or fuel interrupts, turning on population unrest interrupts, etc., along with the ability to change your mind while still in the game.

Even more unutterably awesome would be the ability to customize interrupt priority by source. For example, I could say, "Interrupt when maintenance failures happen, but not from this ship. Tell me when the population on this world increases in unrest, but not the others. Don't bother me about ground combat on these three worlds."
Title: Re: C# Aurora v0.x Suggestions
Post by: vorpal+5 on June 17, 2019, 01:13:51 AM
Has it been considered to add more surprises (and FUN) to the colonization efforts by adding anomalies and oddities? Basically a system body can have from 0 to 3 oddities that might be good or bad. Some will require efforts to deal with, some are permanent or passive.

Nothing super original compared to others games, but this is akin to the concept of 'Goody Huts' for Sid Meier Civilization. Really, I think all Sci-fi 4X games have this kind of stuff on their planets (Endless Space, Stellaris, Galactic Civ III).

This can require a bit of efforts in writing so they are diverse enough, but I'm sure a lot of us would gladly help.

Can also be seen as an extension of the current ruins feature but more diverse. It can be about a dangerous semi-intelligent animal in a jungle world, some left over nanite cloud in a chasm of an asteroid, a strange (abandoned?) pyramid in a desert world, etc. The more the merrier. It would add mystery and thrill and make system body more unique also.

There is no need to create a complex 'event system' to deal with these oddities. Either you leave it alone and it add a passive effect or you click on the 'handle the issue' button and it solves the issue. In both cases, you spend (or earn if a good event) resources (colonists, money, supply etc.).

"Ah yes, this planet. A nice one now with 10 millions colonists and 100 industries, and good corbinite concentration. But these seemingly intelligent octopus in the sea are posing problems as they tend to mind-control unwary colonists."

Passive effect (per month): Loses 0.1% of colonists total
Solving1 (button A): A massive effort (cost 50.000 money) can be undertaken to get rid of these octopuses in the sea by adding a targeted neurotoxin in the water.
Solving2 (button B): We can put these octopuses (pi?) in a natural reserve and study them (cost 250.000 money). This will prevent any nefarious activity while giving us a chance to study them (1% a month to gain 500 RP in Biology)

Etc :)



Title: Re: C# Aurora v0.x Suggestions
Post by: swarm_sadist on June 18, 2019, 05:25:46 PM
For the new Spoiler Race:

Have their numbers regenerate when attacked, requiring a massive assault that will kill them off for good. You go all the way or they will just replenish their numbers, using your wrecked units and technologies against you the next time you fight them.
Title: Re: C# Aurora v0.x Suggestions
Post by: Ranged66 on June 21, 2019, 02:34:42 AM
Facility idea:

Interstellar mass driver

Must be built on closest planet to system primary. Needs 2.5 mil population to be operated. Can target other interstellar mass drivers across jump points. Only 1 per system with limited annual tons of material.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on June 21, 2019, 07:41:54 AM
Facility idea:

Interstellar mass driver

Must be built on closest planet to system primary. Needs 2.5 mil population to be operated. Can target other interstellar mass drivers across jump points. Only 1 per system with limited annual tons of material.

Slightly different proposal: no limits on the # per system or the location in-system, but every time you fire one, it requires a small amount of minerals of certain types, which are consumed. This is to model the mineral package being sent with a small 'one use' jump-field generator in order to punch through the jump point. Surcharge is a simple ratio to the packet size, so you don't have to optimize firing schedule.

A given interstellar mass driver can only send through a single jump; if you want your minerals to go further, use another in the next system (and pay the surcharge again).

A possible problem with this is that naturally people are going to want to start putting these one-use JDs on missiles, but I think that can be gotten around by saying these jump generators are too unstable for engines of any power, much like commercial JDs can't handle military engines but moreso.
Title: Re: C# Aurora v0.x Suggestions
Post by: totos_totidis on June 21, 2019, 07:49:03 AM
I have an idea about the Rakhas.
Since the Rakhas are the remenants of an ancient civ it would make sense for there to be a much greater chance of ancient ruins on their planets.
Title: Re: C# Aurora v0.x Suggestions
Post by: hubgbf on June 21, 2019, 11:13:13 AM
Facility idea:

Interstellar mass driver

Must be built on closest planet to system primary. Needs 2.5 mil population to be operated. Can target other interstellar mass drivers across jump points. Only 1 per system with limited annual tons of material.

If you want to simplify mineral logistic, what about teleportation?
technobable say it will only work with pure TN materials, and only if there is only one TN material at the same time, as you have to fine tune the teleporter for this element.

No consumer goods, no living being, no component, etc...

Perhaps as an option ?

Rerouting civilian mass driver component is also possible.
Will only work when stationed on a jump point, and for mineral packet only, be it a station or a ship. If there is no such component when the packet arrive, it is destructed by interacting with the jump point, creating a blast effect dependant on the quantity and quality of the TN material (sorium will made bigger boom).

My 2 cents
Title: Re: C# Aurora v0.x Suggestions
Post by: Cyborg29 on June 21, 2019, 04:27:34 PM
I would like to suggest a simple change to the way VB6 handles inexperienced fleets: instead of the fleet stopping while it acknowledges new orders, have it follow the last order given until it does so.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on June 21, 2019, 06:01:39 PM
I would like to suggest a simple change to the way VB6 handles inexperienced fleets: instead of the fleet stopping while it acknowledges new orders, have it follow the last order given until it does so.

Definitely this.

(Though a nagging little voice in the back of my mind says Steve already made this change for C# Aurora.)
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on June 22, 2019, 04:11:50 AM
Yes, I believe you remember correctly.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on June 24, 2019, 05:12:13 AM
The new option for "Human NPRs"; could it be possible to make the chance variable? Not fixed 1/3rd but rather an option and we can choose how likely the chance for a human NPR is?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on June 24, 2019, 08:19:18 AM
The new option for "Human NPRs"; could it be possible to make the chance variable? Not fixed 1/3rd but rather an option and we can choose how likely the chance for a human NPR is?

Yes, I will probably change to that at some point.
Title: Re: C# Aurora v0.x Suggestions
Post by: Happerry on June 25, 2019, 12:57:20 AM
Any chance that we could eventually have sort of 'Conserve NPR Variety' option based on the 'Human NPR' option? IE, instead of just the oldest population just an already existing population? For stuff like when two empires met and destroyed each other both can have remnants showing up, or when a big galactic federation went up in flames it left colonies of all its member species scattered around and so on?
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on June 25, 2019, 06:36:15 AM
Actually fuel consumption per engine hour is a general tech that is automatically applied to all engine types. I know it would not add much to gameplay except more "realism", but I would like to have fuel consumption per engine hour dependend upon each engine class. So at first when you research a new type of engine class, it might be faster but would eventually eat much more fuel, Later on you would get the benefit of lesser fuel consumption as you research it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Doren on June 26, 2019, 10:20:11 AM
Quote from: TMaekler link=topic=9841. msg115091#msg115091 date=1561462575
Actually fuel consumption per engine hour is a general tech that is automatically applied to all engine types.  I know it would not add much to gameplay except more "realism", but I would like to have fuel consumption per engine hour dependend upon each engine class.  So at first when you research a new type of engine class, it might be faster but would eventually eat much more fuel, Later on you would get the benefit of lesser fuel consumption as you research it.
I once thought of this but each engine tech step needs to matter a lot less and the fuel tech needs to be really cheap compared to next engine tech to be worth to research.
Right now engine tech is more or less the priority 1 tech in the game and you would be hard pressed to diver resources from trying to go forward with it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on June 26, 2019, 12:17:02 PM
Except in multi-faction Sol starts, where the delay between starting engine research and putting faster ships into combat can be sufficiently long that researching other things becomes more important. But granted, that is a fairly rare case.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on June 26, 2019, 04:25:41 PM
To be honest I like the fact that you would research fuel efficiency for each class rather than just one universal technology... this could make it worth sticking to an older engine even if you have a newer technology. They might even be better than the new engine given you can increase the power setting but still burn less fuel for the same speed.

Older engines might be slightly slower but certainly more economical.

It would then make more interesting choices, the question would then be how to balance the cost of research.


I also agree on the multiple faction type of games. Here ships develop more organic and much less in leaps and bounds. You are also quite likely to be stuck with ships having several technological standards of everything. You will never be able to convert all your ships from one technology to the next so everything will always be in some state of flux.
Title: Re: C# Aurora v0.x Suggestions
Post by: Expy on June 27, 2019, 10:51:55 AM
I don't know if this has been suggested before but I really liked the idea of a ship's computer/ AI tech that would reduce the crew requirement: research could determine the crew quality that the computer could simulate, how many crew it can replace per ton stuff like that.  Precursor ships could be translated to use these systems instead of what they do right now.

I'm really looking forward to getting to fool around in C#, whenever you decide to release it! =)
Title: Re: C# Aurora v0.x Suggestions
Post by: tobijon on June 27, 2019, 02:04:33 PM
I don't know if this has been suggested before but I really liked the idea of a ship's computer/ AI tech that would reduce the crew requirement: research could determine the crew quality that the computer could simulate, how many crew it can replace per ton stuff like that.  Precursor ships could be translated to use these systems instead of what they do right now.

I'm really looking forward to getting to fool around in C#, whenever you decide to release it! =)

I have thought about this before and I think that the best way to do it would be to reduce crew requirement (and therefore shipsize) at the cost of high resource requirement. having to choose between cheap crew compartments and very expensive automated systems. Perhaps with a tech research line for a maximum percentage or amount of reduced crew, or a research chain to replace the crew of certain components.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 02, 2019, 07:39:52 AM
Level of Importance for Task Groups:
I usually rename my Task Groups with spaces in front of them so that the more important ones are at the top of my TG list. That on the other hand gets a bit "out of hand" when you do that with several levels of importance. Would be nice if we could add a "level of importance" to the TG and that the TG list will be sorted by that level of importance first; then name etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: Shuul on July 02, 2019, 07:41:30 AM
Level of Importance for Task Groups:
I usually rename my Task Groups with spaces in front of them so that the more important ones are at the top of my TG list. That on the other hand gets a bit "out of hand" when you do that with several levels of importance. Would be nice if we could add a "level of importance" to the TG and that the TG list will be sorted by that level of importance first; then name etc.
Totally support this idea!!!!!
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on July 02, 2019, 09:07:42 AM
Level of Importance for Task Groups:
I usually rename my Task Groups with spaces in front of them so that the more important ones are at the top of my TG list. That on the other hand gets a bit "out of hand" when you do that with several levels of importance. Would be nice if we could add a "level of importance" to the TG and that the TG list will be sorted by that level of importance first; then name etc.

With the Fleet Tree and Admin Commands, you can organize your task groups and see a lot of them at once, so you won't have the same issue as VB6
Title: Re: C# Aurora v0.x Suggestions
Post by: ExChairman on July 02, 2019, 11:17:03 AM
Not sure if its been asked for but I would like to have an "Default order" for rescue lifepods, gets a bit tedious to do it the "Hard way" for 300 pods, friendly and non friendly
Title: Re: C# Aurora v0.x Suggestions
Post by: Shuul on July 03, 2019, 02:51:06 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.

Not sure if this was added or not, but choosing what stops time cycles is something I am hoping for :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on July 03, 2019, 08:25:37 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.

Not sure if this was added or not, but choosing what stops time cycles is something I am hoping for :)


Same. Would be very relevant to my interests
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on July 04, 2019, 10:13:09 AM
Just a shout out to say I'm really looking forward to C# version.  It has become my most anticipated game because more than anything, Aurora lets me play out a specific science fiction fantasy and really scratches my details oriented itch.  I have stopped playing 7.10 because I've never had particularly top of the line computers and there did become a point where the games do become too hard to go through due to the interrupts and long turn times and by all accounts the new version addresses it.  I'm especially looking forward to the new features, particularly on ground combat and the possibility of NPR ground invasions.  I would gladly play premium price for this version.

My suggestion is towards Commander traits.  I really dig the role-playing aspect of Aurora and the management of commanders and oddly the traits really make the characters come alive to me - I even write little notes about the commanders based off of them and their associated dramas.  Though it isn't strictly necessary, I would like to see some game play effects associated with the traits - modifiers to existing skills based off the traits and the possibility of trait gain/loss over an interval (every 5 years or so).  Some of the traits could be intrinsic and not subject to change but others could change.  I feel this system could create the illusion of even more dynamic nature to the Commanders/Leaders.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 08, 2019, 03:22:29 AM
Duration of Escape Pod Life Support

I found the duration of Life Pods always a bit short. Was wondering if it would be a nice addition to C# if you could define the endurance of life pods at the level of ship design. It would for example make sense if a slow long distance cargo hauler would have life pods which would endure let’s say 60 days and those of a local system transport only 15. The additional space needed for bigger life pods could be calculated into the space requirements for crew.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bughunter on July 08, 2019, 01:44:30 PM
I like the escape pod idea. But it should probably come with some more negative effects from not rescuing your personnel. Otherwise I think it will be too tempting to just go with the minimum time on every design. Or perhaps set 14 days as the minimum time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on July 08, 2019, 02:10:26 PM
I like the escape pod idea. But it should probably come with some more negative effects from not rescuing your personnel. Otherwise I think it will be too tempting to just go with the minimum time on every design. Or perhaps set 14 days as the minimum time.

I, too, love the idea of variable escape pod time that one sets when designing ships.  But I strongly disagree that there should be increased penealties for not rescuing personnel or a fixed minimum duration for life pods.

Whether or not an empire rescues survivors is a *role-playing* decision for that empire, and should not be inflicted on me by game mechanics.  What if my empire is a machine race, and automatically downloads all crew before ship destruction?  What if my empire is a hive mind and sees zero value in rescuing drones?  What if my empire suffers from military chauvinism and views 'death before dishonour' as the overriding principle (in which case, it would be nice if I could prevent my ships from having life pods at all)?

The 'penalty' for too-short a time on your life pods is that you don't get your crew back.  If you want a three-day window, or a three-month window, that should be up to your empire to decide.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on July 08, 2019, 04:51:34 PM
I like the escape pod idea. But it should probably come with some more negative effects from not rescuing your personnel. Otherwise I think it will be too tempting to just go with the minimum time on every design. Or perhaps set 14 days as the minimum time.

I, too, love the idea of variable escape pod time that one sets when designing ships.  But I strongly disagree that there should be increased penealties for not rescuing personnel or a fixed minimum duration for life pods.

Whether or not an empire rescues survivors is a *role-playing* decision for that empire, and should not be inflicted on me by game mechanics.  What if my empire is a machine race, and automatically downloads all crew before ship destruction?  What if my empire is a hive mind and sees zero value in rescuing drones?  What if my empire suffers from military chauvinism and views 'death before dishonour' as the overriding principle (in which case, it would be nice if I could prevent my ships from having life pods at all)?

The 'penalty' for too-short a time on your life pods is that you don't get your crew back.  If you want a three-day window, or a three-month window, that should be up to your empire to decide.

I would agree, penalties of that sort is part of the role-playing in Aurora. If you want to "waste" tonnage on advanced life pods should mainly be a role-playing decision.

I would also like if a ships damage control system could prevent a ship from exploding for a short while to allow more crew to get to their pods as well. This would give damage control another interesting and realistic thing to do in the game.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on July 09, 2019, 01:53:37 AM
I, too, love the idea of variable escape pod time that one sets when designing ships.  But I strongly disagree that there should be increased penealties for not rescuing personnel or a fixed minimum duration for life pods.

Good point about penalties not being ideal.

But how about going from it in the other direction? Now it was some time since I played Aurora 4x, but I don't recall there being a meaningful enough bonus in retained experience from rescuing crew/leaders most of the time.

Perhaps if more crew / leaders survived ship destruction on average and if they gained a bit of extra experience simply by surviving ( failure is the greatest teacher ), then it would be worth more for players to rescue their crew so that the decision to leave them to their fate instead of trying a risky rescue mission isn't quite as easy.

This could probably give alot of flavor to the game IMO, especially for fighter crews as it was a huge thing in WW2 that USA rescued fighter crews and put them back in fighters, now with the experience of how their enemy had shot them down, while Japanese pilots often preferred to not even bring parachutes and die a warriors death.

I think it also adds plenty more opportunities for storytelling about epic rescue missions both failures and successes.
Title: Re: C# Aurora v0.x Suggestions
Post by: DIT_grue on July 09, 2019, 07:52:39 AM
Speaking of rescue missions that succeed or fail by a hair, would it be worth having at least a day or two of possible uncertainty in when escape pods die? On the one hand you have the Cold Equations experience several people have written up of the Admiral looking at when they will expire, knowing there isn't a fast enough ship to reach them by then, and turning back through the jump point in futility. But that means you never have the pod that lasted a little longer because not every one assigned to it made it off the ship (... perhaps suspiciously so? Did a coward abandon potential survivors to maximise their own chances?) and the supplies therefore stretched far enough, or there was heroic sacrifice so some of them could see home again, or... For that matter, there's no overcrowded pod with people dying just hours before rescue when there was still days left in the according-to-specifications survival window, sabotage or poor maintenance killing those that had just started to process that they have barely escaped with their lives, ...
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 10, 2019, 04:21:48 AM
Maybe the survivors begin dying at the beginning of the end of the survival pod life time which will last for a while until the last one dies. So if you arrive let’s say a day late you will still be able to rescue 25% of the original survivors.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 10, 2019, 04:26:52 AM
Another idea: when a planetary governor dies his bonuses immediately disappear. Which can be annoying if they were the factor that kept you over a certain margin. And the new governor still isn’t there yet.

How about bonuses fade into the new values over time. The people in the beginning are still used to the old ways of the former governor and therefore continue with the bonus. But over time (let’s say 3 to 6 month) they have to adjust to the new ways of the new governor and loose or gain his bonuses. Same when a leader gets better at a job. He needs time to implement his new knowledge until it yields full fruition.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 10, 2019, 04:49:06 AM
Tractor ships: I think tractor ships will become more important in C# Aurora. So I was thinking about utilizing them better. Let’s say you build an immovable space station and want to carry it into its final destination after construction. So you attach it to a tractor ship and move it there. You 15.000kms tractor ship will of course only move it there at 110kms because of the massive size of the space station. In reality you would attach 10 tractor ships to get it moved a bit quicker. So maybe it can be made possible that when you have five tractor ships in a task group, that their summary of thrust is calculated for max transport speed rather than for just one of them?
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on July 10, 2019, 01:11:31 PM
Could we please replace the current design screen UI with something along the lines of how the turret design screen works? It's really annoying having to use step sizes of 1 HS for components and it's even more annoying to scroll down the extremely long list of available sizes. I'm suggesting something like inputting two out of three of the following with a keyboard to build an engine : fuel draw per EPH/boost, engine power, engine size, with fuel efficiency being selected automatically. It'll be really useful for engines, sensors, and especially fire controls, where the step sizes are aggravating.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on July 11, 2019, 02:47:15 PM
I agree, that would be really nice.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 12, 2019, 03:52:00 AM
Front / Rear Beam Weapons for Fighters. Once an engagement has closed in to dogfight machineguns... eh, I mean beam weapons take over. Usually the one with either speed and/or range advantage can destroy the opponent whilst „running away“ from him. Armor really doesn’t count in those battles.
I would suggest to add a limitation option for area of engagement for small fighter beam weapons. They can either point forwards or backwards. If you equip a fighter only with forward weapons then you can’t engage your enemy as he closes in, whilst he already can fire on you - even if you would have a range advantage. If you want to fire back directly (with a bomber for example), you install a backwards firing beam weapon.

What would be the gain here? An additional command for fighters „Turn around at range x, fire weapon y on target z, then resume previous course“ gives you the advantage of firing back at a distance where your weapons are effective and can potentially one-kill the pursuer. So we add a tactical element to beam dogfights.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rich.h on July 12, 2019, 07:38:12 AM
On the point of lifepod penalties, could this not be implemented by using a racial trait? We already have various ones so add in a new one that could be called compassion or such, the higher it is then the greater the morale penalties a population suffers from losses such as lifepods. This then easily allows folks to create races of custom opinions and keeps a scalable mechanic in place also.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on July 12, 2019, 01:14:11 PM
On the point of lifepod penalties, could this not be implemented by using a racial trait? We already have various ones so add in a new one that could be called compassion or such, the higher it is then the greater the morale penalties a population suffers from losses such as lifepods. This then easily allows folks to create races of custom opinions and keeps a scalable mechanic in place also.

.. Maybe call it "willingnes to sacrifice"? Honestly I think it would be better to just leave it to roleplay. For example, if I roleplay a honorbound warrior race... it's not a matter of compassion or such. Maybe they think that surviving a lost fight is cowardice. Maybe they think that wasting space for escape pods is stupid and inefficient. I really don't want to reduce something like this to "compassion", there can be a lot of reasons for a race not wanting to save the people in escape pods.

I'd still really just leave it to roleplay. I'm ok with having variable lenght of escape pods duration in designs if people want to.... provided we can also choose to go without escape pods at all.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on July 13, 2019, 02:55:36 AM
Count me as another who would like to be able to configure lifepod duration, even down to nothing for those who want that.  A modest cost for increased duration is entirely reasonable and crew returned to a populated colony should at least add their grade points to the pool.

Since we are on that subject, the ability to move survivors and POWs between ships would also be much appreciated.  It would be nice to be able to rescue a 300 seat pod with two 200 seat shuttles and then offload the survivors to the mothership so the shuttles can go get the next one.  Transferring them to another ship or back onto a shuttle for fast transit to another ship/colony would be useful as well.

If Steve allows putting fighter factories on carriers then making on-board survivors available to crew new fighters would be an interesting dynamic, especially if such ships have to provide new crews themselves instead of automagically drawing from the homeworld.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on July 13, 2019, 03:57:05 PM
While we're on the subject of crews, crew rotation could be an alternative to R&R. At any stop where the crew could R&R, you could instead opt to perform a six-hour action that would muster off your existing crew and take on new crew, at the cost of resetting your vessel performance to the racial training level default (or the minimum, if the vessel class is set to use conscripts). For warships this would normally be counterproductive, but merchant vessels typically do not want to spend two weeks in port while the crew is on shore leave, and don't generally care about the things that crew grade modifies.

On a purely cosmetic note, I think the "use conscript crew" should be changed to "use merchant crew." I have a hard time imagining a modern vessel being entrusted to an impressed crew (outside some neo-Victorian dystopia). Whereas I have no problem at all with imagining orbital miners and fuel refineries being crewed by merchant mariners.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kelewan on July 15, 2019, 10:36:48 AM
I like the escape pod idea. But it should probably come with some more negative effects from not rescuing your personnel. Otherwise I think it will be too tempting to just go with the minimum time on every design. Or perhaps set 14 days as the minimum time.

I, too, love the idea of variable escape pod time that one sets when designing ships.  But I strongly disagree that there should be increased penealties for not rescuing personnel or a fixed minimum duration for life pods.

Whether or not an empire rescues survivors is a *role-playing* decision for that empire, and should not be inflicted on me by game mechanics.  What if my empire is a machine race, and automatically downloads all crew before ship destruction?  What if my empire is a hive mind and sees zero value in rescuing drones?  What if my empire suffers from military chauvinism and views 'death before dishonour' as the overriding principle (in which case, it would be nice if I could prevent my ships from having life pods at all)?

The 'penalty' for too-short a time on your life pods is that you don't get your crew back.  If you want a three-day window, or a three-month window, that should be up to your empire to decide.

I am also in favor of configurable life time for escape pods during ship design, but short lived escape pods, or no escape pods at all also have implications regarding capturing POW
and therefor for intelligence gathering.  This could leave the AI  in an big disadvantage. So some other game mechanics  to offset the disadvantage may be required.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on July 15, 2019, 01:17:49 PM
While we're on the subject of crews, crew rotation could be an alternative to R&R. At any stop where the crew could R&R, you could instead opt to perform a six-hour action that would muster off your existing crew and take on new crew, at the cost of resetting your vessel performance to the racial training level default (or the minimum, if the vessel class is set to use conscripts). For warships this would normally be counterproductive, but merchant vessels typically do not want to spend two weeks in port while the crew is on shore leave, and don't generally care about the things that crew grade modifies.

On a purely cosmetic note, I think the "use conscript crew" should be changed to "use merchant crew." I have a hard time imagining a modern vessel being entrusted to an impressed crew (outside some neo-Victorian dystopia). Whereas I have no problem at all with imagining orbital miners and fuel refineries being crewed by merchant mariners.
I don't think this is much of an issue now that Steve has removed crew morale for commercial vessels. So we can RP crew rotation to be taking place among them easily enough.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on July 15, 2019, 01:41:45 PM
I like the escape pod idea. But it should probably come with some more negative effects from not rescuing your personnel. Otherwise I think it will be too tempting to just go with the minimum time on every design. Or perhaps set 14 days as the minimum time.

I, too, love the idea of variable escape pod time that one sets when designing ships.  But I strongly disagree that there should be increased penealties for not rescuing personnel or a fixed minimum duration for life pods.

Whether or not an empire rescues survivors is a *role-playing* decision for that empire, and should not be inflicted on me by game mechanics.  What if my empire is a machine race, and automatically downloads all crew before ship destruction?  What if my empire is a hive mind and sees zero value in rescuing drones?  What if my empire suffers from military chauvinism and views 'death before dishonour' as the overriding principle (in which case, it would be nice if I could prevent my ships from having life pods at all)?

The 'penalty' for too-short a time on your life pods is that you don't get your crew back.  If you want a three-day window, or a three-month window, that should be up to your empire to decide.

I am also in favor of configurable life time for escape pods during ship design, but short lived escape pods, or no escape pods at all also have implications regarding capturing POW
and therefor for intelligence gathering.  This could leave the AI  in an big disadvantage. So some other game mechanics  to offset the disadvantage may be required.
If the AI can set its own policy, even just choosing one at random at race creation, that would make it even.  If crew are valuable enough that whether or not to rescue them is a legitimate strategic choice, not just for RP, then that should be enough to keep it balanced and interesting.

I don't think this is much of an issue now that Steve has removed crew morale for commercial vessels. So we can RP crew rotation to be taking place among them easily enough.
So combined with the unlimited fuel glitch my geosurvey ships will now have unlimited endurance?   :D

Seriously, though, I've been using crew morale to keep track of such ships' deployment times.  This means I won't have any way to know when to bring them in for shore leave.

Edit: I just checked and survey ships will still have morale, but other civilian ships won't.  Other small civilian ships would still be affected.
Title: Re: C# Aurora v0.x Suggestions
Post by: TheRowan on July 16, 2019, 02:48:40 AM
On the point of lifepod penalties, could this not be implemented by using a racial trait? We already have various ones so add in a new one that could be called compassion or such, the higher it is then the greater the morale penalties a population suffers from losses such as lifepods. This then easily allows folks to create races of custom opinions and keeps a scalable mechanic in place also.

.. Maybe call it "willingnes to sacrifice"? Honestly I think it would be better to just leave it to roleplay. For example, if I roleplay a honorbound warrior race... it's not a matter of compassion or such. Maybe they think that surviving a lost fight is cowardice. Maybe they think that wasting space for escape pods is stupid and inefficient. I really don't want to reduce something like this to "compassion", there can be a lot of reasons for a race not wanting to save the people in escape pods.

I'd still really just leave it to roleplay. I'm ok with having variable lenght of escape pods duration in designs if people want to.... provided we can also choose to go without escape pods at all.

That could be an interesting variable to distinguish NPRs diplomatically too... a race with high compassion could get an opinion boost if you pick up their survivors after battle (even if they're prisoners, at least they're alive) or an opinion penalty if you leave their lifepods to expire. Conversely, the stereotypical honourbound warriors might respect you more for letting their crew die a swift death rather than taking them prisoner.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on July 16, 2019, 09:11:52 AM
That could be an interesting variable to distinguish NPRs diplomatically too... a race with high compassion could get an opinion boost if you pick up their survivors after battle (even if they're prisoners, at least they're alive) or an opinion penalty if you leave their lifepods to expire. Conversely, the stereotypical honourbound warriors might respect you more for letting their crew die a swift death rather than taking them prisoner.


Likewise, the ability to return captured personnel to their empire of origin should be added, and an empire's willingness to do so (or not) and the original empire's opinion of such should also affect diplomacy.  The Happy Individualists of Rygel IV should like me more for returning their captured people, whereas the Hiveworms of Mimicia II should take the opportunity to destroy my units along with their failed drones.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on July 16, 2019, 11:29:14 AM
On the topic of missile defence I have a couple of suggestions:

1) For beam defence, an option during turret design to include a CIWS scale sensor and fire control.  When not linked to a fire control or when linked to a fire control in any PD mode and attacked by an invisible missile, such as during jump blindness, such a turret would act as a regular CIWS.

2) For AMMs, an option to prefer wider incoming volleys before closer ones.  This helps when the enemy is firing more missiles than you can shoot down and you want to thin them as much as possible before your beam PD cleans up.

3) AMM intercept validation.  This doesn't just apply to self defence but also to area defence, which is a harder problem to solve.  Currently AMMs will attempt to shoot down missiles that are too close to their target to catch, wasting the entire volley.  Worse, this weakness can be exploited at range.  If the attacker can match the defender volley-for-volley and can get even a single missile inside that critical band every exchange then the defender's AMM defence will collapse completely with no chance of recovery.  Once anything gets through, everything gets through.  Currently the only mitigation is to disable AMM completely to save your missiles.  The only saving grace is that the NPRs don't exploit it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on July 16, 2019, 11:43:19 AM
I think (2) and (3) could be collapsed into an AMM PD setting toggle to 'prefer targetting further away salvoes over closer ones' which is the opposite of what Aurora does now.

As someone who almost never uses AMM PD, and when I do only at 1v1, I think many of these problems can be solved -- or at least strongly mitigated -- by fine-tuning the fire control to launcher ratio on AMM ships.

Though most of all, I would like to see point defense ditch the 'salvo' concept and change to an 'all missiles within X radius' system where it wouldn't matter if I'm shooting at 24 missiles from a single BCR or 24 missiles from a dozen bombers.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on July 16, 2019, 02:15:52 PM
I think (2) and (3) could be collapsed into an AMM PD setting toggle to 'prefer targetting further away salvoes over closer ones' which is the opposite of what Aurora does now.

As someone who almost never uses AMM PD, and when I do only at 1v1, I think many of these problems can be solved -- or at least strongly mitigated -- by fine-tuning the fire control to launcher ratio on AMM ships.

Though most of all, I would like to see point defense ditch the 'salvo' concept and change to an 'all missiles within X radius' system where it wouldn't matter if I'm shooting at 24 missiles from a single BCR or 24 missiles from a dozen bombers.
'Target furthest salvo' would help in most cases, and is in fact what I was initially going to ask for, but it is less efficient than 'target widest salvo'.

I must respectfully disagree.  The defender's fire control to launcher ratio doesn't make any difference, nor does changing the AMM per ASM PD setting.  All the attacker needs is FC and reload rate parity, a small* tube advantage, and enough magazine depth for sustained fire until the defender dies.  While that should generally be the case, the problem is that the numbers are a lot lower than they should be.  Even a single tube advantage becomes total superiority.  How the attacker matches tubes to FC's makes no difference beyond 'every FC has at least one tube', and any mismatch in salvo size between attacker and defender is always in the attacker's favour.  The only possible counters under current rules are: manual PD targeting, putting big enough sensors on AMMs to find incoming ASMs, or outrunning them.  Good luck with that.TM

While I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions.  That seems a bit much.

*The minimum tubes is (defender tubes * defender cth + 1), with the optimum being (defender tubes * defender cth + #FCs), so if the defender's AMMs have 50% cth, only 50%+1 tubes are needed.  Even against 100% cth AMMs the attacker only needs one more tube.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on July 16, 2019, 03:43:57 PM
Are you completely excluding beam PD from this?  Personally, I have never tried to 100% stop incoming missiles with AMMs.  I have only ever experimented with set ups designed to thin their numbers and have always used beam PD, shields, and armour to absorb the leakers.  (Sometimes I use entire battleships to absorb the leakers.  #:-] )

- - -

If Steve is going to reprogram AMM PD from 'target nearest salvo' to (optionally) 'target furthest salvo', I don't expect it would be too much trouble to also add 'target largest salvo' to the radio buttons.

- - -

Quote
While I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions.  That seems a bit much.

Oh, I didn't mean a radius from the firing ship; but rather a radius around the initial target.  So if I shoot / launch AMMs at incoming Missile #578984632115, let the same FC also shoot / launch at any missiles within, say, 5,000 km of it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on July 16, 2019, 03:44:14 PM
I think (2) and (3) could be collapsed into an AMM PD setting toggle to 'prefer targetting further away salvoes over closer ones' which is the opposite of what Aurora does now.

As someone who almost never uses AMM PD, and when I do only at 1v1, I think many of these problems can be solved -- or at least strongly mitigated -- by fine-tuning the fire control to launcher ratio on AMM ships.

Though most of all, I would like to see point defense ditch the 'salvo' concept and change to an 'all missiles within X radius' system where it wouldn't matter if I'm shooting at 24 missiles from a single BCR or 24 missiles from a dozen bombers.

'Target furthest salvo' would help in most cases, and is in fact what I was initially going to ask for, but it is less efficient than 'target widest salvo'.

I must respectfully disagree.  The defender's fire control to launcher ratio doesn't make any difference, nor does changing the AMM per ASM PD setting.  All the attacker needs is FC and reload rate parity, a small* tube advantage, and enough magazine depth for sustained fire until the defender dies.  While that should generally be the case, the problem is that the numbers are a lot lower than they should be.  Even a single tube advantage becomes total superiority.  How the attacker matches tubes to FC's makes no difference beyond 'every FC has at least one tube', and any mismatch in salvo size between attacker and defender is always in the attacker's favour.  The only possible counters under current rules are: manual PD targeting, putting big enough sensors on AMMs to find incoming ASMs, or outrunning them.  Good luck with that.TM

While I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions.  That seems a bit much.

*The minimum tubes is (defender tubes * defender cth + 1), with the optimum being (defender tubes * defender cth + #FCs), so if the defender's AMMs have 50% cth, only 50%+1 tubes are needed.  Even against 100% cth AMMs the attacker only needs one more tube.

The problem is not Fire-Controls in and of itself, especially not against AMM. If you want to fire say one missile per enemy ASM the problem with Fire-Control usually crop up since you only fire on one salvo so the defender are generally wasting more fire-controls. If a salvo contain say 6 missiles and the defender only have five AMM per fire control you need tow fire-controls to engage that salvo with one missile and waste four missiles in that 5sec turn. Even if there are more missiles incoming, there are no reason that you could not target more missiles from a realistic point of view unless you want to twist and bend the technobabble to fit the narrative.

The thing is way worse for beam fire-controls that can easily be saturated. One problem is that five different missiles fired with the same fire-control create five different salvos as one example.

I don't think that engaging missiles coming in from different direction (in the same 5 sec turn) happen enough in an actual game that it is reasonable to bring up as a reason against engagement of missile fire-control salvos. In that case I would settle for engaging missiles with the same position if that would be a major issue and ignoring the fire-control issue.

Full size missile launcher against an equal tech level opponent is often a waste of resources since beam point defence are too effective (at least until rather late in the game when beam PD become useless, although I never play that late). The only way you can beat beam PD is by saturating the PD by gaming the system (which is possible if you want to). Thus you need reduced sized launchers rather than deep magazines of missiles so you can hopefully overpower the enemies beam PD, this is where AMM become really important.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on July 16, 2019, 04:41:20 PM
Are you completely excluding beam PD from this?  Personally, I have never tried to 100% stop incoming missiles with AMMs.  I have only ever experimented with set ups designed to thin their numbers and have always used beam PD, shields, and armour to absorb the leakers.  (Sometimes I use entire battleships to absorb the leakers.  #:-] )

- - -

If Steve is going to reprogram AMM PD from 'target nearest salvo' to (optionally) 'target furthest salvo', I don't expect it would be too much trouble to also add 'target largest salvo' to the radio buttons.

- - -

Quote
While I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions.  That seems a bit much.

Oh, I didn't mean a radius from the firing ship; but rather a radius around the initial target.  So if I shoot / launch AMMs at incoming Missile #578984632115, let the same FC also shoot / launch at any missiles within, say, 5,000 km of it.

I think that you would perhaps like to choose what is the priority and in which order. I would for the most part like to target largest salvo first, furthest out second and closest last.

I would also like to have a minimum salvo size to even shoot AMM in the first place to also be in the game.

In general... wasting AMM to shoot down 100% of incoming anti-ship missiles is usually a wasteful doctrine which pretty much anyone living in that world should recognise quite quickly, especially using low tech AMM which can be very bad at shooting down ASM.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on July 16, 2019, 05:23:34 PM
Are you completely excluding beam PD from this?  Personally, I have never tried to 100% stop incoming missiles with AMMs.  I have only ever experimented with set ups designed to thin their numbers and have always used beam PD, shields, and armour to absorb the leakers.  (Sometimes I use entire battleships to absorb the leakers.  #:-] )

- - -

If Steve is going to reprogram AMM PD from 'target nearest salvo' to (optionally) 'target furthest salvo', I don't expect it would be too much trouble to also add 'target largest salvo' to the radio buttons.

- - -

Quote
While I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions.  That seems a bit much.

Oh, I didn't mean a radius from the firing ship; but rather a radius around the initial target.  So if I shoot / launch AMMs at incoming Missile #578984632115, let the same FC also shoot / launch at any missiles within, say, 5,000 km of it.
The point is that against this exploit you need enough beam defence that missile defence didn't matter anyway.  Once triggered 100% of incoming missiles leak.  While the AI doesn't deliberately exploit it I have lost ships to it, though I didn't understand it at the time.  The AI is defenceless against it and it also negates missile defence in hotseat games since it is simple to exploit.

----

Adding either option should be no harder than the other.  While I consider one better than the other I am in no way against adding both.   :)

----

That supposedly is what missile sensors are for, but good luck mounting those on AMMs before late game in VB or at all in C# due to the new minimum sensor size.

The problem is not Fire-Controls in and of itself, especially not against AMM. If you want to fire say one missile per enemy ASM the problem with Fire-Control usually crop up since you only fire on one salvo so the defender are generally wasting more fire-controls. If a salvo contain say 6 missiles and the defender only have five AMM per fire control you need tow fire-controls to engage that salvo with one missile and waste four missiles in that 5sec turn. Even if there are more missiles incoming, there are no reason that you could not target more missiles from a realistic point of view unless you want to twist and bend the technobabble to fit the narrative.

The thing is way worse for beam fire-controls that can easily be saturated. One problem is that five different missiles fired with the same fire-control create five different salvos as one example.

I don't think that engaging missiles coming in from different direction (in the same 5 sec turn) happen enough in an actual game that it is reasonable to bring up as a reason against engagement of missile fire-control salvos. In that case I would settle for engaging missiles with the same position if that would be a major issue and ignoring the fire-control issue.

Full size missile launcher against an equal tech level opponent is often a waste of resources since beam point defence are too effective (at least until rather late in the game when beam PD become useless, although I never play that late). The only way you can beat beam PD is by saturating the PD by gaming the system (which is possible if you want to). Thus you need reduced sized launchers rather than deep magazines of missiles so you can hopefully overpower the enemies beam PD, this is where AMM become really important.

If the enemy is attacking with more missiles per salvo than my AMM is set up for, I just reassign some tubes.  What saturates missile PD is that it takes more than one outgoing salvo to completely kill an incoming one, so you want more FCs than the enemy has.

I've never tried linking different types of ASM to the same FC since I always standardize my loads so I will need to test that.  Otherwise I've never seen a missile FC create more than one salvo per tick.  As long as they arrive one salvo at a time then one beam FC can keep up with them.

While I misunderstood Father Tim's objection I stand by what I said.

The exploit is that you only need about half as many launchers and a quarter the missiles that you should to defeat AMMs.  Theoretically even a start-game attacker could exploit this against an end-game defender.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on July 16, 2019, 05:47:05 PM
Are you completely excluding beam PD from this?  Personally, I have never tried to 100% stop incoming missiles with AMMs.  I have only ever experimented with set ups designed to thin their numbers and have always used beam PD, shields, and armour to absorb the leakers.  (Sometimes I use entire battleships to absorb the leakers.  #:-] )

- - -

If Steve is going to reprogram AMM PD from 'target nearest salvo' to (optionally) 'target furthest salvo', I don't expect it would be too much trouble to also add 'target largest salvo' to the radio buttons.

- - -

Quote
While I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions.  That seems a bit much.

Oh, I didn't mean a radius from the firing ship; but rather a radius around the initial target.  So if I shoot / launch AMMs at incoming Missile #578984632115, let the same FC also shoot / launch at any missiles within, say, 5,000 km of it.
The point is that against this exploit you need enough beam defence that missile defence didn't matter anyway.  Once triggered 100% of incoming missiles leak.  While the AI doesn't deliberately exploit it I have lost ships to it, though I didn't understand it at the time.  The AI is defenceless against it and it also negates missile defence in hotseat games since it is simple to exploit.

----

Adding either option should be no harder than the other.  While I consider one better than the other I am in no way against adding both.   :)

----

That supposedly is what missile sensors are for, but good luck mounting those on AMMs before late game in VB or at all in C# due to the new minimum sensor size.

The problem is not Fire-Controls in and of itself, especially not against AMM. If you want to fire say one missile per enemy ASM the problem with Fire-Control usually crop up since you only fire on one salvo so the defender are generally wasting more fire-controls. If a salvo contain say 6 missiles and the defender only have five AMM per fire control you need tow fire-controls to engage that salvo with one missile and waste four missiles in that 5sec turn. Even if there are more missiles incoming, there are no reason that you could not target more missiles from a realistic point of view unless you want to twist and bend the technobabble to fit the narrative.

The thing is way worse for beam fire-controls that can easily be saturated. One problem is that five different missiles fired with the same fire-control create five different salvos as one example.

I don't think that engaging missiles coming in from different direction (in the same 5 sec turn) happen enough in an actual game that it is reasonable to bring up as a reason against engagement of missile fire-control salvos. In that case I would settle for engaging missiles with the same position if that would be a major issue and ignoring the fire-control issue.

Full size missile launcher against an equal tech level opponent is often a waste of resources since beam point defence are too effective (at least until rather late in the game when beam PD become useless, although I never play that late). The only way you can beat beam PD is by saturating the PD by gaming the system (which is possible if you want to). Thus you need reduced sized launchers rather than deep magazines of missiles so you can hopefully overpower the enemies beam PD, this is where AMM become really important.

If the enemy is attacking with more missiles per salvo than my AMM is set up for, I just reassign some tubes.  What saturates missile PD is that it takes more than one outgoing salvo to completely kill an incoming one, so you want more FCs than the enemy has.

I've never tried linking different types of ASM to the same FC since I always standardize my loads so I will need to test that.  Otherwise I've never seen a missile FC create more than one salvo per tick.  As long as they arrive one salvo at a time then one beam FC can keep up with them.

While I misunderstood Father Tim's objection I stand by what I said.

The exploit is that you only need about half as many launchers and a quarter the missiles that you should to defeat AMMs.  Theoretically even a start-game attacker could exploit this against an end-game defender.

Well... I often play with multiple human controlled factions and I find the fire-control mechanic problematic even when I don't exploit obvious game mechanics. Especially against beam PD fire-controls. Things like mixing of huge box launched single salvos and multiple small box launched salvos from fighters forces the defender to use too much resources on beam fire-controls which are quite expensive. Against large box launched salvos it is huge overkill and expensive, but you still need them against much smaller but numerous salvos if fighter launched. The defender always draws the shortest straw no matter what.

Against AMM it is not as big of a problem, but it does exist there as well in terms of general cost in fire-control you need against versus the enemy fire-controls for ASM.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bartimeus on July 18, 2019, 08:48:34 AM
Hello all,

I have a little suggestion/idea.
In VBS 6 some officier have the trait "political relation" which give them a bonus for promotion(right?). Will it be possible to create ourself other "trait" with promotion bonus ? I have an idea of a aristocratic game were people belonging to certain great family/house have more chance of getting promote than lambda officier.
Is it doable ? This possibility already existe ? I know we can trick it bu using the medal system.

Bye bye 
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on July 18, 2019, 11:26:29 AM
Yeah you can use the medal system to do this in VB6. Steve hasn't said anything of this sort for C# - and the political reliability bonus can be made meaningless in the game setup options, if you want to.

Personally, I think using the medal system is the best option for this, because it's such a niche case. Since medals can give both positive or negative promotion points.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 18, 2019, 12:05:28 PM
An idea for planetary growth maximum: in C# we will get an upper limit to populations on a body. Really good thing this... so I was wondering: with technology everything can be extended. But it also might get very fragile that way. A civilization which is for example very limited in space to expand might come up with technology to cram more people into small space. Also to extend the food production etc.

So how about a building which will do exactly that? It provides food production, services, etc, and thereby extends the maximum population on a planet by 10.000 people (this building does nothing but provides this amount of people; everything else is already simulated by the pop numbers). Pop then can grow over the limit which gives additional free jobs which you then can use to build more industry, etc.

Then comes a Desaster or an enemy bombardment destroys 80% of these buildings... and your people begin to die because of overpopulation and starvation etc... . So you have a Choice... Build tall but eventually fragile, or wide and save...

Just a thought...
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on July 18, 2019, 03:39:54 PM
IIRC you can go over the planetary population maximum. However, it comes with the drawback of zero population growth and increasing political instability.
Title: Re: C# Aurora v0.x Suggestions
Post by: dukea42 on July 19, 2019, 01:06:16 PM
So how about a building which will do exactly that?

It's already in the game as orbital habitats http://aurora2.pentarch.org/index.php?topic=8495.msg106761#msg106761 and just infrastructure if not yet habitable on the surface.

I also believe you can genemod your population's density attribute.
Title: Re: C# Aurora v0.x Suggestions
Post by: amschnei on July 20, 2019, 12:32:30 AM
Steve,

Since you mentioned elsewhere that military academies can be assigned directors now, it might be nice if they could be named also.  So instead of assigning a high level general to just a “military academy” I can have him run “West Point”, or assign a laser researcher to the “Mars High Energy Physics Institute” or whatever.  Would be a nice cosmetic thing.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on July 20, 2019, 05:50:25 AM
Yeah, this sounds really superfluous because of the improvements to orbital habitats and the possibility of LG infrastructure AND genetic modification.
Title: Ship name list manipulation
Post by: Stryker on July 20, 2019, 02:14:45 PM
A feature I would like to see would be the ability to manipulate ship name lists.   Currently, you can add a ship name list by creating a text file and this is fine for new lists.   However, there is no way to manipulate the existing lists.   For example: I never use the alphabetical lists.   The ability to move these to the left hand pane would reduce the number of list I have to scroll through to reach a list I want to use.   I also always use the Hippy list.   Since I could not find a posting for this list, I ended up having to re-type the entire list and add it to the game.   

I would suggest being able to select a name list (or multiple lists) in the left hand panel and add them to the right hand panel.   Additionally the ability to select one or multiple lists in the right hand panel and shift them to the left hand panel (I don't wish to remove the names permanently, I may wish to use them later).   This would allow the player to keep the "in use" ship lists smaller, but easily add more later if he chooses without having to re-type them or add an existing list outside the game.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 21, 2019, 02:25:25 AM
Yeah, this sounds really superfluous because of the improvements to orbital habitats and the possibility of LG infrastructure AND genetic modification.
Yeah, you are right, forgotten about that. My suggestion seems only different in general gameplay. Though would be nice to know what happens if you add living space on a body and those stations got shot down. Does the population instantly disappear with them or are they left on the body and slowly die away?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on July 21, 2019, 04:37:08 AM
Yeah, this sounds really superfluous because of the improvements to orbital habitats and the possibility of LG infrastructure AND genetic modification.
Though would be nice to know what happens if you add living space on a body and those stations got shot down. Does the population instantly disappear with them or are they left on the body and slowly die away?
The pop remains. Orbital habs are just a form of infrastructure.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on July 21, 2019, 08:38:21 AM
Instead of Exclude (qualifier) for the logistics list, it might be better to have Include (qualifier). ie. Include (Armed), (FAC), (Fighters), (Tanker), (Supply), (Collier), (Freighter), (Civilian), (In Shipyard), and just tick all the boxes at  the start of the game so the entire navy is on the list.

Civilian would be the catch all for terraformers, fuel harvesters and any other ships not otherwise on the list. And yes, if a ship is a supply, fuel and ordnance support ship that does mean that they can qualify for the list on all of them.
Title: Re: C# Aurora v0.x Suggestions
Post by: ReviewDude01 on July 21, 2019, 12:29:13 PM
Make a button that deletes all missiles (and if applicable drones mines countermeasures)  in a system.

This is very useful in single player scenarios where a player is already 100% sure that enemy AI cannot get past his point defence but AI is still shooting 50 missiles per minute that severely slow down the game.

Another option in my opinion far better one is to make AI stop shooting missiles and choose a different behaviour if lets say last 3 full salvoes shot by AI had 0% hit rate (all shot down by PD).

edit: this behaviour could stay until a ship by player takes a damage so there might be a change in PD or/and until AI get reinforcements and/or until some time runs out

sorry for bad english/grammar

edit2: make all/most weapon size techs severely cheaper to research with some numbers rebalance. big cannons should have a slow reload time and another tech pre-requesites to be effective for example capacitor recharge rate. some games just do it wrong where bigger cannons are better and expensive to research and its not very logical compared to real world engineering
I think that bigger cannons should be primarily about design choice (possibly inefficient big cannons or more versatile small ones or more point defence) not about tech levels.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on July 22, 2019, 08:33:53 AM

Another option in my opinion far better one is to make AI stop shooting missiles and choose a different behaviour if lets say last 3 full salvoes shot by AI had 0% hit rate (all shot down by PD).


This is a very good idea that should be made a note of. Dumping your entire missile stocks into space should be a conscious choice not default behaviour. An entire Missile Attack AI might be a good thing to implement, considering how important missiles are to combat in Aurora. It should consider the following:

I can take a look at figuring out a decision tree that Steve can just implement. Sounds like a fun project. Won't be able to do the code, but I think Steve likes doing that himself anyway.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on July 22, 2019, 12:05:55 PM
Worth double checking what Steve has posted about improvements to AI, since he has worked on it quite a bit.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on July 22, 2019, 01:07:00 PM
I have read through that, but from what I saw it mostly pertains to top down ai levels so far. Empire, sector, fleet command, battlegroup, fleet unit, etc. My suggestion was exactly that a 'fire control' ai is added that feeds back into fleet unit ai level.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on July 22, 2019, 01:45:46 PM
Make a button that deletes all missiles (and if applicable drones mines countermeasures)  in a system.

This is very useful in single player scenarios where a player is already 100% sure that enemy AI cannot get past his point defence but AI is still shooting 50 missiles per minute that severely slow down the game.

Another option in my opinion far better one is to make AI stop shooting missiles and choose a different behaviour if lets say last 3 full salvoes shot by AI had 0% hit rate (all shot down by PD).

edit: this behaviour could stay until a ship by player takes a damage so there might be a change in PD or/and until AI get reinforcements and/or until some time runs out

sorry for bad english/grammar

edit2: make all/most weapon size techs severely cheaper to research with some numbers rebalance. big cannons should have a slow reload time and another tech pre-requesites to be effective for example capacitor recharge rate. some games just do it wrong where bigger cannons are better and expensive to research and its not very logical compared to real world engineering
I think that bigger cannons should be primarily about design choice (possibly inefficient big cannons or more versatile small ones or more point defence) not about tech levels.
Such a button might be appropriate for SM mode.
C# is reportedly much faster than VB, so missile spam shouldn't cause significant lag anymore.
Missile ship AI could use some work.
Larger weapons already have slower reload times.  Weapon size is a design choice and larger weapons are harder to design and build, just like in real life.
That would be a major balance and mechanics change.  It Steve even considers it, it will be after C#1.0 comes out.
Title: Re: C# Aurora v0.x Suggestions
Post by: Ranged66 on July 22, 2019, 02:04:31 PM
Simple game creation setting:

Jump point distance modifier. Default 100% (current). Multiplies how far on average jump points will spawn from system primary.


Medium suggestion:
Give system secondary stars above a certain mass threshold LaGrange/intra system point(s)! Makes those 0.2 ly radius systems a bit more than a novelty.

Hard suggestion:
Allow jump points to spawn against different stars than the system primary.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on July 27, 2019, 02:44:12 AM
Something that came up in my current game:  A switch to turn off automatic damage control for a ship.  I have a carrier hauling a severely mangled destroyer back to port for scrapping and the thing is merrily chewing through MSP trying to fix itself.
Title: Re: C# Aurora v0.x Suggestions
Post by: amschnei on July 28, 2019, 10:38:18 AM
I tried to post this as a guest, and don’t think it came up, so apologies if it’s a repost, but:

With the new ability to appoint military academy commanders in C# it would be a nice thing to be able to rename academies like you can with shipyards.  That way instead of assigning your high level general to run earth military academy you could have him run “West Point”, or assign your favored laser scientist to train up new scientific personnel at “Mars High Energy Physics Institute” or whatever fits one’s role play needs.
Title: Re: C# Aurora v0.x Suggestions
Post by: Ranged66 on July 28, 2019, 11:34:29 AM
'Skip current order' button please :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on July 28, 2019, 01:25:05 PM
'Skip current order' button please :)

Not quite sure you mean by this.

If you are in Sol, your first order is Transit to Alpha Centauri and your second order is move to Alpha Centauri-A I, how could you skip the first one?
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on July 28, 2019, 02:07:20 PM
'Skip current order' button please :)

Not quite sure you mean by this.
Suppose you have a freighter or survey vessel set up to collect minerals from ten different systems and drop them off in your central mining hub, and one of those systems develops a bad case of unfriendly alien warships. Having to reconstruct the entire order queue for the freighter (and then re-reconstruct it after you've cleared out the baddies) is a lot of tedious clicking just for skipping a single pickup.

Quote
If you are in Sol, your first order is Transit to Alpha Centauri and your second order is move to Alpha Centauri-A I, how could you skip the first one?
That would be theoretically fixable by checking whether the second order remains valid without the first order. Perhaps a better way to do it would be a "skip to next valid order" function (so a vessel in Sol that was set up to go to Alpha Centauri, come back, and report to Earth for overhaul would skip the whole round trip to AC and go directly to Earth for overhaul). I'm not sure how practical that is to code, though - that would depend on how easy it is to identify orders that would be valid in counterfactual scenarios.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on July 28, 2019, 06:02:10 PM
'Skip current order' button please :)

Not quite sure you mean by this.
Suppose you have a freighter or survey vessel set up to collect minerals from ten different systems and drop them off in your central mining hub, and one of those systems develops a bad case of unfriendly alien warships. Having to reconstruct the entire order queue for the freighter (and then re-reconstruct it after you've cleared out the baddies) is a lot of tedious clicking just for skipping a single pickup.

Quote
If you are in Sol, your first order is Transit to Alpha Centauri and your second order is move to Alpha Centauri-A I, how could you skip the first one?
That would be theoretically fixable by checking whether the second order remains valid without the first order. Perhaps a better way to do it would be a "skip to next valid order" function (so a vessel in Sol that was set up to go to Alpha Centauri, come back, and report to Earth for overhaul would skip the whole round trip to AC and go directly to Earth for overhaul). I'm not sure how practical that is to code, though - that would depend on how easy it is to identify orders that would be valid in counterfactual scenarios.

The amount of code that would be required to handle checking every conceivable combination of orders to see if removing the first would make the second impossible would be huge.

You can store order templates very easily in C# Aurora so that is probably a better option than the above.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on July 29, 2019, 09:55:41 AM
The ability to change the assigned name of another race's ship class in the intelligence screen would be nice, since it doesn't seem like that can be done in the current version.

Also, I briefly mentioned this elsewhere, but I think that being able to eventually establish an embassy on another race's planet, maybe using diplomatic units similar to to archaeological units, would be cool, and open the way to espionage that goes beyond special ship sensors.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on July 29, 2019, 11:59:52 AM
The ability to change the assigned name of another race's ship class in the intelligence screen would be nice, since it doesn't seem like that can be done in the current version.

You can do this on VB6 and C#. For VB6 it is the Rename Class button on the Tactical Intelligence tab of the Intelligence window.
Title: Re: C# Aurora v0.x Suggestions
Post by: totos_totidis on July 31, 2019, 05:29:13 AM
Planets in c# will have a max population. What about adding the ability to increase the population capacity of planets with research? Adding technologies such as urbanisation tech and/or arcologies would add an interesting dimension to planetairy development.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on July 31, 2019, 09:43:37 AM
Planets in c# will have a max population. What about adding the ability to increase the population capacity of planets with research? Adding technologies such as urbanisation tech and/or arcologies would add an interesting dimension to planetairy development.
Had asked the same a while ago. You can add pop max with space stations, so no need to add such a tech tree (yet).
Title: Re: C# Aurora v0.x Suggestions
Post by: totos_totidis on August 01, 2019, 07:52:32 AM
You can, but I suggest a tech line for increasing urbanisation as an alternative.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on August 01, 2019, 12:07:39 PM
I get what you're going for but it's the same problem as with space elevators and mobility for ground units and bunch of other suggestions, in that it encroaches on the RP side of the game by providing detail that is actually unnecessary for game play purposes.

What's the difference between a space elevator and a level X space port in a game where such things only affect the loading and unloading speeds of ships? What's the difference between a walking tank and a tracked tank in a game that does not model more than 1 terrain type per planetary body nor any sort of tactical combat? What's the difference between researching Arcology tech and building Orbital Habitats in a game where both just add additional population capacity on a body?

The population densities that C# will allow are already pretty generous. Earth will have capacity for 12,000,000,000 people. That's a lot when you remember that it isn't just the physical space that all those bodies require - and you can't stack people like firewood - but also their jobs, their entertainment, their food production, their energy production, the entire trade goods sector and more.

If/when Aurora beings to model the civilian sector in more detail, including food and energy production and consumption, such techs will become useful additions.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on August 01, 2019, 05:02:07 PM
What's the difference between researching Arcology tech and building Orbital Habitats in a game where both just add additional population capacity on a body?
Orbital habitats are spacecraft.  There's a pretty obvious and big mechanical difference.
Title: Re: C# Aurora v0.x Suggestions
Post by: totos_totidis on August 03, 2019, 04:34:28 AM
I was suggesting urbanization tech due to the following reason: A lower tech level society cannot support the same number of people on a planet as a higher tech one, I am proposing to model that. Also buildable archologies are a high tech level structure that is to be considered as an addendum to the original idea. The original idea was adding a racial population density modifier that increases with technology.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on August 03, 2019, 04:46:38 AM
Orbital habitats are spacecraft.  There's a pretty obvious and big mechanical difference.
But that doesn't actually matter.

The game does not model the commute of workers or the cost of transporting goods so it's meaningless whether population commutes from orbit to the surface or across oceans or is actually housed entirely in an underground bunkers - that's all left to the player to describe/imagine how they see fit for their "story". Neither does a TN-nuke care whether it's target is an orbital habitat, destruction of which might turn population growth negative, or the population itself - both cause a loss of population, one just does it more rapidly than the other.

I was suggesting urbanization tech due to the following reason: A lower tech level society cannot support the same number of people on a planet as a higher tech one, I am proposing to model that.
Unless I'm misunderstanding what you mean here, this is still completely irrelevant. We're not talking about Medieval urban areas without sanitation, health services or refrigerated food transport. Once you have running water and electricity and vaccinations, there is technically no limit to population density that your society can support.

And because Aurora does not model any of that, adding a tech line that arbitrarily increases population density seems pointless. There already is a Construction tech line that makes Infrastructure more efficient and a Biology tech line that makes Terraforming faster.

I'm sorry if I come across as hostile, that's not my intention. Again, if/when Aurora models civilian society down to food, energy and health care production/consumption/distribution level, then your proposal would absolutely be useful and should be added.
Title: Re: C# Aurora v0.x Suggestions
Post by: Borealis4x on August 04, 2019, 01:51:27 AM
How about adding automation tech that lowers the need for crew members and increases efficiency in  exchange for higher costs? The upper-scale of such tech would be sentient AI's that eliminate the need for crew on most ships and can gain experience like regular crew while still being more efficient out of the gate.

The only problem is if the AI gets any funny ideas of its own...
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on August 04, 2019, 03:44:07 AM
Lowering crew requirements as either an 'lower the crew requirements of the entire ship, round upwards' modifier, as part of the parts designer or as entirely new parts are quite possible, if not necessarily what Steve will want to deal with.

AI rebellion? That'd be a lot of work for him to work out how that'll work and program.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on August 04, 2019, 10:37:02 PM
Neither does a TN-nuke care whether it's target is an orbital habitat, destruction of which might turn population growth negative, or the population itself - both cause a loss of population, one just does it more rapidly than the other.
Unless I'm mistaken, the nuke hitting a habitat has no possibility of damaging installations or causing atmospheric dust.  Also, there are of course going to be differences regarding sensor interaction, I think.

And because Aurora does not model any of that, adding a tech line that arbitrarily increases population density seems pointless. There already is a Construction tech line that makes Infrastructure more efficient and a Biology tech line that makes Terraforming faster.
I actually think the way to implement this would simply be to allow infrastructure to increase the body's population capacity, still governed by the efficiency tech, and maybe getting less efficient the more you're using infrastructure to boost the population capacity.  The specifics would be left up to player imagination, and the simplicity explains the wide range of usability.

For planets that already need infastructure, I imagine the way it would work is that once you hit the population capacity the planet would have if its colony cost was 0, you would need to add the infrastructure for the colony cost to the infrastructure for bypassing pop-cap together in order to achieve the same effect.  So, if you need 200 infrastructure to raise a colony cost 0 planet's pop cap by 1 million, and the planet has a colony cost of 2, you'd need 400 infrastructure to raise that planet's pop cap by 1 millions.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on August 05, 2019, 01:16:28 PM
Neither does a TN-nuke care whether it's target is an orbital habitat, destruction of which might turn population growth negative, or the population itself - both cause a loss of population, one just does it more rapidly than the other.
Unless I'm mistaken, the nuke hitting a habitat has no possibility of damaging installations or causing atmospheric dust.  Also, there are of course going to be differences regarding sensor interaction, I think.

And because Aurora does not model any of that, adding a tech line that arbitrarily increases population density seems pointless. There already is a Construction tech line that makes Infrastructure more efficient and a Biology tech line that makes Terraforming faster.
I actually think the way to implement this would simply be to allow infrastructure to increase the body's population capacity, still governed by the efficiency tech, and maybe getting less efficient the more you're using infrastructure to boost the population capacity.  The specifics would be left up to player imagination, and the simplicity explains the wide range of usability.

For planets that already need infastructure, I imagine the way it would work is that once you hit the population capacity the planet would have if its colony cost was 0, you would need to add the infrastructure for the colony cost to the infrastructure for bypassing pop-cap together in order to achieve the same effect.  So, if you need 200 infrastructure to raise a colony cost 0 planet's pop cap by 1 million, and the planet has a colony cost of 2, you'd need 400 infrastructure to raise that planet's pop cap by 1 millions.
If we go down that route, it would make more sense to say that all planets need infrastructure, and change the current infrastructure calculation to:
[millions of pop supported] = [tech modifier] * [planet "maximum" population] * log2(1 + [infrastructure] / ([colony cost] * [planet "maximum" population])) / 2ln(2)
with colony cost calculated as:
[colony cost] = abs([actual temperature - species optimal temperature]) / [temperature tolerance] + max(0; [pressure] / [species max pressure] - 1) + [lack of breathable atmosphere penalty] + [toxic atmosphere penalty] + [lack of liquid water penalty] + [minimum colony cost]

In the small population limit (infrastructure / (colony cost * max pop) << 1), this would behave like the current model (essentially planet size would cancel out, because the planet would be approximately infinitely large), but supporting about 5 % more population for the same infra. But as you approach the current planetary maximum population you would need increasingly more infrastructure, until, at the current max population, the marginal gain from additional infrastructure would be only half the initial value.
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on August 05, 2019, 09:54:17 PM
Here's a suggestion: Expand the scope of the civilian sector. Give civilians the ability to independently create colonies like they do civilian mines, and add more civilian ship types, including private jump ships and exploration ships. I think it'd be fun to have the chance that a civilian survey ship violates a neutral race's borders, leading to a confrontation, or that civilian settlers found "New Jonestown" in an inconvenient system. Right now diplomacy seems to be completely deterministic: if you can generate diplomacy points faster than a race's xenophobia lowers them, you will inevitably become allies, otherwise, war is unavoidable.

Also, since C# Aurora is better able to handle large numbers of ships, I'd make civilian transports required to move generated race wealth from colonies to the capital. This would add a lot of depth, since you'd now be able to wage guerre de course against an enemy, paralyzing their economy by destroying merchant ships. It would solve the "doomstack" complaint by giving independent cruisers something to do in the form of commerce raiding and trade protection.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 05, 2019, 11:03:21 PM
This is distinctly for the future, but to build on that it would be kindof cool if you could elect to block civilian colonization by default.  They could then pressure you somehow for authorization to colonize, giving you an incentive to go find some place for them to grow into.

Perhaps they could simply lobby the government in various ways, meaning they will gradually (over the course of a decade or so) proceed towards colonizing somewhere of their own (probably idiotic) choosing.  This might result in nothing bad happening, or it might result in them selecting a planet that is very dangerous (perhaps claimed by aliens, though they probably shouldn't pick somewhere actually defended by said aliens).  Assuming they announce the planned target at the beginning of their lobbying, it could occasionally create ticking time bomb situations that you need to resolve (by providing some not-at-full-capacity colonizaiton target at 2.0 cost or less).

All the numbers there are totally made up and I don't consider them to be particularly good for anything other than providing a general idea of what I mean.
Title: Re: C# Aurora v0.x Suggestions
Post by: totos_totidis on August 06, 2019, 02:55:52 AM
This is distinctly for the future, but to build on that it would be kindof cool if you could elect to block civilian colonization by default.  They could then pressure you somehow for authorization to colonize, giving you an incentive to go find some place for them to grow into.

Perhaps they could simply lobby the government in various ways, meaning they will gradually (over the course of a decade or so) proceed towards colonizing somewhere of their own (probably idiotic) choosing.  This might result in nothing bad happening, or it might result in them selecting a planet that is very dangerous (perhaps claimed by aliens, though they probably shouldn't pick somewhere actually defended by said aliens).  Assuming they announce the planned target at the beginning of their lobbying, it could occasionally create ticking time bomb situations that you need to resolve (by providing some not-at-full-capacity colonizaiton target at 2.0 cost or less).

All the numbers there are totally made up and I don't consider them to be particularly good for anything other than providing a general idea of what I mean.

or i could just click the abandon colony button or nuke the colony.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on August 06, 2019, 04:32:50 PM
Please take a look at how PD engages missile salvos. As it is right now you need too many fire-controls for small missiles salvos because if one PD turret linked to a fire-control leave even one missile the next turret will be used on that one instead of shooting on a new salvo where they would score allot more missile kills.

This should be looked at from a game balance perspective in my opinion, beam PD fire-controls already are way more expensive than missile fire-controls in general.

I would suggest that PD is put on a list where the biggest is on the top (or rather the one that have the most likely higher kills). Each control then target the largest salvo in that increment that hit also sorted into some list where the largest salvo always get put on top.

Currently you need almost somewhat like 25-50% more fire-controls even against relatively small salvos such as fighters unless there is a very high chance one turret can destroy all incoming missiles in one go. You could of course put more turrets on each fire control but turrets are pretty big. There also are problems with mixing ships with smaller turrets and larger ones, if you are unlucky the smaller turret fire first and simply waste its ammunition since the larger could have killed the salvo.

A good example of the problem is... lets say you have 10 salvos of incoming missiles of 6 missiles in each salvo. You have a quad Gauss turret to engage them and you are quite likely to kill all missiles on one turret and you have ten turrets and PD fire-controls. Lets say out of the ten salvos you would theoretically miss one or two missiles. In practice this means that you get six to twelve missiles to leak and not one or two. In this instance I rather have triple turrets and a few more fire-controls but that also is way more expensive... and very taxing on certain resources. Also given the change to maintenance then size of the ships matter allot more than before so just adding more turrets to each fire control to reduce the chance of missing a missile is weaker than before.

I think a change to this would make the weird salvo mechanic less abusable and small salvo attacks such as fighters less problematic unless you intend to destroy entire salvos with AMM.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on August 09, 2019, 11:46:10 AM
Could we possibly edit the rules for the detection of targets smaller than the designed active sensor resolution? Right now, it scales to the square of ship resolution divided by sensor resolution, while active sensor resolution only scales with the cube root of sensor resolution. This disproportionately favours smaller resolutions to avoid ships sneaking in, and it especially becomes a problem with small, sub kiloton craft. It's already hard enough to detect them without excessively large sensors and fire controls, but the present system is such that simply reducing the size of your craft by 50-100t, which is easily done for fighters, results in the enemy having to perform a very expensive overhaul of their ships to edit resolution and avoid becoming obsolete.

May I suggest something along the lines of :
Active Sensor Range = Max Range * SQRT(Ship HS/Resolution HS)
Title: Re: C# Aurora v0.x Suggestions
Post by: Doren on August 10, 2019, 05:04:09 AM
Could it be possible to make it so that double clicking on a jump point would switch the system view to the system that jump point leads to?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on August 10, 2019, 06:08:42 AM
Could we possibly edit the rules for the detection of targets smaller than the designed active sensor resolution? Right now, it scales to the square of ship resolution divided by sensor resolution, while active sensor resolution only scales with the cube root of sensor resolution. This disproportionately favours smaller resolutions to avoid ships sneaking in, and it especially becomes a problem with small, sub kiloton craft. It's already hard enough to detect them without excessively large sensors and fire controls, but the present system is such that simply reducing the size of your craft by 50-100t, which is easily done for fighters, results in the enemy having to perform a very expensive overhaul of their ships to edit resolution and avoid becoming obsolete.

May I suggest something along the lines of :
Active Sensor Range = Max Range * SQRT(Ship HS/Resolution HS)

These are the new sensor rules for C#. Detecting small ships is already easier than in VB6.

http://aurora2.pentarch.org/index.php?topic=8495.msg102701#msg102701
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on August 10, 2019, 06:56:37 AM
Could we possibly edit the rules for the detection of targets smaller than the designed active sensor resolution? Right now, it scales to the square of ship resolution divided by sensor resolution, while active sensor resolution only scales with the cube root of sensor resolution. This disproportionately favours smaller resolutions to avoid ships sneaking in, and it especially becomes a problem with small, sub kiloton craft. It's already hard enough to detect them without excessively large sensors and fire controls, but the present system is such that simply reducing the size of your craft by 50-100t, which is easily done for fighters, results in the enemy having to perform a very expensive overhaul of their ships to edit resolution and avoid becoming obsolete.

May I suggest something along the lines of :
Active Sensor Range = Max Range * SQRT(Ship HS/Resolution HS)

http://aurora2.pentarch.org/index.php?topic=8495.msg102701#msg102701

To be honest I don't think that was the point. The point was that because of the new change it most often is better to use a bigger smaller res sensor than having two sensors one small res and one big res. For example there is no point in having say one 300t 5 res and one 300t 20 res when one 600t res 5 have pretty much the same range as a 300t 20 res sensor. The difference get worse the higher the resolution you have on the sensors.

If the lower end of a high res scaled differently then large res sensors would make more sense to use in general from a research point of view.

These are the new sensor rules for C#. Detecting small ships is already easier than in VB6.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on August 10, 2019, 08:03:58 AM
To be honest I don't think that was the point. The point was that because of the new change it most often is better to use a bigger smaller res sensor than having two sensors one small res and one big res. For example there is no point in having say one 300t 5 res and one 300t 20 res when one 600t res 5 have pretty much the same range as a 300t 20 res sensor. The difference get worse the higher the resolution you have on the sensors.

If the lower end of a high res scaled differently then large res sensors would make more sense to use in general from a research point of view.

Yes, I understand now. I've run the numbers for the suggestion but it massively increases sensor range vs smaller ships to the point where small resolution sensors wouldn't be needed. For example, using active sensor 21 and EM 11, the range of a 50 ton resolution sensor is 40m (23m VB6). It can detect FACs at 1.6m (900k VB6) and 250 ton fighters at 100k (57K VB6). A dedicated resolution-20 sensor would detect the FAC at 23m and a dedicated fighter sensor would detect the fighter at 14m

With the proposed change for a resolution-100 sensor the FAC would be detected at 18m and the fighters at 9m so you wouldn't need the dedicated sensors.

It is definitely true that you gain less of a range advantage on C# with higher resolution sensors, but on the other hand gaining an extra twenty or thirty percent of range (for example) can be important, especially with reduced missile ranges. You also gain far less range now by researching extra sensor tech. Sensor ranges are much more compressed so small gains are worth relatively more.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on August 10, 2019, 08:47:17 AM
Could it be possible to make it so that double clicking on a jump point would switch the system view to the system that jump point leads to?

Double-clicking would be tricky as the first click centres the system on the object you click :)

However, I think I have come up with something better. When you right-click on the tactical map, any fleets, populations or jump points within a few pixels of where you click will appear in a list. If you select a population, the Economics window will load with the population selected. If you select a fleet, the Naval Organization window will load with the fleet selected. If you select the jump point, which appears as the name of any destination system, the tactical map will change to that system.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on August 10, 2019, 09:08:33 AM
To be honest I don't think that was the point. The point was that because of the new change it most often is better to use a bigger smaller res sensor than having two sensors one small res and one big res. For example there is no point in having say one 300t 5 res and one 300t 20 res when one 600t res 5 have pretty much the same range as a 300t 20 res sensor. The difference get worse the higher the resolution you have on the sensors.

If the lower end of a high res scaled differently then large res sensors would make more sense to use in general from a research point of view.

Yes, I understand now. I've run the numbers for the suggestion but it massively increases sensor range vs smaller ships to the point where small resolution sensors wouldn't be needed. For example, using active sensor 21 and EM 11, the range of a 50 ton resolution sensor is 40m (23m VB6). It can detect FACs at 1.6m (900k VB6) and 250 ton fighters at 100k (57K VB6). A dedicated resolution-20 sensor would detect the FAC at 23m and a dedicated fighter sensor would detect the fighter at 14m

With the proposed change for a resolution-100 sensor the FAC would be detected at 18m and the fighters at 9m so you wouldn't need the dedicated sensors.

It is definitely true that you gain less of a range advantage on C# with higher resolution sensors, but on the other hand gaining an extra twenty or thirty percent of range (for example) can be important, especially with reduced missile ranges. You also gain far less range now by researching extra sensor tech. Sensor ranges are much more compressed so small gains are worth relatively more.

Yes... I agree with that assessment as well. Especially important is that you gain less range advantage with sensors as technology goes up now which I think will balance the game allot better. I think more technology should work like that so you need to invest more research for less advantages over time. It would remove some of the snowballing effects in general.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on August 10, 2019, 02:56:05 PM
Could it be possible to make it so that double clicking on a jump point would switch the system view to the system that jump point leads to?

Double-clicking would be tricky as the first click centres the system on the object you click :)

However, I think I have come up with something better. When you right-click on the tactical map, any fleets, populations or jump points within a few pixels of where you click will appear in a list. If you select a population, the Economics window will load with the population selected. If you select a fleet, the Naval Organization window will load with the fleet selected. If you select the jump point, which appears as the name of any destination system, the tactical map will change to that system.
There are some things I'd like to suggest since we are on the subject.

Clicking on hidden objects shouldn't select them or prevent clicking on visible objects.
Hidden objects shouldn't be listed in the context menu unless they are only hidden due to overlap.
Shift clicking to start a distance measurement shouldn't center the map, though starting the distance line from the center of a selected object would often be helpful.
A button on the Production window to center the tactical map on the current colony.
Allow dragging the tactical map to scroll it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on August 10, 2019, 03:31:44 PM
There are some things I'd like to suggest since we are on the subject.

Clicking on hidden objects shouldn't select them or prevent clicking on visible objects.
Hidden objects shouldn't be listed in the context menu unless they are only hidden due to overlap.

It is your own fleets and populations so they won't be hidden. The jump point only gets added to the list if you have already explored it (no point otherwise)

Quote
Allow dragging the tactical map to scroll it.

You can already click-drag the tactical and galactic maps.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on August 11, 2019, 08:12:39 AM
Yes, I understand now. I've run the numbers for the suggestion but it massively increases sensor range vs smaller ships to the point where small resolution sensors wouldn't be needed. For example, using active sensor 21 and EM 11, the range of a 50 ton resolution sensor is 40m (23m VB6). It can detect FACs at 1.6m (900k VB6) and 250 ton fighters at 100k (57K VB6). A dedicated resolution-20 sensor would detect the FAC at 23m and a dedicated fighter sensor would detect the fighter at 14m

With the proposed change for a resolution-100 sensor the FAC would be detected at 18m and the fighters at 9m so you wouldn't need the dedicated sensors.

It is definitely true that you gain less of a range advantage on C# with higher resolution sensors, but on the other hand gaining an extra twenty or thirty percent of range (for example) can be important, especially with reduced missile ranges. You also gain far less range now by researching extra sensor tech. Sensor ranges are much more compressed so small gains are worth relatively more.

Those numbers were tentative. I did some calculations and I've arrived at a revised formula:
AS Range = Max Range * ((Ship HS/Sensor Resolution)^(2/3))

Let me demonstrate with a test case : we have 400t of space available for active sensors (ASS 21, EMS 11) and we need to detect enemy fighters (4 HS) and FACs (16 HS). The mass budget can be spent on a single sensor or on multiple sensors.

If we opt for a single 400t Res 4 sensor, we will detect both the fighter and the FAC at 38.50 mn km. If we opt for a single 400t Res 16 sensor, we will detect the FAC at 61.12 mn km (+58.7%) and the fighter at 24.25 mn km (-37.0%), at the cost of a 4x increase in EM signature. If we opt for a 200t Res 4 sensor and a 200t Res 16 sensor, we will detect the fighter at 27.22 mn km (-29.3%) and the FAC at 43.21 mn km (+12.2%).

All of these options are equally expensive with respect to research, maintenance, materials, and volume. The first two options offer superior performance against one threat, while the last provides reasonable performance against both, and also allows us to have separate ships for anti-fighter and anti-FAC work. Each of them is a viable choice, and which one is selected will depend heavily on tactics and enemy composition.

The scaling curve is also steep enough that a Res 80 sensor used for anti-ship work might be useful at point-blank range range against FACs, but will still be useless against fighters. It might make detecting missiles a bit easier though, so if it's implemented there's probably no need to hard-cap detection size to 0.33 HS.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on August 12, 2019, 05:30:04 PM
If we go down that route, it would make more sense to say that all planets need infrastructure
I don't really agree.  As things are right now, infrastructure is used to allow population on worlds with bad temps, atmospheres, and with research, low gravity.  All of these are about sustaining populations in inhospitable/otherwise unlivable circumstances.  I don't think extending that to deal with overpopulation is moving that far out of where it conceptually is right now.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on August 12, 2019, 05:50:15 PM
Without some kind of infrastructure, Earth could support maybe ten million people. You might not need pressurized domes or CO2 scrubbers, but that doesn't mean an Earth city doesn't need infrastructure. The advantage of requiring all planets to use infrastructure is that it provides a more organic and less artificial transition between colony cost 0 planets that are above and below their pop cap.
Title: Re: C# Aurora v0.x Suggestions
Post by: the obelisk on August 12, 2019, 06:11:36 PM
Without some kind of infrastructure, Earth could support maybe ten million people. You might not need pressurized domes or CO2 scrubbers, but that doesn't mean an Earth city doesn't need infrastructure.
My point is that what infrastructure currently represents is clearly more specific.  Also, all planets, regardless of conditions, having an evergrowing need for infastructure the moment you begin colonizing doesn't sound fun.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 12, 2019, 08:44:45 PM
Personally I think it makes sense that you would need to furnish infrastructure, however if I remember right 'Infrastructure' in the aurora sense is specifically TN material based stuff, which doesn't necessarily make sense for planets that are hospitable to humans already.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on August 13, 2019, 05:14:03 AM
The idea of all planets needing SOME infrastructure actually does sound like fun. Especially since pretty much all planets naturally produce infrastructure. As QuakeIV said, it will just soften that transition between colony cost 0 that needs 0 infrastructure for a population of 10 billion and colony cost 0.0001 (perhaps due to dust) that suddenly needs 1k infrastructure for that same amount.

Still, there will have to be some lower softcap and an upper softcap. A garden world with perfect conditions and 100k colonists doesn't need infrastructure. People can live in tents and pick the food from the trees around them. But if you try to cram 100 million colonists on that same planet, that becomes a slightly more tricky proposition and it makes sense that at least SOME TN tech will be necessary, if not crucially so for survival, at least for obtaining maximum efficiency.

Basically, initial colonization shouldn't need infrastructure but if you actually develop a colony it should.

Edit:
I spent some time and developed a proposal for the actual infrastructure needed formula. Currently, the formula is Pop (millions) x Colony Cost x 100. This could be seen as "100% of infrastructure needs are determined by colony cost". If instead we change that to "80% of infrastructure needs are determined by colony cost and 20% by maximum population" we can derive the following formula:

Infrastructure needed = Current population x Colony Cost x 80 + Current population x (Current population over lower cap / Max population over lower cap) x 20.

If your population is a very small percentage of the maximum capacity of the planet, the second term is going to be very close to zero. If your population is exactly equal to the capacity, 20% of your population is assumed to be living on colony cost 1 under the old system. If you have double your max population on a planet, each million population needs 40 infrastructure BEFORE considering the effects of colony costs.

Effectively, this results in the impact of colony cost becoming almost negligable at really high population densities. If you have 100x the capacity of the planet, each million population requires 80 x colony cost + 2000 infrastructure. The amount is absolutely silly high, but for really small bodies it is relevant as you might consider dumping 50k infrastructure on an asteroid to get to 30mil population to run your forward fleet base. This would represent building out and hollowing out the asteroid until there is very little of the original rock left.

If there is further interest in this, I suggest we split it out into its own seperate discussion.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on August 13, 2019, 09:08:34 AM
We're maintaining some 7 billion people and counting on Earth without TN based infrastructure right now.

I agree that the mechanics are in some ways rather odd, Mars should for example be quite capable of supporting human habitation without TN infrastructure or terraforming, although it would need to account for the harsh environmental conditions. But keep in mind that TN infrastructure isn't needed in a surprisingly wide range of cases. As long as gravity is tolerable? TN materials are not needed. As long as the atmospheric content is tolerable? TN materials not needed. As long as the temperature is tolerable? TN materials not needed.

And that offers a fairly large range of options in which standard physics based infrastructure is enough to supply all needed support, even if that includes things like vast, centrally heated cities to cope with the long and cold winters of a -5 degrees Celsius average temperature planet, the terrible, baking heat of a planet with an average 30 degrees Celsius temperature, or the vast storms of an archipelago planet fueled by the tremendous expanse of an uninterrupted world spanning ocean.
Title: Re: C# Aurora v0.x Suggestions
Post by: space dwarf on August 13, 2019, 03:13:28 PM
We're maintaining some 7 billion people and counting on Earth without TN based infrastructure right now.

I agree that the mechanics are in some ways rather odd, Mars should for example be quite capable of supporting human habitation without TN infrastructure or terraforming, although it would need to account for the harsh environmental conditions. But keep in mind that TN infrastructure isn't needed in a surprisingly wide range of cases. As long as gravity is tolerable? TN materials are not needed. As long as the atmospheric content is tolerable? TN materials not needed. As long as the temperature is tolerable? TN materials not needed.

And that offers a fairly large range of options in which standard physics based infrastructure is enough to supply all needed support, even if that includes things like vast, centrally heated cities to cope with the long and cold winters of a -5 degrees Celsius average temperature planet, the terrible, baking heat of a planet with an average 30 degrees Celsius temperature, or the vast storms of an archipelago planet fueled by the tremendous expanse of an uninterrupted world spanning ocean.

Of course, after a point you have the issue that if TN materials can do these things better and easier, people will want those used instead, in the same way that we don't fly via old-style wooden propeller airliners now even though the aircraft themselves were cheaper and used fewer rare resources than modern airliners.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on August 14, 2019, 04:33:17 AM
Of course, after a point you have the issue that if TN materials can do these things better and easier, people will want those used instead, in the same way that we don't fly via old-style wooden propeller airliners now even though the aircraft themselves were cheaper and used fewer rare resources than modern airliners.

And yet, for thousands of years people did not use construction materials beyond stone, wood and mud.

We don't use old style wooden propeller airliners because of a number of factors, including improved engines, improved materials and lower costs for both materials and engines in the capabilities that are required for airliners. We use all metal jet aircraft as our main air transportation because we can afford to use all metal jet aircraft.

If TN materials remain 'extremely expensive strategic materials' you will not see them proliferate outside certain areas where they really are so much more efficient they are cheaper than just accepting standard materials and their costs.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on August 14, 2019, 01:45:00 PM
There are some things I'd like to suggest since we are on the subject.

Clicking on hidden objects shouldn't select them or prevent clicking on visible objects.
Hidden objects shouldn't be listed in the context menu unless they are only hidden due to overlap.

It is your own fleets and populations so they won't be hidden. The jump point only gets added to the list if you have already explored it (no point otherwise)
I guess I wasn't clear what I meant.  Sorry.

If you turn off Asteroids in the Display tab then they aren't displayed but clicking on one still selects it.  This can prevent you from interacting with objects that are visible if the hidden object is in front of the visible one.

There are times when it is helpful to hide your own fleets and colonies, in which case they shouldn't be clickable.
Quote
Quote
Allow dragging the tactical map to scroll it.

You can already click-drag the tactical and galactic maps.
I must have forgotten that change then.  There are so many improvements in C# it can be tricky to keep track of them all.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 14, 2019, 01:51:43 PM
I wouldn't personally be against being able to fabricate non-TN infrastructure.  It wouldn't be crazy to say that you can make stuff that is considerably heavier but does the same job without said TN resources.  That could then also the same stuff that civilian populations currently slowly produce under their own power.

So you would still be fairly encouraged to use TN stuff if you are delivering the infrastructure over interstellar distances (unless you have a lot of shipping capacity available), but its technically an option if you need it, and for in-situ production it might make a fair bit of sense.  Drop some factories on a planet that then proceed to mass produce conventional infrastructure over time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on August 14, 2019, 02:21:28 PM
IMO the non-TN infrastructure is already accounted for in the racial tolerances as well as partially by Colony Cost calculations involving how much of the population is dedicated to agriculture and life support.
Title: Re: C# Aurora v0.x Suggestions
Post by: totos_totidis on August 16, 2019, 04:23:35 AM
In c# aurora ground surveys will be conducted not by teams as in vb but by ground forces. I would like to suggest that ground survey be something that can be automated.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on August 16, 2019, 05:24:31 AM
In c# aurora ground surveys will be conducted not by teams as in vb but by ground forces. I would like to suggest that ground survey be something that can be automated.

There are far fewer surveys now. Many systems don't even have one ground survey site and the most I have seen so far is three.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on August 17, 2019, 05:54:24 AM
Please take a look at how PD engages missile salvos. As it is right now you need too many fire-controls for small missiles salvos because if one PD turret linked to a fire-control leave even one missile the next turret will be used on that one instead of shooting on a new salvo where they would score allot more missile kills.

This should be looked at from a game balance perspective in my opinion, beam PD fire-controls already are way more expensive than missile fire-controls in general.

I would suggest that PD is put on a list where the biggest is on the top (or rather the one that have the most likely higher kills). Each control then target the largest salvo in that increment that hit also sorted into some list where the largest salvo always get put on top.

Currently you need almost somewhat like 25-50% more fire-controls even against relatively small salvos such as fighters unless there is a very high chance one turret can destroy all incoming missiles in one go. You could of course put more turrets on each fire control but turrets are pretty big. There also are problems with mixing ships with smaller turrets and larger ones, if you are unlucky the smaller turret fire first and simply waste its ammunition since the larger could have killed the salvo.

A good example of the problem is... lets say you have 10 salvos of incoming missiles of 6 missiles in each salvo. You have a quad Gauss turret to engage them and you are quite likely to kill all missiles on one turret and you have ten turrets and PD fire-controls. Lets say out of the ten salvos you would theoretically miss one or two missiles. In practice this means that you get six to twelve missiles to leak and not one or two. In this instance I rather have triple turrets and a few more fire-controls but that also is way more expensive... and very taxing on certain resources. Also given the change to maintenance then size of the ships matter allot more than before so just adding more turrets to each fire control to reduce the chance of missing a missile is weaker than before.

I think a change to this would make the weird salvo mechanic less abusable and small salvo attacks such as fighters less problematic unless you intend to destroy entire salvos with AMM.

I've been giving this some thought. I think I do need to improve the situation vs small salvos. However, the way the sequence of play works is a problem for the above solution. Each salvo moves one at once, rather than all together. As a salvo attacks its target, the local point defence will shoot at it, without consideration for what other salvos may arrive later in the turn. This late in development, I don't want to mess around with the sequence of play as that would be a huge task.

What might work though is to simply lift the restriction on each fire control only engaging a single target during point blank fire. Each weapon would still be only able to engage a single salvo. So you could have the same number of fire controls and have two twin turrets per fire control in the above situation, with each turret allowed to shoot a different salvo. You would still tend to have multiple fire controls anyway for redundancy, but fewer than are required now.

EDIT: I've implemented the above. Only needed to move a couple of lines of code. Also, missiles moved in descending order of speed. I've updated that to descending order of speed then by descending order of salvo size, so the largest salvos of the same type of missile will move first.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on August 17, 2019, 06:57:27 AM
Please take a look at how PD engages missile salvos. As it is right now you need too many fire-controls for small missiles salvos because if one PD turret linked to a fire-control leave even one missile the next turret will be used on that one instead of shooting on a new salvo where they would score allot more missile kills.

This should be looked at from a game balance perspective in my opinion, beam PD fire-controls already are way more expensive than missile fire-controls in general.

I would suggest that PD is put on a list where the biggest is on the top (or rather the one that have the most likely higher kills). Each control then target the largest salvo in that increment that hit also sorted into some list where the largest salvo always get put on top.

Currently you need almost somewhat like 25-50% more fire-controls even against relatively small salvos such as fighters unless there is a very high chance one turret can destroy all incoming missiles in one go. You could of course put more turrets on each fire control but turrets are pretty big. There also are problems with mixing ships with smaller turrets and larger ones, if you are unlucky the smaller turret fire first and simply waste its ammunition since the larger could have killed the salvo.

A good example of the problem is... lets say you have 10 salvos of incoming missiles of 6 missiles in each salvo. You have a quad Gauss turret to engage them and you are quite likely to kill all missiles on one turret and you have ten turrets and PD fire-controls. Lets say out of the ten salvos you would theoretically miss one or two missiles. In practice this means that you get six to twelve missiles to leak and not one or two. In this instance I rather have triple turrets and a few more fire-controls but that also is way more expensive... and very taxing on certain resources. Also given the change to maintenance then size of the ships matter allot more than before so just adding more turrets to each fire control to reduce the chance of missing a missile is weaker than before.

I think a change to this would make the weird salvo mechanic less abusable and small salvo attacks such as fighters less problematic unless you intend to destroy entire salvos with AMM.

I've been giving this some thought. I think I do need to improve the situation vs small salvos. However, the way the sequence of play works is a problem for the above solution. Each salvo moves one at once, rather than all together. As a salvo attacks its target, the local point defence will shoot at it, without consideration for what other salvos may arrive later in the turn. This late in development, I don't want to mess around with the sequence of play as that would be a huge task.

What might work though is to simply lift the restriction on each fire control only engaging a single target during point blank fire. Each weapon would still be only able to engage a single salvo. So you could have the same number of fire controls and have two twin turrets per fire control in the above situation, with each turret allowed to shoot a different salvo. You would still tend to have multiple fire controls anyway for redundancy, but fewer than are required now.

EDIT: I've implemented the above. Only needed to move a couple of lines of code. Also, missiles moved in descending order of speed. I've updated that to descending order of speed then by descending order of salvo size, so the largest salvos of the same type of missile will move first.

This is a really good improvement in general. Having the largest salvos move first and fire-controls to to engage multiple salvos means that you can engage both large and small salvos with a decent investment in fire-controls more in line with missile fire-control costs.

Later on if you have time and feel it is worth the investment you could look into the whole salvo mechanic and how it works. Perhaps tie fire-controls to controlling missiles and targets and having technology that improve on that which would make it a bit more "realistic".

But all in all I think this is a very good improvement.
Title: Re: C# Aurora v0.x Suggestions
Post by: Shuul on August 17, 2019, 03:09:01 PM
Please take a look at how PD engages missile salvos. As it is right now you need too many fire-controls for small missiles salvos because if one PD turret linked to a fire-control leave even one missile the next turret will be used on that one instead of shooting on a new salvo where they would score allot more missile kills.

This should be looked at from a game balance perspective in my opinion, beam PD fire-controls already are way more expensive than missile fire-controls in general.

I would suggest that PD is put on a list where the biggest is on the top (or rather the one that have the most likely higher kills). Each control then target the largest salvo in that increment that hit also sorted into some list where the largest salvo always get put on top.

Currently you need almost somewhat like 25-50% more fire-controls even against relatively small salvos such as fighters unless there is a very high chance one turret can destroy all incoming missiles in one go. You could of course put more turrets on each fire control but turrets are pretty big. There also are problems with mixing ships with smaller turrets and larger ones, if you are unlucky the smaller turret fire first and simply waste its ammunition since the larger could have killed the salvo.

A good example of the problem is... lets say you have 10 salvos of incoming missiles of 6 missiles in each salvo. You have a quad Gauss turret to engage them and you are quite likely to kill all missiles on one turret and you have ten turrets and PD fire-controls. Lets say out of the ten salvos you would theoretically miss one or two missiles. In practice this means that you get six to twelve missiles to leak and not one or two. In this instance I rather have triple turrets and a few more fire-controls but that also is way more expensive... and very taxing on certain resources. Also given the change to maintenance then size of the ships matter allot more than before so just adding more turrets to each fire control to reduce the chance of missing a missile is weaker than before.

I think a change to this would make the weird salvo mechanic less abusable and small salvo attacks such as fighters less problematic unless you intend to destroy entire salvos with AMM.

I've been giving this some thought. I think I do need to improve the situation vs small salvos. However, the way the sequence of play works is a problem for the above solution. Each salvo moves one at once, rather than all together. As a salvo attacks its target, the local point defence will shoot at it, without consideration for what other salvos may arrive later in the turn. This late in development, I don't want to mess around with the sequence of play as that would be a huge task.

What might work though is to simply lift the restriction on each fire control only engaging a single target during point blank fire. Each weapon would still be only able to engage a single salvo. So you could have the same number of fire controls and have two twin turrets per fire control in the above situation, with each turret allowed to shoot a different salvo. You would still tend to have multiple fire controls anyway for redundancy, but fewer than are required now.

EDIT: I've implemented the above. Only needed to move a couple of lines of code. Also, missiles moved in descending order of speed. I've updated that to descending order of speed then by descending order of salvo size, so the largest salvos of the same type of missile will move first.

Will this somehow change efficiency of CIWS? I mostly rely on them for missile defense.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on August 17, 2019, 08:50:21 PM
Will this somehow change efficiency of CIWS? I mostly rely on them for missile defense.

It was some time since I played, but doesn't CIWS already come with it's own built in Fire control in each turret?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on August 18, 2019, 04:50:09 AM
Will this somehow change efficiency of CIWS? I mostly rely on them for missile defense.

CIWS is a single weapon with an integral fire control so it will still only be able to handle a single salvo. If you have two CIWS, they can both fire at the same salvo or at two different salvos.
Title: Re: C# Aurora v0.x Suggestions
Post by: totos_totidis on August 19, 2019, 01:35:53 PM
I would like to suggest more advanced ruin only weapons. I recommend adding advanced gauss cannons with double the fire rate and advanced particle lances with higher damage.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on August 23, 2019, 01:39:28 AM
IMO, component design should be more like turret design, where you enter desired performance (desired sensor range, engine power, etc.) and let Aurora crunch the numbers using techs that you have access to and return appropriate values for the other parameters (sensor size, engine boost, etc.).

Failing that, could we please at least get more increments for BFC tracking speed and range? Even just 0.75x, 1.25x, 2.50x and 3.50x would be appreciated. I'd also like to suggest that the multiplier be gated behind tech, like max and minimum engine boost.

Could we also get a small, 2HS 100 colonist transport module for conventional starts with multiple pre-TN colonies? It'll be useful to RP pre-TN colonisation with conventional starships like BFR.
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on August 23, 2019, 01:50:28 AM
I would like to suggest the ability to refit fighters and i'm not if this was mentioned if its possible in the new version to use maintenance facilities to maintain fighters.

I tend to build a group of low fuel consumption / long range patrol fighters on nearly every colony and just being able to organically upgrade them or just even maintain them without building a space station just for that would be awesome.
Title: Re: C# Aurora v0.x Suggestions
Post by: mtm84 on August 23, 2019, 02:24:40 AM
I don’t think he will allow upgrading of fighters but in C# they can use normal maintenance facilities, and the new fleet organization should make it easy to swap out new fighters for old ones.

Edit: well looks like you can refit fighters, which he may have mentioned and I forgot about.  I blame it being late.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on August 23, 2019, 02:42:27 AM
I would like to suggest the ability to refit fighters and i'm not if this was mentioned if its possible in the new version to use maintenance facilities to maintain fighters.

I tend to build a group of low fuel consumption / long range patrol fighters on nearly every colony and just being able to organically upgrade them or just even maintain them without building a space station just for that would be awesome.

Apart from being able to build them in fighter factories (which is covered by the technobabble on ships near gravity fields), fighters are treated like any other ship. You can build and refit them in shipyards and they are maintained by maintenance facilities.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on August 23, 2019, 02:43:53 AM
I would like to suggest more advanced ruin only weapons. I recommend adding advanced gauss cannons with double the fire rate and advanced particle lances with higher damage.

I think double fire gauss would be a little overpowered :)

Maybe something on the lines of advanced railguns, with an extra shot. Having said that, I haven't really looked at ruin-only weapons yet for C. I'll revisit the weapon concepts when I do.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on August 23, 2019, 04:00:14 AM
I think double fire gauss would be a little overpowered :)

Maybe something on the lines of advanced railguns, with an extra shot. Having said that, I haven't really looked at ruin-only weapons yet for C. I'll revisit the weapon concepts when I do.

It might be pretty cool if you were able to specify in game setup which weapon/shields and special tech-lines you want to be available freely, ruin only ( and at what chance ) or not available at all. I would for sure up the chance a bit to discover some ruin-only techs since in my experience you had to explore alot of ruins to get anything at all ( or I was just unlucky ).

Although being able to disable some techs that's normally freely available might cause some issues for the AI unless it's a player empire only setting.
Title: Re: C# Aurora v0.x Suggestions
Post by: mtm84 on August 23, 2019, 04:25:30 AM

It might be pretty cool if you were able to specify in game setup which weapon/shields and special tech-lines you want to be available freely, ruin only ( and at what chance ) or not available at all. I would for sure up the chance a bit to discover some ruin-only techs since in my experience you had to explore alot of ruins to get anything at all ( or I was just unlucky ).

Although being able to disable some techs that's normally freely available might cause some issues for the AI unless it's a player empire only setting.

If I remember right, Master of Orion 3 had a system where by each race would only see 75-80 percent of the tech tree in any one game, chosen randomly.  I'm not quite sure how you would adapt that to Aurora's tech system but its food for thought.  I'm all for having increased game/SM options (SM ability to seed special techs in ruins, anyone?)
Title: Re: C# Aurora v0.x Suggestions
Post by: Doren on August 23, 2019, 10:35:13 AM
I think double fire gauss would be a little overpowered :)

Maybe something on the lines of advanced railguns, with an extra shot. Having said that, I haven't really looked at ruin-only weapons yet for C. I'll revisit the weapon concepts when I do.
I honestly think that you should not get directly stronger stuff from ruins just alternatives for example meson weapon type could be rather interesting to get out of ruins (well not that interesting that we are accustomed to be able to use them from the get go) as it is rather unique among the weapon types

It might be pretty cool if you were able to specify in game setup which weapon/shields and special tech-lines you want to be available freely, ruin only ( and at what chance ) or not available at all. I would for sure up the chance a bit to discover some ruin-only techs since in my experience you had to explore alot of ruins to get anything at all ( or I was just unlucky ).

Although being able to disable some techs that's normally freely available might cause some issues for the AI unless it's a player empire only setting.
Possibly though right now there's not too many possibilities in tech other than couple weapon techs that could be interesting to get from the ruins while not hindering the normal gameplay. Unless of course, you were running campaing which is heavy tech restricted on purpose
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on August 23, 2019, 06:56:04 PM
I'm not personally a huge fan of ruins providing tech that couldn't be developed by some other means.  I do kindof like the idea of them potentially providing a really huge boost to some particular technology though, personally.  Maybe work on some ruins for a decade or so and jump five or six levels of railgun tech.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on August 24, 2019, 05:22:21 PM
If I remember right, Master of Orion 3 had a system where by each race would only see 75-80 percent of the tech tree in any one game, chosen randomly.  I'm not quite sure how you would adapt that to Aurora's tech system but its food for thought.  I'm all for having increased game/SM options (SM ability to seed special techs in ruins, anyone?)

I'm not personally a huge fan of ruins providing tech that couldn't be developed by some other means.  I do kindof like the idea of them potentially providing a really huge boost to some particular technology though, personally.  Maybe work on some ruins for a decade or so and jump five or six levels of railgun tech.

If you wanted racial differences you could combine these two, and have a startup option so that each race would start with one "advanced" tech (advanced lasers, compressed fuel, etc) at random, but they couldn't be researched normally. Then you could obtain new advanced techs by blowing up enemy ships with them and salvaging them :P

Maybe something on the lines of advanced railguns, with an extra shot. Having said that, I haven't really looked at ruin-only weapons yet for C. I'll revisit the weapon concepts when I do.

One more shot for gauss would scale differently as you increased the fire rate. I'd suggest giving them a slightly smaller base size.

Other ideas, since this came up in Discord awhile back:
Advanced Particle Beams: Slightly lower power requirement, same damage.
Magnetic Launch Rails: Larger, slower firing missile launchers that give missiles a bonus to velocity (that possibly falls back to the base value over time, if that wouldn't be too tricky to program)
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on August 26, 2019, 11:25:39 AM
Since maximum planetary population is now a thing, why not have the effects of radiation scale with how full the planet is? Realistically, high-intensity radiation will likely remain largely localised, and even on a planet that's undergone significant bombardment, there is still likely to be a significant part of the surface that is still habitable and safe. It should probably scale such that mildly irradiating a world will have nearly no effects if the population is at 1% of capacity, but will have severe effects at 10% and will cause total collapse at 100%. A completely irradiated planet will be dangerous even if the population is at just 0.1% of capacity.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bughunter on August 27, 2019, 02:42:21 AM
Since maximum planetary population is now a thing, why not have the effects of radiation scale with how full the planet is? Realistically, high-intensity radiation will likely remain largely localised, and even on a planet that's undergone significant bombardment, there is still likely to be a significant part of the surface that is still habitable and safe. It should probably scale such that mildly irradiating a world will have nearly no effects if the population is at 1% of capacity, but will have severe effects at 10% and will cause total collapse at 100%. A completely irradiated planet will be dangerous even if the population is at just 0.1% of capacity.

I like the idea behind this. But even for barely colonized worlds the missile impacts (and radiation) would be right at the main colony site, mines etc. and thereby a major inconvenience even if everything could theoretically be moved to the other side of the planet. Still it could make sense that fully populated worlds are affected more, and in terms of gameplay becomes even more high-value targets.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on August 27, 2019, 07:08:35 AM
That will depend on how much Infrastructure is needed per colonist. Higher infrastructure requirements would encourage more dense colonization efforts in an attempt to lower costs by limiting how much Newton compliant infrastructure needs to be covered for by TN Infrastructure. On an easily habitable world that's not as important because there are less problems that need to be covered for.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on August 27, 2019, 02:16:01 PM
As an expansion to the intel options I was wondering whether the ability to detect levels of jump point activity and time since use through a scan of an un-stabilised jump point. I think this would add an interesting capability when it comes to tracking NPRs back to their homeworlds and vice versa for NPRs to find routes back to player systems. Longer scans might give number of jumps in recent periods or rough tonnage of jumps based on some technobabble on anlysis of disturbances in the jump point. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on August 27, 2019, 08:35:34 PM
As an expansion to the intel options I was wondering whether the ability to detect levels of jump point activity and time since use through a scan of an un-stabilised jump point. I think this would add an interesting capability when it comes to tracking NPRs back to their homeworlds and vice versa for NPRs to find routes back to player systems. Longer scans might give number of jumps in recent periods or rough tonnage of jumps based on some technobabble on anlysis of disturbances in the jump point.


All of which are interesting ideas, but none of whose data are currently being recorded.  So Steve would first have to implement records for every jump point before we could then have technology / components to 'see' those records.  And I'm pretty sure trying to write an AI for how & when to scan wormholes would be a nightmare, meaning this sytem would be a huge benefit to Player Races, and very little to NPRs.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kiruth on August 28, 2019, 10:52:25 AM
I'd like to play more with mine and minefields, but when I played last time deploying mines was a bit of a chore (please note that it's more than an year that I don't play, and I'm no expert in Aurora).

1) Can we have a better way to create a "pattern/grid" of waypoint around a JP/Location?
Something like: DX on Jump Point -> Add orbital waypoints (ask for number of Waypoints, Name prefix and distance from body, deploy them on the chosen orbit at equal distance)

This should be quite easy for JP (since they are fix on the map), for planet/orbital bodies it add an "update position" cost but could still be usefull (and we already have orbital mechanics for moons and alike)

2) Can we have a way, during launch of mines/buoy, to limit the active sensor pickup range? I don't mean to limit the actual emissions, that would be undesirable for gameplay balance, but to have something like an engagement distance (eg.  if you output 100 emission and 10m range at resolution 10, if you limit during launch to 5m range it will still output 100 emission). . . this way we don't need to design/carry around multiple type of mines if we want to have "staggered" range of mines detection/activation
These option could also be applied to multi stage missile, so we can have only 1 type of sub-munition but we could design missile with sub-munitions configured differently (albeit I could not find an use of this configuration on top of my head)

Regarding the recent ground unit Intellicenge: do you plan to add bonus/intelligence breakthrough based on land/planet conquest? Maybe based on the type of infrastructure still intact and/or number of population still alive after the conquest? I think this could simulate acquiring information on technology and/or mass interrogation of population.
Do you also plan to address the trickling of Intelligence due to civilian shipping if we are talking about neutral powers? I seems to remember something like this mentioned for VB6. . .
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on August 30, 2019, 07:59:40 AM
SUGGESTION

I suggest changing geological survey sensors to be a military system.  The original rationale for them to be civilian was so that commercial companies would build geo survey designs.  Aurora has changed so that civilians no longer build geo surveyers, removing the need for civilian geo sensors.

Geo sensors also break the 'sensors larger than one hull space are military systems' rule.  (The counter-point to this, that geo sensors should be reduced in size and effectiveness to one hull space to remain civilian, raises the question of why grav sensors cannot likewise be reduced -- or if they can, why they are not then civilian systems.)
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on August 30, 2019, 08:07:26 AM
SUGGESTION

I suggest changing geological survey sensors to be a military system.  The original rationale for them to be civilian was so that commercial companies would build geo survey designs.  Aurora has changed so that civilians no longer build geo surveyers, removing the need for civilian geo sensors.

Geo sensors also break the 'sensors larger than one hull space are military systems' rule.  (The counter-point to this, that geo sensors should be reduced in size and effectiveness to one hull space to remain civilian, raises the question of why grav sensors cannot likewise be reduced -- or if they can, why they are not then civilian systems.)

I have been considering this for a while and probably will make this change.

Title: Re: C# Aurora v0.x Suggestions
Post by: Doren on August 30, 2019, 12:19:34 PM
I'd really love if Galactic map would center on the system you have selected on system map
Title: Re: C# Aurora v0.x Suggestions
Post by: Bughunter on August 30, 2019, 12:38:04 PM
I'd really love if Galactic map would center on the system you have selected on system map

I would hate the same thing as I don't want it to move around from where I centered it. Cannot be easy to be Steve  ;)
Title: Re: C# Aurora v0.x Suggestions
Post by: DEEPenergy on August 30, 2019, 04:08:29 PM
How about a 'center on selected system' checkbox  :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on August 31, 2019, 07:09:06 AM
I'd really love if Galactic map would center on the system you have selected on system map

I'm positive that there already is some combination of Ctrl or Shift clicking (maybe dragging) that does this.  I don't have Aurora handy to check, but isn't it:

Single click highlights the system
Double-click opens the system
Ctrl-click draws box to move systems

Maybe it's click-and-drag that moves the map?  Shift-click and drag?
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on August 31, 2019, 08:15:33 AM
Some thoughts on how to handle tractor beams and tractoring several ships/stations/modules with a single tug?

Currently there is a bug/exploit in VB6 where you can tug many stations/module with a single tug as if you only tractor one station.

There certainly are some role-play value in using tugs to tractor cargo modules and connecting several of them and move them as you would a train, this seems reasonable in space when you have tractor technology available. Although perhaps there should be some limits to how much a tractor beam should be able to pull so you need more tractor beams for heavier mass to drag along. You could then also have a technology that can increase the tractor strength per tractor beam.
Title: Re: C# Aurora v0.x Suggestions
Post by: Doren on August 31, 2019, 08:28:54 AM
I'm positive that there already is some combination of Ctrl or Shift clicking (maybe dragging) that does this.  I don't have Aurora handy to check, but isn't it:

Single click highlights the system
Double-click opens the system
Ctrl-click draws box to move systems

Maybe it's click-and-drag that moves the map?  Shift-click and drag?
I think you are talking about moving and positioning the systems on the map? I'm talking about panning the map to a system when you open the map without touching the saved position of the systems.

The thing I want this for is that when I click task force event and jump to a system where the task force has finished up it's business I need to give new orders and often I need to send them to nearest colony for refuel. The problem is with ever increasing system names (especially if you play real stars) it can be rather hard to remember the exact name of the system and where it stands on the saved galactic map. Right now I open the galactic map and look at the edges of known galaxy for the correct system name or if that fails use the find system function. It would be faster if the galactic map had already panned to the system so I would be able to chart the course with a quick glance
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on August 31, 2019, 08:31:38 AM
Perhaps make a check when attempting to connect a tractor beam: If the vessel attempting to engage the beam is already connected (either with its own beams or as the target) to more than its own tonnage, then it cannot connect.

This way, you could have a single large tractor towing a number of smaller pods (e.g. a satellite catcher towing back three probes to its mothership for refurbishment), or a large station such as an asteroid miner or fuel refinery being towed by multiple tugs. Or two battlecruisers towing a crippled dreadnought off the battlefield.

This would not allow the creation of serially coupled trains, but those anyway seem difficult to justify in space, since there is no shared rail system to provide guidance.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on August 31, 2019, 11:02:04 AM
I think you are talking about moving and positioning the systems on the map? I'm talking about panning the map to a system when you open the map without touching the saved position of the systems.

No, I'm talking about changing where the map is centered.  I know it's possible because I have done it.

If you're talking about switching to & auto-centering the galactic map by double-clicking on a system name on a different window. . .  I think most of them do that already.  Maybe they only do that if they open the galactic window, not if it's already open.
Title: Re: C# Aurora v0.x Suggestions
Post by: Doren on August 31, 2019, 12:12:43 PM
No, I'm talking about changing where the map is centered.  I know it's possible because I have done it.

If you're talking about switching to & auto-centering the galactic map by double-clicking on a system name on a different window. . .  I think most of them do that already.  Maybe they only do that if they open the galactic window, not if it's already open.
I started snooping around menus since all I ever saw was opening systems menu and such and there does seem to ever open but lo and behold there's a option to center the galactic map in the task force menu it doesn't seem to work unless galactic map is open already but I need it open to map the route anyway so this should do
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 02, 2019, 08:47:32 AM
Maybe an idea for version 1.1: a lot of international politics is based upon resources. The ones you need, the counties they have it, they become your friends.

Since it will be possible in C# to have multi nations on one planet, it would make it more interesting if the resources of that planet aren’t global, but dependent on where the nation is. Could be a simple system of: body has <random number of resource areas>, which have each x, y, z amount of TN resources, and that area number is linked to a nation (and one nation can of course control several of them). You can then eventually fight for those areas individually - or make them part of diplomatic agreements to exchange after a war.
Title: Civilian infrastructure transport
Post by: Stryker on September 03, 2019, 02:36:34 PM
One of the things I regularly see is the civilian fleet moving infrastructure to the closest colony until it is marked stable.    However, I quite often end up with enough infrastructure for 15-20 million people on say Luna, which may only require 7-8 million people.    At the same time my colony on Europa, for example has minimal infrastructure with a manufacturing efficiency of 20-30%, yet I still can't mark Luna as stable (despite the fact that I have millions more population than I have jobs for them). 

Perhaps rather than checking to see if a colony is stable or not,  the civilian fleet should check the manufacturing efficiency of colonies first, then check to see if they are stable or not before determining where to drop infrastructure. 

This may also improve the AI's colonies efficiencies as I don't know if the AI will use contracts for civilian fleets.   This way the infrastructure is going not only where the player needs it, but where the AI needs it as well.

For example:
Luna: Pop.   15 million, manufacturing efficiency 100%, not yet stable. 
Europa: Pop.   2 million, manufacturing efficiency 27%, not yet stable. 
Decision: Deliver infrastructure to Europa. 

This would boost Europa's manufacturing efficiency, while not harming Luna's.    This would also make more sense from an RP standpoint as increasing Luna's population, without increasing it's number of jobs would actually increase unhappiness rather than decreasing it. 
Title: Civilian infrastructure transport part 2
Post by: Stryker on September 03, 2019, 02:56:44 PM
An alternate solution to moving the trade infrastructure where it needs to be would be to remove the 25 million population cap for marking a colony as stable.   

After all, if my colony has 7 million people, but has 100% efficiency, it is stable.   Introducing more infrastructure increases the population, which increases unemployment, which introduces instability and unhappiness.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on September 04, 2019, 10:40:47 AM
Trying to move this discussion out of the AAR comments thread to the appropriate place for better visibility:

When you refit ships are the systems replaced put into storage or just lost? I tend to have front line fleets, kept up to date with the latest equipment and second line squadrons which I would want to upgrade with the items removed from the front line fleet. In VB6 it appears systems removed in refits are just lost. I would like the option to reuse systems removed in refits.

Yes, they are lost in C# too. Should be straightforward to add them to the stockpile instead.

I would like that too, we can scrap them for a few pennies worth of resources, or re-use it for 'colonial fleets units'.

If components you take out of ships for refit are retained, which I think is a cool idea (maybe with an 'auto-scrap' toggle) then the refit cost calculation should probably also be re-worked, since right now it assumes the cost of removing the components is balanced by the minerals/manpower saved by repurposing and recycling them.
Title: Re: C# Aurora v0.x Suggestions
Post by: ropedog on September 04, 2019, 11:36:30 AM
Quote from: TMaekler link=topic=9841. msg114280#msg114280 date=1557237855
For a more "random" experience in the research area, maybe going into a different direction might be interesting to think about - whilst keeping a "kind of deterministic" system as it is now.

I personally really, really like that individual control you have over your ship designs.  It's not like in most games: Destroyer Class I, Class II, etc.  But that concept doesn't transfer to the underlying technologies you have to research.  They are Tech I, Tech II, etc.

In todays military, if they for example want to have a new type of fighter, they compose a list of ideas, what that fighter should be able to do.  Then the underlying research begins (if that is possible and in what areas new technologies or materials would have to be researched).  I imagine a similar kind of system for Aurora without the actually given limits of certain weapons, ranges, etc. : You specify what kind of ship you want to have.  In a second step the game then shows you a list of needed technologies for that ship type and what research duration each part would need (the duration would of course highly depend upon what you are actually capable of and the bigger the difference to your actual state of technology is, the bigger the duration will be).
You then go back and forth between design wishes and research list until you are happy with the individual research durations (maybe you didn't like the long duration of the new armor research and toned your wishes down to a "reasonable" duration) and give permission to research the modules.

That system would enable you to
a) react to certain situations individually (like in a war you realize that your laser weapons are slighty (5000km range) to short to overwhelm a certain enemy ship type, so you give a quick research order to increase the laser range and refit your ships quickly with the new weapon type; whilst in the actual system you would have to research the next (full) step of technology - which of course would bring your range 50. 000km but would also need 18 month to research instead of 3)
b) give long term research jumps a go if your political situation allows for that in peace times
c) can control technology more precisely, be a bit more in control of your research time, etc.

Again, this would be quite an overhaul - don't know if it would be worth it.
I've also been thinking how a bit of randomness should be introduced to the research area.
I find it a little immersion-killing (and a little too much micro) that you know exactly when that new ultra high tech engine tech will be completed, so you end up waiting to build the new engine that's needed for your new destroyer.   Then the engine tech finally is done, but the next laser tech is right around the corner, and on and on. . .   Or, you move your labs around so several techs complete in the same month.   The only surprise comes when your prize scientist gets killed and your project gets pushed back.
I don't think we should know exactly when technology discoveries occur, maybe an estimation or target, but with lots of built-in variability.   That way you have to use what you have, or take the gamble and wait - which could be 3 more cycles or 30!  This would make min-maxing impossible for research.
I have ideas of how to accomplish this (including adding team mechanics to research), but won't get into the details unless there is interest in this idea.

As TMaekler stated, I think the current method is much more believable in the construction area, but I don't think that's how research/innovation works in the real world.

I wouldn't expect this in the first release of C#, but maybe, hopefully v2. 0 if there's support.   But, I think it would greatly increase the variability from game to game, and just make for a better story.

Thanks!
Title: Re: C# Aurora v0.x Suggestions
Post by: Drakale on September 04, 2019, 01:51:33 PM
I really like your concept of uncertain research time. Rule the Waves does it in a similar manner and it's true that it forces you to use what you have rather than plan out precisely what will be researched and when, although you still control the general direction of your research. It's a pretty big change though, need to find a ratio between remaining RP and the how likely a breakthrough is and make the relation between technology level and invested RP less direct.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on September 04, 2019, 03:41:18 PM
I really like your concept of uncertain research time. Rule the Waves does it in a similar manner and it's true that it forces you to use what you have rather than plan out precisely what will be researched and when, although you still control the general direction of your research. It's a pretty big change though, need to find a ratio between remaining RP and the how likely a breakthrough is and make the relation between technology level and invested RP less direct.

I think a system similar to Rule the Waves would do well in Aurora for role-play purposes.

You basically would assigns researchers and labs for each category and then the game give you what it does give you when it is time for it. It certainly is more realistic and would serve very well for multi-nation campaigns.

Rule the Waves also has a diminishing return on investment into research which is also sort of realistic.

The system would abstract research and with research agreements with others you would then get specific points or benefits to research things that partner already have or if you research in the same thing you could both get a small bonus to that research.

You would then get some hints on research progress or if there is any setbacks.

There could then be some things you can steer research such as lowering the research on some weapon in order to prioritise something else. But you should never be able to completely cut research on some specific things, society have a tendency to be rather curious and want to know just for the sake of knowing. And often we the player use perfect foresight of the mechanic to just don't research something because we know that we don't need it, that is not usually how the people in that world actually see things.

I know that Steve don't like to add optional rules, but I really think that having something like this would be awesome so we don't end up with the same stuff every time at the same time, it just is not very realistic. But some players probably would object quite strongly so it could be an option in the same way that officer political influence can be an option for realistic purposes or maintenance on ships etc...

I always RP in my games that research labs (and even industry) can't just be moved between areas, that I have done for a long time. Even within the same area labs can't just switch focus in a major way. I want the factions of my games to make long term decisions and need to live with what they have for a long time. Expensive components is very difficult and time consuming to research etc..

I would definitely be in favour of this in some form and it works really well in Rule the Waves.
Title: Re: Civilian infrastructure transport
Post by: Doren on September 05, 2019, 01:18:12 AM
Perhaps rather than checking to see if a colony is stable or not,  the civilian fleet should check the manufacturing efficiency of colonies first, then check to see if they are stable or not before determining where to drop infrastructure. 
Maybe a new option of "Promote colonization" to spend money to increase civilian sector's willingness to interact with the colony could be added
Title: Re: Civilian infrastructure transport part 2
Post by: theoderic on September 05, 2019, 02:47:38 PM
Quote from: Stryker link=topic=9841.   msg116290#msg116290 date=1567540604
An alternate solution to moving the trade infrastructure where it needs to be would be to remove the 25 million population cap for marking a colony as stable.     

After all, if my colony has 7 million people, but has 100% efficiency, it is stable.      Introducing more infrastructure increases the population, which increases unemployment, which introduces instability and unhappiness.   

Cool, but shouldn't people actually move to the places that has "jobs" rather than infrastructure?

The current system in aurora basically just means a colony gets filled even if the planet has no jobs, is extremely toxic and has massive G-forces.    I would suggest an adoption of the "free market" system where shipping lines are only able to transport colonists to planets that are actually attractive for people to live in, this would also reintroduce the need to build colony ships of the "state" that can transport people to planets guided by a more draconic mindset.     ::)
Title: Re: C# Aurora v0.x Suggestions
Post by: TheRowan on September 05, 2019, 04:45:49 PM
I always assumed that infrastructure included a certain amount of "non-TN" jobs... the colonists who aren't labouring in your mines and shipyards aren't necessarily unemployed, they're just working as estate agents, or short-order cooks, or dog groomers. They're not necessarily going to want to move just because you've opened a new Maintenance facility on Eros.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on September 05, 2019, 05:30:34 PM
Given that Aurora doesn't simulate unemployment figures, it's very reasonable to assume that the section of the population that's available as the Manufacturing sector is the section of the population that could be employed in TN industries, and the remainder is otherwise gainfully employed doing non-TN jobs that may or may not involve manufacturing.

I mean, nobody cares if your TN factories are doing anything either, they'll still generate wealth, so they are probably being used for something even if it's not anything TN related. They'd hardly be running idle, that's entirely too expensive.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on September 05, 2019, 05:59:19 PM
Yeah we've had this discussion before and it kinda opens a whole can of worms. Basically, if we want to have more "realistic" immigration/emigration mechanics, then the whole civilian sector needs to be revamped and made more detailed.
Title: Re: C# Aurora v0.x Suggestions
Post by: mtm84 on September 05, 2019, 08:29:55 PM
Personally I’m ok with the current high level economic function vs something detailed like, say, a Paradox grand strategy game.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on September 06, 2019, 08:33:41 AM
Yeah we've had this discussion before and it kinda opens a whole can of worms. Basically, if we want to have more "realistic" immigration/emigration mechanics, then the whole civilian sector needs to be revamped and made more detailed.
Personally I’m ok with the current high level economic function vs something detailed like, say, a Paradox grand strategy game.

I'd still like a tad bit more detail, so that for example if you move alot of TN factories, shipyards and facilities to a new colony it will create alot of demand which will cause shipping companies to focus on getting more people there ASAP to fill that demand instead of sending colonists seemingly towards random destinations.

Doesn't have to be anything fancy or super detailed, just the basics of unemployment/worker shortage + connection to where people want to relocate from and towards.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpikeTheHobbitMage on September 07, 2019, 04:05:47 PM
Yeah we've had this discussion before and it kinda opens a whole can of worms. Basically, if we want to have more "realistic" immigration/emigration mechanics, then the whole civilian sector needs to be revamped and made more detailed.
Personally I’m ok with the current high level economic function vs something detailed like, say, a Paradox grand strategy game.

I'd still like a tad bit more detail, so that for example if you move alot of TN factories, shipyards and facilities to a new colony it will create alot of demand which will cause shipping companies to focus on getting more people there ASAP to fill that demand instead of sending colonists seemingly towards random destinations.

Doesn't have to be anything fancy or super detailed, just the basics of unemployment/worker shortage + connection to where people want to relocate from and towards.
Aurora already models three 'motivators' that could be used to effectively govern population movement:
Overcrowded populations should want to move to colonies with sufficient space.
Unhappy populations should want to move to colonies with sufficient space and no unrest.
Unemployed populations should want to move to colonies with sufficient space, no unrest, and a worker shortage.  'Lower unemployment' would be a better destination metric, but care would be needed to prevent seesaw movement.
The system doesn't even need to be efficient as long as the above rules are followed and colonists in transit are accounted for.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on September 07, 2019, 08:04:59 PM
You have that wrong.
Overcrowded populations would seek more room.
Unemployed populations would seek employment.
Unhappy populations would seek to relieve the cause of their unhappiness, which is not modeled (the most common method is some form of regime change, civil unrest tends to be the result of continued heavy discontent in a population). High unrest populations however would generally seek other places with lower unrest.

All of these factors interact and strengthen eachother's impact on migration, but make no mistake, employment tends to be the most key factor involved. People will accept almost any circumstances as long as it means they survive. They just rarely accept them easily.
Title: Re: C# Aurora v0.x Suggestions
Post by: SerBeardian on September 09, 2019, 05:00:58 PM
Crossposting from the Discord:

Due to how tracking speed works, turrets that are slower than the ship are inherently useless.
This doesn't really make much sense since a turret rotating as the ship turns would have a faster overall tracking speed than one that's mounted to the hull.

I propose that turret tracking speed and ship tracking speed be additive values, not "instead of" values.

Proposed maths:
33% of ship speed is base tracking speed for non-fighters, 66% for fighters.
Turrets have their stated tracking speed.
Final weapon tracking speed would be the highest value plus 75% of the other.

Throwing some numbers out there:
A mag plas ship with 8000km/s movement and hull-mounted weapons would have 2666km/s tracking speed, or 33% base accuracy against itself.
Making the weapons turreted with a 6000km/s tracking speed would add 4500km/s to the final tracking speed, giving a total of 7166km/s.

Final numbers and equations would be up to Steve after playtesting, of course, but something along those lines.

This change would make turrets significantly more competitive in the beam ship world. Currently with speed being both offensive and defensive, combined with more guns per ton for hull-mounted weapons, and turrets adding literally nothing except wasted tonnage until they exceed the ship speed, makes turrets for anything other than PD significantly less effective than just mounting them to the hull. It would also provide a nice choice between spinals (harder hitting but inaccurate) versus turrets (more accurate but weaker), something that just doesn't compare with current weapons mechanics.

Thoughts appreciated.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on September 09, 2019, 05:28:10 PM
I propose that turret tracking speed and ship tracking speed be additive values, not "instead of" values.

Proposed maths:
33% of ship speed is base tracking speed for non-fighters, 66% for fighters.
Turrets have their stated tracking speed.
Final weapon tracking speed would be the highest value plus 75% of the other.

...

Thoughts appreciated.

IMO that formula both sounds unnecessarily complex and also contradicts your first statements that they should be additive.

A great feature of the current way it's designed is that it's easy to figure out what the tracking speed will be.


Id suggest something more simple like Fighters + FAC get 100% of ship speed ( but can't use turrets ) while other ships get 50% of ship speed + turret tracking speed.

Title: Re: C# Aurora v0.x Suggestions
Post by: ulf on September 10, 2019, 06:44:11 AM
A more "realistic" method would be that speed used for either tracking, or for maneuvering - so that the effective tracking speed would be max speed - current speed.
If so, it would also be good that actual required tracking speed (of the guns, not the targeting system) would be a bit lower too - after all, you don't need to change the direction the guns point by a lot if the target is only moving 2 degrees angle to you.  So effective speed for targeting should be some variant of current speed / distance - with counting at full speed if within 10k, as we're considering that point blank range.
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on September 10, 2019, 01:05:39 PM
what wrong with turret fighters and the classical multi-gun FAC? :'(

I do agree with your idea that ships less or equal to 20 HS have 100% of ship speed as basic weapon tracking speed and ships greater than 20 HS have 50% of ship speed as basic weapon tracking speed.

Or alternatively: Instead of a blanket 50% for all ships greater than 20 HS decrease it evenly from 100% ship speed as basic weapon tracking speed by 5% every additionally 20 HS greater than 20 HS until you hit 25% Base Weapon tracking speed from ship speeds at a certain size. Creating incentives for smaller ships as high accuracy escorts and for turrets on larger slower ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on September 10, 2019, 03:04:51 PM
what wrong with turret fighters and the classical multi-gun FAC? :'(

Game balance. If fighters/FAC both get a bonus to tracking from ship speed + can use turrets, then they would always be the best Point Defense platform, which I don't think should be the case.

Mid sized screens or larger ships should be able to field competitive point defense too IMHO.


The idea that ship speed contributes more to tracking the smaller the ship does make alot of sense, but for balance you need to make turrets better for larger ships too in that case or the risk is that everyone will build as small fighters as they can get away having just engine and a minimal turret for PD.
Title: Re: C# Aurora v0.x Suggestions
Post by: dukea42 on September 10, 2019, 08:16:33 PM
This touches on the element my brain can't wrap around which is that linear speed translates to tracking speed.  But in a fluid, turning is the death of linear speed.  The titanic was famously a fast ship that couldn't turn.

I feel like if work was going to be added here, it should consider a factor for ship level agility like what missiles have. A "rudder tech" tech and component line.   Perhaps a speed penalty for tracking when agility is low. A tracking penalty for attacks against when agility is high.  Tracking penalty for spinals when high speed goes above rudder sizing.

I know the game also traditionally has infinite acceleration, but at least this would bring a little acceleration factor into play without the full newtonian calculations.
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on September 11, 2019, 05:01:22 AM
I feel like if work was going to be added here, it should consider a factor for ship level agility like what missiles have. A "rudder tech" tech and component line.   Perhaps a speed penalty for tracking when agility is low. A tracking penalty for attacks against when agility is high.  Tracking penalty for spinals when high speed goes above rudder sizing.
If used Maybe call it thruster or maneuver tech ?

---

Game balance. If fighters/FAC both get a bonus to tracking from ship speed + can use turrets, then they would always be the best Point Defense platform, which I don't think should be the case.
In a way fighters and to a lesser extent FACs are already Superior PD units in a void outside of a campaign. Due to BFC bonus for fighters and small sensor pickup for FACs; fighters been used in a few of Steve's campaigns as fleet interceptors for PD and I have used PD FACs with long range endurance engines to escort survey ships. Outside of the void and in a campaign due to maintenance, fuel, crew, and other concerns not to mention the micromanagement to effective use such an advantage would mitigate the effects on game balance. Also as with most things in Aurora it's can be managed with self control on the players behalf of course.

The idea that ship speed contributes more to tracking the smaller the ship does make alot of sense, but for balance you need to make turrets better for larger ships too in that case or the risk is that everyone will build as small fighters as they can get away having just engine and a minimal turret for PD.

That would create an interesting follow-on effect as the largest reasonable size for a beam combat ship would additional have to be balanced against your turret tracking speed in addition to other considerations.
Or adding a hanger Bay to the design and carry a squadron of interceptors for PD which can be targeted by the enemy PD or interceptors...

I personally think that would be pretty awesome.
Title: Re: C# Aurora v0.x Suggestions
Post by: TheRowan on September 11, 2019, 08:36:21 AM
Game balance. If fighters/FAC both get a bonus to tracking from ship speed + can use turrets, then they would always be the best Point Defense platform, which I don't think should be the case.

I don't have an issue with turreted fighters being the most effective Point Defence platform, because they already have a price attached to that effectiveness. Using PD Fighters means you also need a Fire Control for every fighter rather than multiple turrets per FC on a larger ship. It means you need hangar bays, taking up more space than just mounting the weapons directly on the ship. You need mutiple crew quarters for each crewmember on your PD fighters (one on the fighter, one on the carrier). You need scanners on each fighter or run the risk of a separate scanner being destroyed and rendering the entire squadron ineffective. In other words, you may get the most effective PD platform, but not necessarily the most efficient.
Title: Re: C# Aurora v0.x Suggestions
Post by: Titanian on September 12, 2019, 08:01:18 AM
This touches on the element my brain can't wrap around which is that linear speed translates to tracking speed.  But in a fluid, turning is the death of linear speed.  The titanic was famously a fast ship that couldn't turn.

I feel like if work was going to be added here, it should consider a factor for ship level agility like what missiles have. A "rudder tech" tech and component line.   Perhaps a speed penalty for tracking when agility is low. A tracking penalty for attacks against when agility is high.  Tracking penalty for spinals when high speed goes above rudder sizing.

I know the game also traditionally has infinite acceleration, but at least this would bring a little acceleration factor into play without the full newtonian calculations.
The whole tracking speed calculation of the game doesn't make much sense - after all, the only thing a turret should care for is the angular velocity. If something comes at you directly, it's speed should not matter at all.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bughunter on September 12, 2019, 10:56:05 AM
The whole tracking speed calculation of the game doesn't make much sense - after all, the only thing a turret should care for is the angular velocity. If something comes at you directly, it's speed should not matter at all.

It doesn't come right at you. Some evasive manoeuvrers from the missile is counted into the calculation as I understand it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on September 13, 2019, 02:38:20 PM
This touches on the element my brain can't wrap around which is that linear speed translates to tracking speed.  But in a fluid, turning is the death of linear speed.  The titanic was famously a fast ship that couldn't turn.

I feel like if work was going to be added here, it should consider a factor for ship level agility like what missiles have. A "rudder tech" tech and component line.   Perhaps a speed penalty for tracking when agility is low. A tracking penalty for attacks against when agility is high.  Tracking penalty for spinals when high speed goes above rudder sizing.

I know the game also traditionally has infinite acceleration, but at least this would bring a little acceleration factor into play without the full newtonian calculations.
The whole tracking speed calculation of the game doesn't make much sense - after all, the only thing a turret should care for is the angular velocity. If something comes at you directly, it's speed should not matter at all.

No, this is the opposite of the problem. What matters for accuracy is how much space the target could possibly be in by the time your weapon hits - which in Aurora with lightspeed beams is going to be between zero and five seconds after being fired. So if the target moves at 1000 km a second, it could (theoretically) be anywhere within 5000 km of where it is now when the beam reaches it.

Realistically, it would be effectively impossible to pick anywhere within a 5,000 km sphere at random and hit the target, so it would probably be fair to say that ships can't just instantly change their speed and direction. But assuming the acceleration/deceleration/turning abilities of a ship are roughly proportional to its speed, then it's reasonable to say that accuracy should scale relative to that speed.

Meanwhile angular velocity should only really matter if it can literally rotate around you faster than the turret can, which isn't likely with a minimum combat distance of 10,000 km.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on September 14, 2019, 12:13:15 AM
Could just be that the 'fire control' is a huge supercomputer cluster that tries to predict the enemies position, and higher tech ones can generate acceptable hit probabilities against more agile enemies.

As for the turrets themselves and stuff, perhaps it relates to their ability to very rapidly make extremely minute adjustments to the direction they are pointing?  Assuming a 1km target at 128,000km range (I often have turrets that can shoot this far to my memory), thats about a 1.5 arcsecond target region (assuming my calculator fiddling just now was correct), which it seems to me is a tricky sort of target to snapshot instantaneously.

Not really sure about spinals to be honest, that just seems a bit wacky that ship agility significantly helps them aim.  I assume they have a degree of gimballing in their mounts, but it seems like said gimballing would be the main deciding factor to decide a hit in most cases.
Title: Re: C# Aurora v0.x Suggestions
Post by: Ranged66 on September 14, 2019, 05:38:33 AM
Facility:

Mining Hub. When placed on a planet, it will send out small automated mining vessels (mechanics could be similar to mass driver packets, just for fluff and looking cool) to nearby (1m km, upgrades with engine efficiency tech?) asteroids and small moons, slowly harvesting their minerals at a set amount per year. Could scale with the mining techs.

Module/mechanic:

Laboratory module. Make it huge, expensive, crew-intensive and heavy, but I've always wanted to make science vessels. There must be heaps of discoveries waiting to be found in those new star systems, considering the breakthroughs we already made with our limited space exploration IRL. It could allow for a new mechanic, where some planets can spawn with a pool of 'research points' in a specific field. A science vessel could perform research near the planet, then return and offload those research points into a tech currently being researched.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on September 14, 2019, 10:01:57 PM
That sounds like a really fun idea to me.
Title: Re: C# Aurora v0.x Suggestions
Post by: Ranged66 on September 16, 2019, 02:03:47 PM
Not sure how hard this will be to implement:

A game creation option to make JPs orbit too
If enabled, perhaps give them a chance to spawn in some Lagrangian points (L1, L2 or L3?) of planets
Title: Re: C# Aurora v0.x Suggestions
Post by: mtm84 on September 17, 2019, 11:26:58 PM
LPs already orbit, I can’t imagine it would be much more difficult to add that to JPs if desired.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on September 18, 2019, 04:36:44 AM
JPs make less sense to jump though. They're links between starsystems. And while starsystems shift location relative to eachother over time, the process takes thousands of years due to the vast distances involved.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on September 18, 2019, 07:42:41 AM
JPs make less sense to jump though. They're links between starsystems. And while starsystems shift location relative to eachother over time, the process takes thousands of years due to the vast distances involved.

What Hazard said. It does not make sense for the JP to move. They are, supposedly, "relative" to the position of the star they lead to.
At least, that's what I had understood
Title: Re: C# Aurora v0.x Suggestions
Post by: Impassive on September 19, 2019, 03:22:31 AM
We could also then have the trouble with waypoints and deepspace installations that are setup at a specific spot near a JP as a base to launch strikes from, but you don't want to be too close incase you don't eliminate the threat before jump shock wears off.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on September 19, 2019, 08:22:32 AM
Regarding gravity tolerances, instead of allowing us to set a range greater or less than the optimum gravity, can we instead have minimum and maximum acceptable gravity boxes? Higher gravity is generally far more dangerous than lower gravity. Experiments on primates have shown that while sustained 1.5 g is survivable indefinitely, 2.0 g is lethal within an hour. However, lower gravity, even microgravity, is far, far more survivable over a long period.

Humans can optimistically survive between ~0.10 g and ~1.50 g, but there's no way to set such a range with an optimum of 1.0 g.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on September 19, 2019, 08:47:53 AM
Regarding gravity tolerances, instead of allowing us to set a range greater or less than the optimum gravity, can we instead have minimum and maximum acceptable gravity boxes? Higher gravity is generally far more dangerous than lower gravity. Experiments on primates have shown that while sustained 1.5 g is survivable indefinitely, 2.0 g is lethal within an hour. However, lower gravity, even microgravity, is far, far more survivable over a long period.

Humans can optimistically survive between ~0.10 g and ~1.50 g, but there's no way to set such a range with an optimum of 1.0 g.

Yes, that is a good point. Maybe the gravity tolerance should be asymmetrical vs the baseline in general, rather than as a specific case.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on September 19, 2019, 01:15:41 PM
Regarding gravity tolerances, instead of allowing us to set a range greater or less than the optimum gravity, can we instead have minimum and maximum acceptable gravity boxes? Higher gravity is generally far more dangerous than lower gravity. Experiments on primates have shown that while sustained 1.5 g is survivable indefinitely, 2.0 g is lethal within an hour. However, lower gravity, even microgravity, is far, far more survivable over a long period.

Humans can optimistically survive between ~0.10 g and ~1.50 g, but there's no way to set such a range with an optimum of 1.0 g.

The problem with gravity is that it is a very complex question... it is one thing that a grown adult can survive but can you actually LIVE under those environment without being in the top 10% of the human population in terms of physical and psychological fitness. How about old, sick and children not to mention infants?!?!

No... I think that in terms of actually living most human settlements would need gravitational infrastructure for most gravity and the tolerances probably are very small in real terms, exactly how much is hard to say but these are much more complex questions outside the scope of the game.

I don't believe that humans will ever be able to LIVE on Mars outside a select small elite of fit relatively young people... not unless we manage to overcome gravity issues with some advanced technology in the future for all kind of people.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on September 19, 2019, 01:26:38 PM
Humans can optimistically survive between ~0.10 g and ~1.50 g, but there's no way to set such a range with an optimum of 1.0 g.

True, but there is also no need for the optimum to be 1.0g.  The 'grav factor' for colonization is calculated form the nearest point in the spread, so functionally there is no difference between 0.8g +or- 0.7g and 1.0g plus up to 0.5g or minus up to 0.9g.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on September 19, 2019, 01:29:19 PM
Or weighing down the body.

Low gravity worlds are much more tolerable than high gravity worlds relative to the world of origin. While the cardiovascular system will not develop to quite the same level as it doesn't have to fight gravity as much, the remaining differences regarding muscular atrophy and bone density can be handled simply by adding sufficient mass through lead weights at the shoulders and hips attached to a load bearing harness.

The body reacts to stress factors after all, and as long as the stresses are close enough to Earth it won't really matter.
Title: Re: C# Aurora v0.x Suggestions
Post by: Ranged66 on September 19, 2019, 02:02:37 PM
Regarding gravity tolerances, instead of allowing us to set a range greater or less than the optimum gravity, can we instead have minimum and maximum acceptable gravity boxes? Higher gravity is generally far more dangerous than lower gravity. Experiments on primates have shown that while sustained 1.5 g is survivable indefinitely, 2.0 g is lethal within an hour. However, lower gravity, even microgravity, is far, far more survivable over a long period.

Humans can optimistically survive between ~0.10 g and ~1.50 g, but there's no way to set such a range with an optimum of 1.0 g.

The problem with gravity is that it is a very complex question... it is one thing that a grown adult can survive but can you actually LIVE under those environment without being in the top 10% of the human population in terms of physical and psychological fitness. How about old, sick and children not to mention infants?!?!

No... I think that in terms of actually living most human settlements would need gravitational infrastructure for most gravity and the tolerances probably are very small in real terms, exactly how much is hard to say but these are much more complex questions outside the scope of the game.

I don't believe that humans will ever be able to LIVE on Mars outside a select small elite of fit relatively young people... not unless we manage to overcome gravity issues with some advanced technology in the future for all kind of people.

That 'advanced technology' can be as simple as a big spinning structure you spend a few hours a day in.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on September 19, 2019, 02:06:48 PM
Regarding gravity tolerances, instead of allowing us to set a range greater or less than the optimum gravity, can we instead have minimum and maximum acceptable gravity boxes? Higher gravity is generally far more dangerous than lower gravity. Experiments on primates have shown that while sustained 1.5 g is survivable indefinitely, 2.0 g is lethal within an hour. However, lower gravity, even microgravity, is far, far more survivable over a long period.

Humans can optimistically survive between ~0.10 g and ~1.50 g, but there's no way to set such a range with an optimum of 1.0 g.

The problem with gravity is that it is a very complex question... it is one thing that a grown adult can survive but can you actually LIVE under those environment without being in the top 10% of the human population in terms of physical and psychological fitness. How about old, sick and children not to mention infants?!?!

No... I think that in terms of actually living most human settlements would need gravitational infrastructure for most gravity and the tolerances probably are very small in real terms, exactly how much is hard to say but these are much more complex questions outside the scope of the game.

I don't believe that humans will ever be able to LIVE on Mars outside a select small elite of fit relatively young people... not unless we manage to overcome gravity issues with some advanced technology in the future for all kind of people.

That 'advanced technology' can be as simple as a big spinning structure you spend a few hours a day in.

We are still talking about a society with lots of different people of all kinds... not a station with selected personnel that can live under special conditions. In my opinion any such technology need to disrupt life in a very minimal way for a society to function properly.

I imagine that colonies in Aurora do have advanced anti-gravity or gravity manipulation technologies built into its main infrastructure on world that deviates too much. But at some point this technology become very expensive and those worlds are outside the spectrum of colonisation.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on September 19, 2019, 02:39:51 PM
Humans can optimistically survive between ~0.10 g and ~1.50 g, but there's no way to set such a range with an optimum of 1.0 g.

True, but there is also no need for the optimum to be 1.0g.  The 'grav factor' for colonization is calculated form the nearest point in the spread, so functionally there is no difference between 0.8g +or- 0.7g and 1.0g plus up to 0.5g or minus up to 0.9g.

Also good point :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Kelewan on September 20, 2019, 07:25:17 AM
Hi,

i had some ideas about managing ground force formations. 
http://aurora2.pentarch.org/index.php?topic=10498.msg116436#msg116436
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 23, 2019, 10:47:28 AM
Maybe the people who colonize on a 0.5g world will change over time like in the Expanse series. Someone who grew up in 0.5g won't at some point be able to live on earth. So you cannot settle back those people at some point.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on September 23, 2019, 09:39:08 PM
Maybe the people who colonize on a 0.5g world will change over time like in the Expanse series. Someone who grew up in 0.5g won't at some point be able to live on earth. So you cannot settle back those people at some point.

That's why we have Genetic Modification Centres to make (literal) Martians.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 24, 2019, 06:30:47 AM
Maybe the people who colonize on a 0.5g world will change over time like in the Expanse series. Someone who grew up in 0.5g won't at some point be able to live on earth. So you cannot settle back those people at some point.

That's why we have Genetic Modification Centres to make (literal) Martians.
Yes. I was just thinking that it can happen automatically if you settle in a gravity, too far from your original one, but close enough that you can.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bughunter on September 24, 2019, 08:59:28 AM
I don't think this is relevant on the timescale an Aurora game even with C# performance.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on September 24, 2019, 06:09:21 PM
I mean, epigenetically at least, you'd probably start seeing noticable changes within a few generations.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on September 25, 2019, 01:10:25 AM
Yes. I was just thinking that it can happen automatically if you settle in a gravity, too far from your original one, but close enough that you can.


Okay, but what does that do to the value of GenMod/BioTech?  If I can just dump colonists on a body and wait for them to change species grav and/or temp tolerance over time, then there is definitely a point at which I shouldn't bother building Infrastructure, LGI, and/or GeneMod Centres.

I certainly (and I suspect other players do) already view BioTech and GMCs as "luxury goods" that my empires don't bother with until well into their industrial development --  or as part of specific scenario set-up.  If I want a "The Moon is a Harsh Mistress" feel then I need 'Lunies', but if I'm playing SPACE:1889 my British Empire has no need of (or desire for) 'super-humans'.

Which brings up the point that in some scenarios, I actively don't want my population mutating to meet colonial conditions.  If I set up a 'John Carter of Mars'-inspired solar system, my Martians, Jovians, and Earthlings need to stay recognizably different.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on September 25, 2019, 03:06:11 AM
Yes. I was just thinking that it can happen automatically if you settle in a gravity, too far from your original one, but close enough that you can.

For game play reasons I don't think you would want your Empire slowing morphing into many different species. It would be a micromanagement nightmare, especially as new colonists arrived from the old species and you ended up with different species even on the same body.
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on September 26, 2019, 04:34:05 PM
Can we have a export / import feature for ships, missiles, and player designed components? One for the new ground forces would be nice as well. :)

Ideally it would export not just the stats, but the component tallies and the specifications of the component w/ RP costs.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on September 27, 2019, 11:02:31 AM
Unless I've missed something, Terraforming Modules are still 500 BP while Terraforming Installations are 600 BP and need 250k workers. This seems like a problem? Either modules should be 1200 BP to match the costs of similar components or installation costs should be reduced to ~200 BP.
Title: Re: C# Aurora v0.x Suggestions
Post by: Shuul on September 29, 2019, 04:44:02 AM
I always play Aurora starting in another system, not sol. It is much more easier to roleplay for me that way. But it's such a chore to creat a suitable starting system.
Can we have an option to start in a non-sol system? Game can just generate and destroy systems until it finds a suitable one in the same way as we had to do it manually in SM mode?
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on September 29, 2019, 05:27:57 AM
I always play Aurora starting in another system, not sol. It is much more easier to roleplay for me that way. But it's such a chore to creat a suitable starting system.
Can we have an option to start in a non-sol system? Game can just generate and destroy systems until it finds a suitable one in the same way as we had to do it manually in SM mode?

I'm not saying we shouldn't have this, but I've never needed to generate more than two (EDIT: that's a lie, I've had starless nexi three times in a row) systems to get a homeworld.

  --  Grab a body (planet, gas giant moon, super-asteroid, etc.) of acceptable gravity
  --  SM remove all atmosphere and add nitrogen-[oxygen/methane]
  --    --  (and if you care about temperature, greenhouse or anti-greenhouse gas) to taste.
  --  Done.

If you want a Human empire, you grab the body closest to 1.0 gravity and SM the atmosphere to 0.23 Oxy, 0.78 Nitro, and however much GG or AGG needed.  Otherwise Aurora will create a custom, 'native' species perfectly suited to your world.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on September 30, 2019, 03:23:39 AM
At the moment making part of your empire independent is quite a hazzle; if it works at all. Have you spend some thought on making it easier to split of fractions of your empire? Maybe some kind of SM dialog where you can select colonies, technologies, ships, etc. which want to "join" the new empire, rather than having to struggle through several dialoges and have to do it manually... .
Title: Re: C# Aurora v0.x Suggestions
Post by: Tavik Toth on September 30, 2019, 08:00:18 AM
Yeah, I'd like to see that, along with the option of making the independent parts a NPR/s
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on September 30, 2019, 08:10:23 AM
On the topic of NPR and SM...

Would it be possible to either convert a NPR permanently to a player controlled race, or just sharing vision of being able to see everything they see but not changing anything?


I think this could be very helpful both for making it easier for the community to find bugs if an NPR get stuck, understand how the NPRs AI work ( and how it can be improved ) and for storytelling where you want a NPR in your story to start doing something different.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tikigod on October 02, 2019, 10:23:48 PM
Reading up on the change to MSP construction and the resources involved, and was wondering would it be possible to have a ship order for our transport ships something like "Pick-up Maintenance Resources" and a "Drop-Off Maintenance Resources" that will instruct that ship to fill (Or empty) a variable % amount of its cargo hold with the resources required for producing MSP, with the resources picked-up and dropped off done that maintains a balanced ratio between the resources (Or as close to the ratio as that ship was able given the source target)?

Seems like a nice little quality of life addition that would remove a lot of the excessive repetitive order clicking when running regular supply runs into more established campaigns, and would also help indirectly address the issue raised in the change list post about having to keep track of the exact resources and ratios when trying to keep your empire running. 


Edit: This is slightly more clunky from a UI design perspective, but instead of a % amount of cargo hold perhaps even have the custom field for amount to collect actually denote the actual number of MSP that would be produced. So a transport fleet told to "Pick-Up Maintenance Resource" for 100,000 MSP worth of resources, would attempt to collect:

10,000 Duranium.
5,000 Uridium.
10,000 Gallicite.

The player could then more easily set further orders to "Drop-Off Maintenance Resource" to multiple destinations denoting the exact MSP output worth of resources they wanted for each stop.
Title: Re: C# Aurora v0.x Suggestions
Post by: Iranon on October 03, 2019, 05:58:07 AM
Would it make sense to expand the missile agility system to ships?

I miss the distinction between speed and agility, especially for beam fighter combat as I envision it.
Fast fighters could dictate combat conditions, but would lose to more nimble ones in a dogfight.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on October 03, 2019, 10:13:39 AM
On the topic of NPR and SM...

Would it be possible to either convert a NPR permanently to a player controlled race

Already exists in VB Aurora.  What you can't do is ever go back to an Aurora-controlled NPR afterwards.

or just sharing vision of being able to see everything they see but not changing anything?

In VB Aurora, turn on SM mode, then set the viewing options (generally top left corner of most windows) to the NPR of your choice.

(Note that this does not work for spoiler races.)
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on October 04, 2019, 01:30:30 AM
On the topic of NPR and SM...

Would it be possible to either convert a NPR permanently to a player controlled race

Already exists in VB Aurora.  What you can't do is ever go back to an Aurora-controlled NPR afterwards.

or just sharing vision of being able to see everything they see but not changing anything?

In VB Aurora, turn on SM mode, then set the viewing options (generally top left corner of most windows) to the NPR of your choice.

(Note that this does not work for spoiler races.)

I recall trying to do this a bunch of times with normal NPRs but never getting it to work properly. :(

Maybe I was missing something.. I'll have to test it again if Aurora C# is ever released I guess and return with more specific feedback.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on October 04, 2019, 12:54:05 PM
It'll be nice if we could force-spawn spoiler races in specific systems or locations, especially for scripted role-play games.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on October 05, 2019, 04:44:11 PM
This was mostly meant as a nebulous "some time in the future suggestion" when I mentioned it on Discord, but people seemed to like it, so here it is.

I'd like for there to be some crossover in beam weapons tech. Basically some techs would be shared between "schools" of weapons, so that having two types of beam weapons wouldn't require twice as much research.

For example, instead of Laser Focal Size, Meson Focal Size, and Microwave Focal Size, there could be one tech, "Focusing Lens Diameter" or maybe "Energy Weapon Focal Size" with the same cost to research.  There would still be Laser Wavelength, Meson Focusing, etc lines, so it's not that one tech would give you all three weapons, but rather you'd need the focusing lens diameter + one weapon specific tech. Using just lasers would still be two techs, but Lasers + Mesons would be three techs instead of four, and all three would be four techs instead of six. Meanwhile Railgun and Gauss Projectile velocity could be combined into one "Projectile Launch Velocity" tech (maybe alongside either plasma or a third new weapon), but you'd still need to research Railgun size and Gauss rate of fire separately.

The goal here is to make it more practical to use multiple types of beam weapon, and also clean up the research trees a little bit.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on October 07, 2019, 01:28:13 PM
That's a pretty nifty idea! I wouldn't mind that change at all.
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on October 08, 2019, 10:26:42 PM
I dunno... we can already process multiple Research Projects at a time. The only meaningful limits are Scientists and Labs. That, and the focusing elements of Lasers, Mesons, and Microwave weapons would be RADICALLY different.

I feel like these are already pretty balanced, and don't feel as though I'm being forced to choose... if anything else I find myself wanting MORE types of energy weapon.
Title: Re: C# Aurora v0.x Suggestions
Post by: MJOne on October 09, 2019, 12:43:20 AM
This was mostly meant as a nebulous "some time in the future suggestion" when I mentioned it on Discord, but people seemed to like it, so here it is.

I'd like for there to be some crossover in beam weapons tech. Basically some techs would be shared between "schools" of weapons, so that having two types of beam weapons wouldn't require twice as much research.

For example, instead of Laser Focal Size, Meson Focal Size, and Microwave Focal Size, there could be one tech, "Focusing Lens Diameter" or maybe "Energy Weapon Focal Size" with the same cost to research.  There would still be Laser Wavelength, Meson Focusing, etc lines, so it's not that one tech would give you all three weapons, but rather you'd need the focusing lens diameter + one weapon specific tech. Using just lasers would still be two techs, but Lasers + Mesons would be three techs instead of four, and all three would be four techs instead of six. Meanwhile Railgun and Gauss Projectile velocity could be combined into one "Projectile Launch Velocity" tech (maybe alongside either plasma or a third new weapon), but you'd still need to research Railgun size and Gauss rate of fire separately.

The goal here is to make it more practical to use multiple types of beam weapon, and also clean up the research trees a little bit.

From one perspective, this will flatten ”racial” variations.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on October 09, 2019, 01:55:29 AM
I personally kindof like the shared tech idea, mainly because a lot of those weapons are kindof useless on their own so you would need to research a family of weapons regardless.  One of the nice things about missiles is common techs give you better AMMs as well as ASMs, so it might balance things out a bit if you have tech that helps you get a family of projectile weapons, rather than JUST a guass weapon (mainly flak) or just a railgun (definitely not flak).


I could point to warhead strength for instance, which gives you better missiles of all kinds, whereas there isnt really an equivalent 'launch velocity' at the moment.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on October 09, 2019, 04:35:27 AM
There are engine strength, boost and efficiency techs though.

And yes, those are shared with warship engines.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on October 09, 2019, 11:50:39 AM
The problem with multiple techs for each weapon isn't much of an issue at early game when RP costs are quite low but they ramp up pretty quickly. Unless you're playing with a vast number of labs (or for RP reasons), you're probably not going to keep researching both rail and gauss once each tech goes above 10,000 RP - or both laser and meson and so on. Which means that if you're only playing one faction/race/power, your weaponry gets pretty monotone fairly fast. So having all energy beams and kinetic "beams" have a shared tech for both types would help out without making a choice completely irrelevant.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on October 09, 2019, 05:43:06 PM
I think the problem is less the number of techs and more the exponential growth of costs which strongly disincentivises more 'realistic' progression. I hope we see some sort of overhaul of the tech system in v1.x.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on October 09, 2019, 06:45:56 PM
One issue of this equation is that the number of labs you can give to scientists don't scale well with the expansion of empires. In the beginning 20-30 labs on one scientists can be all the labs that you have, more or less. It also feels very gamy to switch an entire societies labs from one project to the next and they are in completely different fields. If you are forced to split the labs in many fields even early on then research can't be so focused in general and the time it take to advance will be more equal throughout the game.

In my opinion the cost of techs could be less and the number of labs you can assign to scientists lowered quite substantially, perhaps some admin tech that can increase it over time which then would scale better with you able to build more labs.

I usually role-play this and start with one lab per level and then go up with the general tech research (one extra lab per two level of this tech)... this forces you to spread tech around and also make technology take way longer to research per level but the increased cost is then offset with you able to put more labs on one scientist.

So the current system could work if slightly altered, you can do it yourself if you really want to.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tikigod on October 09, 2019, 07:30:23 PM
This is entirely a personal preference of how I'd probably go about it in my own project more than a suggestion for what I think would be a better approach for Aurora, but I think a good way to go about it would be to treat weapons tech progression similar to how Aurora already handles engine drive tech progression... but just with a bit more width to it.

So there would a underlining high cost 'theoretical field' research which also provides some underlining advantage damage buff to a series of weapon types related to that field (The Aurora equivalent of this I suppose would be in the case of explosive missiles that the the warhead damage per MSP is increased or whatever other variable another weapons equivalent to that stat may be).

Once the theoretical field research tech is done a series of sub-techs are made accessible that relate to a very specific weapons branch, so a kinetic/explosives field research tech being completed would then open up one or two layers of techs for improving the various performance stats of missile, gauss and whatever other flavour of weapons you want to throw in. These sub-techs would be relatively small cost compared to its parent research project (25% of the parent tech sounds pretty reasonable if the theory were to exist in a Aurora scenario).

The player then has some choice about focusing strongly on the slow grind through the hefty theoretical field projects in one or more categories of weapons in a big push and then blitz the sub-techs after, or more optimise the performance at each stage then cross over into another weapons field and do the same until each are at a equivalent point and then repeat the process for the next stage.

As the sub-techs are relatively low cost, there is quite the incentive to specialise in a particular weapons field as it would return the biggest performance return in very frequent bursts once the underlining field tech was completed. However because each field tech covers a entire category of weapons related to that area, generalising and putting aside the sub-techs could provide a entirely different (but still effective in its own way) experience providing high damage weapon choices across multiple categories, but at the cost of secondary stat performance in each weapon type.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on October 11, 2019, 10:24:33 AM
I like that thought.

While we're at it, I think we should probably rename the Manufacturing Sector to the Public Sector and the Service Sector to the Private Sector, respectively, since that is far more indicative of what they actually are. The Agriculture/Environment Sector could probably be just eliminated entirely, since, IMO, the massive reduction in available workers for even moderate colony cost worlds is painful when playing a campaign with few, or no garden worlds around. We're already paying for terrible planetary conditions with more infrastructure, and there's never going to be linear increase in the workers needed to deal with that problem.

Oh, and wealth should probably be generated by the Private Sector (Service Sector) population, not the Public Sector (Manufacturing Sector) population as it currently is, but at a rate that is modified by the percentage of the manufacturing population employed in TN industries. It nicely fixes the realism issue without leading to excessive early wealth production.

It'll be nice to have the game properly model demographics, but that's going to be a hard sell.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on October 11, 2019, 01:27:04 PM
And I think we shouldn't do any of those things.

The names Agriculture/Environment, Manufacturing, and Service describe what they do.  Not only does your proposed renaming obscure their functions, but your political labels are factually wrong for my empire of Utopian Communist silicate-based rock people.  And my hive-mind machine race.  And my tribal warlord pirate faction.

On top of which, I point out that the term "Public School" means literally the opposite in the US as it does in the UK.  Replacing a label that clearly describes function with one upon which we disagree about what it does mean, what it should mean, and what it could mean is a bad idea.

- - - -

Removing the Ag/Env worker requirement for Colony Cost bodies would vastly increase the available space real estate.  It would eliminate most of the need for exploration, and virtually all of the need for expansion.  With populations producing endless free infrastructure, civilian shipping moving it around for free, and mass drivers moving refined minerals for free, there would be no need for population to ever leave the home system.  An empire could survey neighbour systems, mine everything and mass driver it to a collection point, ship it through the jump point, and mass driver it to final destination.

With no Ag/Env sector, Venus is as habitable as Earth.  All you have to do is send 1 Infrastructure and 0.000001 Population (in millions) and the civilians will do the rest.

I do not think that removing one of the major constraints of the game is a good idea.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on October 12, 2019, 01:43:26 AM
And I think we shouldn't do any of those things.

The names Agriculture/Environment, Manufacturing, and Service describe what they do.  Not only does your proposed renaming obscure their functions, but your political labels are factually wrong for my empire of Utopian Communist silicate-based rock people.  And my hive-mind machine race.  And my tribal warlord pirate faction.

On top of which, I point out that the term "Public School" means literally the opposite in the US as it does in the UK.  Replacing a label that clearly describes function with one upon which we disagree about what it does mean, what it should mean, and what it could mean is a bad idea.


I don't think that's quite fair. The 'manufacturing' sector does a lot more than just manufacturing, and let me bring up Steve's current campaign to demonstrate this.

(http://www.pentarch.org/steve/Screenshots/Crusade/Economic001.PNG)

The manufacturing sector has 312.5 million workers. Research and Development is not a manufacturing industry. Mines and Financial Centres are not manufacturing industries.  That's 90 million workers and 28.8% of the worker population not performing manufacturing activities in the so-called manufacturing sector.

Let's look at the Martian Republic from the Aftermath Campaign.

(http://www.pentarch.org/steve/Screenshots/MartianRepublic001.PNG)

40 million scientists, 24 million miners, and 6 million financial centre workers - 70 million of the 150 million strong labour force, nearly half the 'manufacturing population' is not actually performing manufacturing activities. It gets worse if you include maintenance workers as non-manufacturing labour force, which they traditionally have been.

The Manufacturing Sector appears to represent the proportion of the working population whose employment is directly controlled by the player, while the Service Sector is there just to limit the population directly under our control, and does nothing. It's easier to call them what they are - workers catering to the needs of the people, and workers catering to the need of the nation. The present labels just do not fit. Even something like Civilian/Commercial Sector and Government/State Sector is better. Unless it's hard-coded in, though, allowing the player to simply rename the sectors to whatever they want may be an acceptable compromise.

Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on October 12, 2019, 07:09:22 AM
I say it is neither of those things... it is just a mechanic of what the player controls and don't control. Exactly what each category or part of it is depend entirely on what society you imagine they belong to and how you approach using them as a player. The service sector are basically the part of the population the player simply have no control over and represent most of the private and public sector in form of commercial goods, schools, entertainment, agriculture etc... the manufacturing part is the part the player can influence by deciding what these people do for a living, this can be represented as a free market economy, closed communal society or a hive mind... it really does not matter what it is... it is just a difference on what the player can control and what they can't.

One part is the service sector the other manufacturing sector, these have no real meaning or ties to reality in that sense.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on October 12, 2019, 01:35:26 PM
I don't really see a huge upside to renaming the sectors, I too would prefer more functional names such as 'manufacturing' since that is a little more common to any given high tech society, regardless of how its organized.  I mean, maybe service could be renamed to something else, since I doubt a huge colony of semi sentient ant slaves would have such a thing?  I don't really think its really worth any degree of hassle though.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on October 12, 2019, 07:04:39 PM
It's easier to call them what they are - workers catering to the needs of the people, and workers catering to the need of the nation. The present labels just do not fit. Even something like Civilian/Commercial Sector and Government/State Sector is better. Unless it's hard-coded in, though, allowing the player to simply rename the sectors to whatever they want may be an acceptable compromise.
What the "manufacturing sector" currently represents is the empire's military-industrial complex, and if we are going for functional names, that is what I would suggest. It is incorrect to call it the government sector or state sector, as it does not include things like teachers or doctors, which in most industrial cultures are predominantly government workers.

Precisely how to split specific job functions between the "environmental" and "service" sectors is best left to the player's imagination in the current version - the important point is that their total share of the workforce grows as the planet becomes more hostile (you need more atmosphere scrubber techs and doctors to treat complications and accidents). The distinction is perhaps best seen as not actually representing an economic distinction we would recognize in the national accounts, but rather a way to make it transparent to the player why one planet has a smaller workforce available to the armaments sector than another.

In general, I am with the people who encourage not giving overly specific interpretations to the different parts of the economic model. It simply does not have the kind of granularity you'd need for that.
Title: Re: C# Aurora v0.x Suggestions
Post by: MJOne on October 13, 2019, 02:22:34 AM
I think the problem is less the number of techs and more the exponential growth of costs which strongly disincentivises more 'realistic' progression. I hope we see some sort of overhaul of the tech system in v1.x.

Well to be honest, most people I have seen on Youtube, playing are using research labs ineffectively.
Whats the point of having 20 labs on one tech, when 10 of these only cuts a few months of the research time?

It is better to research on a broad front maybe using 2-4 labs per tech.
2 labs cuts the research time in half. Thats a good investment.
4 labs cuts the time to a quarter. Half the investment gain per lab, compared to the above.

You get the idea...
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on October 13, 2019, 03:33:02 AM
I think the problem is less the number of techs and more the exponential growth of costs which strongly disincentivises more 'realistic' progression. I hope we see some sort of overhaul of the tech system in v1.x.

Well to be honest, most people I have seen on Youtube, playing are using research labs ineffectively.
Whats the point of having 20 labs on one tech, when 10 of these only cuts a few months of the research time?

It is better to research on a broad front maybe using 2-4 labs per tech.
2 labs cuts the research time in half. Thats a good investment.
4 labs cuts the time to a quarter. Half the investment gain per lab, compared to the above.

You get the idea...

That reasoning is mathematically suspect. Doubling the number of labs halves the time. That is always true, so why is 1 -> 2 a better investement than 2 -> 4? Remember, if the research finishes earlier, it also releases your labs earlier to do other stuff.

The thing you are trying to optimize is "at date XYZ, what is the most technologies I can have?" It doesnt matter how you spread your labs, assuming everything you put labs into completes by that time (ie. you dont leave anything half done), how you distribute your labs has no impact on anything except the order in which you unlock the technologies. However, we all agree having techs is better than not having them, so putting all your labs into fewer techs first means you unlock those specific techs earlier and the others at the same time as you otherwise would. A strictly superior outcome.

The real reason it is absolutely the right move the spread research out with 1-2 labs per tech is that scientists are far more likely to get skill increases if they are working, doesnt really matter how many labs they are working on as far as I am aware. Its the difference between having a single 50% bonus scientist after 10 years and having five of them. Or even higher. And that % bonus results in an absolute decrease in total research time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on October 13, 2019, 05:19:15 AM
It is straight up most efficient to give as many labs to as few scientists as possible and then exactly ONE lab to all the rest so they can train.

Unlocking techs along the way is way better than unlocking ALL the techs at the end of the cycle which you get if you spread your labs around evenly.

If you focus the labs you will in general speed up research and industry and so will win on that tactic in the end no matter how you see it.

To me this is boring and very unrealistic so I have rules that prevent this sort of usage of labs so you are forced to make more long term decisions which become allot more strategic and interesting. It also stops you from extreme focusing of certain technologies and areas.
Labs should instead have a diminishing return as you assign them to projects, this would be a far more interesting mechanic. This diminishing return could also be modified with the scientists administrative skills. A linear increase of more labs is not realistic to begin with. With this you also could skip the skill of the scientist, instead each branch could have sub branches instead. With that I mean a scientist can be "Defence System" major and "Shield" specialist... some could be specialist in more than one field. The administrative skill would impact the number of research point they can get from more labs while the major and specialist areas decide the base number of points they get from said research in a linear capacity. No need for numbered skills. This would produce more interesting choices for research would be my guess and a relatively simple change.

In my games I limit the number of labs that scientists can use differently than what the game does. I also force labs to be used in specific categories and shifting them to other categories can only be done over a longer time period, worst case scenario they will have to be unused for some time. But that is just how I does it and like to do it. I don't like the gamy type of efficiency by which you can focus either research or industry in the game. In my opinion the game become allot more interesting if you need to focus more on long term strategies, makes for more realistic decisions.

Part of these efficiency "problems" that the game have is also what causes the snowball effect to become quite severe in multi-faction games. Bonuses are directly transferred into better industry, research etc no matter where these facilities are or how many you have. A small (or tall) empire need as much investment in resources to transfer industrial efficiency bonuses as a spread out or wide empire can for example.

I know we have had these discussions before... but I think that now in C# buildings could have a technology level and we could now "upgrade" them with industry. This would be more realistic and would also force you to have some industry where you want to upgrade things. Automated mines could perhaps be upgraded by sending upgrading "kits" to those places.

This would make a huge difference to the game in the form of infrastructure and logistics and how much you can centralise the empires populations and also force most population sites to not specialise entirely which you often do otherwise which is quite unrealistic in most circumstances in real life. A society that retains all classes of people also tend to flourish allot better over all as it improve all aspect of the economy. Specialisation might in some ways be better in the short term, but long term it will just stagnate any local society and overall empires to. So I would like some game mechanics that reflect this to some degree and show that the sum of the parts often are greater than the individual parts separately.
Title: Re: C# Aurora v0.x Suggestions
Post by: The Forbidden on October 15, 2019, 04:40:19 PM
Idea for a SPOILER race for Aurora 4X.

This race is heavily inspired by the Achuultani from the Empire from the Ashes novel of David Weber, the Gbaba from the Safehold novel series also from David Weber, the Imperium of Man from Warhammer 40 000 license of Games Workshop, as well as the Fallen and Awakened Empires of the video game Stellaris from Paradox Interactive.

I’ll refer to the race as the Achuultani throughout the proposal to keep thing streamlined, as well as a form of hommage, it should be noted however that they have few things in common with the ones from the Empire from the Ashes besides periodic galactic genocide.

There is also a small TL;DR at the end, for those of you who don't want to wade through this wall of text ^^.

Fluff (background and information) :

The Achuultani is an interstellar, some would say galaxy spanning, Empire that has existed for so long that it’s origins vanish in the mist of galactic history. Their civilization came to galactic domination through the extermination of all other sentient forms of life in the galaxy. What triggered such a behavior is shrouded in mystery, and it is highly unlikely that the Achuultani themselves even remember it. One important fact however is that through xenocide their Empire was founded, and through xenocide it is sustained. The reason for such a long reign of galactic domination is simple : the Achuultani purely and simply wipe out any and all possible competitors to their hegemony, and every sentient specie they encounter is considered a potential competitor.

The Achuultani Empire is tied together by a massive network of so called Hyperspace Gates, massive constructs that can go from the size of a large space station to larger than an entire planet. Those Gates allow near-instantaneous travel throughout their Empire, allowing ships to traverse their massive galactic hegemony in a matter of days. Every colony in the Achuultani Empire has at least an Hyperspace Gate, which ties the solar system with the rest of the Empire. The gate varies in size depending on the colony of course, with small outposts having a gate barely capable of letting FACs and systems defence boats through, while massive industrialized worlds would have access to a gate capable of transiting capital ships in the hundreds of thousands of tons.

Fortunately, the Achuultani Empire has decayed into decadence, bureaucratic incompetence, and technology has become a much coveted commodity, technological knowledge being hoarded by the Core Worlds, keeping it away from the outer colonies, and only using it sparingly. This in turn has severely weakened it’s response to an emerging threat, such as an interstellar Empire.

When the first reports from outposts and colonies come in of contact with space-faring aliens, it can take months, years, in some cases even decades for the report to make it’s way in the incomprehensible labyrinth that is the Achuultani bureaucracy. Most of the time those reports are read and acted upon long after the outpost in question has been reduced to radioactive ash by saturation orbital bombardment. Initially the only response will be a few scout ships, with orders to attack all vessels that they encounter, and assess the threat. Most of the time the grand majority of these scouting expeditions do not come back, but usually a few do, giving coordinates of alien worlds and centers of population, setting the gears of the Achuultani war machine in motion.

After confirmed sightings of alien population centers (or too many lost scout ships) the Achuultani Bureau of Extermination will set in motion, and light patrols as well as expeditionary formations are sent out to dispatch the threat. Systems close to the aliens are slowly, but surely, reinforced, and basic defense stations and ground units are shipped out along the patrol detachements. Regular patrols are set up in the systems adjacent to Achuultani worlds. Meanwhile the expeditionary formations, usually composed of frigates and destroyers of a few thousand tons each at best, start aggressive reconnaissance efforts in systems where scout ships disappeared or found signs of alien life. Once there they will search the entire system from top to bottom, checking every single asteroid for life signs, and bombarding into oblivion any and all signs of active sentient life in the system with near automata single-mindedness, even unmanned installations being bombarded from high orbit without a second thought.

If the specie that encountered them is unlucky enough to not have a standing navy when encountering those first expeditions, they are at a very real risk of being wiped out. But most civilizations quickly dispatch those small expeditions, who will single mindedly attack even super-battleships head on, leading some civilizations to speculate that the first waves are little more than brain washed lunatics, although upon inspection of personnel further up the chain of command, it becomes obvious that it is simply that not exterminating all other sentient life is completely alien to the Achuultani, that fact having become so ingrained into their society that it is practically coded into their genome (and might actually be, in fact).

If the expeditionary forces fail to terminate the menace, the alert level is raised, and the Empire stirs as the Bureau of Extermination begins dispatching light cruiser aggressive reconnaissance formations and new expeditionary task forces sporting heavy cruisers ranging in the tens of thousands of tons with substantial amounts of lighter escorts. Those forces, while quite heavy in tonnage, are relatively low tech, sporting ion drives and equivalent technology, and are built more for extended deployment than combat. The fortification efforts at the frontier systems are accelerated, more stations (although still of the same pathetically technologically backward type as the previous wave) and troops are brought in, and expeditionary fleets are stationed in high orbit over every Achuultani population center while the number of patrols in the nearby systems is augmented (although only the frequency of the patrols increases, the ships remaining the same).

Should this fail as well the Bureau of Extermination will activate it’s own combat protocols, and deem the situation to start getting problematic. Battlecruisers and even more heavy cruisers are called up, as new waves of scout ships are sent, the expeditionary fleets become substantially deadlier and magneto-plasma drive level of technology starts appearing in the heavier starships and picket forces are placed at each jump point leading to an Achuultani systems, and minor fortifications are set up at the jump points. Overall the rate of patrols and aggressive reconnaissance raids increases as the expeditionary task forces remain on the same schedule, albeit significantly reinforced.

If the task forces remain unsuccessful, the matter is deemed critical, and the Bureau of Extermination steps down. For a few months, the raids slow down, then stops entirely as all Bureau forces withdraw, leaving only the fortifications, picket ships and orbital defence fleets untouched. And at long last, the Achuultani Fleet steps in.

Fortifications are quickly supplemented with much more capable stations, the grunts on the ground, that were until now holding their grounds with nothing more than simple body armor, assault riffles, a few autocanons and the odd STO, being joined by fleet marines, equipped with heavy armor, light to medium tanks, AA defences, a full complement of STOs and substantial artillery. The pickets are backed up with combat ready detachments and entire fleet task forces take up guard position in high orbit over Achuultani worlds.

Task Forces led by battlecruisers, supplemented with escort carriers carrying FACs and fighters, heavy cruisers and destroyers serving as escorts. Naval bases are established to resupply ships whose operational time and fuel reserves are significantly smaller than the one of their Bureau counterparts. Their technology is uniformly magneto-plasma drive level. Fleet Task Forces are significantly deadlier, boasting carrier capabilities, decent point defence with massed railguns and lasers, as well as much thicker armor and better shield generators.

Should those forces fail, the Achuultani Empire will stir once more, and rumble as the sleeping giant starts to wake up. Battleships ranging in the hundreds of thousands of tons are called up, lumbering behemots of incredible destructive power, joined by fleet carriers of equivalent tonnage, vast warfleets of ships being called up to support them. Massive fortresses are deployed to secure Achuultani worlds, and the Achuultani starts expanding, securing supply lines and establishing fleet bases and maintenance stations in key systems, with accompanying fleet marines detachment. Detachments and small picket forces are also stationed above each significant purified population center.

Were those massive fleets to falter, and be unable to finish their assignments, the Achuultani Empire will finally notice the tiny speck of dust calling itself an Empire defying it (or at least so they see it). The Fleet is reinforced by elements of the Achuultani Armada, vast super-battleships and siege carriers, as well as mobile motherships joining the attack fleets, technology improving substantially as patrols counting battlecruisers in their ranks starts deploying everywhere, waves of them attempting more reconnaissance and strikes on civilian shipping. Jump points are systematically fortified as space stations large enough to pass for large asteroids are towed in the orbit of Achuultani worlds, and new gates are assembled in controlled systems to increase the flow of ships and troops to the front lines. Imperial Marines, equipped with heavy tanks, extremely powerful STOs and scores of support systems are sent by the thousands to garrison systems. A vast invasion fleet is gathered, whose tonnage dwarves even moons, with millions of soldiers and dozens of capital ships accompanied with hundreds of escorts. And then, finally, the attack is launched.

Finally, it’s most capable warships shattered and it’s mightiest fleets now debris fields, the Achuultani Empire recoils. Horror dawns on them, and the giant wakes. Ancient data caches are unearthed, shielded worlds and massive fleet mothballs are opened. Cryogenic pods containing heroes of the Empire are thawed out, and warforges that have laid dormant for millions of years sputter back to life.

The Achuultani Empire is Awakened once more, and a new Great Crusade is declared.

A massive onslaught of warships is sent upon those who have defied the Achuultani, antimatter powered starships being sent to the frontlines by the dozens, sometimes the hundreds, and a long lost warship, a Nova class Super-Dreadnought, is reactivated. Crusaders detachments, genetically engineered super-soldiers clad in power armour, wielding weapons capable of vaporizing buildings, piloting super-heavy vehicles the size of skyscrappers and manning STOs capable of shredding even capital ships. A massive Invasion gate the size of a super-jovian is once more connected to the network, where the planet sized super-dreadnought stands watch over it like an immortal guardian. Nothing short of it’s annihilation capable of stemming the tide of death.

That is, until the Achuultani inevitably succomb to their greatest weakness.....themselves.



Crunch (The vague ideas in term of gameplay) :

Adds the Achuultani race.

An Achuultani colony can appear on an any planet with large quantities of oxygen, and will usually sport medium to low accessibility of very high quantities of multiple TN elements. Colonies can come in several sizes, which will determine the presence of the Achuultani in the system as well :

-Outpost : Only a Small Gate orbitting the planet and a couple of FACs, the population will be around 100 000, no industry.

-Colony : A Small Gate orbits the planet, with a squadron of FACs. Large amounts of mines and few CF. Population in the few millions.

-Rim World : A Small Gate orbits the planet, with several squadrons of FACs and a small amount of frigates and destroyers, large amounts of mines and a decent amount of CF, as well as 3 Civilian Mining colonies in the system. Population in the tens of millions.

-Civilized World : A Medium Gate orbits the planet, with several squadrons of frigates and destroyers, accompanied by a few cruisers. Fortresses already guard the planet’s orbit, albeit very low tech. Large amount of mines, a decent amount of CF, several financial centers, 3 to 10 Civilian Mining colonies in the system. Population in the hundred of million.

-Industrialized World : A Medium Gate orbits the planet, with squadrons of cruisers guarding the world. Fortresses supplemented by substantial ground forces are also in place, with small garrison in every extra-planetary settlements. Large mount of CF, decent amount of mines, lots of financial centers. Several satellite colonies of a few hundred thousands in population throughout the system. Population in the hundreds of millions.

-Member World : A Large Gate orbits the planet, with squadrons of battlecruisers, and perhaps a few capital ships, deployed in the system, backed up by large amounts of escorts. Fortresses are numerous and relatively advanced, and bolstered by a very large garrison, with detachments and additional stations scattered throughout the system. Incredible amount of CF, no mines, lots of financial centers, a few shipyards. Dozens of habitats and satellite colonies whose population totals in the tens of millions throughout the system. Population of the entire system around a billion.


Reinforcement Points :
The Achuultani do not build ships, instead, they get reinforcements through their gates, who are allocated based on the resources the system has. The more of CFs, mines, population and financial centers it has, the more Reinforcement Points (RP) it gets. Note that shipyards count for a lot in RP generation. This is for their systems however, has the waves function slightly differently.

Each RP is equivalent to a thousand tons of ship.

The waves essentially buy pre-made fleets and task forces, and direct them around. If a fleet or task force take losses, and manages to withdraw to a large enough gate, the AI then basically buys the ships it needs to refill the taskforce to it’s original strength, or close to it. All damaged ships are repaired at the gates, with a 1 month timer (to simulate ships being sent back to the shipyards while another is sent from the depths of the Empire, and all the bureaucratic shenanigans), and the AI can “recycle” fleets, refunding their RP cost by sending them through the portal, effectively deleting them, allowing for a recall of various task forces that are not doing the job, and trying a new strategy.

Similarly the defence budget is spent on fleets/task forces that are assigned at one of three posts : Picket, at which point it will either pick a jump point in the system without picket, preferably the one which leads to an NPR or player race, or reinforce the most lightly defended of the jump points.
Guard, where it will stand guard over the planet and (more importantly for the Empire) the gate.
Patrol, essentially meaning that they will randomly check either the adjacent systems, or even systems further down the jump chain periodically, essentially going to all the habitable bodies, the mineral rich ones(including sorium rich gas giants), and finally the jump points, in that order, before retreating back to base.
Or on stations, which can be either assigned to Jump point protection or the protection of the the Gate and the planet.


The Gates :

There are different types of gates, with different properties, as follow :

-Small Gate :
Maximum tonnage per ship able to transit : 3 000 tons.
Maximum total tonnage in a year : 90 000 tons.

-Medium Gate :
Maximum tonnage per ship able to transit : 90 000 tons.
Maximum total tonnage in a year : 700 000 tons.

-Large Gate :
Maximum tonnage per ship able to transit : 300 000 tons.
Maximum total tonnage in a year : 3 000 000 tons.

-Gargantuan Gate :
Note : Does not spawn, built by the Achuultani Fleet.
Maximum tonnage per ship able to transit : 600 000 tons.
Maximum total tonnage in a year : 9 000 000 tons.

-Invasion Gate :
Note : Has a 0.1% of spawning in any given system, replaces a super-jovian and has a Lagrange point. Only one per galaxy. If none have been discovered and the Great Crusade start, a system with one will be generated via a dormant jump point.
Maximum tonnage per ship able to transit : Infinite.
Maximum total tonnage in a year : Infinite.

All gates act as stations, that, if destroyed cease to function. The only exception is the Invasion Gate, who cannot be destroyed as it is a celestial body, destroying the orbiting Super-Dreadnought will shut it down though.



The waves :

Defence budget includes patrol and “home fleets” as well as static fortifications, it does not, however, include the innate defenses and resources of the system, who can reinforce their own militia according to their own capabilities.
There are several stages in the waves attack sent by the Achuultani, as follow :

-Unaware :
Attack waves annual budget : 0 RP
Defence annual budget : 0 RP
Tech level : Low.

Scouting Procedure :
Attack waves annual budget : 10 RP
Defence annual budget : 0 RP
Tech level : Low.

Expeditionary Units :
Attack waves annual budget : 30 RP
Defence annual budget : 10 RP
Tech level : Low.

Expeditonnary Task Forces :
Attack waves annual budget : 100 RP
Defence annual budget : 30 RP
Tech level : Low.

Expeditionnary Fleets :
Attack waves annual budget : 300 RP
Defence annual budget : 45 RP
Tech level : Low to Midline (larger ships are midline, the rest is low).

Achuultani Fleet Incursion :
Attack waves annual budget : 1 000 RP
Defence annual budget : 250 RP
Tech level : Midline

Achuultani Fleet Invasion :
Attack waves annual budget : 3 000 RP
Defence annual budget : 350 RP
Tech level : Midline to Midline+ (Battleships and Fleet Carriers being Magnetic Confinement Fusion Drive level, and the rest of the ships a more cospolitan mix of less advanced tech).

Achuultani Armada Intervention :
Attack waves annual budget : 10 000 RP
Defence annual budget : 3 000 RP
Tech level : High (first tier of antimatter).

Great Crusade :
Attack waves annual budget : 100 000 RP
Defence annual budget : 10 000 RP
Tech level : High.

Civil War :
Attack waves annual budget : 250 to 1 000 RP
Defence annual budget : 0 RP
Tech level : Low to Midline.

Note that the Great Crusade stops a few years after it’s inception, as the Achuultani Empire fall once more into civil war. The back of it’s war machine broken, they will withdraw all of their fleets and only send (or exile) warfleets of middling power compared to their once incomparable armadas. This is heavily inspired by the Great Khan mid-game crisis from Stellaris, where weathering the onslaught and holding on is an option as is going for the head of the problem (although you can surrender yourself to the Khan in Stellaris).

Now, all of those numbers are very much experimental, I do not have a big playing experience with Aurora, let alone the C# version (obviously), and I have no clue if this could even be implemented, it’s more of a proof of concept than anything :

TL;DR :
The Achuultani rely on a large number of low tech warships, and their main strength comes from sheer attrition, as they will keep sending waves after waves of starships until your empire is no more. Their technology might be easily reproducible (and complete rubbish at some points) but the point being that they should always be able to outproduce the player. They don’t have any form of tactics, except in the later waves, they just rush headlong into the enemy (they do have strategic planning though, and should try to alter fleet composition to counter the player’s according to their intelligence). They’re a mix between the AI in AI Wars from Arcen game and the Arachnid Omnivoracity, completely uncarring about their losses and having a virtually unlimited production capability, the only thing limiting them being the bureaucratic inertia and the decay and decadence of their own Empire.


Woo, okay, I’m done. Please be gentle with this, it’s just been one big brainstorm and I haven’t exactly been able to much refine it yet, but I felt like posting it to see what far more experience players are thinking would be a good idea. So, what are your thoughts ?
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on October 15, 2019, 04:50:01 PM
So it's a combination of Swarm and Invaders with minor differences here and there? While that isn't inherently a bad thing, my gut instinct is that any new spoiler should radically stand out from the existing spoilers.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on October 15, 2019, 05:34:00 PM
To which I would add that we already have both Invaders and the Arachnid Omnivoracity.  We have ever-increasing, ever-improving 'outside' forces that can't be counter-invaded, only endured or stoppered.  And we have suicidally-hostile, wipe-out-all-life, massively out-produce player empire(s) yet technologically slow/stagnant enemies.

Certainly, the 'implacable foe' and/or 'endless horde' is a staple of space opera, and has a place in Aurora.  But I agree that spoiler races need to be significantly different from not only what a player can do, but from each other.

Personally, I also think they should be a surprise.  That is why we spoiler them after all.  I wouldn't want to know all the mechanics behind them (as are laid out above).  There are more things in space (and Aurora) than are dreamt of in my empire's philosophy.

I am excited to discover organically the changes and additions Steve has made to the spoiler races, and if he wants to do something like The Forbidden is suggesting, hopefully he'll keep the details quiet until well after I've had my grubby little manipulators on C# Aurora for a while.

- - -

First, though, I want Steve to build the "bug button" he promised me:  http://aurora2.pentarch.org/index.php?topic=9841.msg110045#msg110045 (http://aurora2.pentarch.org/index.php?topic=9841.msg110045#msg110045)
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on October 15, 2019, 07:47:25 PM
I like the escalation mechanic and a spoiler that works that way would be interesting and superships are always fun but I feel that there's too much overlap between this and invaders.  The thought you out into is is evident, though.

Also locking tech levels isn't the best idea I'm my opinion, they should scale relative to the player to an extent because it's easy to get a curb stomp either way if it's fixed.
Title: Re: C# Aurora v0.x Suggestions
Post by: DIT_grue on October 16, 2019, 02:59:52 AM
It is straight up most efficient to give as many labs to as few scientists as possible and then exactly ONE lab to all the rest so they can train.

Even that is a compromise. There's nothing mechanically preventing you assigning a project, reducing the allocated labs to zero, then leaving the scientist in charge to improve their skill at the same odds as any other project leader. (I guess churning out paper studies and grant applications in a desperate scrabble to acquire the resources to actually get the job done is excellent practice and motivation?)
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on October 16, 2019, 12:16:31 PM
First, though, I want Steve to build the "bug button" he promised me:  http://aurora2.pentarch.org/index.php?topic=9841.msg110045#msg110045 (http://aurora2.pentarch.org/index.php?topic=9841.msg110045#msg110045)
Oh, I had completely forgotten that! Yes, 100% agreed, that would be really cool feature to have.
Title: Re: C# Aurora v0.x Suggestions
Post by: Stryker on October 23, 2019, 06:20:40 PM
Being God-Emperor of the universe is hard, especially when your underlings won't do what you want!  I was recently annoyed with them because after acquiring 500 points of ecm tech from a salvaged ship, I sent the salvage vessel to Mars (where my secret electronic warfare lab is) and told them to release the tech data.   However, despite being in Mars orbit, the fools sent the data to Earth.   Since I was already researching this on Mars, and had already done more than 500 points in research, the data was wasted.   A good flogging is in order. . . or maybe an order.

I recommend an order on the fleet management screen: Release tech data too (target world).   This would resolve this and the future crews of my salvage vessels (and their widows) would appreciate it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Shuul on October 24, 2019, 03:39:25 AM
I want to suggest to have an optional picture for your ship design.
So in design screen we can select png or jpg to represent ship design. Maybe it can be also shown in fleet screen or somewhere else.
It should be optional though, for me it will be much easier to imagine the ship I want.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on October 29, 2019, 04:46:03 AM
Ground Unit Auto-Improvement
------------------------------------

I would love it if, when I develop new armour and/or weapon tech, Aurora would immediately make copycat designs of all my ground units that used the old 'best' armour or weapon tech and replace it with the newly researched version.

So, upon me gaining Composite Armour Tech, Aurora would immediately copy my High Density Duranium Armour-using 'Mark I Fighting Tractor' design, and create a 'Mark I Fighting Tractor A' design using Composite Armour. . . or maybe a 'Mark I Fighting Tractor (CompArm)' design.  It's fine if Aurora doesn't know or can't match my empire's naming scheme -- as long as I can clearly identify the new design, I can rename it 'appropriately' myself.

Likewise with improved weapons tech.
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on October 29, 2019, 06:54:17 AM
That seems like a great way to flood any RP'd military with useless formations. If I'm running a fictional WW2 Britian in space, I don't want my unit lists flooding out with a bunch of different Bren gun units because I made a push for new tech to build the new fangled Hover Churchill tank designs. It could be a nice option, as long as it is exactly that, an option. Perhaps an auto-update box on the initial unit definition, or a game level setting.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on October 29, 2019, 09:10:29 AM
Works better if automatically generated designs get deleted if an improvement becomes available and none were build of the previous version.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on October 29, 2019, 06:44:06 PM
I'd say it would be about as good as auto updating ship designs, that is to say likely to annoy people more than actually help.  I'll phase in a next gen wave of combat gear when I am good and ready to.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on October 31, 2019, 07:08:54 PM
I suggest that you change ship based maintenance facilities so that the need population to run and as such would need 50k population in order to operate just like ground based maintenance facilities.

These ship based facilities might be a bit more expensive to build but the strategic benefit and the economic benefit in the long run (as they don't need population) to run will almost always outweigh the small initial cost benefit of building ground based maintenance facilities.

Since we can now have population anywhere in space I think that making this change will improve the logistical challenge of where you can maintain your ships in a positive way.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 01, 2019, 11:03:52 AM
Instead of forcing ship based facilities require population, it might be more sensible to make them require large numbers of personnel instead, or be more expensive like automated mines. Not just maintenance facilities; fuel harvesters and asteroid miners as well do jobs at the same production rates as ground side facilities, and have similar or smaller construction costs.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 01, 2019, 11:07:30 AM
I suggest that you change ship based maintenance facilities so that the need population to run and as such would need 50k population in order to operate just like ground based maintenance facilities.

These ship based facilities might be a bit more expensive to build but the strategic benefit and the economic benefit in the long run (as they don't need population) to run will almost always outweigh the small initial cost benefit of building ground based maintenance facilities.

Since we can now have population anywhere in space I think that making this change will improve the logistical challenge of where you can maintain your ships in a positive way.

Since Terraforming Modules / Facilities have the exact same issue -- and have had it for 15+ years -- I doubt that it will (or even should) change.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 01, 2019, 01:45:45 PM
I suggest that you change ship based maintenance facilities so that the need population to run and as such would need 50k population in order to operate just like ground based maintenance facilities.

These ship based facilities might be a bit more expensive to build but the strategic benefit and the economic benefit in the long run (as they don't need population) to run will almost always outweigh the small initial cost benefit of building ground based maintenance facilities.

Since we can now have population anywhere in space I think that making this change will improve the logistical challenge of where you can maintain your ships in a positive way.


Since Terraforming Modules / Facilities have the exact same issue -- and have had it for 15+ years -- I doubt that it will (or even should) change.

The problem have mostly been moving population to run them... I think that all should work the same or you simply make them allot more expensive like Automated mines are twice as costly as regular mines to make it a real decision.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on November 01, 2019, 04:54:51 PM
I personally think it would be pretty awesome if you had to build orbital habitat facilities into the mobile terraformers to meet their personnel requirements and keep them running.  Then you could have these truly massive vehicles you have to fly around in order to transform the atmospheres of entire worlds, which kindof makes sense to me personally.

Ostensibly you might even be able to go on the cheap and overpopulate them, so if its your style you can have cheaper orbital terraformers that have to have garrisons to keep the angry populations in check.

e: If that kind of operation were necessary to terraform a world, it would certainly make naturally habitable worlds a lot more valuable than they are now.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 01, 2019, 06:22:22 PM
I personally think it would be pretty awesome if you had to build orbital habitat facilities into the mobile terraformers to meet their personnel requirements and keep them running.  Then you could have these truly massive vehicles you have to fly around in order to transform the atmospheres of entire worlds, which kindof makes sense to me personally.

Ostensibly you might even be able to go on the cheap and overpopulate them, so if its your style you can have cheaper orbital terraformers that have to have garrisons to keep the angry populations in check.

e: If that kind of operation were necessary to terraform a world, it would certainly make naturally habitable worlds a lot more valuable than they are now.

This is also something I would support... it should take a considerable effort to terraform really inhospitable planets.

At least I think it would make a bit more sense and be fun at the same time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on November 02, 2019, 12:51:05 AM
Alternatively, restrict in some meaningful way the number of "conscripts" you can press into naval service. Right now you have an unlimited pool of perfectly functional merchant mariners. If the crew requirements for those modules were made actually meaningful, it would impose a real constraint. It could be as simple as having a separate pool of merchant mariners in addition to the naval crew pool, and refill the merchant mariner pool from various economic activities, such as spaceports, shipyards, civilian mining complexes, civilian trade goods deliveries, maintenance facilities, etc.

That way you would still have the distinction between expensive naval crews and cheaper civilian crews, but to get the cheaper civilian crews you would have to maintain an actual space-based civilian society, not just a planetside society with a space navy and barely populated industrial platforms in space.
Title: Re: C# Aurora v0.x Suggestions
Post by: jonw on November 02, 2019, 06:59:10 AM
I personally think it would be pretty awesome if you had to build orbital habitat facilities into the mobile terraformers to meet their personnel requirements and keep them running.  Then you could have these truly massive vehicles you have to fly around in order to transform the atmospheres of entire worlds, which kindof makes sense to me personally.

Ostensibly you might even be able to go on the cheap and overpopulate them, so if its your style you can have cheaper orbital terraformers that have to have garrisons to keep the angry populations in check.

e: If that kind of operation were necessary to terraform a world, it would certainly make naturally habitable worlds a lot more valuable than they are now.


This is also something I would support... it should take a considerable effort to terraform really inhospitable planets.

At least I think it would make a bit more sense and be fun at the same time.

I don't think habitat  modules make much sense - thats been specifically removed so that large orbital stations can be conviently build by planet industry, rather than shipyards. The orbital habitat module has been made cheaper, so you can still build orbitals if you want.

However, I've always thought thhere is a weird advantage over the ship terraforming modules rather than the planet modules. Planet terraforming modules require a very large amount of employees, but the ship terraforming modules have a minimal crew requirement. Transporting ground terraforming modules requires 125 000 cargo space, but building ship modules requires only like 100 crew and 25 000 hs. Consequently, I have never used planet terraforming modules and have always used ship terraforming modules, simply because it's easier to accumulate large numbers of them.

I'm not sure this is aproblem with the ship modules but rather than planet modules - if a ship terraforming installation can operate with 100 crew and much reduced physical volume, why does the planet module need to be so bulky and so population-intensive?
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 02, 2019, 07:13:14 AM
Alternatively, restrict in some meaningful way the number of "conscripts" you can press into naval service. Right now you have an unlimited pool of perfectly functional merchant mariners. If the crew requirements for those modules were made actually meaningful, it would impose a real constraint. It could be as simple as having a separate pool of merchant mariners in addition to the naval crew pool, and refill the merchant mariner pool from various economic activities, such as spaceports, shipyards, civilian mining complexes, civilian trade goods deliveries, maintenance facilities, etc.

That way you would still have the distinction between expensive naval crews and cheaper civilian crews, but to get the cheaper civilian crews you would have to maintain an actual space-based civilian society, not just a planetside society with a space navy and barely populated industrial platforms in space.

I have always been a proponent of commercial ships to have a maintenance cost in terms of wealth (say 1/10t of its production cost in wealth per year). This is a cost you would pay the same way you pay other types of facilities worked by populations. So it would just be a monthly cost no matter where the ships are and a simple way of putting some restriction on your commercial fleets. If you wanted to make it a bit more complicated then just apply the cost when the ships are in actual use.

I simply don't like the fact there are NO cost after you constructed them other than using fuel.

This way you don't have to deal with maintenance logistics for your commercial fleets but you will need to pay for their crews work and running maintenance performed by their crews.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 02, 2019, 07:22:32 AM
I personally think it would be pretty awesome if you had to build orbital habitat facilities into the mobile terraformers to meet their personnel requirements and keep them running.  Then you could have these truly massive vehicles you have to fly around in order to transform the atmospheres of entire worlds, which kindof makes sense to me personally.

Ostensibly you might even be able to go on the cheap and overpopulate them, so if its your style you can have cheaper orbital terraformers that have to have garrisons to keep the angry populations in check.

e: If that kind of operation were necessary to terraform a world, it would certainly make naturally habitable worlds a lot more valuable than they are now.

This is also something I would support... it should take a considerable effort to terraform really inhospitable planets.

At least I think it would make a bit more sense and be fun at the same time.

I don't think habitat  modules make much sense - thats been specifically removed so that large orbital stations can be conviently build by planet industry, rather than shipyards. The orbital habitat module has been made cheaper, so you can still build orbitals if you want.

However, I've always thought thhere is a weird advantage over the ship terraforming modules rather than the planet modules. Planet terraforming modules require a very large amount of employees, but the ship terraforming modules have a minimal crew requirement. Transporting ground terraforming modules requires 125 000 cargo space, but building ship modules requires only like 100 crew and 25 000 hs. Consequently, I have never used planet terraforming modules and have always used ship terraforming modules, simply because it's easier to accumulate large numbers of them.

I'm not sure this is aproblem with the ship modules but rather than planet modules - if a ship terraforming installation can operate with 100 crew and much reduced physical volume, why does the planet module need to be so bulky and so population-intensive?

But there is a problem here... requiring population to run terraforming installations is not completely irrational to implement as would it be for maintenance facilities. If they need population to run ON a planet they would need them in space to. If not you should be able to build automated ground based facilities too... it simply make little sense.

In my opinion the logistical compromises to require population is the more fun option... but you could also offer an automated solution for space but it needs to be allot more expensive, as in more expensive than using a habitat and a maintenance module, at least twice that price or something. Population can be a serious resource constraint eventually, often sooner rather than later.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 02, 2019, 09:43:36 AM

I have always been a proponent of commercial ships to have a maintenance cost in terms of wealth (say 1/10t of its production cost in wealth per year). This is a cost you would pay the same way you pay other types of facilities worked by populations. So it would just be a monthly cost no matter where the ships are and a simple way of putting some restriction on your commercial fleets. If you wanted to make it a bit more complicated then just apply the cost when the ships are in actual use.

I simply don't like the fact there are NO cost after you constructed them other than using fuel.

This way you don't have to deal with maintenance logistics for your commercial fleets but you will need to pay for their crews work and running maintenance performed by their crews.

No.  I think that's a terrible idea.

Wait, let me rephrase that.

Sure, absolutely. . .  as long as government-owned 'civilian' vessels like freighters and colony ships and fuel harvesters, etc., also generate wealth over time at least equal to the proposed cost.

What I simply don't like is the ridiculous wealth and infrastructure-generation of shipping lines, or the outright theft performed by CMCs.  The ridiculous profitability of the Earth-Luna run and the near-ubiquity of starting in Sol sytem distorts the 'wealth picture' of Aurora to the point where a game not using such exploits suffers.  Case in point, C#'s new wealth cap added to handle the 'conventional start to TNE conversion' massive boom-bust-echo swing is not only utterly unneeded in my games, but a huge handicap.  Why?  Because I build imperial freighters and colony ships, never build mass drivers, ship all my minerals (and most of everything else) by imperial freighter, ruthlessly claim every mining spot, never subsidise shipping lines, and most of all because I always start in a custom system and never with an easily habitable moon in orbit of my homeworld.  My empires never have enough wealth, and the only thing that stops a massive crash ten years into space is the cushion built up during converntioanl to TNE conversion.

Having broken my game with a system I don't like (the ridiculous amount of money generated by shippping lines), you now propose to double-punish my empire by (one) taking more of the wealth I never have enough of because I use imperial shipping instead of exploiting civiilians for (two) the express purpose of implementing imperial shippping costs.

- - - -

Here's my counter suggestion:  Remove all wealth generation from commercial shipping, and implement costs for moving government items in commercial hulls.  You want those Auto-Mines on Ithaca III?  Then do it yourself or pay someone else to do it for you.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 02, 2019, 09:55:35 AM
I personally think it would be pretty awesome if you had to build orbital habitat facilities into the mobile terraformers to meet their personnel requirements and keep them running.  Then you could have these truly massive vehicles you have to fly around in order to transform the atmospheres of entire worlds, which kindof makes sense to me personally.

Ostensibly you might even be able to go on the cheap and overpopulate them, so if its your style you can have cheaper orbital terraformers that have to have garrisons to keep the angry populations in check.

e: If that kind of operation were necessary to terraform a world, it would certainly make naturally habitable worlds a lot more valuable than they are now.

I think that would be pretty terrible.  My number one priority with terraforming modules would be to reduce the amount of workers required.  Risking fifty or one hundred thousand lives over a deadly planet seems insane.

Auto-Mines give us an excellent template.  I mentioned terraforming because it is the most egregious offender -- TF modules are better in every way than TF installations.  Even if the modules had twice the cost, twice the size, twice the worker requirement, and twice anything else we could think of they would STILL be the obvious choice, simply because TF installations can't be moved.

C# Aurora should absolutely rationalize all installation / unmanned installation / module options along a single system.  Extrapolate terraformers and fuel harvesters from the Mine / AutoMine / Asteroid Mining Module relationship.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 02, 2019, 10:23:08 AM
Alternatively, restrict in some meaningful way the number of "conscripts" you can press into naval service. Right now you have an unlimited pool of perfectly functional merchant mariners. If the crew requirements for those modules were made actually meaningful, it would impose a real constraint. It could be as simple as having a separate pool of merchant mariners in addition to the naval crew pool, and refill the merchant mariner pool from various economic activities, such as spaceports, shipyards, civilian mining complexes, civilian trade goods deliveries, maintenance facilities, etc.

That way you would still have the distinction between expensive naval crews and cheaper civilian crews, but to get the cheaper civilian crews you would have to maintain an actual space-based civilian society, not just a planetside society with a space navy and barely populated industrial platforms in space.

So you would like to literally limit my fun to some arbitrary number that you (or, I suppose, the community) consider appropriate.  We currently have a system that represents 'minimally trained' personnel and you want to cap it.

So my 'Age of Sail in space' campaign -- where it is a fundamental part of the fiction (history) that people are literally kidnapped off the street and imprisoned on the ships to crew them, where every reference (fiction and non-fiction alike) describes how these people need to be led by the hand to the line in question and told when to pull it -- this campaign is no longer possible because I'm not allowed to have enough untrained crew.

What about the ever-popular 'space vagabond' or 'Battlestar Galactica' campaigns, where the goal is for eveything the empire possesses to be mobile?  Mine the heck out of a system then move on, all while housing & working the population in as many orbital habitats as necessary, plus a thousand or so freighters to move the research labs & military academies & ground force training facilities and other non-space-based installations.  How exactly can they function if crew numbers are capped by the (non-existent) spaceports & CMCs?

Or a fungal, robotic, or insectoid hivemind (such as Rabid_Cog's Swarm) where absolutely every crewmember is a Conscript because that's what the ficiton calls for.  When the premise is literally every member of the race in question can adequately -- but not optimally -- perform the job of 'spacecraft crew'.

- - - -

If an empire wnats more trained crew, they should build more academies (and/or lower the racial training level).  If you think Conscripts at -10% efficiency are too powerful, feel free to lobby Steve for Planetlubbers at -20 or 25% efficiency. . .  or whatever other number(s) you find appropriate.  But please don't force my roleplaying to live by your ideas of what's appropriate.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 02, 2019, 10:33:33 AM
Research Labs vs Research Facilities
=======================

Currently, Research is performed by installations that are twenty times the size, twenty times the cost, and employ twenty times teh manpower of other installaions.  Most problematically, they produce ZERO effect if 95% complete.

Because of their increased size, they are generally moved from colony to colony in chunks of X twentieths.  Rare is the empire that builds superfreighters to carry 20 mines/automines/factories/etc. or one complete Research Facility.  And common (or so it seems) is the bug that causes some tiny fraction of a Research Facility to go missing, resulting in some SM shenanigans to sort it all out.

My suggestion is to add a new installation: the Research Lab.  The Research Lab would be the same size, cost, and worker requirement as one-twentieth of a Research Facility.  It would also produce one twentieth of the research points, and count as one-twentieth of the amount a Scientist could oversee.*

.

*Along with this change, I would also advocate to redefine the Scientist's admin rating in terms of the 1/20th size labs, rather than the larger Research Facilities.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 02, 2019, 10:56:01 AM
Fractional Installations
==============

Currently, 1.75 mines produce exactly the same output as 1 mine. . . or 1.01, or 1.99, etc.  As a result, any glitch that occurs in construction, movement (loading or unloading), or otherwise effectively causes an entire installation to disappear.  We also have the problem that some larger installations need a single LARGE cargo hold to move them, while others can be shipped piecemeal.

I would like to rationalize this system, and allow any portion of any installation (that can be moved) to be shipped in whatever amount of cargo points is appropriate, and allow partial installations to funciton at partial efficiency.

Yes, at its worst this means one three-quarters of a Research Facility could be on Earth, under the supervision of Reed Richards, and looking into visible light lasers while the other quarter is on Mars, under the supervision of Viktor von Doom, and looking into Ion Drive Engines.  I'm okay with that.

I think the benefit of having two-thirds of a factory still producing something is worth the cost of probably never realizing the other third was 'lost in space' due to a freighter hiccup.

It will also help with the situation where one freighter carying a piece of a large installation is lost to accident or enemy action.  Currently, Aurora is a royal pain to deal with when the Bugs blew up 3/20ths of a Research Facility and now you have to build 0.15 RF and ship it to the colony with other 85%.  In fact, it's enough of a pain that I usually just SM it in.

I would also like it if 'less than one' of an installation would still function at its reduced rate.  So 0.15 of a Military Academy turns out crew per production cycle at 0.15 of its annual rate.  (The computer can handle the math.)  This way I can have 'small academies' or 'casual mines' or 'cottage industry' by deliberately building fractions of installations.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 02, 2019, 11:11:36 AM

I have always been a proponent of commercial ships to have a maintenance cost in terms of wealth (say 1/10t of its production cost in wealth per year). This is a cost you would pay the same way you pay other types of facilities worked by populations. So it would just be a monthly cost no matter where the ships are and a simple way of putting some restriction on your commercial fleets. If you wanted to make it a bit more complicated then just apply the cost when the ships are in actual use.

I simply don't like the fact there are NO cost after you constructed them other than using fuel.

This way you don't have to deal with maintenance logistics for your commercial fleets but you will need to pay for their crews work and running maintenance performed by their crews.

No.  I think that's a terrible idea.

Wait, let me rephrase that.

Sure, absolutely. . .  as long as government-owned 'civilian' vessels like freighters and colony ships and fuel harvesters, etc., also generate wealth over time at least equal to the proposed cost.

What I simply don't like is the ridiculous wealth and infrastructure-generation of shipping lines, or the outright theft performed by CMCs.  The ridiculous profitability of the Earth-Luna run and the near-ubiquity of starting in Sol sytem distorts the 'wealth picture' of Aurora to the point where a game not using such exploits suffers.  Case in point, C#'s new wealth cap added to handle the 'conventional start to TNE conversion' massive boom-bust-echo swing is not only utterly unneeded in my games, but a huge handicap.  Why?  Because I build imperial freighters and colony ships, never build mass drivers, ship all my minerals (and most of everything else) by imperial freighter, ruthlessly claim every mining spot, never subsidise shipping lines, and most of all because I always start in a custom system and never with an easily habitable moon in orbit of my homeworld.  My empires never have enough wealth, and the only thing that stops a massive crash ten years into space is the cushion built up during converntioanl to TNE conversion.

Having broken my game with a system I don't like (the ridiculous amount of money generated by shippping lines), you now propose to double-punish my empire by (one) taking more of the wealth I never have enough of because I use imperial shipping instead of exploiting civiilians for (two) the express purpose of implementing imperial shippping costs.

- - - -

Here's my counter suggestion:  Remove all wealth generation from commercial shipping, and implement costs for moving government items in commercial hulls.  You want those Auto-Mines on Ithaca III?  Then do it yourself or pay someone else to do it for you.

To be honest I don't think that one specific style of play is a good argument for this rather than "fixing" general game balance in regards to civilian trade etc...

Trade in C# have changed so trading in the same system are not as profitable as it once was, so there are some measures of fixing done to that.

There actually is a real issue with being able to build and use something which have no related cost to it... I don't think the cost should be enormous... just enough so you can't spam a commercial fleet and stations without ANY support cost. I don't think that freighters or fuel ships will be very expensive... I would rather target things like terraforming stations, habitats and maintenance facilities that require no population to actually have a cost.

You also would need to pay the merchant marine and do some rudimentary maintenance on ships and neither can be free.

The exact cost would be about balance.
Title: Re: C# Aurora v0.x Suggestions
Post by: jonw on November 02, 2019, 11:15:00 AM
...My number one priority with terraforming modules would be to reduce the amount of workers required.
...TF modules are better in every way than TF installations.  Even if the modules had twice the cost, twice the size, twice the worker requirement, and twice anything else we could think of they would STILL be the obvious choice, simply because TF installations can't be moved.

Agreed
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 02, 2019, 11:16:52 AM
I personally think it would be pretty awesome if you had to build orbital habitat facilities into the mobile terraformers to meet their personnel requirements and keep them running.  Then you could have these truly massive vehicles you have to fly around in order to transform the atmospheres of entire worlds, which kindof makes sense to me personally.

Ostensibly you might even be able to go on the cheap and overpopulate them, so if its your style you can have cheaper orbital terraformers that have to have garrisons to keep the angry populations in check.

e: If that kind of operation were necessary to terraform a world, it would certainly make naturally habitable worlds a lot more valuable than they are now.


I think that would be pretty terrible.  My number one priority with terraforming modules would be to reduce the amount of workers required.  Risking fifty or one hundred thousand lives over a deadly planet seems insane.

Auto-Mines give us an excellent template.  I mentioned terraforming because it is the most egregious offender -- TF modules are better in every way than TF installations.  Even if the modules had twice the cost, twice the size, twice the worker requirement, and twice anything else we could think of they would STILL be the obvious choice, simply because TF installations can't be moved.

C# Aurora should absolutely rationalize all installation / unmanned installation / module options along a single system.  Extrapolate terraformers and fuel harvesters from the Mine / AutoMine / Asteroid Mining Module relationship.

Given that ground based terraforming installation will require 250.000 people in C# why would ANYONE build them and NOT terraforming stations in space (as you pointed out)?

I wonder where the choice in this equation actually lies unless the space based ones are extremely more expensive to build.

So what should be done to "fix" the situation... scrap ground based installations?!?
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 02, 2019, 12:12:39 PM

There actually is a real issue with being able to build and use something which have no related cost to it... I don't think the cost should be enormous... just enough so you can't spam a commercial fleet and stations without ANY support cost. I don't think that freighters or fuel ships will be very expensive... I would rather target things like terraforming stations, habitats and maintenance facilities that require no population to actually have a cost.

You also would need to pay the merchant marine and do some rudimentary maintenance on ships and neither can be free.

The exact cost would be about balance.

Okay, but you're defining imperial wealth generation as 'every centicredit collected' and then complaining that salaries and supplies aren't accounted for, and I'm defining wealth as what the government has left over after paying for all thise things.  Neither one of us is more right than the other.

In your view, the merchant marine & space 'infrastructure' is a net drain on imperial coffers, and therefore should cost increasing wealth as it expands.

I counter that those things can be a net gain for "the economy", and that the wealth Aurora shows us is profit after paying for those things you are complaining aren't being paid for.  I say that Aurora is simply not line-item listing that it's paying for them.

- - - -

But really, your point seems to be "you can't spam a commercial fleet and stations without ANY support cost."  And whether -- or to what extent -- that is true I say depends on the empire's overall financial situation.  Which means it should be debated alongside that overall financial situation.  Your point (as I understand it) is essentially "Aurora empires have too much wealth; here's how I would reduce it."  My point is "Aurora empires only have 'too much wealth' due to exploiting commercial shippping.  If epires don't do that, they in fact do not have enough wealth."

You're right, I can't spam a commercial fleet, as hard as I try, because I can't afford it without the large wealth boost of exploiting commercial shippping lines.

- - - -

To ruthlessly summarize all of the recent posts, I think it is a fundamental part of Aurora's DNA to present the player with the choice of the cheap, worker intensive installation (e.g. Mine); the expensive, low- (or no-) manpower version (e.g. AutoMine); and the restricted (perhaps less efficient) ship-mounted module (e.g. Asteroid Miner) that has the benefit of high mobility.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 02, 2019, 01:43:36 PM
The balance of many economic aspects of the game is changing for C#. Wealth is harder to create, manpower constraints are much greater, especially for shipyards, terraforming is more time-consuming, maintenance is more 'expensive' in terms of number of installations, orbital mining is based on diameter rather than asteroid classification, etc.. You can no longer subsidise civilian shipping or shut down entire industry sectors or use construction factories to create maintenance supplies.

I have already been adjusting things as I go and it will take a while before that balance starts to shake out. For example, with the new space station rules I thought I would be using construction factories to build space stations, but I've found I needed them for maintenance facilities and financial centres. I would like to expand shipyards to build more commercial vessels but available population has proven to be a significant issue, etc..

There probably is some balancing to be done with ground vs space, but I need to see how everything else works out first, including the fact that installations are likely to be a lot safer on the ground in C# vs VB6.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on November 02, 2019, 07:11:14 PM
I feel like for the most part my terraforming post was met with a resounding 'i dont want terraforming to be that difficult', which is like okay I guess.  It was just an idea.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on November 02, 2019, 08:20:46 PM
I use TF facilities. If you do a conventional start with a big population, in the early game, it's faster and easier to build and move couple a dozen TF facilities to Mars. Then I, later on, move them to Colony Cost 2.0 planets while I save my TF ships for more challenging targets.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on November 03, 2019, 01:29:08 AM
I guess another thing is they might make a lot more sense if you had worlds that needed a degree of constant upkeep to keep them terraformed.  For instance, small moons leaking an atmosphere, or some very hostile world constantly releasing toxic gases and/or burning up all of the oxygen.  (maybe burning the oxygen into oxygen difluoride)

This would be very much a long term suggestion, but it might be cool to add as a sortof thing where you would have a large roving fleet of terraformer ships, and then be building/setting up smaller numbers of terraformer installations to keep the planet in good condition without having to go to all of the maintenance trouble.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 03, 2019, 02:32:11 PM

There actually is a real issue with being able to build and use something which have no related cost to it... I don't think the cost should be enormous... just enough so you can't spam a commercial fleet and stations without ANY support cost. I don't think that freighters or fuel ships will be very expensive... I would rather target things like terraforming stations, habitats and maintenance facilities that require no population to actually have a cost.

You also would need to pay the merchant marine and do some rudimentary maintenance on ships and neither can be free.

The exact cost would be about balance.

Okay, but you're defining imperial wealth generation as 'every centicredit collected' and then complaining that salaries and supplies aren't accounted for, and I'm defining wealth as what the government has left over after paying for all thise things.  Neither one of us is more right than the other.

In your view, the merchant marine & space 'infrastructure' is a net drain on imperial coffers, and therefore should cost increasing wealth as it expands.

I counter that those things can be a net gain for "the economy", and that the wealth Aurora shows us is profit after paying for those things you are complaining aren't being paid for.  I say that Aurora is simply not line-item listing that it's paying for them.

- - - -

But really, your point seems to be "you can't spam a commercial fleet and stations without ANY support cost."  And whether -- or to what extent -- that is true I say depends on the empire's overall financial situation.  Which means it should be debated alongside that overall financial situation.  Your point (as I understand it) is essentially "Aurora empires have too much wealth; here's how I would reduce it."  My point is "Aurora empires only have 'too much wealth' due to exploiting commercial shippping.  If epires don't do that, they in fact do not have enough wealth."

You're right, I can't spam a commercial fleet, as hard as I try, because I can't afford it without the large wealth boost of exploiting commercial shippping lines.

- - - -

To ruthlessly summarize all of the recent posts, I think it is a fundamental part of Aurora's DNA to present the player with the choice of the cheap, worker intensive installation (e.g. Mine); the expensive, low- (or no-) manpower version (e.g. AutoMine); and the restricted (perhaps less efficient) ship-mounted module (e.g. Asteroid Miner) that has the benefit of high mobility.

I always changed the tolerance levels for human colonisation in Aurora to 0.7-1.3 as that are probably more realistic (although high gravity are way more dangerous), anything else would need some gene modification. In addition to this I always removed allot of the initial wealth with SM in conventional starts. So I'm not that well versed in exploiting the moon or mars... I always also restricted the subsidisation of civilian fleets as I felt it could be a bit ridiculous, especially in a conventional start where you swim in wealth without restrictions on yourself.

So... wealth have always been an issue to monitor in all of my games so far so I'm not approaching this from the perspective of exploiting the civilian trade. Just to be clear...  ;)

I probably don't' agree that it is a zero sum game to run the commercial ships for the same reason you need to pay for civilian ships to move things and operate for you instead of generating wealth moving trade goods. If you could use your commercial ships to move trade goods then I would not argue this, but you can't... might be an interesting thing you could do. There could be a "state" company and if you assign freighters or colony ships they would operate as civilian ships but you built them. You could then take them of this duty and control them directly but you still have to pay for any trips they take in some wealth as well as paying for the fuel when you want to make more controlled missions. While part of the "state" company the state could actually earn wealth with them as all the income goes directly to the state.

In my opinion state controlled freighters should be more expensive to use long term, but there also are strategical benefits of using them.

I also fail to see how a supply or ammunition ship part of a fleet is an economical zero sum game type of ship, they should be nothing but a drain on resources other than build cost and fuel. A small wealth cost would be fine and really easy to implement.

I do agree with Steve that it should not be done without testing and balancing, I would never suggest that. I clearly stated it needed to be tested and balanced first. As Steve already changed allot of the the economic underpinning foundations I would be fine if this was considered at a later date.
Title: Re: C# Aurora v0.x Suggestions
Post by: MultiVitamin on November 05, 2019, 05:31:42 AM
So while reading through the Crusade campaign and seeing the ground forces Steve designed, it just occurred to me. Would it be possible to, once a unit is designed, be able to rename the components that that unit has? It's purely aesthetic and helps with the immersion, but I figured I'd like to see "Heavy Bolter" rather then "Crew-Served Anti-Personnel" when looking at my space marine. Again, it's purely aesthetic and immersion, but I think it could help a player get into immersing themselves a bit more seeing their Leman Russ tanks have "Battle Cannon" rather then "Heavy Anti-Vehicle".
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 05, 2019, 05:34:51 AM
So while reading through the Crusade campaign and seeing the ground forces Steve designed, it just occurred to me. Would it be possible to, once a unit is designed, be able to rename the components that that unit has? It's purely aesthetic and helps with the immersion, but I figured I'd like to see "Heavy Bolter" rather then "Crew-Served Anti-Personnel" when looking at my space marine. Again, it's purely aesthetic and immersion, but I think it could help a player get into immersing themselves a bit more seeing their Leman Russ tanks have "Battle Cannon" rather then "Heavy Anti-Vehicle".

Yes, that wouldn't be hard to do. I'll add it to the list :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 05, 2019, 10:39:08 AM
I guess another thing is they might make a lot more sense if you had worlds that needed a degree of constant upkeep to keep them terraformed.  For instance, small moons leaking an atmosphere, or some very hostile world constantly releasing toxic gases and/or burning up all of the oxygen.  (maybe burning the oxygen into oxygen difluoride)

This would be very much a long term suggestion, but it might be cool to add as a sortof thing where you would have a large roving fleet of terraformer ships, and then be building/setting up smaller numbers of terraformer installations to keep the planet in good condition without having to go to all of the maintenance trouble.

Okay, but if I have a colony that loses X atm per year, why would I do anything other than build/move/assign enough terraforming installations/modules there to produce equal-to-or-greater-than X atm?

If terraforming has an upkeep cost, the only rational thing to do is assign enough resources to cover the upkeep, and then ignore it forever.  I fail to see where the decision-making, and therefore the fun, is in that scenario.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on November 05, 2019, 12:02:37 PM
Because certain worlds would require more resources allocated before you got them to a point of equilibrium, which would have a flat continuous cost in workers and wealth upkeep that other worlds wouldnt suffer from, and if someone bombed your terraforming installations the world might start dying fairly quickly.  During peacetime the difference might be relatively small, but during bad situations that makes them fairly different from worlds that require no upkeep whatsoever.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 05, 2019, 12:24:13 PM
Okay, but how is that different from Infrastructure?

Flat continuous cost in workers (and therefore reduced wealth generation) -- check.  (Due to the increased Ag & Env sector.)
Other colonies don't (necessarily) suffer the same cost -- check.
Orbital bombardment and/or ground combat can destroy it -- check.

Other than the fact that your Terraforming upkeep might be in space rather than on the ground, I don't see a differenace.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on November 05, 2019, 01:37:34 PM
Well, its not proportional to population for one thing.  It would cost the exact same amount to keep a world terraformed no matter how many people live there.

e:  It would also most likely be much cheaper for a large colony as compared to infrastructure costs, whereas a smaller one would probably be better off just using infrastructure.
Title: Re: C# Aurora v0.x Suggestions
Post by: Coleslaw on November 07, 2019, 01:16:58 AM
Will there be any changes to how troops can be attached to ships (i. e.  for protection in the event of a Tyranid boarding action :^) ) as compared to Aurora as is? Would troops be attachable based on Spare Berths or will there need to be a dedicated "barracks" component, and will it come in varying sizes? If so, how many and of what capacity? Can ships be designated to have a specific attachment of shipboard troops that are automatically "built" alongside the ship?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 07, 2019, 03:15:54 AM
Will there be any changes to how troops can be attached to ships (i. e.  for protection in the event of a Tyranid boarding action :^) ) as compared to Aurora as is? Would troops be attachable based on Spare Berths or will there need to be a dedicated "barracks" component, and will it come in varying sizes? If so, how many and of what capacity? Can ships be designated to have a specific attachment of shipboard troops that are automatically "built" alongside the ship?

There are various sizes of troop transport bays. I'm not at home at the moment but I think they start at 100 tons. There is no facility to auto-build troops as part of the ship construction.
Title: Re: C# Aurora v0.x Suggestions
Post by: MultiVitamin on November 07, 2019, 05:09:39 AM
Will there be any changes to how troops can be attached to ships (i. e.  for protection in the event of a Tyranid boarding action :^) ) as compared to Aurora as is? Would troops be attachable based on Spare Berths or will there need to be a dedicated "barracks" component, and will it come in varying sizes? If so, how many and of what capacity? Can ships be designated to have a specific attachment of shipboard troops that are automatically "built" alongside the ship?

There are various sizes of troop transport bays. I'm not at home at the moment but I think they start at 100 tons. There is no facility to auto-build troops as part of the ship construction.

I'm typically not one to do any mathematics but I like to get exact numbers of troops to help paint a better image in my head. So I did some random math and 100 tons troop transport is enough for 1460 troops (rounded up) (when you use the Average Human Weight as 137 lbs).

This also means that Fighters as Transports can hold up to 5480 troops if 400 tons of it is dedicated to 100 ton troop transports.


Hope you all enjoyed my random math moment  :P
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on November 07, 2019, 05:25:51 AM
I'm typically not one to do any mathematics but I like to get exact numbers of troops to help paint a better image in my head. So I did some random math and 100 tons troop transport is enough for 1460 troops (rounded up) (when you use the Average Human Weight as 137 lbs).

This also means that Fighters as Transports can hold up to 5480 troops if 400 tons of it is dedicated to 100 ton troop transports.


Hope you all enjoyed my random math moment  :P

You really would send trained troops on a spaceship without clothing, armor, weapons, food, equipment... etcpp?  ;D

it is more like 5t per soldier so 100t = 20 marines +/-
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 07, 2019, 07:05:45 AM
Given that the 3 tons requirement for Light Personal Weapons also includes things like all the equipment necessary to not die instantly in vacuum, a high pressure environment, freeze to death in a pool of liquid nitrogen or burn the instant you get close to a lava planet all at the same time, I would be okay with the concept of a unit/component type/modifier that's exclusive to infantry that literally can't fight in environments that aren't in the species' 0 colonization cost tolerance for a lower cost.

That'd basically be your boarding defense parties. Don't try to send them into enemy ships and expect to get a happy ending, especially if their species has very different tolerances.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 07, 2019, 12:43:47 PM
I wouldn't, because my 'given' is that those 3 tons also include food & water for several combat cycles, cleaning & maintenance kits for weapons, spare batteries for all their equipment, footlockers, duffel bags, extra clothes, and eveything else a soldier needs to be effective.

In short, the "infantry that literally can't fight in environments that aren't in the species' 0 colonization cost tolerance" should die instantly in boarding combat, because the darkness, explosive decompression, hard vacuum, and other aspects of the "boarding combat environment" make it decidely not a zero colony cost situation.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on November 07, 2019, 03:08:20 PM
It would certainly make sense for planetary garrisons though.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 07, 2019, 04:08:37 PM
I don't think it would.  I think the rule is 3 tons for Personal Weapon (Light) Infantry, and 5 tons for Personal Weapon Infantry.  PW INF is already the baseline from which all other ground forces were developed.  They have no special training, no special defenses, and -- until we added Personal Weapon (Light) Infantry -- no 'lesser version'.

Now you want another lesser version of the lesser version of combatant we already have.  You think Military Police are too powerful because they might -- might -- have a submachinegun?

Or are you hung up on the idea that it takes 3 tons' displacement to feed, care for, and maintain one of them?  That each troop's share of the group showers, mess facilities, machine shops, training rooms, armoury, etc., should be less than that, or should be counted in the 'headquarters' or 'supply' unit type?

- - - -

Right now, the combat difference between one PWL INF and one Crewmember is a 50% penalty to the armour of the crewmember.  I tried to look up the size of a 100-ton cap troop transport bay and a Crew Quarters in C# Aurora to compare how many of each you could get per hull space, but I couldn't find the mechanics.  I still think that what you're asking for is wildly out of line with the established C# mechanics.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on November 07, 2019, 04:29:23 PM
I imagine that security troops on a ship carry kit like emergency air supplies as a replacement for how troops on a frontier world probably carrying things like wilderness survival gear. And it's probably fairly easy to swap those out if a unit is moved from one to another. There's such a thing as making things too granular, especially for a high level strategy game.

For specialized units we already have the special training options.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bughunter on November 08, 2019, 02:38:32 AM
Regarding Steves latest AAR update I had a thought about the spoilers.

I was surprised the swarm/tyranids didn't eat the defenseless colonists, I think any self-respecting breed of horrible space monster should have that in their work description.

Also if they took some time going about it that might provide opportunity for rescue missions including a ground assault, stuff that makes great AAR material.
Title: Re: C# Aurora v0.x Suggestions
Post by: MultiVitamin on November 08, 2019, 03:43:42 AM
Regarding Steves latest AAR update I had a thought about the spoilers.

I was surprised the swarm/tyranids didn't eat the defenseless colonists, I think any self-respecting breed of horrible space monster should have that in their work description.

Also if they took some time going about it that might provide opportunity for rescue missions including a ground assault, stuff that makes great AAR material.


Given that this campaign is to mostly test Ground Combat, and that Steve did allude to spoilers having their own Ground units, I think something is in the works for that already.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on November 08, 2019, 12:22:18 PM
Regarding Steves latest AAR update I had a thought about the spoilers.

I was surprised the swarm/tyranids didn't eat the defenseless colonists, I think any self-respecting breed of horrible space monster should have that in their work description.

Also if they took some time going about it that might provide opportunity for rescue missions including a ground assault, stuff that makes great AAR material.


Well, remember, in the AAR they're the Tyranids, who would definitely eat all the colonests, but in game they're the Star Swarm. They probably only care about TNEs. Also the colonists slowly dying without infrastructure does provide a need to launch a rescue mission.
Title: Re: C# Aurora v0.x Suggestions
Post by: Stryker on November 08, 2019, 02:10:38 PM
Would it be possible on the assign systems to sector screen to include the total population for the selected sector?  Additionally, a total empire population entry would be nice.

Alternatively, or in addition to, the option to sort by sector on the population and production screen with this information would also be useful.
Title: Re: C# Aurora v0.x Suggestions
Post by: MultiVitamin on November 08, 2019, 08:48:32 PM
Actually, would it be possible to make research trees for the Ground Force components? Just generic ones to increase their effectiveness, number of shots, etc? Or maybe make it so that we can design them?

So for example there'd be a few fields

Type - Anti-Personnel, Anti-Vehicle, Bombardment, Anti-Aircraft, Autocannon, or HQ (CE would stay the same)

Size - (Light, Medium, Heavy, Super-Heavy, Ultra-Heavy)

AP - (Dropdown menu from 1 to 50)

Damage - (Dropdown menu from 1 to 60)

Shots - (Dropdown menu from 1 to 6)

CIWS - (Can be blank, choose from pre-made CIWS made for ships, just resized maybe?)

FFD - (Dropdown menu from 1 to 3)


And various research could upgrade the ranges of these higher and higher. Just a suggestion I thought of while anticipating the renaming of components when a unit is designed, thought of "why not just build the components with research to make them better, and have that be designable?". It adds a lot more variety and player decision making for Ground Forces, like when you design the weapons, powerplants, defense, engines, etc for ships, just not as intense. Also helps solve the "Can't think of anything for Ultra-Heavy" problem you mention about having a while ago in (I think) a different thread.

If no on the designing the components themselves, what about just research to improve components?
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on November 09, 2019, 02:57:35 AM
Quote
Given that the 3 tons requirement for Light Personal Weapons also includes things like all the equipment necessary to not die instantly in vacuum, a high pressure environment, freeze to death in a pool of liquid nitrogen or burn the instant you get close to a lava planet all at the same time, I would be okay with the concept of a unit/component type/modifier that's exclusive to infantry that literally can't fight in environments that aren't in the species' 0 colonization cost tolerance for a lower cost.

That'd basically be your boarding defense parties. Don't try to send them into enemy ships and expect to get a happy ending, especially if their species has very different tolerances

~Hazard

Quote
I don't think it would.  I think the rule is 3 tons for Personal Weapon (Light) Infantry, and 5 tons for Personal Weapon Infantry.  PW INF is already the baseline from which all other ground forces were developed.  They have no special training, no special defenses, and -- until we added Personal Weapon (Light) Infantry -- no 'lesser version'.

Now you want another lesser version of the lesser version of combatant we already have.  You think Military Police are too powerful because they might -- might -- have a submachinegun?

Or are you hung up on the idea that it takes 3 tons' displacement to feed, care for, and maintain one of them?  That each troop's share of the group showers, mess facilities, machine shops, training rooms, armoury, etc., should be less than that, or should be counted in the 'headquarters' or 'supply' unit type?

~Father Tim

 --- What about a 1 Ton kit for Garrison / Security Forces? With the caveat that they require external support or else suffer damage? That support could be in the form of Logistics Units, Colonies with a great than 'X' population, Colonies with a equal to or greater than  'X' population but only if the planet has a greater than 'X' Colony Suitability Cost, and being on board a ship with Troop Transport capabilities? A 1.5 Ton kit would be also be nice as a 'heavy' option, for those empires that would splurge on 'Elite' bodyguards or for officers or something like that.

 --- I rather like the idea of 'cheap' defense units; that are dedicated to defense, mind you. Such units wouldn't NEED the overhead of attacking forces because they could have everything "right at home" so to speak. Likewise, security forces for Logistics Bases, Forward HQs, or Artillery Detachments (an admittedly weird proposition, but IRL countries make weird choices all the time so... yeah). These forces would be cheap for the sake of peacetime or cheap for the sake of their rear guard status. They really should have low stats, though.

 --- Garrisons could have defense equal to light infantry, but have attack that was only half of it. Security units could have defenses equal to half of light infantry, with a quarter of that attack, but be even cheaper to produce than a garrison. Security and Garrison should just be 1 Ton however, to represent the absolute bare minimum, but Security would just have cheaper stuff to reflect their more 'Specialized' role. The 1.5 ton 'heavy' versions would be better and more expensive of course.

 --- Another interesting idea would be dedicated Marine Garrisons for space stations, ships w/ Troop Transport abilities and such. Same idea, with the 1 Ton kit and maybe the 1.5 ton 'heavy' kit, and the same with the caveat that they require dedicated logistics support from their ships, space stations, colonies or whatever. Not sure WHY you would put Marines on a colony, but then again I do like building colonies on airless hell holes... so yeah, there's that. (sooper sekrit soviet spess koloni for built stronk tenk) Still, while Marines would mostly be a bad choice to defend a colony, they could still be support just like any troops.

Just some thoughts, cheers! ;D
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on November 09, 2019, 03:06:56 AM
I protest the lack of civillian shipping subsidies! I wanna be a space commie dammit all! Subsidize EVERYTHING!

Now that I've gotten that out of my system, I had some thoughts on what could be done moving forward. And thought I might share them here.

 --- It's been mentioned about piracy and such before, but I did think of something I'd like along the lines of that. Militia forces. Militia ships, Militia navy, militia ground troops. ALL THE MILITIAS!

 --- I think privateering is a cool avenue to explore as well, alongside private security firms, and mercenary units / bounty hunter groups. These could be like Commercial Mining Colonies in that you need a certain amount of "growth" before they can exist. Not just wealth, but also weapons and ships, to represent not just the economic growth to sustain it but also the technological growth as well. Military units typically have the top shelf guns, while civilians would have (if any... I'm American so this is far more normal to me.) the 'civilian version' or the military's old surplus sold to them. Would be a nice organic thing to add some depth to the game, but I'm very much for it being a check box option to toggle on and off. Same with Militias, doing something akin to The Expanse would be better served by disabling the functionality so NPRs don't have it... or do. Maybe separate parameters and a random gen option? Meh, I don't jack about programming, but that sounds like a lot of work.

 --- Still, tanks for all the great work Steve, hope these ideas can be of some use.

Cheers!  ;D
Title: Re: C# Aurora v0.x Suggestions
Post by: arty on November 09, 2019, 04:29:45 AM
If possible a Ship Mass driver Module would be grat :) make mining ships so much easyer to handle  ;D

and if the industrie build space stations could get civilian engines than you dont have to refit them ?!
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 09, 2019, 11:29:56 AM
Arty, it's a good thing that industry build space stations can't get engines. It'd break the game because now shipyards no longer matter except possibly for repairs and refits of ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 09, 2019, 01:11:14 PM
--- What about a 1 Ton kit for Garrison / Security Forces? With the caveat that they require external support or else suffer damage? That support could be in the form of Logistics Units, Colonies with a great than 'X' population, Colonies with a equal to or greater than  'X' population but only if the planet has a greater than 'X' Colony Suitability Cost, and being on board a ship with Troop Transport capabilities? A 1.5 Ton kit would be also be nice as a 'heavy' option, for those empires that would splurge on 'Elite' bodyguards or for officers or something like that.

 --- I rather like the idea of 'cheap' defense units; that are dedicated to defense, mind you. Such units wouldn't NEED the overhead of attacking forces because they could have everything "right at home" so to speak. Likewise, security forces for Logistics Bases, Forward HQs, or Artillery Detachments (an admittedly weird proposition, but IRL countries make weird choices all the time so... yeah). These forces would be cheap for the sake of peacetime or cheap for the sake of their rear guard status. They really should have low stats, though.

 --- Garrisons could have defense equal to light infantry, but have attack that was only half of it. Security units could have defenses equal to half of light infantry, with a quarter of that attack, but be even cheaper to produce than a garrison. Security and Garrison should just be 1 Ton however, to represent the absolute bare minimum, but Security would just have cheaper stuff to reflect their more 'Specialized' role. The 1.5 ton 'heavy' versions would be better and more expensive of course.

 --- Another interesting idea would be dedicated Marine Garrisons for space stations, ships w/ Troop Transport abilities and such. Same idea, with the 1 Ton kit and maybe the 1.5 ton 'heavy' kit, and the same with the caveat that they require dedicated logistics support from their ships, space stations, colonies or whatever. Not sure WHY you would put Marines on a colony, but then again I do like building colonies on airless hell holes... so yeah, there's that. (sooper sekrit soviet spess koloni for built stronk tenk) Still, while Marines would mostly be a bad choice to defend a colony, they could still be support just like any troops.

Just some thoughts, cheers! ;D

Okay, but now you have the situation where a guy whose job is supposed to be fighting is worse at it than a guy whose job is cleaning the gunk out of the soup nozzles.

What we've seen so far from Steve's AARs (admittedly quite a small sample size) is that dedicated boarding troops tear through defending crew at a ratio of 80 or 100 to 1.  If we make defenders any weaker, they are going to inflict zero casualties.  We're already at the point where 90% of attacker's casualties are from the drop attempt rather than fighting on board.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 09, 2019, 01:23:13 PM
If possible a Ship Mass driver Module would be grat :) make mining ships so much easyer to handle  ;D


I've been lobbying for the opposite for quite some time.  I think Aurora should remove mass drivers entirely and move everything by ship so my -- and Xenoscepter's -- privateers and pirates and militia and such have much more to do.  As I understand it, mass drivers were only added because the AI to handle civilian freighters wasn't up to the job of regular mineral collection.

But if Aurora is going to keep mass drivers, it desperately needs to make their packets detectable & stealable in deep space.  FAC squadrons with big nets to come along behind them and scoop 'em up, or freighters with oversize doors to fly in front of them and very slightly slow down so the minerals load themselves.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 09, 2019, 02:11:02 PM
If possible a Ship Mass driver Module would be grat :) make mining ships so much easyer to handle  ;D


I've been lobbying for the opposite for quite some time.  I think Aurora should remove mass drivers entirely and move everything by ship so my -- and Xenoscepter's -- privateers and pirates and militia and such have much more to do.  As I understand it, mass drivers were only added because the AI to handle civilian freighters wasn't up to the job of regular mineral collection.

But if Aurora is going to keep mass drivers, it desperately needs to make their packets detectable & stealable in deep space.  FAC squadrons with big nets to come along behind them and scoop 'em up, or freighters with oversize doors to fly in front of them and very slightly slow down so the minerals load themselves.

I agree... a way to interact with them and an option to play without them where the civilian ships move minerals from civilian complexes automatically to the closest colony. The production could still be somewhat abstracted and the cargo on ships going between colony and base should then load based on the type of minerals complexes produce.

It is sometimes interesting to play campaigns where you imagine a world where mass-drivers moving minerals is not a thing.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on November 09, 2019, 03:46:51 PM
Okay, but now you have the situation where a guy whose job is supposed to be fighting is worse at it than a guy whose job is cleaning the gunk out of the soup nozzles.

What we've seen so far from Steve's AARs (admittedly quite a small sample size) is that dedicated boarding troops tear through defending crew at a ratio of 80 or 100 to 1.  If we make defenders any weaker, they are going to inflict zero casualties.  We're already at the point where 90% of attacker's casualties are from the drop attempt rather than fighting on board.

To be fair, in Steve's AAR the attackers seem to have a significant tech advantage. They also tore apart actual ground troops with vehicle support. Assuming equal tech the fight between boarders and crew might be less one-sided.
Title: Re: C# Aurora v0.x Suggestions
Post by: SerBeardian on November 09, 2019, 09:25:55 PM
Not sure if already mentioned, but I would very much like to be able to self-destruct missile salvos from the main system map, since trying to figure out which set of 10 mines out of 300 identical ones in the system is the one that just blew it's load all over the enemy fleet from the "missiles in flight" screen is pretty much impossible.

Having mines sitting there that you think have payload but don't is rather dangerous to your empire security.
Title: Re: C# Aurora v0.x Suggestions
Post by: Nori on November 10, 2019, 06:22:27 PM
Any of you play that old 4x game Stars!  ?
The way they did mass drivers is each tech allowed you to send packets at a specific speed (and the recipient needed to be able to handle that). So maybe you could send at what was in the game warp 10. You could intercept them by going faster, or simply intercepting from the side or in front. Worked pretty well I thought.
Title: Re: C# Aurora v0.x Suggestions
Post by: clement on November 11, 2019, 06:42:47 AM
Any of you play that old 4x game Stars!  ?
The way they did mass drivers is each tech allowed you to send packets at a specific speed (and the recipient needed to be able to handle that). So maybe you could send at what was in the game warp 10. You could intercept them by going faster, or simply intercepting from the side or in front. Worked pretty well I thought.

Yes Stars! was a great game.
Their mass driver implementation was interesting.
I liked their build queue system. You could queue up a certain amount of each building as recurring each build cycle and then put extra build items behind those and all excess build points would go to the extra items once the recurring items were done.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 11, 2019, 04:54:45 PM
Yes Stars! was a great game.
Their mass driver implementation was interesting.
I liked their build queue system. You could queue up a certain amount of each building as recurring each build cycle and then put extra build items behind those and all excess build points would go to the extra items once the recurring items were done.

This seems like it would differ from Aurora's implementation in that the player has to do the math instead of the game.  Instead of setting 10% of your production to build more mines, 10% to more factories, and 10% to research facilities, you'd set it to one mine, one factory, and one research facility per production cycle. . . and then realize that that leaves no excess production since a research facility is twenty times the size of the other two.  You'd also have to figure out when your production capacity doubles and change all the numbers.  Aurora makes this a lot easier, but still suffers from the problem.
Title: Re: C# Aurora v0.x Suggestions
Post by: MultiVitamin on November 12, 2019, 01:32:02 AM
Actually, would it be possible to make research trees for the Ground Force components? Just generic ones to increase their effectiveness, number of shots, etc? Or maybe make it so that we can design them?

So for example there'd be a few fields

Type - Anti-Personnel, Anti-Vehicle, Bombardment, Anti-Aircraft, Autocannon, or HQ (CE would stay the same)

Size - (Light, Medium, Heavy, Super-Heavy, Ultra-Heavy)

AP - (Dropdown menu from 1 to 50)

Damage - (Dropdown menu from 1 to 60)

Shots - (Dropdown menu from 1 to 6)

CIWS - (Can be blank, choose from pre-made CIWS made for ships, just resized maybe?)

FFD - (Dropdown menu from 1 to 3)


And various research could upgrade the ranges of these higher and higher. Just a suggestion I thought of while anticipating the renaming of components when a unit is designed, thought of "why not just build the components with research to make them better, and have that be designable?". It adds a lot more variety and player decision making for Ground Forces, like when you design the weapons, powerplants, defense, engines, etc for ships, just not as intense. Also helps solve the "Can't think of anything for Ultra-Heavy" problem you mention about having a while ago in (I think) a different thread.

If no on the designing the components themselves, what about just research to improve components?

Actually thinking on this, if steve does add more esoteric components later, this might not work out. I also don't fully know all of the research techs already in place for ground units other then the bio-enhancements for infantry.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on November 17, 2019, 10:13:01 AM
Outside of population growth or worker shenanigans, Aurora appears to strongly incentivise having a single large colony over multiple smaller colonies, both to take advantage of strong leader bonuses and to minimise micro. Smaller colonies only really make sense to boost population growth or to act as forward bases, since having a large number of small industrial centres makes any ind of industrial growth an utter pain. Even with regards to resources, it's often best to dump all your mining complexes on that one world with ridiculous deposits at outrageous accessibilities.

As a way to make smaller colonies more viable (so we can all get a slice of that nice, thematic SPACE RACE!), I'd like to suggest that mineral accessibility on system bodies scale with the number of mines present on them, with a larger number of mines giving diminishing results on smaller bodies.

You might be able to accommodate, say, 1,000 mines on Earth without running into diminishing returns, but 10,000 mines may produce only twice as many minerals, so it would be better to spread this across ten Earth-sized bodies. For a system body with a smaller surface area, the limit might be hit much, much sooner. I'd anticipate that to balance this, accesibilities in general might need to be revised upwards.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 17, 2019, 10:52:10 AM
This has already been addressed; planets now have a maximum population, which largely and linearly depends on surface area of the planet, with Earth having a max of 12 billion people.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 17, 2019, 07:19:22 PM
This has already been addressed; planets now have a maximum population, which largely and linearly depends on surface area of the planet, with Earth having a max of 12 billion people.

I still think that having a diminishing return of mining efforts make sense from a realistic perspective. You can only have that many mines on a surface in order to access the easy deposits, adding more should not be that effective.

It would also insentience to spread out a bit more for more reasons than role-play. Sure, strip mining can lead to over consumption and sudden dips in the stream of important minerals which can become really problematic, but in general you want to strip mine every place before going to the next one unless you are pressured by other factors to start mining them or at least control them.

For the most part it probably also are very little incentive to use population for mining in the game anyway as population is too important for other tasks.
Title: Re: C# Aurora v0.x Suggestions
Post by: Nori on November 17, 2019, 07:37:25 PM
I'm not sure how it'll play out in C#, but in the VB version, I only used population for mines early on, or with colonies that didn't have dire need for the populations.

Quite curious to see how the C# changes makes that all play out. From Steve's comments it seems like Automines will be even more important.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 17, 2019, 08:25:43 PM
I still think that having a diminishing return of mining efforts make sense from a realistic perspective. You can only have that many mines on a surface in order to access the easy deposits, adding more should not be that effective.

Okay, but now we're arguing 'how many' is "that many".

Given that Aurora mines are fixed in size, "ten Aurora mine installations" can be defined as "one mine that is ten times bigger than that one over there."  If we define one Aurora automine as one hydraulic excavator plus two trucks plus one ore processor, it suddenly seems perfectly reasonable to have tens (if not hundreds) of thousands of them on Earth.  Given that a basic Aurora mine produces only ten tons of refined TNE per year (per mineral, yes, but I'm going to ignore that for now) it can't be that big.

- - -

Okay, sure, this implies that manned Aurora mines are insanely inefficient, but we already had that problem.  Fifty thousand people is larger than the population of Fort MacMurray, the city at the heart of Canada's oilsands mining region, and the source of over one-third of all of Canada's oil production.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on November 17, 2019, 09:33:51 PM
I always kindof assumed that was just to create a mental image of millions of slaves laboring away in the mines, since some people like that aesthetic.  I also would also note that automines are almost always preferable however.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on November 18, 2019, 03:05:06 AM
I always thought of it that a "mine" is not just the bits that dig into the ground, but includes a significant chunk of supporting facilities like farms to feed the miners, schools, truck factories, workshops, entertainment and whatever else you need to have a minimally self-sufficient mining town. Low production can simply be explained by TN minerals being an absolute bugger to extract, perhaps only occurring in relatively trace amounts or whatever.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 18, 2019, 03:11:27 AM
There is approximately 25 (short) tons of gold in one cubic mile of seawater -- or 22 tonnes in 4 cubic kilometers.  I assume TNE are likewise diffuse.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 18, 2019, 04:41:40 AM
Available workers has been a consistent problem in my current campaign. That solution to that is creating new colonies, as smaller colonies have faster growth and a larger manufacturing sector.

In fact, I am already spreading mines, construction factories and even shipyards to those colonies within 15 years of campaign start. Also, with the maintenance changes, it is a LOT easier to setup naval bases at new colonies
Title: Re: C# Aurora v0.x Suggestions
Post by: vorpal+5 on November 18, 2019, 05:15:11 AM
Is that not 'artificial'? Do we really think that workers, as 'biological beings' will be the main limiting constraints in the future?

I can understand you have this limitation primarily as a gameplay feature perhaps? But if not, how about being able to produce robotics workers, as it will happen soon enough in our world? Alternatively or in addition, some techs reducing the manpower need of various industries would be simple to do and realistic?

In the grand scheme of things, being productive is a matter of logistic and industrial muscles, but the bottleneck is probably not on meatbags amounts.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 18, 2019, 05:31:45 AM
It's entirely possible that the reason it takes 50 000 people to run a mine is because you aren't dealing with just a bunch of digging machines and the logistics of moving vast amounts of materials around. Rather, due to TN shenanigans, the facilities that are needed to reach into the aether and draw in and refine even minute quantities of TN materials are huge and require a lot of upkeep, and the industry necessary for that upkeep is included in the 50 000 population support figure.

I mean, at the early game 10 tons per year production that's less than 30 kilograms per day per mine. It's a tiny supply by any measure.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 18, 2019, 06:48:25 AM
The game already have allot of automation such as auto mines, maintenance facilities etc.. so many of these things can be run without any population what so ever.

There could be some technology though that reduce the reliance of population on facilities over time down to relatively low levels at increased production costs though.

I'm pretty sure that most people in a mine are maintenance and office workers. I presume most actual labour is made by robotic machines anyway in this era. So the people are just about anyone from a clerk, engineer to a cook.

In very modern production industries most people already work with servicing the factories functions rather than working with the actual production line. Administration jobs are one of the biggest employers today in what used to be hard labour places. The actual "hard working" people tend to be highly educated engineers who oversee the machinery.

On the other hand you want to use the population for something in the game, even if realistically you don't need that man actual people to produce stuff in the future. It is more fun if the world are a bit more dystopian.  ;)
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 18, 2019, 06:54:22 AM
I still think that having a diminishing return of mining efforts make sense from a realistic perspective. You can only have that many mines on a surface in order to access the easy deposits, adding more should not be that effective.

Okay, but now we're arguing 'how many' is "that many".

Given that Aurora mines are fixed in size, "ten Aurora mine installations" can be defined as "one mine that is ten times bigger than that one over there."  If we define one Aurora automine as one hydraulic excavator plus two trucks plus one ore processor, it suddenly seems perfectly reasonable to have tens (if not hundreds) of thousands of them on Earth.  Given that a basic Aurora mine produces only ten tons of refined TNE per year (per mineral, yes, but I'm going to ignore that for now) it can't be that big.

- - -

Okay, sure, this implies that manned Aurora mines are insanely inefficient, but we already had that problem.  Fifty thousand people is larger than the population of Fort MacMurray, the city at the heart of Canada's oilsands mining region, and the source of over one-third of all of Canada's oil production.

I always thought of it that a "mine" is not just the bits that dig into the ground, but includes a significant chunk of supporting facilities like farms to feed the miners, schools, truck factories, workshops, entertainment and whatever else you need to have a minimally self-sufficient mining town. Low production can simply be explained by TN minerals being an absolute bugger to extract, perhaps only occurring in relatively trace amounts or whatever.

Yes... I think that ground facilities in Aurora are abstracts "units" rather than fixed buildings and trucks. A mine is simply the infrastructure, machinery and administration needed to produce a certain amount of goods and services. Not even necessarily all located in the same physical location either.

It would not be hard to come up with some rough estimation of proper number of mines, factories etc... that are suitable for each world as the optimal number and after this there is a diminishing return on their effectiveness.

You probably could use more mines on an asteroid for example in proportion to size than on say the moon or earth. So it would be way more easy to strip mine an asteroid than the moon and way more easy to strip mine the moon than earth for example.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 18, 2019, 08:53:11 AM
On the other hand, part of the lore of Aurora is that TN materials gather in gravity wells and that deeper gravity wells both draw in more TN materials and are harder to get to, so you might well need and have the room to place more mines on larger bodies than you do on smaller ones in a manner that's greater than linear.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 18, 2019, 04:16:27 PM
On the other hand, part of the lore of Aurora is that TN materials gather in gravity wells and that deeper gravity wells both draw in more TN materials and are harder to get to, so you might well need and have the room to place more mines on larger bodies than you do on smaller ones in a manner that's greater than linear.

Make sense too I suppose...
Title: Re: C# Aurora v0.x Suggestions
Post by: Coleslaw on November 19, 2019, 12:22:11 AM
So for the navy, we have the ability to assign staff officers to give bonuses to fleet operations (for fleets located in the same system as the location of the staff offices, I believe), but would something similar be reasonable to implement for Ground Forces? Sort of as a general staff that functions similarly?
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 19, 2019, 01:20:18 AM
So for the navy, we have the ability to assign staff officers to give bonuses to fleet operations (for fleets located in the same system as the location of the staff offices, I believe), but would something similar be reasonable to implement for Ground Forces? Sort of as a general staff that functions similarly?

We will -- to some extent -- have that, as HQ units can stack up to several million tons of control.  With a sixteen-million-ton GF HQ, you should have plenty of room for multiple GF officers and their bonuses.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on November 19, 2019, 01:30:50 PM
Yes, now that rank structure for ground officers is basically unlimited (only limit is the total number of officers available) and that HQs are both customised to fit what is needed AND can be stacked on top of each other (meaning that a higher level HQ does not need to be big enough to handle everything under it, just its own level of the order-of-battle structure, it's possible to create as elaborate and complicated chains of command as you could want.

I am tempted to make a chain like this:

Platoon -> Company -> Battalion -> Regiment -> Brigade -> Division -> Corps -> Army -> Group -> Theatre -> Force

Which would require 11 ranks of GF officers but I'm not sure if I want to have a HQ vehicle in an otherwise infantry formation (rifle platoon) so I might have Company as the lowest level with an HQ for a total of 10.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 19, 2019, 02:50:01 PM
HQ units can be infantry platformed as easily as they can be vehicle platformed. And the highest level of command should probably be static platforms, for realism, or super heavy units for the 'massive crawler command base' factor you so often see in science fiction.
Title: Re: C# Aurora v0.x Suggestions
Post by: King-Salomon on November 19, 2019, 03:05:12 PM
I am tempted to make a chain like this:

Platoon -> Company -> Battalion -> Regiment -> Brigade -> Division -> Corps -> Army -> Group -> Theatre -> Force

Which would require 11 ranks of GF officers but I'm not sure if I want to have a HQ vehicle in an otherwise infantry formation (rifle platoon) so I might have Company as the lowest level with an HQ for a total of 10.
^

I was thinking about the same but without the platoon-level .. but after reading the AA-Reports from Steve I am not so sure anymore.. it would be a micro nightmare to fill up the looses/spent-supplytrucks "per hand" with hundreds of tiny units...
if there will be an order to bring "all units" back up to strength from a destinated replacement-unit I will try to go with a 10 level-OOB ... if you have to do it by hand I will stick to a 2-level-OOB I guess..

will find out when C# is out I guess  ;D
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 19, 2019, 07:38:02 PM
I am tempted to make a chain like this:

Platoon -> Company -> Battalion -> Regiment -> Brigade -> Division -> Corps -> Army -> Group -> Theatre -> Force

Which would require 11 ranks of GF officers but I'm not sure if I want to have a HQ vehicle in an otherwise infantry formation (rifle platoon) so I might have Company as the lowest level with an HQ for a total of 10.
^

I was thinking about the same but without the platoon-level .. but after reading the AA-Reports from Steve I am not so sure anymore.. it would be a micro nightmare to fill up the looses/spent-supplytrucks "per hand" with hundreds of tiny units...
if there will be an order to bring "all units" back up to strength from a destinated replacement-unit I will try to go with a 10 level-OOB ... if you have to do it by hand I will stick to a 2-level-OOB I guess..

will find out when C# is out I guess  ;D

It should actually not be terribly difficult. A unit will only draw supply from within its own unit if there are no supplies available in a higher chain of command. So unless you start to run out of supplies you can imagine the supply running down the hierarchy to each unit. You will not draw supplies from the platoons or companies unless there is a need to. You can just restock the divisional supply from time to time by dropping them down from orbit on the planet or from the factory floor if on a planet.

Its probably not going to be useful to go down below company level, that smallest HQ are 1250 ton so that would probably be a rather typical company sized formation or a really large platoon for some reason.

A platoon of heavy tanks that comprise 5 tanks might be around 500t in size, roughly.

A typical modern Company is about three Platoons and a command and or weapons section. If mechanized that would be roughly 12-15 light/medium vehicles and 100-150 men or so, that would roughly be 1000-1250 in Aurora size.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on November 20, 2019, 11:48:06 AM
HQ units can be infantry platformed as easily as they can be vehicle platformed. And the highest level of command should probably be static platforms, for realism, or super heavy units for the 'massive crawler command base' factor you so often see in science fiction.
Ah thanks for reminding me! I completely forgot that HQ's do not need to be vehicles.

Its probably not going to be useful to go down below company level, that smallest HQ are 1250 ton so that would probably be a rather typical company sized formation or a really large platoon for some reason.
Steve changed that. HQs are now much more modular:
Quote
You select the HQ component and then type in the required capacity. The component cost is Capacity / 2500 and the component size is Capacity / 50 with a max of 500 tons. There is no limit on cost.
So if your platoon - without the HQ - is only 50 tons, then your platoon HQ will just add 1 ton on top and cost only 0.02.

For example, a rifle platoon of 3 rifle squads each with 5 riflemen (personal weapon), 1 grenadier (light anti vehicle), 1 machinegunner (crew served anti-personnel) would be:

3x5x5 = 75 tons
3x1x16 = 48 tons
3x1x12 = 36 tons

totalling 159 tons which requires an infantry HQ of 3.18 tons. Here is a design example Steve gave us back in 2018:
Quote
Pathfinder class Transport Shuttle      451 tons       10 Crew       53.1 BP       TCS 9    TH 64    EM 0
7099 km/s      Armour 1-5       Shields 0-0       HTK 1      Sensors 1/1/0/0      DCR 0      PPV 0
Maint Life 3.55 Years     MSP 0    AFR 90%    IFR 1.3%    1YR 8    5YR 115    Max Repair 40.5 MSP
Troop Capacity 300 tons     
Lieutenant Commander    Control Rating 1   
Intended Deployment Time: 0.5 months    Morale Check Required   

Large Fighter Engine (1)    Power 64    Fuel Use 758.95%    Signature 64    Explosion 20%
Fuel Capacity 20,000 Litres    Range 1.1 billion km   (41 hours at full power)
It has capacity for 300 tons, meaning that it could actually be smaller and still transport our platoon at fighter-size.

I like it. I'm seeing the dropships from Starship Troopers or Aliens, swooping down on planet surface in their dozens to drop off the first wave of ground pounders.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on November 20, 2019, 01:02:09 PM
I've been thinking about simulating on the squad level for smegs and giggles, pump out lots and lots of ground focus military academies. It's pointlessly granular except maybe for marines, but I love this sort of stuff.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 20, 2019, 04:03:37 PM
Its probably not going to be useful to go down below company level, that smallest HQ are 1250 ton so that would probably be a rather typical company sized formation or a really large platoon for some reason.
Steve changed that. HQs are now much more modular:

Ah... that I did not remember... that makes me happy... I gladly model my forces at platoon level if possible.

I just wonder how easy it will be to fill up the templates after losses if I do though.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 20, 2019, 04:18:16 PM
Frankly, you'd be replacing units whole sale in that case, because you're not losing 'most of a battalion in an engagement' but entire platoons.

Quite frankly, I'd be more worried about having to constantly churn them out in the GFTFs without some way of queuing them up like with ground construction, rather than having to do it like with ship construction where every ship needs a button press.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 20, 2019, 05:57:08 PM
I have been playing Aurora for the last week or two and there are something that I would like to revisit... I know that you Steve have talked about electronic warfare, stealth and the like before. I just wanted to add some to that.

It is a bit "boring" to constantly build highly specialised ship with one large sensor on it. I know that sensors will work differently and that building larger and larger sensors now will have a diminishing return so spreading out smaller scouts are going to be a thing.

But there still is no real point adding active and passive sensors on every ship as long as you have a one or two in each task group, this really make no sense as sensors are one of the more sensitive and easily disrupt able and damageable components of any military vessel, from tanks to ships or planes or whatever. For example.. a modern tank are so reliant on sensors that even firing on it with machine guns can effectively knock them out without too much luck as a valid fighting machine.

There are a few things that I would like to take up as potential interesting mechanic to deal with sensors.

1. Sensors should be way more susceptible to chock damage than most other components. Sensors almost always need to be to some degree in vulnerable parts of a ship and therefore are more susceptible to being damaged through near misses and general mayhem. Having sensors often just degraded by damage impacts in general could also work.

2. Allow us to use Microwave technology in missiles and use them as area effect weapons that have the potential to harm or at least temporarily disable or degrade sensors. You shoot missiles and instead of a normal charge the missile have technologies similar to microwave beams. You should be able to choose between range or strength. These missiles are rarely knocking sensor equipment out like beams but will degrade them and randomly effect all ships within range and those close by less the further they are away. The range should not be huge, say increments of 5.000km per strength level or something.

3. Active jamming technology that randomly can degrade enemy sensors. I think such devices should be directed against targets and not effect everything around them. Jamming technologies usually work best when directed specifically against something. You should be able to confuse both active and passive sensors if you know what to target.


All or even some of these would make it worth while to put sensors on most warships at least to some degree. It would still make sense to have dedicated sensor ships designed with hardened sensor equipment, but you could never truly depend on one or two of such ships in any serious fleet or task-group.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 21, 2019, 01:00:54 AM
I *already* put sensors on all my ships, but I think the increased effectiveness of small sensors is going to encourage a lot of other people to do likewise.

For anything more than that, I want to play with C# Aurora first and see what it's like before starting down the EW rabbit hole.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 21, 2019, 01:51:39 AM
I *already* put sensors on all my ships, but I think the increased effectiveness of small sensors is going to encourage a lot of other people to do likewise.

For anything more than that, I want to play with C# Aurora first and see what it's like before starting down the EW rabbit hole.

I would like sensors to be a lot less deterministic, it certainly would enhance multi-faction campaigns allot in my opinion. I also know that Stave have discussed electronic warfare and stealth not too long ago, so this were just some suggestion for those ideas. We also have ELINT now as well so it is sort of an extension to that as well.

Electronic warfare is almost more important than actually firing missiles at each other in reality. Knowledge is is the ultimate power in many ways.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kelewan on November 21, 2019, 05:45:06 AM
Its probably not going to be useful to go down below company level, that smallest HQ are 1250 ton so that would probably be a rather typical company sized formation or a really large platoon for some reason.
Steve changed that. HQs are now much more modular:

Ah... that I did not remember... that makes me happy... I gladly model my forces at platoon level if possible.

I just wonder how easy it will be to fill up the templates after losses if I do though.

Recently I made a suggestion on managing ground forces
http://aurora2.pentarch.org/index.php?topic=10498.0 (http://aurora2.pentarch.org/index.php?topic=10498.0)
But I think for managing forces at platoon level multi-select is
really needed
Title: Re: C# Aurora v0.x Suggestions
Post by: AlStar on November 21, 2019, 09:55:34 AM
According to Steve's latest campaign notes, the spoilers that he's currently battling appear to completely ignore organics  - up to and including dissolving the infrastructure right out from under colonists, leaving them to die in a hostile biosphere.

I feel like at least some percentage of that kind of spoiler should hate letting all that biomass go to waste - and instead should convert colonist populations on conquered planets into ground units.  Ideally, these would be unique units, so that the player can appreciate how they've failed those poor innocents they were supposed to protect while they're getting their own colonists thrown at them.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 21, 2019, 10:52:02 AM
Yeah, biosphere possessing/inhabited planets should make those spoilers a lot more terrifying than they already are. Even if it's just (x tons of disposable ground troops) per however many colonists seem appropriate.
Title: Re: C# Aurora v0.x Suggestions
Post by: vorpal+5 on November 21, 2019, 02:56:14 PM
I'm not sure about if Aurora C# will allow space factories where you can output ships from A to Z, in deep space, provided you have the construction materials?
Title: Re: C# Aurora v0.x Suggestions
Post by: MultiVitamin on November 21, 2019, 05:49:30 PM
Just a thought while reading through the Real World 21st Century Ground Unit Templates thread.

To give a bit more variation between Light, Medium, Heavy, Super Heavy and Ultra Heavy weapon components, why not make it so that lighter versions have more shots?

So for example, Infantry Personal Weapons have 1 shot, but Light Personal Weapons have 2, or Crew-Served Anti Personnel (again, infantry) have 9 shots, and Heavy Crew-Served Anti-Personnel has 6 shots.

Just thought on weapon based components, since they're not as diverse in terms of differences in size except in AP and, well, Size.

Maybe rapid versions of those components that have more shots then normal, but less damage/AP?
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 21, 2019, 06:17:05 PM
'Number of shots' is not how many times they actually fire. Rather, it's an abstraction to how likely they are to fire a shot that is likely to destroy a target when engaged. For things like personal weapons and crew served anti personnel that's quite a lot of shots, but things like suppression fire, covering fire and recon by fire (shooting a bunch of cover to see if the enemy responds to having been 'found') are not considered.

The abstraction is not perfect, especially given the hours long length of a given turn and a number of other factors, but things like bombardment weapons have high number of shots for their weight because those are basically abstractions of area carpeting weapons of limited effectiveness against armour, while things like AA or AV weapons tend to have heavier damage and armour penetrating stats with a single shot per turn because they either generally are kept from engaging until necessary/beneficial or just don't really get a good target presented to them that often.
Title: Re: C# Aurora v0.x Suggestions
Post by: MultiVitamin on November 21, 2019, 08:57:47 PM
'Number of shots' is not how many times they actually fire. Rather, it's an abstraction to how likely they are to fire a shot that is likely to destroy a target when engaged. For things like personal weapons and crew served anti personnel that's quite a lot of shots, but things like suppression fire, covering fire and recon by fire (shooting a bunch of cover to see if the enemy responds to having been 'found') are not considered.

The abstraction is not perfect, especially given the hours long length of a given turn and a number of other factors, but things like bombardment weapons have high number of shots for their weight because those are basically abstractions of area carpeting weapons of limited effectiveness against armour, while things like AA or AV weapons tend to have heavier damage and armour penetrating stats with a single shot per turn because they either generally are kept from engaging until necessary/beneficial or just don't really get a good target presented to them that often.

Ah, I was operating under the assumption that Shots was the amount of attacks made per turn with that component by a unit. Thanks for the info.
Title: Re: C# Aurora v0.x Suggestions
Post by: Coleslaw on November 24, 2019, 06:19:32 PM
Will we be able to utilize cloaking technology when it comes to ground units? Perhaps makes the unit with it harder to hit/detect from orbit?
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 24, 2019, 07:17:39 PM
No.

Cloaking technology is something that is currently space only. Hiding things on planet is currently solely the province of the Fortification mechanic IIRC.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 25, 2019, 01:52:32 AM
I was thinking about the crew system and there are a few things that always bother me about this and that was that crew basically are immortal... crew production are completely linear and make no real sense.

I think crew production should be about skill and expected service time, so each academy would instead be able to support a number of crew in your fleet rather than producing a certain number of crew every month. They should work more like your officers as they will retire at some time in the future.

This would make crew more of a strategic resource just like in reality and not something you can just replace and have a huge ready pool of if you are at or near your capacity.

If you have already used up the available pool the only way to get more is to build more Academies and not just wait to get more. If your ships are destroyed and the crew dies there will be a significant time before you manage to acquire more crew.

You could also tie max deployment rate of ships to crew service length. If you deploy a ship that has a higher deployment range than the service length of your average crew you have to provide more living space or perhaps add some other extra cost for those ships to compensate.

You could also tie it into fleet readiness levels such as crew training, as ships abstractly receive new crew over time then fleet training should drop off as time goes by if you don't periodically perform fleet training.

Your race will then determine how many crew can be trained from each academy based on the skill level, the same as now. Service length should be a variable setting and tie into the overall pool size and cost of the crew. Even crew that you are not using should cost wealth, so just tax the economy of the total crew pool with a certain type of wealth cost every month. Even if they are not assigned they need to be constantly trained and ready to be deployed if they aren't not already.

This would be an abstract way of managing replacement and retirement of crew over time, something I think the game lacks.

Military ships should require military grade personnel or suffer some horrendous penalties in terms of skill, moral and much lower deployment times than normal. The risk of something breaking on a ship with drafted untrained personnel should be significantly higher too.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on November 25, 2019, 05:12:53 AM
While it makes sense to me that crew should eventually 'age out' of the pool, instead of accumulating endlessly unless lost with ship destruction, I am highly nervous about the mechanism employed to do it.  If it turned out that building the size of navy I want to build, featuring the types of ships I want to use, meant that my empire needed sixty extra Academies on every major colony, I would be pissed.  In the fiction of my mind I expect certain ratios of installations.  Varying wildly from that harms my believability.

But my main concern is with what I consider the worst bug in all of Aurora.  Since version 2 or so officer promotion has included the 'up-or-out' philosophy of the modern U.S. military.  As a result, literally every single one of my conventional starts has followed roughly the same path; by the time my empire has researched the necessary jump point theory, grav sensors, jump engine techs (& an actual functioning jump engine design) and constructs its first survey ships, 90% of officers in the fleet have been without an assignment for two-to-three tour lengths and are "deemed surplus to requirements and released from the service."

I fear the same thing happening with crews.  I want the problem solved before giving C# Aurora the ability to fire any more of my personnel.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 25, 2019, 05:16:43 AM
I was thinking about the crew system and there are a few things that always bother me about this and that was that crew basically are immortal... crew production are completely linear and make no real sense.

I think crew production should be about skill and expected service time, so each academy would instead be able to support a number of crew in your fleet rather than producing a certain number of crew every month. They should work more like your officers as they will retire at some time in the future.

This would make crew more of a strategic resource just like in reality and not something you can just replace and have a huge ready pool of if you are at or near your capacity.

If you have already used up the available pool the only way to get more is to build more Academies and not just wait to get more. If your ships are destroyed and the crew dies there will be a significant time before you manage to acquire more crew.

You could also tie max deployment rate of ships to crew service length. If you deploy a ship that has a higher deployment range than the service length of your average crew you have to provide more living space or perhaps add some other extra cost for those ships to compensate.

You could also tie it into fleet readiness levels such as crew training, as ships abstractly receive new crew over time then fleet training should drop off as time goes by if you don't periodically perform fleet training.

Your race will then determine how many crew can be trained from each academy based on the skill level, the same as now. Service length should be a variable setting and tie into the overall pool size and cost of the crew. Even crew that you are not using should cost wealth, so just tax the economy of the total crew pool with a certain type of wealth cost every month. Even if they are not assigned they need to be constantly trained and ready to be deployed if they aren't not already.

This would be an abstract way of managing replacement and retirement of crew over time, something I think the game lacks.

Military ships should require military grade personnel or suffer some horrendous penalties in terms of skill, moral and much lower deployment times than normal. The risk of something breaking on a ship with drafted untrained personnel should be significantly higher too.

Very interesting concept.

I watched 'The Cruel Sea' last night (excellent 1953 B&W film - recommended viewing). I have a seen it several times over the years but hadn't watched it for a while. It starts with the newly-built Flower class corvette (escort vessel of about 1000 tons) Compass Rose and her newly trained crew in 1939 as they embark on the Battle of the Atlantic. The captain is from the merchant navy, the other officers have a few weeks training and most of the crew have never been to sea before.

The concept of gearing up for war and turning civilians into professional navy officers and crew is something that would be interesting to simulate in more depth than the current mechanics. I'll give it some thought.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 25, 2019, 05:18:44 AM
But my main concern is with what I consider the worst bug in all of Aurora.  Since version 2 or so officer promotion has included the 'up-or-out' philosophy of the modern U.S. military.  As a result, literally every single one of my conventional starts has followed roughly the same path; by the time my empire has researched the necessary jump point theory, grav sensors, jump engine techs (& an actual functioning jump engine design) and constructs its first survey ships, 90% of officers in the fleet have been without an assignment for two-to-three tour lengths and are "deemed surplus to requirements and released from the service."

I fear the same thing happening with crews.  I want the problem solved before giving C# Aurora the ability to fire any more of my personnel.

This has been removed from C# Aurora and there is a new promotions and retirement system:

http://aurora2.pentarch.org/index.php?topic=8495.msg104038#msg104038

Title: Re: C# Aurora v0.x Suggestions
Post by: Tikigod on November 25, 2019, 05:57:09 AM
I was thinking about the crew system and there are a few things that always bother me about this and that was that crew basically are immortal... crew production are completely linear and make no real sense.

I think crew production should be about skill and expected service time, so each academy would instead be able to support a number of crew in your fleet rather than producing a certain number of crew every month. They should work more like your officers as they will retire at some time in the future.

This would make crew more of a strategic resource just like in reality and not something you can just replace and have a huge ready pool of if you are at or near your capacity.

If you have already used up the available pool the only way to get more is to build more Academies and not just wait to get more. If your ships are destroyed and the crew dies there will be a significant time before you manage to acquire more crew.

You could also tie max deployment rate of ships to crew service length. If you deploy a ship that has a higher deployment range than the service length of your average crew you have to provide more living space or perhaps add some other extra cost for those ships to compensate.

You could also tie it into fleet readiness levels such as crew training, as ships abstractly receive new crew over time then fleet training should drop off as time goes by if you don't periodically perform fleet training.

Your race will then determine how many crew can be trained from each academy based on the skill level, the same as now. Service length should be a variable setting and tie into the overall pool size and cost of the crew. Even crew that you are not using should cost wealth, so just tax the economy of the total crew pool with a certain type of wealth cost every month. Even if they are not assigned they need to be constantly trained and ready to be deployed if they aren't not already.

This would be an abstract way of managing replacement and retirement of crew over time, something I think the game lacks.

Military ships should require military grade personnel or suffer some horrendous penalties in terms of skill, moral and much lower deployment times than normal. The risk of something breaking on a ship with drafted untrained personnel should be significantly higher too.

Very interesting concept.

I watched 'The Cruel Sea' last night (excellent 1953 B&W film - recommended viewing). I have a seen it several times over the years but hadn't watched it for a while. It starts with the newly-built Flower class corvette (escort vessel of about 1000 tons) Compass Rose and her newly trained crew in 1939 as they embark on the Battle of the Atlantic. The captain is from the merchant navy, the other officers have a few weeks training and most of the crew have never been to sea before.

The concept of gearing up for war and turning civilians into professional navy officers and crew is something that would be interesting to simulate in more depth than the current mechanics. I'll give it some thought.

All for that kind of thing providing it doesn't impact the freedom to produce ships, see how they work out and potentially having to abandon them or see them destroyed by external forces due to designs not performing quite as intended (Or from design errors).

Experimenting with designs to see what works and coming up with interesting compositions is quite a strong draw point for me with Aurora, and general crew with any degree of competence for ships being turned into some kind of consumable resource would probably dampen the creation side of things and encourage the recycling of the same tried and true designs over and over every campaign rather than risk being faced with not having enough crew to field ships if you suddenly need them without just sitting skipping forward months/years of time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tikigod on November 25, 2019, 06:00:14 AM
No.

Cloaking technology is something that is currently space only. Hiding things on planet is currently solely the province of the Fortification mechanic IIRC.

Would make for a pretty interesting new direction for the old underground excavation concept that I think has been replaced with something else in C#.

Reintroduce underground excavation as a kind of passive thermal signature reduction to all planet based activity going on there if there has been construction effort put into the excavation of space below the surface.

Dummy example with placeholder figures would be something like 10% of excavation total would translate into how many 'constructions' would have their thermal signature from space reduced. So 100 excavation construction jobs would result in 10 constructions being technically 'subterranean' getting a 20% thermal contribution reduction. A single excavation construction job would probably require a fair bit of CP though, along with some base TN material cost perhaps similar to the cost of infrastructure.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 25, 2019, 06:48:26 AM
All for that kind of thing providing it doesn't impact the freedom to produce ships, see how they work out and potentially having to abandon them or see them destroyed by external forces due to designs not performing quite as intended (Or from design errors).

Experimenting with designs to see what works and coming up with interesting compositions is quite a strong draw point for me with Aurora, and general crew with any degree of competence for ships being turned into some kind of consumable resource would probably dampen the creation side of things and encourage the recycling of the same tried and true designs over and over every campaign rather than risk being faced with not having enough crew to field ships if you suddenly need them without just sitting skipping forward months/years of time.

At this point, I am just thinking about the concept. I'm a long way from designing mechanics. Any significant crew-related change would most likely be optional anyway - like maintenance or inexperienced crew,
Title: Re: C# Aurora v0.x Suggestions
Post by: vorpal+5 on November 25, 2019, 07:56:31 AM
But my main concern is with what I consider the worst bug in all of Aurora.  Since version 2 or so officer promotion has included the 'up-or-out' philosophy of the modern U.S. military.  As a result, literally every single one of my conventional starts has followed roughly the same path; by the time my empire has researched the necessary jump point theory, grav sensors, jump engine techs (& an actual functioning jump engine design) and constructs its first survey ships, 90% of officers in the fleet have been without an assignment for two-to-three tour lengths and are "deemed surplus to requirements and released from the service."

I fear the same thing happening with crews.  I want the problem solved before giving C# Aurora the ability to fire any more of my personnel.

This has been removed from C# Aurora and there is a new promotions and retirement system:

http://aurora2.pentarch.org/index.php?topic=8495.msg104038#msg104038

Thanks <insert random entity name here, but not hastur the unspeakable that aaaahhrgghhrheee> !!

Does it means I can at last stop producing useless unarmed fighters so my precious officers are not rotated out?  ;D
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on November 25, 2019, 08:14:43 AM
I fear the same thing happening with crews.  I want the problem solved before giving C# Aurora the ability to fire any more of my personnel.

Keep in mind that the concept of inexperienced crews exists for a reason. Yes, you generally want properly trained crew on your ships, but if the situation is bad enough or a given ship doesn't need a certain grade of crew a government can just toss in untrained crew into positions that don't need that training, or there's just no trained personnel to fill it.

All for that kind of thing providing it doesn't impact the freedom to produce ships, see how they work out and potentially having to abandon them or see them destroyed by external forces due to designs not performing quite as intended (Or from design errors).

Experimenting with designs to see what works and coming up with interesting compositions is quite a strong draw point for me with Aurora, and general crew with any degree of competence for ships being turned into some kind of consumable resource would probably dampen the creation side of things and encourage the recycling of the same tried and true designs over and over every campaign rather than risk being faced with not having enough crew to field ships if you suddenly need them without just sitting skipping forward months/years of time.

It'd work fine as a pool system where a given percentage of crew retires each year and a given number of new crew enter from the academies each year. At that point you can define 'total size of the trained crew pool', 'total number of assigned crew' and 'available crew for new assignment'.

Classes with the 'conscript crew' modifier would use a modified system that only checks the total size of the 'assigned conscript crew' pool and drop a (notably higher) percentage from the pool before making up the difference with new untrained crew.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 25, 2019, 08:39:21 AM
While it makes sense to me that crew should eventually 'age out' of the pool, instead of accumulating endlessly unless lost with ship destruction, I am highly nervous about the mechanism employed to do it.  If it turned out that building the size of navy I want to build, featuring the types of ships I want to use, meant that my empire needed sixty extra Academies on every major colony, I would be pissed.  In the fiction of my mind I expect certain ratios of installations.  Varying wildly from that harms my believability.

But my main concern is with what I consider the worst bug in all of Aurora.  Since version 2 or so officer promotion has included the 'up-or-out' philosophy of the modern U.S. military.  As a result, literally every single one of my conventional starts has followed roughly the same path; by the time my empire has researched the necessary jump point theory, grav sensors, jump engine techs (& an actual functioning jump engine design) and constructs its first survey ships, 90% of officers in the fleet have been without an assignment for two-to-three tour lengths and are "deemed surplus to requirements and released from the service."

I fear the same thing happening with crews.  I want the problem solved before giving C# Aurora the ability to fire any more of my personnel.

This would not happen, the amount of crew from each academy stays the same after the academy reached its limit in graduating crewmen.

Lets say each Academy allow 1000 crew (based on service length)...

When it is built it will add 30 new crew per month until it supplied 1000. after witch it is abstracted that it is able to train as many new crew as are leaving the service after the service time is finished.

If you have a ship that carry 300 crew that is destroyed and they alll die the pool now suddenly is only 700 and you have to wait for 30 month for the pool to recover.

Service length could also be extended during wartime, but the cost of service time should not be a linear cost. So a service time of 12 month might cost you say 0.1 wealth per crew while 24 month service time might cost you 0.3 wealth per crew. Service time could then be increased during wartime for a considerable cost and would also be a way to cover some losses or add to the pool for new ships produced faster than expected without having to add more academies.

If you increase the service length you don't just get more crew though, you just increase the pool limit and gradually add more crew over time until the limit is reached. If you lower the service time though you will pretty much immediately retire allot of crew as their service time is up... or you can do the same procedure and imagine everyone serve their time but are not replaced afterwards.

The number of graduates per month and academy would also depend on their skill level. Low skill give you more graduates per academy per month thus also a higher pool limit, while high skill require more time and effort and give you less per month and thus a smaller total pool size... pretty similar to now.

It would be a really simple but interesting system to work from.

So the fear that crew would disappear would only happen if you loos academies, from say a war. But you would not loose them immediately, they wold then be lost in the same pace you would otherwise have gained them, but you could mos likely offset this by raising the service length and pay more for them for a while from your other academies (unless all the academies are in one place).

If the crew pool start to dip below the totally required crew for your ship then ships would start to get totally untrained crew and the skill level of the crews on all your ships would start to drop considerably until you fix the situation.

It is a really simple and abstract way of dealing with a more realistic crew system that does not result you needing to keep track of crews individually. You just tie the general pool with the ship and their individual training and skill depend on the skill level of new crew.

One interesting thing you also could do is tie it into the deployment time of ships. As if you give ships a very long deployment time you will have to accommodate for the fact that the crew is especially picked and have special needs. Thus you could incur some penalties such as wealth cost of the crew of that ship being much higher than otherwise. This means you are not going to give ships a deployment time higher than regular service length unless it is really necessary.

This also would make saving crew a pretty important thing to do if at all possible, as saving them will make sure they can join a new ship as the pool size don't go down.

You probably also would want to separate crew training from the Academy into its own building, perhaps also give some technology that can increase the efficiency and pool size of these buildings over time.

If you want crew to be an interesting resource something like this could add to the game without needing any micromanagement.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 25, 2019, 08:43:57 AM
I was thinking about the crew system and there are a few things that always bother me about this and that was that crew basically are immortal... crew production are completely linear and make no real sense.

I think crew production should be about skill and expected service time, so each academy would instead be able to support a number of crew in your fleet rather than producing a certain number of crew every month. They should work more like your officers as they will retire at some time in the future.

This would make crew more of a strategic resource just like in reality and not something you can just replace and have a huge ready pool of if you are at or near your capacity.

If you have already used up the available pool the only way to get more is to build more Academies and not just wait to get more. If your ships are destroyed and the crew dies there will be a significant time before you manage to acquire more crew.

You could also tie max deployment rate of ships to crew service length. If you deploy a ship that has a higher deployment range than the service length of your average crew you have to provide more living space or perhaps add some other extra cost for those ships to compensate.

You could also tie it into fleet readiness levels such as crew training, as ships abstractly receive new crew over time then fleet training should drop off as time goes by if you don't periodically perform fleet training.

Your race will then determine how many crew can be trained from each academy based on the skill level, the same as now. Service length should be a variable setting and tie into the overall pool size and cost of the crew. Even crew that you are not using should cost wealth, so just tax the economy of the total crew pool with a certain type of wealth cost every month. Even if they are not assigned they need to be constantly trained and ready to be deployed if they aren't not already.

This would be an abstract way of managing replacement and retirement of crew over time, something I think the game lacks.

Military ships should require military grade personnel or suffer some horrendous penalties in terms of skill, moral and much lower deployment times than normal. The risk of something breaking on a ship with drafted untrained personnel should be significantly higher too.

Very interesting concept.

I watched 'The Cruel Sea' last night (excellent 1953 B&W film - recommended viewing). I have a seen it several times over the years but hadn't watched it for a while. It starts with the newly-built Flower class corvette (escort vessel of about 1000 tons) Compass Rose and her newly trained crew in 1939 as they embark on the Battle of the Atlantic. The captain is from the merchant navy, the other officers have a few weeks training and most of the crew have never been to sea before.

The concept of gearing up for war and turning civilians into professional navy officers and crew is something that would be interesting to simulate in more depth than the current mechanics. I'll give it some thought.

All for that kind of thing providing it doesn't impact the freedom to produce ships, see how they work out and potentially having to abandon them or see them destroyed by external forces due to designs not performing quite as intended (Or from design errors).

Experimenting with designs to see what works and coming up with interesting compositions is quite a strong draw point for me with Aurora, and general crew with any degree of competence for ships being turned into some kind of consumable resource would probably dampen the creation side of things and encourage the recycling of the same tried and true designs over and over every campaign rather than risk being faced with not having enough crew to field ships if you suddenly need them without just sitting skipping forward months/years of time.

You could always designate a design to use untrained crew and not draw from the professional pool of crew just like today. Then wait for that crew to acquire skill on their own. Alternatively you could have the skill level of professional crew low so the pool size are pretty high if you want a large and cheap pool OR you increase the service time at the expense of wealth costs.

Also, when you retire a ship they go back into the pool, so no harm done. You could also potentially track the average skill of the none assigned crew so this goes up if you retire a ship full of highly skilled crew, this skill are then eroded back to normal level after some time depending on the service length of your crew pool. So you might "train" the pool in cheap ships and retire them to the pool to get better average crew, but it will still cost you considerable resources and effort to do so and would not be entirely unrealistic to do so either. Many large navies keep older ships around for this very purpose in real life.

There should be many ways to deal with the issue though.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on November 25, 2019, 11:43:02 AM
It is an interesting concept and something I would embrace on a Sol/Earth/Human start but its details need to be carefully thought through so that non-human/non-Earth games are not shafted. Does a Hive Mind bug race need military academies?
Title: Re: C# Aurora v0.x Suggestions
Post by: MultiVitamin on November 25, 2019, 12:52:18 PM
Just another aesthetic suggestion but would it be possible to let us change the name for Wealth at game creation, so that instead of working with Wealth, we work with Credits, USD, Euros, etc etc. Just another suggestion to give more immersion.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 25, 2019, 03:15:21 PM
It is an interesting concept and something I would embrace on a Sol/Earth/Human start but its details need to be carefully thought through so that non-human/non-Earth games are not shafted. Does a Hive Mind bug race need military academies?

As Steve mentioned it would probably in that case be optional for that very reason. I feel the whole character system could be optional for hive type campaigns and you could just create leaders at positions at will but with much lower fixed values, including scientists.

On the other hand it is easy to role-play that academies are hatching facilities to breed certain type of hive members suitable for certain more complex and important tasks. Perhaps these creatures are more in tune with the warships biological hull and mere drones can't operate them as well. The service time are basically at which time these crew drones simply are worn out and tossed in the incinerator as they are spent and no longer useful in its task.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 25, 2019, 04:13:49 PM
Another thing I have pondered in Aurora C#... would it not be time to lift the restriction on minimum resolution of sensors at 1HS and allow from 1-20 MSP as well.

Given that you very well can build fighter craft that are very small it might be a good thing. Otherwise tiny little scout ships can become VERY difficult to find even with a dedicated RES 1 active sensor.

So a small craft with a 0.1 HS engine and and 0.3 sensor could probably be about 30-35t, this little craft would still be quite potent at detecting stuff but be very difficult to find in return given its size is so much smaller than the smallest possible resolution scanner in the game. And you might even make it even smaller.
Title: Re: C# Aurora v0.x Suggestions
Post by: Akhillis on November 25, 2019, 06:55:57 PM
It is an interesting concept and something I would embrace on a Sol/Earth/Human start but its details need to be carefully thought through so that non-human/non-Earth games are not shafted. Does a Hive Mind bug race need military academies?

A Hive Mind bug race is always going to be require a bunch of role-playing X as Y (scientists? Fleet training? Morale?).
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 26, 2019, 02:57:27 AM
Another thing I have pondered in Aurora C#... would it not be time to lift the restriction on minimum resolution of sensors at 1HS and allow from 1-20 MSP as well.

Given that you very well can build fighter craft that are very small it might be a good thing. Otherwise tiny little scout ships can become VERY difficult to find even with a dedicated RES 1 active sensor.

So a small craft with a 0.1 HS engine and and 0.3 sensor could probably be about 30-35t, this little craft would still be quite potent at detecting stuff but be very difficult to find in return given its size is so much smaller than the smallest possible resolution scanner in the game. And you might even make it even smaller.

35 tons is about 0.7 HS or equal to a size 14 missile.

Small sensors are far more effective in C# compared to VB6, especially Res-1, so it is easier to detect missiles and other small objects. As a result, I've started adding small but effective missile detection sensors to a lot more designs. Check the comparison table in this post.

http://aurora2.pentarch.org/index.php?topic=8495.msg102701#msg102701
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 26, 2019, 06:06:05 AM
Another thing I have pondered in Aurora C#... would it not be time to lift the restriction on minimum resolution of sensors at 1HS and allow from 1-20 MSP as well.

Given that you very well can build fighter craft that are very small it might be a good thing. Otherwise tiny little scout ships can become VERY difficult to find even with a dedicated RES 1 active sensor.

So a small craft with a 0.1 HS engine and and 0.3 sensor could probably be about 30-35t, this little craft would still be quite potent at detecting stuff but be very difficult to find in return given its size is so much smaller than the smallest possible resolution scanner in the game. And you might even make it even smaller.

35 tons is about 0.7 HS or equal to a size 14 missile.

Small sensors are far more effective in C# compared to VB6, especially Res-1, so it is easier to detect missiles and other small objects. As a result, I've started adding small but effective missile detection sensors to a lot more designs. Check the comparison table in this post.

http://aurora2.pentarch.org/index.php?topic=8495.msg102701#msg102701

I know... I have been staring at that for some time and made some tools to do the math for me.

The reason for my suggestion is that small sensors are also ALOT more efficient as well.

A 30t scout could reasonably have 0.3HS res 100 sensor and it would take a size 50 comparable sensor to detect that at the same range. Don't remember if you allowed smaller fuel tanks than 5000 but I think I remember the smallest being 1000 or so now for small ground fighters as they don't need that much fuel, could be fitted on a small scout as well for minimal size if that is the case and make the size even smaller than 30t.

A 0.3HS resolution 100 sensor with Strength 21, Sensitivity 11 have a range of roughly 21 million km against 5000t.

A resolution 1 sensor at size 50 would spot that small sensor scout at 21 million km. I also would need a size 15-17 EM detector to sense that scout at that range too.

I'm just looking for options to use smaller resolution active sensors as an option so these RES 1 don't need to be inflated too much to find very small scouts.

I do understand that it would also make missile detection easier, so it would be a trade off with that as a balancing issue.

I don't necessarily thing this is a problem in and of itself... I see no wrong in small scouts being very powerful as it opens the game up for more interesting scouting potential where fog of war are more pronounced.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tikigod on November 26, 2019, 07:52:25 AM
Another thing I have pondered in Aurora C#... would it not be time to lift the restriction on minimum resolution of sensors at 1HS and allow from 1-20 MSP as well.

Given that you very well can build fighter craft that are very small it might be a good thing. Otherwise tiny little scout ships can become VERY difficult to find even with a dedicated RES 1 active sensor.

So a small craft with a 0.1 HS engine and and 0.3 sensor could probably be about 30-35t, this little craft would still be quite potent at detecting stuff but be very difficult to find in return given its size is so much smaller than the smallest possible resolution scanner in the game. And you might even make it even smaller.

35 tons is about 0.7 HS or equal to a size 14 missile.

Small sensors are far more effective in C# compared to VB6, especially Res-1, so it is easier to detect missiles and other small objects. As a result, I've started adding small but effective missile detection sensors to a lot more designs. Check the comparison table in this post.

http://aurora2.pentarch.org/index.php?topic=8495.msg102701#msg102701

I know... I have been staring at that for some time and made some tools to do the math for me.

The reason for my suggestion is that small sensors are also ALOT more efficient as well.

A 30t scout could reasonably have 0.3HS res 100 sensor and it would take a size 50 comparable sensor to detect that at the same range. Don't remember if you allowed smaller fuel tanks than 5000 but I think I remember the smallest being 1000 or so now for small ground fighters as they don't need that much fuel, could be fitted on a small scout as well for minimal size if that is the case and make the size even smaller than 30t.

A 0.3HS resolution 100 sensor with Strength 21, Sensitivity 11 have a range of roughly 21 million km against 5000t.

A resolution 1 sensor at size 50 would spot that small sensor scout at 21 million km.

I'm just looking for options to use smaller resolution active sensors as an option so these RES 1 don't need to be inflated too much to find very small scouts.

I do understand that it would also make missile detection easier, so it would be a trade off with that as a balancing issue.

Would be pretty interesting if there was a branch technology tech for ECM or a similar parent technology that dealt with providing additional masking for any objects that fit within some kind of payload designation. It would essentially reflect the peak capability of your current parent masking technology tech that can't be utilised on a larger scale (For simplicity sake the point where any object has some kind of crew requirement) and on objects that do benefit from the technology it loses additional ECM bonus effectiveness with each size designation step up.

Of course it would be possible to do all of this code wise as a natural part of just how sensor detection works, but I think making it a progressive technology advancement could be more interesting from a 'game' perspective and actually introduces some kind of investment drive.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 26, 2019, 08:01:46 AM
Another thing I have pondered in Aurora C#... would it not be time to lift the restriction on minimum resolution of sensors at 1HS and allow from 1-20 MSP as well.

Given that you very well can build fighter craft that are very small it might be a good thing. Otherwise tiny little scout ships can become VERY difficult to find even with a dedicated RES 1 active sensor.

So a small craft with a 0.1 HS engine and and 0.3 sensor could probably be about 30-35t, this little craft would still be quite potent at detecting stuff but be very difficult to find in return given its size is so much smaller than the smallest possible resolution scanner in the game. And you might even make it even smaller.

35 tons is about 0.7 HS or equal to a size 14 missile.

Small sensors are far more effective in C# compared to VB6, especially Res-1, so it is easier to detect missiles and other small objects. As a result, I've started adding small but effective missile detection sensors to a lot more designs. Check the comparison table in this post.

http://aurora2.pentarch.org/index.php?topic=8495.msg102701#msg102701

I know... I have been staring at that for some time and made some tools to do the math for me.

The reason for my suggestion is that small sensors are also ALOT more efficient as well.

A 30t scout could reasonably have 0.3HS res 100 sensor and it would take a size 50 comparable sensor to detect that at the same range. Don't remember if you allowed smaller fuel tanks than 5000 but I think I remember the smallest being 1000 or so now for small ground fighters as they don't need that much fuel, could be fitted on a small scout as well for minimal size if that is the case and make the size even smaller than 30t.

A 0.3HS resolution 100 sensor with Strength 21, Sensitivity 11 have a range of roughly 21 million km against 5000t.

A resolution 1 sensor at size 50 would spot that small sensor scout at 21 million km.

I'm just looking for options to use smaller resolution active sensors as an option so these RES 1 don't need to be inflated too much to find very small scouts.

I do understand that it would also make missile detection easier, so it would be a trade off with that as a balancing issue.

Would be pretty interesting if there was a branch technology tech for ECM or a similar parent technology that dealt with providing additional masking for any objects that fit within some kind of payload designation. It would essentially reflect the peak capability of your current parent masking technology tech that can't be utilised on a larger scale (For simplicity sake the point where any object has some kind of crew requirement) and on objects that do benefit from the technology it loses additional ECM bonus effectiveness with each size designation step up.

Of course it would be possible to do all of this code wise as a natural part of just how sensor detection works, but I think making it a progressive technology advancement could be more interesting from a 'game' perspective and actually introduces some kind of investment drive.

Yes... I have already suggested more options for electronic warfare, stealth and that stuff. Larger ships should be allot better at EW than small ships in general.

I would also not mind if active sensors had to be supplied with reactors as well depending on their strength, then there is an additional use for technology that boost reactors. In the real world sensors are one of the most energy consuming pieces of equipment on ships, I would think that sensors in Aurora are no exception. They could also burn massive amounts of fuel when online as an extra logistic and limiting small scouts who are just one big active sensor. But this is a different issue and not that important.

Electronic warfare and stealth are definitely something I would like to see at some point, but I would likely want to play C# version first before anything like that is added... ;)
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on November 28, 2019, 12:56:37 AM
Even crew that you are not using should cost wealth, so just tax the economy of the total crew pool with a certain type of wealth cost every month. Even if they are not assigned they need to be constantly trained and ready to be deployed if they aren't not already.

Maybe let the player set how many they want to retain in active reserve, and let the rest go into a pool of civilian reservists, who are still available but whose training level degrades over time (representing the fact that most civilian reservists will not be keeping up full readiness). Most countries in our world maintain a civilian reserve that can be called up in time of particular exigency.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on November 28, 2019, 09:41:03 AM
I watched 'The Cruel Sea' last night (excellent 1953 B&W film - recommended viewing). I have a seen it several times over the years but hadn't watched it for a while. It starts with the newly-built Flower class corvette (escort vessel of about 1000 tons) Compass Rose and her newly trained crew in 1939 as they embark on the Battle of the Atlantic. The captain is from the merchant navy, the other officers have a few weeks training and most of the crew have never been to sea before.

The concept of gearing up for war and turning civilians into professional navy officers and crew is something that would be interesting to simulate in more depth than the current mechanics. I'll give it some thought.

Have you ever read the book (author Monsarrat)?  It's been decades since I've read it, but I remember it being excellent, especially in terms of giving a sense the powerlessness of the small escorts in the early war and how arbitrary submarine attacks on convoys were (in the sense of a torpedo hit being a bolt from the blue that they had no idea was coming).

John
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on November 28, 2019, 10:42:19 AM
I watched 'The Cruel Sea' last night (excellent 1953 B&W film - recommended viewing). I have a seen it several times over the years but hadn't watched it for a while. It starts with the newly-built Flower class corvette (escort vessel of about 1000 tons) Compass Rose and her newly trained crew in 1939 as they embark on the Battle of the Atlantic. The captain is from the merchant navy, the other officers have a few weeks training and most of the crew have never been to sea before.

The concept of gearing up for war and turning civilians into professional navy officers and crew is something that would be interesting to simulate in more depth than the current mechanics. I'll give it some thought.

Have you ever read the book (author Monsarrat)?  It's been decades since I've read it, but I remember it being excellent, especially in terms of giving a sense the powerlessness of the small escorts in the early war and how arbitrary submarine attacks on convoys were (in the sense of a torpedo hit being a bolt from the blue that they had no idea was coming).

John

I've read the beginning on Amazon, then got distracted before I bought it :)

I do plan to read it.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on November 29, 2019, 01:31:26 AM
I know... I have been staring at that for some time and made some tools to do the math for me.

The reason for my suggestion is that small sensors are also ALOT more efficient as well.

A 30t scout could reasonably have 0.3HS res 100 sensor and it would take a size 50 comparable sensor to detect that at the same range. Don't remember if you allowed smaller fuel tanks than 5000 but I think I remember the smallest being 1000 or so now for small ground fighters as they don't need that much fuel, could be fitted on a small scout as well for minimal size if that is the case and make the size even smaller than 30t.

A 0.3HS resolution 100 sensor with Strength 21, Sensitivity 11 have a range of roughly 21 million km against 5000t.

A resolution 1 sensor at size 50 would spot that small sensor scout at 21 million km. I also would need a size 15-17 EM detector to sense that scout at that range too.

I'm just looking for options to use smaller resolution active sensors as an option so these RES 1 don't need to be inflated too much to find very small scouts.

I do understand that it would also make missile detection easier, so it would be a trade off with that as a balancing issue.

I don't necessarily thing this is a problem in and of itself... I see no wrong in small scouts being very powerful as it opens the game up for more interesting scouting potential where fog of war are more pronounced.

Except even a tiny, 0.3 HS sensor with resolution 100 is still going to have a very large GPS. I'm not sure how you arrived at that number, but per my the wiki rules:

GPS = size x resolution x ASS = 0.3 x 100 x 21 = 630

So it will get detected beyond it's own range (21.80 m km) by any EM sensor with a sensitivity greater than 12.07, which is a pathetic 1.09 HS with EM sensitivity 11.

EM sensors in C# Aurora will absolutely be extremely important, since, like with Thermal sensors, their effective range actually increases if your opponents have superior sensor technology. That tiny scout of yours will get seen from well beyond it's own range by even moderately sized passive sensors, whereupon it either gets avoided, baited, or is gunned down by interceptors.

The fact is, that in C# Aurora, active sensors areloud and are very very unlikely to actually get in range of an evading enemy fleet running on passives. Ironically, this makes thermal sensors more important - when lighting up actives is suicide, EM passives become useless as no one dares to do so unless they have a definite advantage, and only thermal sensors can actually see anything.

But even so, you can still have scouts along one vector directing missile fire from fleets approaching in a completely different vector, which seems a bit cheesy, given how small scouts can get. I think some sort of range limit for fire direction might be useful, where a fleet has to be withing x range of a scout for it to actually be able to send them targeting information. Maybe some sort of transmitter and/or receiver components?
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 29, 2019, 02:16:03 AM
I know... I have been staring at that for some time and made some tools to do the math for me.

The reason for my suggestion is that small sensors are also ALOT more efficient as well.

A 30t scout could reasonably have 0.3HS res 100 sensor and it would take a size 50 comparable sensor to detect that at the same range. Don't remember if you allowed smaller fuel tanks than 5000 but I think I remember the smallest being 1000 or so now for small ground fighters as they don't need that much fuel, could be fitted on a small scout as well for minimal size if that is the case and make the size even smaller than 30t.

A 0.3HS resolution 100 sensor with Strength 21, Sensitivity 11 have a range of roughly 21 million km against 5000t.

A resolution 1 sensor at size 50 would spot that small sensor scout at 21 million km. I also would need a size 15-17 EM detector to sense that scout at that range too.

I'm just looking for options to use smaller resolution active sensors as an option so these RES 1 don't need to be inflated too much to find very small scouts.

I do understand that it would also make missile detection easier, so it would be a trade off with that as a balancing issue.

I don't necessarily thing this is a problem in and of itself... I see no wrong in small scouts being very powerful as it opens the game up for more interesting scouting potential where fog of war are more pronounced.

Except even a tiny, 0.3 HS sensor with resolution 100 is still going to have a very large GPS. I'm not sure how you arrived at that number, but per my the wiki rules:

GPS = size x resolution x ASS = 0.3 x 100 x 21 = 630

So it will get detected beyond it's own range (21.80 m km) by any EM sensor with a sensitivity greater than 12.07, which is a pathetic 1.09 HS with EM sensitivity 11.

EM sensors in C# Aurora will absolutely be extremely important, since, like with Thermal sensors, their effective range actually increases if your opponents have superior sensor technology. That tiny scout of yours will get seen from well beyond it's own range by even moderately sized passive sensors, whereupon it either gets avoided, baited, or is gunned down by interceptors.

The fact is, that in C# Aurora, active sensors areloud and are very very unlikely to actually get in range of an evading enemy fleet running on passives. Ironically, this makes thermal sensors more important - when lighting up actives is suicide, EM passives become useless as no one dares to do so unless they have a definite advantage, and only thermal sensors can actually see anything.

But even so, you can still have scouts along one vector directing missile fire from fleets approaching in a completely different vector, which seems a bit cheesy, given how small scouts can get. I think some sort of range limit for fire direction might be useful, where a fleet has to be withing x range of a scout for it to actually be able to send them targeting information. Maybe some sort of transmitter and/or receiver components?

I calculated correctly with the EM I just brainfarted and used size instead of sensitivity... ;)

As for lighting up that is a none issue as you are using such sensor craft to put active sensor on an already detected enemy... and a cheap one at that. You could use multiple sensor scouts at multiple vectors and only light them up briefly before turning of the sensor and move to another position. All the while missiles are inbound.

And how do you know they are not a cheap bait for your interceptors... ;)

Given how small and cheap they are it is efficient.

I agree that passive sensor are more important as finding the enemy before you are found yourself is key.

But these really small sensor crafts will be efficient in that they are stealth when they turn the sensor off. An active only need to be on for a few seconds to get data.., you don't run around with them on all the time. Even a small escort could have many such small scouts to send out in active patrols instead or as complement to passive scouting.

Since they are smaller than 50 ton they will be really hard to engage as they are very hard to find. It will also be very cheap with stealthy engines o  such small ships so they are very hard to find on thermal sensors too.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on November 29, 2019, 03:23:32 AM

I calculated correctly with the EM I just brainfarted and used size instead of sensitivity... ;)

As for lighting up that is a none issue as you are using such sensor craft to put active sensor on an already detected enemy... and a cheap one at that. You could use multiple sensor scouts at multiple vectors and only light them up briefly before turning of the sensor and move to another position. All the while missiles are inbound.

And how do you know they are not a cheap bait for your interceptors... ;)

Given how small and cheap they are it is efficient.

I agree that passive sensor are more important as finding the enemy before you are found yourself is key.

But these really small sensor crafts will be efficient in that they are stealth when they turn the sensor off. An active only need to be on for a few seconds to get data.., you don't run around with them on all the time. Even a small escort could have many such small scouts to send out in active patrols instead or as complement to passive scouting.

Since they are smaller than 50 ton they will be really hard to engage as they are very hard to find. It will also be very cheap with stealthy engines o  such small ships so they are very hard to find on thermal sensors too.

You'll need so many of them that it'll be inefficient. For painting a fleet when you already know it's exact position, sure, it might be useful to have lots of tiny scouts, but they're never going to keep up with any serious battlefleet because they're going to end up with minimal speed and endurance. Which is pretty much the exact opposite of what you wan for reconnaissance or patrol activities.

Flicking on the active sensors momentarily doesn't mean that an opponent in range won't see the EM surge and investigate. A gunship with reduced-size gauss cannons and reasonably boosted engines is both very inexpensive and hard to counter without defensive assets that will end up presenting a larger target to track, and can be reasonably expected to get close enough that subsequent pulses will paint a bright red target on the scout. A moderately-sized fleet can easily carry dozens of these things. Even bog-standard railgun PD fighters can be easily re-purposed to go scout hunting in a pinch.

And how exactly do you expect to maintain continuous sensor coverage from multiple vectors on a target that will certainly be random-walking itself, and will also be able to see your sensor from maybe twice it's own range? You're assuming that these scouts can effectively surround a likely faster and more endurant enemy, and will know exactly when they are in range so they can activate their actives at the exact same time. They're also going to be completely useless against smaller vessels.

Here's how this will go. You launch fifty of these scout boats and manoeuvre them into place. Combined, they can search an area of
74,753 quadrillion square kilometres. Except that's a circle with a radius of about one AU. Oops? You are absolutely not going to be able to find a hostile vessel hidden in any moderately-sized star system by running around blind with only moments of sensor coverage. Not before it sees you first, and avoids you or guns you down.

With how much C# will increase fog-of-war, running down any long-endurance enemy ghost fleets in a system is going to be an utter nightmare. Clearing systems is going to be very, very painful for an attacker and you can never quite be sure there won't be a minefield suddenly appearing amongst your convoy routes.


Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on November 29, 2019, 02:34:26 PM

I calculated correctly with the EM I just brainfarted and used size instead of sensitivity... ;)

As for lighting up that is a none issue as you are using such sensor craft to put active sensor on an already detected enemy... and a cheap one at that. You could use multiple sensor scouts at multiple vectors and only light them up briefly before turning of the sensor and move to another position. All the while missiles are inbound. Given how small and stealthy (reduced thermal engines are easy to give these) they are it is very hard to find them once their sensor is off.

And how do you know they are not a cheap bait for your interceptors... ;)

Given how small and cheap they are it is efficient.

I agree that passive sensor are more important as finding the enemy before you are found yourself is key.

But these really small sensor crafts will be efficient in that they are stealth when they turn the sensor off. An active only need to be on for a few seconds to get data.., you don't run around with them on all the time. Even a small escort could have many such small scouts to send out in active patrols instead or as complement to passive scouting.

Since they are smaller than 50 ton they will be really hard to engage as they are very hard to find. It will also be very cheap with stealthy engines o  such small ships so they are very hard to find on thermal sensors too.

You'll need so many of them that it'll be inefficient. For painting a fleet when you already know it's exact position, sure, it might be useful to have lots of tiny scouts, but they're never going to keep up with any serious battlefleet because they're going to end up with minimal speed and endurance. Which is pretty much the exact opposite of what you wan for reconnaissance or patrol activities.

Flicking on the active sensors momentarily doesn't mean that an opponent in range won't see the EM surge and investigate. A gunship with reduced-size gauss cannons and reasonably boosted engines is both very inexpensive and hard to counter without defensive assets that will end up presenting a larger target to track, and can be reasonably expected to get close enough that subsequent pulses will paint a bright red target on the scout. A moderately-sized fleet can easily carry dozens of these things. Even bog-standard railgun PD fighters can be easily re-purposed to go scout hunting in a pinch.

And how exactly do you expect to maintain continuous sensor coverage from multiple vectors on a target that will certainly be random-walking itself, and will also be able to see your sensor from maybe twice it's own range? You're assuming that these scouts can effectively surround a likely faster and more endurant enemy, and will know exactly when they are in range so they can activate their actives at the exact same time. They're also going to be completely useless against smaller vessels.

Here's how this will go. You launch fifty of these scout boats and manoeuvre them into place. Combined, they can search an area of
74,753 quadrillion square kilometres. Except that's a circle with a radius of about one AU. Oops? You are absolutely not going to be able to find a hostile vessel hidden in any moderately-sized star system by running around blind with only moments of sensor coverage. Not before it sees you first, and avoids you or guns you down.

With how much C# will increase fog-of-war, running down any long-endurance enemy ghost fleets in a system is going to be an utter nightmare. Clearing systems is going to be very, very painful for an attacker and you can never quite be sure there won't be a minefield suddenly appearing amongst your convoy routes.

I have done this MANY times in the current version of Auroa as well... these small scouts are generally faster, some times much faster than larger ships. They are often relatively short range though and even shorter range in C#.

These small sensors are way more efficient than a comparable larger sensor so you can have more of them. That is the whole purpose of the new change to the system as you need to quadruple the size of the sensor to scan twice as far.

You keep continuous sensor coverage with using a few scouts that paint the target in turns if necessary, long enough for missile strikes to hit. About 20 million km is a pretty far distance for such a small craft. Even loosing one or two will make little impact on your ability to scout.

And yes, small scouts are very likely to be much faster than a standard warship, at least in the context I usually see them as they trade speed for range. As they are launched from a carrier they don't need efficient engines or endurance. A 10t 2-3x engine on a 30-35t craft will make it go really fast. These scouts are NOT long range or endurance ships. They are small fast scouts with a specific purpose, speed and stealth are their defences.

If a fleet start seeing pings of dozens of small scouts in an area they can certainly avoid that area, that can also be the intention when you then funnel an enemy into a different area where you placed your passive scouts. They don't need to cover an area fully either as no sane admiral would fly their capital ships in the general direction and risk being detected as you don't know where the scouts are or will be. So a handful of scouts would be able to cover a pretty large area by making random searches here and there. It might also be a trap to go after them as well, how do you know?!?

Is it worth the risk destroying an extremely cheap little 30-35t scout and risk loosing something way more expensive.

You also DON'T search in squares or circles, the whole purpose with more space efficient sensors is that you search in LINES or at least layered lines, that means a small sensor are four times more effective than comparable large sensors if they are all of the same speed. I really don't understand why you would scan an entire system like this, this is a tactical tool not a strategical. It is for when you know the general area of an opponent, these scouts don't replace passive scouts, buoys, stations or ships. They are a tactical tool with a specific use. Why do you assume they are used in the attack role... I don't think it matters if they are used offensively or defensively.

There are many fun ways they could be used with other assets.

So, the reason I asked for lower resolution sensors was that you could more easily paint such craft from a distance and shoot them down with small AMM like missiles. In the current form the only option is more or less a beam interceptor. The smallest beam interceptor are likely to be at least about 75-100 ton or so as the smallest Gauss is 25t for the weapon itself and then you need a fire-control, engine, fuel etc.

Against the AI all these points are moot as they will clearly be OP against the AI no matter what, even more so than in VB6 Aurora. I'm talking about multi-faction games where several sides are human controlled.
Title: Re: C# Aurora v0.x Suggestions
Post by: Ciphascain on December 06, 2019, 02:30:20 AM
For the infantry it might be cool if there was a powered and in powered infantry version.  So I could build lots of cheap unpowered infantry for some things and have an elite core of powered armoires infantry (I. e 40k).  Might not be the biggest thing but would be nice for rp purposes. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 06, 2019, 03:13:34 AM
There already are different armour options for infantry that could represent regular or power armoured infantry.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 06, 2019, 03:26:30 AM
For the infantry it might be cool if there was a powered and in powered infantry version.  So I could build lots of cheap unpowered infantry for some things and have an elite core of powered armoires infantry (I. e 40k).  Might not be the biggest thing but would be nice for rp purposes.

Here is an excerpt from my current c# test campaign:

Research into Improved Genetic Enhancement was completed in Y2505. With the new technology available, a new type of solder, the Space Marine, was created by Terran geneticists. Equipped with new heavy powered infantry armour, trained in boarding combat and armed with a heavy bolter that had the same firepower as a crew-served anti-personnel weapon, the Space Marine was a formidable warrior. The Terminator Space Marine was even more heavily armed and carried a Storm Bolter, which had equivalent firepower to the secondary weapon of a Leman Russ battle tank. The first Space Marine formations to be trained would be Assault Forces of thirty Space Marines, six Terminator Space Marines and two command personnel. A single Thunderhawk assault transport would carry each Assault Force. As a strike cruiser had three such transports with over a hundred Space Marines in total, the force assigned to each strike cruiser would be known as a Space Marine Company.

Space Marine
Transport Size (tons)  12     Cost  2.4     Armour  16     Hit Points  12.8
Annual Maintenance Cost  0.3     Resupply Cost  6
Crew-Served Anti-Personnel:      Shots 6      Penetration 10      Damage 10
Boarding Combat
Improved Genetic Enhancement

Terminator Space Marine
Transport Size (tons)  20     Cost  4     Armour  16     Hit Points  12.8
Annual Maintenance Cost  0.5     Resupply Cost  9
Heavy Crew-Served Anti-Personnel:      Shots 6      Penetration 15      Damage 10
Boarding Combat
Improved Genetic Enhancement


http://aurora2.pentarch.org/index.php?board=266.0
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on December 06, 2019, 10:50:50 AM

So, the reason I asked for lower resolution sensors was that you could more easily paint such craft from a distance and shoot them down with small AMM like missiles. In the current form the only option is more or less a beam interceptor. The smallest beam interceptor are likely to be at least about 75-100 ton or so as the smallest Gauss is 25t for the weapon itself and then you need a fire-control, engine, fuel etc.


Oh, well. . . in that case, no.  I am against anything that makes missiles more effective.  Especially at the cost of beams.  I think that pendulum has already swung much too far in favour of missiles.
Title: Re: C# Aurora v0.x Suggestions
Post by: Ciphascain on December 06, 2019, 11:32:00 AM
Quote from: Steve Walmsley link=topic=9841. msg117265#msg117265 date=1575624390
Quote from: Ciphascain link=topic=9841. msg117263#msg117263 date=1575621020
For the infantry it might be cool if there was a powered and in powered infantry version.   So I could build lots of cheap unpowered infantry for some things and have an elite core of powered armoires infantry (I.  e 40k).   Might not be the biggest thing but would be nice for rp purposes. 

Here is an excerpt from my current c# test campaign:

Research into Improved Genetic Enhancement was completed in Y2505.  With the new technology available, a new type of solder, the Space Marine, was created by Terran geneticists.  Equipped with new heavy powered infantry armour, trained in boarding combat and armed with a heavy bolter that had the same firepower as a crew-served anti-personnel weapon, the Space Marine was a formidable warrior.  The Terminator Space Marine was even more heavily armed and carried a Storm Bolter, which had equivalent firepower to the secondary weapon of a Leman Russ battle tank.  The first Space Marine formations to be trained would be Assault Forces of thirty Space Marines, six Terminator Space Marines and two command personnel.  A single Thunderhawk assault transport would carry each Assault Force.  As a strike cruiser had three such transports with over a hundred Space Marines in total, the force assigned to each strike cruiser would be known as a Space Marine Company.

Space Marine
Transport Size (tons)  12     Cost  2. 4     Armour  16     Hit Points  12. 8
Annual Maintenance Cost  0. 3     Resupply Cost  6
Crew-Served Anti-Personnel:      Shots 6      Penetration 10      Damage 10
Boarding Combat
Improved Genetic Enhancement

Terminator Space Marine
Transport Size (tons)  20     Cost  4     Armour  16     Hit Points  12. 8
Annual Maintenance Cost  0. 5     Resupply Cost  9
Heavy Crew-Served Anti-Personnel:      Shots 6      Penetration 15      Damage 10
Boarding Combat
Improved Genetic Enhancement


hxxp: aurora2. pentarch. org/index. php?board=266. 0

Oh I just saw the genetic  Enhancements  that’s awesome thank you
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on December 06, 2019, 03:18:44 PM
In all seriousness can we just say that aurora TN beams are FTL and therefore can have range beyond the distance light can travel in 5 second increments?  The sensors are already FTL, so there is clearly some way to physically interact with stuff at FTL speeds.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 06, 2019, 04:12:21 PM
In all seriousness can we just say that aurora TN beams are FTL and therefore can have range beyond the distance light can travel in 5 second increments?  The sensors are already FTL, so there is clearly some way to physically interact with stuff at FTL speeds.

To be honest I think beams work just fine as is. Beam weapons are still important weapon systems as you don't want ships to be totally defenceless when missiles fail and they are really good for defending a specific point in place such as planets or jump points or used as bombardment weapons.

I don't thin there is anything in particular wrong with missiles being a better weapon for general space superiority purposes.

C# will close the gap and range quite significantly between the two as well so the dynamic might actually change more than we know. With general scouting becoming more of a hide and seek question then beam weapons might become even more important as well, I think we will have to wait and see how the new dynamic will play out.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 06, 2019, 04:20:36 PM
In all seriousness can we just say that aurora TN beams are FTL and therefore can have range beyond the distance light can travel in 5 second increments?  The sensors are already FTL, so there is clearly some way to physically interact with stuff at FTL speeds.

The 5 second limit isn't because of light speed - that is just the convenient technobabble.

The real reason is that longer-range beams would unbalance the game. Currently, if you are out-ranged in a beam conflict, you at least have the chance to build faster ships and close the range. You'll take damage, but it isn't game over. If beam ranges become much longer, then speed becomes irrelevant and longest range wins every time.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on December 06, 2019, 05:41:48 PM
That kind of reminds me of battleship combat honestly, like how the British navy had fast big gun battleships during the great war and said 'speed is our armor', then they suffered a rather severe defeat where some idiot admiral willingly chose to close the distance in spite of that being completely against doctrine.

e: https://en.wikipedia.org/wiki/Battle_of_Jutland

Overall makes sense though I suppose.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on December 06, 2019, 07:15:21 PM
Great Britain didn't have fast big gun battleships in that battle.

Great Britain had a doctrine which fielded battlecruisers; long ranged, fast ships with relatively big guns. But when designing ships you are trading on 3 traits in a given displacement; speed, protection, firepower. The British battlecruisers focused on speed and firepower, and were never meant to get into the battleship line. Rather, they were supposed to beat off enemy cruisers and battleships when in the cruiser line, focusing particularly on the cruisers and stalling the battleships from closing in while friendly battleships moved in to take over.

Jutland however, saw those low armour battlecruisers face off against battleships, with similar bore guns but much better protection. This then combined with British doctrine requiring as rapid fire as possible, causing a number of munitions handling safety regulations to be systematically ignored meant that whenever a German ship managed to land a hefty enough blow on a British battlecruiser's turret and penetrate, ignite the stacked propellant and shells in the turret itself, and that fire then flashed down into the magazine spaces, igniting the propellant and shells there.

The results were to be expected with the magazines blowing up. Having your magazine blow up inside your ship tends to do horrible things to the ship, so...


Had those battlecruisers faced off against enemy cruisers, which generally fielded smaller guns to the battlecruisers and would have difficulty penetrating, but with similar armour protection facing off against the battlecruisers' bigger guns, the battlecruisers would've done pretty well for themselves.

It's notable that while the German fleet got pretty heavily damaged, they lost fewer ships and IIRC much fewer crew than the British did.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 06, 2019, 07:47:51 PM
Yes... the battle of Jutland was a huge example of command failure and not a specific ship design being bad. If you use a the wrong tool for the job you might also expect the results to match.

Even if Great Britain walked of with a strategic victory it was a tactical blunder and embarrassment.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on December 07, 2019, 02:09:46 AM
In all seriousness can we just say that aurora TN beams are FTL and therefore can have range beyond the distance light can travel in 5 second increments?  The sensors are already FTL, so there is clearly some way to physically interact with stuff at FTL speeds.

The 5 second limit isn't because of light speed - that is just the convenient technobabble.

The real reason is that longer-range beams would unbalance the game. Currently, if you are out-ranged in a beam conflict, you at least have the chance to build faster ships and close the range. You'll take damage, but it isn't game over. If beam ranges become much longer, then speed becomes irrelevant and longest range wins every time.

Could we get that made optional?

Shields will go a long way towards mitigating the difference.  Whats more, assuming we simply get increased multipliers on FC's to be able to use the full range of weapons, the MSP, resource, and research costs become absolutely insane.

A max tech advanced spinal might have a 45mkm range, but over about 22mkm it does a paltry 1 damage, on a 80 second recharge, which means 0.0125dps on less than 50% chance to hit, a single shield 2 tiers from max has 10 HP and 300 second recharge, which lets it regen with 0.0333hp/s on 100% chance.  Long range, a single shield cannot be broken by three lasers, much less one.

If we go with 80cm far gamma capacitor 25 RoF 35 lasers, so we can stack more than one(without gamey tricks), you'd need an FC that can reach 20.16mkm.  That's a 121x multiplier on an FC, about 30 times the current maximum.  That suggests an MSP repair cost of about 80,000, and an equally absurd resource and research cost to produce.

Bring 10 such lasers along, you get 10 damage across nearly half your range, and that is with low chances to hit targets, less than 50% out beyond the rated FC range. If we assume an average around 37.5%, which works out to range around 12.6mkm, you only get 0.0107 damage per second per laser, 0.107 total.  We can easily resist this indefinitely with just 4 shields.

Suppose our opponent could only muster 60cm near gamma capacitor 16 RoF 30, and brings 10 of those, an all things equal sort of ship.  They're 300 tons lighter, so they could, if they wanted, spend that mass on shields, which nets them 60 shields.    it gets better, they don't need a 121x multiplier on their FC, so if we step down 2 tiers in tech, then its not 175kkm, its 125kkm, and they don't need 20.16mkm range, they only need 9.4, so a 76 multiplier.  The FC is 550 tons lighter, which is another 10 shields we can bring along.

If we assume the shields are also 2 tiers down, thats 10hp and 300s to recharge.  Those can reliably recharge at 0.0333 hp/sec, and there are 70 of them, for a combined 2.333hp/sec, and 700hp of resistance.  The 80cm lasers cannot hurt it at long range.  They cannot penetrate the shielding until you close to around 2.01mkm, as they start doing 10 damage apiece, when they reach an average of 2.572dmg/sec.  For a sanity check, 10/35 is 0.29 damage per second each, or 2.9 damage per second for 10 weapons.  At 10% of range, so 90% hit chance for an equivalent range FC, as above, which lowers the average sustained to 2.6, rounding errors.

We can resist as long as we wish pretty much. 

Lets make it an 1.4mkm, current maximum.  They hit for 14 damage apiece, averaging 3.72dps overall.  We can resist that for 9.4 minutes.

Those were 7.1 shields, its even better with c# shields.  We get 70HS of shielding, lets run 2x35 HS, which if I understand things correctly, means it'd be (under the same hp/tech, which I am unsure of) 187.1% stronger than standard, which means instead of 700hp, we get 1310hp, but the same basic rate(because the shields take proportionally longer to recharge fully).  Now we can resist for 17.65 minutes.

If you're only 1.4mkm out, how much harm could we do in return with 10 60cm lasers?  Well, 10 60cm Near Gamma with capacitor 16, 2 tiers down in all relevant tech, reach to 9.4mkm.  We can hit back.  Whats more, we can hit fairly strongly too, managing 2.553 damage per second, in salvos that average 51.1 damage, each laser doing 6 damage on 85% chance to hit.

Every second the fight goes on at 1.4mkm, they do more damage than we do, but they have more shields to shields to work through than we do.  By the time they bust down our shields, after 17.65 minutes, we've had 35 salvos, and done 1788 damage to armor/hull.  The max tech advanced spinal isn't any help either, just 32 damage at 1.4mkm, on an 80 second recharge, for 0.387dmg/sec, we can resist that indefinitely.

If we have weaker energy weaponry, we just need more shielding than they have, to force them to come closer to overcome our shielding, which lets us hit back.  Having enough shields brings them close enough that we can also bring their shields down.

Shields can force the main fighting to be within 5 light seconds anyways.

I don't see the problem.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on December 07, 2019, 03:03:25 AM
Shields can force the main fighting to be within 5 light seconds anyways.

I don't see the problem.

And how well does those shields work against particle beams ( which retain full damage out to max range ) or against mesons ( which ignore shields )?
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on December 07, 2019, 06:35:09 AM
Shields can force the main fighting to be within 5 light seconds anyways.

I don't see the problem.

And how well does those shields work against particle beams ( which retain full damage out to max range ) or against mesons ( which ignore shields )?

If the particle beams are on the attack?  They cap out at 1.2mkm.  They can afford to force you in closer by having a vastly cheaper FC and cheaper weaponry, in tonnage terms.

If the Particle beam ship is the one needing to weather the storm to get its kill, then with you can match their 15.5kton investment into destruction on a smaller investment of just 8200 tons with an 8x FC getting you 7300 tons to spend on shielding if your need to to force them closer.  That lets a 25 damage 20 RoF 800 ton particle beam, with 10 on one ship, output 250 damage at 65% odds at 700kkm, for a sustained 8.125 damage per second, and a whopping 146 shields, for the same tonnage budget.

Do note that I've ignored the cost of carrying enough MSP to ever manage a single repair of the only firecontrol on the ship, which swings things further towards the inferior tech shield heavy ship.  80,000 MSP costs you quite a bit of tonnage, its just far too messy to work out in excel.

So, you get 4x36hs shields.  Which means you have 1440 hp base, at 189.7% strength for 2732hp more shielding than them, and 4.8hp/sec regen.  This lets you sustain the abuse indefinitely beyond 1.1mkm, or last for 15.595 minutes at 700kkm over which you can do 11500 damage with strength 25 hits.

If they could kite you to death now, then they still can, with a narrow 300,000 window to do it in where you cannot respond.  If you can get the closure to 1000km/s, you can close that gap in just 300 seconds, 5 minutes, you'll survive 15+.



Mesons get to play with ranges up to 10.08mkm, you are gonna get a little chewed up on the way in.  Have HTK to spare.  Spend your excess, if any, on armor.  To have that range, they'll need an FC of at least 10.08mkm, a multiplier of 58, for an FC tonnage of 1450, and 10 weapons, at 1250 tons, it costs them 13950 tons.

Now, one would think that mesons bypassing shields and armor become king.  Except, in c# they don't entirely bypass armor, they may be stopped by it, you can weather this storm, somewhat.  7% chance to not penetrate at maximum tech, 93% chance they do penetrate per layer of armor.  You can make a max tech warship at around 35ktons easily enough.  Putting 6 layers of armor, 6 shields, 2 16HS x2.15 engines, and 14 Large fuel + 1 Normal gives a 35kt warship that can do 70kkm/s over 20bkm and still have 22ktons for mission package.  Plenty of headroom to load the 15.5kton weapons package above. 

So lets drop two engine tiers to plasma core engines, .16 fuel, and drop two tiers in armor. 35ktons, 9 45hs x3.0 engines, and 53 Normal Fuel tanks, and I get a warship that can do 106.5kkms over 9.5bkm 10 particle beams as above.  6 layers of armor leaves just enough mission package to carry adequate MSP and a simple sensor, very short endurance.  We've a closure of 36kkm/s if they attempt to run.  A lucky strike could send us packing, we can lose 2 engines before they can close in on us.

We can close the range in 260 seconds, or 7 firing cycles before we can retaliate.  So I will assume they get shots every 1340kkm of range closed in, starting from 1000kkm outwards, so the first shot as closing would occur at 10.076mkm.  They have a 93% chance to penetrate armor per layer and we have 6 layers, so they have a 64.7% chance of getting an internal hit per actual hit, they've got 10 weapons.  The first salvo at 9.04mkm nets 0.667 hits, 7.7mkm nets 1.53 hits, 6.36 nets 2.39, 5.02 -> 3.24, 3.68 -> 4.1, 2.34 -> 4.97, 1 -> 5.83, sum total of 22.7 hits, call it 23.

We have 207HTk in just engines, comprising 69.9% of all hits.  50HTk in fuel, 44 HTK in crew, 12 in engineering.  In DAC, 415-558 is particle beams, 562-565 is fire control, 610 is search sensor, 674-682 are reactors.  Those comprise just 155, out of a total of 686, or 77.4% of internal hits are going to be absorbed by systems not critical to killing the opponent - though engines can really only afford one loss.

She's short legged, but can win her fight by taking 65% engine/fuel, can't go hunting, but if they come to her...



Can you overcome a min-maxed warship on the same tonnage that has tech advantage?  Probably not.  Can you build a tech disadvantaged warship to kill an advantaged warship?  Absolutely.  Can two ships of equal tech deal with their shortcomings?  Certainly.

Only way the Meson holds its range advantage for same tech, is equal or greater investment into engines, or lesser tonnage.  Both require you decrease weaponry, c# imposes a penalty to having few rapidly firing weapons, that 2% failure will bite you.  Over 34 shots, its 50/50 that a weapon fails.  The Meson wants its range, it needs to splurge on an FC, that hands the speed advantage, or the quantity advantage, or the defence advantage tot he competitor.

To get that disadvantaged in a fight between equals, one of you wasn't teching at all, or the other was handed the advantage as a handicap.

I still don't see this as the insurmountable task its been made to be. 

See attached for the particle beam/meson warships specc'ed out.  Keep in mind I stacked multiple FC's to consume tonnage as if it were bigger—as if the multiplier allowed such ranges, and over stocked MSP to allow replacement of the FC, which is the biggest cost in both ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 07, 2019, 08:51:01 AM
Shields can force the main fighting to be within 5 light seconds anyways.

I don't see the problem.

And how well does those shields work against particle beams ( which retain full damage out to max range ) or against mesons ( which ignore shields )?

If the particle beams are on the attack?  They cap out at 1.2mkm.  They can afford to force you in closer by having a vastly cheaper FC and cheaper weaponry, in tonnage terms.

If the Particle beam ship is the one needing to weather the storm to get its kill, then with you can match their 15.5kton investment into destruction on a smaller investment of just 8200 tons with an 8x FC getting you 7300 tons to spend on shielding if your need to to force them closer.  That lets a 25 damage 20 RoF 800 ton particle beam, with 10 on one ship, output 250 damage at 65% odds at 700kkm, for a sustained 8.125 damage per second, and a whopping 146 shields, for the same tonnage budget.

Do note that I've ignored the cost of carrying enough MSP to ever manage a single repair of the only firecontrol on the ship, which swings things further towards the inferior tech shield heavy ship.  80,000 MSP costs you quite a bit of tonnage, its just far too messy to work out in excel.

So, you get 4x36hs shields.  Which means you have 1440 hp base, at 189.7% strength for 2732hp more shielding than them, and 4.8hp/sec regen.  This lets you sustain the abuse indefinitely beyond 1.1mkm, or last for 15.595 minutes at 700kkm over which you can do 11500 damage with strength 25 hits.

If they could kite you to death now, then they still can, with a narrow 300,000 window to do it in where you cannot respond.  If you can get the closure to 1000km/s, you can close that gap in just 300 seconds, 5 minutes, you'll survive 15+.



Mesons get to play with ranges up to 10.08mkm, you are gonna get a little chewed up on the way in.  Have HTK to spare.  Spend your excess, if any, on armor.  To have that range, they'll need an FC of at least 10.08mkm, a multiplier of 58, for an FC tonnage of 1450, and 10 weapons, at 1250 tons, it costs them 13950 tons.

Now, one would think that mesons bypassing shields and armor become king.  Except, in c# they don't entirely bypass armor, they may be stopped by it, you can weather this storm, somewhat.  7% chance to penetrate at maximum tech, per layer of armor.  At max tech, you can make the max tech warship at around 35ktons easily enough.  For a 35kton warship, putting 6 layers of armor, 6 shields, 2 16HS x2.15 engines, and 14 Large fuel + 1 Normal gives a 35kt warship that can do 70kkm/s over 20bkm and still have 22ktons for mission package.  Plenty of headroom to load the 15.5kton weapons package above. 

So lets drop two engine tiers to plasma core engines, .16 fuel, and drop two tiers in armor. 6 layers of armor, 6 shields, 35ktons, 9 45hs x3.0 engines, and 53 Normal Fuel tanks, and I get a warship that can do 106.5kkms over 9.5bkm 10 particle beams as above.  Drop the shields and raise to sit at 6 layers of armor leaves just enough mission package to carry adequate MSP and a simple sensor, very short endurance.  We've a closure of 36kkm/s if they attempt to run.  A lucky strike could send us packing, we can lose 2 engines before they can close in on us.

We can close the range in 260 seconds, or 7 firing cycles before we can retaliate.  So I will assume they get shots every 1340kkm of range closed in, starting from 1000kkm outwards, so the first shot as closing would occur at 10.076mkm.  They have a 93% chance to penetrate armor per layer and we have 6 layers, so they have a 64.7% chance of getting an internal hit per actual hit, they've got 10 weapons.  The first salvo at 9.04mkm nets 0.667 hits, 7.7mkm nets 1.53 hits, 6.36 nets 2.39, 5.02 -> 3.24, 3.68 -> 4.1, 2.34 -> 4.97, 1 -> 5.83, sum total of 22.7 hits, call it 23.

We have 207HTk in just engines, comprising 69.9% of all hits.  50HTk in fuel, 44 HTK in crew, 12 in engineering.  In DAC, 415-558 is particle beams, 562-565 is fire control, 610 is search sensor, 674-682 are reactors.  Those comprise just 155, out of a total of 686, or 77.4% of internal hits are going to be absorbed by systems not critical to killing the opponent - though engines can really only afford one loss.

She's short legged, but can win her fight by taking 65% engine/fuel, can't go hunting, but if they come to her...



Can you overcome a min-maxed warship on the same tonnage that has tech advantage?  Probably not.  Can you build a tech disadvantaged warship to kill an advantaged warship?  Absolutely.  Can two ships of equal tech deal with their shortcomings?  Certainly.

Only way the Meson holds its range advantage for same tech, is equal or greater investment into engines, or lesser tonnage.  Both require you decrease weaponry, c# imposes a penalty to having few rapidly firing weapons, that 2% failure will bite you.  Over 34 shots, its 50/50 that a weapon fails.  The Meson wants its range, it needs to splurge on an FC, that hands the speed advantage, or the quantity advantage, or the defence advantage tot he competitor.

To get that disadvantaged in a fight between equals, one of you wasn't teching at all, or the other was handed the advantage as a handicap.

I still don't see this as the insurmountable task its been made to be. 

See attached for the particle beam/meson warships specc'ed out.  Keep in mind I stacked multiple FC's to consume tonnage as if it were bigger—as if the multiplier allowed such ranges, and over stocked MSP to allow replacement of the FC, which is the biggest cost in both ships.

I hope that fire-control is hardened if the ship is ever hit by a Microwave weapon....  far more dangerous to such ships than any other weapon.  ;)

I probably agree that there would not be a huge problem... but if these extreme beams was unleashed I think you should also add some penalty or bonus to hit based on ship size. Otherwise small ships might get really shafted as you focus fire easily on them with weaker shields, not to mention really small ships or fighters being even worse.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on December 07, 2019, 10:36:02 AM
Definitely a concern.  Smaller ships have less ability to counter punch at range, or to take the abuse until they can.  They can't mass enough armor to take abuse, nor enough shields to shrug it off.  Nor can fighters compete for ECM/ECCM, generally either 10% behind with compact, or way 30% behind with compact.

That said, they almost always have a significant closure and numbers advantage.  You can hit 180kkms and still pack beam weapons if you want to, closing at speeds that make most missiles seem slow.  Those speeds can push their hit chances below 50% point blank, and worse at range.



Agreed on "fear the microwave" if you don't harden the hell out of an FC that big — you're begging to get it blotted out, microwaves have some reach, lol.  If you built to counter microwaves, you likely went shield heavy, and Meson's can gut you.  Build for Meson and you might lack enough shielding to help against microwaves, lol.  Build for both, master neither.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on December 08, 2019, 10:25:23 AM
Thinking of the mineral situation that so often causes issues:

Refactoring mining from 'full mining rating, all materials, multiply by availability' to 'total mining potential, weighted share of minerals by availability', which would produce 10 times as much of a 1.0 mineral over a 0.1 availability mineral, or 'total mining potential, weighted share of minerals by availability, fractional loss of potential according to total of ((number of minerals)-(sum of availability))', which would make body with a small number of high availability minerals very valuable over a planet with one or two high availability minerals and low availability on the others because the mining potential loss fraction is so much lower.

Although in that case you want the ability to focus efforts on mining a certain mineral as a planetary/colony policy, or a technology that lets you lower the availability penalty.

All of these would pretty majorly impact the economic side of the game though.

The main goal here is to offer a little greater control or at least different trade offs, without the oddities that you sometimes get like where you are desperately mining a low availability deposit of a material you need while the same high availability deposit of a material you don't need (right now) just produces a bigger and bigger stockpile of stuff you can't make use of.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on December 08, 2019, 03:31:48 PM
Thinking of the mineral situation that so often causes issues:

Refactoring mining from 'full mining rating, all materials, multiply by availability' to 'total mining potential, weighted share of minerals by availability', which would produce 10 times as much of a 1.0 mineral over a 0.1 availability mineral, or 'total mining potential, weighted share of minerals by availability, fractional loss of potential according to total of ((number of minerals)-(sum of availability))', which would make body with a small number of high availability minerals very valuable over a planet with one or two high availability minerals and low availability on the others because the mining potential loss fraction is so much lower.

Although in that case you want the ability to focus efforts on mining a certain mineral as a planetary/colony policy, or a technology that lets you lower the availability penalty.

All of these would pretty majorly impact the economic side of the game though.

The main goal here is to offer a little greater control or at least different trade offs, without the oddities that you sometimes get like where you are desperately mining a low availability deposit of a material you need while the same high availability deposit of a material you don't need (right now) just produces a bigger and bigger stockpile of stuff you can't make use of.

I don't entirely understand your suggestions, but the ability to set a colony-wide 'focus on this mineral' command that, say, doubled the availability of one mineral at the expense of halving all the others would be valuable to me.

So Planet Bob, with 1.0 Duranium, 0.8 Neutronium, 0.6 Gallicite, and 0.4 Mercassium could be set to focus on the Merc (effectively 0.8) at the cost of reducing Dura to 0.5, Neut to 0.4, & Gall to 0.3; or focus on the Neut (1.2) and get Dura 0.5, Gall 0.3, & Merc 0.2.


- - - - -


Obviously, a colony with only one or two minerals would gain +100% or +25% to its total mining rate from this change.  Any colony using this feature would also be racing towards the point of diminishing availability at twice the previous rate.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on December 08, 2019, 04:03:44 PM
Well, I was basically thinking like this:

Mining potential would be the total amount of minerals a given planet could dig in a year, let's say that we're at 300 mines with a mining rate of 10 tons per year per mine, so 3000 tons in total.

Weighted share of minerals by availability would go, for example, go with Duranium (0.7), Gallicite (0.2) and Mercassium (0.1). Total availability is 1.0, total mining rate is 3000 tons, Duranium has 7 shares of the mining rate (total mined in a year 2100 tons), Gallicite has 2 shares (total mined 600 tons) and Mercassium has 1 share (total mined 300 tons). Total mined is 3000 tons of material.

Weighted share with loss of potential from lack of availability would go 0.7 Duranium, 0.2 Gallicite, 0.1 Mercassium, 0.3 unavailable, 0.8 unavailable, 0.9 unavailable, total 2.0 unavailable, and mine 700 tons of Duranium, 200 tons of Gallicite and 100 tons of Mercassium. The remaining 2000 ton capacity is 'wasted', dredging up Newtonian materials from the depths of the aether that are not relevant to the game or otherwise just expended effort that is not useful. There would still be 3000 tons of material mined in total even 2/3rd of it is discarded.

Being able to turn certain minerals off in a mining operation is helpful in this case because it lets you go for 0.7 Duranium and ignore the impact and loss of efficiency due to low availability of other materials, you'd still need to account for the 0.3 unavailability rating though. So in that case you'd be mining 2100 tons of Duranium, 900 tons of discarded waste material, and not touch the Gallicite and Mercassium deposits.

Being able to turn off certain minerals in a place where you are always mining the maximum possible of the mineral wealth of the planet with the availability ratings only impacting ratios of the materials dug up would kinda break the system because it'd allow you to use this setup to mine 3000 tons of material from an availability 0.1 material from a planet with only one or a few materials, and would render a body with all minerals at 1.0 availability but in small quantities strictly inferior to a body with vast quantities of all materials at only 0.1 availability simply because that body is going to be mined for a long time to come.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on December 08, 2019, 08:15:18 PM
I for one think in general it would be nice if at some point mineral mining was de-simplified so you could focus purely on mining the stuff you actually want.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on December 14, 2019, 10:48:18 AM
I would like to see a few more ship components and installations to make pre-TN gameplay a bit more fun for those of us that like starting from almost nothing:

- Pre-TN colonization transport module ( Similar to Cryogenic but with say 1000 or 2000 capacity of 10000 ) so you can get a small offworld colony started
- Pre-TN engine techs ( 1 or 2 more levels with say 50 or 100 times worse fuel efficiency )
- Ability to build additional Conventional Industry as an installation
- Ability to make a very basic sensor / MFC ( I guess could also be handled like ICBM Launch Control but a pre researched version of each for ships too )
- Ability to make a very basic magazine ( I guess could also be handled like ICBM Launch Control but a pre researched version of each for ships too )
- Pre-TN slow geo-surveying ship module ( I mean we do start with the ability to mine them on our homeworld so with enough time/effort why not find them on other worlds? )
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on December 14, 2019, 12:22:57 PM
pre-TN engine tech isn't marked by low efficiency, it's marked by their engine power. The most basic TN engine has a 40 EP to hullsize ratio, the pre-TN Conventional Engine has a 1EP to hullsize ratio.

It'll get where you want it to get, but it's going to be slow as molasses getting there.

Efficiency doesn't offer high engine power or speed, it offers lower fuel costs for the same distance for the same weight of vessel. No seriously, range of the ship doesn't change when you shove in a stronger or weaker engine with the same engine efficiency modifier as long as the weight of the ship also remains the same.
Title: Re: C# Aurora v0.x Suggestions
Post by: AlStar on December 14, 2019, 02:27:46 PM
I was thinking that a government corruption mechanic could make for some interesting gameplay/roleplaying opportunities.

Basically, the way I see it working is as a tab on your Military Academies that goes from "uncorrupt -> lightly corrupt -> corrupt -> heavily corrupt", which can be changed one pip every (say) 5 years.  Uncorrupt would work as per usual, while increasing corruptness would cause your Military Academies to generate (a lot of) wealth, representing the ability of wealthy citizens to purchase ranks in the military well above their levels of competence.

The flip side of this would be an increasing percentage of leaders who spawn with substandard or possibly even negative modifiers in their abilities.  To get around the fact that players will (obviously) just not use these leaders, some (all?) of these leaders will have a "political appointment" tag - all leaders with political appointment tags must be assigned to an appropriate station before you can start appointing regular leaders, and all political appointments cannot be reassigned for a minimum amount of time (probably a year or two. )

So you'll have to dedicate some percentage of labs to idiot scientists, or small, out of the way colonies to drunken administrators, or assign a commander to your gas harvester so that they're not blocking you from assigning a promising recruit to an actual ship of the line.

Political Naval Officers maybe should also come with a "must be assigned to a military vessel" tag, so you can't just throw them into your transports. . .
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on December 14, 2019, 03:06:14 PM
pre-TN engine tech isn't marked by low efficiency, it's marked by their engine power. The most basic TN engine has a 40 EP to hullsize ratio, the pre-TN Conventional Engine has a 1EP to hullsize ratio.

It'll get where you want it to get, but it's going to be slow as molasses getting there.

Efficiency doesn't offer high engine power or speed, it offers lower fuel costs for the same distance for the same weight of vessel. No seriously, range of the ship doesn't change when you shove in a stronger or weaker engine with the same engine efficiency modifier as long as the weight of the ship also remains the same.

I'm aware of that but what I am after is making pre-TN ship design feel a bit more plausibel with you needing to assign more than 1-2% of the ship mass to fuel which is silly when our real rockers today use something like 90%+ and that's still not enough for SSTO.
Title: Re: C# Aurora v0.x Suggestions
Post by: mtm84 on December 14, 2019, 03:49:48 PM
I'm aware of that but what I am after is making pre-TN ship design feel a bit more plausibel with you needing to assign more than 1-2% of the ship mass to fuel which is silly when our real rockers today use something like 90%+ and that's still not enough for SSTO.

I believe handwavium stipulates that even pre-TN ships are constructed in orbit.  But yes fuel/mass vs delta-v would still be a major problem.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on December 14, 2019, 04:48:29 PM
I was thinking that a government corruption mechanic could make for some interesting gameplay/roleplaying opportunities.

Basically, the way I see it working is as a tab on your Military Academies that goes from "uncorrupt -> lightly corrupt -> corrupt -> heavily corrupt", which can be changed one pip every (say) 5 years.  Uncorrupt would work as per usual, while increasing corruptness would cause your Military Academies to generate (a lot of) wealth, representing the ability of wealthy citizens to purchase ranks in the military well above their levels of competence.

The flip side of this would be an increasing percentage of leaders who spawn with substandard or possibly even negative modifiers in their abilities.  To get around the fact that players will (obviously) just not use these leaders, some (all?) of these leaders will have a "political appointment" tag - all leaders with political appointment tags must be assigned to an appropriate station before you can start appointing regular leaders, and all political appointments cannot be reassigned for a minimum amount of time (probably a year or two. )

So you'll have to dedicate some percentage of labs to idiot scientists, or small, out of the way colonies to drunken administrators, or assign a commander to your gas harvester so that they're not blocking you from assigning a promising recruit to an actual ship of the line.

Political Naval Officers maybe should also come with a "must be assigned to a military vessel" tag, so you can't just throw them into your transports. . .

Okay, first? The amount of wealth that would go into buying those commissions is going to be trivial compared to actually running the military, or the long term drain on military resources due to corrupt practices of corrupt officers. And I don't just mean in the loss of lives, munitions and equipment due to those officers being incompetent in combat, I also mean things like the procurement office giving their palls in the military industry sweet deals in return for a cut of the profits, or crates of military equipment and supplies (even if it's just crates of food and shelters) disappearing into the black market, with the conspiracy dividing the price of the sale while turning around and telling the logistics branch to bring more supplies.

There's a reason corruption is a pretty serious charge for officers and enlisted both.

Second, political appointees are already a thing in this game; it's the politically connected trait (IIRC of the top of my head), and it counts as a double strength qualifier when calculating promotions. As such, politically connected but poorly qualified officers often promote more quickly than their more competent but less connected officers. This only applies to military officers though, administrators and head scientists aren't affected by the promotion system after all. For those, what matters is their administrative rank and skills, as those the maximum size of the colony they can be appointed to or the number of labs that can be assigned to them, as well as what bonuses they offer.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on December 14, 2019, 06:01:47 PM
I believe handwavium stipulates that even pre-TN ships are constructed in orbit.  But yes fuel/mass vs delta-v would still be a major problem.

It's a good point. A more complete improvement of pre-TN tech isn't possible without reworking some mechanics, for example so that getting out of the gravity well and into orbit is on the same order of magnitude expensive fuel wise as getting around inside the solar system.

My suggestion was not that ambitious though, just a few balancing and small "minimum effort" additions to make it feel a bit more plausible, and possible to have some interesting scenarios set in this tech level which also could include space warfare.

A larger rework is probably not meaningful unless you try and make Newtonian Aurora complete with Delta-V budgets and so on, which actually seemed to be something Steve was toying around with quite a few years back (http://aurora2.pentarch.org/index.php?board=155.0).
Title: Re: C# Aurora v0.x Suggestions
Post by: ReviewDude01 on December 15, 2019, 04:10:33 PM
Suggestions - ship military concepts - ideas:
Ship Components - Jump Engine. Add option to design personal jump engine only for smaller minerals cost and tonnage. Cost and tonnage can be lower with increased "max ships jumped tech") Good starting number is around 0.5 of size of full sized jump engine.

Ship Components - Anti-sensor paint camouflage - coating Add option to add % reduction of heat and other signatures. The differences between cloak is that if the ship paint is damaged, can be in game simulated as min. 1 point of damage taken. The effect of coat or paint is broken. Another difference is that coat or paint is probably almost no tonnage little mineral cost and relatively little % effect.

Ship Components - Military Engine overthrusting - overdrive - afterburner Add option that some designed military engines can be overcharged to 150% or more speed for a limited amount of time. After this time they can go down to under 100% maximum speed, guzzle a lot of fuel or could also break and be damaged until repaired. Smaller ships could be easier to design with this. Design efficiency wise in game for medium or larger ships it could be viable to outrun a missile salvo, once.

If desired, same concept can be added for shield generators and sensors. This overcharge designs would need a tech!

Add military ship sensor software or sensor uplink tech makes all ships with same sensor component in a single squadron or fleet having % increased sensor range - efficiency. This % can be relatively low and is here to make many ships with same sensors more viable for RP purposes primarily.

Add variable outermost armor layer options Standard armor, reactive, reduction-based, energy-proof, exact names of these armors are intended examples only. Reactive blocks up to 5 or more points of damage but all adjacent armor squares in a grid are destroyed in the process. If there is no armor down from reactive ship takes damage from armor. Reduction-based. Damage of 1 or x  point is ignored entirely. Incoming weapon can be ricocheted. Damage of more than x deals full damage to armor. Example: Standard ablative face hardened outermost armor layer is more expensive and weights more than standard armor but also blocks up to 1 point of damage. Incoming 1 damage shots are ricocheted entirely (can be with 3% chance to destroy armor anyway). Incoming 4 damage shot destroys 4 grids of armor, not 3. Example of energy-proof or anti laser reactive type lasers and energy beams deals only 50% or lower damage when this type of armor is hit as a first grid of armor.

Add SM option to delete all active missile salvoes in a system. Useful to fasten the game in case of rare performance issues due to many salvoes in a system. Can happen in some circumstances.


Title: Re: C# Aurora v0.x Suggestions
Post by: ReviewDude01 on December 15, 2019, 04:17:10 PM
Military ship component Anti-Missile Countermeasure launchers Unlike AMM or ship PD size of 1 Anti-Missile countermeasure component is based on % of tonnage of carrying ship. It adds a % chance that every incoming missile from salvo will miss the ship which deploys countermeasures. Countermeasures are countered with missile ECCM and can be deployed only once per component. AI logic of deploying countermesures is simple. IT uses 1 launcher per incoming missile salvo together with last line defence or point blank PD as multiple countermeasure launches does not stack.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 15, 2019, 07:00:25 PM
Add military ship sensor software or sensor uplink tech makes all ships with same sensor component in a single squadron or fleet having % increased sensor range - efficiency. This % can be relatively low and is here to make many ships with same sensors more viable for RP purposes primarily.

If Steve would look into the sensor model and do something with it I would like to see sensor working a bit more like modern sensors.

That would mean that active sensors are not 100% accurate and it will take time to identify and position targets. Then having many sensors would make this process go allot quicker and finding fire solutions possible further out at the fringes of sensors capabilities.

It would even be interesting if sensor lock would go even faster if sensor crafts were separated in different places, the further apart the more likely it is to triangulate the target profile.

I would also like it if active sensors only give and approximation of the weight and you might get more and more accurate information about weight in time, but you don't get full identification of the enemy craft. You would need ELINT to identify any eventual sensors to identify targets depending on historical data.

The more fog of war we can get the more interesting space combat can get, you could even model communications to some degree as communication blackout between ships might be important to not reveal positions from EM and ELINT sensors.

Then you add electronic warfare components, spoofing sensor buoys and all manner of interesting gears. If you can cloak a ships mass you probably could do the reverse and fool someone to see a big ship that is not really there.

There could be some really interesting stuff done with sensors...
Title: Re: C# Aurora v0.x Suggestions
Post by: mtm84 on December 17, 2019, 06:19:54 PM
So I appreciate the... “arcane” calculations (may they never be spoken) that are used for armor, but wouldn’t it be simpler to use the volume of a spherical shell instead?  Armor columns would be based on internal component volume and you can calculate any number of layers and armor strength based off the starting point of the thickness of 1 layer of strength 1 armor.

(Also I won’t have to bash my head in trying to match how armor is described as working with how it actually works >.>)
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on December 17, 2019, 08:29:18 PM
An option for SM Mode: Initiate civilian mining colony on planetary body; regardless if civilians would have colonized there or not. This way SM can manually create civilian activities for story telling purposes.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on December 18, 2019, 01:14:17 AM
So I appreciate the... “arcane” calculations (may they never be spoken) that are used for armor, but wouldn’t it be simpler to use the volume of a spherical shell instead?  Armor columns would be based on internal component volume and you can calculate any number of layers and armor strength based off the starting point of the thickness of 1 layer of strength 1 armor.

(Also I won’t have to bash my head in trying to match how armor is described as working with how it actually works >.>)

Instead of the current system using the surface area of a sphere?  Nope.

Your suggestion would be equally complicated, then add one more step, and all with a less-easily-visualized formula.
Title: Re: C# Aurora v0.x Suggestions
Post by: mtm84 on December 18, 2019, 01:57:15 AM

Instead of the current system using the surface area of a sphere?  Nope.

Your suggestion would be equally complicated, then add one more step, and all with a less-easily-visualized formula.

Not really adding a step, just combing the layers.  If you can calculate the surface area from HS, you can calculate the radius just as easily from the HS.  After that all you are doing is figuring out what the thickness of the armor is, which is trivial (thickness of a strength one armor layer divided by the racial armor strength and time that by the number of layers). One shot.  No calculating each layer individually.  As for visualizing it, it isn’t any harder then the surface area, unless I miss understood you.  Is the equation itself longer?  Sure.  I think it’s less ambiguous compared to nesting surface areas on top of each other though.


I know this won’t happen, I’m just frustrated trying to work out what Steve is doing.  I know how it is supposed to work but none of my layers past the first one line up.  Maybe I’m missing something obvious which wouldn’t be the first time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 18, 2019, 04:54:16 AM
So I appreciate the... “arcane” calculations (may they never be spoken) that are used for armor, but wouldn’t it be simpler to use the volume of a spherical shell instead?  Armor columns would be based on internal component volume and you can calculate any number of layers and armor strength based off the starting point of the thickness of 1 layer of strength 1 armor.

(Also I won’t have to bash my head in trying to match how armor is described as working with how it actually works >.>)

The armour calculation uses the surface area of a sphere. That is more realistic than using the volume of the sphere.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on December 18, 2019, 07:39:33 AM
. . .and iterates three times to account for the added mass of the armour itself.
Title: Re: C# Aurora v0.x Suggestions
Post by: mtm84 on December 18, 2019, 01:20:51 PM
The armour calculation uses the surface area of a sphere. That is more realistic than using the volume of the sphere.

I understand that armor uses the surface area of a sphere, but I do not understand your use of more realistic here.  Using the volume of a shell is conceptually the same as using the surface area of a sphere, the armor is going to have a thickness either way.  Unless you mean "ease of calculating one layer of armor by hand", which yes I agree.  But if you are already calculating the surface area of a sphere based on its volume, calculating the radius of a sphere isn't any harder, and that radius is all you need to find the shell volume.  less compounded rounding errors.  no per layer calculations.


Some of the math.  Volume of a sphere is (4/3) * pi * R^3.  If you add the thickness of the armor to R, you would get the volume of the internal components plus the armor, aka the ECS in aurora terms.  Armor thickness is  (Number of Layers / Strength per HS) * (magic number) .  In aurora's case I believe this number to be .25, since that's what I get whenever I compare the radius of internal components to the radius of the ECS of a ship for one layer of armor when armor strength per HS is taken into account.  I understand that this is more complicated then Surface Area / 4 / Armor Strength per HS.  But it lets you calculate all of the armor in one equation for any number of layers.  End result is still an amount of Armor in HS needed to cover a sphere.  All you need to give the equation would be the Radius, the number of layers, and the strength of the armor per HS.  I believe the end math isn't any more complicated then the new sensor strength model.  Here's what it looks like:

Armor HS = 4.18879 * ( (R + T)^3 - R^3)

where R is 0.62035 * (HS of internal components) ^ (1/3)
and T is Number of Armor Layers / Armor Tech Strength / 4

This gives values that are a bit smaller then Aurora gives now, but still requires more armor every layer then the last one.  Armor columns is calculated the same, Surface Area of ECS / 4.


I guess this is all just frustration that when I try to calculate armor on my own it never matches what Aurora does, even for 1 layer.  for example, I have a ship that has a size of 251.3 without armor (adding up all the components).  the surface area of this volume in a sphere is 192.6, Dividing by 4 gives an armor strength required of 48.2.  with a HD duranium armor value of 6, that gives us 8 worth of armor.  but Aurora says it has armor strength requirement of 49.2 for 8.2 armor.  So where does this extra .2 come from?  even with heavy rounding I don't see how you can go from 192.6 surface area to 196.8 with a pre armor HS of 251.3.  From what I understand the armor strength shown in the ship designer is the sum of  Surface Area / 4 for every layer.  But if I can't match what Aurora is doing on one layer I have no hope of accurately doing it for multiple layers.  Maybe simpler was the wrong word to use in my original post on this topic.  Perhaps "easier to replicate would have been better.  In any case, I'm not suggesting this to be a troll or to disparage the system Steve has now.  To me it just seems more natural that you could add up layers of uniform armor thickness, and that an individual layer would have a thickness based on the tech level.

Or maybe I'm just bored waiting for C# to drop so I can play around with the new ground forces formations...
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 18, 2019, 05:12:03 PM
If possible make CIWS systems smaller so they can be used a bit more often, I almost NEVER use them in favour of just adding a few extra 10cm low tech railguns to serve a similar purpose but that also can protect other ships as well.

I know that CIWS can be used on civilian ships and stations, but they really are of limited use there as well as high valued targets almost always are protected by an escort anyway.

You also can build very cheap "drones" and deploy them when needed such as these...

Code: [Select]
Phalanx IIa class Point Defence Drone    412 tons     2 Crew     69.2 BP      TCS 8.24  TH 0  EM 0
1 km/s     Armour 1-4     Shields 0-0     Sensors 1/1/0/0     Damage Control Rating 0     PPV 7.4
Maint Life 0 Years     MSP 0    AFR 82%    IFR 1.1%    1YR 29    5YR 442    Max Repair 42 MSP
Intended Deployment Time: 0.1 months    Spare Berths 2   

Single Gauss Cannon R3-85 Turret (1x3)    Range 30 000km     TS: 30000 km/s     Power 0-0     RM 3    ROF 5        1 1 1 0 0 0 0 0 0 0
Fire Control S00.4 20-7500 (FTR) (1)    Max Range: 40 000 km   TS: 30000 km/s     75 50 25 0 0 0 0 0 0 0

or this...

Code: [Select]
Phalanx IIb class Point Defence Drone    500 tons     4 Crew     65.4 BP      TCS 10  TH 0  EM 0
1 km/s     Armour 1-5     Shields 0-0     Sensors 1/1/0/0     Damage Control Rating 0     PPV 8.66
Maint Life 0 Years     MSP 0    AFR 100%    IFR 1.4%    1YR 24    5YR 354    Max Repair 28 MSP
Intended Deployment Time: 0.1 months    Spare Berths 0   

Triple 10cm C1 Infrared Laser Turret (1x3)    Range 30 000km     TS: 30000 km/s     Power 9-3     RM 1    ROF 15        3 1 1 0 0 0 0 0 0 0
Fire Control S00.4 20-7500 (FTR) (1)    Max Range: 40 000 km   TS: 30000 km/s     75 50 25 0 0 0 0 0 0 0
Stellarator Fusion Reactor Technology PB-1.3 (1)     Total Power Output 3.12    Armour 0    Exp 25%

Compared to this...

Code: [Select]
Rate of Fire: 6 shots every 5 seconds
Dual GC: 5HS    Turret: 1.6 HS    Fire Control: 0.5 HS    Sensor 0.1071 HS    ECCM: 0.5
Overall Size: 7.7 HS    HTK: 2
Tracking Speed: 20000 km/s     ECCM Level: 1
Cost: 41    Crew: 8
Materials Required: 8x Duranium  5x Corbomite  15x Vendarite  13x Uridium
Base Chance to Hit: 50%

Given the new rules and calculations for turrets I'm not sure but I think that will just impact the drones more possitively than the CIWS system too perhaps. Given that these small "drones" can also protect other ships for a relatively small cost and will be very effective due to its very high tracking speeds. I'm not sure if using fighter fire controls to push tracking speed high is intended behaviour but it certainly is useful, pushing it to even 40000km/s is not impossible for the Gauss system... but I figured that 30000km/s would be more than enough for C# especially when you add tracking bonus to that as well.

The above is not the only reason why I suggest reducing the size of CIWS... I would like to fit them on smaller platforms too and I really think they should be smaller. Since they only shoot targets up to 1000km I think they should be consideraly smaller not just 2.5 HS instead of 3. I would make them at least 1.5HS if not even 1HS in size. That way you would actually start consider adding them to warships as they are so small so why not.

Since the mechanic of fire-control versus salvoes have been changed I also think CIWS need this boost to keep being at least somewhat interesting system to put on a ship.

I also would like to put a CIWS system on my small patrol vessels and be at least somewhat effective.

I really don't think that you can abuse them in that many ways... sure someone are going to load up a large commercial ships with 1000 CIWS and charge them at an NPR base who then empty their missile magazines at it, but that is pure mechanical abuse because the AI can't deal with it, in the same way you can run in and then kite their missiles.

Title: Re: C# Aurora v0.x Suggestions
Post by: Polestar on December 18, 2019, 07:58:34 PM
I'm liking a lot of the recent suggestions made here. 

Re. conversation about how mines might specialize in the production of desired minerals:

I am a big "yes, please" for any revision to mining that allows us to fully appreciate quality mining sites that don't include the full suite of scarce TN resources. I am also a big supporter for changes that ease the pain on resource-reliant AI entities (if any), and/or that make multi-faction games more competitive. If the player requests such a game, then there simply must be enough adequate resource sites, in reasonable range, to give more than one empire a fair shot. Letting Gallium 0.8, Duranium 0.0 worlds specialize would therefore be a big, big win.


Re. fleshing out pre-TN gameplay a bit:

Aurora allows players to choose pre-TN starts, but doesn't really deliver much to do in such games except to develop a single world. The problem is more than that it's so tedious to get anywhere with pre-TN tech, it's that there are almost no resources that would make you want to bother. I feel that Aurora would do well to "fish or cut bait" here: If pre-TN is retained, let it deliver a bit more gameplay. If this is not desired, remove it.

I lean towards removal, because of the lack of any physics required to support Newtonian (or Einsteinian) -constrained motion. Because bothering with these is just not what TN Aurora's all about, worrying about pre-TN ships and movement would be a major distraction, not merely at the coding level, but at the game design level. The question has to be asked: At what point do we need to simply "let Aurora be Aurora"?


Re. Ship and military concepts:

I like the afterburner idea. 
Fleshing out armor and allowing different types sounds like it could add a bunch to the gameplay. I really liked Star Ruler I  and Star Ruler II's take on all this.

I quite take mtm84's point that the way armor is actually calculated is needlessly opaque. It  /might/ even be mathematically incorrect, perhaps due to iterative calculations on rounded results. I don't know. All I know is that armor is weird. Better, like he says, to calculate the volume of a shell  with a specified thickness, and then round to an even number of armor boxes only once.
     The easiest way to translate this result to the armor box that Aurora currently uses is to divide the  non-rounded armor volume by the number of armor rows,  then round the result. If this leads to armor calculations that jump around too much for armored small ships, then either increase the number of boxes per unit volume, or re-think how armor is damaged.

I'd love CIWS systems that weren't so big.  Like Jordan_CAB, however, I do worry about them potentially getting overpowered. One straightforward way to balance them is to remember that, in the real world, the effectiveness of CIWS is not linear with their number. The first such system protects better then CIWS # 10, regardless of the weight of incoming. Among the reasons for this is that it is much easier to optimize integrated fire control and weapon systems LOS/LOF relative to incoming heat for one system, than it is for multiple, each having their own LOS/LOF, and each having to  coordinate with all others ... or just overkill some missiles and miss others.


SM option for creating mining colonies:

Solid idea. Off-world mining, transport, and the civilian sector are often critical parts of the backstory.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on December 19, 2019, 11:09:32 AM
If mines are going to be specialized, how about giving them an initial maximum they are able to mine, and that maximum can be extended by research.

Example:
Duranium 0,8
Vendarite 0,6
Neutronium 0,7
Iridiums 0,5

Initial capacity would be 1,2. That can be used to mine 0,8 duranium and 0,4 Vendarite. Or any other values that adds up to 1,2.
Title: Re: C# Aurora v0.x Suggestions
Post by: mtm84 on December 19, 2019, 11:35:48 AM
I wouldn't mind an expansion of CIWS, but I don't think they could get any smaller then what they are now unless you are reducing the size of the Gauss cannons themselves.  As far as I know the size is simply based on a twin turret with size 3 cannons using 4x turret speed with a built in fire control and an active sensor, all using (mostly) normal sized components.  The only benefit is that you don't have to set up fire controls on the ship to use them and you can stick them on civilian ships.  Especially with the new auto fire control system C# is going to have, it will probably always be more space effective to set up your own point defense systems on a ship set to final defensive fire, since you wont need a bunch of fire controls and active sensors for every turret.

For some perspective, in modern day navies you really don't see more then 1 or two systems on smaller ships.  USN frigates and destroyers have 1-2, cruisers have 2, carriers 4.  Of course those CIWS systems are considerably smaller than the Aurora version ( they would be about .125 HS).  I wonder how small a twin .5 Gauss CIWS would be?  More options are always a plus, I can't imagine it would be hard to add a weapon size selection to that screen.  (as an aside, I think there is a bug in VB6 aurora where CIWS uses the highest turret speed tech regardless of what you select in the design.)
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 19, 2019, 11:52:57 AM
I wouldn't mind an expansion of CIWS, but I don't think they could get any smaller then what they are now unless you are reducing the size of the Gauss cannons themselves.  As far as I know the size is simply based on a twin turret with size 3 cannons using 4x turret speed with a built in fire control and an active sensor, all using (mostly) normal sized components.  The only benefit is that you don't have to set up fire controls on the ship to use them and you can stick them on civilian ships.  Especially with the new auto fire control system C# is going to have, it will probably always be more space effective to set up your own point defense systems on a ship set to final defensive fire, since you wont need a bunch of fire controls and active sensors for every turret.

For some perspective, in modern day navies you really don't see more then 1 or two systems on smaller ships.  USN frigates and destroyers have 1-2, cruisers have 2, carriers 4.  Of course those CIWS systems are considerably smaller than the Aurora version ( they would be about .125 HS).  I wonder how small a twin .5 Gauss CIWS would be?  More options are always a plus, I can't imagine it would be hard to add a weapon size selection to that screen.  (as an aside, I think there is a bug in VB6 aurora where CIWS uses the highest turret speed tech regardless of what you select in the design.)

As I said in my suggestion... CURRENT size of the CIWS guns are 2.5 HS for a 50% Gauss where a regular 50% Gauss is 3HS... so they already are a bit smaller.

My point was that fire-controls have increased in efficiency and CIWS already are way too big to be of any use in comparison to how more effective it is to have a turret that can cover more than itself.

The "problem" is that they are too large because space is a huge premium on a military ship, for commercial ships this change would practically mean nothing as the size of the system really don't matter much at all.

If the Gauss gun was modelled at 1HS (for a 50% size) I actually might consider that as an option over a few 10cm railguns on patrol and smaller frigates. I would definitely put one or two on most designs as they are quite cheap and small enough to not compromise much of anything on the ship. That would make them used in roughly the same way CIWS are used on modern ships as well.
Title: Re: C# Aurora v0.x Suggestions
Post by: mtm84 on December 19, 2019, 02:28:00 PM
My apologies, I miss read some of your post. And didn’t realize the Gauss cannons where smaller then normal, but it makes sense since they only shoot at 1000km.  I still think trading off accuracy for smaller ciws size would be the way to go if you wanted the options.  You don’t want to make them so small that there’s no point in other PD setups vs spamming CIWS.  I’m not sure what that balance would be though.  I do agree that as they stand now they are too big to be used on smaller craft. But on the other hand smaller ships are just the place for finely tuned setups where you don’t want to replicate multiple fire controls and sensors per weapon system.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 19, 2019, 03:06:51 PM
My apologies, I miss read some of your post. And didn’t realize the Gauss cannons where smaller then normal, but it makes sense since they only shoot at 1000km.  I still think trading off accuracy for smaller ciws size would be the way to go if you wanted the options.  You don’t want to make them so small that there’s no point in other PD setups vs spamming CIWS.  I’m not sure what that balance would be though.  I do agree that as they stand now they are too big to be used on smaller craft. But on the other hand smaller ships are just the place for finely tuned setups where you don’t want to replicate multiple fire controls and sensors per weapon system.

In my opinion trading size for accuracy is not an option as you are better off just add another 10cm railgun for PD (plus beam combat ability) and just use the beam fire control you already have on the ship anyway, that is just about 300-350t for a decent PD option. A CIWS will not really be much better at that size AND it will only defend the ship itself which is a huge drawback in most situations. These CIWS need to be much more efficient than regular PD in order to even be considered.

You don't have to worry about spamming CIWS ever being a better option, they would have to be many magnitudes better before that would ever happen. Why would anyone shoot at a ship full of CIWS fi they take up 25% of the hull in addition to engines, armour and shields... there really are nothing left for anything important to protect. Having 25% dedicated to PD is always meaningful even if they are five time less efficient as they can protect not just itself but other ships as well, a few of these ships and you are vastly more better of than putting CIWS on all the ships. Not to mention regular PD also can fire directly at opposing ships if they approach to point blank range.
Title: Re: C# Aurora v0.x Suggestions
Post by: ReviewDude01 on December 19, 2019, 03:20:17 PM
Reply to Gauss PD and Ciws.

I also think that multiple Gauss PD in same ship squadron firing at the same time should suffer a small % accuracy penalty increasing with numbers of Gauss PD shooting in same 5 second phase. Logic is that it is harder to coordinate for example 100 Gauss PD cannons cowering fleet to shoot at the right targets from incoming salvo / to shorten it imagine an extremely "crowded" tower defence game where each tower kills enemy in one hit and the problem is overshooting / overkill. the more towers are in one place the more overkill happens assuming they are in one place shooting at the same time and having not an instant delivery weapon - ballistics. Then Ciws would be also more viable than current gauss pd.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 19, 2019, 03:55:01 PM
Reply to Gauss PD and Ciws.

I also think that multiple Gauss PD in same ship squadron firing at the same time should suffer a small % accuracy penalty increasing with numbers of Gauss PD shooting in same 5 second phase. Logic is that it is harder to coordinate for example 100 Gauss PD cannons cowering fleet to shoot at the right targets from incoming salvo / to shorten it imagine an extremely "crowded" tower defence game where each tower kills enemy in one hit and the problem is overshooting / overkill. the more towers are in one place the more overkill happens assuming they are in one place shooting at the same time and having not an instant delivery weapon - ballistics. Then Ciws would be also more viable than current gauss pd.

In reality this goes for all weapons fire more or less. The more weapons you use at the same target the less effective they are. In WW1 & 2 naval gunfire combat there was very difficult to know where your shot ended up the more shots were targeted at the same ship, this made fire-correction more difficult... it was bad enough when the guns of the own ship fired at the same target but double worse when another ship did it.

It could be a good feature if Aurora had some of that so effectiveness of PD goes down with a few different factors. The more weapons that coordinate there are some effective penalties. More fire-controls per weapons would reduce this effect somewhat. But it would also depend on the incoming targets, the more targets the less of a problem this is. This means you would not get a direct linear effect of effectiveness and there is a much higher risk of leaking missiles even with a rather good PD coverage.

Could be interesting...
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 19, 2019, 04:06:18 PM
In addition you could also throw in the possibility of a ship the perform "evasive manoeuvres" to make incoming fire less accurate but of course reducing THAT ships accuracy as well... perhaps increase a ships "effective speed" for targeting with x2 while reduce the ships accuracy with 75%.

That would also make none combat ship able to do something when targeted and might also force groups of ships to spread its fire around a bit more.

This would not just represent the ship moving more erratic, but also spending more power and resources on damage prevention, electronic counter measures that interfere with their own targeting and tracking sensors etc.

This could also be used with the "Afterburner" suggestion... and ship that uses afterburner also effectively count as conducting evasive manoeuvres as well. A ship trying to get missiles to hit while using afterburners during ANY point in the missiles flight to the target gets a 75% deduction on accuracy (for game balance sake).
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on December 20, 2019, 11:49:36 AM
To get more variety in the names of your people, an option to mix first and last names of the selected languages would be nice.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on December 20, 2019, 12:06:58 PM
A nice additional option for civilians would be to do asteroid mining. They should either deliver those minerals to the closest planetary body with a production site, or you tax them.
As parameters for them choosing to mine there should be something like: max 2.000t of total mineral content on asteroid.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on December 21, 2019, 01:46:30 AM
I would love it if CIWS came in multiple sizes (of GC, not of numbers of GC).  So in addition to the standard "two Gauss Cannon of 50% accuracy" one could also have "two Gauss Cannon of 33% accuracy" and "two Gauss Cannon of 17% accuaracy", etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: shepard1707 on December 25, 2019, 11:44:29 AM
Not sure if its been suggested yet, but a way to include class/ship numbering or ship serials alongside names would be massively helpful for organization.  If we could designate the serial for a class (numbers starting at DD 1000, or FF tt, for example) it could nicely mirror modern US Navy.  But if not, it could just be tied to the Hull Type and still be handy.  With us just making new hull types if we want a true serial number reset.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on December 28, 2019, 09:18:33 AM
If not already added, could we get an event warning message to the Event Updates log for when you have unassigned industry ( just like with unassigned research labs ).
Title: Re: C# Aurora v0.x Suggestions
Post by: Stryker on December 30, 2019, 07:42:59 PM
I was rereading the Lagrange point stabilization rules.   I did not see a mention of a default order for stabilizing Lagrange points.   Have you, or will you include such default orders?
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on December 30, 2019, 08:45:56 PM
I don't see why you would ever want to stabilize every planet in the system, that would take an incredible amount of time and, more important, make defending anything near impossible. A default order for that would be a little pointless.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on December 30, 2019, 11:55:27 PM
This is probably more a future game version suggestion than a C# release idea, but I'd love to see a special warhead type (sort of like x-ray laser warheads) that works something like microwave lasers - it does greatly reduced damage and pierces shields and armor, but only damages engines. Call them Gravitic warheads, or Disruption Warheads, something like that. For game balance reasons, it would probably be best if they couldn't cause engine explosions - maybe even if they didn't destroy engines but temporarily knock them out, though that would mean more code work to add a new mechanic.

The basic idea is that this would make beam combat both more important and less all or nothing - you could carry a bunch of size 1 short range missiles, and if the enemy tries to kite you you can launch a few dozen and hopefully take out a few engines, even through powerful point defense. And all you have to do is slow one ship and the enemy would need to decide between sacrificing the ship or keeping together and letting you enter range. At the very least, one faster and longer ranged ship would no longer be able to effortlessly slaughter a dozen inferior ones.

It would also make piracy/boarding combat more feasible, maybe even to the point that larger warships start routinely carrying small units of marines as boarding defense. Which I consider a plus. Though even if you can easily force enemy ships to a standstill, getting boarding shuttles through heavy beam weapon defenses would probably be difficult and expensive.
Title: Re: C# Aurora v0.x Suggestions
Post by: Ciphascain on December 31, 2019, 02:14:22 AM
Quote from: Bremen link=topic=9841. msg117751#msg117751 date=1577771727
This is probably more a future game version suggestion than a C# release idea, but I'd love to see a special warhead type (sort of like x-ray laser warheads) that works something like microwave lasers - it does greatly reduced damage and pierces shields and armor, but only damages engines.  Call them Gravitic warheads, or Disruption Warheads, something like that.  For game balance reasons, it would probably be best if they couldn't cause engine explosions - maybe even if they didn't destroy engines but temporarily knock them out, though that would mean more code work to add a new mechanic.

The basic idea is that this would make beam combat both more important and less all or nothing - you could carry a bunch of size 1 short range missiles, and if the enemy tries to kite you you can launch a few dozen and hopefully take out a few engines, even through powerful point defense.  And all you have to do is slow one ship and the enemy would need to decide between sacrificing the ship or keeping together and letting you enter range.  At the very least, one faster and longer ranged ship would no longer be able to effortlessly slaughter a dozen inferior ones.

It would also make piracy/boarding combat more feasible, maybe even to the point that larger warships start routinely carrying small units of marines as boarding defense.  Which I consider a plus.  Though even if you can easily force enemy ships to a standstill, getting boarding shuttles through heavy beam weapon defenses would probably be difficult and expensive.

You could even make them hurt electronics such as the fire control system.  They could be something like the current harm missiles or AAGRM missiles. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on December 31, 2019, 04:20:16 AM
I was rereading the Lagrange point stabilization rules.   I did not see a mention of a default order for stabilizing Lagrange points.   Have you, or will you include such default orders?

Stabilising a Lagrange point is a very specific decision with a lot of variables. You are probably only going to stabilise a very small percentage of planets, so default orders wouldn't work.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on December 31, 2019, 11:38:28 AM
Quote from: Bremen link=topic=9841. msg117751#msg117751 date=1577771727
This is probably more a future game version suggestion than a C# release idea, but I'd love to see a special warhead type (sort of like x-ray laser warheads) that works something like microwave lasers - it does greatly reduced damage and pierces shields and armor, but only damages engines.  Call them Gravitic warheads, or Disruption Warheads, something like that.  For game balance reasons, it would probably be best if they couldn't cause engine explosions - maybe even if they didn't destroy engines but temporarily knock them out, though that would mean more code work to add a new mechanic.

The basic idea is that this would make beam combat both more important and less all or nothing - you could carry a bunch of size 1 short range missiles, and if the enemy tries to kite you you can launch a few dozen and hopefully take out a few engines, even through powerful point defense.  And all you have to do is slow one ship and the enemy would need to decide between sacrificing the ship or keeping together and letting you enter range.  At the very least, one faster and longer ranged ship would no longer be able to effortlessly slaughter a dozen inferior ones.

It would also make piracy/boarding combat more feasible, maybe even to the point that larger warships start routinely carrying small units of marines as boarding defense.  Which I consider a plus.  Though even if you can easily force enemy ships to a standstill, getting boarding shuttles through heavy beam weapon defenses would probably be difficult and expensive.

You could even make them hurt electronics such as the fire control system.  They could be something like the current harm missiles or AAGRM missiles.

That would be the complete opposite of the purpose. The idea is a missile to slow your opponents down so that being faster would not always be an automatic "I win" in beam fights, but there would still be an actual fight.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on December 31, 2019, 06:47:12 PM
While I would like to see a bit more variety on how you can target ships in general, both with missiles and beams I don't think that fighting from extreme range will be very effective anymore. As damage at such ranges is very low together with accuracy, you will probably run out of supply before you do any significant damage to an opponent, specially if they have even half decent shields.

If you have dedicated beam ships this is going t be an even worse prospect rather than fitting some beam weapons on most ships as you have much less supply for each weapon. I certainly can see some interesting strategic design choices being made here as accepting some more cost in Uridium in fire-control sensors for allot more durability in combat, both in terms of hit-points and Supply for weapon failures.

I would definitely like at some point a more engaging beam combat mechanic where you can target things like engines and weapons specifically and where armour are not just an automatic protection of the entire ship in a unison layer. Many component will need to be more or less exposed and some will be more or less important to armour for the same reasons. Old battleship had allot more armour around their magazines and weapon turrets for a reason.

I would also like to see armour acting more like real armour as in either they hole or they break. Being able to just peal of layer by layer with a really weak weapon would at some level be impossible. But this is not just a matter of depth of the armour but also its quality and type. Also different weapons might require different types of armour to be really effective. As in reactive armour against kinetic projectiles or reflective armour against lasers etc... this might also force more wide weapon research in and of itself.

There would be allot of possibilities at least. I know Steve had some great ideas for his Aurora 2 project a while back that seemed very promising to me... so I know he have thought about this stuff before.
Title: Re: C# Aurora v0.x Suggestions
Post by: shepard1707 on January 03, 2020, 07:29:42 AM
So.  A thought I had that would make for some interesting interactions in equipment is the idea that Missile Fire Controls, and possibly even fire controls in general, can only control so many missiles at a time.  Such that, even if I had a ship with, say, 78 box launchers, if my missile fire control tech wasn't good enough, I couldn't actually fire them ALL at once .  .  .  unless they had their own guidance.

This would add a lot of additional incentive to having self-guiding missiles, as well as functionally enforce the idea that just throwing all the missiles all at once is the absolute best solution all the time.  Put some control onto those great big box launcher designs.

It also has some degree of basis in reality, as from what I understand, modern missile control systems do not have an unlimited ability to launch and control missiles.





Also had a thought about possible fun to be had in Class, Hull, or Vessel 'quirks'.  Basically, little buffs or debuffs that a ship could have as a quality to it.  Perhaps it's sensors have a slightly higher failure rate, or it's engines are a bit more efficient, or it's turrets are just a bit faster turning than the tech would indicate.  No two ships in real life are the same, after all.  Ships would have a roll of the dice to see if it can develop a quirk, what that quirk is, and what the trigger might be .  .  .  all done when the vessel is built.  The quirk is initially hidden, unless 'triggered'.  It can be made to trigger with a tour of task force training, or, if the vessel is pressed into service right away, it might be revealed in the field.

Just a thought.  It'd be a lot of variables and probably ultimately not that fun, unless some method of forcing a reroll was implemented, or the debuff quirks were light enough to not be so bothersome.
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on January 03, 2020, 09:23:19 AM
in regards to the MFC/BFC idea, couldn't that just be roleplayed without limiting another players game/story?
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 04, 2020, 12:23:33 PM
in regards to the MFC/BFC idea, couldn't that just be roleplayed without limiting another players game/story?

While that is true you could say that with almost any mechanic in the game. I think this is a part that would add interesting choices in design, tactics and doctrine.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 04, 2020, 02:40:24 PM
While that is true you could say that with almost any mechanic in the game. I think this is a part that would add interesting choices in design, tactics and doctrine.


Would it?  If the research cost for "guide 25 missiles" was equivalent to Ion-tech engines, and the cost for "guide 36 missiles" was equivalent to Magneto-Plasma, would anyone actually build Ion-engined missile cruisers with seven tubes?  Would they build Magneto-Plasma BCs with nine tubes, or four?

Before Aurora expands in that direction, I want to see it fix the problem of 'point defense only fires on one salvo at a time, and stupidly will prioritise a one-missile salvo over a sixteen-missile salvo.'

- - - - -

Not to mention my "ships of the line" are only ever going to have two beam fire controls (port and starboard).  Dont prevent me from assigning 37 cannons to each of them on my "74s" -- or worse, make it cost a million RP to do so.  NPR tech is proportional to MY tech, and I don't want to give them all dozens of free levels over me.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 04, 2020, 03:31:50 PM
Before Aurora expands in that direction, I want to see it fix the problem of 'point defense only fires on one salvo at a time, and stupidly will prioritise a one-missile salvo over a sixteen-missile salvo.'

I have fixed that  - I just forgot to mention it in the change log :)

http://aurora2.pentarch.org/index.php?topic=9841.msg115852#msg115852

Title: Re: C# Aurora v0.x Suggestions
Post by: amram on January 04, 2020, 04:04:39 PM
I assume PD still only fires on one salvo at a time?

That is, if you have a single quad RoF8 100% gauss turret, and adequate tracking speed, FC range, and crew training to achieve 100% accuracy, allowing up to 32 missile kills per increment, and face 32 single missile salvos arriving simultaneously in 8 waves, for a total of 256 missiles, I suspect you are still gonna eat 248 hits, your PD being 97% idle while it happens.

Any chance in the future that is mitigated if not resolved?
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 04, 2020, 06:22:56 PM
I assume PD still only fires on one salvo at a time?

That is, if you have a single quad RoF8 100% gauss turret, and adequate tracking speed, FC range, and crew training to achieve 100% accuracy, allowing up to 32 missile kills per increment, and face 32 single missile salvos arriving simultaneously in 8 waves, for a total of 256 missiles, I suspect you are still gonna eat 248 hits, your PD being 97% idle while it happens.

Any chance in the future that is mitigated if not resolved?

I think that might be a strong indicator to switch from quad turrets to singles.

Which, obviously, will only mitigate your specific situation a small amount.  But I'm excited to see C#'s changes in action before requesting further PD changes.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 04, 2020, 06:34:06 PM
I assume PD still only fires on one salvo at a time?

That is, if you have a single quad RoF8 100% gauss turret, and adequate tracking speed, FC range, and crew training to achieve 100% accuracy, allowing up to 32 missile kills per increment, and face 32 single missile salvos arriving simultaneously in 8 waves, for a total of 256 missiles, I suspect you are still gonna eat 248 hits, your PD being 97% idle while it happens.

Any chance in the future that is mitigated if not resolved?

I can't see you ever facing that situation in the game unless you create it yourself. The AI isn't going to design ships that fire hordes of single missile salvos.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 04, 2020, 10:36:24 PM
I can't see you ever facing that situation in the game unless you create it yourself. The AI isn't going to design ships that fire hordes of single missile salvos.

I'd personally be happy to just roll with the progress that was made in that regard, since it does appear to have been somewhat improved.  Though I mean, the better balanced the game becomes the more common player versus player scenarios will become.

e:
I assume PD still only fires on one salvo at a time?

That is, if you have a single quad RoF8 100% gauss turret, and adequate tracking speed, FC range, and crew training to achieve 100% accuracy, allowing up to 32 missile kills per increment, and face 32 single missile salvos arriving simultaneously in 8 waves, for a total of 256 missiles, I suspect you are still gonna eat 248 hits, your PD being 97% idle while it happens.

Any chance in the future that is mitigated if not resolved?

Like guys though, really, its kindof annoying when he improves a thing and you are like 'ree but what about these other things'.  I've been in more than one community like this and its actually pretty counterproductive to be that way at this point, even if it seems to you to be an innocent enough question.
Title: Re: C# Aurora v0.x Suggestions
Post by: shepard1707 on January 05, 2020, 12:26:28 AM
Id probably make the 'How many can it control' part of a Fire Control function similar to fire control speed in bfcs.  So having a large missile swarm capability earlier might be more a matter of how much of your ship you have to cut out to fit it in.

Mind, this would have knock on effects to the effectiveness of anti-missiles.  If the Anti-Missile firecontrol can only handle so many missiles in the air at once, you may not get the chance to just evaporate a salvo so quickly.  And neither will the AI. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on January 05, 2020, 01:01:06 AM
One way to handle missile fire control is with a modifier that exchanges range for greater control, so a max range MFC would only be able to support a single missile, but one whose max range has been shortened by half might support 2, or 4, or some other appropriate number.

By the time you get to very short ranges you could be flinging very large salvos of barely mobile bombs.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on January 05, 2020, 09:23:50 AM
AMMs already suffer vis-a-vis beam PD and if I've understood things correctly, C# is not helping them, whereas the improvements to PD will make that aspect of defence even stronger. Limiting the number of missiles an MFC can control would nerf AMM defence even further. And since PD is getting help with the salvo issue, I really wouldn't want to limit missiles in general even further until we know for sure how much the current changes, all combined together, affect the gameplay.

Any chance in the future that is mitigated if not resolved?
The mitigation to that is to not have all your eggs in one basket. Steve confirmed that the AI will never do that so the only case is in human-vs-human battle scenarios, in which you should diversify your PD anyway. Yeah, that gauss turret is great at taking out one big salvo, so it needs to be accompanied by another ship that is built to take out many tiny salvos. It's not even a problem in multi-faction single-player games, only in specific PvP scenarios, IMHO.

Of course, in the long run I agree that having beam PD use all their capacity instead of being idle would be great but it's not a high priority thing in the current system since I assume it would require replacing the salvo system with something else.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on January 05, 2020, 10:02:35 AM
To make life easier: A comparison chart where you can select two ships / missiles and see the actual detection / weapons range etc.  of each other, according to your Intel.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on January 05, 2020, 10:29:12 AM
Seriously speaking, in human vs human, someone who builds fleets tailored to launch tens of one-missile salvos is in my opinion someone who exploits the game engine to the point I don't want to play against this person.

This is clearly a case that falls so far into mechanics exploitation that I don't care at all. I would simply stop playing against this person in literally 5 seconds, the time needed to delete the game. So who cares.


There needs to be a line bewteen what is acceptable and what is not. I don't think Steve has to work to try to prevent all these tiny, edge-case exploitations that go beyond the scope of normal games. I would hope that even those players that do PvP have enough common sense and moral integrity to avoid these things. Else what is the point?
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on January 05, 2020, 02:22:02 PM
So perhaps taking it to the extreme was a bit much.  That's where everyone has stayed glued.

Steve, apologies if that seemed aggressive, it certainly wasn't the intent, its why my posts tend to be large, I am often misconstrued when too few words are used to clarify my position.  Granted, I could use other words, and perhaps not be so mis-understood, or perhaps more so, who knows.

I think that might be a strong indicator to switch from quad turrets to singles.

Which, obviously, will only mitigate your specific situation a small amount.  But I'm excited to see C#'s changes in action before requesting further PD changes.
Well, yeah, the case was specifically chosen though.  One could doom stack PD and not need to worry ever.  We mostly exist between the extremes, perhaps that was the main failing of my example.

...snipped the quote...
I can't see you ever facing that situation in the game unless you create it yourself. The AI isn't going to design ships that fire hordes of single missile salvos.
Wouldn't fighter or FAC swarms create a similar scenario?  That was more the point, I really shouldn't have made it such an extreme case.  They can create multiple stacked salvos that are far smaller than available PD capability, more numerous than available PD, and larger in sum, and will repeatedly attack as need and/or reloads in a hangar permit.  I assume the AI will use fighters and FACs against us with missiles?  Just using missile fighters against the AI would create this scenario without even trying to.

Example, 10 fighters, 4 launchers each, you've got 40 inbound in 10 salvos, again, assuming an idealised one shot one kill.  Supposing we split the quad turret to singles, you stop 4, have 50% idle, and get plastered by the remaining  6 salvos. If you didn't split the turret and had it as a quad still, you stop one salvo, and eat the remaining 9 salvos, 90% idle.

Perhaps turrets that are under utilised could be permitted to engage another salvo with a penalty to accuracy.  Perhaps, 1-(used/max) for something direct and simple, subtract it off the current base and use that?

Re-using the above scenario, assuming base accuracy of 80%, engages a 4 missile salvo, spends 5 rounds, kills the salvo.  Retargets, base accuracy penalised by 15.6%, accuracy now 64.4%.  Spends 7 rounds to kill 4 missiles, second salvo stopped.  Re-targets, base accuracy now penalised by 37.5%, accuracy now 42.5%.  Spends 10 rounds to kill 4 missiles.  Re-targets, base accuracy now penalised with 68.75%, accuracy now 11.25%, would need 36 rounds to stop 4, has 10, lets say it gets 2.  Rather than only 4 kills, you get 14 of 40.

Using the 4 singles example, same setup.  Each spends 5 rounds for the first salvo it engages, 4 salvos are killed.  Each has 3 rounds left, suffers a 65.5% penalty on their second engagement, 17.5% accuracy.  They would need 23 rounds to kill 4, a bit under 6 per.  To simplify here, lets just say each gets one more kill in, so each tags 5 missiles, instead of just 4.  Rather than only stopping 16 missiles, you stop 20.

In the extreme example I started with, 32 singles, using that setup, you'd average 17 kills per increment, rather than 1.

The salvo system remains essentially unchanged, there is no free lunch, PD is less easily overwhelmed by quantity in salvos, while still easily overwhelmed by quantity in total sum.

Would that perhaps be a sensible mitigation?

...snipped the quote...
I'd personally be happy to just roll with the progress that was made in that regard, since it does appear to have been somewhat improved.  Though I mean, the better balanced the game becomes the more common player versus player scenarios will become.

...snipped the quote...
Like guys though, really, its kindof annoying when he improves a thing and you are like 'ree but what about these other things'.  I've been in more than one community like this and its actually pretty counterproductive to be that way at this point, even if it seems to you to be an innocent enough question.
Its not merely somewhat improved, as is, with what we know now, its enormously improved, and I'm happy to have it either way, overjoyed that he doesn't charge for it, just releases it to us.

That said, he is human, he can forget or overlook things, just as we can.  He is very anti-abuse in some areas, less so in others.  We can't know if this means of abuse is overlooked, intentionally as is, or just lacking a suitable solution until someone asks and he answers.  The topic came up, I asked.

AMMs already suffer vis-a-vis beam PD and if I've understood things correctly, C# is not helping them, whereas the improvements to PD will make that aspect of defence even stronger. Limiting the number of missiles an MFC can control would nerf AMM defence even further. And since PD is getting help with the salvo issue, I really wouldn't want to limit missiles in general even further until we know for sure how much the current changes, all combined together, affect the gameplay.

...snipped the quote...
The mitigation to that is to not have all your eggs in one basket. Steve confirmed that the AI will never do that so the only case is in human-vs-human battle scenarios, in which you should diversify your PD anyway. Yeah, that gauss turret is great at taking out one big salvo, so it needs to be accompanied by another ship that is built to take out many tiny salvos. It's not even a problem in multi-faction single-player games, only in specific PvP scenarios, IMHO.

Of course, in the long run I agree that having beam PD use all their capacity instead of being idle would be great but it's not a high priority thing in the current system since I assume it would require replacing the salvo system with something else.
Definitely agreed on priority, I would note I asked if it had a chance in the future, rather than now. 

I'm not so sure the salvo system needs to die to allow further utilisation.  If I understand things, Missiles move, and in so doing reach a piece of code where PD is checked for as area defence or final fire.  When checked for, spent turrets are skipped over, or excluded from the list which is used to pick the next turret to open fire in defence.  Presumably, once a weapon engages, it is marked as used, and thus not considered in successive salvo movements this increment.  Not marking it used until fully used would leave it available in such case for multiple salvos.  A caveat is if it searches for fully loaded turrets only, a partially spent turret is not fully loaded, no way around that other than a change to what makes the turret available.  I can't say with certainty either way.

Agreed on the obvious in-game design mitigation, not placing all eggs in one basket, it was certainly a contrived situation, but one that comes up often enough in similar state, especially once missile fighters or FACs get involved.  Many small salvos arriving in the same increment.  The obvious answer is to stack many small PD weapons, since collectively they can all engage big salvos, or spread across small salvos, especially now that you do not need more than one FC to engage more than one salvo.

AMM's might need some love someday to make them more viable, yes, or a wholesale hit to PD accuracy to make it less effective, or who knows what else I can't think of now.  I agree its too powerful as is once you can afford to stack competent turrets in your fleet.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 05, 2020, 02:45:25 PM
I don't think this will be any sort of problem as same technology PD weapons will very rarely come even close to 100% final accuracy... if you are close then you are better to make the turrets smaller and with less weapons in the turrets as you will recognise the threat from smaller salvos from fighters in that case. Nothing is forcing you to build quad 100% size Gauss cannons.

Salvo sizes of 4-7 is not that uncommon from smaller regular AI ships either so such salvo sizes are quite common.

I would say that building your PD turrets for engaging salvos at around 5 missiles are a pretty sound logical conclusion. At same tech level that probably are more like a dual or triple turret depending on the fire rate of the cannon.

From a RP stand-point I think that salvo saturation can make some sense. In real life you actually want missiles to come from multiple vectors for example to saturate enemy point defences and salvos could sort of abstract something similar. As a single turret can't focus on more than one incoming salvo at a time.

Some limitation and trade offs can be interesting as otherwise you would always just build the biggest most space efficient turrets all the time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on January 05, 2020, 03:14:37 PM
AMM's might need some love someday to make them more viable, yes, or a wholesale hit to PD accuracy to make it less effective, or who knows what else I can't think of now.  I agree its too powerful as is once you can afford to stack competent turrets in your fleet.

I also apologize if I came as too aggressive myself. I still do think it's rather reasonable, provided you don't build quad gauss. Generally speaking, I turret at most twin gauss cannons...

Do keep in mind, AMM do have a great advantage. You can shoot at each salvo multiple times, provided your sensors allow you. It's still a costly but...

Think of it this way. At decent tech levels, mass PD is better against normal missile salvos. However, it's very inferior against massed missiles strike due to large usage of box launchers. Against a wave of 800 missiles, you're probably better off being able to shoot AMM 6-8 or so times.
So it's a tradeoff. Will you build to defend against normal missile ships? Or against massed box launchers strikes?

All in all, I think the balance is not that bad at average tech levels. It might break at extreme tech levels, I never reached it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 05, 2020, 03:49:46 PM
AMM's might need some love someday to make them more viable, yes, or a wholesale hit to PD accuracy to make it less effective, or who knows what else I can't think of now.  I agree its too powerful as is once you can afford to stack competent turrets in your fleet.

I also apologize if I came as too aggressive myself. I still do think it's rather reasonable, provided you don't build quad gauss. Generally speaking, I turret at most twin gauss cannons...

Do keep in mind, AMM do have a great advantage. You can shoot at each salvo multiple times, provided your sensors allow you. It's still a costly but...

Think of it this way. At decent tech levels, mass PD is better against normal missile salvos. However, it's very inferior against massed missiles strike due to large usage of box launchers. Against a wave of 800 missiles, you're probably better off being able to shoot AMM 6-8 or so times.
So it's a tradeoff. Will you build to defend against normal missile ships? Or against massed box launchers strikes?

All in all, I think the balance is not that bad at average tech levels. It might break at extreme tech levels, I never reached it.

There is a fine balance between beam PD and AMM defences as you need both to be effective.

Large capital ships are not likely to carry large box launched salvos as they are one trick ponies. It will take you weeks to get back to a maintenance facility to reload if the first salvo is not enough, in this case using 30% reduced launchers is likely more usable as you can have some magazines and reload them and supply ships who can supply with more missiles for extended operations. Being able to reload also give a much higher flexibility in missile loads, such as range, sensor etc...

In any way both options for defence is effective in its own sense.

Against regular sized launchers you can make extremely effective PD and with just a tiny bit of AMM make missile attacks way to expensive even against an inferior defending fleet.
Title: Re: C# Aurora v0.x Suggestions
Post by: amschnei on January 05, 2020, 04:51:31 PM
One thing which would be nice would be a simple dropdown menu with previously used names for designed systems, so if I don't have to go and look to see how I spelled "Example Industrial Consortium" when designing a new widget.
Title: Re: C# Aurora v0.x Suggestions
Post by: L0ckAndL0ad on January 06, 2020, 02:19:49 PM
I was reading through all the changes notes and found the info about the AI using fuel now in C#, while still being given a leeway to travel without fuel while searching for it, which is a great change IMO.

With the new maintenance system in place, hasn't there been anything similar done to AI ship usage of MSP? In my current 7.1 campaign, I see two NPRs (now both friendly, thankfully  :)) mass hundreds and hundreds of ships. They don't need maintenance and it's frankly terrifying and... discouraging.

If similar (to fuel) changes cannot be made to AI ship MSP usage, can, at least, AI ships have some sort of rules to scrap old ships to prevent huge  NPR navies?

Also, I'd welcome any features involving giving more control to Civilian sector, like moving minerals between planets the same way they can transport installations for you.

Otherwise, all the C# changes I've read about so far sound absolutely great. Thank you for your work, Steve!
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 06, 2020, 02:49:49 PM
I was reading through all the changes notes and found the info about the AI using fuel now in C#, while still being given a leeway to travel without fuel while searching for it, which is a great change IMO.

With the new maintenance system in place, hasn't there been anything similar done to AI ship usage of MSP? In my current 7.1 campaign, I see two NPRs (now both friendly, thankfully  :)) mass hundreds and hundreds of ships. They don't need maintenance and it's frankly terrifying and... discouraging.

If similar (to fuel) changes cannot be made to AI ship MSP usage, can, at least, AI ships have some sort of rules to scrap old ships to prevent huge  NPR navies?

Also, I'd welcome any features involving giving more control to Civilian sector, like moving minerals between planets the same way they can transport installations for you.

Otherwise, all the C# changes I've read about so far sound absolutely great. Thank you for your work, Steve!

I will tackle AI maintenance at some point, but probably not for initial release.
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on January 06, 2020, 03:53:52 PM
Does the AI currently try to stay within (or near) the limit of its maintenance facilities, even if it doesn't technically use them? That seems like the easiest implementation without making them care about actual maintenance.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 06, 2020, 04:52:48 PM
Does the AI currently try to stay within (or near) the limit of its maintenance facilities, even if it doesn't technically use them? That seems like the easiest implementation without making them care about actual maintenance.

To do that, it would also have to consider building extra maintenance facilities when needed, or predict they will be needed, and to prioritise that over other construction tasks. For the full maintenance, the AI will have to take into account availability, location and production rates of maintenance supplies. It's not straightforward, but I will probably aim for something similar to fuel, where the AI does the best it can, but isn't penalised too heavily if it runs out.

Title: Re: C# Aurora v0.x Suggestions
Post by: AlStar on January 08, 2020, 10:05:16 AM
I was thinking that a ground-based invasion risk (which isn't combined with a major space force) could be interesting.
Basically, motherships that, upon getting within range of a colony, fire off dozens of armored shuttles which drop off an assault force - possibly consuming the mothership in the process.

Now as to how to actually get these motherships within range of colonies, I had two ideas - first, that they come from unexplored jump points, and will head towards habitable planets (if any exist in the system).  Once they get within active sensor range of the planet, if they detect anything, they launch.  If no planets have a colony they can detect (or if no habitable planets exist), they pick a random (explored) jump point and jump through it.

Alternatively, the motherships are generated in the system, powered down (and/or stealthed), within passive sensor range of habitable planets.  Once a colony gets large enough to trigger their sensors, they power up and drop their shuttles.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 08, 2020, 11:37:13 AM
One suggestion that might be interesting about Beam Fire-controls.

I don't particular like that fighter fire-controls are just arbitrarily smaller, I do understand that it is game balance... but I think it could be better. I offer an alternative that give more options.

When you create a fire-control you select whether it should be ship, turret or fixed (or ground based).

The ship fire-control is tied to the ships speed and can never deliver more accuracy than the speed of the ship with a lower cap of the basic speed of the fire-control. This fire control are x2 the speed of the normal fire-control.

The turret fire control is pretty much your standard fire-control.

Fixed installation fire-controls can only function on space station or structures with no engines. They get a x1.5 modifier to the range efficiency.

Ground based fire-controls get the same x2 range bonus as it does in C# currently.

Or some variation of this... shure... you could probably game some if this with tractoring space station modules for better FC or something, but that could possibly be fixed or just ignored.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 08, 2020, 12:12:16 PM
I don't think I mentioned anywhere but I removed the fighter beam fire control. All beam fire controls now have the same rules.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on January 08, 2020, 02:48:36 PM
Are there any plans to replace them with some other mechanic? It seems like beam fighters have no real niche as it is.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 08, 2020, 03:45:18 PM
Are there any plans to replace them with some other mechanic? It seems like beam fighters have no real niche as it is.

Beam fighters can be quite effective against other fighters and as PD for other fighters or even ships for that matter. It is far cheaper to kill enemy fighters with beam weapons than missiles. They could also work well against more or less unarmed scouts for example.

With the new sensor rules in C# it is quite cheap and effective to keep a small PD screen for your fighter-bombers.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 08, 2020, 03:51:03 PM
I don't think I mentioned anywhere but I removed the fighter beam fire control. All beam fire controls now have the same rules.

That sounds good... although I still think you could do something more with beam fire-controls.

For example having longer range on station beams would make them more viable as defensive obstacles in space other than used as missile platforms, especially if you want to defend a point in space, such as a jump point.

Then having a fire-control that act sort of like the fighter fire-control did but available for any ship could also be interesting.

Or perhaps something completely different.

Not something I would suggest for the release of C#, but something down the road perhaps.

I would also not mind if fire-controls had some more limitation such as how many weapons they can serve and what type of weapons. I guess that a fire-control for a laser would probably be very different from a fire-control for a rail-gun for example.
Title: Re: C# Aurora v0.x Suggestions
Post by: shepard1707 on January 09, 2020, 06:31:18 AM
Another one off of my head, though I'd be very surprised if it hasn't been suggested in some way before:

Changing the way power plants and thrusters both work.

Specifically, Power-Plants now require fuel to operate, demanding a given amount of fuel per power-hour they produce.  Like with engines, if they are not using their full power, they do not use their full fuel consumption.  Like with engines, their efficiency is closely related to both their size, and their 'boost' out put, with high efficiency 'commercial' engines having low total output and large size, and on the other end high boosted engines being much much less efficient, but much smaller and with better total power outputs.  The explosion chance upon destruction would likely remain.

The big thing this would change, however would be that now, everything requires some degree of power output.

Engines, in this case, would no longer require any fuel to operate.  This is because, rather than being based on our modern understanding of Newtonian physics where fast thing goes out back, ship moves forward, they instead impel against the Aether/Sub-Space in some way.  Making this single change alone, however, does certainly flatten the granularity of engine design, which is why I propose a pair of further additions, this time onto Engines: Top Speed/Cruising Speed and Acceleration.  They might both be taken, or neither.

In the case of Top Speed/Cruising-Speed, the power necessary to operate an engine could be on a curve towards 100% at 100%, such that at 50% speed the engine is using less than 50% power, and thus, less than 50% fuel.  Boosted engines would basically expand the curve, while more efficient engines would shrink it back.  More powerful engines produce more engine power for a given amount of power input, thus producing a different function of efficiency to speed.

Alternately, one could include acceleration: Ships now do not automatically go 0 to x000km/s But require some time to accelerate towards their top speed.  More efficient engines are slower to accelerate, while less efficient engines have much higher acceleration.  This could be combined with the concept of Top/Cruising Speed by having engines use their full power requirement during acceleration, but require only HALF power when above or below a certain speed threshold.  A 'Commercial Engine' in this case would have it's cruising speed BE it's top speed, but perhaps still being inefficient in size, while a fighter or missile engine wouldn't have any cruising speed at all, but be at reduced size.

In this case, 'Acceleration' also becomes the measure of maneuverability, rather than top speed.  Determining how quickly a vessel can change course, how easily it can avoid enemy fire, etc.  (In the case of the former, perhaps the percentage of acceleration compared to top-speed functionally determines how fast it can turn within a 5 second interval).

I dunno.  A lot of this was written while forced awake by nasty gas pain.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 09, 2020, 07:14:05 AM
Sounds interesting... I agree that handling the power grid of ships would make an additional variable to juggle and could be fun. I certainly like engines that would have differences in acceleration versus efficient etc... that sounds fun.

You could build a ship that could fire all their weapons, power the shield and run at max acceleration or speed at the same time, but you would compromise the space for weapons and defences to accommodate for powering all those systems at the same time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 09, 2020, 09:13:43 AM
Are there any plans to replace them with some other mechanic? It seems like beam fighters have no real niche as it is.

The 'fighter-only' beam fire control was removed because there wasn't really any reason that a fighter could have that and a normal ship couldn't. I am trying to rationalise as much as I can for C# and remove any 'special' rules. Fighters aren't F-18s, they are just small ships. Besides, BFC are smaller and cheaper than when the 'fighter-only' rule came into effect, plus sensors are smaller for fighters in C#, so there is more room for the fire control anyway.

I'm using beam fighters in my current campaign and they seem fine so far.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on January 09, 2020, 12:37:13 PM
We've had multiple flavours of suggestions over the years about power plants, power management, and fuel/power budget. It would be a massive changed to everything ship-related in Aurora. I'm not sure that a complex power management system, in both ship design and ship use, is where Aurora should go or needs to go - especially as Steve already removed one micromanagement aspect: shields no longer consume fuel, as well as making Fire Control/Weapon assignments easily automated.

Power management is great in a space sim game where you control a single ship. Not so much when you could have a hundred ships/fighters engaged in battle and you might need to fiddle with them. And if you only implement power management at ship design, you're going to have a lot of people demanding that it should be a part of combat too - all power to the shields and all that jazz.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 09, 2020, 01:34:31 PM
We've had multiple flavours of suggestions over the years about power plants, power management, and fuel/power budget. It would be a massive changed to everything ship-related in Aurora. I'm not sure that a complex power management system, in both ship design and ship use, is where Aurora should go or needs to go - especially as Steve already removed one micromanagement aspect: shields no longer consume fuel, as well as making Fire Control/Weapon assignments easily automated.

Power management is great in a space sim game where you control a single ship. Not so much when you could have a hundred ships/fighters engaged in battle and you might need to fiddle with them. And if you only implement power management at ship design, you're going to have a lot of people demanding that it should be a part of combat too - all power to the shields and all that jazz.

Well it works pretty well in games such as Distant Worlds which have far less intricate ship design systems. They work pretty much as described above and it work fairly well and is not difficult to comprehend or design around. There you have three different speed settings which all use different amounts of energy and thus fuel. You need fuel to power the power plants and the efficiency of burning fuel is connected to the type of power plants that you have.

I don't think it would be difficult to handle if it was changed down the line, it would at least open up several new possibilities to build ships and why you do it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Alsadius on January 09, 2020, 01:44:34 PM
Well it works pretty well in games such as Distant Worlds which have far less intricate ship design systems. They work pretty much as described above and it work fairly well and is not difficult to comprehend or design around. There you have three different speed settings which all use different amounts of energy and thus fuel. You need fuel to power the power plants and the efficiency of burning fuel is connected to the type of power plants that you have.

I don't think it would be difficult to handle if it was changed down the line, it would at least open up several new possibilities to build ships and why you do it.

It'd make for a decent game, but it'd also make for a very different game. Just assume that the power plants are included in the weight of the other modules, especially the engines. (Yes, this makes the power plant modules slightly odd - call them "power converters" or something?)
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 09, 2020, 04:08:59 PM
Ships already have a 'power budget' -- power plants vs capacitors -- so if this expanded to include additonal components on either side of the (in)equation I wouldn't mind.

. . . But I absolutely DO NOT WANT any sort of in-combat power allocation decisions.  If I'm hurling a thirty-six vessel battlefleet versus a hundred-odd bug ships of the Arachnid Omnivoracity it would be a nightmare of micro-management.  Tell me at ship design that I need extra power converters or batteries or auxiliary warp reactors for my sensor suite, fine, but don't slow down my gameplay.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 09, 2020, 05:22:33 PM
Ships already have a 'power budget' -- power plants vs capacitors -- so if this expanded to include additonal components on either side of the (in)equation I wouldn't mind.

. . . But I absolutely DO NOT WANT any sort of in-combat power allocation decisions.  If I'm hurling a thirty-six vessel battlefleet versus a hundred-odd bug ships of the Arachnid Omnivoracity it would be a nightmare of micro-management.  Tell me at ship design that I need extra power converters or batteries or auxiliary warp reactors for my sensor suite, fine, but don't slow down my gameplay.

It probably would simply work like power plants do right now, more or less if you don't have enough power to power all the systems at once it would shut down system  according to a priority list. You probably could decide what that is. So it could shut down sensors first, reduce engine speed second and weapons last... or some such. You should not need to micromanage it. It would be a power pool like now but for more things than just weapons.

Or it would just make weapons fire slower, active sensors to be reduced in power and engines slowing down... until you say turn of the sensors or change the speed of the ships yourself.

The same when the reactors get damaged.

At least that is how I envision it could work.

It should not be a complicated system and it should only include active system, those that you don't always use, such as active sensors, weapons, shields and engines... perhaps even hangars. Less power to the hangar means lower reload, repair and refuel rates of crafts. More permanent passive system should probably be excluded for simplicity such as crew, maintenance, bridge systems and the like.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 10, 2020, 02:39:57 AM
One more suggestion I would like to see in C# is a change in how the capacitor work with energy weapons. Certain weapons and levels are really bad in how they line up with Capacitor technology and the required energy. Since weapons only fire every five seconds there are often huge waste of the the energy the goes into the weapon making them very inefficient. Particle Beams have a particular problem with this.

I think that energy should go into the weapon power bank and stored so that weapons sometimes fire 5s earlier once in a while if possible.

Example
A Particle beam with Strength 3 has a power requirement of 7, there are no Capacitor level to correctly charge the weapon and capacitor of 3 is normal at that tech level and that makes the gun fire every 15s. But if you charged the weapon with 9 power then 2 power should remain in the gun and transferred to the next cycle so now it will fire after 10s two times in a row. So this way the particle beam would fire 15s, 10s, 10s.

This way you would not have to figure what capacitor to stick in a weapon as long as it does not supply more power than it can use to fire every 5s.

You could show the fire cycle in the profile like 15s/10s(2) or something.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 10, 2020, 04:54:32 AM
I'm a big fan of Star Fleet Battles, which had an extensive power management system. However, that is a tactical game and Aurora is more at operational level. I consciously left out tactical elements such as facing, weapon arcs, hiding behind terrain, power management, etc..

Adding that type of detail would be overwhelming in large battles. Also, detail is important in tactical battle games because careful management of small edges can make a difference in a balanced engagement. Conversely, many Aurora battles are decided before the first shot is fired and careful management of small edges is often irrelevant to the outcome.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 10, 2020, 06:49:12 AM
I'm a big fan of Star Fleet Battles, which had an extensive power management system. However, that is a tactical game and Aurora is more at operational level. I consciously left out tactical elements such as facing, weapon arcs, hiding behind terrain, power management, etc..

Adding that type of detail would be overwhelming in large battles. Also, detail is important in tactical battle games because careful management of small edges can make a difference in a balanced engagement. Conversely, many Aurora battles are decided before the first shot is fired and careful management of small edges is often irrelevant to the outcome.

One interesting effect that I miss from Aurora is the ability to run from a fight as speed are sort of arbitrary. If tied to some power systems it would be able to build ships that can run away fast but not fire its weapon or perhaps not even use their shields. Since you would have to juggle these things you are likely to be able to sprint out of danger as the enemy can't sprint as fast AND shoot their weapons at the same time. If you design a ship around max speed and weapons firing the ship would have to sacrifice allot of other operational benefits such as total weapon power, defensiveness leaving them vulnerable in other ways.

At least there would be a wider gap between moving at chasing speed and fleeing speeds that I think would add to the tactical element of the game.

So there could be some potential interesting effects from being able to do this. I do agree with too much micromanagement... it would have to be a system that is highly automatic and streamlined to work well.

Or for simplicity if you would allow for such tactics then introduce a flanking speed mode where the ship move at say +25% speed but can't use any weapon systems or active sensors and burns twice the amount of normal fuel AND run the maintenance cycle like four times the speed or something. A ship could not even use missile fire-controls thus guide missiles in flight during such speeds, missiles would simply stop until you slow down and acquire the target again to guide the missiles. Once a ship stop moving at flank speed there should be a grace period before weapon and system can be activated, much like making a combat jump. Otherwise you could flank speed at a fleeing enemy and drop out when you are right on top of them and fire your weapons.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 10, 2020, 07:27:15 AM
One interesting effect that I miss from Aurora is the ability to run from a fight as speed are sort of arbitrary. If tied to some power systems it would be able to build ships that can run away fast but not fire its weapon or perhaps not even use their shields. Since you would have to juggle these things you are likely to be able to sprint out of danger as the enemy can't sprint as fast AND shoot their weapons at the same time. If you design a ship around max speed and weapons firing the ship would have to sacrifice allot of other operational benefits such as total weapon power, defensiveness leaving them vulnerable in other ways.

At least there would be a wider gap between moving at chasing speed and fleeing speeds that I think would add to the tactical element of the game.

So there could be some potential interesting effects from being able to do this. I do agree with too much micromanagement... it would have to be a system that is highly automatic and streamlined to work well.

Or for simplicity if you would allow for such tactics then introduce a flanking speed mode where the ship move at say +25% speed but can't use any weapon systems or active sensors and burns twice the amount of normal fuel AND run the maintenance cycle like four times the speed or something. A ship could not even use missile fire-controls thus guide missiles in flight during such speeds, missiles would simply stop until you slow down and acquire the target again to guide the missiles. Once a ship stop moving at flank speed there should be a grace period before weapon and system can be activated, much like making a combat jump. Otherwise you could flank speed at a fleeing enemy and drop out when you are right on top of them and fire your weapons.

Some form of increased speed with a penalty or associated risk might be OK - perhaps like Orion Pirates in SFB or the engine tuners in Starfire. I'll give that some thought.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bughunter on January 10, 2020, 08:04:54 AM
In most scenarios I think the stronger side would just chase down the weaker regardless, wait out whatever timer and kill them. I don't like that version at all.

Maybe if it was introduced as pushing engines over safe limits and involve a risk of them (per engine) breaking or even exploding? The weaker side would not have much to lose from taking the risk, the stronger would by definition have to risk more assets to pursue. Fuel efficiency penalty also seems appropriate.

Still they would have to be relatively equal in speed to begin with for this to give you edge enough to flee so I would not expect that scenario to play out too often. And how long can you sustain it? They might chase you for days if they know where you are going. If it can be sustained for any length of time it would be used for other purposes as well.

Even if only a temporary speed increase can be achieved I would expect it to be weaponized somehow regardless of risk. Missiles where you accept a certain failure rate, AMM:s, dropships..

But I could see some interesting things coming out of going in this direction. The risk/reward approach to designs, more depth to how many engines/repair capacity to include. The decision if to boost or not. Even on a tactical level trying to lure enemies into boosting after your smaller force and pick off stragglers who blow their engines with your second taskforce.
Title: Re: C# Aurora v0.x Suggestions
Post by: clement on January 10, 2020, 08:21:51 AM
Instead of linking engine tuning to a time limit, have it trigger a higher failure rate for engines. If the failure rate of an engine was increased by a factor of 10 or 100, then there would be a serious trade off. If tuning was a flat speed boost, I am sure Steve can figure out what kind of increased failure rate for engines would be sufficient to prevent it from being abused. If the tuning level is variable, then it could be a scalar for the increase in the failure rate.

This means ships fleeing could escape but run the risk of engine failures and detonations if they run out of maintenance supplies..

It could of course also prevent weapon firing while active.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on January 10, 2020, 09:06:50 AM
I'm a big fan of Star Fleet Battles, which had an extensive power management system. However, that is a tactical game and Aurora is more at operational level. I consciously left out tactical elements such as facing, weapon arcs, hiding behind terrain, power management, etc..

Adding that type of detail would be overwhelming in large battles. Also, detail is important in tactical battle games because careful management of small edges can make a difference in a balanced engagement. Conversely, many Aurora battles are decided before the first shot is fired and careful management of small edges is often irrelevant to the outcome.

I think I agree with Steve that given this is primarily an operational simulator, power management might be too much in the weeds to create enjoyable game play - there is essentially a lot of detail work for minimal game play benefit once the battle is actually joined.  Certainly one can always build faster ships but the sacrifice for weapons is already built in it seems.  If catching those fleeing ships is a problem, divide your force and box them in.  Take long range missile shots and score engine shots and pick off stragglers.  I think there are some other options to be consider:  Steve indicated a possible modifier which might be do the trick.  Perhaps doing something with Commander or Engineer's engineering skill allows one to get more speed out of an engine.  I think I also like the idea of a 'disruptor' sort of weapon system - an EM warhead on a missile which makes a temporary debuff perhaps?
Title: Re: C# Aurora v0.x Suggestions
Post by: Alsadius on January 10, 2020, 09:10:22 AM
Some form of increased speed with a penalty or associated risk might be OK - perhaps like Orion Pirates in SFB or the engine tuners in Starfire. I'll give that some thought.

Suggestion: How about a checkbox that I'll call "Brave Sir Robin Mode"?

Penalty: All power plants, shield generators, sensors, and fire controls are disabled.
Bonus: Engine power is increased by a factor of (tonnage of above module types / tonnage of engines) * 50%. Fuel use and thermal signature increases by a factor of (tonnage of above module types / tonnage of engines) * 2.

Example: Consider a 10,000 ton ship with 1000 tons of engines and 500 tons of power plants/sensors/fire. If it checks Brave Sir Robin Mode, all its sensors turn off, but their power is now diverted to the engines. That 500 tons of gear acts like 250 tons of engine, and increases the ship's speed by 25%. However, it's just lost its eyes and its ability to fire most weapons. It's also doubled fuel use and thermal signature, because high-power mode on the engines is pretty inefficient.

It's simple, it can be a checkbox on the fleet, and it isn't something you'll normally want to use(since the mass and fuel ratios are much worse than for dedicated engines, and most of that gear is more expensive per HS as well). But it'd be an option if you just need to GTFO back to the nearest gate as soon as possible.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on January 10, 2020, 09:29:18 AM
Instead of linking engine tuning to a time limit, have it trigger a higher failure rate for engines. If the failure rate of an engine was increased by a factor of 10 or 100, then there would be a serious trade off. If tuning was a flat speed boost, I am sure Steve can figure out what kind of increased failure rate for engines would be sufficient to prevent it from being abused. If the tuning level is variable, then it could be a scalar for the increase in the failure rate.

This means ships fleeing could escape but run the risk of engine failures and detonations if they run out of maintenance supplies..

It could of course also prevent weapon firing while active.

I agree with Steve and Father Tim 100% about the micromanagement hell that would arise if SFB-esque energy management were introduced in Aurora.

OTOH, I really like this (and Bughunter's) "engine tuners" idea as something to contemplate, where tuning leads to very high risk of engine breakdown (or explosion).  A few observations:

1) It instantly brings to mind the scene from one of the Hornblower books (Hotspur perhaps), where he's scouting for the Brest blockade force and a French frigate comes out and pursues him in a long stern chase in heavy weather.  My recollection is that they both pile on too much sail for the weather until someone's mast breaks, which is analogous to an overstressed (from tuning) engine breaking down.  From this point of view it's a really cool idea.
2) Steve is intimately familiar with the "engine-tuning-chase-leading-to-breakdown" scenario - there are a bunch of these in the Rigellian Diaries.  So I think he'll have a good feeling for whether he thinks it's a positive or negative game mechanic.
3) One of the things I remember from the diaries is that both sides essentially always tuned.  IIRC this was because the pursuing force was usually a (bug) swarm, and the only bad thing that would happen was non-catastrophic, i.e. and engine breakdown.  So this kind of takes away the ability to make choices - tuning is obviously superior over not tuning in the pursuit scenario.  So if Steve did put this in, I would advocate having the breakdown penalty include a significant (e.g. 50% of the time) risk of explosion.  That would make the decision a lot more stark, and add to fiction possibilities (especially if it were technobabbled that when tuning goes bad the engines run away and there's e.g. a 15 second window where the crew (not the player) can recognize this and try to shut tuning down with a 50/50 chance of explosion vs damage.  Just enough time for the engineer to say "Captain, engines are destabilizing.  Attempting to [BOOM]")
4) There are two scenarios: 1) small tactical advantage in combat, i.e. closing to beam range 2) long term running away (where you have to get all the way across the system to get to the warp point/out of sensor range).  This means that for it to be a useful mechanic the failure rates would probably need to be fairly low; on a timescale of 1 week mean time to boom.  OTOH, if you just need to stay out of beam range, or if you're just a little inside the enemy's sensor envelope they could be shorter.  In other words, I'm not sure the coolness factor outweighs the coding work.
5)  I would put the flag at the TG level, and I would have it increase the max possible speed.  This is because some ships in the TG might be able to go faster, and should not be penalized as badly.  In other words, it's only that slow BB (or whatever) that needs to tune to keep of with the rest of the TG while running away.

John
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 10, 2020, 09:31:48 AM
Starfire - the  distant, original ancestor of Aurora - had two game play concepts that might work here.

1) Detuning: A mode that could used for all engines. In Aurora terms, this would be an on/off function at the ship level that provides a small boost to speed (perhaps 20%), reduces sensor range, impairs fire control and has an increasing risk of damage to engines.

2) Engine Tuners. A system built into engines that provides a boost to speed without penalty for a given period. The system itself requires additional space. In Aurora terms, it would be on/off at the ship level for ships with engines equipped with tuners. As the tuners add mass without power, they would either reduce normal speed or reduce available space in exchange for a short-term, tactical speed advantage.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 10, 2020, 09:37:20 AM
I think it is also worth mentioning that in Starfire, everyone was essentially at the same speed, so small speed advantages made a difference. That won't be true very often in Aurora, so the speed boost and penalties would have to be much larger for it to be relevant.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on January 10, 2020, 09:38:12 AM
I  think 2) sounds like a reasonable solution.  Give Engine Tuners a research line with increased power per level, or size.  I think making it a fixed size that makes them not a consideration for fighters or frigate-sized vessels - it is a module that really be viable for light-cruisers or above - would reduce the chances of unhittable small craft.
Title: Re: C# Aurora v0.x Suggestions
Post by: lupin-de-mid on January 10, 2020, 10:01:51 AM
In Honorverse they fly on 80% of full power (except in emergencies)
So full death of all crew on ship is . . .   mmm . . .  nice bonus for boarding  teams of wininners.
But 25% of acceleration boost there is slightly more than 25% of speed increase here in Aurora.
Numbers definitely should be tuned
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on January 10, 2020, 11:11:05 AM
Perhaps a delay in activation for the tuners, to make it possible to catch an opponent off guard before they boost off? Attach it to a tech line, starting at like a two minutes and going down to 15 seconds. This also solves the issue of having a faster opponent always able to win beam, because if you activate your boost first they can't immediately respond. This seems like a practical, interesting solution to several issues at once.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on January 10, 2020, 12:36:12 PM
I don't think this would add much of usefulness. As others said, speeds are nowhere near equal in Aurora, not even among same engine generation ships of roughly the same size. Let's say it's a 20% speed increase with engine tuners which sounds reasonable but,

Ship A is 2500 km/s whereas Ship B is 3000 km/s. Yeah, ship A could now maintain distance to ship B but couldn't escape. And that's a really small speed difference in the first place. Could be that ship A is 5000 km/s and ship B is 8777 km/s - now 20% speed increase for ship A makes no difference whatsoever, except for a very specific situation where you have relief ships coming in just close enough that the longer time for ship B to close the distance makes a difference.

Another thing is missiles. Now that engines are unified across all sizes, it means that missiles should get tuning as well. That's not a bad thing, increased last minute acceleration is a staple of Sci-Fi and it could make PD a little bit more exciting. But in Starfire tuning makes a difference because missiles are so short ranged, whereas even in C# Aurora, we're talking about tens of million of kilometres with just normal ASM. Whether the target moves 20% slower or faster makes no difference in that scenario.

If it's not a difficult thing to add, then yeah more options is better than less options, but I foresee a situation where beam ships always have them but there's no point in putting them on anything else, except maybe fast scouts. What's the point of a module where its inclusion is a no-brainer? At least with ECM and ECCM, there are ways to around them so while useful, they are not mandatory. With engine tuners, they definitely were mandatory in Starfire according to the AARs I've read here, and that might happen easily in Aurora too.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on January 10, 2020, 12:56:49 PM
The obvious solution, in my mind, is just to make the tuner more powerful. Also, why not, instead of having a single component to increase speed by a percentage, just have a "Booster" component that acts as a very powerful, very fuel inefficient engine with a limited use period. That seems the more flexible system. You could even have it so that you could decide the speed multiplier, size and fuel efficiency like a normal engine but also pick the duration, as a size/cost multiplier.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 10, 2020, 01:30:41 PM
For me the idea of burning a lot more fuel and steadily damaging the engines is a rather fun way to handle a speed boost, since I think it would better depict a low tech race trying to catch a higher tech one.  "sir we are measuring a 80% increase in enemy engine power" >one of the enemy ships explodes into a million pieces "they cant keep this up forever..."

I feel the need to mention that since I think 'tuners' without tradeoffs like that, or at least the option to significantly overdrive them and start taking tradeoffs, is less fun.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 10, 2020, 03:53:44 PM
Personally, I still like my suggestion here (http://aurora2.pentarch.org/index.php?topic=9841.msg117751#msg117751) for missiles designed to take out enemy engines. I think it provides similar gameplay effects to engine tuners while not requiring special new mechanics, and having more tactical counters available.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 10, 2020, 04:09:54 PM
I do agree that if such a system was in place as a booster tech then the bonus speed would have to be large enough to bridge at least a 25-50% gap as speed in Aurora can differ rather much. There could also be a technology that give you more boost and perhaps also damaging the engines less. Say that boosting tech start at 20% and slowly can rise to about 50%. Another technology could decrease the damage to the engines as the higher the boost you select the more damage it does to the engines. The boost should be tied to the engine directly, I think that seem the easiest. So you would select it in the same way you select if the engines would have reduced thermal radiation.

I don't think I agree that it would necessarily favour beam offensive ships that much, it could but it certainly would not need to. Especially if there is a grace period from when you drop the speed until weapons come online again. Then you could not just steam in and fire, you would have to wait before doing so and under that time the opponent could increase the range again. But in some situations it would not matter either way, but in some it might matter allot. I think that if you use beam oriented combat ships you still would rather have really fast reliable engines rather than boosting them.

The feeling I'm after are more one of making a tactical retreat from a battle where speeds are similar. It will mean that two opponents with roughly similar speeds then both will be able to pull away from a fight if it goes badly instead of one side always having a small advantage because their ships are 10-20% faster. Another thematic scenario would be when I need to push my ships engines to respond to a threat that have taken me by surprise, I now need to steam my ships over two system, burn twice the MSP in store on the way and will be forced into overhaul after the mission is over.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 10, 2020, 05:21:57 PM
I would suggest that the boost thing be a separate module, whatever it is.  That way you can choose to retrofit it onto existing ships if you previously didn't want to invest in that but are suddenly facing high tech enemies.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on January 11, 2020, 02:56:30 AM
Starfire - the  distant, original ancestor of Aurora - had two game play concepts that might work here.

1) Detuning: A mode that could used for all engines. In Aurora terms, this would be an on/off function at the ship level that provides a small boost to speed (perhaps 20%), reduces sensor range, impairs fire control and has an increasing risk of damage to engines.

2) Engine Tuners. A system built into engines that provides a boost to speed without penalty for a given period. The system itself requires additional space. In Aurora terms, it would be on/off at the ship level for ships with engines equipped with tuners. As the tuners add mass without power, they would either reduce normal speed or reduce available space in exchange for a short-term, tactical speed advantage.

Another option might be to make it work the other way around.

Have Military engines listed speed still be their maximum but offer a economy / cruising mode where the ship move say 50% Speed for 30% fuel consumption or something along those lines. ( With fuel consumption being connected perhaps to minimum engine power modifier tech line ).

This would allow design of ships with a bit higher power modifier without crippling their economical range.
Title: Re: C# Aurora v0.x Suggestions
Post by: BwenGun on January 11, 2020, 05:20:58 AM
Starfire - the  distant, original ancestor of Aurora - had two game play concepts that might work here.

1) Detuning: A mode that could used for all engines. In Aurora terms, this would be an on/off function at the ship level that provides a small boost to speed (perhaps 20%), reduces sensor range, impairs fire control and has an increasing risk of damage to engines.

2) Engine Tuners. A system built into engines that provides a boost to speed without penalty for a given period. The system itself requires additional space. In Aurora terms, it would be on/off at the ship level for ships with engines equipped with tuners. As the tuners add mass without power, they would either reduce normal speed or reduce available space in exchange for a short-term, tactical speed advantage.

The advantage of the second one is that it does provide another way to make beam weaponry more viable. As missile armed ships with fast drives are almost impossible to deal with using beam armed warships unless you're able to endure the barrage until the enemy runs out of munitions and are forced to withdraw. Being able to build engines with a sprint mode might well provide more opportunities where if a missile armed combatant is out of place that beam armed ships might be able to rapidly close the distance and bring them within range.

As someone else mentioned though I think using the Honorverse trade-off might be suitable, whereby sustained boosting has an increased chance of the inertial dampeners failing and killing everyone aboard the ship. Meaning you could perhaps run for a few hours at 120-150% your speed, but the longer you do it the more chance that a ships systems will catastrophically fail and either kill everyone aboard or if you wanted to make it slightly less drastic cause widespread loss of life and injury amongst the crew, thus making the ship combat ineffective for a period of time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 11, 2020, 06:24:18 AM
Something else to bear in mind is that faster ships are harder to hit. If the penalty for using some form of 'tuner' was relatively minor, it would be used whenever a ship came under attack, which means all weapons become relatively weaker, which means shields become relatively stronger vs armour. I have to be careful here that an apparently minor change doesn't have far-ranging effects. To avoid the above, there would have to be significant penalties to fire control.

It could also make things more difficult for the AI, depending on the mechanics.

Maybe the other suggestion, to have some form of anti-engine missile warhead, would be a better option.
Title: Re: C# Aurora v0.x Suggestions
Post by: Sleepymoon on January 11, 2020, 07:38:43 AM
You do all know this mechanic already exists in-game?
It's called Maximum Engine Power Modifier.

Pros:
It's already in the game.
You can use it anytime you want for as long as you need it.
Steve doesn't have to keep pushing back the release date to program new stuff.
It doesn't damage or destroy your ships when you use it.
No need to micromanage your ships.
You can choose how much boost you want.

Cons:
It costs more to research and build.
It uses more fuel.
You actually have to make compromises when designing your ships.
Edit: slightly more explody.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 11, 2020, 07:49:02 AM
You do all know this mechanic already exists in-game?
It's called Maximum Engine Power Modifier.

Pros:
It's already in the game.
You can use it anytime you want for as long as you need it.
Steve doesn't have to keep pushing back the release date to program new stuff.
It doesn't damage or destroy your ships when you use it.
No need to micromanage your ships.
You can choose how much boost you want.

Cons:
It costs more to research and build.
It uses more fuel.
You actually have to make compromises when designing your ships.

That would not really be the same thing. The whole point were a way to retreat for both sides as neither can use weapons during the boosted engine usage, thus you could retreat to a safe zone where you can defend and the enemy can't follow you or they will suffer defeat.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 11, 2020, 07:57:32 AM
Something else to bear in mind is that faster ships are harder to hit. If the penalty for using some form of 'tuner' was relatively minor, it would be used whenever a ship came under attack, which means all weapons become relatively weaker, which means shields become relatively stronger vs armour. I have to be careful here that an apparently minor change doesn't have far-ranging effects. To avoid the above, there would have to be significant penalties to fire control.

It could also make things more difficult for the AI, depending on the mechanics.

Maybe the other suggestion, to have some form of anti-engine missile warhead, would be a better option.

For missiles I would like two ways to mess with an opponent. A missile with a microwave type warhead and a way to target engines using passive thermal sensors that would have a chance to hit engines directly through armour. A microwave warhead could probably also work with EM sensors on missiles which then would increase the hit chance of such missiles or the chance to effect the enemy ships electrical components.

I also think that active missiles should do something beside homing in such as adding extra to hit chance depending on the time the missile are able to track the target. Something like the tracking time bonus for beam weapons.

This would make it more important with hardened sensor systems and perhaps add an armour component to the engine design. Perhaps also make reduced thermal engines harder to hit or simple the less thermal signature the harder it is to hit with such missiles.

You could also allow engines to have degrading performance from damage so can receive partial destruction as one solution. Engines could also be hit through armour with beam weapons besides chock damage. I'm pretty sure that armour engines will be very difficult with 100% certainty.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 11, 2020, 10:22:35 AM
You do all know this mechanic already exists in-game?
It's called Maximum Engine Power Modifier.

Pros:
It's already in the game.
You can use it anytime you want for as long as you need it.
Steve doesn't have to keep pushing back the release date to program new stuff.
It doesn't damage or destroy your ships when you use it.
No need to micromanage your ships.
You can choose how much boost you want.

Cons:
It costs more to research and build.
It uses more fuel.
You actually have to make compromises when designing your ships.

That would not really be the same thing. The whole point were a way to retreat for both sides as neither can use weapons during the boosted engine usage, thus you could retreat to a safe zone where you can defend and the enemy can't follow you or they will suffer defeat.

Engine tuners wouldn't work for this. Even if they shut off weapons completely, the faster side would still be able to follow with their own tuners and occasionally turn them off to open fire. Same for kiting (staying at maximum weapon range and firing), really, though they might prevent kiting if they had a delay between turning off and on again.

Something else to bear in mind is that faster ships are harder to hit. If the penalty for using some form of 'tuner' was relatively minor, it would be used whenever a ship came under attack, which means all weapons become relatively weaker, which means shields become relatively stronger vs armour. I have to be careful here that an apparently minor change doesn't have far-ranging effects. To avoid the above, there would have to be significant penalties to fire control.

It could also make things more difficult for the AI, depending on the mechanics.

Maybe the other suggestion, to have some form of anti-engine missile warhead, would be a better option.

For missiles I would like two ways to mess with an opponent. A missile with a microwave type warhead and a way to target engines using passive thermal sensors that would have a chance to hit engines directly through armour. A microwave warhead could probably also work with EM sensors on missiles which then would increase the hit chance of such missiles or the chance to effect the enemy ships electrical components.

I also think that active missiles should do something beside homing in such as adding extra to hit chance depending on the time the missile are able to track the target. Something like the tracking time bonus for beam weapons.

This would make it more important with hardened sensor systems and perhaps add an armour component to the engine design. Perhaps also make reduced thermal engines harder to hit or simple the less thermal signature the harder it is to hit with such missiles.

You could also allow engines to have degrading performance from damage so can receive partial destruction as one solution. Engines could also be hit through armour with beam weapons besides chock damage. I'm pretty sure that armour engines will be very difficult with 100% certainty.

I don't really like the idea of microwave missiles. There's already a microwave beam weapon, and I don't think doubling up on the same concept adds anything. An anti-engine missile wouldn't be meant as a general purpose weapon, but instead serve the important purpose of making beam combat less all or nothing as it would provide a way to force the opponent to let you close in.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on January 11, 2020, 10:34:49 AM
Anti-Engine missiles are a reasonable solution, although it seriously hampers beam only runs. Maybe have a special component as well that can fire at max beam range, a tractor beam say, that lowers an enemy speed for an amount of time?
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on January 11, 2020, 10:41:54 AM
An engine hunting missile would also be an effective way to force boarding combat, and could be implemented by letting missiles that have only been equipped with thermal sensors have a weighted chance of striking the engines after getting through the armour.

And if engine tuning becomes a thing I'd favour putting the Engine Power Modifier techline to that effect, with engines that have been boosted but running at the 100% power level being slightly less efficient than engines that have not been boosted, while engines running at their maximum boosted level guzzling down fuel at the noted rate. An engine that's running boosted but not to their maximum boost would also be slightly less efficient than engines that were designed with that level of boosting as their maximum.

Engines that have been limited in their maximum power rating to produce less than 100% would not be able to achieve higher than their engines maximum power level, trading flexibility for great fuel efficiency.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 11, 2020, 10:41:57 AM
I don't really like the idea of microwave missiles. There's already a microwave beam weapon, and I don't think doubling up on the same concept adds anything. An anti-engine missile wouldn't be meant as a general purpose weapon, but instead serve the important purpose of making beam combat less all or nothing as it would provide a way to force the opponent to let you close in.

The trick here is going to be making anti-engine missiles a special situation, rather than one that would used all the time. They need to have some disadvantage as well as the anti-engine advantage.

Rather than 'special' missiles, one option would be that missiles that include a thermal sensor(even if ship-guided) are more likely to damage engines if they score internals, while missiles that include an EM sensor are more likely to damage electronics if they score internals. The larger the EM/Thermal seeker, the more likely the damage is directed at engines/electronics. That has the disadvantage that the warhead will be smaller or the range shorter, so it wouldn't be used in general. Also a very easy fix to the code, as all the components already exist.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on January 11, 2020, 10:46:21 AM
I'm not much of a fan on the concept of engine tuners, or whatever.

Honestly speaking, I don't think that the concept of "forcing" an engine to work beyond its maximum speed works well with ultra technology. The most complex and advanced an engine (or anything, really) the smaller are the possible defect and problem tolerance.

I think it's quite safe to assume that with ultra technological engines, once you set a "maximum" engine speed, that's it. Operating beyond it would very quickly prove catastrophic.

I would only be open to something like this IF we go the reactor way: engine stressed beyond its normal limits -> any hit and it goes BOOM. Or maybe, x chance every y seconds of it breaking down entirely. No other compromise is even remotely realistic in my opinion.


As for anti-engine missiles... how about no? Must we have YET another thing that make missiles better than beam weapons? Yes, yes, missiles have to be produced and can be intercepted. But that aside, they're incredibly powerful already.  Put in a anti-engine missile, and beam warships are now immediately completely useless. You just need ONE missile to hit, and your beam dreadnaught is dead in space.
Load your fighters with 10 boxed launcher anti engine missiles, shoot, go away because the enemy beam warships cannot do anything now.


EDIT: as Steve has posted. I would not be against his idea. If you need to put  a decent sensor on missiles, and IF it's only a chance increase, then it's acceptable I suppose.

I would then suggest that thermal reduction would reduce the chance of the missile actually hitting the engine
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on January 11, 2020, 10:53:16 AM
I think that's an appropriate change, one that makes missiles more interesting to design, helps alleviate the major balance issue with beam weapons (though no completely, but that's okay) and is not too difficult to implement.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 11, 2020, 10:56:25 AM
Engine boosting would only serve the intended purpose if its something you would really really prefer to never have to do it.  I think risking an explosion (and possibly really high maintenance part usage while doing it) would be one way to achieve that.

As was mentioned maybe overloading the engines would cause 'inertial dampener' failures that cause potentially catastrophic crew casualties, which is a really good concept in my opinion.  You could explain that as the overloaded engines occasionally causing a surge that the dampeners weren't able to predict which then slams the crew around and potentially kills some (or all) of them.

If the booster is something that smoothly works all the time then its not going to help the lower tech people, because the higher tech people would have absolutely no reason to not do it themselves.  Some kind of modular system that is very pricey but otherwise pretty low tech to build to enhance the ships ability to engine boost (such as a tuner) might also be an option, insofar as it could be something that costs as much or more than the engines its boosting, can be retrofitted onto existing ships (so you could make the choice to switch over to this), and then gives you an advantage over higher tech ships that chose to not install such an expensive piece of hardware.

Also, anti-engine missiles would probably just intensify the punching-down effect in my opinion, because it seems to me it would be really hard to explain why the higher tech side wouldnt just use it as well (from outside of range of the lower tech side because they have better tech) and then leave them both dead in space and out of weapon range, to be picked off at the leisure of the higher tech side.

e: Maybe an anti-engine beam weapon of some sort that isnt too heavy?  At which point the low-tech side could build some ship that has the highest engine power modifier they could build, and then install the anti engine beam or whatnot onto a ship that is 90% engine.  Perhaps the weapons could viably be built at fighter size, meaning you have a way to mitigate the excessive fuel consumption.  Assuming this was some kind of thing where you would basically be able to very quickly and reliably blow out the enemies engines (and then presumably die) it might be an option to force the enemy to hold still long enough for you to engage.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 11, 2020, 11:03:11 AM
I don't really like the idea of microwave missiles. There's already a microwave beam weapon, and I don't think doubling up on the same concept adds anything. An anti-engine missile wouldn't be meant as a general purpose weapon, but instead serve the important purpose of making beam combat less all or nothing as it would provide a way to force the opponent to let you close in.

The trick here is going to be making anti-engine missiles a special situation, rather than one that would used all the time. They need to have some disadvantage as well as the anti-engine advantage.

Rather than 'special' missiles, one option would be that missiles that include a thermal sensor(even if ship-guided) are more likely to damage engines if they score internals, while missiles that include an EM sensor are more likely to damage electronics if they score internals. The larger the EM/Thermal seeker, the more likely the damage is directed at engines/electronics. That has the disadvantage that the warhead will be smaller or the range shorter, so it wouldn't be used in general. Also a very easy fix to the code, as all the components already exist.

Unless the anti-engine missile has a way to penetrate defenses, or at least armor, it's unlikely to function as an anti-kiting measure. With missile combat once you've gotten through shields and armor the enemy is already 90% dead. So it would still have a lot of synergy with boarding, but realistically if you could use that sort of weapon to stop a ship, you could already kill it with normal missiles.

I think the best disadvantage would be for the missiles to do greatly reduced damage. Perhaps 25% or less of a normal missile, and possibly not cause engine explosions. Alternately they could not even destroy engines but instead just temporarily disable them, but I'm not sure how hard that would be to code. That would make them special ordinance because they wouldn't be able to destroy an enemy, or even permanently disable them, as eventually the target would be able to repair its engines.

As for anti-engine missiles... how about no? Must we have YET another thing that make missiles better than beam weapons? Yes, yes, missiles have to be produced and can be intercepted. But that aside, they're incredibly powerful already.  Put in a anti-engine missile, and beam warships are now immediately completely useless. You just need ONE missile to hit, and your beam dreadnaught is dead in space.
Load your fighters with 10 boxed launcher anti engine missiles, shoot, go away because the enemy beam warships cannot do anything now.

The purpose of anti-engine missiles is to make beam warships much more effective, not less. In the current game, a dozen of your beam dreadnoughts would be massacred by a single beam destroyer that was faster with a longer range, which makes them very unfeasible to use. Add a bunch of very short range, very hard to shoot down anti-engine missiles with a range of 2-3m km, and now suddenly those dreadnoughts can force an enemy into their range.

Also, anti-engine missiles would probably just intensify the punching-down effect in my opinion, because it seems to me it would be really hard to explain why the higher tech side wouldnt just use it as well (from outside of range of the lower tech side because they have better tech) and then leave them both dead in space and out of weapon range, to be picked off at the leisure of the higher tech side.

That's the thing, though, anti-engine missiles would counter kiting even if both sides have them (the same is not true of engine tuners). If you're trying to hold the range open, and one of your ships loses half its engines, you have to choose between letting the enemy close or sacrificing that ship. If you're trying to approach the enemy and one of your ships loses half its engines, you can just let the slower ship fall out of formation.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 11, 2020, 11:06:14 AM
Since the beam dreadnoughts are given to be larger and slower to begin with, they would be both more vulnerable to anti engine missiles (better hit chance against the slower target) and lower in numbers, meaning presumably they would require less anti engine missiles to disable.  I still think it would fundamentally favor the faster people regardless.

e:  Ideally you would build your dreadnoughts with the same general engine percentage as your other ships, so given equal tech the smaller ships wouldn't really be faster anyhow.

Also, anti-engine missiles would probably just intensify the punching-down effect in my opinion, because it seems to me it would be really hard to explain why the higher tech side wouldnt just use it as well (from outside of range of the lower tech side because they have better tech) and then leave them both dead in space and out of weapon range, to be picked off at the leisure of the higher tech side.

That's the thing, though, anti-engine missiles would counter kiting even if both sides have them (the same is not true of engine tuners). If you're trying to hold the range open, and one of your ships loses half its engines, you have to choose between letting the enemy close or sacrificing that ship. If you're trying to approach the enemy and one of your ships loses half its engines, you can just let the slower ship fall out of formation.

Right, and I'm saying the higher tech side with superior missile technology would be able to fight a kiting missile engagement, cripple the lower tech sides engines, and then close in to massacre them from beam range.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 11, 2020, 11:08:37 AM
That would not really be the same thing. The whole point were a way to retreat for both sides as neither can use weapons during the boosted engine usage, thus you could retreat to a safe zone where you can defend and the enemy can't follow you or they will suffer defeat.

This is why I raised this very problem in my first proposal to this and said that weapon fire controls would not work for a minute or so after the boost is turned off, much like when you do a combat jump through a jump point. You also could be sitting completely still in space for that time before you can start moving again and be rather vulnerable.

For retreating this would be a way to move where you have reserves or some reinforcement arriving.

This would also make it more reliable to split up your forces as it would be easier for a weaker part to retreat towards a stronger part, even for beam combat purposes.

I really think it would make the tactical game more interesting and less decisive as it would give both sides a possibility to disengage if they have roughly equal tech and speeds, that at least is true in a multi-faction campaign. If you have two rather different opponents with tech levels there might not be much difference but that is the same now as well.

It would make combat less decisive and thus patrolling in smaller numbers could be done with a bit less risk. As it is easier to defend against missiles than beam in general it would give you more tactical options. Patrol ships would be armed mainly with anti-missile systems and decent speed with booster to avoid fast beam fighters for examples. As you want decently fuel efficient patrol ships you can't really give the really high powered engines, that makes for a very bad patrol or reconnaissance ship. I could also see other uses for incorporating it into doctrines as a whole.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on January 11, 2020, 11:14:13 AM
The purpose of anti-engine missiles is to make beam warships much more effective, not less. In the current game, a dozen of your beam dreadnoughts would be massacred by a single beam destroyer that was faster with a longer range, which makes them very unfeasible to use. Add a bunch of very short range, very hard to shoot down anti-engine missiles with a range of 2-3m km, and now suddenly those dreadnoughts can force an enemy into their range.

While that is a possible use, the opposite is also true. If you have technological equivalent fleets, a beam weapon fleet is very often the one that is built to be faster. This is by design, after all you need to get in range to shoot.

And so, say you have two fleets. A missile fleet, and a beam fleet. Supposing the missile fleet can surpass the beam fleet point defense (because if not, of course the point is moot), an anti-engine missile like you propose would mean that the missile fleet can escape 100% of the times. Just load a wave of anti engine missiles, disable the enemy ships' engines, leave the system, or get under OWP protection or whatever.
It's a get out of jail free card, unless you make the disablement time super short, like 30 seconds or so.

Mind you, I would be much less against this if beam weapons were not capped at 1.5 million km range... but as it is, if you take speed away from beam warships, they're literally just expensive junk.
 
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 11, 2020, 11:16:00 AM
That would not really be the same thing. The whole point were a way to retreat for both sides as neither can use weapons during the boosted engine usage, thus you could retreat to a safe zone where you can defend and the enemy can't follow you or they will suffer defeat.

This is why I raised this very problem in my first proposal to this and said that weapon fire controls would not work for a minute or so after the boost is turned off, much like when you do a combat jump through a jump point. You also could be sitting completely still in space for that time before you can start moving again and be rather vulnerable.

For retreating this would be a way to move where you have reserves or some reinforcement arriving.

This would also make it more reliable to split up your forces as it would be easier for a weaker part to retreat towards a stronger part, even for beam combat purposes.

I really think it would make the tactical game more interesting and less decisive as it would give both sides a possibility to disengage if they have roughly equal tech and speeds, that at least is true in a multi-faction campaign. If you have two rather different opponents with tech levels there might not be much difference but that is the same now as well.

Regarding the other school of thought here (let the low tech people run away, rather than let the low tech people close the range) maybe that would be easier to implement.  As has been pointed out you could say the boosting ships are just incapable of fighting while engine boosting.  Given that there could be all sorts of interesting side effects associated with engine boosting, I think it would be easier to go for that approach and to justify the fact that the ship cannot do anything to fight while its boosting.

e: The more I think about it, the more I like the idea of less decisive engagements as you have put it in general.  If you can prevent your entire military from being totally crippled after losing one battle, then that does tend to lead to much longer and more complicated wars.  Maybe this is the way to do that.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 11, 2020, 11:19:44 AM
Given that the beam dreadnoughts are given to be larger and slower to begin with, they would be both more vulnerable to anti engine missiles and lower in numbers, meaning presumably they would require less anti engine missiles to disable.  I still think it would fundamentally favor the faster people regardless.

e:  Ideally you would build your dreadnoughts with the same engine percentage as the enemy, so given equal tech the smaller ships wouldn't really be faster anyhow.

The dreadnoughts would also have more total engine tonnage and thus be less vulnerable to the missiles, and have more damage control rating so they could get the engines up quicker while the enemy was still disabled. Or as noted, if you have multiple ships you can leave the one with engine damage behind.

And yeah, you could design your dreadnought to be faster, but the point is that in the current system for beams faster ship = invulnerable, and I like the idea of a system that is fuzzier than that - where even if you're slower you can get some punches in, even if you're at a disadvantage.

This is why I raised this very problem in my first proposal to this and said that weapon fire controls would not work for a minute or so after the boost is turned off, much like when you do a combat jump through a jump point. You also could be sitting completely still in space for that time before you can start moving again and be rather vulnerable.

This seems like it would make it completely impossible to ever engage a ship with beam weapons if they didn't want to, since you couldn't catch them, for what it's worth. Basically the current situation but making it so that a faster beam ship couldn't even force a missile ship into range once it was out of missiles, since the missile ship could just turn on its tuners if the beam ship was almost in range, and the beam ship wouldn't be able to engage even if it did use its tuners.

While that is a possible use, the opposite is also true. If you have technological equivalent fleets, a beam weapon fleet is very often the one that is built to be faster. This is by design, after all you need to get in range to shoot.

And so, say you have two fleets. A missile fleet, and a beam fleet. Supposing the missile fleet can surpass the beam fleet point defense (because if not, of course the point is moot), an anti-engine missile like you propose would mean that the missile fleet can escape 100% of the times. Just load a wave of anti engine missiles, disable the enemy ships' engines, leave the system.
It's a get out of jail free card.

Mind you, I would be much less against this if beam weapons were not capped at 1.5 million km range... but as it is, if you take speed away from beam warships, they're literally just expensive junk.

It would work completely the opposite in practice. If they launch a wave of anti-engine missiles and take out the engines on one or two ships, you can leave them behind, and still have 100% beam superiority over pure missile ships. Even if they have such massive crushing superiority that they can disable every engine in your fleet, then A) they could probably just blow up your fleet with missiles before you close the range, and B) you'd be able to repair the engines, probably within less than an hour, and resume the pursuit.

Anti-engine missiles are not symmetrical in nature (one of the primary reasons I like them over tuners). Because of repairs and a fleet being able to leave damaged ships behind, they are far more effective at preventing a fleet from escaping than they are at preventing a fleet from pursuing.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 11, 2020, 11:24:42 AM
I don't really like the idea of microwave missiles. There's already a microwave beam weapon, and I don't think doubling up on the same concept adds anything. An anti-engine missile wouldn't be meant as a general purpose weapon, but instead serve the important purpose of making beam combat less all or nothing as it would provide a way to force the opponent to let you close in.

The trick here is going to be making anti-engine missiles a special situation, rather than one that would used all the time. They need to have some disadvantage as well as the anti-engine advantage.

Rather than 'special' missiles, one option would be that missiles that include a thermal sensor(even if ship-guided) are more likely to damage engines if they score internals, while missiles that include an EM sensor are more likely to damage electronics if they score internals. The larger the EM/Thermal seeker, the more likely the damage is directed at engines/electronics. That has the disadvantage that the warhead will be smaller or the range shorter, so it wouldn't be used in general. Also a very easy fix to the code, as all the components already exist.

This sounds interesting, especially if it applies to shock damage as well as normal penetration damage.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 11, 2020, 11:31:04 AM
This seems like it would make it completely impossible to ever engage a ship with beam weapons if they didn't want to, since you couldn't catch them, for what it's worth. Basically the current situation but making it so that a faster beam ship couldn't even force a missile ship into range once it was out of missiles, since the missile ship could just turn on its tuners if the beam ship was almost in range, and the beam ship wouldn't be able to engage even if it did use its tuners.

No... I don't think so... you could use your own boosters to charge against the jump point you think that enemy ships is headed for an sit on it, effectively force the enemy to come to you.

It would open up to a few more interesting situations with multiple manoeuvring forces in beam combat.

It would make two side able to disengage from an otherwise balance engagement with some losses on both sides. Combat in Aurora right now are very decisive, now you could allow for a bit more slow attrition instead. You might dare engage a bit more often in beam combat as you know that it is possible to disengage if it goes sideways.

In most of my multi-faction games beam combat are so dangerous that sides only engage in them if they are very certain to win and it become very one sided. They almost never engage if numbers are even close to similar as they tend to be very one sided eventually with one side being totally wiped out and you never want to be that side.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 11, 2020, 11:48:37 AM
In most of my multi-faction games beam combat are so dangerous that sides only engage in them if they are very certain to win and it become very one sided. They almost never engage if numbers are even close to similar as they tend to be very one sided eventually with one side being totally wiped out and you never want to be that side.

I'm sympathetic, but it seems to me this would swing things too far the other way. Missiles are already highly dominant, and if you change things so that beam combat is almost never decisive, it seems to me that the obvious emergent gameplay would be to never build anything but pure missile ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 11, 2020, 11:58:18 AM
The disengagement boosters would also help escape from missile fights.  Its possible to fight at a distance where either side can choose to run away and then the incoming damage is potentially very significantly degraded.  The best way to disengage presently is to turn around and run away such that the missiles run out of range before they can reach you.  Thats also a big part of why missile engagements are less decisive.  Boosters would probably mainly enhance that aspect.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 11, 2020, 12:08:49 PM
The disengagement boosters would also help escape from missile fights.  Its possible to fight at a distance where either side can choose to run away and then the incoming damage is potentially very significantly degraded.  The best way to disengage presently is to turn around and run away such that the missiles run out of range before they can reach you.  Thats also a big part of why missile engagements are less decisive.  Boosters would probably mainly enhance that aspect.

True, they'd have some effect on missiles (though if it locked your weapons off for a minute after disengaging, the threat of being hit by missiles when your anti-missile defenses couldn't fire would be a major one), but much less of an effect than they'd have on beams. It's a non-symmetrical change that favors missiles, and that's still a relative boost to missile ships.

You'd also have to keep the tuners running much longer during a missile engagement, greatly increasing the chance of burning out your engines.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 11, 2020, 12:32:34 PM
The disengagement boosters would also help escape from missile fights.  Its possible to fight at a distance where either side can choose to run away and then the incoming damage is potentially very significantly degraded.  The best way to disengage presently is to turn around and run away such that the missiles run out of range before they can reach you.  Thats also a big part of why missile engagements are less decisive.  Boosters would probably mainly enhance that aspect.

True, they'd have some effect on missiles (though if it locked your weapons off for a minute after disengaging, the threat of being hit by missiles when your anti-missile defenses couldn't fire would be a major one), but much less of an effect than they'd have on beams. It's a non-symmetrical change that favors missiles, and that's still a relative boost to missile ships.

You'd also have to keep the tuners running much longer during a missile engagement, greatly increasing the chance of burning out your engines.

I don't think there would be much difference in the impact on missile versus beam combat defence... it would make both missiles and beams less decisive in general... since missiles are very expensive it could actually impact missile warfare even worse over the long term.

To be honest it probably would at best make combat less decisive on a tactical perspective but certainly not on a strategic scale as you still need to defend some places that can't move anyway.

To be honest I don't think it would upset balance as much as just change some of the game play but probably less than what we believe to be honest. It would generally effect two forces at relative parity but make less impact if there is a bigger disparity in technology.

I think that a change into cloaking or submarine like warfare that Steve said he might explore would perhaps have a bigger impact as an example.

I just would like a bit more tactical variety when technology are relatively even.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on January 11, 2020, 01:09:44 PM
I'm against disengagement in general. At least this type of disengagement, a sudden "speed boost" that lets you escape. I'm all in favor of playing with sensors and such

Disengagement by speed or climate interference was a thing in battles in the past. The more high tech a conflict, in space, the less disengagement makes sense. You say it offers more tactical options. I say that it makes decisions less important. Because well, you can always "flee" albeit at a cost.

I would suggest not thinking of WW2 fights. Nowadays, with radars, satellites and the like, Similar "tech" nations would no really be able to retreat once committed, not in air nor in naval warfare.

I feel that this would be a meta-change to try to tailor the game in order to make wars last longer, while they should not.


I remember reading one of those declarations by the pentagon, I think it was, that nowadays a non-nuclear war between powerful nations (say China-Russia) would be over in a matter of hours, because in that period of time one of the two would lose the capabilities to strike the other, and be reduced to trying to defend with ground troops.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 11, 2020, 02:13:25 PM
I think basing gameplay mechanics on "realism", much less a hypothetical realism for a form of war that doesn't exist, is a bad idea. That said, while I can sympathize with wanting combat in Aurora to be more skirmish-y (which would help with the problem of wanting to keep your entire fleet together in one ball of death) I can't think of a way to do it without making beam armed ships even worse off.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on January 11, 2020, 03:17:30 PM
The issue that needs to be resolved is not a lack of a retreat option, but the all or nothing going nature of most beam fights. Steve even said it in the latest update to Crusade, his entire fleet could have been lost to a single ship and there was nothing he could have done about it, which isn't really interesting or fun. Any mechanic or change that resolved this issue is good, in my books.
Title: Re: C# Aurora v0.x Suggestions
Post by: zatomic on January 11, 2020, 03:39:24 PM
Another approach I've had rattling around in my head related the discussion around engine boosting is to allow multiple engine types on the same ship.

My thought would be to allow each ship to have 2 types of engine. The ship would then have a cruising speed based on the more efficient engines only and a max speed based on all engines. The fleet UI would just have an option to set the fleet to cruising speed (which would be the slowest cruising speed of any ship in the fleet) or max speed (which would be the slowest max speed of any ship).

This would give a boost to beam ships as they currently struggle with being fast enough for combat but being fuel guzzlers when moving strategically. The built in downside to running at max speed (or any speed above cruising) besides less efficient fuel use would be the already higher explosion chance of boosted engines.

As an option, maybe engines only have a chance to explode if they are in use so a ship at or below cruising speed taking damage to one of it's higher boost engines might lose the engine, but not have an explosion chance.

I think this works with all existing modules and techs and just a UI adjustment to quickly set either cruising or max speed for a fleet.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on January 11, 2020, 04:09:19 PM
The issue that needs to be resolved is not a lack of a retreat option, but the all or nothing going nature of most beam fights. Steve even said it in the latest update to Crusade, his entire fleet could have been lost to a single ship and there was nothing he could have done about it, which isn't really interesting or fun. Any mechanic or change that resolved this issue is good, in my books.

But is that really an issue? I contest that. If your ships are slower and you have shorter range than your enemy, you deserve to lose. Do something else. Build fighters, beam or otherwise. Switch to missiles until you upgrade your engines OR your weapon range.

Steve NOTED it. I have always been under the impression that he does not really mind. Technological inferiority is a bitch like that. You lose. And STeve HAD prepared, because he also brough fighters with box launchers, and so he won.

I see absolutely no reason to put in "handholding" mechanics to cater to the needs of inferior civilizations. Althought I am an extreme fan of beam weapons, I see no reason for the game to try and help me if I did not research enough and have not prepared a single contingency plan in case my enemies are faster and outrange me.

I don't see why you consider all or nothing fights an issue. If you don't want to commit to an all-or-nothing fight, don't commit to it. You have other options. Build more ships. Build different ships, aimed at your specific enemy. Guard the wormholes. Switch tactics. In a multi faction start, move to another planet so you are not on the very same planet as your enemies.

I don't want to sound like an asshole. It seems to me you simply want a "skirmish" war. But... nothing stops you from doing that. Divide your ships. Attack from multiple directions. Don't commit to fights, harass the enemy lines. Main battles are bloody because well, they generally are. Send 2-3 ships in multiple directions and hit different targets. You will lose some, but that's ok.
And if your enemy is so superior that none of that works, well yes you have lost a game. It happens
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on January 11, 2020, 04:18:52 PM
The issue is less on the side of things being too hard, but things being too easy. Players will, very consistently, be faster then the enemy because they understand that speed is, in the context of a beam fight, the most important mechanic. Players also tend to be farther ahead down the tech line. This makes wars trivial because you literally need one offensive ship and point defense and you're good. Literally one gun is a it takes. Having a speed and range advantage should be a big deal but it shouldn't be the only relevant variables, it makes both ship design and fighting boring.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on January 11, 2020, 04:24:03 PM
The fundamental problem we're trying to solve here - the original sin, as it were - appears to be that kiting is too powerful; any ship that has a large enough range advantage to kill the enemy before running out of maintenance supplies, and any speed advantage whatever, will always win the engagement not merely decisively but without even taking effective return fire.

One possible way to resolve this is to let vessels mount a tractor beam that outranges all possible fire controls (say, out to a maximum range of 5 million km), but does not do any damage - rather it adds mass to the target ship for the purposes of speed calculations during the next increment. Such a weapon would kill kiting, but no otherwise disrupt the beam/missile meta, the fuel economy, the damage economy, or the relative power of shields vs. armor.

It would make jump point blockades harder to penetrate - no more jumping through and flooring the gas pedal blindly away from the jump point in some random direction. But I'm not sure that's necessarily a bad thing.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on January 11, 2020, 04:27:38 PM
The issue is less on the side of things being too hard, but things being too easy. Players will, very consistently, be faster then the enemy because they understand that speed is, in the context of a beam fight, the most important mechanic. Players also tend to be farther ahead down the tech line. This makes wars trivial because you literally need one offensive ship and point defense and you're good. Literally one gun is a it takes. Having a speed and range advantage should be a big deal but it shouldn't be the only relevant variables, it makes both ship design and fighting boring.

I'm sorry but... do you really believe the AI would be able to micromanage something like a "speed bosting" or "tuning" better than the player? No it would not. In fact, it would probably make things worse, as the player is capable of micromanaging better. And so, the situation would be even more unbalanced.

The player, if ahead in technology, would add onto his superior ship speed by micromanaging better, resulting in the AI being even more disadvantaged. Every time you put in something that can be micromanaged, consider that you're favoring the player.

At any rate, we're really clogging the Suggestions thread. If there are people that want to discuss this further, it's probably better to split off to another thread by now in my opinion
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 11, 2020, 04:43:50 PM
I question that it would be pure advantage to the player to provide the 'booster' option.  If the AI has a reasonably solid ability to decide when to run away in the first place, then it will have no problems using the boosters to run away faster.  In general the assertion that AI cant micromanage is not necessarily accurate, it has vastly superior information handling and can 'micro' certain things way better than a human ever could, its in matters of abstract decision making where it suffers.

Its also worth noting the boosters have more to do with beam combat in general, be it with the AI, with another human, or with yourself if you are running a campaign.
Title: Re: C# Aurora v0.x Suggestions
Post by: Darkminion on January 11, 2020, 05:15:03 PM
Would it be possible to add the ability to set alarms to trigger on a specified date? Kinda like the "Send Message" fleet order but for time rather than space. I'm sure one could just make a note somewhere but that would require remembering to check it, having a reminder pop up in the event log would be nice.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 11, 2020, 06:57:59 PM
I don't know about engine boosters, or tuners, or de-tuners, or anti-engine missiles.  The problem I want to solve is my survey cruiser trundles into a nice new system, starts looking around at the planets, and suddenly sees thirty-odd presumably-hostile ships racing towards it.  At this point, I want a "Run Away!" button.

I want to jump to light speed, disengage via warp, hide behind a planet or among some asteroids.  I want to steam into a nearby rain squall, or pour on canvas until disappearing over the horizon, or lose them in the surface clutter.  I want to roll my ships ninety degrees to interpose their wedges, and start building delta-V in a perpendicular direction.

I want to run away with some reasonable chance of success.  I *DON'T* want to feed survey cruiser after survey cruiser into the meat grinder until I "roleplay" realizing something is wrong; then use some sort of custom-built, super-tough 'heavily-defended-jump-point probe ship'.

Mostly, I want to turn situations where I know hours in advance that my ship / squadron / flotilla is going to die and there is nothing I can do about it into a situation where there *IS* something I can do about it.

Because -- honestly -- if eighty percent of my battlefleet runs into a single destroyer that is faster and armed with a longer-ranged beam weapon, far from a jump point, I'm going to use SpaceMaster functions to save my game rather than watch Aurora obliterate hours of investment.

= = = = =

I'm not interested in solving the 'problem' of how does a beam fleet get within its own range of a missile fleet.  Aurora currently has an answer for that and it is 'point defense, shields, and armour to weather the missile storm'.

If Aurora gets some form of short-term speed boost, it needs to disable all weapons' fire (except maybe CIWS) while in use, and for several HOURS afterwards.  It shouldn't be possible to 'sprint' into range and then fight. 

I agree that the goal should be to make combats less of an all-or-nothing affair.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 11, 2020, 08:03:17 PM
I'm against disengagement in general. At least this type of disengagement, a sudden "speed boost" that lets you escape. I'm all in favor of playing with sensors and such.

I am FOR disengagement in general; especially this type of disengagement.

Disengagement by speed or climate interference was a thing in battles in the past. The more high tech a conflict, in space, the less disengagement makes sense.

And I want to simulate (perhaps 'echo' is the better term) battles of the past.  I'm not interested in Aurora's "realism" because Trans-Newtonian Elements aren't real.  I see literally no reason why "The more high tech a conflict, in space, the less disengagement makes sense."

The Honor Harrington universe does not exist because David Weber thinks that is our most realistic future, but rather because he wanted to write Hornblower or Aubry-Maturin books and the actual, historical Age of Sail battles had already been thoroughly mined for fiction.  So he invented a whole raft of future tech that 'just happened' to turn space battles into analogs of Age of Sail actions.  Ships with broadsides and bow & stern chasers and essentially 2-D combat.  Ships that could 'turn and run for it' over the horizon/hyper limit.

You say it offers more tactical options. I say that it makes decisions less important. Because well, you can always "flee" albeit at a cost.

SpaceMaster allows us to magically refit entire ship classes after deployment, because we forgot to add fire control systems during design.  You may say that was an important decision and we should live with the cost of our mistakes, but I say no sane ship architect would overlook such a detail.

Likewise, my ship's crew would not overlook details about range to enemies, range to jump points, weapons reach, travel times at various speeds, etc.  They would know exactly how far my survey cruiser could go from the jump point and still be able to spot an approaching Necron in time to flee safely.  I say, that's the sort of micro-management Aurora should be shielding us from. . .  with a "Run Away!" button.

I would suggest not thinking of WW2 fights. Nowadays, with radars, satellites and the like, Similar "tech" nations would no really be able to retreat once committed, not in air nor in naval warfare.

I *WOULD* suggest thinking of WWII fights.  And Great War fights.  And Balkan War fights.  And Russo-Japanese fights.  And South American fights.  And Steam & Steel fights.  And U.S. Civil War fights.  And Age of Sail fights.  And Imjin War fights.  And Viking raids.  And Roman-Carthaginian fights.  And Greek-Persian fights.

And Star Wars fights.  And Star Trek fights.  And Firefly/Serenity fights.  And Black Fleet fights.  And The Last Starfighter fights.  And Battle Beyond the Stars fights.  And The Expanse fights.  And Royal Cinnabar Navy fights.  And even Blake's 7 fights.

In short, anything and everything that is *NOT* modern (or cold war) wet-navy (and air) battle, where sensors reign supreme and a first-strike missile swarm wipes out your enemy.  I am not interested in seeing Aurora turn into "Harpoon, the PC version".  Such a thing already exists.

I feel that this would be a meta-change to try to tailor the game in order to make wars last longer, while they should not.

Why shouldn't they?  Why should Aurora space combat be so decisive?  How is that more fun than multiple small skirmishes?  If my patrol destroyers are guaranteed to die (uselessly) when an enemy missile cruiser shows up, is it still fun to build and deploy them?

This is like Mass Drivers all over again.  "It's fun to have lots of ships flying around doing commerce, so let's introduce a ground facility to remove the need for that."  I've stopped complaining about mass drivers because I (personally) don't have to use them.

I remember reading one of those declarations by the pentagon, I think it was, that nowadays a non-nuclear war between powerful nations (say China-Russia) would be over in a matter of hours, because in that period of time one of the two would lose the capabilities to strike the other, and be reduced to trying to defend with ground troops.

[sarcasm]  I can imagine how excited the Axis & Allies folks are to make that board game.  "Flip a coin to see who will eventually win, then spend four hours playing it out!"  [/sarcasm]

'Realism' is no replacement for fun, just as truth is no defense for verisimilitude.  If you are suggesting the "One True Way" to play Aurora is 'speed at all costs' because in space, everyone can see you hide and that's 'realistic', then I disagree.  Aurora is NOT "the most realistic space sim ever," it's "a fun game of space combat, exploration, and empire management."

Watching my fleet die because the only way to avoid that is to probe everywhere with missiles and fighters or to mount monster sensors that can light up an entire star system is NOT FUN for me.  Don't force me to play Aurora your way.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 12, 2020, 06:17:32 AM
The issue is less on the side of things being too hard, but things being too easy. Players will, very consistently, be faster then the enemy because they understand that speed is, in the context of a beam fight, the most important mechanic. Players also tend to be farther ahead down the tech line. This makes wars trivial because you literally need one offensive ship and point defense and you're good. Literally one gun is a it takes. Having a speed and range advantage should be a big deal but it shouldn't be the only relevant variables, it makes both ship design and fighting boring.

That is true in VB6. It isn't really true for C#. The AI is a lot better at research and will design improved ships and ground forces as the game progresses (the NPRs have already done that in my current campaign). The AI is also better at creating mixed forces than VB6, so you will encounter fleets with better balanced weapons.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 12, 2020, 08:35:22 AM
I would generally agree with Father Tim on this one. The boosted engine would not solve the beam core issue but would make it possible to in some instances flee from a bad fight.

I don't mind if a high technology fleet could easily defeat an inferior fleet in beam combat... but the thing is that even only slightly better fleet can become nearly invincible in beam combat. I still think that game mechanics should allow numbers of low quality to count for something as they do in missile combat.

Let's say that ships that stand still have full range of fire controls while ships that move get a 0.5 modifier if moving at full speed. That would still make range important but would still make older ship dangerous if enough in numbers.
Title: Re: C# Aurora v0.x Suggestions
Post by: Titanian on January 12, 2020, 09:32:12 AM
Let's say that ships that stand still have full range of fire controls while ships that move get a 0.5 modifier if moving at full speed. That would still make range important but would still make older ship dangerous if enough in numbers.

That won't work, the faster, longer ranged ship would boost out of the others range, come to a stop and fire, boost on, repeat. Only if there was some cooldown to this effect, the range advantage you need to have would increase. But then the side with lower range would see the other stop, and could just turn away and avoid the attack, turning the battle into a micromanagement dance.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 12, 2020, 09:56:35 AM
Let's say that ships that stand still have full range of fire controls while ships that move get a 0.5 modifier if moving at full speed. That would still make range important but would still make older ship dangerous if enough in numbers.

That won't work, the faster, longer ranged ship would boost out of the others range, come to a stop and fire, boost on, repeat. Only if there was some cool down to this effect, the range advantage you need to have would increase. But then the side with lower range would see the other stop, and could just turn away and avoid the attack, turning the battle into a micromanagement dance.

How many times do one have to repeat that it HAS to be together with a block timer of fire-control once you end the boost of at least a few minutes like a combat jump... perhaps even more. Then it would work just fine. I hope that this is clear by now...  ;) ...there need to be a timer on the change from moving to standing still as well... perhaps the same penalty.

Using boost in this way would not work at all... dancing in and out would not work that well either as the one who stand still would get too many opportunities to fire without return fire most of the time. If you have the advantage you would just run into a good firing position and try to hold that distance. But then at least both side would be able to fire and the weaker side could still defend themselves and do damage and if numerous enough could potentially overwhelm a technological superior opponent that then would have to retreat.

There would still be a benefit to the technologically superior or faster fleet as they have more tactical options available.

The result is simply that moving cost you accuracy... a slower fleet can run away but the faster fleet will have to run the gauntlet into a good firing position and the slower fleet could defend itself. A fleet with lower range could still fight the enemy or try to run away, if the enemy follows they are both out of range... so the fleet with lower range can still win the fight if it has stronger beam offensive power but lower range and slower engines, but the other side could always retreat when needed.

It would be a more fair system for everyone involved. A fleet would only be invincible ones their range are close to double that of the other fleet which is a gap I certainly could live with.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 12, 2020, 12:05:47 PM
I don't understand, do you mean if boosting then you can still shoot but at a halved range?
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 12, 2020, 12:32:55 PM
I don't understand, do you mean if boosting then you can still shoot but at a halved range?

No... that was a completely different suggestion to fix a completely different issue of unbalance in beam combat.

The problem with beam combat that missile combat does not have is that you can overwhelm of defend against a superior missile fleet with numbers against quality... in beam combat this is almost impossible and the superiority you need in speed and/or range are very minor for a very huge benefit. This is what makes beam only fleets a very risky move, as soon as you come across someone with just a slight advantage you are basically done, that don't happen with missile combat in the same way.

Being able to sun away would not fix why it is mostly inferior with using beam only combat fleets. Beam fleets demands parity on speed and fire-control range, missile fleets can bridge the gap with enough numbers. This is what in my opinion make beam fleets very risky. If you would like to play a multi-faction campaign with only beam combat you would soon find yourself in problematic combat scenarios for these very reasons.

I just tried to give a few example how you could make beam combat only campaigns or fleets in general more feasible.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 12, 2020, 12:51:38 PM
How many times do one have to repeat that it HAS to be together with a block timer of fire-control once you end the boost of at least a few minutes like a combat jump... perhaps even more. Then it would work just fine. I hope that this is clear by now...  ;) ...there need to be a timer on the change from moving to standing still as well... perhaps the same penalty.

Using boost in this way would not work at all... dancing in and out would not work that well either as the one who stand still would get too many opportunities to fire without return fire most of the time. If you have the advantage you would just run into a good firing position and try to hold that distance. But then at least both side would be able to fire and the weaker side could still defend themselves and do damage and if numerous enough could potentially overwhelm a technological superior opponent that then would have to retreat.

There would still be a benefit to the technologically superior or faster fleet as they have more tactical options available.

The result is simply that moving cost you accuracy... a slower fleet can run away but the faster fleet will have to run the gauntlet into a good firing position and the slower fleet could defend itself. A fleet with lower range could still fight the enemy or try to run away, if the enemy follows they are both out of range... so the fleet with lower range can still win the fight if it has stronger beam offensive power but lower range and slower engines, but the other side could always retreat when needed.

It would be a more fair system for everyone involved. A fleet would only be invincible ones their range are close to double that of the other fleet which is a gap I certainly could live with.

If boosting ships had half the range, the faster/longer range ships could still slaughter the slower/shorter ranged ships unopposed. Let's look at the scenario in detail:

Side A has a tech advantage - their ships are slightly faster and their fire controls have a slightly better range. Side B is one tech tier lower, but we'll say they have twice as many ships - any exchange of fire will still favor them.

Side A approaches, but sits outside Side B's range and starts firing. Side B has two choices - tune their engines or don't tune. If they don't tune, they'll eventually be destroyed, so they really have one choice. They turn on their engine tuners and either approach or flee - it doesn't matter.

Side A turns on their tuners as well and now starts maintaining half the range they previously were - they can still fire and Side B still can't. Side B turns off their engine tuners and starts waiting for whatever period for their fire controls to recover - Side A flies back out of Side B's range and then turns off their engine tuners. When they recover they can resume firing but Side B can't.

No matter what Side B does in this scenario, the same problem continues - they can't fire back, and they can't escape.

In the scenario where engine tuning disables weapons entirely, then instead we get a situation where Side B still can't ever fire on Side A, but may be able to escape. Which sounds good except I think the net result of it being far more difficult to ever force a beam engagement is to never almost build beam ships, since the current role of beam ships is basically "force your enemy into combat once they're out of missiles".
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 12, 2020, 01:12:46 PM
If boosting ships had half the range, the faster/longer range ships could still slaughter the slower/shorter ranged ships unopposed. Let's look at the scenario in detail:

Side A has a tech advantage - their ships are slightly faster and their fire controls have a slightly better range. Side B is one tech tier lower, but we'll say they have twice as many ships - any exchange of fire will still favor them.

Side A approaches, but sits outside Side B's range and starts firing. Side B has two choices - tune their engines or don't tune. If they don't tune, they'll eventually be destroyed, so they really have one choice. They turn on their engine tuners and either approach or flee - it doesn't matter.

Side A turns on their tuners as well and now starts maintaining half the range they previously were - they can still fire and Side B still can't. Side B turns off their engine tuners and starts waiting for whatever period for their fire controls to recover - Side A flies back out of Side B's range and then turns off their engine tuners. When they recover they can resume firing but Side B can't.

No matter what Side B does in this scenario, the same problem continues - they can't fire back, and they can't escape.

In the scenario where engine tuning disables weapons entirely, then instead we get a situation where Side B still can't ever fire on Side A, but may be able to escape. Which sounds good except I think the net result of it being far more difficult to ever force a beam engagement is to never almost build beam ships, since the current role of beam ships is basically "force your enemy into combat once they're out of missiles".

First of all I never said that boosted ship would get half range... that was a completely different suggestion that MOVING ships would get half range in order to "fix" the issue with the fact that you only need a SLIGHT advantage in beam combat. It would actually make beam combat a viable option as two beam fleets could fight even if one have a slight range and speed advantage. This has nothing to do with missile versus beam combat balance what so ever.

At some point you will have to defend points in space so you can't run forever... right?!?

Stopping would in either case suspend fire-controls in the boosting instance and half the range in the "moving" scenario for a certain period of time to avoid the problem of moving back and forth so that there is combat until someone wants to run away.

Technology will still matter but in beam combat you would now need to have a certain advantage to engage as the defender will always have a slight advantage... I don't see that as a huge problem to be honest. I still see allot of instances where one side is strong enough to engage... if you also have a speed advantage then engaging to probe enemy strength are still relatively safe in beam combat.

It would make beam combat more interesting as they are less one dimensional.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 12, 2020, 02:27:35 PM
To make matters more clear I have actually suggested TWO different things that are completely separated from each other but could both be implemented together as well.

1. Boosted Engines
There would be a technology where you could attach a device or be part of the engines themselves that could boost engines between say 25%-50%. At 25% boost you would burn x2 fuel and at 50% you would burn x4 fuel. The higher the boost the more likely you would receive an engine failure while using the booster effect, the ships maintenance cycle should probably also be effected. There would also be a tech that reduce engine failure.

While the ship is using Boosters it could not use active sensors or fire-controls. Once a ship exit the boost it have to stop and stand still for 120 seconds and neither sensors nor fire-controls would work. This time could be modified with fleet training, crew experience and officers down to maybe 30-45 seconds or so (throw in some RND).

Ships that uses boosted engines at any point for more than really short periods are quite likely to need immediate overhaul after such activities and need be supplied with more MSP, so using it will then put a severe limitation on strategical operations for those ship... offensive or defensive purposes.


2. Modified range for moving in Beam combat
Ships that move have their beam fire-control range halved. A ship (or station) that stands still get to fire with their fire-controls at full range. Although it will take 120 seconds before a ship can utilise the full range of fire-controls after they stop moving. The time needed is then modified with fleet training, crew training and officers down to around 30-45 seconds as minimum (throw in some RND.

You could rationalise it that anything that stand still can easily build a map of the physical and Eather space around them to make their weapons more precise, but this will take some time after the stop.

This would make it slightly more efficient to defend rather than attack so an attacker would need to have a slight advantage to win a beam combat, it also would mean that you need a considerable advantage in technology to become invincible in beam combat and that a technologically inferior fleet could win if they have enough ships in many situations. It would make combat between beam ships behave more like combat between missile ships of different technological standards.


These are two different suggestion that actually would work together pretty well and would serve different purposes. The first is not only for beam combat as it will impact missile combat as well. You would likely not want to use boosted engines when on the offensive as it puts rather hard restrictions on operational range and stamina of your ships. For defensive purposes it is good if you need to just run away into the safety of reinforcement or a military base where you have plenty of missile and beam defences to protect you.

I do understand that some people like when things are very decisive. Personally I like when things are a but more indecisive and you need to have a clear advantage to win and that you might not always know what that is. Being able to probe enemy defences without being directly overwhelmed is more interesting. You will still be able to produce those decisive moments even with these rules in place.


Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 12, 2020, 03:29:36 PM
it also would mean that you need a considerable advantage in technology to become invincible in beam combat and that a technologically inferior fleet could win if they have enough ships in many situations. It would make combat between beam ships behave more like combat between missile ships of different technological standards.

It wouldn't do this for the reasons I already covered, whether it involved engine tuning or not. Just fly to a point that's inside your range but outside theirs and stop; if they fly towards you, they're now getting the reduced range penalty too. It wouldn't change anything about beam combat other than adding extra micromanagement.
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on January 12, 2020, 03:41:03 PM
Bremen beat me to it, these changes don't do anything but add micro. Same goes for boost, if the slower fleet kicks on boost but can't fight, its not helping at all, and if boost becomes key to beam combat, everyone will just bring boost. So if your boost is fast enough to outpace the otherwise superior enemy, they'll just kick on their superior boost and now its back to the same problem, except nobody can fire their guns without chilling dead in the water for a while. I guess its good for running away?

I'm still not entire sure why we're trying to create a complex system to resolve a problem that has already been solved. The beam knife fighting problem of minor advantages being an all or nothing win was already solved with the implementation of missiles, you are supposed to use combined arms. A modern guns only warship would be shredded it it tried to face down a faster opponent with longer range on its guns, and the solution was cruise missiles. Beams are supposed to be secondary batteries, and the risk to using them instead of your missile armament is being at that disadvantage to your enemy.

The only thing I can think of that doesn't involve ridiculous amounts of micromanagement, while also stopping the worst of beam kiting, is have it based on direction. if you opponent is within a given angle from your rear (based on your movement that turn) then you suffer a range malus for firing into your engine wake or something technical like that. Superior opponents will retain their speed advantage, but can't fire as far directly backwards. This means you can't just fly directly away from the enemy and use the full range advantage, you need to either go oblique, or turn into them, both of which give an inferior enemy a chance to close. If your speed or range advantage is so overwhelming that they still cannot deal with it, that's fine, such a massive tech difference should cause problems.

Edit: On retrospect, I'm not even sure that'll help, you'd just make larger laps of leaving then closing the range. I still think the solution to this problem is "Bring missiles"
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 12, 2020, 03:46:41 PM
it also would mean that you need a considerable advantage in technology to become invincible in beam combat and that a technologically inferior fleet could win if they have enough ships in many situations. It would make combat between beam ships behave more like combat between missile ships of different technological standards.

It wouldn't do this for the reasons I already covered, whether it involved engine tuning or not. Just fly to a point that's inside your range but outside theirs and stop; if they fly towards you, they're now getting the reduced range penalty too. It wouldn't change anything about beam combat other than adding extra micromanagement.

But that is pointless as that is the same as simply avoiding to fight as the other side could just move out of range and sit in return... so it would be pointless. The AI would never do it and the AI could simply move outside your range indefinitely until you tire of doing it and in a multi-faction human campaign you would not do it as it is simply pointless.

Either you commit to engage or you don't and try to run away using boost. If the enemy still can catch you then you are in bad luck and the tech gap simply is too big.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 12, 2020, 03:57:09 PM
But that is pointless as that is the same as simply avoiding to fight as the other side could just move out of range and sit in return... so it would be pointless. The AI would never do it and the AI could simply move outside your range indefinitely until you tire of doing it and in a multi-faction human campaign you would not do it as it is simply pointless.

Either you commit to engage or you don't and try to run away using boost. If the enemy still can catch you then you are in bad luck and the tech gap simply is too big.

That was discussing the situation without boosting. You said it meant an inferior tech but numerically superior force could actually win and I was pointing out that it didn't do that at all. The enemy force can't move outside of your range, because once they do their weapons have the same .5x range modifier, so you move to .5x your range which is outside .5x their range and you're able to fire unopposed. Then if they stop moving, before their range goes back to normal you can move back out to 1x. If they move after that, you repeat everything, if not you eventually get back to 1x range modifier too and they're dead.

I've already pointed out why I think your separate suggestion for engine tuning is also a bad idea, but for different reasons.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 12, 2020, 04:10:54 PM
Bremen beat me to it, these changes don't do anything but add micro. Same goes for boost, if the slower fleet kicks on boost but can't fight, its not helping at all, and if boost becomes key to beam combat, everyone will just bring boost. So if your boost is fast enough to outpace the otherwise superior enemy, they'll just kick on their superior boost and now its back to the same problem, except nobody can fire their guns without chilling dead in the water for a while. I guess its good for running away?

I'm still not entire sure why we're trying to create a complex system to resolve a problem that has already been solved. The beam knife fighting problem of minor advantages being an all or nothing win was already solved with the implementation of missiles, you are supposed to use combined arms. A modern guns only warship would be shredded it it tried to face down a faster opponent with longer range on its guns, and the solution was cruise missiles. Beams are supposed to be secondary batteries, and the risk to using them instead of your missile armament is being at that disadvantage to your enemy.

The only thing I can think of that doesn't involve ridiculous amounts of micromanagement, while also stopping the worst of beam kiting, is have it based on direction. if you opponent is within a given angle from your rear (based on your movement that turn) then you suffer a range malus for firing into your engine wake or something technical like that. Superior opponents will retain their speed advantage, but can't fire as far directly backwards. This means you can't just fly directly away from the enemy and use the full range advantage, you need to either go oblique, or turn into them, both of which give an inferior enemy a chance to close. If your speed or range advantage is so overwhelming that they still cannot deal with it, that's fine, such a massive tech difference should cause problems.

Edit: On retrospect, I'm not even sure that'll help, you'd just make larger laps of leaving then closing the range. I still think the solution to this problem is "Bring missiles"

I agree that missiles is a solution to beam weapons in general. The suggestion was for those that like to play with only beam weapons mostly. Try playing a campaign with only using beam weapons with multiple faction, it will end badly I believe... I have never tried it though as you want a balanced fleet to be strong.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 12, 2020, 04:18:55 PM
But that is pointless as that is the same as simply avoiding to fight as the other side could just move out of range and sit in return... so it would be pointless. The AI would never do it and the AI could simply move outside your range indefinitely until you tire of doing it and in a multi-faction human campaign you would not do it as it is simply pointless.

Either you commit to engage or you don't and try to run away using boost. If the enemy still can catch you then you are in bad luck and the tech gap simply is too big.

That was discussing the situation without boosting. You said it meant an inferior tech but numerically superior force could actually win and I was pointing out that it didn't do that at all. The enemy force can't move outside of your range, because once they do their weapons have the same .5x range modifier, so you move to .5x your range which is outside .5x their range and you're able to fire unopposed. Then if they stop moving, before their range goes back to normal you can move back out to 1x. If they move after that, you repeat everything, if not you eventually get back to 1x range modifier too and they're dead.

I've already pointed out why I think your separate suggestion for engine tuning is also a bad idea, but for different reasons.

Yes... you are partially right... but there would be no need to do that... you would move into a decent range and be at a disadvantage for a while and after that you would get advantage in accuracy (as your fire-control range is better). Now it is a mettle of whose fleet is stronger. Once either side feel they are loosing they can try to disengage and retreat. This would produce partial destruction of a fleet rather than one fleet always ending up destroyed every time.

Either you fight or you flee. Now you at least can try and fight for a while and then flee...

Boosting would be necessary for both sides having a chance to flee in combat situation where the difference in tech is not too great. It might not work all the time but it will at times do so. If there is no boost you would at least be able to get the slower fleet a chance to take some of the offender with them in defeat.

So.. yes... it would give a power boost to the one who are defending in beam combat. I don't see a direct problem with that.

It would produce more to do in beam combat and combat would take longer. But tactical retreat would make more leeway of manoeuvre, especially with multiple task-forces.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 12, 2020, 04:26:04 PM
Yes... you are partially right... but there would be no need to do that... you would move into a decent range and be at a disadvantage for a while and after that you would get advantage in accuracy (as your fire-control range is better). Now it is a mettle of whose fleet is stronger. Once either side feel they are loosing they can try to disengage and retreat. This would produce partial destruction of a fleet rather than one fleet always ending up destroyed every time.

Boosting would be necessary for both sides having a chance to flee in combat situation where the difference in tech is not too great. It might not work all the time but it will at times do so.

So.. yes... it would give a power boost to the one who are defending in beam combat. I don't see a direct problem with that.

I mean, yeah, a fleet could voluntarily move into range and fight it out instead of winning without ever being shot at. This is also true in the current version of the rules. But in both the current version and your proposed changes it wouldn't happen, since the fleet with the range and speed advantage wouldn't voluntarily give up its advantage.

As for boosting, yes, I get that you want a fleet to be able to disengage if it's losing beam combat. But the problem with that is that if either side can disengage from beam combat whenever they want, the result will be beam combat never happening, because one side is always going to be at a disadvantage, and the result of that is going to be both sides only being pure missile combatants because there's no way to force beam combat. At this point we're just repeating ourselves.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 12, 2020, 04:34:47 PM
Specifically the claim that 'beam combat will never happen if they can disengage' is not true.  There are two distinct interpretations of that which seem apparant to me at this time.

First one is that they will never engage in the first place because they see a disadvantageous engagement and choose to not take said engagement.  In order to do that the player would need to reliably predict that that is the case, and I think it could be reasonably claimed that neither the AI nor the player will be perfect at this.  It would also require that the defender have no targets that they are obliged to defend, which is also unlikely (you would probably have to defend your main population, if not any other critical installations you might possess).  In general though I think it would be a relatively good thing, because it means a star could change hands without a fight even necessarily taking place.  You show up with a fleet, present an unwinnable situation, and the enemy chooses to withdraw (and is actually able to reliably do so).  That type of scenario has I think been lacking from aurora for quite a while but is entirely realistic and in my opinion can be fun because locating a large percentage of the low tech enemies fleet isn't necessarily an instant game over for them, meaning the conflict can be drawn out and there is a chance more things will happen.

The second possible interpretation is that the ships trade blows, and then the side that is currently losing decides to run away.  I think thats fine, because you will probably kill some of them anyways since most likely there are several mobility kills if nothing else, and even if not then you have inflicted damage that they now need to go repair, thereby inflicting a load on their repair and logistical infrastructure, as well as temporarily taking ships out of action, which will make a difference to their overall ability to continue fighting.

e: In general I would argue that if a damaged fleet is able to withdraw, then it allows a much more logistical form of warfare.  If both sides can usually withdraw before a ship is outright destroyed (barring an unlucky mobility kill) then that means you would potentially be trying to win by straining their logistics to the point that they can no longer make enough of their fleet ready to continue offering effective resistance.  This is a much more fun and complicated concept in my opinion, because you now have new design considerations, regarding how you build your ships, and how you prepare for a conflict.  Deep wells of replacement components for repairs might become more useful, for instance.
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on January 12, 2020, 04:48:16 PM
I'm not sure how well disengagement would work, now that I think on it. Assuming both beam only forces have boost, if the inferior group flipped on boost and turned tail for a jump point, the superior force can just flip on their boost and head for the same jump point, likely reach it first (depends on the speed advantage and the range before the retreat was called), and drop back to regular drives and intercept. If the range was great enough that the inferior defender can make it before the attacker, then they could have achieved the exact same retreat in a version of the game where boost never existed.

The only reason we don't see this happen currently is the superior force can engage, instead of bypassing them to sit at the jump point.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 12, 2020, 04:51:56 PM
I'm not sure how well disengagement would work, now that I think on it. Assuming both beam only forces have boost, if the inferior group flipped on boost and turned tail for a jump point, the superior force can just flip on their boost and head for the same jump point, likely reach it first (depends on the speed advantage and the range before the retreat was called), and drop back to regular drives and intercept. If the range was great enough that the inferior defender can make it before the attacker, then they could have achieved the exact same retreat in a version of the game where boost never existed.

The only reason we don't see this happen currently is the superior force can engage, instead of bypassing them to sit at the jump point.

Maybe, but that requires that both sides know where the jump point is, and even if they do it only gives the faster force a few seconds to engage before the other force can jump. Or the slower force can just decline to use the jump point until the faster force leaves.

My main point is that currently, the only way beam ships can kill missile ships is by closing the range and forcing them into a beam fight. Any change that makes it more difficult to force a beam fight therefor disproportionately favors missile ships because it makes them very nearly impossible to kill.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 12, 2020, 04:54:46 PM
Boosting would need to be something you really really want to avoid doing, in order to avoid the superior side just happily doing it as well to chase down the lower tech enemy.

Perhaps you are damaging certain delicate ship components over time by doing it.  The list of said components could probably be fairly arbitrary since its just not really known what parts would be the most sensitive to 'boosting', especially that far into the future, so you could equally say the fire controls break down or the sensors or something else.  Then you actually need to sit around repairing things for a while before you are fully operational again.

It would still presumably be usable to chase down an inferior enemy at that point, but I feel like if the damage set in fairly quickly and you wind up burning through a lot of MSP and time to get back to readiness every time you do it, then it would greatly discourage it.  The idea being its generally only worth it if you are going to really score big by continuing the pursuit, or in the case of the fleeing side, its mainly worth it if the ships were probably going to die anyways, so sustaining some damage instead is preferable.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 12, 2020, 04:56:48 PM
Yes... you are partially right... but there would be no need to do that... you would move into a decent range and be at a disadvantage for a while and after that you would get advantage in accuracy (as your fire-control range is better). Now it is a mettle of whose fleet is stronger. Once either side feel they are loosing they can try to disengage and retreat. This would produce partial destruction of a fleet rather than one fleet always ending up destroyed every time.

Boosting would be necessary for both sides having a chance to flee in combat situation where the difference in tech is not too great. It might not work all the time but it will at times do so.

So.. yes... it would give a power boost to the one who are defending in beam combat. I don't see a direct problem with that.

I mean, yeah, a fleet could voluntarily move into range and fight it out instead of winning without ever being shot at. This is also true in the current version of the rules. But in both the current version and your proposed changes it wouldn't happen, since the fleet with the range and speed advantage wouldn't voluntarily give up its advantage.

As for boosting, yes, I get that you want a fleet to be able to disengage if it's losing beam combat. But the problem with that is that if either side can disengage from beam combat whenever they want, the result will be beam combat never happening, because one side is always going to be at a disadvantage, and the result of that is going to be both sides only being pure missile combatants because there's no way to force beam combat. At this point we're just repeating ourselves.

No... that no shot scenario will never occur as you will have to get in range if you want to fight unless you have twice the range. It would not work as you believe it would as there is a timer on when you can fire at full efficiency after moving. If the slower fleet can't flee there is no point if them moving unless you move out of their range while being still, but that is akin to not wanting to fight and would be a pointless move to make if you want to attack.

If you can't win against the opponent you might as well just allow them to run away and perhaps shadow them at range.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 12, 2020, 05:03:19 PM
I'm not sure how well disengagement would work, now that I think on it. Assuming both beam only forces have boost, if the inferior group flipped on boost and turned tail for a jump point, the superior force can just flip on their boost and head for the same jump point, likely reach it first (depends on the speed advantage and the range before the retreat was called), and drop back to regular drives and intercept. If the range was great enough that the inferior defender can make it before the attacker, then they could have achieved the exact same retreat in a version of the game where boost never existed.

The only reason we don't see this happen currently is the superior force can engage, instead of bypassing them to sit at the jump point.

How do you know there are no reinforcement waiting there... using boost for longer ranges will mess with your fuel, MSP and maintenance cycles and can basically mean you have to abort your offensive and the opponent win anyway as you have to retreat back to where you came from. You might find an enemy reserve task-force heading your way... now you wasted fuel, MSP and burned your fleet stamina for nothing. The defender retreated a few frigates while you waster a couple of cruiser running after them. The list could go on...

There are strategical reasons for not wanting to use boost to follow a retreating enemy... not everything is about destroying assets... that is rarely what missions is all about, just a bonus.

There are all manner of reason for why you would not want to follow an enemy trying to retreat. Things are not as simple as just one fight allot of the time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 12, 2020, 05:12:22 PM
No... that no shot scenario will never occur as you will have to get in range if you want to fight unless you have twice the range. It would not work as you believe it would as there is a timer on when you can fire at full efficiency after moving. If the slower fleet can't flee there is no point if them moving unless you move out of their range while being still, but that is akin to not wanting to fight and would be a pointless move to make if you want to attack.

Umm, no, you are completely wrong there, and I've repeatedly tried to explain why. Ok, let me try again.

Fleet A moves at 5,000 km/s and has a range of 200,000 km. Fleet B moves at 6,000 km/s and has a range of 240,000km. Whenever they move a fleet has its range cut by 50% for 60 seconds (or whatever, these numbers only matter for the example).

Fleet B moves to a range of 201,000km and stops. Fleet A now has three choices:

A) Remain stationary. After 60 seconds, Fleet B starts shooting them and they die.
B) Approach Fleet B. Fleet B uses its superior speed to hold them at a range of 101,000 km and shoots them until they die.
C) Retreat from Fleet B. Fleet B uses its superior speed to close to a range of 101,000 km and shoots them until they die. If Fleet A stops at any point, Fleet B shoots them for 40 seconds, then backs away to 201,000 km and stops as well - at this point this whole scenario repeats, but with Fleet A already damaged.

This is the scenario without boosting. Boosting is a different discussion, and has its own isssues. But even with boosting, there's no way for the slower and shorter ranged fleet to ever get to fire.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 12, 2020, 05:31:55 PM
No... that no shot scenario will never occur as you will have to get in range if you want to fight unless you have twice the range. It would not work as you believe it would as there is a timer on when you can fire at full efficiency after moving. If the slower fleet can't flee there is no point if them moving unless you move out of their range while being still, but that is akin to not wanting to fight and would be a pointless move to make if you want to attack.

Umm, no, you are completely wrong there, and I've repeatedly tried to explain why. Ok, let me try again.

Fleet A moves at 5,000 km/s and has a range of 200,000 km. Fleet B moves at 6,000 km/s and has a range of 240,000km. Whenever they move a fleet has its range cut by 50% for 60 seconds (or whatever, these numbers only matter for the example).

Fleet B moves to a range of 201,000km and stops. Fleet A now has three choices:

A) Remain stationary. After 60 seconds, Fleet B starts shooting them and they die.
B) Approach Fleet B. Fleet B uses its superior speed to hold them at a range of 101,000 km and shoots them until they die.
C) Retreat from Fleet B. Fleet B uses its superior speed to close to a range of 101,000 km and shoots them until they die. If Fleet A stops at any point, Fleet B shoots them for 40 seconds, then backs away to 201,000 km and stops as well - at this point this whole scenario repeats, but with Fleet A already damaged.

This is the scenario without boosting. Boosting is a different discussion, and has its own isssues. But even with boosting, there's no way for the slower and shorter ranged fleet to ever get to fire.

The problem here is that you assume that fleet A wants to escape... in this scenario then I agree that fleet B will win as it is superiors in all three categories of speed, firepower AND range... they should win.

If fleet A have twice the firepower it can just stop and wait for fleet B to fly into their max range and start firing on it as it approaches, once they get to 101.000km they don't run... they keep fighting and will win as they still have superior firepower, even if fleet B get to fire at full range after 60 seconds. This is the point...

If they are inferior they can still make a stand and do SOME damage to the enemy fleet.

The faster fleet can still disengage as it is faster when it realise it is weaker in fire-power. But even if fleet B is stronger in fire-power then fleet A might still do SOME damage to fleet B and so the reinforcement that is coming will force fleet B to retreat instead of fleet B destroying that one too without breaking a sweat.

If fleet B moves outside of fleet B at 201.000km and stop then fleet A moves to 241.000km and stops and you can repeat that indefinitely which simply is ludicrous to do... either you commit or you don't. Sure fleet B can start following fleet but A can stop at any point and B will come under fire or have to move outside that 200.000km before A can fire. Sooo... you either commit to the fight or you don't... going back and forth will not really yield any result that way. The C scenario is the only one that can result in the quicker fleet doing damage without any in return if the time is not enough for B to fire a few times.

In my opinion a slower fleet don't have to be able to force a fight, forcing the enemy to leave is enough. At some point that faster fleet will have to fight as sometimes you will need to defend a fixed point.
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on January 12, 2020, 05:35:13 PM
maybe, we can split off the discussion about merits and flaws of a boosting/tuning/afterburner/whatacallit to a seperate thread?

also suggestion would it be possible to assign FAC's (Sub 1000 ton ships) to squadrons?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 12, 2020, 05:49:07 PM
maybe, we can split off the discussion about merits and flaws of a boosting/tuning/afterburner/whatacallit to a seperate thread?

also suggestion would it be possible to assign FAC's (Sub 1000 ton ships) to squadrons?

Squadrons don't exist in the VB6 sense. The new naval organisation in C# will allow you to create 'sub-fleets' that include any type of ship.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 12, 2020, 06:03:38 PM
maybe, we can split off the discussion about merits and flaws of a boosting/tuning/afterburner/whatacallit to a seperate thread?

Yes.. I think this subject are more or less emptied at this point.  ;)

I will only say that I liked that other suggestion with getting half range while kiting an opponent. Let's say you would get half range as long as you shoot someone moving in a 45-90 (or why not 180) degree cone behind you while moving in the other direction. That would probably be a simpler solution to kiting by a faster fleet with better range and leave fire-power to decide the fight more than just speed and range.

With speed you still are superior as you could run away or close whenever you wish which is strategically very strong. Range would give you a fire-power bonus.

In this instance you should be able to give an order of going into a specific range but also opt to not kite if the opponent tries to get closer to avoid kiting by mistake. This would generally take ships to within the distance that are the closest set by both sides. Or if you have the firepower to do so you could still kite, but you would need to have a significant fire-power advantage to do so.

This would be a far better solution most probably.
Title: Re: C# Aurora v0.x Suggestions
Post by: mtm84 on January 12, 2020, 06:13:27 PM
maybe, we can split off the discussion about merits and flaws of a boosting/tuning/afterburner/whatacallit to a seperate thread?

also suggestion would it be possible to assign FAC's (Sub 1000 ton ships) to squadrons?

Squadrons don't exist in the VB6 sense. The new naval organisation in C# will allow you to create 'sub-fleets' that include any type of ship.

I had been meaning to ask this early, how do sub fleets work with the new organization commands?  Do sub fleets have to be part of their parent fleet to get a naval command bonus?  How far do sub fleets nest?
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 12, 2020, 06:47:40 PM
The problem here is that you assume that fleet A wants to escape... in this scenario then I agree that fleet B will win as it is superiors in all three categories of speed, firepower AND range... they should win.

If fleet A have twice the firepower it can just stop and wait for fleet B to fly into their max range and start firing on it as it approaches, once they get to 101.000km they don't run... they keep fighting and will win as they still have superior firepower, even if fleet B get to fire at full range after 60 seconds. This is the point...

If they are inferior they can still make a stand and do SOME damage to the enemy fleet.

The faster fleet can still disengage as it is faster when it realise it is weaker in fire-power. But even if fleet B is stronger in fire-power then fleet A might still do SOME damage to fleet B and so the reinforcement that is coming will force fleet B to retreat instead of fleet B destroying that one too without breaking a sweat.

If fleet B moves outside of fleet B at 201.000km and stop then fleet A moves to 241.000km and stops and you can repeat that indefinitely which simply is ludicrous to do... either you commit or you don't. Sure fleet B can start following fleet but A can stop at any point and B will come under fire or have to move outside that 200.000km before A can fire. Sooo... you either commit to the fight or you don't... going back and forth will not really yield any result that way. The C scenario is the only one that can result in the quicker fleet doing damage without any in return if the time is not enough for B to fire a few times.

In my opinion a slower fleet don't have to be able to force a fight, forcing the enemy to leave is enough. At some point that faster fleet will have to fight as sometimes you will need to defend a fixed point.

I'm going to take this to PMs for now, since I'm mostly trying to correct Jorgen. If anyone's still interested let me know and we can make a thread for it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 12, 2020, 10:30:55 PM
I really like the idea that missiles with thermal sensors are more likely to damage engines than other systems, and that missiles with EM sensors are more likely to damage sensors, fire controls and shield generators than other systems.  It provides a reason to use sensor-equipped missiles other than conservation of ammo.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 12, 2020, 10:39:10 PM
I still think the solution to this problem is "Bring missiles"


This is not the solution; this is the problem I'm trying to fix.  I'm not interested in playing an Aurora where the 'only way' is missile fleets, long-range fighter strikes, and giant sensors.  That is not my fiction.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 12, 2020, 11:17:35 PM
I think at this point pretty much everyone is like 'but how does this solve my particular problem' which is resulting in a pretty obvious condition of every concept being rejected.  I do agree however that the engine boosting stuff discussed so far doesn't do a whole lot for the specific scenario of beam ships vs missile ships (aside from probably helping their ability to flee for their lives).  I think whats mostly come up so far is trying to blur the effect of tech level a little bit, in particular trying to mitigate wholesale slaughter where one fleet doing 4020 km/s with slightly longer range beams totally annihilates the one doing 4000km/s.



Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 12, 2020, 11:21:36 PM
In all seriousness can we just say that aurora TN beams are FTL and therefore can have range beyond the distance light can travel in 5 second increments?  The sensors are already FTL, so there is clearly some way to physically interact with stuff at FTL speeds.

The 5 second limit isn't because of light speed - that is just the convenient technobabble.

The real reason is that longer-range beams would unbalance the game. Currently, if you are out-ranged in a beam conflict, you at least have the chance to build faster ships and close the range. You'll take damage, but it isn't game over. If beam ranges become much longer, then speed becomes irrelevant and longest range wins every time.

This is where the missile vs beam combat idea last came up for me.  Maybe one way to mitigate beam range in general is to make it possible to shoot at a target from more or less any range, you just get a steadily diminishing chance to hit.  Assuming it was a relatively gentle curve (this part in particular is so vague its pretty far from ever being implemented, but may as well put it out there for now) you might be able to have a scenario where the lower tech side is still shooting back and is scoring damage, the attacking side is just generally getting the better of it because they have longer range beams.  That might then make it possible to pretty significantly expand the range of beam combat without literally taking 0 damage from the lower tech side.  I'll start working on some graphs to try to lay out a reasonable mathematical argument for how exactly that could work out.
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on January 13, 2020, 12:52:44 AM
If the goal is purely "I want beam armed ships at a minor but not crippling tech disadvantage to have an option when outranged and outsped", is there a reason that using regular engine boost in the design phase hasn't been discussed? Its always been a consideration in Aurora to bring combat capability to mitigate your potential weaknesses, what is to prevent you from taking your all beam forces, and adding a carrier or two to the fleet that hold max boosted FAC's or Fighters? These can work and give you a chance to fight back even if the enemy has a speed advantage against your standard forces, you just pay a significant fuel premium, and likely lose some of these ships as you blitz down the enemy formation.

Maybe I'm just failing to understand why this is a big problem that needs to be solved, when a massive part of Aurora has always been designing new ships to counter the enemy, or designing in advance to combat your known weaknesses. This is feeling like a solution to an extremely niche, contrived problem of multiple 'what if' scenarios stacking atop of each other.

I really like the idea that missiles with thermal sensors are more likely to damage engines than other systems, and that missiles with EM sensors are more likely to damage sensors, fire controls and shield generators than other systems.  It provides a reason to use sensor-equipped missiles other than conservation of ammo.

This is an idea I could get behind, could also add value to thermal reduced engines once the ship has been engaged, since its relative engine to ship thermal difference should be lower. Something could probably do the same for the EM ones, ECCM, maybe cloaking too?
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 13, 2020, 01:10:55 AM
Mainly because of the volatility of outcome.  The fact that FACs can be built has very little to do with it, because at the end of the day if those FACs are fighting something that outranges them and even only slightly outspeeds them then they will still get annihilated with no risk to their enemy.  The sheer inelasticity of that outcome is kindof the problem, and I do agree with others that its rather a big one.  I once wiped out an entire enemy fleet of like 100 ships with one trapped beam armed destroyer that was kiting them.  Strictly I took some casualties, but that was because the enemy fired missiles (they massively overkilled a jump gate constructor, and then destroyed one of the two accompanying destroyers).  Once they ran out of missiles they had literally a 0% chance of either destroying the remaining ship or running away.  The AI did eventually try to flee but I just switched to pursuing them instead and wiped them out to the last ship, which turned out to be more or less that entire NPRs space navy.  The sheer absurdity of that is not a good gameplay aspect in my opinion, there was absolutely no risk whatsoever and I wasn't even all that much faster than them to my recollection.  The fact that the beams would probably break down eventually in the current version is only a minor mitigation, because being able to fire from complete safety until your lasers literally break down and run out of parts is still very excessive (in my opinion).

Another way of putting it, as soon as that NPR was caught out against even one destroyer the game was over.  There was no designing for them, there was no anything.  Their fleet didn't even make it back to their main planet to get more missiles before it was completely destroyed.  The flight would have taken several hours, they did not have several hours.

extra edit:
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on January 13, 2020, 01:38:22 AM
Why is this considered a problem? If you have a speed and range advantage in a gunfight, you can destroy the enemy at your leisure. This is perfectly realistic and logical, and happened in history - an example would be the destruction of the German squadron at the battle of the Falklands in WWI.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 13, 2020, 01:44:42 AM
Yeah but its not like the entire british grand fleet was killed by one kitey boy in a single day at any point, nor was there any risk of that ever happening like that.  I'm not arguing against lower tech enemies being massacred wholesale, I'm fine with that, but the fact that its so inelastic in the technical sense of the word inelastic, that is to say its pretty much going to be one side winning by a landslide in almost every circumstance, including ones where the ships are almost identical, is a really seirous problem.

e:  What I mean to say is, one small ship wiping out a really massive amount of enemy tonnage should probably be a matter of pretty significant technical edge, not literally a couple hundred km/s of extra speed plus a spinal beam that happens to outrange anything they have but is otherwise the same tech.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 13, 2020, 01:45:31 AM
Mainly because of the volatility of outcome.  The fact that FACs can be built has very little to do with it, because at the end of the day if those FACs are fighting something that outranges them and even only slightly outspeeds them then they will still get annihilated with no risk to their enemy.  The sheer inelasticity of that outcome is kindof the problem, and I do agree its rather a big one.  I once wiped out an entire enemy fleet of like 100 ships with one trapped beam armed destroyer that was kiting them.  Strictly I took some casualties, but that was because the enemy fired missiles (they massively overkilled a jump gate constructor, and then destroyed one of the two accompanying destroyers).  Once they ran out of missiles they had literally a 0% chance of either destroying the remaining ship or running away.  The AI did eventually try to flee but I just switched to pursuing them instead and wiped them out to the last ship, which turned out to be more or less that entire NPRs space navy.  The sheer absurdity of that is not a good gameplay aspect in my opinion, there was absolutely no risk whatsoever and I wasn't even all that much faster than them to my recollection.  The fact that the beams would probably break down eventually in the current version is only a minor mitigation, because being able to fire from complete safety until your lasers literally break down and run out of parts is still very excessive (in my opinion).

Another way of putting it, as soon as that NPR was caught out against even one destroyer the game was over.  There was no designing for them, there was no anything.  Their fleet didn't even make it back to their main planet to get more missiles before it was completely destroyed.  The flight would have taken several hours, they did not have several hours.

I agree that this is the main problem that needs to be looked at. The fact that you can use to attack someone with impunity with a rather small advantage in beam and speed build. The border between when you can attack with impunity or the weaker side at least do some damage needs to be bigger. Having faster speed is still really strong as you can retreat from a fight at any time, if you also have just slightly better range you can kill almost any number of enemy ships.

Now... there are some minor tricks you can do with dividing up an inferior fleet in several parts and use escort mechanic to fore the distance to some extent, but that usually take a very strong fleet to do damage to an enemy that have a tiny bit if speed and range advantage.

I would like if an inferior beam fleet at least could do some damage back at a reasonable rate. Some mechanic that at least forces two fleet to close to a place where both can use their beam weapons.

Now, I do believe that you probably should need to have some beam defence in a fleet, even if missiles are the primary weapon. If one is caught with no missiles left and have no beam weapons available (or very short ranged ones) then you should probably be destroyed if caught in beam range combat eventually. A boost technology might help with this scenario. The question is then if you actually need beam weapons much at all on ships rather than good engines and the ability to boost away when missiles are gone. The AI should at least be better at building balanced fleets and have some beam weapons present in most fleets.

But having every ship that is just a bit slower and a bit shorter ranged weapon incapable to strike back is not that fun or exciting. I would like to see beam ships actually fire at each other outside having the same maximum range (where initiative can be another really huge factor) or each side the upper hand in either range or speed.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 13, 2020, 01:55:03 AM
Why is this considered a problem? If you have a speed and range advantage in a gunfight, you can destroy the enemy at your leisure. This is perfectly realistic and logical, and happened in history - an example would be the destruction of the German squadron at the battle of the Falklands in WWI.

But even in WWI and II ship fights there would be some danger of enemy shells hitting some unarmoured part of a ship or just freak accidents happen to a ship that appear superior... this happened during both WWI and II ship engagements. During the fight you describe then both sides ship were under fire and the British sustained hits even if they were minor.

When playing Rule the Waves 2 I had a destroyer lobbing a 5" shell right into the torpedo tube of a 12000t battle cruiser as one example... it was a freak action shot but an epic one. It did not destroy the battlecruiser but it was doomed after that shot...  ;) ...now this could as well have been a ship with slower speed than the battle cruiser as in WWI you always had to come under some form of fire to attack someone, even against inferior ranged weapons, the chance of damage to you just were allot less than to them. You just could not sit at extreme range as the accuracy was too bad and ammunition was finite.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 13, 2020, 05:16:25 AM
I had been meaning to ask this early, how do sub fleets work with the new organization commands?  Do sub fleets have to be part of their parent fleet to get a naval command bonus?  How far do sub fleets nest?

Sub-fleets are purely organizational. You can nest as deep as you want. All sub-fleets benefit from command bonuses that apply to the parent fleet.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on January 13, 2020, 05:40:32 AM
Another way of putting it, as soon as that NPR was caught out against even one destroyer the game was over.  There was no designing for them, there was no anything.  Their fleet didn't even make it back to their main planet to get more missiles before it was completely destroyed.  The flight would have taken several hours, they did not have several hours.
That problem has already been fixed for C# we don't need another fix. Steve has confirmed that with the new AI functionality, the NPR battle fleets will be better balanced and the NPR will understand when the run quicker. Plus, as you yourself said, the new weapon breakage rule. There shouldn't be a situation where the NPR attacks you with 100 missile ships. The problem was never beams themselves, it was an AI problem.

And I would disagree that the system even in VB6 is inelastic. Your given example, sure. But because there are so many possibilities for weapon range and ship speed combinations, this problem isn't one that would happen routinely unless the player intentionally builds their fleets to trap themselves.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 13, 2020, 06:55:14 AM
The discussion seems to be coming down to answering the question: Is it good for the game that a small force that is slightly faster and has longer-range weapons can completely destroy a much larger force?

In my recent campaign update for example, a damaged Necron destroyer could potentially have wiped out the entire Expeditionary Fleet if that fleet did not have either torpedoes or fighters. However, in this case they did have both torpedoes and fighters, because I knew from previous tactical intelligence that the enemy ships were faster and had longer-ranged weapons. If I did not have those capabilities, then I would not have sent the fleet into the system in the first place.

Earlier in the campaign, I found myself in exactly that situation and lost a fleet because I couldn't get escape. In that case however, I was unprepared, had minimal tactical intelligence and was surprised by an opponent with a significant tech advantage. After that point I was extremely wary about placing my forces in a similar situation and conducted operations accordingly. I have been working on ships and technology to counter the Tyranid advantages so I can go back into combat with some chance of success.

So in general, I think if you find yourself in a bad situation in deep space against a higher tech opponent with longer-ranged weapons, you probably should be in serious trouble. However, lets look at an extreme situation. A single small ship vs a very large opposing force. Unless the tech advantage is very large, the small ship will be firing at extreme range and therefore might still struggle to overcome the shield recharge rate of the large force. Also, the large force can split up, either for most of them to escape or to attempt to surround the faster opponent.

In summary, I think there are options for a weaker, lower tech race to fight a higher tech, faster race. That is one of the challenges of the game.

Finally, having argued the above, I think there might be an option we haven't considered so far; the equivalent of 'making smoke'. Perhaps there should be some form of crude ECM that makes a ship harder to hit, but also affects its own weapons. In this situation, the lower tech force might be able to 'obscure' itself sufficiently to make it difficult for a small, higher tech force to obtain a long-range firing solution. The higher tech force would either have to move closer to gain a better firing solution, opening itself up to counter-attack if the 'smoke' is turned off, or be content with shadowing the enemy. This capability would only be useful in that type of situation and only useful for the lower tech force. My concern would how the AI handles this, but I think I could code it.

Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on January 13, 2020, 08:11:25 AM
Modern day 'smoke' would have to be pretty hightech; it not only needs to obscure the visual light spectrum, it also needs to obscure radar rangefinding. And in Aurora? Aiming isn't done by looking down the sights at the target, distances are far too great, so it's all done by long range sensors.

Which makes the question of 'how to display ECM' kinda difficult. There are three kinds of sensors in Aurora; thermal passive, electromagnetic passive, and electromagnetic active, some technobabble applied to make them not suffer light-lag. Electromagnetic active is the only aiming system used by beam weapons, and missiles without their own sensor package are pretty clearly semi-actively guided, that is to say that they follow the sensor return from the missile fire control system to their target (otherwise they wouldn't be wired to explode due to loose weapon risk when the MFC loses target lock), and missiles with their own sensor package hunt enemy ships through them instead and do so infallibly (which is quite a trick, as real life has yet to figure out how to make guided munitions not explode your own ships, aircraft, tanks and everything else when they get pointed that way. A self guiding torpedo or missile has no friends).

Defeating all these sensor types at once is difficult, but the technobabble for why they suffer no light-lag could actually provide us a system as to how that could happen. The 'smoke generator' system drags the ship in question or the electromagnetic spectrum out of the aether in such a way that all sensor systems suffer from light lag. On the one side, it's a massive 'I'm here' marker due to how it interacts with the aether and as any player of World of Warships can tell you that tends to attract torpedoes. On the other side, good luck actually hitting a target without absolutely saturating the place with gunfire. And from the inside, good luck seeing out of it, you are going to need somebody whose view is not obscured by the smoke telling you where your shots are landing.

It would be best if this took more than just some hullsize and a few more tons of material though, it's probably a system that should be eating MSP or fuel to function. Though it's fair to note that it's basically a really low quality stealth system.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 13, 2020, 08:21:47 AM
Modern day 'smoke' would have to be pretty hightech; it not only needs to obscure the visual light spectrum, it also needs to obscure radar rangefinding. And in Aurora? Aiming isn't done by looking down the sights at the target, distances are far too great, so it's all done by long range sensors.

Which makes the question of 'how to display ECM' kinda difficult. There are three kinds of sensors in Aurora; thermal passive, electromagnetic passive, and electromagnetic active, some technobabble applied to make them not suffer light-lag. Electromagnetic active is the only aiming system used by beam weapons, and missiles without their own sensor package are pretty clearly semi-actively guided, that is to say that they follow the sensor return from the missile fire control system to their target (otherwise they wouldn't be wired to explode due to loose weapon risk when the MFC loses target lock), and missiles with their own sensor package hunt enemy ships through them instead and do so infallibly (which is quite a trick, as real life has yet to figure out how to make guided munitions not explode your own ships, aircraft, tanks and everything else when they get pointed that way. A self guiding torpedo or missile has no friends).

Defeating all these sensor types at once is difficult, but the technobabble for why they suffer no light-lag could actually provide us a system as to how that could happen. The 'smoke generator' system drags the ship in question or the electromagnetic spectrum out of the aether in such a way that all sensor systems suffer from light lag. On the one side, it's a massive 'I'm here' marker due to how it interacts with the aether and as any player of World of Warships can tell you that tends to attract torpedoes. On the other side, good luck actually hitting a target without absolutely saturating the place with gunfire. And from the inside, good luck seeing out of it, you are going to need somebody whose view is not obscured by the smoke telling you where your shots are landing.

It would be best if this took more than just some hullsize and a few more tons of material though, it's probably a system that should be eating MSP or fuel to function. Though it's fair to note that it's basically a really low quality stealth system.

I think you can make up ANY techno babble to fit the narrative, here is another one...

Fire-controls are calculating Eather waves which is way more precise and faster than regular EM range finder systems. Now the "smoke" is some spacial disturbance active sensors which make ripples in the Eather and much harder to fix a ships exact position unless you move closer to cut through the noise. Likewise it make your own range finder systems act crazy as well. Might even effect any active sensors in use within a certain distance of the task-force as well, just for kicks.

You basically can make up any story you wish to make any mechanic internally consistent as everything in the game are make believe anyway... ;)
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 13, 2020, 08:37:25 AM
The discussion seems to be coming down to answering the question: Is it good for the game that a small force that is slightly faster and has longer-range weapons can completely destroy a much larger force?

In my recent campaign update for example, a damaged Necron destroyer could potentially have wiped out the entire Expeditionary Fleet if that fleet did not have either torpedoes or fighters. However, in this case they did have both torpedoes and fighters, because I knew from previous tactical intelligence that the enemy ships were faster and had longer-ranged weapons. If I did not have those capabilities, then I would not have sent the fleet into the system in the first place.

Earlier in the campaign, I found myself in exactly that situation and lost a fleet because I couldn't get escape. In that case however, I was unprepared, had minimal tactical intelligence and was surprised by an opponent with a significant tech advantage. After that point I was extremely wary about placing my forces in a similar situation and conducted operations accordingly. I have been working on ships and technology to counter the Tyranid advantages so I can go back into combat with some chance of success.

So in general, I think if you find yourself in a bad situation in deep space against a higher tech opponent with longer-ranged weapons, you probably should be in serious trouble. However, lets look at an extreme situation. A single small ship vs a very large opposing force. Unless the tech advantage is very large, the small ship will be firing at extreme range and therefore might still struggle to overcome the shield recharge rate of the large force. Also, the large force can split up, either for most of them to escape or to attempt to surround the faster opponent.

In summary, I think there are options for a weaker, lower tech race to fight a higher tech, faster race. That is one of the challenges of the game.

Finally, having argued the above, I think there might be an option we haven't considered so far; the equivalent of 'making smoke'. Perhaps there should be some form of crude ECM that makes a ship harder to hit, but also affects its own weapons. In this situation, the lower tech force might be able to 'obscure' itself sufficiently to make it difficult for a small, higher tech force to obtain a long-range firing solution. The higher tech force would either have to move closer to gain a better firing solution, opening itself up to counter-attack if the 'smoke' is turned off, or be content with shadowing the enemy. This capability would only be useful in that type of situation and only useful for the lower tech force. My concern would how the AI handles this, but I think I could code it.

This sort of mirror my feeling as well... the problem is mainly when I play multi-factions and technologies are fairly similar. I don't want one faction that just managed to get a better ranged fire-control to dominate beam combat quite literally. The main issue is basically to blur the line a bit and make fire-power a part of the the question as well as range and speed. Having a better speed and range is already in and of itself a huge advantage even if a weaker side could force the other into engagement, but it might mean that the one with better speed and range might need to retreat rather than engage at some time as the enemy has too much strength present, such as one destroyer against four destroyers.

Missiles are obviously the first solution to most problems.

I assume that this "smoke" would only effect the ship it is on and the one targeting it. This would definitely favour smaller ships or if you have more ships of lower tech perhaps. In any way it would favour the most numerous enemy. So lets say you use smoke and enemies have half range to hit you while you have half range hitting them in return.

I think that perhaps it should be a task-force thing to avoid micro management in that case, so you don't switch smoke on and off per ship depending on which ship is targeted, but that might be odd to handle it that way.

An order to a task-force to automatically use or not use smoke at specific distances would then be good so you don't have to manually switch them on and off.

Just some ideas...

The smoke idea also might make immobile defence platforms a bit more viable for defending points in space with beam weapons and not just missiles.
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on January 13, 2020, 10:32:57 AM
How about an active sensor jammer option that reduces beam fire control range? Or sensor decoys that work like missiles but mimic a ship's sensor signature? The smoke idea could be a cloud of duranium chaff that causes sensor disruption.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 13, 2020, 10:50:46 AM
Another way of putting it, as soon as that NPR was caught out against even one destroyer the game was over.  There was no designing for them, there was no anything.  Their fleet didn't even make it back to their main planet to get more missiles before it was completely destroyed.  The flight would have taken several hours, they did not have several hours.
That problem has already been fixed for C# we don't need another fix. Steve has confirmed that with the new AI functionality, the NPR battle fleets will be better balanced and the NPR will understand when the run quicker. Plus, as you yourself said, the new weapon breakage rule. There shouldn't be a situation where the NPR attacks you with 100 missile ships. The problem was never beams themselves, it was an AI problem.

And I would disagree that the system even in VB6 is inelastic. Your given example, sure. But because there are so many possibilities for weapon range and ship speed combinations, this problem isn't one that would happen routinely unless the player intentionally builds their fleets to trap themselves.

They had plenty of beams, however said beams were shorter ranged and therefore did nothing.  Also them choosing to retreat sooner would not have saved them, they didn't even get close to making it back to their planet.  Basically if you wanted a pure beam fleet, then the only logical thing you can do is make the biggest longest range beam you possibly can, and make the ship as fast as is economically practical, and then you will not be defeated by other beams.

As far as I can see it though, Steve is basically like 'you shouldn't do a beam only fleet' so I suppose the point is relatively moot.  Also as Steve pointed out, both the player and AI making heavier use of shields at lower techs (alpha shields) would blur the range issue to a meaningful extent which would also undoubtedly help.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 13, 2020, 11:03:48 AM
I think it is just fine that missiles are suppose to be the primary weapon system in general.

But it can still be fun with experimenting with beam combat, especially in multi-faction campaign settings... When I had beam combat in my campaigns I simply allowed the longer ranged fleets to enter the shorter ranged fleet range so combat was more exiting from a role-play perspective. The reasoning was that long range combat was inefficient and ammunition was not infinite so attacking at extreme ranges was stupid. If you had infinite ammunition in the real world fleets then you would have tried to stay out of enemy gun ranges too and just keep firing, you would hit eventually.

Factions with longer range and faster speed still had a huge benefit when it came to beam combat no matter what, but at least they were not one way engagements.

So personally I don't need a change from a role-play perspective, but it would be nice if that behaviour were mirrored in actual game mechanics.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 13, 2020, 11:10:46 AM
As far as I can see it though, Steve is basically like 'you shouldn't do a beam only fleet' so I suppose the point is relatively moot.  Also as Steve pointed out, both the player and AI making heavier use of shields at lower techs (alpha shields) would blur the range issue to a meaningful extent which would also undoubtedly help.

I'm not saying don't do beam only fleets - I have done beam-only races myself. I am saying, if you choose a beam-only fleet then make every effort to avoid being in a situation where you are in deep space against a faster, long-ranged opponent. Create faster ships and accept being very fuel-inefficient, or defend jump points, or do what I have done in this campaign against the Tyranids and run away at the strategic level until you can make a stand somewhere or you can develop longer-range weapons. Sometimes you are just outclassed and have to play the hand you are dealt as best you can.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 13, 2020, 11:20:05 AM
As far as I can see it though, Steve is basically like 'you shouldn't do a beam only fleet' so I suppose the point is relatively moot.  Also as Steve pointed out, both the player and AI making heavier use of shields at lower techs (alpha shields) would blur the range issue to a meaningful extent which would also undoubtedly help.

I'm not saying don't do beam only fleets - I have done beam-only races myself. I am saying, if you choose a beam-only fleet then make every effort to avoid being in a situation where you are in deep space against a faster, long-ranged opponent. Create faster ships and accept being very fuel-inefficient, or defend jump points, or do what I have done in this campaign against the Tyranids and run away at the strategic level until you can make a stand somewhere or you can develop longer-range weapons. Sometimes you are just outclassed and have to play the hand you are dealt as best you can.

Having a system like "smoke" actually would make beam fleets more attractive as you could then fight an enemy with slightly superior range and speed in deep space given you have enough numbers on your side. Thus you might not need to break the bank with over engineering the engines quite as much, more beams perhaps etc..
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on January 13, 2020, 11:58:41 AM
I agree, it would make beam combat a little more interesting, especially design wise. I'm in support of at least trying it.

EDIT: Also, I'm in favor of having ships in Aurora being unable to brake and start on a dime, moving and stopping after 10-20 seconds or something like that. Fighters could ignore that, which would make them more interesting.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on January 13, 2020, 12:48:28 PM
It's interesting how we started with "engine tuners" and went to "beam fire control ranges" and ended up with "Trans-Newtonian equivalent of destroyer laying a smoke screen"  8)

I'm definitely not against a ship module that consumes fuel or MSP and in return acts like a ECM on steroids for a little while, even if that effect works only against BFC - though in fairness sake it should probably affect MFC too but I can also see an exploit where the "smoke" is laid down just 5 seconds before non-self-guided missiles would hit and possibly cause them to self-destruct because the MFC was firing from maximum range and that just got reduced by the "smoke".

OTOH, that's not any different from the exploit of jumping back and forth through a JP or cruising back and forth across the firing range, causing the AI to waste all their missiles. So maybe it isn't a problem.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 13, 2020, 01:10:41 PM
It's interesting how we started with "engine tuners" and went to "beam fire control ranges" and ended up with "Trans-Newtonian equivalent of destroyer laying a smoke screen"  8)

I'm definitely not against a ship module that consumes fuel or MSP and in return acts like a ECM on steroids for a little while, even if that effect works only against BFC - though in fairness sake it should probably affect MFC too but I can also see an exploit where the "smoke" is laid down just 5 seconds before non-self-guided missiles would hit and possibly cause them to self-destruct because the MFC was firing from maximum range and that just got reduced by the "smoke".

OTOH, that's not any different from the exploit of jumping back and forth through a JP or cruising back and forth across the firing range, causing the AI to waste all their missiles. So maybe it isn't a problem.

I think you could technobabble a reason why MFC are not effected. They probably don't need terribly accurate information of a ships exact position at the exact time. Missiles probably also are intelligent enough for some self guidance and the missiles themselves rarely crash into the ship as explode very close to the ship.

This is the reason why missile fire controls can be used as such great ranges... smoke might actually make missile fire-controls lock on to a ship easier and not harder...  ;)
Title: Re: C# Aurora v0.x Suggestions
Post by: lupin-de-mid on January 13, 2020, 01:45:56 PM
the "smoke" is laid down just 5 seconds before non-self-guided missiles would hit and possibly cause them to self-destruct because the MFC was firing from maximum range and that just got reduced by the "smoke".
If smoke affect only hit chance not range, than it is not a problem. But better add cooldown for smoke generators
Title: Re: C# Aurora v0.x Suggestions
Post by: Bughunter on January 13, 2020, 05:14:11 PM
What if the dropoff in accuracy at/near maximum range was less sharp? At least for the earlier techs where you will have less design options available. That is you can fire at longer range but the hit chances are so low it will not normally be useful. But if you fleet is about to be annihilated by a single higher tech destroyer your sheer number of shots would at least give them a chance.

This is trying to solve one very specific problem, but I get the feeling any good solution would touch a lot of subsystems in the game and become a major coding/balancing job in comparison to the results.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 13, 2020, 06:23:27 PM
What if the dropoff in accuracy at/near maximum range was less sharp? At least for the earlier techs where you will have less design options available. That is you can fire at longer range but the hit chances are so low it will not normally be useful. But if you fleet is about to be annihilated by a single higher tech destroyer your sheer number of shots would at least give them a chance.

This is trying to solve one very specific problem, but I get the feeling any good solution would touch a lot of subsystems in the game and become a major coding/balancing job in comparison to the results.

Allowing all fire-controls to hit at max 5 light second distance would be one option where the difference is the curve gradient at which they gain accuracy down to 10k km distance would be one viable option. Now, one or two tech levels would only shift the accuracy at most ranges by 20-30% or so in difference. Now you could overwhelm the opponent with massive volumes of fire in worst case scenario.

It would be one other option.

Range of the weapons themselves might be another issue... but most lasers have such huge range that the to hit ratio for most fire-controls at max distances are so low that there would be no point of using them, especially now where there is a 2% failure rate on each shot.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 13, 2020, 11:36:39 PM
As far as I can see it though, Steve is basically like 'you shouldn't do a beam only fleet' so I suppose the point is relatively moot.  Also as Steve pointed out, both the player and AI making heavier use of shields at lower techs (alpha shields) would blur the range issue to a meaningful extent which would also undoubtedly help.

I'm not saying don't do beam only fleets - I have done beam-only races myself. I am saying, if you choose a beam-only fleet then make every effort to avoid being in a situation where you are in deep space against a faster, long-ranged opponent. Create faster ships and accept being very fuel-inefficient, or defend jump points, or do what I have done in this campaign against the Tyranids and run away at the strategic level until you can make a stand somewhere or you can develop longer-range weapons. Sometimes you are just outclassed and have to play the hand you are dealt as best you can.

I mean in fairness we have dudes who want to have a powerful beams-only fleet that is realistically able to beat up the big mean standoff missile boats and project a comparable if not superior presence in space.  What you are saying more or less totally precludes that.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 14, 2020, 03:24:54 AM
I mean in fairness we have dudes who want to have a powerful beams-only fleet that is realistically able to beat up the big mean standoff missile boats and project a comparable if not superior presence in space.  What you are saying more or less totally precludes that.

I think mixed armament is the most flexible option but if I had to choose between missile-only or beam-only for a campaign, I would have no hesitation in choosing beam-only.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 14, 2020, 06:26:19 AM
"Making smoke" is a reasonable interpretation of my requested 'run away' feature.  When my fleet (or even just my scout cruiser) realizes it is in over its head and just wants to get back through the jump point, all I care about is not being plinked to destruction one tiny little shot at at time.

Which means 'making smoke' needs to be a thing any ship (though not fighter) can do, not a component that has to be built and included.  I'm after an 'escape' button, not yet another tactical system to be managed.
Title: Re: C# Aurora v0.x Suggestions
Post by: UberWaffe on January 14, 2020, 07:37:32 AM
I really like the idea of more functionality on ECM, though personally I would like such option to be component designs rather than user-toggled buttons.  I like the idea of not having to micro-manage, but rather gather intelligence and plan long-term.

For some future release beyond the current release aims, I think being able to design ECM components with additional options would be good.
(The numbers here do not matter, mostly just there to convey the concepts. )
Title: Re: C# Aurora v0.x Suggestions
Post by: Alsadius on January 14, 2020, 08:02:28 AM
I really like the idea of more functionality on ECM, though personally I would like such option to be component designs rather than user-toggled buttons.  I like the idea of not having to micro-manage, but rather gather intelligence and plan long-term.

For some future release beyond the current release aims, I think being able to design ECM components with additional options would be good.
(snip)

I like the thinking here, but you need to make sure it doesn't turn into micromanagement hell. There's real advantage in having ECM/ECCM be passive, abstracted modules, because it makes combat easier to run. This is a fleet game, not a tactics game, so you need to be cautious about the level of detail being added to individual units.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 14, 2020, 08:14:50 AM
The smoke idea also need to look into how the weapon balance look like before implemented. Particle Beams would surely suffer if you could halve the range of weapons whenever you wish and short ranged weapons such as rail guns obviously would become more powerful, lasers probably would be roughly as useful as before as they still have lethal penetration power at shorter ranges.

I think that Particle Beams would need to be looked at, perhaps have them be the best armour penetrating weapon and only cut through one armour column or something like the lance.
Title: Re: C# Aurora v0.x Suggestions
Post by: misanthropope on January 14, 2020, 10:24:11 AM
if you can disrupt enemy fire while fleeing, you can disrupt enemy fire while closing.

is everybody sure for some reason that the beam burn-out doesn't sufficiently address the "kiting problem"?  a partial fix is distinctly preferable to an over-fix, from the standpoint of unintended consequences.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on January 14, 2020, 12:29:03 PM
is everybody sure for some reason that the beam burn-out doesn't sufficiently address the "kiting problem"?  a partial fix is distinctly preferable to an over-fix, from the standpoint of unintended consequences.
No, nobody is sure of that. We haven't had enough testing done. Steve hasn't encountered that situation in his test games. The chance is 2% for each time the weapon fires and it also requires that the ship has insufficient MSP left - otherwise the weapon will be instantly repaired and continues firing.

Someone better at statistics could throw numbers on a chart to illustrate the odds.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 14, 2020, 01:03:20 PM
if you can disrupt enemy fire while fleeing, you can disrupt enemy fire while closing.

is everybody sure for some reason that the beam burn-out doesn't sufficiently address the "kiting problem"?  a partial fix is distinctly preferable to an over-fix, from the standpoint of unintended consequences.

It addresses the most excessive examples of the situation, where one destroyer can destroy a fleet of battleships. However, from what I recall the actual MSP cost of firing works out sufficiently small that I don't think it will be a major factor. I'm also not sure if the AI has limited MSP, if you're on the defending side.

Shields getting a buff will also help with it, though that of course has the downside that it doesn't scale with larger numbers of ships - one destroyer vs one battleship the battleship might be able the shield tank long range fire, but 10 destroyers vs 10 battleships that could no longer be true.

So I think both those changes definitely help in some situations, but it will still be a potential issue with beam combat.
Title: Re: C# Aurora v0.x Suggestions
Post by: lupin-de-mid on January 14, 2020, 01:14:21 PM
Shields getting a buff will also help with it, though that of course has the downside that it doesn't scale with larger numbers of ships - one destroyer vs one battleship the battleship might be able the shield tank long range fire, but 10 destroyers vs 10 battleships that could no longer be true.
In case of one destroyer and 10 battleships  it possible to move out ship with most damaged shield (target) out of formation, so attacker should change target or move in range of fleet
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 14, 2020, 01:23:26 PM
is everybody sure for some reason that the beam burn-out doesn't sufficiently address the "kiting problem"?  a partial fix is distinctly preferable to an over-fix, from the standpoint of unintended consequences.
No, nobody is sure of that. We haven't had enough testing done. Steve hasn't encountered that situation in his test games. The chance is 2% for each time the weapon fires and it also requires that the ship has insufficient MSP left - otherwise the weapon will be instantly repaired and continues firing.

Someone better at statistics could throw numbers on a chart to illustrate the odds.

I have only done some rudimentary calculations... but here is one example...

In my starting new campaign I have an Ion tech ship with 3 15cm lasers that each have a cost of 66 so it will take 66 supplies if it breaks down. The ship is an 8000t frigate with a total of 353 MSP, so it can have 5 failures (or rather in the sixth it will stop firing). We also have to assume the ship has not had any previous failures of any components.

Let's say it engages at extreme range and will only do one damage. Also let's assume it has enough crew grade to get the accuracy to about 20%. So that is 1 in 5 shot that will hit. With a 2% failure rate the ship would roughly be able to do around 300 shots or do 60 damage over 500 seconds for three lasers on the same ship. The ship have 20 shields so can actually recharge about 33 additional damage over that time.

In theory that ship would do about 7 damage to the armour (against itself), the ship in question have four layers of armour for a total armour strength of 145.

This particular ship could never do any significant damage at extreme range against a similar ship.

Shields also become more and more effective over time against extreme range combat.

If the above ship have a max range of about 200.000km it will only start to do any significant damage until around 100.000km.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 14, 2020, 01:32:23 PM
if you can disrupt enemy fire while fleeing, you can disrupt enemy fire while closing.

is everybody sure for some reason that the beam burn-out doesn't sufficiently address the "kiting problem"?  a partial fix is distinctly preferable to an over-fix, from the standpoint of unintended consequences.

It addresses the most excessive examples of the situation, where one destroyer can destroy a fleet of battleships. However, from what I recall the actual MSP cost of firing works out sufficiently small that I don't think it will be a major factor. I'm also not sure if the AI has limited MSP, if you're on the defending side.

Shields getting a buff will also help with it, though that of course has the downside that it doesn't scale with larger numbers of ships - one destroyer vs one battleship the battleship might be able the shield tank long range fire, but 10 destroyers vs 10 battleships that could no longer be true.

So I think both those changes definitely help in some situations, but it will still be a potential issue with beam combat.

What happens in such a situation if the destroyers all focus in one battleship the rest will be able to close to within their weapons range using the formation mechanics this is easy to set up. I have used this many times in my multi-faction games. Beam combat sometimes devolves into a mess of one or a few ships in each task-group and ships moving all over the place. There will always be something in range, even for the one with slower speed or shorter ranged weapons. But the side with shorter ranged weapons still need to have numerical superiority to be able to beat the other side off.

The speed at which ships react to new orders also is a factor as is initiative.

So it is not always a clear cut scenario.

If the enemy focus their fire on one ship that ship will try to move away and the opponent will risk the enemy getting closer and increasing their weapons fire-power if they follow.

This is why shields are so important in beam combat in general.
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on January 14, 2020, 01:51:15 PM
So, in real life, a battlecruiser or fast battleship with long-range 14" guns and 26+ knots of speed could 'kite' a squadron of 12"-gunned, 21 knot early dreadnoughts basically forever and engage them from beyond the distance that they could return fire. But they wouldn't be able to sink very many, if any, because, in real life:

Ships have limited ammunition.
Long-range gunnery before radar fire control was horrendously inaccurate.
Eventually, weather or nightfall will artificially limit engagement ranges, forcing them to close in or withdraw.
Long-range gunfire would likely bounce harmlessly off battleship-tier armor, as opposed to Aurora, where all armor is ablative.

If you want to make it so that a single beam destroyer can't destroy a fleet of beam battleships, you could try to adapt these factors to Aurora.

Limited ammunition:
Beam weapons now consume some form of ammunition, whether that's ionized gas, duranium slugs, or reactor fuel. Make it completely separate from the engine fuel, and produced at a certain rate without cost by maintenance facilities. Unlike missile magazines, beam magazines are inert and nonexplosive.

Accuracy:
Increase base beam range, while simultaneously reducing beam fire control range. Basically, make it so that most beam weapons' ranges overlap more, and if you're on the edge of engagement range, hits are unlikely and do so little damage that shields will protect you - except maybe for specialized long range weapons like particle lances.

Space weather:
It might be interesting to introduce dynamic "weather" effects, like 'aether storms' or whatever, that could have a deleterious effect on beam combat. Maybe it'd be interesting if planetary gravity wells were hotspots of aether storms, and an outgunned fleet could seek refuge by hiding in a gas giant's orbit.

Armor:
Regenerating shields paired with armor I think accomplish the same effect as a 'pass or reject' type armor scheme, but the way armor works could be adjusted so that if a shot strikes a fully armored location, it won't do damage unless it would penetrate a certain fraction (say 25%) of the armor stack. That is, if a location is fully armored with 4 layers of armor, it will reject all strength 1 hits; if it's fully armored with 8 layers of armor, it'll reject all strength 2 hits, and so on.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 14, 2020, 02:03:03 PM
Armor:
Regenerating shields paired with armor I think accomplish the same effect as a 'pass or reject' type armor scheme, but the way armor works could be adjusted so that if a shot strikes a fully armored location, it won't do damage unless it would penetrate a certain fraction (say 25%) of the armor stack. That is, if a location is fully armored with 4 layers of armor, it will reject all strength 1 hits; if it's fully armored with 8 layers of armor, it'll reject all strength 2 hits, and so on.

This would be nice but way too strong... I would suggest a quadratic approach like...

AD = Armour Depth
R = Damage resistance

(AD*AD)-1=R

So

AD 1-3 = 0 R
AD 4-8 = 1 R
AD 9-15 = 2 R
AG 16-24 = 3 R
etc...

It would be a huge bonus to larger ships using such a mechanic though...

It would make missiles more interesting as well as you need bigger missiles to do significant damage to really though ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 14, 2020, 02:28:26 PM
is everybody sure for some reason that the beam burn-out doesn't sufficiently address the "kiting problem"?  a partial fix is distinctly preferable to an over-fix, from the standpoint of unintended consequences.
No, nobody is sure of that. We haven't had enough testing done. Steve hasn't encountered that situation in his test games. The chance is 2% for each time the weapon fires and it also requires that the ship has insufficient MSP left - otherwise the weapon will be instantly repaired and continues firing.

Its 1% now after play testing.
Title: Re: C# Aurora v0.x Suggestions
Post by: UberWaffe on January 15, 2020, 01:30:44 AM
Quote from: Alsadius link=topic=9841.  msg118117#msg118117 date=1579010548
I like the thinking here, but you need to make sure it doesn't turn into micromanagement hell.   There's real advantage in having ECM/ECCM be passive, abstracted modules, because it makes combat easier to run.   This is a fleet game, not a tactics game, so you need to be cautious about the level of detail being added to individual units. 
I envisioned these ECM modules as not being player controlled (not even sure I would give the user the option to at all). 

Missile jammer would automatically target the salvo it has the best chance of jamming that isn't already being jammed.   
Blinder modules would target an enemy ship in range with the best (known) sensors, that is not already being blinded. 
And the knife-fight ECM is closer to passive ECM, so it simply affects anything targeting the ship, it just has a slightly different rule on strength and range. 


I would want to avoid manual commands for any of these as far as feasible.
I'm more thinking along the lines of the player have more design choices for 'support' type ships and/or modules.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on January 15, 2020, 01:11:38 PM
is everybody sure for some reason that the beam burn-out doesn't sufficiently address the "kiting problem"?  a partial fix is distinctly preferable to an over-fix, from the standpoint of unintended consequences.
No, nobody is sure of that. We haven't had enough testing done. Steve hasn't encountered that situation in his test games. The chance is 2% for each time the weapon fires and it also requires that the ship has insufficient MSP left - otherwise the weapon will be instantly repaired and continues firing.
Its 1% now after play testing.
Alrighty! Could you edit the post in the Changes topic to reflect that? It's here: http://aurora2.pentarch.org/index.php?topic=8495.msg107701#msg107701

Desdinova, I don't think there's need for those big changes because we know that shields will be more powerful and weapons can now malfunction during combat. Combined with all the other changes, the kiting problem might not be a much of a problem at all.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 16, 2020, 06:15:27 PM
Another thing that  I have wanted on Aurora for a long time is a missile type that you can use similar to a MIRV but have no engines and whose missiles can be individually launched from a larger missile launcher but not part of the same salvo.

Let's say that you have 8 size 12 launchers on a ship and you then stuff them each with size 4 missiles using this feature you would be able to launch 3 salvos of 8 missiles each with a 5s gap.

Of course you could just make a MIRV that launches all missiles in one salvo if saturating an enemy is the meaning. But sometimes you actually might want to launch only a few missiles on each target such as against fighters, FAC or smaller scout ships. As these crafts most likely will become more prominent you can make your regular missile cruisers more versatile by being able to engage swarms of fighters at long range. There also can be an idea of having smaller AMM missiles stored in regular launchers as you might need larger more capable AMM, especially long range AMM or those fit with sensors such as ECCM and the like.

This could make certain missile ships more dynamic as they can carry more types of missiles. I think this could be quite and interesting game mechanic, at least something I have wanted in the game for a long time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 17, 2020, 05:06:44 AM
Alrighty! Could you edit the post in the Changes topic to reflect that? It's here: http://aurora2.pentarch.org/index.php?topic=8495.msg107701#msg107701

Done.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on January 17, 2020, 09:39:42 AM
Another thing that  I have wanted on Aurora for a long time is a missile type that you can use similar to a MIRV but have no engines and whose missiles can be individually launched from a larger missile launcher but not part of the same salvo.

Let's say that you have 8 size 12 launchers on a ship and you then stuff them each with size 4 missiles using this feature you would be able to launch 3 salvos of 8 missiles each with a 5s gap.

Of course you could just make a MIRV that launches all missiles in one salvo if saturating an enemy is the meaning. But sometimes you actually might want to launch only a few missiles on each target such as against fighters, FAC or smaller scout ships. As these crafts most likely will become more prominent you can make your regular missile cruisers more versatile by being able to engage swarms of fighters at long range. There also can be an idea of having smaller AMM missiles stored in regular launchers as you might need larger more capable AMM, especially long range AMM or those fit with sensors such as ECCM and the like.

This could make certain missile ships more dynamic as they can carry more types of missiles. I think this could be quite and interesting game mechanic, at least something I have wanted in the game for a long time.

That seems superfluous. If you have twelve launchers with three sub-missiles, you'll get the exact same result if you just launch all sub-missiles loaded in four launchers.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 17, 2020, 11:23:31 AM
Another thing that  I have wanted on Aurora for a long time is a missile type that you can use similar to a MIRV but have no engines and whose missiles can be individually launched from a larger missile launcher but not part of the same salvo.

Let's say that you have 8 size 12 launchers on a ship and you then stuff them each with size 4 missiles using this feature you would be able to launch 3 salvos of 8 missiles each with a 5s gap.

Of course you could just make a MIRV that launches all missiles in one salvo if saturating an enemy is the meaning. But sometimes you actually might want to launch only a few missiles on each target such as against fighters, FAC or smaller scout ships. As these crafts most likely will become more prominent you can make your regular missile cruisers more versatile by being able to engage swarms of fighters at long range. There also can be an idea of having smaller AMM missiles stored in regular launchers as you might need larger more capable AMM, especially long range AMM or those fit with sensors such as ECCM and the like.

This could make certain missile ships more dynamic as they can carry more types of missiles. I think this could be quite and interesting game mechanic, at least something I have wanted in the game for a long time.

That seems superfluous. If you have twelve launchers with three sub-missiles, you'll get the exact same result if you just launch all sub-missiles loaded in four launchers.

Not if you want to fire them at different targets, that was the point... let's say you have size 12 launchers and you want to stock them with 8 size 1.5 AMM missiles for example. You want to fire them individually because that is how the AMM missile logic works... you don't want to fire one size two MIRV at each incoming enemy missile, you want one missile to fire. The same is you fire against enemy fighters... you might want to fire them one or two at a time against such targets not is large bulk.

Imagine a large missile cruisers that can have a portion of their missile storage with these AMM packed missiles. You can use your missile cruisers as makeshift escort ships when you need without necessarily use smaller launchers. This also happen to be how modern ships tend to use their vertical launch systems for example.
Title: Re: C# Aurora v0.x Suggestions
Post by: Alsadius on January 17, 2020, 11:41:57 AM
That seems like a lot of coding work for a fairly small impact. Maybe in a future version, but it's certainly not a priority right now.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 17, 2020, 12:53:19 PM
That seems like a lot of coding work for a fairly small impact. Maybe in a future version, but it's certainly not a priority right now.

It is just a suggestion... the rest is up to Steve to decide what is worth what..   ;)
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on January 18, 2020, 08:21:28 AM
Easy FLAG / RACE change for spoilers.

Change the flag and race code for all spoilers in C# to look for a specific pictures in the flag and race folders instead of random ones. Currently, you can get a picture of Bears with the flag of Vietnam for Precursors for example, and since it is not possible to change them, you'll have to stare at those pictures every time you check the Foreign Intelligence window. Only workaround is to manually switch the flag & race pictures that the game picked.

In C#, it would be great if the game was looking for swarm.jpg and precursor.jpg and invader.jpg and rakshasa.jpg in RACE folder and swarm_flag.jpg and so on in the FLAG folder. This would make it very easy for players to pick whatever images they wanted for each game. The only downside is that you'd know immediately that you've encountered one of the spoilers but hey, experienced players recognize them pretty fast in any case.

Alternatively, include a button in Foreign Intelligence window to change the race and flag pictures for all known contacts.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on January 22, 2020, 12:24:55 AM
I'm sure there are quite a few people on the forum who find the concept of massive fleets built around a limited number of large, powerful warships appealing. I'm also sure there are people who like the idea of Star Trek style independent long-range cruisers for exploration and expeditionary warfare. Unfortunately, though, the size of jump drives in the game makes it all but impossible to build ships with any kind of reasonable mission tonnage at low tech levels, when the game is most fun to play. Additionally, the cost of jump drives means that you always want to take maximum advantage of their capabilities, so any expeditionary group will end up comprising at least three or four vessels of a given tonnage, with one jump warship.

This is not ideal, but a simple change can rectify this. We already have self-only jump drives in the game, so why not extend that? A new technology, for about 5,000 RP, will allow jump drives to be marked as 'self-only'. This will cut their build cost and research cost by half, and their size by a third, but only allow them to jump the ship they are mounted on. An advanced version of this tech, for 20,000 RP, will cut it to a third and a fourth, respectively. Using regular jump drives will still be cheaper and more efficient when jumping squadrons of ships, so self-only drives will be strictly inferior for smaller vessels that are built in large numbers, for whom economies of scale make dedicated jump ships viable.

Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 22, 2020, 12:42:20 AM
I don't totally agree with the jump drive thing being a serious limit insofar as I haven't ever really let that stop me from putting drives onto every military ship so they have the independent capability.  Yeah there is a cost, but for me its usually not that big of a deal.

e:  Though I'd vaguely prefer an option to build a cheaper single-ship drive that doesn't have the gang jump capability since I almost never use it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on January 22, 2020, 02:31:55 AM
I'm sure there are quite a few people on the forum who find the concept of massive fleets built around a limited number of large, powerful warships appealing. I'm also sure there are people who like the idea of Star Trek style independent long-range cruisers for exploration and expeditionary warfare. Unfortunately, though, the size of jump drives in the game makes it all but impossible to build ships with any kind of reasonable mission tonnage at low tech levels, when the game is most fun to play. Additionally, the cost of jump drives means that you always want to take maximum advantage of their capabilities, so any expeditionary group will end up comprising at least three or four vessels of a given tonnage, with one jump warship.

This is not ideal, but a simple change can rectify this. We already have self-only jump drives in the game, so why not extend that? A new technology, for about 5,000 RP, will allow jump drives to be marked as 'self-only'. This will cut their build cost and research cost by half, and their size by a third, but only allow them to jump the ship they are mounted on. An advanced version of this tech, for 20,000 RP, will cut it to a third and a fourth, respectively. Using regular jump drives will still be cheaper and more efficient when jumping squadrons of ships, so self-only drives will be strictly inferior for smaller vessels that are built in large numbers, for whom economies of scale make dedicated jump ships viable.

Just a note, if regular jump drives can jump 5 ships and self-only jump drives are 1/5 the tonnage of a regular jump drive, then they are pretty much exactly equal. Arguably slightly superior since you are splitting the tonnage among 5 ships. This isn't criticism of your idea, its just something that needs to be kept in mind when figuring out balance of the research cost of the size modifier.

The issue is, in about 50% of jumps without a gate the ship jumps alone anyway (think surveying). In 99% of jumps there is no combat on the other side of the jump and the number of ships that can jump at once is irrelevant. Frankly, I think I can count the number of jump point combat scenarios I've read about on this board on one hand. Combat jumps just aren't a significant part of the game. If self-jumps were 1/3 the size of regular jump drives, slapping one of them on each of your military ships might turn out to be the optimal route.

And if they are big enough to prevent this, they might be too big to make large, solo vessels viable. Perhaps some form of serious downside to using them in fleets? Perhaps a 'resonance' effect where each ship that jumps using a self-jump drive adds to the total jump shock time that every ship experiences? So if you jump with 1 ship, you get 10 seconds jump shock. When you jump with 10, each gets 50 seconds jump shock. When you jump with 100, each gets 30 minutes jump shock.

In fact, if you go this route, I'd make self-only drives the starting tech and have group jump a later tech you unlock.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on January 22, 2020, 04:19:05 AM

Just a note, if regular jump drives can jump 5 ships and self-only jump drives are 1/5 the tonnage of a regular jump drive, then they are pretty much exactly equal. Arguably slightly superior since you are splitting the tonnage among 5 ships. This isn't criticism of your idea, its just something that needs to be kept in mind when figuring out balance of the research cost of the size modifier.


Jump squadron size 4 is 4,000 RP [Self-Jump for 5,000 RP cuts size and cost to 1/3], and squadron size 6 is 16,000 RP [Advanced Self-Jump for 20,000 RP cuts size and cost to 1/4], so at equal tech levels, self-only jump drives will always end up being more expensive and eat up more mission tonnage than adding a ship with regular jump drives to the fleet. The actual numbers are up to Steve.


The issue is, in about 50% of jumps without a gate the ship jumps alone anyway (think surveying). In 99% of jumps there is no combat on the other side of the jump and the number of ships that can jump at once is irrelevant. Frankly, I think I can count the number of jump point combat scenarios I've read about on this board on one hand. Combat jumps just aren't a significant part of the game. If self-jumps were 1/3 the size of regular jump drives, slapping one of them on each of your military ships might turn out to be the optimal route.


I do believe the C# AI will be a bit more intelligent about exploiting jump points for defence. I think Steve lost a battlefleet to the Swarm after making a combat jump in his current Crusade campaign? In terms of player versus player games, though, jump point combat will always be a very important consideration since they provide a ridiculous defensive advantage.

In any circumstance, only survey vessels are likely to transit alone. Slapping jump drives on all military vessels would be a net loss in terms of capability, since dedicated jump vessels would end up being cheaper.


And if they are big enough to prevent this, they might be too big to make large, solo vessels viable. Perhaps some form of serious downside to using them in fleets? Perhaps a 'resonance' effect where each ship that jumps using a self-jump drive adds to the total jump shock time that every ship experiences? So if you jump with 1 ship, you get 10 seconds jump shock. When you jump with 10, each gets 50 seconds jump shock. When you jump with 100, each gets 30 minutes jump shock.

In fact, if you go this route, I'd make self-only drives the starting tech and have group jump a later tech you unlock.

That's an interesting idea, but it also feels like it's a bit more involved than the original proposal. Steve's targeted release date is only two months away.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 22, 2020, 05:55:04 AM
Personally, I think this is one of those areas where you should use SpacceMaster to customize your game.

If you want a universe where every ship larger than a TIE fighter can "make the jump to Hyper" without spending one-third of their displacement on a special engine, then use SM to give your empire max jump drive efficiency tech.  That's a 1-20 ratio instead of a 1-3, if memory serves?  I would think your fleet could afford 5% of its hull spaces.
Title: Re: C# Aurora v0.x Suggestions
Post by: lupin-de-mid on January 22, 2020, 07:51:48 AM
Personally, I think this is one of those areas where you should use SpacceMaster to customize your game.
But it's impossible to customzie NPR
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 22, 2020, 08:26:18 AM
Personally, I think this is one of those areas where you should use SpacceMaster to customize your game.
But it's impossible to customzie NPR

That's OK, the NPRs don't currently have any code that would cause them to build self-only jump drives.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on January 22, 2020, 09:25:19 AM
Personally, I think this is one of those areas where you should use SpacceMaster to customize your game.

If you want a universe where every ship larger than a TIE fighter can "make the jump to Hyper" without spending one-third of their displacement on a special engine, then use SM to give your empire max jump drive efficiency tech.  That's a 1-20 ratio instead of a 1-3, if memory serves?  I would think your fleet could afford 5% of its hull spaces.

Your opinion is appreciated, but that's not very helpful. Using SM mode to give all races max tech beam weapon range modifiers and fire control ranges is also a valid solution to the beam kiting problem, but it's not a very good one. The normal tech progression is a good thing to have.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 22, 2020, 11:51:06 AM
I could also see individual jump drives being a ruins only tech or similar, like compressed fuel tanks.
Title: Re: C# Aurora v0.x Suggestions
Post by: ReviewDude01 on January 22, 2020, 05:50:34 PM
Reply to Kiting problem and engine boosts afterburners with highligting Steve: Aurora is operational level of game and I try to evade as much coding and micromanagement as possible:

My solutions - ideally all of this solutions should be implemented into the game mixing them:

1. Gravitational Survey Vessels are Gravitational Stabilization Vessels and most system contains Wormholes where ships can jump to different locations in system, mixing "hyperdrive" context into combat.

Wormholes are discovered via EM sensors and Grav Stabilization vessel only stabilize wormholes.
Jumping thru unstabilized wormhole for an empire has a high chance of inflicting bad things from ship damage to ship incapacitated to jumping to a random point in system, all sorts of solutions are possible.

2.  All squadrons would require Degree (2D 0-360 degrees) variable in code. And one constant degree variable for example 30 degrees for determining engine emission blocks clear targeting.
It is based on following : engines emit something. They leave something in space and it can obfuscate targeting, is a similar thing as smoke from exhausts in 2 WW or 1 WW era.  Ships facing away from enemy would have hit chance lowered. Same for PD - point defence. So ships attemping to kite would be penalized. Unless they would choose some other degree than directly away from enemy (+- 15 degrees if we set global variable to 30 degrees, numbers are examples.) These ships could also have greater heat and EM signature only for ships targeting them from this angle. This would be ultimate solution for penalizing kiting. Players could still attempt to kite but with some offset as they would try to avoid to place enemies at this angle meaning that kiting would be less useful.

Bonus: ships taking hits from weapons from these angles could also have a chance to armor ignored. As engines usually have no armor.

3B. This is not a solution but I would like to see this in game: Implementing my former Engine Boost or "afterburner " idea is certainly not an easy task to do it properly but it could be done as following:
Military ships can have 2 types of engines. There is a checkbox for secondary type of engines autouse and turn off at % percentage below. It could lead to military designs having speed of X (1337 km/s) while having (8000 km/s with duration of 2 hours, idea is that smaller military AI ships would use greater speeds with less endurance fighters 10 minutes , destroyers 2 hours larger can be also 1 day  , exact numbers are examples only. AI and player squadrons would simply turn on these secondary engines every combat. This would implement endurance aspect into kiting combat.

In this case: beam energy weapons should use fuel same way as shields do.

Edit: 2. engine exhaust obfuscating targeting would obviously need some time to run off to avoid micro
1. wormholes would be stabilized per empire

reply to engine tuning/ other tuning/ is the same thing as not engine tuning but with more micro: no it is not as long as it has reasonable costs in terms of minerals/fuel/ship damage/timed ship inaccuracy penalty or some other penalty/ tonnage (not tech), in this case it is a design choice and voluntary choice for players.  Regarding micro: it can be auto turned on at the start of combat or when first ship takes first hit etc. - based on player and/or AI choice   Boost will always benefit the side which is running away since it can reach a wormhole faster. in case that both sides have boost it should be balanced so that the weaker side get more so it  lowers the difference thereby tech difference thereby weapon range difference.

Edit 2 (my final word on these topics) - aka. super simple and ultimate solution to run away button = run away button.
All squadron uses emergency jump hopefully warping to home system. Delayed, highly damaging to fleet to the point where 50% of fleet can be destroyed. Destruction and delay based on squadron jump drives tonnage + efficiency compared to total fleet tonnage.
Can be based on distance from home system. More distance is more dangerous. AI would use when fleet is taking damage for long time but dealing 0 damage to enemy for prolonged time.
Title: Re: C# Aurora v0.x Suggestions
Post by: amschnei on January 22, 2020, 07:33:52 PM
It might be nice to have the new early game tech have proper names, rather than “improved X tech”

For the engines you could use fission and fusion for the “lower” and “upper” tech respectively:

Fission Thermal Engine
Fusion Thermal Engine
Fission Pulse Engine
Fusion Pulse Engine

Something similar could be done for the reactors, though I can’t think of something right now.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on January 23, 2020, 02:53:26 AM
It might be nice to have the new early game tech have proper names, rather than “improved X tech”

For the engines you could use fission and fusion for the “lower” and “upper” tech respectively:

Fission Thermal Engine
Fusion Thermal Engine
Fission Pulse Engine
Fusion Pulse Engine

Something similar could be done for the reactors, though I can’t think of something right now.

If you want proper names then "fusion" IMO should be avoided since stellarator, tokamak + confinement further down the tree all are different types of fusion engine powerplants.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 23, 2020, 02:54:03 AM
I'm open to suggestion on the new engine names.
Title: Re: C# Aurora v0.x Suggestions
Post by: dukea42 on January 23, 2020, 07:29:08 AM
How about just "Engine Power X".   We already get to name them when designed. It has always seemed, out of character for lack of a better term, that there was newtonian sounding engine names.

Do TN engines even need to have a thruster?

It seems like this is the one place in the game trying to label instead of spec the technology.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on January 23, 2020, 08:40:48 AM
It might be nice to have the new early game tech have proper names, rather than “improved X tech”

For the engines you could use fission and fusion for the “lower” and “upper” tech respectively:

Fission Thermal Engine
Fusion Thermal Engine
Fission Pulse Engine
Fusion Pulse Engine

Something similar could be done for the reactors, though I can’t think of something right now.

No.

Because fission and fusion are vastly different ways of handling nuclear reaction based energy production with very different traits. You could build a fusion thermal engine, but it'd basically be a fission thermal engine with a different heat source plugged into the system that's a lot more fiddly to keep working. A nuclear pulse engine would be using a fission-fusion-fission bomb as its power source (look up the Orion Nuclear Pulse Drive) because if you can build fusion bombs the greater efficiency per unit of mass/fuel only makes sense.
Title: Re: C# Aurora v0.x Suggestions
Post by: amschnei on January 23, 2020, 10:10:16 AM
I’ve not read enough hard sci-fi to say what would be a “reasonable” tech progression (insofar as a sci-fi world based on materials which are named for the fact that they defy the laws of physics can be construed as reasonable).  My main point was just that having a handful of techs called “improved whatever” and all the others have unique flavor names looked a little odd.  I don’t care what the names are, exactly.  And even if it stays as in it’s hardly a big deal, it just seems an easy change to increase the immersion.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 23, 2020, 10:20:38 AM
I’ve not read enough hard sci-fi to say what would be a “reasonable” tech progression (insofar as a sci-fi world based on materials which are named for the fact that they defy the laws of physics can be construed as reasonable).  My main point was just that having a handful of techs called “improved whatever” and all the others have unique flavor names looked a little odd.  I don’t care what the names are, exactly.  And even if it stays as in it’s hardly a big deal, it just seems an easy change to increase the immersion.

Yes, I understand. There are different types of nuclear thermal (Solid core, liquid core, gas core), so I could use those three and move nuclear pulse to what is now improved nuclear pulse.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 23, 2020, 11:49:29 AM
Well, engines don't have to just have real theoretical propulsion names, since we've got the lore of TNE to work with.

Maybe the first (1000 RP) engine should be something like Sorium-Catalyzed Rocket Engine? Basically "we found magic space rocks, let's throw some in our chemical thrusters."

On the theoretical real world engine front, I've always liked the idea of Antimatter Catalyzed Nuclear rockets (https://en.wikipedia.org/wiki/Antimatter-catalyzed_nuclear_pulse_propulsion). They'd probably be pretty high up the tree, though, so using them as a new engine there would mean re-adjusting the other engine names downward, which might throw veteran players off.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 23, 2020, 12:08:51 PM
I allays imagined engines to be very different from the ones operating in normal space, so nothing like a thruster at all.

Since they don't seem to convey any sort of G force on ships and they have no acceleration they operate on a very different level. I always imagined them acting more like an Alcubierre drive type of principle and interacting with the ether in a way that is hard to describe in scientific terms.

The names of the drives could be very different and definitely have more of Trans Newtonian theme... they certainly are not going to operate with Anti-matter, or Ion, Fusion or the like as they use Sorium fuel and the engine itself is something completely different.
Title: Re: C# Aurora v0.x Suggestions
Post by: Ranged66 on January 23, 2020, 12:57:24 PM
(https://i.gyazo.com/e26438b92f57f5b65e9bf1bc60d7c49e.png)

Suggestion for new engine/reactor naming!

Ignore the typo at Liquid Sorium Engine Technology  :/
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on January 23, 2020, 01:07:24 PM
I think the generic xx Engine Power per HS would allow us a bit more leeway to RP. On a side note, would it be possible for players to rename non-racial technologies?
Title: Re: C# Aurora v0.x Suggestions
Post by: Bluebreaker on January 23, 2020, 03:13:24 PM
Will there be any change to the mineral cost of components, particularly engines? I always felt that by the time you got into fusion techs, gallicite cost of engines and missiles get out of control really fast.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 23, 2020, 05:40:11 PM
For me X power engines would be less enjoyable than having names for it.  If the tech isn't meant to refer to anything in particular then the basis of comparison is harder because someone could say 'this is an ion drive' and then someone else say that it's just an incrementally better chemical rocket or something and the fluff explanation of what's going on there subsequently means nothing.
Title: Re: C# Aurora v0.x Suggestions
Post by: ExChairman on January 25, 2020, 12:23:20 PM
Ship fatigue: With my latest campaign I have ships that are up to 50 years old, starting as a frigate of around 5000 tons, now 10-12 000 ton destroyers. Somehow there should be a penalty for "long lived" ships
Title: Re: C# Aurora v0.x Suggestions
Post by: mtm84 on January 25, 2020, 12:42:36 PM
Ship fatigue: With my latest campaign I have ships that are up to 50 years old, starting as a frigate of around 5000 tons, now 10-12 000 ton destroyers. Somehow there should be a penalty for "long lived" ships

I think if you are spending that much resources into maintaining/refitting a ship, you would have essentially replaced all the original parts with new ones over its lifetime anyways.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on January 25, 2020, 12:45:40 PM
Ship fatigue: With my latest campaign I have ships that are up to 50 years old, starting as a frigate of around 5000 tons, now 10-12 000 ton destroyers. Somehow there should be a penalty for "long lived" ships

I think I like the idea of increasing costs of maintaining ships based on age.  Say 10% increase up to a max of 50% per 10 years over 50 years...or perhaps 1% increase every time the ship is overhauled. I don't feel like I need this change and would be completely fine without it, but I would also welcome something like it if introduced.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 25, 2020, 12:56:58 PM
It might be reasonable if you look at it as 'spaceframe fatigue', fighter jets at least have a concept of 'airframe fatigue' where the superstructure of the aircraft itself is so worn out that there isn't really a way to fix the thing without effectively building a totally new aircraft.  Maybe aurora could have something along those lines.  Really old ships just start experiencing major structural failures (maybe past a certain point of time a slow-burning exponential growth of maintenance failure on its components, say over the course of 5-10 years) unless you do some kind of complete re-build of the ship at a shipyard.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on January 25, 2020, 02:03:42 PM
It might be reasonable if you look at it as 'spaceframe fatigue', fighter jets at least have a concept of 'airframe fatigue' where the superstructure of the aircraft itself is so worn out that there isn't really a way to fix the thing without effectively building a totally new aircraft.  Maybe aurora could have something along those lines.  Really old ships just start experiencing major structural failures (maybe past a certain point of time a slow-burning exponential growth of maintenance failure on its components, say over the course of 5-10 years) unless you do some kind of complete re-build of the ship at a shipyard.

What do you think an overhaul is for? Given how much time it takes it's pretty much stripping the ship down as much as possible, checking everything and then putting it back again.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 25, 2020, 04:48:36 PM
Generally that type of overhaul is not actually replacing the superstructure.
Title: Re: C# Aurora v0.x Suggestions
Post by: ExChairman on January 26, 2020, 12:45:19 AM
Overhaul is one thing but rebuilding ships is another matter, in a overhaul you repair/replaces older equipments and a lot of paint. Yea I know its a bit harder than that... ;)
Depending on the shipclass it takes more or less time.
But rebuilding a ship does usually create problems, at least waterbased. But its usually, a lot faster to rebuild a old ship than building one from scratch or there might be problems with shipyard space or its needed for some small task while being rebuilt... Or another explanation...
I have rebuilt my frigates from around 5000 tons to 11000 tons destroyers but in 4 different stages, so its been relative fast and minor builds each time.
But in a "real" world there would be problems with those ships, one way or the other.

I love the starfire way of giving a military engine a possible "burn out" when going full speed in a strategic redeployment, were a commercial engine is slower but built for a steady boost.
Jumping throe a wormhole would also do some wear and tear, I presume at least, this could be decreased with a  jump gate, tuned into the wormhole stresses, or something...
Title: Re: C# Aurora v0.x Suggestions
Post by: serger on January 26, 2020, 03:45:38 AM
I understand entirely those of us, who will prefer strongly to have some reference-names for engine techs. That's space SF, that's cool! Moreover, I'd prefer to have ALL techs having some reference-names, not only branch-and-number names. But we have no such names for nigh-anything (except engines and laser wavelengths), and those we have - are artifacts, those does not correspond well with all other TN narrative.

The last of my VB campaigns, I had DB password and use it to change all tech names to smth like "*-Q smth" (tier numbers in the place of asterisk). Made quiet RP explanations of quantity of layers of some layered TN-composite materials, needed to build corresponding tech, and it was coherent enough to play and believe in it, to have a WORLD in my head. It was, really, a job of work to rename all those DB records coherently, having such a vague notion about game code and no game experience with late tiers mechanics, but it really was fun to play with this name scheme in the upshot.

So, I think it will be close to ideal to have basic branch-tier tech names, and to have reference-name schemes (and some default scheme with current power-and-propultion tech names), with some player interface to create your own name-scheme for techs, the same as for ships and ground units. It can be also a way co contribute in Aurora for us, uploading our schemes to compare and integrate at next release.

P.S. Sorry for my clumsy English, I hope it's still comprehensible in outline.
Title: Re: C# Aurora v0.x Suggestions
Post by: Razgriz on January 26, 2020, 10:55:30 PM
What do you guys think about Keel/Spinal mount railguns? :)

Or better yet internally mounted?  ;D Essentially a ship built around a gun.  Inspired from The Expanse and Halo (Internal mount MAC cannon or Gauss)

The Rocinante has a spinal mount Railgun and the Amun-Ra stealth frigate has an internally mounted gun.

It would give three levels for all weapons Standard hull/turret mounted guns, larger spinal mounted guns and huge Internally  mounted weapons

Just some thoughts, thanks.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on January 27, 2020, 01:55:16 AM
I thought spine mounted and internally-mounted were the same thing? The only difference is exactly how much ship you have that is not gun. They are functionally the same, after all. No turret, bigger than normal.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on January 27, 2020, 02:02:31 AM
I thought spine mounted and internally-mounted were the same thing? The only difference is exactly how much ship you have that is not gun. They are functionally the same, after all. No turret, bigger than normal.

Technically the difference I think is that you can have several internally mounted guns, but only one spinal.

In fact any weapons in Aurora including turrets could be argued to be treated as internal from a game mechanics standpoint since they are protected by your armor.

I would love to be able to make some sort of spinal railgun or more types of spinal weapons overall, and also would love to be able to put more weapons in turrets ( even if you disable speeding them up for balancing, but just for RP/extra armor purposes ) :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on January 27, 2020, 09:37:15 AM
We already have Spinal and Advanced Spinal for lasers. For Particle Beams, we have Particle Lance. Plasma Carronade doesn't need it as it already starts at big and is even cheaper in C#. Gauss is meant for PD and fighters. So that only leaves Rail gun - which shouldn't be turreted because then Gauss loses 90% of its reason to exist since turreted RG will then be almost always superior to GG in PD role. Spinal mount for RG would thus be the other option and, in fact, it would balance Laser out. Because if you don't have any EW scientists or you want to stick with MK field for RP reasons, you don't have any "big guns" except for making missiles with ultra-short ranges and pretending they are gigantic cannon shells or something.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 27, 2020, 09:37:37 AM
In respond to ship fatigue I think that it would be sound to make it so that the chance of breakdown a ship will get increases over time... let's say +1% per year. Every time you refit the ship you might reduce this penalty by a certain amount depending on how extensive the refit is... but you will never be able to eliminate the problem and after about 50-70 years you will get too frequent malfunctions that you will need to scrap the ship.

I also think it would be good if a ship could only be refitted to be say 20% less or 25% more than its original weight as well as a hard limit to how a ship can be refitted over time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Alsadius on January 27, 2020, 10:05:56 AM
Given that this is a more roleplay-heavy game than a competitive one, I'm not sure if the ship fatigue thing needs to exist. There's a lot of fiction out there where ridiculously old ships still see use(Battletech comes to mind). Heck, even in the real world, there's wet-navy ships over a century old that are still in active use(one over 200 years old and still sailing (https://en.wikipedia.org/wiki/USS_Constitution),  one from the Kaiser's navy of WW1 which has also been sunken and re-floated (https://en.wikipedia.org/wiki/MV_Liemba), and one over a century old and still in use for its original purpose (https://en.wikipedia.org/wiki/Russian_salvage_ship_Kommuna) come to mind), and salt water is generally far nastier than vacuum.
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on January 27, 2020, 12:25:33 PM
There's also the gameplay concern that NPRs don't have maintenance.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 27, 2020, 11:41:40 PM
I mean, on the flip side, the ships in aurora are maneuvering in pretty insane ways compared to ships.  You could reasonably argue that might inflict wear and tear more comparable to what fighter jets have to deal with.  I think its a good point that wet navy ships can potentially be usable for a really long time though.  The Volkhov there being a particularly good example.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 28, 2020, 02:29:42 AM
Given that this is a more roleplay-heavy game than a competitive one, I'm not sure if the ship fatigue thing needs to exist. There's a lot of fiction out there where ridiculously old ships still see use(Battletech comes to mind). Heck, even in the real world, there's wet-navy ships over a century old that are still in active use(one over 200 years old and still sailing (https://en.wikipedia.org/wiki/USS_Constitution),  one from the Kaiser's navy of WW1 which has also been sunken and re-floated (https://en.wikipedia.org/wiki/MV_Liemba), and one over a century old and still in use for its original purpose (https://en.wikipedia.org/wiki/Russian_salvage_ship_Kommuna) come to mind), and salt water is generally far nastier than vacuum.

There is a very big differences between a ship and a ship and what they are used for... sure... it is possible to run ships for hundreds of years if they are maintained well enough... pure warships are another thing though as some component of ships simply can't be modernised enough over time and the cost of running them becomes progressively more expensive. Most combat ships simply have too much wear and tear to last more than about 50 years or so, most of those reason have little to do with salt water and corrosion damage which can be fixed through proper maintenance.

I suggested a soft cap... you could run a ship for hundreds of years you just can't run them for very long before they need maintenance at that time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on January 28, 2020, 08:17:35 AM
What problem is this trying to fix that the game has? If you leave a ship without refitting it to a new class for a hundred years, what you have is a very useless ship puttering about. If you constantly refit it into whole new ships over time, you are going to regularly get notified about refits in excess of the cost of a new ship, which always felt to me like you started passing the point where you are replacing whole superstructure and other such things.

Much like how we have 200 year old sailing ships floating around, but if you took one of those and wanted to refit a nuclear reactor and vertical launch systems onto it, your going to pay more than the cost to just build one from scratch, and have to build an entirely new superstructure to support these modern parts.

I also don't want this stepping on my roleplaying. I've regularly played feudal style multi empire games, and its fairly common for a couple of 'pride of' style ships to end up going through many times their normal refit costs just to be a continuation of a legacy starship for nobility or the like. I don't want them doing so only to be told "but it'll break down every two weeks and you can't fix that" even when dropping 150% the price of a new ship on overhauls, and RPing it as the ship being essentially the answer to the ship of Theseus problem. I could just build a new ship with the same name, but then the history is lost, along with the point.
Title: Re: C# Aurora v0.x Suggestions
Post by: DEEPenergy on January 28, 2020, 05:08:44 PM
Hey Steve, any chance for forced deportations or evacuations of aliens whos systems you conquer? In case you just want the system, not the alien population. Could be worked into treaties as well, where one side demands the other remove a colony in X amount of time.
Title: Re: C# Aurora v0.x Suggestions
Post by: DFNewb on January 28, 2020, 05:13:11 PM
Has the beam fighters having a hard time hitting things slower than them with very close range weapons depending on target speed and your fire control range or weapon range?

I recently had a problem with my 7km speed fighters not being able to hit a moving 5km ship.  I later changed them with longer ranged weapons and they could but makes no sense that the faster ships couldn't get in range. . .
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 28, 2020, 05:15:11 PM
Hey Steve, any chance for forced deportations or evacuations of aliens whos systems you conquer? In case you just want the system, not the alien population. Could be worked into treaties as well, where one side demands the other remove a colony in X amount of time.

I guess you could transport the aliens to a new system and then transfer the colony to the NPR. I looked at the AI removing colonies when I coded the latest Diplomacy update and it was tricky to make it work with all the potential factors involved - what if there was no direct route back NPR space for example? That's why I went for transferring the populations. There is some precedent for that on Earth. Countries agree border changes and towns and cities end up in a different country.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on January 28, 2020, 05:57:39 PM
Hey Steve, any chance for forced deportations or evacuations of aliens whos systems you conquer? In case you just want the system, not the alien population. Could be worked into treaties as well, where one side demands the other remove a colony in X amount of time.

I guess you could transport the aliens to a new system and then transfer the colony to the NPR. I looked at the AI removing colonies when I coded the latest Diplomacy update and it was tricky to make it work with all the potential factors involved - what if there was no direct route back NPR space for example? That's why I went for transferring the populations. There is some precedent for that on Earth. Countries agree border changes and towns and cities end up in a different country.

I also think it would make for an interesting synergy with the ground game. Okay you know just forced the NPR fleet out of the system without firing a shot but their former colony of 25m isn't happy with the new management and now you're going to have to garrison that world.  I don't know if Steve has coded revolts, uprisings, declaring independence yet (it was mentioned in the wiki), but if so you might have just inherited a big problem in your borders.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 28, 2020, 06:10:11 PM
I guess you could transport the aliens to a new system and then transfer the colony to the NPR. I looked at the AI removing colonies when I coded the latest Diplomacy update and it was tricky to make it work with all the potential factors involved - what if there was no direct route back NPR space for example? That's why I went for transferring the populations. There is some precedent for that on Earth. Countries agree border changes and towns and cities end up in a different country.

I also think it would make for an interesting synergy with the ground game. Okay you know just forced the NPR fleet out of the system without firing a shot but their former colony of 25m isn't happy with the new management and now you're going to have to garrison that world.  I don't know if Steve has coded revolts, uprisings, declaring independence yet (it was mentioned in the wiki), but if so you might have just inherited a big problem in your borders.

Not yet, but the new ground combat system lends itself well to spawning insurgent forces.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on January 28, 2020, 08:38:28 PM
Insurgent forces would be good and would force the decision, 'I'm in a shooting war with an NPR and need my best ground forces at the front but I now have this insurgent problem.  Do I keep high capability ground units back to deal with it and take risk at the front?  Do I have purpose built counter-insurgent formations hunting these guys down?  As I occupy more systems, do I need more of these forces but do they come at the expense of my front line warfighters?'  For little additional coding effort (I think), it could really add some REALLY interesting strategic/operational decisions.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on January 29, 2020, 05:13:32 AM
With the C# habitat changes, orbital habitats become viable alternatives to infrastructure when the colony cost exceeds about 6.0. However, since LG infrastructure costs thrice as much as regular infrastructure, housing population on habitats always ends up being cheaper than using LG infrastructure when the colony cost exceeds 2.0. This is somewhat problematic, since a large majority of near habitable worlds are colony cost 2.0 or thereabouts, due to oxygen pressure requirements. Add in the fact that habitats do not need a larger environment sector population, and LG infrastructure becomes almost useless in comparison

Can the cost of LG infrastructure be lowered to 4.0 BP to make it at least somewhat competitive?
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on January 29, 2020, 08:32:22 AM
Has the beam fighters having a hard time hitting things slower than them with very close range weapons depending on target speed and your fire control range or weapon range?

I recently had a problem with my 7km speed fighters not being able to hit a moving 5km ship.  I later changed them with longer ranged weapons and they could but makes no sense that the faster ships couldn't get in range. . .
This is an issue with Initiative and how new players do not understand how it works. It is a little counter-intuitive. Steve has changed the initiative system for C# a little bit: http://aurora2.pentarch.org/index.php?topic=8495.msg97342;topicseen#msg97342

The detailed answer to your issue was given in the Bugs thread and you should read that as the underlying mechanics do not change.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 29, 2020, 08:41:12 AM
What problem is this trying to fix that the game has? If you leave a ship without refitting it to a new class for a hundred years, what you have is a very useless ship puttering about. If you constantly refit it into whole new ships over time, you are going to regularly get notified about refits in excess of the cost of a new ship, which always felt to me like you started passing the point where you are replacing whole superstructure and other such things.

Much like how we have 200 year old sailing ships floating around, but if you took one of those and wanted to refit a nuclear reactor and vertical launch systems onto it, your going to pay more than the cost to just build one from scratch, and have to build an entirely new superstructure to support these modern parts.

I also don't want this stepping on my roleplaying. I've regularly played feudal style multi empire games, and its fairly common for a couple of 'pride of' style ships to end up going through many times their normal refit costs just to be a continuation of a legacy starship for nobility or the like. I don't want them doing so only to be told "but it'll break down every two weeks and you can't fix that" even when dropping 150% the price of a new ship on overhauls, and RPing it as the ship being essentially the answer to the ship of Theseus problem. I could just build a new ship with the same name, but then the history is lost, along with the point.

I would not worry about the role-play aspect as you could always put in some extra engineering modules to still make a 150 year old ship work reasonably well for that purpose. I think role-play in this context is a relatively weak argument as you could say that to just about every mechanic that poses some form of restriction in the game. Soon we are down to imagining everything in our heads using that argument...  ;)

I think it is important that we can imagine all sort of role-playing environments, so don't get me wrong here...

I still think it is a good idea to somehow force older ships to eventually need to be scraped because of excessive overhaul and refit costs. It is fairly easy to design ships with the intention of continually being able to afford refitting them indefinitely as you do so incrementally over time for very low costs. You can even increase the size of ships just a tiny bit every time so a 9000t ship ends up a 16000t ship after a 100years of continual incremental refit projects.

Now... you don't HAVE to do this as YOU decide if this kind of mechanic should be exploited in this way or not, you also could just scrap old ships and ROLEPLAY it is no longer worth to refit them even if mechanically they still are. I just would like to have a system where I need to deal with the fact that time and usage of (especially military) ships will have unusually high wear and tear as they are built for high stress use and so are also put under allot of stress, even during training exercises. It will ultimately force long term logistical and economical decision makings that is interesting to deal with.


Another thing is experience... as the game really don't model crew rotation and ships need to continually be under training over time it becomes a bit immersion breaking when a ship can retain its high experience and fleet training levels over many centuries with little effort. Perhaps some form of degrading of experience and fleet training over time would be nice as well as ship crews would need to be replace over time as well depending on the service length of the crew which then would effect experience and fleet training levels. You should not have to bother about this logistically... just that depending on your crew service policy ship will need a certain amount of crew and each year the ship would drain your crew pool as old and new crew are rotated from the ship, new and old crew swap places when the ship is at port due to deployment recovery. Only crew from the academies are obviously drained this way and commercial ships should not be able to use academy crews at all anymore if this was implemented.

This would produce some interesting ways that you deal with ship deployment that makes it allot more realistic. It would be very difficult to have ships with many years of deployment without making them VERY expensive in terms of crew cost.

Let's then assume that crew available is more a crew pool in the form of points and not actual numbers. Each ship will then have a service length and a deployment value. Your empire will also have a general service length of crew which are the general level of service length your crew are expected to serve on ship in each term. A ship could never have a deployment longer than its individual service length.

Now each ship that deviate from the empires general service length would have to pay more or less crew points to refill either lost crew or simply to replace them over time. If you lower the service length on the individual length it will require slightly less crew points but more then if the empire general level was reduced to that level. If a ships general service length is higher you will have to spend considerably more crew points to replace crew.

Now... for the more interesting things that also is very realistic. The more incrementally you replace the crew the more they are able to retain their skill and training. Let's say you have an empire wide service requirement of 24 month and a ship with a 6 months deployment rating you will need to replace 25% of the crew after that 6 month is up (abstraction of how it would work in the long term). Now, if the same ship instead had a 12 month deployment rating you would need to replace 50% of it crew after those 12 months in space. In the first case the ship might loose say 9% of its experience and in the second it might loose 25% of its experience (subject to balancing). The reason being that if a ship have more experienced crew they can more easily train the new crew to the higher standard. If you replace all crew you are down to the base experience level and so lost 100% of the ships experience. This also goes for fleet training levels.

This wold make deployment time and actual use of ships even more engaging as the longer they spend in space the more those ship loose in experience once they replace a larger portion of its crew. Obviously the max deployment rate of ships is not the major factor for this, it should always be the actual deployment of the ship, not the max possible. So you can still have a 12 month potential deployment of a ship but rarely use it all to retain experience and fleet training levels better.

Such rules would also put a higher emphasis on a highly skilled base crew or one that you train up with a long service time to retain the skill of the crew easier... sort of quality over quantity strategies.

Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 29, 2020, 11:32:52 AM
With the C# habitat changes, orbital habitats become viable alternatives to infrastructure when the colony cost exceeds about 6.0. However, since LG infrastructure costs thrice as much as regular infrastructure, housing population on habitats always ends up being cheaper than using LG infrastructure when the colony cost exceeds 2.0. This is somewhat problematic, since a large majority of near habitable worlds are colony cost 2.0 or thereabouts, due to oxygen pressure requirements. Add in the fact that habitats do not need a larger environment sector population, and LG infrastructure becomes almost useless in comparison

Can the cost of LG infrastructure be lowered to 4.0 BP to make it at least somewhat competitive?

Yes, that is a good point - I've changed it as suggested.
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on January 29, 2020, 01:09:17 PM
Jorgen, if the goal is to discourage still using and refitting century-old ships, why don't we just do exactly that. Add a modifying to the cost of refitting a ship based on its age, rather than a constantly ticking malus on deployment time. A refit on a 5 or 10 year old ship wouldn't be much affected, a 30 year old ship would be getting pretty expensive, and a 100 year old ship would be exorbinant to refit, but once its refit, then it performs as expected. If you leave a ship 30 years out of date, its been overhauled and maintained this entire time so much like our 200 year old sailing ships, you can still take them out and they'll perform as well as back then. That old performance will just be terrible. As long as refitting the ship doesn't reset this 'service life' tracker, then it should work fine.

This preserves the best of both worlds of allowing these sorts of poor decisions to be made on player RP, while building a mechanic that discourages gaming the refit system forever. I'm still not convinced its needed, but at least this is adding a modifying to a players choice, instead of just chipping away at their options by drawing arbitrary limits. And I'm pretty sure service life of a ship is a pretty easy check to look at when refitting.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 29, 2020, 06:02:13 PM
I still think it is a good idea to somehow force older ships to eventually need to be scraped. . .

I don't.  I think it's a terrible idea.  I completely disagree with the proposal to limit my fun.

As Jorgen_CAB pointed out, no one is forcing you to use centuries-old ships, or to continually refit them to be larger and larger.  So don't do it.  But don't take away MY ability to do so just because YOU think it's unrealistic.  Don't cripple MY ships' crews' experience just because YOU imagine one-quarter of them being replaced at once.  That's not how my empire works.

Aurora has never been realistic.  Internally consistent, yes, but never realistic.  We literally threw out Newton's Laws when we started.  There is no "realistic" in our imaginary futures, only "appropriate for our fiction" and "NOT appropriate for our fiction."

My empire (this week) consists of slow-growing, incredibly long-lived tree people who build their spaceships out of 'wood' and sail on solar winds captured in gossamer-thin electron sails rigged all around their nigh-spherical hulls.  Our semi-living ships are expected to last centuries, increasing in size the entire time, and our crew turnover is basically nil.

Your proposals are totally "unrealistic"
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on January 29, 2020, 06:44:45 PM
I don't plan to add any restrictions on older ships. Partly this is because older ships with a long history make for great story telling, so I don't want to damage that potential, and partly because I don't think ships becoming harder to refit or overhaul after decades in service is adding any meaningful game decision. It is likely to be frustrating more than challenging.

There is nothing to stop anyone adding their own role play elements to avoid using older ships.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 29, 2020, 07:28:54 PM
I still think it is a good idea to somehow force older ships to eventually need to be scraped. . .

I don't.  I think it's a terrible idea.  I completely disagree with the proposal to limit my fun.

As Jorgen_CAB pointed out, no one is forcing you to use centuries-old ships, or to continually refit them to be larger and larger.  So don't do it.  But don't take away MY ability to do so just because YOU think it's unrealistic.  Don't cripple MY ships' crews' experience just because YOU imagine one-quarter of them being replaced at once.  That's not how my empire works.

Aurora has never been realistic.  Internally consistent, yes, but never realistic.  We literally threw out Newton's Laws when we started.  There is no "realistic" in our imaginary futures, only "appropriate for our fiction" and "NOT appropriate for our fiction."

My empire (this week) consists of slow-growing, incredibly long-lived tree people who build their spaceships out of 'wood' and sail on solar winds captured in gossamer-thin electron sails rigged all around their nigh-spherical hulls.  Our semi-living ships are expected to last centuries, increasing in size the entire time, and our crew turnover is basically nil.

Your proposals are totally "unrealistic"

As I also said before.. you can say that about ANY mechanic in the game... eventually you are just laying in bed dreaming...  ;)

Anyway... I think that having ships require crew over time and experience trickle down over time if you don't retrain the ships would add to decision making. As max fleet training completely remove the penalty for giving order I feel that it should be very difficult to have large part of a fleet at 100% fleet training.

Realistic crew training could be something you use in the same way that realistic maintenance is used... as an option for more realistic experience and training simulation. If implemented roughly as I outlined it would be more or less automated and you would have to train the ships more, that is it. But you would have to make a bit harder design decisions.
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on January 29, 2020, 10:28:25 PM
How does a system that just mandates "slightly more training" introduce any meaningful decision into the game though. Father Tim put it well when he said that Aurora isn't about realism. As far as I can glean from Steve's messages, Aurora is about interesting Strategic decisions, and the tactical combat is the consequence of the strategic decisions playing out. I don't see how crew turnover provides any sort of interesting strategic decision, and I don't see how having my crews forget their training introduces any interesting strategic or build decisions. In almost all my empires, its pretty well set that the crews are performing normal drills and such while they're stationed, they're not just playing poker. They're beating their FNG's into shape, whole task group training just accelerates it by coordinating the training.

Changes that turn the decisions into flat "You must X" scenarios on a clock don't do anything other than introduce busywork. Stuff like the Sensor changes we're getting do introduce meaningful change, as the performance alterations adjust what sort of doctrines you may use for vision. The changes to fighters to allow them to be maintained and landed is already seriously changing up my plans for planetary defense, before factoring in surface to orbit guns. Those are meaningful changes that create meaningful strategic decisions. Ships being rustbuckets inevitably after X years and crews becoming useless after Y years doesn't create a meaningful decision. They just draw restrictions around the sandbox of strategic decisions we get to make in this game.

Roleplay just comes down to the player deciding how they limit their strategic decisions to a vision, good or bad. Until its feasible for Steve to build a system that allows me to enforce by game rule that my current empire is suffering from political infighting between the ground and space branches, where the ground forces have successfully argued that planetary facilities are safer than orbital ones, so we've got an abundance of fighter manufacturing and 4 shipyards for the next 20 years until the leadership roles over, and my doctrine has to live with that, Roleplaying is necessary. When arbitrary gameplay rules come in and do nothing but remove decisions, they remove space that roleplay could have ran instead, and narrow the possibilities for everyone.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 30, 2020, 12:44:59 AM
As I also said before.. you can say that about ANY mechanic in the game... eventually you are just laying in bed dreaming...  ;)

Yes, you have said that before.  But you have offered no explanation for why adding more restrictions would make Aurora more fun. . . only suggestions that would make *MY* Aurora less fun.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 30, 2020, 01:18:42 AM
As I also said before.. you can say that about ANY mechanic in the game... eventually you are just laying in bed dreaming...  ;)

Yes, you have said that before.  But you have offered no explanation for why adding more restrictions would make Aurora more fun. . . only suggestions that would make *MY* Aurora less fun.

I thought I had done that... adding experience change would have the same type of impact as maintenance needs of ships but in a different way. Will I have the ships stay out on a long mission or not, the longer ships stay out on a mission the more experience you loose at the end of their mission as they need to replace more crew. It would have the same type of impact as maintenance have, the same type of restriction but it would be important in a different way... it would also "fix" the issue of once a ship is trained to 100% fleet training it will not stay there indefinitely as long as it looses its crew.

If it is tied to an optional feature like maintenance I don't see why it could not be added.

You would have to manage deployment of fleets as well as choose how to design them and choose how long a service length your crew usually have in your empire. Crew is a finite resource and you need to manage it carefully.

It would make leaders more important in therms of training skills etc... leaders still come and go... why should not the crew do the same.

You can imagine your crew as immortal all you want, your leaders and officers still have human lifespans so I don't get why you could not imagine this anyway. You also could turn it of in the same way you can turn maintenance off.

I really don't see how this would be any different than manage maintenance with overhauls or minerals for building materials and so on. It also would require MUCH less micromanagement than maintenance and overhauls but add some interesting resource management into the picture.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on January 30, 2020, 07:48:51 AM
General observation: things seems to be getting a little tense/personal.  Let's not to make Erik get out the trout!! :) http://aurora2.pentarch.org/index.php?topic=966.0
Title: Re: C# Aurora v0.x Suggestions
Post by: Profugo Barbatus on January 30, 2020, 09:03:35 AM

I really don't see how this would be any different than manage maintenance with overhauls or minerals for building materials and so on. It also would require MUCH less micromanagement than maintenance and overhauls but add some interesting resource management into the picture.

Its very different. Maintenance and minerals play into that strategic portion of the game, you have to have produced enough of them in advance, with enough mineral income to support that production, and have deployed it to forward positions/supply tenders to feed your fleet in its forward operations. A flat "My crew gets crap over time" ticker doesn't play into any of that, short of sliding around the crew training setting between 1 and 5. There's no part of that mechanic that turns around and provides interesting strategic decisions, just "Crew gets crap, swap 'em out".

You mention mitigation solutions like planning around your crew duration, but that's not a mechanic, that's a limit. Your ship design, endurance, etc is now being limited by some other arbitrary line that assumes X percent of your people retire every year, even thought your roleplay may say differently, such as a militaristic alien culture where a caste system means service is for life. I know you keep discounting roleplay, but your talking drawing arbitrary lines around how you think it should work, which is exactly what roleplay is, except you want to enforce that as a straight game rule against everyone else.

your leaders and officers still have human lifespans so I don't get why you could not imagine this anyway.

I think this is part of our fundamental disconnect, my cybernetic enhanced humans, my android race, my hivemind insectoid race, none of them have human lifespans :P To apply a human limit to a science fiction game in a universe of impossible physics and alien species is going to be pretty silly.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on January 30, 2020, 11:44:04 AM
Well your officers still get sick and they still retire during "human" life spans. As far as I know, that's hard-coded into VB6. In C# we can use the "Story Character" tick box to make an officer live forever but currently we can't. I think that's what Jorgen_CAB intended to say. You can roleplay that your race lives 500 years but your actual officers will retire when they are in theirs 60s and 70s.

I do agree that there is little point in forcing old ships to be scrapped and while I'm not against TF training slowly diminishing over time - remember it's a different thing from crew grade - I don't think it's a high priority thing either.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on January 30, 2020, 12:52:57 PM
Listening to the current argument I think both sides have valid points but I personally default to the idea of some level of crew skill degradation being modeled.  But first, a word on RP - my personal RP story line for Aurora isn't an immortal race but rather a post-WWIII 'rise from the ashes' kind of scenario with decidedly human crews and most of my asks are generally towards RPing that sort of scenario...but everyone enjoys this game from a different angle and if a Warhammer scenario of ancient dreadnoughts or 'immortal' crews is your thing, than great!  A couple of weeks ago, I asked for the ability to rename academies - I could have done without it but hey, It got added and that is cool too.  I'm not necessarily a fan of 'immortal' ships which can theoretically be upgraded forever but as has been pointed out, I can 'RP' it so that I force myself to not upgrade any ship which requires more than 25-30% of tonnage differential so my style really isn't constrained where forcing the mechanic would constrain someone else.

When it comes to crew skill degradation, I do think there is an argument to be made. We now have effectively 'immortal' ships and because of it, the crew bonuses/grade points short of catastrophic damage to the ship won't significantly degrade.  The crew/officer model is now predicated on 'mortal' crews which age up, transfer, retire, get sick, and die (I know the story tag exists but that is an option and not the default).  That creates something of a gap where the conceit is that this one fortunate and ancient ship is crewed by superbly trained crewman accrued over the decades the ship has been in service but the crew model is one of mortality and rotation and I think this in some fundamental ways cheapens the crew grade training bonuses and detracts from those that might want to RP a more 'conventional' sort of space empire.

I think some of the ideas about gradual degradation would be unwieldy and constrain other's RP choice but I think perhaps a reasonable and possibly more simple compromise would be to tie crew skill degradation to ship overhauls - therefore it becomes an optional part of the game because one can switch it on/off at game setup.  If you elect to play with it on, every time a ship overhauls/refits, then it would lose a percentage of its crew grade points (lets say 25%) to simulate crew rotation, retirements, promotions of enlisted crew members, transfers.  I wouldn't actually propose 'moving' crew members back into the pool because I think it might create too much complexity in the model and naturally the ship would have received competent replacements....but what the 25% crew point degradation at overhaul simulates is new people coming on board and building a new team and learning all the new hardware/software upgrades on board.  I think my handling it this way, it lets you create 'ships of excellence' - older and more prestigious ships will have have more 'accrued' points reflecting optimization and traditions - but also incentivizes a cycle of training exercises to rebuild/recertify crew competency like in a real navy.  If you decide to just let a ship set without training, eventually its crew training points will erode due to overhauls and even the best ship in the fleet will be 'stale'. 

I think handling it in this fashion might be a good way to meet all equities and do it in a relatively easy way to implement and without stepping on people's RP styles.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 30, 2020, 03:36:57 PM
I thought I had done that... adding experience change would have the same type of impact as maintenance needs of ships but in a different way. Will I have the ships stay out on a long mission or not, the longer ships stay out on a mission the more experience you loose at the end of their mission as they need to replace more crew.

Okay.  I think that would be NOT FUN.  In fact, I think it would be annoying.  It would be counter to my fiction and my desires.

Quote
It would have the same type of impact as maintenance have, the same type of restriction but it would be important in a different way... it would also "fix" the issue of once a ship is trained to 100% fleet training it will not stay there indefinitely as long as it looses its crew.

This is not a problem I've EVER had.  It's not a problem I've seen anyone else complain about.  If you think it's a problem, I suggest you stop training your Task Forces up to 100%.   I don't think I've ever had ship reach that point.  You are asking to restrict everyone's game to stop you from exploiting one part of the rules.

Quote
If it is tied to an optional feature like maintenance I don't see why it could not be added.

Because then you've ruined my maintenance.

Now, if it was an entirely separate feature with an on/off checkbox and the default setting was 'OFF' then it would be easy enough to ignore.  In that case, the only 'cost' to me is the programming time Steve spends on it in place of something that makes the game better for me.

Quote
You would have to manage deployment of fleets as well as choose how to design them and choose how long a service length your crew usually have in your empire. Crew is a finite resource and you need to manage it carefully.

No it isn't.  My crew are pressed landlubbers from a thousand different ports and every time a ship touches down some percentage of them desert and (a hopefully greater number) are kidnapped and forced to join the navy. . . because I'm playing Age of Sail in space.

What I am NOT playing is an orderly turnover of one-quarter of my crew every six months.

Quote
It would make leaders more important in therms of training skills etc... leaders still come and go... why should not the crew do the same.

You can imagine your crew as immortal all you want, your leaders and officers still have human lifespans so I don't get why you could not imagine this anyway. You also could turn it of in the same way you can turn maintenance off.

I don't know that Officers should be more important. . . I already find them epicly important.  And whether my crew comes and goes, or are chained to their stations like slave galley rowers, is for my fiction to decide.  I disagree that crew experience should fluctuate on a schedule -- that dictates that my empire's training methods can't allow five veteran beings to compensate for one newbie.

It flies in the face of 'Lucky' Jack Aubry or Honor Harrington whipping their crew into crack shape, or already-whipped crew finagling ways to join their old captain.



If such a system gets added, I certainly will turn it off.  The problem is that I was told the same thing years ago about up-or-out realistic promotions. . . and that system was bugged and never got fixed.  Literally every single conventional start I have ever played has included ~80% of my officer corps being deemed excess to requirements and let go because I can't create jobs for them fast enough.  Sure, there are workarounds (dozens of excess teams, SM re-run officer creation, hammering the 'Add Officer' button) but it's still super annoying.

Quote
I really don't see how this would be any different than manage maintenance with overhauls or minerals for building materials and so on. It also would require MUCH less micromanagement than maintenance and overhauls but add some interesting resource management into the picture.

Resorce management, yes.  Interesting?  I disagree.  It seems like I just get to watch my crew training go slowly up, then abruptly down every X months.

Actually, I'm not seeing the 'management' part.  My only real choices seem to be how much of my crew gets replaced and when.  And who decides the 'when' part?  You seem to be suggesting "only at colonies with pools of available crew" but that's not how officers work -- they can be sent anywhere, instantly.  Sure, many (most?) of us use actual ships to move them around as cargo, but Aurora's Auto-Assign teleports them across the universe. . . even on & off the command deck of our 22-year deep space explorers a dozens systems out from anywhere friendly.  Is crew rotation going to work the same way?

So now I should exploit the solution to the exploit by setting my crew rotation to 5 days, so that the constant flux is small enough to be ignored. . . or maybe set it to fifty years, so that it doesn't happen before the ship gets scrapped.  Or maybe five hundred years, because my fiction includes ships a century or two old.  Certainly, turning it off would be easier but it might not be possible without breaking something else I care about more.

- - - - -

What you're requesting would make the daily life of my empire worse (and more annoying) in order to solve a problem that -- to me -- seems self-inflicted.  And only 'a problem' for one or two people.

= = = = =

Maybe I'm misunderstanding the math here, or your idea.   It sounds like the HMS Average (crew exp 100) under Captain Okay would train a bit (crew exp 104) in six months, then swap 25% of its experienced crew for average newbs (new net crew exp 103), and repeat.  End result is a lower 'max crew exp' when the two curves of 'training rate' and 'turnover rate' meet.

. . .Though note that the empire-wide crew pool is now slowly rising in base experience.  If the majority of your crew are being trained by captains, the 'max crew exp' is still going up (though more slowly) since the replacements are no longer 'average' but above average.  You've changed the problem from 'exceptional ships' to 'exceptional navy' -- which, granted, may not be a problem.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 30, 2020, 03:52:37 PM
Quote
We now have effectively 'immortal' ships and because of it, the crew bonuses/grade points short of catastrophic damage to the ship won't significantly degrade.  The crew/officer model is now predicated on 'mortal' crews which age up, transfer, retire, get sick, and die (I know the story tag exists but that is an option and not the default).  That creates something of a gap where the conceit is that this one fortunate and ancient ship is crewed by superbly trained crewman accrued over the decades the ship has been in service but the crew model is one of mortality and rotation and I think this in some fundamental ways cheapens the crew grade training bonuses and detracts from those that might want to RP a more 'conventional' sort of space empire.

Only because you're choosing to define it that way.

The fifty-year-old ship with the exceptional crew doesn't have to mean octogenarians that have been doing the same job the whole time.  It can mean the culture of the ship is to learn and excel.  It can mean a prestige posting that the best & the brightest wish to serve aboard.  It can mean a lucky ship that likewise attracts skilled crewbeings.

Or it could even mean a thousand little tweaks and upgrades that makes it function faster or more effectively than a sister ship, even with an equal crew.

The SAS used jeeps in WWII North Africa. . .  but there are jeeps and there are jeeps.  Is a 4% improvement of a specific jeep over another due to the skill of its mechanic & driver, or the use of German jerry cans instead of British?
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on January 30, 2020, 04:10:37 PM
RE:  Father Tim

Of course I've chosen to define it that way.  I play a relatively 'human' empire whose military and personnel policy mimics 21st century military organization with ships that operate (and wear out) much like their 21st century naval equivalents and crews do a cruise or two before transferring to a different ship or shore job.  That is how I play my game.  It seems you play a more exotic sort of RP conceit and that is cool as well...but no more or less valid than my play style and respectfully, from your comments to me and Jorgen, it kind of seems to me that you think your play style is more valid.

That solution I propose isn't one to constrain your play style, that is why I suggested it to be optional.  I'm suggesting some sort of crew training degradation to better enable my play style. Aurora 4x really isn't your or my fantasy universe - it is Steve's and generally his vision/style aligns with mine and where it doesn't, in this case ships with an effectively infinite service life that never wear out and a crew bonus that only ever gets bigger (short of damage) and never smaller , I'll make and adhere to personal analog rules which further aligns our visions and maximizes my enjoyment.  However, Steve has shown in numerous ways he is willing to share and collaborate on his fantasy universe and so therefore - much like the academy ask from last week - I'm willing to ask for something to facilitate my play style and do it in a fashion which allows for others to live their own fantasy.  He'll either incorporate it or he won't - either way I'll play.

I hope that clears up my position.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 30, 2020, 07:48:20 PM
@Father Tim
I don't understand the rather hostile stance here.. I did also suggest it could be an "optional" mechanic in the same way that maintenance is optional as it is in the same category of "human" realism that perhaps not everyone would like to use.

From a human perspective it does make allot of sense. From an immortal tree species it might not... but then officers are still a problem in my opinion story wise too.

It was just as simple suggestion to get crew replacement into the game without much micromanagement.

I'm pretty sure Steve are less interested about covering every type of RP setting and rather look at how fun a mechanic is to use as a base reason for adopting it... that seem likely from his many responses in general. I leave it to him to ponder if crew degradation could be interesting or not.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 30, 2020, 08:39:26 PM
RE: Kristover

I do not think my play style is more valid than any other.



@Jorgen_CAB

I do not think my stance is hostile.



- - - - -


Along with trying to be clear that I do not want any such change in my personal Aurora campaign(s), I am objecting to the idea that it is somehow realistic.  To extrapolate from the given condition that crew experience is only reduced by crew deaths the hypothesis "therefore, no personnel changes occur over the life of the ship" is, I think, going too far.  Why not the explanantion "new crew are quickly trained up to this ship's standards, which exceed those elsewhere in the fleet" instead?

I also completely fail to see where the mangement, decision making, or fun is in changing the paradigm from "training/experience increases from good officers/combat" to "training/experience increases from good officers/combat and then goes down over time."


= = = = =

I agree that Steve has limited development time, and I'd rather he use it implementing a new feature that forty-odd players want and are excited about instead of one that maybe only a couple of people want and a couple of others definitely don't.



So. . .  to clear up my position:
1.  I read a request for a feature that, as I understand it, I definitely do not want and would not use.
2.  So I tried to explain why I did not want it.


I'm glad we all agree that if implemented, it should be optional.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on January 30, 2020, 11:13:42 PM
I mean, its true that the ship crew rating pretty much stays top notch after you train them up and then stays there forever, which is deeply unrealistic compared to navies that regularly have to do drills to stay reasonably sharp.

Unless you could automate training exercises though, I dont think its a fun thing to add to the game.  In reality training is actually an exceedingly costly endeavour for most militaries and choosing to not keep up with training requirements is a pretty common budget decision when times are hard, that could later lead to that military getting its ass kicked.  It could be a pretty fun tradeoff (in my opinion) to cut off the training due to a sorium shortage and to then actually feel the negative effects of less well prepared crews.  However it would not be particularly fun (in my opinion) to constantly be having to manually re-schedule training exercises lest your fleets become useless.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on January 31, 2020, 12:00:29 AM
I mean, its true that the ship crew rating pretty much stays top notch after you train them up and then stays there forever, which is deeply unrealistic compared to navies that regularly have to do drills to stay reasonably sharp.

Unless you could automate training exercises though, I dont think its a fun thing to add to the game.  In reality training is actually an exceedingly costly endeavour for most militaries and choosing to not keep up with training requirements is a pretty common budget decision when times are hard, that could later lead to that military getting its ass kicked.  It could be a pretty fun tradeoff (in my opinion) to cut off the training due to a sorium shortage and to then actually feel the negative effects of less well prepared crews.  However it would not be particularly fun (in my opinion) to constantly be having to manually re-schedule training exercises lest your fleets become useless.

I'm not sure how much of an issue that would be. If I understand correctly, fleet training can happen at any time while a ship is within the radius of its parent admin command, even while it is executing a movement order, but it needs to be assigned to the training admin command, so theoretically, it would just be a matter of copy-pasting the fleet to the training command whenever you want it on the move, or when it is garrisoned somewhere.

Maybe reassigning command could be an order of some sort? Like, "move to planet X, reassign to TRN Command, start fleet training. If hostile fleet detected, reassign to NAV Command, abandon training." or something similar.

To mitigate the effects, fleet training could decay over time, at a slow rate inversely proportional to the existent fleet training and crew grade. So it might take a year to go from 100% to 99%, another year to 95%, another year to 75%, and then it would rapidly decrease to zero, so a small amount of this decay could be acceptable.

Remembering to assign fleet to fleet training every three or four years is not that big of a chore, unless you somehow have hundreds of fleets.
Title: Re: C# Aurora v0.x Suggestions
Post by: Razgriz on January 31, 2020, 12:04:26 AM
Any thoughts on Tech to extend leader/species lifespans? It would push the age of retirement up higher. 

Unless the new story function makes them immortal, only dying in battle and accidents.

 ;D

Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on January 31, 2020, 12:49:49 AM
Any thoughts on Tech to extend leader/species lifespans? It would push the age of retirement up higher. 

Unless the new story function makes them immortal, only dying in battle and accidents.

 ;D

Biology/Genetics needs some love. A tech that increases the lifespan of a species as a whole should also boost the population growth rate since you have fewer people dying per year. Since the only real late-game limitation is population, this would be a huge boon, if properly balanced, in the mid-to-late parts of the game.

On a side note, can it be made possible to control or stop population growth in certain colonies (military facilities, research outposts or mining complexes on high colony cost worlds, which typically have small populations that grow rapidly) where you don't need or want the extra population? Shipping people out gets really annoying when you have scores of these colonies. Or maybe a conditional order to "Pickup N colonists from Planet X when population exceeds Y." I know you can always set a colony's population to 'stable', but that requires a population of ten million in C#, and it's not always very effective, at least in VB6.

If it does happen, could there also be a method to control population growth by species for those xenophobic empires that prefer their core species to be the most populous? And since we have ground armies now, some way to eradicate the civilian population of a certain species of a world without using orbital weapons would be nice, too. Of course, it would need to be a long, arduous process that would demand significantly more resources than just nuking everything.

I think, right now, it can be gamed by shipping the entire population to some random colony cost 20+ hellhole with no infrastructure, but that takes a long, long time for large populations. It's not very satisfying, and a bit gimmicky.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 31, 2020, 01:31:51 AM
I mean, its true that the ship crew rating pretty much stays top notch after you train them up and then stays there forever, which is deeply unrealistic compared to navies that regularly have to do drills to stay reasonably sharp.

Unless you could automate training exercises though, I dont think its a fun thing to add to the game.  In reality training is actually an exceedingly costly endeavour for most militaries and choosing to not keep up with training requirements is a pretty common budget decision when times are hard, that could later lead to that military getting its ass kicked.  It could be a pretty fun tradeoff (in my opinion) to cut off the training due to a sorium shortage and to then actually feel the negative effects of less well prepared crews.  However it would not be particularly fun (in my opinion) to constantly be having to manually re-schedule training exercises lest your fleets become useless.

I'm not sure how much of an issue that would be. If I understand correctly, fleet training can happen at any time while a ship is within the radius of its parent admin command, even while it is executing a movement order, but it needs to be assigned to the training admin command, so theoretically, it would just be a matter of copy-pasting the fleet to the training command whenever you want it on the move, or when it is garrisoned somewhere.

Maybe reassigning command could be an order of some sort? Like, "move to planet X, reassign to TRN Command, start fleet training. If hostile fleet detected, reassign to NAV Command, abandon training." or something similar.

To mitigate the effects, fleet training could decay over time, at a slow rate inversely proportional to the existent fleet training and crew grade. So it might take a year to go from 100% to 99%, another year to 95%, another year to 75%, and then it would rapidly decrease to zero, so a small amount of this decay could be acceptable.

Remembering to assign fleet to fleet training every three or four years is not that big of a chore, unless you somehow have hundreds of fleets.

Yes... it would be a matter of moving the fleet into a training admin after a long deployment or several as you would for the most part not lose that much fleet training. Individual ship experience is completely automated so you don't need to do anything.

If the ship stay at port with a population it would not loose fleet training or individual ship training at all as the ship only swap out crew once in a while. You could just argue that the ships or the fleet will do the occasional exercises and drills to keep the crew up to speed. So this would only impact when large part of the crew have to be replaced after the fleet have been on really long deployments. You would only loose a very small amount of crew points every 5 day cycle, much smaller than you otherwise would. Just like paying supplies for maintenance... you just don't need to have the academy at the local base but anywhere in your empire, we just assume that crew can travel to where they are needed using civilian means.
The reason why it wold work like this is the fact that it certainly is no fun to have to retrain ships just because, just like maintenance. You should only have to care about this if you actually use the ships and need to replace a considerable amount of crew at once.

So I don't think this would need huge amount of micromanagement, especially not with the new fleet training mechanic in the game.

It would impact your willingness to have ships stationed at really long deployments though and building ships that have deployment for 10 or more years will cost you allot of crew points so you will only afford to have a very few such ships... say a few survey ship... you also would not like to loose those ships as the crew is worth allot more to you as they should be with that amount of training they would need for such long deployments..

You could also have a system where you pay slightly less crew point the less part of the ship crew you need to replace after a mission. So a ship that need to replace 50% of the crew pay X amount, a ship that replace 25% only pays 0.3X for example. Which sort of reflect the training that the crew on board the ship can give the new crew. This would make the crew resource something you actually would care about in a different way as your away mission time will impact the cost of replacing crew.

So.... let's say that your empire have a four year crew service length. You might still want to give your science vessel double or triple that while the ships themselves have deployments of perhaps 24-36 months. When they replace crew after a deployment they don't have to pay too much crew points as the initial cost generally is much higher.

Think of crew points more as the cost for you to train and educate new people and not an exact number of crew you have access to. In the "real" world you would have a much better understanding for the exact need of new crew in a way it is difficult to have in a game, so the exact number of crew you have available is not that interesting.. it rather is the capacity to educate them to a certain standard that is.
We also should understand that in today's military ships the cost if its crew generally is the most costly part in money of a modern ship in terms of on going costs in peace time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on January 31, 2020, 01:52:40 AM
On a side note, can it be made possible to control or stop population growth in certain colonies (military facilities, research outposts or mining complexes on high colony cost worlds, which typically have small populations that grow rapidly) where you don't need or want the extra population?

The "Flag as Military Restricted" option http://aurora2.pentarch.org/index.php?topic=8495.msg117794#msg117794 (http://aurora2.pentarch.org/index.php?topic=8495.msg117794#msg117794) should do so.  With no immigration pop growth should drop to zero at the Infrastructure limit.
Title: Re: C# Aurora v0.x Suggestions
Post by: Bremen on January 31, 2020, 06:23:40 AM
Biology/Genetics needs some love. A tech that increases the lifespan of a species as a whole should also boost the population growth rate since you have fewer people dying per year. Since the only real late-game limitation is population, this would be a huge boon, if properly balanced, in the mid-to-late parts of the game.

If we did get a tech to increase population growth, I think the boost should be very small; instead of 20% a tier like most techs probably something like 2% (so 10% ->10.2%). Population growth is exponential by nature so even small boosts will add up fast.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on January 31, 2020, 07:42:07 AM
I mean, its true that the ship crew rating pretty much stays top notch after you train them up and then stays there forever, which is deeply unrealistic compared to navies that regularly have to do drills to stay reasonably sharp.

Unless you could automate training exercises though, I dont think its a fun thing to add to the game.  In reality training is actually an exceedingly costly endeavour for most militaries and choosing to not keep up with training requirements is a pretty common budget decision when times are hard, that could later lead to that military getting its ass kicked.  It could be a pretty fun tradeoff (in my opinion) to cut off the training due to a sorium shortage and to then actually feel the negative effects of less well prepared crews.  However it would not be particularly fun (in my opinion) to constantly be having to manually re-schedule training exercises lest your fleets become useless.

For some people you would absolutely be correct but I'm something of a simulationist in outlook and I would have GREAT fun trying to figure out the supply chain of minerals to a shipyard, scheduling new construction to be delivered by a specific date, bringing certain ships back for overhauls and timing their release, and then putting it all together for a a series of fleet exercises to get folks up to a level of proficiency I think appropriate and then off to the front lines the fleet goes - truth in lending, I enjoy Factorio also!  It would create interesting decisions because as wars progress, I would have to consider how 'trained' I want my forces to be before sending them off to the front - an emergency situation would dictate you go straight from yard to the fight.  It would add additional pressures onto my overhaul schedules.  We already have to watch maintenance timers on all our ships and make decisions about when to bring them in for overhaul vs. having them suffer maintenance failures which I imagine for some is hugely tedious - it is why it is an option to be switched on/off for those that rather not deal with it.  This could/would be another option for those who want that kind of detail.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on January 31, 2020, 07:56:56 AM
Biology/Genetics needs some love. A tech that increases the lifespan of a species as a whole should also boost the population growth rate since you have fewer people dying per year. Since the only real late-game limitation is population, this would be a huge boon, if properly balanced, in the mid-to-late parts of the game.

No it doesn't. Greater longevity may actually slow down population growth as people wait longer to have children, stretching the distance between generations even while numbers per generation remain the same.

Population growth limitation is largely cultural in modern society, it would be entirely possible for a woman to produce a child every 4 years or even faster strictly biologically speaking and they don't for a variety of reasons. While the death rate would slow down a little, it would not actually speed population growth unless either it encourages the birth of more children per person or shortens the timespan between generations.

It would temporarily help by limiting deaths, that's true, but it won't affect the chances of survival in the long term. Even those that have been treated with such a longevity booster will eventually die. Even if humans become immortal in the sense that they won't die of old age it has been calculated that the average lifespan of people is going to be around 700 years due to accidents, misadventure and disease. That doesn't mean that there won't be eventually extremely old people far older than 700 years, but there's going to be plenty of people who end up dead before they're even 200 years old for any number of reasons.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on January 31, 2020, 08:33:51 AM
Biology/Genetics needs some love. A tech that increases the lifespan of a species as a whole should also boost the population growth rate since you have fewer people dying per year. Since the only real late-game limitation is population, this would be a huge boon, if properly balanced, in the mid-to-late parts of the game.

No it doesn't. Greater longevity may actually slow down population growth as people wait longer to have children, stretching the distance between generations even while numbers per generation remain the same.

Population growth limitation is largely cultural in modern society, it would be entirely possible for a woman to produce a child every 4 years or even faster strictly biologically speaking and they don't for a variety of reasons. While the death rate would slow down a little, it would not actually speed population growth unless either it encourages the birth of more children per person or shortens the timespan between generations.

It would temporarily help by limiting deaths, that's true, but it won't affect the chances of survival in the long term. Even those that have been treated with such a longevity booster will eventually die. Even if humans become immortal in the sense that they won't die of old age it has been calculated that the average lifespan of people is going to be around 700 years due to accidents, misadventure and disease. That doesn't mean that there won't be eventually extremely old people far older than 700 years, but there's going to be plenty of people who end up dead before they're even 200 years old for any number of reasons.

I think that the problem often is that the "player" see population as a means to economic growth while the society where the population exist don't see it that way. Realistically if we look at the technologically advancement today and in the future then industrial growth can reasonably be decoupled from population quite drastically if you have the need for it, such as in a war. Population is only useful for keeping the consumer based economy going and for general research progress.

I could see many cultural reason for why population growth would become allot slower with technological advancement.. even if you could effectively clone or artificially create people without parents directly involved. Population might at that point just be an industrial commodity just as anything else with only ethics setting the limits.

So you could potentially have a society that produce POP at astounding rates or societies where the POP have more or less completely stagnated. Artificial AI could definitely make future societies completely independent for industrial growth in terms of population... but then again why would you produce stuff if no one consumes it and round you go.

In terms of warships such a society could probably multiply its warship production capacity exponentially as long as there are resources and energy to exploit as their actually biological population don't really need to be involved except on the very top level.

Now... Aurora is not that game with that type of societies... at least not mechanically as population IS an important resource. Population makes for an interesting finite resource that you need to manage carefully and there is a reason why you wan't to expand as colonies makes you exploit a greater percentage of the population and increase the overall growth of your population.
Title: Re: C# Aurora v0.x Suggestions
Post by: Saros on January 31, 2020, 09:36:04 AM
Hi Steve, is there any plan for greater ability to manipulate ruins, and the various spoiler spawns? It would be a great tool to have for 'Lets play' or forum run games to be able to spawn/edit ruins and precusrors from spacemaster mode.

Also is it possible to be able to have a toggle to make the game 'locked' without the spacemaster password.  i. e.  you can't advance time without entering it.  Would help greatly with said forum games by being able to provide the save to players without worrying about them zooming forward in time.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on January 31, 2020, 12:02:38 PM

No it doesn't. Greater longevity may actually slow down population growth as people wait longer to have children, stretching the distance between generations even while numbers per generation remain the same.

Population growth limitation is largely cultural in modern society, it would be entirely possible for a woman to produce a child every 4 years or even faster strictly biologically speaking and they don't for a variety of reasons. While the death rate would slow down a little, it would not actually speed population growth unless either it encourages the birth of more children per person or shortens the timespan between generations.

It would temporarily help by limiting deaths, that's true, but it won't affect the chances of survival in the long term. Even those that have been treated with such a longevity booster will eventually die. Even if humans become immortal in the sense that they won't die of old age it has been calculated that the average lifespan of people is going to be around 700 years due to accidents, misadventure and disease. That doesn't mean that there won't be eventually extremely old people far older than 700 years, but there's going to be plenty of people who end up dead before they're even 200 years old for any number of reasons.

I understand that the effects of longevity with regards to population growth are strongly dependant on how well people retain fertility with advancing age, assuming we don't automate the process of procreation at some point. Current trends indicate that demographic ageing and increasing lifespans are strongly associated with declining fertility, but I would be cautious about applying these to futuristic societies where people retain their health and virility well into their hundreds.

While it is probable that people would delay child-rearing significantly to sustain focus on their education or career, I seriously doubt that the time taken for a child to mature and achieve independence will increase beyond twenty or thirty years. The reproductive age in humans is typically considered to be 16-50, which is insufficient time to conceive more than a single generation of children. If that were to be 16-100, or 16-200, though? Certainly most people would opt not to have children well into their fifties or sixties, but it is also possible that those exact same people would choose to have children again in their eighties or nineties, and then again in their one-twenties, as their earlier children age and separate from them. The size of each subsequent generation will still repeatedly increase as the population grows, since almost the entire population is both capable of reproducing and might be willing to do so.

It's probably incorrect to attribute any such increase in the growth rate to a decline in death rate, it's a decline in death rate and an assumption that sufficiently long lifespans will prompt people to have multiple children spaced several decades apart. Which, granted, may very well be proven to be false.

Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on January 31, 2020, 12:22:43 PM
Hi Steve, is there any plan for greater ability to manipulate ruins, and the various spoiler spawns? It would be a great tool to have for 'Lets play' or forum run games to be able to spawn/edit ruins and precusrors from spacemaster mode.
You can already use SM mode to place random ruins on a body. You cannot determine its size or tech level but you can place it. AFAIK, SM mode does not allow spawning spoilers, only new player races or new NPRs - conventional and TN.

Also is it possible to be able to have a toggle to make the game 'locked' without the spacemaster password.  i. e.  you can't advance time without entering it.  Would help greatly with said forum games by being able to provide the save to players without worrying about them zooming forward in time.
That would indeed be useful if you use the style where the save gets passed around for people to issue orders and so on, and then you as the Space-Game-Master advances time.

Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on February 01, 2020, 05:08:51 AM

No it doesn't. Greater longevity may actually slow down population growth as people wait longer to have children, stretching the distance between generations even while numbers per generation remain the same.

Population growth limitation is largely cultural in modern society, it would be entirely possible for a woman to produce a child every 4 years or even faster strictly biologically speaking and they don't for a variety of reasons. While the death rate would slow down a little, it would not actually speed population growth unless either it encourages the birth of more children per person or shortens the timespan between generations.

It would temporarily help by limiting deaths, that's true, but it won't affect the chances of survival in the long term. Even those that have been treated with such a longevity booster will eventually die. Even if humans become immortal in the sense that they won't die of old age it has been calculated that the average lifespan of people is going to be around 700 years due to accidents, misadventure and disease. That doesn't mean that there won't be eventually extremely old people far older than 700 years, but there's going to be plenty of people who end up dead before they're even 200 years old for any number of reasons.

I understand that the effects of longevity with regards to population growth are strongly dependant on how well people retain fertility with advancing age, assuming we don't automate the process of procreation at some point. Current trends indicate that demographic ageing and increasing lifespans are strongly associated with declining fertility, but I would be cautious about applying these to futuristic societies where people retain their health and virility well into their hundreds.

While it is probable that people would delay child-rearing significantly to sustain focus on their education or career, I seriously doubt that the time taken for a child to mature and achieve independence will increase beyond twenty or thirty years. The reproductive age in humans is typically considered to be 16-50, which is insufficient time to conceive more than a single generation of children. If that were to be 16-100, or 16-200, though? Certainly most people would opt not to have children well into their fifties or sixties, but it is also possible that those exact same people would choose to have children again in their eighties or nineties, and then again in their one-twenties, as their earlier children age and separate from them. The size of each subsequent generation will still repeatedly increase as the population grows, since almost the entire population is both capable of reproducing and might be willing to do so.

It's probably incorrect to attribute any such increase in the growth rate to a decline in death rate, it's a decline in death rate and an assumption that sufficiently long lifespans will prompt people to have multiple children spaced several decades apart. Which, granted, may very well be proven to be false.

The general problem in the game is that is mostly is a cultural thing. In the future population growth rate can probably be anything you want as you can artificially grow people in a lab is you wish. It will become more of an ethical and cultural thing.

In game terms you will ALWAYS want more population (as a player) as it is one of the most restraining resources you have, so it will put severe restrictions on how you expand. You have to be very careful with how this is balanced, that is my opinion.
Title: Re: C# Aurora v0.x Suggestions
Post by: Akhillis on February 02, 2020, 12:00:32 AM
Demographics is a complicated science and while we understand how it works fairly well in past conditions, Aurora doesn't take place in those conditions. For that matter A4X doesn't really pretend to be realistic in this respect. Population growth is way too fast.

I'd say a tech that increases longevity of your officers and increases pop growth slightly would be good from a game play standpoint
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on February 02, 2020, 08:48:17 AM
Steve, thanks for the update on independence. 

If I can make a small suggestion(s), first the newly independent colony starts in communication with their former parent empire....they're kin after all.

Additionally, the diplomatic status reflect the mode of independence - if you grant it to them, they have a neutral and perhaps even a friendlier disposition (it was a peaceful break after all).  If the colony broke away due to unrest, perhaps their diplomatic stance is less friendly to hostile given they had to physically break away.

REALLY looking forward to C# now - the new ground and diplomatic game when combined with the improvements to naval, economic, and exploration game really are going to make this THE true space 4x. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 02, 2020, 08:56:47 AM
If I can make a small suggestion(s), first the newly independent colony starts in communication with their former parent empire....they're kin after all.

Yes, that is already coded :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 02, 2020, 08:57:49 AM
Additionally, the diplomatic status reflect the mode of independence - if you grant it to them, they have a neutral and perhaps even a friendlier disposition (it was a peaceful break after all).  If the colony broke away due to unrest, perhaps their diplomatic stance is less friendly to hostile given they had to physically break away.

The default is neutral. I'll handle the starting relations differently depending on how the independence is achieved.
Title: Re: C# Aurora v0.x Suggestions
Post by: DFNewb on February 03, 2020, 12:01:02 AM
Autosaving with both real time and game time options.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kaiser on February 03, 2020, 07:17:38 AM
Hi @Steve, I have just read last posts about diplo, I like how the new pattern looks like, after all, over the year Aurora has evolved in something more than a simple simulation (I know, I know how you see your creature), but for us players this is a GAME and diplomacy, wars, alliance and treaties all play a fundamental role in Aurora (without them would be like playing a paradox game without diplomacy, a boring endless game).
My suggestion is just to add as many features as you can (resources and tech exchange, POW exchange, buying and selling ships, planets exchange, slavery).
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on February 03, 2020, 07:22:22 AM
I feel like a suggestion that just says "Add lots more stuff" is not particularly productive, especially so close to release. Let's not play backseat gamedev.
Title: Re: C# Aurora v0.x Suggestions
Post by: Ektor on February 03, 2020, 06:00:56 PM
Hello, people.     This is my first post on this forum.     

I joined because I've been playing Aurora nonstop for some time now, and I talked about some stuff I'd like to see to people in the Discord channel and while some disagreed, they said I could post it here if I wanted.     I understand if some of these suggestions are considered unbalanced or boring, but I'll share what I've been thinking.   

Suggestion 1: Ways to get more accessibility out of 0.    1 deposits

Most systems I find have millions of tons of resources, which are basically unreachable because accessibility is 0.    1.     I understand that the shortage of minerals and the steps you need to take to remedy them are part of the meat of the game, so I also think that simply being able to ignore accessibility wouldn't be very fun.     An increase from 0.    1 to 0.    2 is already a 200% jump in productivity, so I think that anything more than that would be excessive.   

But I'd like for there to be some way of making those deposits marginally useful.     I'm thinking of something that's kinda like this:

-Have a tech that allows the building of a special mine, which would cost 180 resources for its manned version and 360 for its auto version.     This is a mine with normal productivity except it counts a 0.    1 deposit as a 0.    2 deposit.     Now, there could be additional constraints to using these, for example, they could be impossible to ship with freighters, necessitating the movement of factories or construction brigades.     This tech could be called "deep core mining" or something like that.   

or

-Simply having a single tech, that costs a lot of research points, that takes every 0.    1 resource and turns it to 0.    2.     I think this would be simpler, but not as fun.   

Suggestion 2: Population happiness mechanics

Currently, stability modifiers are penalties only, that is, if you fail to provide infrastructure or PPV to a colony, its productivity goes down, and taking in account the new rebellion mechanics, can rebel.     My suggestion is to add a positive facet to productivity by adding a happiness modifier in addition to the stability one.     This would involve some things like:

-Adding installations that provide happiness.     Similar to infrastructure, there could be a "x% happiness at y installations per million pop", this would add an abstraction to deal with every day government stuff, but it would also let you roleplay an evil nation that doesn't provide to its population.     These could be multiple types of installation like says schools and hospitals, but I think it would fit better the kinda minimalist tone of Aurora if you had a single installation type called something like "social installations" or even "social infrastructure".     These would bring the population happiness to a x%, which could add like, a x/2% bonus to productivity, I'm picturing 50% happiness turning the production modifier to 125% or something like that.   

-The rest of the happiness would be tied to the trade good system.     More trade goods could be added, and the remaining 50% happiness could be proportional to "% of import need fulfilled", which would add a secondary reason for us to encourage civilian shipping in our systems.   

Suggestion 3: Some optional alterations to the civilian shipping model

There could be some additional options like:

-Allowing which specific types of civilian ship can appear.     You could have a different toggle for freighters, harvesters and colony ships, so if you want to control completely a sector in your empire you could do so, while leaving the rest for civilians.     I know there's already an option to disable harvesters, so that's not that hard.   

and

-Allowing player control of the civilian economy ships.     This is mainly so I can feel contemplated when I want to RP centralized, command economies.     Basically instead of spawning civilian lines, you could build freighters and use either default orders to automate or direct orders to allow it to ship trade goods from planet to planet.     This would tie in with the happiness modifiers I mentioned earlier, as you could earn reduced or even no wealth from this government controlled shipping, but the happiness bonus could remain.   

Anyway, this is probably way too much stuff to be talking about before the release of C#, so I think that even if these make sense, they shouldn't become like, a big priority, but those are things I'd like to see.   
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on February 03, 2020, 06:18:42 PM
Suggestion #3 is already in.  The government (you) can build any and all sorts of civilian ships, and have complete control over what they do.  There's also a setting to disable "civilians" (commercial companies), meaning they never build ships or CMCs.  It leaves the government (a.k.a. you) as the sole operator of vessels and the economy.
Title: Re: C# Aurora v0.x Suggestions
Post by: Ektor on February 03, 2020, 06:24:07 PM
Oh goddess, C# gets better every time I hear about it!
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on February 03, 2020, 06:36:28 PM

Suggestion 2: Population happiness mechanics

Currently, stability modifiers are penalties only, that is, if you fail to provide infrastructure or PPV to a colony, its productivity goes down, and taking in account the new rebellion mechanics, can rebel.     My suggestion is to add a positive facet to productivity by adding a happiness modifier in addition to the stability one.     This would involve some things like:

-Adding installations that provide happiness.     Similar to infrastructure, there could be a "x% happiness at y installations per million pop", this would add an abstraction to deal with every day government stuff, but it would also let you roleplay an evil nation that doesn't provide to its population.     These could be multiple types of installation like says schools and hospitals, but I think it would fit better the kinda minimalist tone of Aurora if you had a single installation type called something like "social installations" or even "social infrastructure".     These would bring the population happiness to a x%, which could add like, a x/2% bonus to productivity, I'm picturing 50% happiness turning the production modifier to 125% or something like that.   

-The rest of the happiness would be tied to the trade good system.     More trade goods could be added, and the remaining 50% happiness could be proportional to "% of import need fulfilled", which would add a secondary reason for us to encourage civilian shipping in our systems.   

If Steve were to add some form of positive/negative population morale and living quality to the game I think it should be tied into the current mechanic.

People probably would like to be decently self sufficient and get access to the trade items they lack and able to trade the ones they are in excess of.

So you could add some negative/positive effects on how many construction factories and financial buildings a colony have and also some effect based on the trade done at the colony. These bonuses should probably scale with population size... so a colony of 1 million people will not really be bothered very much by any of this as it is too small to consider itself a self sustaining entity while a colony with 1 billion population would like to have pretty much everything there as they see themselves as a very important centre of intellectuals, industry etc... if you don't provide for labs, shipyards in enough quantities they will start to complain at that level.

Now... it could be sort of an optional part of the game as I believe not everyone would like to have a more detailed social simulation in the game and prefer to role-play it. But I think it could be fun for a generally human campaign.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on February 03, 2020, 06:43:59 PM
We also have the colony supply/demand values for various trade goods, so importing sufficient in a category could increase happiness and not getting enough decrease it.

Maybe 'Alien Artifacts' is only counted for increased happiness, or at least has drastically reduced unhappiness rates.
Title: Re: C# Aurora v0.x Suggestions
Post by: Ektor on February 03, 2020, 06:54:01 PM
Quote from: Father Tim link=topic=9841. msg118519#msg118519 date=1580777039
We also have the colony supply/demand values for various trade goods, so importing sufficient in a category could increase happiness and not getting enough decrease it.

That would penalise the years the main planet spends not being able to trade with anyone, wouldn't it?
Title: Re: C# Aurora v0.x Suggestions
Post by: Mini on February 03, 2020, 08:40:10 PM
And also cause problems for empires with commercial companies disabled, since you can't transfer trade goods yourself.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on February 03, 2020, 11:09:48 PM
And also cause problems for empires with commercial companies disabled, since you can't transfer trade goods yourself.

Then we should fix that rather than let it be a reason we can't do something else.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on February 04, 2020, 01:21:02 AM
And also cause problems for empires with commercial companies disabled, since you can't transfer trade goods yourself.

Then we should fix that rather than let it be a reason we can't do something else.

Yes.. you could simply add an order to pick up and drop of trade goods that work the same as any other transport order an allow the player to set up trade routes if they choose to do that themselves.

Simple enough in my opinion.

I also think such a "simulation" system could be optional in the first place as not everyone would like to have it. But then again... the more optional system these is the more exceptions in the code there has to be and it become more complex to do.
Title: Re: C# Aurora v0.x Suggestions
Post by: Akhillis on February 04, 2020, 07:41:13 AM
I don't think the trade system is well suited for that task.

Even if you could transfer trade goods manually, the player has little control over the surpluses and deficits at an empire-wide level. AFAIK the only way you can influence production is by sending more colonists to a planet.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on February 04, 2020, 07:51:41 AM
I don't think the trade system is well suited for that task.

Even if you could transfer trade goods manually, the player has little control over the surpluses and deficits at an empire-wide level. AFAIK the only way you can influence production is by sending more colonists to a planet.

You are probably right...
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on February 05, 2020, 12:49:47 AM
Could Fighter-Sized Crew Quarters be made 0 Tons and made Fighter Only with a hard limit on the number of modules mounted? Or maybe Fighters having a certain amount of free crew space equivalent to a fighter sized crew quarters module, but only ships designated as Fighters would have them? The size of Fighter Sized Crew modules and Tiny engineering spaces piss me off...
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 05, 2020, 03:35:51 AM
Could Fighter-Sized Crew Quarters be made 0 Tons and made Fighter Only with a hard limit on the number of modules mounted? Or maybe Fighters having a certain amount of free crew space equivalent to a fighter sized crew quarters module, but only ships designated as Fighters would have them? The size of Fighter Sized Crew modules and Tiny engineering spaces piss me off...

The fighter crew quarters component is only 2 tons (0.04 HS). Fighters (and FAC) already benefit from not requiring a dedicated command component due to size, but that is reasonable given that the crew will be in close proximity. They can also reduce required crew space by having short deployment times. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Kiruth on February 05, 2020, 08:40:20 AM
A typical issue with beam based fleets is that they are "all or nothing" weapons: if you are slower than the opponent and you can't dictate the engagement you are going to be destroyed and/or kited. 

I don't know if it was already suggested, but I would like to see an option to give an order (or a tech) to temporarily boost engine performance for a brief period of time.  This should be within reasonable percentage (eg.  20/30% boost), should not be deactivable at will (it will continue to get boosted for a specific time) and should come with an heavy cost such as an high risk of explosion of the engines or loss of all power for the ship for a time after the boost (like jump shock). 

I much prefer the first option because it provide an hard choice also for the fleet that has the advantage (do we prefer continuing kiting with the risk of engine explosion or are we ready for a close quarter fight?). 
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on February 05, 2020, 08:45:15 AM
A typical issue with beam based fleets is that they are "all or nothing" weapons: if you are slower than the opponent and you can't dictate the engagement you are going to be destroyed and/or kited. 

I don't know if it was already suggested, but I would like to see an option to give an order (or a tech) to temporarily boost engine performance for a brief period of time.  This should be within reasonable percentage (eg.  20/30% boost), should not be deactivable at will (it will continue to get boosted for a specific time) and should come with an heavy cost such as an high risk of explosion of the engines or loss of all power for the ship for a time after the boost (like jump shock). 

I much prefer the first option because it provide an hard choice also for the fleet that has the advantage (do we prefer continuing kiting with the risk of engine explosion or are we ready for a close quarter fight?).

There was quite a heated discussion on how to "fix" this a couple of pages ago... you should check that out.   ;)
Title: Re: C# Aurora v0.x Suggestions
Post by: Kiruth on February 05, 2020, 09:46:44 AM
Quote from: Jorgen_CAB link=topic=9841. msg118598#msg118598 date=1580913915
Quote from: Kiruth link=topic=9841. msg118596#msg118596 date=1580913620
A typical issue with beam based fleets is that they are "all or nothing" weapons: if you are slower than the opponent and you can't dictate the engagement you are going to be destroyed and/or kited.   

I don't know if it was already suggested, but I would like to see an option to give an order (or a tech) to temporarily boost engine performance for a brief period of time.   This should be within reasonable percentage (eg.   20/30% boost), should not be deactivable at will (it will continue to get boosted for a specific time) and should come with an heavy cost such as an high risk of explosion of the engines or loss of all power for the ship for a time after the boost (like jump shock).   

I much prefer the first option because it provide an hard choice also for the fleet that has the advantage (do we prefer continuing kiting with the risk of engine explosion or are we ready for a close quarter fight?). 

There was quite a heated discussion on how to "fix" this a couple of pages ago. . .  you should check that out.    ;)

Thanks, will do  :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Ektor on February 06, 2020, 07:57:25 PM
Quote from: Mini link=topic=9841.  msg118524#msg118524 date=1580784010
And also cause problems for empires with commercial companies disabled, since you can't transfer trade goods yourself.     

Thats.  .  .      Exactly what I proposed in suggestion 3?

Quote from: Jorgen_CAB link=topic=9841.  msg118535#msg118535 date=1580800862
Yes.    .     you could simply add an order to pick up and drop of trade goods that work the same as any other transport order an allow the player to set up trade routes if they choose to do that themselves.   

Quote from: Ektor
Basically instead of spawning civilian lines, you could build freighters and use either default orders to automate or direct orders to allow it to ship trade goods from planet to planet

Quote from: Jorgen_CAB link=topic=9841.  msg118535#msg118535 date=1580800862
I also think such a "simulation" system could be optional in the first place as not everyone would like to have it.     But then again.  .  .   the more optional system these is the more exceptions in the code there has to be and it become more complex to do.   

I definitely think it should be optional.   I have a liking for the X series and its clones, this simulation of space freight lines is exactly up my alley.   I suggested that because I think it would be loads of fun, but different people have differing ideas of what constitutes fun.   

Quote from: Akhillis link=topic=9841.  msg118548#msg118548 date=1580823673
Even if you could transfer trade goods manually

Which is exactly what I said.   

Quote from: Akhillis link=topic=9841.  msg118548#msg118548 date=1580823673
the player has little control over the surpluses and deficits at an empire-wide level.    AFAIK the only way you can influence production is by sending more colonists to a planet.   

That's why it should be a bonus only mechanic.    Because the more you can fulfill the demand, the higher your productivity, but you would always be capped at the exports that your empire produces.    Unless there was a way to build civilian industries to build exports, but I think that would be too much micro. 

Edit: All periods I write keep having spaces added after them.  Can I disable this?
Title: Re: C# Aurora v0.x Suggestions
Post by: kuhaica on February 07, 2020, 10:24:02 AM
Being able to build Civilian "production" centres would be good, but it would be nicer to have something akin to "Civilian Shipping" where companies show up at random depending on the demands and the Player can subsidise them.  Also, I do like the idea of the civilian goods giving a bonus for being fulfilled rather than negatives for not, just because of the nature of the early game and some scenarios where you expand slowly. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on February 07, 2020, 12:54:12 PM
Edit: All periods I write keep having spaces added after them.  Can I disable this?
It's an anti-spam feature because the forum software thinks you're trying to put in URL links in a sneaky way or something. It'll go away once you have 10 posts, I believe.
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on February 07, 2020, 08:24:02 PM
Could jump point distance (jump engine modifier) apply on both sides of the jump?

I was thinking that in addition to how far away from the destination jump point you can appear, jump point distance also controls how far away from the originating jump point you can initiate a jump. Shaving some distance/time.
 ;D
This also creates the potential to surprise an opponent running to escape a system from a known jump point by actually jumping from behind them in a stern chase and have your ships jump shock wearing off when they are just arriving...
Title: Re: C# Aurora v0.x Suggestions
Post by: DFNewb on February 10, 2020, 08:51:43 AM
Could you please add this:

 Newly constructed fighters will automatically assign and land onto mothership in orbit pre-selected.  Maybe even an option to do it for taskforce (if TF's are gone then just any empty hanger in orbit) if there is hanger space.
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on February 10, 2020, 09:22:16 AM
Could you please add this:

 Newly constructed fighters will automatically assign and land onto mothership in orbit pre-selected.

I was under the impression that the preferred strikegroup listing on ship class design did this already.
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on February 10, 2020, 05:46:53 PM
So, regarding Missile Launcher Sizes. Steve already said the he will be including pre-TN armors. That got me thinking. So, currently Missile Launcher tech starts off fully developed in C#, but wouldn't it be necessary to re-develop the tech to take advantage of TN materials? At least for a Conventional Start. I suggest as part of a Conventional Start we have to research either the original VB6 tech lines for missile launcher size, or just have a "TN Launchers" tech, maybe make it a 500 or 1000 RP Tech.
Title: Re: C# Aurora v0.x Suggestions
Post by: spqrein on February 10, 2020, 10:20:55 PM
Quote from: Kiruth link=topic=9841.   msg118596#msg118596 date=1580913620
A typical issue with beam based fleets is that they are "all or nothing" weapons: if you are slower than the opponent and you can't dictate the engagement you are going to be destroyed and/or kited.     

I don't know if it was already suggested, but I would like to see an option to give an order (or a tech) to temporarily boost engine performance for a brief period of time.     This should be within reasonable percentage (eg.     20/30% boost), should not be deactivable at will (it will continue to get boosted for a specific time) and should come with an heavy cost such as an high risk of explosion of the engines or loss of all power for the ship for a time after the boost (like jump shock).     

I much prefer the first option because it provide an hard choice also for the fleet that has the advantage (do we prefer continuing kiting with the risk of engine explosion or are we ready for a close quarter fight?).   

I have not fully read all the changes but this idea sounds good but in my view isn't.     So slow ships can boost to close range, then fast ships can boost to keep at range, not solving the problem.     

Guns:  If mainly limited by fire control range like in VB.     Have most guns at early levels reach that far to start and vary things like accuracy, damage, or tracking speed.     Now higher tech engines or faster ships (gun ships) don't fight by kitting but maintain the advantage of their better tech or speed to choose when to engage or length of engagement.     Can they still kit at max range yes but not without some risk.     

It would be nice if some gun types could shot much farther but require a spotting ship or drone to increase range.     I would limit the drones to the ship that can carry it, thus fighters and small capital ships probably can't make use of them but larger battleships could.   In fleet engagement would give a role to fighter to find and clear the area of these type of small targets to prevent long range fire.   Maybe even lead to who can gain local space superiority so the battleships can stand off and blast things.   

Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on February 11, 2020, 07:11:01 AM
A suggestion of small balance if it has not been changed already...

I think that the 15cm laser at 4HS is too small, it's general DPS is way to effective very early, especially when you consider that 15cm lasers can have really long range too they are extremely effective in general in comparison with most other lasers. They often even can compete with high damage lasers in terms of cutting through enemy ship armour through cheer DPS, almost no other laser can do this as effective as the 15cm.

10cm is 3HS
12cm is 4HS
15cm is 4HS
20cm is 6HS
25cm is 8HS
30cm is 10HS

15cm lasers should have a size of 5HS.

I also think that weapons perhaps should be able to have fractions of HS as well to balance them a bit better.

In addition to this larger weapons also often get shafted due to not being able to produce enough capacity to synchronise with the 5sec  charge rate per turn. I think that capacity that is over from a previous turn should go into the weapon in the next turn (after it fired) so a weapons might fire in say 4 turns sometimes and 5 turns times. This should even out the benefit of different weapons and make it easier to select a weapon type that best fit the ship you are trying to design. Right now, certain weapons simple are not usable as they synch very badly with the capacitor tech. Take the 20cm laser that is really good at capacitor 5 but really inefficient at any other lever in comparison with a 15cm (even if the size was increased to 5HS) until capacitor 10 where it still is marginally better than a 15cm laser due to its larger size but higher damage and better capacitor tech finally make it better, but not by that much.

In the same spirit perhaps you should be able to fire weapons even more often if you can deliver enough power to do so, like a 10cm lares cold fire twice with a capacitor 6 for example.

You could then also redo how rail-guns work a bit so the capacitor sort of dictate how often they fire rather than they firing 4 shots every time they fire, which seems a bit odd when they fire four shot but only every 20sec instead of one shot every five seconds.

This obviously would effect balance between Gauss and Rail-guns so would have to be handled with great care. I think that Gauss in general are very under powered weapons in general when you compare them with rail-guns, both in therms of technology and cost as rail-guns can use the same fire-control as all other beam weapons while the Gauss require turrets and fast firing fire-controls.

Changing this would also "fix" rail-gun versus Gauss balance as early rail-guns would perhaps only fire ones or twice per turn and increase in speed later on, it would also make rail-guns semi useful for PD even later on.

I think that weapons could be shown with true fire speed rather than per 5 second turns... although the game would make a weapons sometimes fire one or two shots in a turn or more or less turns in between shots.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on February 11, 2020, 10:04:26 AM
Another suggestion for a quality of life type of thing...

Would it be possible to add an supply automatic order for different things to anything produced on a world add will get picked up by the civilian transports.

As far as I remember there was a problem with adding a supply of thing that might not be available. In addition to that it often is more trouble than it is worth to keep adding more and more of something you build allot and just want shipped out to your colonies. Most often this is mines and automatic mines, but it can be other stuff as well.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 11, 2020, 10:33:25 AM
Another suggestion for a quality of life type of thing...

Would it be possible to add an supply automatic order for different things to anything produced on a world add will get picked up by the civilian transports.

As far as I remember there was a problem with adding a supply of thing that might not be available. In addition to that it often is more trouble than it is worth to keep adding more and more of something you build allot and just want shipped out to your colonies. Most often this is mines and automatic mines, but it can be other stuff as well.

You don't have to create matching supply and demand orders. Supply won't get picked up though without matching demand.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 11, 2020, 10:33:42 AM
A suggestion of small balance if it has not been changed already...

I think that the 15cm laser at 4HS is too small, it's general DPS is way to effective very early, especially when you consider that 15cm lasers can have really long range too they are extremely effective in general in comparison with most other lasers. They often even can compete with high damage lasers in terms of cutting through enemy ship armour through cheer DPS, almost no other laser can do this as effective as the 15cm.

10cm is 3HS
12cm is 4HS
15cm is 4HS
20cm is 6HS
25cm is 8HS
30cm is 10HS

15cm lasers should have a size of 5HS.

I also think that weapons perhaps should be able to have fractions of HS as well to balance them a bit better.

In addition to this larger weapons also often get shafted due to not being able to produce enough capacity to synchronise with the 5sec  charge rate per turn. I think that capacity that is over from a previous turn should go into the weapon in the next turn (after it fired) so a weapons might fire in say 4 turns sometimes and 5 turns times. This should even out the benefit of different weapons and make it easier to select a weapon type that best fit the ship you are trying to design. Right now, certain weapons simple are not usable as they synch very badly with the capacitor tech. Take the 20cm laser that is really good at capacitor 5 but really inefficient at any other lever in comparison with a 15cm (even if the size was increased to 5HS) until capacitor 10 where it still is marginally better than a 15cm laser due to its larger size but higher damage and better capacitor tech finally make it better, but not by that much.

In the same spirit perhaps you should be able to fire weapons even more often if you can deliver enough power to do so, like a 10cm lares cold fire twice with a capacitor 6 for example.

You could then also redo how rail-guns work a bit so the capacitor sort of dictate how often they fire rather than they firing 4 shots every time they fire, which seems a bit odd when they fire four shot but only every 20sec instead of one shot every five seconds.

This obviously would effect balance between Gauss and Rail-guns so would have to be handled with great care. I think that Gauss in general are very under powered weapons in general when you compare them with rail-guns, both in therms of technology and cost as rail-guns can use the same fire-control as all other beam weapons while the Gauss require turrets and fast firing fire-controls.

Changing this would also "fix" rail-gun versus Gauss balance as early rail-guns would perhaps only fire ones or twice per turn and increase in speed later on, it would also make rail-guns semi useful for PD even later on.

I think that weapons could be shown with true fire speed rather than per 5 second turns... although the game would make a weapons sometimes fire one or two shots in a turn or more or less turns in between shots.

I don't want to change weapons very much as I am happy with the balance right now. For example, a laser firing once in a turret has a similar effect to a fixed railgun firing four times. Fixed railguns have the advantage that they function as both offensive and defensive weapons but fixed lasers have greater range. If you allow the laser to fire twice, that makes the railgun far less effective in comparison.

However, I agree about the laser size progression. I've changed the rounding on laser HS from Floor to Nearest Int, which moves the 15cm from 4 HS to 5HS. This also changes 30cm from 9 HS to 10 HS and 40cm from 12 HS to 13 HS. I considered round to a decimal place (which would make the progression 3.4, 4, 4.9, 6.3, 8, 9.8, etc.) but it just doesn't look right :) so I decided to leave it as whole HS for now.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on February 11, 2020, 01:13:06 PM
I don't want to change weapons very much as I am happy with the balance right now. For example, a laser firing once in a turret has a similar effect to a fixed railgun firing four times. Fixed railguns have the advantage that they function as both offensive and defensive weapons but fixed lasers have greater range. If you allow the laser to fire twice, that makes the railgun far less effective in comparison.

However, I agree about the laser size progression. I've changed the rounding on laser HS from Floor to Nearest Int, which moves the 15cm from 4 HS to 5HS. This also changes 30cm from 9 HS to 10 HS and 40cm from 12 HS to 13 HS. I considered round to a decimal place (which would make the progression 3.4, 4, 4.9, 6.3, 8, 9.8, etc.) but it just doesn't look right :) so I decided to leave it as whole HS for now.

Yes... I agree about the balance would need to be looked over and it might be a bit much at this stage. Perhaps sometime in the future...

One thing you "might" look into though I think is the capacitor able to overflow to the next turn. It would reduce some weapons being more or less impractical as there are no capacity levels that make them viable over other choices.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on February 11, 2020, 07:57:46 PM
Another suggestion for a quality of life type of thing...

Would it be possible to add an supply automatic order for different things to anything produced on a world add will get picked up by the civilian transports.

As far as I remember there was a problem with adding a supply of thing that might not be available. In addition to that it often is more trouble than it is worth to keep adding more and more of something you build allot and just want shipped out to your colonies. Most often this is mines and automatic mines, but it can be other stuff as well.

You don't have to create matching supply and demand orders. Supply won't get picked up though without matching demand.

In VB6 if you supplied something and there was nothing to load you keep getting an error message that it can't load and interrupts... it also would lower the supplied item with one even though it did not load anything.

Will this work differently in C#?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 12, 2020, 05:06:37 AM
Another suggestion for a quality of life type of thing...

Would it be possible to add an supply automatic order for different things to anything produced on a world add will get picked up by the civilian transports.

As far as I remember there was a problem with adding a supply of thing that might not be available. In addition to that it often is more trouble than it is worth to keep adding more and more of something you build allot and just want shipped out to your colonies. Most often this is mines and automatic mines, but it can be other stuff as well.

You don't have to create matching supply and demand orders. Supply won't get picked up though without matching demand.

In VB6 if you supplied something and there was nothing to load you keep getting an error message that it can't load and interrupts... it also would lower the supplied item with one even though it did not load anything.

Will this work differently in C#?

In C#, you will get an event but not an interrupt. If nothing is there, the pickup code doesn't execute.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on February 12, 2020, 09:40:17 AM
Another suggestion for a quality of life type of thing...

Would it be possible to add an supply automatic order for different things to anything produced on a world add will get picked up by the civilian transports.

As far as I remember there was a problem with adding a supply of thing that might not be available. In addition to that it often is more trouble than it is worth to keep adding more and more of something you build allot and just want shipped out to your colonies. Most often this is mines and automatic mines, but it can be other stuff as well.

You don't have to create matching supply and demand orders. Supply won't get picked up though without matching demand.

In VB6 if you supplied something and there was nothing to load you keep getting an error message that it can't load and interrupts... it also would lower the supplied item with one even though it did not load anything.

Will this work differently in C#?

In C#, you will get an event but not an interrupt. If nothing is there, the pickup code doesn't execute.

Ok... that sounds good... I just wonder what happen if I say supply Automatic Mines on two planets but only one have any available. Will ships that are about to pick something up check if there actually is something there and go to the other planet?

I could have two planets, perhaps in the same system producing mines both with a supply order far above what it can supply so I don't have to deal with it as often. They both supply mines to colonies far from the system. So ships don't go to just one planet (the closest) and just wait until it delivers while there are plenty on another planet just a few hundred million km away, or simply that you waste alloy of transport ships on waiting to be supplied instead of doing something else.
 
I just hope it covers all the bases... would be awesome if I did not have to bother about things that you are mass producing for the colonies in the central systems.  :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on February 12, 2020, 12:53:00 PM
I'm pretty sure that when Steve talked about the way he overhauled the code for civilians and their trading, it included a bit where they are aware of each other. It's not exactly the same as what you're asking, though, but it's close.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on February 13, 2020, 07:27:44 AM
Tinkering with VB6 last night and had an RP thought/suggestion:

I have never noticed but once Commanders die/retired/KIA, are they still viewable in an inactive file or are they gone forever?  If possible, I wonder if it would be possible for those Commanders to shift to a past Commander tab so their accomplishments and lives (records, medals, comments) are still viewable?  I tend toward paying a lot of attention to my Commanders to the point of entering in comments on their actions and lives essentially creating a fictional story/universe as  I go with these guys and when they eventually move on, I would like to go back and see who came before the present generation and what they did.  Maybe even name a new colony world or warship (ex: 'TFNS Steve Walmsley') off a past Commander of renown and this function would make the record keeping for such a lot easier.
Title: Re: C# Aurora v0.x Suggestions
Post by: StarshipCactus on February 13, 2020, 08:27:28 AM
Quote from: Kristover link=topic=9841. msg118825#msg118825 date=1581600464
Tinkering with VB6 last night and had an RP thought/suggestion:

I have never noticed but once Commanders die/retired/KIA, are they still viewable in an inactive file or are they gone forever?  If possible, I wonder if it would be possible for those Commanders to shift to a past Commander tab so their accomplishments and lives (records, medals, comments) are still viewable?  I tend toward paying a lot of attention to my Commanders to the point of entering in comments on their actions and lives essentially creating a fictional story/universe as  I go with these guys and when they eventually move on, I would like to go back and see who came before the present generation and what they did.   Maybe even name a new colony world or warship (ex: 'TFNS Steve Walmsley') off a past Commander of renown and this function would make the record keeping for such a lot easier.


Another cool feature of such a record would be posthumous medal awarding.  So you might have a medal for officers KIA.  You could also have service medals that you award based on number of years served.  That poor LT who stubbed his toe and had to retire after 1 year won't get anything, but your long serving 60+ year old admiral would get a long service medal after getting too old to work.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tikigod on February 13, 2020, 09:57:20 AM
Another suggestion for a quality of life type of thing...

Would it be possible to add an supply automatic order for different things to anything produced on a world add will get picked up by the civilian transports.

As far as I remember there was a problem with adding a supply of thing that might not be available. In addition to that it often is more trouble than it is worth to keep adding more and more of something you build allot and just want shipped out to your colonies. Most often this is mines and automatic mines, but it can be other stuff as well.

You don't have to create matching supply and demand orders. Supply won't get picked up though without matching demand.

In VB6 if you supplied something and there was nothing to load you keep getting an error message that it can't load and interrupts... it also would lower the supplied item with one even though it did not load anything.

Will this work differently in C#?

In C#, you will get an event but not an interrupt. If nothing is there, the pickup code doesn't execute.

On this note, I don't remember seeing anything about event interrupts mentioned but is there any chance C# will include a option to customise how certain 'day to day' event interruptions are treated?

I got a current campaign where my empire started with a higher number of labs but the economy can't really support running all of them researching during certain larger construction periods like expanding my naval shipyards, or producing high volume of automated mines for early mining colony expansion in my home system, yet "Inactive research Labs" interruption makes progressing game time through these often 1-2 year construction periods a right headache.

Would be nice if there was the option in the event log settings to flag events I know will be occurring but am fine with to stop interrupting time progression, I know in VB there's the option to filter events visually but it was my understanding that it doesn't actually stop them from interrupting time progression?
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on February 13, 2020, 11:44:34 AM
Tinkering with VB6 last night and had an RP thought/suggestion:

I have never noticed but once Commanders die/retired/KIA, are they still viewable in an inactive file or are they gone forever?  If possible, I wonder if it would be possible for those Commanders to shift to a past Commander tab so their accomplishments and lives (records, medals, comments) are still viewable?  I tend toward paying a lot of attention to my Commanders to the point of entering in comments on their actions and lives essentially creating a fictional story/universe as  I go with these guys and when they eventually move on, I would like to go back and see who came before the present generation and what they did.  Maybe even name a new colony world or warship (ex: 'TFNS Steve Walmsley') off a past Commander of renown and this function would make the record keeping for such a lot easier.

This has been in and out a couple times, and the problem is always how to differentiate between the few dozen Officers you care about and the hundreds you don't.  Do they get a tickbox while alive to mark them as special?  Do all dead/retired officers go to a 'pool' for a couple of years before deletion to give you time to note their details?  Do you manually confirm "save or delete" for each dead/retired officer?
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on February 13, 2020, 11:48:21 AM
Naval officers who got promoted X times
Ground officers who participated in X battles (since their promotions are rarer)
Scientists who have been in charge of labs for X years
Administrators who have been leading a colony for X years

It could be similar to the automatic medal process, where the players has a relatively small number of variables to adjust and then the game automatically tracks it. The "In Memoriam" system could, in fact, build on top of the medal system.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on February 13, 2020, 11:49:50 AM
Tinkering with VB6 last night and had an RP thought/suggestion:

I have never noticed but once Commanders die/retired/KIA, are they still viewable in an inactive file or are they gone forever?  If possible, I wonder if it would be possible for those Commanders to shift to a past Commander tab so their accomplishments and lives (records, medals, comments) are still viewable?  I tend toward paying a lot of attention to my Commanders to the point of entering in comments on their actions and lives essentially creating a fictional story/universe as  I go with these guys and when they eventually move on, I would like to go back and see who came before the present generation and what they did.  Maybe even name a new colony world or warship (ex: 'TFNS Steve Walmsley') off a past Commander of renown and this function would make the record keeping for such a lot easier.

This has been in and out a couple times, and the problem is always how to differentiate between the few dozen Officers you care about and the hundreds you don't.  Do they get a tickbox while alive to mark them as special?  Do all dead/retired officers go to a 'pool' for a couple of years before deletion to give you time to note their details?  Do you manually confirm "save or delete" for each dead/retired officer?

The officers wouldn't be in the same listing as the active Commanders.  The suggestion is they be moved to a separate tab for 'Past Officers'.  Certainly, the list would eventually after a 100 years or so be a couple hundred (or more) names long but given the amount of effort I put into them and their backstories, I wouldn't mind having that long list.  Besides, if they're inactive and separate from the active list - preferably on a different page/listing altogether - they aren't really taking any processing power or cluttering up the active screen
Title: Re: C# Aurora v0.x Suggestions
Post by: Tikigod on February 13, 2020, 12:27:03 PM
Tinkering with VB6 last night and had an RP thought/suggestion:

I have never noticed but once Commanders die/retired/KIA, are they still viewable in an inactive file or are they gone forever?  If possible, I wonder if it would be possible for those Commanders to shift to a past Commander tab so their accomplishments and lives (records, medals, comments) are still viewable?  I tend toward paying a lot of attention to my Commanders to the point of entering in comments on their actions and lives essentially creating a fictional story/universe as  I go with these guys and when they eventually move on, I would like to go back and see who came before the present generation and what they did.  Maybe even name a new colony world or warship (ex: 'TFNS Steve Walmsley') off a past Commander of renown and this function would make the record keeping for such a lot easier.

This has been in and out a couple times, and the problem is always how to differentiate between the few dozen Officers you care about and the hundreds you don't.  Do they get a tickbox while alive to mark them as special?  Do all dead/retired officers go to a 'pool' for a couple of years before deletion to give you time to note their details?  Do you manually confirm "save or delete" for each dead/retired officer?

The officers wouldn't be in the same listing as the active Commanders.  The suggestion is they be moved to a separate tab for 'Past Officers'.  Certainly, the list would eventually after a 100 years or so be a couple hundred (or more) names long but given the amount of effort I put into them and their backstories, I wouldn't mind having that long list.  Besides, if they're inactive and separate from the active list - preferably on a different page/listing altogether - they aren't really taking any processing power or cluttering up the active screen

Using VB figures so C# specifics won't be exact given certain changes being made but:

Each Academy generate 5 Officers a year. So even just 5 Academies on your homeworld early on pushes out 25 Officers annually.
So in 10 years you'll be churning out 250 Officers, most of which will likely never have a position and be culled a short few years after being produced after the preset amount of time.
In 100 years you'll have produced yet another 2,500 Officers. Now your list contains probably approximately 2,200 past-officers at a minimum.

Imagine loading up that list of 2,200 names to take a stroll down memory lane.

And that's just from 5 academies.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on February 13, 2020, 12:36:32 PM
Tinkering with VB6 last night and had an RP thought/suggestion:

I have never noticed but once Commanders die/retired/KIA, are they still viewable in an inactive file or are they gone forever?  If possible, I wonder if it would be possible for those Commanders to shift to a past Commander tab so their accomplishments and lives (records, medals, comments) are still viewable?  I tend toward paying a lot of attention to my Commanders to the point of entering in comments on their actions and lives essentially creating a fictional story/universe as  I go with these guys and when they eventually move on, I would like to go back and see who came before the present generation and what they did.  Maybe even name a new colony world or warship (ex: 'TFNS Steve Walmsley') off a past Commander of renown and this function would make the record keeping for such a lot easier.

This has been in and out a couple times, and the problem is always how to differentiate between the few dozen Officers you care about and the hundreds you don't.  Do they get a tickbox while alive to mark them as special?  Do all dead/retired officers go to a 'pool' for a couple of years before deletion to give you time to note their details?  Do you manually confirm "save or delete" for each dead/retired officer?

The officers wouldn't be in the same listing as the active Commanders.  The suggestion is they be moved to a separate tab for 'Past Officers'.  Certainly, the list would eventually after a 100 years or so be a couple hundred (or more) names long but given the amount of effort I put into them and their backstories, I wouldn't mind having that long list.  Besides, if they're inactive and separate from the active list - preferably on a different page/listing altogether - they aren't really taking any processing power or cluttering up the active screen

Using VB figures so C# specifics won't be exact given certain changes being made but:

Each Academy generate 5 Officers a year. So even just 5 Academies on your homeworld early on pushes out 25 Officers annually.
So in 10 years you'll be churning out 250 Officers, most of which will likely never have a position and be culled a short few years after being produced after the preset amount of time.
In 100 years you'll have produced yet another 2,500 Officers. Now your list contains probably approximately 2,200 past-officers at a minimum.

Imagine loading up that list of 2,200 names to take a stroll down memory lane.

And that's just from 5 academies.

I think it would be neat with a checkbox beside any commander if you want to save them past their death or retirement or any commander that you have made manual notes on or when you award a medal to them it could be part of the medal if they get saved for posterity or not.

I agree there are no point in saving all commanders that have made little to no specific impact on your story.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on February 13, 2020, 12:47:20 PM
"Imagine loading up that list of 2,200 names to take a stroll down memory lane."

Well, I just might want too!  But seriously point taken it would be quite a list and perhaps a tag that only those who served more 10 years would be retained so you didn't get the minor officers who didn't make an impact or a check box for those you wished to retain in your 'Past Officer' file would be an adequate compromise to reduce bloat.  In fact, I think I might even like the check box more because lets say I wanted to be crazy and retain 2,000 plus names - I could just check mark all of them at the beginning. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 13, 2020, 01:14:29 PM
C# has a 'story character' flag for commanders. One option is to retain those commanders in a 'KIA' list if they die.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on February 13, 2020, 01:31:51 PM
C# has a 'story character' flag for commanders. One option is to retain those commanders in a 'KIA' list if they die.

I don't think I would personally use the 'story character' flag in my games - I don't really want an 'immortal' commander on the roles who won't die or retire (but can be killed) and rather let your promotion/assignment routine work to churn and rotate and elevate new commanders.  But I would want to save the record of my Fleet Admiral who I watched over 40 years heroically rise through the ranks, discover new worlds and meet new races, and command the Fleet in the Great War before finally retiring.
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on February 13, 2020, 01:34:05 PM
If the idea is to track notable officers, I'd have it track those with a certain minimum promotion point value in medals. Basically, just decorated officers get tracked.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on February 13, 2020, 02:12:09 PM
If the idea is to track notable officers, I'd have it track those with a certain minimum promotion point value in medals. Basically, just decorated officers get tracked.

Promotion score off medals  wouldn’t be a bad way to handle distinction particularly if you had a war hero Lieutenant Commander who goes down in a blaze of glory on his first assignment and earns the ‘Star of the Federation’ for his heroics.  I might want to name a dreadnought off the brave frigate commander.
Title: Re: C# Aurora v0.x Suggestions
Post by: iceball3 on February 13, 2020, 09:25:13 PM
Perhaps a list with "recent retirements/casualties" will save officers and the like for up to two years, with the option to inter them in a permanent "list of honor" manually, or to have a settable value for promotion score or rank that automagically pushes officers to the list of honor, where they can receive posthumous/postcareer medals and are kept with relative safety.
The middle list will have a rough average of around two years worth of officer production in listed names and attributes, but obviously won't be accessed as often as your normal list, which also maintains around two years worth of officer production.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on February 14, 2020, 11:45:28 AM
Naval officers who got promoted X times
Ground officers who participated in X battles (since their promotions are rarer)
Scientists who have been in charge of labs for X years
Administrators who have been leading a colony for X years

It could be similar to the automatic medal process, where the players has a relatively small number of variables to adjust and then the game automatically tracks it. The "In Memoriam" system could, in fact, build on top of the medal system.
A-hem.  ;D

With all the possibilities that the automated medal system allows us, it should be feasible to expand it to save deceased/retired officers within certain criteria.
Title: Re: C# Aurora v0.x Suggestions
Post by: kuhaica on February 15, 2020, 07:13:46 PM
Hey Steve.  So a quick question/suggestion regarding the new Mantience storage bays and other such storage components.  Can it be possible to have a gradual increase in storage efficiency per size increase rather than just a flat liner increase of space directly proportion to the HS used? It's always something that has irked me somewhat in the game where space means everything.     

If I can use 5 Standard Maintenance storage bays or 1 Large storage bay, there is no difference, even though thematically that's 5 separate compartments with walls and all included.  Yet it gives me the exact same space as the large storage bay.  It would simply be nice if there was a gradual increase in storage the larger the size you have, even nicer if it applied to everything with storage mechanics.     


So rather then
Code: [Select]
Large: 2000 MSP, 5HS
Standard: 400 MSP, 1 HS
Small: 80 MSP: 0.2 HS
Tiny: 40 MSP 0.1 HS
Fighter: 20 MSP: 0.05 HS.

It can be a 10%+5% increase per size (rounded nicely)
Code: [Select]
25% Increase Large: 2500: 5 HS
20% Increase Standard: 480: 1 HS
15% Increase Small: 95 MSP: 0.2 HS
10% Increase Tiny: 45 MSP 0.1 HS
Base Fighter 20 MSP: 0.05 HS

A similar such 'formula' if you even want to call it that could be used for Crew Quarters, Fuel Storage and everything else which fits the function.   Effectively making better use of the space with and it feels slightly more realistic than everything being linear.   

Current Fuel
Code: [Select]
Ultra Large: 5,000,000: 100 HS
Very Large: 1,000,000: 20 HS
Large: 250,000: 5 HS
Basic: 50,000: 1 HS
Small: 10,000: 0.2 HS
Tiny: 5,000: 0.1 HS

Suggested Fuel
Code: [Select]
30% Ultra Large: 6,500,000: 100 HS
25% Very Large: 1,250,000: 20 HS
20% Large: 300,000: 5 HS
15% Basic: 57,500?: 1 HS
10% Small: 11,000: 0.2 HS
Tiny: 5,000: 0.1 HS
Title: Re: C# Aurora v0.x Suggestions
Post by: Tikigod on February 15, 2020, 08:05:26 PM
Hey Steve.  So a quick question/suggestion regarding the new Mantience storage bays and other such storage components.  Can it be possible to have a gradual increase in storage efficiency per size increase rather than just a flat liner increase of space directly proportion to the HS used? It's always something that has irked me somewhat in the game where space means everything.     

If I can use 5 Standard Maintenance storage bays or 1 Large storage bay, there is no difference, even though thematically that's 5 separate compartments with walls and all included.  Yet it gives me the exact same space as the large storage bay.  It would simply be nice if there was a gradual increase in storage the larger the size you have, even nicer if it applied to everything with storage mechanics.     


So rather then
Code: [Select]
Large: 2000 MSP, 5HS
Standard: 400 MSP, 1 HS
Small: 80 MSP: 0.2 HS
Tiny: 40 MSP 0.1 HS
Fighter: 20 MSP: 0.05 HS.

It can be a 10%+5% increase per size (rounded nicely)
Code: [Select]
25% Increase Large: 2500: 5 HS
20% Increase Standard: 480: 1 HS
15% Increase Small: 95 MSP: 0.2 HS
10% Increase Tiny: 45 MSP 0.1 HS
Base Fighter 20 MSP: 0.05 HS

A similar such 'formula' if you even want to call it that could be used for Crew Quarters, Fuel Storage and everything else which fits the function.   Effectively making better use of the space with and it feels slightly more realistic than everything being linear.   

Current Fuel
Code: [Select]
Ultra Large: 5,000,000: 100 HS
Very Large: 1,000,000: 20 HS
Large: 250,000: 5 HS
Basic: 50,000: 1 HS
Small: 10,000: 0.2 HS
Tiny: 5,000: 0.1 HS

Suggested Fuel
Code: [Select]
30% Ultra Large: 6,500,000: 100 HS
25% Very Large: 1,250,000: 20 HS
20% Large: 300,000: 5 HS
15% Basic: 57,500?: 1 HS
10% Small: 11,000: 0.2 HS
Tiny: 5,000: 0.1 HS

If this was done I think the existing resource cost advantage (assuming these still exist in C#) between the options should be removed given there will now be actual performance gains, and the performance gains much more subtle given how much of a impact even a 1% or 2% extra bonus can mean for design performance. (Then there is the need to re-evaluate how many size iterations and their contents are actually required now given the scaling gains with multiple modules)

----------

On the subject of fighters, maintenance supplies and component failures I have always wondered if it were possible to have components essentially include basic supplies for one off repairs as part of the size they contribute to the hull design. As it seems daft that the base size consumed by 'general supplies' to support a ship based on deployment time doesn't include anything to do with keeping the ship operational. Maintenance modules would still be needed for larger designs to combat high failure rates and longer deployment times, but smaller craft with very short deployment times could effect at least one off repairs for a module before needing to return to some kind of support dockyard.

It wouldn't strictly be treated as 'Free maintenance supplies' but rather each module that the rule is applied to would have a flag variable that determines if that module can be repaired whilst deployed with no supply cost, once the first repair is made the flag then switches and future repairs consume supplies until the ship returns to some kind of supporting structure that can then reset the flag. This would need to be restricted to only particular types of modules to stop it being too silly though.
Title: Re: C# Aurora v0.x Suggestions
Post by: bankshot on February 17, 2020, 09:37:24 PM
For the Intelligence section - class design summary.  In VB Aurora this is populated upon a successful interrogation (or I suppose a capture of a ship).  Salvage doesn't seem populate this tab (at least not so far for me).

Proposal:  when you successfully salvage a part from a wrecked ship add that part to a list of parts on this tab, creating a partial summary.  It won't be a complete summary unless you salvage enough wrecks to put together the full jigsaw, but it could at least accumulate the data you've gathered in one spot.  You could even extrapolate a bit based on observed thermal signature and speed and a salvaged engine the total number of engines could be predicted.  Ditto EM signature and shields. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Alsadius on February 18, 2020, 11:59:05 AM
Isn't the usual approach that larger designs are more cost-efficient, but no more space-efficient? That works fine for me.
Title: Re: C# Aurora v0.x Suggestions
Post by: Saros on February 19, 2020, 10:12:20 AM
Quote from: Saros link=topic=9841. msg118445#msg118445 date=1580484964
Hi Steve, is there any plan for greater ability to manipulate ruins, and the various spoiler spawns? It would be a great tool to have for 'Lets play' or forum run games to be able to spawn/edit ruins and precusrors from spacemaster mode. 

Also is it possible to be able to have a toggle to make the game 'locked' without the spacemaster password.   i.  e.   you can't advance time without entering it.   Would help greatly with said forum games by being able to provide the save to players without worrying about them zooming forward in time.

Hey Steve, sorry if I missed it but did you have any 2c on these?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 19, 2020, 01:15:00 PM
Quote from: Saros link=topic=9841. msg118445#msg118445 date=1580484964
Hi Steve, is there any plan for greater ability to manipulate ruins, and the various spoiler spawns? It would be a great tool to have for 'Lets play' or forum run games to be able to spawn/edit ruins and precusrors from spacemaster mode. 

Also is it possible to be able to have a toggle to make the game 'locked' without the spacemaster password.   i.  e.   you can't advance time without entering it.   Would help greatly with said forum games by being able to provide the save to players without worrying about them zooming forward in time.

Hey Steve, sorry if I missed it but did you have any 2c on these?

There is a random ruin button on the System View. Nothing more specific than that yet. I'll try to sort something out post-launch when I start trawling through the suggestion thread.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on February 21, 2020, 11:46:22 AM
Two ideas:

A) Stealth Jump: can only self-jump and jump will land at least 3mkm outside of Target jump point. Maybe increaseable by tech line to keep up with better sensor tech.
The drive needs special stealth jump tech, which limits the max size of a ship using it drastically - and uses a lot of resources. So you‘ll be basically limited to small submarine scouts or very weak attack ships who are able to stealth jump. Idea is to be capable of more secret elint collection as well as having to perform more patrols around your own defenses to be sure, nobody is listening... .

B) New Race factor: work morale. Values: 0 to 100. 0 halves the amount of work a population is capable of doing, 100 doubles the amount. Additionally an Option list where you can set the amount of workers used for factory production: same login from 0 to 100.
Goal is to be able to have a larger variety of races as well as options of using your workforce. In early game you usually have too many unused workers, so increasing the amount of people who would work in a shipyard would help building those ships faster. Later, when you have trouble getting enough workers, you can play with those numbers to optimize your empire workforce.
It basically always bugged me that every race you created was totally equal in terms of production... . This way, some races can be power houses for production and other be the more chilled work mules. Depending a bit on roleplay style... .
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on February 21, 2020, 11:55:08 AM
Your B is already in:
http://aurora2.pentarch.org/index.php?topic=8495.msg100712#msg100712 (http://aurora2.pentarch.org/index.php?topic=8495.msg100712#msg100712)

Quote from: Steve Walmsley
New Species Attributes

Each Species now has four new attributes, all of which default to 1.0 but have a low chance to be higher or lower:

1) Population Growth Rate Modifier
2) Population Density Modifier. This affect max population capacity, infrastructure capacity and orbital habitat capacity. Some species prefer more open environments while some can accept higher population densities than normal.
3) Research Rate Modifier (increases or decreases research rate)
4) Production Rate Modifier (affects factories, refineries and shipbuilding)

Player-created Species can have custom values set. Also note this is at the species level, not the empire level. Empire modifiers to Research or Production are based on technology rather than innate ability.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on February 22, 2020, 04:57:40 AM
Your B is already in:
http://aurora2.pentarch.org/index.php?topic=8495.msg100712#msg100712 (http://aurora2.pentarch.org/index.php?topic=8495.msg100712#msg100712)
Ah, that‘s nice... thanks.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on February 22, 2020, 07:31:00 AM
In VB6 Aurora when you copied a Class Design the Class Priority wasn't copied to the new design. Intentional? Otherwise it would be nice if it was copied.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 22, 2020, 09:09:49 AM
In VB6 Aurora when you copied a Class Design the Class Priority wasn't copied to the new design. Intentional? Otherwise it would be nice if it was copied.

In VB6 every field had to be copied manually in code so it was easy to miss something, or add a new field and forget to update the copy code.

In C#, you can clone an object, which will replicate every value-based member of that object. If new values are added later, they will still be copied by the older code. Anything reference-based (the address of another object rather than the object itself) is more of an issue as the reference is copied rather than the object, so that needs more care - still far better than VB6 though.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on February 22, 2020, 12:03:37 PM
I seem to be spending a lot of time rearranging systems on the galactic map to please my aesthetic sensibilities, so could we please have a box to specify the XY coordinates of systems on the galactic map when moving them around? It's a bit of a hassle right now. Actually, since the Real Stars catalogue in the game already include the XYZ coordinates of all stars, an option to snap them to their actual positions on the map would also work.
Title: Re: C# Aurora v0.x Suggestions
Post by: clement on February 22, 2020, 12:57:23 PM
In VB6 Aurora when you copied a Class Design the Class Priority wasn't copied to the new design. Intentional? Otherwise it would be nice if it was copied.

In VB6 every field had to be copied manually in code so it was easy to miss something, or add a new field and forget to update the copy code.

In C#, you can clone an object, which will replicate every value-based member of that object. If new values are added later, they will still be copied by the older code. Anything reference-based (the address of another object rather than the object itself) is more of an issue as the reference is copied rather than the object, so that needs more care - still far better than VB6 though.

Steve, a quick and easy way to solve the deep cloning issue is to serialize the object to JSON, then deserialize it back into a new instance. At runtime, it is not quite as fast as manually transferring/mapping all the fields and handling the same for all the reference types, but it is faster and less prone to bugs of omission during development.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 22, 2020, 01:15:32 PM
I seem to be spending a lot of time rearranging systems on the galactic map to please my aesthetic sensibilities, so could we please have a box to specify the XY coordinates of systems on the galactic map when moving them around? It's a bit of a hassle right now. Actually, since the Real Stars catalogue in the game already include the XYZ coordinates of all stars, an option to snap them to their actual positions on the map would also work.

Except the map is 2D and the coordinates are 3D :)

I'll take a look at this but probably post-release,
Title: Re: C# Aurora v0.x Suggestions
Post by: jonw on February 22, 2020, 02:31:42 PM
Here's a thought - would it be possible to have the option of setting civilian admin positions as elected? As it is now, every position is appointed and serves indefinitely, this feels appropriate for feudal or authoritarian RP but not so much a democracy. A democratic process means I can't manually alllocate the min-maxed best commanders and would enable convenient RP of having limited term lengths and not having full control of a civilian process.

Kind of like, every all civilian positions are appointed except where a colony has a population over X where it acquires electoral rights, and then self-generates random admin officers after term length. More senior admin commands are randomly 'elected' from the total pool of candidates from lower level positions. Obviously a lot of work has gone into the career for naval officers, it would be cool to have something similiar for civilians.

Thanks!
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on February 22, 2020, 02:57:03 PM
That would break the academy mechanic, due to conjuring civilian administrators out of thin air.
Title: Re: C# Aurora v0.x Suggestions
Post by: jonw on February 22, 2020, 03:16:58 PM
Do you mean there would be balance issues with this since academies no longer have a necessary function for generating civilian commanders, or that this would impede implementation in code somehow?
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on February 22, 2020, 06:35:55 PM
Only Steve can comment on the code issue, but yes, this would break the academy game balance due to no longer generating civilian commanders.

One of the things that is fairly important on the civilian side is managing the bonuses the various administrators give you. A 5% boost to your construction rates is useful but not very impressive, yet when that means your 1000 construction factories are now 1050 construction factories it's something you notice. A 40% boost however is all sorts of absurd, turning 1000 factories into 1400 factories is even better. On the other hand, having a construction bonus on a planet that has no construction efforts whatsoever is inconvenient, especially when you can't reassign the fool to a job better suited to them.

Cheesing high skill administrators is partially managed by civilian administrators being less numerous so less chance of getting that exact match of skills you want, and by the fact that the civilian administrators like scientists have an administration rating. There is actually a limit to how large a combined population an administrator can administer. This limit can be partially circumvented by playing games with the population numbers as that limit is checked only when assigning, not during normal operation like during a construction update.

At the same time, the game does assume during standard progression that you are generally making good use of your administrators, and the pace with which NPRs progress is supposed to match that. Failing to meet that expectation can impact your nation's success.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on February 22, 2020, 06:56:43 PM
I don't really see that it would break anything, since presumably if they were truly random then you would be getting stuck with some truly horrifically bad administrators at times.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on February 23, 2020, 01:26:02 AM
In VB6 I don't think there is a menu entry for the "Geological Survey Report" - I only could access that window through the "System Maps" screen, the button at the top. Can we have a main menu entry for that window in C#?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 23, 2020, 07:40:08 AM
In VB6 I don't think there is a menu entry for the "Geological Survey Report" - I only could access that window through the "System Maps" screen, the button at the top. Can we have a main menu entry for that window in C#?

There is no main menu in C# :)

The main window is the Tactical Map. Everything is accessed via that.
Title: Re: C# Aurora v0.x Suggestions
Post by: jonw on February 23, 2020, 08:05:27 AM
...presumably if they were truly random then you would be getting stuck with some truly horrifically bad administrators at times.

Thats kind of what I mean - for a military or totalitarian hierarchy, appointing the best man for the job makes sense, but for a democratic hierarchy, you have to make do with who you've got, and the choice is not often made by the electorate to prioritize what we as players would prioritize. The appointed routes makes perfect sense for some RP styles, but it would be nice to have some way of reflecting either a more fully realized civil service career (ie. an individual does not remain at the same post until retirement, but gets promoted according to some reasonable ruleset a la naval commanders), or some way of representing an electoral process to aid RP.

Actually I suppose the same could be said for a feudal RP - the player maight appoint the 1st Grand Duke of Mars who will rule until retirement, but then the player shouldn't be able to choose the second dynastic heir? My ck2 interest might be showing
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on February 23, 2020, 10:30:29 AM
Thats kind of what I mean - for a military or totalitarian hierarchy, appointing the best man for the job makes sense, but for a democratic hierarchy, you have to make do with who you've got, and the choice is not often made by the electorate to prioritize what we as players would prioritize.

No, any form of government always tries to appoint the most appropriate people to the job. It's just that the criteria of what makes someone the most appropriate person to be appointed differs because different people, different groups of people and different ideologies have different ideas as to what is required to be a good holder of the office.

In hierarchies decided by election, the decision of who ends up appointed is based on who manages to convince the most people who can cast a vote and the group to make the selection is usually large enough that you have to deliberately campaign for the position and a refusal will usually be accepted if you didn't run for the position. In hierarchies decided by appointment, the decision is made by whoever may appoint anybody they like and refusing is usually not possible or at least a lot harder.
Title: Re: C# Aurora v0.x Suggestions
Post by: jonw on February 23, 2020, 11:11:16 AM
No, any form of government always tries to appoint the most appropriate people to the job.

I think we might be speaking at crosspurposes here. I can imagine that the civilian adminstrator of a comet mining colony is a directly appointed civil serveant, fair enough - picking the guy with the best mining skill is a no-brainer, that colony represents a commercial not political interest and this is clearly a job best given to professionals who may serve professionally in that role for a long period of time. However, the governor of a 100m colony on the moon is not a civil serveant but a political figure in charge of a very large nation in modern real terms. Under most democratic government, this bloke would serve limited terms. If I am roleplaying as a democracy, I can't really imagine what the civilian administrators represent - are they elected politicians or senior civil serveants? is the governor of earth a presidential figure or the equivalent of like permanent undersecretary of some ministry?

As a player, I might want a governor who is going to increase construction and pop growth, and I would want that guy to serve indefinitely and get better over time. However, under a political process, the 100m electorate of the lunar colony might want to prioritize something else for their own local reasons which may appear irrational to the player (brexit? the lunar colony clearly needs shipyard bonii even though there are no shipyards, thats a campaign promise you can believe in!). And then 5 years in the future, the agenda would change, and a different set of debately releveant priorities would emerge.

Under the c# command rules, ships can have multiple officers and we have several commands over them. It might be fun to add a similiar level of complexity to civilian adminstrators, with some delineation between permanent appointed civil serveants working in professional roles, and temporary elected roles for colonies with larger population, or both on the same colony.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on February 23, 2020, 12:24:32 PM
However, the governor of a 100m colony on the moon is not a civil serveant but a political figure in charge of a very large nation in modern real terms. Under most democratic government, this bloke would serve limited terms. If I am roleplaying as a democracy, I can't really imagine what the civilian administrators represent - are they elected politicians or senior civil serveants? is the governor of earth a presidential figure or the equivalent of like permanent undersecretary of some ministry?

The "Governor of Earth" is clearly a senior civil servant -- a Permanent Under-Scretary of State for <whatever> in Westminster-style democracies -- though I am going to use circular reasoning to assert that. . .  Because said governor is not replaced every election, and is not the one deciding 'build more construction factories, pause fuel production, etc.'

We the player are the elected governement, the Minister for Mining & Minerals or whoever.  The Civiilian Administator is responsible for carrying out our policies as efficiently as possible.  Ergo, senior civil servant.
Title: Re: C# Aurora v0.x Suggestions
Post by: jonw on February 23, 2020, 12:54:05 PM
We the player are the elected governement, the Minister for Mining & Minerals or whoever.  The Civiilian Administator is responsible for carrying out our policies as efficiently as possible.  Ergo, senior civil servant.

As you say, your reasoning is obviously circular here. If this is true, it would make sesne to have multiple administrators per colony to represent a broad staff of specialists, rather than 1 named person. There is a paralell in the c# naval command+control rules for this, in that now ships can have multiple lower ranking officers.

There is not one democracy I can imagine that would entrust the management of a multiple millions of people to 1 civil serveant, and if they did, any such single figure would become a de facto monarch very quickly, rather than a member of a civil service. The closest parallel I can think of to this would be proconsuls in the roman republic, but even their authority was time-limited.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on February 23, 2020, 01:02:28 PM
I think we might be speaking at crosspurposes here. I can imagine that the civilian adminstrator of a comet mining colony is a directly appointed civil serveant, fair enough - picking the guy with the best mining skill is a no-brainer, that colony represents a commercial not political interest and this is clearly a job best given to professionals who may serve professionally in that role for a long period of time. However, the governor of a 100m colony on the moon is not a civil serveant but a political figure in charge of a very large nation in modern real terms. Under most democratic government, this bloke would serve limited terms. If I am roleplaying as a democracy, I can't really imagine what the civilian administrators represent - are they elected politicians or senior civil serveants? is the governor of earth a presidential figure or the equivalent of like permanent undersecretary of some ministry?

As a player, I might want a governor who is going to increase construction and pop growth, and I would want that guy to serve indefinitely and get better over time. However, under a political process, the 100m electorate of the lunar colony might want to prioritize something else for their own local reasons which may appear irrational to the player (brexit? the lunar colony clearly needs shipyard bonii even though there are no shipyards, thats a campaign promise you can believe in!). And then 5 years in the future, the agenda would change, and a different set of debately releveant priorities would emerge.

Under the c# command rules, ships can have multiple officers and we have several commands over them. It might be fun to add a similiar level of complexity to civilian adminstrators, with some delineation between permanent appointed civil serveants working in professional roles, and temporary elected roles for colonies with larger population, or both on the same colony.

Actually, that guy in charge of a comet mining facility that is appointed?

Might not have a mining bonus. He might have a big enough political bonus however that rates how good he is at convincing the people making the decision that he is either knowledgeable enough or reliable and loyal enough to the people assigning him put him there for a variety of reasons, up to and including him being much less likely to cause a problem than mister rebellious mining genius who could also be assigned.

Or he might have screwed up so badly for whatever reason at a colony that despite his clear competence in managing shipbuilding projects he is kicked to a forgettable corner of the nation so that tempers can cool.


When political decision making gets involved, skill and competence often compete with how much the people making the decision think they themselves benefit or suffer from that decision. Assigning a mining genius to a colony whose main economical sector is mining may sound like a no brainer, but you may want them somewhere else for a number of different reasons.


That elected official of the Luna colony with the shipbuilding bonuses probably wouldn't be elected if he runs on a shipbuilding platform unless the Luna colony itself wants to do shipbuilding. It might also be that he ran on a manufacturing platform, which he may or may not be competent in but convinced enough people it was a good idea to elect him on that basis.

Simulating the political process and prioritization of a nation would be quite difficult and involved, while leaving it entirely randomized would be frustrating because of how powerful the bonuses can get, and how much a new roll of the dice can and most likely will skewer your long term plans. It's not helped by the fact that the game actually has a fairly slow pace on the strategic layer; ships often take a year or more to build, so you have to plan ahead by several years at a minimum just to be confident that you will have what you need at that point in time. If an election in the middle of that period craters mining of a critical mineral you need to build and maintain your ships and facilities, or majorly slows down ship construction so that every slip you could use is occupied and yet need to do major maintenance and refits in slips that should've been cleared and idle months earlier, that gets really annoying.

And sure, if you can assign administrators long term to a colony they can keel over dead and leave you with the same problem, but in that case you at least have the option of reassigning other administrators to plug the gap and catch the damage. That's not something you can do with what's effectively a randomized bonus selection system that allows no attempt to mitigate the damage without needing to completely overhaul your entire nation's building and personnel distribution.

It'd be less bad if the bonuses couldn't stack up so massively. Losing a 5% bonus is inconvenient but something you can cover for. Losing a 20% bonus is crippling.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on February 23, 2020, 01:16:10 PM
The admin side has slowly grown over the years - your Fleet Admiral used to be your Civilian Administrator at the same time. I'd be happy wit growing the civilian administrator side, feature-wise, post C# release at some point and yeah, incorporating some elements from Crusader Kings and Stellaris, for example, could be useful.

As it is, you can RP your admin staff the way you want and I'd like to maintain that freedom. Your planetary governor can be your elected president in one game and a permanently appointed civil servant in another game and the executive program that your AI Hivemind obeys in a third. Any mechanisms added to it should be flexible.

For balance, I don't think it matters. Sure, the admin bonuses can get huge and in an even knife-fight they can be the difference between life and death, but that's a rare occasion. After all, it's entirely possible to have a successful game without any leaders whatsoever.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rabid_Cog on February 24, 2020, 07:15:15 AM
If you want to roleplay a democracy, just manually reassign whichever governor has the highest administration to each position every 5/10/whatever years. Bam. Instant democracy. Clearly "Administration skill" is a proxy for how many people are willing to follow this bloke and therefore his popularity.
Title: Re: C# Aurora v0.x Suggestions
Post by: Alsadius on February 24, 2020, 09:23:33 AM
That would break the academy mechanic, due to conjuring civilian administrators out of thin air.

Not necessarily. You just have an election take place between existing admins. Heck, for a really basic system, you could just pick two admins of appropriate level at random, and let the player pick between them.

You can get into more advanced election mechanics - Victoria 2 comes to mind, since I've been re-playing that recently - but it's really not necessary, and it'd probably be a lot of work.
Title: Re: C# Aurora v0.x Suggestions
Post by: Shuul on February 25, 2020, 08:55:08 AM
Is it possible to get a new game parameter to configure energy weapon breakdowns chance? Reading from the post for me they seem to be too frequent (and too costly in MSP) and I would like to somehow change this.
Title: Re: C# Aurora v0.x Suggestions
Post by: spudman1996 on February 25, 2020, 10:31:39 AM
On the Research section, change "Completion Date" to "Days to Completion".
And use "Days to Completion" in ascending mode.   

It is truly irritating to have the dates spread all over the board.     
Title: Re: C# Aurora v0.x Suggestions
Post by: Alsadius on February 25, 2020, 11:32:00 AM
On the Research section, change "Completion Date" to "Days to Completion".
And use "Days to Completion" in ascending mode.   

It is truly irritating to have the dates spread all over the board.   

Or use Completion Date ascending, for a similar effect.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 25, 2020, 11:55:25 AM
Is it possible to get a new game parameter to configure energy weapon breakdowns chance? Reading from the post for me they seem to be too frequent (and too costly in MSP) and I would like to somehow change this.

I may change the frequency of breakdown based on play test (as I already did from 2% to 1%) but the breakdown itself won't be an option.

The breakdown is to counter the ability of beams to penetrate atmosphere in C#. Otherwise, you could simply kill everything on a planet from orbit given sufficient time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 25, 2020, 12:16:14 PM
On the Research section, change "Completion Date" to "Days to Completion".
And use "Days to Completion" in ascending mode.   

It is truly irritating to have the dates spread all over the board.   

Or use Completion Date ascending, for a similar effect.

The projects are sorted by number of facilities descending. I've added an option to sort by completion date ascending.
Title: Re: C# Aurora v0.x Suggestions
Post by: L0ckAndL0ad on February 26, 2020, 12:31:39 PM
Target Tracking Bonus from Multiple Sensors

I propose to give a slight bonus to target tracking (accuracy) based on the amount of sensors tracking the target. As ships are separated from one another and presumably data-linked into a single combat network create an array of radars and processing computers, having multiple radars tracking the target should allow some advanced processing techniques that can get you better accuracy. Or, this could be used somewhat differently, in terms of having more raw computing power being distributed among several ships simultaneously, allowing faster calculations, and maybe even better resolution(?). But a simple + accuracy bonus should do fine.

A bonus cap is required, obviously. Currently implemented solution for existing time/tracking bonus should work here just as well, I guess.

Why do this?
I was thinking about my older ship and fighter designs and future, more optimized designs, and when considering their sensor equipment I realized there's not that much purpose to have many sensors within the same formation of ships, except for redundancy. Why not figure a way to change that?. Giving an accuracy bonus for each radar in the formation (or all in the vicinity) will give an incentive to have sensors on all your ships (counter to "radarless designs meta"), while still being limited by the price of such equipment.

This is a reality-based idea that should promote realistic behavior and give an alternative to "pure meta" designs.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on February 27, 2020, 11:36:39 AM
I like it and I support it, especially if we can control individual active sensors instead of all or none. Currently, all sensors are on or all sensors are off on a hull.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on February 27, 2020, 01:10:54 PM
I like it and I support it, especially if we can control individual active sensors instead of all or none. Currently, all sensors are on or all sensors are off on a hull.

Steve said C# Aurora would fix that, and you could turn individual sensors on and off, but I can't find a post in the Changes List indicating he's done it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tikigod on February 27, 2020, 10:34:23 PM
Bit of a niche use request, but a little check box on the production/colony management screen that allows us to mark a colony to be automatically abandoned once devoid of all population and installations would be kind of nifty.  ;D
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on February 28, 2020, 02:40:53 AM
Bit of a niche use request, but a little check box on the production/colony management screen that allows us to mark a colony to be automatically abandoned once devoid of all population and installations would be kind of nifty.  ;D

There is a button to delete all colonies that fall into that category.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on February 28, 2020, 12:40:00 PM
Looking at the various bonuses and admin HQ types, is it possible to have add an 'Intelligence' Admin Command type with 25% bonus to Intelligence and Reaction or Engineering as the bonus types?  This would facilitate creating our own intelligence directorates for our Fleets.  I want my Section 31.
Title: Re: C# Aurora v0.x Suggestions
Post by: Conscript Gary on March 04, 2020, 12:10:35 PM
I seem to be spending a lot of time rearranging systems on the galactic map to please my aesthetic sensibilities, so could we please have a box to specify the XY coordinates of systems on the galactic map when moving them around? It's a bit of a hassle right now. Actually, since the Real Stars catalogue in the game already include the XYZ coordinates of all stars, an option to snap them to their actual positions on the map would also work.

Except the map is 2D and the coordinates are 3D :)

I'll take a look at this but probably post-release,

I believe he means a way to set the position of a system in the map's 2d coordinate system, not converting the 3d stellar coordinates into anything. An input box that moves a selected system to that map spot exactly.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on March 05, 2020, 06:04:14 PM
So I'm playing a game of 7.1, and caught myself doing the same thing over and over, that I've often done, but hardly ever think of.

When I am designing ships and technology, I create two techs for every single component design where its new to my current game or a different size/needs than prior parts have.  One is just a component like any other, used like any other, to be researched and produced as regular ship components.

The other is a "prototype" part, and under a house rule, is not produced, which I instant research, so it can be used to design with, I put "prototype" in front of the name to indicate that.

This lets me fully design a ship, missile, or turret all the way to the point of being able to produce it, without having to wait for potentially months or years of research to finish before I can find out I'm a dolt and need to rework my design.  I simply do not produce them until I have done the research on the parts along the way, but I gain the ability to spot the need to make changes before I have wasted the time researching them.

I'm sure many of us have been here before.  You want a new warship with a turreted weapon, lets say, gauss guns for PD.  You pick a type, research it.  Then you make the turret, research it.  Then you go to make the ship, and only one turret fits, two is so close but not quite—the crew (or reactors for other weapons) cost you too much.  You could wait for the slipway to be enlarged, in which case the ship will need new/more engines or be slower because its bigger.  Or you wait for a slightly smaller turret that will fit to be researched, say by reducing turret armor, or reducing the turret tracking speed by a small amount to shrink it a little bit.

Or you design a gauss gun, get the tech for it, have the tech available as a prototype component so you can design the turret, which itself is available as a prototype component, and see before any time is wasted researching components that it needs to be made a little smaller, change it, and then begin research with a workable turret.


So, the request, if we could get two things:

A new button in the research window, to generate a prototype part from a research project, which would work on any technology which generates a component - so all the racial techs and things like damage control, ecm, fuel tanks, etc.  Only current research prjects should be available for prototyping—if all you have is 10cm lasers, then no prototyping 80cm advanced spinals yet, but you could prototype a 12cm laser since its the next project in the laser line of techs, and would be a currently available research project.

When the associated technology completes which yields the component that the prototype is substituting for, replace the prototype component in the design with the real one so players who are just getting started on a large construction project don't have many parts to track down and replace one by one.

Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on March 06, 2020, 02:39:37 AM
Hey... what if Plasma Carronades were like super-short ranged Particle Beams? In that they have no damage drop off? Particle Beams are longer ranged than Lasers and do full damage out to their maximum range, but lasers do more damage in close. So what if Plasma Carronades were the inverse of Particle Beams? The Carronade is way shorter range than comparable weight Lasers, but they do full damage out to that range. A 10cm Visible Light Laser goes out to 60k, but a basic tech Carronade only goes to 30k, so while the Carronade does 6 damage at 30k as compared to the 10cm Lasers 3, the Laser wielder can just kite the Carronade wielder... making speed essential and turning the Carronade into the hit and run weapon of choice.

EDIT: My maths is FUBARed; 15cm carronade is 200 Tons, six damage and 60k with 6 power needed to attain a 5s reload. It has one less crew requirement than a 10cm Laser, and equivalent range to a 10cm VL Laser. Still I thinlk the idea would work, considering it will fire twice as slow at the same Capacitor tech, weighs one entire HS more, and only does five more damage at the same range. Meanwhile a 12cm VL Laser Can fire nearly as fast on the same Capacitor Tech (30s for the Carronade and 20s for the 12cm Laser at Capacitor 1), but reaches out to 80k. The 12cm VL Laser is a better comparison as it's 200 tons, needs four more crew, but still less power than the 15cm carronade. A ship mounting the laser could still kite the carronade ship, but the carronade would outperform a low tech 10cm and outdamage a high tech one, while competing with 12cm damage output through the mid game. So the choice of carronade or 10/12cm laser becomes a matter of weight, rather than a clear cut choice.

EDIT: I was in a rush, sorry for typos. :-\
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 06, 2020, 07:09:40 AM
So I'm playing a game of 7.1, and caught myself doing the same thing over and over, that I've often done, but hardly ever think of.

When I am designing ships and technology, I create two techs for every single component design where its new to my current game or a different size/needs than prior parts have.  One is just a component like any other, used like any other, to be researched and produced as regular ship components.

The other is a "prototype" part, and under a house rule, is not produced, which I instant research, so it can be used to design with, I put "prototype" in front of the name to indicate that.

This lets me fully design a ship, missile, or turret all the way to the point of being able to produce it, without having to wait for potentially months or years of research to finish before I can find out I'm a dolt and need to rework my design.  I simply do not produce them until I have done the research on the parts along the way, but I gain the ability to spot the need to make changes before I have wasted the time researching them.

I'm sure many of us have been here before.  You want a new warship with a turreted weapon, lets say, gauss guns for PD.  You pick a type, research it.  Then you make the turret, research it.  Then you go to make the ship, and only one turret fits, two is so close but not quite—the crew (or reactors for other weapons) cost you too much.  You could wait for the slipway to be enlarged, in which case the ship will need new/more engines or be slower because its bigger.  Or you wait for a slightly smaller turret that will fit to be researched, say by reducing turret armor, or reducing the turret tracking speed by a small amount to shrink it a little bit.

Or you design a gauss gun, get the tech for it, have the tech available as a prototype component so you can design the turret, which itself is available as a prototype component, and see before any time is wasted researching components that it needs to be made a little smaller, change it, and then begin research with a workable turret.


So, the request, if we could get two things:

A new button in the research window, to generate a prototype part from a research project, which would work on any technology which generates a component - so all the racial techs and things like damage control, ecm, fuel tanks, etc.  Only current research prjects should be available for prototyping—if all you have is 10cm lasers, then no prototyping 80cm advanced spinals yet, but you could prototype a 12cm laser since its the next project in the laser line of techs, and would be a currently available research project.

When the associated technology completes which yields the component that the prototype is substituting for, replace the prototype component in the design with the real one so players who are just getting started on a large construction project don't have many parts to track down and replace one by one.

I've added prototype components (see below). Not exactly as you specify above, but it achieves most of what you suggested. I'll look separately at allowing prototype components to use tech that has not yet been researched.

http://aurora2.pentarch.org/index.php?topic=8495.msg119332#msg119332

EDIT: Here is prototypes for future tech

http://aurora2.pentarch.org/index.php?topic=8495.msg119338#msg119338
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on March 06, 2020, 08:26:05 AM
So I'm playing a game of 7.1, and caught myself doing the same thing over and over, that I've often done, but hardly ever think of.

When I am designing ships and technology, I create two techs for every single component design where its new to my current game or a different size/needs than prior parts have.  One is just a component like any other, used like any other, to be researched and produced as regular ship components.

The other is a "prototype" part, and under a house rule, is not produced, which I instant research, so it can be used to design with, I put "prototype" in front of the name to indicate that.

This lets me fully design a ship, missile, or turret all the way to the point of being able to produce it, without having to wait for potentially months or years of research to finish before I can find out I'm a dolt and need to rework my design.  I simply do not produce them until I have done the research on the parts along the way, but I gain the ability to spot the need to make changes before I have wasted the time researching them.

I'm sure many of us have been here before.  You want a new warship with a turreted weapon, lets say, gauss guns for PD.  You pick a type, research it.  Then you make the turret, research it.  Then you go to make the ship, and only one turret fits, two is so close but not quite—the crew (or reactors for other weapons) cost you too much.  You could wait for the slipway to be enlarged, in which case the ship will need new/more engines or be slower because its bigger.  Or you wait for a slightly smaller turret that will fit to be researched, say by reducing turret armor, or reducing the turret tracking speed by a small amount to shrink it a little bit.

Or you design a gauss gun, get the tech for it, have the tech available as a prototype component so you can design the turret, which itself is available as a prototype component, and see before any time is wasted researching components that it needs to be made a little smaller, change it, and then begin research with a workable turret.


So, the request, if we could get two things:

A new button in the research window, to generate a prototype part from a research project, which would work on any technology which generates a component - so all the racial techs and things like damage control, ecm, fuel tanks, etc.  Only current research prjects should be available for prototyping—if all you have is 10cm lasers, then no prototyping 80cm advanced spinals yet, but you could prototype a 12cm laser since its the next project in the laser line of techs, and would be a currently available research project.

When the associated technology completes which yields the component that the prototype is substituting for, replace the prototype component in the design with the real one so players who are just getting started on a large construction project don't have many parts to track down and replace one by one.

I've added prototype components (see below). Not exactly as you specify above, but it achieves most of what you suggested. I'll look separately at allowing prototype components to use tech that has not yet been researched.

http://aurora2.pentarch.org/index.php?topic=8495.msg119332#msg119332

Was going to put this in the changes discussion, but I think it goes here better.  Suggestion:

Allow prototypes to be researched.

If you do this, then you can probably get away with eliminating the old "un-researched design" components.  Basically, the old distinction between un-researched designs and researched components gets captured in the prototype flag.  This would also ease the workflow for changing a prototype class design into a "real" design - the state of whether the ship design has a (P) is a dependent value (e.g. a Property with a non-trivial get function that looks at the rest of the state) - when the last (P) component in the design is researched the class design automagically loses its (P) and is available for retooling.

John
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on March 06, 2020, 08:57:51 AM
Was going to put this in the changes discussion, but I think it goes here better.  Suggestion:

Allow prototypes to be researched.

If you do this, then you can probably get away with eliminating the old "un-researched design" components.  Basically, the old distinction between un-researched designs and researched components gets captured in the prototype flag.  This would also ease the workflow for changing a prototype class design into a "real" design - the state of whether the ship design has a (P) is a dependent value (e.g. a Property with a non-trivial get function that looks at the rest of the state) - when the last (P) component in the design is researched the class design automagically loses its (P) and is available for retooling.

John

Nothing automagical about that. Clearly, the design bureau has some clue about the specifications and expected results of the component design, so they put some place holders in the design and when the components were completed integrated them properly after some refinement.
Title: Re: C# Aurora v0.x Suggestions
Post by: SerBeardian on March 06, 2020, 11:19:50 AM
Not sure if already suggested, but something struck me while recording today's Hypetrain episode:

Ships should be able to alter priority on recharge for beam weapons in-flight (if they lack the power to recharge all weapons fully).

Unless it's been changed, weapons recharge in ascending power draw, but what if I have a 40cm laser with 8 draw and a bunch of 10cm lasers with 3 draw, and am up against an armored battleship? I don't really care about my 10cm guns and really need that 40cm laser recharging as top priority for the higher damage and penetrating hits.

If not already mentioned/implemented, I propose being able to set a recharge priority for cannons within the combat screen, with "ascending power draw" being the default for any weapons without priority assignment.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 06, 2020, 11:34:54 AM
Was going to put this in the changes discussion, but I think it goes here better.  Suggestion:

Allow prototypes to be researched.

If you do this, then you can probably get away with eliminating the old "un-researched design" components.  Basically, the old distinction between un-researched designs and researched components gets captured in the prototype flag.  This would also ease the workflow for changing a prototype class design into a "real" design - the state of whether the ship design has a (P) is a dependent value (e.g. a Property with a non-trivial get function that looks at the rest of the state) - when the last (P) component in the design is researched the class design automagically loses its (P) and is available for retooling.

John

I've implemented this suggestion:

http://aurora2.pentarch.org/index.php?topic=8495.msg119347#msg119347
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on March 06, 2020, 06:30:29 PM
A small suggestion for missile combat... I would like to see both a minimum and maximum range for PD fire-controls.

For missiles you might want to ignore salvos when they get too close and focus on salvos further out, especially if you have very strong beam PD and shields on your ships. I suppose this should not be too difficult to code.

Also a question... what are the target priority for missiles. Will they always target the closest missiles that have not the correct number of missiles or the ones furthest out. In general I think you would want the ones furthest out as otherwise you will tend to get bigger salvos for the PD to deal with if your AMM can't intercept everything. In general it probably is better that salvos hit sooner but at an average lower amount. Or perhaps make it a choice on the PD fire-control setting perhaps.

Perhaps also teach some AMM strategies for the AI as well so they don't drain their AMM stores unnecessarily too soon.
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on March 06, 2020, 06:42:54 PM
If not already added, how about having Training slowly decrease over time as "crew rotate out, get rusty, or die?" However, recent battles will slow down this descent for quite a while, until it again returns back to normal.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 06, 2020, 07:59:22 PM

Also a question... what are the target priority for missiles. Will they always target the closest missiles that have not the correct number of missiles or the ones furthest out. In general I think you would want the ones furthest out as otherwise you will tend to get bigger salvos for the PD to deal with if your AMM can't intercept everything. In general it probably is better that salvos hit sooner but at an average lower amount. Or perhaps make it a choice on the PD fire-control setting perhaps.


About a month ago Steve changed PD to target the largest salvo first.
Title: Re: C# Aurora v0.x Suggestions
Post by: MJOne on March 07, 2020, 02:20:45 AM
If not already implemented, it would be handy to have ”quick info” and ”quick orders” to a selected fleet on the system map. Like set heading & speed, activate AS/shields, fuel/ammo status, something along those lines... perhaps by right-clicking a fleet a menu will appear so we don’t clutter the map.

And for the future it would be great if we could set a destination(Ex. 10 systems away) to the captain through a quick-order. Search bar, perhaps + pathfinding routine. Perhaps only for colonies with Space Ports. So to narrow the list and exclude clutter colonies.

When your empire is 150-200+ years old, it takes awhile just finding the right fleet and the right destination.

Just some thoughts....
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 07, 2020, 05:09:35 AM
If not already implemented, it would be handy to have ”quick info” and ”quick orders” to a selected fleet on the system map. Like set heading & speed, activate AS/shields, fuel/ammo status, something along those lines... perhaps by right-clicking a fleet a menu will appear so we don’t clutter the map.

And for the future it would be great if we could set a destination(Ex. 10 systems away) to the captain through a quick-order. Search bar, perhaps + pathfinding routine. Perhaps only for colonies with Space Ports. So to narrow the list and exclude clutter colonies.

When your empire is 150-200+ years old, it takes awhile just finding the right fleet and the right destination.

Just some thoughts....

All of the above is already in, except for set heading/speed as Aurora doesn't really operate in that way. Although you can set waypoints instead.

As an example, here is Fleet Auto-Route
http://aurora2.pentarch.org/index.php?topic=8495.msg106871;topicseen#msg106871

I suggest reading through the changes list:
http://aurora2.pentarch.org/index.php?topic=8495.0

Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on March 07, 2020, 02:46:09 PM
Was going to put this in the changes discussion, but I think it goes here better.  Suggestion:

Allow prototypes to be researched.

If you do this, then you can probably get away with eliminating the old "un-researched design" components.  Basically, the old distinction between un-researched designs and researched components gets captured in the prototype flag.  This would also ease the workflow for changing a prototype class design into a "real" design - the state of whether the ship design has a (P) is a dependent value (e.g. a Property with a non-trivial get function that looks at the rest of the state) - when the last (P) component in the design is researched the class design automagically loses its (P) and is available for retooling.

John

Nothing automagical about that. Clearly, the design bureau has some clue about the specifications and expected results of the component design, so they put some place holders in the design and when the components were completed integrated them properly after some refinement.

The magic part was intended to refer to the player experience created by the underlying code, i.e. the player doesn't need to do anything to change it from a prototype to an active design - the class just magically changes itself.  That being said, it isn't all that stunning and I mainly used the word because I like to say "automagic" and this gave me a fig leaf of an excuse :)

John
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on March 07, 2020, 02:50:39 PM
Was going to put this in the changes discussion, but I think it goes here better.  Suggestion:

Allow prototypes to be researched.

If you do this, then you can probably get away with eliminating the old "un-researched design" components.  Basically, the old distinction between un-researched designs and researched components gets captured in the prototype flag.  This would also ease the workflow for changing a prototype class design into a "real" design - the state of whether the ship design has a (P) is a dependent value (e.g. a Property with a non-trivial get function that looks at the rest of the state) - when the last (P) component in the design is researched the class design automagically loses its (P) and is available for retooling.

John

I've implemented this suggestion:

http://aurora2.pentarch.org/index.php?topic=8495.msg119347#msg119347

Cool!  Hadn't thought of the case where the prototype depended on un-researched tech.  As you point out in the comment it sounds like the process for bringing class designs that depend on un-researched components into production is a lot smoother now.

John
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on March 07, 2020, 03:26:36 PM

Also a question... what are the target priority for missiles. Will they always target the closest missiles that have not the correct number of missiles or the ones furthest out. In general I think you would want the ones furthest out as otherwise you will tend to get bigger salvos for the PD to deal with if your AMM can't intercept everything. In general it probably is better that salvos hit sooner but at an average lower amount. Or perhaps make it a choice on the PD fire-control setting perhaps.


About a month ago Steve changed PD to target the largest salvo first.

I got the impression that was for beam weapon final fire only but if it is all PD fire-controls then that is great. But I still would like to have a minimum distance as well as that would help allot for AMM engagement where you also have a strong beam PD present.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on March 07, 2020, 05:40:03 PM

Also a question... what are the target priority for missiles. Will they always target the closest missiles that have not the correct number of missiles or the ones furthest out. In general I think you would want the ones furthest out as otherwise you will tend to get bigger salvos for the PD to deal with if your AMM can't intercept everything. In general it probably is better that salvos hit sooner but at an average lower amount. Or perhaps make it a choice on the PD fire-control setting perhaps.


About a month ago Steve changed PD to target the largest salvo first.

I got the impression that was for beam weapon final fire only but if it is all PD fire-controls then that is great. But I still would like to have a minimum distance as well as that would help allot for AMM engagement where you also have a strong beam PD present.

As well as layered anti missile missiles - I can micro which launchers get to target what and have both in use, or i can load one until they are close enough then load the other across the board to mitigate micro at cost of combat efficiency.

If I can set a minimum range on weapons or firecontrols, I can prevent the longer ranged AMM from wasting shots on targets the shorter ranged amm should be taking, or either from wasting shots better left to the guns.

For reference, these are the sort of two tier AMM I tend to use when I decide on AMM defences (7.1 numbers, for c#, nearly identical results can be had except for significantly shorter reach, 0.44mkm and 3.63mkm range, respectively):
Code: [Select]
Viper S1 AMM
Missile Size: 1 MSP  (0.05 HS)     Warhead: 1    Armour: 0     Manoeuvre Rating: 41
Speed: 49000 km/s    Engine Endurance: 1 minutes   Range: 1.9m km
Cost Per Missile: 1.482
Chance to Hit: 1k km/s 2009%   3k km/s 656%   5k km/s 401.8%   10k km/s 200.9%
Materials Required:    0.25x Tritanium   1.232x Gallicite   Fuel x33.25

Code: [Select]
Taipan S1 AMM
Missile Size: 1 MSP  (0.05 HS)     Warhead: 1    Armour: 0     Manoeuvre Rating: 38
Speed: 42200 km/s    Engine Endurance: 6 minutes   Range: 14.6m km
Cost Per Missile: 1.338
Chance to Hit: 1k km/s 1603.6%   3k km/s 532%   5k km/s 320.7%   10k km/s 160.4%
Materials Required:    0.25x Tritanium   1.088x Gallicite   Fuel x283.25

Ideally, I would have Taipans restricted from engaging inside of 2mkm, and let the Vipers tackle anything between 2mkm and PD area defence range.  As it stands, one must micro the missile FC's to prevent not firing when one should or firing when one should not.

Having that minimum engagement range would go a long way towards mitigating player intervention in achieving the same result, since you could simply set a minimum large enough to keep the two missiles from overlapping at all, so each works to its own strength when needed to do so.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 07, 2020, 11:34:57 PM
If not already added, how about having Training slowly decrease over time as "crew rotate out, get rusty, or die?" However, recent battles will slow down this descent for quite a while, until it again returns back to normal.

If you scroll back a few pages, you can see a couple-dozen-post argument on this very topic.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 07, 2020, 11:48:02 PM
A QoL improvement:

Can the 'Summary' tab of the Colony (F2) window {this one: http://www.pentarch.org/steve/Screenshots/Crusade/Space1889_01.PNG (http://www.pentarch.org/steve/Screenshots/Crusade/Space1889_01.PNG)} section "Manufacturing Worker Breakdown" auto-sort itself to descending order by number of workers (with "Available Workers" still at the end though)?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 08, 2020, 06:51:23 AM
A QoL improvement:

Can the 'Summary' tab of the Colony (F2) window {this one: http://www.pentarch.org/steve/Screenshots/Crusade/Space1889_01.PNG (http://www.pentarch.org/steve/Screenshots/Crusade/Space1889_01.PNG)} section "Manufacturing Worker Breakdown" auto-sort itself to descending order by number of workers (with "Available Workers" still at the end though)?

Done.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 08, 2020, 07:36:27 AM
Thanks!
Title: Re: C# Aurora v0.x Suggestions
Post by: L0ckAndL0ad on March 08, 2020, 08:11:55 AM
Allow refit of electronics on any appropriate shipyard

Crusade AAR made me thinking about updating older ships vs building new ones. In my own game in VB6 Aurora, when I create new generations of ships and retool shipyards, I loose the ability to make small upgrades on my older generation vessels (which is not realistic). To be able to keep the old ships updated with newer FCS and sensors, you need to either have to make costly refit to them to get them to a new generation standards and replace their engines and armor along the way (which is unrealistic and super inefficient), or have as many separate shipyards (that will be idle and PITA to deal with) that were tooled for this particular design that you still use.

So, I propose allowing refit of electronic modules (sensors and fire controls) on any appropriate (type and size) shipyard.

Optional: Allow other small changes to be done the same way, regardless of what design the shipyard is tooled for.  Similar to how USN refitted its old 21 knot Standard type battleships in WW2 with new 5 inch DPs. BB-45 - USS Colorado, for example, was built on the East Coast in 1921, but was under refit at West Coast in 1942 where it received new 5/38 DPs.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 08, 2020, 09:38:13 AM
Allow refit of electronics on any appropriate shipyard

Crusade AAR made me thinking about updating older ships vs building new ones. In my own game in VB6 Aurora, when I create new generations of ships and retool shipyards, I loose the ability to make small upgrades on my older generation vessels (which is not realistic). To be able to keep the old ships updated with newer FCS and sensors, you need to either have to make costly refit to them to get them to a new generation standards and replace their engines and armor along the way (which is unrealistic and super inefficient), or have as many separate shipyards (that will be idle and PITA to deal with) that were tooled for this particular design that you still use.

So, I propose allowing refit of electronic modules (sensors and fire controls) on any appropriate (type and size) shipyard.

Optional: Allow other small changes to be done the same way, regardless of what design the shipyard is tooled for.  Similar to how USN refitted its old 21 knot Standard type battleships in WW2 with new 5 inch DPs. BB-45 - USS Colorado, for example, was built on the East Coast in 1921, but was under refit at West Coast in 1942 where it received new 5/38 DPs.

Even in that case, I doubt the battleships could just drop by any shipyard at any time and have the guns fitted. There would need to be some scheduling and preparation work.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on March 08, 2020, 01:04:22 PM
You'd also need a slipway that's large enough to fit the ship and a shipyard that can handle the components.

When you order a capital ship in for work on the electronics you aren't pulling chips from the motherboard and slotting in new chips, you are moving hundreds if not thousands of tons of sensitive equipment in and out of the armour layer, consisting of sensor panels, mechanical gears to adjust the panels, large amounts of computation equipment to process the data the sensors gather and kilometers and kilometers of cabling along with adjustments to the ship's power distribution system to deal with the different demands of the new electronics.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 08, 2020, 04:17:57 PM
As an example, here is Fleet Auto-Route
http://aurora2.pentarch.org/index.php?topic=8495.msg106871;topicseen#msg106871
Will this auto route feature also in the "repeat order list"? Would be nice if a transport would recalculate the (always changing) shortest route due to Lagrange points etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: BAGrimm on March 08, 2020, 07:45:19 PM
Had a thought while playing around with missile designs in my most recent campaign attempt.  As an RP-tool, Enhanced Radiation warheads are useful.  And while I have yet to personally unleash them against an actual population, I assume that they can be useful under the correct circumstances for planetary attack.  However, outside of this, they seem to be fairly useless.  What I propose is as follows: What if they were turned into a tactical choice in ship to ship encounters by giving them an effect on, say, shields/electronics/crew/component malfunctions? I haven't really thought out a concrete set of possible/useful rules for them, but I found the idea intriguing.  Obviously not expecting anything to come from this in the initial C# release, as it is coming much too SoonTM, but maybe as a later inclusion, to play off of possible general enhancements to Electronic Warfare?
Title: Re: C# Aurora v0.x Suggestions
Post by: vorpal+5 on March 09, 2020, 03:42:18 AM
You'd also need a slipway that's large enough to fit the ship and a shipyard that can handle the components.

When you order a capital ship in for work on the electronics you aren't pulling chips from the motherboard and slotting in new chips, you are moving hundreds if not thousands of tons of sensitive equipment in and out of the armour layer, consisting of sensor panels, mechanical gears to adjust the panels, large amounts of computation equipment to process the data the sensors gather and kilometers and kilometers of cabling along with adjustments to the ship's power distribution system to deal with the different demands of the new electronics.

Makes sense too. Now from a gaming perspective, would it be possible to give some leeway to ship retrofit if the difference is only 5% between the 2 ships? I doubt that in WW2 if you had a very large slipway, you needed to retool it for months just to change the radar of a carrier, right? in fact, except because of size, slipways, were they really specialized down to a precise class of ship?
Title: Re: C# Aurora v0.x Suggestions
Post by: SultanPepper on March 09, 2020, 04:20:25 AM
Hi all, long time lurker, first time poster (haha).  Been reading through a lot of this, but not all, so apologies if it's been discussed.  Any chance for a 'disable missile tech' option at campaign start? I love me some Star Wars, and would love for NPR's to play by the same rules - beam weapons only.  Maybe have such an option also boost beam ranges and whatnot to keep the game smooth.  Possible/thoguhts?

Amazing game, Steve.  I've been (im)patiently awaiting C# version for a while haha.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on March 09, 2020, 06:32:05 AM
Hi all, long time lurker, first time poster (haha).  Been reading through a lot of this, but not all, so apologies if it's been discussed.  Any chance for a 'disable missile tech' option at campaign start? I love me some Star Wars, and would love for NPR's to play by the same rules - beam weapons only.  Maybe have such an option also boost beam ranges and whatnot to keep the game smooth.  Possible/thoguhts?

Amazing game, Steve.  I've been (im)patiently awaiting C# version for a while haha.

Steve have said in a previous comment that the way the AI is coded it is not possible to remove missile technology from the game. The player have to simply ignore it for their own RP which is the only solution for now. Perhaps something that could be done for the future though.
Title: Re: C# Aurora v0.x Suggestions
Post by: L0ckAndL0ad on March 09, 2020, 08:04:31 AM
Even in that case, I doubt the battleships could just drop by any shipyard at any time and have the guns fitted. There would need to be some scheduling and preparation work.
Of course. The same applies to the situation when you need to make repairs (after combat) and replace damaged equipment. Fortunately, in Aurora, you don't need a shipyard tooled for specific design to be able to repair ships. Only big enough and of the correct type.

Alternatively, allowing shipyards to be able to refit ships it was tooled to build previously (for example, the last 2-3 tooled designs) would also work, I guess.

My main point is that there needs to be a better way to make small refits without having shipyards sitting there idly just to preserve such capability.

You'd also need a slipway that's large enough to fit the ship and a shipyard that can handle the components.
That's what I said: on any appropriate shipyard, in terms of size and type.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on March 09, 2020, 12:22:23 PM
I have a minor request : can we please remove the gender of commanders from their stats? I'm not aware of the exact algorithm Aurora uses for naming commanders, but while it does an okay-ish job with Anglo/European names, it absolutely butchers the naming conventions followed by other cultures. It's like half the women get unambiguously male names, while a quarter of the males get unambiguously female names, and it really breaks my immersion when I see that 'M' next to 'Lieutenant Katie Stanton' or 'F' next to 'Scientist Roger Mansson'.

Fixing it will require some way of cataloguing and gendering names, which I don't think is worth the effort. It's just easier to remove the classification entirely and leave the gender of commanders ambiguous/use gender-neutral language wherever it comes up.
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on March 09, 2020, 02:53:39 PM
Or, you know, just make the name/gender/pronoun fields editable?
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 09, 2020, 11:26:52 PM
I have a minor request : can we please remove the gender of commanders from their stats? I'm not aware of the exact algorithm Aurora uses for naming commanders, but while it does an okay-ish job with Anglo/European names, it absolutely butchers the naming conventions followed by other cultures. It's like half the women get unambiguously male names, while a quarter of the males get unambiguously female names, and it really breaks my immersion when I see that 'M' next to 'Lieutenant Katie Stanton' or 'F' next to 'Scientist Roger Mansson'.

Fixing it will require some way of cataloguing and gendering names, which I don't think is worth the effort. It's just easier to remove the classification entirely and leave the gender of commanders ambiguous/use gender-neutral language wherever it comes up.

The name files are already segregated into last names, female first names and male first names.  The 'F' or 'M' is dictated solely by which file the first name is drawn from.

You can easily edit the files to remove (or move) the names you have a problem with, and then share the edited files here.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on March 10, 2020, 02:37:28 AM
The name files are already segregated into last names, female first names and male first names.  The 'F' or 'M' is dictated solely by which file the first name is drawn from.

You can easily edit the files to remove (or move) the names you have a problem with, and then share the edited files here.

Are you sure you don't need designer mode to access the name files?

Even if it you could, though, there must be thousands of first names - it would take literal days to sort through everything, especially since you'd need to cross-check against online databases to gender names correctly for cultures you have minimal knowledge about. It's far simpler to just remove the gender field, and it's not like it serves much of a purpose anyway.
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on March 10, 2020, 03:06:57 AM
What if I wanna play a Matriarchal Society? Or a society which only assigns military roles to men? Seeing, "M" or "F" in the commander tabs would be far, far easier than having to sort through my commanders manually by name. I've had upward of 200+ of them in some games. I think a girl named Roger is definitely weird, especially if Aurora is auto-generating them, but removing the gender field is the wrong solution.

I think it should just be turned into an editable field. If I want to RP a machine race, or a Bug race with Male, Female and genderless Drones that would be quite useful. Or a faux-Star Trek future utopia where humans transcended the idea of gender via trans-humanism. Or a pseudo-Amazonian / Drow culture where men are lower-class and only women hold positions of power. Maybe with the Gene Modification Centers serving to change them into Females, but with genes specifically designed for certain worlds or deep space, making them less likely to rebel and still being second-class.
Title: Re: C# Aurora v0.x Suggestions
Post by: professorpicke on March 12, 2020, 12:33:24 AM
Missile agility as it currently is just a way to squeeze out extra hit chance by guessing/calculating the optimal ratio; it's unnecessary complexity.  My suggestion is to remove missile agility, or add it as a research line that flatly buffs missiles for missiles built with the technology.
Title: Re: C# Aurora v0.x Suggestions
Post by: Mini on March 12, 2020, 03:35:41 AM
There is some choice to be made, since if you use agility then your engine is going to be smaller and therefore the missile slower. I do agree that the current implementation is too opaque, maybe reducing it to a simple toggle, trading a percentage increase in missile size for increased hit chance (with tech improving the increase to hit chance) would be better.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on March 12, 2020, 03:57:48 AM
There also is a problem with agility in that it increase the chance of AMM to intercept enemy missile over time that does not scale well with the other sides ability to avoid being intercepted. So, the current agility ,echanic will make AMM intercept enemy missiles of the same technology more or less 100% every time eventually making missiles as a weapons almost useless at some point against someone with the same technology level.

For that reason I always just set the agility level to a certain level in my games when I play multi-faction games in such a way that AMM have roughly a 30-40% chance to intercept enemy missiles of the same technology level. Of course the AI are restricted to use agility like normal but I'm not too concerned about that.

I would like to see agility being redone so that it scale better in general. I still think there is a use for agility as a concept as I don't think that a missiles speed should be the only thing that govern how good it is at hitting something or avoid being hit. The problem is that speed is both a factor of hitting and avoid being hit where agility only allow you to hit more easily. In my opinion I think that both of these should do both things they just should do it differently. Let's say that speed is about 75% of the missiles defence and 25% of its ability to hit while agility is 75% ability to hit but also about 25% of the ability to avoid being hit. I mean... speed of the missile effect thing like the time you have to intercept it from the time you detect it and how effective area PD can be against it. Speed is a very strong attribute for the missiles defence in many respects, the chance to hit a missile and the chance for a missile to hit something should be reevaluated in the future in my opinion. Make agility the primary source for a missile to target something and speed is its main defence but both values should apply to some degree in both calculations. This would then make both values roughly equally important and balance each other out over the course of an entire game.
Title: Re: C# Aurora v0.x Suggestions
Post by: The_Seeker on March 12, 2020, 08:03:23 AM
Quote from: Jorgen_CAB link=topic=9841. msg119530#msg119530 date=1584003468
There also is a problem with agility in that it increase the chance of AMM to intercept enemy missile over time that does not scale well with the other sides ability to avoid being intercepted.  So, the current agility ,echanic will make AMM intercept enemy missiles of the same technology more or less 100% every time eventually making missiles as a weapons almost useless at some point against someone with the same technology level.

For that reason I always just set the agility level to a certain level in my games when I play multi-faction games in such a way that AMM have roughly a 30-40% chance to intercept enemy missiles of the same technology level.  Of course the AI are restricted to use agility like normal but I'm not too concerned about that.

I would like to see agility being redone so that it scale better in general.  I still think there is a use for agility as a concept as I don't think that a missiles speed should be the only thing that govern how good it is at hitting something or avoid being hit.  The problem is that speed is both a factor of hitting and avoid being hit where agility only allow you to hit more easily.  In my opinion I think that both of these should do both things they just should do it differently.  Let's say that speed is about 75% of the missiles defence and 25% of its ability to hit while agility is 75% ability to hit but also about 25% of the ability to avoid being hit.  I mean. . .  speed of the missile effect thing like the time you have to intercept it from the time you detect it and how effective area PD can be against it.  Speed is a very strong attribute for the missiles defence in many respects, the chance to hit a missile and the chance for a missile to hit something should be reevaluated in the future in my opinion.  Make agility the primary source for a missile to target something and speed is its main defence but both values should apply to some degree in both calculations.  This would then make both values roughly equally important and balance each other out over the course of an entire game.
I find the missile calculations to be unsatisfactory in general, factors such as target aspect, size, and acceleration aren't taken to account in the game, but are far more important than target velocity for real missiles.   It's really easy to throw a dart at a 70mph train and hit it from directly in front of it, it'd be much harder to throw a dart and intercept a 70mph curveball at a right angle, but both of those scenarios would be equivalent in aurora because only the target's velocity and the dart's unmaneuverability are accounted for.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on March 12, 2020, 01:05:26 PM
Wouldn't it be better that Speed is your chance to hit and Agility is your chance to avoid being hit? If both affect both, then it's just another Excel sheet where you punch in numbers and the macro tells you where the sweet spot lies. If they affect different things, then you would value them differently depending on what the purpose of that missile is - attacking other missiles, avoiding AMMs, avoiding PD, hitting planets, hitting ships, and so on.

Or am I barking up the wrong tree?
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on March 13, 2020, 02:50:28 AM
I'm kindof in the remove agility camp at the moment, personally.

e: Not militantly so, I dont really care that much, but I can see the argument for just doing away with it.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on March 13, 2020, 03:27:10 AM
I'm kindof in the remove agility camp at the moment, personally.

e: Not militantly so, I dont really care that much, but I can see the argument for just doing away with it.

I am of the same opinion. It's just misleading and obscure. Not to mention, not really all that useful as it is right now. I'd simply remove it.

I'd simply balance hit chance against missiles based on velocity and speed. I don't really see much point in agility as it is now.

Not to mention, it has always bugged me a bit. I can imagine "agile" missiles.... but agile missiles should slow down their approach to targets, thus taking longer to hit them because the missile takes evasive maneuvers. It bugs me that the game does not model that, travel time is not influenced at ALL by these "evasive maneuvers". Since it does not model that, I'd rather simplify things and do without agility.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on March 13, 2020, 04:41:25 AM
Wouldn't it be better that Speed is your chance to hit and Agility is your chance to avoid being hit? If both affect both, then it's just another Excel sheet where you punch in numbers and the macro tells you where the sweet spot lies. If they affect different things, then you would value them differently depending on what the purpose of that missile is - attacking other missiles, avoiding AMMs, avoiding PD, hitting planets, hitting ships, and so on.

Or am I barking up the wrong tree?

Agreed that they should see a change, right now speed is just the better agility, though depending on your tech levels, there may be better gains in improving one or the other.

Suppose we took the radius of a sphere representing the volume of an entity, using the targets tonnage as the "volume" value.  Divide the entity's speed by that "radius", and divide that result by 500 to compress the numbers a bit more, then in normal aurora fashion, truncate to one or two decimal places, lets go with one place.

Tons"Radius"Speed"Agility"
2.750.86980000184.1
5.51.09570000127.9
111.386000087
16.51.5795000063.3
331.994000040.2
502.2854000035
2503.9083000015.4
5004.9243000012.2
7505.636200007.1
10006.204200006.4
20007.816200005.1
30008.947200004.5
500010.608200003.8
Note that 2.75, 5.5, 11, 33, and 50 are missile sizes 1, 2, 4, 6, 12, and 18 respectively.  If you do the math on sensors, an s6 must be 6*2.75=16.5 tons or the ranges don't match up for MCR against an S6 missile.

If your agility is more than 5 times higher than theirs, there is no penalty to the intercept, If not, then ratio/5 is the accuracy from agility.

So a 16.5t (s6) missile at 50kkm/s has little issue intercepting a 500t fighter at 30kkms, since its 5.19x more "agile", or 104% agile enough.  An s12(33t) missile at 40kkms would have some issues, being only 3.3x as agile, or 66% agile enough.  Take that 40.2 agility, divide by 66%, get 61 agility, hit that rating, you get 100% in this match up.  That means you'd need 20.8 more AGI, which at 200AGI/MSP is 0.104MSP per missile MSP, or 1.248msp on AGI to get 100% chance.



This means ASM's will pretty much never need AGI to get kills against ships.  At the same speed, just by virtue of size, an s6 has no penalty against anything larger than ~1000t, and s12 against 2000t.  If they are faster, no the same speed as that example, then the targets can be smaler to have 100% chance, with no additional agility.


So what about evasive use of agility?

Well, lets take an example of 2.75t(s1) intercepting 33t(s12), with speeds of 80kkkms and 40kkms respectively.  The ratio is currently 4.57, which means the AMM has a ~92% intercept chance.  Again, assuming 200 AGI/MSP tech, if the ASM added 1 MSP of AGI, then it adds 200/s12 in agility, which is 8.5 agility, lifting itself from 40.2 to 48.7 so the ratio moves from 4.57 to 3.78, which is a 75% chance.


If it worked like that, you could ignore it for ASMs, and possibly some AMMs, or add AGI to engage difficult targets, or even get into an AGI arms race trying to be agile enough to not get hit, while they try to be agile enough to hit — that extra agility eats into your fuel and/or warhead space.

Of course, that would muddy the waters a bit with respect to still needing an excel sheet to figure out optimal engine and agi combinations still, since both would still impact the outcome for intercepts.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on March 13, 2020, 08:40:23 AM
I'm kindof in the remove agility camp at the moment, personally.

e: Not militantly so, I dont really care that much, but I can see the argument for just doing away with it.

Simply removing it and rely on speed alone is not a good solution in my opinion as that makes slow long range missiles quite unfeasible to build. You need to add some agility to these so they can actually hit something. With the fuel changes in C# I'm pretty sure this will be needed. Otherwise you would have to completely rely on multi-stage missiles which is unnecessarily complicated if you need them in all long range cases.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 13, 2020, 09:39:03 AM
I'm kindof in the remove agility camp at the moment, personally.

e: Not militantly so, I dont really care that much, but I can see the argument for just doing away with it.

Simply removing it and rely on speed alone is not a good solution in my opinion as that makes slow long range missiles quite unfeasible to build. You need to add some agility to these so they can actually hit something. With the fuel changes in C# I'm pretty sure this will be needed. Otherwise you would have to completely rely on multi-stage missiles which is unnecessarily complicated if you need them in all long range cases.

It's also worth noting that this is where missiles started, and speed alone was deemed insufficient, and adding Missile Agility was the solution.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on March 13, 2020, 11:23:24 AM
I tend to very rarely use it because generally adding more speed has been a better use of mass in terms of increased hit chance, with only a few exceptions that I remember.  I also tend to make fairly fast longer-ranged missiles anyhow (admittedly at a cost) because the time it takes for the missiles to reach the target has been very important to the pacing of the engagement.  Generally I need to loiter around until the missiles reach the target before I can flee, or I want to save on ammo by only engaging targets that survived the previous salvo before launching the next one, meaning the faster each salvo resolves the faster I can launch the next one without wasting huge amounts of ammo (sensor missiles only help with this when the enemy is all stacked into the same place, but I do employ them to mitigate that somewhat).
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on March 13, 2020, 08:33:14 PM
I tend to very rarely use it because generally adding more speed has been a better use of mass in terms of increased hit chance, with only a few exceptions that I remember.  I also tend to make fairly fast longer-ranged missiles anyhow (admittedly at a cost) because the time it takes for the missiles to reach the target has been very important to the pacing of the engagement.  Generally I need to loiter around until the missiles reach the target before I can flee, or I want to save on ammo by only engaging targets that survived the previous salvo before launching the next one, meaning the faster each salvo resolves the faster I can launch the next one without wasting huge amounts of ammo (sensor missiles only help with this when the enemy is all stacked into the same place, but I do employ them to mitigate that somewhat).

Yes. for the most part that is true in VB6 unless you want to target FAC, fighters or other missiles.

It will change quite drastically in C# though with the change in how fuel work. You can see that in Steve's play-through that his missiles are quite allot slower and he still haven't used allot of ECM and/or ECCM or other electronics in them.
So missiles of any significant range will have to be big in order to be fuel efficient and have decent speed, and even then it probably will need to be quite a bit slower. Otherwise you will end up on the loosing side of the missile exchange in the first place... especially if you want to be able to release missile out of range of enemy active sensor range to keep your main task-forces hidden for any counter attacks.

In VB6 I certainly did make some use of agility in armoured missiles where they had less speed. It made the missiles allot cheaper but still roughly as hard to shoot down with conventional means.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on March 13, 2020, 10:30:08 PM
To be honest the survivability aspect of agility was never something I looked into much, because there weren't really any tools at hand to evaluate that so you would be left with very laborious trial and error.  I did encounter some slower missiles that were very difficult to hit so I presume those were probably using that.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 14, 2020, 02:35:27 AM
So it would be nice to evaluate the difference between using agility or not. How can we do that?
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 14, 2020, 06:13:34 AM
To be honest the survivability aspect of agility was never something I looked into much. . .

Uh, there isn't one.  There's no 'dodge bonus' or anything for Agility -- it has zero effect on defense, only on chance to hit.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 14, 2020, 06:18:38 AM
So it would be nice to evaluate the difference between using agility or not. How can we do that?

The oft-mentioned Excel spreadsheet (which I believe has also been published as a straight formula) calculates the optimal engine/agility ratio for a given target's speed.  It tells you whether one more point of Agility is worth losing 133 km/s versus a 5,140 km/s ship.
Title: Re: C# Aurora v0.x Suggestions
Post by: hostergaard on March 14, 2020, 08:28:42 AM
Some manner of multiplayer support

Or something to make the life of a space master easier when making community games


Best possible would be a way to set up a server or have people being able to access the same save game, but perhaps only being able to see and control a particular race except their own (except the spacemaster). The game would largely played like normal (although, perhaps give the space master some ability to control what a player can see and do, during play or game setup) except the passage of time could either be controlled by the space master or by some maner of player voting. Like, have the speed be the highest possible that all agree on.

 If adding server support or something else to enable live multiplayer is too much to ask, maybe a way to split and integrate save games of the same game. So saves can be passed on to all involved, they can give their orders and return it to the space master who integrate the games and let time pass to let the orders and actions resolve. Just so we don't have to pass one save game around and wait for everyone to their thing one at the time.

And maybe make space masters able to open multible windows, one for each player race so I could possibly stream each view to a person or a group of person. That way I could enable live space battles.

I mean, some maner of multiplayer support would be awesome. 


Might have been suggested or implemented before and I am sorry if it have, I could not locate anything at a glance, so I figured I would throw it in there.
Title: Re: C# Aurora v0.x Suggestions
Post by: hostergaard on March 14, 2020, 08:31:53 AM
Mod Supopport

Steve, lets have a little talk, you are apparently weirdly against open sourcing things (according to one of your latest posts. I wasn't thinking of it before but your posts made me think of it. Tough, I stil don't know why, despite the name the posts did not really explain it), and that is okay, its your game and its your decision alone what to do with it, but maybe consider having parts of the code open to enable moders and alike to work with your game? You should look at the guys doing CDDA and Dwarf Fortress, they done so quite successful and it benefited their games tremendously. If you did, I might be able to say, make a client of my own to enable other players to take control of things during a live stream of space battles. It could be really great fun, to assemble a bunch of people, have some act as generals, others a ship pilots and have them all able to act and make decisions on their own. Or whatever else, please do consider it. Sharing is caring!

Also, stay healthy! Wont want you do die from Corona before releasing C# ;p
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 14, 2020, 08:58:10 AM
Some manner of multiplayer support

Or something to make the life of a space master easier when making community games


Best possible would be a way to set up a server or have people being able to access the same save game, but perhaps only being able to see and control a particular race except their own (except the spacemaster). The game would largely played like normal (although, perhaps give the space master some ability to control what a player can see and do, during play or game setup) except the passage of time could either be controlled by the space master or by some maner of player voting. Like, have the speed be the highest possible that all agree on.

<snip>



There's a password for Space Master functions (if left blank Aurora treats this as 'no password').  You can lock each race behind its own password.

I can't remember if the current version supports locking time advance behind the SM password, but you can instruct your players that only the SM will advance time.

Now you can email the database to each player in turn (or use some sort of virtual drive and versioning support) and 'run' multiplayer Aurora.

(Note, however, that when two (or more) players start fighting each other the game is going to bog down to an epic degree.  It can take days or even weeks for players A & B to finish a three-Aurora-hour fight during which players C through H can do nothing.)
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 14, 2020, 09:28:59 AM
Mod Supopport

Steve, lets have a little talk, you are apparently weirdly against open sourcing things (according to one of your latest posts. I wasn't thinking of it before but your posts made me think of it. Tough, I stil don't know why, despite the name the posts did not really explain it), and that is okay, its your game and its your decision alone what to do with it, but maybe consider having parts of the code open to enable moders and alike to work with your game? You should look at the guys doing CDDA and Dwarf Fortress, they done so quite successful and it benefited their games tremendously. If you did, I might be able to say, make a client of my own to enable other players to take control of things during a live stream of space battles. It could be really great fun, to assemble a bunch of people, have some act as generals, others a ship pilots and have them all able to act and make decisions on their own. Or whatever else, please do consider it. Sharing is caring!

Also, stay healthy! Wont want you do die from Corona before releasing C# ;p

I'm not sure how I could have made it clearer :)

As stated in the FAQ entry, I have zero interest in project managing a group of developers or trying to integrate someone else's code. I'm not interested in Aurora having the best possible code or the best possible architecture or debating what that might look like. I simply want to have fun programming and playing.  I do not want to share the actual code, which represents thousands of hours of work on my part. I don't want to waste time on bug reports caused by someone else hacking around and I don't want multiple potentially competing versions of Aurora. In simple terms, I want to maintain control over my creation.

Now it might seem 'weird' to you that I am not prepared to hand over my work to everyone and that's fine. I'm not trying to defend my stance on this, I am simply stating it so there is no confusion.
Title: Re: C# Aurora v0.x Suggestions
Post by: Kristover on March 14, 2020, 11:21:02 AM
Mod Supopport

Steve, lets have a little talk, you are apparently weirdly against open sourcing things (according to one of your latest posts. I wasn't thinking of it before but your posts made me think of it. Tough, I stil don't know why, despite the name the posts did not really explain it), and that is okay, its your game and its your decision alone what to do with it, but maybe consider having parts of the code open to enable moders and alike to work with your game? You should look at the guys doing CDDA and Dwarf Fortress, they done so quite successful and it benefited their games tremendously. If you did, I might be able to say, make a client of my own to enable other players to take control of things during a live stream of space battles. It could be really great fun, to assemble a bunch of people, have some act as generals, others a ship pilots and have them all able to act and make decisions on their own. Or whatever else, please do consider it. Sharing is caring!

Also, stay healthy! Wont want you do die from Corona before releasing C# ;p

I'm not sure how I could have made it clearer :)

As stated in the FAQ entry, I have zero interest in project managing a group of developers or trying to integrate someone else's code. I'm not interested in Aurora having the best possible code or the best possible architecture or debating what that might look like. I simply want to have fun programming and playing.  I do not want to share the actual code, which represents thousands of hours of work on my part. I don't want to waste time on bug reports caused by someone else hacking around and I don't want multiple potentially competing versions of Aurora. In simple terms, I want to maintain control over my creation.

Now it might seem 'weird' to you that I am not prepared to hand over my work to everyone and that's fine. I'm not trying to defend my stance on this, I am simply stating it so there is no confusion.

Couple of points - In the original posters comment, he mentions the open source nature of Catalysm DDA.  Now, I'm a huge fan of CDDA and I have several long running games on it and the community has brought many really interesting ideas to the game....but as a long time CDDA player, the game is always a huge damn mess and several times some member of the community has made a change on an experimental version which has completely ruined a run for me.  Add on to it, CDDA has ALWAYS suffered from competing visions some of which has created huge rifts in that community resulting in branch versions, drama, and hurt feelings.  CDDA is a joy to play but it is also rife with lots of frustration because of it.  None of this means that CDDA isn't worth playing, quite the contrary.  But I in no way want CDDA's design anarchy to be ported over to Aurora.  Given the amount of work I put into a single Aurora game exceeds that which I put into literally dozens of CDDA runs, I would quickly abandoned Aurora.

At the end of the day, Steve has chosen to share his hobby with us.  I'm thankful.  If he ever wanted to make this an actual product, I would gladly play $100 - back in my tabletop war gaming days, I easily dropped $100 on a really good Avalon Hill game.  BUT, I would expect for my $100 for Aurora to work EXACTLY as advertised out of the box and if a game bug cropped up, I would expect Steve to fix it quickly and not six months later when he had time.  We are getting a guy's hobby project.  Because he seems to find merit in sharing his hobby with us, I have no problem making suggestions and asking for features that I think would benefit - but I don't have any expectation the guy will add them and don't get irritated if he doesn't.  I not paying for it after all.  I think at the end of the day, the man has flat out said what he is going to provide to the community and on what terms he will do it.  I think a bit of respect and civility - and leave the hectoring tone at the door - is in order.
Title: Re: C# Aurora v0.x Suggestions
Post by: Inglonias on March 14, 2020, 11:50:51 AM
Hey.  Just thought I would post what I want for Christmas, so to speak.

It would be nice to be able to press a button and rename as many solar system bodies as possible according to a theme, either chosen randomly or just going down the naming theme list as you go down the list of system bodies. I say "as possible" because I know that having two system bodies with the same name is a bad thing in VB6 (makes it throw errors) so if the theme runs out of names before you run out of bodies to name, the operation would halt to avoid duplicate names.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on March 14, 2020, 02:05:29 PM
Mod Supopport
I'm not sure how I could have made it clearer :)
Couple of points - In the original posters comment, he mentions the open source nature of Catalysm DDA
And to add from Dwarf Fortress, the mods can be great fun but they are also a massive headache. A vast amount of bug reports and complaint posts on the Bay12 forum are from modded games. At least DF has thousands of experienced players who act as a filter between the sole developer and the community. Aurora doesn't. Not to mention that I can't even imagine how frustrating it is for modder A to have people complain about stuff because of modder B due to players mix'n'matching stuff that isn't compatible. We know from every modding community that players do stupid stuff like that all the time.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on March 14, 2020, 04:43:04 PM
I feel like 'people will post spurious bug reports because of broken mods' is a somewhat weak argument against modding, because mods can potentially do a lot for the enjoyability of a game, and to my general experience its not all that hard to ignore reports that fail to clarify whether they are using mods or not.  Mind you, I also don't know what form the modding would even take exactly in this case, perhaps adding new weapons or rebalancing existing ones?  Its not totally clear if that would even be practical to add.

e: As an aside, cataclysm DDA was a total disaster long term and turned into a kindof terrible game due to all the weird crap people were adding to the baseline game.  I can't say I particularly support an open sourced approach in any specific regard.  It has its uses, some projects do it successfully, but you need to constantly be an asshole to people making pull requests if you want to keep the game in any sort of good state, and there will be splinter games forming at the drop of a hat.  Heck, in the case of aurora there is already that Quasar thing which sprung up even without any open sourced code.
Title: Re: C# Aurora v0.x Suggestions
Post by: JustAnotherDude on March 14, 2020, 04:55:28 PM
At the end of the day, all of the conjecture about whether or not it would make the game better is moot because Steve is not comfortable with it. That is his right and we should all respect it. It's his game and ultimately his choice.
Title: Re: C# Aurora v0.x Suggestions
Post by: Frank Jager on March 14, 2020, 05:47:53 PM
Fer Cthullu's sake!

Steve is very nearly NOT releasing C# Aurora in ANY format to the public, because you all can't respect the mans property.

There will be no mod support. The source code will not be released. That's pretty clear from the MULTIPLE posts and thread that Steve created.

Imagine you had a boat, that you had built from scratch. It took several hundred hours to create. Now imagine sharing that boat with everyone, because you are proud of it. Now imagine everyone chopping that boat to pieces, changing things around to suit them. That boat that you built, suddenly doesn't look like your boat, your labor of love.

I would really, really, really like to actually be allowed to play with Aurora C#. I would like it to be released in a few weeks.

There is already a delay, caused by this community, with the repeated blatant statements that you will not respect the mans wishes, and will simply hack the source code anyway. This has led to an actual DELAY!!!

Please just respect Steve's wishes.

It isn't like its hard to figure them out.
Title: Re: C# Aurora v0.x Suggestions
Post by: hostergaard on March 15, 2020, 03:45:28 AM

I'm not sure how I could have made it clearer :)

As stated in the FAQ entry, I have zero interest in project managing a group of developers or trying to integrate someone else's code. I'm not interested in Aurora having the best possible code or the best possible architecture or debating what that might look like. I simply want to have fun programming and playing.  I do not want to share the actual code, which represents thousands of hours of work on my part. I don't want to waste time on bug reports caused by someone else hacking around and I don't want multiple potentially competing versions of Aurora. In simple terms, I want to maintain control over my creation.

Now it might seem 'weird' to you that I am not prepared to hand over my work to everyone and that's fine. I'm not trying to defend my stance on this, I am simply stating it so there is no confusion.



Okay, thanks for the clarifications, I believed those arguments to be about having people working on the actual game, not about open sourcing it.  :) While I largely disagree with some of those arguments its not up to me and you have made up your mind and I respect your wishes, so its pointless to debate, especially here. Weird simply because for me my default nature and thinking is to share things with others unless there is very good reason not to but people are different. Thanks for taking the time to answer and I hope you will reconsider one day as I would love to do some work expanding certain areas of the game.

Anyway, really excited for the release and appreciative of the hard work you are doing for us all!

Fer Cthullu's sake!

Steve is very nearly NOT releasing C# Aurora in ANY format to the public, because you all can't respect the mans property.

There will be no mod support. The source code will not be released. That's pretty clear from the MULTIPLE posts and thread that Steve created.

Imagine you had a boat, that you had built from scratch. It took several hundred hours to create. Now imagine sharing that boat with everyone, because you are proud of it. Now imagine everyone chopping that boat to pieces, changing things around to suit them. That boat that you built, suddenly doesn't look like your boat, your labor of love.

I would really, really, really like to actually be allowed to play with Aurora C#. I would like it to be released in a few weeks.

There is already a delay, caused by this community, with the repeated blatant statements that you will not respect the mans wishes, and will simply hack the source code anyway. This has led to an actual DELAY!!!

Please just respect Steve's wishes.

It isn't like its hard to figure them out.

Calm down buddy, I was just asking him to clarify since the post he made left me a bit confused about it, no need toget so upset over it. I am not going to get into a debate over the merits of freedom of information but suffice to say, a lot of of what you said I find to be incorrect of misleading and if you want me to explain how you can send me a message and I am happy to have a talk about it there, this thread is not the place. That is all I have to say about that, I am not demanding anything but please do keep a civil and respectful tone and don't treat me and others who have a different opinions and disagree with you and at perhaps Steve as if we are idiots. We, or at least I am, are fully aware of most arguments for and against open sourcing code, no need to be so derisive when making arguments.



There's a password for Space Master functions (if left blank Aurora treats this as 'no password').  You can lock each race behind its own password.

I can't remember if the current version supports locking time advance behind the SM password, but you can instruct your players that only the SM will advance time.

Now you can email the database to each player in turn (or use some sort of virtual drive and versioning support) and 'run' multiplayer Aurora.

(Note, however, that when two (or more) players start fighting each other the game is going to bog down to an epic degree.  It can take days or even weeks for players A & B to finish a three-Aurora-hour fight during which players C through H can do nothing.)

Problem with that is its entirely honor based. Might work if you do it with close friends, but if you do some forum game or something its almost guaranteed someone will advance the game to know whats going to happen to get an advantage.

As for it taking a long time, well, hence the suggestion to make it multiplayer so one can do live battles and not have the battles bog down games forever.
Title: Re: C# Aurora v0.x Suggestions
Post by: SultanPepper on March 15, 2020, 05:14:17 AM
VERY much a long term idea, just wanting to put this out there.

A game style similar to Freelancer(kinda) and whatnot.  Player race handed off to NPR, player only controls one Task Force, has to buy new ships with wealth.  I know it's vastly different to what Aurora is, but this is a suggestions forum isn't it?

Essentially it'd be like Adventurer in Dwarf Fortress.  The player would control their captain/whoever in the universe as is.

Again, VERY MUCH a long term suggestion, thought I'd throw it out and see what people think.

As for the open-source nonsense, people who want open-source, moddable Aurora should go and code their own.  Steve doesn't want it open source, or cracking the code, or anything.  Small-ass price to pay for the game.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 15, 2020, 05:41:47 AM
Maybe Steve could create an option that blocks time Progression for regular players if activated?

Don’t know if the one who is creating quasar 4x would appreciate having people helping him?
Title: Re: C# Aurora v0.x Suggestions
Post by: Inglonias on March 15, 2020, 07:14:21 AM

Problem with that is its entirely honor based. Might work if you do it with close friends, but if you do some forum game or something its almost guaranteed someone will advance the game to know whats going to happen to get an advantage.

As for it taking a long time, well, hence the suggestion to make it multiplayer so one can do live battles and not have the battles bog down games forever.

I mean, there's nothing stopping me from clambering over the poker table and looking at my opponents' hands either, or walking behind the DM screen and taking a sneak peek. If someone goes and ruins the game, stop playing with them.

Maybe Steve could create an option that blocks time Progression for regular players if activated?

All of my above statements being said, this would also work.
Title: Re: C# Aurora v0.x Suggestions
Post by: Nori on March 15, 2020, 08:00:22 PM
Oh boy... Modding rears up again. I generally love modding, but I can also understand why a developer wouldn't want it.

That being said, my biggest concern is that, God forbid, something bad happens to Steve and Aurora dies off. Hopefully Steve has given some trusted person access, just in case.

Anywho, super excited for the impending release. Best wishes to all and stay safe and healthy.
Title: Re: C# Aurora v0.x Suggestions
Post by: Vasious on March 16, 2020, 01:43:41 AM
Reading the FAQ Modding and Open source posts, I'd quite understand and support a decision to not release C# to the public, especially if code obfuscation became too time consuming or burdensome.

I'd just hope we'd still get to share the fiction from C#
Title: Re: C# Aurora v0.x Suggestions
Post by: Zhatelier on March 16, 2020, 03:47:15 PM
Now, firstly, if this has already been suggested (or implemented), my apologies.

But a feature I'd like to see for role-playing purposes is the ability to give the control of a race to the AI permanently, effectively converting it into an NPR, control of which you couldn't take back without the developer mode.  This wouldn't exactly need to be a high priority feature, should Steve be interested in this, but rather if/when there's enough loose time to implement it in.

The reason why I'm expressing interest in this is somewhat selfish: I'm planning for my first proper playthrough for C# Aurora and I'm toying with an idea of around 4-14* NPRs, but I'd like to personalize each one of them a bit, give some initial ship designs, starting fleets etc.  to make things somewhat balanced but also have a control on the starting varieties between the races.

* A run as Pirates utilizing mostly carronades and boarding parties with the NPRs modelled after various (naval) powers from 17th & 18th century, like Britain, France, Spain etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 16, 2020, 04:10:08 PM
But a feature I'd like to see for role-playing purposes is the ability to give the control of a race to the AI permanently, effectively converting it into an NPR, control of which you couldn't take back without the developer mode.  This wouldn't exactly need to be a high priority feature, should Steve be interested in this, but rather if/when there's enough loose time to implement it in.

It's on the wish list, but the complexities of 'taking over' an empire that wasn't designed according to NPR AI rules are vast and daunting -- and the AI rules don't currently include "don't use missiles" or "rely heavily on boarding actions" or "only build general-purpose cruisers."
Title: Re: C# Aurora v0.x Suggestions
Post by: Zhatelier on March 16, 2020, 04:16:49 PM
Quote from: Father Tim link=topic=9841. msg119684#msg119684 date=1584393008
It's on the wish list, but the complexities of 'taking over' an empire that wasn't designed according to NPR AI rules are vast and daunting -- and the AI rules don't currently include "don't use missiles" or "rely heavily on boarding actions" or "only build general-purpose cruisers. "
I'm not actually saying it needs to have special rules, in my opinion, the AI could take everything to a completely different direction if deemed it better.  But I do understand that it isn't nearly as simple as it might sound and hence probably shouldn't be very high on the priority list.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 16, 2020, 05:00:49 PM
Quote from: Father Tim link=topic=9841. msg119684#msg119684 date=1584393008
It's on the wish list, but the complexities of 'taking over' an empire that wasn't designed according to NPR AI rules are vast and daunting -- and the AI rules don't currently include "don't use missiles" or "rely heavily on boarding actions" or "only build general-purpose cruisers. "
I'm not actually saying it needs to have special rules, in my opinion, the AI could take everything to a completely different direction if deemed it better.  But I do understand that it isn't nearly as simple as it might sound and hence probably shouldn't be very high on the priority list.

It's extremely complex and therefore unlikely to happen any time soon. The AI currently decides on a doctrine and then designs and builds a fleet according to that doctrine. It knows what everything does, because it was built to a plan. It would be a lore more complex for the AI to understand everything designed by the player and then develop a doctrine of its own based on those designs.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on March 16, 2020, 05:04:23 PM
Quote from: Father Tim link=topic=9841. msg119684#msg119684 date=1584393008
It's on the wish list, but the complexities of 'taking over' an empire that wasn't designed according to NPR AI rules are vast and daunting -- and the AI rules don't currently include "don't use missiles" or "rely heavily on boarding actions" or "only build general-purpose cruisers. "
I'm not actually saying it needs to have special rules, in my opinion, the AI could take everything to a completely different direction if deemed it better.  But I do understand that it isn't nearly as simple as it might sound and hence probably shouldn't be very high on the priority list.

It's extremely complex and therefore unlikely to happen any time soon. The AI currently decides on a doctrine and then designs and builds a fleet according to that doctrine. It knows what everything does, because it was built to a plan. It would be a lore more complex for the AI to understand everything designed by the player and then develop a doctrine of its own based on those designs.

As an intermediary "fix" you could make it possible for the player to choose the AI ship building theme for an NPR... that would to some degree help in this case. It would then choose technologies according to that scheme and build the ships based on that AI theme.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zhatelier on March 16, 2020, 05:45:23 PM
Quote from: Steve Walmsley
It's extremely complex and therefore unlikely to happen any time soon.  The AI currently decides on a doctrine and then designs and builds a fleet according to that doctrine.  It knows what everything does, because it was built to a plan.  It would be a lore more complex for the AI to understand everything designed by the player and then develop a doctrine of its own based on those designs.
Quite understandable.  I reckon the AI could just roll for the doctrine and ignore any potentially pre-existing designs, that would cut some corners and make it a bit less complex for the AI.  That would risk losing some work, but I suppose a warning message about AI ignoring certain stuff would prevent it from being a surprise for the player.  Handing the stuff for AI to handle once you've set up stuff, like colonies in multiple pre-generated systems with various installations, and so forth, would make things less prone for accidents.  I do realize that it can be done through already existing tools to a degree via SM, but the ability to double-check the details before handing the keys would be handy.  I'm aware that my scenario is going to be most likely a very rare in nature compared to the average playthrough and I'll make do with any tools available to the best of my abilities  :)
Title: Re: C# Aurora v0.x Suggestions
Post by: professorpicke on March 16, 2020, 05:52:55 PM
Quote from: Father Tim link=topic=9841. msg119594#msg119594 date=1584184414
Uh, there isn't one.   There's no 'dodge bonus' or anything for Agility -- it has zero effect on defense, only on chance to hit.

Oh I didn't even think of that.  I guess agility does serve a real purpose.  I'd like to change my suggestion to keep agility, but do not make it a size you type in.  Instead make it a technology you choose to equip or not equip, that reduces your speed by say 20% but increases hitchance by 50% (for the slower speed), with the hitchance increasing with research.  Really all I cared about was getting rid of the spreadsheet.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on March 16, 2020, 06:08:48 PM
Quote from: Steve Walmsley
It's extremely complex and therefore unlikely to happen any time soon.  The AI currently decides on a doctrine and then designs and builds a fleet according to that doctrine.  It knows what everything does, because it was built to a plan.  It would be a lore more complex for the AI to understand everything designed by the player and then develop a doctrine of its own based on those designs.
Quite understandable.  I reckon the AI could just roll for the doctrine and ignore any potentially pre-existing designs, that would cut some corners and make it a bit less complex for the AI.  That would risk losing some work, but I suppose a warning message about AI ignoring certain stuff would prevent it from being a surprise for the player.  Handing the stuff for AI to handle once you've set up stuff, like colonies in multiple pre-generated systems with various installations, and so forth, would make things less prone for accidents.  I do realize that it can be done through already existing tools to a degree via SM, but the ability to double-check the details before handing the keys would be handy.  I'm aware that my scenario is going to be most likely a very rare in nature compared to the average playthrough and I'll make do with any tools available to the best of my abilities  :)

I mean, the ai won't know what to do with the ships you give it at all, so ignoring them would presumably mean the ships are stationary and do nothing.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on March 16, 2020, 06:14:20 PM
Quote from: Steve Walmsley
It's extremely complex and therefore unlikely to happen any time soon.  The AI currently decides on a doctrine and then designs and builds a fleet according to that doctrine.  It knows what everything does, because it was built to a plan.  It would be a lore more complex for the AI to understand everything designed by the player and then develop a doctrine of its own based on those designs.
Quite understandable.  I reckon the AI could just roll for the doctrine and ignore any potentially pre-existing designs, that would cut some corners and make it a bit less complex for the AI.  That would risk losing some work, but I suppose a warning message about AI ignoring certain stuff would prevent it from being a surprise for the player.  Handing the stuff for AI to handle once you've set up stuff, like colonies in multiple pre-generated systems with various installations, and so forth, would make things less prone for accidents.  I do realize that it can be done through already existing tools to a degree via SM, but the ability to double-check the details before handing the keys would be handy.  I'm aware that my scenario is going to be most likely a very rare in nature compared to the average playthrough and I'll make do with any tools available to the best of my abilities  :)

I mean, the ai won't know what to do with the ships you give it at all, so ignoring them would presumably mean the ships are stationary and do nothing.

Yes... I think that making the player do anything for the NPR are probably off the table in any instance, that seem very complex and not worth doing. You should at best choose a specifc theme for the AI and the the NPR is created from that theme using that themed AI behaviour.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on March 17, 2020, 12:35:21 AM
I think that is potentially a pretty good option.  Have some ability to configure (some/all?) of the factors that go into the AI's design behavior that would have otherwise have been random.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 17, 2020, 05:08:04 AM
I think that is potentially a pretty good option.  Have some ability to configure (some/all?) of the factors that go into the AI's design behavior that would have otherwise have been random.

I won't do this for release, but this should be straightforward when I get to it.
Title: Re: C# Aurora v0.x Suggestions
Post by: hostergaard on March 17, 2020, 06:06:16 AM
Not sure if its been suggested or already in the game, the list over features is getting pretty long so its hard to find out but

Being able to use theoretical designs and research projects in ships design and other projects

I have before made various suggestions on ship design, but one thing that would be lovely is being able to use designs that you have made but not yet researched when designing ships and other things. Its really annoying having to guess or calculate how big a jumpdrive or cloak or whatever you need when designing a ship and getting it wrong and having to design and research a new one that fits cause you it more crew quarters than you expected or something. Instead you could make a ship that included various possible designs that are yet to be researched and then research the design.
Title: Re: C# Aurora v0.x Suggestions
Post by: Akhillis on March 17, 2020, 06:26:24 AM
Not sure if its been suggested or already in the game, the list over features is getting pretty long so its hard to find out but

Being able to use theoretical designs and research projects in ships design and other projects

I have before made various suggestions on ship design, but one thing that would be lovely is being able to use designs that you have made but not yet researched when designing ships and other things. Its really annoying having to guess or calculate how big a jumpdrive or cloak or whatever you need when designing a ship and getting it wrong and having to design and research a new one that fits cause you it more crew quarters than you expected or something. Instead you could make a ship that included various possible designs that are yet to be researched and then research the design.

http://aurora2.pentarch.org/index.php?topic=8495.msg119332#msg119332 (http://aurora2.pentarch.org/index.php?topic=8495.msg119332#msg119332)

Already in.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 17, 2020, 07:02:15 AM
When Quasar4x is up it will have external access to the AI - and if that system works maybe that sparks ideas in Steve's mind to go into same/identical direction. Would be nice if AI could be improved over time.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on March 17, 2020, 10:34:59 AM
At some point in the future it'll be nice to have a certain 'fuzziness' to active and passive sensor detection. Detection of vessels is only guaranteed till a certain percentage of the sensor range against that TCS, with the percentage detection chance per increment (probably an hour?) dropping linearly till the maximum sensor range. Effectively, at the edge of sensor ranges ships could remain undetected or they could only be tracked very sporadically. This will extend to missile fire controls and the like. ECM and ECCM will modify the detection chance per increment for both active sensors and missile fire controls, but not passive sensors.

There could also be a modifier allowing you to trade between maximum sensor range and the maximum range at which detection is guaranteed while maintaining sensor cost and GPS. I think this might quite neatly solve the fighter issue - with active sensors modified to have a very high maximum range but a very low maximum range at which detection is guaranteed, fighter squadrons will eventually be detected by shipborne active sensors at long ranges, but they won't be tracked continuously and firing missiles will be foolhardy. You'll have to dispatch a destroyer squadron or two to investigate, so you'll be encouraged to maintain escort vessels for your fleets.

Of course, the main drawback as usual will be game performance degradation. On the plus side - more choices to active sensors design, a reason to bring along escorts, more vulnerable box launcher fighter squadrons, etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 17, 2020, 10:40:07 AM
At some point in the future it'll be nice to have a certain 'fuzziness' to active and passive sensor detection. Detection of vessels is only guaranteed till a certain percentage of the sensor range against that TCS, with the percentage detection chance per increment (probably an hour?) dropping linearly till the maximum sensor range. Effectively, at the edge of sensor ranges ships could remain undetected or they could only be tracked very sporadically. This will extend to missile fire controls and the like. ECM and ECCM will modify the detection chance per increment for both active sensors and missile fire controls, but not passive sensors.

There could also be a modifier allowing you to trade between maximum sensor range and the maximum range at which detection is guaranteed while maintaining sensor cost and GPS. I think this might quite neatly solve the fighter issue - with active sensors modified to have a very high maximum range but a very low maximum range at which detection is guaranteed, fighter squadrons will eventually be detected by shipborne active sensors at long ranges, but they won't be tracked continuously and firing missiles will be foolhardy. You'll have to dispatch a destroyer squadron or two to investigate, so you'll be encouraged to maintain escort vessels for your fleets.

Of course, the main drawback as usual will be game performance degradation. On the plus side - more choices to active sensors design, a reason to bring along escorts, more vulnerable box launcher fighter squadrons, etc.

The sensor model used to function differently. For example, you only saw a thermal signature - but you couldn't tell the ship. The consequence was extra micromanagement to send out a ship to check every contact, which got tedious fast, so I moved to the current immediate-knowledge model instead.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on March 17, 2020, 10:52:10 AM
The sensor model used to function differently. For example, you only saw a thermal signature - but you couldn't tell the ship. The consequence was extra micromanagement to send out a ship to check every contact, which got tedious fast, so I moved to the current immediate-knowledge model instead.

That sounds fair enough. Speaking of small ship detection, what is your verdict on the modifier to detection range for TCS smaller than sensor resolution? I recall that we had a conversation earlier where I mentioned that the (TCS / Resolution)^2 dropoff was too steep and reducing the size of fighters by 50-100 dT, which is quite trivial for box launcher fighters, often makes existing sensors totally useless. Having a single fighter-resolution sensor is fine, but being forced to have three or four separate sensors to find small, medium and large fighters, and FACs gets annoying and expensive fast.

You mentioned that you would check and rebalance if necessary?
Title: Re: C# Aurora v0.x Suggestions
Post by: Ektor on March 18, 2020, 03:03:27 PM
Some people were talking about ground combat on the Discord and one guy basically came up with the idea of "engineers" or "anti-fortification" roles, basically, it would be a weapon type put onto infantry or vehicles that would counter-act the fortification bonus of an entrenched enemy.  He was thinking more on the lines of support vehicles and engineers, whilst I though it might also represent SPGs and other types of fortification busters.

Some other people gave the idea of adding a medical type to add to formations that would reduce the number of casualties.

I found those pretty good ideas, what do you guys say?
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on March 18, 2020, 04:29:51 PM
The problem with a medical unit with a saving chance is that they basically shift the combat investment, by possibly a large margin and with great difficulty to predict when and how. A medical unit saving PW infantry doesn't save you that much in shipping and minerals, but a medical unit saving an Ultra Heavy Vehicle with 4 weapon slots? That's a big chunk of resources that suddenly didn't go up in a ball of fire. And worse, for the opposing side that's a big chunk of resources they invested in bringing the UHV down that just got cancelled. UHVs ain't cheap, but they are also very tough, and difficult to destroy.

A key component of good game design is that you can predict, at least to some extent, how a given event is going to play out. A random result should not be capable of majorly impacting the course of an event, especially when you can't know what you will be up against and thus not predict what you'll be dealing with anyway. It just gets frustrating.


As for the engineering trait/component, that idea has merit to me, but I don't think Steve's going to implement it for Aurora C# 0.1. It's something for later at a minimum.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zhatelier on March 18, 2020, 05:18:43 PM
One way to implement the medical units would be another tech line for field medicine.  Say the first level (potentially one you start with) would be 1% and the tech goes up to 10%.  Casualty trickle back would be calculated by ( medical efficiency / armour level of the unit).  That way the infantry would get the full benefit of the medical unit but armoured units would benefit less.  What takes down a trooper is more likely to be of smaller calibre than something that takes out a heavy tank.  The numbers could be tweaked, but personally I wouldn't go over 25% as a max.  Another idea to add to this would be the amount of personnel that a single medical unit can service, again improvable by tech, but to that, I'm unable to give example figures at this time.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on March 18, 2020, 05:47:23 PM
This would be useful if there was a manpower mechanic attached to ground combat, but there isn't. Ground units are very much depicted by their equipment, and the manpower attached to it is utterly inconsequential. A PW(L) infantryman may be rated at 3 tons in weight/shipping, but does that mean that a 60 ton Heavy Anti Vehicle Static Unit is made up of 20 men?
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on March 18, 2020, 10:38:20 PM
Could we have it so the Technology Screen shows us what is in use and what isn't? So we can make those parts obsolete easier.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on March 19, 2020, 02:13:48 PM
This would be useful if there was a manpower mechanic attached to ground combat, but there isn't. Ground units are very much depicted by their equipment, and the manpower attached to it is utterly inconsequential. A PW(L) infantryman may be rated at 3 tons in weight/shipping, but does that mean that a 60 ton Heavy Anti Vehicle Static Unit is made up of 20 men?
Agreed with Hazard.

It's very difficult to justify a Medical Unit when there is nothing that ties down units to manpower or even biology. So it would need to be generic Field Repair Unit(s) that have a chance of saving a unit that got hit and destroyed. Two new tech lines: one to improve the chance of saving and another to improve the tonnage size of the unit - for example, you would start with a FRU that can save 5 tons at combat round at 5% chance and eventually go up to 500 tons at 25% chance. That way you can't save Ultra-Heavy Vehicles or Super-Heavy Vehicles or maybe you can if the tech lines are allowed to go even higher.

The engineering equipment should be both defensive and offensive - on unarmoured light vehicles you would only help fortify your defensive units whereas on strongly armoured heavy vehicles it'll help reduce enemy defences with your other attackers.
Title: Re: C# Aurora v0.x Suggestions
Post by: Zhatelier on March 20, 2020, 03:07:15 AM
I was wondering, would it be possible to have an ability to add in entries into the event log in SM mode.  I'm not asking for the entries to have any function into the game itself, mostly for flavour.  As I see it, it would require the ability to select which empire will see the entry, location (if applicable) and a text field.  After making the entry, it would appear in the selected empire's event log in addition to the SM view.
An example of a custom entry could be something like this:

Great Britain      The Caribbean      HMS Cornwall has plundered San Antonio [SPA] for 200 wealth.
(And from the other side with a second custom entry)
Spain                The Caribbean      Our ship San Antonio was plundered by HMS Cornwall [GB] for 200 wealth.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rook on March 24, 2020, 06:28:19 AM
Two Suggestions, though I haven't torn through this thread in a while, so I'm not sure if these have been covered.  .  . 

First, Parasite Naming theme based on assigned group:
 The idea here is that a naming theme can be a assigned to a sub-group, and, possibly, only to parasites within that subgroup.   When a parasite is transferred to that subgroup, it is automatically renamed according to the naming theme.   Making it easier to apply callsigns to Parasites.   The purpose is purely for flavor, where your fleet has callsigns for different fighter groups.   

Second, Covert/Submarine Patrol Order:
 An Advanced order for reconnaissance craft with low signatures/stealth capability.   This order will automatically assign headings and speeds, based on fuel status, its signature, its own sensor range, and known enemy sensor ranges, to scout a system for contacts.   The idea here is that a ship will automatically scout a system, but avoid detection.   As well, for "long duration missions" it will keep its speed low during patrol to conserve fuel, but increase speed as necessary to avoid detection or evade hostile ships.  An additional thought, an area within the system could be designated for the patrol order, or boundaries set, to limit the search area.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 24, 2020, 01:44:39 PM
. . . As well, for "long duration missions" it will keep its speed low during patrol to conserve fuel, but increase speed as necessary to avoid detection or evade hostile ships. . .

Speed has zero effect on fuel efficiency.  Fuel per unit distance is constant regardless of whether it's at 2 km/s or 20,000 km/s.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on March 25, 2020, 12:32:05 AM
I was wondering, could certain system bodies that are in close orbit of gas giants or near a hyperactive star have a minimum radiation level? Like, for most system bodies radiation will eventually settle down to zero, but for these, it will instead start at a base number within range of around 10-200 or so, determined by proximity to a star (below a certain orbit radius) and type of star (focusing on flare stars, neutron stars, pulsars and the like) and proximity to a gas giant (below a certain orbit radius) and the magnetic field strength of the gas giant. Radiation level will not decline below this fixed number. I'm mostly asking so we need to actually need to think twice between colonising radioactive hellholes like Io and its much calmer neighbour Callisto, which in Aurora are functionally identical. Of course really mineral rich bodies might still be worth colonising despite the efficiency hit.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tyrannus Rex on March 25, 2020, 04:57:59 AM
Quote from: SevenOfCarina link=topic=9841. msg119979#msg119979 date=1585114325
I was wondering, could certain system bodies that are in close orbit of gas giants or near a hyperactive star have a minimum radiation level? Like, for most system bodies radiation will eventually settle down to zero, but for these, it will instead start at a base number within range of around 10-200 or so, determined by proximity to a star (below a certain orbit radius) and type of star (focusing on flare stars, neutron stars, pulsars and the like) and proximity to a gas giant (below a certain orbit radius) and the magnetic field strength of the gas giant.  Radiation level will not decline below this fixed number.  I'm mostly asking so we need to actually need to think twice between colonising radioactive hellholes like Io and its much calmer neighbour Callisto, which in Aurora are functionally identical.  Of course really mineral rich bodies might still be worth colonising despite the efficiency hit.

This would be an excellent thing to have implemented.  As such even if you had a wonderful mineral rich planet that you wanted to collect, paying the costs of a constant Radiation penalty would be interesting.  Maybe to tie in with this is that you had to have shields, or thicker armor to approach said objects.  Making it just a little bit of a challenge for some, or just a flavor for RP purposes.
Title: Re: C# Aurora v0.x Suggestions
Post by: obsidian_green on March 25, 2020, 11:31:25 PM

Second, Covert/Submarine Patrol Order:
 An Advanced order for reconnaissance craft with low signatures/stealth capability.   This order will automatically assign headings and speeds, based on fuel status, its signature, its own sensor range, and known enemy sensor ranges, to scout a system for contacts.   The idea here is that a ship will automatically scout a system, but avoid detection.   As well, for "long duration missions" it will keep its speed low during patrol to conserve fuel, but increase speed as necessary to avoid detection or evade hostile ships.  An additional thought, an area within the system could be designated for the patrol order, or boundaries set, to limit the search area.

I love this idea, more because the logic could be employed by NPRs. If the mechanics haven't changed from 7.1, lower speed would reduce IR signature. Every working tool in the AI toolbox can increase the chances of pleasant surprises from NPRs.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on March 26, 2020, 09:39:13 AM
With the C# release date literally around the corner, it's probably a bit late to ask for this, but could there be a global modifier to survey speed like with terraforming speed at game start? Sometimes it's worthwhile to play a game where exploration is deliberately slow, so much so that significant colonies and industry could already be in place before a system has been fully surveyed. You could have a giant hostile empire a literal four or five jumps away, right on your doorstep, and you wouldn't find out till you've already expanded right next to them.

I'm asking because I really love the thought of massive defensive wars and grinding campaigns through hostile territory, but most of my VB6 campaigns don't really go there because hostile empires are either too distant or they're encountered so early that the intervening space is mostly unoccupied, so wars devolve down to rushing the entire fleet to their capital before they can do the same to you, or turtling in for a long military build-up because there are no colonies that you need to worry about defending.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 26, 2020, 11:01:21 AM
With the C# release date literally around the corner, it's probably a bit late to ask for this, but could there be a global modifier to survey speed like with terraforming speed at game start? Sometimes it's worthwhile to play a game where exploration is deliberately slow, so much so that significant colonies and industry could already be in place before a system has been fully surveyed. You could have a giant hostile empire a literal four or five jumps away, right on your doorstep, and you wouldn't find out till you've already expanded right next to them.

I'm asking because I really love the thought of massive defensive wars and grinding campaigns through hostile territory, but most of my VB6 campaigns don't really go there because hostile empires are either too distant or they're encountered so early that the intervening space is mostly unoccupied, so wars devolve down to rushing the entire fleet to their capital before they can do the same to you, or turtling in for a long military build-up because there are no colonies that you need to worry about defending.

That's a good idea. I've added it.

http://aurora2.pentarch.org/index.php?topic=8495.msg119998#msg119998

EDIT: Good thing you suggested this as it highlighted a problem with saving game settings :)
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on March 28, 2020, 12:22:36 PM
What with all of the global modifier suggestions and features going around, would it be possible to have a maintenance modifier that affects how much tonnage maintenance facilities support (and how many MSPs they produce)?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 28, 2020, 12:24:46 PM
What with all of the global modifier suggestions and features going around, would it be possible to have a maintenance modifier that affects how much tonnage maintenance facilities support (and how many MSPs they produce)?

There is a tech line for both so you can SM the extra if required.
Title: Re: C# Aurora v0.x Suggestions
Post by: Shuul on March 28, 2020, 12:49:15 PM
Can I suggest to limit possible weapons. For ships with diplomacy module just to ciws? I feel like this can be exploited if we can fit them with weapons for first strike.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 28, 2020, 02:00:57 PM
Can I suggest to limit possible weapons. For ships with diplomacy module just to ciws? I feel like this can be exploited if we can fit them with weapons for first strike.

I've updated the Diplomacy Part 2 post with the following text.

NPRs deduct 10,000 tons from the tonnage of one Diplomatic Ship per system for threat purposes if that class type has never fired weapons and the Diplomatic Ship is in a non-Core system. If the NPR only has one system, it is not treated as core for this purpose

It will be possible to send in an armed Diplomatic Ship for some form of sneak attack. However, the Diplomacy Module is 1500 tons, so once engines and maybe a jump drive are added, there isn't much room for weapons. You could send a Diplomatic Ship larger than 10,000 tons, although that would cause a diplomatic penalty for the excess whenever you use the ship and most of the time you won't be conducting sneak attacks. Finally, missiles are detected on launch now so you can't get inside PD range. So sneak attack is possible (try to take out shipyards in a mass box launcher attack maybe) but I don't think that is overpowered.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on March 28, 2020, 03:34:34 PM
Is that deduction before or after commercial engine modifier?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 28, 2020, 04:46:49 PM
Is that deduction before or after commercial engine modifier?

Before.
Title: Re: C# Aurora v0.x Suggestions
Post by: DIT_grue on March 29, 2020, 12:39:17 AM
Can I suggest to limit possible weapons. For ships with diplomacy module just to ciws? I feel like this can be exploited if we can fit them with weapons for first strike.

Besides Steve's answer, while Star Trek roleplay doesn't fall into my own range of playstyles, it seems quite popular here - especially if we include themes recognisably trending in that direction or narratives that independently arrive at similar outcomes. Outright forbidding it doesn't seem appropriate or justified.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on March 29, 2020, 05:25:11 AM
I think its completely justified because the AI has a really limited ability to deal with it.  If the AI had some way to search the ship for weapons as it approaches their capital, then you should be able to put weapons on your diplomatic ships.  Otherwise its just silly to expect to get away with that kind of nonsense and expect the AI to make no attempt to stop you or check that you are lying about your diplomacy ship as it approaches something important.  You are arguing to put subterfuge into a game with no established system to fight back against that (including on your own behalf should the AI start doing that).
Title: Re: C# Aurora v0.x Suggestions
Post by: Veneke on March 29, 2020, 05:39:35 AM
Is it possible for ships to be grouped by race? For instance, in the screenshot below it would be useful for HOT, MAR, and JOV entries to be grouped together rather than going back and forth between them.
 
(http://www.pentarch.org/steve/Screenshots/Crusade/1889_014.PNG)
 
It's not a big issue, and only really a problem for situations like the above where you're trying to make sense of a jumble of information from multiple races clustered on a single body.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 29, 2020, 06:05:01 AM
Is it possible for ships to be grouped by race? For instance, in the screenshot below it would be useful for HOT, MAR, and JOV entries to be grouped together rather than going back and forth between them.

Yes, that would look better. Here is the updated version.

(http://www.pentarch.org/steve/Screenshots/Crusade/NewOrder.PNG)
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on March 29, 2020, 06:09:41 AM

Yes, that would look better. Here is the updated version.

(http://www.pentarch.org/steve/Screenshots/Crusade/NewOrder.PNG)

Not to bother you further, Steve, but is there any chance we could specify certain colours for a known empire apart from the standard hostile/neutral/friendly? In this circumstance, contacts from Mars would be orange with orange text, contacts from Venus would be yellow with yellow text, etc. It'll make things a lot more readable, but it's fine as it is.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 29, 2020, 06:14:44 AM
Not to bother you further, Steve, but is there any chance we could specify certain colours for a known empire apart from the standard hostile/neutral/friendly? In this circumstance, contacts from Mars would be orange with orange text, contacts from Venus would be yellow with yellow text, etc. It'll make things a lot more readable, but it's fine as it is.

That might get confusing if there are a lot of races. I've tried to keep the number of colours relatively low on the map so it is easy to recognise different objects.
Title: Re: C# Aurora v0.x Suggestions
Post by: SevenOfCarina on March 29, 2020, 06:19:02 AM
That might get confusing if there are a lot of races. I've tried to keep the number of colours relatively low on the map so it is easy to recognise different objects.

Fair enough. What about moving the empire designation to the front? So it'll be like this :
[MAR] 2x Huangwen 6449 tons Thermal 6 0 km/s
And not like this :
2x Huangwen 6449 tons Thermal 6 0 km/s [MAR]
Title: Re: C# Aurora v0.x Suggestions
Post by: Zincat on March 29, 2020, 07:44:16 AM
That might get confusing if there are a lot of races. I've tried to keep the number of colours relatively low on the map so it is easy to recognise different objects.

Fair enough. What about moving the empire designation to the front? So it'll be like this :
[MAR] 2x Huangwen 6449 tons Thermal 6 0 km/s
And not like this :
2x Huangwen 6449 tons Thermal 6 0 km/s [MAR]

I think this would make a lot of sense, and be especially useful with many races or complex situations. After all, you're likely only caring about one or two at a time, and having the race designation in front allows to quickly skip all the ones you don't care about.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 29, 2020, 08:21:02 AM
That might get confusing if there are a lot of races. I've tried to keep the number of colours relatively low on the map so it is easy to recognise different objects.

Fair enough. What about moving the empire designation to the front? So it'll be like this :
[MAR] 2x Huangwen 6449 tons Thermal 6 0 km/s
And not like this :
2x Huangwen 6449 tons Thermal 6 0 km/s [MAR]

Yes, that looks much better, both for single contacts and groups

(http://www.pentarch.org/steve/Screenshots/Crusade/NewOrder02.PNG)
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on March 29, 2020, 09:08:27 AM
Regarding diplo ships being limited in weaponry: I strongly disagree.

Almost all ambassadorial ships in history and the current world are armed to some degree or another. The Ming treasure fleet, HMS Victory, Perry's expedition to Japan, SMS Panther, SMS Goeben, and all modern aircraft carriers, just off the top of my head. I'd go so far as to say that an implication of the ability to project force is part and parcel of diplomacy, though I don't really expect that to be reflected in the diplomatic code because that would be super-complex.

Rather, I'd go the other way, even, and argue that any ship with a flag bridge should also be able to act as a diplomatic ship, albeit probably at a reduced ability compared to one with a diplomatic module attached; it wouldn't be the first time in history an ambassador has commandeered CIC for diplomacy.

Rather, I have a simpler proposal for limiting the possibility of people sneaking in warships under cover of diplomacy to get away with surprise attacks. If you have an active diplomatic ship in system or have had an active diplomatic ship in system recently (perhaps within a year?) and you begin hostilities, you take an extreme relationship hit with the NPR in question and with all others who witness or hear about the event (all NPRs with assets in system as well as all NPRs with whom they have established communications).

Could you still use a diplomatic mission to sneak ships in under the flag of peace for a dastardly bombardment? Yes. Is that necessarily a good idea if your galaxy has a web of diplomatic contacts in place already? Probably not.
Title: Re: C# Aurora v0.x Suggestions
Post by: Scandinavian on March 29, 2020, 01:40:06 PM
Another option would be to have the interlocutor automatically gain certain intelligence on the vessel acting as a diplomatic envoy. Perhaps simply accumulating over time, or perhaps as a prerequisite for reaching a certain relationship status.

While it is plausible that one might negotiate an armistice purely over video link, if you are negotiating a joint research initiative it is going to look at best standoffish to not invite the foreign delegation to come over to your embassy for some of the talks. Likewise, once you start issuing travel permits to alien nationals (which is, if not an absolute necessity for, at least strongly conducive to developing a trading relationship), aliens are going to start showing up at your consular offices. Some of those aliens are going to be spies, unless the people running the other guys' foreign intelligence services have rocks and gravel in their heads.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on March 29, 2020, 01:45:50 PM
You might not have the same environmental requirements. Pretty difficult to run face-to-face consular services or round table negotiations if your air is toxic to them. Let's not make things too detailed if they don't have to be.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on March 29, 2020, 05:04:36 PM
You might not have the same environmental requirements. Pretty difficult to run face-to-face consular services or round table negotiations if your air is toxic to them. Let's not make things too detailed if they don't have to be.

I'd be totally cool with a mild, scaling diplomatic penalty for different, exclusive environmental tolerances, with a much larger penalty for 'we breathe oxygen and you breathe methane', that distinction already being mechanically tracked in the game.

Sounds like an after-release sort of thing.
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on March 29, 2020, 05:28:21 PM

I'd be totally cool with a mild, scaling diplomatic penalty for different, exclusive environmental tolerances, with a much larger penalty for 'we breathe oxygen and you breathe methane', that distinction already being mechanically tracked in the game.

Sounds like an after-release sort of thing.

Why would that matter? We can't build multispecies colonies. If anything not having any environmental overlap should give a diplomatic bonus as you won't be competing for the same real estate. For example conflicts and fighting between terrestrial predators and omnivores happen frequently because same needs. But I haven't heard of sealions trying to muscle wolves out of their territory.

I would agree with a worse odds in making contact and communication rolls and chances. Due to the differences and such.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on March 29, 2020, 05:32:47 PM
Why would that matter?

Because it's hard to have intricate trust-based conversations if you can't even stand in the same room and read each others' facial expressions.
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on March 29, 2020, 05:51:27 PM
Tell that to my methane breathing viking crab people.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 29, 2020, 05:56:32 PM
Why would that matter?

Because it's hard to have intricate trust-based conversations if you can't even stand in the same room and read each others' facial expressions.

Just because we can stand in the same room, doesn't mean you can read my (species') facial experessions.  Or even know which part is my face.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on March 29, 2020, 06:01:08 PM
Sure, but that's already covered by the fact that diplomacy's hard in the first place.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on March 30, 2020, 01:36:45 AM
Why would that matter?

Because it's hard to have intricate trust-based conversations if you can't even stand in the same room and read each others' facial expressions.

Just because we can stand in the same room, doesn't mean you can read my (species') facial experessions.  Or even know which part is my face.

I would say that ALL species that reach the stars is in some form or another social species and will need physical communication to some degree. Therefore physical interaction no matter the differences might be quite important. If you can understand and learn how each other work then diplomacy can become so much more fruitful.
Title: Re: C# Aurora v0.x Suggestions
Post by: mtm84 on March 30, 2020, 01:52:10 AM
Gentlemen, gentlemen, please.  I think we can all agree that the easiest solution here it to just kill all xeno scum.  Laser fire needs no introduction.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on March 30, 2020, 04:09:10 AM
Gentlemen, gentlemen, please.  I think we can all agree that the easiest solution here it to just kill all xeno scum.  Laser fire needs no introduction.

If force is not solving your problem, you aren't using enough of it.
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on March 30, 2020, 05:41:06 AM
Yes, that looks much better, both for single contacts and groups

(http://www.pentarch.org/steve/Screenshots/Crusade/NewOrder02.PNG)
Just my 2c on this: A small two or three pixel separation after each race (when there is more than one entry in a block) would be the final perfection of this display...  :D
Title: Re: C# Aurora v0.x Suggestions
Post by: Inglonias on March 30, 2020, 10:38:52 AM
This is probably something for after the first release, but it was cool enough that I wanted to bring it up. You know how every race has a picture associated with them in the race details page? I was wondering if it would be possible to do the same thing for ships that we design, or ships that we see in the alien intel window. Basically, just have the option to attach a JPEG image to each ship class we design so that we can have a visual reference if we like.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 30, 2020, 11:17:05 AM
This is probably something for after the first release, but it was cool enough that I wanted to bring it up. You know how every race has a picture associated with them in the race details page? I was wondering if it would be possible to do the same thing for ships that we design, or ships that we see in the alien intel window. Basically, just have the option to attach a JPEG image to each ship class we design so that we can have a visual reference if we like.

It's possible and I've considered it in the past. The problem is most people wouldn't have images for their ships so it would just be a blank area. It can be hard to find sci-fi ship pictures with a common theme, beyond Star Trek, Star Wars, etc.
Title: Re: C# Aurora v0.x Suggestions
Post by: Rich.h on March 30, 2020, 11:25:58 AM
This is probably something for after the first release, but it was cool enough that I wanted to bring it up. You know how every race has a picture associated with them in the race details page? I was wondering if it would be possible to do the same thing for ships that we design, or ships that we see in the alien intel window. Basically, just have the option to attach a JPEG image to each ship class we design so that we can have a visual reference if we like.

It's possible and I've considered it in the past. The problem is most people wouldn't have images for their ships so it would just be a blank area. It can be hard to find sci-fi ship pictures with a common theme, beyond Star Trek, Star Wars, etc.

Would it be possible to have this in two ways.

Firstly so we have a different graphic on the galaxy map for different races, having this allow us to choose the picure would be ideal (in addition could we also have the option to manually change the race graphics for both NPR's in addition to our own).

Secondly have a default image that we choose to start with for our own ships, then allow it to be manually changed on a class by class basis if we choose to.
Title: Re: C# Aurora v0.x Suggestions
Post by: vorpal+5 on March 30, 2020, 01:10:15 PM
That would be cool. I'm gathering ships for a RPG campaign myself (low tech) and there is a surprisingly high number of images available over the internet.

If by default this is the racial ship image, no harm done, right? Then you can perhaps add images on a 'category' basis and if you have a lot of images, you'll add images on a ship class basis. Now, Steve won't be able to add them officially as most will be copyrighted I guess.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on March 30, 2020, 01:11:31 PM
This is probably something for after the first release, but it was cool enough that I wanted to bring it up. You know how every race has a picture associated with them in the race details page? I was wondering if it would be possible to do the same thing for ships that we design, or ships that we see in the alien intel window. Basically, just have the option to attach a JPEG image to each ship class we design so that we can have a visual reference if we like.

It's possible and I've considered it in the past. The problem is most people wouldn't have images for their ships so it would just be a blank area. It can be hard to find sci-fi ship pictures with a common theme, beyond Star Trek, Star Wars, etc.

If you have GalCiv you can build your own and import them into Aurora... I would love to do that to be honest...   ;)

I'm pretty sure the community could come up with enough basic ship sets to satisfy most... at least some generic art to be placed there based on hull type or something.
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on March 30, 2020, 01:58:08 PM
@Jorgen_CAB
in additional to designing our own shipsets, we could use the vast amount of shipsets the space empires community has built over the years.

in addition it would be a bonding of two cadet branches of the Starfire dynasty. as it was concisely noted by sloanjh
....
Historical note:  I'm 99% certain that SE4 is a "sibling" of Aurora, in that both of them got their start with StarFire.  If you look at SE functionality, naming and timing (10 years after Starfire 2nd edition), it would be an amazing coincidence (hence only 99%) if SF wasn't a motivation for SE.  On the other side, I'm not sure if you're aware that the underlying engine for Aurora started off as "StarFire Assistant", until Steve decided to go write his own game (Aurora).
-snipped-
John

EDIT: sorry quarantine and too much crusader kings 2 on my mind.
Title: Re: C# Aurora v0.x Suggestions
Post by: bombastico on March 31, 2020, 06:35:04 AM
Hi Steve!
I'm a fan, player and long-time lurker. . .
Of the aspects of the game "explore-expand-exploit-exterminate" I like more the first two and I would know if there are plans to develop the aspect of colony managing and keep colonies happy, flourishing and healthy.

Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 31, 2020, 09:56:23 AM
Hi Steve!
I'm a fan, player and long-time lurker. . .
Of the aspects of the game "explore-expand-exploit-exterminate" I like more the first two and I would know if there are plans to develop the aspect of colony managing and keep colonies happy, flourishing and healthy.

Nothing beyond what is currently in the changes list. I'll see how things progress after release.
Title: Re: C# Aurora v0.x Suggestions
Post by: bombastico on March 31, 2020, 11:29:52 AM
Ok thank you and have a nice day!
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on March 31, 2020, 01:09:38 PM
I would like a slight overhaul of the technology system so we can't just build labs to produce research points. It should be tied with more factors such as general education and amount of resource spent on higher education.

I also think that even a relatively small empire should be able to match a bigger empire in terms of theoretical research, the difference should be in the amount of applied research two empires can produce. That would mean more restrictions on how much you can focus in any single technology. As it is no really realistic that you can spend labs and expect a linear return of that investment.

I also believe that scientist skill often play too much of a role in the amount of points you get.

I also would like that technologies that give automatic bonuses should scale in cost with the society they impact or if those modifiers can be added in a different way so there is an industrial or scientific cost to implement them throughout an empire. We don't get our ships automatically upgraded with new technology as soon as we discover them, the same thing should be true for the rest of  society as well.
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on March 31, 2020, 03:35:43 PM
Some brainstorming/thoughts.

I would like a slight overhaul of the technology system so we can't just build labs to produce research points. It should be tied with more factors such as general education and amount of resource spent on higher education.

Bringing in education  is a bit of a can of worms / slippery slope here because for it to make sense more and more of the entire civilian sector needs to be modeled, but otherwise I am all for something to make it less linear with empire size which ties in probably more with your next point.

I also think that even a relatively small empire should be able to match a bigger empire in terms of theoretical research, the difference should be in the amount of applied research two empires can produce. That would mean more restrictions on how much you can focus in any single technology. As it is no really realistic that you can spend labs and expect a linear return of that investment.

The feasibility of Tall vs Wide empire strategies is a common debate in all 4x games I've engaged in discussions around, and wide is certainly being VERY favored in Aurora with everything from population growth mechanics to research rewarding spreading out rather than focusing "inward" on quality over quantity. I am also a firm believer that diminishing returns makes almost every simulation-like game better due to it's nature of being self-balancing much more so than a linear scaling is.

I also believe that scientist skill often play too much of a role in the amount of points you get.

For sure. While it feels great to have that 65% * 4 = 3.6 times research speed when you do have it, it's also absolutely devastating to lose it, and it's a bit hard on your immersion to have a single leader over 10 million research workers able to influence the output to such a degree. Another immersion ruining factor is how an empire with billions of subjects can refocus 100% of it's research effort overnight into a totally different area, so some sort of "retooling" delay for labs switching specialization might be something worth considering. I would like the research bonuses to be gained and connected closer to the planet/lab in some way instead and have leaders able to maybe influence it in smaller and more unique/interesting ways in terms of tradeoffs. Maybe some scientists reduce credit cost instead of increase research point output, while those that increase output the greatest also increase credit costs more to mention one option, another is having them influence how many workers the labs need as a tradeoff too ( Classic efficiency vs output ).

I also would like that technologies that give automatic bonuses should scale in cost with the society they impact or if those modifiers can be added in a different way so there is an industrial or scientific cost to implement them throughout an empire. We don't get our ships automatically upgraded with new technology as soon as we discover them, the same thing should be true for the rest of  society as well.

It's a tricky one though to implement in a good way in order to not make it a huge choir and boring aspect of the game to have to upgrade 30 worlds manually each time you research a new tech. One of my favorite implementations of this was in ST:TNG:BotF (http://Star Trek: The Next Generation: Birth of the Federation) ( yes that is the proper abbreviation of the full title). This game let you assign an industrial project to upgrade labs, factories, farms or other building types that became progressively more expensive with tech before being able to enjoy the advantage and it always was such a hard choice what to prioritize and when, especially since the price of obsolete upgrades was significantly reduced so letting a system fall behind made upgrading to the old tech levels much cheaper.

Another abstracted way to achieve something similar might be to have later techs just reduce the worker requirements instead ( or at least mostly provide efficiency improvement this way ) which means that you constantly need to increase the number of factories/labs/finance centers and so on to gain benefit of the later tech levels. ( Building more buildings here is an abstraction/simplification of investments into upgrading to more advanced buildings ). This would probably make the math much harder though to judge how many buildings your population can support unless other UI improvements are made.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on March 31, 2020, 05:18:06 PM
Not sure if I mentioned anywhere but max scientist bonus in C# Aurora is 50%,
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on March 31, 2020, 05:21:07 PM
I'd be happy to see Research Facilities switch from an 'X points per month' basis to a 'random amount per month centered on X points' -- effectively a die roll for each production cycle.  Overall research times should stay roughly the same, but this 2,000 point item might take a month longer than that 2,000 point item.  I'd definitely prefer not to know that my empire will invent a new drive system on Tuesday, September 14th, 926 AL.

I would also prefer to see newly assigned labs & scientists 'ramp up' to their full bonus -- maybe 1-5% per week.  I wouldn't want to penalize racial tech projects for the same team (so that Dr. P&P's labs aren't dropping back to zero for each new size of the same old engine), but I can see arguments both for and against keeping the bonus when going from Magnetic Confinement to Internal Confinement, for example.

- - - - -

A much more radical idea that tempts me is to drastically reduce the number of labs a scientist can oversee (say, to one-fifth of current, i.e. one per admin rating) and to allow multiple lab groups working on the same project to produce combined progress.  (Currently, any research done on Mars is ignored on Earth, and vice versa, unless and until a project is completed.)

So instead of having one super-scientist who can oversee thirty-five labs in one place all working on the next anti-matter engines, you would instead have one scientist with seven labs on Earth, another with five labs on Mars, a third with four labs on Io, etc.  I would want a small penalty (maybe only 10%) to the research produced by the additional scientists to enforce the paradigm that 'a single project under a single leader is more efficient' -- not for "realism" (I don't want to open that can of worms) but because I think there is value in that game mechanic.  Probabaly also an additonal penalty for research done in a different system.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on March 31, 2020, 05:25:20 PM

Bringing in education  is a bit of a can of worms / slippery slope here because for it to make sense more and more of the entire civilian sector needs to be modeled, but otherwise I am all for something to make it less linear with empire size which ties in probably more with your next point.

The feasibility of Tall vs Wide empire strategies is a common debate in all 4x games I've engaged in discussions around, and wide is certainly being VERY favored in Aurora with everything from population growth mechanics to research rewarding spreading out rather than focusing "inward" on quality over quantity. I am also a firm believer that diminishing returns makes almost every simulation-like game better due to it's nature of being self-balancing much more so than a linear scaling is.

For sure. While it feels great to have that 65% * 4 = 3.6 times research speed when you do have it, it's also absolutely devastating to lose it, and it's a bit hard on your immersion to have a single leader over 10 million research workers able to influence the output to such a degree. Another immersion ruining factor is how an empire with billions of subjects can refocus 100% of it's research effort overnight into a totally different area, so some sort of "retooling" delay for labs switching specialization might be something worth considering. I would like the research bonuses to be gained and connected closer to the planet/lab in some way instead and have leaders able to maybe influence it in smaller and more unique/interesting ways in terms of tradeoffs. Maybe some scientists reduce credit cost instead of increase research point output, while those that increase output the greatest also increase credit costs more to mention one option, another is having them influence how many workers the labs need as a tradeoff too ( Classic efficiency vs output ).

It's a tricky one though to implement in a good way in order to not make it a huge choir and boring aspect of the game to have to upgrade 30 worlds manually each time you research a new tech. One of my favorite implementations of this was in ST:TNG:BotF (http://Star Trek: The Next Generation: Birth of the Federation) ( yes that is the proper abbreviation of the full title). This game let you assign an industrial project to upgrade labs, factories, farms or other building types that became progressively more expensive with tech before being able to enjoy the advantage and it always was such a hard choice what to prioritize and when, especially since the price of obsolete upgrades was significantly reduced so letting a system fall behind made upgrading to the old tech levels much cheaper.

Another abstracted way to achieve something similar might be to have later techs just reduce the worker requirements instead ( or at least mostly provide efficiency improvement this way ) which means that you constantly need to increase the number of factories/labs/finance centers and so on to gain benefit of the later tech levels. ( Building more buildings here is an abstraction/simplification of investments into upgrading to more advanced buildings ). This would probably make the math much harder though to judge how many buildings your population can support unless other UI improvements are made.

Ahh... please don't get me started on the Tall versus Wide troupe... something that only exist in fantasy land. Reality is far more complex and evolved than that.

I generally agree with what you say... the point would simply to make research less linear. If you invest twice the amount of resources into research you simply can't expect twice the outcome of that investment.

There also is a very big difference between theoretical and practical science. As most factions in Aurora are big enough to be competitive in theoretical science but economy is what generally will govern how much you can apply that theoretical science into applicable technology. And even then there need to be limitations... at some point it probably don't matter how big your economy is, certain research will still take time. economy will at some point matter more for how wide you can spread your science and be competitive through multiple choices and general superiority in quality too.

When I refer to smaller empires I don't mean the troupe of Tall from certain 4x games... I hate that term. I just mean an empire with a weaker economy. In real life a physically small country can obviously be more economically stronger than a larger country or some country with a smaller population versus one with a bigger population. But that is a complex issue and can't be explained with Wide or Tall as those concepts really don't exist in such simple terms, so we should not loose ourselves in flawed concepts... ;)

I agree that there should not be some tedious way to integrate technology it would have to be easy and automatic. But there should be a choice to how much resources you want to put into it and by which speed you want to incorporate it versus using the resources elsewhere. The same type of decisions you make when updating a fleet now or later based on other needs.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on March 31, 2020, 05:35:46 PM
I'd be happy to see Research Facilities switch from an 'X points per month' basis to a 'random amount per month centered on X points' -- effectively a die roll for each production cycle.  Overall research times should stay roughly the same, but this 2,000 point item might take a month longer than that 2,000 point item.  I'd definitely prefer not to know that my empire will invent a new drive system on Tuesday, September 14th, 926 AL.

I would also prefer to see newly assigned labs & scientists 'ramp up' to their full bonus -- maybe 1-5% per week.  I wouldn't want to penalize racial tech projects for the same team (so that Dr. P&P's labs aren't dropping back to zero for each new size of the same old engine), but I can see arguments both for and against keeping the bonus when going from Magnetic Confinement to Internal Confinement, for example.

- - - - -

A much more radical idea that tempts me is to drastically reduce the number of labs a scientist can oversee (say, to one-fifth of current, i.e. one per admin rating) and to allow multiple lab groups working on the same project to produce combined progress.  (Currently, any research done on Mars is ignored on Earth, and vice versa, unless and until a project is completed.)

So instead of having one super-scientist who can oversee thirty-five labs in one place all working on the next anti-matter engines, you would instead have one scientist with seven labs on Earth, another with five labs on Mars, a third with four labs on Io, etc.  I would want a small penalty (maybe only 10%) to the research produced by the additional scientists to enforce the paradigm that 'a single project under a single leader is more efficient' -- not for "realism" (I don't want to open that can of worms) but because I think there is value in that game mechanic.  Probabaly also an additonal penalty for research done in a different system.

Certainly some interesting ideas... personally I like if there is a die roll each cycle if you manage to get some progress and you not knowing the exact progress. I also like the way science is performed in Rule the Waves... to be honest that game give a relatively good simulation of how research is actually performed. You can't actually just ignore some research but you can reduce the likelihood that you have breakthroughs in some over other areas but you can't have 100% control of it.

I would really like a system similar to that if possible... but I'm sure allot of people would not like not being in full control of what gets researched... but it would be really good for role-play as you have to play the cards that get dealt and there will naturally be differences in factions research endeavours. You can't postpone development because you have not reached a certain level in a certain technology... you have no idea what technology your scientists will have a breakthrough next and when that will be anyway.
Title: Re: C# Aurora v0.x Suggestions
Post by: SultanPepper on March 31, 2020, 06:47:21 PM
Continuing on with the Research Discussion, I was always a fan of how Sword of the Stars did it. 
In SotS, you put a portion of your economic income into science, which directly affected how quickly you'd a tech.  More money = faster progress.  That aspect wouldn't work well in Aurora, but the breakthrough-overbudget system could.  After reaching 50% of the tech progress, there was a chance each turn it would be finished with a breakthrough.  At 100%, there'd be a chance they got held up and it'd go overbudget.  The chances would scale as you got closer or further from 100%.  That would potentially eliminate the 'Tech on 12th of March' factor, and if you could give a medal or commendation to Scientists with breakthroughs that could also be cool.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on March 31, 2020, 07:50:07 PM
Could also steal a page from the original Master of Orion. You select an emphasis (though MoO did allow you to focus everything) but your research is benefiting all fields to some extent. And once tech progresses, you need to improve the infrastructure of your planets. Of course in MoO it was just a slider and the game even adjusted it automatically for you.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on April 01, 2020, 01:42:26 AM
Could also steal a page from the original Master of Orion. You select an emphasis (though MoO did allow you to focus everything) but your research is benefiting all fields to some extent. And once tech progresses, you need to improve the infrastructure of your planets. Of course in MoO it was just a slider and the game even adjusted it automatically for you.

That is roughly how Rule the Waves technology works too... you can select to focus more or less on different technologies. It is pointless to focus on everything as that is the same as leaving everything on normal focus.

You then also commit part of your economy to it. The higher this value is the less you get out of it.

I think that having a "slider" or just selecting a "%" box of the number of wealth you dedicate for technological upgrades for each colony would suffice. Then each colony could have a progress meter for each research category you want to catch up on that goes up over time depending on how much wealth you spend on improving it.

You could also give a lump sum of wealth that then speed up the process by up to twice the speed...

For example...

A colony is generating 1000 wealth and have 100 factories... you get the research to add +20% extra industry power. You have selected 10% of the wealth to go toward upgrading technology at that colony which meas it automatically add 100 wealth per year towards upgrade. Let's say each factory need 10 wealth to upgrade so you would need 1000 wealth to upgrade them all to the new standard. Let's say you produce 1000 points of construction at the start. After one year you have built 10 new industries and spent 100 wealth on upgrades... obviously all new industries is of the new standard... so now 20 of 110 industries are done... but the game does not have to track exactly how many just the overall progress, so the progress now is 18.2% so the colony generate 1139 construction points with 110 factories.
The game just show a progress made at 18.2% to max tech capacity for industry.

If you say... give the colony 300 wealth for upgrades these get stored at the colony earmarked for technological upgrades and for each cycle the colony upgrade it matches money from this storage so it upgrades twice as fast... so... in the above example it would apply 200 wealth the first year and take 100 wealth from this pool to do the upgrades and instead of ending up at 18.6% you instead end up at  30/110 at 27.2% or 1159 construction points

This should be a relatively simple yet effective system that is easy to overlook and will not require much micromanagement.

There could always be a default value for how much money would go towards technological upgrades and you don't have to fiddle with it unless you want it to change. Obviously no wealth is used if there is nothing to upgrade.

Such a system will have to make decisions on how fast you tech up depending on how fast you are able to integrate said technology to your society. You also should not be able to choose which sector to upgrade just a sum to upgrade and it apply that across all sectors that it can upgrade, that is the simplest way to do it. But you can boost it by adding funds and colonies that generate more wealth also can upgrade faster which to some extent make sense as an economically stronger colony should be able to upgrade faster.

Wealth upgrades probably should work slightly different though, at least for the civilian economy.

Or some such system that is simple yet effective and give you a choice of how to utilise your economy and to what benefit. If you already is overtaxing your wealth economy with military assets you might not afford technological upgrades... but then you have not been kind to your economy in the first place.  ;)
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on April 01, 2020, 04:42:55 AM
I don't mind if my empire's mines slowly ramp production from 16 to 20 upon researching a new level of tech -- even if the start of such increases 'flow' outward from the discovering colony at 'the speed of ship' -- as long as I don't have to micro-manage them.

However, I can't conceive of a situation where I wouldn't immediately pay to start/continue the process -- whether that cost be wealth, minerals, lost production, or whatever -- unless it there were enemies in my sytems and that cost meant the difference between launching new ships this production cycle or not.

In every other case it's a net increase in {whatever}, regardless of the cost you put on it.  It's a decision on par with "Do I buy $5 worth of gas so I can take $50 worth of empties to the bottle depot, or do I leave them in my basement for another month?"  It's never not going to be worth it.

- - - - -

It sounds like my only real decision is going to be "Do I pay extra to get increased capacity sooner?"  To which the answer is going to be blatantly obvious.  Empire making a profit?  Do it (because we can afford it)!  Empire running a deficit?  Do it (because it increases taxes, and therefore imperial income)!
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on April 01, 2020, 05:17:18 AM
I don't mind if my empire's mines slowly ramp production from 16 to 20 upon researching a new level of tech -- even if the start of such increases 'flow' outward from the discovering colony at 'the speed of ship' -- as long as I don't have to micro-manage them.

However, I can't conceive of a situation where I wouldn't immediately pay to start/continue the process -- whether that cost be wealth, minerals, lost production, or whatever -- unless it there were enemies in my sytems and that cost meant the difference between launching new ships this production cycle or not.

In every other case it's a net increase in {whatever}, regardless of the cost you put on it.  It's a decision on par with "Do I buy $5 worth of gas so I can take $50 worth of empties to the bottle depot, or do I leave them in my basement for another month?"  It's never not going to be worth it.

- - - - -

It sounds like my only real decision is going to be "Do I pay extra to get increased capacity sooner?"  To which the answer is going to be blatantly obvious.  Empire making a profit?  Do it (because we can afford it)!  Empire running a deficit?  Do it (because it increases taxes, and therefore imperial income)!

Yes... but the decision might become what areas of your economy will you sacrifice in the mean time as it will require wealth to do the upgrades for you and how much wealth can you spend on it. We only can save a limited number of wealth now, so these should be real choice that have to be made.

To make it more interesting you could also make this a diminishing return sort if payment. So 10% means you get 10% return but at 100% you only get 50% of the investment to upgrades as there are more overhead cost to increase the speed of the projects.

There should always be a choice otherwise it make no sense to have the system in place. That is why linear system are not the greatest as there always are a best option.

I also agree on the micromanagement part, there should be minimal interaction and the action you do take should have a big impact.

There is also the fact that some colonies can upgrade allot faster than others as it depends on the wealth generation of the individual colony. Now... you obviously would need to have a special case for automated colonies... a base line wealth cost per building... so automated mines probably would upgrade slower than regular mines for example. There could be a minimum wealth to upgrade at say 10% of the cost per year no matter the wealth distribution of any colony.
But colonies with no population would become much slower to upgrade than colonies with population... at least the max speed possible.

But there would be decisions to be made in how much of the economy goes into developing tech as to how much goes into implementing it in a very different way.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on April 01, 2020, 05:44:39 AM
So if I spend 10% of a colony's wealth (per month, for a year) my installations upgrade in a year, and if I spend 100% (for six months) they upgrade in six months?  I'm pretty sure I'm going to find some level of acceptable 'penalty' (maybe 25% for nine months) and "set it and forget it" on an empire-wide level.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on April 01, 2020, 06:00:28 AM
So if I spend 10% of a colony's wealth (per month, for a year) my installations upgrade in a year, and if I spend 100% (for six months) they upgrade in six months?  I'm pretty sure I'm going to find some level of acceptable 'penalty' (maybe 25% for nine months) and "set it and forget it" on an empire-wide level.

That will depend on your overall health of the empire... so it will always be a decision at some stage.
Title: Re: C# Aurora v0.x Suggestions
Post by: sloanjh on April 01, 2020, 07:11:41 AM
So if I spend 10% of a colony's wealth (per month, for a year) my installations upgrade in a year, and if I spend 100% (for six months) they upgrade in six months?  I'm pretty sure I'm going to find some level of acceptable 'penalty' (maybe 25% for nine months) and "set it and forget it" on an empire-wide level.

In Rule the Waves, there are two knobs: what to emphasize (in terms of field of research - each gets low/medium/high) and what percentage of your economy to devote to research (8-12% IIRC).  For percent economy I always set it and forget it.  What to emphasize is more nuanced.  At different stages of the game different things are important.  Fire control I set on high and leave there the whole game.  Engine tech is high early on, until the transition to oil firing is discovered.  When aviation is introduced, you'll typically want to shift emphasis to that.  Also, every few years I rebalance - raising the priority of things that are low compared to where I want them and lowering the priority of things that are high.  So I actually think it has an appropriate level of making choices vs set and forget - you tend to make changes only every few years, because at the civilization level choices should be about multi-year strategic goals, not tactical research projects (which fits into the whole paradigm of Rule the Waves of abstracting away choices that are finer-grain level of detail than the strategic level).

A nice thing about the system is that there's a balance between "sure thing" progression (knowing exactly what will be discovered) and randomness - techs can appear out of order.  Also, there's no progress bar for techs, so from the point of view of the player they serendipitously appear.

John
Title: Re: C# Aurora v0.x Suggestions
Post by: TMaekler on April 01, 2020, 08:49:28 AM
Travel Time for Wormholes: wormhole travel is instant - and it is limited due to the fixed exit points and therefore a limiting factor in surprise or stealth attacks.

I was wondering if a change into a travel time mechanic could provide a deeper game experience. So any given wormhole gets some kind of base travel time factor - which could even be different depending from which side one enters. A Sol-Alpha Centauri jump could last 30 days. In the opposite direction maybe 21 days.
Jump Point Stabilization then could be used to shorten the travel time. A stabilized wormhole could half the travel time from the one side it was stabilized from. We maybe even could add a tech tree which shortens the travel time with each increase in techlevel.

What could be the benefit? A military engine receives the additional function of jump exit distance, similar to the already existing techline to increase to exit distance. But those come at a price. If you want to avoid an alien jump point assault decimating your fleet, you could choose a high exit distance (beginning at a million km up to one billion or more. However, increasing the distance will largely increase travel time. Let’s say you want to exit 1bkm away from the JP to ensure total secrecy. That would then mean 10 times the jump time. So 300 days.
For the ship/fleet itself the jump would be instant. So no increase in maintenance etc. But they would be off the grid for the selected time.

With this stealth and surprise warfare would become more likely, I think. You agree?
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on April 01, 2020, 10:24:58 AM
I still want to design my components and systems as much as possible. So any change to research should not affect that.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on April 01, 2020, 02:08:59 PM
I still want to design my components and systems as much as possible. So any change to research should not affect that.

I don't think anyone would like to change the way we create components for ships. Direct applied research should probably be handled slightly different than core research projects. These also don't need any change in how we incorporate them into new ships as they always have rather big overhead cost and are never automatically applicable in effect.
Title: Re: C# Aurora v0.x Suggestions
Post by: stabliser on April 02, 2020, 06:53:08 AM
It may have already been suggested (its is a long thread) but could we have an option to display our choice of tiled background image in the system map and the galactic map (nebula variant too) that zooms in and out with the rest of the information?    I have in mind a traveller rpg hex map for galactic map, hence the zooming being important.

Im still too much of a noob to suggest anything for game mechanics.

Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 02, 2020, 07:35:59 AM
It may have already been suggested (its is a long thread) but could we have an option to display our choice of tiled background image in the system map and the galactic map (nebula variant too) that zooms in and out with the rest of the information?    I have in mind a traveller rpg hex map for galactic map, hence the zooming being important.

Im still too much of a noob to suggest anything for game mechanics.

Reminded me of something I should mention. Galactic Map doesn't zoom at the moment. I never got around to adding it because it never became an issue. I'll address that after launch.
Title: Re: C# Aurora v0.x Suggestions
Post by: Froggiest1982 on April 02, 2020, 04:35:06 PM
It may have already been suggested (its is a long thread) but could we have an option to display our choice of tiled background image in the system map and the galactic map (nebula variant too) that zooms in and out with the rest of the information?    I have in mind a traveller rpg hex map for galactic map, hence the zooming being important.

Im still too much of a noob to suggest anything for game mechanics.

Reminded me of something I should mention. Galactic Map doesn't zoom at the moment. I never got around to adding it because it never became an issue. I'll address that after launch.

Would that really be needed though? As said on the other post unless you can fix the scaling issue it's kind of pointless as it would take longer to fix it every time than just deal with the fixed zoom. I would rather you implement the background if you have the time (maybe easier?) as that would help with RP immersion.

Cheers.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on April 03, 2020, 09:32:54 AM
I use the zoom on the galactic map all the time. In the early game I zoom in close and then zoom outwards as I explore.
Title: Re: C# Aurora v0.x Suggestions
Post by: Froggiest1982 on April 04, 2020, 02:30:09 AM
I use the zoom on the galactic map all the time. In the early game I zoom in close and then zoom outwards as I explore.

Probably for those playing on a laptop. I usually zoom out only when I have arrived 10 or 11 jumps away from Sol. I do agree it's a useful feature, just not worth the delay or pre-release though.
Title: Re: C# Aurora v0.x Suggestions
Post by: Norm49 on April 04, 2020, 07:37:47 AM
It would be nice if could manage some governmental infrastructure like hospital.   I find that my officer have a lot of medical problem.   We could have bonus by lowering the frequencies of this happening with more hospital.   Having some recherche to implore life expectancy so hour officer retire at a older age could be nice too. 
Title: Re: C# Aurora v0.x Suggestions
Post by: SultanPepper on April 05, 2020, 06:56:37 AM
Moving the spinal mount discussion from the 'Update' thread, I think Spinals could be given a massive damage boost - and a massive power increase requirement.  You should need to design an entire ship around a spinal, not add one because you can/want.  A spinal weapon should WRECK the target, but require such a large amount of power your ship is only good for said weapon.  Making them like this would add another level of complexity to the battles we love.
Title: Re: C# Aurora v0.x Suggestions
Post by: stabliser on April 05, 2020, 11:30:36 AM
Possibly suggested before, but looking at screenshots I dont find the directional arrows layout particularly intuitive.
can I suggest a different layout like:

L. U. R
+. D. -


(http://hxxp: C:\Users\Stabliser\Desktop\buttons. png)
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 05, 2020, 11:35:21 AM
Possibly suggested before, but looking at screenshots I dont find the directional arrows layout particularly intuitive.
can I suggest a different layout like:

L. U. R
+. D. -


(http://hxxp: C:\Users\Stabliser\Desktop\buttons. png)

I've not been using the arrows because you can move the map by click-drag, but I see your point. I've changed them as per your suggestion.
Title: Re: C# Aurora v0.x Suggestions
Post by: alaysian on April 05, 2020, 02:31:50 PM
Quote
It would be nice if could manage some governmental infrastructure like hospital.      I find that my officer have a lot of medical problem.      We could have bonus by lowering the frequencies of this happening with more hospital.      Having some recherche to implore life expectancy so hour officer retire at a older age could be nice too.     

Seconding the suggestion to add research and/or hospitals to improve lifespan.     Either would be awesome, but I think the research route that has you genetically engineer people makes more sense.   

Quote
Moving the spinal mount discussion from the 'Update' thread, I think Spinals could be given a massive damage boost - and a massive power increase requirement.     You should need to design an entire ship around a spinal, not add one because you can/want.     A spinal weapon should WRECK the target, but require such a large amount of power your ship is only good for said weapon.     Making them like this would add another level of complexity to the battles we love.   

I liked the suggestion earlier of having to design them like turrets, integrating a beam fire control and selecting minimum tonnage.     I would also love to see missile launchers larger then size 100.     The idea of firing a missile bigger then some FAC cracks me up.   
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on April 05, 2020, 03:45:00 PM
I would also love to see missile launchers larger then size 100.     The idea of firing a missile bigger then some FAC cracks me up.

To be honest that would just be silly and immersion breaking unless there also are mechanics added to armor them appropriately and have them partially fail from damage ( single point of dmg from a gauss can kill a FAC sized object no thanks )
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on April 05, 2020, 04:16:24 PM
Would be kindof cool if we could build ship sized missiles.
Title: Re: C# Aurora v0.x Suggestions
Post by: Erik L on April 05, 2020, 07:01:12 PM
Would be kindof cool if we could build ship sized missiles.

Pretty certain the larger missiles are at least fighter sized. Size 100 missile = 250 tons :)
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on April 05, 2020, 09:29:40 PM
To be honest that would just be silly and immersion breaking unless there also are mechanics added to armor them appropriately and have them partially fail from damage ( single point of dmg from a gauss can kill a FAC sized object no thanks )

A FAC sized object designed to go boom and aggressively optimized to do so. Don't think of a missile as a crewed ship; it's a more or less solid brick of material that squeezes the highest power engine possible into the smallest space possible behind a canister of transnewtonian fuel behind a massive warhead behind the sensor and communication package, all of which is build as lightly as possible to get the biggest acceleration and warhead possible.

That said, a size 100 missile probably isn't a ship killer. It's not even much of a bombardment weapon at that size, it's simply too easy a target to any STO defenses. If you are building missiles that big, it's probably to use them as long range survey drones.
Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on April 05, 2020, 09:43:36 PM
I wonder if the following might be more intuitive :
- U +
L D R

As default keybindings people are used to for gaming are either WSAD or the keyboard arrows which have that format, and also plus is generally situated to the right of minus.
However to be even more irritatingly nitpicky, Ive noticed that adding an extra column of buttons would make the 3 top rows line up.
See following image.

Title: Re: C# Aurora v0.x Suggestions
Post by: Protomolecule on April 06, 2020, 09:57:41 AM
Suggestion for the future: Dual Boost Engines, inspired by naval geared steam turbines.

Would work like this: when creating an engine, you would select two boost options, one for cruising, and another one for when you really need the speed.  The engine would have a minus 20% power modifier, to reflect the fact that part of the engine is now the equipment to vary the boost level.  Could also have increased costs as well.

When working below the maximum speed of the smaller boost, it would use the fuel consumption of the smaller boost, and when above that, would use the fuel consumption of the higher boost.  That would keep things simple, I think.  And there would be a tradeoff, as a jack of all trades, master of none thing, since a normal engine of the same size and boost would be more powerful, and thus, it would not make the regular engines obsolete.

Could also have a techline limiting the difference between boost levels, for example, starting at 0. 5x.  So you could make a 0. 5x/1. 0x, or a 1. 0x/1. 5x

I'm pretty new here, so I don't know how Steve feels about this sorta of stuff.
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on April 06, 2020, 01:01:32 PM
I'd honestly like a "cruising power" option or something... or just be able to have more than one type of engine on a ship.

Strategic Movement at reduced speed with reduced fuel usage to "get there" and max speed to kick ass once I've arrived.

Even a check box option, something like "Use Strategic Fuel" on the Task Group level, would be nice. The Class Design could show the Strategic Range. Boosted Engines could have less Strategic Range as boost increases, while Commercial Engines would not have the option to use Strategic mode. Hence, when a Fleet or Task Group has a Commercial Engined ship in it, but ticks the "Use Strategic Fuel" option, it would be limited by the Max Speed of the Commercial Engined craft and could go no faster.

I think half speed one-quarter fuel use or three quarters speed with half fuel use would be good starting points for the Strategic Mode, but play testing would be needed.

EDIT: I support Protomolecule suggestion. I like this a lot and would like to see it implemented. It uses the system that is already in place, and only adds one tech.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on April 06, 2020, 01:44:08 PM
Such proposals have been put forth before and the discussion got quite lively on occasion. Both in this thread and elsewhere. It's unlikely to happen anytime soon.

What you can do, now that commercial hangars are a reality in C#, is to make huge commercial carriers with slow commercial engines. No need for maintenance and they use barely any fuel as they carry your military ships to the front.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on April 06, 2020, 03:03:10 PM
Such proposals have been put forth before and the discussion got quite lively on occasion. Both in this thread and elsewhere. It's unlikely to happen anytime soon.

What you can do, now that commercial hangars are a reality in C#, is to make huge commercial carriers with slow commercial engines. No need for maintenance and they use barely any fuel as they carry your military ships to the front.

There were no reason for you to not use tugs for the same reasons before... ;)

Tugs are way more economical to build if all you want to do is transporting a military ship from one place to another using little to no fuel.
Title: Re: C# Aurora v0.x Suggestions
Post by: Froggiest1982 on April 06, 2020, 04:09:53 PM
Such proposals have been put forth before and the discussion got quite lively on occasion. Both in this thread and elsewhere. It's unlikely to happen anytime soon.

What you can do, now that commercial hangars are a reality in C#, is to make huge commercial carriers with slow commercial engines. No need for maintenance and they use barely any fuel as they carry your military ships to the front.

I don't think commercial hangar should be able to transport military vessels though.
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on April 06, 2020, 04:12:45 PM
Such proposals have been put forth before and the discussion got quite lively on occasion. Both in this thread and elsewhere. It's unlikely to happen anytime soon.

What you can do, now that commercial hangars are a reality in C#, is to make huge commercial carriers with slow commercial engines. No need for maintenance and they use barely any fuel as they carry your military ships to the front.

I don't think commercial hangar should be able to transport military vessels though.

Why not? It's basically a big box that you put spaceships in.
Title: Re: C# Aurora v0.x Suggestions
Post by: xenoscepter on April 06, 2020, 04:21:42 PM
You can transport them, but not maintain them. I'm pretty sure it freezes the morale loss, but doesn't stop the maintenance clock, thus you would need maintenance modules if you wanted to store military ships in non-military hangars.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jorgen_CAB on April 06, 2020, 04:26:44 PM
You can transport them, but not maintain them. I'm pretty sure it freezes the morale loss, but doesn't stop the maintenance clock, thus you would need maintenance modules if you wanted to store military ships in non-military hangars.

You can theoretically build HUGE carriers with commercial engines, hangars and maintenance facilities in one ship. But they are not going to be very good fleet carriers as they are likely to be slow and have a HUGE thermal output when moving at any decent speeds.

Using a commercial carrier as a utility carrier and moving smaller military ships about might not be a terrible idea to some degree, but I would mainly see them as a supportive ship. More like an Escort Carrier in WW2 for example.
Title: Re: C# Aurora v0.x Suggestions
Post by: SerBeardian on April 06, 2020, 04:57:20 PM
Don't know if this was suggested, since 145 pages is a lot to go through, and while I like to imagine that Steve eagerly watches all the stuff I throw onto Youtube, I know he's probably too busy to, so I'd like to suggest an eventual expansion on diplomacy I like to call: Local Wars vs. Total Wars.

Scenario for your consideration: You have an alliance with a neighboring empire. You have three JPs leading to their systems where you are neighbors. Neither empire claims the other's systems, so there is no border conflict, just a border. You still lay mines and defensive platforms/patrol fleets at the JPs because good practices (as does the NPR), but you never expect to use them because hey, it's a comfortable peace - they're just there to keep the other guy honest.

Now, in some distant (but not TOO distant) system, you run into some really rich deposits, but your neighbor has some ships who have just shown up there as well. You each have a few light combat vessels there, but neither side is willing to concede this resource deposit (both empires claim system, neither concedes).

Now, in the current system, there are three outcomes:
1) Diplo teams manage to keep the diplo score above -100 long enough for someone to drop a colony in the system, and the AI bails out.
2) The refusals from either side to vacate, or the empires fail to yield even after colonies are set up, and leads to a reduction in diplo score until one empire declares war at -100.
3) You think you have an advantage and decide to "give them a nudge" in that system by firing a shot at their (shielded) ships to kindly ask them to "no really, go away".

the first instance is already fine, but in either of the latter instances, diplo score ends up at -100, which leads to war.

What happens then? A battle breaks out in the new system, someone wins, well done. This is fine, and is meant to happen.

But what happens at the rest of the border? Mines arm, and go after merchant traffic. Your own ships now consider the hefty trade ships in your systems valid targets, as do their ships to your merchants in their systems. Mass murder all-round everywhere, diplo score plummets to -bazillion, you're now in a total war with your once ally. Even if you don't attack them, you still have to send your diplo ships into their systems to try and bring your score up, and if they get shot at on transit, or trip up on mines, that just makes things worse. And how long is it going to take to claw back ALL the diplo points to get above -100? Especially if they send through attacks from their systems? Do we agree that this is a problem?

To give a real-world analogue, it would be like a new island full of oil appears in the middle of the Atlantic, the US and Russia both send a pair of destroyers over, one of them fires a shot that does minimal/no damage, and both countries decide "welp, time to launch all the nukes, lol!". It just doesn't make any sense!

So, I have two proposals:

1) The quick-fix: Make ship damage ONLY decrease diplo score while it is above -100. This way, your diplomats can try and work towards peace, even if you're still fighting off raids from the enemy. This lets you work towards peace as long as nobody invades anyone's colonies. It would also largely remove the necessity of a "warscore", as the value of the rep below that war threshold, plus ongoing combat and invasions, plus diplo team efforts and skills can somewhat account for that. But while easy to implement, it's so un-satisfying, and will still spike mass-slaughter among merchant shipping while the score is still below that threshold of war.
2) The better solution: Expand into a two-tier diplo system.

The way it would work is like this. Each empire has two ratings - one "global" relations rating, and one "local" relations rating within each system where there is a known presence. When combat and damage happens, that local system's diplo rep plummets and you can go about your shooting and killing in there. While there is no combat, the rep climbs back towards zero (where it stops contributing to global rep) or, if colonies are present, towards a baseline set by the global rep level. Diplo teams that can work on that empire can target that system to raise the local rep in that system (rather than just raising the "global" rep overall) and can do this from within any other system (so they don't have to work in a warzone).

The "Global" diplo rep is determined by the average diplo ratings of every system's local score.
Local rep would initially start at the global rep level (upon discovery of the presence of the other empire, so as to not alter the global rep), and tends towards whatever the current global rep is as long as presence continues to be detected. If no presence is detected after X months, or no colonies are identified in that system, then the system is eventually removed from influencing global rep.

So in the above scenario, you would have 6 systems with +1000 rep (one each either side of the JP border), and one system with -1000 rep where your fleets are having the fight over the new territory. Fleets within that system would be at war, and will fire on one another as they desire, but the "Global" diplo rating would be at like +700 points ((6000 - 1000)/7). This means that, as long as you don't engage any ships anywhere else, trade will continue to flow, and the border will remain cordial (with perhaps some minor tension).
However, if you let that conflict fester, then the local rep at each of those other systems will start trending towards the new baseline of +700 instead of +1000, which will start dragging the global score down [((6x700-1000)7)=450], which will drag the local scores down, leading into a loop that eventually brings the global score to -100, at which point total war breaks out. This way, you can't have a perpetual border conflict without any diplomatic penalties, but a single border conflict doesn't instantly get you there, and you have time for diplo teams to bring the local score for that system up if you avoid confict in that area.

The AI would also be aware of this, and would re-evaluate whether it wants to give up on that system and let diplo teams pach up relations, or whether that system is valuable enough to eventually escalate into total war.

Having a hidden third value "Desired Diplo Rep" would accomplish this by letting NPRs decide at what point are they willing to let relations fall to. For example, a low-militancy empire that is gaining a lot of wealth from trade, espeically to the point where it would go into debt without it, might not be willing to fall below the threshold where that trade is cut off, and would pull back from contested systems if the rep falls low enough to threaten a trade treaty. A highly militaristic and xenophobic empire that doesn't benefit economically from your own very much, with a much stronger military, would be much more willing to let global rep fall into total war.

I think that something like this system would give a lot more flexibility and depth to diplomacy and allow things like border conflicts to happen without plunging both empires into total war the second anyone fires a shot at anyone else. It doesn't make sense that two long-time allies would instantly go into total war over some minor damage (and not even destruction) to a corvette in some distant system far from the core worlds.

I also understand that this would mean a lot of work on diplomacy and would not expect to see this in the current release, and I fully expect Steve to be burnt out on diplomacy and be much more keen to work on literally anything else, but perhaps later on down the road something like this would be really awesome to see.
Title: Re: C# Aurora v0.x Suggestions
Post by: Froggiest1982 on April 06, 2020, 09:25:57 PM
Don't know if this was suggested, since 145 pages is a lot to go through, and while I like to imagine that Steve eagerly watches all the stuff I throw onto Youtube, I know he's probably too busy to, so I'd like to suggest an eventual expansion on diplomacy I like to call: Local Wars vs. Total Wars.

Scenario for your consideration: You have an alliance with a neighboring empire. You have three JPs leading to their systems where you are neighbors. Neither empire claims the other's systems, so there is no border conflict, just a border. You still lay mines and defensive platforms/patrol fleets at the JPs because good practices (as does the NPR), but you never expect to use them because hey, it's a comfortable peace - they're just there to keep the other guy honest.

Now, in some distant (but not TOO distant) system, you run into some really rich deposits, but your neighbor has some ships who have just shown up there as well. You each have a few light combat vessels there, but neither side is willing to concede this resource deposit (both empires claim system, neither concedes).

Now, in the current system, there are three outcomes:
1) Diplo teams manage to keep the diplo score above -100 long enough for someone to drop a colony in the system, and the AI bails out.
2) The refusals from either side to vacate, or the empires fail to yield even after colonies are set up, and leads to a reduction in diplo score until one empire declares war at -100.
3) You think you have an advantage and decide to "give them a nudge" in that system by firing a shot at their (shielded) ships to kindly ask them to "no really, go away".

the first instance is already fine, but in either of the latter instances, diplo score ends up at -100, which leads to war.

What happens then? A battle breaks out in the new system, someone wins, well done. This is fine, and is meant to happen.

But what happens at the rest of the border? Mines arm, and go after merchant traffic. Your own ships now consider the hefty trade ships in your systems valid targets, as do their ships to your merchants in their systems. Mass murder all-round everywhere, diplo score plummets to -bazillion, you're now in a total war with your once ally. Even if you don't attack them, you still have to send your diplo ships into their systems to try and bring your score up, and if they get shot at on transit, or trip up on mines, that just makes things worse. And how long is it going to take to claw back ALL the diplo points to get above -100? Especially if they send through attacks from their systems? Do we agree that this is a problem?

To give a real-world analogue, it would be like a new island full of oil appears in the middle of the Atlantic, the US and Russia both send a pair of destroyers over, one of them fires a shot that does minimal/no damage, and both countries decide "welp, time to launch all the nukes, lol!". It just doesn't make any sense!

So, I have two proposals:

1) The quick-fix: Make ship damage ONLY decrease diplo score while it is above -100. This way, your diplomats can try and work towards peace, even if you're still fighting off raids from the enemy. This lets you work towards peace as long as nobody invades anyone's colonies. It would also largely remove the necessity of a "warscore", as the value of the rep below that war threshold, plus ongoing combat and invasions, plus diplo team efforts and skills can somewhat account for that. But while easy to implement, it's so un-satisfying, and will still spike mass-slaughter among merchant shipping while the score is still below that threshold of war.
2) The better solution: Expand into a two-tier diplo system.

The way it would work is like this. Each empire has two ratings - one "global" relations rating, and one "local" relations rating within each system where there is a known presence. When combat and damage happens, that local system's diplo rep plummets and you can go about your shooting and killing in there. While there is no combat, the rep climbs back towards zero (where it stops contributing to global rep) or, if colonies are present, towards a baseline set by the global rep level. Diplo teams that can work on that empire can target that system to raise the local rep in that system (rather than just raising the "global" rep overall) and can do this from within any other system (so they don't have to work in a warzone).

The "Global" diplo rep is determined by the average diplo ratings of every system's local score.
Local rep would initially start at the global rep level (upon discovery of the presence of the other empire, so as to not alter the global rep), and tends towards whatever the current global rep is as long as presence continues to be detected. If no presence is detected after X months, or no colonies are identified in that system, then the system is eventually removed from influencing global rep.

So in the above scenario, you would have 6 systems with +1000 rep (one each either side of the JP border), and one system with -1000 rep where your fleets are having the fight over the new territory. Fleets within that system would be at war, and will fire on one another as they desire, but the "Global" diplo rating would be at like +700 points ((6000 - 1000)/7). This means that, as long as you don't engage any ships anywhere else, trade will continue to flow, and the border will remain cordial (with perhaps some minor tension).
However, if you let that conflict fester, then the local rep at each of those other systems will start trending towards the new baseline of +700 instead of +1000, which will start dragging the global score down [((6x700-1000)7)=450], which will drag the local scores down, leading into a loop that eventually brings the global score to -100, at which point total war breaks out. This way, you can't have a perpetual border conflict without any diplomatic penalties, but a single border conflict doesn't instantly get you there, and you have time for diplo teams to bring the local score for that system up if you avoid confict in that area.

The AI would also be aware of this, and would re-evaluate whether it wants to give up on that system and let diplo teams pach up relations, or whether that system is valuable enough to eventually escalate into total war.

Having a hidden third value "Desired Diplo Rep" would accomplish this by letting NPRs decide at what point are they willing to let relations fall to. For example, a low-militancy empire that is gaining a lot of wealth from trade, espeically to the point where it would go into debt without it, might not be willing to fall below the threshold where that trade is cut off, and would pull back from contested systems if the rep falls low enough to threaten a trade treaty. A highly militaristic and xenophobic empire that doesn't benefit economically from your own very much, with a much stronger military, would be much more willing to let global rep fall into total war.

I think that something like this system would give a lot more flexibility and depth to diplomacy and allow things like border conflicts to happen without plunging both empires into total war the second anyone fires a shot at anyone else. It doesn't make sense that two long-time allies would instantly go into total war over some minor damage (and not even destruction) to a corvette in some distant system far from the core worlds.

I also understand that this would mean a lot of work on diplomacy and would not expect to see this in the current release, and I fully expect Steve to be burnt out on diplomacy and be much more keen to work on literally anything else, but perhaps later on down the road something like this would be really awesome to see.

Hi Ser, first of all: BIG FAN!

I read your post carefully and even if we will have to wait for Steve official answer it may be possible you got the diplomacy posts wrong. I am attaching the links again:

http://aurora2.pentarch.org/index.php?topic=8495.msg118258#msg118258

especially this part:

Positive and Negative diplomatic points will be gained through other events, many of which will be defined in future posts. An example of a negative impact is combat. Negative diplomatic points are suffered due to damage inflicted by an alien race using the following rules:
Each point of damage from a hit that only damages shields: 0.1
Each point of damage from a hit that causes armour damage but not internal: 0.25
Each point of damage from a hit that causes internal damage: 1.0
Each point of space-based damage to populations, ground forces or shipyards: 1.0
Each ton of ground forces destroyed in ground-based combat: 0.01
If diplomatic relations are above the hostile level (-100), then even a single point of damage through combat will reduce relations to that point. However a period of mutual non-interaction following a small clash will probably return the diplomatic status to neutral. For example, if communications are established you may ask a survey ship to leave your system (mechanics in a future post). If that didn't work or you did not have communication, you can slightly damage that ship. An unarmed ship would retreat from hostile aliens and the immediate impact would be the alien race treating you as hostile. However, with no further combat in the short term, the status would soon return to a wary neutrality. Future communication and diplomacy would still be an option. Larger wars are harder to resolve but peace treaties will be covered in a future post.
I know that "future posts" are mentioned several times, but I wanted to lay out the basic framework so I can build upon it.


Small skirmishes will be permitted plus on the long-run relations will tend to go back towards 0 (both positive and negative) in the absence of further interactions. Of course peace treaties and such will help in us understanding the mechanic in place more once Steve will implement them into the game. Maybe in the meantime, Steve could lower the values for the interactions? I think it will depend also on his testing.
Now on your specific scenario (even if I absolutely understand what you mean and I really looking forward to Steve answer), you should also consider this mechanic:

http://aurora2.pentarch.org/index.php?topic=8495.msg118362#msg118362

This meaning that:
Now, in the current system, there are three outcomes:
1) Diplo teams manage to keep the diplo score above -100 long enough for someone to drop a colony in the system, and the AI bails out.
2) The refusals from either side to vacate, or the empires fail to yield even after colonies are set up, and leads to a reduction in diplo score until one empire declares war at -100.
3) You think you have an advantage and decide to "give them a nudge" in that system by firing a shot at their (shielded) ships to kindly ask them to "no really, go away".

1) even if you drop a colony it will not be enough for the AI to bails out and it will take for you several years before reaching a level where the AI is leaving the place and good luck with your commercial and or logistic effort in getting that colony going with all the AI sparrows around.
2) this is the most likely scenario you are going to face and honestly, I believe is quite accurate. You are pretty much trying to form Israel in Palestine. We all know how this ends.
3) it will not work as per the first mechanic and also for the one discussed at the beginning.

I also do believe like you do that the Diplo part requires just that pretty little feature to allow AI to recognize what is acceptable and what is absolutely unacceptable when it comes to judging human player actions. Maybe lower the tiers as I suggested could help but I think we have to consider both yours and potentially my suggestion will not avoid the exploit of taking the NPR out just one piece at the time and we may need something more considerate. However, I still believe we should give Steve a shot and look at what the Peace mechanics will bring to the table as I guess he cannot go down there road without actually coding the AI judgement on Human actions based on the situation and data available.
Title: Re: C# Aurora v0.x Suggestions
Post by: Agm-114 on April 06, 2020, 09:35:32 PM
Hey steve, in terms of making your code difficult to decompile/modify it might be worthwhile to checksum the exe in addition to the obfuscation, I did it with a personal project and it worked great. 

In fact for pulsar we have the current git version printed to the bottom of the screen, it's been a great debugging tool to make sure that everyone's files are the same so it might be worthwhile to have the game display the current version / hash in non intrusive, but always visible way. 

While there is a certain aspect of your reasoning obfuscation I disagree with, the rest is pretty solid IMO.   However there is a very major reason for obfuscation I think you either haven't considered / neglected to mention and that's the fact that if other people start distributing a modded version of the game, it is risky for you and users since malicious code may also be injected.
Title: Re: C# Aurora v0.x Suggestions
Post by: SerBeardian on April 07, 2020, 03:06:40 AM

Yadda Yadda Yadda, look two up


Hi Ser, first of all: BIG FAN!


Thanks! It means a lot! :D

Now, it's true that I may be misreading it, so would love a clarification from Steve, but the way I read this bit:

If diplomatic relations are above the hostile level (-100), then even a single point of damage through combat will reduce relations to that point.

This seems to me that ANY point of damage is enough to bring relations from +whatever to -100 instantly. This means that a fully maxed out alliance would instantly turn into total war if a single shot is exchanged between the two of you.
Since -100 is Total War, this means instant hostilities, which means mines trigger on that empire. Mines means uncontrolled damage to any civilian shipping in the area. Which means more negative diplo rep. Now you have to start digging, but the AI is at war. It wants to start attacking you. So you now have to fight off attacks, dealing more damage, causing further diplo losses.

However a period of mutual non-interaction following a small clash will probably return the diplomatic status to neutral.

HOW, exactly, are we supposed to not engage in hostilities if the AI is sending attacks at out colonies? How are we supposed to dig our way out of -200 or -300 diplo points before the AI sends another attack, especially if they're right next door?

That's why I suggested having ship damage not reduce diplo rep if you're already at war - to give you a chance to dig your way out of it, without self-defense heaping more negative rep onto you.

1) even if you drop a colony it will not be enough for the AI to bails out and it will take for you several years before reaching a level where the AI is leaving the place and good luck with your commercial and or logistic effort in getting that colony going with all the AI sparrows around.
2) this is the most likely scenario you are going to face and honestly, I believe is quite accurate. You are pretty much trying to form Israel in Palestine. We all know how this ends.
3) it will not work as per the first mechanic and also for the one discussed at the beginning.

1) Entirely true, but something you have to deal with and hope you have enough positive diplo coming in to counteract the refused demands in the meantime. Also beyond what I'm talking about because the ideal outcome is no war at all.
2) we agree with.
3) This not working is exactly what I'm talking about - You can't shoot any of their ships without triggering total, empire-wide war.

Steve and you mentioned "Small Clash" and "Small Skirmish". There IS no "small" anything when any damage causes war, which causes the AI to send ships at you from everywhere that you then have to blow up. Every dip below -100 that doesn't IMMEDIATELY get back above -100 and out of hostilities will snowball, especially if there's trade and minefields.

I'm willing to give C# a shot as Steve has it and see if I'm misunderstanding the post, or if there are other mechanics that he hasn't mentioned that already deal with this issue, but this is a serious concern for me - that any damage between ships, no matter how small or insignificant in the grand scheme of things, between even the longest and strongest of allies, is going to ultimately descend into total annihilation of one of the two parties, and no way for the player to resolve this.

I mean... it won't stop me from playing it and purging them anyway if I have to, long-time allies or not... but it's still something I'd like to see with a proper solution and I think my local/global + NPR target rep is a good mechanism to fix that problem if Steve doesn't have something better in mind.
Title: Re: C# Aurora v0.x Suggestions
Post by: alaysian on April 07, 2020, 08:45:47 AM
An alternative to this would be a small preliminary diplomatic hit followed by a diplomatic inquiry from that empire into why you shot their ship, with the results of that inquiry potentially bringing more diplomatic loss and/or bringing war.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 07, 2020, 09:00:43 AM
What may happen quite often is that you see a lone alien survey ship and it won't leave. You damage it (perhaps a single missile) and it runs away. Unless the NPR has forces waiting very close by, relations will move above the hostile threshold within a few days or weeks.

If you actually destroy the ship, that would take a lot longer to resolve.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on April 07, 2020, 12:09:36 PM
What may happen quite often is that you see a lone alien survey ship and it won't leave. You damage it (perhaps a single missile) and it runs away. Unless the NPR has forces waiting very close by, relations will move above the hostile threshold within a few days or weeks.

If you actually destroy the ship, that would take a lot longer to resolve.
This is assuming the two races haven't been allied a long time with trade intermingling everywhere.  You hit a survey ship once and only do shield damage, and now all the mines and JP pickets on both sides obliterate every merchant ship, and you go from -101 to -10,000.

I think a border skirmish spiraling into total war should be possible, the Seven Years War happened like that after all, but not all border skirmishes should do so.  The US didn't obliterate Israel in retribution for the attack on the USS Liberty.

Ideally, there'd also be some kind of way for the reverse to happen, in which a total war winds down to an uneasy peace.  The player may be able to do that if they're winning, but it seems like the AI will never stop before total annihilation if they're winning.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 07, 2020, 12:20:24 PM
What may happen quite often is that you see a lone alien survey ship and it won't leave. You damage it (perhaps a single missile) and it runs away. Unless the NPR has forces waiting very close by, relations will move above the hostile threshold within a few days or weeks.

If you actually destroy the ship, that would take a lot longer to resolve.
This is assuming the two races haven't been allied a long time with trade intermingling everywhere.  You hit a survey ship once and only do shield damage, and now all the mines and JP pickets on both sides obliterate every merchant ship, and you go from -101 to -10,000.

I think a border skirmish spiraling into total war should be possible, the Seven Years War happened like that after all, but not all border skirmishes should do so.  The US didn't obliterate Israel in retribution for the attack on the USS Liberty.

Ideally, there'd also be some kind of way for the reverse to happen, in which a total war winds down to an uneasy peace.  The player may be able to do that if they're winning, but it seems like the AI will never stop before total annihilation if they're winning.

Yes, I've said I will add a variety of additional diplomacy options post-launch, including peace treaties of some sort. I'm just pointing out what is possible at launch.

I guess what you are asking though is that in some situations (depending on NPR characteristics and current relations), there would be a protest rather than immediate combat
Title: Re: C# Aurora v0.x Suggestions
Post by: alex_brunius on April 07, 2020, 04:24:02 PM
Yes, I've said I will add a variety of additional diplomacy options post-launch, including peace treaties of some sort. I'm just pointing out what is possible at launch.

I guess what you are asking though is that in some situations (depending on NPR characteristics and current relations), there would be a protest rather than immediate combat

I think what people are asking for is a more gradual degradation of relations to be the norm, rather than it being possible to go from close allies to war overnight.


Basically if a point of contention appears between two allied empires relations could degrade over some months or even some years with civilian trade getting cut off at a fairly early point and possibility of border skirmishes only towards the end.


A game that captures this excellent is Rule the Waves where you never know exactly what will bring you over the brink of war but you can see it coming miles away and make preparations. Being able to react to the development isn't just good for a feeling of plausibility, it also opens up strategic choices like the player being able to either move forces into place, dig in and prepare for operations in enemy territory... or redouble diplomatic efforts and compromise to try and avoid conflict.
Title: Re: C# Aurora v0.x Suggestions
Post by: Dawa1147 on April 07, 2020, 05:11:21 PM
On the topic of mines, unless I missed it and its being fixed in C# Friendly and Allied NPRs will still trigger the players mines.  This happens with all three sensor types.
Title: Re: C# Aurora v0.x Suggestions
Post by: Froggiest1982 on April 07, 2020, 05:17:27 PM
Thanks! It means a lot! :D

Now, it's true that I may be misreading it, so would love a clarification from Steve, but the way I read this bit:

If diplomatic relations are above the hostile level (-100), then even a single point of damage through combat will reduce relations to that point.

This seems to me that ANY point of damage is enough to bring relations from +whatever to -100 instantly. This means that a fully maxed out alliance would instantly turn into total war if a single shot is exchanged between the two of you.
Since -100 is Total War, this means instant hostilities, which means mines trigger on that empire. Mines means uncontrolled damage to any civilian shipping in the area. Which means more negative diplo rep. Now you have to start digging, but the AI is at war. It wants to start attacking you. So you now have to fight off attacks, dealing more damage, causing further diplo losses.


Hi again Ser.

I understand what you mean and I will tell you the way I see it based on what Steve said.

If diplomatic relations are above the hostile level (-100), then even a single point of damage through combat will reduce relations to that point.

Let's analyze it:
If diplomatic relations are above the hostile level (-100): it means to me you are already passed that point (so let's say -101) due to multiple skirmishes.
And therein, as the Bard would tell us, lies the rub. If you mean above as higher numerical weight (let's say +100) or above as higher numerical figure (-101). I believe it's the latter.

then even a single point of damage through combat will reduce relations to that point: it seems to me that this is kind of restoring the relations to -100 (he is using the words "reducing to"). This should avoid the escalation of the -10000 relations which will trigger if after the hostile status the AI decides to declare war. I believe though at this stage Declaration of War and Peace Treaties are not implemented as per 1.0 and we can expect more done to it after launch and have tested base mechanics.

Now the part Steve should intervene is: Is my assumption correct? Or Ser's assumption is correct? Or is even that passed the -100 point every shot counts as -100 relationship penalty, therefore, escalating the situation into unrecoverable s**t in a second?

I've found this: http://aurora2.pentarch.org/index.php?topic=8497.msg118384#msg118384 but again it's misleading as it doesn't clarify if it triggers at one hit after the -100 threshold and how that trigger is handled.

EDIT AFTER STEVE'S REPLY: I hear you Ser, I am afraid I am now sharing your concerns. All we can do is to try and see how it goes and wait for the peace mechanics to be in place as well.

Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 07, 2020, 05:38:42 PM
Yes, I've said I will add a variety of additional diplomacy options post-launch, including peace treaties of some sort. I'm just pointing out what is possible at launch.

I guess what you are asking though is that in some situations (depending on NPR characteristics and current relations), there would be a protest rather than immediate combat

I think what people are asking for is a more gradual degradation of relations to be the norm, rather than it being possible to go from close allies to war overnight.

Basically if a point of contention appears between two allied empires relations could degrade over some months or even some years with civilian trade getting cut off at a fairly early point and possibility of border skirmishes only towards the end.

A game that captures this excellent is Rule the Waves where you never know exactly what will bring you over the brink of war but you can see it coming miles away and make preparations. Being able to react to the development isn't just good for a feeling of plausibility, it also opens up strategic choices like the player being able to either move forces into place, dig in and prepare for operations in enemy territory... or redouble diplomatic efforts and compromise to try and avoid conflict.

The degradation happens due to tensions over territory. I am playing through that exact situation now in the test game. The powers are threatening each over Alpha Centauri and the situation is escalating. It is obvious that war is coming if someone doesn't back down.

However, tensions increasing is different than destroying a ship. Even on Earth, if a one power started sinking ships of a second, friendly power, relationships wouldn't gradually decrease. In the game, an allied NPR isn't going to suddenly open fire on you without warning. Conversely, if you start destroying ships from friendly NPRs then it is reasonable that they retaliate.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 07, 2020, 05:40:31 PM
>> If diplomatic relations are above the hostile level (-100), then even a single point of damage through combat will reduce relations to that point.

This means if relations are +100, they will move to -100.
Title: Re: C# Aurora v0.x Suggestions
Post by: space dwarf on April 07, 2020, 05:58:18 PM
Yes, I've said I will add a variety of additional diplomacy options post-launch, including peace treaties of some sort. I'm just pointing out what is possible at launch.

I guess what you are asking though is that in some situations (depending on NPR characteristics and current relations), there would be a protest rather than immediate combat

I think what people are asking for is a more gradual degradation of relations to be the norm, rather than it being possible to go from close allies to war overnight.

Basically if a point of contention appears between two allied empires relations could degrade over some months or even some years with civilian trade getting cut off at a fairly early point and possibility of border skirmishes only towards the end.

A game that captures this excellent is Rule the Waves where you never know exactly what will bring you over the brink of war but you can see it coming miles away and make preparations. Being able to react to the development isn't just good for a feeling of plausibility, it also opens up strategic choices like the player being able to either move forces into place, dig in and prepare for operations in enemy territory... or redouble diplomatic efforts and compromise to try and avoid conflict.

The degradation happens due to tensions over territory. I am playing through that exact situation now in the test game. The powers are threatening each over Alpha Centauri and the situation is escalating. It is obvious that war is coming if someone doesn't back down.

However, tensions increasing is different than destroying a ship. Even on Earth, if a one power started sinking ships of a second, friendly power, relationships wouldn't gradually decrease. In the game, an allied NPR isn't going to suddenly open fire on you without warning. Conversely, if you start destroying ships from friendly NPRs then it is reasonable that they retaliate.

Yes, but if for some reason the UK torpedoed a US frigate in the English Channel then it could certainly lead to the immediate end of friendship and maybe even further battle/war, but what *wouldn't* happen is that the US navy immediately opens fire on and sinks every british-flagged ship on the eastern seaboard, immediately turning a single outrageous incident into a total war of annihilation.

Maybe there could be a "system-level conflict" where retaliation is immediate for attacks on a ship but conflict outside that immediate battle doesn't automatically start right away - some kind of official declaration of war from them (if sufficiently outraged and you insufficiently apologetic) or you (if you're genuinely turning on them and launching a surprise attack)? Its a very complex subject in either case
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on April 07, 2020, 06:27:08 PM
Yes, I've said I will add a variety of additional diplomacy options post-launch, including peace treaties of some sort. I'm just pointing out what is possible at launch.

I guess what you are asking though is that in some situations (depending on NPR characteristics and current relations), there would be a protest rather than immediate combat

I think what people are asking for is a more gradual degradation of relations to be the norm, rather than it being possible to go from close allies to war overnight.

Basically if a point of contention appears between two allied empires relations could degrade over some months or even some years with civilian trade getting cut off at a fairly early point and possibility of border skirmishes only towards the end.

A game that captures this excellent is Rule the Waves where you never know exactly what will bring you over the brink of war but you can see it coming miles away and make preparations. Being able to react to the development isn't just good for a feeling of plausibility, it also opens up strategic choices like the player being able to either move forces into place, dig in and prepare for operations in enemy territory... or redouble diplomatic efforts and compromise to try and avoid conflict.

The degradation happens due to tensions over territory. I am playing through that exact situation now in the test game. The powers are threatening each over Alpha Centauri and the situation is escalating. It is obvious that war is coming if someone doesn't back down.

However, tensions increasing is different than destroying a ship. Even on Earth, if a one power started sinking ships of a second, friendly power, relationships wouldn't gradually decrease. In the game, an allied NPR isn't going to suddenly open fire on you without warning. Conversely, if you start destroying ships from friendly NPRs then it is reasonable that they retaliate.

I look forward to seeing the escalation. Are you playing the obfuscated release version?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 07, 2020, 06:29:54 PM
Yes, but if for some reason the UK torpedoed a US frigate in the English Channel then it could certainly lead to the immediate end of friendship and maybe even further battle/war, but what *wouldn't* happen is that the US navy immediately opens fire on and sinks every british-flagged ship on the eastern seaboard, immediately turning a single outrageous incident into a total war of annihilation.

Maybe there could be a "system-level conflict" where retaliation is immediate for attacks on a ship but conflict outside that immediate battle doesn't automatically start right away - some kind of official declaration of war from them (if sufficiently outraged and you insufficiently apologetic) or you (if you're genuinely turning on them and launching a surprise attack)? Its a very complex subject in either case

I agree with that in principle. The problem is that in the scenario above, you have two countries with an equal ability to understand this could be an accident or it could be negotiated away. Assume the US is an NPR. Should the British be able to get away with sinking a US ship occasionally without long-term relationship problems? Or should the British be able to sink a US ship and know the US will only retaliate in the same area and can therefore make preparations accordingly - like luring the US fleet into an ambush? Also in this scenario, the US has to follow rules and isn't allowed to do the same to the British without lots of warnings first.

When you are dealing with an AI, you need to make rules that do not allow the player to manipulate those rules in unrealistic ways. Even with the rules on launch, you have the option to lightly damage an NPR ship and, without immediate further contact, relations will return to non-hostile quickly. If you are lined up face to face with an NPR ready for war, then don't shoot at its ships.

Longer term, there may be other options. If the damage isn't too bad and relations are good, then maybe a warning and a relationship hit for the first incident only.  I need to see the diplomacy in action a lot more though before I start adding more options or detail. It is already far more complex than VB6.
Title: Re: C# Aurora v0.x Suggestions
Post by: TinkerPox on April 07, 2020, 06:35:52 PM
There actually is a historical precedent.  .  .   See the USS Liberty Incident https://en. wikipedia. org/wiki/USS_Liberty_incident
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 07, 2020, 06:37:57 PM
I look forward to seeing the escalation. Are you playing the obfuscated release version?

No, I'm still making changes in the debug version. One NPR is about to open fire on another, so I am going to play that out as I've been adding some more AI intelligence around targeting populations. Assuming that goes well (as this will be the first NPR on NPR conflict), then I will compile the exe, add the obfuscation and go through the create game process in the installed version (minimal background). If I can play the first year or two of a basic campaign without issues, then I will be happy to release. The main constraint is that I am very busy with my day job at the moment so my time on the game is limited. Fortunately, the four-day weekend is coming up.
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on April 07, 2020, 06:48:36 PM
Yes, but if for some reason the UK torpedoed a US frigate in the English Channel then it could certainly lead to the immediate end of friendship and maybe even further battle/war, but what *wouldn't* happen is that the US navy immediately opens fire on and sinks every british-flagged ship on the eastern seaboard, immediately turning a single outrageous incident into a total war of annihilation.

Maybe there could be a "system-level conflict" where retaliation is immediate for attacks on a ship but conflict outside that immediate battle doesn't automatically start right away - some kind of official declaration of war from them (if sufficiently outraged and you insufficiently apologetic) or you (if you're genuinely turning on them and launching a surprise attack)? Its a very complex subject in either case

I agree with that in principle. The problem is that in the scenario above, you have two countries with an equal ability to understand this could be an accident or it could be negotiated away. Assume the US is an NPR. Should the British be able to get away with sinking a US ship occasionally without long-term relationship problems? Or should the British be able to sink a US ship and know the US will only retaliate in the same area and can therefore make preparations accordingly - like luring the US fleet into an ambush? Also in this scenario, the US has to follow rules and isn't allowed to do the same to the British without lots of warnings first.

When you are dealing with an AI, you need to make rules that do not allow the player to manipulate those rules in unrealistic ways. Even with the rules on launch, you have the option to lightly damage an NPR ship and, without immediate further contact, relations will return to non-hostile quickly. If you are lined up face to face with an NPR ready for war, then don't shoot at its ships.

Longer term, there may be other options. If the damage isn't too bad and relations are good, then maybe a warning and a relationship hit for the first incident only.  I need to see the diplomacy in action a lot more though before I start adding more options or detail. It is already far more complex than VB6.

Doesn't Aurora kind of presume that faster-than-light communication doesn't exist? It occurs to me that if long-range communications is difficult or impossible, then it might be accepted by fleet command that a certain number of ships sent out are just going to disappear. Obviously things change if they can radio home immediately to let them know they're under attack.


The USS Liberty incident is a good example of that kind of scenario. Another example might be the Dogger Bank Incident during the Russo-Japanese War, where the Russian second pacific squadron mistook English fishing trawlers for Japanese torpedo boats and fired on them, very nearly causing Great Britain to declare war on Russia.
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on April 07, 2020, 07:01:38 PM
Doesn't Aurora kind of presume that faster-than-light communication doesn't exist? It occurs to me that if long-range communications is difficult or impossible, then it might be accepted by fleet command that a certain number of ships sent out are just going to disappear. Obviously things change if they can radio home immediately to let them know they're under attack.
The AI currently doesn't, and I can imagine that making it do so would be pretty difficult. As it is, any non-FTL communication is purely a roleplaying choice by the player. One that I and many people personally enjoy and make quite often, since it allows for more interesting decision-making, but a roleplaying choice nevertheless.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on April 07, 2020, 07:02:42 PM
There actually is a historical precedent.  .  .   See the USS Liberty Incident https://en. wikipedia. org/wiki/USS_Liberty_incident
We also have historical examples of it going the other way:

https://en.wikipedia.org/wiki/Gulf_of_Tonkin_incident  (https://en.wikipedia.org/wiki/Gulf_of_Tonkin_incident)
and
https://en.wikipedia.org/wiki/USS_Maine_(ACR-1) (https://en.wikipedia.org/wiki/USS_Maine_(ACR-1))

There are many examples of the situation escalating as well as de-escalating. History is tricky like that.
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on April 07, 2020, 07:05:52 PM
What I propose is splitting relations into two metrics: an overall relations status, and a "flashpoint" or "tension" metric that is system-specific.

This system-specific "flashpoint" level multiplies the effect of diplomatic actions on the overall relations. Furthermore, the "flashpoint" level falls very slowly.

In the scenario were side A blows up side B's ship, it escalates the tension level in that system by some arbitrary amount, say from 1 to 3. If side A blows up another one of side B's ships, the relations penalty is now 3 times worse, and because the tension level falls very slowly, side A can't keep blowing up side B's ships every once in a while. If a war does occur, and relations are later normalized following a peace treaty, the tension level is still high enough that a future hostile action might warrant an immediate military response.
Title: Re: C# Aurora v0.x Suggestions
Post by: Hazard on April 07, 2020, 08:49:07 PM
The thing with a single incident causing a war is that they don't.

Rather, what you will see is that the governments figure out if a war would be worth fighting. Wars are expensive after all, in lives and material. But after that assessment? They start pushing for that war, and they either manufacture an incident, they exploit an incident or they manage to bully their opposition into yielding. The incident is rarely the cause of the war, it's merely the spark lighting the fuse.


So if the UK sank a USA warship in British waters it'd be put down to a terrible accident and a bunch of heads in both navies are likely to roll because the accident happened at all. You might see a cooling of relations but the USA and the UK are allies and that alliance is more valuable to both of them. Likewise were there a number of incidents during the Cold War that could've ignited that war, like when Korean Air Lines Flight 007 was shot down by the Soviet Union during a time of very high tensions between NATO and the Warsaw Pact, but nobody actually wanted that war. Everybody would've lost.

At the same time, small events have been blown greatly out of proportion for the sake of provoking a war, or flat out invented for the sake of political expedience. When the ####s were ready to attack Poland, part of the plans was to have #### troops pretend to be Polish forces shelling German positions, and to take that as the justification for the war against Poland. Similarly was the presence of WMDs in Iraq's arsenal used as justification by the USA, but later investigation showed no such weapons existed and that it was entirely fabricated to justify the war. The War for Jenkins' Ear started when a sailor by the name of Jenkins presented his cut off decaying ear to the English Parliament and related how it was severed years beforehand by the Spanish. Incensed and having spend the last decades looking for a justification for a war to resolve a territory dispute in the Americas it was seized upon by Parliament and used to start the war that had been brewing for quite a while by then.


That said, one way to resolve the question of 'how to make the AI estimate whether or not something was an accident or deliberate action' is by having the AI check the incident, see what got hit, check the point value of that damage and check the originating empire's relationship with the AI involved. If they're allies and it's the first incident? The AI stores the incident for a while (probably related to the build point value or build time of the ship) after which it forgets it happened. If they're allies and both empires had just (as in the past 24 hours) been in conflict in that system with a third party with missiles flying around? Well, friendly fire isn't, but it happens and it happens more often when weapons with self aiming capability end up pointed the wrong way, so it stores the data for a while.

Should repeat events occur the AI will shift their diplomatic stance away from their unreliable ally, adding the diplomatic point shift that had been deferred.

When we're not talking allies but friendly empires the same happens but part of the shift happens immediately.

With neutral and hostile empires it's just straight to confrontation.
Title: Re: C# Aurora v0.x Suggestions
Post by: amram on April 07, 2020, 08:53:51 PM
Rather than multiple measures of relation, which certainly have merit, i'm not arguing against, but would it not be simpler to just have enough headroom in the range of possible relations to allow a huge diplomatic hit from ship loss? 

A set back worth years, if not decades of diplomatic effort. If you have enough goodwill stacked up, perhaps not war, but definitely not the trust you had.

Across all of history there have been examples of different peoples meeting for the first time, unable to effectively communicate for language barriers and differing cultural norms, some have come to start war, some have started war without meaning to.  Lets set that aside and worry about those that managed extended peace before war broke out.

Granted, potentially very different alien species may not even realise their opposite is even looking at them if they cannot see what they recognise as a face, or even just eyes, or possibly even that they are trying to communicate at all, those early days are fraught with challenges, miscommunication and misunderstandings.  War should be easy to get into, and hard to get out of during this period.

Given enough time though, you learn to communicate with them, their culture, ideals, how not to offend, and what they view as a form of apology.  Any less and one must ask what those diplomatic envoys have been up to all those years, getting paid to chat and socialise, formally or otherwise.

That knowledge and trust could lead them to understand, for example, that rogue elements have attacked them, it was not sanctioned, the aggressors have been neutralised, and the host nation seeks to make amends.  Tense situation, but if the diplomats have done their jobs well, it doesn't get worse.

More likely, it could lead to understanding of an accident.  We didn't fire at you, we didn't even know your ship was there, we couldn't see it on sensors.  Alas, our missile had an active sensor aboard and when its original target died it was able to see your ship and engaged it with unfortunate results.

As far as having the AI discern a degree of player/AI intent without much effort, perhaps a pair of fields in the active missile/salvo object and relayed to any child objects spawned via stages, referencing the original target the firecontrol was set to, and the originating launch platform.  If the ship hit by the missile, was the FC target, be upset, that was intentional.  If the FC target was another empire's vessel, most likely an accident, be less upset.  If the target was a waypoint, don't be quite as mad as if you were the target, you might not have been, but it might not have been an accident.  If the missile also sets itself as launch platform when it is used as a mine, then that can be factored as well, since mines are less than an intentional strike, but more than an accidental blow.

Extend that intent to loss of a ship, since a single salvo acting as one entity of many may accidentally smash a target other than intended, coupled with enough headroom that accidental loss of ship plus maximum/near maximum relations results not in war but badly damaged relations. Two ships should be nearly, if not impossible to afford the penalty without war within a few years/decades of each other.

As a modifier, large powerful salvos will still be more harm than lesser ones, so bigger ships would, assuming only the damage received is counted rather than delivered, by default convey larger penalties with or without any modifier, so you perhaps could never hit their battleship hard enough to kill without triggering war, but a scout ship, a tanker, or some other fragile vessel, quite possibly.
Title: Re: C# Aurora v0.x Suggestions
Post by: Vivalas on April 07, 2020, 10:35:40 PM
I have an unrelated suggestion that is relatively simple, but pleases the Star Trek and conventional ocean navy fan in me  ;D


Is it possible to get an option somewhere to change the formatting of how ship names are displayed? Best case this is maybe fully customizable with template strings the user can edit, but maybe also a simple few different formats would be nice.

The format I'd like to see, really, is just something along the lines of 'USS Montana (DD-034)' or something. Basically, the ability to add hull numbers to your ship (which increment for every ship of the same hull type) and a way to change the way ships are displayed.

So instead of DD Ganges, TR Progea, CS Tango and etc. it would be USS Ganges (DD-21), USS Progea (TR-05), USS Tango (CS-01) etc. ([prefix] [name] ([class prefix]-[hull number]) in the various screens where ship names are displayed. With also the ability to customize the ship prefix for your empire (or even change it according to branches of your naval organization / admin command so you could get stuff like USNS for auxillar ships etc.) and having civilian liners have prefixes based on either shipping lines or just a common prefix (so SS Mercury's Bane or MV Achaea or something)

EDIT: And of course things like USS Enterprise (NX-01) :D
Title: Re: C# Aurora v0.x Suggestions
Post by: Zhatelier on April 08, 2020, 12:48:39 AM
I would actually suggest a "Trust factor" to damped the negative impacts on relations.  For obvious reasons, it would only be a post-release thing, but here are some example numbers on how it could work:

Trust would we a number ranging from 1-10 and any negative effects on relations would be divided by SQRT(Trust).
When a new race is met, the trust starts at 1.
Each year, the trust has a chance of going up by one: (100 - Xenophobia + Modifiers) / 1000.
Modifiers would include the diplo rating of a team plus any existing deals like trade or research etc.  each giving a 20 points bonus.
For every -100 to relations (prior to dampening, can happen in multiple incidents or claims if trust has not increased in the meanwhile. ) the trust will drop by one but never goes negative.

Trust would behave in a way similar to the diplomatic rating in that a race can only see their trust of another race, but not vice versa.  So I might have a trust factor of 5 to an NPR while they only have a trust of 3, thus my nation would be more willing to overlook any claims or incidents by the NPR than the other way around.  Trust would not have any direct impact on positive effects on relations, only lowering the negative ones.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 08, 2020, 03:31:33 AM
How about instead of moving directly to -100 for the first point of damage, there is instead a high multiple of the normal relationship hit for damage if not already hostile at the start of the increment?

I would also increase the 'Danger Rating' of the system where the incident occurred, so that non-military NPR shipping would avoid the area.

That way, a single ship being damaged is going to affect relations and cause an NPR pull-back in economic terms but probably not cause a war if relations are high enough. Conversely, if you destroy several ships in a surprise attack while at peace, you end up with a huge negative reaction (a Pearl Harbour reaction). Those mechanics avoid a lot of complexity but provides the basic idea proposed above. To make things fair, I would also allow an NPR to fire on player ships without being hostile if the player continues to ignore requests to leave a system.

Title: Re: C# Aurora v0.x Suggestions
Post by: MarcAFK on April 08, 2020, 03:55:59 AM
That sounds fair to me.
Title: Re: C# Aurora v0.x Suggestions
Post by: chrislocke2000 on April 08, 2020, 04:20:53 AM
Sounds good to me as well. Not sure if you have implemented different AI types yet but if so I guess you could change the multiplier based on the outlook of the empire AI.
Title: Re: C# Aurora v0.x Suggestions
Post by: SerBeardian on April 08, 2020, 03:30:16 PM
How about instead of moving directly to -100 for the first point of damage, there is instead a high multiple of the normal relationship hit for damage if not already hostile at the start of the increment?

I would also increase the 'Danger Rating' of the system where the incident occurred, so that non-military NPR shipping would avoid the area.

That way, a single ship being damaged is going to affect relations and cause an NPR pull-back in economic terms but probably not cause a war if relations are high enough. Conversely, if you destroy several ships in a surprise attack while at peace, you end up with a huge negative reaction (a Pearl Harbour reaction). Those mechanics avoid a lot of complexity but provides the basic idea proposed above. To make things fair, I would also allow an NPR to fire on player ships without being hostile if the player continues to ignore requests to leave a system.

Entirely reasonable on all fronts.
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on April 08, 2020, 05:12:59 PM
Just adding my +1. Simple ways to model complex outcomes are great.
Title: Re: C# Aurora v0.x Suggestions
Post by: Barkhorn on April 08, 2020, 07:49:28 PM
How about instead of moving directly to -100 for the first point of damage, there is instead a high multiple of the normal relationship hit for damage if not already hostile at the start of the increment?

I would also increase the 'Danger Rating' of the system where the incident occurred, so that non-military NPR shipping would avoid the area.

That way, a single ship being damaged is going to affect relations and cause an NPR pull-back in economic terms but probably not cause a war if relations are high enough. Conversely, if you destroy several ships in a surprise attack while at peace, you end up with a huge negative reaction (a Pearl Harbour reaction). Those mechanics avoid a lot of complexity but provides the basic idea proposed above. To make things fair, I would also allow an NPR to fire on player ships without being hostile if the player continues to ignore requests to leave a system.
Could you include the ability for the NPR to do a Pearl Harbour style attack as well?  It just doesn't seem right if that mechanic is only an option for players.
Title: Re: C# Aurora v0.x Suggestions
Post by: Vivalas on April 08, 2020, 09:14:54 PM
How about instead of moving directly to -100 for the first point of damage, there is instead a high multiple of the normal relationship hit for damage if not already hostile at the start of the increment?

I would also increase the 'Danger Rating' of the system where the incident occurred, so that non-military NPR shipping would avoid the area.

That way, a single ship being damaged is going to affect relations and cause an NPR pull-back in economic terms but probably not cause a war if relations are high enough. Conversely, if you destroy several ships in a surprise attack while at peace, you end up with a huge negative reaction (a Pearl Harbour reaction). Those mechanics avoid a lot of complexity but provides the basic idea proposed above. To make things fair, I would also allow an NPR to fire on player ships without being hostile if the player continues to ignore requests to leave a system.
Could you include the ability for the NPR to do a Pearl Harbour style attack as well?  It just doesn't seem right if that mechanic is only an option for players.


That would be really cool. It could mirror the above formula and the chance of a surprise attack being possible would be proportional to xenophobia, determination, and militancy.

So, instead of the current situation of decreased relations, threats, and posturing and warning shots after ignoring its claims or you claiming a system it wants, it determines that it does in fact want to go to war with you, but instead of the player getting any notices of the sort, it just stealthily starts posturing its fleets and recalling its traders before dropping the hammer out of nowhere and suddenly what you just thought was your ally now has a battle fleet on a direct course for your homeworld  ;)
Title: Re: C# Aurora v0.x Suggestions
Post by: MasonMac on April 08, 2020, 11:48:10 PM
Possibly mentioned before, but how about enabling scripts to automate some button mashing. For instance, if I wanted to create the exact same Mars NPR each time, but with colonies and ships already generated. It wouldn't introduce true modability, and is more of a QOL thing. At minimum, it would let you do the same things you could do without a script.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 09, 2020, 03:34:33 AM
Could you include the ability for the NPR to do a Pearl Harbour style attack as well?  It just doesn't seem right if that mechanic is only an option for players.

You don't see the NPR view of you, although you could probably infer it from some of the messages. Even so, you don't know when they are about to attack.

I could add some unlikely drop in relations as a random event, that would trigger something similar. Or perhaps better would be a random over-reaction to a negative event.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 09, 2020, 03:36:06 AM
Possibly mentioned before, but how about enabling scripts to automate some button mashing. For instance, if I wanted to create the exact same Mars NPR each time, but with colonies and ships already generated. It wouldn't introduce true modability, and is more of a QOL thing. At minimum, it would let you do the same things you could do without a script.

You can do that outside of Aurora if you want to setup a macro.
Title: Re: C# Aurora v0.x Suggestions
Post by: alaysian on April 09, 2020, 10:40:43 AM
Quote
Or perhaps better would be a random over-reaction to a negative event.

I think that would be the better way, as at least it would be based on something.   I would also add the opposite for the sake of balance.   
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on April 09, 2020, 10:54:21 AM
Yeah, random drop sounds terrible. Randomly overreacting to an event sounds more plausible. The idea that Pearl Harbour came from nowhere is false. It happened after years of growing hostility between Japan and the US and after a major embargo by the latter. The timing and the location were the surprises, not the act itself.

I certainly wouldn't want an allied NPR that I'm sharing trade and tech and survey data with, to suddenly attack me out of the blue. But performing a surprise attack in force, after several production cycles of worsening relations and having treaties broken - yeah that's cool and a great story element.
Title: Re: C# Aurora v0.x Suggestions
Post by: Desdinova on April 09, 2020, 01:30:39 PM
Hi Steve, it'd be really cool if Aurora could display a device on a ribbon for multiple awards of a medal.

This is a problem I just had to solve for my ribbon maker program. It took me quite a while to figure out how to draw a device over a ribbon correctly. I'm having a slow day at work so I wrote up this code sample just in case this is a feature you were interested in implementing later:

Code: [Select]
//Dependencies
using System.Drawing;

Bitmap ribbon; //base ribbon sans device
int num_awards; //number of times medal has been awarded
Bitmap device; //particular device for number of awards

//iterate over each medal awarded, loading the ribbon bitmap and calculating the number of awards
{
//Load device bitmap. In this example, the devices are loaded into a resource file
if (num_awards = 2) device = Properties.Resources.BronzeOakLeaf
if (num_awards = 3) device = Properties.Resources.SilverOakLeaf
if (num_awards >= 4) device = Properties.Resources.GoldOakLeaf
//etc etc.....

//this is required for alpha channel transparency to work
device.MakeTransparent();

//destination for drawing the device on top of the ribbon is a rectangle
//centered in the ribbon, with width and height equal to the device
Rectangle destRectangle = new Rectangle (
(ribbon.Width - device.Width) / 2,
(ribbon.Height - device.Height) / 2,
device.Width,
device.Height
);

//source for drawing is just the entire device
Rectangle sourceRectangle = new Rectangle (0, 0, device.Width, device.Height);

//Compose device on top of ribbon bitmap
using (Graphics g = Graphics.FromImage(Ribbon))
{
g.DrawImage(device, destRectangle, sourceRectangle, GraphicsUnit.Pixel);
}
}

Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 09, 2020, 02:21:54 PM
Hi Steve, it'd be really cool if Aurora could display a device on a ribbon for multiple awards of a medal.

This is a problem I just had to solve for my ribbon maker program. It took me quite a while to figure out how to draw a device over a ribbon correctly. I'm having a slow day at work so I wrote up this code sample just in case this is a feature you were interested in implementing later:

Code: [Select]
//Dependencies
using System.Drawing;

Bitmap ribbon; //base ribbon sans device
int num_awards; //number of times medal has been awarded
Bitmap device; //particular device for number of awards

//iterate over each medal awarded, loading the ribbon bitmap and calculating the number of awards
{
//Load device bitmap. In this example, the devices are loaded into a resource file
if (num_awards = 2) device = Properties.Resources.BronzeOakLeaf
if (num_awards = 3) device = Properties.Resources.SilverOakLeaf
if (num_awards >= 4) device = Properties.Resources.GoldOakLeaf
//etc etc.....

//this is required for alpha channel transparency to work
device.MakeTransparent();

//destination for drawing the device on top of the ribbon is a rectangle
//centered in the ribbon, with width and height equal to the device
Rectangle destRectangle = new Rectangle (
(ribbon.Width - device.Width) / 2,
(ribbon.Height - device.Height) / 2,
device.Width,
device.Height
);

//source for drawing is just the entire device
Rectangle sourceRectangle = new Rectangle (0, 0, device.Width, device.Height);

//Compose device on top of ribbon bitmap
using (Graphics g = Graphics.FromImage(Ribbon))
{
g.DrawImage(device, destRectangle, sourceRectangle, GraphicsUnit.Pixel);
}
}

Thanks. I probably won't do this for launch but I will look into it post-launch.
Title: Re: C# Aurora v0.x Suggestions
Post by: Pounipop on April 09, 2020, 02:24:04 PM
It will be cool if the genetics modification center can be use to create better soldier (like space marine). 
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 09, 2020, 02:26:19 PM
It will be cool if the genetics modification center can be use to create better soldier (like space marine).

You can already do that through the new ground combat biology techs.
Title: Re: C# Aurora v0.x Suggestions
Post by: papent on April 09, 2020, 02:32:48 PM
Would it be possible to get plasma cannonades as turretable weapons?
 I would also suggest particle beams but I'm unsure how that would effect balance.
Title: Re: C# Aurora v0.x Suggestions
Post by: Agraelgrimm on April 09, 2020, 07:40:43 PM
Quote from: papent link=topic=9841. msg120682#msg120682 date=1586460768
Would it be possible to get plasma cannonades as turretable weapons?
 I would also suggest particle beams but I'm unsure how that would effect balance.
I dont know about that, but what i would really like to see is proper torpedo mechanics.  Could even be an energy weapon variant, like the photon torpedoes of Star Trek out something like this, in order to reuse the existing codes and mechanics for a minimal amount of code changes. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on April 10, 2020, 01:58:00 AM
I dont know about that, but what i would really like to see is proper torpedo mechanics.  Could even be an energy weapon variant, like the photon torpedoes of Star Trek out something like this, in order to reuse the existing codes and mechanics for a minimal amount of code changes.

Sure.  *Renames size-14 missile "Photon Torpedo"*

- - - - -

Okay, sorry to be facetious.

What do you mean by "proper torpedo mechanics"?  Are you looking for a light-speed weapon that breaks the 5 LS distance limit?  A tracking weapon that moves that fast would be completely un-balanced compared to regular missiles.

Do you want a different damage profile from 'regular missile'?  That can be done -- we once had x-ray laser warheads for missiles and supposedly will again -- though it is 'on the list' for C# Aurora 2.0, or maybe 3.0.

Do you want an entirely energy-based 'missile' so your ships (and empire, for that matter) never run out of ammuntion, don't need ordnance factories, and spend less (possibly no) minerals on torpedoes?  That sounds even more unbalanced.

Now, maybe a missile that needs to have it's warhead 'charged' from an on-board power plant and uses different minerals -- maybe even a non-Sorium fuel source -- could be reasonable.  Or maybe plasma carronades gain a sister-tech line that allows them to produce (relatively) slow-moving 'plasma torpedoes' that are ammunition-free pure energy seeking weapons.

Or maybe -- and best of all from my perspective -- we get armoured missiles back, and my empire can build slow-moving, short-ranged, size 14, or 21, or 24 (armoured) missiles with massive warheads that put huge holes in ships and my empire calls them Fourteen (or Twenty-One, or Twenty-Four) Inch Torpedoes.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tree on April 10, 2020, 04:29:13 AM
IIRC you once shot down the idea of arranging systems like in the picture below because Aurora would have to generate all the systems at once at game start, and this would take a very long time. Now with C#'s faster generation, will it be possible in the future to have a map like this one rather than the more usual tree/arms structure with the occasional link to another? To be clear I'm talking about the way stars are linked to each others generally, and how from a star to another some distance away there are a thousand different paths rather than the one or two paths usually found with the tree structure; not talking about the galaxy shape which wouldn't make all that much sense in Aurora or the visuals.
Or maybe it'd be possible to shorten the time by generating only the star and jump points, and then the other bodies (and the possible NPR) only once a player or NPR explores the system, though I think you also once said system generation was a thing ran all at once that couldn't be cut into pieces.
I suppose having however many NPRs generated right from zero wouldn't make for good performances too, this would probably need an option for a hard cap on the number of NPRs.

(https://pbs.twimg.com/media/DTlyakAXUAAOeWX?format=jpg&name=medium)

Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on April 10, 2020, 04:53:58 AM
IIRC you once shot down the idea of arranging systems like in the picture below. . .

(https://pbs.twimg.com/media/DTlyakAXUAAOeWX?format=jpg&name=medium)

If you set "Local System Generation Chance" to 100%, and "Local System Generation Spread" to 2 or 3, you'll get a map much like that one. . . Oh, and of course set "Real Stars" to OFF.

Well, you personally will still have to drag all those systems around one-by-one on the galactic map to duplicate the layout, but you'll have the interconnectedness.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tree on April 10, 2020, 06:02:17 AM
If you set "Local System Generation Chance" to 100%, and "Local System Generation Spread" to 2 or 3, you'll get a map much like that one. . . Oh, and of course set "Real Stars" to OFF.

Well, you personally will still have to drag all those systems around one-by-one on the galactic map to duplicate the layout, but you'll have the interconnectedness.

Right but I was thinking real stars, I just so rarely play fake stars.
And there's also still problems with it:
Untitled2 is with 100%/3 (from Sol), Untitled3 with 90%/3 (from Kansazan, middle top) and Untitled4 (from Praxedis, top left) with 97%/3.
I think the problem with 2 is a bit obvious.
With Untitled3 the usual tree structure starts emerging already. Yes there would be the occasional link to another branch eventually, but that's an exception rather than a rule.
Untitled4 was starting to look like an Untitled2 that would go on forever, but the game there froze and crashed while generating Durer from Ludovica. I relaunched the game and explored the jump point again in Ludovica, and it led to Chassagne instead of Durer.

I just don't think the dense network from the Stellaris screenshot is currently attainable in Aurora with the generation rules as they are.

Untitled2
(http://aurora2.pentarch.org/index.php?action=dlattach;topic=9841.0;attach=2521)

Untitled3
(http://aurora2.pentarch.org/index.php?action=dlattach;topic=9841.0;attach=2523)

Untitled4
(http://aurora2.pentarch.org/index.php?action=dlattach;topic=9841.0;attach=2525)
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on April 10, 2020, 06:46:57 AM

Right but I was thinking real stars, I just so rarely play fake stars.



Okay, but that's equivalent to asking "How come there's never an NPR on Mars when I do a Sol start?"  Real stars doesn't work that way.

- - - - -

To get the kind of 'web of stars' you're looking for, Aurora would have to completely change its 'jump point generation & destination' algorithm, and force every system to have 2-5 jump points that connect to neighbouring systems.

= = = = =

If you mess around with 100%/2 and 100%/3 and 100%/4 settings, and make judicious use of SpaceMaster to force connections (or even just "Add JP") you can get your web, but short of Steve implementing a "No dead end systems" option I don't see how Aurora could do what you want without changing a huge chunk of the code.
Title: Re: C# Aurora v0.x Suggestions
Post by: Tree on April 10, 2020, 08:33:31 AM
Real stars could be made to work like fake stars, or implementing that web for both could be easier (or even more complicated) than any of us thinks. Real stars after all already have XYZ coordinate, fake stars could get XY coordinates of their own. It would also bring a definitive change in pace and gameplay, that's why I'm posting here.
Title: Re: C# Aurora v0.x Suggestions
Post by: SpaceMarine on April 10, 2020, 11:49:14 AM
Hey steve, so after the turn time video came out, we were discussing on the discord and we started talking about how interrupts in C# will be the probably the main thing to "slow" games down,
I know you have worked on interrupts to make them better but maybe adding post release a way to turn off certain non "essential" interrupts such as civillians or haulers, effectively "speeding up"
the game, just a thought. 
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 10, 2020, 12:05:08 PM
Hey steve, so after the turn time video came out, we were discussing on the discord and we started talking about how interrupts in C# will be the probably the main thing to "slow" games down,
I know you have worked on interrupts to make them better but maybe adding post release a way to turn off certain non "essential" interrupts such as civillians or haulers, effectively "speeding up"
the game, just a thought.

Here is the current interrupt list for players. There are no civilian interrupts. In C#, NPR interrupts do not stop automated turns; they only shorten the current increment.

Alien Communication
Breathable Atmosphere
Combat Summary
Damage Report
Fleet Message
Gas Removed
Ground Combat Update
Hostile Contact Update
Ice Sheet Melted
Illegal Order
Inactive Lab
Invalid Unload System
Jump Point Detected
Mineral Shortage
New Alien Race
New Hostile Contact
New System Discovered
No Missile Assigned
Orders Completed
Out of Ammo
Overhaul Complete
Pickup Failed
Planet Looted
Production
Ramming Attempt
Reparations
Research Completed
Ruins Exploited
Ruins Located
Ship Construction
Ship Destroyed
Ship Refit
Ship Repair
Ship Scrapped
Ship Surrender
Shipyard Modified
Successful Espionage
System Surveyed
Targeting Problem
Tech Downloaded
Terraforming Report
Transit Failure
Unit Trained
Title: Re: C# Aurora v0.x Suggestions
Post by: SpaceMarine on April 10, 2020, 12:08:38 PM
Thanks, that seems much better and its nice to actually see what will actually activate the interrupts, good work! Still could be useful to add the ability to turn certain ones off such as "inactive lab"
which can get quite annoying if very specific scenarios such as not enough workers for new labs etc, but overall it looks fine to me
Title: Re: C# Aurora v0.x Suggestions
Post by: misanthropope on April 10, 2020, 12:44:42 PM
i haven't been following the # conversation very closely, but i'm playing caveman aurora right now, and a QOL buff i would love is this:

on the fleet orders page, the "task force" dropdown shouldn't be to set the TF, it should be a filter (including the option "all", obv) to _display_ only fleets belonging to said task force.  put an identical filter on the "ships" page, and you could put the "assign to a TF" functionality under the "special orders/ organization" tab in the fleet orders page.  it seems pretty natural and the real estate seems sufficient.

thanks
Title: Re: C# Aurora v0.x Suggestions
Post by: JacenHan on April 10, 2020, 01:08:45 PM
The fleet orders and organization system has changed pretty dramatically, and the task force/task group distinction doesn't really exist anymore. You may want to read this post (http://aurora2.pentarch.org/index.php?topic=8495.msg97344;topicseen#msg97344) and this post (http://aurora2.pentarch.org/index.php?topic=8495.msg103849;topicseen#msg103849).
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 10, 2020, 01:14:32 PM
Thanks, that seems much better and its nice to actually see what will actually activate the interrupts, good work! Still could be useful to add the ability to turn certain ones off such as "inactive lab"
which can get quite annoying if very specific scenarios such as not enough workers for new labs etc, but overall it looks fine to me

You can't turn workers off in C#, so that issue no longer exists. They just run at lower efficiency.
Title: Re: C# Aurora v0.x Suggestions
Post by: harpyeagle on April 10, 2020, 10:57:53 PM
Hi everyone! Looking forwards to the Aurora C# release :D

One thing I noticed while browsing the forums is that one of the Non-Support Fighter Missions had a really anachronistic sounding name: "Flak Suppression"

It would probably fit better to use the modern terminology: Suppression of Enemy Air Defenses (SEAD)

There is a Wikipedia article for a fuller description.  I'd link to it but hyperlinks don't seem to work.
Title: Re: C# Aurora v0.x Suggestions
Post by: harpyeagle on April 11, 2020, 08:56:46 AM
Well, I guess my gripe with Flak Suppression is that it isn't general.  Flak (which sounds like WW2 or early cold war era air defence artillery) versus the more generic Enemy Air Defences.
Title: Re: C# Aurora v0.x Suggestions
Post by: harpyeagle on April 11, 2020, 10:18:28 AM
For some reason [img] tags aren't working for me, nether are links  ???  so I'll just have to paste this URL below:

hxxp: www. pentarch. org/steve/Screenshots/Crusade/1889_017. PNG

When viewing displays such as this one, where there are many different objects on and around a body with many different owners, I think it would be much easier to read at a glance if the list was sorted 1st by surface/orbital (kind of like how it is now), 2nd by ownership, then 3rd by tonnage.  Visually pulling apart the HOT and MARS ships in that long list is a bit of a headache.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 11, 2020, 10:47:56 AM
For some reason [img] tags aren't working for me, nether are links  ???  so I'll just have to paste this URL below:

hxxp: www. pentarch. org/steve/Screenshots/Crusade/1889_017. PNG

When viewing displays such as this one, where there are many different objects on and around a body with many different owners, I think it would be much easier to read at a glance if the list was sorted 1st by surface/orbital (kind of like how it is now), 2nd by ownership, then 3rd by tonnage.  Visually pulling apart the HOT and MARS ships in that long list is a bit of a headache.

This has already been addressed. Check out the later screenshots.
Title: Re: C# Aurora v0.x Suggestions
Post by: DFNewb on April 11, 2020, 12:35:30 PM
Hey steve, so after the turn time video came out, we were discussing on the discord and we started talking about how interrupts in C# will be the probably the main thing to "slow" games down,
I know you have worked on interrupts to make them better but maybe adding post release a way to turn off certain non "essential" interrupts such as civillians or haulers, effectively "speeding up"
the game, just a thought.

Here is the current interrupt list for players. There are no civilian interrupts. In C#, NPR interrupts do not stop automated turns; they only shorten the current increment.

Alien Communication
Breathable Atmosphere
Combat Summary
Damage Report
Fleet Message
Gas Removed
Ground Combat Update
Hostile Contact Update
Ice Sheet Melted
Illegal Order
Inactive Lab
Invalid Unload System
Jump Point Detected
Mineral Shortage
New Alien Race
New Hostile Contact
New System Discovered
No Missile Assigned
Orders Completed
Out of Ammo
Overhaul Complete
Pickup Failed
Planet Looted
Production
Ramming Attempt
Reparations
Research Completed
Ruins Exploited
Ruins Located
Ship Construction
Ship Destroyed
Ship Refit
Ship Repair
Ship Scrapped
Ship Surrender
Shipyard Modified
Successful Espionage
System Surveyed
Targeting Problem
Tech Downloaded
Terraforming Report
Transit Failure
Unit Trained


Would it be possible to make this list customizable in future releases?
Title: Re: C# Aurora v0.x Suggestions
Post by: Jovus on April 11, 2020, 12:41:56 PM
Are NPRs now capable of starting conventional and then transferring to be TN?

Not at release. I will tackle that at some point though.

When you do, would it be too much to ask for a configuration toggle so that you can set it up that some NPRs will not make the transition from conventional to TN empire? This would be a great way to roleplay a 'minor power' scenario where the player could uplift, observe, oppress, etc. someone who "didn't get to space fast enough."
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on April 11, 2020, 01:15:33 PM
Ideally, you would have pre-TN NPRs with a random element so that they research TN in 5-50 years, with some being so far behind that they cannot do it on their own - their fate left to the player.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 11, 2020, 01:41:49 PM
Would it be possible to make this list customizable in future releases?

Not likely soon. These are all events that will need action by the player and I don't want to get into a situation post-release where players miss things of this type. Maybe in a while I will look at it.
Title: Re: C# Aurora v0.x Suggestions
Post by: jatzi on April 12, 2020, 12:23:45 AM
So I had an idea while talking to people on the discord about invaders.  I know they've been taken out of the game for now.  What if though instead of randomly appearing from wormholes every once in awhile they were a large, powerful, established NPR-style race.  Like when you came across one of their systems the game would generate a dozen or more systems that they own.  Or when the game starts, guess it doesn't matter.  But yeah the idea is just that they're an established race with actual territory and perhaps they're a little stagnant when you first come across them but become more aggressive similar to Fallen Empires from Stellaris. 

Also I hope that eye of terror idea becomes a thing.  The idea of a large, super scary, genocidal crusade coming out and potentially wrecking everything would be awesome. 
Title: Re: C# Aurora v0.x Suggestions
Post by: QuakeIV on April 12, 2020, 01:24:53 AM
Suddenly black crusade.  I support such an idea...
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on April 12, 2020, 03:15:16 AM
. . .What if though instead of randomly appearing from wormholes every once in awhile they were a large, powerful, established NPR-style race.  Like when you came across one of their systems the game would generate a dozen or more systems that they own.  Or when the game starts, guess it doesn't matter.  But yeah the idea is just that they're an established race with actual territory. . .

Already in.

If -- upon exploring a jump point -- Aurora generates a "big" enough NPR to have multiple systems, it 'breaks' that jump point link and generates a new, stop-gap system and puts the original NPR-bearing system on the other side of one of the new system's jump points.  Aurora will do this two or three times if necessary.
Title: Re: C# Aurora v0.x Suggestions
Post by: Agm-114 on April 12, 2020, 07:41:33 AM
Hey steve, would it be possible for the ui images be unpacked from the exe so we can change them out?
Title: Re: C# Aurora v0.x Suggestions
Post by: Wieseltrupp on April 12, 2020, 07:45:47 AM
I would like to have an "Reasearch Started" event for queued Projects so i could see wich of my researches truly completed their work without looking it up in the Research Screen
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 12, 2020, 09:14:52 AM
Hey steve, would it be possible for the ui images be unpacked from the exe so we can change them out?

They are built into the individual buttons. I'll look at this at some point, but not priority at the moment.
Title: Re: C# Aurora v0.x Suggestions
Post by: Wieseltrupp on April 12, 2020, 09:20:51 AM
Please add a confirmation Dialog when closing the game, VB6 saved every turn so i just closed the game out of habbit
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on April 12, 2020, 09:26:21 AM
Powered Infantry Armour is available automatically at Conventional Start.

Personally, I think that it should be gated behind Trans-Newtonian Tech or at least it should need to be researched.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on April 12, 2020, 09:28:32 AM
I'd love if the "Hull Types" list on the Ship Design Screen would allow me to hide some (or all) of the hull types so I could populate the list I see with only the ones I'm going to use in my game (I know the NPRs use the list too, that's fine, I primarily want to make it easier to find the six-to-ten entries my empire will use).

- - - - -

Failing that, can the list be ordered alphabetically by abbreviation, so it becomes a lot easier to notice that we're simultaneously using CS for Colony Ship, Survey Cruiser, and Strike Cruiser?
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 12, 2020, 09:32:10 AM
Powered Infantry Armour is available automatically at Conventional Start.

Personally, I think that it should be gated behind Trans-Newtonian Tech or at least it should need to be researched.

Agree and fixed.
Title: Re: C# Aurora v0.x Suggestions
Post by: Energyz on April 12, 2020, 10:54:06 AM
Quote from: Wieseltrupp link=topic=9841. msg121001#msg121001 date=1586701251
Please add a confirmation Dialog when closing the game, VB6 saved every turn so i just closed the game out of habbit

Yeah that would be fantastic, i really felt stupid
Title: Re: C# Aurora v0.x Suggestions
Post by: Demonides on April 12, 2020, 11:06:32 AM
Suggestion.
When you want quit the game, a window pop up and asking "do you want to save the game"
Title: Re: C# Aurora v0.x Suggestions
Post by: TinkerPox on April 12, 2020, 05:06:46 PM
We're only able to add ranks to Naval Officers, not Ground Forces. If we use huge formations this could be an issue and I want to RP company level and up. Also renaming ranks while in the window would be a nice feature too.
Title: Re: C# Aurora v0.x Suggestions
Post by: Garfunkel on April 12, 2020, 06:49:16 PM
Click rank, click rename.

Click name, click rename.

The same button does both, just depending on what you've selected before.
Title: Re: C# Aurora v0.x Suggestions
Post by: Marski on April 12, 2020, 09:46:06 PM
Yeah ground force ranks need some love. Please I beg you, add the possibility to add ranks to the ground forces as well.
Title: Re: C# Aurora v0.x Suggestions
Post by: jatzi on April 13, 2020, 06:48:32 AM
Quote from: Father Tim link=topic=9841. msg120824#msg120824 date=1586679316
Quote from: jatzi link=topic=9841. msg120820#msg120820 date=1586669025
.  .  . What if though instead of randomly appearing from wormholes every once in awhile they were a large, powerful, established NPR-style race.   Like when you came across one of their systems the game would generate a dozen or more systems that they own.   Or when the game starts, guess it doesn't matter.   But yeah the idea is just that they're an established race with actual territory.  .  . 

Already in.

If -- upon exploring a jump point -- Aurora generates a "big" enough NPR to have multiple systems, it 'breaks' that jump point link and generates a new, stop-gap system and puts the original NPR-bearing system on the other side of one of the new system's jump points.   Aurora will do this two or three times if necessary.

So I know this thread is probably dead now but I'll respond here.  I didn't mean an NPR I meant a spoiler that is kind of like an NPR in that it owns systems but that's it.  It's just the idea that the invaders didn't leave through a wormhole after killing the precursors, they stayed and set up shop in some systems.  They'd be stronger and more advanced and ideally way more aggressive than a normal NPR.
Title: Re: C# Aurora v0.x Suggestions
Post by: Father Tim on April 13, 2020, 10:26:30 AM
Well, depending on your empire's tech level, Precursors and Swarm and even Invaders can be way less advanced or strong than the player.  They generally don't scale with you.

But -- unless such a race included some weird new tech or other systems -- what you are describing IS an NPR.  Or bog standard precursors, depending on whether or not they have populations.

Any NPR or spoiler that gets activated, stays activated, and expands or explores or exploits or exterminates according to its programmed behaviour.  Start a game with an NPR and have that NPR stumble into the Swarm the first month, and by the time your empire finds the Swarm it will have harvested fifty systems.
Title: Re: C# Aurora v0.x Suggestions
Post by: DFNewb on April 13, 2020, 11:17:18 AM
Well, depending on your empire's tech level, Precursors and Swarm and even Invaders can be way less advanced or strong than the player.  They generally don't scale with you.

But -- unless such a race included some weird new tech or other systems -- what you are describing IS an NPR.  Or bog standard precursors, depending on whether or not they have populations.

Any NPR or spoiler that gets activated, stays activated, and expands or explores or exploits or exterminates according to its programmed behaviour.  Start a game with an NPR and have that NPR stumble into the Swarm the first month, and by the time your empire finds the Swarm it will have harvested fifty systems.

Personally I am having a lot of trouble with Precursors in C compared to VB. In VB I would make 10 or so ships with 1 or 2 quad gauss and the precursors couldn't hit me with missiles.

Now missiles move so fast that the tracking can't keep up and it seems like PD is really bad compared to VB and they are wrecking my fleets before they can get into range cause they have like a 10 percent chance to hit now compared to in VB they were hitting like 4/5 shots no problem.

Sightly unrelated but does anyone know if the precursors can "follow" you back to Sol? I had this happen in one of my VB games and I had no combat ships or PDC but with the new STO system I would love to test them out.


Also my suggestion is to either increase turret tracking speed researches or to make missiles slower cause right now they are insane.
Title: Re: C# Aurora v0.x Suggestions
Post by: Steve Walmsley on April 13, 2020, 12:02:16 PM
I'm going to lock this thread so I know everything in it was pre-release