Aurora 4x
C# Aurora => C# Mechanics => Topic started by: Steve Walmsley on November 21, 2020, 11:17:22 AM
-
Thread for discussion of changes announced for v1.13. Please do not post bug reports or unrelated suggestions in this thread.
-
Did I miss 1.12.1?
-
No but what happened is that 1.12.1 got a DB change, turning it into 1.13.0
-
I don't know Steve if you've seen the Conventional Railgun in Suggestions thread but it would fit well with the reduced shot ones: a 5cm 1-shot Railgun that's available before TN-tech. Though I don't know if it would throw off the weapon level progression for ground forces and if it would play havoc elsewhere. We could power it with a conventional powerplant, meaning that a rudimentary armed space shuttle would be possible!
-
I'm a bit unsure what the use case is for reduced shot railguns, since the HS-per-shot is larger as the number of shots is reduced. My best guess is that this is to make railgun fighters more viable?
-
I've never understood this. Why exactly do we have to pick sizes from a list? Why not let us type in arbitrary values? I know it can be done, the missile design window and designing command units for ground forces both allow arbitrary values. So why can't I make a 57.6 size engine or whatever?
-
I've never understood this. Why exactly do we have to pick sizes from a list? Why not let us type in arbitrary values? I know it can be done, the missile design window and designing command units for ground forces both allow arbitrary values. So why can't I make a 57.6 size engine or whatever?
Missiles and ground forces (and turrets) use bespoke windows. Ship components all use the same dropdowns on the same project window, which means they have to follow some common rules (like choosing from a list). At some point I may create bespoke design windows for each different component (probably tabs on the same window), which would get around the restriction. I would also need to change all the design code to accept different inputs and update the NPR design rules so they don't choose from a list either.
-
The reduced shots railguns open the interesting possibility of very small beam fighters, even around 100 tons. That doesn't really make them more effective, in fact four would have less firepower than a single 400 ton fighter, but it does give them a sort of survival enhancement in that you can only shoot one at a time. Previously you could do that with very low accuracy gauss, but... then you were using very low accuracy gauss. The only argument against tiny railgun fighters is micromanagement, and that could easily be reduced by improving fighter management tools (and in truth I haven't played with them enough to say if the micromanagement is even still an issue).
Being able to match your capacitor tech will also make for very high DPS weapons, I think. You get the advantages of a high caliber weapon (like improved range and armor penetration) without the cost of low DPS due to capacitor charge being the same regardless of caliber. And that's on top of railguns already getting a bonus to damage per power use and not using corundium.
I honestly think this change might single-handedly make railguns the king of beam weapons, though I look forward to actually playing around with it.
-
The single weapons fire control change is great.
My beam fighters will surely benefit from that a lot. I'm also toying with the possibility of making single weapon FCs for my spinal lasers ^^
-
Lasers have spinal weapons and particle beams have lances, so I thought this would make a good 'special ability' for railguns while helping beam fighters.
-
Lasers have spinal weapons and particle beams have lances, so I thought this would make a good 'special ability' for railguns while helping beam fighters.
I'm going to make a couple of changes for the next version to make beam fighters a little easier, without making them overpowered.
I like the changes so far! After all, beam fighters don't have to be able to beat actual beam warships on a tonnage/cost basis to be practical as a weapon system. If they're even decent they'll still fill a useful role for skirmishing and picking off damaged/solo enemies, and unlike beam warships it's extremely hard to kite or run from them. You'd just have to avoid sending them into range of massed beam battleships.
Even if it ends up as simple as Missiles beat Beams which beat fighters which beat missiles, that's a matchup that rewards combined arms, and in truth it's likely to end up much more complex than that. I know I'll be much more worried about unescorted missile ships if swarms of tiny railgun fighters are a threat.
-
Lasers have spinal weapons and particle beams have lances, so I thought this would make a good 'special ability' for railguns while helping beam fighters.
Is there a plan to add something special to carronades too? I love the weapon, but designing one hurts with only 2 options.
That said, love all the changes so far. Beam fighters needing to be reduced laser or gauss always threw me off of them as both of these come with big disadvantages. Reduced rails look like the thing to bridge the gap between big alpha strike and volume of ineffective fire those 2 provide.
-
The only argument against tiny railgun fighters is micromanagement, and that could easily be reduced by improving fighter management tools (and in truth I haven't played with them enough to say if the micromanagement is even still an issue).
I think mass fighter management is only a problem in the context of ground support fighters. Right now large numbers of CAS is literally unuseable because of having to one by one drag each fighter to a formation to support it. This is made worse by the fact that you cannot scroll the ground OOB menu while dragging fighters meaning that after a certain amount you become forced to split your CAS into a massive amount wings, cluttering the naval OOB menu. I say this with a force that "only" has 42 CAS fighters in 7 wings of six.
-
These changes are going to work well with my next project:
4 or 5 player controlled races starting in different systems. No NPRs or aliens in general, small galaxy 150 stars.
Special rules: no missiles on fighters, no launchers on ship only box launchers.
The idea was to have mostly dogfighting and close combat after first deadly alpha strikes
-
The changes are great, looking forward to making FACs with massive caliber single shot railguns
-
http://aurora2.pentarch.org/index.php?topic=12035.msg143332#msg143332
^Hell yeah! I was hoping for a return of the Fighter-Only Beam FCS, Lord only knows I've bellyached about it, but this is wayyyy better! ;D
Great job on this one, knocked it out of the park! I like the Railgun thing too, btw. Having nice, big, single shot Railguns is gonna be awesome! A shame though that it puts another nail into Gauss, but to be honest Gauss is already very potent, so no big deal. :) I love these changes, bravo!
-
The only argument against tiny railgun fighters is micromanagement, and that could easily be reduced by improving fighter management tools (and in truth I haven't played with them enough to say if the micromanagement is even still an issue).
I think mass fighter management is only a problem in the context of ground support fighters. Right now large numbers of CAS is literally unuseable because of having to one by one drag each fighter to a formation to support it. This is made worse by the fact that you cannot scroll the ground OOB menu while dragging fighters meaning that after a certain amount you become forced to split your CAS into a massive amount wings, cluttering the naval OOB menu. I say this with a force that "only" has 42 CAS fighters in 7 wings of six.
You can drag and drop between two different windows as well... will this not help you when doing this. I might be out of practice as I have not had that many ground combats in the last couple of months.
-
You can drag and drop between two different windows as well... will this not help you when doing this. I might be out of practice as I have not had that many ground combats in the last couple of months.
I'll admit that I havent thought of doing that since I use a single monitor but that does not remove the problem of only being able to drag fighters one by one. Even with just 42 of them it can become quite troublesome. I think having some button to auto-distribute CAS to FFDs would be nice.
-
We now need something for gauss cannons maybe?
-
Interesting changes. I remember having difficulties creating a 250 ton viable railgun fighter, this might very well make it possible at lowish tech level. May even pack a decent punch with a spinal 1 shot 12CM, if weight allows.
-
You can drag and drop between two different windows as well... will this not help you when doing this. I might be out of practice as I have not had that many ground combats in the last couple of months.
I'll admit that I havent thought of doing that since I use a single monitor but that does not remove the problem of only being able to drag fighters one by one. Even with just 42 of them it can become quite troublesome. I think having some button to auto-distribute CAS to FFDs would be nice.
I have no idea what type of devices you have at home but I have outside of two monitors also several tablets (android devices) that I use to have the log on and sometimes more than one device for different windows.
If you use Spacedesk which is an application you can share your devices as virtual screens and this works on pretty much any device. So if you have an old laptop or tablets you can use them as extra screens and this works really well with Aurora as you can open windows on multiple smaller screens.
-
We now need something for gauss cannons maybe?
Perhaps the gauss cannons could gain some benefit to being turreted, as a lot of the other special options focus more around hull mounting.
-
We now need something for gauss cannons maybe?
Is not Gauss Cannon's thing, that they do not suffer failures?
Or am I incorrect in that account
-
We now need something for gauss cannons maybe?
Perhaps the gauss cannons could gain some benefit to being turreted, as a lot of the other special options focus more around hull mounting.
Gauss cannons already have reduced accuracy options, which are sort of similar to the new railgun changes. They're not terribly useful, but they exist. They're also the only weapon that gets increased fire rate from tech.
Actually if Steve really wanted to make every weapon more unique I think the next on the list would be plasma cannons. If he's looking for suggestions, I think they'd be a good target for playing with the recharge rate mechanic. For instance, over- or under- charging. Say, if you had a plasma cannon that took 60 power to fire for 60 damage, but in design you could tick the "overcharge capability" box to make it 10% larger but if not fired it would charge all the way up to 120 power and do 90 damage when fired (and then be back to doing 60 for 60 until you let it overcharge again). Or an undercharge mechanic would let plasma cannons fire whatever power they had in their capacitor.. if it takes 60 power to deal 60 damage normally, but you left it on open fire, it would just dump all it's power every 5 seconds doing that much damage. I think either of those changes would lend itself well to the plasma cannon's role as a brutal close range weapon, but I don't know how weapons fire is coded so have no idea how much work the change would be.
I guess that's kind of turning into a suggestion post instead of discussion. Anyways, I love the way the changes are making the weapons more unique.
-
Gauss cannons already have reduced accuracy options, which are sort of similar to the new railgun changes. They're not terribly useful, but they exist. They're also the only weapon that gets increased fire rate from tech.
Actually if Steve really wanted to make every weapon more unique I think the next on the list would be plasma cannons. If he's looking for suggestions, I think they'd be a good target for playing with the recharge rate mechanic. For instance, over- or under- charging. Say, if you had a plasma cannon that took 60 power to fire for 60 damage, but in design you could tick the "overcharge capability" box to make it 10% larger but if not fired it would charge all the way up to 120 power and do 90 damage when fired (and then be back to doing 60 for 60 until you let it overcharge again). Or an undercharge mechanic would let plasma cannons fire whatever power they had in their capacitor.. if it takes 60 power to deal 60 damage normally, but you left it on open fire, it would just dump all it's power every 5 seconds doing that much damage. I think either of those changes would lend itself well to the plasma cannon's role as a brutal close range weapon, but I don't know how weapons fire is coded so have no idea how much work the change would be.
I guess that's kind of turning into a suggestion post instead of discussion. Anyways, I love the way the changes are making the weapons more unique.
The issue with plasma carronades is that they're already nearly unbeatable as a close-range brawling weapon. Making them better at close-range brawling won't really make them a better weapon because their main limitation is simply that getting into close brawling range is so difficult, since in the process you have to not only fend off missile fire but also close range against all the longer-ranged beamships you might encounter. That's not unsolvable, but it does make plasma usually a poor choice of weapon in terms of relative optimization and buffing their alpha damage even more doesn't really change this.
One thought I did have was to give plasma carronades some kind of miniaturization help similar to what Railguns are getting here to make them more viable to mount on fighters, which can close range with beamships using high speed and thus make good platforms for plasma guns. Plus, the playstyle of flying in fast, dodging flak fire, firing off a salvo of plasma guns, and retreating out of range to reload is a unique "bombing run" playstyle that you don't really get from missile fighters as much.
Note that this does admittedly leave microwaves as the other beam weapon type without a special mounting of some kind (Gauss/Meson = turrets, Laser = spinal, Particle Beam = lance, and now Railguns in the next patch). Those are already a pretty special kind of weapon though.
-
One possible option for fighter plasma cannons I dont think has been done yet for another weapon would be an ability to do away with any inbuilt recharging capability (reducing mass of the cannon itself and also removing the need for a reactor on the fighter), so you get relatively very lightweight plasma cannons, can charge the plasma cannon at the mothership, and then the fighter gets one shot per cannon.
-
That actually sounds cool. It would need to be a fairly quick recharge, not hours. You could do a lot of damage at a jump point for low costs with a squad of plasma carronade fighters to assist your minefields.
-
One possible option for fighter plasma cannons I dont think has been done yet for another weapon would be an ability to do away with any inbuilt recharging capability (reducing mass of the cannon itself and also removing the need for a reactor on the fighter), so you get relatively very lightweight plasma cannons, can charge the plasma cannon at the mothership, and then the fighter gets one shot per cannon.
That sounds... perfect, actually. Though perhaps not one shot, but a very limited number of shots, such as 5?
This would mean you could have another sort of bomber entirely, a plasma bomber which did not use missiles. Creative, interesting, and could allow for some insane alpha strikes in many cases.
-
- Well, the return of reduced size FCS already makes Beam fighters wayyyy more practical than they were before. Like, quite significantly so.
- With that having been said; for Plasma Carronades I'd like to see them have an option to consume fuel as ammo. Perhaps a kind of alternative shield that was stronger and/or smaller, but consumed fuel as well to go with it. In Homeworld and Homeworld 2, the Plasma Bombs were fluffed as using a portion of the starship's fuel as ammo, which keeps with the idea and logic of what plasma actually is, that being a state of matter. I don't really expect Steve to put all that work into them though, as much as I'd like to see such a change it really doesn't jive to well with Aurora's flavor, IMO.
- An alternative for the Carronades would simply to be adding in the reduced size and giving them an "Extended Minimum" analogous to the Laser's Spinal Mounts. The Extended Minimum would have two levels, with the first reducing damage drop off for a corresponding increase in weight, say halving the drop off in exchange for a mass increase equal to +1 calibre. AKA, like how Spinal Mounts increase the laser's weight. The second tier would add +2 calibres of mass for a removal of damage drop off. This would mean that you could combine the two upgrades to make an expensive 15cm Plasma Carronade that had no drop off and weighed the roughly the same mass, but had drastically increased recharge needs.
- For the HPMs, I'd really just like the option to turret 'em, tbh. I think they'd make nice Anti-Fighter / Anti-FAC guns. I'd also like to see the damage of HPMs, well "damage", but you know what I mean... I'd like to see that increase with calibre. Likewise for Mesons, I'd like to see bigger Meson Guns do more damage. So a 12cm HPM would do 4 damage to shields and a 15cm would do 5 damage to them, but both would still only roll once for E-DAC, while the 20cm would do 6 Damage to shields and roll twice on the E-DAC. Basically have the bigger HPMs increase the shield damage while making the number of rolls on the E-DAC be equal to half the shield damage rounded down.
- Mesons could do something similar, in that they fire a bigger "shot". So a 12cm Meson fires a 2-point "shot", a 15cm Meson fires a 3-point "shot" and so on and so forth. Thus the Meson Retardation Tech would become more useful as you went up in size, with each failed roll removing 1 point of strength from the "shot" until it finally fizzled. The size, power requirements, costs and so on would keep smaller guns useful for fighters, turrets and such, while the FCS needed to make use of the better range would help keep the mid-sized guns relevant for some time as well. These factors would also curb the usefulness of truly monstrous guns, like 30cm+ ones, as their FCS and Power Requirements would hamstring their damage output via accuracy, RoF, and required technological & material investment.
- Thus under these changes Plasma Carronades would become a more robust and interesting weapon system to invest in, without losing their low-cost / low-tech niche. HPMs would become shield-buster / ion cannon-esque weapons, and with the option to turret would double as Anti-Fighter / Anti-FAC against beam-centric foes. Mesons would a lot more useful to research as a main weapon option, since the big ones would give better performance against ships while the turreted small ones remain a viable Anti-Missile / Anti-FAC, with the ones in the 12~15cm range would double as Anti-Fighter weapons. These would make Mesons into an actually threatening weapon, without reverting them to the overpowered monstrosities that they were. Add back them Armored Missiles and suddenly they become very, very attractive options indeed. :)
-
- With that having been said; for Plasma Carronades I'd like to see them have an option to consume fuel as ammo. Perhaps a kind of alternative shield that was stronger and/or smaller, but consumed fuel as well to go with it. In Homeworld and Homeworld 2, the Plasma Bombs were fluffed as using a portion of the starship's fuel as ammo, which keeps with the idea and logic of what plasma actually is, that being a state of matter. I don't really expect Steve to put all that work into them though, as much as I'd like to see such a change it really doesn't jive to well with Aurora's flavor, IMO.
This is a neat idea. Could be unlocked by the first fusion reactor tech, which marks the point in the tech tree where we can use Sorium fuel to generate high-temperature plasmas. However as you say it doesn't quite fit, namely you'd still need a power reactor to run the weapon unless you throw lore out the window, so there'd be no benefit...unless Steve wanted to bring back plasma torpedoes? :o
- An alternative for the Carronades would simply to be adding in the reduced size and giving them an "Extended Minimum" analogous to the Laser's Spinal Mounts. The Extended Minimum would have two levels, with the first reducing damage drop off for a corresponding increase in weight, say halving the drop off in exchange for a mass increase equal to +1 calibre. AKA, like how Spinal Mounts increase the laser's weight. The second tier would add +2 calibres of mass for a removal of damage drop off. This would mean that you could combine the two upgrades to make an expensive 15cm Plasma Carronade that had no drop off and weighed the roughly the same mass, but had drastically increased recharge needs.
I'm not sure how this is appreciably different from the particle beam except with variations in range, hitting power, and maybe firing speed. Given that Steve seems very set on keeping each type of beam/gun weapon distinctive I'm not sure this would fit well. That said, the general concept is similar enough to a spinal plasma cannon kind of weapon and I think we can all get behind the idea of another badass BFG in the game.
- For the HPMs, I'd really just like the option to turret 'em, tbh. I think they'd make nice Anti-Fighter / Anti-FAC guns. I'd also like to see the damage of HPMs, well "damage", but you know what I mean... I'd like to see that increase with calibre. Likewise for Mesons, I'd like to see bigger Meson Guns do more damage. So a 12cm HPM would do 4 damage to shields and a 15cm would do 5 damage to them, but both would still only roll once for E-DAC, while the 20cm would do 6 Damage to shields and roll twice on the E-DAC. Basically have the bigger HPMs increase the shield damage while making the number of rolls on the E-DAC be equal to half the shield damage rounded down.
I believe Steve has said he chose not to turret HPMs to keep them exclusively as an anti-ship weapon.
- Mesons could do something similar, in that they fire a bigger "shot". So a 12cm Meson fires a 2-point "shot", a 15cm Meson fires a 3-point "shot" and so on and so forth. Thus the Meson Retardation Tech would become more useful as you went up in size, with each failed roll removing 1 point of strength from the "shot" until it finally fizzled. The size, power requirements, costs and so on would keep smaller guns useful for fighters, turrets and such, while the FCS needed to make use of the better range would help keep the mid-sized guns relevant for some time as well. These factors would also curb the usefulness of truly monstrous guns, like 30cm+ ones, as their FCS and Power Requirements would hamstring their damage output via accuracy, RoF, and required technological & material investment.
Interesting idea, though I worry it might be a bit powerful after a couple of tech levels as they simply eat less-armored ships alive whereas anything else has to at least ablate a few layers of armor to begin breaking things. Which I know is the whole idea of mesons, but it's a damn powerful idea. Maybe a compromise is to have them fire in salvos, similar to railguns but the shots per salvo can increase as with Gauss guns. That way you multiply the firepower still, but the armor penetration stays the same per shot which is easier to balance.
-
Any fix coming for the Raksha save/load issue or is that even a conceived bug on the to do list yet?
-
Single shot carronades would be awesome and totally fit into the WW2 naval battles in space feeling that I get from the game :) As it stands now missile-fighters are less fighters and more like carrier launched missile boats
-
Any fix coming for the Raksha save/load issue or is that even a conceived bug on the to do list yet?
Oh, is THAT why they keep vanishing?
-
Any fix coming for the Raksha save/load issue or is that even a conceived bug on the to do list yet?
Oh, is THAT why they keep vanishing?
Happened to me too, they just vanished on continuing my game. They still have a colony but pacifying it apparently require a completely absurd amount of military forces, like several billions infantry.
-
- Thus under these changes Plasma Carronades would become a more robust and interesting weapon system to invest in, without losing their low-cost / low-tech niche. HPMs would become shield-buster / ion cannon-esque weapons, and with the option to turret would double as Anti-Fighter / Anti-FAC against beam-centric foes. Mesons would a lot more useful to research as a main weapon option, since the big ones would give better performance against ships while the turreted small ones remain a viable Anti-Missile / Anti-FAC, with the ones in the 12~15cm range would double as Anti-Fighter weapons. These would make Mesons into an actually threatening weapon, without reverting them to the overpowered monstrosities that they were. Add back them Armored Missiles and suddenly they become very, very attractive options indeed. :)
A different view on Plasma Carronades, I have always seen them as the short range, super high damage weapon of the game. To that end, in my head, they have been a lot like the Plasma Mortars in the The Last Angel stories. In those, the plasma mortar is a short range devastating weapon that hits harder than just about any other energy weapon and then burns. To that end, I would do something like a certain spoiler's weapon.
To that end, I would make it so that when a plasma carronade hits, it does its damage and then each 5 second tick after the hit, it applies "burn" damage to the same armor columns it damaged in the initial hit. The burn damage would be at most 1 armor in each armor column per 5 second tick. The total amount of burn damage that a hit from the plasma carronade could do would be limited to some percentage of the damage the initial hit did. The percentage could start at 50% and you could have a research line to increase this percent, call it Plasma Control. With a research option you could allow more damage to be caused by the burn, even potentially more than the initial hit.
Example: (Numbers are from VB Aurora so not sure if damage number is the same)
25 cm Plasma Carronade: 16 damage
Damage Template: The damage would be across 7 armor columns and be 4 rows deep.
Time 0: Plasma Carronade hits and causes 16 damage
Time 1 (5 seconds after initial hit): 50% of initial damage is 8, 8 units of burn damage remain to be applied. All 7 armor columns would apply a single point of damage, for a total of 7 burn damage. If any columns with no additional armor rows, then the burn damage is applied to internal ship components.
Time 2 (10 seconds after initial hit): 50% of initial damage is 8, 1 unit of burn damage remains to be applied. 1 armor column applies a single point of damage, choose deepest armor column (ie: the middle column in the damage template). If the column(s) have no additional armor rows, then the burn damage is applied to internal ship components. (Stretch goal: apply burn damage to same components as previous increment if they were not destroyed by previous damage)
Time 3 (15 seconds after the initial hit): 50% of initial damage is 8, all damage has been applied so do nothing.
For a max tech Plasma Carronade, you would do 168 initial damage (24 columns wide, 13 columns deep) and burn another 84 damage across 24 columns of armor resulting in another 3+ rows of armor destruction or internal damage.
Now that is a close quarters devastating weapon.
-
Another use for reduced fire rate railguns occured to me - STO weapons. In addition to all the normal benefits (and range is a big one for STOs), STO weapons have the same durability regardless of weapon size. So having multiple smaller guns will make them much harder to destroy if they get in a gun duel with enemy warships.
It does mean extra size spent on extra sensors and fire controls, but for large caliber railguns that would otherwise have low ROF I think it will be extremely worth it.
-
Super excited about the BFC changes, now my dream of spinal only fleet carried around by civie carriers will happen.
-
Another use for reduced fire rate railguns occured to me - STO weapons. In addition to all the normal benefits (and range is a big one for STOs), STO weapons have the same durability regardless of weapon size. So having multiple smaller guns will make them much harder to destroy if they get in a gun duel with enemy warships.
It does mean extra size spent on extra sensors and fire controls, but for large caliber railguns that would otherwise have low ROF I think it will be extremely worth it.
The best par for the bigger calibre guns is that the reduced fire rate Railguns will shoot faster too, on account of reduced power requirements. :D
-
This isn't really a question specific to 1.13 as it regards gene modding.
How will gene modding in C# differ from what it was in VB6?
-
So, the Small Boat Bay was changed to only hold 1 HS... or 50 tons. This makes me sad... :(
I liked the 125 Ton bay...
-
Instant Build to Carriers
Instant Build on the Class window now has an option to build straight into a carrier hangar bay (and assign). This takes away the micro of creating fighters and manually setting the move orders to land on carriers.
I love changes that reduce unnecessary micromanagement. Will something similar be available for non Spacemaster mode as well, eventually?
My first and therefore probably bad idea is a setting in the fighter production menu where you can select a ship class. All built fighters would be assigned to and landed in hangars of any ships of that ship class in orbit around the planet.
-
Instant Build to Carriers
Instant Build on the Class window now has an option to build straight into a carrier hangar bay (and assign). This takes away the micro of creating fighters and manually setting the move orders to land on carriers.
I love changes that reduce unnecessary micromanagement. Will something similar be available for non Spacemaster mode as well, eventually?
My first and therefore probably bad idea is a setting in the fighter production menu where you can select a ship class. All built fighters would be assigned to and landed in hangars of any ships of that ship class in orbit around the planet.
- Well if you have Build Points you don't need SM. :D
-
Looks like a great list of changes. Thanks Steve.
-
So, the Small Boat Bay was changed to only hold 1 HS... or 50 tons. This makes me sad... :(
I liked the 125 Ton bay...
Since you can have multiple boat bays on a ship, I like this change as it allows more granularity in designing exactly the hangar size you need for a single specialized fighter. For example a fighter of 150 or 200 tons can now be accommodated exactly instead of wasting 50 or 100 tons on extra hangar space.
-
So, the Small Boat Bay was changed to only hold 1 HS... or 50 tons. This makes me sad... :(
I liked the 125 Ton bay...
Since you can have multiple boat bays on a ship, I like this change as it allows more granularity in designing exactly the hangar size you need for a single specialized fighter. For example a fighter of 150 or 200 tons can now be accommodated exactly instead of wasting 50 or 100 tons on extra hangar space.
- But I design a lot of Fighters with 125 or 375 Ton profiles, precisely because they fit in a single Small Boat Bay, or a Small Boat Bay + Boat Bay. :(
-
So, the Small Boat Bay was changed to only hold 1 HS... or 50 tons. This makes me sad... :(
I liked the 125 Ton bay...
Since you can have multiple boat bays on a ship, I like this change as it allows more granularity in designing exactly the hangar size you need for a single specialized fighter. For example a fighter of 150 or 200 tons can now be accommodated exactly instead of wasting 50 or 100 tons on extra hangar space.
- But I design a lot of Fighters with 125 or 375 Ton profiles, precisely because they fit in a single Small Boat Bay, or a Small Boat Bay + Boat Bay. :(
But how do you get round speeds with ship sizes in the fractional HS? Truly, you are a braver man/woman/space alien than I... :P
-
So, the Small Boat Bay was changed to only hold 1 HS... or 50 tons. This makes me sad... :(
I liked the 125 Ton bay...
Since you can have multiple boat bays on a ship, I like this change as it allows more granularity in designing exactly the hangar size you need for a single specialized fighter. For example a fighter of 150 or 200 tons can now be accommodated exactly instead of wasting 50 or 100 tons on extra hangar space.
- But I design a lot of Fighters with 125 or 375 Ton profiles, precisely because they fit in a single Small Boat Bay, or a Small Boat Bay + Boat Bay. :(
But how do you get round speeds with ship sizes in the fractional HS? Truly, you are a braver man/woman/space alien than I... :P
- Close enough is good enough for me. ;D I won't complain too much... worst comes to worst I just need to rebuild certain craft. :P
-
- But I design a lot of Fighters with 125 or 375 Ton profiles, precisely because they fit in a single Small Boat Bay, or a Small Boat Bay + Boat Bay. :(
He could make the Small Boat Bay hold 1t, then we could precisely target any size ship.
-
- But I design a lot of Fighters with 125 or 375 Ton profiles, precisely because they fit in a single Small Boat Bay, or a Small Boat Bay + Boat Bay. :(
He could make the Small Boat Bay hold 1t, then we could precisely target any size ship.
- Maybe a separate component for that... or better yet, make Hangars a designable component, kind of like magazines. ;D
-
My first and therefore probably bad idea is a setting in the fighter production menu where you can select a ship class. All built fighters would be assigned to and landed in hangars of any ships of that ship class in orbit around the planet.
You can already build fighters into a specific fleet with carriers by using the fighter target fleet.
-
- But I design a lot of Fighters with 125 or 375 Ton profiles, precisely because they fit in a single Small Boat Bay, or a Small Boat Bay + Boat Bay. :(
He could make the Small Boat Bay hold 1t, then we could precisely target any size ship.
- Maybe a separate component for that... or better yet, make Hangars a designable component, kind of like magazines. ;D
Designable hangars would be cool. You could choose between space efficiency and rearming efficiency for example
-
Designable hangars would be cool. You could choose between space efficiency and rearming efficiency for example
also the new repair functionality could be made to be selected for more costs/space or left to lower costs/space
-
Carrier Operations Bonus
The Fighter Operations bonus for commanders has been renamed to the Carrier Operations bonus.
This bonus will apply to the rate at which fuel, supplies and ordnance are transferred to parasites in the ship's hangar.
While this is a current topic, could we get some clarification as to how the fighter combat / carrier ops bonuses are considered by the auto-assign? I.e. how they fit into the priority system and which ships are considered for such types of commanders. I don't think the post for C# auto-assign has been updated with this information for those bonuses.
-
Carrier Operations Bonus
The Fighter Operations bonus for commanders has been renamed to the Carrier Operations bonus.
This bonus will apply to the rate at which fuel, supplies and ordnance are transferred to parasites in the ship's hangar.
While this is a current topic, could we get some clarification as to how the fighter combat / carrier ops bonuses are considered by the auto-assign? I.e. how they fit into the priority system and which ships are considered for such types of commanders. I don't think the post for C# auto-assign has been updated with this information for those bonuses.
It is used as the primary bonus for CAG officers.
-
Carrier Operations Bonus
The Fighter Operations bonus for commanders has been renamed to the Carrier Operations bonus.
This bonus will apply to the rate at which fuel, supplies and ordnance are transferred to parasites in the ship's hangar.
While this is a current topic, could we get some clarification as to how the fighter combat / carrier ops bonuses are considered by the auto-assign? I.e. how they fit into the priority system and which ships are considered for such types of commanders. I don't think the post for C# auto-assign has been updated with this information for those bonuses.
It is used as the primary bonus for CAG officers.
The non-command positions are listed here as:
Executive Officer
Science Officer
Commander, Air Group
Chief Engineer
Tactical Officer
Is this the order in which they are prioritized, e.g. a commander with Crew Training and Fighter/Carrier Ops will preferentially be assigned to an XO posting?
What about Fighter Combat? I assume it's assigned to <500-ton ships, but what precedence does it have relative to Crew Training, Reaction, Engineering, Tactical? Where are fighters in the auto-assign priority?
Again sorry for this being a bit outside of 1.13 discussion, but it's come up. :)
-
Order is XO, Science, CAG, Engineer, Tactical.
I've checked the code on auto-assign and it doesn't look like I did anything specific for fighters, so at the moment so are handled using the ship mechanics.
-
Regarding Constellation Names,
Can you possibly work up a scheme to generate the names for a non-Known Stars game?
-
Regarding Constellation Names,
Can you possibly work up a scheme to generate the names for a non-Known Stars game?
There are no 3D star positions in random games, so no constellations. It would be easier to generate a name theme using all combinations of Greek letters and constellation names, which would provide over 2000 names.
-
Very cool changes with constellations. I've always loved the Greek-Constellation naming pattern as it feels the most sci fi-y.
If we're throwing around design ideas here, hangar design would be cool too. Adding a launch rate to fighters and designing carrier space around launch rate / capacity would be interesting. Perhaps an option for an "open flight deck" too which greatly increases launch rate at the expense of damage to the hangar bay also damaging fighters and fighter explosions caused by such damage causing secondary explosions to the ship-- in true open flight defk warship fashion!
-
I've adopted a naming system for my games that revolves around my central system (I always use the name Solaria for my home system). This is the system I use:
<Greek City Name> - <Position in Chain> - <System Identifier Code> - <Jump Distance from Home World> - <Optional World Name>
I have list of about 500 ancient Greek city names which I semi-randomized but I always use Athens, Sparta, Corinth, Thebes, and Delphi first. I change the City name every 3 to 5 planets which is the second position in the system name.
My system identifier code is as follows:
A: Starport Present in system
N: Naval Base (Perm. Naval Presence) in system
S: Sorium Fueling in system
C: Populated Colony + # of colonies
W: Part of my stabilized Jump Point Network
X: No permanent presence
So for example, lets take a world that is the third system in the Athens Chain, has a three populated colonies of which this was the first world (Cardiff A, B, C), a sorium harvesting operation, starport present, and is part of the stabilized jump point network. And it is 9 jumps from Solaria. Its designation would be:
ATHENS-3-ASC3W-9-CARDIFF A
I came about this system because I do a lot of paying attention to the log as I advanced turns and as my empire grew bigger, I started lose the spatial sense of where things were happening and this allowed me to better keep track of events in relation to my home world or important neighbors.
-
Very cool changes with constellations. I've always loved the Greek-Constellation naming pattern as it feels the most sci fi-y.
If we're throwing around design ideas here, hangar design would be cool too. Adding a launch rate to fighters and designing carrier space around launch rate / capacity would be interesting. Perhaps an option for an "open flight deck" too which greatly increases launch rate at the expense of damage to the hangar bay also damaging fighters and fighter explosions caused by such damage causing secondary explosions to the ship-- in true open flight defk warship fashion!
This has been suggested before - in addition to what you've said resupply/rearm rate could also be design factor as well.
-
Love the new constellation naming change, will really help with one of the less enjoyable parts of Real Stars games.
I would like to specially request that one of the WISE stars be named WISE 531-8008 and left alone, because I am a very mature adult and certainly never played with calculators in grade school...
-
It occurs to me you might be able to write a small program to do the heavy lifting with generating all names needed. Perhaps the javascript on the site is extensible for this purpose? Of course that might be a more significant focus of effort then doing a single small batch by hand. In any case I'm definitely looking forward to the change.
-
Regarding Constellation Names,
Can you possibly work up a scheme to generate the names for a non-Known Stars game?
There are no 3D star positions in random games, so no constellations. It would be easier to generate a name theme using all combinations of Greek letters and constellation names, which would provide over 2000 names.
That is more along the lines of what I meant. Something to randomly generate names rather than a static list.
-
Are colony rebellions enabled yet or is that mechanism still being worked on?
-
Are colony rebellions enabled yet or is that mechanism still being worked on?
So far you have to do it manually through independence. I have played a lot with the mechanic recently and I have understood why is soo hard to implement. out of 5 attempts to just declare independence and change the DB so that the new faction would be led by the AI, only 1 succeded and I still don't really know why or well I guess that the reason was for me to leave it as it was. The problem with that is you have a completely worthless opponent. All the others that involved some sort of help like ships or troops have either: broke the game after a few decades or simply thrown multiple errors every sub pulse click making it unplayable.
I think there is some sort of heavy coding involved to actually make this a mechanic. It would require the NPR to be generated as it was brand new but I don't think people will be happy with a bunch of ships or troops appeared out of nowhere. Unless you happy with just a planet where you need to send ground troops unopposed...
-
Are colony rebellions enabled yet or is that mechanism still being worked on?
So far you have to do it manually through independence. I have played a lot with the mechanic recently and I have understood why is soo hard to implement. out of 5 attempts to just declare independence and change the DB so that the new faction would be led by the AI, only 1 succeded and I still don't really know why or well I guess that the reason was for me to leave it as it was. The problem with that is you have a completely worthless opponent. All the others that involved some sort of help like ships or troops have either: broke the game after a few decades or simply thrown multiple errors every sub pulse click making it unplayable.
I think there is some sort of heavy coding involved to actually make this a mechanic. It would require the NPR to be generated as it was brand new but I don't think people will be happy with a bunch of ships or troops appeared out of nowhere. Unless you happy with just a planet where you need to send ground troops unopposed...
I don't think rebellion has to be a planet declaring independence though. You could have riots and stuff that fire once unrest has been high for a long enough period of time. Installations are destroyed, ground units take casualties, missile stockpiles are rendered useless. Maybe even things in orbit are sabotaged, damaging or destroying ships etc. Unrest could even spread to other planets to the same system and to a lesser extent planets that are in the same sector (based on no. of jumps from the unrest).
To me this sounds like an easier way than implementing some form of secession mechanic.
Declaring independence feels like it should be related to a more novel secession mechanic that is maybe handled on the sector command level (yes I know you could game this by not having sectors). When a sector as a whole has high unrest across multiple worlds/systems it might decide to secede from the empire with planets determining allegiance based on how big and stable they are. If you feel like putting in the work you could also factor in the industrial dependence of a colony to the rest of the empire when factoring this in. This could make it so that instead of individual colonies, entire systems or sections of the empire could secede and become a real pain in the ass as opposed to a lone planet rising up on its own.
I don't know how you'd allocate ships and space installations. It makes sense to make engineless ships switch/stay on the side that their planet has joined. I think its acceptable to spawn somewhat weak but numerous infantry based militias to act as the initial garrison to the new independent worlds depending on population size. You could make the homeworlds of officers as a factor, making officers more likely to attempt to defect their ships to their home sector / planet if its declared independence.
I think for the time being a simple rebellion planet state would be good to at least provide RPers with a prelude to manual independence and to provide players more of an incentive to police their worlds.
-
Are colony rebellions enabled yet or is that mechanism still being worked on?
So far you have to do it manually through independence. I have played a lot with the mechanic recently and I have understood why is soo hard to implement. out of 5 attempts to just declare independence and change the DB so that the new faction would be led by the AI, only 1 succeded and I still don't really know why or well I guess that the reason was for me to leave it as it was. The problem with that is you have a completely worthless opponent. All the others that involved some sort of help like ships or troops have either: broke the game after a few decades or simply thrown multiple errors every sub pulse click making it unplayable.
I think there is some sort of heavy coding involved to actually make this a mechanic. It would require the NPR to be generated as it was brand new but I don't think people will be happy with a bunch of ships or troops appeared out of nowhere. Unless you happy with just a planet where you need to send ground troops unopposed...
I don't think rebellion has to be a planet declaring independence though. You could have riots and stuff that fire once unrest has been high for a long enough period of time. Installations are destroyed, ground units take casualties, missile stockpiles are rendered useless. Maybe even things in orbit are sabotaged, damaging or destroying ships etc. Unrest could even spread to other planets to the same system and to a lesser extent planets that are in the same sector (based on no. of jumps from the unrest).
To me this sounds like an easier way of implementing some form of secession mechanic.
I like this.
-
Regarding Constellation Names,
Can you possibly work up a scheme to generate the names for a non-Known Stars game?
There are no 3D star positions in random games, so no constellations. It would be easier to generate a name theme using all combinations of Greek letters and constellation names, which would provide over 2000 names.
That is more along the lines of what I meant. Something to randomly generate names rather than a static list.
I think that he meant that a player (you or I, for example) could gin up a list of a few thousand names, put them into a text file, and import them as a new name list in a game, without needing him to do anything. It could then presumably be posted as a new system naming theme suggestion (there's a thread somewhere for that purpose).
-
I agree that it would be nice to have it ingame, however, this is something that a good RAND function can already due for you
;D
Happy to write something down and share.
I like the new constallation System, I finally can Quit my labelling all over the galaxy map.
-
Are colony rebellions enabled yet or is that mechanism still being worked on?
So far you have to do it manually through independence. I have played a lot with the mechanic recently and I have understood why is soo hard to implement. out of 5 attempts to just declare independence and change the DB so that the new faction would be led by the AI, only 1 succeded and I still don't really know why or well I guess that the reason was for me to leave it as it was. The problem with that is you have a completely worthless opponent. All the others that involved some sort of help like ships or troops have either: broke the game after a few decades or simply thrown multiple errors every sub pulse click making it unplayable.
I think there is some sort of heavy coding involved to actually make this a mechanic. It would require the NPR to be generated as it was brand new but I don't think people will be happy with a bunch of ships or troops appeared out of nowhere. Unless you happy with just a planet where you need to send ground troops unopposed...
I don't think rebellion has to be a planet declaring independence though. You could have riots and stuff that fire once unrest has been high for a long enough period of time. Installations are destroyed, ground units take casualties, missile stockpiles are rendered useless. Maybe even things in orbit are sabotaged, damaging or destroying ships etc. Unrest could even spread to other planets to the same system and to a lesser extent planets that are in the same sector (based on no. of jumps from the unrest).
To me this sounds like an easier way than implementing some form of secession mechanic.
Declaring independence feels like it should be related to a more novel secession mechanic that is maybe handled on the sector command level (yes I know you could game this by not having sectors). When a sector as a whole has high unrest across multiple worlds/systems it might decide to secede from the empire with planets determining allegiance based on how big and stable they are. If you feel like putting in the work you could also factor in the industrial dependence of a colony to the rest of the empire when factoring this in. This could make it so that instead of individual colonies, entire systems or sections of the empire could secede and become a real pain in the ass as opposed to a lone planet rising up on its own.
I don't know how you'd allocate ships and space installations. It makes sense to make engineless ships switch/stay on the side that their planet has joined. I think its acceptable to spawn somewhat weak but numerous infantry based militias to act as the initial garrison to the new independent worlds depending on population size. You could make the homeworlds of officers as a factor, making officers more likely to attempt to defect their ships to their home sector / planet if its declared independence.
I think for the time being a simple rebellion planet state would be good to at least provide RPers with a prelude to manual independence and to provide players more of an incentive to police their worlds.
Keeping population stability at 100% is really easy. Build warships, build troops and that's about it.
-
Keeping population stability at 100% is really easy. Build warships, build troops and that's about it.
Thats probably something else that will need to be changed. IMO policing is already too powerful on the ground. PPV is less of a problem for me.
It might make sense for every planet above a certain size to start generating a base level of unrest. Events such as work camps/overpopulation should only add to that. There just needs to be more stuff that causes unrest. You could also have it so that planets further away from the capital have a % modifier that increases the amount of unrest they have, which could be reduced if it is part of a sector (more local autonomy?).
Other than that Steve could go mad and implement a full happiness system but I'm kind of thinking of quicker and easier solutions.
-
Regarding Constellation Names,
Can you possibly work up a scheme to generate the names for a non-Known Stars game?
There are no 3D star positions in random games, so no constellations. It would be easier to generate a name theme using all combinations of Greek letters and constellation names, which would provide over 2000 names.
That is more along the lines of what I meant. Something to randomly generate names rather than a static list.
I think that he meant that a player (you or I, for example) could gin up a list of a few thousand names, put them into a text file, and import them as a new name list in a game, without needing him to do anything. It could then presumably be posted as a new system naming theme suggestion (there's a thread somewhere for that purpose).
I may be wrong but I seem to recall system themes to always go straight down the list. perhaps Steve could add an option to randomise that list? Or has he already done that and I missed it?
-
In my opinion it would be nearly impossible to make any political and social unrest model in Aurora either realistic or fun unless it was very complex so it can work well with the plethora of role-play the current system can provide for you.
It is certainly my opinion that you are to play the game using role-play so you can add as much unrest from that standpoint as you like or simulate unhappiness and dissent in multiple ways, especially if you are writing some sort of story around your game.
There are no way to just say a planet should have more or less dissent or unrest just because it is far away or have more or less autonomy... there are many reasons for why a planet would have lots of dissent and unrest or not. Most game just add arbitrary very unrealistic modifiers and limits that have no real basis in reality and I hope that will never get introduce into this game, that would be very unfortunate.
In most of my play-through I role-play heavily so I develop planet in a way I think it would realistically have developed based on economy, needs and the political climate. A self governing world obviously would be as self sufficient as possible while still being able to compete with some speciality versus other planets. I usually use trade goods as one example on how I characterise a planets structure to give me some guidance as one example.
So... I would not be that happy to add lots of arbitrary and none dynamic traits to why planets have lots of dissent or not.... I would be satisfied if the player could just turn it up or down using space master... that would fit this game allot better in my opinion.
-
Keeping population stability at 100% is really easy. Build warships, build troops and that's about it.
Thats probably something else that will need to be changed. IMO policing is already too powerful on the ground. PPV is less of a problem for me.
It might make sense for every planet above a certain size to start generating a base level of unrest. Events such as work camps/overpopulation should only add to that. There just needs to be more stuff that causes unrest. You could also have it so that planets further away from the capital have a % modifier that increases the amount of unrest they have, which could be reduced if it is part of a sector (more local autonomy?).
Other than that Steve could go mad and implement a full happiness system but I'm kind of thinking of quicker and easier solutions.
Population demographics could be a good starting point for setting reasons for unrest. Divide population between different democraphics in the same way a working force is. Naturally democrats don't like authoritarian central government, so a colony composed mostly out of opposite spectrum of your government type would generate unrest on said planet, troops or no troops. Unemployment aka "available workers" also could play a factor in unrest. Unemployment cause unrest which can be mitigated by setting a unemployment support fund which draws from your empire wealth. Of course that's going to be a problem at some point, so maybe options for population growth control could be implemented such as "one/two child policy". Which do have problems of their own of course.
-
I think we mixing up the cakes here. One thing is unrest and another is morale. Low morale could lead to unrest while a specific event could leave to unrest regardless of the morale.
So I will keep this post within the unrest as it is in Aurora without adding anything else.
You have so much that could contribute to unrest in the way Aurora already considers it. I know some could agree with others on this post as they don't think something could be achieved while others would like to make it more interesting. Where I stand will be clear at the end of this post.
Back to the datas, you have at least 5 currently in game right now that could easily contribute in creating an equation able to satisfy many without destroying any mechanic or upset other players. Eventually such mechanic could be made optional through a check box same as the political reliability and realistic promotions.
2 out of 5 are already considered: Protection Value and Slavery (even if this could be objectively buffered a bit with more severe penalties at least).
Then you have:
Unemployment - this is an objective cause of unrest unless you live in an utopia society where people receive a universal wage to basically exist.
Access to trade goods: a shortfall of certain trade goods should cause unrest. Now this is tricky as it also affects civilian companies and such, but again something that could be easily overcome with a little buff lowering requirements perhaps.
Finally population. Same as per unemployment is unreasonable to think that in a society everybody is happy and a minimum of penalty should be applied regardless. Could even be 0.0001% per Mil pop for instance. Will require some testing of course but everything does.
The problem
While in theory all is fantastic and yes let's get more unrest and such there is a problem. At the end of the day all can be solved with more police, more Protection Value, and more and more you get the point.
So unless that can be sorted (and considering how the system is structured now I don't think you can) I don't see any reason why we should touch the system as it is right now. I mean all you are achieving is to build more ground units to counter the higher unrest penalty.
Obviously this is my view and I am sure there are many good ideas ready to change my mind. But these ideas must actually introduce a whole new mechanic and I am sure it will be super interesting but I really would like to have independence to NPR directly or even monetary aids, exchange of ships and such back from VB6 first to be honest before looking into unrest and revolts.
-
I think we mixing up the cakes here. One thing is unrest and another is morale. Low morale could lead to unrest while a specific event could leave to unrest regardless of the morale.
So I will keep this post within the unrest as it is in Aurora without adding anything else.
You have so much that could contribute to unrest in the way Aurora already considers it. I know some could agree with others on this post as they don't think something could be achieved while others would like to make it more interesting. Where I stand will be clear at the end of this post.
Back to the datas, you have at least 5 currently in game right now that could easily contribute in creating an equation able to satisfy many without destroying any mechanic or upset other players. Eventually such mechanic could be made optional through a check box same as the political reliability and realistic promotions.
2 out of 5 are already considered: Protection Value and Slavery (even if this could be objectively buffered a bit with more severe penalties at least).
I feel like while the current unrest mechanic could be a bit more robust, the current system is good in its simplicity. Specifically both are tied to definite causes in-game which the player can directly influence, and the player can approach the causes of unrest in a few different ways to handle them which interact well with the core game mechanics, plus to a certain extent encourage "realistic" play without limiting options. This is a hallmark of good design.
Then you have:
Unemployment - this is an objective cause of unrest unless you live in an utopia society where people receive a universal wage to basically exist.
This is a difficult one. For starters, usually at the start of the game there is a significant unemployed fraction of the population which can be grown into economically or used to found colonies without killing Earth's manufacturing efficiency. This would also be a rather limiting mechanic unless it was toned down so much as to be barely noticeable, since often one will found a colony and populate it well in advance of relocating industry, etc. in order to stay ahead of the ball, so to speak. Finally, in realism terms a certain amount of unemployment is healthy for an economy as it facilitates a balance between labor supply, labor demand, and movement of laborers throughout the economy. In this respect, a flat "unemployment == bad" approach is not realistic, whereas an approach based around (say) a target unemployment fraction would be I think too complex for a mechanic where simplicity is preferable.
Access to trade goods: a shortfall of certain trade goods should cause unrest. Now this is tricky as it also affects civilian companies and such, but again something that could be easily overcome with a little buff lowering requirements perhaps.
This would be horrible to me as a player, because I have little if any way to actually influence trade goods. Besides the fact that only CSLs move these goods, I don't have any direct control over how to produce them to maintain a balance. And frankly, I wouldn't want the ability to do so in the game, because giving the player a knob to jiggle which only has the purpose of preventing Bad Things™ from happening is poor game design. Gameplay is best when it allows the player to work for a positive achievement, and worst when it forces the player to work for the sole purpose of staving off a negative modifier.
Finally population. Same as per unemployment is unreasonable to think that in a society everybody is happy and a minimum of penalty should be applied regardless. Could even be 0.0001% per Mil pop for instance. Will require some testing of course but everything does.
I believe PPV already incorporates a population size effect, larger populations require more PPV, so this would be somewhat redundant. Currently the PPV mechanic works well because it allows the player to address the need via any combination of ships and garrisons which meet the net PPV/unrest reduction needs, thus is quite flexible. A redundant population-based unrest modifier forces the player to maintain larger garrisons on bigger colonies regardless of PPV, which rather eclipses the effectiveness of that mechanic.
The problem
While in theory all is fantastic and yes let's get more unrest and such there is a problem. At the end of the day all can be solved with more police, more Protection Value, and more and more you get the point.
So unless that can be sorted (and considering how the system is structured now I don't think you can) I don't see any reason why we should touch the system as it is right now. I mean all you are achieving is to build more ground units to counter the higher unrest penalty.
Spot-on analysis, except that PPV does not directly reduce unrest. Only ground units do this. Otherwise though completely correct, ultimately all we're accomplishing is forcing the player to station more ground units everywhere. Currently the unrest system encourages this, but does not require it, leaving the player with flexibility to decide how he places his colonial defenses.
Obviously this is my view and I am sure there are many good ideas ready to change my mind. But these ideas must actually introduce a whole new mechanic and I am sure it will be super interesting but I really would like to have independence to NPR directly or even monetary aids, exchange of ships and such back from VB6 first to be honest before looking into unrest and revolts.
Agreed.
Independence directly to NPR is chiefly limited by the AI which presently lacks the ability to develop a strategy in-situ so to speak, i.e. if the AI is suddenly given a colony of basically random development level and ships/ground forces of variable composition, it cannot readily fit these into one of the predefined AI strategy templates and thus cannot use its resources with any effectiveness. Given that the AI when able to follow a preset strategy is...not exactly robust, let's say...I can see why this would be a rather imposing challenge.
-
I think it would be better for this discussion to continue in a separate thread because an overhaul of the PPV/morale system is not currently listed as a change in 1.13.
-
This might not be the correct thread but are there plans to fix naval mines / blind fired active missiles for 1.13?
-
This might not be the correct thread but are there plans to fix naval mines / blind fired active missiles for 1.13?
What is the problem with them? I haven't used them in any of my C# campaigns.
-
They dont target correctly. I dont know the exact bug. EnterElysium explained the issue in one of his videos and im sure its somewhere in the bugs thread.
-
They dont target correctly. I dont know the exact bug. EnterElysium explained the issue in one of his videos and im sure its somewhere in the bugs thread.
This is the issue I was referrencing but I've asked for more detailed comment in the discord. EE also stated that self-guided missiles blind fired with no target would also have problems with targeting. If I get enough details I might be able to do a full bug report.
Edit - Below I'm going to post some discord testimonies over time:
"right now re targeting doesn't work for missiles for whatever reason its a bug"
"right now in C# your missile auto destroys itself if it doesn't have a target regardless of having an active sensor on it"
"even with a sensor on it it won't re target so it means over kill with missiles can be a problem"
-
This might not be the correct thread but are there plans to fix naval mines / blind fired active missiles for 1.13?
What is the problem with them? I haven't used them in any of my C# campaigns.
Version 1.12
The above quote has my experimentation and conclusions regarding the state of active sensor missiles and naval mines posted to the bug thread. I'll delete my post of the experiment from this thread.
-
1 - Despite standing still at the waypoint, the missiles expire after a while - seems like they still consume fuel when stationary (might be WAI for missiles but is a problem for naval mines)
The problem I have found regarding naval mines is that when an enemy fleet enters their sensor range they seek like they are supposed to. But the fact that all "salvos" of mines arrive at the same time means that they can at most destroy one ship as they tend to target the same vessel. This is the same problem that active missiles have.
Afaik mines are multi-stage missiles without an engine, which should therefore stay still in space forever. The first stage has an active sensor set to some trigger range, and if that range is set the second stage triggers (one or more actual short-range missiles). Am I right that what you're describing as mines there is just missiles fired at a waypoint where they'll idle with their timer ticking down until something is in range?
From your tests it sounds like the (re-)targeting behavior makes active missiles or minefields unviable at current anyway.
I haven't tried anything with mines/active sensor missiles in C# myself because they're, well, broken.
Here's a thread (http://aurora2.pentarch.org/index.php?topic=11124.0) of somebody trying to use mines and their results.
-
1 - Despite standing still at the waypoint, the missiles expire after a while - seems like they still consume fuel when stationary (might be WAI for missiles but is a problem for naval mines)
The problem I have found regarding naval mines is that when an enemy fleet enters their sensor range they seek like they are supposed to. But the fact that all "salvos" of mines arrive at the same time means that they can at most destroy one ship as they tend to target the same vessel. This is the same problem that active missiles have.
Afaik mines are multi-stage missiles without an engine, which should therefore stay still in space forever. The first stage has an active sensor set to some trigger range, and if that range is set the second stage triggers (one or more actual short-range missiles). Am I right that what you're describing as mines there is just missiles fired at a waypoint where they'll idle with their timer ticking down until something is in range?
From your tests it sounds like the (re-)targeting behavior makes active missiles or minefields unviable at current anyway.
I haven't tried anything with mines/active sensor missiles in C# myself because they're, well, broken.
Here's a thread (http://aurora2.pentarch.org/index.php?topic=11124.0) of somebody trying to use mines and their results.
The mines I used were single stage and had engines - firing them at a waypoint causes them to eventually expire, no good. Using "launch ready ordnance" seems to make them stay put forever (or maybe my test there was incomplete, but sensor buoys are also deployed like this)
From the way missile hit chance works you need the mine itself to have an engine, otherwise your hit chance will be 0 or damn close to it.
TBH my "mines" and "missiles" here are mechanically identical. All I did was vary the way their deployment was done. IMO stationary missiles without a target should not be running their timer down. That should happen when a target is acquired and movement begins.
I don't fully understand how a multi-stage mine works when it comes to trying to actually hit something.
So think of my mines as "active seekers" that stay put until something comes into range, where they behave as a missile.
-
1 - Despite standing still at the waypoint, the missiles expire after a while - seems like they still consume fuel when stationary (might be WAI for missiles but is a problem for naval mines)
The problem I have found regarding naval mines is that when an enemy fleet enters their sensor range they seek like they are supposed to. But the fact that all "salvos" of mines arrive at the same time means that they can at most destroy one ship as they tend to target the same vessel. This is the same problem that active missiles have.
Afaik mines are multi-stage missiles without an engine, which should therefore stay still in space forever. The first stage has an active sensor set to some trigger range, and if that range is set the second stage triggers (one or more actual short-range missiles). Am I right that what you're describing as mines there is just missiles fired at a waypoint where they'll idle with their timer ticking down until something is in range?
From your tests it sounds like the (re-)targeting behavior makes active missiles or minefields unviable at current anyway.
I haven't tried anything with mines/active sensor missiles in C# myself because they're, well, broken.
Here's a thread (http://aurora2.pentarch.org/index.php?topic=11124.0) of somebody trying to use mines and their results.
Steve, currently second stage missiles, mines (not tested yet as general mine concept doesn't work so no point), and retarget or multi stage in general works only under an active MFC range.
I think it's fine for missiles to avoid cheaty designs of 500mkm range missile magically find its target out of a Waypoint making MFC useless otherwise so I would say WAI, however, it's impacting the mines design which are probably operating under the same rule. I dont know if you have changed something from the vb6 code, only you can answer/know that.
All other tests and attempts have failed.
Sensor buoys and Geo Probes do work fine.
-
1 - Despite standing still at the waypoint, the missiles expire after a while - seems like they still consume fuel when stationary (might be WAI for missiles but is a problem for naval mines)
The problem I have found regarding naval mines is that when an enemy fleet enters their sensor range they seek like they are supposed to. But the fact that all "salvos" of mines arrive at the same time means that they can at most destroy one ship as they tend to target the same vessel. This is the same problem that active missiles have.
Afaik mines are multi-stage missiles without an engine, which should therefore stay still in space forever. The first stage has an active sensor set to some trigger range, and if that range is set the second stage triggers (one or more actual short-range missiles). Am I right that what you're describing as mines there is just missiles fired at a waypoint where they'll idle with their timer ticking down until something is in range?
From your tests it sounds like the (re-)targeting behavior makes active missiles or minefields unviable at current anyway.
I haven't tried anything with mines/active sensor missiles in C# myself because they're, well, broken.
Here's a thread (http://aurora2.pentarch.org/index.php?topic=11124.0) of somebody trying to use mines and their results.
Steve, currently second stage missiles, mines (not tested yet as general mine concept doesn't work so no point), and retarget or multi stage in general works only under an active MFC range.
I think it's fine for missiles to avoid cheaty designs of 500mkm range missile magically find its target out of a Waypoint making MFC useless otherwise so I would say WAI, however, it's impacting the mines design which are probably operating under the same rule. I dont know if you have changed something from the vb6 code, only you can answer/know that.
All other tests and attempts have failed.
Sensor buoys and Geo Probes do work fine.
Missiles expiring at waypoints is fine since mines/sensor buoy placement actually works without waypoints, simultaneous salvos not properly re-targeting is not. Being forced to stagger launches makes PD un-penetrable for these missile/mine types.
-
1 - Despite standing still at the waypoint, the missiles expire after a while - seems like they still consume fuel when stationary (might be WAI for missiles but is a problem for naval mines)
The problem I have found regarding naval mines is that when an enemy fleet enters their sensor range they seek like they are supposed to. But the fact that all "salvos" of mines arrive at the same time means that they can at most destroy one ship as they tend to target the same vessel. This is the same problem that active missiles have.
Afaik mines are multi-stage missiles without an engine, which should therefore stay still in space forever. The first stage has an active sensor set to some trigger range, and if that range is set the second stage triggers (one or more actual short-range missiles). Am I right that what you're describing as mines there is just missiles fired at a waypoint where they'll idle with their timer ticking down until something is in range?
From your tests it sounds like the (re-)targeting behavior makes active missiles or minefields unviable at current anyway.
I haven't tried anything with mines/active sensor missiles in C# myself because they're, well, broken.
Here's a thread (http://aurora2.pentarch.org/index.php?topic=11124.0) of somebody trying to use mines and their results.
Steve, currently second stage missiles, mines (not tested yet as general mine concept doesn't work so no point), and retarget or multi stage in general works only under an active MFC range.
I think it's fine for missiles to avoid cheaty designs of 500mkm range missile magically find its target out of a Waypoint making MFC useless otherwise so I would say WAI, however, it's impacting the mines design which are probably operating under the same rule. I dont know if you have changed something from the vb6 code, only you can answer/know that.
All other tests and attempts have failed.
Sensor buoys and Geo Probes do work fine.
Missiles expiring at waypoints is fine since mines/sensor buoy placement actually works without waypoints, simultaneous salvos not properly re-targeting is not. Being forced to stagger launches makes PD un-penetrable for these missile/mine types.
all I know is that compared to vb6 everything seems to work fine/same but mines. The reasons are yet unknown.
I am sure from time to time Steve may look into it but as it does not really use them he is just prioritizing other things which it's fine.
-
all I know is that compared to vb6 everything seems to work fine/same but mines.
My point is that its not just mines but active missiles too that are borked.
-
I just wanted to clarify, does the armour repair that happens in hangers cost MSP or is it free?
-
I just wanted to clarify, does the armour repair that happens in hangers cost MSP or is it free?
It costs MSP
-
Possibly a dumb question, but how to the RP modules fit in to damage?
Ignored/excluded or damageable?
-
They will probably be a 1 hit to destroy kinda thing.
-
Possibly a dumb question, but how to the RP modules fit in to damage?
Ignored/excluded or damageable?
The HTK is equal to the square root of the size. I've updated the rules post with that information.
-
Sorry for possibly dumb question, but what is the use of larger shield generators? If I may judge from the post (http://aurora2.pentarch.org/index.php?topic=8495.msg102769#msg102769), they are simultaneously more expensive (BC, TNM require, RC) and more vulnerable per size sum, having no advantage I can see comparable to stacked smaller generators.
-
Sorry for possibly dumb question, but what is the use of larger shield generators? If I may judge from the post (http://aurora2.pentarch.org/index.php?topic=8495.msg102769#msg102769), they are simultaneously more expensive (BC, TNM require, RC) and more vulnerable per size sum, having no advantage I can see comparable to stacked smaller generators.
Not really the right thread (better to ask in the thread for small questions), but the answer is that larger shield generators have a shield output bonus.
2xsize 10 generators produce a weaker shield than 1xsize 20 generator.
-
Sorry for possibly dumb question, but what is the use of larger shield generators? If I may judge from the post (http://aurora2.pentarch.org/index.php?topic=8495.msg102769#msg102769), they are simultaneously more expensive (BC, TNM require, RC) and more vulnerable per size sum, having no advantage I can see comparable to stacked smaller generators.
You gain more shield strength the larger the shield generator is... SQRT(HS/10) times the shield strength.
So a strength 3 size 5 shield have 10.6 shield points and a size 20 have 84.8 shield points.
They both recharge the same amount of points per 5 sec interval for their size though.
-
Aw. "Normal strength" is a strength per ton, not a strength of 10HS generator!
-
Aw. "Normal strength" is a strength per ton, not a strength of 10HS generator!
It is the normal strength per HS of shield generator which is *1 at size 10 due to the formula. So a strength 3 size 10 shield generator have 30 shield point (strength 3 times 10 HS).
-
Steve can you clarify something for me with the repair yards, can the yards provide the ability for you to overhaul ships? If so this gives me a lot of ideas and uses for forward operating bases that can have repair yards, or secondary colonies with repair yards that have ships stationed there.
-
Note that as Repair Yards are upgraded like commercial shipyards, they are faster and cheaper to construct than a naval shipyard with the same capacity. They provide a much cheaper option for military repair capacity, allowing naval shipyards to focus on construction. The cost of a specific ship repair will remain the same in all types of shipyard.
This will be lovely for making distant naval outposts easier to set up, very nice.
Steve can you clarify something for me with the repair yards, can the yards provide the ability for you to overhaul ships? If so this gives me a lot of ideas and uses for forward operating bases that can have repair yards, or secondary colonies with repair yards that have ships stationed there.
Maintenance facilities and MSP are required for an overhaul, not shipyards. I can't recall if you also need a spaceport, but in any case the shipyard is not used for overhauls.
-
am misremembering then, my bad, but yea this is a really nice addition.
-
How many workers will the new repair yards need per tonnage of ship serviced?
Will it be less than naval yards?
Edit: Nvm I just re-read the post, same as commercial
-
I assume it will now not possible to repair ships in normal shipyards, correct?
If not, has the displacement bug been fixed?
-
Steve can you clarify something for me with the repair yards, can the yards provide the ability for you to overhaul ships? If so this gives me a lot of ideas and uses for forward operating bases that can have repair yards, or secondary colonies with repair yards that have ships stationed there.
No, they are still shipyards, not maintenance facilities.
-
I assume it will now not possible to repair ships in normal shipyards, correct?
If not, has the displacement bug been fixed?
You can still repair as normal in naval and commercial shipyards. I've fixed the size bug as per the change log. Shipyards can no longer repair ships larger than their capacity and commercial shipyards can no longer repair military ships.
-
I assume it will now not possible to repair ships in normal shipyards, correct?
If not, has the displacement bug been fixed?
You can still repair as normal in naval and commercial shipyards. I've fixed the size bug as per the change log. Shipyards can no longer repair ships larger than their capacity and commercial shipyards can no longer repair military ships.
Thanks, I did not read the changelog. My bad!
I really like the new addition.
-
What will the cost of Repair Yards be as you can build a Commercial Hangar station for around 1100 BP to service 10.000t I assume that repair yards will be at least this cheap as they will require people to operate but are a bit more flexible than a station in regards to upgrading them?
But if they become too expensive you probably still would settle for commercial hangar stations most of the time as they also can be towed to any point in space and repair ships as well.
Stations can't scrap ships but I don't think that is a huge drawback in general.
-
What will the cost of Repair Yards be as you can build a Commercial Hangar station for around 1100 BP to service 10.000t I assume that repair yards will be at least this cheap as they will require people to operate but are a bit more flexible than a station in regards to upgrading them?
But if they become too expensive you probably still would settle for commercial hangar stations most of the time as they also can be towed to any point in space and repair ships as well.
Stations can't scrap ships but I don't think that is a huge drawback in general.
They are the same cost as a commercial shipyard. As you say, they are very flexible because you can upgrade them and they can also scrap ships. Also, repairing significant damage in a commercial hangar uses a lot of MSP, which is a finite resource, whereas the repair yard uses minerals, like any other shipyard. Finally, they don't need any special technology so you can build them at the start of the game.
-
This is a really great addition. No moe shipyards occupied for repairing or scrapping, plus since it's cheaper you can build and tow these to important places.
I love this change
-
Oh so i can create the full on equivalent to Kuat Drive Yards now? Awesome. ;D
-
What will the cost of Repair Yards be as you can build a Commercial Hangar station for around 1100 BP to service 10.000t I assume that repair yards will be at least this cheap as they will require people to operate but are a bit more flexible than a station in regards to upgrading them?
But if they become too expensive you probably still would settle for commercial hangar stations most of the time as they also can be towed to any point in space and repair ships as well.
Stations can't scrap ships but I don't think that is a huge drawback in general.
They are the same cost as a commercial shipyard. As you say, they are very flexible because you can upgrade them and they can also scrap ships. Also, repairing significant damage in a commercial hangar uses a lot of MSP, which is a finite resource, whereas the repair yard uses minerals, like any other shipyard. Finally, they don't need any special technology so you can build them at the start of the game.
I think it's a decent idea, a useful addition for a major fleet base but not something you'd want or need dozens of.
I'd kind of like it to do overhauls as well (consuming minerals equal to the MSP cost), I think it would fit thematically although I understand why you didn't.
-
I'd also kindof like if it was capable of overhaul though IMO it should probably be considered wasteful compared to using a maint facility. Like, the repair yard that is capable of opening up a ships guts and pulling out and replacing major components could also conceivably do overhaul work, but its a waste of its time and should take up yard space while its ongoing (also IMO it should probably need MSP in order to conduct that kind of maintenance and just not have any innate ability to make MSP). At any rate I think it would make logical sense that the yard would be capable of it.
-
Will the new Repair Yard for v1.13 be able to scrap non-engined Tractorable Stations when these become obsolete and new versions have been introduced ?
( assuming the Yard tonnage is sufficient. )
DavidR
-
Will the new Repair Yard for v1.13 be able to scrap non-engined Tractorable Stations when these become obsolete and new versions have been introduced ?
( assuming the Yard tonnage is sufficient. )
DavidR
They function in every way as a normal shipyard, except they can't construct or refit ships.
-
The 'Obso Comp' button on the Class window is only visible for race-designed components. It will not appear for basic components such as Bridge, Engineering, etc..
Does this apply to components like refueling systems, which are not designed but are directly upgraded by research?
-
The 'Obso Comp' button on the Class window is only visible for race-designed components. It will not appear for basic components such as Bridge, Engineering, etc..
Does this apply to components like refueling systems, which are not designed but are directly upgraded by research?
Good point - I've changed it so obsolete will be available for race-designed components or basic components with multiple generations.
-
Will the single-weapon fire controls be usable with all turreted versions of the weapon?
So could a fire control meant for a single gauss cannon also be used for a twin or quad-linked turreted version of said gauss cannon?
-
Will the single-weapon fire controls be usable with all turreted versions of the weapon?
So could a fire control meant for a single gauss cannon also be used for a twin or quad-linked turreted version of said gauss cannon?
Yes.
-
The new fire at will option seems like it could save a lot of micromanagement for fighters and such.
Was that what motivated you to add it?
-
The new fire at will option seems like it could save a lot of micromanagement for fighters and such.
Was that what motivated you to add it?
My campaign in which I was doing really well, suddenly took an unexpected turn. Now I need to react quickly to a lot of small, deadly ships :)
-
The new fire at will option seems like it could save a lot of micromanagement for fighters and such.
Was that what motivated you to add it?
My campaign in which I was doing really well, suddenly took an unexpected turn. Now I need to react quickly to a lot of small, deadly ships :)
To this effect wouldn't it be useful to have auto target not be on a per-ship basis but also have a variant of auto-target that does it on a per-BFC basis?
Many of my ships split even their larger guns into multiple BFCs to achieve multi-targeting ability but auto target only assigns targets per-ship (BFCs on the same ship attack the same target)
-
The new fire at will option seems like it could save a lot of micromanagement for fighters and such.
Was that what motivated you to add it?
My campaign in which I was doing really well, suddenly took an unexpected turn. Now I need to react quickly to a lot of small, deadly ships :)
To this effect wouldn't it be useful to have auto target not be on a per-ship basis but also have a variant of auto-target that does it on a per-BFC basis?
Many of my ships split even their larger guns into multiple BFCs to achieve multi-targeting ability but auto target only assigns targets per-ship (BFCs on the same ship attack the same target)
A way to determine how much to allocate to each target would be needed then. For example, if a ship has both large "primary" beam weapons and a set of smaller "secondary" weapons, how do you make sure the different sizes of guns get the right target. Or if you have a massive enemy ship and some enemy FACs, how do you ensure most of the firepower is allocated to the big ship
-
The new fire at will option seems like it could save a lot of micromanagement for fighters and such.
Was that what motivated you to add it?
My campaign in which I was doing really well, suddenly took an unexpected turn. Now I need to react quickly to a lot of small, deadly ships :)
To this effect wouldn't it be useful to have auto target not be on a per-ship basis but also have a variant of auto-target that does it on a per-BFC basis?
Many of my ships split even their larger guns into multiple BFCs to achieve multi-targeting ability but auto target only assigns targets per-ship (BFCs on the same ship attack the same target)
A way to determine how much to allocate to each target would be needed then. For example, if a ship has both large "primary" beam weapons and a set of smaller "secondary" weapons, how do you make sure the different sizes of guns get the right target. Or if you have a massive enemy ship and some enemy FACs, how do you ensure most of the firepower is allocated to the big ship
Well separating primary from secondary armament would be really hard and I don't really mind microing that to fix it. However it is easy to separate BFCs with active PD modes from anti-ship weapons. That is the only distinction I really need.
-
The new Fire-at-will rule will select a random target for each BFC on that ship. A long as you set your different weapons to different BFC you should be fine.
I also think that weapons will follow the normal structure of fire... which should make it so that PD opportunities go before firing on an enemy ship. That is your ship will fire on any potential missiles using final fire before firing your weapons at an enemy ship. I presume you can set your weapons that have the heavy beams to never fire on missiles or at least only fire if the missiles are targeted at that ship specifically.
-
The new Fire-at-will rule will select a random target for each BFC on that ship. A long as you set your different weapons to different BFC you should be fine.
I also think that weapons will follow the normal structure of fire... which should make it so that PD opportunities go before firing on an enemy ship. That is your ship will fire on any potential missiles using final fire before firing your weapons at an enemy ship. I presume you can set your weapons that have the heavy beams to never fire on missiles or at least only fire if the missiles are targeted at that ship specifically.
I do this in my current campaign. The multi-use railguns will fire on missiles if needed and on enemy ships otherwise. The heavy lasers will ignore missiles and only fire on hostile ships. You can do the same with fire-at-will because only the targeting changes, not the point defence status.
-
I have to admit, I'm not sure I will do anything BUT fire at will, except in rare situations where I need to optimize my damage against larger forces.
-
I really like the Fire at will option. I will probably set all my beam weapons to use it.
-
I have to admit, I'm not sure I will do anything BUT fire at will, except in rare situations where I need to optimize my damage against larger forces.
Fire at will sounds like the old auto-target we had in Vb6 but better
-
Does it overkill targets or do they retarget the rest of the beams that tick once the closest thing dies?
-
Does it overkill targets or do they retarget the rest of the beams that tick once the closest thing dies?
I would suspect they overkill. That would be the fair and reasonable way to do it, just like normal targetting.
-
It would, but it does kindof move it into the 'off the table' category for me just because i feel like the majority of ships would all fire on the nearest target and massively overkill it.
-
It would, but it does kindof move it into the 'off the table' category for me just because i feel like the majority of ships would all fire on the nearest target and massively overkill it.
But the targeting is random with a weighted system. So while you will eventually get some overkill your ships should spread out the fire quite effectively otherwise.
-
What he described implies that something substantially in front of the other targets would hugely throw off the weighting. It'd be fine if remaining shots reallocated but it sounds like they wont.
-
What he described implies that something substantially in front of the other targets would hugely throw off the weighting. It'd be fine if remaining shots reallocated but it sounds like they wont.
But all shots are fired simultaneously in any 5s increment, at least in an abstract sense. It would make no sense that you should be able to re-target once a target is decided for each fire-control in that time frame, that decision is based by the crews judgement. I also saw not indication for how the weighting system would work... I got the impression that it would become fairly random with a preference for any fire-control to target that which it are most likely to do most damage to.
In my opinion PD should work the same way... even if that would make PD less effective in general. But then again I think that the howl missile salvo mechanic need to be overhauled at some point anyway as full sized launchers versus box launched salvos is an anaemic issue in my opinion.
-
What he described implies that something substantially in front of the other targets would hugely throw off the weighting. It'd be fine if remaining shots reallocated but it sounds like they wont.
Another option is just triggering it in sequential increments (Jump point ambush: 1, TRAP, 3 ships FaW, click 5secs 2, 4 ships FaW, click 5sec, repeat). If I am misunderstanding it, then another option is having the lowest-graded ships FaW while the experienced ships hit targets that are less likely to be hit. If you are dying to JP ambush, overkilling is way better than killing no ships due to fire delay.
-
What he described implies that something substantially in front of the other targets would hugely throw off the weighting. It'd be fine if remaining shots reallocated but it sounds like they wont.
But all shots are fired simultaneously in any 5s increment, at least in an abstract sense. It would make no sense that you should be able to re-target once a target is decided for each fire-control in that time frame, that decision is based by the crews judgement. I also saw not indication for how the weighting system would work... I got the impression that it would become fairly random with a preference for any fire-control to target that which it are most likely to do most damage to.
In my opinion PD should work the same way... even if that would make PD less effective in general. But then again I think that the howl missile salvo mechanic need to be overhauled at some point anyway as full sized launchers versus box launched salvos is an anaemic issue in my opinion.
It would be perfectly reasonable to say that a degree of computer control is involved and the delay is purely down to the crew trying to make sense of the sensor data and pick out particular targets. So in other words both PD (and maybe free fire mode) could fire in a very rapid sequence in a coordinated fashion that doesn't involve humans but also doesn't involve human decision making as to target priority.
What he described implies that something substantially in front of the other targets would hugely throw off the weighting. It'd be fine if remaining shots reallocated but it sounds like they wont.
Another option is just triggering it in sequential increments (Jump point ambush: 1, TRAP, 3 ships FaW, click 5secs 2, 4 ships FaW, click 5sec, repeat). If I am misunderstanding it, then another option is having the lowest-graded ships FaW while the experienced ships hit targets that are less likely to be hit. If you are dying to JP ambush, overkilling is way better than killing no ships due to fire delay.
Thats kindof an edge case for me since my general understanding is it doesn't actually bypass jump shock, just the delay related to a lack of training.
-
It would be perfectly reasonable to say that a degree of computer control is involved and the delay is purely down to the crew trying to make sense of the sensor data and pick out particular targets. So in other words both PD (and maybe free fire mode) could fire in a very rapid sequence in a coordinated fashion that doesn't involve humans but also doesn't involve human decision making as to target priority.
I don't even thing that an advanced AI would be able to shoot... assess battle damage and then assign an new target all in a five second time frame... that would require some sort of advanced knowledge of the outcome in advance.
It is more realistic that fire are done per five second increment... even being able to asses battle damage in just five seconds to know if something is destroyed/damages and how much is asking allot to be honest.
It is a game and I understand that some measure of abstraction need to be done. I guess this is more to do with wanting efficiency not really being realistic. Personally I like the issues with simulation so I'm in favor of more obstruction to picking targets in general.
-
It is a game and I understand that some measure of abstraction need to be done. I guess this is more to do with wanting efficiency not really being realistic. Personally I like the issues with simulation so I'm in favor of more obstruction to picking targets in general.
It's also sensible that an automation feature (which this is) should be less effective than human micromanagement. If the automation can perform perfectly, there is no reason for the human to ever play that part of the game. It sounds like the feature as implemented will be simple and good enough that players shouldn't have to micromanage too much to avoid blindingly stupid outcomes, which I think is the goal.
-
It would be perfectly reasonable to say that a degree of computer control is involved and the delay is purely down to the crew trying to make sense of the sensor data and pick out particular targets. So in other words both PD (and maybe free fire mode) could fire in a very rapid sequence in a coordinated fashion that doesn't involve humans but also doesn't involve human decision making as to target priority.
I don't even thing that an advanced AI would be able to shoot... assess battle damage and then assign an new target all in a five second time frame... that would require some sort of advanced knowledge of the outcome in advance.
It is more realistic that fire are done per five second increment... even being able to asses battle damage in just five seconds to know if something is destroyed/damages and how much is asking allot to be honest.
It is a game and I understand that some measure of abstraction need to be done. I guess this is more to do with wanting efficiency not really being realistic. Personally I like the issues with simulation so I'm in favor of more obstruction to picking targets in general.
I would agree with you if battle damage assessment appeared to have anything to do with crew, but it does not it is instantaneous for all intents and purposes. Also generally if the target separates into multiple pieces you don't need AI to figure out it was destroyed and modern radars are capable of figuring that out without human intervention. What you are suggesting is fairly old fashioned and unlikely to really be a thing in the future, let alone in a fully space faring civilization.
-
It would be perfectly reasonable to say that a degree of computer control is involved and the delay is purely down to the crew trying to make sense of the sensor data and pick out particular targets. So in other words both PD (and maybe free fire mode) could fire in a very rapid sequence in a coordinated fashion that doesn't involve humans but also doesn't involve human decision making as to target priority.
I don't even thing that an advanced AI would be able to shoot... assess battle damage and then assign an new target all in a five second time frame... that would require some sort of advanced knowledge of the outcome in advance.
It is more realistic that fire are done per five second increment... even being able to asses battle damage in just five seconds to know if something is destroyed/damages and how much is asking allot to be honest.
It is a game and I understand that some measure of abstraction need to be done. I guess this is more to do with wanting efficiency not really being realistic. Personally I like the issues with simulation so I'm in favor of more obstruction to picking targets in general.
I would agree with you if battle damage assessment appeared to have anything to do with crew, but it does not it is instantaneous for all intents and purposes. Also generally if the target separates into multiple pieces you don't need AI to figure out it was destroyed and modern radars are capable of figuring that out without human intervention. What you are suggesting is fairly old fashioned and unlikely to really be a thing in the future, let alone in a fully space faring civilization.
Battle damage assessment in the game is not realistic... it is a convenient abstraction for ease of play. It is physically impossible to get that accurate battle damage assessment within that time frame in reality no matter what technology you would be using. ;)
A ship does not have to actually explode to be a complete loss, so knowing a damaged ship from a lost one could be very difficult to know in real life, especially in space as they don't "sink" anywhere.
The fact that crew can get to the escape pods in a five second increment also is unrealistic and just an abstraction of the combat mechanic.
You could try and play games such as "Command: Modern Operations" which probably are as realistic you can get from that perspective on modern warfare. Battle damage is quite literally part of the game and it can take quite some time to know how much damage any type of attack did in many circumstances.
In real life target acquisition outside imminent threat usually have to go through some sort of command chain... if you need to coordinate ships in a fleet you need to respect the command chain to some degree as well to coordinate fire between ships their squadron or the entire task-force or even worse an entire fleet of dozens or more ships.
The fire at will rule... sort of abstract the chain of command away so each captain or weapons officer in charge of that targeting array make the decision on the fly, this is also an abstraction.
-
The fire at will rule... sort of abstract the chain of command away so each captain or weapons officer in charge of that targeting array make the decision on the fly, this is also an abstraction.
Yes, this is the intention. The assumption is that each ship makes its own decision independent of the decisions of other ships. There will be overkill and if there are a lot of targets, it is likely that some won't be hit at all. However, you can issue a new fire at will order once a few enemy ships are destroyed. You can also use manual targeting for those ships with good training and only use fire-at-will for less experienced ships.
I've used it in action and it worked as intended; loss of precise control in exchange for speed of action.
-
The fire at will rule... sort of abstract the chain of command away so each captain or weapons officer in charge of that targeting array make the decision on the fly, this is also an abstraction.
Yes, this is the intention. The assumption is that each ship makes its own decision independent of the decisions of other ships. There will be overkill and if there are a lot of targets, it is likely that some won't be hit at all. However, you can issue a new fire at will order once a few enemy ships are destroyed. You can also use manual targeting for those ships with good training and only use fire-at-will for less experienced ships.
I've used it in action and it worked as intended; loss of precise control in exchange for speed of action.
With this new rule I also think that giving ships direct order should give a order delay of at minimum 5 second increment and only "Fire at Will" will enable weapons to retarget between two increments.
I have always been a proponent that fleet training should never reduce the reaction to zero to begin with though.
-
The fire at will rule... sort of abstract the chain of command away so each captain or weapons officer in charge of that targeting array make the decision on the fly, this is also an abstraction.
Yes, this is the intention. The assumption is that each ship makes its own decision independent of the decisions of other ships. There will be overkill and if there are a lot of targets, it is likely that some won't be hit at all. However, you can issue a new fire at will order once a few enemy ships are destroyed. You can also use manual targeting for those ships with good training and only use fire-at-will for less experienced ships.
I've used it in action and it worked as intended; loss of precise control in exchange for speed of action.
Do ships only pick targets when you press the "fire at will" button? IE if my cruiser has fire at will enabled, and kills the ship it chose to target, will it not automatically choose a new target?
If that is the case, can you make it so ships automatically pick new targets when their original target dies? Maybe have it work like the defensive fire commands?
-
Do ships only pick targets when you press the "fire at will" button? IE if my cruiser has fire at will enabled, and kills the ship it chose to target, will it not automatically choose a new target?
If that is the case, can you make it so ships automatically pick new targets when their original target dies? Maybe have it work like the defensive fire commands?
No, they don't automatically pick targets. Because each fire control is targeting separately and changing targets resets fire delay for the ship, you wouldn't want one fire control changing and causing delay for the others.
Maybe I could add a new 'continuous fire' order for ships that did that, if they were happy to accept the delays.
-
Do ships only pick targets when you press the "fire at will" button? IE if my cruiser has fire at will enabled, and kills the ship it chose to target, will it not automatically choose a new target?
If that is the case, can you make it so ships automatically pick new targets when their original target dies? Maybe have it work like the defensive fire commands?
No, they don't automatically pick targets. Because each fire control is targeting separately and changing targets resets fire delay for the ship, you wouldn't want one fire control changing and causing delay for the others.
Maybe I could add a new 'continuous fire' order for ships that did that, if they were happy to accept the delays.
Oh, fire delay isn't per fire control?
-
Maybe I could add a new 'continuous fire' order for ships that did that, if they were happy to accept the delays.
IIRC you had something similar in VB6, I would massively appreciated if you added a continuous fire command that would make beamers automatically switch to a fresh target after their original has been destroyed.
Bonus points if it's on an FC-wise basis as opposed to ship-wise but the latter would be good enough regardless.
-
Do ships only pick targets when you press the "fire at will" button? IE if my cruiser has fire at will enabled, and kills the ship it chose to target, will it not automatically choose a new target?
If that is the case, can you make it so ships automatically pick new targets when their original target dies? Maybe have it work like the defensive fire commands?
No, they don't automatically pick targets. Because each fire control is targeting separately and changing targets resets fire delay for the ship, you wouldn't want one fire control changing and causing delay for the others.
Maybe I could add a new 'continuous fire' order for ships that did that, if they were happy to accept the delays.
Wow, I really thought that was what 'fire at will' did. I guess I was confused.
Yes, please, something like 'continuous fire' would be amazing. The extra cost would more than worth paying just to avoid the constant micro of target assignment.
-
Battle damage assessment in the game is not realistic... it is a convenient abstraction for ease of play. It is physically impossible to get that accurate battle damage assessment within that time frame in reality no matter what technology you would be using. ;)
A ship does not have to actually explode to be a complete loss, so knowing a damaged ship from a lost one could be very difficult to know in real life, especially in space as they don't "sink" anywhere.
The fact that crew can get to the escape pods in a five second increment also is unrealistic and just an abstraction of the combat mechanic.
You could try and play games such as "Command: Modern Operations" which probably are as realistic you can get from that perspective on modern warfare. Battle damage is quite literally part of the game and it can take quite some time to know how much damage any type of attack did in many circumstances.
In real life target acquisition outside imminent threat usually have to go through some sort of command chain... if you need to coordinate ships in a fleet you need to respect the command chain to some degree as well to coordinate fire between ships their squadron or the entire task-force or even worse an entire fleet of dozens or more ships.
The fire at will rule... sort of abstract the chain of command away so each captain or weapons officer in charge of that targeting array make the decision on the fly, this is also an abstraction.
I aknowledge that Steve has basically stated that he is with you on this, but you will note that there is no protracted BDA phase for objects that are flying around in an open environment where radar can clearly see them, you know more or less immediately if they are dead or not.
I do also consider the escape pods to be pretty much reasonable as just a very high tech version of ejection seats that move people off of the ship as quickly as possible (again on an automated basis).
-
I aknowledge that Steve has basically stated that he is with you on this, but you will note that there is no protracted BDA phase for objects that are flying around in an open environment where radar can clearly see them, you know more or less immediately if they are dead or not.
I do also consider the escape pods to be pretty much reasonable as just a very high tech version of ejection seats that move people off of the ship as quickly as possible (again on an automated basis).
Well... I just don't agree that any of that is practically realistic in the slightest in general, ships in Aurora are not really fighter jets... but let's just leave it at that.
-
You could always think of it as interfaced escape pods. I. e. As the captain sounds general quarters (battle quarters, etc. ) and battle lighting flicks on, all personnel other than direct damage control personnel would immediately head for their escape pods. Each escape pod would have wired in terminals for each person that is strapped in, and would be able to do their combat jobs from there. You would be able to immediately eject in the event of an "abandon ship" order. Internal sensors would be able to give basic damage reports on the fly, and for armor damage reports, simple radar density scanners placed on the internal parts of the armor would be able to tell you how thick the armor is, similar to what we use currently for geological surveys today. Given that the computers onboard would know how thick the armor should be and it's density, you could compare the scanner data to the given and, get armor damage reports "on the fly" as well.
Just my two cents, sorry if this was inappropriate, I don't mean to get in the way.
-
You could always think of it as interfaced escape pods. I. e. As the captain sounds general quarters (battle quarters, etc. ) and battle lighting flicks on, all personnel other than direct damage control personnel would immediately head for their escape pods. Each escape pod would have wired in terminals for each person that is strapped in, and would be able to do their combat jobs from there. You would be able to immediately eject in the event of an "abandon ship" order. Internal sensors would be able to give basic damage reports on the fly, and for armor damage reports, simple radar density scanners placed on the internal parts of the armor would be able to tell you how thick the armor is, similar to what we use currently for geological surveys today. Given that the computers onboard would know how thick the armor should be and it's density, you could compare the scanner data to the given and, get armor damage reports "on the fly" as well.
Just my two cents, sorry if this was inappropriate, I don't mean to get in the way.
That's basically what I assume actually. If you've ever read "The Algebraist" there is a segment in that book that discusses an engagement between some fairly advanced human spacecraft and some nasty aliens. One item of interest was the use of sealed 'combat pods' which contained a single crew member suspended in some sort of shock gel and connected to the ship's weapon systems via a neural computer link. I've always thought that type of a setup translated pretty well to Aurora's life pod situation.
-
I just always assumed the escape pods didn't launch instantly; considering they're directly on top of the wreck, we don't actually know that they are. In fact, we don't even know they're separate vehicles; they could be armored citadels that simply withstand the destruction of the ship. Ships do this in real life sometimes; three sailors were trapped on the USS West Virginia after it was sunk at Pearl Harbor. They survived for a long time, 3 weeks iirc, stuck in that shelter. For all we know that kind of thing happens in Aurora too.
-
I just always assumed the escape pods didn't launch instantly; considering they're directly on top of the wreck, we don't actually know that they are. In fact, we don't even know they're separate vehicles; they could be armored citadels that simply withstand the destruction of the ship. Ships do this in real life sometimes; three sailors were trapped on the USS West Virginia after it was sunk at Pearl Harbor. They survived for a long time, 3 weeks iirc, stuck in that shelter. For all we know that kind of thing happens in Aurora too.
In fairness that makes a degree of sense, for me pods leaving is more logical since city-destroying levels of weaponry are involved, but at the same time you can have a ship suffer an armor penetrating hit and not immediately vaporize the whole crew, which rather implies that the ships have compartmentalization adequate to deal with that to some extent. It seems to me both theories work with the information at hand (though I do think the wording leans towards the pods leaving the ship, particularly since the pods are separate objects and would remain if the wreck itself was salvaged or something before they expired).
It does also sound a little cooler to me just because I like the idea of SAR ships cruising up to a wreck and pulling people out of it...
-
I would imagine the nuclear weapons that destroy ships would also blow up any loose escape pods. I mean, can a pod really get far enough away from a ship suffering a magazine detonation to survive? If it can, it kinda makes you wonder why they didn't make the magazine out of the same stuff as the escape pod.
-
I would imagine the nuclear weapons that destroy ships would also blow up any loose escape pods. I mean, can a pod really get far enough away from a ship suffering a magazine detonation to survive? If it can, it kinda makes you wonder why they didn't make the magazine out of the same stuff as the escape pod.
- I mean, but would they need to be? Any concussive blast, they would need be only strong enough to ride it out. Radiation / Thermal Output, they'd need only sufficient insulation to survive until it dissipated. How much ship is between them and the magazine? That's a broad statement to be honest...
-
The damage of even nuclear explosions drops off relatively quickly in space. Most of the damage nukes do is caused by the blast wave and the fact that the air is being superheated or whatever. Given that even civilian ships can survive small (Strength 1) nukes, I would expect that armoring life pods enough that proximity explosions won't usually kill them would actually be quite feasible, especially since the armor only needs to work once.
-
I think it would depend on how much warning the pods have that the magazines are about to go and how quickly they can move as to whether opening the distance is better than staying put. Notably its an inverse square law so the first little bit of distance is going to have huge marginal gains over staying put.
-
We now need something for gauss cannons maybe?
Is not Gauss Cannon's thing, that they do not suffer failures?
Or am I incorrect in that account
Is this true in v1. 13. 0?
-
The damage of even nuclear explosions drops off relatively quickly in space. Most of the damage nukes do is caused by the blast wave and the fact that the air is being superheated or whatever.
In fact it's quite reverse: the damage of nuclear explosions drops much faster in air, than in vacuum, because in vacuum nearly all of explosion's energy is moving as spherical wave (so depressing at 1/r^2), while in air it's boiling in all the volume of this sphere (so depressing nearly at 1/r^3).
The main damaging factor of nuke in vacuum is very dense gamma wave. Gamma have quite feeble penetrability (millimeters of steel, for example), so any spacecraft's hull will absorb this wave, resulting in evaporation and hummerlike blow of vaporized materials of hull, if it was close enough. At bigger distance - hull will melt or seam by uneven thermal expansion.
-
The damage of even nuclear explosions drops off relatively quickly in space. Most of the damage nukes do is caused by the blast wave and the fact that the air is being superheated or whatever.
In fact it's quite reverse: the damage of nuclear explosions drops much faster in air, than in vacuum, because in vacuum nearly all of explosion's energy is moving as spherical wave (so depressing at 1/r^2), while in air it's boiling in all the volume of this sphere (so depressing nearly at 1/r^3).
The main damaging factor of nuke in vacuum is very dense gamma wave. Gamma have quite feeble penetrability (millimeters of steel, for example), so any spacecraft's hull will absorb this wave, resulting in evaporation and hummerlike blow of vaporized materials of hull, if it was close enough. At bigger distance - hull will melt or seam by uneven thermal expansion.
Heat is relatively easy to armor against, though. The thing is that because it is a spherical explosion, increasing the distance between you and the nuke rapidly decreases how much energy you absorb.
-
Sorry if this is the wrong thread, but do PD ships require multiple BFCs to defend against multiple incoming missiles?
From what I have read, you need multiple BFCs to have the ability to multi-target, but this is usually discussing having attack weapons target multiple enemy ships, not PD weapons such as dual turret gauss cannons target multiple incoming missiles.
From testing, I know that PD using a single BFC will target incoming volleys of missiles as long as they are being fired off of a single enemy missile ship.
However, against small fighters in swarms (say 40 - 50) firing a single missile each, do my PD ships need multiple BFCs to be able to target each of the missiles as they are not truly volley firing?
I ask because BFCs are quite expensive as well as if I use this tactic against enemy ships, it overwhelms the enemy's PD quite easily.
-
Sorry if this is the wrong thread, but do PD ships require multiple BFCs to defend against multiple incoming missiles?
From what I have read, you need multiple BFCs to have the ability to multi-target, but this is usually discussing having attack weapons target multiple enemy ships, not PD weapons such as dual turret gauss cannons target multiple incoming missiles.
From testing, I know that PD using a single BFC will target incoming volleys of missiles as long as they are being fired off of a single enemy missile ship.
However, against small fighters in swarms (say 40 - 50) firing a single missile each, do my PD ships need multiple BFCs to be able to target each of the missiles as they are not truly volley firing?
I ask because BFCs are quite expensive as well as if I use this tactic against enemy ships, it overwhelms the enemy's PD quite easily.
you can find you answer here: http://aurora2.pentarch.org/index.php?topic=8495.msg117825#msg117825
Long story short, 1 Fire Control is enough to engage a Salvo (no matter the size). Multiple Salvos will require multiple BFC weapons
-
Sorry if this is the wrong thread, but do PD ships require multiple BFCs to defend against multiple incoming missiles?
From what I have read, you need multiple BFCs to have the ability to multi-target, but this is usually discussing having attack weapons target multiple enemy ships, not PD weapons such as dual turret gauss cannons target multiple incoming missiles.
From testing, I know that PD using a single BFC will target incoming volleys of missiles as long as they are being fired off of a single enemy missile ship.
However, against small fighters in swarms (say 40 - 50) firing a single missile each, do my PD ships need multiple BFCs to be able to target each of the missiles as they are not truly volley firing?
I ask because BFCs are quite expensive as well as if I use this tactic against enemy ships, it overwhelms the enemy's PD quite easily.
you can find you answer here: hxxp: aurora2. pentarch. org/index. php?topic=8495. msg117825#msg117825
Long story short, 1 Fire Control is enough to engage a Salvo (no matter the size). Multiple Salvos will require multiple BFC.
From what Steve said in that link, in C# 1 FC is enough for any number of salvos, the restriction on number of salvos is the number of turrets. Or did I read that wrong on your link?
-
Multiple Salvos will require multiple BFC.
This is false, multiple salvos require multiple weapons to simultaneously target but not necessarily multiple PD BFCs. A change that happened in C#
-
Multiple Salvos will require multiple BFC.
This is false, multiple salvos require multiple weapons to simultaneously target but not necessarily multiple PD BFCs. A change that happened in C#
Even more specific it is either per individual weapons or turret. A turret can have multiple weapons and each turret can only engage one salvo.
I would be in favor of a more random salvo engagement of PD... it is a bit irritating that you have to completely eliminate one salvo before you start shooting at the next one. Please make the PD engage in a more random way and simple weight the random so larger missiles are engaged first, larger salvos second... but it should still be fairly random so PD fire are spread out among the incoming salvoes.
-
Multiple Salvos will require multiple BFC.
This is false, multiple salvos require multiple weapons to simultaneously target but not necessarily multiple PD BFCs. A change that happened in C#
Even more specific it is either per individual weapons or turret. A turret can have multiple weapons and each turret can only engage one salvo.
I would be in favor of a more random salvo engagement of PD... it is a bit irritating that you have to completely eliminate one salvo before you start shooting at the next one. Please make the PD engage in a more random way and simple weight the random so larger missiles are engaged first, larger salvos second... but it should still be fairly random so PD fire are spread out among the incoming salvoes.
I would prefer that such random targetting is based not on missile size but just weighted on salvo size, that will make each salvo draw proportionate fire. A salvo with 40 missiles should draw around twice as many shots as a 20 missile one.
I think favoring specific types of missiles based on missile parameters can upset balance. I think there was a discussion about this somewhere else in the forum already.
-
Thanks for all the help!
One last thing, I was reading that gauss cannons do not have the failure rate like other weapons, is that correct? It was stated earlier in this thread but wasn't confirmed.
Thanks again! Love this feaking game!
-
Thanks for all the help!
One last thing, I was reading that gauss cannons do not have the failure rate like other weapons, is that correct? It was stated earlier in this thread but wasn't confirmed.
Thanks again! Love this feaking game!
Yes sorry weapons not bfc, not sure about gausses though as I don't use them.
Also you may want to ask questions on the relative section: The Academy
;D
-
Thanks for all the help!
One last thing, I was reading that gauss cannons do not have the failure rate like other weapons, is that correct? It was stated earlier in this thread but wasn't confirmed.
Thanks again! Love this feaking game!
Gauss Cannons do have a failure rate like all beam weapons. However, it tends not to be a problem unless you are intending to do something like attack an AMM base with beam ships.
-
In fact it's quite reverse: the damage of nuclear explosions drops much faster in air, than in vacuum, because in vacuum nearly all of explosion's energy is moving as spherical wave (so depressing at 1/r^2), while in air it's boiling in all the volume of this sphere (so depressing nearly at 1/r^3).
The main damaging factor of nuke in vacuum is very dense gamma wave. Gamma have quite feeble penetrability (millimeters of steel, for example), so any spacecraft's hull will absorb this wave, resulting in evaporation and hummerlike blow of vaporized materials of hull, if it was close enough. At bigger distance - hull will melt or seam by uneven thermal expansion.
Heat is relatively easy to armor against, though.
When it's "slow" heat in atmosphere - well, you'll have an option to find water or wait several minutes for the rain. Though in vacuum it's very difficult to discharge heat - you'll have thermal radiation only.
But that's not a main point. Once more again. Nuclear explosion in vacuum - it's heat wave, compressed in microseconds. Your intuition will inevitably produce a bunch of bugs when you trying to picture it, because you have no experience of similar events. Such a sharp heat wave is much worse than a wave of slightly heated and compressed air, that your intuition will inevitably perceive as catastrific impact.
Just another try: at the same distance, where in air your ship will be hummered with air wave - in vacuum it will be hummered much worse with it's own shell, evaporated in microseconds. When this shell mass is evaporated - it's very, very dense vapour, very dense and hot "super-air" if you like air to picture, and it's much sharper, the wave is compressed to microseconds, not milliseconds as air wave in atmosphere! Your ship will suffer from momentary titanic kick, because a half of it's shell will be momentary transformed in super-dense super-brisant explosive charge.
The thing is that because it is a spherical explosion, increasing the distance between you and the nuke rapidly decreases how much energy you absorb.
Yes! But again - in air this decrease is much faster! Look again at the formula. It's inversely quadratic proportional in vacuum, and inversely cubic proportional in air (because, again, nuke's energy in air is boiling in all volume of air ball, when in vacuum it's compressed at the edge of spherical gamma wave, that wasn't absorbed by air).
Air is not a multiplier of impact! It's just shock-absorber.
-
In fact it's quite reverse: the damage of nuclear explosions drops much faster in air, than in vacuum, because in vacuum nearly all of explosion's energy is moving as spherical wave (so depressing at 1/r^2), while in air it's boiling in all the volume of this sphere (so depressing nearly at 1/r^3).
The main damaging factor of nuke in vacuum is very dense gamma wave. Gamma have quite feeble penetrability (millimeters of steel, for example), so any spacecraft's hull will absorb this wave, resulting in evaporation and hummerlike blow of vaporized materials of hull, if it was close enough. At bigger distance - hull will melt or seam by uneven thermal expansion.
Heat is relatively easy to armor against, though.
When it's "slow" heat in atmosphere - well, you'll have an option to find water or wait several minutes for the rain. Though in vacuum it's very difficult to discharge heat - you'll have thermal radiation only.
But that's not a main point. Once more again. Nuclear explosion in vacuum - it's heat wave, compressed in microseconds. Your intuition will inevitably produce a bunch of bugs when you trying to picture it, because you have no experience of similar events. Such a sharp heat wave is much worse than a wave of slightly heated and compressed air, that your intuition will inevitably perceive as catastrific impact.
Just another try: at the same distance, where in air your ship will be hummered with air wave - in vacuum it will be hummered much worse with it's own shell, evaporated in microseconds. When this shell mass is evaporated - it's very, very dense vapour, very dense and hot "super-air" if you like air to picture, and it's much sharper, the wave is compressed to microseconds, not milliseconds as air wave in atmosphere! Your ship will suffer from momentary titanic kick, because a half of it's shell will be momentary transformed in super-dense super-brisant explosive charge.
The thing is that because it is a spherical explosion, increasing the distance between you and the nuke rapidly decreases how much energy you absorb.
Yes! But again - in air this decrease is much faster! Look again at the formula. It's inversely quadratic proportional in vacuum, and inversely cubic proportional in air (because, again, nuke's energy in air is boiling in all volume of air ball, when in vacuum it's compressed at the edge of spherical gamma wave, that wasn't absorbed by air).
Air is not a multiplier of impact! It's just shock-absorber.
This is simply incorrect, unless you are referring to nuclear radiation. The majority of a nuke’s damage in atmosphere is caused by the pressure wave of the bomb.
See this link
http://www.projectrho.com/public_html/rocket/spacegunconvent.php#warhead
-
This is simply incorrect, unless you are referring to nuclear radiation. The majority of a nuke’s damage in atmosphere is caused by the pressure wave of the bomb.
See this link
http://www.projectrho.com/public_html/rocket/spacegunconvent.php#warhead
What is incorrect?! I tell you the same thing: the majority of a nuke’s damage in atmosphere is caused by the pressure wave of the bomb, which is decreasing much faster (roundly with inversely cubic proportional law), than a gamma wave, that initially caused this air pressure wave!
Yet another try.
Initial energy burst of nuke is - what? - yes, gamma photons with some tail of other energy forms.
In air these gamma quants will absorb mostly in first hundreds of meters, causing overheated initial air ball.
So nuke energy in air is delaminating on impact factors, proceeding to the target in this order:
1. The rest (small part) of gamma wave, that wasn't absorbed in air.
2. X-ray, UV, visual and IR reemissions - even less dangerous for ships, because it's small part of nuke's energy too, and it's stretched out comparinf to initial gamma wave.
3. Compressed air pressure wave (caused by rather small part of overall nuke's energy, much slower and less dense comparing to initial gamma wave, but it's enough to take down most non-armoured targets, though armoured battle machines are quite staunch to this blow).
4. Air, water and ground heat wave - the most energy-capacious, but not very dangerous, except if your target is over or under explosion point.
5. Long-term radiation - well, not a danger for TN ships and GF.
Notice the way in which nuke's energy in air is delaminating, stretching and slowing down.
Yes, p.3 (compressed air pressure wave) is the most dangerous, but it's the most dangerous comparing with other impact factors in air, not comparing with impact factors in vacuum! In fact most of nuke's energy in air will be wasted on heating air ball, that will further lift itself over explosion point.
Comparing with vacuum impact factors - it's smth completely different! No air - no absorbtion of initial gamma wave. No no slowing down, no delamination, no stretching in the volume of the air ball - nearly all the energy impact is moving with the speed of light in one microsecond-length wavefront. All the energy, that caused air pressure wave - all that energy is traveling now (in vacuum) to the target too, but in other form. And in addition to this, in the same form of microsecond-length gamma wavefront you'll take nearly all other parts of nuke: all those gamma quants, that was wasted or slowed down in air - all that gamma you'll instantly take on your ship's shell.
You think, obviously, that this shell (ship's hull) is quite capable of absorbing this damage. Yes, that's what I trying to tell: it will be absorbed! It will be absorbed in microseconds. There is no way to take it away safely: gamma is very stubborn thing, it's nearly impossible to reflect, because gamma photons have very high energy, so they are just tearing electrons off the material, no way to reflect (instantly reemission) that much energy with any material's surface. So, nearly all the energy will cause heat. The Heat! And not in the air in all the way to the target! All that heat - target's sectional area's part of nuke's energy - will be delivered instanly, without delamination and stretching, nealy withoul losses - and what do you think, the ship will safely dodge all this energy? No way. It will evaporate some part of the shell, as I wrote above, and this evaporation will be in INSTANT. What is instant evaporation of some dense matter? Yes, it's explosion! Some part of ship's hull will just explode. Explode with much more brisance, then any brisant explosive you can imagine (because no chemical brisant can release this much energy so quickly), and that will be much more part of nuke's energy, than in compressed air wave.
No miracles! If you take more energy in less time length with the same area - you'll suffer more damage.
-
By the way, there is a mention about Impulsive Shock damage below at your link.
They only forget 2 things:
1. There will be not a uniform absorbtion in the depth of hull, but logarithmic (so closer to the surface - more absorbtion density), and so there must be much lesser Kt by the distance to evaporate some part of the hull.
2. There will be hummering effect on the ship itself, not only a shell damage they calculated. Let's calculate a little. 1kt tac nuke at 1 km range will deliver smth about 300k J per 1m^2 of ship's shell in microsecond. If your ship's sectional area is 1000m^2 (smth like 10x100m cigar-like hull, wet navy's corvette or frigate) - smth about 1/2 of this energy will cause instant evaporation of the hull surface, so it's about 10 kg of iron vapour in microsecond - 10g per 1m^2. It doesn't sound dangerous until you remember that RDX's density is 1.77g/cm^3, so iron vapour in contact - that's no less then 5cm of RDX explosive cubes at all the hull's surface plates. It's like satchel charges through all the hull.
And it's 1kt surface tac nuke. Take 1Mt at the same 1km range - and it's roundly 50kg of RDX plates per hull square meter all around the hull's nuke side. That's what crack any Wet Navy battleship as an egg.
-
By the way, there is a mention about Impulsive Shock damage below at your link.
They only forget 2 things:
1. There will be not a uniform absorthion in the depth of hull, but logariphmic (so closer to the surface - more absorthion density), and so there must be much lesser Kt by the distance to evaporate some part of the hull.
2. There will be hummering effect on the ship itself, not only a shell damage they calculated. Let's calculate a little. 1kt tac nuke at 1 km range will deliver smth about 300k J per 1m^2 of ship's shell in microsecond. If your ship's sectional area is 1000m^2 (smth like 10x100m cigar-like hull, wet navy's corvette or frigate) - smth about 1/2 of this energy will cause instant evaporation of the hull surface, so it's about 10 kg of iron vapour in microsecond - 10g per 1m^2. It doesn't sound dangerous until you remember that hexogen's density is 1. 77g/cm^3, so iron vapour in contact - that's no less then 5cm of hexogen explosive layer at all the hull's surface. It's more then armour-piercing satchel charges.
And it's 1kt surface tac nuke. Take 1Mt at the same 1km range - and it's roundly 5 meters of hexogene plates all around the hull's nuke side. You'll need a small battle moon to deal with it.
This implies modern newtonian hull materials, not trans-newtonian materials. When looking at a 6,000 ton ship in game compared to the modern day ticonderoga-class cruiser at 9,800 tons, and looking at the ability of the modern naval cruiser to withstand even a 1kt nuclear explosion, the in game trans-newtonian hull materials would have to have massive specific heat figures while also having near perfect thermal conductivity ratings (either near zero or near infinity). To vaporize even a single molecule of the material at the surface would take massive amounts of energy, and it would be much more effective to then attack the armors elasticity and strength values (tensile, yield, compressive, etc. ) which would result in blowing "chunks" off the ship, instead of using radiation energy to vaporize it.
In effect, the damage of nukes would be much more limited in space than if the same ship was in atmosphere, as the concussive blast wave of the air in atmosphere would likely cause more damage than just the initial explosive force of a direct hit in vacuum.
-
This implies modern newtonian hull materials, not trans-newtonian materials. When looking at a 6,000 ton ship in game compared to the modern day ticonderoga-class cruiser at 9,800 tons, and looking at the ability of the modern naval cruiser to withstand even a 1kt nuclear explosion, the in game trans-newtonian hull materials would have to have massive specific heat figures while also having near perfect thermal conductivity ratings (either near zero or near infinity). To vaporize even a single molecule of the material at the surface would take massive amounts of energy, and it would be much more effective to then attack the armors elasticity and strength values (tensile, yield, compressive, etc. ) which would result in blowing "chunks" off the ship, instead of using radiation energy to vaporize it.
In effect, the damage of nukes would be much more limited in space than if the same ship was in atmosphere, as the concussive blast wave of the air in atmosphere would likely cause more damage than just the initial explosive force of a direct hit in vacuum.
Well, let's go this way. Any Aurora TN ship is able to fully reverse her full velocity in 5 secs without any damage. Let's be moderate - take 10kkm/s fighter, not smth of antimatter era. 10kkm/s per 5s = 2000000m/s^2 ~= 200000 G.
TN hull, that can withstand this, will withstand any blowing "chunks".
-
Regarding nuclear weapons damage: It's helpful to start by realizing what a nuclear weapon actually produces that delivers the heat and radiation damage.
Broadly, a (fission) nuclear weapon releases several kinds of radiation when it detonates:
- MeV heavy fission products, which carry the majority of the reaction energy initially
- MeV fission neutrons
- MeV prompt gamma rays
- Delayed beta and gamma emissions in the 100s keV to MeV energy range
Two things are important here: first, the energy level of these particles/radiations are all of roughly MeV order (correlating with temperatures on the order of 10 billion degrees), which determines the nature of the material interaction when the radiation impacts our ship's armor. In reality since this energy will be most immediately distributed to the non-fissioned part of the warhead (and at least some of the surrounding structure) the actual per-particle energy is probably dipping into the 100s keV range.
Second, all of the fission energy at the atomic scale is kinetic energy - when people say it is "easy to deal with heat" this is not an accurate statement when dealing with nuclear explosions and radiation. At the atomic scale, all "heat" is in fact kinetic energy.
In atmosphere, this energy most immediately goes to the surrounding air which produces the characteristic shockwave most are familiar with. It's not true that the shockwave decays as 1/r3 as the superheated atmosphere still gets pushed out with the blast and that energy will be transferred to a target, although the actual nature of the damage may vary substantially due to the lower per-particle energies involved. Thus 1/r2 is the right first approximation.
In vacuum, with no atmosphere the blast expands in a roughly spherically-symmetric way - thus serger I believe was correct that it falls off as 1/r2. Thus the energy that does impact the ship is the cross sectional area over 4*pi*r2 which is the major contribution to how a spaceship can even survive a nuclear impact (strictly speaking, missile "accuracy" should be a continuum value as the key value is how near to the ship a missile explodes rather than a binary hit/miss.
Anyways, the point is that considering space vs atmosphere, there is no reason a space explosion would be any less lethal other than the distances involved.
On impact, the first thing that will happen is all those MeV particles will ablate probably the first cm or so of hull plating (possibly less for a TNE plating - however as the base armor tech is conventional steel we have a baseline for comparison, though I won't do this right now). The ablated layer which is basically a compressed metal (or ceramic depending on tech) layer will on one hand "shield" the underlying armor, however the momentum arriving at the target will cause two effects:
First, the ablation layer will be driven "forward" by the middle and tail "ends" of the blast wave. Even though the armor underneath is shielded from direct impacts there will still be significant melting at a rapid rate though probably slower than the initial vaporization impact (this is a highly nonlinear process). Once the blast wave is more or less "finished" then this vapor will begin dissipating off into space and the rate of melting will slow and eventually stop.
Second, overall conservation of momentum will push the ship significantly and unexpectedly in the outward direction from the explosion center. In Aurora this is the "shock" damage which correctly scales inversely with ship mass. Intuitively it should scale as 1/M however I believe in Aurora it may be 1/sqrt(M) accounting for the larger cross sectional area of a larger ship. This is difficult to estimate precisely, but if we assume an impact energy of ~1 kT (say a MT warhead but only a fraction of that energy impacts due to the 1/r2 scaling) or about 4 TJ a 10,000-ton ship would see roughly a 1 km/s change in velocity. Therefore the "shock" damage has little to do with an apparent change in the ship's velocity, and everything to do with the sudden material stresses that it experiences when that 4 TJ of energy is transferred through the entire structure as essentially a pressure wave - notably interference effects at every material interface are likely to cause unpredictable failure modes.
Really the most unrealistic part of Aurora's missile damage model is that it damages a discrete section of the armor instead of being spread across the entire armor belt with some gradient based on an assumed distance from the explosion center. In this sense the damage model appears to represent a direct impact of ~kT warheads rather than nearby detonation of ~MT warheads, though I'd more readily just attribute this to handwaving to fit the game mechanics.
-
This implies modern newtonian hull materials, not trans-newtonian materials. When looking at a 6,000 ton ship in game compared to the modern day ticonderoga-class cruiser at 9,800 tons, and looking at the ability of the modern naval cruiser to withstand even a 1kt nuclear explosion, the in game trans-newtonian hull materials would have to have massive specific heat figures while also having near perfect thermal conductivity ratings (either near zero or near infinity). To vaporize even a single molecule of the material at the surface would take massive amounts of energy, and it would be much more effective to then attack the armors elasticity and strength values (tensile, yield, compressive, etc. ) which would result in blowing "chunks" off the ship, instead of using radiation energy to vaporize it.
In effect, the damage of nukes would be much more limited in space than if the same ship was in atmosphere, as the concussive blast wave of the air in atmosphere would likely cause more damage than just the initial explosive force of a direct hit in vacuum.
Well, let's go this way. Any Aurora TN ship is able to fully reverse her full velocity in 5 secs without any damage. Let's be moderate - take 10kkm/s fighter, not smth of antimatter era. 10kkm/s per 5s = 2000000m/s^2 ~= 200000 G.
TN hull, that can withstand this, will withstand any blowing "chunks".
Relative to C that ship is accelerating at less than 1% of C. An impact with an object, for this instance a explosion of a nuke propelling fragments at a conservative . 5C, would be quite a different story, as they would add their speeds together, as well as the fragments would behave as if their mass was exponentially greater than it actually is due to relativity.
Also, the idea of the hull material being able to withstand massive radiation (high density gamma wave) as opposed to physical trauma (ballistic impacts from nuke exploding and fragments) is already modeled, with radiation multiplier tech decreasing armor damage for a given warhead. Now this theory should also allow high velocity missiles with a warhead of 0 to still do massive damage on impact to a ship, but that is up to steve, and it doesnt have to do with damage caused by nuke explosions.
Again, the game implies a material with near zero thermal conductivity and astronomically high specific heat. In reality with modern, or even futuristic in the terms of the next 50-100 years, your analysis of damage with regards to vacuum or atmosphere is correct. I was just pointing out how the game models it, and what a material would require for it to behave accordingly.
-
Really the most unrealistic part of Aurora's missile damage model is that it damages a discrete section of the armor instead of being spread across the entire armor belt with some gradient based on an assumed distance from the explosion center. In this sense the damage model appears to represent a direct impact of ~kT warheads rather than nearby detonation of ~MT warheads, though I'd more readily just attribute this to handwaving to fit the game mechanics.
It is game-play based rather than realistic. Also to restrict damage to a single ship.
Here are the nuclear detonation rules for Newtonian Aurora, which does spread the damage over half the armour belt.
http://aurora2.pentarch.org/index.php?topic=4329.msg43459#msg43459
-
Really the most unrealistic part of Aurora's missile damage model is that it damages a discrete section of the armor instead of being spread across the entire armor belt with some gradient based on an assumed distance from the explosion center. In this sense the damage model appears to represent a direct impact of ~kT warheads rather than nearby detonation of ~MT warheads, though I'd more readily just attribute this to handwaving to fit the game mechanics.
It is game-play based rather than realistic. Also to restrict damage to a single ship.
Here are the nuclear detonation rules for Newtonian Aurora, which does spread the damage over half the armour belt.
http://aurora2.pentarch.org/index.php?topic=4329.msg43459#msg43459
How complete is newtonian aurora and is it under development or is it considered finished? Is there a download?
-
In atmosphere, this energy most immediately goes to the surrounding air which produces the characteristic shockwave most are familiar with. It's not true that the shockwave decays as 1/r3 as the superheated atmosphere still gets pushed out with the blast and that energy will be transferred to a target, although the actual nature of the damage may vary substantially due to the lower per-particle energies involved. Thus 1/r2 is the right first approximation.
Well, I must agree that 1/r^3 is too simplistic - it's about air ball heating, not shockwave: in the air (0-5000m) shockwave is about 1/3 of nuke's energy, while 1/6 to 1/5 is heated air ball (that is around 1/r^3 decay).
Another 1/3 is UV to IR reemission, that will not produce momentary inner damage, though it can overheat the ship.
Speaking of small light life-pods - I'd say they have small chances to withstand nuke closer than several kms, and in 5 sec they have no chance to go this far in normal space.
Though, on the other hand, Aurora Lore is telling us that these velocities are effectively projective, so it's not clear what Aether's velocity it will represent.
To avoid these questions, I'm supplementing Aurora Lore for myself with a notion, that guns and emergency catapults are just transferring their pods and impacts through Aether, not through normal space, so it's like small hyper-jumps, and they are obviously able to open it in any direction even through the planet body (though haven't enough precision to target inside another hull). So, it's quite convenient, that life-pods are jumping outside of the ship at the distances up to 10 000 km nearly instantly, and so they are quite safe from explosions, that destroyed their ship.
-
How complete is newtonian aurora and is it under development or is it considered finished? Is there a download?
Abandoned, at least for the foreseeable future. The problem was that it was actually quite hard to run an Aurora-scale game using real-world mechanics :)
If I go back to this in future, I would probably keep to planets and restrict the need for long interplanetary flight (some form of jump engine that can function outside gravity wells). That would keep speeds down for combat and avoid the long-range travel. This is years away though, if at all.
-
Hey steve, I just wanna say thank you for some of the great changes coming in 1.13 especially to carriers but in regards to that would you be willing to look into the UI for using carriers and finding ways to improve it (I know suggesting to improve the UI practically blasphemous) as i feel thats the main thing stopping people from using carriers, these changes that are already in 1.13 will make beam fighters much m ore viable and will also buff carriers across the board but ease of use is the main obstacle so am wondering if that would be possible.
And I would be willing to help with this as i have various suggestions on how this could be improved, at the very least some things that would just help reduce overall confusion with how the interface is currently.
-
Maybe start a new thread specifically for carrier ops suggestions. I am using beam fighters in my current campaign and they are proving very useful.
-
Maybe start a new thread specifically for carrier ops suggestions. I am using beam fighters in my current campaign and they are proving very useful.
Alright also awesome to hear as we all know steve whenever you start using stuff in your campaigns you tend to pay it extra attention so this would be a great time to do so.
-
The further 1.13 changes look great but I feel that large ships are getting a lot of love here that is taking away some of the Rock Paper Scissors v smaller ships. Would be good to look at some up side to smaller ships to balance this - maybe another look at efficiency benefits of multi slipway shipyards for example.
-
The further 1.13 changes look great but I feel that large ships are getting a lot of love here that is taking away some of the Rock Paper Scissors v smaller ships. Would be good to look at some up side to smaller ships to balance this - maybe another look at efficiency benefits of multi slipway shipyards for example.
Small ships already have a pretty significant building advantage over larger ships. You need less people to build small ships faster, you also can get more yard space faster up and running to pump out smaller ships faster than larger ships.
Large ships is long term more effective as you get more bang for the buck per tonnage which is important long term.. but in order to gain that benefit you need to invest more into research and infrastructure.
I think the balance are relatively good between them to be honest.
-
Would Steve consider adding in a different resource to limit ground installations other than population?
I hate how Research Facilities, which should have a very small, if any, population requirement due to the specialized skills needed to work there, required a population of 1,000,000!
Even if you assume that a vast majority are supporting industries, that is still far, far more people involved than there should. You can't build secret moon research bases without shipping literally a million people to said "secret" base which is a big shame.
What if Research Facilities required a huge amount of power from a new Power Grid ground installation?
-
The further 1.13 changes look great but I feel that large ships are getting a lot of love here that is taking away some of the Rock Paper Scissors v smaller ships. Would be good to look at some up side to smaller ships to balance this - maybe another look at efficiency benefits of multi slipway shipyards for example.
In C# generally large ships get loved much more than smaller ships, compared to what we had in VB6 :(
-
In atmosphere, this energy most immediately goes to the surrounding air which produces the characteristic shockwave most are familiar with. It's not true that the shockwave decays as 1/r3 as the superheated atmosphere still gets pushed out with the blast and that energy will be transferred to a target, although the actual nature of the damage may vary substantially due to the lower per-particle energies involved. Thus 1/r2 is the right first approximation.
Well, I must agree that 1/r^3 is too simplistic - it's about air ball heating, not shockwave: in the air (0-5000m) shockwave is about 1/3 of nuke's energy, while 1/6 to 1/5 is heated air ball (that is around 1/r^3 decay).
Another 1/3 is UV to IR reemission, that will not produce momentary inner damage, though it can overheat the ship.
Speaking of small light life-pods - I'd say they have small chances to withstand nuke closer than several kms, and in 5 sec they have no chance to go this far in normal space.
Though, on the other hand, Aurora Lore is telling us that these velocities are effectively projective, so it's not clear what Aether's velocity it will represent.
To avoid these questions, I'm supplementing Aurora Lore for myself with a notion, that guns and emergency catapults are just transferring their pods and impacts through Aether, not through normal space, so it's like small hyper-jumps, and they are obviously able to open it in any direction even through the planet body (though haven't enough precision to target inside another hull). So, it's quite convenient, that life-pods are jumping outside of the ship at the distances up to 10 000 km nearly instantly, and so they are quite safe from explosions, that destroyed their ship.
Oh, a simple explanation would be: The nuclear warheads detonate in the Aether, instead of in the real world, because the majority of Trans-Newtonian ships are in the Aether. Thus, life pods don't have to get far away, they simply have to drop out of the Aether, so that the explosions aren't in the same dimension as the life pods.
-
The further 1.13 changes look great but I feel that large ships are getting a lot of love here that is taking away some of the Rock Paper Scissors v smaller ships. Would be good to look at some up side to smaller ships to balance this - maybe another look at efficiency benefits of multi slipway shipyards for example.
- I'd handily disagree, to be honest with you. The Point Defense changes mean smaller escorts are more viable as they no longer need the same overhead for FCS. Having all Size-Reduction Tech for missile launchers available from turn one, even in a Conventional Start, buffs all missile ships across the board and not just large ones. The changes to Active and Passive Sensor models have hugely benefited smaller ships over larger ones. With engines being able to be designed in sub 1HS models, truly tiny fighters are possible for the first time ever. Fighter Sized Fuel Tanks and the introduction of smaller Maintenance Storage Bays have benefited smaller ships tremendously.
- The only changes I can think of that were heavily skewed towards larger vessels are the shield changes and the change where Beam weapons now consume MSP.
-
The further 1.13 changes look great but I feel that large ships are getting a lot of love here that is taking away some of the Rock Paper Scissors v smaller ships. Would be good to look at some up side to smaller ships to balance this - maybe another look at efficiency benefits of multi slipway shipyards for example.
- I'd handily disagree, to be honest with you. The Point Defense changes mean smaller escorts are more viable as they no longer need the same overhead for FCS. Having all Size-Reduction Tech for missile launchers available from turn one, even in a Conventional Start, buffs all missile ships across the board and not just large ones. The changes to Active and Passive Sensor models have hugely benefited smaller ships over larger ones. With engines being able to be designed in sub 1HS models, truly tiny fighters are possible for the first time ever. Fighter Sized Fuel Tanks and the introduction of smaller Maintenance Storage Bays have benefited smaller ships tremendously.
- The only changes I can think of that were heavily skewed towards larger vessels are the shield changes and the change where Beam weapons now consume MSP.
Change to maintenance model, increased pressure on officer corp (b/c of admin commands+multiple officers/ship+officer bonuses are a bigger deal now), shock damage rules, fuel efficiency, electronic warfare
All of these changes benefit bigger ships>smaller ships imo. I probably missed some.
-
Change to maintenance model, increased pressure on officer corp (b/c of admin commands+multiple officers/ship+officer bonuses are a bigger deal now), shock damage rules, fuel efficiency, electronic warfare
All of these changes benefit bigger ships>smaller ships imo. I probably missed some.
- Fuel and ECM/ECCM was always skewed to larger ships anyway, so that's somewhat of a moot point. Shock damage is certainly skewed in favor of large ships, but then again small ships tend to be more fragile as a rule anyway, so it's also kind of moot. Increased pressure on the officer corps is certainly something that encourages larger ships. The maintenance module doesn't favor one or the other; in my opinion the old model very clearly favored larger ships over smaller ones, as any maintenance threshold over a ship's tonnage was effectively "wasted".
-
Change to maintenance model, increased pressure on officer corp (b/c of admin commands+multiple officers/ship+officer bonuses are a bigger deal now), shock damage rules, fuel efficiency, electronic warfare
All of these changes benefit bigger ships>smaller ships imo. I probably missed some.
- Fuel and ECM/ECCM was always skewed to larger ships anyway, so that's somewhat of a moot point. Shock damage is certainly skewed in favor of large ships, but then again small ships tend to be more fragile as a rule anyway, so it's also kind of moot. Increased pressure on the officer corps is certainly something that encourages larger ships. The maintenance module doesn't favor one or the other; in my opinion the old model very clearly favored larger ships over smaller ones, as any maintenance threshold over a ship's tonnage was effectively "wasted".
Increased pressure on the officer corps is a bit of a moot point - part of the C# design for officers was to give each rank a role in a mature fleet through admin commands (for high-ranking officers e.g. admirals) as well as the non-command officer positions e.g. Aux Control, Main Engineering, and so on. Given the 2:1 ratio between successive ranks (if auto-promote is used) it is I think quite rare to find ships that would use for instance one CAPT, two CDRs, and four LCDRs thus there are plenty of lower-rank commanders left over to command smaller ships. At the same time, while a larger ship class is broadly better as the core of a fleet there are many ancillary roles which must be filled for which smaller ship classes are often the best solution. No one needs a 100,000-ton dedicated sensor ship for instance, 5,000 tons will do.
I think perhaps the issue some people have is that the game mechanics do favor a fleet design that includes large capital ships, and if one wants to stick to smaller ships this is admittedly not going to lead to the best efficiency. However, Aurora is IMO realistic in this regard if we assume that loosely replicating IRL naval history is realism (in the immortal words of a famous sci-fi character, "There's always a bigger fish warship"). That said, I think the mechanics really support a well-designed balanced fleet with ships at different size points to fulfill different roles but based around the capital ships as the core of a fleet - again, fairly realistic.
That being said, if officers are a problem this suggests that perhaps the player needs to invest a little bit more into academy construction to support their expanding fleet. I certainly tend to underestimate how much I need another academy until I actually do in fact need it.
-
Does ticking the 'No Maintenance Required' box get rid of weapon failure maintenance as well as standard maintenance in v. 1. 13? I know ships would still need MSP for damage control but I haven't been able to tell if the ships weapons still fail.
-
Does ticking the 'No Maintenance Required' box get rid of weapon failure maintenance as well as standard maintenance in v. 1. 13? I know ships would still need MSP for damage control but I haven't been able to tell if the ships weapons still fail.
Yes it gets rid of weapon failures as well
-
Would Steve consider adding in a different resource to limit ground installations other than population?
I hate how Research Facilities, which should have a very small, if any, population requirement due to the specialized skills needed to work there, required a population of 1,000,000!
Even if you assume that a vast majority are supporting industries, that is still far, far more people involved than there should. You can't build secret moon research bases without shipping literally a million people to said "secret" base which is a big shame.
What if Research Facilities required a huge amount of power from a new Power Grid ground installation?
I would like that too. Although I think Steve don't want to elaborate much more the "facility" game. Me I like Civilization-esque plethora of buildings, but I can understand why he don't want to go this way in Aurora.
A Power Grid requirement would be very nice though. I'm currently struggling on Europa, this is supposed to be a research center on what might be under the thick ice of the planet(oid) but with a one million pop requirement, it just don't work.
-
I suppose the research facilities might be trying to indicate that you need a lot of population in order to have enough people that are capable of facilitating real RND (from an aptitude perspective). Minding it should still take thousands of people at least at the facilities themselves.
I therefore suggest that maybe specialized labor become a thing, for instance you empire can only have so many 'RND' laborers working in labs, as a percent of total empire population (so for multiplicities sake the researchers are just assumed to be living at whatever population the research complexes are located at).
-
A "research complex" can be composed of quite a lot actually if you expand the definition to include support services. Not only do you have a lot of researchers (and in a TNE economy we can presume the level of education would be enabled to be quite high, many warm bodies to throw in the labs here) but numerous supporting roles - production of lab equipment, cyberinfrastructure, administration departments, and so on. One can also imagine the research complex being not only a pure lab environment but also the many connections back to the robust educational sector beyond the military academies - many universities which are affiliated with the research labs and of course have quite large staffing requirements as well, you can count at least the graduate students there and perhaps the undergrads as well if you imagine some fraction of that million population are cycled through the system each year at graduation and freshman admission dates.
Of course one might then ask why can we not place a lab way out on Europa which is supported by universities, manufacturers, etc. on Earth, and the answer there is simply that the Aurora planetside installations model simply does not go to such a level of detail.
-
A "research complex" can be composed of quite a lot actually if you expand the definition to include support services. Not only do you have a lot of researchers (and in a TNE economy we can presume the level of education would be enabled to be quite high, many warm bodies to throw in the labs here) but numerous supporting roles - production of lab equipment, cyberinfrastructure, administration departments, and so on. One can also imagine the research complex being not only a pure lab environment but also the many connections back to the robust educational sector beyond the military academies - many universities which are affiliated with the research labs and of course have quite large staffing requirements as well, you can count at least the graduate students there and perhaps the undergrads as well if you imagine some fraction of that million population are cycled through the system each year at graduation and freshman admission dates.
Of course one might then ask why can we not place a lab way out on Europa which is supported by universities, manufacturers, etc. on Earth, and the answer there is simply that the Aurora planetside installations model simply does not go to such a level of detail.
I don't think its right to include such a broad array of industries with a single Research Lab. Then it poses questions like 'Why do I need a whole university to support one lab?' 'Why is the cyber-security/lab equipment industries not paying taxes?' 'If education standards are higher, wouldn't that just mean the standard for scientists has increased rather than resulted in more scientists?'
The population requirement is purely for balance, I get that. But it sticks out like a sore thumb in this case cuz its being applied to a facility that should need less people, not more, and in such an extreme way. I really hope Steve finds another way to balance things in a more sensible way. Adding a power requirement to all buildings will allow Steve to cut down on the unrealistic amount of workers the installations need without sacrificing balance. It would also give more heft to Reactor technology for empires that don't typically use Beam weapons since it would upgrade the efficiency of your Power Grid buildings.
One interesting way to balance research labs is to instead re-imagine them completely. Make them a lot more powerful but a lot rarer and harder to obtain. Make them get big bonuses from being setup on planets with special 'anomalies' so you can have those isolated secret research outposts that actually have a reason to be in the ass-crack of nowhere and not stack them all on Earth. Make the interface better so you don't pull your hair out assigning research projects across multiple planets.
I might elaborate on this further in an independent post after I think some more. It could be very interesting.
-
As a side note I think I recall him mentioning that the population is actually what sets the cost of running the research complex, so it might be partly an inverse function of how high he wants the credit cost to be? (i believe currently all buildings follow the same rules with respect to cost so it may require a change of rules to let him keep things balanced as he likes)
-
I don't think its right to include such a broad array of industries with a single Research Lab.
That's why I nearly always rename "Research Lab" to "R&D complex" in the DB.
(Except for test campaigns, that I play to contribute at bug-hunting - that's "no bug report after BD intrusion" rule.)
As for other questions about economic model - it is possible not to look at this direction, and I prefer strongly to not look.
(With unsuitable names I have no such option.)
Adding a power requirement to all buildings will allow Steve to cut down on the unrealistic amount of workers the installations need without sacrificing balance. It would also give more heft to Reactor technology for empires that don't typically use Beam weapons since it would upgrade the efficiency of your Power Grid buildings.
One interesting way to balance research labs is to instead re-imagine them completely. Make them a lot more powerful but a lot rarer and harder to obtain. Make them get big bonuses from being setup on planets with special 'anomalies' so you can have those isolated secret research outposts that actually have a reason to be in the ass-crack of nowhere and not stack them all on Earth. Make the interface better so you don't pull your hair out assigning research projects across multiple planets.
Second these.
-
I wouldn't mind substantially increasing the value of remote research bases, but I'd prefer if stacking most of them on earth or wherever remained viable purely due to that making a degree of logical sense. You don't usually do a huge percentage of your RND at random remote locations because a lot of the heavy lifting involved in making something work benefits most from close access to the rest of the economy and access to as many engineers as possible.
-
Research in the game are fairly abstract and you need to impose personal restriction for it not to become too gamey, in my opinion.
I would not mind if research at some point became a bit more dynamic and fun.
Right now you don't really have any education level of the population which should be something that limit the amount of research complexes you could build and utilise. I also think that you should separate civilisation spanning research from more military applied sciences and they should perhaps tie a bit more into each other.
In general, military applied science spin of from more general civilisation spanning science... so engine technology, power generation etc should be a civilian basic science that you later can do military application of requiring more sophisticated research and higher level of costs and specialisation. Civilian research does not exclusively mean private research... it would most of the time be government funded research in addition to private industrial research.
I also would like to see civilian technology spread between colonies and not get applied everywhere at the same time. So, whenever something is discovered it start somewhere and then spread through trade and having civilian research facilities on the colonies. Mining colonies would be depending on populated colonies close by to influence them. So remote mining colonies could take some time to get updated mining technologies applied. This would encourage building small populated colonies along your border even more. If not just as administrative outpost to spread technology.
I don't think it need to be very complicated, just that each technology have a separate rating for each colony and the spread to colonies depend on their types, number of population, trade and local research facilities to speed up integration of new civilian technologies.
We then have military research facilities that work exclusively on "military" application of basic research. When you discovered the pre-requisite of a new engine your civilian industry (civilian research complexes) can develop new civilian engines while you need military specific research facilities to research military applications of the same engine types.
Facilities should also be built to service a specific category of research with the ability to convert them to another field the same way you can convert a mine into an auto-mine (more or less).
Military science installation should require much less population but be way more expensive to operate from a wealth perspective and probably also a bit more expensive to build.
I would also like to see that adding more complexes to a single project should have diminishing return for the amount of RP you get. The admin rating could instead impact the penalties for adding more labs to a single project.
With the above rules it would make more sense to spread you civilian research complexes among many colonies but keep your military research more centralised, this makes allot of sense realistically. If you don't have some civilian research in large population centres it will take a very long time for such colonies to adapt to newly discovered efficiency technologies.
I also think that we should be able to set the rate at which technology spread as some people will like it more than others, the same way we can control rate of research and survey speed. So you could set the speed at ten times the normal or perhaps like I probably would reduce it quite significantly so it is a real problem I need to actual deal and account for when setting up colonies and mining operations.
-
This is the changes discussion thread, not the suggestions thread.
-
Can I download v1. 13 somewhere? I can't seem to find it. . .
-
Can I download v1. 13 somewhere? I can't seem to find it. . .
It doesn't exist yet. 1.13 is the next version of the game, currently we are on 1.12
-
Will missile retargeting be fixed in v1.13?
-
Will missile retargeting be fixed in v1.13?
It is not in the changelog yet. Never say never, but Steve hasn't really mentioned it and his current campaign doesn't use a lot of missiles so it is not likely.
-
Will missile retargeting be fixed in v1.13?
What is the bug?
-
Will missile retargeting be fixed in v1.13?
What is the bug?
As it stands self-guided missile salvos that hit their target simultaneously will not avoid overkill like they used to in VB6. My understanding is that when a bunch of self-guided missiles destroy a target, any missiles that are still around should re-target another ship within their detection radius - this does not happen for any salvos that hit their target at the same time.
Re-targeting only works if the salvos are staggered where they arrive one-after-the-other. Thanks to how gauss PD works, this makes the main feature of self-guidance very bad against anything that has PD. This kind of makes self-guided incredibly weak compared to standard missiles, especially thanks to the changes to onboard sensor size.
-
As it stands self-guided missile salvos that hit their target simultaneously will not avoid overkill like they used to in VB6. My understanding is that when a bunch of self-guided missiles destroy a target, any missiles that are still around should re-target another ship within their detection radius - this does not happen for any salvos that hit their target at the same time.
Re-targeting only works if the salvos are staggered where they arrive one-after-the-other. Thanks to how gauss PD works, this makes the main feature of self-guidance very bad against anything that has PD. This kind of makes self-guided incredibly weak compared to standard missiles, especially thanks to the changes to onboard sensor size.
This might be a good piece of balancing behavior, as honestly re-targeting is insanely powerful, and with all missiles hitting at once, it would make sense they couldn't re-target. Massive salvos of missiles are already insanely powerful, and not terribly hard to achieve, this would at least mean the 'overkill' problem would that expensive in terms of missiles, and require more targeting spread to achieve multiple kills.
That said, I think the minimum size of missile sensors should be reduced slightly to compensate, then there are different advantages to both sorts of missiles.
-
As it stands self-guided missile salvos that hit their target simultaneously will not avoid overkill like they used to in VB6. My understanding is that when a bunch of self-guided missiles destroy a target, any missiles that are still around should re-target another ship within their detection radius - this does not happen for any salvos that hit their target at the same time.
Re-targeting only works if the salvos are staggered where they arrive one-after-the-other. Thanks to how gauss PD works, this makes the main feature of self-guidance very bad against anything that has PD. This kind of makes self-guided incredibly weak compared to standard missiles, especially thanks to the changes to onboard sensor size.
This might be a good piece of balancing behavior, as honestly re-targeting is insanely powerful, and with all missiles hitting at once, it would make sense they couldn't re-target. Massive salvos of missiles are already insanely powerful, and not terribly hard to achieve, this would at least mean the 'overkill' problem would that expensive in terms of missiles, and require more targeting spread to achieve multiple kills.
That said, I think the minimum size of missile sensors should be reduced slightly to compensate, then there are different advantages to both sorts of missiles.
I would agree, it also is way more efficient to spread your missile out on many ships as damaging ships are generally better as you then can pick of the straggler one by one and it lower their PD defences or offensive capabilities for the next strike.
You need to learn moderation to be effective in the first place... ;)
If your opponents capabilities are unknown just spread your first salvo among at least as many ships as you think is needed to get a good assessment of their capabilities. You then can adjust the ratio of missiles on each ships based on that Intel for consecutive strikes. First strike should generally target suspected escorts, that makes successive strikes that more effective.
-
I think I can appreciate the sentiment of the above two replies but with the new minimum on board sensor size requirements it does really make self-guided missiles more niche than I'd like. Ironically in VB6 if these missiles behaved like they do now I think it'd be much more balanced since the sensor would be much smaller anyways.
As it stands the only case where self-guided missiles are very useful is in a combat stealth ship context.
Edit: I would like to add that there are quite a few people who think that missile re-targeting is broken so Steve if you could clarify whether or not this is intended behavior that would be helpful. If it isn't a bug please consider reducing the minimum required sensor size.
-
I think I can appreciate the sentiment of the above two replies but with the new minimum on board sensor size requirements it does really make self-guided missiles more niche than I'd like. Ironically in VB6 if these missiles behaved like they do now I think it'd be much more balanced since the sensor would be much smaller anyways.
As it stands the only case where self-guided missiles are very useful is in a combat stealth ship context.
Edit: I would like to add that there are quite a few people who think that missile re-targeting is broken so Steve if you could clarify whether or not this is intended behavior that would be helpful. If it isn't a bug please consider reducing the minimum required sensor size.
I'm not sure if people have experimented enough with active sensor drones?
They can have pretty decent range for quite a small buoy attached to it. This is an excellent way to attack something using stealth as you don't have to reveal the striking ship... just have a fire-control large enough to track the target and missile with a range enough to attack so you remain hidden.
-
I think I can appreciate the sentiment of the above two replies but with the new minimum on board sensor size requirements it does really make self-guided missiles more niche than I'd like. Ironically in VB6 if these missiles behaved like they do now I think it'd be much more balanced since the sensor would be much smaller anyways.
As it stands the only case where self-guided missiles are very useful is in a combat stealth ship context.
Edit: I would like to add that there are quite a few people who think that missile re-targeting is broken so Steve if you could clarify whether or not this is intended behavior that would be helpful. If it isn't a bug please consider reducing the minimum required sensor size.
Perhaps I am a bit confused, but I considered self-targeting missiles completely necessary, because otherwise when a ship is destroyed all missile salvos aimed at that ship are wasted, even if your ship remains present.
Perhaps my designs are different, but I generally engage at ranges where I can fire quite a few salvos before the first salvo arrives, and spreading out those missiles is less effective than focusing, at least in terms of many salvos.
-
Sorry for the vague question on missiles, I was really busy all day and haven't been able to look at replies until now.
I think I can appreciate the sentiment of the above two replies but with the new minimum on board sensor size requirements it does really make self-guided missiles more niche than I'd like. Ironically in VB6 if these missiles behaved like they do now I think it'd be much more balanced since the sensor would be much smaller anyways.
As it stands the only case where self-guided missiles are very useful is in a combat stealth ship context.
Edit: I would like to add that there are quite a few people who think that missile re-targeting is broken so Steve if you could clarify whether or not this is intended behavior that would be helpful. If it isn't a bug please consider reducing the minimum required sensor size.
This. I'm under the impression that it is WAI, but I've read quite a few threads and have talked to a few people who believe that it is bugged. My question was more from a few of my friends asking if it was being "fixed" so I figured I would ask. I saw on the changelog that buoy's will remain in orbit now so it made me wonder if any other aspects of missiles had been looked at for 1.13.
-
I believe at some point Steve mentioned that it was not yet finished. He has left retargeting unimplemented for a while, and I assume he is pondering whether or not he should leave them that way.
The biggest potentially unintended side effect is that the change makes mines more or less useless.
-
A way to have missile sensor retargeting not be overpowered could be to have missile sensors select targets in a manner similar to how the new "Fire at Will" command will work. That way, missiles won't be "wasted", but will still be less effective since damage will be spread across the entire enemy fleet instead of wrecking a few of the targets.
-
Frankly speaking, I do not think that missiles within a single volley or simultaneous volleys should retarget. Impact is simultaneous and instantaneous
There is simply no way for them to retarget because they all detonate at the same instant.
It's not like missiles magically know, just before impact: "Oh look, only 12 of us will be enough, the others can all target someone else!!" I'll say it again, a volley all hit likely at the same second, so they should not retarget.
Subsequent volleys should instead retarget, and as far as I knows it happens.
I'd say this is working as intended, and also, it's working as it makes sense.
-
It's not working for me.
Mines and missiles with sensors are useless
-
a volley all hit likely at the same second
At the same 5-second.
I think it's long enough for electronics to consider retargetting with some simple algorithm, using sensors at very close* range.
(*) close for this tech level
But I'm inclinig to agree, that ideal retargetting is quite boring. I'd prefer to see missiles targetting as v1.13's "Fire at Will" mode do, just to make escorts more important.
-
a volley all hit likely at the same second
At the same 5-second.
I think it's long enough for electronics to consider retargetting with some simple algorithm, using sensors at very close* range.
(*) close for this tech level
But I'm inclinig to agree, that ideal retargetting is quite boring. I'd prefer to see missiles targetting as v1.13's "Fire at Will" mode do, just to make escorts more important.
All the missiles need to penetrate the final fire PD in those same 5 seconds, and need to distinguish between a burning hulk and a functional warship, both of which are surrounded by the nuclear fireballs of missiles which have already impacted, then need to find a new target and change course to hit that other target.
So personally I disagree that re-targeting should be possible based on a realism argument, at best it should be highly improbable or require specialised designs.
As a possible compromise, missiles targeted at destroyed ships could have a chance of re-targeting, but instead of hitting in the same increment they fly past and make another 'attack run' in the next increment against a random target (or weighted random target based on size).
This would make missiles face the final fire PD again, giving the targets another chance to fight back and reducing the ability of a single overwhelming strike to take out multiple targets without risking overkill.
One way of making missile sensors more important would be to make the re-targeting chance based on the size of the on-board sensor.
Something like 1% per 0.01 MSP, reduced by ECM so that a missile with a 0.25 MSP minimal sensor gets a 25% chance of re-targeting, or 15% if opposed by ECM 1.
Alternatively you could make the missile Maneuver value the % chance of re-targeting, or a combination of both factors.
This would incentivise using specialised missiles with large sensors (or high maneuver value) if you want to use missile strikes which automatically re-target.
Another factor could be the presence of the original missile fire control, if no longer in range the chance to re-target is halved.
That would incentivise keeping the missile launch platform (relatively) nearby if you want to use this tactic.
:P now this post looks like it belongs in the suggestions thread...
-
I personally am in favor of 'fire at will' style missile re-targeting.
Additionally, I think it would be perfectly reasonable for missiles to re-attack and be subject to defensive fire a second time. Perhaps if the primary target is destroyed, remaining missiles will persist until the next 5 second tick before moving on to their next targets, organically giving defensive weapons a second chance to fire under the current game rules. This would presume the missiles more or less blow past the remains of their original target and have to take a bit of time to re-engage, which I for one think makes sense.
I disagree with the idea of there only being a percent chance of re-targeting. By all accounts TN sensors are all-aspect so there is no reason why they would lose the ability to see other targets and engage them unless they were destroyed.
Additionally, there is no requirement to presume that TN sensors are in any way subject to being dazzled by nuclear explosions, we could very reasonably say that they have a clear view for purposes of retargeting, and the missiles are staggered perhaps a millisecond or so apart each, which given TN tech (or even probably today's tech) would provide plenty of time to ponder whether to abort a run against the current target.
-
Frankly speaking, I do not think that missiles within a single volley or simultaneous volleys should retarget. Impact is simultaneous and instantaneous
There is simply no way for them to retarget because they all detonate at the same instant.
It's not like missiles magically know, just before impact: "Oh look, only 12 of us will be enough, the others can all target someone else!!" I'll say it again, a volley all hit likely at the same second, so they should not retarget.
Subsequent volleys should instead retarget, and as far as I knows it happens.
I'd say this is working as intended, and also, it's working as it makes sense.
I would tend to agree with this assessment for a few reasons.
First, even though the increment is 5 seconds, this is purely a game mechanics decision, and nothing else in game suggests that missiles in a salvo are staggered more than milliseconds apart.
The other major consideration in my view is that when we look at how missiles and ship destruction actually work, it's really not feasible for missiles to even in five seconds assess that the target is destroyed and re-target. On one hand, missile damage is from a nuclear explosion and we can safely assume these are triggered at a certain set distance from the target, as trying to directly strike a target would be prohibitively difficult given the speeds involved, but also far more destructive than what actually happens in-game (the kinetic energy of a missile moving at ~0.1c far outweighs anything a nuclear explosion can output at the sizes we're playing with) - so we can safely assume direct impacts are not happening. Point being, missiles are exploding in close proximity to the target (or more likely in close proximity to the expected trajectory) and these explosions take some amount of time to actually reach and damage the target - the process is not instantaneous.
On the other hand, it would take even more time for damage to propagate through a ship and actually destroy it by causing secondary explosions etc. Perhaps not five seconds, at least not to be able to detect with certainty that the ship will imminently explode, but certainly it is also not instantaneous and missiles in a salvo milliseconds apart will not physically have the time before impact to assess this. Missiles in other salvos, I suppose it is reasonable enough given the limitations of a fixed minimum delta-t in-game.
Finally, in terms of gameplay I do note that a lack of salvo re-targeting if a partial salvo kills a ship maintains a certain amount of decision-making requirement in terms of allocating firepower to balance kill probability and use of limited ordnance. Additionally, this is a slight check against box launcher mega-salvos at least forcing box launcher ships to use many MFCs to avoid too much overkill...again, only a slight check given the small size of MFCs but still notable.
-
The other major consideration in my view is that when we look at how missiles and ship destruction actually work, it's really not feasible for missiles to even in five seconds assess that the target is destroyed and re-target.
If a significant percentage of the internal volume of the target turns into plasma you could probably conclude that it is dead.
-
I see no way to think about Aurora drives as about inertial velocity thing. They obviously cannot have any inertion or momentum - it will not conform to any other game mechanics.
These drives are, despite their tech names, smth like "vibrating" micro-jump drives of Asimov's or Anderson's SF worlds. There is no way to envision them in a different way with this mechanics.
So no need to "blow past target" and even nearly no possibility to be so.
The same about nuclear explosions. There is no way to envision them as contact or proximity nuclear explosions near to the hull, because (as nuclearslurpee already mentioned) there is no missile body impact and (as QuakeIV already mentioned) no explosion noise burst / blinding. And there is missile damage pattern, that is obviously contact explosion pattern, not proximity one.
So the only way to envision this - is to envision some explosion-pumping TN mechanics, that is delivering some small part of normal-space explosion's energy towards Aether, and that is missile's impact at the hull.
The same about sensors - they are (as QuakeIV already mentioned too) all-aspect ones always in Aurora mechanics, and there is no nuclear explosion EMP, and there is no way to just ignore those absences.
Yes, if it will be some retargetting - it will be in the middle of battle. But it's not that the first strike will be much simpler - there will be other ships and their ECMs, that must be filtered, so no cause to think that target's destruction will complicate missile brain's existence. Any our probe without even dedicated sensor can scan entire star system in 5-sec interval - what is the problem of scanning several nearby ships?
That's not a problem, there will be no contradiction with any other data you see in Aurora. We - and Steve in the first place - can chose what we want as more interesting, more play-well mechanics.
-
While there are no realistic chance to assess damage within the fraction of a second or more that it needs it does not matter... If Steve want missile to re-target in each 5-second turn they can. It is simply an abstraction as many other things like scanning an entire star system in 5-seconds or being able to see wrecks instantaneously but not functional ships for example. These are all abstractions to make the game either fun or simpler.
A ship going from just damaged to destroyed in this time-frame probably would be impossible in most cases to know even if you could perfectly scan the ship, they don't have to always blow up to be considered a mission kill. There also would not be much of wreckage left either if that was the case.
Anyway... I think it is just fine if we did not get the re-targeting back... we can either calculate roughly how many missiles we need and spread them out or stagger the salvos over several 5-second turns so they do have time to re-target. You have to piece together the information you have on the targets capabilities and fire missiles accordingly.
The more mechanics in the game to reduce the effectiveness of mass launched box launched salvos the better in my opinion.
-
The other major consideration in my view is that when we look at how missiles and ship destruction actually work, it's really not feasible for missiles to even in five seconds assess that the target is destroyed and re-target.
If a significant percentage of the internal volume of the target turns into plasma you could probably conclude that it is dead.
Yes - but my point is that this takes time, particularly for any ship large and sturdy enough to require several (dozen...hundred...) close hits from nuclear weapons to destroy. Because of that time, it is reasonable that a missile would not be able to near-instantaneously break lock and re-target when the "official" killing blow is landed by another missile in the same salvo - given that missiles in a salvo fly in quite close formation relative to the scales involved.
One presumes, I think, that missiles in a separate salvo are separated enough from each other that this destruction process happens quickly enough for those missiles to re-target. It's only the same salvo we're concerned about.
I see no way to think about Aurora drives as about inertial velocity thing. They obviously cannot have any inertion or momentum - it will not conform to any other game mechanics.
These drives are, despite their tech names, smth like "vibrating" micro-jump drives of Asimov's or Anderson's SF worlds. There is no way to envision them in a different way with this mechanics.
So no need to "blow past target" and even nearly no possibility to be so.
The rest is broadly good points, but I do want to note that canonically (as best I can tell, as Steve's canon is deliberately vague) engines in Aurora travel through the fluidic space of the Aether, thus do have inertia, momentum, kinetic energy, and so on - the distinction is that rather than traveling in vacuum objects in Aurora are subject to a drag force from this fluidic space (which is why ships travel at constant speed under constant engine power, it follows).
Of course once can headcanon however they like, but canonically there's nothing that suggests objects with mass and velocity measured in-game somehow do not have momentum nor kinetic energy.
Anyway... I think it is just fine if we did not get the re-targeting back... we can either calculate roughly how many missiles we need and spread them out or stagger the salvos over several 5-second turns so they do have time to re-target. You have to piece together the information you have on the targets capabilities and fire missiles accordingly.
The more mechanics in the game to reduce the effectiveness of mass launched box launched salvos the better in my opinion.
Amen, fellow space dictator.
-
Of course once can headcanon however they like, but canonically there's nothing that suggests objects with mass and velocity measured in-game somehow do not have momentum nor kinetic energy.
In terms of this I always envision that drives in Aurora never change a ships momentum (they can stop and turn in an instant or accelerate from 0-10kkm/s) directly but sort of make micro teleportation of ships or sort of folds space like an Alcubierre drive. From a technobabble way the Aether are subject to gravity so ships that travel throw the Aether this way may not change its momentum or kinetic energy directly it will change the energy as it get closer and closer to really large massive objects. This is why a ship will always have the same relative speed and momentum as any large massive object it get close to using the Aether drives. This is also why only really small objects (500t or less) can land on planets.
-
I do want to note that canonically (as best I can tell, as Steve's canon is deliberately vague) engines in Aurora travel through the fluidic space of the Aether, thus do have inertia, momentum, kinetic energy, and so on
Aether "has fluidic properties and is much more compressed in terms of distance between objects". There is no mention about other properties, like inertia, and this phrase implies some (most relevant/important) fluidic properties, not all properties of normal space's fluids. For example, normal space's fluids have a property of 3-dimensional wave mechanics, that Aurora have no trace of - Aurora's Aether is smth like planar nearly-Aristotelian projections of normal-space ecliptics, not 3D volume at all, both in speed or sensoring aspects. There is no hydromechanics in Aurora, no such properties as drag coefficient, block coefficient and so on.
There is no reason to confine ourselves in this "real physics" matters, because there will be no conformity in any case - the only way to make it nearly-coherent is to envision some other space with other number of dimensions, other metrics, topology, quantification and so on. And then - and only then - we'll have a freedom to chose usable, "playable" rules, and it's to be rules, not absolute freedom, because a play needs constraints to be interesting, to mould problems and challenges. Old retargetting rule was too simple, there was nearly no challenge. "No retargetting" rule will be too micro-heavy. We need smth to not be bogged down in calculating every single enemy ship's "this-missile's-hit-chance-and-warhead-strength-capacity" and manual targetting. So I'd prefer to have and ability to paint some target with ship's guidance system, but it must be confined hardly (as it is now with a pressure of MFC's range and resolution), and it will be good to have some decent probability of distraction, to have more importance of escorts and simultaneously less micro-manage with them. I'd like to see it even with missiles without sensors, but semi-active guidance is really naturally more like "hit or miss" thing, so it's good enough now, no pressing need to change current rules about AMM-like missiles.
-
or being able to see wrecks instantaneously but not functional ships for example.
"If a ship should suffer so much damage that it loses structural cohesion, the wreckage will be pushed out of the Aether, like an object floating to the surface of a fluid, and therefore will be detected easily in normal space."
That's good enough for me - I can easily unfold this "terse and simplistic" explanation with some high math and make myself believe in it to play without exertion.
The same about circular orbits and strict ecliptical planars of Aether star system's locuses - it's smth I can envision as some complicated and rather counterintuitive consequences of additional dimensions and their interaction with normal matter, some nearly-Aristotelian 2-dimensional projections of normal conic sections (ellipses and hyperbolas) into circles and straight lines, formed there as a consequence of long-recurring movement of gravitic masses. Good enough to play without exertion. It's not arbitrary for me, it can be envisioned as natural consequences of some intricate extra-dimensional physics.
What I cannot believe - it's 500-tons limit, for example. Just cannot explain it for myself at all, it's like a bone in the throat, it's not natural, it's completely arbitrary and is not necessary.
-
or being able to see wrecks instantaneously but not functional ships for example.
"If a ship should suffer so much damage that it loses structural cohesion, the wreckage will be pushed out of the Aether, like an object floating to the surface of a fluid, and therefore will be detected easily in normal space."
That's good enough for me - I can easily unfold this "terse and simplistic" explanation with some high math and make myself believe in it to play without exertion.
The same about circular orbits and strict ecliptical planars of Aether star system's locuses - it's smth I can envision as some complicated and rather counterintuitive consequences of additional dimensions and their interaction with normal matter, some nearly-Aristotelian 2-dimensional projections of normal conic sections (ellipses and hyperbolas) into circles and straight lines, formed there as a consequence of long-recurring movement of gravitic masses. Good enough to play without exertion. It's not arbitrary for me, it can be envisioned as natural consequences of some intricate extra-dimensional physics.
What I cannot believe - it's 500-tons limit, for example. Just cannot explain it for myself at all, it's like a bone in the throat, it's not natural, it's completely arbitrary and is not necessary.
If you really want to nitpick, how come a ship which looses all engines stays within the Aether rather than falling out and becoming detectable like a wreck?
For that matter why are immobile stations not detectable like wrecks?
-
If you really want to nitpick, how come a ship which looses all engines stays within the Aether rather than falling out and becoming detectable like a wreck?
For that matter why are immobile stations not detectable like wrecks?
Take it by analogy with wet navy or aerostatics: if some ocean ship will loose all engines - it will not sink, if some zeppelin will loose all engines - it will not fall.
Engine is for moving through Aether in rapid controllable manner, not for drifting there without falling out in normal space - that's "structural cohesion" is for, citing again that Lore fragment.
-
If you really want to nitpick, how come a ship which looses all engines stays within the Aether rather than falling out and becoming detectable like a wreck?
For that matter why are immobile stations not detectable like wrecks?
Take it by analogy with wet navy or aerostatics: if some ocean ship will loose all engines - it will not sink, if some zeppelin will loose all engines - it will not fall.
Engine is for moving through Aether in rapid controllable manner, not for drifting there without falling out in normal space - that's "structural cohesion" is for, citing again that Lore fragment.
That's a nice and helpful analogy.
-
If you really want to nitpick, how come a ship which looses all engines stays within the Aether rather than falling out and becoming detectable like a wreck?
For that matter why are immobile stations not detectable like wrecks?
Take it by analogy with wet navy or aerostatics: if some ocean ship will loose all engines - it will not sink, if some zeppelin will loose all engines - it will not fall.
Engine is for moving through Aether in rapid controllable manner, not for drifting there without falling out in normal space - that's "structural cohesion" is for, citing again that Lore fragment.
Does not make much sense in this case though as you need the engine to touch the water in the first place. A station or any object in space that does not have an active engine can't surf the Aether in any way so it makes very little sense in my opinion.
You can make up any technobabble you wish, it is just game mechanic at the end of the day for making game-play easy and understandable.
You obviously can easily see any wreck in a system but it is hard to detect a large population on a planet with all the satellites in and around the planet. At some point you just have to give up and realise it is just a game mechanic. The reason it is the way it is is because it otherwise wuold be very difficult to find wreckage and that is no fun, fun take priority over what makes sense.
It is the same with sensors and how this works... even a pre TN empire play by the same rules even though they don't possess the technology to see everything in space in an instant. They would also notice any combat damage done at the outskirt of the system or see any wreckage as soon as a ship is destroyed. Conventional engines and ships also follow regular game mechanics even if it make no sense... it is just for ease of play and does not have to make sense.
You just make up your own personal idea of how it works... in my opinion using engines in Aurora don't alter the kinetic energy of anything directly. That is just the way I rationalise what happens in my story. Anyone can make up their own story of how things work to fit the mechanics, you can't really be wrong.
-
To paraphrase a bit: “It’s just a game, you should really just relax”.
I personally don’t use the aether mechanic at all, my head cannon is that TN materials are used to contract devices that work more like Star Trek warp bubbles and structural integrity fields that let ships using them turn on a dime and come to complete stops. Though I guess aether is a pretty good sub space analogue.
-
Though I guess aether is a pretty good sub space analogue.
This is basically how I treat it in my headcanon, although I also couple Aether and TNEs to ultrastrong gravity waves to justify my constant power / constant speed engines as gravity drives of a nonspecific sort.
-
Does not make much sense in this case though as you need the engine to touch the water in the first place. A station or any object in space that does not have an active engine can't surf the Aether in any way
I don't understand why they need engines to be in Aether.
You can make up any technobabble you wish, it is just game mechanic at the end of the day for making game-play easy and understandable.
Yes, surely it is.
The difference is how often and how striking are those inconsistencies.
Say, you have an option to not use conventional engines at all - even with slow start.
You have an option to not look at some data, when it's not in the main page and you have no necessity to open it.
And the core sense of roleplay is to believe in that world with some part of your brain. No other sense in it, no other sense in Aurora maps, and officers, and naming themes, and so on. To hide inconsistencies is a must.
-
Regarding the whole 'there is no way to establish the damage within the necessary timeframe to retarget' I feel the need to point out that nuclear explosions (as they stand with current, real nuclear bombs) will propagate a fireball on the order of hundreds microseconds to milliseconds.
Here you can see from the trinity test a fireball is already propogating from 100 to 940 microseconds (no scale due to poor resolution of the images):
(https://nuclearweaponarchive.org/Usa/Tests/Trinityto1MS320c20.jpg)
And by 6 milliseconds it has already exceeded 100 meters in diameter:
(https://nuclearweaponarchive.org/Usa/Tests/Trin1.jpg)
You could reasonably argue that it would take longer than that to achieve penetration against dense armor, and I for one would not overtly disagree with that, it seems to me the situation would allow you to push the numbers in any direction you so choose (either in favor of same-salvo missile retargeting or against it), however the point stands that its not necessarily ridiculous that you would be able to tell if the target was dead or not over the course of milliseconds.
Additionally, a millisecond is potentially plenty of time for a computer to make decisions, I can write code that you could run on your home computer to prove this to any of you if you so desire (let alone application-specific computers designed for the job). It would not be insanity to say that a missile salvo could be spread milliseconds apart (one millisecond corresponds with about 300km at light speed which is below the resolution of the game), and assuming instantaneous/accurate sensor information from the fancy TN FTL sensors (which you could argue is not available, if you want to instead say that this is impossible for gameplay reasons), missiles could then make certain decisions about the likelihood of the destruction of the target.
On this general basis, I would say that the absolute most optimistic case in favor of retargeting missiles, assuming they are travelling at the speed of light, would require at least 1800km of separation between individual missiles (which does fit into the games resolution and would be technically noticeable) if we consider the 6ms timeframe as a baseline for detection of the destruction of the target (which is admittedly a completely bastardized comparison).
It would require accurate sensor information regarding whether certain portions of the ship had been reduced to plasma, which could (obviously) be freely said to be available or unavailable depending on the preference of the developer as to how Steve thinks this should all work. As an alternate mode of detecting the destruction of the target, per earlier posts mentioning the lore snippet of how wreckage is detected instantly, it could be said that an effectively-destroyed ship instantaneously translates into real space as wreckage and the detection of that fact provides the missile's computer with the criteria it needs to decide whether to abort its attack or not.
In other words I am saying I reject the notion that 'there is no way to determine if the target is destroyed or not in that timeframe' because assuming instantaneous intel as to the status of the target (whether we are detecting severe phase changes to the internal volume, or simply detecting its translation into real space via our magical FTL TN sensors) its perfectly possible to potentially gather that information and then make decisions based off of it in a very expedient manner and potentially for both the bombs and the computers involved to meet the timing requirements posed.
-
Regarding the whole 'there is no way to establish the damage within the necessary timeframe to retarget' I feel the need to point out that nuclear explosions (as they stand with current, real nuclear bombs) will propagate a fireball on the order of hundreds microseconds to milliseconds.
Here you can see from the trinity test a fireball is already propogating from 100 to 940 microseconds (no scale due to poor resolution of the images):
In other words I am saying I reject the notion that 'there is no way to determine if the target is destroyed or not in that timeframe' because assuming instantaneous intel as to the status of the target (whether we are detecting severe phase changes to the internal volume, or simply detecting its translation into real space via our magical FTL TN sensors) its perfectly possible to potentially gather that information and then make decisions based off of it in a very expedient manner and potentially for both the bombs and the computers involved to meet the timing requirements posed.
Now you have a swarm of hundreds of missiles hitting the same ship?!?
It is not just the damage that needs to propagate it also is the feedback into the sensors and then the calculations on what the results are and the time it takes for the actual damage to propagate the media. There simply is not time for any of this... it is just complete fiction in my opinion without some magic ingredient.
Anyone can technobabble anything, you can use time perception changes, precognition or what have you, that would make it more "realistic".
-
The sensors are ostensibly literally instantaneous, and computers have no problems making decisions on the scale of milliseconds (which would appear to be the timeframe we are discussing). It is in fact possible on that specific basis.
-
The sensors are ostensibly literally instantaneous, and computers have no problems making decisions on the scale of milliseconds (which would appear to be the timeframe we are discussing). It is in fact possible on that specific basis.
In my opinion it make no sense and it just is a game-mechanic that works because it has to work in some fashion and does not have to make full sense.
There simply is no logical reason for it to work as you describe, it is just absurd and from a realistic perspective and would never be possible. Being able to make sense of damage will require allot more time no matter how you do it.
Even if the missile could get a decision to re-target it also physically have to actually do it and hit something else?!?
It make perfectly sense that it will require some time and it also make perfectly sense from a game mechanic perspective if missiles can't re-target within the same 5 second increment either.
-
I'll write and compile an example executable later (IE probably tomorrow since its almost 1am), but if you were to for instance assume that your TN sensors are working like infrared cameras and deducing internal temperature (and then averaging a 3 dimensional grid of measurements), I think you will be surprised by the amount of such calculations your own computer can manage in the timeframe we are talking about.
-
I'll write and compile an example executable later (IE probably tomorrow since its almost 1am), but if you were to for instance assume that your TN sensors are working like infrared cameras and deducing internal temperature, I think you would be surprised by the amount of such calculations your own computer can manage in the timeframe we are talking about.
Ascertain damage is one of the more difficult process in real military applications, it usually take quite some time to find out if a target is destroyed or not. Even of you assume communication are near instant.
I never really imagined that communication in Aurora is instant, that is in my opinion just an artefact of game-mechanics, it would be very difficult to add time-delay with communication especially over distances so we just assume perfect knowledge because of it. Pretty much every game does that, even the ones that model realistic conflicts. It does not mean that either sensor data or communication is actually instant.
For me it make perfectly sense from a mechanical perspective we can't re-target missiles in the same 5-sec increment, that is good enough for me.
-
Well of course, you could perfectly reasonably say that the needed information is not actually available for a whole host of reasons, but if you assume FTL sensors (which you could reasonably assume since its magical TN sensors made out of TN materials which enable instantaneous FTL travel via various modes, plus the fact that in-game the sensors are depicted as working that way) providing information on the target (for instance temperature) then all I am saying is its possible for it to happen. The bombs can maybe do it depending on how you are inclined to say that nuclear bombs interact with TN armor, and the computers can definitely do it.
To be clear I am specifically objecting to the notion that its inconceivable and impossible to justify due to the timing requirements. No such thing is true.
e: Also I understand that modern BDA is quite slow, this setting however does (potentially) provide significantly better information gathering tools than those currently available to us today.
-
Well of course, you could perfectly reasonably say that the needed information is not actually available for a whole host of reasons, but if you assume FTL sensors (which you could reasonably assume since its magical TN sensors made out of TN materials which enable instantaneous FTL travel via various modes, plus the fact that in-game the sensors are depicted as working that way) providing information on the target (for instance temperature) then all I am saying is its possible for it to happen. The bombs can maybe do it depending on how you are inclined to say that nuclear bombs interact with TN armor, and the computers can definitely do it.
To be clear I am specifically objecting to the notion that its inconceivable and impossible to justify due to the timing requirements. No such thing is true.
e: Also I understand that modern BDA is quite slow, this setting however does (potentially) provide significantly better information gathering tools than those currently available to us today.
100 missiles that is an average of 100km distance per missile... so the missile would need. A missile travelling at 30.000km/s that is what 0.003 seconds. In this time it needs not only to know what damage another missiles did it also need to physically re-target into another target and more importantly actually hit close to it and then the following missiles need to react to that one.
What if the missiles already passed all other eligible targets in the area... is it going to turn around and hit something else... perhaps possible!?!
In my opinion this is just bending backwards trying to rationalise something you don't have to. From a realistic perspective it is just fantasy so you need magic to explain it. If we use magic then anything goes. ;)
And as I said.. from a mechanical perspective we don't need it.
-
I would like to add, to the whole 'access damage thing', that there is another factor.
Any method you use to check if the ship is damaged, is a weakness in the 'code' of your missiles. It gives the target something to spoof, via ecm. Make that too sensitive, or too fast to assume a target is destroyed, and the enemy will find a way to convince all your missiles that it is 'dead' after the first few explosions. Playing dead is a very real tactic, and trying to get fancy with missile AI is a good way to leave yourself quite vulnerable.
It's better to 'waste' missiles that don't have time for detailed checks on the target, than risk having most of your missiles make mistakes and ignore the enemy.
-
snip snip
nuclear bomb pictures
snip snip
You're not wrong but in my view, far more important than the time it takes for a nuclear explosion to propagate (and I do think a time scale on the order of ms is significant for missiles in the same tight-formation salvo, but I digress) is the fact that the destruction of a ship, particularly one built to withstand multiple nuclear explosions in close proximity, is not an instantaneous or even millisecond-scale process. Obviously the exact details are going to be highly variable particularly related to just how we envision the ships in our personal headcanon, but in any case the time required for a ship to go from suffering several missile impacts to clearly killed is non-trivial.
I'll buy everything about near-instantaneous compute and signal times for the purposes of retargeting other salvos in the same time increment as these are presumably staggered by a much greater degree than the missiles in a single salvo, but I do think the missiles in a single salvo are close enough together that by the time those milliseconds elapse, they will all have hit or attempted to hit the target simply by virtue of covering the distance to that target in less than a millisecond. Of course one can always headcanon anything one likes, but I simply don't see a good justification for same-salvo retargeting without making a lot of leaps beyond what seems apparent in the actual game. Again, other-salvo retargeting in the same increment is perfectly fine.
Others have raised excellent points as well, and certainly game mechanically I don't think same-salvo retargeting is needed as the existing mechanic introduced interesting decisions regarding use vs. conservation of ordnance which is a good thing even if some players die a little bit inside when they "waste" a missile.
-
Yeah, my main problem with missile sensors is
1. They seem to stop in space if the FC assigned target is destroyed, insteading of continuing to head in the same direction
2. The missiles in any given salvo that are using sensors all target a single ship, instead of targeting multiple ships.
I don't mind that if I fire 40 missiles in one salvo, they won't retarget in after killing their target
What I mind is that if I fire two salvos of 20 with a 15 second delay, and the first salvo kills the target, the second salvo will only ever hit 1 ship.
Example of why this is bad: If fighting FACs and launching salvos as rapidly as possible, the moment a target is killed all other salvos going for that target that hadn't hit yet will hit a single FAC, instead of spreading out, meaning that using missile sensors to prevent follow-up salvos from being wasted is almost useless.
-
Yeah, my main problem with missile sensors is
1. They seem to stop in space if the FC assigned target is destroyed, insteading of continuing to head in the same direction
2. The missiles in any given salvo that are using sensors all target a single ship, instead of targeting multiple ships.
I don't mind that if I fire 40 missiles in one salvo, they won't retarget in after killing their target
What I mind is that if I fire two salvos of 20 with a 15 second delay, and the first salvo kills the target, the second salvo will only ever hit 1 ship.
Example of why this is bad: If fighting FACs and launching salvos as rapidly as possible, the moment a target is killed all other salvos going for that target that hadn't hit yet will hit a single FAC, instead of spreading out, meaning that using missile sensors to prevent follow-up salvos from being wasted is almost useless.
This is supposed to be handled if you put active sensors on your missiles...admittedly it's a bit silly that the ship's own sensors/MFC cannot issue the correction to the missiles but that's how it's done in-game.
That said, tactically it's rarely a good idea to send a follow-up salvo unless you've badly underestimated a ship's capabilities. If your first salvo which "should" be enough to kill the target fails, it should still have mission-killed the target and rendered it combat-ineffective, thus you are better off shooting at another target anyways and leaving the first target for mop-up work. Of course if the first ship is not mission killed or even heavily damaged, mistakes have been made as they say.
-
This is supposed to be handled if you put active sensors on your missiles...admittedly it's a bit silly that the ship's own sensors/MFC cannot issue the correction to the missiles but that's how it's done in-game.
That said, tactically it's rarely a good idea to send a follow-up salvo unless you've badly underestimated a ship's capabilities. If your first salvo which "should" be enough to kill the target fails, it should still have mission-killed the target and rendered it combat-ineffective, thus you are better off shooting at another target anyways and leaving the first target for mop-up work. Of course if the first ship is not mission killed or even heavily damaged, mistakes have been made as they say.
Yes... I think it is important that we don't get lazy and use the information that we have to judge the amount of missiles you need to severely damage or destroy an enemy ship without wasting ammunition.
If it is the first salvo you fire against an enemy with unknown capabilities you should consider the first salvo a probing attack to understand the opponents capabilities. If you massively overkill in your first attack it might be difficult to understand what their overall capabilities are. My first attack on an unknown enemy usually mean I spread the damage among as many different enemy ships so I can get as much information about them as possible.
It also generally is more efficient to damage enemy ships than outright destroy them in the first attack, it makes them more vulnerable to a second strike and overall you will use less ordnance. I also think that you should make sure you have enough fire-controls so each salvo is not too large.
-
- My 2 cents on Missile Sensors. I just want missile sensors fixed so I can go back to using mines and performing Waypoint Firing with my passive sensors stealth ships. :) I never use the re-targeting function, tbh.
-
- My 2 cents on Missile Sensors. I just want missile sensors fixed so I can go back to using mines and performing Waypoint Firing with my passive sensors stealth ships. :) I never use the re-targeting function, tbh.
Yes... that would be nice... just as long as not all your missiles target the same ship this would work fine.
-
All this missile talk might be better off in its own thread.
-
All this missile talk might be better off in its own thread.
You would think so, but within ten posts that thread would be a discussion about ground forces or something. It's really quite impressive how these things go.
-
By the way, made the aforementioned test executable (compiled for windows and linux)
Also included source code (should all be attached to this post)
-
Will missile retargeting be fixed in v1.13?
What is the bug?
As it stands self-guided missile salvos that hit their target simultaneously will not avoid overkill like they used to in VB6. My understanding is that when a bunch of self-guided missiles destroy a target, any missiles that are still around should re-target another ship within their detection radius - this does not happen for any salvos that hit their target at the same time.
Re-targeting only works if the salvos are staggered where they arrive one-after-the-other. Thanks to how gauss PD works, this makes the main feature of self-guidance very bad against anything that has PD. This kind of makes self-guided incredibly weak compared to standard missiles, especially thanks to the changes to onboard sensor size.
That is working as intended. If missiles A and B arrive simultaneously, then B would not know if A had destroyed the target ship and therefore could not change behaviour on that basis.
-
Will missile retargeting be fixed in v1.13?
What is the bug?
As it stands self-guided missile salvos that hit their target simultaneously will not avoid overkill like they used to in VB6. My understanding is that when a bunch of self-guided missiles destroy a target, any missiles that are still around should re-target another ship within their detection radius - this does not happen for any salvos that hit their target at the same time.
Re-targeting only works if the salvos are staggered where they arrive one-after-the-other. Thanks to how gauss PD works, this makes the main feature of self-guidance very bad against anything that has PD. This kind of makes self-guided incredibly weak compared to standard missiles, especially thanks to the changes to onboard sensor size.
That is working as intended. If missiles A and B arrive simultaneously, then B would not know if A had destroyed the target ship and therefore could not change behaviour on that basis.
Very well, that by itself is fine, but you do also understand that this makes naval mines largely useless correct? Because if I put 30 mines in one spot, the most they can do is destroy one ship according to this.
-
Very well, that by itself is fine, but you do also understand that this makes naval mines largely useless correct? Because if I put 30 mines in one spot, the most they can do is destroy one ship according to this.
Mines don't really work at all anyway so not sure it matters all that much. Mines if implemented could use a similar method as the "fire at will" command to semi randomly target something.
In general mines don't work all that well to begin with as you only need one ship to trigger a whole minefield.
-
Very well, that by itself is fine, but you do also understand that this makes naval mines largely useless correct? Because if I put 30 mines in one spot, the most they can do is destroy one ship according to this.
Maybe don't put all the mines in the same spot :)
If you stagger the location of the mines, that will also stagger their arrival at the target. For example, if you have missiles that are 20,000 km/s, set up one set of mines at 99,000 km and a second at 101,000 km (and a third at 201,000, etc.). Or setup mines at max distance but in two or more directions, so that ships moving away from the jump point will be hit by one and then the other. Or set up mines in concentric circles.
I could also perhaps add some form of random targeting if a second stage missile is launched without a parent fire control.
-
I could also perhaps add some form of random targeting if a second stage missile is launched without a parent fire control.
This, please, yeah!!!
-
Very well, that by itself is fine, but you do also understand that this makes naval mines largely useless correct? Because if I put 30 mines in one spot, the most they can do is destroy one ship according to this.
Maybe don't put all the mines in the same spot :)
If you stagger the location of the mines, that will also stagger their arrival at the target. For example, if you have missiles that are 20,000 km/s, set up one set of mines at 99,000 km and a second at 101,000 km (and a third at 201,000, etc.). Or setup mines at max distance but in two or more directions, so that ships moving away from the jump point will be hit by one and then the other. Or set up mines in concentric circles.
I could also perhaps add some form of random targeting if a second stage missile is launched without a parent fire control.
The random targeting would be amazing.
As for staggering mines, that makes sense but again becomes super weak against any sort of PD.
-
Aside of drastic lowering of PD breakthrough chances, staggering mine fields would be inevitably very micro-heavy.
-
Some form of random targeting of second stage missiles or mines would be great.
I would like to be able to fire a missile at a point in space and then have the missile deploy a second stage that randomly target something in range.
-
Aside of drastic lowering of PD breakthrough chances, staggering mine fields would be inevitably very micro-heavy.
Couldn't you just have your 'mines' be their own 2 stage and stagger the placement?
-
Couldn't you just have your 'mines' be their own 2 stage and stagger the placement?
Sorry, I cannot understand what is your question/suggestion.
I can stagger the placement, yes, but it's rather heavy micromanagement.
-
Really the most unrealistic part of Aurora's missile damage model is that it damages a discrete section of the armor instead of being spread across the entire armor belt with some gradient based on an assumed distance from the explosion center. In this sense the damage model appears to represent a direct impact of ~kT warheads rather than nearby detonation of ~MT warheads, though I'd more readily just attribute this to handwaving to fit the game mechanics.
It is game-play based rather than realistic. Also to restrict damage to a single ship.
Here are the nuclear detonation rules for Newtonian Aurora, which does spread the damage over half the armour belt.
http://aurora2.pentarch.org/index.php?topic=4329.msg43459#msg43459
Given the severe limitations on range for thermonuclear warheads detonating in vacuum, the standard armor/damage model does make some sense. A symmetric release of high-power x-rays is still very damaging, but with no atmosphere to be converted into a big blastwave you have to get the warhead to within tens of meters of the target to do real damage.
On the other hand, there are various sensible ways to "shape" the charge to get more efficient damage out of smaller warheads; such as using the nuke to pump a directional x-ray laser (as we all remember from VB6,) and of course the "Casabah Howitzer" which used a heavy neutron reflector and tungsten to create a nuclear shaped charge working much like conventional HE charges do; using the nuclear blast to propel a heavy mass medium towards a target; converting x-rays into directed kinetic energy.
Given that even final defensive fire would probably see k-slugs engaging at tens of kilometres and lasers at 5-9, it'd behoove missile designers to favor weapon designs that bridge the "last kilometre" instantly to a degree. One could well assume that the to-hit probabilities involved for both missiles and PD fire assume such designs. The blooming shape of the missile warhead damage template reflects that even a high-speed jet of tungsten plasma is going to spread more at a few km's range than lasers or particle lances.
-
Really the most unrealistic part of Aurora's missile damage model is that it damages a discrete section of the armor instead of being spread across the entire armor belt with some gradient based on an assumed distance from the explosion center. In this sense the damage model appears to represent a direct impact of ~kT warheads rather than nearby detonation of ~MT warheads, though I'd more readily just attribute this to handwaving to fit the game mechanics.
It is game-play based rather than realistic. Also to restrict damage to a single ship.
Here are the nuclear detonation rules for Newtonian Aurora, which does spread the damage over half the armour belt.
http://aurora2.pentarch.org/index.php?topic=4329.msg43459#msg43459
Given the severe limitations on range for thermonuclear warheads detonating in vacuum, the standard armor/damage model does make some sense. A symmetric release of high-power x-rays is still very damaging, but with no atmosphere to be converted into a big blastwave you have to get the warhead to within tens of meters of the target to do real damage.
On the other hand, there are various sensible ways to "shape" the charge to get more efficient damage out of smaller warheads; such as using the nuke to pump a directional x-ray laser (as we all remember from VB6,) and of course the "Casabah Howitzer" which used a heavy neutron reflector and tungsten to create a nuclear shaped charge working much like conventional HE charges do; using the nuclear blast to propel a heavy mass medium towards a target; converting x-rays into directed kinetic energy.
Given that even final defensive fire would probably see k-slugs engaging at tens of kilometres and lasers at 5-9, it'd behoove missile designers to favor weapon designs that bridge the "last kilometre" instantly to a degree. One could well assume that the to-hit probabilities involved for both missiles and PD fire assume such designs. The blooming shape of the missile warhead damage template reflects that even a high-speed jet of tungsten plasma is going to spread more at a few km's range than lasers or particle lances.
I read a series recently, and wish I could recall which. But the missile warheads were converted to a plasma form that did the actual damage, not the nuclear explosion.
-
Really the most unrealistic part of Aurora's missile damage model is that it damages a discrete section of the armor instead of being spread across the entire armor belt with some gradient based on an assumed distance from the explosion center. In this sense the damage model appears to represent a direct impact of ~kT warheads rather than nearby detonation of ~MT warheads, though I'd more readily just attribute this to handwaving to fit the game mechanics.
It is game-play based rather than realistic. Also to restrict damage to a single ship.
Here are the nuclear detonation rules for Newtonian Aurora, which does spread the damage over half the armour belt.
http://aurora2.pentarch.org/index.php?topic=4329.msg43459#msg43459
Given the severe limitations on range for thermonuclear warheads detonating in vacuum, the standard armor/damage model does make some sense. A symmetric release of high-power x-rays is still very damaging, but with no atmosphere to be converted into a big blastwave you have to get the warhead to within tens of meters of the target to do real damage.
On the other hand, there are various sensible ways to "shape" the charge to get more efficient damage out of smaller warheads; such as using the nuke to pump a directional x-ray laser (as we all remember from VB6,) and of course the "Casabah Howitzer" which used a heavy neutron reflector and tungsten to create a nuclear shaped charge working much like conventional HE charges do; using the nuclear blast to propel a heavy mass medium towards a target; converting x-rays into directed kinetic energy.
Given that even final defensive fire would probably see k-slugs engaging at tens of kilometres and lasers at 5-9, it'd behoove missile designers to favor weapon designs that bridge the "last kilometre" instantly to a degree. One could well assume that the to-hit probabilities involved for both missiles and PD fire assume such designs. The blooming shape of the missile warhead damage template reflects that even a high-speed jet of tungsten plasma is going to spread more at a few km's range than lasers or particle lances.
I read a series recently, and wish I could recall which. But the missile warheads were converted to a plasma form that did the actual damage, not the nuclear explosion.
No need to allude to fiction with this one; this technology was actually developed in real life, as part of the Orion project. Google "Casaba-Howitzer."
The scientists were very pleased with themselves; having developed a way to make the propulsion bombs for Project Orion drastically cheaper by directing all the energy at the pusher plate. About ten seconds after they finished patting themselves on the back, they realized that if one was to not engineer the resulting plasma cone to spread across as much of the pusher plate as possible, it would actually be a horrifyingly powerful weapon. Others have done the back-of-the-envelope math and found that a megaton-yield device could make a plasma jet tight and coherent enough to be dangerous out to a range of light seconds.
And that is why elements of Project Orion are still classified to this very day.
-
Given the severe limitations on range for thermonuclear warheads detonating in vacuum, the standard armor/damage model does make some sense. A symmetric release of high-power x-rays is still very damaging, but with no atmosphere to be converted into a big blastwave you have to get the warhead to within tens of meters of the target to do real damage.
Within megaton-range warheads and without gamma mirrors on the hull - atmosphere is not necessary to make blastwave, because target's hull in this distance without atmosphere's protective pillow will be instantly, within microseconds, vaporized by direct, unimpaired gamma wave. This lash of hull's vapour will be much more hazardous blastwave than any air blastwave possible. Think about it it as like half of your hull's surface will be converted in extra-brisant explosive, that will be detonated with extreme synchronism. In fact, that's what nuclear explosion makes with atmosphere, but without losses to inner atmosphere ball's heating and lifting (that's smth like 1/3 to 1/2 of atmosphere nuke energy) and without sprawling of air blastwave, that will weaken it's hazardous effect - without atmosphere nuke will make the same blastwave out of hull matter instead of air matter.
-
Steve in regards to the last change you didnt list rahkas as an option is this because NPRs never could generate them or is it because rahkas are having more stuff looked at because they are bugged atm.
or just a simple thing of forgetting to list it there, clarification would be great.
-
Steve in regards to the last change you didnt list rahkas as an option is this because NPRs never could generate them or is it because rahkas are having more stuff looked at because they are bugged atm.
or just a simple thing of forgetting to list it there, clarification would be great.
I left it out for now, as I think I fixed Rakhas but didn't want NPRs generating them until I was sure :)
-
gotcha so the rahkas disappearing after save is sorted then (hopefully), i cant wait to fight them properly i managed to land forces before saving and they got decimated so this is gonna be really interesting to play with once its fixed.
-
If a missile releases its second stage and has no assigned parent fire control, the second stage missiles will select a target randomly using the following guidelines
...
•The target must be hostile and not have friendly boarders.
...
Very considerate of the missiles to avoid our boarders.
I realize that this is a convenience of life thing, but it's just funny to me that an automated missile would go "whelp, better avoid that enemy ship - pretty sure it's got friendlies on board!"
-
If a missile releases its second stage and has no assigned parent fire control, the second stage missiles will select a target randomly using the following guidelines
...
•The target must be hostile and not have friendly boarders.
...
Very considerate of the missiles to avoid our boarders.
I realize that this is a convenience of life thing, but it's just funny to me that an automated missile would go "whelp, better avoid that enemy ship - pretty sure it's got friendlies on board!"
Actually it wouldnt avoid a ship being boarded until the marines have captured the vessel as it would still be seen as an enemy, also this is the future am sure these missiles have some kind of intelligence onboard that lets them make these kinds of decisions mid flight, especially considering they are flying at tens of thousands of km/s
trying to hit ships that are also doing that.
-
I think it's just marines have a habit to bring IFF (Identification, friend or foe) responders with current codes in their satchels and fix them at the hull during boarding action.
-
I think it's just marines have a habit to bring IFF (Identification, friend or foe) responders with current codes in their satchels and fix them at the hull during boarding action.
Yes, that was also in my head when thinking of a reason to include that parameter :)
-
Hi Steve, could we also get an option at some point to export the commander name theme setup and/or rank setup?
I usually add several dozen commander name themes for an 'international' game and also usually edit the rank names to add a junior officer rank and it's a pain to set up every time.
-
My excitement level for 1.13 grows. I ended my long running 1.12 game a couple of weeks ago and haven’t started another because I can’t imagine without playing with the 1.13 updates. The player made cosmetic components and the the STO/ground support fighter changes are big for me.
-
My excitement level for 1.13 grows. I ended my long running 1.12 game a couple of weeks ago and haven’t started another because I can’t imagine without playing with the 1.13 updates. The player made cosmetic components and the the STO/ground support fighter changes are big for me.
What changes have been made to ground support fighters? Cannot find anything on the change list regarding them.
It sounds like they are still going to be micro nightmare/unusable in 1.13 during combat. (carrier auto build helps but was never a massive problem thanks to sub-fleets)
-
Fixed bug that allowed STO units to fire at fighters on ground support missions.
Fixed bug that prevented fighters on search and destroy missions from attacking planets without friendly populations.
-
If there was any STO on planet, it pretty much rendered Ground Support Fighters useless because they would get obliterated prior to having any effect whatsoever.
-
Fixed bug that allowed STO units to fire at fighters on ground support missions.
Fixed bug that prevented fighters on search and destroy missions from attacking planets without friendly populations.
Oh right, I was thinking of how bad the UI micro is for actually assigning fighters to support ground formations and didn't see anything relating to that.
Sorry I am very one-minded when it comes to my problems with ground support fighters which is why I kind of "ignored" the fix list there.
Still important fixes though.
-
I'm waiting greedy for 1.13 too, but the most desired for me are fixes of auto-assignment and Fire At Will + Random Second Stage Targeting features.
-
Thank God for the change removing ground force size limitation to Commanders. I often had to go back in and change out Commanders in larger formations because the auto assign wanted to assign a guy with GCB of 5,000 to command my Armor Corp of 600K.
-
Question: does the random targeting for 2-stage missiles also apply to single-stage missiles that have onboard sensors and had their target be destroyed before the missiles reached the target?
-
Thank God for the change removing ground force size limitation to Commanders. I often had to go back in and change out Commanders in larger formations because the auto assign wanted to assign a guy with GCB of 5,000 to command my Armor Corp of 600K.
I had the opposite problem, my skilled leaders with 2,000 ton GCC wouldn't auto-fill any 5,000-ton battalion command even though mechanically nothing prevented them from taking that command and they would still give 40% of their bonuses - better than nothing! This is a good change, possibly the best of this latest batch for me although there's a lot in there.
-
Good to see mines are back and I love the setup for spoilers.
Nice touch adding the Travelled distance and I agree with the decision of removing the commander combat bonus. It was an interesting idea, however, it was too hard sometimes to find the right officers considering they do not rain already. Ultimately was also a limitation in the size of some custom corps.
-
I can't help but wonder and ask this question. Are there any specific goals with 1.13? It does seem like it is a much larger update than previous ones. Though IIRC 1.11 (1.12? Cant seem to remember) was very large with the whole invader stuff.
-
I can't help but wonder and ask this question. Are there any specific goals with 1.13? It does seem like it is a much larger update than previous ones. Though IIRC 1.11 (1.12? Cant seem to remember) was very large with the whole invader stuff.
You're thinking 1.10 which added invaders. 1.11 was quite small from the change log, and 1.12 had unit replacement series as the "big" feature along with many smaller additions.
1.13 is definitely pretty big as we've already seen a number of new big features, notably reduced-size railguns, which will basically add a whole new class of fighters to play with, and the misc components. Plus a large amount of very popular QoL changes. I suspect at this point probably we will see release when Steve "finishes" his current fiction campaign which is basically the testbed for a lot of these changes.
-
I can't help but wonder and ask this question. Are there any specific goals with 1.13? It does seem like it is a much larger update than previous ones. Though IIRC 1.11 (1.12? Cant seem to remember) was very large with the whole invader stuff.
No specific goal, although it is getting larger :)
The update is mainly the result of bug fixes, a trawl through the suggestions thread and some changes to fix issues I encountered myself. As you might guess from the import/export changes I am probably going to start a new campaign soon. The current one has four Swarm races, all of which were spawned by NPRs and are beating up those NPRs, which is why I added the option to specify which spoilers would be generated by NPRs. I am probably going to run a Swarm-free campaign, as I have fought them a lot in recent campaigns so I would like a different challenge. I'm also going to start smaller and push the starting NPRs further out to allow more of a build-up phase.
I've not been very active in the last month or two for a few reasons, one of which is my new trading hobby which is taking time away from my Aurora hobby :) However, I have some stocks that I want to mainly hold for a while so that gives me time to focus on Aurora for the next few weeks. I'll probably run the new campaign for a while to test the recent changes and then look at a potential release.
-
Don't hold those stocks over the upcoming market crash... ::)
-
Don't hold those stocks over the upcoming market crash... ::)
I'm entirely in mineral exploration stocks so they are less affected by the general movements of the stock market (famous last words!).
-
I'm entirely in mineral exploration stocks so they are less affected by the general movements of the stock market (famous last words!).
Why am I not surprised you are mainly into MINERALS... ;D
-
I would be slightly cautious with anything related to minerals right now. https://silverprice.org/
As of right now, I believe Silver especially is overpriced, it has only been higher than $20 USD once in the last five years. Now it is all the way up at $27. Gold is on a downwards trend I think, but Gold always tends upwards long term, so that won't be an issue I believe.
-
I would be slightly cautious with anything related to minerals right now. https://silverprice.org/
As of right now, I believe Silver especially is overpriced, it has only been higher than $20 USD once in the last five years. Now it is all the way up at $27. Gold is on a downwards trend I think, but Gold always tends upwards long term, so that won't be an issue I believe.
Okay but how is the duranium market?
-
I would be slightly cautious with anything related to minerals right now. https://silverprice.org/
As of right now, I believe Silver especially is overpriced, it has only been higher than $20 USD once in the last five years. Now it is all the way up at $27. Gold is on a downwards trend I think, but Gold always tends upwards long term, so that won't be an issue I believe.
Okay but how is the duranium market?
Duranium is weak stock. Invest in gallicite
-
I would be slightly cautious with anything related to minerals right now. https://silverprice.org/
As of right now, I believe Silver especially is overpriced, it has only been higher than $20 USD once in the last five years. Now it is all the way up at $27. Gold is on a downwards trend I think, but Gold always tends upwards long term, so that won't be an issue I believe.
Okay but how is the duranium market?
Duranium is weak stock. Invest in gallicite
Gold has served me well... I mean gallicite.
-
Oops... I derailed the "Change Discussion Thread" into a stock market floor... ;)
-
I would be slightly cautious with anything related to minerals right now. https://silverprice.org/
As of right now, I believe Silver especially is overpriced, it has only been higher than $20 USD once in the last five years. Now it is all the way up at $27. Gold is on a downwards trend I think, but Gold always tends upwards long term, so that won't be an issue I believe.
Most gold forecasts for the next few years are on the high side, primarily due to the amount of money being pumped into economies due to COVID. Even so, the main focus for me at the moment is copper exploration with gold as a backup. Copper demand is rising due to all the green energy requirements, supply is falling and mining grades are falling. Consequently, the ongoing price rise is opening up deposits and areas of exploration than were once considered uneconomic. I do have some exposure to silver but no more so than other metals like molybdenum. I also plan to invest in a nickel miner in the near future. I decided to focus on exploration and early-stage mining because I thought it would be better to understand one sector in depth than invest in a wide-range of sectors with a lower level of knowledge. Anyway, I'll probably should not go into to detail here. Maybe we need an investing sub-forum :) It would certainly be better-run that all the stock market forms online.
-
But muh game stonks
e: In all seriousness I'd probably be down
-
I heard the Duke brothers know something and they are cornering the frozen concentrated orange juice futures. But my money is with Valentine and Winthorpe, a pair of up and coming commodity traders.
-
Since there are Miscellaneous Components is it possible to add Miscellaneous Installations?
Also, some installations to convert POW into a usable population (so we can force them to work in labor camps :-X ).
-
Numbering on a formation basis
Hooray! Finally, about time I sa--
Roman numerals
Ooh, very nice, this will be nice for flav--
"Sort Creation" button
Steve is a god. ;D ;D ;D
Not to look a gift horse dev in the mouth, but if we could also have this in the Fleet Window that would be amazing.
-
Numbering on a formation basis: I would like to add a vote for "numbering on a ship class basis". I.e. when I upgrade my cargo transports I would like to keep the numbers increasing rather than restart with 001. It also would be nice if the name of the ship could be different from the class name. I.e. my transports are named for example "Bull Mk.1 class transport vessel", and then "Bull Mk.2 class transport vessel", etc. But the cargo ships should be named "Bull 001", "Bull 002" etc., independent from the Mk.x version... possible?
-
I heard the Duke brothers know something and they are cornering the frozen concentrated orange juice futures. But my money is with Valentine and Winthorpe, a pair of up and coming commodity traders.
FYI, Insider trading is illegal. ;)
-
Steve, you are absolutely killing it in these last few days. Also, I love the mental image of a tired Steve coming home from work, booting up his pc to work on his game centrally focused on mineral exploitaiton in space, and after getting bored with it he goes on the internet to check his mineral exploration stocks. This is peak Steve, it's really cool!
-
So will the reduced-shot railguns make them the go-to weapon for beam fighters? I try to keep my fighters at 125 tons and always had trouble fitting gauss cannons in them. They are only meant to act as mobile PD for the bombers anyways.
-
So will the reduced-shot railguns make them the go-to weapon for beam fighters? I try to keep my fighters at 125 tons and always had trouble fitting gauss cannons in them. They are only meant to act as mobile PD for the bombers anyways.
Almost certainly, Gauss on fighters will now have no real advantage over railguns (technically it doesn't now, unless you use fighters much smaller than 500 tons) as an equivalent Gauss cannon weighs about twice as much as a railgun and on a fighter you don't benefit as much from turrets (which also add more weight).
If Steve ever fixed the reduced size lasers bug then 10 cm Lasers will also be viable for fighters, with the larger range allowing them to fill an anti-fighter role. Otherwise the other weapons are really only for very specialized designs e.g. plasma bombers.
-
What's wrong with reduced-size lasers?
-
What's wrong with reduced-size lasers?
They don`t work, .5 size reduction doesn`t lower the 100mm Lasres mass below 100tons.
So will the reduced-shot railguns make them the go-to weapon for beam fighters? I try to keep my fighters at 125 tons and always had trouble fitting gauss cannons in them. They are only meant to act as mobile PD for the bombers anyways.
Steves said a single shot 100mm railgun will mass 49tons to match that for damage you need at minimum a sixth scale rate of fire 5 gauss cannon, and it be slightly less accurate then, at RoF 6+ the gauss cannon is better though.
-
So will the reduced-shot railguns make them the go-to weapon for beam fighters? I try to keep my fighters at 125 tons and always had trouble fitting gauss cannons in them. They are only meant to act as mobile PD for the bombers anyways.
Steves said a single shot 100mm railgun will mass 49tons to match that for damage you need at minimum a sixth scale rate of fire 5 gauss cannon, and it be slightly less accurate then, at RoF 6+ the gauss cannon is better though.
Actually one ROF higher. 49 tons, round up to 50 for neatness, is 1 HS, and a 1 HS Gauss cannon has 17% accuracy. You need ROF 6 to match the expected damage of a 10 cm railgun and ROF 8 to exceed it as there is no ROF 7 - a very expensive (750k RP) proposition so really only worth it if you are also using Gauss for fleet PD as well.
-
So will the reduced-shot railguns make them the go-to weapon for beam fighters? I try to keep my fighters at 125 tons and always had trouble fitting gauss cannons in them. They are only meant to act as mobile PD for the bombers anyways.
Steves said a single shot 100mm railgun will mass 49tons to match that for damage you need at minimum a sixth scale rate of fire 5 gauss cannon, and it be slightly less accurate then, at RoF 6+ the gauss cannon is better though.
Actually one ROF higher. 49 tons, round up to 50 for neatness, is 1 HS, and a 1 HS Gauss cannon has 17% accuracy. You need ROF 6 to match the expected damage of a 10 cm railgun and ROF 8 to exceed it as there is no ROF 7 - a very expensive (750k RP) proposition so really only worth it if you are also using Gauss for fleet PD as well.
Derp 1 sixth scale gauss cannon at RoF 6 equals 1 hit per volley on average...that would be how math does indeed work yes...GC rof goes up to 8 by the way though your point still stands
-
Would it be possible at this stage to slip in a function to que up slipway expansions instead of having to do them one at a time?
-
So will the reduced-shot railguns make them the go-to weapon for beam fighters? I try to keep my fighters at 125 tons and always had trouble fitting gauss cannons in them. They are only meant to act as mobile PD for the bombers anyways.
It'll be interesting. In theory a four shot railgun fighter still does more damage/PD coverage per ton than a one shot railgun fighter that's a third the size, not to mention better range due to the fuel efficiency of larger engines. But dozens to hundreds of 125 ton fighters are going to be a nightmare to detect and shoot down; as the quote goes "quantity has a quality all its own."
-
I dont agree, heres my thoughts on it.
80, 125 ton Railgun fighters that use a 1 shot railgun are 10,000 tons
20, 500 ton Railgun fighters that use a 4 shot railgun are 10,000 tons (Keep in mind atm 400-500 tons is the amount required for railgun fighters due to BFC size, railgun weapon size and reactor size)
Both fire the exact same number of shots so in terms of PD they are the same, for anti ship railguns themselves have one of the worst damage patterns anyway so if its in chunks of four or 1 it will do around the same.
Now in terms of fuel efficiency yes larger fighters will be better but this is offset by the fact that you dont make beam fighters for their fuel efficiency you make them for their very fast speed and flexibility.
I agree with the point that 80+ Fighters are gonna be insanely hard to deal with for some fleets and you may overwhelm the enemy as they may have the weapons to destroy them or the ammo but they cant target enough of the fighters at a time before they themselves take damage, not only will this provide a useful distraction its also very dangerous especially when you combine this with other weapons as the enemy PD, missile and other capabilities will be fired a these fighters which are small, hard to hit due to speed and expendable.
-
I dont agree, heres my thoughts on it.
80, 125 ton Railgun fighters that use a 1 shot railgun are 10,000 tons
20, 500 ton Railgun fighters that use a 4 shot railgun are 10,000 tons (Keep in mind atm 400-500 tons is the amount required for railgun fighters due to BFC size, railgun weapon size and reactor size)
Both fire the exact same number of shots so in terms of PD they are the same, for anti ship railguns themselves have one of the worst damage patterns anyway so if its in chunks of four or 1 it will do around the same.
Now in terms of fuel efficiency yes larger fighters will be better but this is offset by the fact that you dont make beam fighters for their fuel efficiency you make them for their very fast speed and flexibility.
I agree with the point that 80+ Fighters are gonna be insanely hard to deal with for some fleets and you may overwhelm the enemy as they may have the weapons to destroy them or the ammo but they cant target enough of the fighters at a time before they themselves take damage, not only will this provide a useful distraction its also very dangerous especially when you combine this with other weapons as the enemy PD, missile and other capabilities will be fired a these fighters which are small, hard to hit due to speed and expendable.
A 500t fighter in a pure engagement will almost always win given equal tech level... they can have more armour use more efficient engines and require less space for fire-controls and sensors. They are just way more durable than the small ones. The only benefit of being small is essentially the stealth factor in terms of fighters so they are harder to fight with missiles. But as long as the opponent know your fighters size even this matters very little in the end.
A heavier fighter also can fit a heavier beam weapon which is deadly to other fighters even with less DPS.
-
I dont agree, heres my thoughts on it.
80, 125 ton Railgun fighters that use a 1 shot railgun are 10,000 tons
20, 500 ton Railgun fighters that use a 4 shot railgun are 10,000 tons (Keep in mind atm 400-500 tons is the amount required for railgun fighters due to BFC size, railgun weapon size and reactor size)
Both fire the exact same number of shots so in terms of PD they are the same, for anti ship railguns themselves have one of the worst damage patterns anyway so if its in chunks of four or 1 it will do around the same.
Now in terms of fuel efficiency yes larger fighters will be better but this is offset by the fact that you dont make beam fighters for their fuel efficiency you make them for their very fast speed and flexibility.
I agree with the point that 80+ Fighters are gonna be insanely hard to deal with for some fleets and you may overwhelm the enemy as they may have the weapons to destroy them or the ammo but they cant target enough of the fighters at a time before they themselves take damage, not only will this provide a useful distraction its also very dangerous especially when you combine this with other weapons as the enemy PD, missile and other capabilities will be fired a these fighters which are small, hard to hit due to speed and expendable.
A 500t fighter in a pure engagement will almost always win given equal tech level... they can have more armour use more efficient engines and require less space for fire-controls and sensors. They are just way more durable than the small ones. The only benefit of being small is essentially the stealth factor in terms of fighters so they are harder to fight with missiles. But as long as the opponent know your fighters size even this matters very little in the end.
A heavier fighter also can fit a heavier beam weapons which is deadly to other fighters even with less DPS.
I disagree on some of the points.
1A - Armour is not important for fighters really due to various reasons, 1. they cant even fit more armour on space wise because of how tight the margins are for beamfighters, 2. Most things that will hit it will do enough damage/shock damage to disable the fighter if not destroy it, 3. Fighters are generally expendable so putting armour on is just extra cost for not much gain.
2A - In terms of BFCs the main tonnage sink is the engines and the weapon for example on one of my railgun fighters 350 of the 500 tons are already gone for the weapon and engine, BFCs atm tend to be around 50 tons, reactors 30-35 at around Ion-magneto, and the rest is fuel, so while your correct you have less space in practise not really at all, since percent wise its gonna be the same with the changes made, also the idea of "sensors" on a beamfighter is just dumb, any beamfighter will not have its own sensors as its too much tonnage that could be used on fuel or anything else as beamfighters are inherently quite massive, instead they use their carries or an AWACs that accompanies them.
3A - I disagree that the only benefit is stealth yes that is one of the benefits but as stated in the previous post if you have 80 fighters instead of 20 you have 60 more targets for the enemy to shoot at, and lets be real if you get hit once in a fighter theres an 80% chance its either disabled or destroyed so this will actually massively increase survivability in terms of endurance in being effective.
4A - While technically this is true it doesnt change tonnage efficiency or anything else, now for lasers fighters you may have a point as a larger laser can and will penetrate deeper but for railgun fighters this matters little as railgun damage pattern is not good at all.
At the end of the day we can argue forever but I for one am happy we have more choice in 1.13 where we can decide on what doctrine to use fighter wise either swarm or heavier more deadly fighters, we dont have this in 1.12, keep in mind this is all preference, peoples own doctrine and how they use fighters so its gonna be heavily subjective in many regards.
-
I dont agree, heres my thoughts on it.
80, 125 ton Railgun fighters that use a 1 shot railgun are 10,000 tons
20, 500 ton Railgun fighters that use a 4 shot railgun are 10,000 tons (Keep in mind atm 400-500 tons is the amount required for railgun fighters due to BFC size, railgun weapon size and reactor size)
Both fire the exact same number of shots so in terms of PD they are the same, for anti ship railguns themselves have one of the worst damage patterns anyway so if its in chunks of four or 1 it will do around the same.
Now in terms of fuel efficiency yes larger fighters will be better but this is offset by the fact that you dont make beam fighters for their fuel efficiency you make them for their very fast speed and flexibility.
I agree with the point that 80+ Fighters are gonna be insanely hard to deal with for some fleets and you may overwhelm the enemy as they may have the weapons to destroy them or the ammo but they cant target enough of the fighters at a time before they themselves take damage, not only will this provide a useful distraction its also very dangerous especially when you combine this with other weapons as the enemy PD, missile and other capabilities will be fired a these fighters which are small, hard to hit due to speed and expendable.
A 1-shot railgun will be larger than 1/4 of a 4-shot railgun (35% rather than 25%), meaning if you design a 125-ton fighter with a 1-shot railgun, it has less fraction to be used for engines. So you cannot assume they perform the same when doing PD duties. Yes, the number of shots is the same, but the tracking speed on the 125-ton fighters will be worse than the 500-ton ones.
If the two fighter designs have a similar weapon/engine/fuel ratio, the smaller one utilizing the 1-shot railgun will be roughly 1/3 size of a 500-ton one. So yes they will be more numerous, but ton-for-ton efficiency is lower.
-
For the following list of components, the Development Cost has been changed to: SQRT(Cost * 5000)
snip
I notice that the only ship design component not listed are HPMs. Is there a reason for this, or an oversight in the listing?
For ground units the breakeven point is a cost of 10 BP. For example, the development cost of a minimal armour static HQ with 250,000 capacity will reduce from 5,012 RP to 1,583 RP.
This is absolutely the best news I've heard all day. Personally I didn't mind linear component RP costs as much as others did, but the ground HQ costs were a major thorn so this is an A++ change.
-
I dont agree, heres my thoughts on it.
80, 125 ton Railgun fighters that use a 1 shot railgun are 10,000 tons
20, 500 ton Railgun fighters that use a 4 shot railgun are 10,000 tons (Keep in mind atm 400-500 tons is the amount required for railgun fighters due to BFC size, railgun weapon size and reactor size)
Both fire the exact same number of shots so in terms of PD they are the same, for anti ship railguns themselves have one of the worst damage patterns anyway so if its in chunks of four or 1 it will do around the same.
Now in terms of fuel efficiency yes larger fighters will be better but this is offset by the fact that you dont make beam fighters for their fuel efficiency you make them for their very fast speed and flexibility.
I agree with the point that 80+ Fighters are gonna be insanely hard to deal with for some fleets and you may overwhelm the enemy as they may have the weapons to destroy them or the ammo but they cant target enough of the fighters at a time before they themselves take damage, not only will this provide a useful distraction its also very dangerous especially when you combine this with other weapons as the enemy PD, missile and other capabilities will be fired a these fighters which are small, hard to hit due to speed and expendable.
A 4 shot 10cm railgun is 150 tons, a 1 shot railgun is 49 tons. So assuming exactly the same tonnage proportionately, you'd have 3 1 shot fighters for every 4 shot fighter. Actually a little less, since you need a few tons for the fire control and crew quarters, less efficient power plant, etc.
So you're trading a 25% reduction in firepower for having three targets instead of one. That's not necessarily a bad trade - there are a lot of situations where having 3 smaller fighters makes them much harder to deal with, particularly if the enemy is trying to kill your fighters with missiles - but it's not a clear upgrade, either. Like I said, it's going to be an interesting tradeoff.
If your fighters' primary job is providing PD support for larger ships or picking off damaged/defenseless targets, you're probably better off with 4 shot railguns since they get more shots per ton. If you want the fighters to charge the enemy and duke it out in beam range, I think 1-shots are better - trading 25% less firepower for effectively 200% more hitpoints (the larger fighters are technically more durable, but how often do fighters survive a hit?) is a decent looking trade.
-
I dont agree, heres my thoughts on it.
80, 125 ton Railgun fighters that use a 1 shot railgun are 10,000 tons
20, 500 ton Railgun fighters that use a 4 shot railgun are 10,000 tons (Keep in mind atm 400-500 tons is the amount required for railgun fighters due to BFC size, railgun weapon size and reactor size)
Both fire the exact same number of shots so in terms of PD they are the same, for anti ship railguns themselves have one of the worst damage patterns anyway so if its in chunks of four or 1 it will do around the same.
Now in terms of fuel efficiency yes larger fighters will be better but this is offset by the fact that you dont make beam fighters for their fuel efficiency you make them for their very fast speed and flexibility.
I agree with the point that 80+ Fighters are gonna be insanely hard to deal with for some fleets and you may overwhelm the enemy as they may have the weapons to destroy them or the ammo but they cant target enough of the fighters at a time before they themselves take damage, not only will this provide a useful distraction its also very dangerous especially when you combine this with other weapons as the enemy PD, missile and other capabilities will be fired a these fighters which are small, hard to hit due to speed and expendable.
A 500t fighter in a pure engagement will almost always win given equal tech level... they can have more armour use more efficient engines and require less space for fire-controls and sensors. They are just way more durable than the small ones. The only benefit of being small is essentially the stealth factor in terms of fighters so they are harder to fight with missiles. But as long as the opponent know your fighters size even this matters very little in the end.
A heavier fighter also can fit a heavier beam weapons which is deadly to other fighters even with less DPS.
I disagree on some of the points.
1A - Armour is not important for fighters really due to various reasons, 1. they cant even fit more armour on space wise because of how tight the margins are for beamfighters, 2. Most things that will hit it will do enough damage/shock damage to disable the fighter if not destroy it, 3. Fighters are generally expendable so putting armour on is just extra cost for not much gain.
2A - In terms of BFCs the main tonnage sink is the engines and the weapon for example on one of my railgun fighters 350 of the 500 tons are already gone for the weapon and engine, BFCs atm tend to be around 50 tons, reactors 30-35 at around Ion-magneto, and the rest is fuel, so while your correct you have less space in practise not really at all, since percent wise its gonna be the same with the changes made, also the idea of "sensors" on a beamfighter is just dumb, any beamfighter will not have its own sensors as its too much tonnage that could be used on fuel or anything else as beamfighters are inherently quite massive, instead they use their carries or an AWACs that accompanies them.
3A - I disagree that the only benefit is stealth yes that is one of the benefits but as stated in the previous post if you have 80 fighters instead of 20 you have 60 more targets for the enemy to shoot at, and lets be real if you get hit once in a fighter theres an 80% chance its either disabled or destroyed so this will actually massively increase survivability in terms of endurance in being effective.
4A - While technically this is true it doesnt change tonnage efficiency or anything else, now for lasers fighters you may have a point as a larger laser can and will penetrate deeper but for railgun fighters this matters little as railgun damage pattern is not good at all.
At the end of the day we can argue forever but I for one am happy we have more choice in 1.13 where we can decide on what doctrine to use fighter wise either swarm or heavier more deadly fighters, we dont have this in 1.12, keep in mind this is all preference, peoples own doctrine and how they use fighters so its gonna be heavily subjective in many regards.
I'm sorry but you are just wrong and I have actually done test of this in the game and had MANY fighter engagements with beam fighter against each other... armour is super important and will make them survive very effectively. Even the small savings you do with BFC is huge and fighter ECM is also huge as they add even more survival ability, a small fighter just can't fit an ECM module at all. You also need at least a 5t active on most if not all fighters... otherwise your active sensor fighters are targeted first if you don't have something far off that have the sensor. A 500t fighter only suffer shock damage at 10% for 1 damage point (actually only a total of 2% as shock damage is only 20% of 1 damage), so they are quite likely to survive.... bigger weapon also means more HTK as well, even the engine will have 2 HTK at 200t witch you would want as that give you a 50% chance to survive a 1 point damage, this is important.
Bigger weapon mean longer range too which is huge in beam combat, this is why Lasers are so powerful in beam fighter combat, a 15cm (even 20cm) laser in a 500t figher is possible.
I think you need to actually test it and not theorise it... ;)
DPS is not as important as you might think, if you want a good beam fighter you should just make it as big as possible and use armour, just test it and you will see. The only reason you build fighter with small railguns is PD against missiles, they are NOT optimal against a beam fighter whose job it is to shoot down enemy fighters.
If I design my fighter for PD then I want as much PD as possible so that means a full size 10cm railgun... if I want something in between then a 12cm or 15cm railgun could be considered too in 1.13. Then they will be better in a beam engagement as well and pose a dual role. You could then have a few 15cm railgun fighters and a bunch of 10cm railgun fighters.
I would NEVER run a beam fighter without at least a 5t active res 1 sensor... it is just too easy and a big loss if the sensor scout is somehow destroyed, also a reason I don't like small beam fighters. If your fighter ever only operate close to the carrier then sure... but then I don't see why their beam fighting skills would ever be of much use either, they have too short range for that. PD fighters are pretty bad at beam range fighting.
-
Well I am very excited with the new RP scaling changes. I was hoping for just ground formation HQ scaling to be changed, but it looks like nearly everything is getting hit with the RP=SQRT(SIZE) stick.
Even jump engines...
That should mean that large jump engines are much more practical now. This will be excellent and entertaining.
-
Well I am very excited with the new RP scaling changes. I was hoping for just ground formation HQ scaling to be changed, but it looks like nearly everything is getting hit with the RP=SQRT(SIZE) stick.
Even jump engines...
That should mean that large jump engines are much more practical now. This will be excellent and entertaining.
Yes... this is a big boon for larger ships as you will be able to afford larger military jump engines now, I will likely be able to afford my really large military engine carriers at much lower tech level now.
It will also make larger active sensor more affordable as well, even if they still are limited in use in general, but I still can afford the occasional larger active sensor as well.
It definitely will make larger engines way more affordable as well, they were really expensive before for the general benefit of having them.
Now I also will actually have to spend some RP developing my fighters and FAC and making allot of different version of fighters and FAC will actually have a price now, that is nice too.
I really like how this work... it will also make more complex components cheaper the higher you research technology, so you will be able to afford more diverse components the further up the technology tree you get which sort of make sense in a way. Low tech components are more expensive than high tech components to develop in relation to their cost.
-
I also really like this. It lends credence to the concept of 'economies of scale' for large components. Combined with all of the other new things that v113 is brining to the table I am going to have to seriously rethink my fleet composition and ship designs.
-
I'm very much a fan of the RP cost reduction for large components. As I almost always build large ships.
I'm looking at you, sensors and jump engines. ;D
Thank you Steve
-
I just saw the changes with regards to commander selection on the naval OOB menu which are really good.
Will the same work with admin commands?
-
I'm very much a fan of the RP cost reduction for large components. As I almost always build large ships.
I'm looking at you, sensors and jump engines. ;D
Thank you Steve
Ditto. The large engines were always a bother too. :)
-
I just saw the changes with regards to commander selection on the naval OOB menu which are really good.
Will the same work with admin commands?
AFAIK In VB Aurora you can click on any role in the commander window and the commander having that role will be automatically selected. It works for ground force commanders and administrators too. Wondering when and if this can be brought back to C# :P
-
In regard to "Miscellaneous Components" I was wondering if we could also link them to a character type. Say I want my science vessel to be equipped with a science lab section and then add a scientist to the ship. I think this would be fun for role-play perspective and give some needed jobs to characters that otherwise don't have any even if they don't actually do anything.
I could think of many other reasons for attaching different types of commanders, administrators or the like to ships.
-
In regard to "Miscellaneous Components" I was wondering if we could also link them to a character type. Say I want my science vessel to be equipped with a science lab section and then add a scientist to the ship. I think this would be fun for role-play perspective and give some needed jobs to characters that otherwise don't have any even if they don't actually do anything.
I could think of many other reasons for attaching different types of commanders, administrators or the like to ships.
I usually just use the Science Department option for this (150 tons seems reasonable & it creates an officer slot for the ship too). I use the same thing for my hospital ships treatment rooms, just headcanon that the officer is a doctor, or manufactory (officer is an engineer) and so forth. A long as the component is not really changing the capabilities of the ship it works OK.
-
In regard to "Miscellaneous Components" I was wondering if we could also link them to a character type. Say I want my science vessel to be equipped with a science lab section and then add a scientist to the ship. I think this would be fun for role-play perspective and give some needed jobs to characters that otherwise don't have any even if they don't actually do anything.
I could think of many other reasons for attaching different types of commanders, administrators or the like to ships.
I usually just use the Science Department option for this (150 tons seems reasonable & it creates an officer slot for the ship too). I use the same thing for my hospital ships treatment rooms, just headcanon that the officer is a doctor, or manufactory (officer is an engineer) and so forth. A long as the component is not really changing the capabilities of the ship it works OK.
I think Jorgen's idea was more to have a component where unused scientists and civ admins could be stationed for flavor...currently, many of these officers have not got much to do for large parts of the game - many civ admins won't be useful until late game when you have many developed colonies, and many scientists will just never get used because there's 2-3 better in their field. Ideally, it would be nice for those leaders to still have a chance to contribute, but as no niche exists for them flavor reasons and a new misc component would be sufficient.
-
In regard to "Miscellaneous Components" I was wondering if we could also link them to a character type. Say I want my science vessel to be equipped with a science lab section and then add a scientist to the ship. I think this would be fun for role-play perspective and give some needed jobs to characters that otherwise don't have any even if they don't actually do anything.
I could think of many other reasons for attaching different types of commanders, administrators or the like to ships.
I usually just use the Science Department option for this (150 tons seems reasonable & it creates an officer slot for the ship too). I use the same thing for my hospital ships treatment rooms, just headcanon that the officer is a doctor, or manufactory (officer is an engineer) and so forth. A long as the component is not really changing the capabilities of the ship it works OK.
I think Jorgen's idea was more to have a component where unused scientists and civ admins could be stationed for flavor. . . currently, many of these officers have not got much to do for large parts of the game - many civ admins won't be useful until late game when you have many developed colonies, and many scientists will just never get used because there's 2-3 better in their field. Ideally, it would be nice for those leaders to still have a chance to contribute, but as no niche exists for them flavor reasons and a new misc component would be sufficient.
On the topic of massive amounts of unused officers, it would be nice if there was something mechanically useful we could use them for. Scientists in particular have very few being useful at any one time relative to the amount of idlers. Maybe something akin to VB's Task Force staff officers? Or some sort of background task they can be assigned to?
-
On the topic of massive amounts of unused officers, it would be nice if there was something mechanically useful we could use them for. Scientists in particular have very few being useful at any one time relative to the amount of idlers. Maybe something akin to VB's Task Force staff officers? Or some sort of background task they can be assigned to?
Scientists can be assigned to naval admin commands when?
"Alpha Fleet and Beta Fleet, set a course directly towards each other at 10,000 km/s."
"Lord Admiral, sir, is this wise?"
"It's better than wise, Captain...it's science!!"
;D
-
In regard to "Miscellaneous Components" I was wondering if we could also link them to a character type. Say I want my science vessel to be equipped with a science lab section and then add a scientist to the ship. I think this would be fun for role-play perspective and give some needed jobs to characters that otherwise don't have any even if they don't actually do anything.
I could think of many other reasons for attaching different types of commanders, administrators or the like to ships.
I usually just use the Science Department option for this (150 tons seems reasonable & it creates an officer slot for the ship too). I use the same thing for my hospital ships treatment rooms, just headcanon that the officer is a doctor, or manufactory (officer is an engineer) and so forth. A long as the component is not really changing the capabilities of the ship it works OK.
I think Jorgen's idea was more to have a component where unused scientists and civ admins could be stationed for flavor. . . currently, many of these officers have not got much to do for large parts of the game - many civ admins won't be useful until late game when you have many developed colonies, and many scientists will just never get used because there's 2-3 better in their field. Ideally, it would be nice for those leaders to still have a chance to contribute, but as no niche exists for them flavor reasons and a new misc component would be sufficient.
On the topic of massive amounts of unused officers, it would be nice if there was something mechanically useful we could use them for. Scientists in particular have very few being useful at any one time relative to the amount of idlers. Maybe something akin to VB's Task Force staff officers? Or some sort of background task they can be assigned to?
When I play I usually have all my scientists researching even with only 1 lab cause it can give them bonuses to their research stat or max labs.
-
When I play I usually have all my scientists researching even with only 1 lab cause it can give them bonuses to their research stat or max labs.
Scientists can gain bonuses to their max labs even when idle, but their research skill only increases when in a lab I believe.
I used to do this, but especially in the early game when you have few labs it takes valuable space away that you need to blitz out early techs I find. Added to that, usually your early scientists are quite weak aside from one or two, and you'll eventually generate ones with better skills more quickly than you can level up your starting scientists. In any non-critical fields you're usually better off in terms of net RP generated to wait for a good scientist to spawn and use the good ones you've got to jump ahead in a couple of key tech areas.
By "usually" I mean "never" because I always generate three Bio/Gen rock stars at game start and muddle along praying for just one C/P specialist, but your mileage may vary...
-
I usually have at least one main line researcher in each area that I am doing work in, and then have basically a 'trainee' that has 1-3 labs who is trying to catch up before the mainline person dies. Later as I grow wealthier I add more of these people so that I have a steady supply of useful researchers. The number of labs doesn't seem to substantially effect skill gain, so you can potentially relatively cheaply ensure that you have good researchers for the future, which is absolutely worth it for me even early game.
-
I have role-play rules in place that forces all factions to use allot more scientist. First of all each lab is only usable in ONE research category so no way to switch a lab from being used from Construction to Groung-combat for example... If there is need I would have to convert 2 labs to 1 to switch field so it would be costly.
In addition to that no specific project type can just switch labs willy-nilly either so I need to use multiple scientist in each field to work on different projects. A scientist can only reassign one lab for every 10 administration skill they have per year, minimum one lab. These project are so large and impactful to society that it is really difficult to shift research around without becoming very inefficient.
So when I want to start work on a new component I usually can only reassign one or two labs per year to work on it. Since I also usually play on 10-15% research you may imagine what effect this have on priorities and type of components that get used. It also highly influence ship design as well. Scientists usually can retain their labs if they continue working on component types of similar types.
If a large project ends and it has a huge amount of labs it usually have to be divided among all the other projects or several new projects started... though I do allow some type of techs to be interchangeable such as passive EM, Thermal and Active strength for example... I can the have one running project for those same technologies.
This give me allot of use for allot more scientists over time.
-
Again, I can't seem to leave a comment without it devolving into a math nerd fight I can't even follow.
Anyways, on the topic of more roles for leaders I fully support it but I don't think it will come with this update. What I do hope will come, and what I assume would just require a minor tweak to a variable or two, is making Ground Officers spawn much more rapidly. I personally think they should be more plentiful than Naval officers since I'd bet recruiting standards would be low (no offense to anyone in the Army but an Naval officer is probably a literal rocket scientist at least). However, I'd settle for them spawning at the same rate as Naval officers for now.
What would be even better is a way to tweak leader spawn rates from the game options menu, just like you can with survey speeds and such.
Also, making Scientists lead survey ground units instead of ground leaders would be really cool.
-
Anyways, on the topic of more roles for leaders I fully support it but I don't think it will come with this update. What I do hope will come, and what I assume would just require a minor tweak to a variable or two, is making Ground Officers spawn much more rapidly. I personally think they should be more plentiful than Naval officers since I'd bet recruiting standards would be low (no offense to anyone in the Army but an Naval officer is probably a literal rocket scientist at least). However, I'd settle for them spawning at the same rate as Naval officers for now.
This would need to be coupled with a general buff to officer spawn rates (say from 5/yr to 6/yr per academy) so that adding ground officers isn't taking away naval officers and scientists. The latter two are arguably more vital which I think is why ground force officers currently are underrepresented, so ideally we can bump up the spawn rate overall so that all officers are well-represented. I would prefer if quality of officers were a limit on military expansion rather than quantity as it is now.
What would be even better is a way to tweak leader spawn rates from the game options menu, just like you can with survey speeds and such.
Would support this especially coupled with the ability to set rank ratios - bring back 4:1 ground forces!
-
Anyways, on the topic of more roles for leaders I fully support it but I don't think it will come with this update. What I do hope will come, and what I assume would just require a minor tweak to a variable or two, is making Ground Officers spawn much more rapidly. I personally think they should be more plentiful than Naval officers since I'd bet recruiting standards would be low (no offense to anyone in the Army but an Naval officer is probably a literal rocket scientist at least). However, I'd settle for them spawning at the same rate as Naval officers for now.
This would need to be coupled with a general buff to officer spawn rates (say from 5/yr to 6/yr per academy) so that adding ground officers isn't taking away naval officers and scientists. The latter two are arguably more vital which I think is why ground force officers currently are underrepresented, so ideally we can bump up the spawn rate overall so that all officers are well-represented. I would prefer if quality of officers were a limit on military expansion rather than quantity as it is now.
What would be even better is a way to tweak leader spawn rates from the game options menu, just like you can with survey speeds and such.
Would support this especially coupled with the ability to set rank ratios - bring back 4:1 ground forces!
As well as tweakable rank ratios - I would like the academy structure to get split into Naval, Ground, Science and Management types that each give out their own type of characters only. If you don't want it to be that granular instead make it so that the separation is military academy (naval, ground), civilian academy (admin, scientist) instead. I have made this suggestion on the thread before but the post is pretty deeply buried by now.
-
As well as tweakable rank ratios - I would like the academy structure to get split into Naval, Ground, Science and Management types that each give out their own type of characters only. If you don't want it to be that granular instead make it so that the separation is military academy (naval, ground), civilian academy (admin, scientist) instead. I have made this suggestion on the thread before but the post is pretty deeply buried by now.
I agree that splitting up Academies between Civilian and Military make sense... I also think you can add some more effect to academies aside from just training characters and crew. I also think they both should require population to run as well, they also should have a wealth cost. At least civilian academies should have some other effect outside training administrators and scientists.
-
Anyways, on the topic of more roles for leaders I fully support it but I don't think it will come with this update. What I do hope will come, and what I assume would just require a minor tweak to a variable or two, is making Ground Officers spawn much more rapidly.
If you assign a ground officer as academy commandant, it will generate more ground force officers.
-
Anyways, on the topic of more roles for leaders I fully support it but I don't think it will come with this update. What I do hope will come, and what I assume would just require a minor tweak to a variable or two, is making Ground Officers spawn much more rapidly.
If you assign a ground officer as academy commandant, it will generate more ground force officers.
I am aware of this and do regularly assign ground officers as commandants, but it is still not enough imo.
-
My suggestion above solves this by at least separating out the military and civilian academies and in the extreme creating an academy type for each officer.
IMO if Steve every implements a change like that you could change it so that academy commandants will make an academy give out only their type.
Also, and this is also buried in the suggestions thread, late game when you have 4k+ officers it takes a very long time to open the commanders menu, this is because the officer filtering/sorting on the bottom right of the screen will automatically filter out the massive list of officers from lowest rank to highest rank.
Either add a "filter" button to make the filtering manual or make it so that by default it sorts from highest rank to highest rank - which keeps the list small much later into the game and improves the speed at which the commander screen opens.
-
Also, and this is also buried in the suggestions thread, late game when you have 4k+ officers it takes a very long time to open the commanders menu, this is because the officer filtering/sorting on the bottom right of the screen will automatically filter out the massive list of officers from lowest rank to highest rank.
Either add a "filter" button to make the filtering manual or make it so that by default it sorts from highest rank to highest rank - which keeps the list small much later into the game and improves the speed at which the commander screen opens.
Easy fix is to not auto-populate that list until the player chooses a filter manually (or presses a button if this suggestion is taken up). Never ever in the history of playing Aurora have I interacted with the default unsorted naval officers list, at the very least I'll sort to the rank(s) I actually care about at the moment, so it makes sense to save the processor cycles there as they're wasted anyways.
-
Please put missile series back in. As is, I have to change the loadout of each ship or the class loadout every time I want to top off my magazine with older missiles. So please, please put this back in.