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

0 Members and 1 Guest are viewing this topic.

Offline Borealis4x

  • Commodore
  • **********
  • Posts: 717
  • Thanked: 141 times
Re: C# Aurora Changes Discussion
« Reply #600 on: March 25, 2017, 09:03:39 PM »
Still don't see why lightspeed has to be taken into account for weapons made of materials that already break physics when put together right.
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Aurora Changes Discussion
« Reply #601 on: March 25, 2017, 09:14:43 PM »
I don't see why you can't just model it like flak, where you are spamming shots in their general direction and trying to score hits.  I can understand not wanting tracking laser projectiles, but you could just delay the application of laser damage and then say that any of the enemies movements was accounted for in the statistical models used to target the laser shots.  Its not like most ships at laser range are going to be moving particularly large distances anyways, except at the super high techs.
 

Offline Hazard

  • Commodore
  • **********
  • H
  • Posts: 643
  • Thanked: 73 times
Re: C# Aurora Changes Discussion
« Reply #602 on: March 25, 2017, 09:55:38 PM »
I don't see why you can't just model it like flak, where you are spamming shots in their general direction and trying to score hits.  I can understand not wanting tracking laser projectiles, but you could just delay the application of laser damage and then say that any of the enemies movements was accounted for in the statistical models used to target the laser shots.  Its not like most ships at laser range are going to be moving particularly large distances anyways, except at the super high techs.

Matter of volume the fire needs to cover. In WW2 aircraft usually didn't travel faster than 180m/s, and tended to fire several rounds per second for the smaller guns. And they missed, rather often at that. I don't have the numbers on hand, but even with proximity fuses several hundred shots were fire for every hit at minimum.

Aurora spaceships move faster. In fact, a ship going at 180 000m/s is pretty slow. They are much more massive and as such also a lot larger than WW2 aircraft, but the sphere they could've changed course to is even larger by a much greater margin. And unlike WW2 shells, you have to hit, as a proximity fuse for lasers and particle beams doesn't exist, and your rail guns are dumbfire unguided weapons. And rather more importantly, even on a big ship you aren't going to be mounting a whole lot of these guns, and the best rate of fire you could theoretically get is the rail gun's 4 shots every 5 seconds.
 

Offline mrwigggles

  • Sub-Lieutenant
  • ******
  • Posts: 138
  • Thanked: 1 times
Re: C# Aurora Changes Discussion
« Reply #603 on: March 25, 2017, 11:49:20 PM »
Still don't see why lightspeed has to be taken into account for weapons made of materials that already break physics when put together right.
The materiel are exotic, the particles aren't. A laser is coherent wavelength of light, of photons. Photons still obey relativity.  This though means that you could make a superliminal railgun, if you made the slugs it throws out of tn materiel. Though right now, the slugs that railgun throw are 'free', presumably because they're composed out of mundane materials. And if you made the slugs out of TN materiel, you would need to account for them, in a similar fashion to missiles. 
 

Offline TheDeadlyShoe

  • Vice Admiral
  • **********
  • Posts: 1264
  • Thanked: 58 times
  • Dance Commander
Re: C# Aurora Changes Discussion
« Reply #604 on: March 26, 2017, 12:35:59 AM »
There's just no way you can beat a guided, self propelled projectile for anything resembling a realistic space weapon.  increasing beam weapon range - besides the realism problems - won't do much, because they will still be dunked by missiles. 

Missile v beam balance is very complicated, because there is a metagame with missile size/range/launcher size reduction.  Smaller missiles are much better at penetrating defenses, *particularly* beam defenses.  Their primary downside is typically lesser range, which means that despite better performance overall you might lose anyway if you're bombarded from beyond your ability to respond.

There's also that as of the engine rule revision, railguns have become dramatically high performers in terms of missile pd (anomalously so). which distorts efforts to compare.

