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

0 Members and 3 Guests are viewing this topic.

Offline the obelisk

  • Sub-Lieutenant
  • ******
  • t
  • Posts: 109
  • Thanked: 11 times
Re: C# Aurora v0.x Suggestions
« Reply #1305 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.
 
The following users thanked this post: alex_brunius

Offline totos_totidis

  • Chief Petty Officer
  • ***
  • Posts: 32
  • Thanked: 3 times
Re: C# Aurora v0.x Suggestions
« Reply #1306 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.
 

Offline Garfunkel

  • Registered
  • Admiral of the Fleet
  • ***********
  • Posts: 2781
  • Thanked: 1048 times
Re: C# Aurora v0.x Suggestions
« Reply #1307 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.
 

Offline Borealis4x

  • Commodore
  • **********
  • Posts: 717
  • Thanked: 141 times
Re: C# Aurora v0.x Suggestions
« Reply #1308 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...
« Last Edit: August 04, 2019, 01:53:07 AM by BasileusMaximos »
 

Offline Hazard

  • Commodore
  • **********
  • H
  • Posts: 643
  • Thanked: 73 times
Re: C# Aurora v0.x Suggestions
« Reply #1309 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.
 

Offline the obelisk

  • Sub-Lieutenant
  • ******
  • t
  • Posts: 109
  • Thanked: 11 times
Re: C# Aurora v0.x Suggestions
« Reply #1310 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.
 

Offline Scandinavian

  • Lieutenant
  • *******
  • S
  • Posts: 158
  • Thanked: 55 times
Re: C# Aurora v0.x Suggestions
« Reply #1311 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.
 

Offline Desdinova

  • Lt. Commander
  • ********
  • D
  • Posts: 280
  • Thanked: 280 times
Re: C# Aurora v0.x Suggestions
« Reply #1312 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.
 
The following users thanked this post: papent

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Aurora v0.x Suggestions
« Reply #1313 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.
« Last Edit: August 05, 2019, 11:06:30 PM by QuakeIV »
 

Offline totos_totidis

  • Chief Petty Officer
  • ***
  • Posts: 32
  • Thanked: 3 times
Re: C# Aurora v0.x Suggestions
« Reply #1314 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.
 

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2822
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1315 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.
« Last Edit: August 07, 2019, 06:04:02 PM by Jorgen_CAB »
 
The following users thanked this post: Garfunkel, Scandinavian

Offline SevenOfCarina

  • Lieutenant
  • *******
  • Posts: 170
  • Thanked: 95 times
Re: C# Aurora v0.x Suggestions
« Reply #1316 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)
 

Offline Doren

  • Sub-Lieutenant
  • ******
  • D
  • Posts: 137
  • Thanked: 34 times
Re: C# Aurora v0.x Suggestions
« Reply #1317 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?
 

Offline Steve Walmsley

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

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2822
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1319 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.