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

0 Members and 3 Guests are viewing this topic.

Offline SpikeTheHobbitMage

  • Warrant Officer, Class 1
  • *****
  • S
  • Posts: 75
  • Thanked: 4 times
Re: C# Aurora v0.x Suggestions
« Reply #360 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.

 
The following users thanked this post: Rye123, Agoelia

Offline alex_brunius

  • Rear Admiral
  • **********
  • Posts: 984
  • Thanked: 36 times
Re: C# Aurora v0.x Suggestions
« Reply #361 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 ).
 

Offline Whitecold

  • Lt. Commander
  • ********
  • W
  • Posts: 273
  • Thanked: 59 times
Re: C# Aurora v0.x Suggestions
« Reply #362 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.
 
The following users thanked this post: SpikeTheHobbitMage, Triato, DIT_grue, Titanian, Agoelia

Offline Triato

  • Warrant Officer, Class 2
  • ****
  • T
  • Posts: 57
  • Thanked: 2 times
Re: C# Aurora v0.x Suggestions
« Reply #363 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.
 
The following users thanked this post: Agoelia

Offline Profugo Barbatus

  • Chief Petty Officer
  • ***
  • P
  • Posts: 39
  • Thanked: 6 times
Re: C# Aurora v0.x Suggestions
« Reply #364 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.
 

Offline DIT_grue

  • Lieutenant
  • *******
  • D
  • Posts: 156
  • Thanked: 19 times
Re: C# Aurora v0.x Suggestions
« Reply #365 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 rules? Because at first glance this suggestion looks seriously imbalanced in that context, to the extent of undercutting stated design goals.
 

Offline alex_brunius

  • Rear Admiral
  • **********
  • Posts: 984
  • Thanked: 36 times
Re: C# Aurora v0.x Suggestions
« Reply #366 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.
 

Offline SpikeTheHobbitMage

  • Warrant Officer, Class 1
  • *****
  • S
  • Posts: 75
  • Thanked: 4 times
Re: C# Aurora v0.x Suggestions
« Reply #367 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 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.
« Last Edit: July 19, 2018, 08:49:44 PM by SpikeTheHobbitMage »
 

Offline ardem

  • Commodore
  • **********
  • a
  • Posts: 774
  • Thanked: 17 times
Re: C# Aurora v0.x Suggestions
« Reply #368 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.



 
The following users thanked this post: QuakeIV, SpikeTheHobbitMage, El Pip, Alucard

Offline TMaekler

  • Captain
  • **********
  • Posts: 423
  • Thanked: 55 times
Re: C# Aurora v0.x Suggestions
« Reply #369 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.
 
The following users thanked this post: SpikeTheHobbitMage, Titanian

Offline TMaekler

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

 

Offline SpikeTheHobbitMage

  • Warrant Officer, Class 1
  • *****
  • S
  • Posts: 75
  • Thanked: 4 times
Re: C# Aurora v0.x Suggestions
« Reply #371 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.
 

Offline Alucard

  • Leading Rate
  • *
  • A
  • Posts: 10
Re: C# Aurora v0.x Suggestions
« Reply #372 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.
 

Offline joeclark77

  • Commander
  • *********
  • j
  • Posts: 347
  • Thanked: 1 times
Re: C# Aurora v0.x Suggestions
« Reply #373 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.
 

Offline Whitecold

  • Lt. Commander
  • ********
  • W
  • Posts: 273
  • Thanked: 59 times
Re: C# Aurora v0.x Suggestions
« Reply #374 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.
 

 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54