I do think overall missiles are a bit too much better than beams, in that a close range missile combatant (i.e. an AMM vessel) is usually superior to a beam warship.  I also think that strategically, missiles are still better than beams;  it's much cheaper and easier (on a build point to build point basis) to replace expended missiles than it is to replace the beam warships you will lose when you are at a disadvantage in the missile fight.  Missiles do place a greater stress on Gallicite, but beam warships typically have very expensive engines anyway.  I find that beams advantage is usually tactical - when the missiles run out, the fleet with better beam performance wins the battle. 

My own personal Modest Proposal on beams v missiles is rather complicated.

1.)  Eliminate final fire PD. Beams can only be used for area PD. Any weapon type can be used in designing CIWS, possibly excepting microwaves and mesons.  Slightly extend basic beam weapon/fire control ranges, particularly at lower tech levels.
2.)  Apply principles of diminishing returns to active sensors, dramatically reducing their possible ranges.  (The ideal is that a fleet benefits from using pickets more so than scaling all sensors up to size 50, as tends to happen when optimizing.)
3.)  Reduce the basic engine power multiplier bonus of missiles.  Adjust multiplier tech for both missiles and engines so it is more of a gradual curve.  This may necessitate adjustments to the tracking speed mechanic.
4.) Make reload speed for missiles less linear with size; a TL3 size 1 standard launcher might have 20-30s reload time, whereas a size 10 might only be 60-70s.  The idea would be to make missile defenses more about capability (like beams) and less about magazine size.
5.) Missile decoys - give missiles an ecm capability to produce false missiles, which protect the real salvo. would work sort of like HTK.  Could replace missile armor.   A salvo of 10 missiles with a decoy rating of 1 would give an incoming hit a 50/50 chance of hitting a decoy rather than a missile; hits on a decoy reduce the decoy value, and striking a real missile would also eliminate its decoys.

et cetera.
 

Offline Bremen

  • Commodore
  • **********
  • B
  • Posts: 743
  • Thanked: 150 times
Re: C# Aurora Changes Discussion
« Reply #605 on: March 26, 2017, 01:55:46 AM »
Well, if we're going for it, my modest proposal for making beams a viable alternative to missiles:

1) Halve all non-conventional engine and fire control tracking speeds, across the board. If this makes logistics a problem, also reduce cargo holds and non-mineral cargo sizes by 60% (ie, cargo hold and construction factory both change from 25,000 tons to 10,000 tons). Accuracy would be unchanged, but it would be effectively doubling beam range as targets would move through that range slower.
1b) If that's not enough, rebalance fire control ranges to be longer. Keep the cap at 1.4m km, but make it so that's reachable at about the middle to middle-late part of the tree, and after that you're just improving accuracy at 1.4m km.
2) Require all missiles to have at least one layer of armor like ships do (making smaller missiles trickier), but missile armor scale with armor tech. Edit: To clarify, the one layer of armor would be the 1 hp missiles have now, not make them harder to destroy.
3) Final Fire PD should work like AMM PD (and I think area PD?); all weapons in an increment pick a target, then roll to hit. This makes PD more random, leakers more common, and incentivizes multiple layers of PD (AMM -> Area PD -> Final Fire PD). Turns good PD into damage mitigation rather than damage negation.
4) Add some sort of E-War system or non-conventional beam weapon that has a chance to temporarily disable engines and always has a range of 1.4m km (max beam range). This eliminates the issue of "kiting" an enemy while firing beam weapons from outside their range.

It isn't really related to the change but I do really like the diminishing returns to active sensors idea.
« Last Edit: March 26, 2017, 03:23:49 AM by Bremen »
 

Offline Gyrfalcon

  • Bug Moderators
  • Commander
  • ***
  • G
  • Posts: 331
  • Thanked: 199 times
Re: C# Aurora Changes Discussion
« Reply #606 on: March 26, 2017, 02:50:49 AM »
On a different topic, I realized yesterday that the new maintainence rules will heavily penalize carrier-based play because fighters are counted twice for the maintainence tonnage - once as the needed hanger space on the carrier itself, and a second time for the fighter's own tonnage.
 

