Author Topic: C# Aurora Changes Discussion  (Read 447582 times)

0 Members and 5 Guests are viewing this topic.

Offline alex_brunius

  • Vice Admiral
  • **********
  • Posts: 1240
  • Thanked: 153 times
Re: C# Aurora Changes Discussion
« Reply #165 on: October 12, 2016, 05:16:20 AM »
What about the option to turn on/off specific search sensors? Unless I missed something, we only have the option to toggle them all at once right now.

I think that would be helpful. At least the option to toggle low RES sensors ( 20HS or below ) separately from long range / high RES sensors (>20HS). That would allow you to keep your missile/fighter detection running without flipping on the huge emitter announcing your arrival to everyone and their grandmother in system.
 

Offline bean

  • Rear Admiral
  • **********
  • b
  • Posts: 921
  • Thanked: 58 times
Re: C# Aurora Changes Discussion
« Reply #166 on: October 12, 2016, 09:52:32 AM »
Just out of curiosity, is this something you can do in reality? I mean detect if the radar that is tracking your craft is a firecontrol or search radar?
Absolutely.  These days, advanced ESM systems can identify specific emitters, which they can then correlate with a library to figure out exactly which ship they're looking at.  (This is because naval radars are essentially hand-built, so they vary a lot more than, say, merchant navigation radars.)  Even the most basic ESM can tell apart a search radar and a fire control radar.  The two have very different requirements (large area vs precise targeting), which affects what signals the designers choose, and that in turn can be picked up by the ESM system.  Unfortunately, this is an area without a lot of good online sources.

Edit: I am not an expert so some of the above could be wrong
None of it is wrong.

I would like Steve to consider a low probability of intercept (LPI) mode for active sensors.  This would cut the range of the sensor, but cut the radiated power even more.  To some extent, this can be done now by increasing the resolution, but it would be nice to have it as a more explicit design option.
This is Excel-in-Space, not Wing Commander - Rastaman
 

Offline 83athom

  • Big Ship Commander
  • Vice Admiral
  • **********
  • Posts: 1261
  • Thanked: 86 times
Re: C# Aurora Changes Discussion
« Reply #167 on: October 12, 2016, 03:36:13 PM »
To some extent, this can be done now by increasing the resolution, but it would be nice to have it as a more explicit design option.
This can also be done by focusing more on EM sensitivity than Grav-pulse strength. That is one of the better things to do for stealth craft later on in the game. You create a stealthed active sensor with a very high sensitivity but a low pulse strength, increasing range of detection wile lowering emissions.
« Last Edit: October 12, 2016, 03:38:01 PM by 83athom »
Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life.
 

Offline bean

  • Rear Admiral
  • **********
  • b
  • Posts: 921
  • Thanked: 58 times
Re: C# Aurora Changes Discussion
« Reply #168 on: October 12, 2016, 04:54:04 PM »
This can also be done by focusing more on EM sensitivity than Grav-pulse strength.
I'm aware of that, but there are limits on what you can do there.
Quote
That is one of the better things to do for stealth craft later on in the game. You create a stealthed active sensor with a very high sensitivity but a low pulse strength, increasing range of detection wile lowering emissions.
Actually, if you dig through the math, lowering pulse strength doesn't improve the ratio of range to counterdetection range.  The EM sensitivity is applied as a multiplier to your range, so making a bigger sensor with reduced pulse strength gains you nothing over a normal sensor.
This is Excel-in-Space, not Wing Commander - Rastaman
 

Iranon

  • Guest
Re: C# Aurora Changes Discussion
« Reply #169 on: October 12, 2016, 06:44:57 PM »
What you can do though is use big fine-grained sensors - resolution scales linearly with grav pulse strength, but range will only increase by the square root.
At the same EM sensitivity tech, a R100 sensor can be detected at its maximum range by a size-1 passive EM sensor... for an R1 sensor, you'd need a size-10 passive.
 

Offline bean

  • Rear Admiral
  • **********
  • b
  • Posts: 921
  • Thanked: 58 times
