Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - alex_brunius

Pages: [1] 2
1
Aurora Suggestions / Re: Bringing Back Mothballing
« on: November 13, 2017, 06:20:40 AM »
What the heck is mothballing?
I've done a quick search but Google had no satisfactory answer.

https://en.wikipedia.org/wiki/Mothballing

( Aircraft boneyard and Reserve fleet are relevant entries to this use of the word ).
The following users thanked this post: Seolferwulf

2
C# Aurora / Re: Replacing PDCs
« on: October 26, 2017, 08:35:25 AM »
For C# Aurora, a ground 'unit' will be an individual soldier or vehicle, while a group of units will be a 'formation', although you will be able to name formations as companies, battalions, etc..

...

Each individual unit within a formation will fortify separately, so there is no problem fortifying a formation that includes infantry, static and vehicles.

In terms of combat mechanics, units will fire at units, using the chance to hit...

Is it really wise to use individual soldiers from a performance & database size perspective?

If numbers are similar to current we could be looking at upwards to 50000 soldiers if not more per side that all need to have individual fortification, individual hit chance / fire rolls / targeting and so on.

I don't think you would lose out much by reducing the scale to squads of 10 soldiers or companies of 100 soldiers which are modeled as the smallest infantry "unit", at least for purposes of calculation ( even if you can track individual casualties in more detail if you want ).


Something else which isn't totally clear is how vehicle crew will be handled ( if at all ).
The following users thanked this post: obsidian_green

3
C# Aurora / Re: Replacing PDCs
« on: October 25, 2017, 10:39:22 AM »
Apologies if this has already been covered.   I usually build PDC's at new colonies as a quick and easy way to keep unrest under control.   If I remember correctly, ground troops do  not have a Population Protection Value so they can only reduce, not prevent unrest.  If PDC's go away, will ground forces get some sort of PPV?

Since PPV seems to represent the ability to defend against enemy spaceships it would make sense to give ground forces that can fire at orbiting spaceships the same PPV that identical firepower from other sources ( like PDC or a space station ) would have.
The following users thanked this post: DIT_grue

4
C# Aurora / Re: Replacing PDCs
« on: October 20, 2017, 05:46:16 AM »
On the other hand Marski, if you are tossing ground detonation nukes around in such numbers that the fireballs overlap you can be fairly confident that whatever formation existed there does so no longer.

It quickly becomes a problem of math and economics...

Earth has a total surface land area of ~150 million km^2.