Offline Bremen

  • Commodore
  • **********
  • B
  • Posts: 743
  • Thanked: 150 times
Re: C# Aurora Changes Discussion
« Reply #607 on: March 26, 2017, 02:53:33 AM »
On a different topic, I realized yesterday that the new maintainence rules will heavily penalize carrier-based play because fighters are counted twice for the maintainence tonnage - once as the needed hanger space on the carrier itself, and a second time for the fighter's own tonnage.

Fighters aren't maintained by maintenance facilities. For that matter, any ships in a hangar normally aren't either.
 

Offline Gyrfalcon

  • Bug Moderators
  • Commander
  • ***
  • G
  • Posts: 331
  • Thanked: 199 times
Re: C# Aurora Changes Discussion
« Reply #608 on: March 26, 2017, 03:06:31 AM »
Under the new rules, they will be, and the rules don't say anything about ships in hanger not counting towards the maximum tinnage under maintainence cap.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11649
  • Thanked: 20350 times
Re: C# Aurora Changes Discussion
« Reply #609 on: March 26, 2017, 06:38:23 AM »
Under the new rules, they will be, and the rules don't say anything about ships in hanger not counting towards the maximum tinnage under maintainence cap.

Ships in hangars still won't require maintenance.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11649
  • Thanked: 20350 times
Re: C# Aurora Changes Discussion
« Reply #610 on: March 26, 2017, 07:13:04 AM »
With regard to the various missiles vs beams ideas:

1) Increased beam range. I am reluctant to increase beam range significantly. The main reason is that currently faster ship plus longer-range beam vs beam opponent = instant win. if we make any major change to beam range, that will mean longer range beam (even when slower) vs beam ship = instant win, because the faster ship with shorter-range weapons will be destroyed before it can close the (increased) range.

2) Reduced overall speeds for missiles and ships (and reducing tracking speeds). This also creates the above problem, but by changing speed rather than range.

3) I like the idea of removing the link between missile size and reload time, or at least significantly reducing the impact, as this will negate some of the advantages of smaller missiles.

4) Also like the idea of some type of missile frame that would favour larger missiles (more frame overhead for smaller missiles), although this might impact the effectiveness of AMMs in the anti-missile mode. I guess one option would be to allow fractional missile launcher sizes so you could use missiles of size 1.2 for example.

5) I am happy to remove the distinction in the power curve between missiles and normal engines. From a consistency POV, there really is no reason why a missile engine could be boosted more than a normal engine. However, I will probably just allow normal engines to be boosted more, rather than reducing missile boost. If missiles are reduced in speed too much, they become too easy for point defence to destroy (some may argue that is already too easy).

6) I will include missiles in whatever final version of electronic warfare I decide upon.

