Aurora 4x
VB6 Aurora => VB6 Mechanics => Topic started by: sloanjh on April 21, 2012, 09:37:35 AM
-
This thread is for discussion of Steve's (locked) "Change for v6.00" thread.
-
I have two questions:
1. How are buoys affected?
2. When will you stop taunting us and release it?
Other then that, it looks very good indeed.
-
I have two questions:
1. How are buoys affected?
2. When will you stop taunting us and release it?
Other then that, it looks very good indeed.
certainly #2. I am itching to work with the expanded Sol.
-
I have two questions:
1. How are buoys affected?
2. When will you stop taunting us and release it?
Other then that, it looks very good indeed.
I haven't decided yet on buoys - I may change it to the NA system where the design process allocates reactors automatically for any on-board sensors and the buoys last forever.
It will be a while before I release it. I need to finish the planned changes and test everything in a quick mini-campaign. Also I get the keys to a new house in 2 weeks and I have to move in on the 15th May, so I may not get much free time in the near future.
Steve
-
That is both tragic and good news. Good luck with the new house.
There hasn't been much discussion on your end as to the possibility of changes that would make star bases more feasible. I don't want to start a full discussion of the topic here, just wondering if there were plans to includes changes in that area.
-
That is both tragic and good news. Good luck with the new house.
There hasn't been much discussion on your end as to the possibility of changes that would make star bases more feasible. I don't want to start a full discussion of the topic here, just wondering if there were plans to includes changes in that area.
I haven't commented on it yet as I haven't really had time to look at it. I do think there needs to be some way of having a large base that can maintain itself though.
Steve
-
... I do think there needs to be some way of having a large base that can maintain itself though.
Steve
I am delighted by this thought and the possible conversion of the buoys! The release date, in an ideal world, would be today of course :) but it sounds like you'll be fairly busy. Like xeryon said, good luck with the new house.
-
I like how the new concept for missiles is shaping up.
However, I don't think reducing beam weapon size is not necessarily going to "fix" beam weapons with respect to buffed missile combat.
-
I'd be tempted to consider a more direct anti-missile balance factor, if one seems to be required : allow a new EW component that shuts off missiles (cuts their FC tracking or something) at a little beyond beam range. You can therefore leave beam weapons as is, and extend your effective PD range without upsetting the balance of beam weapons
-
With the new tech line on max engine power variation I'd be interested in the comparative RP to create fighter and FAC equiv engines compared to the current version. Ie are fighters and FACs effectively going to become later game techs as the cumulative RP needed is a lot higher?
-
suggestion: eliminate the size reduction of missile fire controls vs active sensors.
*reduces the current big advantage missiles have in small craft, especially wrt long range missiles and crew reqs;
*slightly improves beam starships vs missile starships;
*makes ignoring ECM through overengineered fire controls less easy-breezy;
-
An EW system, especially simply drones that look like a copy of their mothership but can't take much damage, would go a long way to balancing missiles and beams. Beams would be able to quickly "test" targets until they find the real ships, while missiles would be more difficult and take longer due to flight time.
-
With regards to the Sol system I stumbled across this tid-bit when doing a little light reading into the physics of Lagrangian Points. Turns out there are at least two instances of Moon's have fields strong enough at L4 and L5 to have captured their own trojans. Will those have made it into the new Sol as well?
Excerpt from Wiki
Saturn's moon Tethys has two much smaller satellites at its L4 and L5 points named Telesto and Calypso, respectively.
Saturn's moon Dione has smaller moons Helene and Polydeuces at its L4 and L5 points, respectively.
-
An EW system, especially simply drones that look like a copy of their mothership but can't take much damage, would go a long way to balancing missiles and beams. Beams would be able to quickly "test" targets until they find the real ships, while missiles would be more difficult and take longer due to flight time.
Steve did mention a while back (a year or so) that he wanted to take another look at EW.
-
suggestion: eliminate the size reduction of missile fire controls vs active sensors.
*reduces the current big advantage missiles have in small craft, especially wrt long range missiles and crew reqs;
*slightly improves beam starships vs missile starships;
*makes ignoring ECM through overengineered fire controls less easy-breezy;
I'm not so sure about that. A revised ECM system would take care of the third point, and maybe reducing the multiplier from x3 to x2 would take care of the others. The problem with making them the same size is that they have different jobs, and from a realism standpoint, they won't be the same size.
EW is in need of revision, and I posted my thoughts in the suggestions section.
Missiles are tricky, and I'd probably go for reduced accuracy and reduced range instead of just reduced range.
-
Another potential problem with increasing the size of MFCs is the impact this would have on AMM ships. This is likely to be disproportionate given their need to carry far more MFCs compared to missile ships.
-
With the changes made to fire controls and such, is htere any chance we could get a linked fire control system, say you have a single ship that handles fire control for the entire fleet, where there is a new component, something like a Data Link Module, or Data Link Server/Data Link Client, where ships in the same fleet with one of these can link fire control systems, or ships within a certain distance of each other, in the case of the Client/Server thing, it would be that ships with the server have linkable fire controls, while ships with the client can link into those fire controls. Would make for some interesting designs, and I can see it being especially useful for carriers with bombers, where the bombers would no longer need to have their own fire control
-
Seems like Giant Railguns is practically the only thing in the NA rules that isn't be adapted for regular Aurora. Pity, that's the one I really wanted. :( Not that I'm surprised, it's pretty easy to imagine why a projectile weapon is something that wouldn't translate perfectly from NA to RA and back.
Anyway, can't wait for the release!
-
"I may add some form of failure during very long term deployment - a failing IFF system on a mine could be entertaining - but I haven't decided yet."
A bit devious are we? Surprises are always welcome :)
-
Another potential problem with increasing the size of MFCs is the impact this would have on AMM ships. This is likely to be disproportionate given their need to carry far more MFCs compared to missile ships.
I actually believe most players are drastically overengineering their AMM ships anyway. A salvo of 5-6 missiles needs 15 AMMs shot at it which means you only need 1 MFC per 15 tubes if that is your doctrine. In any case, reducing the effectiveness of AMM defense would, in my view, actually be a plus.
Accuracy is an interesting point. With the changes in engine technology, its probably possible to make much faster / more accurate short range AMMs; which makes maybe makes it possible to decrease missile accuracy across the board and still have viable missile defense.
-
I'm not sure how you would balance Beam wepaons short of maybe giving them more range, kinda like PT's...but then how would you show that on screen between 5sec intervals...light coming at you??lol
Five
-
I'm not sure how you would balance Beam wepaons short of maybe giving them more range, kinda like PT's...but then how would you show that on screen between 5sec intervals...light coming at you??lol
Five
You wouldn't. You can't see light coming at you, as it's traveling at the speed of light.
-
Wow, I'm extremely excited about the missile changes! I don't use ECM, can't comment there... but the missile changes I am drooling over!
-
I'm excited. Massive range missiles make me happy. I'll end up putting ships out beyond the solar system to do wide volleys of enemy targets. Indirect fire FTW!
-
I'm excited. Massive range missiles make me happy. I'll end up putting ships out beyond the solar system to do wide volleys of enemy targets. Indirect fire FTW!
I can't wait to see what kind of designs we come up with. The long range potential is incredible.
-
I'm excited. Massive range missiles make me happy. I'll end up putting ships out beyond the solar system to do wide volleys of enemy targets. Indirect fire FTW!
The problem there is targeting. You either need the mother of all fire controls, and constant contact with the target, or really good sensors on the missiles and the ability to predict where the target will be. Either one is a tall order. Depending on the tech level, flight time might be long enough that even planetary targets move, and those are the tech levels where the sensors are weakest as well.
This brings another thought to mind. For terminal sensors on missiles with warheads, would it be possible to reduce sensor costs and reactor size. I generally build some thermal sensors into my missiles in case of overkill or the firing ship getting killed, and it would be nice to not have to build them to the same grade as bouys. Just removing the reactor should do the trick, as I'd imagine the engine would provide sufficient power.
-
My own missiles will almost certainly simply become multistaged, with a size-2 or so carrier stage with a very efficient yet slow engine, then a size-4 missile on top with a max-power engine. (Although at higher techs I might end up making it two size-2 missiles instead.) My only concern with this is enemy AM coverage.
-
The problem there is targeting. You either need the mother of all fire controls, and constant contact with the target, or really good sensors on the missiles and the ability to predict where the target will be. Either one is a tall order. Depending on the tech level, flight time might be long enough that even planetary targets move, and those are the tech levels where the sensors are weakest as well.
Sensor contact will be a bit easier with long-term reactor powered sensor buoys. I already have a technique of firing off long-range drones with sensor buoys at suspect planets to see what's there before approach. Maybe enormous sensor arrays on dedicated ships, networks of buoys, and long range sensor drones/buoys. Deploy more DSTS around important systems?
Planetary targets moving poses an interesting problem - I think the biggest danger would be the missiles running out of fuel as the planet shifts unexpectedly.
Havear's plan of a simple multistage missile is an intriguingly simple adaptation to the new rules. Seems like it'd boost to-hit rates significantly over our current designs.
-
Sensor contact will be a bit easier with long-term reactor powered sensor buoys. I already have a technique of firing off long-range drones with sensor buoys at suspect planets to see what's there before approach. Maybe enormous sensor arrays on dedicated ships, networks of buoys, and long range sensor drones/buoys. Deploy more DSTS around important systems?
Planetary targets moving poses an interesting problem - I think the biggest danger would be the missiles running out of fuel as the planet shifts unexpectedly.
Havear's plan of a simple multistage missile is an intriguingly simple adaptation to the new rules. Seems like it'd boost to-hit rates significantly over our current designs.
The problem with long-range targeting is that you need active sensor contact, and the aforementioned very long range fire control. Unless you shoot at the planet itself, in which case you only need the fire control.
The issue with relying on internal sensors is that they generally have fairly short ranges. If you guess wrong, it just sits there until it runs out of fuel.
I've actually been thinking along similar lines to Havear. It would be quite possible to design a missile system such that the interceptor is the same on all units, and the first stage has the same engine, and a different amount of fuel.
-
I usually specialize my fleets for stealth and range. Done right, I can get ships firing across millions of km and landing perfect strikes. It all depends on spotters and lobbers. Spotters flitter about as tiny ships with powerful stealth and thermal reduction engines, sporting small active sensors or very large ones, designed to either fly in close and spot or to sit at far range and hope the enemy can't properly see the active sensor. Although usually it's a massive thermal sensor that keeps a vague awareness of a fleet, and the lobbers are firing missiles with sensors of their own. Most times I have to account for planetary motion, but if I'm doing good then I can fire the missiles straight and let them track the targets the whole way.
Although with these changes, I see short-term minefields being a prime weapon of mine. Fire it ahead of the enemy, either in the planet's orbital path or between my ship and theirs, and let the missiles' own sensors do the painting.
-
I'm not sure how you would balance Beam wepaons short of maybe giving them more range, kinda like PT's...but then how would you show that on screen between 5sec intervals...light coming at you??lol
This is a major reason why beams have the max range they do - Steve didn't want to have to deal with delayed impact beam shots, i.e. fire one pulse and hit on the next pulse 5s later.
John
-
This is a major reason why beams have the max range they do - Steve didn't want to have to deal with delayed impact beam shots, i.e. fire one pulse and hit on the next pulse 5s later.
John
Handwavium: TNE-based beam weapons are not restricted to light speed. :P
-
I think to the extent beam range is a problem, its mostly on the low end/ on the curve / has to do with fire controls as much as beam weapons. /shrug/.
-
I'm leaning toward upping the beam fire control speed techs a little. That would be the simplest way to improve beam weapons in response to improved missiles and wouldn't require any coding changes.
Steve
-
Although with these changes, I see short-term minefields being a prime weapon of mine. Fire it ahead of the enemy, either in the planet's orbital path or between my ship and theirs, and let the missiles' own sensors do the painting.
I was thinking of something like that, although it'd be hard to calculate intercept points without a ruler.
When you say 'short-term', what kind of design do you have in mind? One limited by fuel, with slow engines?
-
"Short-term minefield" would be measured in hours, and wouldn't be a buoy type but instead a cluster of missiles that sit in front of the enemy with some active sensors. Or in assaulting planets, it may be days and use a buoy type "infinite lifespan mine" style.
-
Just a quick note to say that development of v5.70 is progressing. I'm spending a lot of time at the moment on adjusting the automated NPR ship design to take account of the rule changes. Even though NPRs don't use fuel (for the moment, anyway), their designs will allocate a suitable amount of space for fuel and crew quarters. I've spent most of the weekend looking at the design of NPR missiles. The changes to missile design mean more flexibility for players but a lot more factors to consider during automated missile design.
Steve
-
By all means the AI is one of the most important factors. It's entertaining watching your ships flitter about, but the NPR are your opponent and if they're lame, then there's no way to show off your game mechanics because there's no suitable enemy to use those fancy new missiles against!
-
*cough cough* Something seems to be missing...specialized companies...because I'm rather sure that no matter what year or where, the financial and legal reasons for having baby corps under a big one will never change. But I can forgive you for this since you are working on the NPR ship design thinkums...Which would be nice for a somewhat realistic (as in following the rules realistic...) NPR design would be nice so they would be more...er..'borrowable'. Borrowing designs that *work* is good...borrowing with having to follow around with a tanker so you can get it home to gut it 100% so it operates under the same rules you do is not good...
-
Cheers Steve... hopefully the code for NPRs designing missile engines and engines is reusable... I guess first you have to figure out what makes an effective AMM engine etc., heh.
-
Buy blue emu a beer and get him to do it. I was amazed at his sheer brain sexyness on the paradox forums...and he keeps it up here. I learned long ago just to pretend what he writes after reading PAGES of it, I find it makes my brain want to cry less.....and I can't believe I forgot bay12...Capital idea, get blue emu to do it. Apparently too much time on his hands. Help him to help you.
-
There would be plenty of people willing to delegate the AI routine coding if you opened up that to modders.
-
Several other open-source project games I like to play have AI personalities set up as a separate module that players can make themselves and distribute and then mix and match their play experience to suit their style.
So you want a challenge? Put three instances of the invader personality into your game. Like things a little slower? put in a couple corporation themed empires. The possibilities are endless. Someday this might be a nice addition to Aurora.
-
Teehee. Playing against an AI that uses Steve's NATO or Russian designs (or a selection of designs of my own development) is one of my pet hopes.
-
Why was the size for Jump Engines changed again?
I always liked having to think about how to get ships through jumppoints.
Aside from the part where a fleet consisting of 50% jumpships that can take 2 each with them can't traverse a point until I split them into subgroups.
The Missile Design is obviously lovely, great changes there; But I have to agree with byrons sentiment.
There should be a switch "buoy/missile" that, if set to missile, further halves generator size, but limits maximum time of the missile to a certain number, say, (flight time at full power)*2.
Because otherwise I see missiles being fired at certain places, opponent dies, and they just stay there forever just in case something comes around.
That'd be too easy, and a serious drag on performance.
-
The Missile Design is obviously lovely, great changes there; But I have to agree with byrons sentiment.
There should be a switch "buoy/missile" that, if set to missile, further halves generator size, but limits maximum time of the missile to a certain number, say, (flight time at full power)*2.
Because otherwise I see missiles being fired at certain places, opponent dies, and they just stay there forever just in case something comes around.
That'd be too easy, and a serious drag on performance.
I'm not sure that is needed as anything with a warhead is going to self-destruct when it has no target (one of the two exceptions that Steve has added in). To achieve the above I think you would need to launch a missile with no warhead but with sub-munitions which is back to it acting as a bouy as intended.
On the jump ships I like the fact that it will be easier to build bigger jump ships. It would be great if this was matched by an increase in the cost and effort of gate building to make this more of a strategic decision rather than an option on how to explore the galaxy - perhaps an annual cost for gate maintenance?
-
There should be a switch "buoy/missile" that, if set to missile, further halves generator size, but limits maximum time of the missile to a certain number, say, (flight time at full power)*2.
Because otherwise I see missiles being fired at certain places, opponent dies, and they just stay there forever just in case something comes around.
That'd be too easy, and a serious drag on performance.
He did mention that missiles with warheads go away when the fuel runs out. My proposal is to get rid of reactors entirely for those.
-
Reactors are only needed for sensors, right? No sensors, no reactor, but you need live firecon.
-
Are you going to look into laser heads again this update? I can see how they'd fit really well with the new missile rules.
-
Will we be able to use orbital habitational modules like mobile brothels on a big civilian ship behind our main fleet, to park it at some random planet and orbit the fleet around for the morale boost? Or only grounded populations work?
-
Ha! Orbital brothels.
Come on down to rootin' tootin' al's orbital boîte à bonbons!
-
Forward supply bases should become much more interesting now!
-
Will we be able to use orbital habitational modules like mobile brothels on a big civilian ship behind our main fleet, to park it at some random planet and orbit the fleet around for the morale boost? Or only grounded populations work?
You will be able to use orbital habitats for the population requirement. I'm sure players will find inventive names for such ships.
Steve
-
All sensors and fire controls now require 100% Uridium, instead of 75% Uridium and 25% Duranium
Engines require 100% Gallicite instead of 75% Gallicite and 25% Duranium
Reactors require 100% Boronide instead of 75% Boronide and 25% Duranium
What precipitated this change? increasing demand for these 3 minerals at the expense of Duranium(which is highly prized as is)? I've only rarely run into a Gallicite crunch but was it ever painful.
-
You will be able to use orbital habitats for the population requirement. I'm sure players will find inventive names for such ships.
Steve
Persian Princess!!! Come to the Persian Princess for the best Drinks and Women money can buy in the Empire!!!
-
Now there's a good use for conquered populations. Stick them all in big "entertainment" ships. Keep the troops happy.
-
What precipitated this change? increasing demand for these 3 minerals at the expense of Duranium(which is highly prized as is)? I've only rarely run into a Gallicite crunch but was it ever painful.
I was updating the missile design code, which uses all of the above elements, and decided it was time to start changing the current situation, where almost everything requires Duranium. I may extend this in other areas at some point.
Steve
-
Well, I think it's fine to have a base material, unless you want to introduce basic metal to be found and needed everywhere.
Though it obviously simplies a lot if those specific components don't. Maybe you could even abstract away a material if you streamline everything for the sake of gameplay.
-
Now there's a good use for conquered populations. Stick them all in big "entertainment" ships. Keep the troops happy.
Some slightly disturbing historical parallels :) but as the rules stand that would work. I wonder if I should make it imperial populations only, or leave it to players to RP it.
Steve
-
Some slightly disturbing historical parallels :) but as the rules stand that would work. I wonder if I should make it imperial populations only, or leave it to players to RP it.
Steve
My preference would be to leave it to RPing.
-
My preference would be to leave it to RPing.
That or just apply the manufacturing percentage penalty for non imperial populations to the shore leave recovery rate to reflect crews not being quite so relaxed in a slightly hostile environment.
-
That or just apply the manufacturing percentage penalty for non imperial populations to the shore leave recovery rate to reflect crews not being quite so relaxed in a slightly hostile environment.
+1
Sounds nice.
-
You will be able to use orbital habitats for the population requirement. I'm sure players will find inventive names for such ships.
Steve
I just had a flashback to From Dusk to Dawn...
-
I just had a flashback to From Dusk to Dawn...
;D
-
By the way Steve, are we near a release of 5.70 or can I start Carolus Rise, the return of humans to Sol system and retake Earth??
-
By the way Steve, are we near a release of 5.70 or can I start Carolus Rise, the return of humans to Sol system and retake Earth??
It's not imminent. We got the keys to a new house on Saturday and have been moving boxes all weekend. The furniture is being moved a week tomorrow, although we also have to fit in a 4-day trip to the UK before then :). And then there is work as well, so not much time for programming at the moment.
Steve
-
It's not imminent. We got the keys to a new house on Saturday and have been moving boxes all weekend. The furniture is being moved a week tomorrow, although we also have to fit in a 4-day trip to the UK before then :). And then there is work as well, so not much time for programming at the moment.
Steve
But without 5.70 I might be in danger of getting a life! Or a girlfriend!
Oh wait, who am I kidding :)
-
Depending on the civilization, I could imagine soldiers enjoying a shore leave composed of captured women chained to the wall. Just sayin', shore leave only needs to be enjoyable for one side to be effective.
-
well whichever way you want shore leave to be ;p
-
So it's another month, minimum?
Well, I can wait that long.
Regarding all the discussions about sexual assaults on captured populations, there's probably a lot more to shore leave than that, not to speak of other conditions.
The Atmosphere might be toxic and the captured populaceconsist of spikey balls oozing venomous acid;
Maybe aside the productivity modifier, it should also be affected by the colony habitability, maybe reducing efficiency by 10% relative for every multiplier higher than 1?
-
Were/are there any plans to move the NA planet movement into RA (ie planets don't only move every 5 days)? Or did that already happen and I just hadn't noticed?
-
Were/are there any plans to move the NA planet movement into RA (ie planets don't only move every 5 days)? Or did that already happen and I just hadn't noticed?
Not at the moment. NA planets have to move regularly because of the movement system. It's more of a 'nice to have' feature in Aurora. It would improve Aurora though so I'll add it to the list.
Steve
-
You need to stop reading this thread or we will never see 5.7. Seems more likely at this point that it will end up being 6.0.
-
You need to stop reading this thread or we will never see 5.7. Seems more likely at this point that it will end up being 6.0.
Given the number of changes, I think you are probably right :)
Steve
-
Well, then give it another month, guess a release date in late autumn, and call it officially 6.0.^^ Add a "beta" so you can still refine it for the next year X-D.
If the moving system is too taxing, adding an option to move planets every 1 days if there are ships in the system would do?
-
I just remember a game where one of my satellites (without engines) tried to shift orbit, happened to get caught during the once-every-five-days tick, and ended up too far away from the planet to get back... >.<
-
Um, could I request that new civilian administrator and new scientist become interrupts again?
While new naval and ground not interrupting is nice, I actually want to do things with the other two.
-
Um, could I request that new civilian administrator and new scientist become interrupts again?
While new naval and ground not interrupting is nice, I actually want to do things with the other two.
Or at least make it configurable. Make a check list of what things are interrupts and what are not.
PS. I'd like scientists and civ admins to interrupt also ;)
-
Um, could I request that new civilian administrator and new scientist become interrupts again?
While new naval and ground not interrupting is nice, I actually want to do things with the other two.
OK, I've changed it so that civs and scientists have different events and they do interrupt.
Steve
-
Daw, you were supposed to say, "and it's configurable."
-
Lol.
Would it be possible to set the population growth in the game somewhere?
Also possible just for the race.
I'm about to do a small RP campaign and it's gnawing at my suspension of disbelief that they apparently all breed like rabbits.
-
While we are on the subject of non-interrupting events, can we make new/lost friendly/allied sensor/transponder contact not interrupt?
-
Instead of singling out interrupts, just leave it the way it is by default and make it so all of the log file entries have two switches: one to disable the log entry and one to disable the interrupt.
-
population growth limits under youre normal growth rate could be useful
-
Any action that uses crew grade as a modifier will also be affected by low morale. This includes weapon accuracy, maintenance failures and transit delays.
Just my two cents here, but I think that the morale "penalty" might need to be adjusted for combat situations. If you are saying morale is based on fatigue from being "away" for so long plus general grumpiness from lack of downtime, I would argue that combat would eliminate the grumpy aspect of morale.
I understand that in high stress situations, fatigue is what it is, but if I am getting shot at and afraid for my life, my pissed off attitude at my superiors would probably dissipate and that aspect of my morale would not play a factor. Maybe cut the morale penalty in half for combat situations and leave as is for typical daily grind things.
-
well combat is supposed to be the main penalty for morale. In the interest of KISS its better to have a unified mechanic, i.e. just one morale penalty. So if the combat morale penalty is too high you might as well adjust all of it.
-
More importantly, if morale doesn't affect combat as much then it's no big penalty. To encourage players to keep their fleets AND their crews maintained, it must have a direct and important impact.
-
It does make sense though, you're unlikely to piss about in combat because you're unhappy. To me, low morale would result in things like the maintenance clock increasing faster due to poor job performance alogn with the increased failure rates. Maybe instead of a penalty to the crew grate, it results in slower increases to crew grade and possibly even a decrease if it gets low enough.
You'll give it your best in combat, you just won't know what you're doing. A few weeks in a brothel isn't going to teach you all the things you should have been learning regarding how to do your job during those boring drills.
-
I tend to view the combat penalty due to morale (as with crew grade) to be related to how well the systems are maintained and how often the crew carries out drills. When a warship fires a beam weapon (for example) the grade/morale bonus/penalty is not really based on the crew manually aiming the weapon but on how well the weapon and the fire control function, which is in turn based on how well they have been checked and maintained in the months leading up to the battle. High crew grade means a crew that constantly drills and improves their systems over time to get the absolute best out of them, correcting things that another crew would accept as being within normal parameters. A low crew grade will usually indicate a lack of experience in how to get the most of their systems. A low morale indicates a lack of willingness to do so. In the case of a sudden battle it is unlikely a crew would be able to overcome months of letting things slide in terms of drills and maintenance.
Steve
-
A low morale indicates a lack of willingness to do so. In the case of a sudden battle it is unlikely a crew would be able to overcome months of letting things slide in terms of drills and maintenance.
Steve
Good point. I defer to your logic.
-
I was eyeing the new missile design screen. There's even more things to fidget with than before. It would be kinda nice if you could just set the size of the missile, and the game automatically fills unused space with fuel. It would make it a lot easier to play around with engine sizes etc. and get immediate feedback in terms of to-hits and range.
-
oh crap--- shipping change!
What determines the size of the freighters? I usually locked designs at 350,000 to 700,000 tons to reduce freighter spam
-
What about old ships? Will you refit, scrap or leave them as is?
-
oh crap--- shipping change!
What determines the size of the freighters? I usually locked designs at 350,000 to 700,000 tons to reduce freighter spam
The freighter sizes will be based on the NPR design code. I am also implementing a way for the Shipping Lines to retire their old freighters. What I am leaning toward at the moment is that every time a shipping line builds a new ship, it will retire an equivalent ship with engines that are two generations out of date - if one exists.
EDIT - or maybe simpler that the shipping line will retire the oldest ship of the same general type, with a minimum of 10 years older. In that way, a shipping line is generally going to have a relatively modern fleet and is unlikely to have more ships that it can build in 10 years.
Steve
-
Are the Shipping Companies going to have a limit to the amount of ships they can produce and have operational ?
-
I like the age-based obsolescence option. It has the nice touch that if a shipping line isn't earning much money (and thus buying new ships) its ships will tend to be older. Regardless of engine techs.
And if there's ever wealth-based maintenance for commercial ships it would fit in very well.
I'm a little worried though, since the NPR freighters are often slow cheap affairs. Slow has its own concerns, but cheap might result in larger fleets than currently - at least until ships start getting retired.
Also - I dunno, I've always been unhappy with the way trading works in general... Like the best way to earn wealth is to colonize mars regardless of military or industrial value. And not build your own infrastructure. And the first load of cargo is the same value as the thousandth, so rarity never enters into it. //shrug. Going to think about it.
P.S. - Random idea. "Freight Rating" for freighters, calculated by the game. Simple multiplication of speed and cargo/cryo/troop capacity. It would make it easy to compare designs.
P.P.S. - Does anyone ever ever ever use cargo holds in anything other than multiples of 5? Might they just as well be implemented that way?
-
P.P.S. - Does anyone ever ever ever use cargo holds in anything other than multiples of 5? Might they just as well be implemented that way?
I've already changed it :)
v5.70 has the current cargo hold as Cargo Hold - Small. There is a new Cargo Hold - Standard which is 5x larger.
Steve
-
I'm a little worried though, since the NPR freighters are often slow cheap affairs. Slow has its own concerns, but cheap might result in larger fleets than currently - at least until ships start getting retired.
Also - I dunno, I've always been unhappy with the way trading works in general. . . Like the best way to earn wealth is to colonize mars regardless of military or industrial value. And not build your own infrastructure. And the first load of cargo is the same value as the thousandth, so rarity never enters into it. //shrug. Going to think about it.
I was thinking of multiplying wealth cost of ships so a ship will create 2-5 its cost for its lifespan.
-
I've updated the shipping lines post with the following:
"When a new ship is built, the shipping line will retire the oldest ship of the same general type (with a minimum of 10 years older) that is not currently carrying cargo. So its possible a civilian ship will last longer than 10 years, due to always being active when the shipping line is looking for a ship to scrap. As a ship will not have cargo more than 50% of the time, its luck will probably run out at some point.
All civilian ships will be scrapped when they reach 15 years old, regardless of whether a new ship has been built.
With these changes, a shipping line is generally going to have a relatively modern fleet, with the oldest ships ranging from 10-15 years."
Steve
-
do Civilian designs and even military designs get updated as u get new tech ( for military) if u have the AI designs ship design on game startup clicked.
-
do Civilian designs and even military designs get updated as u get new tech ( for military) if u have the AI designs ship design on game startup clicked.
The only designs that get automatically updated should be the AI ships. Not any pregenerated designs of the player.
-
Instead of scrapping older ships, maybe have old designs get sold to new startups or something. Though probably not indefinitely.
-
Or the option to let the player buy them, saves us the minerals of building them.
-
Or the option to let the player buy them, saves us the minerals of building them.
They was built with cash instead of minerals. . . second rate materials, cheap workers and lack of maintenance = short lifespan of ships
-
how well defenced will these ships be? CWIS / sensors?
-
They was built with cash instead of minerals. . . second rate materials, cheap workers and lack of maintenance = short lifespan of ships
Well not really...
...anyways it would be good to have something to spend the cash I'm (and i assume most of us) are ussually sitting on.
-
how well defenced will these ships be? CWIS / sensors?
At the moment, civilian shipping lines only build colony ships, freighters and passenger liners, none of which have CIWS. They will probably also have fuel harvesters by the time v5.70 comes out but for simplicity I won't be adding CIWS to them, although NPR-designed fuel harvesters could have CIWS.
Steve
-
Is there any advantage to keeping prisoners as POWs on planets, or is it all for RP purposes? I don't think I'd mind negative diplomatic points for a race when I eject their people.
-
Will you be able to return POWs to their Empire if diplomatic relationships with said empire improve?
Also while shipping lines are being updated could the construction of civilian mining complexes be assigned to individual shipping lines so shipping diversify between ships and mining complex and rake in profits from both? Also this would allow shipping lines a valid reason to construct Geological survey ships which would be awesome. This would also be more realistic as most of the the surveys for minerals in the real world are done by enterprises as apposed to governments. And finally will we be able to rename shipping lines?
-
Regarding POWs: What happens if i keep those aliens on a planet unsuitable for them? More so do i have to have a special prison-colony with infrastructure etc. if i want to keep them save and do they reproduce while in prison?
-
Surely there can be mechanical diplomatic uses for POWs?
-
Horror as the bodies bounce off their screens.
-
One of my most recently played games using 5.60 really started slowing down the incremental turns. I was about 50 years in and things slowed down a lot. A few things people said would slow it down are lots of mineral packets in route and all the different fleets doing sensor checks.
I reworked my mining philosophy and eliminated mass drivers and then went about minimizing my fleets so that the sensor checks would be reduced. I also tried to minimize the numbers of civilian transports to reduce additional checks.
Automated design of civilian ships, will that not exacerbate the grind issue later in the game?
-
Given that civilian lines now scrap ships older than 10 years when they create new ones, you'll probably have a lot less civilians to worry about.
-
I think what really kills things is increasing size of the universe. Unfortunately you have limited control over this, since not only will NPRs explore but they'll trigger additional NPRs. Invaders also cause a lot of exploration.
-
Yeh, the limit sadly isn't.^^
-
I think what really kills things is increasing size of the universe. Unfortunately you have limited control over this, since not only will NPRs explore but they'll trigger additional NPRs. Invaders also cause a lot of exploration.
apart from invading all of the NPRs and removing a few via invasions
-
I think what really kills things is increasing size of the universe. Unfortunately you have limited control over this, since not only will NPRs explore but they'll trigger additional NPRs. Invaders also cause a lot of exploration.
Would changing the max number of systems to 0 mid-game fix this? I'll take a small universe over a slow game anytime.
-
well theres a lot of optimsations that can be done with the existing engines, the notification removals that have been implemented for 5.7 is a start point
Reducing the number of systems to 0 means that there are already those spawned systems. More processor, upgrading to VB and a host of other things can be done in the end though there will be a limit to how many systems is sensible versus what is possible
-
If the system was built from the group up, even in the old engine (new is obviously better) it could also include instanced systems; like the time bubble we have for larger fights now (at the discretion of the SM), those could be used to handle systems separate from each other if no jumps are present, and completely ignore them if no one is in them.
Right now, that is unfeasible. What I'd like, though, it a race limit that prevents NPRs from generating further NPRs after a certain margin.
In addition to that, a system limit switch might also be a nice bonus.
-
One question about POW.
What happens if I pick up survivors from a friendly or allied race?
Lets say my scout happens to come across some ships of my long term allies that are fighting a losing battle against another unknown race. Now I decide to do something nice and rescue their pods. What happens?
-
well steve has so far posted we can pick them up and they will be retained seperate in crew quarters and then on youre planets when u drop them off. The big question remains is what is he doing next for 5.7 or after to tie it in with diplomacy or even putting them on empty colonies if u have enough of them and they have tolerances for that enviornment
I think theres more updates from steve to come as he tidies things up i dont think the 5.7 log is done by any stretch yet wach this space
-
A straightforward suggestion on the missile engines:
Steve, could you please make the fuel-efficiency of missile engines heavily dependent on their size?
This would go a long way of solving the issue that size-1 ASMs are very effective and render AMM efforts essentially worthless. Essentially to overcome this issue, a size-1 ASM should have seriously reduced combat characteristics.
I would suggest heavily increasing the fuel-requirement of the smaller engines, so that smaller missiles would be much more limited in the attainable range. This would provide a good incentive to use larger missiles, against which AMMs are viable.
In your current example of an AMM, posted in the other thread, only 2% (0.02MSP) of the missile size is fuel. A player could increase this to 0.2 MSP easily at the cost of say agility and get a good size-1 ASM design of 60mkm against which AMM would be entirely futile. If you made changes such that your design would require about 0.3 MSP of fuel to go to its current range, then the size-1 ASM "exploit" would not be viable anymore.
-
A straightforward suggestion on the missile engines:
Steve, could you please make the fuel-efficiency of missile engines heavily dependent on their size?
This would go a long way of solving the issue that size-1 ASMs are very effective and render AMM efforts essentially worthless. Essentially to overcome this issue, a size-1 ASM should have seriously reduced combat characteristics.
I would suggest heavily increasing the fuel-requirement of the smaller engines, so that smaller missiles would be much more limited in the attainable range. This would provide a good incentive to use larger missiles, against which AMMs are viable.
In your current example of an AMM, posted in the other thread, only 2% (0.02MSP) of the missile size is fuel. A player could increase this to 0.2 MSP easily at the cost of say agility and get a good size-1 ASM design of 60mkm against which AMM would be entirely futile. If you made changes such that your design would require about 0.3 MSP of fuel to go to its current range, then the size-1 ASM "exploit" would not be viable anymore.
I agree size affecting engine size as an output to fuel consumption
-
Some other options for helping larger missiles be more viable are:
Increased damage efficiency as your warhead gets larger. After all, you just need one fuze regardless of warhead size. Thus if a 2.0 MSP warhead was more than twice as strong than a 1.0 MSP warhead, you'd be making an actual trade off of Damage vs Chance of a Hit.
Either a new armor tech could be added, properties could be added to existing armor or a new module could be added that grants minor damage resistance. This kind of already exists with shields, if you can't do damage faster than it recharges, you're in trouble. Something similar to Sword of the Stars 2's damage resistance could be added to armor that would negate some of the damage pattern of weapons. For example, if a missile did damage in a 5-3-1 pattern (top to bottom), one level of resistance would negate the highest row leaving 3-1. Or maybe just the lowest level leaving 5-3. Either way, unless a size 1 missile happened to hit a section of armor that had been completely destroyed, it would be ineffective. Like throwing a grenade against a tank vs throwing the same grenade inside an open hatch. Ideally this would greatly increase the mass of armor, so that smaller frigates and destroyers might shrug off AMMs, but only much larger heavily armored warships could afford to protect against larger missiles.
Having distance based accuracy penalties that can be countered by adding small amounts of MSPs in the form of onboard AIs or better communication gear. Since any missile with no onboard sensor is reliant on the firing ship's MFC, this can be explained as the missile relying less on the firing ship to provide instructions that may be experiencing a delay due to the distance from the firing ship. This would limit AMMs to a much shorter range, while larger missiles can devote some space to maintaining their accuracy at a longer ranger. Then again, I can't remember of Aurora is supposed to have FTL communication cananocially or not. If it does, it renders this on pointless.
Finally, building upon the last one, giving missile fire control's a limit to the number of active missiles they can control at a time. If your currently designed MFC can only control six missiles in flight at once, you'll probably want larger missiles that can attack from further out. Otherwise a beam armed ship might be able to realistically close the range without taking critical damage. New tech can influence the number of missiles controllable per launcher. Ideally your fire control links would be pooled together based on range, so if you had two AMM MFCs that can control 6 missiles at 60M KM each, and two ASM MFCs that can control 3 missiles at 300M KM, you attack with six missiles at a time, or the two ASM MFCs could be handed control of six AMMs to increase the density of your defensive fire. (Or likewise increase your offensive fire once you got within 60M KM).
-
Either a new armor tech could be added, properties could be added to existing armor or a new module could be added that grants minor damage resistance. This kind of already exists with shields, if you can't do damage faster than it recharges, you're in trouble
i was thinking about this but the problem is the number of weapons that just deal 1 point of damage like the gauss cannon. and it strains credulity that hundreds of nuclear explosions (AMM spam) would do no damage whatsoever. So I was thinking of a component that had a 50% chance of negative 1 point of damage, 20% chance to negate 2, improvable with technology, or something like that. Maybe even something ala the Cloaking Device/Jump Drive that had to be scaled to a size of warship. Starting at like efficiency 10 to be practical.
-
Finally, building upon the last one, giving missile fire control's a limit to the number of active missiles they can control at a time. If your currently designed MFC can only control six missiles in flight at once, you'll probably want larger missiles that can attack from further out. Otherwise a beam armed ship might be able to realistically close the range without taking critical damage. New tech can influence the number of missiles controllable per launcher. Ideally your fire control links would be pooled together based on range, so if you had two AMM MFCs that can control 6 missiles at 60M KM each, and two ASM MFCs that can control 3 missiles at 300M KM, you attack with six missiles at a time, or the two ASM MFCs could be handed control of six AMMs to increase the density of your defensive fire. (Or likewise increase your offensive fire once you got within 60M KM).
I use something similar in Astra Imperia. Each sensor suite has a number of channels. You can only track a number of targets as you have channels. Ships, fighters, missiles. And as an added bonus, friendly indirect weapons (missiles and other weapons) consume channels also.
-
Increased damage efficiency as your warhead gets larger. After all, you just need one fuze regardless of warhead size. Thus if a 2. 0 MSP warhead was more than twice as strong than a 1. 0 MSP warhead, you'd be making an actual trade off of Damage vs Chance of a Hit.
Although I like this to help split up roles between large and small missiles, it doesn't actually hurt size-1 missiles unless you reduce their power and thus force them to have a larger warhead which hurts their performance. This hurts AMMs, which helps large missiles more than it helps small missiles (assuming they aren't stopping all the large missiles). Independently of rebalancing though, it gives magazine space advantage to large missiles; more boom for your magazine space helps alleviate one of the primary missile disadvantages. Combined with a few other overhead adjustments you could make it impossible to have a long-ranged accurate and fast size-1 missile that still does any damage.
Either a new armor tech could be added, properties could be added to existing armor or a new module could be added that grants minor damage resistance. This kind of already exists with shields, if you can't do damage faster than it recharges, you're in trouble. Something similar to Sword of the Stars 2's damage resistance could be added to armor that would negate some of the damage pattern of weapons. For example, if a missile did damage in a 5-3-1 pattern (top to bottom), one level of resistance would negate the highest row leaving 3-1. Or maybe just the lowest level leaving 5-3. Either way, unless a size 1 missile happened to hit a section of armor that had been completely destroyed, it would be ineffective. Like throwing a grenade against a tank vs throwing the same grenade inside an open hatch. Ideally this would greatly increase the mass of armor, so that smaller frigates and destroyers might shrug off AMMs, but only much larger heavily armored warships could afford to protect against larger missiles.
Instead of a flat nullification of absolute damage, make it reduce small amounts of damage more than large amounts. As an example, if you make it so that every piece of armor has a 10% chance to shrug off a damage point, -5% for every previous damage point that tried to make it through and +2% for every armor point beneath it, you give extra power to penetrating weapons and better armor for taller stacks but don't completely nullify light weapons. Under your method above I could fly within range of an enemy AMM ship and completely laugh off hundreds of damage points which I feel would be unfair and unbelievable when working with the energy scales of Aurora. It could be believable though depending on your ideas for physical properties of trans-newtonian materials, so it's kind of a wash. I do like adding some form of damage reduction though, as it would help differentiate heavily armored ships from lightly armored ones.
Having distance based accuracy penalties that can be countered by adding small amounts of MSPs in the form of onboard AIs or better communication gear. Since any missile with no onboard sensor is reliant on the firing ship's MFC, this can be explained as the missile relying less on the firing ship to provide instructions that may be experiencing a delay due to the distance from the firing ship. This would limit AMMs to a much shorter range, while larger missiles can devote some space to maintaining their accuracy at a longer ranger. Then again, I can't remember of Aurora is supposed to have FTL communication cananocially or not. If it does, it renders this on pointless.
Looking at a previous thread (can't post a link due to low post counts) it seems that, by canon, the MFC just paints the targets (assuming it hasn't changed somewhere else along the line). I would assume the electronics for beam-riding missiles is a very small percentage of the total mass for a multi-ton missile (even a size-1 missile is 1/20th of 50 tons for 2. 5 tons, versus the AIM-7 Sparrow at less than 1/2 a ton). It also adds extra overhead that isn't needed, since you could put the overhead somewhere else (like the warhead size above) and get roughly the same mechanic without adding another factor. I've also seen it mentioned on the forums and on the wiki that trans-newtonian materials gives FTL communications, but I couldn't find a quote from Steve in particular.
Finally, building upon the last one, giving missile fire control's a limit to the number of active missiles they can control at a time. If your currently designed MFC can only control six missiles in flight at once, you'll probably want larger missiles that can attack from further out. Otherwise a beam armed ship might be able to realistically close the range without taking critical damage. New tech can influence the number of missiles controllable per launcher. Ideally your fire control links would be pooled together based on range, so if you had two AMM MFCs that can control 6 missiles at 60M KM each, and two ASM MFCs that can control 3 missiles at 300M KM, you attack with six missiles at a time, or the two ASM MFCs could be handed control of six AMMs to increase the density of your defensive fire. (Or likewise increase your offensive fire once you got within 60M KM).
This would really hurt reload rate differences for any mid-long range engagement. Since the missile flight time is normally so much longer than the reload rate for any reasonable missile size you might as well drop the reload rate and save yourself the cost. It would also hurt the large-salvo long-reload tactics like the Soviets in Steve's campaign. I do believe that MFCs are too cheap at the moment, but I don't have any decent ideas to change that at the moment.
-
i was thinking about this but the problem is the number of weapons that just deal 1 point of damage like the gauss cannon. and it strains credulity that hundreds of nuclear explosions (AMM spam) would do no damage whatsoever. So I was thinking of a component that had a 50% chance of negative 1 point of damage, 20% chance to negate 2, improvable with technology, or something like that. Maybe even something ala the Cloaking Device/Jump Drive that had to be scaled to a size of warship. Starting at like efficiency 10 to be practical.
Actually, I think the negated damage thing makes a good bit of sense. You can take a 50 cal machine gun and open up on an Iowa class battleship all day long and not do much more than scratch the hull. Even nukes might survivable in space with the right armor. With no atmosphere and thus no shock waves, the primary destructive element of a nuclear weapon (on Earth). Your armor needs to be able to deal with the high levels of x-ray radiation a spaceborne nuclear explosion produces. This radiation can cause both spallation and impulsive shock from vaporizing layers of armor. Granted we don't have anything today that could survive a direct hit from a weapon, but we also don't have duranium.
Maybe instead of armor, a new type of shielding would work. A dampening field of some sort or a structural integrity field. The latter would still let small weapons inflict structural damage if the armor had already been pierced.
-
50 cals are not designed to hurt warships - gauss cannons definitely are! But that aside, the gameplay implications are less than appealing. You basically eliminate an entire branch of beam weaponry as collateral damage. Or if you try to balance them appropriately (RP costs included), Gauss cannons would either be underpowered against wall fields or totally overpowered against ships without them. Or relegated entirely to point defense duties - glorified CIWS. Arguably they are sorta that way already, but oh well. There's also a dramatic range nerf to railguns and lasers while presumably leaving mesons untouched. In short, you'd have to a massive balance pass for existing weapons to address these problems. Now, that shouldn't always be ruled out, but it would be simpler and faster to try to build a mechanic with existing balance in mind.
This would really hurt reload rate differences for any mid-long range engagement. Since the missile flight time is normally so much longer than the reload rate for any reasonable missile size you might as well drop the reload rate and save yourself the cost. It would also hurt the large-salvo long-reload tactics like the Soviets in Steve's campaign. I do believe that MFCs are too cheap at the moment, but I don't have any decent ideas to change that at the moment.
well, right now MFCs run like size 1-2.5 or so in part because they get a 3x increase in capability compared to active sensors. I have long believed they shouldn't get that reduction.
I mean... even if you drastically overengineer a MFC to counter ECM their size is negligible compared to to the huge weight of missiles they can control. Whereas you generally need one BFC per several weapons and they start at size 3-4 for competitive controls (and only get larger).
-
1) Missiles could have a % overhead that decreases with larger missile sizes. A Size 1 MSP is 50% overhead, decreasing linearly until a size 100 MSP is 1% overhead. The idea would be for larger missiles to have overall greater capabilities, rather then being just like many small missiles all stuck together.
2) remove the reload bonus that small launchers get, because it makes it even easier for small missiles to overwhelm PD.
3) make launchers take up more space relative to magazines. So a 'volley fire' setup can deliver much more total firepower per unit of ship size, but a 'one big wave' setup is much better able to penetrate PD.
-
Oh I forgot. One of Steve's comments was that ultra long range missiles will be more viable under the new regime, which entails larger / more expensive MFCs. Point to keep in mind.
-
Some other options for helping larger missiles be more viable are:[...]
Yes, you are correct of course. The reason that I suggested to introduce heavy economies of scale in the engine field in particular is that it is very close to something already announced by Steve: economies of scale in ship-engine design, and a uniform design process for all engines.
So in the spirit of making the smallest possible change solve a situation I think this is an workable, consistent, and most importantly easy solution: It merely requires that large missile engines get enough of a "bonus".
But obviously, other points have a certain appeal to. In particular, there is a gross misrelation between the damage you need to destroy an armour box and a missile. You need one damage point to destroy either, but a missile can be 0.05 hull space, while armour is around 0.20 hull space. Or conversely, 1 HS of missiles can absorb 20 damage, while 1 HS of armour can absorb 5. So missiles are much better at absorbing damage /hullspace than armour, which is kind of awkward since armour is designed for that purposes, while missiles are not particularly sturdy. This could be solved by making armour much more weight-efficient, or by allowing a smaller "0.1 damage" warhead (or whatever size), which would be sufficient to destroy another missile, but would not harm armour at all (like the 0.50 cal against a battleship). Or, alternatively, one could think of adding some mandatory dead-weight module (say the board computer, MFC-link and final approach sensors) that would allow larger missiles to be overall better.
At any rate, I suspect none of these other approaches is as readily available, or straightforward to program, so my request stays to simply make large missile engines much more to fuel efficient than smaller ones, up to the point where smaller missiles can not be made to go to maximal combat ranges.
-
But obviously, other points have a certain appeal to. In particular, there is a gross misrelation between the damage you need to destroy an armour box and a missile. You need one damage point to destroy either, but a missile can be 0.05 hull space, while armour is around 0.20 hull space. Or conversely, 1 HS of missiles can absorb 20 damage, while 1 HS of armour can absorb 5.
I don't think there's inconsistency here. Armor actually harmlessly absorbs/ablates the WHITE HOT FURY OF A HUNDRED SUNS; missiles are simply destroyed by any actual damage. I mean that's why a size1 and size 20 missile are equally easy to kill. It's just a matter of hitting them, not of survivability. Unless the missile itself mounts armor- which just gives it a chance to survive a small explosion. On that note, at 20 MSP we're looking at missiles being waaaaaay worse than armor.
That's without bringing advances in armor tech into it.
I mean...I'm not necessarily against missile or armor changes. For what it's worth, I've been experimenting with 'avionics' designs. The two following Ion Era designs are an AMM and short range anti-ship missile that use the rule of 0.2msp+0.1msp/size in avionics, using armor as a placeholder:
R-27 Riot Missile
Missile Size: 1 MSP (0.05 HS) Warhead: 1 Armour: 0.3 Manoeuvre Rating: 15
Speed: 18000 km/s Endurance: 10 minutes Range: 11.3m km
Cost Per Missile: 0.75
Chance to Hit: 1k km/s 270% 3k km/s 90% 5k km/s 54% 10k km/s 27%T-20 Torpedo
Missile Size: 5 MSP (0.25 HS) Warhead: 9 Armour: 0.7 Manoeuvre Rating: 12
Speed: 20000 km/s Endurance: 8 minutes Range: 9.9m km
Cost Per Missile: 4.145
Chance to Hit: 1k km/s 240% 3k km/s 72% 5k km/s 48% 10k km/s 24%
The AMM is super bad - normal ion AMMs can have twice and more that accuracy. (Tho if I sacrifice some fuel I can get it to 30% at 10km/s). And you can't even make an ASM version, because it's impractical to fit 0.5 of warhead and 0.3 avionics into a size 1 missile. I mean you could but it'd be purely a PDC/orbital assault weapon in terms of accuracy.
The following design is magnetoplasma, with another level of warhead and agility tech:
GARDIAN-1 Countermissile
Missile Size: 1 MSP (0.05 HS) Warhead: 1 Armour: 0.3 Manoeuvre Rating: 21
Speed: 24000 km/s Endurance: 7 minutes Range: 10.5m km
Cost Per Missile: 1
Chance to Hit: 1k km/s 504% 3k km/s 168% 5k km/s 100.8% 10k km/s 50.4%Twice as good, but still half as good as a contemporary no-armor AMM.
-
I don't think there's inconsistency here. Armor actually harmlessly absorbs/ablates the WHITE HOT FURY OF A HUNDRED SUNS; missiles are simply destroyed by any actual damage. I mean that's why a size1 and size 20 missile are equally easy to kill. It's just a matter of hitting them, not of survivability. Unless the missile itself mounts armor- which just gives it a chance to survive a small explosion. On that note, at 20 MSP we're looking at missiles being waaaaaay worse than armor.
Of course it's a bit more than hitting the missile. It's hitting the missile and doing some damage. And currently there is a minimum amount of 1 "point" of damage in the game, corresponding to a nuclear explosion. In other words, currently in order to destroy a single missile of 2.5 tons you need at least the "white hot fury of a hundred suns" - maybe even in all capital letters. Nothing smaller will be able to destroy missiles, because there is nothing smaller.
And that's why I think it would be sensible to introduce the ability to deal some smaller amount of damage that would affect missiles. And, yes the minimum amount of damage that would be sufficient to kill a missile should bear some relation to the effects of damage on other structures. Maybe the closest equivalent in composition to missiles is a fuel tank - 1 damage to destroy 1 HS. It should require less damage to destroy an object 1/20th of that size.
Of course this is just a relict of small integer numbers, which are inherent to the abstraction, and normally it would not really be much of an issue. Yet here it means that to destroy one ton of incoming ordonnance, you need about three tons of ordonnance yourself. If this can be avoided, e.g. by making changes that require incoming missiles to be larger in the first place, then the whole issue becomes mood in normal game situations...
-
White hot fury of a hundred suns referred to, well, a hundred missiles hitting a ship, not whats needed to cause one point of damage. :p
Missiles arn't absorbing damage. Even if you mount armor on a missile, that just gives you a chance of surviving a blast - it doesn't actually sublimate energy harmlessly the way ship armor does. In otherwords a missile is exactly as tough as any ship subsystem - it breaks when you poke it. I like to think of it as any 'hit' being the explosion close enough for a size one explosion to irradiate or otherwise cripple/destroy the missile; armor just means the hit needs to be closer or stronger, thus the % chance. In this scheme, a warhead less than 1 damage-point just isn't practical in terms of the range an AMM needs to detonate at to destroy an incoming missile.
-
In otherwords a missile is exactly as tough as any ship subsystem
Yes: Exactly as tough - at 5% the mass.
I like to think of it as any 'hit' being the explosion close enough for a size one explosion to irradiate or otherwise cripple/destroy the missile;
If a "hit" is based on the maximum distance at which an explosion destroys a 2.5t missile, then the same size explosion at the same maximum distance should not also be able to destroy a 50t ship component. From this angle, one could also argue to change the hit-chance versus missiles on the grounds that a 2.5t missile would be affected by a size-1 explosion at a much larger distance, compared to the larger ship-component.
Anyway, I dont want to derail this thread further, in particular since this is not my main proposal, which stays at: Please make fuel efficiency heavily dependent on missile engine size.
-
Would this encourage the usage of missile busses then? As an example, at tech level 3/4 I can make a size-18 drone that carries 12 size-1 missiles at two damage points each. An equivalent size 18 missile has half the warhead for similar to-hit and cost per warhead but less range at a slightly faster speed. Although the two-stage missiles then have equal reload times and the launchers can't double as AMM launchers, they'll still have much better chances against any anti-missile defenses. This was, by the way, with being locked into a drone chassis. If I could customize my first-stage engine I could improve the bus's efficiency and get the size-1 missiles on target with less waste.
-
One question about POW.
What happens if I pick up survivors from a friendly or allied race?
Lets say my scout happens to come across some ships of my long term allies that are fighting a losing battle against another unknown race. Now I decide to do something nice and rescue their pods. What happens?
I might suggest that if a race is, or becomes, friendly or allied that when dropped off (or if they are already when the race becomes friendly) on a planet they would be returned immediately to the race in question. And that blowing allied crewmen out into space might incur a diplomatic penalty.
-
Been away from the game for around 6 months and come back to find news of a feature filled update to 5. 7 waiting to tease me. After reading several of the 5. 7 related threads, it seems like we are about due for another "release imminent" update.
Steve, I hope your move went well. How is the 5. 7 progress coming? Are we any closer to getting our hands on this latest version? :)
-
Been away from the game for around 6 months and come back to find news of a feature filled update to 5. 7 waiting to tease me. After reading several of the 5. 7 related threads, it seems like we are about due for another "release imminent" update.
Steve, I hope your move went well. How is the 5. 7 progress coming? Are we any closer to getting our hands on this latest version? :)
Welcome back :)
-
And no, it's "coming soon" for a while now, and whenever one would think it to be close, Steve thinks up another devious feature that everyone agrees must be in. :P
-
One question about POW.
What happens if I pick up survivors from a friendly or allied race?
Lets say my scout happens to come across some ships of my long term allies that are fighting a losing battle against another unknown race. Now I decide to do something nice and rescue their pods. What happens?
I'll be adding some way to pick up your own crews from friendly races
Steve
-
A straightforward suggestion on the missile engines:
Steve, could you please make the fuel-efficiency of missile engines heavily dependent on their size?
This would go a long way of solving the issue that size-1 ASMs are very effective and render AMM efforts essentially worthless. Essentially to overcome this issue, a size-1 ASM should have seriously reduced combat characteristics.
I would suggest heavily increasing the fuel-requirement of the smaller engines, so that smaller missiles would be much more limited in the attainable range. This would provide a good incentive to use larger missiles, against which AMMs are viable.
In your current example of an AMM, posted in the other thread, only 2% (0.02MSP) of the missile size is fuel. A player could increase this to 0.2 MSP easily at the cost of say agility and get a good size-1 ASM design of 60mkm against which AMM would be entirely futile. If you made changes such that your design would require about 0.3 MSP of fuel to go to its current range, then the size-1 ASM "exploit" would not be viable anymore.
I don't want to do anything to missile engines that isn't replicated in ship engines. I may look at other options though. For example in Newtonian Aurora missiles require an extra component to communicate with fire controls. The issue is that this would make AMMs less effective. Another possibility is to have missile use proximity detonations and inflict only partial damage. Larger warheads would become more effective because they would have a greater blast radius. The issue with this idea is that missiles become an area effect weapon, which has all sorts of consequences.
Steve
-
Some other options for helping larger missiles be more viable are:
Increased damage efficiency as your warhead gets larger. After all, you just need one fuze regardless of warhead size. Thus if a 2.0 MSP warhead was more than twice as strong than a 1.0 MSP warhead, you'd be making an actual trade off of Damage vs Chance of a Hit.
Either a new armor tech could be added, properties could be added to existing armor or a new module could be added that grants minor damage resistance. This kind of already exists with shields, if you can't do damage faster than it recharges, you're in trouble. Something similar to Sword of the Stars 2's damage resistance could be added to armor that would negate some of the damage pattern of weapons. For example, if a missile did damage in a 5-3-1 pattern (top to bottom), one level of resistance would negate the highest row leaving 3-1. Or maybe just the lowest level leaving 5-3. Either way, unless a size 1 missile happened to hit a section of armor that had been completely destroyed, it would be ineffective. Like throwing a grenade against a tank vs throwing the same grenade inside an open hatch. Ideally this would greatly increase the mass of armor, so that smaller frigates and destroyers might shrug off AMMs, but only much larger heavily armored warships could afford to protect against larger missiles.
Having distance based accuracy penalties that can be countered by adding small amounts of MSPs in the form of onboard AIs or better communication gear. Since any missile with no onboard sensor is reliant on the firing ship's MFC, this can be explained as the missile relying less on the firing ship to provide instructions that may be experiencing a delay due to the distance from the firing ship. This would limit AMMs to a much shorter range, while larger missiles can devote some space to maintaining their accuracy at a longer ranger. Then again, I can't remember of Aurora is supposed to have FTL communication cananocially or not. If it does, it renders this on pointless.
Finally, building upon the last one, giving missile fire control's a limit to the number of active missiles they can control at a time. If your currently designed MFC can only control six missiles in flight at once, you'll probably want larger missiles that can attack from further out. Otherwise a beam armed ship might be able to realistically close the range without taking critical damage. New tech can influence the number of missiles controllable per launcher. Ideally your fire control links would be pooled together based on range, so if you had two AMM MFCs that can control 6 missiles at 60M KM each, and two ASM MFCs that can control 3 missiles at 300M KM, you attack with six missiles at a time, or the two ASM MFCs could be handed control of six AMMs to increase the density of your defensive fire. (Or likewise increase your offensive fire once you got within 60M KM).
I should have read this before posting my last reply :)
I have considered the limits on fire control as well. This is one of the better options, although it would add a degree of micromanagement as players would want the ability to release missiles to their onboard sensors to free up control links.
The option of having an onboard link to the fire control system is one I have mentioned, although the idea of relating the size of this system to distance is one that mnight work well, especially with the missile design changes. AMMs would still be viable because they would only need a small comm unit. I guess a new tech line could be based on comm distance per MSP. My only concern is for internal consistency. Not sure yet if this would cause a contradiction somewhere else. I'll give it some thought.
Steve
-
Anyway, I dont want to derail this thread further, in particular since this is not my main proposal, which stays at: Please make fuel efficiency heavily dependent on missile engine size.
I just want to explain a little more about my earlier point re missile engines vs ship engines. They are really the same thing now and ship engines have improved fuel efficiency with size. Most missile engines though are likely to be smaller than a size 1 ship engine, so I can't really make them more efficient than the equivalent ship engine.
Steve
-
For example in Newtonian Aurora missiles require an extra component to communicate with fire controls. The issue is that this would make AMMs less effective.
Actually, I think it all hangs together if you go back to allowing str-0 warheads to kill missiles. At present, an AMM requires 0.1 - 0.25 MSP for the warhead. If you required e.g. a 0.1 or 0.2 MSP fire control component, then AMM (which don't require a warhead) would have the same or better performance as they have at present, while ASM would have this as a tax.
You would still need to figure out what happens when a str-0 warhead hits an armored missile. A quick thought is that you could introduce "missile damage points" (MDP), which are e.g. 10x smaller than standard damage points (the 10x factor comes from someone's observation in a different thread that 1 hull space worth of missiles absorbs a LOT more damage than 1 HS of machinery). Then you could have the missile body itself do 1 MDP, while the warhead (or beams) does 10*str damage, and use the existing missile armor rules to see if the missiles are destroyed. Oh, yeah - this would mean that beam point defence would have 10x further range before it became ineffective too; you'd have to round the damage done by beams in point defence mode to a factor of 0.1, so they'd be effective against unarmored missiles out to where they do 0.1 in damage. I don't think this is a big imbalance, though, since beams are so short range compared to ASM, plus I expect fire control would probably act as the cutoff (as it typically does already).
John
-
The option of having an onboard link to the fire control system is one I have mentioned, although the idea of relating the size of this system to distance is one that mnight work well, especially with the missile design changes. AMMs would still be viable because they would only need a small comm unit. I guess a new tech line could be based on comm distance per MSP. My only concern is for internal consistency. Not sure yet if this would cause a contradiction somewhere else. I'll give it some thought.
IMO, having an onboard, distance-dependent missile comm unit would also be an easy method of fixing shipboard ECM with regards to missiles. (That is to say, the ease of overengineering fire controls to ignore ECM.)
Between that and the new missile engines missile design would be getting pretty involved. :)
-
What would you do for submunitions then? Would you just require the submunitions to have onboard sensors or large comm units? I think it would be an interesting way to relegate multiple warheads to large missile designs, but I can see it reducing the flexibility of large launchers.
-
Been away from the game for around 6 months and come back to find news of a feature filled update to 5. 7 waiting to tease me. After reading several of the 5. 7 related threads, it seems like we are about due for another "release imminent" update.
Steve, I hope your move went well. How is the 5. 7 progress coming? Are we any closer to getting our hands on this latest version? :)
Move went well. 5.7 is at the stage where I am creating a test campaign. Two problems - one is I can't settle on the theme of the campaign (started two without really getting into them and now thinking of trying a third), and second one is that I have started playing EVE again :).
Steve
-
What would you do for submunitions then? Would you just require the submunitions to have onboard sensors or large comm units? I think it would be an interesting way to relegate multiple warheads to large missile designs, but I can see it reducing the flexibility of large launchers.
Sub munitions would have the same restriction so perhaps they might be better with onboard sensors instead. I haven't decided on this whole idea yet though.
Steve
-
One idea I thought of was to change how fuel was stored in missiles. If you made it less cost effective to store a very small amount of fuel, you would prevent a size-1 missile from having a very long range in the same way that you're making it more cost effective to store very large amounts of fuel in 5. 7. It would be better then to put all the fuel in one large tank rather than a dozen tiny ones. It would be consistent with your stated plans for ship fuel storage as well.
Edit: Also, I made a post in the bug reports forum about how adding fuel to a missile makes it cost less. I'm not sure if it's WAD or not, but it doesn't make much sense to me. Reworking missile fuel costs could fix that issue as well.
-
Move went well. 5.7 is at the stage where I am creating a test campaign. Two problems - one is I can't settle on the theme of the campaign (started two without really getting into them and now thinking of trying a third), and second one is that I have started playing EVE again :).
Steve
Funnily enough I've started playing eve again as I didn't want to start a new Aurora campaign ahead of 5.7! My wife is very disappointed...
-
I should have read this before posting my last reply :)
I have considered the limits on fire control as well. This is one of the better options, although it would add a degree of micromanagement as players would want the ability to release missiles to their onboard sensors to free up control links.
The option of having an onboard link to the fire control system is one I have mentioned, although the idea of relating the size of this system to distance is one that mnight work well, especially with the missile design changes. AMMs would still be viable because they would only need a small comm unit. I guess a new tech line could be based on comm distance per MSP. My only concern is for internal consistency. Not sure yet if this would cause a contradiction somewhere else. I'll give it some thought.
Steve
One thing I was thinking of with the fire control link limitation vs comm gear was that along with a more powerful transmitter receiver, a missile could also contain more processing power/better passive senors for automously dealing with enemy ECM, evasive maneuvers, etc. This way if the missile is "cut loose" from an active fire control link, it doesn't have to suffer a big a penalty to its accuracy as a missile that was 100% reliant on its launching platform. Its possible that a smart enough AI on the missile could reduce the fire control requirements. So a short range AMM might take one link per missile, but a ship-killer with some room to spare might be able to squeeze in enough processing power to afford a five missiles per four FC links ratio (or better).
For submunitions, you could say the bus doesn't get destroyed when it releases its submunitions and acts like a relay between the launch platform and the submunitions along with letting the bus AI partially guide. This gives more reason to add processing power/comm space to the bus, as it would be cheaper to beef it up and have it control its cargo than having the parasite missiles have to coordinate back with the ship.
-
eve is bad for youre health ;D
-
Just read through the 5.7 change log notes... Hot damn is this looking like an impressive release. I can not wait. I'm particularly impressed by the reworking of Sol. And the fact that civilian shipping lines will make their own designs. And keep them modern. And that you can take POWs and track them as separate entities. And that you can create specific missile engines. And...
I think it'd save time to just say it's looking amazing.
-
I just want to explain a little more about my earlier point re missile engines vs ship engines. They are really the same thing now and ship engines have improved fuel efficiency with size. Most missile engines though are likely to be smaller than a size 1 ship engine, so I can't really make them more efficient than the equivalent ship engine.
Steve
I understand that missile engines and ship engines are about to be merged in one system that makes them the same thing really. I also understand that you want to keep internal consistency. But it is possible to use a consistent approach and make the size of missile engines have an effect on fuel efficiency.
You announced that (ship) engines get increased fuel efficiency with size, such that increasing the engine by 1 Hullsize reduces fuel consumption by 1 percentage point. (i.e. a 25 HS engines uses 75% of the fuel per generated power-point). Obviously, missile engines are not that different in absolute size, maybe between 0.01 and 0.1 HS so the resulting difference would be really small in this regime.
An alternative method would be to use a different formula for the entire range of possible engines. Instead of the announced formula FU = 1 – ES/100 (FU= Fuel Usage, ES = Engine Space), one could also use FU=ES^(-0.1)[EDIT: fixed mistake]. The effect on ship-engines would be similar, a size 1 engine would use 100% fuel, while a size 25 engine would use 72% (instead of the 75% you suggest). However, now this would also become relevant for missile engines- a size 0.01 missile engine would use 158% fuel, while a size 0.1 would use 126% fuel. Of course the difference is not tremendous, but missiles can be expected to be “boosted” (more power, less fuel efficient), and this is a multiplier, so the difference could stack up. At any rate, it would be an incentive to use larger missiles. Another alternative would be to use FU=1-ln(ES)/10: A size-1 engine would use 100% fuel, a size-25 engine would use 68%, a size-0.1 would use 139% and a size-0.01 would use 146%.
The point is it is possible to create a system that:- Is consistent and applies the same rules to all engines
- Replicates the fuel-efficiency values you envisioned for ship-engines
- Extends this consideration to become meaningful for missile-engine designs, which provides an inventive for larger missiles
- does not materially effect AMMs, since those require minimal fuel at their short ranges
That being said, the other options are of course also appealing, as mentioned before.
-
Without wading into the coding/equation feasibility discussion on missile engine size the precedent is already there for very small scale systems being inefficient. Once a given system declines in size to a degree you reach a point were certain parts of the system cannot be made smaller and/or declining size and energy output do not remain parallel. I like the idea of engines smaller then 1hs ramping up in fuel cost.
-
Without wading into the coding/equation feasibility discussion on missile engine size the precedent is already there for very small scale systems being inefficient. Once a given system declines in size to a degree you reach a point were certain parts of the system cannot be made smaller and/or declining size and energy output do not remain parallel. I like the idea of engines smaller then 1hs ramping up in fuel cost.
Aha! I hadn't considered it from that perspective. I was thinking that I couldn't have larger missile engines be more fuel efficient than smaller ones because they would be more fuel efficient than larger ship engines. Of course, I can make smaller engines less efficient rather than making larger ones more fuel efficient. I know it sounds like semantics but it is a key difference. That would also solve another issue I have been considering, which is why you wouldn't have a lot of small engines on a missile rather than one larger one.
I agree now that fuel efficiency is the solution to the size-1 ASM issue. I just needed to look at it differently. I'll do some work on it over the next few days when I get chance.
Steve
-
I understand that missile engines and ship engines are about to be merged in one system that makes them the same thing really. I also understand that you want to keep internal consistency. But it is possible to use a consistent approach and make the size of missile engines have an effect on fuel efficiency.
You announced that (ship) engines get increased fuel efficiency with size, such that increasing the engine by 1 Hullsize reduces fuel consumption by 1 percentage point. (i.e. a 25 HS engines uses 75% of the fuel per generated power-point). Obviously, missile engines are not that different in absolute size, maybe between 0.01 and 0.1 HS so the resulting difference would be really small in this regime.
An alternative method would be to use a different formula for the entire range of possible engines. Instead of the announced formula FU = 1 – ES/100 (FU= Fuel Usage, ES = Engine Space), one could also use FU=ES^(-0.1)[EDIT: fixed mistake]. The effect on ship-engines would be similar, a size 1 engine would use 100% fuel, while a size 25 engine would use 72% (instead of the 75% you suggest). However, now this would also become relevant for missile engines- a size 0.01 missile engine would use 158% fuel, while a size 0.1 would use 126% fuel. Of course the difference is not tremendous, but missiles can be expected to be “boosted” (more power, less fuel efficient), and this is a multiplier, so the difference could stack up. At any rate, it would be an incentive to use larger missiles. Another alternative would be to use FU=1-ln(ES)/10: A size-1 engine would use 100% fuel, a size-25 engine would use 68%, a size-0.1 would use 139% and a size-0.01 would use 146%.
The point is it is possible to create a system that:- Is consistent and applies the same rules to all engines
- Replicates the fuel-efficiency values you envisioned for ship-engines
- Extends this consideration to become meaningful for missile-engine designs, which provides an inventive for larger missiles
- does not materially effect AMMs, since those require minimal fuel at their short ranges
That being said, the other options are of course also appealing, as mentioned before.
Thanks for persevering with trying to persuade me on this. I'll do something along the lines you have suggested.
Steve
-
And now we have yet another "must have" item preventing 5.70 release.
=P
Nah, it's good. It is a "must have" after all! XD
-
This is looking like a real sea change in terms of the current game play. Im pretty pumped to see this release!
-
Just a reminder to remember to include my Organic theme in 5.7. Then I can actually restart my Organism campaign with proper names and post it here!
-
Any changes to hyperdrives or how you add them to a design? Can we make hyper missiles yet?
-
Just a reminder to remember to include my Organic theme in 5.7. Then I can actually restart my Organism campaign with proper names and post it here!
I would recommend putting this reminder in the official suggestions thread (and not the unofficial one that someone started). That's the place with the best chance of Steve finding it when he looks for enhancements he might have forgotten.
John
-
50 cals are not designed to hurt warships - gauss cannons definitely are! But that aside, the gameplay implications are less than appealing. You basically eliminate an entire branch of beam weaponry as collateral damage. Or if you try to balance them appropriately (RP costs included), Gauss cannons would either be underpowered against wall fields or totally overpowered against ships without them. Or relegated entirely to point defense duties - glorified CIWS. Arguably they are sorta that way already, but oh well.
Well, it seems that his idea was for a heat resistant shield (like the one on an Orion drive), or ablative (like the space shuttle). Those only prevent damage from thermal energy, such as a nuclear explosion or a laser hit. Kinetic rounds such as gauss, while much weaker, would be unaffected. The orion drive can actually be crippled because the nuke FAILED to go off.
And I would hardly call a gauss gun a capital ship weapon or glorified CIWS. I would say they shine more in the anti-fighter role. Also for interceptors.
There's also a dramatic range nerf to railguns and lasers while presumably leaving mesons untouched. In short, you'd have to a massive balance pass for existing weapons to address these problems.
Well, mesons are suppose to be the long range, guaranteed damage weapon. I always though of mesons as The Traveller style weapons, which were basically nuclear flak guns. Harder to aim the larger shots, but even a close miss would damage the enemie's armour. A direct hit would detonate inside the ship, a guaranteed kill on smaller ships. I always found it funny that Aurora meson have two techs to increase range, one of which does it without increasing mass. But that would ruin the balance we have in place now.
-
Just curious, is it worth it to start a new 5.60 campaign? I wanna start a new one, but I don't know if it'll be worth it to start one now if 5.70 is gonna be released soon, or is the release still a ways off?
-
Just curious, is it worth it to start a new 5.60 campaign? I wanna start a new one, but I don't know if it'll be worth it to start one now if 5.70 is gonna be released soon, or is the release still a ways off?
That depends entirely on your personality. I personally have trouble starting any kind of new game when I know there's a major release on the horizion. Waited months for the new Dwarf Fortress to come out, I currently can't play Civ V because there's an expansion pack coming out next week and even tried to start a new game of Aurora a week or so ago. However knowing that at least a few of the things that bug me will be fixed soon (for some definitions of soon at least) along with new features, I couldn't get past the game creation screen.
Now if you're not quite so picky as me and you enjoy 5.6, then go ahead and start a new game. If you have fun then it's worth it.
-
Just curious, is it worth it to start a new 5.60 campaign? I wanna start a new one, but I don't know if it'll be worth it to start one now if 5.70 is gonna be released soon, or is the release still a ways off?
A way off yet. I have quite a few changes left to code and a lot of testing.
Steve
-
Okay then, I went ahead and started a new one.
It reminded me of something that's bugged me for a while, though: The promotion scores for ground officers. I feel like ground combat bonus gives way too much of a promotion score bonus compared to ground training. After all, ground training is a skill more important to higher officers than the combat bonus. Any chance you could change it so that ground combat bonus gives less of a promotion score boost and ground training gives more?
-
That's debatable. An effective military commander is more likely to get promoted (assuming an absence of politics) in wartime over an effective trainer. While for meta-game reasons, you would want the person with the highest training scores in charge of brigades and divisions, from a RP perspective it does make sense that the commanders with the best grasp of military tactics would be more likely to be promoted.
-
But then the issue occurs that officers with combat skill bonus but no trainer bonus don't get auto-assigned to lead brigades and divisions, so they get retired after 6 years. What this ends up meaning is, your most combat-effective officers (read: the ones that should be commanding battalions) are constantly getting promoted and then retired because they have no trainer bonus.
-
I'm stuck on the whole new-Sol thing. As soon as Steve posted those screen shots I couldn't bring myself to continue my current 5.6 game or start a new one. *Very impatiently waiting - though trying hard not to show it*
As for officer distribution, the auto-assign feature really could use some tweaking. I too have found officers unassigned to ships because of a lack of certain attributes. Even though the lack of training bonuses makes them a poor choice for initial deployment they still bring bonuses to the ship that are useful at other times. When quality officers are in short supply any warm body at the helm is better than nothing. The current fix for this seems to be to overbuild on the training centers so you have a glut of officers for auto-assign to choose from. Either that or resign yourself to micro-management of officer assignments.
I think an adjustment to how non-combat craft are assigned officers would help. I often see quality officers assigned to otherwise worthless craft and main-line warships go unstaffed. If I manually assign them the assignments default back at the next auto-assign unless I force them permanently.
-
Ah, the bug fix is good. This actually affected me in my current game, as I had human freighters shipping things from my home planet to earth and I wasn't getting any taxes for it. At the time I actually just assumed I had misunderstood the taxation mechanics and thought nothing more of it IIRC.
-
Steve
Great to hear you are progressing with a test campaign, what did you settle on for a scenario?
Any chance you could drop a few example ship designs, am dying to see the impact of all of your changes!
-
It'd be cool if you could even turn it into a fiction thing. Even if just a technical gameplay fiction just showing how the changes effect the game.
-
Steve
Great to hear you are progressing with a test campaign, what did you settle on for a scenario?
Any chance you could drop a few example ship designs, am dying to see the impact of all of your changes!
I have been doing some writing up, although not much. Here is the starting blurb I came up with:
In late 1940 the Third Reich directly controlled much of Europe and was either allied or had friendly relations with the remaining independent European powers, with the exception of the United Kingdom. Plans to invade the UK had been abandoned after the Battle of Britain and Germany turned its gaze on the Soviet Union. Japan was heavily engaged in its Chinese war and the United States remained an isolationist power. The Soviet Union was recovering from the purges of the late 1930s and had recently fought a costly but successful war with Finland.
On November 1st 1940, the Swedish scientist Niels Bohr published a paper describing a new theoretical field of physics, quickly dubbed as Trans-Newtonian, which would transform the world, opening up new manufacturing processes and allowing weapons of incredible power. Scientists around the world initially dismissed the claims as fantasy, especially the existence of the so-called Trans-Newtonian minerals which Bohr asserted could be mined from the core of the planet. Albert Einstein, normally an academic opponent of Bohr in debates on classical physics vs. quantum physics, declared his support for Bohr's theories and suddenly every nation in the world began to take notice. Within months, the theories were accepted as facts and work began on extracting the new minerals and converting factories to use the newly discovered technologies.
All the major powers realised that once new Trans-Newtonian weapons were available, continuation of the war in Europe could lead to the destruction of the entire planet. A peace conference was held in Geneva and a non-aggression pact was signed between the British Empire and the Third Reich. Germany remained in control of much of Europe and those European countries that had not been conquered, such as Italy and Spain, soon fell under strong German influence. In the Far East, Japan concentrated on conquering China as quickly as possible. Plans for a strike against the USA were abandoned as Japan's lack of natural resources were no longer an issue. The UK quickly transformed its own industry and began building up the industrial potential of the major Commonwealth countries, such as Canada, Australia and India. The USA, conscious of its limited population compared to the other major powers, began to emerge from isolation and sought to build alliances with other nations in the New World, such as Brazil and Mexico.
By the end of 1945, the world was split into five major power blocs; the Commonwealth, the United States, The Empire of Japan, the Soviet Union and the Third Reich. All their industry was fully converted to the new Trans-Newtonian technology. While it remained obvious to the leaders of the great powers that an all-out world war would result in nothing less than mutual destruction, they all had a new goal in mind - the conquest of space. Almost simultaneously, the five great powers turned their eyes toward the heavens, in search of new resources and new worlds to conquer.
Commonwealth
Australia, Burma, Canada, Iceland, India, Iran, Iraq, Ireland, Malaya, Malta, Nepal, Newfoundland, New Zealand, New Guinea, Singapore, South Africa, Thailand, United Kingdom
Population: 525m
Wealth and Industrial Percentage: 75%
Third Reich
Albania, Austria, Belgium, Bulgaria, Czechoslovakia, Denmark, Ethiopia, France, Germany, Greece, Hungary, Italy, Luxembourg, Netherlands, Norway, Poland, Romania, Ruanda-Urundi, Spain, Turkey, Yugoslavia
Population: 360m
Wealth and Industrial Percentage: 100%
United States
Brazil, Cuba, Mexico, Philippines, United States
Population: 210m
Wealth and Industrial Percentage: 150%
Empire of Japan
China, Dutch East Indies, French Indochina, Japan, Portuguese Timor, Korea, South Pacific Mandate
Population 700m
Wealth and Industrial Percentage: 25%
Soviet Union
Estonia, Finland, Latvia, Lithuania, Mongolia, Soviet Union
Population 180m
Wealth and Industrial Percentage: 100%
All nations start with no shipyards, 30 research labs, and 50,000 research points that may only be spent on Construction/Production techs. The UK and USA are Friendly, as are the Third Reich and the Empire of Japan. All other relationships are neutral.
(I guess I should really start a thread in fiction)
-
Hmm, this has all the makings of a good campaign!
-
China loses before the game even starts? A new low! ;)
-
China loses before the game even starts? A new low! ;)
Ha!
That was one of things I liked about the last campaign, China were making a come back.
-
I was about to protest Finland belonging to USSR but then I remembered that Soviets were planning the "proper" conclusion to Winter War but were prevented from it by the Germans. In this alternate timeline, it's entirely plausible that the Red Army kept marching.
And if we can't have 5.70 itself come out tomorrow, reading about the effects of the changes in your test campaign is the second best thing, so yes please for a fiction thread!
-
Ha!
That was one of things I liked about the last campaign, China were making a come back.
C'mon we both know that was never going to last, Being Chinese in one of Steves campaigns is riskier than being an Ice block on route to the Sun
Matt
-
A small "historical" detail, Niels was from.Denmark. ;) Then we have to wait for more... :(
-
Well, as major population part of one of the existing powers it may actually have some influence.^^
-
Five years from WW2 era tech to TN? Isn't that a bit fast? Interesting scenario, though.
-
Five years from WW2 era tech to TN? Isn't that a bit fast? Interesting scenario, though.
Given how fast and cheap the early researches are, I've always kind of assumed it's more engineering than real scientific research. And considering how the research cost doubles each tier (going from very cheap to very expensive quite quickly) one can easily assume that the first techs are basically just kludged together "try strapping TNEs to it and see what happens" designs, which explains why for just a few more RP you can make something twice as good. I don't think early TNE stuff would really be much of a problem with pre-information era tech.
Though... an interesting point; each side has 30 research labs, which would be 6,000 RP a year, but apparently have 50,000 RP of TNE techs in five years. So maybe a little fast, but not unbelievable assuming good scientists. And that era of history was somewhat notable for impressive scientists and engineers.
-
SteveW, is it possible to buff NPR ship armor of ALL AI ships, including regular alien NPRs, as well as swarm, precursors and extra-galactics? They need to have at least DOUBLE their current armor level to be competitive with humans. It's not particularly amazing when my lasers slice through the enemy like butter because they only have 6-12 armor at best, whereas my 36kton cruisers have 30 layers of armor and my 12kton destroyers have 15 layers of armor standard, plus shields on top of that in my newest revisions.
Other than that, I enjoy the AI's tactics and don't see an urgent need for a change there. My biggest gripe with the AI is that their ships have paper-thin armor. Looking at all the armor values in the database in my 100-year game, they could ALL use a flat doubling.
Thanks SteveW, looking forward to 5.7! :)
-
SteveW, is it possible to buff NPR ship armor of ALL AI ships, including regular alien NPRs, as well as swarm, precursors and extra-galactics? They need to have at least DOUBLE their current armor level to be competitive with humans. It's not particularly amazing when my lasers slice through the enemy like butter because they only have 6-12 armor at best, whereas my 36kton cruisers have 30 layers of armor and my 12kton destroyers have 15 layers of armor standard, plus shields on top of that in my newest revisions.
Other than that, I enjoy the AI's tactics and don't see an urgent need for a change there. My biggest gripe with the AI is that their ships have paper-thin armor. Looking at all the armor values in the database in my 100-year game, they could ALL use a flat doubling.
Thanks SteveW, looking forward to 5.7! :)
I've completely redone the NPR ship design code for v5.70. There isn't a huge change in the actual designs but its now a lot easier for me to add new ones. However, as part of that I have upped NPR armour, although not double.
Steve
-
China loses before the game even starts? A new low! ;)
I Seriously Laughed for five minutes!!!
-
I never understood why people would pile on that much armor.
Though then again my favourite weapons are mesons and MWL.
Yay for better NPR ship designs.
Now we just need a better research behavior so they stop researching all over the place.
-
Steve: A Funfact - German scientistst proposed during the war the usage of railguns as anti aircraft weapons, it was deemed impossible due to the energy amounts and densities (which where a bit overestimated) but on the base of that one could advocate that the germans could have advantage in capacitators and railguns.
If you need someone for some proper german weapon/ship names i would gladly help out. I love your campaigns they make a good read.
-
I'm pretty excited for this new version. It's been almost six months since I played Aurora, and I'll definitely be picking it up again for a long time span after 5.70 drops. Until this, I'm patiently waiting and checking the site once a day. :D
-
Heh, I essentially stopped after NA was announced.
That just seemed so much more nerdy. I just couldn't get myself to ignore it.
But I'll definitely play 5.7. I got an idea for a massive campaign, that'll turn out too stressful after a few years again. I know myself too well.
-
I've completely redone the NPR ship design code for v5.70. There isn't a huge change in the actual designs but its now a lot easier for me to add new ones. However, as part of that I have upped NPR armour, although not double.
Steve
Just a quick addition, do NPRs ever build missiles with x-ray pumped lasers, in order to bypass final defensive fire? If not, they should have a decent chance to be able to build these. I typically build some monstrous AM gauss turrets, and it'd be quite a surprise if I ever encountered these in battle (I never have up until this point), completely negating my systems which can have >99% chance to block 150 missiles at 50kkm/sec velocity for just one of my stacked fleets. :)
-
Just a quick addition, do NPRs ever build missiles with x-ray pumped lasers, in order to bypass final defensive fire? If not, they should have a decent chance to be able to build these. I typically build some monstrous AM gauss turrets, and it'd be quite a surprise if I ever encountered these in battle (I never have up until this point), completely negating my systems which can have >99% chance to block 150 missiles at 50kkm/sec velocity for one of my stacked fleets. :)
Laser warheads don't work properly at the moment IIRC.
-
I noticed Steve played with the Wealth and Industry Percentages for his test Aurora game for v5.70. Has anyone ever given any thought to adjusting how Wealth and Industry Percentages work?
At the moment, they basically model the GDP per capita or industrial GDP per capita of the faction. This allows for the idea that a country with a smaller or larger population is more or less efficient at generating wealth or industry, sort of like comparing the U.S. and PRC.
However, these values are static. If my Aurora game lasts 50 years, I sort of expect that a PRC based faction will eventually catch up to a U.S. based faction in terms of wealth and industry generation efficiency. Or, alternatively, that a U.S. based faction might become worse over time. I just do not like the idea that a faction would essentially have a static GDP per capita or industrial GDP per capita for its entire existence and always be at a disadvantage against a more efficient faction.
I just have no idea what adjusting Wealth and Industry Percentages to overcome this would entail. Ideally, something that occurs automatically based on financial and industrial performance over time, but I have not devoted enough thought to it.
-
I see a need for a scaled GDP in that way, look at Australia, our GDP against our 20 million population is more efficient then the US (not large efficient), mainly due to trade and resources. I think the higher the population there more chance efficiency is reduced as a percentage.
-
I see a need for a scaled GDP in that way, look at Australia, our GDP against our 20 million population is more efficient then the US (not large efficient), mainly due to trade and resources. I think the higher the population there more chance efficiency is reduced as a percentage.
It's definatley something that could do with a look at. In some respects you already see growth in GDP because of the effect of trade and mining operations revenues from your civilian sector. You could further link this to your wider industry and levels of employment on your planets. Ie mining could produce a relatively low GDP per population engaged whilst people engaged in research who might be on higher wages produce a higher level of GDP. This way you might see nations which move from extraction to production and research increasing GDP average across their population. For colonies this could also work quite well with lower paid people being used on all the environmental upkeep becoming more production as terraforming releases them to more proitable employment.
-
A major problem with that is that the appearance of servant economies being more productive than extractive economies has more to do with the fact that extractive economies get the short end of the political stick. When American software developers get paid a hundred times as much as Chinese assembly line workers, who in turn get paid ten times as much as Congolese miners, it is far more because of the uneven distribution of aircraft carriers than because of the uneven distribution of productivity.
So while a planet full of financial centers within a well diversified empire should be richer pro capita than a mining outpost, an empire which has nothing but financial centers should not have a ludicrously high GDP. It should be in complete economic paralysis. But Aurora doesn't model that, because its political, international trade and intra-empire cash flow models are fairly rudimentary.
This discussion also touches upon another fault in the handling of taxation, government budgets and generic "wealth" mechanics: Governments don't get to "save up" money for a rainy day, the way Aurora lets you do. Most of what the government wants to buy with its money is labor, and labor dissipates immediately if it is not used.
Not-spending money today therefore does not allow the government to spend that money tomorrow without straining the economy. In the real world there are no little gray men in suits smoking rose petal cigars and running a time savings bank where the unemployed can stash the man-hours that the government not-buys. Conversely, spending money today does not require the government to not-spend tomorrow to avoid straining the economy. (There might be time-lagged higher-order effects, but they all show up in the output gap, so given sufficiently alert and fast-acting fiscal authorities you can safely ignore them in your macroeconomic planning. )
A more elegant solution would be to have a series of "baseline labor force participation" techs, and simply let empires start at different levels of those techs and different levels of the GDP pro capita techs. This might also open up possibilities of modifying labor force participation rates by governor bonus and by previous employment history (persistent labor shortage brings people out of retirement, provides better career opportunities for academic drop-outs and therefore encourage earlier labor force entry; conversely, persistent unemployment does the opposite, and also pushes people into the informal economy, from which they will take some time emerging when unemployment drops).
-
So how would that be modeled in the game?
In a doable way?
Also, what about inflation?
I'm pretty certain a stock broker pays more for his banana than the farmer that grows them.
-
All very true!
Of course the Organism CAN bank such things, mostly by decommissioning excess workforce when they aren't required and decanting many new ones when they are needed. (grin)
-
Depends on how much detail one wants to go into.
The simplest way to model it would be to have a "maximum deficit" figure (which should depend on GDP, maybe on civilization options, probably on government type), beyond which you will get unrest due to excessive inflation. It would then be assumed that if you run less than that deficit, your ministry of finance will find some worthwhile civilian projects to spend the remaining budget on.
You can add complications from there in arbitrary amounts, such as having the player juggle the civilian government expenditures as well, adding stochastic noise and business cycles, all the way up to a full-blown flow-of-funds model, with Unrest modifiers from unemployment and sudden changes in the provision of government-sponsored civilian goods. But my general feel is that Aurora is more about managing the military-industrial complex than the civilian macroeconomy, so that will probably not be merited.
(All this is assuming that the ambition is to model a (more or less) democratic, (more or less) capitalist monetary economy. Command economies, target economies and non-monetary economies have different rules. As do Soylent Green economies, and civilizations similar uses of "human resources" ;-P)
-
The wealth in Aurora works kind of odd since empires are a mix of communist and capitalist economies.
For instance, if you want to build a factory, you pay for it, and provide the minerals for it, and build it with your own factories. Which would seem to indicate a communist economy. But then you have to pay for production by that factory as well, which would seem to be a capitalist economy.
By comparison, the shipping lines and civilian mining colonies are more clearly free market capitalism, as the respective corporations purchase their own mines and ships, and then you can hire the services with tax money. In theory, it might be possible for the entire economy to be modeled this way, with civilian construction factories on populated worlds, and you could hire them to produce shipyards/etc; wealth percentage/GDP would be more accurately modeled by the total production of an empire than a % set at start, since one assumes all those fantastically production TNE factories would increase GDP. However, while maybe not completely based in reality, Aurora's economy works and is (reasonably) easy to manage, which is possibly more important than a hyper-realistic economy simulator.
-
I imagine the construction factories you build to be the ones devoted to the armaments industries, and the player being a sort of abstraction for the collective technostructure of the military-industrial complex. Likewise, I imagine financial centers to be (subsidies for) civilian manufacturing industries which are necessary subcontractors for the armaments industry, but which are abstracted to generic civilian manufacturing in the game. The armaments industry is substantially a government-funded target economy, whatever the nominal ownership of the relevant factories. So under those assumptions and at Aurora's level of abstraction, all industrial economies look more or less the same, whether Communist, Fascist, Social Democratic or Corporatist.
The wealth variable is the odd duck out, because it operates as if you are running a small open economy (essentially, the "empire wealth" corresponds to the strategic foreign currency reserves of the empire), when in fact you are running a large closed economy (inter-empire trade is peanuts compared to the typical "empire wealth," and the sum of empire surpluses fails to sum to zero, as foreign balances must).
Eliminating the "empire wealth" and replacing it with a "maximum deficit," above which you get unrest due to loss of social acceptance of the government's currency, would be a simple solution which would make the budget work plausibly at the present level of abstraction.
-
Wealth is(or should be) a nifty approximation for energy, and in that vein I'd replace financial center with solar farms/energy storage or some such thing. Obviously in light of the current financial troubles it looks kinda bad to have what we traditionally call finance generate wealth. Also getting away from wealth as we define it takes the human element out of the equation which really throws a monkey wrench into everything.
"However, these values are static. If my Aurora game lasts 50 years, I sort of expect that a PRC based faction will eventually catch up to a U.S. based faction in terms of wealth and industry generation efficiency. Or, alternatively, that a U.S. based faction might become worse over time. I just do not like the idea that a faction would essentially have a static GDP per capita or industrial GDP per capita for its entire existence and always be at a disadvantage against a more efficient faction." - The economic expansion techs apparently model this, China in his scenarios gets a much bigger boost from their greater starting pop than NATO would get for each level.
"When American software developers get paid a hundred times as much as Chinese assembly line workers, who in turn get paid ten times as much as Congolese miners, it is far more because of the uneven distribution of aircraft carriers than because of the uneven distribution of productivity." - I'd say that uneven distribution of carriers is an indicator of uneven distribution of production.
-
Wealth is(or should be) a nifty approximation for energy, and in that vein I'd replace financial center with solar farms/energy storage or some such thing.
Doesn't really matter to the argument, because energy dissipates relatively rapidly once you've harvested it, unless you sacrifice about an order of magnitude to store it. So in practice, your budget constraint is still instantaneous rather than intertemporal.
You also don't get to run up an "energy debt" which must be "paid off. " If you exhaust your strategic stockpile, you'll have to confiscate supplies from the civilian sector, but once you stop confiscating (i. e. stop running an energy deficit) you don't need to (and indeed cannot) replace the kWh you confiscated.
I'd say that uneven distribution of carriers is an indicator of uneven distribution of production.
Not unless the countries in question practice autarky, or you count the ability to extract colonial tribute as a form of productivity (which you shouldn't - bad things happen to empires which make that mistake).
-
Eliminating the "empire wealth" and replacing it with a "maximum deficit," above which you get unrest due to loss of social acceptance of the government's currency, would be a simple solution which would make the budget work plausibly at the present level of abstraction.
Wealth sounds a lot better than max deficit. Really, would there be a difference between Deficit and some sort of hard or soft wealth storage cap?
Wealth is(or should be) a nifty approximation for energy, and in that vein I'd replace financial center with solar farms/energy storage or some such thing. Obviously in light of the current financial troubles it looks kinda bad to have what we traditionally call finance generate wealth. Also getting away from wealth as we define it takes the human element out of the equation which really throws a monkey wrench into everything.
It kind of is already, IMO. I view civilian wealth tech as a general upgrade in commercial and residential technologies of all sorts, certainly including power generation and the like.
Though an orbital wealth/energy generating infrastructure seems like a cool thing to have.
-
Not unless the countries in question practice autarky
Our ability to build carriers basically preceded any serious trade with China so lets go with option A here. The west did industrialize first, and did conquer infant mortality first, and so on, and it will be some time before the rest of the world catches up.
because energy dissipates relatively rapidly once you've harvested it, unless you sacrifice about an order of magnitude to store it.
True, but we can trans-newtonian away such problems. Good point about deficits, but how often does anyone run anything but a minor deficit? The biggest reason for debt spending(pushing the can down the road to the next politician) doesn't exist for us.
-
Really, would there be a difference between Deficit and some sort of hard or soft wealth storage cap?
Yes, that's the difference between an instantaneous and an intertemporal budget constraint. That is a non-trivial difference to your budgeting.
Swapping out wealth for energy supply and energy demand would solve the aesthetic issue, no?
Our ability to build carriers basically preceded any serious trade with China
Eh, no.
The European rise from peripheral to central power in the international trade system is a consequence of first the Iberian, then the Anglo-Dutch maritime dominance, and related colonial activities in South America, permitting gold-silver arbitrage with China as well as buy-in to the Far East carry trade. All of which happened at at time when Europe was, by any reasonable measure, far less productive than any other sedentary Northern-hemisphere culture.
And American hegemony is, economically and culturally, the epilogue of the European colonial system, not the prologue of a different world-system.
-
All of which happened at at time when Europe was, by any reasonable measure, far less productive than any other sedentary Northern-hemisphere culture.
Are you sure about that? European GDP per capita from that time period may be higher than originally thought.
http://www.sciencedaily.com/releases/2010/12/101205234308.htm
-
I was aware of that, yes. Doesn't change the fact that even the relatively prosperous parts of Europe were lagging India and China during this period.
-
Why isn't GDP per capita a reasonable measure of productivity? Didn't we innovate precisely because of the labor crunch we had(particularly post the black death)? And doesn't this take us back to the original point, that there are fewer, but more highly paid, American software developers than there are Chinese assembly line workers?
-
Economic historians tend to use total factor productivity, because it is more reliably measured. GDP pro capita can be increased by increasing hours worked pro capita, for instance, which is a policy decision rather than a productivity improvement.
The notion that remuneration has to do with productivity or the scarcity of applicants for a job is trivially dispelled by even a casual examination of the remuneration gap between an advertising man (who usually has negative productivity, in the sense that humanity has more unfulfilled wants after he has done his job than before) and an assembly line worker. You can construct a more detailed argument by considering the marginal value of an additional customer to the firm vs. the increase in aggregate consumer and producer surplus by the marginal consumer switching firms, but we are already veering pretty far off-topic.
Suffice it to say that if you think you can offshore manufacturing and maintain the R&D and political control functions at home, then you're kidding yourself.
-
Economic historians tend to use total factor productivity, because it is more reliably measured. GDP pro capita can be increased by increasing hours worked pro capita, for instance, which is a policy decision rather than a productivity improvement.
The notion that remuneration has to do with productivity or the scarcity of applicants for a job is trivially dispelled by even a casual examination of the remuneration gap between an advertising man (who usually has negative productivity, in the sense that humanity has more unfulfilled wants after he has done his job than before) and an assembly line worker. You can construct a more detailed argument by considering the marginal value of an additional customer to the firm vs. the increase in aggregate consumer and producer surplus by the marginal consumer switching firms, but we are already veering pretty far off-topic.
Suffice it to say that if you think you can offshore manufacturing and maintain the R&D and political control functions at home, then you're kidding yourself.
Yeah, let's just say that this is rather detached from main stream economics that I would rather not see it in the game. And frankly, your private thoughts on economic drivers are more of an off-topic discussion, rather than a reference to the 5.7 changes.
-
I don't think you'll find any great controversy in the empirical and organization theory literature that remuneration tracks productivity extremely poorly.
The RatEx, DSGE and Real Business Cycle crowds would disagree, but they have (to put it very kindly) problems with matching their theory to empirical reality.
-
Yeah, let's just say that this is rather detached from main stream economics that I would rather not see it in the game. And frankly, your private thoughts on economic drivers are more of an off-topic discussion, rather than a reference to the 5.7 changes.
I started us down this road actually, and I found it interesting atleast.
-
noone said it was uninteresting. but it is definitely OT.
Yes, that's the difference between an instantaneous and an intertemporal budget constraint. That is a non-trivial difference to your budgeting.
Swapping out wealth for energy supply and energy demand would solve the aesthetic issue, no?
I don't really see the practical gameplay difference, unless you completely reworked how wealth worked. Also, 'Wealth' has an obvious interaction with the civilian sector while 'Energy' does not. i.e. it makes no sense whatsoever that luxury liners generate energy.
-
Personally I think that the current wealth system would just work better if you could not store the wealth for a rainy day. Wealth should just be a measure of an economies total productivity and that you can't really store. If you run a deficit you would eventually start getting other negative effects such as lower factory output, unrest etc..
-
Somewhat off-topic.
The 5.7 is supposed to have ability to disable sensors system-wide via SM mode. Since the 5.7 itself is likely not coming anytime soon, is there possibility of having this option in a smaller patch? I don't know about others, but right now I'm playing six-sides campaign (all on Earth) and I have extremly long time increments, on the order of several minutes. Since I'm pretty sure this is due to constant sensor checks, the ability to disable them would be God-sent for me.
-
Probably not possible, as Steve has already implemented all the changes for 5.7 and is currently running a test campaign. So he would have to roll back the other changes and to enable only that change.
-
What you could do, is either take away all of their Deep space tracking stations, or give them all 40 DSTS each. It might short circuit the sensor sweeps, and it will just be up to you to make sure that each "side" doesn't know more than it should.
-
That's an interesting idea. And it could work. However, won't there still be sensor checks for my ships? I know they have only strenght 1 EM/TM sensor, but that's still a sensor and I have, by now, quite few ships running around the Sol system.
-
It depends on how its programmed, but hopefully if all contacts are accounted for it shouldn't run any more sensor checks for suggestion two atleast. On the other hand with suggestion one, each DSTS you've got is running a check on every ship, and precipitating its own check from every other ship if they are on their own colony.
Another idea, if your problem is a bunch of freighters/colonies running everywhere, is to scrap them all, and fast OOB megafreighters/colonies of equal tonnage, but as just 1 ship, which should reduce some, or a great deal of the sensor checks being run.
-
Are civilian fuel harvesters going to be subject to the shiping lines scrapping old ships that is being implemented in the new version? It would make sense for them to be excluded as they have no need to update their tech while they are harvesting. Possibly have a check to see if their engine tech is outdated when the sorium in the gas giant they are harvesting runs out, which would enable obsolete ones to be removed. Although there should probably be an event notice and a time delay before they are actually scrapped to allow for tankers to get there to aquire their last load of fuel.
Also will they just remain idle when they have filled their fuel tanks?
-
I sure hope they sell their fuel for taxes if they are scrapped. Maybe even if full.
I guess they won't be scrapped as long as they are harvesting, because they still have a job?
-
Update to Missile Engines
I have updated the main missile engine post with new rules for increased fuel usage for small missile engines and changed the examples to reflect the changes. This post is just a brief overview as readers may not realise the main post has been edited. The relevant section is below
Engine Size: Missile engines can range in size from 0.1 MSP to 5 MSP in 0.1 MSP increments. It is hard to create very small fuel efficient engines, so smaller missile engines suffer a penalty to fuel consumption. The formula is: Fuel Modifier = Int ((Engine Size in MSP / 5) ^ (-0.683)). There is no need to remember this formula as the % change to fuel consumption is shown for each size option in missile engine design. For example, the following sizes of missile engine have the listed fuel consumption penalties
5 MSP: 0%
4 MSP +16%
3 MSP +41%
2 MSP +86%
1 MSP +200%
0.5 MSP +381%
0.3 MSP +583%
0.1 MSP +1346%
Steve
Very very interesting. This is definitely going to shift the current missile design strategy for a lot of folks. I am really looking forward to the new release!
-
Correct Allocation of Export Tax
I'm playing a test campaign at the moment for v5.70 and I've realised that export taxes are not being correctly assigned. When a civilian freighter transports trade goods, the tax revenue for the government is equally split into two parts - the export tax and the shipping tax. The export tax should go to the parent government of the population from where the trade goods are picked up while the shipping tax goes to the parent government of the shipping company. Although these are usually the same government, it will be different if the goods are being picked up from a foreign power.
In the current version, both these taxes were being incorrectly assigned to the parent government of the shipping company. This has been fixed for v5.70.
This means that if you have goods available for export and a foreign shipping line picks them up, you will still receive export taxes but not shipping taxes.
Steve
What about import taxes? :D
-
Good to see that Robo-ground combat will be finally fixed. CAN'T WAIT!
-
The problem sounds a bit like the old issue of assigning two fleets to be each others sub-fleet, then order them to incorporate their subfleets; And space folds around the ships, never to be seen again. ;)
Nice change to the missiles, gives a reason to not just use more small missiles.
Though I'd obviously still like a change to fire controls and missile armor. :D
-
Very very interesting. This is definitely going to shift the current missile design strategy for a lot of folks. I am really looking forward to the new release!
Finally an advantage to large missiles ;D
Let's see, a 5 MSP engine would probably mean a missile size of at least 10 or 12. So anything smaller will have a significantly smaller range. Makes a nice tradeoff between ease of shooting down and range.
I'm thinking I'll either accept a lower range (but still significantly better than beams) for size 4 or so missiles, or have fleets with XO racks of size 12 missiles that they fire in a single massive volley and then close to finish off the wounded enemy with beams :).
Also, this might put an end to the terror of precursor AMM in anti-ship mode.
-
Bear in mind that the fuel efficiency paradigm might result in missiles with slightly larger engines and slightly less fuel compared to current designs. Current designs are not directly comparable.
-
You can still spam AMMs, only now the range is shorter.
Given that Precursors have a significant tech advantage in the beginning, don't hold your hopes too high.
-
True, but if their AMM range is 3 million km instead of 30 million, at least you have the possibility of closing to beam range without them completely emptying their magazines on you.
-
You really don't, unfortunately. Beam range and missile range are just such different orders of magnitude...
-
No, but your fighters launching size 3 or 4 missiles from 20m km away won't die to volleys of 51 size 1 missiles!
-
The only way I can imagine size 1 AMMs having the same range as your ASM is if the enemy has a massive tech advantage over you. In which case, they should have more capable missiles. If you don't have enough range, try redesigning your missiles.
-
The AI can use Lagrange Points. I didn't even know that was being implemented. Any way hyperdrives will be implemented?
-
With the Civ's designing their own ships i was wondering if they will be able to handle startings in nebulas, will they be smart enough to add armor to increase their speed?
-Five
-
Ai and Lagrane points is wonderfull. Multi-star systems get finaly more accessible for colonisation. Thank you steve!
Oh say any words on your new test campaign?
-
Yay for LP's. Not having to baby-sit TG's that switch to default/conditional orders and ignore LP's will be a blessing.
-
Oh say any words on your new test campaign?
One of the less eventful so far. Mainly just exploration, resource shortages, a couple of minor encounters. I'll post an AAR at some point, more for ship design examples than for exciting action :)
Steve
-
Thanks for that :) I can see the new engine design system really giving me a headache until I get used to it.
-
regarding the "Production Overview Window"
can we have an auto turn option here? and an additional tab with the event log? less clutter ftw! :P :P
-
Hi Steve,
For the new tug fuel usage formula:
Engine Power Used = ((Ship Size + Towed Size) / Ship Size) x (Current Speed / Max Speed).
Do the tow's engines contribute to CurrentSpeed? In other words, is the formula for MaxCurrentSpeed something other than
MaxCurrentSpeed = ShipSize*MaxSpeed/(ShipSize + TowedSize)?
If the answer is "yes", then I think there's still a problem, since the tug will be paying fuel costs for both its engine power and the tow's engine power. (I'm assuming here that "Max Speed" is the max speed of the tug when it's not towing anything.) If the tow's engines contribute, then I think the formulae should be:
MaxCurrentSpeed = (ShipSize*MaxShipSpeed + TowedSize*MaxTowedSpeed)/(ShipSize+TowedSize)
FuelUsageRate = MaxFuelUsageRate*(CurrentSpeed/MaxCurrentSpeed).
Note that I used "MaxFuelUsageRate to get the units right - the formula you gave is actually a (dimensionless) ratio. This is easy to see if you set TowedSize=0 and CurrentSpeed=MaxSpeed; "Engine Power Used" becomes 1, which is probably not what you're intending :)
John
-
Regarding shore leave and civilian vessels that are intended to remain on-station for years, such as fuel refining stations, terraformers and asteroid mining stations:
Has there been any discussion of this? Is it possible to exempt any civilian ships that have no engines from the shore leave rules? That way, luggables such as engineless fuel miners would not need to be towed back home every few years. Alternatively, we could allow orbital habitats to be set up in orbit around gas giants, which would let us add an R&R facility to our mining stations.
-
Civilan ships don't really suffer the penalty so leaving civ workers to suffer is basically the plan. though I could see crew delivery swaps if you wanted to be realistic.
-
Alternately, could there be an "indefinite" level of crew accommodations? Basically something like orbital habitat level, where it can be assumed that the ship is basically a city itself.
-
Hi Steve,
For the new tug fuel usage formula:
Engine Power Used = ((Ship Size + Towed Size) / Ship Size) x (Current Speed / Max Speed).
Do the tow's engines contribute to CurrentSpeed? In other words, is the formula for MaxCurrentSpeed something other than
MaxCurrentSpeed = ShipSize*MaxSpeed/(ShipSize + TowedSize)?
If the answer is "yes", then I think there's still a problem, [. . . ]
I've seen this same problem the other way around, at least with the current formula. A ship (with an engine) being towed by a tug pays immense fuel costs, presumably because it's traveling faster than its max speed. If tugs are getting fixed to pay appropriate fuel costs, towed ships really need to be addressed as well.
Also, during towing, if the towed ship runs out of fuel, that shouldn't stop the tow, it should just disable that ship's engines (and output a low fuel warning, of course).
-
Updates to Older Posts
The following Morale-related updates apply to older posts in this thread that I have edited. This post is just to highlight the changes for anyone who read those posts before I edited them.
Morale Effect on Surveying
The rate at which a ship generates geological or gravitational survey points is modified by morale
No Life Support
If a ship has no life support remaining, either due to battle damage or maintenance failures, emergency systems will keep the crew alive for a while but within a few days whatever jury-rigged systems the crew manage to create will begin to fail and crew members will start to die. The percentage will vary but on average about 50% of the remaining crew will die during each 5-day update. Any survivors that have been picked up by the ship will also start dying. Instead of the overcrowding modifier, morale is divided by 10.
Undermanning
Morale can also be affected by undermanning. If a ship's crew falls below half its normal complement, morale will be affected. The formula is Morale = Current Morale x ((Current Crew * 2) / Normal Crew)
This could be made more complex by looking at the crew required to run the remaining undamaged systems but I think that adds complexity without a corresponding improvement in gameplay.
As you can imagine, an undermanned ship without life support is not going to be responding to orders very quickly :)
Hmm, possibility of derelict ships.
-
Hmm, possibility of derelict ships.
Yes. I considered the idea of a new type somewhere between a normal ship and a wreck. However, that added potential complexities so I thought this would be a good compromise. You can board and capture a ship like this and then attempt to restore life support.
Steve
-
Well considering that, having a way to get a derelict ship towed or moved into Hangarbay would be nice. I mean if you find a ship like that you most likely send in a squad of Marines which gets evacuated as soon as the ship is "yours". So i imagine in the future we will have a dedicated scraper-tug or small carrier with some troopers on board.
-
Steve, I have two questions, if I may:
Could you have a look at the mineral requirements of the missile designs you posted in the other thread? As commented here (http://aurora2.pentarch.org/index.php/topic,5196.msg53158.html#msg53158), I am afraid something might be off there and it would be a shame if the new version introduced some bug.
Also, will it be possible to transfer survivors/excess crew between ships? The penalties for carrying too much crew can seemingly get quite large. Suppose you have two ships, one carrying a lot of survivors, the other only its standard crew (but a lot of spare berth). It would feel awkward if there was no means to share the survivors between the crews. And it would certainly be very frustrating gaming wise to have one ship break down because of that.
-
So 5.70 is officially 6.00 now eh? Thought that might happen! The list of improvements and changes is way too big for a mere incremental update.
-
Regarding shore leave and civilian vessels that are intended to remain on-station for years, such as fuel refining stations, terraformers and asteroid mining stations:
Has there been any discussion of this? Is it possible to exempt any civilian ships that have no engines from the shore leave rules? That way, luggables such as engineless fuel miners would not need to be towed back home every few years. Alternatively, we could allow orbital habitats to be set up in orbit around gas giants, which would let us add an R&R facility to our mining stations.
I am for crew rotation using luxury liners. Maybe this job could even be outsorced to civvies? This way we could have a playable military station like Babylon 5, which would suffer if anything happens to the supply lines.
Speaking of Babylon 5, will it ever be possible to have a space trading stations? It might act as a floating werehouse for long-range trade or as a marketplace for non-so-friendly races(I am friendly with A and B, but A and B are not friendly to each other. They trade through my station and I get tolls and fines)?
-
Having Space Stations that can self maintain and upgrade components would be a start before that.
I still do not see space stations as a viable option at this stage, compared to a planetary military outpost.
-
Having Space Stations that can self maintain and upgrade components would be a start before that.
I still do not see space stations as a viable option at this stage, compared to a planetary military outpost.
Babylon was orbiting some husky planet. I think you can offset the maintenance failures on a big station by having enough of small maintenance vessels (maintenance facility) with it.
Upgrade of the components would be really nice though. If some components are so modular that we can pre-construct them then why can't we take one out and add another one. Maybe we could have some limited shipyard-capable module for that(rather slow "refit to" and "repair" capability for self and smaller vessels. working only with pre-constructed components that needs to be shipped from somewhere else)?
This rises additional issues though, like transporting of components and resources that would be good to outsource to civvies and reasonably automate(currently conditional orders are rather lacking in versatility) military freighters to do it.
-
Well, if you require a planet or asteroid for the station anyways, which is convenient because that's whats currently coded, the main thing for space stations seems to be a module system, where you can switch out modules.
Near a planet, a station might actually have fabrications to switch that out.
I would really like that, it might even allow to install a weapons module on a civilian freighter at a massive premium in mass, thereby relegating maintenance only to those weapon systems, though that obviously won't turn it into a warship.
Then, a Space station could just be switch like PDC, that's just -50% maintenance clock progression, +50% crew habitation needs, or some such, and it can't have an engine; or rather, I'd prefer it not being able to have a topspeed over a given number, say, 25 kms.
After all, a TN-"Maneuvering Thruster" might not be too bad of an idea.
After two decades, however, the frame of the station would still age, even though the modules were kept fresh; One could however deliver a new frame to incorporate those modules, given that that will be significantly lighter.
Though I personally still lack an understanding for the appeal of such large targets.
-
You can SM mode revamp station designs if you want, currently. Or RP several independent modules orbiting a planet as a single massive station. (IE, Habitats, Defence Systems, etc. as different ships) That kind of makes sense, anyway.
-
Well, the idea was not only about modularity.
Space station would not only require some way to upgrade it (actually upgrade is an extra optional feature). Station would need crew rotation mechanism, like space busses.
We can keep the overhaul requirement though. With enough engeneering(there was a lot in Babylon 5) maintanence failures can be kept at bay for decades. And once in a lifetime a great shipyard would be towed to the station to make capital repairs and an overhaul(with increased overhaul speed).
The idea about hull aging is nice. Perhaps it would be better to have a more viewable aging. I propose following:
There are small meteors in space. The bigger your ship is - the bigger is the probability that it will be hit by one. i.e. great battleship will be hit about once a month, FAC - once a year, Fighter - almost never.
A hit would result in 1 point of damage with the normal damage rules. Active shields(any) would prevent the hit, but shields require fuel.
This will be a good change because it will force player to put more armor on larger ships, even if those are not about to fight. Armor can still be repaired at a shipyard.
The point of the space station stuff is not just a shiny new super-expensive capital ship with no drives. I see it as a long-range diplomacy, espionage and trade outpost. I think Aurora diplomacy should be more rich. There should be more options and more AI surprises about it.
First of all I think that races need to be weary not only of your presence in their systems, but also in systems around their systems. They should also be aware of this - settling too close to your neighbours is a sure way to damage the relationships.
Inter-racial trade should bring more benefits then just an ocasional infrastructure(which is not an issue at the time you will be able to build a Babylon-type station) or some halved tax revenues. Espionage info, advanced technology, info on third races, increased population per capita income, decreased unrest... as long as trade flows...
How do you trade then? civilian freighters do not like to move goods more then 4 jumps away, while your neighbours may not be happy to see your colonies right next to theirs. My answer would be - through space trade hubs - large stations which would not aggravate neighbors, but allow for trade logistics.
I think domestic civilian trade should also be improved. If your planet does not have large deposits of ore any more it does not mean there are no materials left at all. There are small private mines, recycling, private minerals stored... I think those should be available for sale. In unlimited quantities but at progressive prices. The more you buy - the higher price climbs. Interracial civilian trade and periods of not purchasing these goods from the market should bring the prices down.
That is a considerable coding effort, but I think it would be worth it.
An added bonus of the station would be diplomacy and espionage. I think a race should be able to stick several teams on a station, be it own station or not-very-hostile station. those teams would improve relationships with any race that have put their teams on that station;and provide intelligence about any race that is either trading through this station or put some teams on it. I think it would be good additional bonus to regular team use and a good countermeasure to the increased hostilities due to squalor.
-
Diplomacy needs a major overhaul, I would much prefer to have seen some big AI improvements and diplomacy improvements then ship design features. Don't get me wrong Steve does a great job with those improvements, but the game is very one dimensional.
Which is 'blow crap up' I tried to be friends with aliens, but they don't understand personal space. Or they feel that they can conquer me without doing any real recon, such as. I am superior in tech then them and a small conflict over a colony that I already had in my system will not benefit them in the long run.
These type of things are real immersion breakers. I am hoping Steve stop working on the mechanic of space craft and focuses on some real AI or diplomacy changes in the next version. Yeah fuzzy logic sucks to code but even some minor AI improvements may go a huge way to include those WOW! moments. (Wow as in surprise not World of Warcraft)
Example of treaties should be easy enough to code, such as;
The non-movement in a a system already inhabited by a colony of the opposing treaty race with military ships.
The non-ability to create a colony in the opposing treaty system if they already have a colony
The non-ability to create a colony on the same planet ( a more trusting option )
The share map treaty (not just new systems)
The request military aid to 'said' system treaty.
These should be simple if then type coding ability to enhance Cooperative AI.
-
Diplomacy improvements would be really nice. It would be good if space races had their agendas and priorities and strategic plans and if wars were fought over some goals, not just to blast an enemy into space, but to actually gain/protect/secure something.
-
These diplomacy things you speak of: that is what multi-human controlled factions are for.
-
That doesn't mean it wouldn't be worthwhile to make NPRs a little smarter and diplomacy a little deeper.
-
I would be pleased with the implementation of sovereign space. Friendly factions avoid it unless they request a right of passage agreement.
-
I will take a look at diplomacy at some point as I haven't touched it in years. Not for v6.00 though. My focus at the moment is on testing and getting the new version out.
Steve
-
Steve, would you post a quick table for the power/fuel consumption modifier tech levels? I'm working on converting my analysis workbook, since v6 isn't out yet I don't have the database to pull an extract from. With this data I can update my ship engine and missile builder sheets.
Thanks
Charlie
-
Steve, would you post a quick table for the power/fuel consumption modifier tech levels? I'm working on converting my analysis workbook, since v6 isn't out yet I don't have the database to pull an extract from. With this data I can update my ship engine and missile builder sheets.
Thanks
Charlie
Power is the same as now. Fuel is as follows:
Fuel Consumption: 1.0 Litres per Engine Power Hour
Fuel Consumption: 0.9 Litres per Engine Power Hour
Fuel Consumption: 0.8 Litres per Engine Power Hour
Fuel Consumption: 0.7 Litres per Engine Power Hour
Fuel Consumption: 0.6 Litres per Engine Power Hour
Fuel Consumption: 0.5 Litres per Engine Power Hour
Fuel Consumption: 0.4 Litres per Engine Power Hour
Fuel Consumption: 0.3 Litres per Engine Power Hour
Fuel Consumption: 0.25 Litres per Engine Power Hour
Fuel Consumption: 0.2 Litres per Engine Power Hour
Fuel Consumption: 0.16 Litres per Engine Power Hour
Fuel Consumption: 0.125 Litres per Engine Power Hour
Fuel Consumption: 0.1 Litres per Engine Power Hour
The various fuel consumption formulae are in the patch notes thread.
Steve
-
I was actually asking for this:
"Power / Fuel Consumption Modifiers: There are two new tech lines to research, called Max Engine Power Modifier and Min Engine Power Modifier"
I'm really just looking for the break points.
Charlie
-
I was actually asking for this:
"Power / Fuel Consumption Modifiers: There are two new tech lines to research, called Max Engine Power Modifier and Min Engine Power Modifier"
I'm really just looking for the break points.
Charlie
Ah OK
Maximum Engine Power Modifier x1
Maximum Engine Power Modifier x1.25
Maximum Engine Power Modifier x1.5
Maximum Engine Power Modifier x1.75
Maximum Engine Power Modifier x2
Maximum Engine Power Modifier x2.5
Maximum Engine Power Modifier x3
Minimum Engine Power Modifier x0.5
Minimum Engine Power Modifier x0.4
Minimum Engine Power Modifier x0.3
Minimum Engine Power Modifier x0.25
Minimum Engine Power Modifier x0.2
Minimum Engine Power Modifier x0.15
Minimum Engine Power Modifier x0.1
Steve
-
Thank You Sir, Exactly what I was looking for.
-
Steve by:
Maximum Engine Power Modifier x1
Maximum Engine Power Modifier x1.25
Maximum Engine Power Modifier x1.5
Maximum Engine Power Modifier x1.75
Maximum Engine Power Modifier x2
Maximum Engine Power Modifier x2.5
Maximum Engine Power Modifier x3
do you mean:
Maximum Engine Power Modifier +100%/fuel modifier x4
Maximum Engine Power Modifier +125%/fuel modifier x5.66
Maximum Engine Power Modifier +150%/fuel modifier x8
Maximum Engine Power Modifier +175%/fuel modifier x11.31
Maximum Engine Power Modifier +200%/fuel modifier x16
Maximum Engine Power Modifier +250%/fuel modifier x32
Maximum Engine Power Modifier +300%/fuel modifier x64
With these values I can come up with the same figures you have on the sample missile engines.
I do run into issues trying to reverse engineer your Crusade missiles though. From what I can determine it appears that the int() function has been dropped from the missile engine modifier calculation and the /4 has been dropped from the Fuel Efficiency Modifier.
I’m still not matching your missile ranges, but I suspect that has to do with the difference between VB6’s calculations and Excel’s.
What are the missile engine designs for both the Gladius ASM and the Dagger AMM. Plus what engine tech, fuel consumption tech, and Max Engine Power Modifier tech were being used. That will tell me a lot about what I’m doing from with my modeling.
Charlie
-
Steve by:
Maximum Engine Power Modifier x1
Maximum Engine Power Modifier x1.25
Maximum Engine Power Modifier x1.5
Maximum Engine Power Modifier x1.75
Maximum Engine Power Modifier x2
Maximum Engine Power Modifier x2.5
Maximum Engine Power Modifier x3
do you mean:
Maximum Engine Power Modifier +100%/fuel modifier x4
Maximum Engine Power Modifier +125%/fuel modifier x5.66
Maximum Engine Power Modifier +150%/fuel modifier x8
Maximum Engine Power Modifier +175%/fuel modifier x11.31
Maximum Engine Power Modifier +200%/fuel modifier x16
Maximum Engine Power Modifier +250%/fuel modifier x32
Maximum Engine Power Modifier +300%/fuel modifier x64
It appears in the Create Research Project dropdown as:
Maximum Engine Power Modifier +0% Fuel Consumption per EPH +0%
Maximum Engine Power Modifier +25% Fuel Consumption per EPH +41%
Maximum Engine Power Modifier +50% Fuel Consumption per EPH +100%
Maximum Engine Power Modifier +75% Fuel Consumption per EPH +183%
Maximum Engine Power Modifier +100% Fuel Consumption per EPH +300%
Maximum Engine Power Modifier +150% Fuel Consumption per EPH +700%
Maximum Engine Power Modifier +200% Fuel Consumption per EPH +1500%
Also, Missile engines can use up to double the current tech in terms of power boost, so 1.75 tech allows 3.50 boost for missile engines, which would be the following:
Maximum Engine Power Modifier +250% Fuel Consumption per EPH +3100%
I do run into issues trying to reverse engineer your Crusade missiles though. From what I can determine it appears that the int() function has been dropped from the missile engine modifier calculation and the /4 has been dropped from the Fuel Efficiency Modifier.
I’m still not matching your missile ranges, but I suspect that has to do with the difference between VB6’s calculations and Excel’s.
What are the missile engine designs for both the Gladius ASM and the Dagger AMM. Plus what engine tech, fuel consumption tech, and Max Engine Power Modifier tech were being used. That will tell me a lot about what I’m doing from with my modeling.
Engine tech is Ion. Max Engine Power Modifier was 1.75, which is 3.50 for missiles. I think fuel consumption is 0.6, although I'm not sure if I have researched that since the design so it might have been 0.7.
Gladius has 1.8 MSP warhead, 0.2 Fuel, 0.105 reactor, 0.395 thermal sensor, 2.5 engine. Engine has 5.25 Engine Power and Fuel Use Per Hour = 161.83 Litres
Dagger has 0.2 MSP warhead, 0.01 Fuel, 0.09 agility, 0.7 engine. Engine has 1.47 Engine Power and Fuel Use Per Hour = 108.1 Litres
Don't forget to account for fuel consumption changes based on missile engine size: +282% for Dagger and +60% for Gladius.
Steve
-
I guessed the warhead correctly, but I didn't know about the thermal sensor. I kept trying too make a size 3 engine fit the speed and range and it just wasn't working.
Thanks for the feedback.
-
q:
how crew morale, bert capacity and life support stuff is handled for NPR/Precursor/Spoiler1/Spoiler2?
is it just abstracted away?
-
Steve,
Is it too late to request a change to missile engine design?
Like allowing more than single point precision? It would help with mixing with the existing components that are designed at 4 point precision.
This next one is probably a bigger issue to impliment. Add a total power modifier for installations of multiple engines. Some value increase for "linking" multiples. As it stands, the use of say a .8msp engine vs 8 .1msp engines have the same useful power but the smaller engines burn between 4-5 times the fuel as the larger one.
As has been noted the new fuel consumption means that missiles can be segnificantly longer ranged as well a faster per engine tech that previous game versions. I'd like to suggest changing the Thermal and EM sensor base table values to match the Active Grav Sensor base table values. this would not match the range extention that missiles have recieved, but it would help in reducing the hull spaces need for detection and missile fire control suites.
-
Steve,
Is it too late to request a change to missile engine design?
Like allowing more than single point precision? It would help with mixing with the existing components that are designed at 4 point precision.
This next one is probably a bigger issue to impliment. Add a total power modifier for installations of multiple engines. Some value increase for "linking" multiples. As it stands, the use of say a .8msp engine vs 8 .1msp engines have the same useful power but the smaller engines burn between 4-5 times the fuel as the larger one.
Just wanted to second this. I love the depth that comes from not having a 'right' design for a particular application. Maybe multiple engines could give an increased agility? 4 gimballed thrusters on the back of a missile would conceivably make it somewhat nimbler than a single equivalent-sized one.
-
Our missiles don't penetrate anyway, so we fill 'em with paint. Makes the Germans mad.
-
I still want a way to individually enable\disable engines, or at least "link" engines in the design and then enable\disable groups. With the fuel changes, it might make sense to attach a high-efficiency primary drive then several high-power military drives for combat maneuvering.
-
This next one is probably a bigger issue to impliment. Add a total power modifier for installations of multiple engines. Some value increase for "linking" multiples. As it stands, the use of say a .8msp engine vs 8 .1msp engines have the same useful power but the smaller engines burn between 4-5 times the fuel as the larger one.
This already happens. There is a fuel-efficiency penalty for smaller engines.
-
This already happens. There is a fuel-efficiency penalty for smaller engines.
I think that's his problem. He is wondering why you'd ever use two size X engines when you could just use a size 2X engine and get the same power for less fuel consumption.
-
I'd use the smaller engines for smaller ships or to squeeze a *little* more speed out of an extra HS.
-
While true, there is no reason to not always use the largest engine you can conceivable fit.
I suppose a minor maneuvering bonus for having multiple exhausts might be a way to counteract that.
-
While true, there is no reason to not always use the largest engine you can conceivable fit.
I suppose a minor maneuvering bonus for having multiple exhausts might be a way to counteract that.
I guess the other issue is leaving you exposed to single component loss shutting down your ship. Still my plan was exactly to have the minimum possible engines to maximise their efficiency.
-
I think that's his problem. He is wondering why you'd ever use two size X engines when you could just use a size 2X engine and get the same power for less fuel consumption.
Mainly because different ships use different amounts of engines. So if you design a size 20 engine, you can only use it on ships where the total engine power fits neatly in a multiple of size 20. Smaller engines make it easier to use the same engine on different designs. Alo large engines are more expensive in research terms so making one large engine for every design is very expensive.
Steve
-
I think that's his problem. He is wondering why you'd ever use two size X engines when you could just use a size 2X engine and get the same power for less fuel consumption.
Actually, the multiple smaller engines have a significantly higher fuel consumption rate not lower for the same propulsion output. What I'm after is a benefit to using multiple engines where a larger single produces the same power for the same use of hull spaces.
-
The reason is the RP cost of designing custom engines for every missile.
I do get the impression that the fuel cost impact will be high enough to justify that RP cost for every viable missile design though.
-
Actually, the multiple smaller engines have a significantly higher fuel consumption rate not lower for the same propulsion output. What I'm after is a benefit to using multiple engines where a larger single produces the same power for the same use of hull spaces.
If what you're saying is "I want 10x size-1 engines of a given power boost level to have the same fuel consumption rate as 1x size-10 engine" (i.e the old behavior where fuel consumption was proportional to power output and independent of engine size), then I think this is an intentional trade-off that Steve is putting in the game. With the new mechanics, you have a choice between creating a 1-off engine design (spending RP and introducing a single-point-of-failure) for each total power output level you want or using multiple instances of a standard design (which will suck more fuel).
If this is not what you're saying then I'm confused as to what it is that you are asking for :)
John
-
If what you're saying is "I want 10x size-1 engines of a given power boost level to have the same fuel consumption rate as 1x size-10 engine" (i.e the old behavior where fuel consumption was proportional to power output and independent of engine size), then I think this is an intentional trade-off that Steve is putting in the game. With the new mechanics, you have a choice between creating a 1-off engine design (spending RP and introducing a single-point-of-failure) for each total power output level you want or using multiple instances of a standard design (which will suck more fuel).
If this is not what you're saying then I'm confused as to what it is that you are asking for :)
John
Not a change to the fuel consumption, a boost to the propulsion power for multi engine installations. Maybe something along the lines of 5% boost per additional engine. That would be a possible benefit for using the multiple smaller engines that have a segnificantly increased fuel rate.
-
One benefit of the multiple smaller engines on a warship is redundancy. With one big engine and a lucky hit you would be completely dead in the water. Similar issue with maintenance. One big engine requires a huge amount of supplies be on board to keep the engine running. If you have 10 small engines with the same power your maximum maintenance supply requirement would be way less.
-
I haven't been real clear on the engine suggestion, mainly because I really hadn't worked it through on my own before posting.
This is for missiles only. As things stand(v6.0) size 1 missile with 1 .7msp engine or one with 7 .1msp engines are the same speed and cost but the one with the 7 engines has roughly 26% the range of single engine missile with no other difference.
What I'm proposing is to add a new techline for missile bodies. Call it whatever, advanced missile bus maybe, but as each tech level is reached a new speed bonus is added per engine. Start with 1% per engine above the first.
Example using Steve's Dagger AMM since the stat's are handy:
Currently the tech is Ion engines for a base of .6 per msp, fuel consumption rate .6(x5 for missiles), max power modifier of 350%/fuel multiplier 22.92(or 2292%) Engine size is .7 for a fuel multiplier of 3.83 and a fuel use per hour of 387.08 and speed 29,400kps. Added agility of .09msp for 2.88 which rounds the maneuver rating to 13 (10+ added agility) and .01msp to fuel for 25 liters giving a range of around 6.8m km. (numbers from my missile design sheet and differ from what the program calc’s slightly)
If we only replace the single .7msp engine with 7 .1 msp engines we get exactly the same speed but only have a range of a little over 1.8m km, fuel use per hour of 208.88, for no gain.
Now if we have a missile that can harmonize/tune/whatever those same 7 engines for a better speed for the same fuel cost the numbers could look like this:
Boost speed vs 1,000 3,000 5,000 10,000
1% bonus – 31,164kps 405.1% 135% 81% 40.5%
2% bonus – 32,928kps 428.1% 142.7% 85.6% 42.8%
3% bonus – 34,692kps 451% 150.3% 90.2% 45.1%
etc etc etc
To keep this restricted to missiles could be explained in any number of ways. Or Steve could add this bonus to ship design as well, though that was not my intention.
Steve, one last thing…please take a look the calc that is used for the missile design screen for the 3k km/s to hit %, I’m getting 127.4% and your screenshot is showing 117%. For the other 3 ranges I’m getting exactly the same values as the screenshot for the Dagger AMM.
Something to think about.
Charlie
-
I was told that IRL, there were two reasons for multiple engines which _might_ apply.
1. Redundancy. Effective protection from maintenance issues, but when it comes to taking damage, many times, you'll lose them all.
2, You just cannot build one big one or smaller ones are more convenient for maintenance/access.
-
I think this is an intentional trade-off that Steve is putting in the game. With the new mechanics, you have a choice between creating a 1-off engine design (spending RP and introducing a single-point-of-failure) for each total power output level you want or using multiple instances of a standard design (which will suck more fuel).
Yes, that was my intention.
Steve
-
If we only replace the single .7msp engine with 7 .1 msp engines we get exactly the same speed but only have a range of a little over 1.8m km, fuel use per hour of 208.88, for no gain.
What I was aiming for with the different fuel consumption rates for different engine sizes was to avoid someone simply designing a cheap 0.1 MSP engine and using whatever number they need in every design without penalty. Players need to decide whether to go for a small cheap (in RP terms) engine that could be used on all missiles without any prior design considerations, or spend the time and money to design more effective engines for each missile. This should add more variety to missile design.
Steve
-
Understood.
Can we at least get 4 decimal point missile engine sizes back? It makes design fine adjustments between the various components easier if all component sizes go the the same decimal precision.
-
One thing that might be very helpful in 6.0 with the increase in fuel usage is cruising speeds. This would make the power required for a given speed be something other than linear. This is the way real ships work. Above a certain point, power requirements go way up. This has the advantage of giving the ships longer range at low speeds. I haven't really worked this out, and I don't want to see it in 6.0. Maybe 6.1.
-
Understood.
Can we at least get 4 decimal point missile engine sizes back? It makes design fine adjustments between the various components easier if all component sizes go the the same decimal precision.
Seconded. Down with artificial discretization!! Up with fine-grain control!! :)
John
-
Given the general size of Commercial class vessels, especially the government owned cargovessels, researching a single humongous Civilian engine per tech level and just use that single thing for every freighter, colony, construction and troop ship you've got works, even if it's a 5000 ton monstrosity. Okay, hullsize 100 is rather expensive in research, but if you can handle it, the extra efficiency should allow you to get away with otherwise laughably small fuel cells. This is especially handy given that Shipping Lines are nowadays handling their own research and development of ship classes, so no need to worry about keeping ships small enough that they can keep buying.
For Military ships, the redundancy a smaller engine allows is however still rather needed, especially given how often they are going to be shot at. Large engines IIRC are more resilient to damage, but they would also go up in much more spectacular explosions when they blow, while a smaller engine is easier to destroy once you get past the armour belt, but the (chain) explosion would be a lot easier to keep confined.
-
Given the general size of Commercial class vessels, especially the government owned cargovessels, researching a single humongous Civilian engine per tech level and just use that single thing for every freighter, colony, construction and troop ship you've got works, even if it's a 5000 ton monstrosity. Okay, hullsize 100 is rather expensive in research, but if you can handle it, the extra efficiency should allow you to get away with otherwise laughably small fuel cells. This is especially handy given that Shipping Lines are nowadays handling their own research and development of ship classes, so no need to worry about keeping ships small enough that they can keep buying.
For Military ships, the redundancy a smaller engine allows is however still rather needed, especially given how often they are going to be shot at. Large engines IIRC are more resilient to damage, but they would also go up in much more spectacular explosions when they blow, while a smaller engine is easier to destroy once you get past the armour belt, but the (chain) explosion would be a lot easier to keep confined.
Just a point of order. Per Steve's posts related to the new Engine Design specification, the largest engine that can be designed and built is 50hs not 100hs. That's still twice the size of current civilian engines.
-
Steve another query, what are the cost modifiers for thermal reduction and hyper drives?
-
Just a point of order. Per Steve's posts related to the new Engine Design specification, the largest engine that can be designed and built is 50hs not 100hs. That's still twice the size of current civilian engines.
At least given my playstyle, I'll probably be using 2500 ton engines on everything except parasite craft and possibly my smallest escort/scout craft; I usually go for about 1/3rd engine by weight, and that means 7500 tons (a destroyer by my standards) for a single engine craft or 15000 tons (heavy cruiser) for double engines. It does mean that losing an engine is a massive blow, but I think it's worth it for the 50% fuel reduction. It'll be interesting to see how much a 2500 ton engine costs to research, though. It also means that I might end up classifying ships by number of engines (IE 1 engine is a destroyer, 2 engines is a cruiser, 3 engines is a heavy cruiser, etc). Which actually sounds kind of fun.
-
Steve another query, what are the cost modifiers for thermal reduction and hyper drives?
At the moment hyper drives aren't in 6.00. I just haven't got around to adding them back into engine design.
For thermal reduction, cost modifiers are as follows:
75% 1.25x
50% 1.5x
35% 1.75x
25% 2x
16% 2.25x
12% 2.5x
8% 2.75x
6% 3x
4% 3.25x
3% 3.5x
2% 3.75x
1% 4x
-
At the moment hyper drives aren't in 6.00. I just haven't got around to adding them back into engine design.
For thermal reduction, cost modifiers are as follows:
75% 1.25x
50% 1.5x
35% 1.75x
25% 2x
16% 2.25x
12% 2.5x
8% 2.75x
6% 3x
4% 3.25x
3% 3.5x
2% 3.75x
1% 4x
Thank You. Just to confirm, base engine cost is engine output. At the very least that is what has worked when I reverse engineer the missile designs posted.
Hyperdrives not being available doesn't break my heart since I don't use them.
Charlie
-
Hyperdrives not being available doesn't break my heart since I don't use them.
To riff on this: Hyperdrive isn't very useful from a strategic point of view if the civies don't use it when planning their routes. So before it gets turned on, I would recommend implementing route-planning code that automatically turns hyperdrive on/off when the boundary is crossed and that includes hyperdrive speed in time estimates.
I see two ways to implement the routine-planning:
1) When the route is being calculated, insert waypoints at or outside the hyper boundary that turns the engine on or off. The problem with this is binary companions, which move. For a single trip you could simply move the waypoint out far enough that you wouldn't run into the boundary, but for permanent, cycling routes that wouldn't work. Another thing that could be done to work around this problem would be to introduce a new type of waypoint whose location was calculated on the fly according to the position of the companion. Basically, it would draw a line from current position to companion, then back up along the line by the hyperdrive distance. (It would then need to check if this point was inside the limit of any other bodies - if so it would need to use the boundary point for the other body instead.)
2) During movement, if a ship starts outside the hyperdrive boundary two things happen: A) If hyperdrive is off, turn it on. B) If movement impulse puts ship inside hyper limit, turn hyperdrive off. Not sure if this would be a big performance impact or not.
John
-
The function of Hyperdrive won't be as critical now that civilian path generation has been updated to make use of LP navigation routes.
On a similar note, the creation of LP points: There are many occasions with Binary, Trinary and Quadrinary systems where the prerequisite gas giants that could produce the two navigable LP for cross system navigation do not exist. Why is it that the stars themselves do not produce the LP? If the star is in orbit of the primary would the 2nd, 3rd and 4th stars not have the required mass to create a gravity well sufficient to make an LP that can be navigated?
-
The function of Hyperdrive won't be as critical now that civilian path generation has been updated to make use of LP navigation routes.
For those systems with LP in both primary and companion....
Even with hyperdrive, it's still a pain in the patootie to colonize (or originate in) a companion system that's a significant distance away from the primary.
On a similar note, the creation of LP points: There are many occasions with Binary, Trinary and Quadrinary systems where the prerequisite gas giants that could produce the two navigable LP for cross system navigation do not exist. Why is it that the stars themselves do not produce the LP? If the star is in orbit of the primary would the 2nd, 3rd and 4th stars not have the required mass to create a gravity well sufficient to make an LP that can be navigated?
This would only be useful in trinary or quadrinary systems where two of the companions are close together. Since LP are at +/- 60 degrees, they form an equilateral triangle with the two generating bodies and transiting to the LP puts you just as far away from a binary companion as the primary is. The place this would be a benefit would be when the 3rd or 4th star is in a tight orbit around the companion (at which point your 1st comment kicks in). I assume this is what you meant by "the prerequisite gas giants ... don't exist".
John
-
Correct. I know that star created LP locations might not be a benefit in many situations but in an instance like you are noting, where a companion star is in a close orbit and creates a LP in close range of the outlying stars, would be very useful.
-
I really think Sorium mining should be made easier and be explained more clearly. It's strange that Sorium Harvesters convert their collected Sorium directly into fuel while asteroid miners collect their minerals on the colony they're mining on. The options in the Task Group command window don't seem to align correctly, either. I get interrupting messages every time the harvesters are above 90% fuel, but there's no IF condition for "fuel tanks at or above 90%. " I just have to deal with the time stopping earlier than normal so it can tell me the harvesters are nearly full. I don't care about when they're nearly full, since their condition to drop their fuel off is set for "fuel tanks full!"
Why shouldn't there be IF conditions for fuel levels at every 10% mark? It goes up to 50% and stops. There should be IF conditions for "at or below 10% fuel," "at or below 20% fuel," and so on all the way up to 90%, and then a "fuel tanks full" condition as well.
The THEN conditions for fuel unloading and Sorium harvesting in particular should be made better. I can drop 90% of my fuel at the nearest colony, or I can drop all my fuel at "colony" (not "nearest colony") and move to nearest Sorium source. Why can't I "unload 90% fuel at nearest colony and move to nearest Sorium source"? Why can't I specify the colony I want them to drop the fuel off to? In my current game, harvesting Saturn is proving to be a pain, since my harvester ships don't want to drop their fuel off automatically at the nearby colony of Titan.
I think there should be a statement somewhere in the class design window that says something to the effect of "harvested Sorium is directly added to fuel tanks. " Perhaps have a similar statement for asteroid miners, "harvested minerals are stockpiled on the colony being mined. " If the message is prominent enough, like in a new Notes section or something, it should hopefully prevent anyone from putting cargo holds on their miners because they think they need them.
I've also been having problems with the Join command for Task Groups. I tell TG-1 to Join TG-2. Then I reopen the F12 Task Group window and get the warning message that TG-1 no longer exists, and it shows me the ships that are in TG-2. But if I want to delete TG-1, I need to be very careful. If I hit the delete button with the ships from TG-2 being shown (mistakenly) in the TG-1 menu (which is the Task Group I'm currently viewing in the Task Group window), the ships in TG-2 will be deleted and removed as well! I have to select an empty Task Group, then select TG-1 and hit the Delete button. That way no ships are accidentally deleted/
-
"I've also been having problems with the Join command for Task Groups. I tell TG-1 to Join TG-2. Then I reopen the F12 Task Group window and get the warning message that TG-1 no longer exists, and it shows me the ships that are in TG-2." - did you close and reopen f12, or just switch away from it. it doesn't refresh the display(which it should) when a taskforce is deleted.
On sorium harvesters, the best thing to do is to have a tanker ferry fuel back from the harvester rather than trying to get the harvester to go somewhere and dump off fuel.
-
Are you going to look at laser 'heads again, what with all the missile changes? If missiles are going to pricier to use, it'd be nice for more of them to actually complete their goal of using explodey, gooey plasma against a target.
-
I can't help but wonder how this new morale stuff works with PDC's. Once they're built (in deep space!) you can't really haul them back for shore leave. Granted a posting on a forward Fighter base would suck, but limit crew rotations and it isn't all that bad. The only way I can think of to give the PDC "Shore leave" is to haul an orbital habitat out to them, fill it with 10k colonists and let it sit for a bit. . . In Gunkanian Imperium Red-Light district comes to you!
-
So far my personal observation is that PDC moral simply doesn't factor in deployment time, but lets the 'time away' harmlessly run up the clock just like NPR maintenance times.
At least, that's what the PDCs on Earth in my 6.0 test game appear to be doing. Three years on the clock despite being located on Earth, but moral is still 100%.
So far I like the new missile changes. At the very least they make geo-survey probes much more feasible. I went with a conventional start and played Nasa with early robotic missions to the asteroid belt using conventinional-tech geo-survey missile/buoys fueled for a 1 billion km range. Sure they had a dinky 100 km/s top speed, but the asteroids and dwarf planets couldn't run away.
-
I can't help but wonder how this new morale stuff works with PDC's. Once they're built (in deep space!) you can't really haul them back for shore leave. Granted a posting on a forward Fighter base would suck, but limit crew rotations and it isn't all that bad. The only way I can think of to give the PDC "Shore leave" is to haul an orbital habitat out to them, fill it with 10k colonists and let it sit for a bit. . . In Gunkanian Imperium Red-Light district comes to you!
If you want to role play it, have a crew ship visit the PDC every once in a while.
-
I couldn't tell from the other posts but do orbital habitats require shore leave? They have enough colonist on them to qualify as a shore leave option it seems so would that count for them?
-
I don't believe they do. A design I hashed together in my initial test campaign had some engines, cryostorage, and an orbital habitat intended to be a mobile shore leave point for fleet trains, but it didn't seem to require leave itself. Might be wrong, I didn't play around too much; too busy trying to figure out how to into missiles.
-
Very silly question, but I couldn't find an answer by searching for it:
Have command modules been removed in 6.00?
I was playing with a test game, busy granting tech to my civilization and noticed that I never unlocked Command Modules, even when most other internal components were researched.
-
From what I have seen the crew quarters tech are no longer there. Instead they are all already available and when you make the ship and adjust the deployment time it adds the modules for you. I haven't tried a conventional start yet so can't say for sure if it is true there as well.
-
Very silly question, but I couldn't find an answer by searching for it:
Have command modules been removed in 6.00?
I was playing with a test game, busy granting tech to my civilization and noticed that I never unlocked Command Modules, even when most other internal components were researched.
There should be a new tiny crew quarters to replace the comman module
Steve
-
Yes, there are:
Crew Quarters, 1000 RP
Crew Quarters - Small, 1000 RP
Crew Quarters - Tiny, 2000 RP
which, imho, is more logical. Just like Bridge or the Small/Standard Cargo Holds, you don't need to research them even with conventional start.
-
Question- was research sharing fixed? Or do you still need to route your salvage ships around tiny colonies to avoid accidentally being stuck researching awesome tech with just one lab?
(Or is this as-designed?)
-
I don't remember Steve talking about this, but engineless TGs now remain motionless even when doing Taskforce Exercises. It used to be that Orbital Weapon Platforms and Satellites "drifted" in space since they had a velocity of 1km/s but no longer. Which is a good thing as you can actually get their TF training to 100%.
-
I don't remember anything about changes to the research all button, but there is one. It allows you to research up to a designated amount within a single field (ie propulsion or sensors) It was on my wish list for quite a while and I already love it.
Thanks Steve, the little additions like this are part of what makes the game so much fun.
Brian
-
I am still trying to understand the Design process for the Engines for the ships and Vessels and the amount of full time for the vessels. ??? :o ??? I'm trying to modify what's available by removing tech I don't need and picking up tech I will and then making those changes to the Engines and I am scratching my Head going what the #@#$ is going on. I guess I am an idiot who liked it less complicated then what's now here....
-
It did get quite a bit more complicated. My rule of thumb is to design a max size engine, crank up its power, then build a ship big enough to fit around it. The specifics don't matter as long as it goes places and fires stuff.
-
Keep excess Q is a great option, but can it work for all ships the way size in Tons works?
-
I have a question for those more knowledgeable about 6.00 than me (meaning most everyone), in the changelog Steve mentioned adding a Warhammer 40k theme for commander and ship names (as empire and chaos). I have found the commander naming theme but not the ship names. Are they implemented?
-
I have a question for those more knowledgeable about 6.00 than me (meaning most everyone), in the changelog Steve mentioned adding a Warhammer 40k theme for commander and ship names (as empire and chaos). I have found the commander naming theme but not the ship names. Are they implemented?
Looking at the database shows only a name theme.
-
Yeah, it's ship names for a specific class, not names for multiple classes.
-
Keep excess Q is a great option, but can it work for all ships the way size in Tons works?
I was going to do it that way but there are some issues. If you build a carrier with spare quarters for flight crews, you could accidently update it when scrolling through the list of classes (if the setting is Global). The way it is implemented you can effectively lock some classes from being updated in that way.
Steve
-
Yeah, it's ship names for a specific class, not names for multiple classes.
Aaah it's that. My bad I thought it will be a list of names for classes themselves. Not for ships. Alright that's good to know.
-
I was going to do it that way but there are some issues. If you build a carrier with spare quarters for flight crews, you could accidently update it when scrolling through the list of classes (if the setting is Global). The way it is implemented you can effectively lock some classes from being updated in that way.
Steve
One way around that would be to allow the player to input a desired (minimum) number of spare beds the same way we can input intended deployment time.
Another option that would probably be gratefully received would be a checkbox that lets you tell the design window to automatically assign spare beds for the designated parasite complement.
And while on the subject of parasites and ordnance, if you design a ship, designate an ordnance loadout, and then remove tubes/mags, it will take on the designated loadout when it is built (possibly also when reloading, though I haven't checked). It will obligingly show a negative available magazine space, and the task force window will show the magazines to be over 100 % full, but it doesn't otherwise complain.
-
I don't believe they do. A design I hashed together in my initial test campaign had some engines, cryostorage, and an orbital habitat intended to be a mobile shore leave point for fleet trains, but it didn't seem to require leave itself. Might be wrong, I didn't play around too much; too busy trying to figure out how to into missiles.
Unless I'm doing something wrong, ships with orbital habitats still require shore leave, unfortunately. I built a 400k ship with an orbital habitat and designed it for 1 month deployments, intending it to cover jump points, but it still has morale drops in the second or third month.
-
Well that's your problem, you can't orbit/have a colony on a jumpoint.
Orbital habs only add population capacity to colonies, they don't function as independent space stations unfortunately
-
Well that's your problem, you can't orbit/have a colony on a jumpoint.
Orbital habs only add population capacity to colonies, they don't function as independent space stations unfortunately
Ah. So much for that idea. Thanks for the feedback. I have a further question on this, but it should probably be in The Academy, so I'll post it there.
-
Asteroid miners seem to have a new lease on life, especially in conventional starts with the new fuel rules.
-
There needs to be some new conditional orders and move orders included for 6.00 since crew morale is in for micromanagement reasons
Condition:
If Morale below 100% return to colony for shore leave (once complete it then logs it)
If Morale below 75% return to colony for shore leave
If Morale below 50% return to colony for shore leave
Move order (like overhaul)
Go to planet for shore leave (once complete then moves onto next task)
--------------------------------------------------------------
While we are at it a Conditional order of
If Fuel is less then 50% and Supply less then 20% (etc etc as we now have once less conditional statement based on above)
Also a Refuel and Resupply move order or conditional order, to save time instead of plotting two.
-
You could just go one step further and make it be 'If (fuel =< 50%, supply =< 20%, morale =< 90%) {Refuel, Resupply, and wait for (months necessary) at nearest colony}', which would let some of the other conditionals be useful.
-
Well that's your problem, you can't orbit/have a colony on a jumpoint.
Orbital habs only add population capacity to colonies, they don't function as independent space stations unfortunately
I really wish this would be changed, or that steve adds in independent space stations, so we could have trade stations in remote sectors without planets and such
-
I really wish this would be changed, or that steve adds in independent space stations, so we could have trade stations in remote sectors without planets and such
Just some background on one of the reasons for Steve not having changed this quickly. My recollection is that a problem is that you can think of two types of man-made "counters" in aurora: populations (which are bound to bodies) and TG (which hold ships). The problem is that a lot of the things that people want to do with deep space bases are functions of populations. Because a population must have an associated body (otherwise lots of things go wrong in lots of places), it would be VERY difficult to change the code so that one could designate a deep-space ship as a population. So the best Steve is likely to be able to do is have TG containing "base" ships that never need to land, rather than full-blown populations.
Caveat: All of this is based on a vague recollection of something Steve said a year or two ago.
John
-
ON THE TOPIC OF THE NEW FIGHTER BONUS:
Boy, wouldn't that be something if the bonus also applied to missile evasion? As in, boy, that could sure make beam fighters awfully feasible...
-
Will version 6. 2 require a re-start of games?
-
Will version 6. 2 require a re-start of games?
Yes. Any time the first or second digit of the version number changes, you have to re-start. (Going from 5.55 to 5.60 does, going from 5.55 to 5.56 does not.)
-
Either the main version number (left of decimal) or the first decimal to the right means that the database as well as the program .exe file are replaced. If the new version is just a bump of the second decimal only the .exe file is replaced.
-
Heh, liking the idea of the new recreation modules.
Uusually, in aurora, you have to find the party, but IN SOVIET AURORA the party fin-*is shot*
-
This also means you no longer have to haul a couple of habitat modules around so you can get your ships time off on the frontline even when there are no even vaguely inhabitable planets around for several jumps. It also means that black holes and nebulae aren't going to be as big a barrier either.
-
Doesn't this change mostly negate the entire crew morale change? Now you just take one extra ship around per sector with fleet and you don't have to worry about it.
-
Not that I'm complaining, per se, no-one is going to force me to build them, it just seems odd to me.
-
Doesn't this change mostly negate the entire crew morale change? Now you just take one extra ship around per sector with fleet and you don't have to worry about it.
Yes, I am a little concerned about that. However, this is going to be a very large and slow ship (120,000 tons plus). They are intended to visit bases and PDCs in out of the way places. It is still much cheaper to create a small colony as a base. For units deployed at jump points, they would be very much in harm's way. Interested to hear other opinions.
Steve
-
I like the idea as it allows PDC's and deep-space stations to operate effectively.
One potential way of limiting it, have each recreation module only able to handle a certain number of crew, while an actual colony has no such limitation.
Also please add a "conduct shoreleave" order that will keep a taskgroup at the colony until all ships have completed shoreleave, and a "conduct shoreleave and overhaul" order that will keep them at a colony until both shoreleave and overhauls are completed for all ships in the taskgroup.
-
Casino barges and other portable R&R facilities that assist crewmen in spending their pay far from home sounds pretty logical. Further, at 2,000+ BP each these luxuries are too expensive to deploy everywhere. I don't see these ships cheapening the morale rules. Except for those players who build and deploy fleets of dreadnoughts each more expensive than the recreation ship would be.
What does seem odd is that a tiny population of 10,000 is potentially able to service entire fleets with crew by the thousand. Perhaps if colonies had crew size limits similar to maintenance facilities? Perhaps only crews of 100-200 per 10,000 citizens could benefit? This would have minimal effect on resting at planetary colonies but would require bigger capital ships to be supported by larger/multiple recreation vessels to avoid taking planetary leave.
Edit: Looks like metalax beat me to the crew size limitation suggestion.
-
Yes, I am a little concerned about that. However, this is going to be a very large and slow ship (120,000 tons plus). They are intended to visit bases and PDCs in out of the way places. It is still much cheaper to create a small colony as a base. For units deployed at jump points, they would be very much in harm's way. Interested to hear other opinions.
Steve
A 50k Hab station with engines and its own colony bays is around 300,000-350,000 tons, and probably costs a similar amount. So this probably doesn't change much.
-
Perhaps only crews of 100-200 per 10,000 citizens could benefit? This would have minimal effect on resting at planetary colonies but would require bigger capital ships to be supported by larger/multiple recreation vessels to avoid taking planetary leave.
think of it as a traveling carnival, heh. that ratio would be a little crazy when the whole population is dedicated to entertainment and support thereof.
-
Gargantuain Whore Ships will now be the backbone of any aggressive force.
-
Yes, I am a little concerned about that. However, this is going to be a very large and slow ship (120,000 tons plus). They are intended to visit bases and PDCs in out of the way places. It is still much cheaper to create a small colony as a base. For units deployed at jump points, they would be very much in harm's way. Interested to hear other opinions.
Steve
Another way to negate it would be that the R&R ships have some kind of supply they have to use to perform their task. That might be over complicating things though....
-
Really like the basic idea.
Now we just need oversized commercial Hangars and we can create nice space stations. ;)
Yes, i know, they still make no practical sense.
-
I still kind of prefer the idea for just an "indefinite" option when determining deployment time. That way you could have some ships designed for permanent deployment, but you'd probably want to keep deployment times low for ships where performance was an issue, like warships.
Alternately, what about making shore leave function by system rather than requiring a ship to be in orbit? It makes sense to me that you could shuttle crews back from the fuel harvesting station at Jupiter. Or perhaps a "Shuttle Bay" component that counts as civilian but lets a ship conduct shore leave a range, for those PDCs and immobile stations.
-
I've noticed that a lot of the threads relating to the new shore leave mechanism seem to be about reducing the micro-management. I'm not certain what the intent was in adding the mechanism, but it seems like it's disrupted some play styles, and impacted other mechanics such as asteroid mining, sorium harvesting, and jump gate defence. Perhaps one way to deal with this is to add a game start-up option similar to the one for jump gates on every wormhole, "Automate shore leave", which removes penalties for not conducting shore leave. In this way, players who want to manage shore leave can do so, and those who don't feel the need don't have to. This should focus the suggestions on how to use the mechanism, instead of how to avoid the mechanism.
-
I still kind of prefer the idea for just an "indefinite" option when determining deployment time. That way you could have some ships designed for permanent deployment, but you'd probably want to keep deployment times low for ships where performance was an issue, like warships.
Alternately, what about making shore leave function by system rather than requiring a ship to be in orbit? It makes sense to me that you could shuttle crews back from the fuel harvesting station at Jupiter. Or perhaps a "Shuttle Bay" component that counts as civilian but lets a ship conduct shore leave a range, for those PDCs and immobile stations.
You can create bases with deployment times of 10 or 20 years fairly easily, which is heading towards indefinite.
I have considered allowing ships with some form of personnel shuttles to rewind the shore leave clock by shuttling crew to an in-system population. I think would be the most realistic option. I just having't found a mechanic I like yet. I don't really want to get into tracking crew off the ship so it would have to be done in some form of abstract. Also, you could end up tracking a lot of shuttles, which would slow down the game. The Shuttle Bay component (without tracking actual shuttles) is possible but how do I tie that in with existing boat bays and hangar decks? I also need to consider that larger ships would need a larger shuttle bay.
One option might be to have a small craft with spare berths that could be designated as "Shore Leave Shuttle" in default orders. This shuttle would go to the ship in a system with the greatest need for shore leave, pick up some of the crew and transport them to a nearby colony for perhaps two weeks then return to the ship. On its return, the shore leave time would be rewound by 20 weeks / percentage of crew on shore leave. The shuttle could be carried by the ship, or based at the colony. This wouldn't be too bad for micromanagement as the shuttle(s) would take care of itself. The downside would be a few more ships flying around. There would also have to be a restriction on the % of crew allowed off the ship. Perhaps 10-20%. However, I have to be careful not to get the point where the deployment time for a ship design is no longer an issue. Otherwise I am adding a lot of management for no game play gain.
Steve
-
I would vote for a simple option personally (though I realize this isn't a democracy). Maybe a specific crew-transport module you could put on a ship, and when that ship is docked in another ship's boat bay it rewinds the crew clock as long there's a suitable population in the system for shore leave? Sort of a compromise between the two extremes.
-
I would also suggest tying any automated crew shuttling to the danger level of a system. You'll be a bit less keen to take an unarmed shuttle to a nearby colony when ravenous aliens cut through a colony ship bound to that same planet not three days prior
-
In my opinion it really seem dangerous to leave ships in the field without sufficient crew and would not be anything a navy would do. You would rather take the ship to a port for some maintenance and crew RnR at the same time. I would rather see some new mechanic for tour duty for crews on ships, thus making the training level of a race much more important. For each training level crew would service longer periods on the ships and thus you keep the high grade of the crew for longer before it starts to degrade because of crew rotations.
I'm not sure how long you expect non officer crew to serve on a ship but anything from 12-36 months would probably be OK. Perhaps tie it in with the training level of a race. A higher training level means that crew service longer tours. You should of course expect that about 20-25% of the crew are career officers so it would only be part of the ship that is replaced.
The only reason that I see for this new module are for large space stations and on isolated planets without a population where you like to build up a naval outpost or maintenance facility. I could see that you could use it to give some shore leave to a large battle group stationed somewhere, but after 9-18 months ships will start to get maintenance failures anyway so you need to get them back for overhauls anyway. I rarely run my ships past half their maintenance cycles. Most regular ships of my design have maintenance for about 2.5-3.5 years and deployment times of 9-18 months. When a task group hit its limit for deployment I usually withdraw them and start an overhaul. Once the shore leave is done I abandon the overhaul and send them on a new mission, I can usually do this for an extended period of time before the ships need to perform some serious overhaul.
In any way, I don't see how I would bother much by placing a shuttle bay for shore leave on my ships. To be frank I already assumed that almost every ship of at least a few thousand tonnes had some form of small bay for docking personnel on and of. I also imagine that there are hundreds if not thousands of smaller shuttles going about in a system regularly to transfer officials, administrators, officers and the like all the time.
-
Jorgen:
I suggested something similar a while ago. Look in "Suggestions for 5.7 and beyond" for an early example, or somewhere in the main suggestion thread for a more recent, cleaned-up one. (BTW, Steve, can we get a new suggestions thread? The old one is big and has stuff in it dating back several versions.)
-
Playing my first "real" game since 6.00 (I say real, it's more a training game in which I get used to the design requirements and such), and I have to say I'm liking the new survey team mechanics (even if I have only had one hit so far).
-
Another possibility is officially creating the 'Starbase' unit type, with different maintenance rules as the curren ones make no sense for long term basing, and create a 'crew exchange' module that ships around crew from planets with Academies to PDCs and Starbases and back. Only bad thing about it is the number of vessels this will eventually end up involving.
-
I have considered allowing ships with some form of personnel shuttles to rewind the shore leave clock by shuttling crew to an in-system population. I think would be the most realistic option. I just having't found a mechanic I like yet. I don't really want to get into tracking crew off the ship so it would have to be done in some form of abstract. Also, you could end up tracking a lot of shuttles, which would slow down the game. The Shuttle Bay component (without tracking actual shuttles) is possible but how do I tie that in with existing boat bays and hangar decks? I also need to consider that larger ships would need a larger shuttle bay.
One option might be to have a small craft with spare berths that could be designated as "Shore Leave Shuttle" in default orders. This shuttle would go to the ship in a system with the greatest need for shore leave, pick up some of the crew and transport them to a nearby colony for perhaps two weeks then return to the ship. On its return, the shore leave time would be rewound by 20 weeks / percentage of crew on shore leave. The shuttle could be carried by the ship, or based at the colony. This wouldn't be too bad for micromanagement as the shuttle(s) would take care of itself. The downside would be a few more ships flying around. There would also have to be a restriction on the % of crew allowed off the ship. Perhaps 10-20%. However, I have to be careful not to get the point where the deployment time for a ship design is no longer an issue. Otherwise I am adding a lot of management for no game play gain.
Steve
Perhaps the easiest mechanism would be to have a new facility designated the Depot/PX. It would be transportable and could include a real or virtual shuttle (built-in boat bay). This facility would have a number of exchange crew who would replace the crew going on leave. They would then form the replacement crew for the next ship who’s crew required shore leave. The facility could even be upgradeable to operate at one systems distance if jump gates or a jump capable shuttle (real or virtual) were in place. It would be up to Steve to decide whether it had to be located on a nearly Earth-like planet or not. After all Scapa Flow could be described as only Earth-like at certain times of the year! :)