Submarine launched nukes are often considered the upper border of what would be a "tactical" nuke, so let's take one of the most common (W-76) in the US/UK arsenal. It has a fireball radius of 500 meters when detonating on the ground meaning the fireball covers an area of 0.79 km^2.
( Source: https://nuclearsecrecy.com/nukemap/ )

You would need to drop around 200 million such nukes to cover the entire land surface of the Earth and ensure you wipe out all hiding & dug in spread out infantry.

Even if you use an airburst and the larger air blast radius ( resulting in universal injuries and widespread fatalities for exposed & unprotected, but most dug in infantry probably survives ) we get 33.5km^2 area covered and around 5 million warheads needed to cover the surface of the earth.


See the problem?
The following users thanked this post: 83athom

5
C# Aurora / Re: Replacing PDCs
« on: October 19, 2017, 07:41:40 AM »
Actually, if you are tossing around lasers with similar energy delivery profiles as a nukes you are basically nuking the planet anyway. You just don't use an actual nuclear warhead to make the kiloton and up explosions happen.

This means you can actually destroy a defending force to the last with orbital laser bombardment alone, just keep in mind the collateral. Because, you know, kiloton range explosions and up are pretty bad at only hitting targets smaller than a city. Usually everything around it also dies.

This assumes that your nuke can deliver 100% of it's energy directly into the ship ( like a laser would ), and that your laser suffers zero energy reduction from a planets atmosphere on it's way down towards the target ( like a nuke would ).

If nukes in space deliver for example just 1% of their energy into the ship ( proximity hit around ~1 ship length away ) while a laser delivers 100%, and if the atmosphere reduce laser energy by say 90%, then what we are looking at is a laser impact with same damage vs space ships transferring 1000 times less energy delivered into a ground target then a nuke.

( At also assume that the energy from shockwave and heat in the nuke is as damaging as the energy from a beam weapon ).



Regardless of what values you use I think it's safe to say that beams deliver several times less total energy, especially when firing at a planetary surface target, then nukes even if they do the same damage against a spaceship.
The following users thanked this post: 83athom

6
C# Aurora / Re: Replacing PDCs
« on: October 03, 2017, 05:18:32 AM »
Agree on the re-designation of combat walker. Some type of super-heavy vehicle designation makes sense.

Isn't walker / vehicle distinction something that could be a design option instead?

Vehicles would be superior in flat terrain and have better max speed, while walkers perform better in rough terrain giving you a more consistent speed. Then the very large vehicles/walkers both carry 3 component slots regardless of method of propulsion.

This would also allow you to reduce complexity a bit since ARM level for Vehicles & Walker types overlap.

Something like this (instead of the 7 you proposed with overlapping ARM levels):

Scout Vehicle/Walker - ARM 2 - 2 slots ( maybe even 1 slot? )
Light Vehicle/Walker - ARM 4 - 2 slots
Medium Vehicle/Walker - ARM 6 - 2 slots
Heavy Vehicle/Walker - ARM 9 - 3 slots
Super-Heavy Vehicle/Walker - ARM 12 - 3 slots

This also allows you to make a total of 10 different vehicles+walker variants.


Transport will be either infantry or vehicle (inc aircraft). In this case I am assuming that 'ground-based' aircraft are more like armoured helicopters (Mi-24) than high-flying jets (mainly because in many cases there would be no atmosphere anyway). Infantry transport will be the existing troop transport bays and combat drop modules. I will add vehicle equivalents.

It would make sense to have a shared bay for all vehicles/walkers/aircraft yeah, they require pretty similar bulk storage for transport I would say. In fact I dislike all the splitting up of "cargo" into special roles going on in Aurora 4x. Why not just have a single Cargo bay that I can put whatever I want in, be it maintenance supplies, vehicles, building parts or minerals? Or maybe 2 types, pressurized and unpressurized.

Looking at current armies they airlift in everything they need from infrastructure to tanks and troops using pretty much the same ( or very similar ) bulk cargo planes.

A few more things to think about surrounding aircraft implementation. Can they go in Hangars? Do they really need drop pods/modules? How would they interact with space based fighters? ( Maybe they get attack bonus vs space based fighters doing ground support role, and space based fighters can provide ground support without needing "Orbital Fire Support Controller" + be hit by AA? )


Ground combat will now take place in the same time frame as ship combat, with each unit firing at specified intervals (except that time won't slow for ground combat - it will instead run multiple cycles depending on turn length). It will still take a while for ground combat though as hit chances will be very low.

Please keep in mind that real war is 99.9% waiting and 0.1% of terror when doing firing times. It would be sweet to have epic campaigns stretching for months or years.

Could intensity maybe be scaled by planet size in some way so that assaulting say large massive jungle planets are year long affairs soaking of huge number of units while landing on a small 10km mining asteroid can be over in a day?

Something else to consider tied to planet size is how do you defend your rear echelon if you land with say 3 units of tanks on a huge planet and order them to take it over? Basically you can't, right?

So maybe there is a need for some kind of "width" for how many units needed to cover the front and prevent breakthroughs, and an inherit advantage to a defender which can move more unhindered through known terrain if the attacker over-extends or can't cover the front (guerrilla defense).
The following users thanked this post: DIT_grue

7
C# Aurora / Re: Replacing PDCs
« on: September 19, 2017, 04:06:18 AM »
My main concern here is that this will greatly change the timespans involved and troop needs for ground invasions. Most beam weapons fire every 5-30 seconds and have infinite ammo, while ground combat updates on the 5 day cycle, so after around 86400 such 5 second pulses.

No matter how much the orbital bombardment hitchance is reduced by ground unit concealment any sufficiently large beam fleet will be able to precision wipe out 100% of the defending ground units in very short order, meaning all ground units any attacker needs will be for garrisoning purposes.


Real campaigns like Vietnam, Afghanistan and Iraq have taught us that no matter how much superior firepower you have, that is not how reality works. Boots on the ground are always a must.


What I propose to resolve this is the following balance:

  • New beam FC component added "Orbital bombardment Firecontrol", which enables aiming and firing beams on ground units
  • New techline added "Orbital bombardment sensors & firecontrol" that gradually increase Orbital bombardment precision stat
  • Mechanics: Only ground units with heavy weapons for firing on space ships can be 100% destroyed by orbital bombardment, but when destroyed by bombardment their cadre survives ( making them faster to rebuild )
  • Mechanics: Maximum damage possible to inflict on all other ground units is based on a comparison between orbital bombardment and concealment stats. High bombardment vs low concealment might result in being able to reduce unit morale and readiness by 80% while the reverse situation could reduce them by just say 20%. Equal tech level results in for example 50% damage cap


This should ensure that bombardment can neutralize ground-space weapons, as well as support ground assaults, but not remove the need of ground assaults entirely.

If you want to make a more accurate and detailed model then the land surface area as well as vegetation & animal life (biosphere) and tectonics could influence how easy it is to conceal units. Hit chance reductions could also help ground-space weapons inflict disproportional damage on bombarding warships before they can be destroyed/knocked out.
The following users thanked this post: Gyrfalcon, DIT_grue

8
C# Aurora / Re: C# Aurora Changes Discussion
« on: July 10, 2017, 02:10:59 AM »
Quote from:    Steve Walmsley
As missiles (for now anyway), don't have thermal reduction or an option to travel below maximum speed, their thermal signature is equal to the power of their engines. Combined with the changes to passive detection, this means that missiles in C# Aurora will probably be detected by thermal sensors at much greater distances than in VB6 Aurora.

Hmm. I wonder if you could make an effective passively guided AMM after this change?

With all the changes to Thermal and EM emissions as well as these being serious ways to guide missiles now it really feels like we need some way for Missile Fire Controls to fire on calculated interception points of target and relying on missiles picking up their emissions once close enough.

Doing that math and geometry by hand every time while possible is going to be pretty frustrating.

This way of playing could also could support making missile design even more interesting and deep. Maybe a 0.1 MSP component to enable a search pattern or loitering if missiles find nothing at their destination as well (continuing until out of fuel), or Friendly Fire risk for passively guided missiles unless you equip a 0.1 MSP IFF component to missiles.
The following users thanked this post: Titanian, superstrijder15

9
C# Aurora / Re: Aurora C# Screenshots
« on: July 06, 2017, 04:49:38 AM »
It's not that counter intuitive. Turret armour is extra hardening of the turret, armour in Aurora is all ablative anyway.

It's counter intuitive that the turrets which are external and outside of any armor belt, citadel or protection on all real warships is put underneath it in Aurora.

It's counter intuitive that the same identical turret design when I put it on my battleship with 15+ armor layers is super hard to knock out while if I put it on my unarmored scout it is super easy to knock out.


I realize that it's a simplification, but I still would love to see some more detail with separate ablative armor boxes for turrets, for outer hull and for inner thicker armored citadel ( I don't care about my crew quarters or fuel storage, but might want the engine, powerplants and ammunition under extra layers of ablative armor ).
The following users thanked this post: MagusXIX

10
One can probably use SM to make new commanders, then rename them and maybe even give them the same attributes, but this would be a lot simpler.

AFAIK you sadly can't SM commander attributes :(
The following users thanked this post: superstrijder15

11
Regarding NPR Tactics what I feel is important is to give the AI a basic sense of tonnage/threat and not mindlessly throw ships away.

This is done by estimating a few things:

- Technology of an enemy can be estimated by comparing the speed of enemy ships & missiles observed to those of your own.

- Estimating how offensive your ships are based on previous encounters weight of missile/beam fire or salvage results ( scoring their threat from for example 0.2 to 3.0 based on how much tonnage they have dedicated to weapon systems and how deadly the salvo fire is ).

- Total tonnage of an enemy fleet can be estimated by knowledge of their known ships and amount ( If the NPR have observed you having a total of five 10k ton ships and fifteen 2k ton ships previously it will estimate your fleets to be worth 16k ton "threat" for each 10k ton ship it observe even before it's sensors can detect a 2k ton signature ).


A practical example:

The AI is observing an enemy fleet made up of eight 20k ton warships approaching in one of it's systems and is tracking it on resolution 160 actives from a long range scout.

Based on a speed advantage of 15% the fleet is estimated to be 1 TL above the AI and as such is given a x1.15 multiplier in perceived "threat". Based on previous encounters the fleet has been observed to be fairly balanced with a bit of offensive focus, so it's given a x1.3 multiplier in perceived "threat". Based on a total of known enemy ships  (108x 4k ton screens, 16x 20k ton warships and 12x 12k ton warships), combined with the fact that the actives can detect any warships larger then 8k ton in the fleet, the fleet approaching is estimated to consist of 8x 20k ton warships and 37x 4k ton screens (160k ton observed / 464k known tonnage that should be observable = fleet is estimated to be composed of 34.5% of the enemy empires warships ). This gives the enemy fleet an estimated calculated tonnage of 308k tons, which is multiplied by x1.15 and x1.3 for technology and offensive firepower. The AI NPR thus judges that it will need to amass at least 460k tons of own warships in a single fleet to be able to meet the threat. This could further be multiplied by the inverse of the racial aggressiveness scoring, such that an aggressive/reckless race can attack with less and a defensive race will want more just to be safe.

If the AI can meet or exceed the fleet size needed (without leaving colonies without defense), it tries to gather the fleet and engage. If not it tries to get as close as it can and defend either the next jump point (if possible to beat the enemy fleet to it), or the closest / likely targeted colony the enemy fleet is approaching.
The following users thanked this post: lordcirth

12
Aurora Suggestions / Re: Considering Changes to Terraforming
« on: January 04, 2017, 03:35:08 AM »
This may be an uninformed question.  However, if small planetary bodies (e.g., moons of sufficient size) are faster to terraform than large planetary bodies (e.g., a planet like Mars), then why would the player bother terraforming large planetary bodies short of minerals?

Is there a correlation between the size of the planetary body and mineral generation or accessibility?

Pretty sure larger body = higher chance of more minerals in 7.1 Aurora

If there a maximum population that a planetary body can hold based on size?

Not in 7.1 Aurora.

But I think you make an excellent point.

What if each body had a "population capacity" which is based on available surface area - hydrosphere coverage. Any population above this would basically count as requiring colony cost 1 infrastructure to not have population growth halt or turn negative.

This would make it worth it to terraform larger bodies I think.



Another related thing I posted previously in suggestions a few years ago is that it would make sense if the population capacity would not reach max until you reached optimal conditions. Right now there is no point in keeping terraforming temperature/oxygen once you crossed the absolute minimum required point, which kind of doesn't make sense... ( in reality each person have a different tolerance and some areas of the planet would be warmer/cooler higher/lower oxygen to suit your needs ).

What would be really cool is if when you reached the minimum tolerance, "population capacity" started growing from 0, linearly up towards the maximum which is achieved when oxygen, temperature and such reach the optimal value.
The following users thanked this post: Demonides

13
C# Aurora / Re: C# Aurora Changes Discussion
« on: December 19, 2016, 06:27:35 AM »
Restricted fuel would not be too bad in a classic Sol start with no other NPRs on Earth. However I found in v6.43 if there are NPRs on Earth with the player race then while you can beat them to the first jump, to beat them the second is very difficult unless you sink all your tech points into fuel economy techs. Additionally the NPR exploration ships keep going and unless they run into something unpleasant youi can not catch them.
Ian

Couldn't there be some simple range limit at least in place to keep NPRs within reasonable ranges? For example NPRs are not allowed to enter JPs further away then X% of their max range from closest friendly colony? ( X being around 30-50% ).
The following users thanked this post: palu

14
I wouldn't use something like this in any of my games. To exploity and to much micro design/missiles needed for me.
The following users thanked this post: Knuckles2095

15
C# Aurora / Re: C# Aurora Changes Discussion
« on: October 21, 2016, 02:23:47 AM »
Just for simplicity. It would be extra work without extra game play if players had to know the tonnage limit for every different system body. The same applies to terraforming (at the moment anyway) with the size of the body not affecting the amount of atmosphere required.
The math doesn't really work that way.  It's a lot more complicated, depending on the nature of your launch system.  I'd suspect that the infrastructure is going to dominate in most of Aurora, not the physical payload of the shuttles themselves.

Alot of stuff in Aurora have math that "doesn't really work that way" in reality  ::)

Even with the TN technobabble Aurora is not really modelling economy of scale except for warship armor for example. And I'm thankful because it would be a pain to calculate and estimate for example factory output or infrastructure needs if they used a non-linear formulas instead.

My point was that if shuttles are worth the effort of adding they should be a meaningful constraint, and as such having gravity impact their efficiency in a linear way ends up closer to reality then it having zero impact does.


To be honest I feel that Steve is missing a big opportunity in Aurora to have the planets feel unique and special when he is hesitating to use their gravity, surface area and other properties in as much of the game mechanics as possible.

I think it would help alot to make the game more immersive and tell interesting stories if you didn't just terraform planet #20 in a long row of planets that in game mechanics feel identical to eachother until it also can sustain infinite population, but if you actually had to spend 5 times as long time to terraform the planet due to it's larger surface area, and in return it could sustain 4 billion instead of the 300 million the smaller moon can sustain, but as a tradeoff the large size and gravity put extra requirements on your shuttle needs.
( just example numbers )

I'm sure there are many other areas and game mechanics where the same concept could be expanded into like:
  • Planets with larger surface areas and larger biospheres could slow down ground combat resolution ( harsh fighting for years on the huge planet with endless jungles )
  • On low gravity bodies assembling PDCs might be much easier
  • A large amount of water/hydrosphere might reduce the surface area you can live on without infrastructure
  • Certain planets could have other unique traits or economical bonuses ( similar to the research anomalies )

The following users thanked this post: hiphop38, palu

Pages: [1] 2