7) I like reducing sensor range and it is something I was already considering (one of the reasons I haven't written the detection code yet). It would make the game more tactical and provide more reason for scouts & pickets. While not impacting missiles directly, the main requirement for missile ships is to detect their opponents (as missiles can be designed with very long-range), so this would effectively reduce missile range. At the moment, active sensor range in km is equal to:

Racial Active Sensor Strength per HS * Sensor Size  * Racial EM Tech * Square Root of Resolution * 10000.

The simplest change is to base the sensor range on the area (or volume) covered rather than the linear range. In essence, divide the result of the above calculation by the area or volume. This will shorten ranges considerably and is much more realistic. This would require some increase in base sensor strength though or the ranges would be reduced dramatically. I will run some numbers and post on this separately.

« Last Edit: March 26, 2017, 07:26:44 AM by Steve Walmsley »
 

Offline Haji

  • Captain
  • **********
  • Posts: 442
  • Thanked: 53 times
Re: C# Aurora Changes Discussion
« Reply #611 on: March 26, 2017, 07:53:35 AM »
I'm in full agreement with points one and two and ambivalent about point 3. However I really don't like points four and five.

While most people play on relatively low technology levels I recently reached anti-matter era and the interception chances are simply too high, rising to 50% against missiles which put 60% of it's mass towards engines. This makes it so difficult to get through point defence it makes any missile above size 2 essentially useless, even with box launchers. Making interception even easier (by reducing potential missile speed) or forcing us to use larger missiles will severely impact missile usefulness for fusion era and above.

What I would like to see is less trying to force us to use larger munitions and more ways for penetrating point defence, ways that favour larger munitions. This ways the player could either try to swamp the defences with small, cheap munitions or try to evade the defences using large, expensive but very hard to intercept missiles. The best way to do this would be by modifying ECM (since ECCM is not that bulky) but I don't know how to do that. Another way may be to allow the shipkillers to use agility to avoid interception, but that would have to be carefully balanced.

The other issue I have some problem with is the reduction is sensor range. Now I agree that sensor ranges become rather ridiculous on higher technological levels, but that the thing - the initial ranges are reasonable, the final ones are not. So what I'd like to see is the modification in the way technology progresses but from what you said you intend to lower even the starting detection range, which I think is a mistake.

In addition if you're tinkering with active sensor ranges you may take a look at passive ranges as well. At the moment a couple tracking stations in a central location can see anything in the system other than either small ships or stealthed ones.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11649
  • Thanked: 20350 times
Re: C# Aurora Changes Discussion
« Reply #612 on: March 26, 2017, 08:36:51 AM »
I'm in full agreement with points one and two and ambivalent about point 3. However I really don't like points four and five.

While most people play on relatively low technology levels I recently reached anti-matter era and the interception chances are simply too high, rising to 50% against missiles which put 60% of it's mass towards engines. This makes it so difficult to get through point defence it makes any missile above size 2 essentially useless, even with box launchers. Making interception even easier (by reducing potential missile speed) or forcing us to use larger missiles will severely impact missile usefulness for fusion era and above.

What I would like to see is less trying to force us to use larger munitions and more ways for penetrating point defence, ways that favour larger munitions. This ways the player could either try to swamp the defences with small, cheap munitions or try to evade the defences using large, expensive but very hard to intercept missiles. The best way to do this would be by modifying ECM (since ECCM is not that bulky) but I don't know how to do that. Another way may be to allow the shipkillers to use agility to avoid interception, but that would have to be carefully balanced.

The other issue I have some problem with is the reduction is sensor range. Now I agree that sensor ranges become rather ridiculous on higher technological levels, but that the thing - the initial ranges are reasonable, the final ones are not. So what I'd like to see is the modification in the way technology progresses but from what you said you intend to lower even the starting detection range, which I think is a mistake.

In addition if you're tinkering with active sensor ranges you may take a look at passive ranges as well. At the moment a couple tracking stations in a central location can see anything in the system other than either small ships or stealthed ones.

I am not trying to force larger munitions but rather than to reduce the advantages of smaller ones :)

I think your point about adding penetration aids to larger missiles is a very good one and I will find a way to implement something on those lines. I will probably advance my timetable for EW changes and include those in the initial C# release.

With regard to sensors, I am already working on some ideas but the main point is to reduce the linear effectiveness of very large sensors rather than reducing the range of smaller sensors. In fact, for lower resolutions, the ranges may go up under the proposal I am creating, which will allow earlier detection of missiles. I will post in a separate thread as I imagine there will be some debate :)
 
The following users thanked this post: Haji

Offline Haji

  • Captain
  • **********
  • Posts: 442
  • Thanked: 53 times
Re: C# Aurora Changes Discussion
« Reply #613 on: March 26, 2017, 09:09:45 AM »
I think your point about adding penetration aids to larger missiles is a very good one and I will find a way to implement something on those lines. I will probably advance my timetable for EW changes and include those in the initial C# release.

