Author Topic: C# Aurora v0.x Suggestions  (Read 345402 times)

0 Members and 2 Guests are viewing this topic.

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Aurora v0.x Suggestions
« Reply #375 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.
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Aurora v0.x Suggestions
« Reply #376 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.
 
The following users thanked this post: Titanian

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: C# Aurora v0.x Suggestions
« Reply #377 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.
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Aurora v0.x Suggestions
« Reply #378 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... .
 
The following users thanked this post: chrislocke2000, El Pip, Kelewan, Titanian

Offline Rich.h

  • Captain
  • **********
  • R
  • Posts: 555
  • Thanked: 55 times
Re: C# Aurora v0.x Suggestions
« Reply #379 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.
 

Offline snapto

  • Bronze Supporter
  • Petty Officer
  • *****
  • s
  • Posts: 27
  • Thanked: 14 times
  • Bronze Supporter Bronze Supporter : Support the forums with a Bronze subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: C# Aurora v0.x Suggestions
« Reply #380 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!
 

Offline Whitecold

  • Commander
  • *********
  • W
  • Posts: 330
  • Thanked: 88 times
Re: C# Aurora v0.x Suggestions
« Reply #381 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.
 
The following users thanked this post: firsal, DIT_grue

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Aurora v0.x Suggestions
« Reply #382 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.
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Aurora v0.x Suggestions
« Reply #383 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.
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Aurora v0.x Suggestions
« Reply #384 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.

 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11649
  • Thanked: 20350 times
Re: C# Aurora v0.x Suggestions
« Reply #385 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).
 

Offline JustAnotherDude

  • Sub-Lieutenant
  • ******
  • J
  • Posts: 114
  • Thanked: 56 times
Re: C# Aurora v0.x Suggestions
« Reply #386 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.
 

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: C# Aurora v0.x Suggestions
« Reply #387 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.
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Aurora v0.x Suggestions
« Reply #388 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
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Aurora v0.x Suggestions
« Reply #389 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... .