Re: C# Aurora Changes Discussion
« Reply #170 on: October 13, 2016, 09:28:39 AM »
What you can do though is use big fine-grained sensors - resolution scales linearly with grav pulse strength, but range will only increase by the square root.
At the same EM sensitivity tech, a R100 sensor can be detected at its maximum range by a size-1 passive EM sensor... for an R1 sensor, you'd need a size-10 passive.
I'm aware of that, and there are two reasons I'd like to see it changed:
1. It makes very little sense to tie radiated power into resolution.  A much more realistic way of doing this is to have radiated power simply equal (Power per HS*Sensor HS).  This would basically flip the ratios around, which is realistic.
2. Big R1s are really expensive.  It would be helpful to have a cheaper way of doing LPI. 
This is Excel-in-Space, not Wing Commander - Rastaman
 

Iranon

  • Guest
Re: C# Aurora Changes Discussion
« Reply #171 on: October 13, 2016, 09:59:39 AM »
I think I like the current system better:
1) There's some trade-offs with space/cost efficiency and emissions
2) Acquiring an active sensor lock at very long ranges without giving yourself away is also very powerful. This should be expensive. An according tech line that works better than the current system (which is self-limiting because low emissions forces large sizes, which may force you into cloaking tech...) would be hard to balance.

Tying radiated power to resolution... my interpretation was that powerful emitters aren't the technical challenge, but that coarse-grained sensors simply allow us to make use of more power where fine-grained ones don't - they'd just pick up more clutter.
 

Offline littleWolf

  • Warrant Officer, Class 1
  • *****
  • l
  • Posts: 76
  • Thanked: 13 times
Re: C# Aurora Changes Discussion
« Reply #172 on: October 14, 2016, 03:48:43 AM »
On latest screensots i see "Commonwealth" and "Japan Empire".

Aurora now have a few separate nations on one planet ?
 

Offline AbuDhabi

  • Sub-Lieutenant
  • ******
  • Posts: 104
  • Thanked: 2 times
Re: C# Aurora Changes Discussion
« Reply #173 on: October 14, 2016, 04:59:03 AM »
You could have that already for a while. That's what the "same system truce" is for.
 

Offline Scandinavian

  • Lieutenant
  • *******
  • S
  • Posts: 158
  • Thanked: 55 times
Re: C# Aurora Changes Discussion
« Reply #174 on: October 16, 2016, 02:58:17 AM »
Since orders in Aurora are sequential, the new refueling rules seem to imply that total time alongside during a port stay would be refueling plus cargo operations, overhauls, etc.

However, it's not clear why replenishing bunker shouldn't happen concurrently with cargo operations, replenishment of stores, minor hot works, etc. In fact, that is how most commercial vessels today operate.

A cleaner solution would be to have a general "port stay" order with options for which activities to perform, and then have those activities being performed concurrently (unless they are mutually exclusive - you probably have to do overhauls and cargo operations sequentially). No idea how much bother it would be to code, but something similar already exists for loading ground units, so I'm guessing it should be feasible.
 

Offline 83athom

  • Big Ship Commander
  • Vice Admiral
  • **********
  • Posts: 1261
  • Thanked: 86 times
Re: C# Aurora Changes Discussion
« Reply #175 on: October 16, 2016, 05:09:10 PM »
You probably don't want to load highly volatile fuels while loading fragile goods and using high power tools to perform maintenance. "Whatever can go wrong, will go wrong"
Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life.
 

Offline sloanjh (OP)

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
Re: C# Aurora Changes Discussion
« Reply #176 on: October 16, 2016, 09:28:46 PM »
If tanker is part of a fleet that it has orders to refuel (i.e. keep topped up), but doesn't have sufficient tech to keep up with fuel usage, the refueling priority should be arranged so that we don't get into a situation where a high priority ship has full tanks after a while a low priority ship in the same fleet is empty.