While I would love to see a good EW system I just had a sudden thought. Maybe it would be best to simply add a nebulous "penetration aid" statistic for missiles (and maybe a technology) that reduces the interception chances of anti-missies/point defence. It would have to be quite massive (definitely more massive than agility is right now) in order to not be overpowered but as most of the problems with very high anti-missile interception chances seem to come from agility rather than speed than having a statistic to counteract said agility (to an extent) could be the best and easiest solution. Of course this would force re-balancing beam based point defence, possibly by increasing the rate at which tracking speed increases. And as a last thought in order to not be overpowered the penetration aids could only nullify bonus from agility/tracking speed bonus but could not reduce interception chances below the base chance rated by missile speed/tracking speed.

As I said just a thought and a game wide EW revamp would likely be superior to that, but also harder to code I imagine.
 

Offline Zincat

  • Captain
  • **********
  • Z
  • Posts: 566
  • Thanked: 111 times
Re: C# Aurora Changes Discussion
« Reply #614 on: March 26, 2017, 09:21:43 AM »
Regardless of what happens, in this thread you can really see the rift between "the poeple who like missiles and would make them better" and "the people who like beams and would make them better"  ;D

Jokes aside. I still do think that missiles are in a much better position that beams. Inordinately so, especially against some enemies. PDCs are particularly unbalanced with missiles. Missiles PDCs are cheap, don't require much tech, use no maintenace currently, are fast to build. And can provide a huge amount of firepower.

Say, I can make a pretty cheap early defense based on missile PDCs against invaders. And it will work, if I shoot enough missiles at them to surpass their PD and have some basic engine speed technology. In my experience, I simply cannot achieve the same with beam weapons. If I want to use beam weapons against invaders, I really need a LOT of tech research, and espensive stations/ships. PDCs with fighters are a possibility, but still much lower efficiency than missile PDCs.

Since tech research is costly and takes time, if I have to choose between research for missiles and research for beams, I won't reasonably go for beams if I know invaders can show up.


This could be mitigated by making planet based missile PDCs less efficient, and all in a realistic way. Since escaping gravity is a costly thing, planet-based missiles could require a 2-stage design, in which the first stage is just something to escape gravity, and the second stage is the normal TN missile. This would make sense and would make planet-based missile PDCs less unbalanced.


3) I like the idea of removing the link between missile size and reload time, or at least significantly reducing the impact, as this will negate some of the advantages of smaller missiles.
This never made sense to me, so I will look forward to seeing it gone. If the launcher is big, and the missile is big, the loading mechanism will be equally big and thus the reload speed will be the same. There's no real reason for small missiles to reload faster, it's all fully automated. You don't have cabin boys manually carrying ordnance.


4) Also like the idea of some type of missile frame that would favour larger missiles (more frame overhead for smaller missiles), although this might impact the effectiveness of AMMs in the anti-missile mode. I guess one option would be to allow fractional missile launcher sizes so you could use missiles of size 1.2 for example.
Small missiles should have more overhead, so I'm in favour of this. Miniaturization does have a cost.

5) I am happy to remove the distinction in the power curve between missiles and normal engines. From a consistency POV, there really is no reason why a missile engine could be boosted more than a normal engine. However, I will probably just allow normal engines to be boosted more, rather than reducing missile boost. If missiles are reduced in speed too much, they become too easy for point defence to destroy (some may argue that is already too easy).
I am ok with this but... I think  there's a problem with the fuel model because higher speed engines for ships won't be usable if range becomes too short. Specifically to solve this, I think that bigger engines should have a more pronounced reduction in fuel consumption. Right now the difference in fuel usage between a size 1 and size 50 engine is pretty low. I think it would make sense to increase the fuel consumption reduction. The tradeoff is ALREADY there, because it's so much more risky to use fewer, bigger engines.

The simplest change is to base the sensor range on the area (or volume) covered rather than the linear range. In essence, divide the result of the above calculation by the area or volume. This will shorten ranges considerably and is much more realistic. This would require some increase in base sensor strength though or the ranges would be reduced dramatically. I will run some numbers and post on this separately.

Yes please, post this in a different thread with some numerical example. It will be a long and complicated discussion :)
« Last Edit: March 26, 2017, 09:50:23 AM by Zincat »