Suggestion for a different way to handle unrep:  Calculate total fuel burned for the increment by the entire fleet, then calculate the percentage of that which is offset by unrep and apply that percentage to each ship.  So if a fleet burned 50,000 units of fuel in an increment, and had unrep capacity for 40,000 units, then 80% of each ship's fuel consumption would be offset by unrep and each ship would burn fuel at 20% of its unmodified rate.  Note that the interaction of this and the "refuel subfleet" might be a little complicated, so you might need to restrict or eliminate that order.

John
 

Iranon

  • Guest
Re: C# Aurora Changes Discussion
« Reply #177 on: October 17, 2016, 04:51:50 AM »
I'm quite wary of the refueling changes.

Making ships that are far too thirsty for no tangible gain is an extremely common design mistake, now one is punished harder for it.
Now it's reasonable to design ships for the utmost fuel efficiency possible for given speed requirement and tech (and aiming low with speed requirements unless essential to the role), rather than making a conscious trade-off versus build cost or compactness... because designing them so we can mostly ignore fuel logistics saves considerable investments elsewhere as well as headaches.

It seems a set of changes that, while mechanically complex,could easily reduce depth ("playing around it entirely is the best option" -> fewer legitimate options while the interesting ramifications end up ignored).
 

Offline alex_brunius

  • Vice Admiral
  • **********
  • Posts: 1240
  • Thanked: 153 times
Re: C# Aurora Changes Discussion
« Reply #178 on: October 17, 2016, 05:33:05 AM »
I think it will be quite interesting to see how the refueling and rearming changes actually turns out in practice.

But based on what has been written I for one look forward to needing several tankers and forward bases to sustain the logistics of more rapid refueling and operations of larger fleets with more fuel-hungry ships.


And I doubt there will be severe issues with tankers keeping up with underway refueling unless you got extreme situations like a single tanker for a huge fleet ( in which case you'll need more tankers anyways ) or ship designs that burn through all their fuel in less then a few days ( these belong in hangars anyways ).

As stated in the changes list you'll be able to refuel up 50k liters per hour ( 1.2 million per day ) without tech, and with a few fairly cheap tech we are likely to see a ~30% underway replenishment * a base rate of around 150k liters per hour, which allows you to get similar numbers from an underway refueling tanker. Even if you design a fuel-hungry warship it will probably not go through more then a million liters fuel in 20 days, so you could still keep a fleet of 20 such ships fully topped up with fuel from a single underway refueling tanker. And if there is an issue with falling behind you can just halt the fleet a few hours to allow the tanker to catch up (stationary using full refueling amount).


Being able to load ammo and cargo in parallel to refueling might make sense and be nice, but I don't see it as a huge issue if it can't be done. For gameplay you could probably find a middle ground where times of each action are not half but also not 100% of total downtime you want, but somewhere in-between. It's also far from given that all these actions in reality can be fully done in parallel or are always done fully in parallel.

Especially when you have bigger fleets of ships it doesn't makes sense they can all be re-armed and re-fueled at the same time even on bigger ground bases, so the final total time we end up with will probably feel in the right ballpark anyways.
« Last Edit: October 17, 2016, 06:06:03 AM by alex_brunius »
 

Offline 83athom

  • Big Ship Commander
  • Vice Admiral
  • **********
  • Posts: 1261
  • Thanked: 86 times
Re: C# Aurora Changes Discussion
« Reply #179 on: October 17, 2016, 07:14:21 AM »
Making ships that are far too thirsty for no tangible gain is an extremely common design mistake, now one is punished harder for it.
Now it's reasonable to design ships for the utmost fuel efficiency possible for given speed requirement and tech (and aiming low with speed requirements unless essential to the role), rather than making a conscious trade-off versus build cost or compactness... because designing them so we can mostly ignore fuel logistics saves considerable investments elsewhere as well as headaches.
I think that is the point of this change. Its to add a greater complexity if you want to continue to build the small designs that skimp on fuel because you could just lug around a small tanker with you.
Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life.