Aurora 4x
VB6 Aurora => VB6 Mechanics => Topic started by: Erik L on December 30, 2015, 03:49:19 PM
-
Have at.
-
I love the possibilities this shipping line transfer allows, sure this wasnt intended, but of course we're going to use this as a expedient method of thinning out the herd as it were if civilians start being a problem.
1) notice your game is slow
2) blame the civilians because why not?
3) Transfer a whole line to a new empire
4) set them as enemy
5) target practice
6) (optional) notice it didn't really help so add a new shipping line and subsidise it heavily
-
Oh yes, finally I wouldn't need to be in constant designer mode anymore. Extinguished around 20 of those lines+all their designs just today.
-
You can thank me for it:
Steve, I thought it's impossible to move shipping lines from one country to another? How are you going to model that in the Commonwealth unification?
I was going to use a database hack :) but I probably should build in the transfer code and make it available to everyone.
;D ;D ;D
-
Disabling New Civilian Ships
I've noticed there are players who are not huge fans of civilian shipping :)
Therefore in 7.2 I have included an option in the game window to disable the creation of new ships by shipping lines.
Personally I would prefer some more fine tuning. I usually only mind Fuel Harvester (stay off my precious gas giants) and CMCs (hands off my precious resources). So some "Ban by category" would be preferable or me.
-
It's nice having a check that disables new ships, when you reach a good level of shipping you can effectively pause their growth.
I'm far more interested in the changes to orbital habitats and the new 'armour'.
-
Personally I would prefer some more fine tuning. I usually only mind Fuel Harvester (stay off my precious gas giants) and CMCs (hands off my precious resources). So some "Ban by category" would be preferable or me.
I have to absolutely agree with this, Steve. Personally it's the fuel harvesters that make me completely mad. At least with CMC I can buy the output and send it home with mass drivers. Though it's a strain on the economy, so be it, at least it's automated. But fuel harvesters not only require me to buy, but to micromanage the entire thing. I hate that. I have to remember to go and get the fuel and bring it back to my colonies. Horrible, really.
Realistically a political power could just sat the civvies: hey there, if you build fuel harvesters around MY gas giants, I'll blow them up.
If possible I would really endorse a granular solution like the one Ostia proposed :)
-
Disabling New Civilian Ships
I've noticed there are players who are not huge fans of civilian shipping :)
Therefore in 7.2 I have included an option in the game window to disable the creation of new ships by shipping lines.
That is even better. I would be a fan, but my cpu is not! xd , so having it optional is very useful. Actually, with that at hand, I will likely start to play like Marc described: Let them be and just stop their growth at some point.(probably weed out the harvesters though still) The only reason to stop them early and entirely so far was because that was the only point where deleting ships had still been manageable.
Then the amazing habitat changes... . I think Aurora got radiation damage, because it is suddenly mutating so fast, though beneficial.
-
Few things
In v7.2 Maintenance Storage Bays are no longer a military system.
THANK YOU. Finally, I can build reasonably sized civilian support to add to the tanker role (or add MSP to fleet tankers)
Could we perhaps beg for a civilian ammo transport method, and perhaps hangar bay?
Missiles can only be unloaded to a planet with a maintenance facility or maintenance module in orbit.
Have them unload at maintenance facility speeds for "reloading" them, as say the missiles were dismantled for shipping and need to be pieced back together, and it takes 1.2 hours for a size 1 missile, per maintenance facility on the planet. Perhaps also have them loaded at this rate too. So as it works out quite nicely, a planet with 1 maintenance bay can load or unload 100MSP worth of ammo to civilian ship per 5 day increment.
A planet with a FAC tender stationed there (5 maintenance modules) is 500MSP per increment.
Might seem rather slow. But your homeworld if you like running 20kt warships will fill up a transport at 10kMSP per increment, which you can then send your cheap expendable civilian ships, to sit at forward bases for a little while to unload. Rather than having a fuel hungry, naval shipyard demanding ammo collier.
For the civilian hangar bays.
Using the above missile example 100MSP in a 5 day = 5HS, or 250tons of "civilian hangar goods" per 5 day inc.
So for the civilian hangars, they also load and unload at what I'm now going to call "maintenance standard rate". A planet with a FAC tender at it can remove and assemble, 2.5 fighters per 5day inc. OR if you prefer to ship your fuel hungry FACs to forward bases in this manner, you could pull 1.25 out of the freighter per 5day and assemble it.
My theory crafting for this is that just like in history, for shipping, aircraft had many things dismantled such as wings, were shoved into boxes, and then put back together when they got to their destinations. Same thing in aurora, all the hangy bits, and perhaps box launchers and modular components were taken off to pack for shipping... and it takes a couple weeks for a team of engineers to put it all back together. Also while I see no reason why you couldn't even do this with ships up to 5kt in size. Beyond that, the fuelcost/time saving becomes worthless, as you were probably better off sending the ship itself
This is mainly something that I think about because I really don't like having to take combat carriers off station, and send them to the home port to transport fighters to forward bases. And perhaps "hopping" from tanker to tanker with fighters is interesting gameplay for some, but it does get a tad annoying, especially with the terrible efficiency of their engines.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Few questions also.
The new civilian shipping line rules. Does this mean I can halt construction of civvy ships, and then at a later time, turn their production back on?
Also since I haven't played in a while if someone can refresh my memory. Size 1 passive sensors are "civilian" IIRC, but are size 1 actives? I forget.
-
Size 1 (or smaller) actives will not remove the commercial tag from ship designs.
-
I give all my larger commercial ships a 'full' size 1 sensor suite, EM, thermal, and res 1, 5, 20, 80, and 500.
Unless I'm trying to save uridium or I'm in a hurry to build. Usually it's harvesters that miss out on the full package since they operate as a group anyway.
-
Missiles can only be unloaded to a planet with a maintenance facility or maintenance module in orbit.
Have them unload at maintenance facility speeds for "reloading" them, as say the missiles were dismantled for shipping and need to be pieced back together, and it takes 1.2 hours for a size 1 missile, per maintenance facility on the planet. Perhaps also have them loaded at this rate too. So as it works out quite nicely, a planet with 1 maintenance bay can load or unload 100MSP worth of ammo to civilian ship per 5 day increment.
A planet with a FAC tender stationed there (5 maintenance modules) is 500MSP per increment.
Might seem rather slow. But your homeworld if you like running 20kt warships will fill up a transport at 10kMSP per increment, which you can then send your cheap expendable civilian ships, to sit at forward bases for a little while to unload. Rather than having a fuel hungry, naval shipyard demanding ammo collier.
For the civilian hangar bays.
Using the above missile example 100MSP in a 5 day = 5HS, or 250tons of "civilian hangar goods" per 5 day inc.
So for the civilian hangars, they also load and unload at what I'm now going to call "maintenance standard rate". A planet with a FAC tender at it can remove and assemble, 2.5 fighters per 5day inc. OR if you prefer to ship your fuel hungry FACs to forward bases in this manner, you could pull 1.25 out of the freighter per 5day and assemble it.
My theory crafting for this is that just like in history, for shipping, aircraft had many things dismantled such as wings, were shoved into boxes, and then put back together when they got to their destinations. Same thing in aurora, all the hangy bits, and perhaps box launchers and modular components were taken off to pack for shipping... and it takes a couple weeks for a team of engineers to put it all back together. Also while I see no reason why you couldn't even do this with ships up to 5kt in size. Beyond that, the fuelcost/time saving becomes worthless, as you were probably better off sending the ship itself
This is mainly something that I think about because I really don't like having to take combat carriers off station, and send them to the home port to transport fighters to forward bases. And perhaps "hopping" from tanker to tanker with fighters is interesting gameplay for some, but it does get a tad annoying, especially with the terrible efficiency of their engines.
That all sounds awfully complex with several new separated game mechanics?
Why not instead aim for the common denominator and try to keep the concept as simple as possible?
The common property of all this is that they are "disassembled" into neat packages for transportation, and then assembled on site.
But, Hey don't we already have something like that, but for PDCs only?
So, the conceptually best way to do this (IMO) would be to expand/improve the PDC option to also include fighters and stacks of missiles?!
Construction option "Prefab PDC" could be changed to a more general "Disassemble" command which allows you to take any number of PDCs, fighters or missiles, and "pack" it into one or more pre-set "crates" which is the same standard size as a PDC Component, but the game remembers the contents. The Industrial cost of this derived the same as the PDC assembly cost ( and no minerals here either ), but you now have to build the PDCs first.
This means you can take for example a completed PDC Hangar loaded with fighters which in turn are loaded with missiles, Select the PDC in a single click, add a few spare reloads worth of missiles and have it all neatly disassembled and packed down into a creates for shipping ( via the Industry->Stockpiles menu ). Once on site you give a single order to disassemble the crates and you have a operational PDC Hangar stocked with fighters and missiles!
-
The new civilian shipping line rules. Does this mean I can halt construction of civvy ships, and then at a later time, turn their production back on?
Yes, that's correct.
-
Why not just use the preexisting launcher reload system with some modifiers based on tech like reload level, feed system efficiency, and cargo handling multiplier.
Lets assume a missile load speed 10 times slower than launcher reload rate.
We'll look at a tier 2 destroyer from my last game.
Portland class Destroyer 9000 tons 256 Crew 1097.6 BP TCS 180 TH 500 EM 0
2777 km/s Armour 5-38 Shields 0-0 Sensors 1/1/0/0 Damage Control 2 PPV 42
Annual Failure Rate: 27% IFR: 0.4% Maintenance Capacity 191 MSP
Magazine 342 Spare Berths 7
10HS 100 EP Nuclear Pulse Engine (5) Power 100 Fuel Use 141.5% Armour 0 Exp 12%
Fuel Capacity 360,000 Litres Range 5.1 billion km (21 days at full power)
Size 6 Missile Launcher (R2) (7) Missile Size 6 Rate of Fire 90
Missile Fire Control 10/5 FC61-R120 (1) Range 61.6m km Resolution 120
Maverick Mk III (57) Speed: 13,800 km/s End: 84.2m Range: 69.7m km WH: 7 Size: 6 TH: 46 / 27 / 13
Active Search Sensor 10 /5 MR65-R120 (1) GPS 14400 Range 65.7m km Resolution 120
Missile to hit chances are vs targets moving at 3000 km/s, 5000 km/s and 10,000 km/s
This design is classed as a military vessel for maintenance purposesDefault reload rate is 90 for a size 6 missile, we'll assume it will take 900 seconds to load a single size 6 into the magazine, lets make this per cargo handling system on the ammunition ship, improved can load 2 in this time, advanced 4 in this time. Note that this is reload rate of 1, lets assume that increased launcher reload rate doesn't help magazine load speed, but magazine feed efficiency should however.
Magazine is about 1000 tons and holds 342 in total, that's 57 missiles at 900 seconds each so default reload time is 14.25 hours. Cargo handling systems weigh in at 100 tons a piece, it's not unreasonable to assume that an ammunition ship serving this 9000 ton ship will be of similar size, lets say we put 4 cargo handling system which is a mere 4% of the ship.
Load rate then is 3.56 hours. Which is significant, but compares to loading speed of other cargo, it will certainly prevent immediate reloads of a fleet during a battle, except in the case of box launchers which obviously can reload very fast by comparison. That time will be halved once improved handling is added, and of course if you have multiple ammo ships in the fleet you get improved transfer speed.
Next there magazine feed efficiency, what about each level reducing the speed penalty compared to normal launcher speed, research reducing load rate from 10 times down by 1 per level, the final feed efficiency tech drops it down to merely double.
So by top tech tier loading a size 6 missile would take only 180 seconds, you can load 4 per advanced cargo handling system, the hypothetical ammo tender we had above would reload the destroyer in only 10.6 minutes.
Without going to that extreme lets just assume we increase cargo handling systems to 6, and have researched improved cargo handling (10,000 points) and feed efficiency 80 and 85% (6000 points total).
Load time per size 6 missile becomes 720 seconds, thats 11 hours, divided by 12 for the 6 improved handling systems makes reloading the ship only take 57 minutes.
How does this sound?
Edit: I like the maintenance changes, my last game I placed a single maintenance colony in Barnards star which required either frequent mineral shipments, or mines on 5 movies in the system and even still needed shipping in uridium and neutronium.
-
Hmm so v7 comes out with lots of nice shiny additions and so I start a new campaign and spent the regulation amount of hours getting it all setup correctly to begin. Then some bugs are discovered and while fixing them Steve puts in some new shinies, since there were serious bugs I hold off doing anything and wait for v7.1 with the new DB. v7.1 comes out and hot on it's heels v7.2 pops up promising so many wonderful shinies I simply have to have them, and it also means waiting due to a db change. When will this torture end? ;D
-
These mechanics not only make maintenance cleaner, it will also make is easier for the next stage, which is implementing deep space maintenance facilities.
It's happening!!!
(https://i.imgur.com/7drHiqrh.jpg)
-
Hmm so v7 comes out with lots of nice shiny additions and so I start a new campaign and spent the regulation amount of hours getting it all setup correctly to begin. Then some bugs are discovered and while fixing them Steve puts in some new shinies, since there were serious bugs I hold off doing anything and wait for v7.1 with the new DB. v7.1 comes out and hot on it's heels v7.2 pops up promising so many wonderful shinies I simply have to have them, and it also means waiting due to a db change. When will this torture end? ;D
It will never happen. Suck it up like a man, start playing now, and start again once 7.2 is out!
Real Aurora men are not afraid of restarting :P
-
These mechanics not only make maintenance cleaner, it will also make is easier for the next stage, which is implementing deep space maintenance facilities.
Now we just need a none military hanger and we can finally have real deep space outposts and the like.
-
Question on the new maint change then.
Does this mean Id need to constantly build maintenence supply points. Or while ships are in orbit, will the maint facilities still "make enough" to support the ships they are servicing?
I realize everyone should be building some msp, but often I only do it for combat ships and such.
Also with regards to civvy hangars and magazines, ill make a nice suggestions forum post about my views, this we wont turn this thread into another suggestions forum.
-
Question on the new maint change then.
Does this mean Id need to constantly build maintenence supply points. Or while ships are in orbit, will the maint facilities still "make enough" to support the ships they are servicing?
I realize everyone should be building some msp, but often I only do it for combat ships and such.
As things stand you would have to build them using construction factories, although you can build a lot quite quickly and you start the game with a stockpile. You would need minerals to build them but you no longer need minerals for maintenance so it is about the same.
However, I guess one option would be for maintenance facilities to build maintenance supply points. You could turn them on and off like fuel refineries.
-
However, I guess one option would be for maintenance facilities to build maintenance supply points. You could turn them on and off like fuel refineries.
This might actually be better Steve. Consider this: now maintenance costs mineral, but does not use construction factories time. With this change, as much as I like it, you'd have to use factories to produce maintenance supplies. So it is a disadvantage compared to how it works now, because you cannot build other things in the meanwhile.
On the other hand this solution would means you need mineral where the maintenance facilities are if you want to produce maintenance supplies. So there are pros and cons to this....
-
Eeh im not super big on the idea of them producing them...
Though the thought occurs that they (being specialized maint facilities) could turn them out very quickly. And perhaps a tech could be added (much like the fuel production techs) to increase the rate of maint production.
I'll make a suggestions forum post about it after lunch for people to mull it over in. Cause to an extent it would strip out a bit of micromanagement in having to produce the things.
It would also let you send maintenence ships (with modules) to your automined planets, and at forward positions turn out MSP to use (and with the new civvy msp storage, theres nothing to stop my FAC tenders from hauling a few thousand MSP anyways.
-
I don't mind the idea of building them with construction factories. Gives more control, and given how cheap they are you can just build a huge chunk and ignore them if you want.
I'm thinking about the tactical and strategic considerations of this change (or more specifically, the deep space maintenance one). Will we also be getting recreation module usage in deep space? Otherwise the benefits are kind of limited.
If we can also use recreation modules, though, it gets interesting. Maintenance modules can't support themselves, so you'd still probably want a large commercial "base station" with maintenance and recreation modules, and probably a bunch of armor, then put it in place with one or more smaller weapon platforms. I'm not sure how useful they'd be; generally the only static things I want to defend are colonized planets, and generally if I know that there's a threat on the other side of a jump point I'd prefer to concentrate on attacking it rather than defending. Though I suppose if you already have them built you can just leave them guarding a fuel harvesting operation or whatever and then tow them to a strategic location if hostilities break out.
Even if I don't end up using it, it adds a new strategic option, which is always nice.
-
Will we also be getting recreation module usage in deep space? Otherwise the benefits are kind of limited.
You can already use the recreational module in deep space - unless a bug is preventing that.
-
Oh, opps. For some reason I thought they only worked at planets, like maintenance facilities do currently.
-
Great implementation change to go for MSP instead of minerals. The mineral management was so far the only thing really holding me back from opening up other fleet hub colonies beside home, because they were a hassle to manage.
Also: Finally a use for Sorium in post gas-giant exploitation empires. :)
Now we just need a none military hanger and we can finally have real deep space outposts and the like.
Hmm, civil hangars are not really needed for this, because you can maintain any separate military hangar with enough maint. modules on position, so it doesn't really prohibit the concept of a deep space base.
As far as I can see, current changes are completely implementing the thing! :D
Oh the possibilities. I have like 2.5 game ideas still waiting for time from before 7.0, and now this comes along. :)
However, I guess one option would be for maintenance facilities to build maintenance supply points. You could turn them on and off like fuel refineries.
This might actually be better Steve. Consider this: now maintenance costs mineral, but does not use construction factories time. With this change, as much as I like it, you'd have to use factories to produce maintenance supplies. So it is a disadvantage compared to how it works now, because you cannot build other things in the meanwhile.
Some people had thought before that this was already how the MSP were produced (yet they thought it happened automatically), and I also think it would make sense. I could live with a little reduced industrial, but this is fine too.
-
Oh, opps. For some reason I thought they only worked at planets, like maintenance facilities do currently.
I'd very much like to see maintenance facilities decoupled from planets and tied to, say, location instead. With commercial supply, fuel, and ammo storage as well as recreation and other modules, the only thing missing from a complete support outpost/maintenance station is the ability to handle overhauls.
-
While I like the fact that maintenance is simplified on the product end, making the MSP cost every single resource just makes the system more complex and inefficient on the manufacturing side.
Take my very simple 2000t gravsurvey ship. It has no active sensors, passive sensors or jump drive to be cheaper. It doesn't require tritanium, neutronium (heavy-duranium armour), vendarite, or sorium, and only requires 5x corbomite for the bridge. I designed this due to a shortage of most resources, and the fact that I wanted the least amount of sorium going to maintenance as possible.
To properly maintain ALL ships now, you now require one world with access to all minerals in order to produce MSP. Any shortage of one resource now means that ALL ships suffer maintenance failures, instead of just the ones that need them. The good thing about the new system is a resource shortfall will have a delayed effect on maintenance, as long as there are MSP stockpiled.
Further, since MSP are used to repair a ship in transit, and shipyards repair in orbit using minerals, are shipyard repairs changed in any way by this? I wouldn't think they are but it doesn't hurt to ask.
-
Due to the new gap below in the mining and maint window. Perhaps some of the buttons on the lower end of the overview window could be duplicated there, for the people with low resolution monitors, so they can still SM somewhat reliably.
-
To properly maintain ALL ships now, you now require one world with access to all minerals in order to produce MSP..
Further, since MSP are used to repair a ship in transit, and shipyards repair in orbit using minerals, are shipyard repairs changed in any way by this? I wouldn't think they are but it doesn't hurt to ask.
It's nine minerals, as Vendarite and Corbomite aren't needed. The other minerals are all needed for different types of ship. Rather than have different types of maintenance supplies for different ships, which would be a lot of micromanagement, the variety of minerals needed for creation of the MSP is still al lot easier than ensuring the right combination of minerals is at each place where maintenance is required. Now you can build in a central location if needed and distribute as required.
Repairs are unchanged.
-
It's nine minerals, as Vendarite and Corbomite aren't needed. The other minerals are all needed for different types of ship. Rather than have different types of maintenance supplies for different ships, which would be a lot of micromanagement, the variety of minerals needed for creation of the MSP is still al lot easier than ensuring the right combination of minerals is at each place where maintenance is required. Now you can build in a central location if needed and distribute as required.
Repairs are unchanged.
In That case, could you remove some other minerals from MSP production? Like tritanium and neutronium? Missile warheads don't really need maintenance, and neither does armour (which neutronium is mostly used for, besides railguns). I was thinking of corundium as well, but almost all weapons seem to use it.
-
In That case, could you remove some other minerals from MSP production? Like tritanium and neutronium? Missile warheads don't really need maintenance, and neither does armour (which neutronium is mostly used for, besides railguns). I was thinking of corundium as well, but almost all weapons seem to use it.
Tritanium is used by missile launchers and magazines. Neutronium is used for several different systems including railguns, combat drop modules and damage control systems.
Both are minerals that are would be used in creating spare parts for ships.
-
The new civilian shipping line rules. Does this mean I can halt construction of civvy ships, and then at a later time, turn their production back on?
Yes, that's correct.
A thought occurs - how does this interact with shipping lines replacing their old ships? You might want them to still do that, if only to get obsolescent junkers out of the trade lanes, but it seems like an additional complication to the code, so I don't know.
-
Yes, that's correct.
A thought occurs - how does this interact with shipping lines replacing their old ships? You might want them to still do that, if only to get obsolescent junkers out of the trade lanes, but it seems like an additional complication to the code, so I don't know.
As things stand, old ships will be scrapped even if new ships are not built.
-
As things stand, old ships will be scrapped even if new ships are not built.
Honestly thats almost better in my opinion. That would let you halt their construction, then wait a few years for them to trickle down and scrap ships, and then when you want to, give them the ability to build again. Probably have a big boom of new civvy ships about, and put them on hold again.
Never again will I click the civilian shipping menu and see literally millions of tons of civilian shipping clogging up my processor.
Edit. page finally loaded, saw civilian magazines.
Me just sitting here like "yes, yesssss, YEASSSSS" i cant wait, this patch is gonna be good.
-
In v7.2, ship-based maintenance modules will function in deep space to maintain and overhaul other ships. All maintenance facilities at the same location, even if spread across different ships and different task groups, will all be added together for the purposes of determining how large a ship can be maintained.
I know this serves no purpose. And I know it's probably too much work. And I know this probably won't happen. But I just have to ask. Would it be possible to also have orbital habitats working in random points in space just like maintenance facilities? So that I can role-play creating an entire city with support facilities in space? Just a thought.
-
I know this serves no purpose. And I know it's probably too much work. And I know this probably won't happen. But I just have to ask. Would it be possible to also have orbital habitats working in random points in space just like maintenance facilities? So that I can role-play creating an entire city with support facilities in space? Just a thought.
There is a similar discussion that went on between myself and Steve on the v7.1 discussion thread. From what he said in that discussion I think I can safely say it will not be possible. It has something to do with the way that populations are tied to system bodies and your idea would require reprogramming a large segment of the game to be even feesable. But it does look like in either this patch or the next we will get deep space stations.
-
You could put orbital habitats in space, you just wouldn't be able to colonise or build anything there.
-
So now that we are getting the nice new changes to maintenance in v7.2, how long will it be until someone designs?
A quarter of a million humans and aliens, wrapped in two million five hundred thousand tonnes of spinning metal. All alone in the nigh
-
So now that we are getting the nice new changes to maintenance in v7.2, how long will it be until someone designs?
A quarter of a million humans and aliens, wrapped in two million five hundred thousand tonnes of spinning metal. All alone in the nigh
Done it a few times... this just means it will be even better, though it is hard enough to stay that small already.
-
Combine Populations
In v7.2 you have the option to combine two populations from the same race and species on the same planet if they both have the same political status.
This sounds useful, for certain circumstances.
Though, I was wondering if we will ever get the ability to revert the genetic modifications of a subspecies back to the original race.
-
How can we get 7. 2? I cannot find installer :(
-
It isn't out yet.
-
The orbital habitat and maint changes have me super-stoked. I cant really get myself to play since I've wanted orbital habitats to be feasible for so long.
-
Kind of wondering about some things. Would a section marked as the "no armor" (structural shell) still be able to do their task when they are being tractored? I was planning on having sectionalized commercial ships using this new change, with a module with nothing but cargo/cryo/harvesters/etc with a 0.1 deployment time and then an armored "drive" section with all the crew, engines, fuel, and whatnot. So would they be able to load cargo/people or harvest fuel while tractored or would they need to detach every time? I know for the harvester I could just tug out and leave but :P. Also would maintenance modules (on ships/stations) be able to construct MSP in deep space if they had the required minerals in a cargo bay at the same location (same TG) without being over a colony (orders/setting to start/stop would/could be in the ship window under the misc/cargo tab. Or a new tab in the TG window labled "Industrial" or something similar), or would you only be able to haul supplies from a colony?
-
Also would maintenance modules (on ships/stations) be able to construct MSP in deep space if they had the required minerals in a cargo bay at the same location (same TG) without being over a colony (orders/setting to start/stop would/could be in the ship window under the misc/cargo tab. Or a new tab in the TG window labled "Industrial" or something similar), or would you only be able to haul supplies from a colony?
The release notes state that only system body based maintenance facilities will produce MSP. That suggests to me that deep space MSP manufacturing will be off the table.
-
Shields also should be classified as commercial not military. That way the armour you have lost atleast it has some protection, from an aggressor else these habitats could be destroyed, single laser gun. Also many time i wanted to atleast have some of my commercial vessels have shields instead of armour to suit the rest of my fleet.
-
Shields also should be classified as commercial not military. That way the armour you have lost atleast it has some protection, from an aggressor else these habitats could be destroyed, single laser gun. Also many time i wanted to atleast have some of my commercial vessels have shields instead of armour to suit the rest of my fleet.
Shield are an inherent military technology because of the power requirements, complications of creating and maintaining, and inefficiencies in its use. And there is also the point that the "structural shell" is supposed to have drawbacks if you want to use it, if shields are made commercial then there is a lot of room for abuse in such you wouldn't have to defend your commercial stations because you could just make them have tens of thousands to millions of shield points with the room from removing the armor (no joke, that is entirely possible). However, there is nothing to say that there couldn't be a civilian version that is larger and provides less shielding per piece at an equivalent military tech. Say it is 10 times larger, recharges 2-5 times slower, and only provides the protection of 1/2 the military version. Since that could still be exploitable, maybe you could make it so speed is 1/2 normal, you can't load/unload cargo/citizens, harvest fuel, or construct gates while the commercial shields are active.
-
Concerning the new alien ruins chance setting. When does it take effect, during system generation (iirc after we go through a jump point) or a random chance during geo survey of terrestrial planet\moon?
-
Shields also should be classified as commercial not military. That way the armour you have lost atleast it has some protection, from an aggressor else these habitats could be destroyed, single laser gun. Also many time i wanted to atleast have some of my commercial vessels have shields instead of armour to suit the rest of my fleet.
The structural shell comes from a discussion about the habitats that went on for some time in another topic. Long story short the habitats were too expensive and not economically viable and during the analysis of the problem Steve concluded that's mostly due to armor. The only reason structural shell exists at all is so that the cost of the habitats can be brought down. It's utility for other constructs, like fuel harvesting bases, is just an unintended consequence.
And this is where the protection issue comes in. Civilian designs are not supposed to be defensible by themselves, they are supposed to be protected by naval units. That's why even now you can destroy any commercial design with a single laser, it will just take you a little longer if you armor your designs. In addition, as mentioned by 83athom, it's difficult for me to see any real shield as a commercial design, much the same way it's difficult for me to see how you could have commercial ECM. Heck, I'm even against CIWS being commercial components, despite them having no offensive power whatsoever. And to be honest it's difficult for me to imagine any reason to put shields on a commercial vessel other than RP purposes. Fuel harvesters, cargo ships, colony ships, orbital habitats and the like are supposed to be behind the lines and protected by naval forces. Adding armor/shields will only make the enemy waste more time/ammunition destroying them, but will not change their fate if they find themselves targeted (note that as far as I know NPR will always go for military ships first). The only ship that could potentially benefit from shields is a commercial grade fleet tanker you want to keep with your warships to extend their range, but you can just pile armor on it and you'll be fine. Or just make it a military ship with defenses added.
Overall I see very little practical reason to make shields a commercial component and as 83athom pointed out, there's a lot of reasons not to do so as they may the break game balance (such as it is). If you're looking for an example of that, orbital habitats can be built in factories. Why is this important? Because anything that has this component can be build in factories, even if it's a massive terraforming ship with engines, tonnes of armor, weak sensors and CIWSs. Considering the ingenuity of many of the players, I don't even want to know what they would build with civilian grade shields, especially against NPR opponents, whose AI is rather limited.
-
Kind of wondering about some things. Would a section marked as the "no armor" (structural shell) still be able to do their task when they are being tractored? I was planning on having sectionalized commercial ships using this new change, with a module with nothing but cargo/cryo/harvesters/etc with a 0.1 deployment time and then an armored "drive" section with all the crew, engines, fuel, and whatnot. So would they be able to load cargo/people or harvest fuel while tractored or would they need to detach every time? I know for the harvester I could just tug out and leave but :P.
I had a couple of games where my standard freighters, tankers and fuel harvesters were exactly that: Module ships.(did that to minor extend in the swarm game too) Essentially just a 75% engine ship with a tractor that would pick up an identical sized mission module (tank, cargo, passenger, harvest or salvage), and it worked perfectly already in 6.4.
I like this, because it enables you to respond to the current needs without having to have expensive engines sitting around doing nothing for years with specialized ships. - The engines are always flying, only the mission module may stay back.
Disadvantage though is that you get difficulty using these freighters in a fight, should that ever be an issue (like tanking over AMM spam bases with your 1.3+mt superfreighter), because every hit will detach the module, and you essentially only have half of the amazing armor advantage of large ships.
It also requires around somewhere less than 2 times as many officers, so small ship civil navies would run into further complication.
-
For purposes of starting a new "grand campaign", is the release of 7. 2 some days or weeks away?
-
Keep in mind there are some pretty significant changes in v7.2, so Steve needs to properly test them for balance/bugs before he is to release it. However, I would say Soon(tm). Keep in mind that the last time I said that, the new version was released the very next day.
-
...In addition, as mentioned by 83athom, it's difficult for me to see any real shield as a commercial design, much the same way it's difficult for me to see how you could have commercial ECM. Heck, I'm even against CIWS being commercial components, despite them having no offensive power whatsoever. And to be honest it's difficult for me to imagine any reason to put shields on a commercial vessel other than RP purposes.
Israel already has ECM and CIWS on their civilian airliners. Most other airliners simply don't bother due to weight and economical considerations.
From Wikipedia:
El Al planes have been fitted with anti-missile counter-measures since the early 2000s, with the initial system known as Flight Guard. El Al has been the only commercial airliner to fit its planes with systems to defend against anti-aircraft missiles.
In 2014, El Al began to fit some of its planes that fly on more sensitive routes with an updated system missile defense system that employs an infrared missile-tracking camera, an “infrared (IR), ultra-violet (UV), or radar missile-approach warning (MAWS) sensor to detect a missile launch in the very early stages of an attack” and a laser system to act as a counter-measure.
Also, WW2 convoys would sometimes tow acoustic decoys to distract the new German acoustic torpedoes being used. Just because it isn't done in modern RL doesn't mean it wouldn't be done during a war.
I am all for arming my civilian shipping. During both world wars freighters were sometimes armed with machine guns, mortars, auto-cannons and sometimes even spare 5" cannons. Adding one 10cm laser should not cause the entire ship to start having maintenance failures just because it's 'military'.
As a footnote, a million shield point shield would use a LOT of fuel.
-
Israel already has ECM and CIWS on their civilian airliners. Most other airliners simply don't bother due to weight and economical considerations.
From Wikipedia:
In 2014, El Al began to fit some of its planes that fly on more sensitive routes with an updated system missile defense system that employs an infrared missile-tracking camera, an “infrared (IR), ultra-violet (UV), or radar missile-approach warning (MAWS) sensor to detect a missile launch in the very early stages of an attack” and a laser system to act as a counter-measure.[/i]
Minor quibble: I strongly suspect that the laser system is an IR laser designed to "blind" IR seekers (as opposed to a point-defense laser designed to destroy the missile itself). I would classify this more as "advanced ECM" than as "CIWS". Ditto for acoustic decoys. As far as I know, DoD is still researching/evaluating laser point-defense systems and they're not yet deployed in a system that would be mounted on a commercial airliner.
That being said, I suspect Steve's reasoning is that it shouldn't be too hard to slap an R2D2 (Phalanx) or 4 onto a commercial ship during wartime. At present [pause while googling] I strongly suspect that there aren't any mounted on civilian ships, although Wikipedia says "The Navy began placing CIWS systems on non-combatant vessels in 1984". (Note that the same Wikipedia article says that a British Sea Dart shot down a Silkworm during Gulf War I, which I wasn't aware of.)
John
-
The LAWS system is currently deployed in the Persian gulf, primarily for shooting down drones. But I believe a more powerful anti missile version is supposed to be deployed in number this year.
-
The LAWS system is currently deployed in the Persian gulf, primarily for shooting down drones. But I believe a more powerful anti missile version is supposed to be deployed in number this year.
I was going to mention that earlier, but he said "they're not yet deployed in a system that would be mounted on a commercial airliner" so I just canceled it. But not only are they able to shoot down drones, but munitions on enemy vessels as well. They tested it by remote controlling a dingy with a rocket launcher strapped on it, destroying the rocket warhead in the launcher.
-
I don't know of any CIWS systems installed on other than naval vessels, but there have been studies of doing so. They have very little impact on operations, as they basically get bolted down and have power and chilled water lines run to them. That's it, along with a mode switch. I do know that some ships which Aurora would classify as civilian are definitely fitted for CIWS, if not with it now. (They're MSC, and currently unarmed, but have the mounting locations fitted and might receive the units in wartime.)
Also, Steve, I had decided not to update my big game to V7, until I saw this stuff. Why do you always do this to me?
-
Minor quibble: I strongly suspect that the laser system is an IR laser designed to "blind" IR seekers (as opposed to a point-defense laser designed to destroy the missile itself). I would classify this more as "advanced ECM" than as "CIWS". Ditto for acoustic decoys. As far as I know, DoD is still researching/evaluating laser point-defense systems and they're not yet deployed in a system that would be mounted on a commercial airliner.
A "blinder" is a soft-kill system. It would burn out the delicate sensor on the front of the missile, which would be just as effective as blowing the missile up.
That being said, I suspect Steve's reasoning is that it shouldn't be too hard to slap an R2D2 (Phalanx) or 4 onto a commercial ship during wartime. At present [pause while googling] I strongly suspect that there aren't any mounted on civilian ships, although Wikipedia says "The Navy began placing CIWS systems on non-combatant vessels in 1984". (Note that the same Wikipedia article says that a British Sea Dart shot down a Silkworm during Gulf War I, which I wasn't aware of.)
Rheinmetall Oerlikon Millennium Gun. A simple to mount design that is not embedded into the hull and requires no external power to fire (although it does need external power to reload). In the modern navy there is no need to have weapons aboard a commercial ship, which is why you won't find modern container ships with weapons. It's actually against international law if I'm not mistaken.
-
It was technically against various international agreements to mount weapons to certain vessels I. WWII but that stopped nobody.
They assumed that as long as they popped out a military flag before opening fire with the hidden guns it was fine, but that's not really how the law works.
What's really interesting is that the controversy at the time was actually based on how commercial vessels were protected from being fired at under international law, however as most countries integrated such ships into it's intelligence system, ie such ships would watch out for and radio the position of enemy vessels, so it was argued that they weren't protected as non belligerents and could be fired at by submarine[1]. In practice though where possible crews were usually given warning so they could evacuate, except in cases where a convoy was too well protected so only a stealthy torpedo could be used to destroy the vessel.
Reference:
[1] http://www.lawbookexchange.com/pages/books/42170/robert-w-tucker/the-law-of-war-and-neutrality-at-sea
-
For purposes of starting a new "grand campaign", is the release of 7. 2 some days or weeks away?
More likely weeks than days. I managed to get a lot done over Xmas as I had 10 days off work. Now I am back to working long days so don't have much time for development work.
-
It was technically against various international agreements to mount weapons to certain vessels I. WWII but that stopped nobody.
They assumed that as long as they popped out a military flag before opening fire with the hidden guns it was fine, but that's not really how the law works.
What's really interesting is that the controversy at the time was actually based on how commercial vessels were protected from being fired at under international law, however as most countries integrated such ships into it's intelligence system, ie such ships would watch out for and radio the position of enemy vessels, so it was argued that they weren't protected as non belligerents and could be fired at by submarine[1]. In practice though where possible crews were usually given warning so they could evacuate, except in cases where a convoy was too well protected so only a stealthy torpedo could be used to destroy the vessel.
Reference:
[1] http://www.lawbookexchange.com/pages/books/42170/robert-w-tucker/the-law-of-war-and-neutrality-at-sea
It was more complicated than that. Subs were originally supposed to be under prize rules, which meant they had to take aboard the ship's crew and put them somewhere safe. Telling them to take to the boats was theoretically not enough unless they were within sight of land. In practice, you can't do that because there's not enough room. So it became common practice for the sub to come alongside and say "Boats, and we'll sink you in a bit." What stopped this was Q-Ships, which pretended to be merchant vessels, then opened fire when the sub pulled up. Then, the Germans began unrestricted submarine warfare.
In WWII, nobody really had much expectation that these rules would be followed, and most merchant ships relatively quickly acquired some weapons, usually antiaircraft guns.
-
Hi Steve, What ever happen to adding maintenance supplies to ground forces needs, to feed a ground force army. (I know you were keen on it at some stage)
Now you made changes to maintenance for the purpose of ships and help with micromanagement, how about adding it for ground forces. Or atleast they have a MSP setting that get used up in a ground war.
-
Hi Steve,
have read on your 7. 2 feature list that you have added an option to disable civilian ship building. How about a "control button" to allow the number of civilian ships which can be build? Or generally the civilian colonies. It is nice that they do their job of creating them in the background but sometimes it would be nicer to control how many of them are created or are allowed for the calculation mechanic to create them.
Thx
-
Its a toggle. If you want more, uncheck the box. Want them to stop, check it.
-
With the new Maintenance supplies mechanic Maintenance Facilities will produce supplies. Does it effect overhull mechanic except consuming more supplies?
-
So just to check I have this right, with the introduction of commercial hangars, the following will be the case?
Military Hangar
Deployment clock stopped
Maintenance clock stopped
Maintenance supplies not consumed
Commercial Hangar
Deployment clock stopped
Maintenance clock continues
Maintenance supplies consumed as normal
Commercial Hangar + Maintenance Modules
Deployment clock stopped
Maintenance clock stopped
Maintenance supplies consumed by Maintenance Modules
Can docked ships undergo overhaul? There doesn't seem to be any pressing reason they shouldn't.
Is there or will there be, any effective detriment for a commercial ship carrying commercial parasites without providing sufficient flight berths?
-
With the new Maintenance supplies mechanic Maintenance Facilities will produce supplies. Does it effect overhull mechanic except consuming more supplies?
Overhauls are the same except they now consume supplies instead of minerals.
-
Everything looks fine. Also, all hangars can repair.
Can docked ships undergo overhaul?
No.
Is there or will there be, any effective detriment for a commercial ship carrying commercial parasites without providing sufficient flight berths?
Probably not. As commercial designs naturally need to have months of deployment, it is presumed they are comfortable, so they would be content to stay in their ships the duration of being docked.
-
So just to check I have this right, with the introduction of commercial hangars, the following will be the case?
Military Hangar
Deployment clock stopped
Maintenance clock stopped
Maintenance supplies not consumed
Commercial Hangar
Deployment clock stopped
Maintenance clock continues
Maintenance supplies consumed as normal
Commercial Hangar + Maintenance Modules
Deployment clock stopped
Maintenance clock stopped
Maintenance supplies consumed by Maintenance Modules
Can docked ships undergo overhaul? There doesn't seem to be any pressing reason they shouldn't.
Is there or will there be, any effective detriment for a commercial ship carrying commercial parasites without providing sufficient flight berths?
Correct except for:
Commercial Hangar
Deployment clock continues
Maintenance clock continues
Maintenance supplies not consumed (unless there are also maintenance modules or there is a system failure)
In effect, a military ship in a commercial hangar is treated as if it wasn't in a hangar at all for maintenance purposes.
As the code is written, a ship in a commercial hangar can be overhauled. May have to check how you would give that order though :)
-
Steeeeve, you are making cooool thiiiiiingssss
-
Correct except for:
Commercial Hangar
Deployment clock continues
Maintenance clock continues
Maintenance supplies not consumed (unless there are also maintenance modules or there is a system failure)
In effect, a military ship in a commercial hangar is treated as if it wasn't in a hangar at all for maintenance purposes.
As the code is written, a ship in a commercial hangar can be overhauled. May have to check how you would give that order though :)
What if the commercial hangar is in a station with a population? Wouldn't that reduce the deployment clock?
-
Correct except for:
Commercial Hangar
Deployment clock continues
Really? I would have thought using the mothership/stations facilities and flight berths so as not to run up the deployment clock for the crew would have been one of the things that would work for a commercial hangar. So as it stands commercial hangars are, by themselves, only of use for repairing systems of military ships, and require sufficient maintenance modules to have any other effect at all?Derp, was only thinking in the context of a station, of course they would also avoid needing to spend fuel on likely much less efficient engines.
Can box launchers be reloaded in a commercial hangar from the new commercial magazines?
-
Would be nice to have an option that conditional commands would be inserted before the actual command instead of replacing all actual commands - so the ship then can resume its former duties.
-
Would be nice to have an option that conditional commands would be inserted before the actual command instead of replacing all actual commands - so the ship then can resume its former duties.
This is very complex because the program would have to calculate if the last order of the conditional command made sense if followed by your existing first order. Because of the huge variety of potential orders you could have set, this is likely to result in logic-breaking situations. Therefore the orders are removed so the human player can intervene.
-
Hopefully never. ;D
-
If the maintenance clock continues to tick, can commercial hangers be used in conjunction with fighters? Like many others, my fighters aren't designed to let their maintenance clock tick for more then a week at most. Hauling them in a commercial hanger where the clock is still ticking will result in delivering a squadron of scrap metal if they need a month to reach their destination.
-
If the maintenance clock continues to tick, can commercial hangers be used in conjunction with fighters? Like many others, my fighters aren't designed to let their maintenance clock tick for more then a week at most. Hauling them in a commercial hanger where the clock is still ticking will result in delivering a squadron of scrap metal if they need a month to reach their destination.
The commercial hangar bay is mainly for repairs. However, I have had fighters sat in orbit for months waiting for a carrier with no maintenance and not had any failures. Although they have no engineering spaces, their chance of failure is very low due to their small size. For example, here is the relevant portion of the US fighter from my current campaign:
F-40 Starfury class Fighter 300 tons 2 Crew 53.4 BP TCS 5.99 TH 42 EM 0
7011 km/s Armour 1-3 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 0 PPV 2.25
Maint Life 0 Years MSP 0 AFR 59% IFR 0.8% 1YR 3 5YR 43 Max Repair 13 MSP
Intended Deployment Time: 0.5 months Spare Berths 0
The class AFR is 59% per year and that is the rate when the fighter has already been in space for a full year (it starts at 0% and will get to 59% after one year of deployment and continue getting higher after that). A fighter with a low deployment clock will have very little chance of failure. A 3 month trip aboard an auxiliary carrier would be very low risk.
-
7. 2 looks awesome! I can't wait to play it! ;D Going to hold off on starting my next game until its out!
-
7. 2 looks awesome! I can't wait to play it! ;D Going to hold off on starting my next game until its out!
It may be a while. I have a few other changes in mind and with several fundamental changes I need to test it for a while.
-
Although they have no engineering spaces, their chance of failure is very low due to their small size. For example, here is the relevant portion of the US fighter from my current campaign:
F-40 Starfury class Fighter 300 tons 2 Crew 53.4 BP TCS 5.99 TH 42 EM 0
7011 km/s Armour 1-3 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 0 PPV 2.25
Maint Life 0 Years MSP 0 AFR 59% IFR 0.8% 1YR 3 5YR 43 Max Repair 13 MSP
Intended Deployment Time: 0.5 months Spare Berths 0
The class AFR is 59% per year and that is the rate when the fighter has already been in space for a full year (it starts at 0% and will get to 59% after one year of deployment and continue getting higher after that). A fighter with a low deployment clock will have very little chance of failure. A 3 month trip aboard an auxiliary carrier would be very low risk.
Does this mean the wiki is wrong? It claims the following:
(AFR, the chance of a spacecraft component failing based on a one year duration)
You seem to suggest here that AFR is the chance each increment that something will fail here after it's gone a year deployment?
Even with 59% per year it should mean 15% per 3 months, which means 15% of your fighters should have damaged components after that low risk trip. If the failing component happens to be engines on any of them they are at big risk for secondary explosions due to normal high power of the engines.
-
Does this mean the wiki is wrong? It claims the following:
(AFR, the chance of a spacecraft component failing based on a one year duration)
You seem to suggest here that AFR is the chance each increment that something will fail here after it's gone a year deployment?
Even with 59% per year it should mean 15% per 3 months, which means 15% of your fighters should have damaged components after that low risk trip. If the failing component happens to be engines on any of them they are at big risk for secondary explosions due to normal high power of the engines.
I haven't read the wiki :)
The base failure rate increases as a ship spends more time away from port. The chance of a failure is equal to Base Class Failure Chance * Years Since Overhaul * Portion of Year in 5-day Increment.
For example, if a class has an annual failure rate of 50% and has been away from port for exactly three months when a production phase takes place. The failure rate at that point is 50% * 0.25 = 12.5%. If the 5-day increment at that point is exactly five days, the chance of failure in that single increment is 5/360 * 12.5%.
If the same ship has been away from port for three years, the chance would 50% * 3 = 150% * 5/360. If you check the ship display rather than the class, the exact current failure rate is displayed
So a fighter with an annual failure rate of 59% would only have a failure rate of 4.9% after a month in space and 14.75% after three months.
So for a single fighter with an annual failure rate of 59%, the chance of at least one failure in a 60-day journey (starting with zero deployment and assuming exact 5-day increments) would be about 0.88%
(http://www.pentarch.org/steve/Screenshots/Excel.PNG)
-
Extremely interesting information! Thanks for taking the time to write it. I think the wiki needs some updating :)
-
This is very complex because the program would have to calculate if the last order of the conditional command made sense if followed by your existing first order. Because of the huge variety of potential orders you could have set, this is likely to result in logic-breaking situations. Therefore the orders are removed so the human player can intervene.
Hmm, that's true. Maybe inserting a buffer for the old orders (instead of deleting them buffering them) from which you then can manually choose to reenter if you see that they fit?!? Although might not be less complex for the program to check if those orders are still valid, I guess... .
-
It may be a while. I have a few other changes in mind and with several fundamental changes I need to test it for a while.
Noooooo!!!!!
Why must you do this to me, Steve? Why?
Or would it make the testing go faster if you had help? ;D
Also, to a first approximation, failure chance seems to go up with the square of time spent in space, assuming you start at 0. That seems a very useful thing to keep in mind, although not terribly realistic.
-
Also, to a first approximation, failure chance seems to go up with the square of time spent in space, assuming you start at 0. That seems a very useful thing to keep in mind, although not terribly realistic.
IMO, it's within the bounds of reason. older components fail more and take more and more work to fix. the flip side though is that inevitably some new components are lemons, which isn't modeled in Aurora, not that it needs to be.
this is why it can be important to have good engineering lifetimes on your ships; all else being equal, it makes them cheaper to deploy for the same length of time because you will face less failures.
/unless im bad at math
-
IMO, it's within the bounds of reason. older components fail more and take more and more work to fix. the flip side though is that inevitably some new components are lemons, which isn't modeled in Aurora, not that it needs to be.
this is why it can be important to have good engineering lifetimes on your ships; all else being equal, it makes them cheaper to deploy for the same length of time because you will face less failures.
/unless im bad at math
Well, the usual curve of failures is U-shaped. There's a period of high failures during burn-in, then a while when the failure rate is pretty much constant and you're getting essentially random failures, and then the failure rate goes up as stuff wears out. This model seems to dump us straight into the last phase. There are mathematical methods to look at when you should do preventative replacements to reduce overall cost. Some components work differently. For instance, preventative replacement of vacuum tubes is pointless. They fail randomly before they wear out, so there's no spike and no point in replacing them before they burn out. (Which tells you just how old the book I got this from is.)
I'll have to look through that book and see if there might be a good equation to use here if Steve's interested. The first thought would be to skip burn-in (which may or may not be significant for a given system) and then have a period of pretty constant failures (which would depend on the ship), and then have the failure rate start up.
-
Does this mean the wiki is wrong? It claims the following:
(AFR, the chance of a spacecraft component failing based on a one year duration)
You seem to suggest here that AFR is the chance each increment that something will fail here after it's gone a year deployment?
Unless I am reading it wrong, both are "true" according to Steve tutorial. AFR on the Class design summary tab assume a ship has one year on its maintenance clock. While the individual ship pages show actual maintenance clock data.
So you'll have to be more specific as to the info on the wiki you refer to, and if you did spot a mistake, please comment here (http://aurora2.pentarch.org/index.php?board=27.0) to make sure they see it.
-
I wonder if, with a low enough failure rate, if it would be more economic to have a ship deployed for the lower part of it's failure portion, then come back in for overhauls periodically. Or does the overhaul make up for lost time by consuming extra minerals/maintenance supplies equal to the rewound time of normal maintenance?
-
Couple thoughts.
With the new governing rules for maintenance, perhaps the maintenance module could add a couple thousands worth of MSP storage to a maintenance ship (partially to help newbies who might forget to put maintenance storage, and partially so that you can just outright store a bit more)
Meanwhile I wonder. If you had a single station or ship with maintenance modules and civilian hangars. Would those maintenance modules maintain the ships in the hangars? Also would they maintain fighters (which often get very grumpy if not maintained for more than a month or so since I rarely build maint into them)
-
Will NPR make use of deep space stations? If so please make sure that they will have a marine compliment because I'll be requisitioning all those for the empire.
EDIT:
Also does anyone know if you can board a ship with Shields up?
-
Will NPR make use of deep space stations? If so please make sure that they will have a marine compliment because I'll be requisitioning all those for the empire.
EDIT:
Also does anyone know if you can board a ship with Shields up?
I haven't tried yet but I believe boarding ignores all aspects of defence, you simply target a ship and try to board them and the only considerations are the speed differences with regards to how many marines actually make it onto the enemy vessel. Though since many boarding craft travel at slow missile speeds I do think if possible that raised shields should prevent boarding attempts.
-
It may be a while. I have a few other changes in mind and with several fundamental changes I need to test it for a while.
I don't mind. Seems like it will be worth the wait!
-
Titans. Woah.
-
You may want to file off some serial-numbers on the titan nomenclature, there.
How feasible would it be to make an Ogre/Bolo/Continental Siege Machine version of this? (It's pretty much there I think, but for fluff, unless the mechanics allow for deployable PDCs.)
Do the mechanics allow for deployable PDCs?
*quick check with current game*
Not really, no. You can put one in a mothership of sufficient bay size but task forces with PDCs can't be given orders.
*unless*
Still no, even with making an Order Template as a work-around.
-
You may want to file off some serial-numbers on the titan nomenclature, there.
How feasible would it be to make an Ogre/Bolo/Continental Siege Machine version of this? (It's pretty much there I think, but for fluff, unless the mechanics allow for deployable PDCs.)
Do the mechanics allow for deployable PDCs?
*quick check with current game*
Not really, no. You can put one in a mothership of sufficient bay size but task forces with PDCs can't be given orders.
*unless*
Still no, even with making an Order Template as a work-around.
Yes, I probably should have some less specific names before release :)
-
Make sure the Star Swarm gets these.
Kaiju. Kaiju.
-
Make sure the Star Swarm gets these.
Kaiju. Kaiju.
(http://lh4.ggpht.com/_CiSi2szXpzY/Tdh7dPQzkUI/AAAAAAAAArA/2AT-O0vFLPY/Spongebob%20Money_thumb%5B2%5D.jpg?imgmax=800)
-
Titans look sweet.
1x CIWS shot @ Racial Fire control x 4?
Note: You can do quasi-deployable PDCs by shipping small prefab PDCs. With a large invasion force you can complete PDC construction before the fighting is over, especially if it becomes a stalemate.
-
Titans look sweet.
1x CIWS shot @ Racial Fire control x 4?
Note: You can do quasi-deployable PDCs by shipping small prefab PDCs. With a large invasion force you can complete PDC construction before the fighting is over, especially if it becomes a stalemate.
Did that (even invaded with a large number construction batalions), set too high a bar (shipped in an actual PDC instead of a glorified pillbox).
-
oh God ... OGRE !
-
Is there PDC Barracks equivalent for Titans?
-
You mght want to more generically title them Scout, Battle and Siege Titans. It'll help keep GWS away.
-
I have already voiced my concerns about civilian alternatives to formerly military-only tech, but that may be just the tip of the iceberg. It adds more options to break an underlying assumption (that military ships present a logistics challenge), the bigger problem is probably the incentive to do so.
In 7.1, I already felt disposable ships (long maintenance life, use up/salvage/scrap when worn out) were often the more economically appealing option. With the changes to the maintenance system, it seems tempting to ignore that maintenance facilities even exist and put some unintuitive effort into recycling MSP.
-
WOOHOOO some ground combat love. Thanks Steve for adding more in the area.
-
What's the chance of having Titans work more as ship classes? Ie you research the various chassises and then get to put various weapons on them depending on your weapons tech?
-
What's the chance of having Titans work more as ship classes? Ie you research the various chassises and then get to put various weapons on them depending on your weapons tech?
That would be pretty neat, yeah, though will be loads more overhead in terms of programming, for a feature that'll take a lot more time to even access.
I'd still vote yes for it though, hehe.
-
Titans? Or Oges/Helltanks/CSU's.... :D
Oh the possibilities!!
-
Bolos!!
-
Exactly what my WH 40k game needs. Ive neglected posting the start because the ground battle was underwhelming.
I second Sematary's idea about customisable titans, but for now what you've got is awesome.
However I think balancing these might be difficult, coming from my experience playing certain browser games.
There's always somebody complaining that goliaths their soldiers, but others complain that goliaths just get slaughtered by mass cruiser spam anyway.
-
Why have I suddenly gotten the impression its the Japanese that are going to develop and build these first? (in steves latest campaign)
-
What's the chance of having Titans work more as ship classes? Ie you research the various chassises and then get to put various weapons on them depending on your weapons tech?
It's possible. I'll see how things work in play test and then look at more customisable options
-
Another suggestion for Titans, include an Emperor-class. This gives four weight classes, which is also handy for Battletech inspired schemes. (Light/medium/heavy/assault)
-
If going with 4 levels I would do Light (Scout), Medium (Line), Heavy (Battle), and Assault (Siege) to keep lawyers at bay :P
-
What's the chance of having Titans work more as ship classes? Ie you research the various chassises and then get to put various weapons on them depending on your weapons tech?
Yeah, I think it would be really nice if eventually titans could be designed in a similar way as ships are (perhaps with new tech lines and weapon types or adapting old techs to fit with extreme miniaturisation).
-
Excited to see work on ground units. That will make my troopships more complicated.
At one point, I wrote up a bunch of suggestions on ground combat, but I can't find them around. It's possible that post never got finished. I may have to track it down if Steve is looking at the area.
-
Will Titans have combat drop pods equivalent, to attack planets under fire? Will they be able to assault ships/PDCs?
-
Will Titans have combat drop pods equivalent, to attack planets under fire? Will they be able to assault ships/PDCs?
They won't be able to carry out boarding combat vs ships or PDCs - they are too large.
They will also have to be landed normally, rather than combat dropped.
-
They won't be able to carry out boarding combat vs ships or PDCs - they are too large.
They will also have to be landed normally, rather than combat dropped.
Can they carry out bombardment against PDCs, though?
-
Can they carry out bombardment against PDCs, though?
No, bombardment is a phase in ground combat and directed only against ground combat units. It isn't the same as bombardment from orbit.
In ground combat against PDCs, the assumption is that the ground units are actually entering the PDC to fight the defenders. Titans will be too large for that.
-
No, bombardment is a phase in ground combat and directed only against ground combat units. It isn't the same as bombardment from orbit.
In ground combat against PDCs, the assumption is that the ground units are actually entering the PDC to fight the defenders. Titans will be too large for that.
Hmm, and titans will not be able to damage the armor of PDCs either, I'm guessing? Ah well.
-
Would it be possible to include non-Titan artillery units? Act as very weak Garrison units for the purposes of ground combat, but do add firepower to bombardment?
-
While Titans have a nice cool factor going for them it's not my first pick for making ground combat fun and engaging, and as others pointed out Titans might even work better as designable "land ships". The most important thing to improve ground combat IMHO is to integrate it well with space combat and with logistics so the game feels connected and you design and plan both tactics and strategy where they can mutually support each other.
Here is what I would like to see if ground combat is the area you want to improve:
- Mechanics allowing all space beam weapons to engage units on the ground on planets with atmospheres, but very inefficiently ( maybe -95% accuracy debuff for earth thickness atmosphere ). Units get some new stuff to shoot back, see points below.
- Barrel life, all beam weapons have a base barrel life of 100 shots after which they are destroyed by combat damage automatically ( needs to be repaired by MSP/Damage control ), and a new technology is added which makes the weapon bigger in exchange for longer barrel life. This is to not make un-opposed beam fleets able to wipe out big ground defences, combined with above a basic beam weapon can only fire 5 hits on average against ground targets before it's destroyed.
- Beam Fire Controls get bombardment targeting technology so you can design them for shooting at stuff on the ground helping them hit a little bit better trading size and cost
- Light AAA/AS battalions - shoots Gauss PD at enemy ships, fighters or stuff within 10kkm range ( no or less accuracy debuff since ships make a nice silhouettes ), automatic final fire defense
- Heavy AAA/AS battalions - shoots Laser at enemy ships in range randomly, fighters or stuff using your biggest designable laser ( no or less accuracy debuff since ships make a nice silhouettes )
- SAM/SSM battalions - Can load and shoot your favorite size 1 AMMs at whatever you got lock on, appears similar to PDCs as a single unit per planet with as many tubes as you got battalions and has your missile reload rate.
- Fighters get a module (starting at 100ton and made smaller by tech) allowing them to fly inside the atmosphere ( fight with all weapons without the accuracy debuff )
- Fighters get a damage buff vs Titans and become a great "Anti titan" weapon
- All ground units hit by fighters fire back in self defense and have 10% chance to inflict 1 point of damage per attack run
- Ammo/Supplies for ground units. All ground units need ammo & supplies produced so you can't fight forever without supply-lines open. If the ammo is not stored in PDC it appears as a valid target for enemy space sensors and can be targeted and destroyed, but ammo carried by units is dispersed so can't be hit.
- Sensible rules for transport of ground units so Light/Garrisons can be transported easily, but heavy assault needs much more space and time to load/unload for their heavy stuff.
- Ability to transport all "light" infantry units on board your warships ( risking overloading their life support unless they have spare berths ) for emergency evacuations or un-opposed invasions.
-
I honestly would like to see something similar to what I did in Astra Imperia. The base unit is an infantry company. From there you add-on capabilities for cost and size to get your armor, assault infantry, etc. This would be more in keeping with the complete customizations in Aurora I think :)
-
I agree that weapon wear having maintenance requirements would be interesting, would be difficult to avoid making that excessively tedious though I think.
-
While Titans have a nice cool factor going for them it's not my first pick for making ground combat fun and engaging, and as others pointed out Titans might even work better as designable "land ships". The most important thing to improve ground combat IMHO is to integrate it well with space combat and with logistics so the game feels connected and you design and plan both tactics and strategy where they can mutually support each other. [...]
I tend to agree. Ground combat is mostly static, either you bombard them to hell or you keep dropping troops until you win. And customize able titans will have no effect on that. Although a lot of work, your suggestion seem interesting, i like that tried to balance all aspects (my first thought after reading #1 was "no way" I'll just park my fleet in orbit and shoot endlessly and then I read #2.. )
-
i just hope there's a Titan Barracks so i can have big stompy robots charge out of the underground bunkers into an apocalyptic wasteland
and probably get blown up by missiles but hey TANJ
-
i just hope there's a Titan Barracks so i can have big stompy robots charge out of the underground bunkers into an apocalyptic wasteland
and probably get blown up by missiles but hey TANJ
Well a PDC should, I would think, be able to mount a Titan Hangar module or 20 ;D
-
I agree that weapon wear having maintenance requirements would be interesting, would be difficult to avoid making that excessively tedious though I think.
Might need some TG orders or a button somewhere to "queue repair all" for entire fleet if they don't already exists somewhere.
i like that tried to balance all aspects (my first thought after reading #1 was "no way" I'll just park my fleet in orbit and shoot endlessly and then I read #2.. )
I'm sure there are some other better ways of doing it, but the main way to balance Ground combat units vs Space bombardment should be the same as historical reasons shore emplacement guns and defenses was undesirable to approach by warships.
That means it must be much cheaper to field the same guns/weapons on the ground, and they must be much harder to hit or knock out. You could also add some more details to how minefields work or have some type of extremely cheap fighters that can buzz out from PDC hangars and harass bigger ships attempting bombardment. ( Inspired by historical balance of minefields and torpedo boats used in shore defense ).
Another way to approach the problem is adding some mechanics to make life more difficult for warships, like fires spreading out of control or loss of pressure disabling certain crewed areas temporarily, which won't be as big of a risk in a PDC or ground based gun system that can be more spread out.
-
PDCs already have huge advantages over ships, ton for ton.
-4 layers of free armor
-double fire rate missile launchers
-superior beam fire controls
and additionally the advantages of no maintenance, automatic task force training, 'infinite magazines', and atmospheric beam interference.
PDCs are fine ;)
-
But then they're static, which mean if the enemy outrange them, they're as good as useless.
-
PDCs already have huge advantages over ships, ton for ton.
...
PDCs are fine ;)
Indeed, and thus my suggestions did not include any direct buffs to PDCs either, except adding the ability to use beam defense non-meson PDCs on planets with atmospheres ( but that one goes a bit both ways since they are no longer immune vs ships either ).
-
For storytelling elements it might be interesting to (in SM Mode) be able to delete researched technology. So literally bombarding someone back into stone age :-)
-
I tend to agree. Ground combat is mostly static, either you bombard them to hell or you keep dropping troops until you win. And customize able titans will have no effect on that.
I disagree. A customizable titan could be anything from a Commander unit from the Supreme Commander series, to an Experimental Land Battleship/Mobile Factory from the same series, or the UFO from After series or XCOM 2, a Jaeger/BattleMech from any anime or a giant Mech Warrior.
Giving the Titan additional abilities, like being stealthed, more artillery, Surface to Orbit weapons, mobile factories, mobile barracks or being completely amphibious, would give each titan it's own flavour in the battlefield.
-
I'm going to try to sketch my ideas for ground combat revision. This has been simmering for a couple of years.
There are three bits that I'd like to see. First, more granularity in ground combat. At the moment, taking over a planet is binary, either you have it or you don't. It might be nice if larger planets had multiple sub-sections which you could conquer one at a time. Some form of terrain system might be a good idea, too. Divide the planet into 'urban' and 'rural' sections. The rural section has a specific type, be it 'desert' or 'forest' or 'sea'. This influences the effects of different unit types.
Second, combined arms. At the moment, all ground units have two values, attack and defense. And that's all. A heavy assault battalion is better than any other battalion, and costs the same to move. Instead, define a dozen or so different types of 'combat power', and rate each unit on them. Some suggestions:
Infantry
Mobility
Armor
Artillery
Engineering
Air
Anti-Armor
Anti-Air
Recon
Fortification (granted by being dug in, not inherent)
Naval
Command and Control
Logistics (maybe)
These interact to give bonuses or penalties in combat, depending on situation, with combined arms being required to gain victory. Some types of units would do better than others in various terrains. For instance, infantry is more important in urban terrain, unless you just want to destroy everything. (And avoiding damage to their infrastructure would be a reason for the defender to deploy forces in the Rural part of the planet.) And infantry is the only thing (except maybe engineers) which can perform boarding actions and the like.
Third, more customization of units, interacting with the combined arms stuff. Let's say we have a dozen or two different elements which are used to build units. These are generally platoons or companies, and research improves each of them separately. (Maybe there'd be level techs to unlock a tier and then individual techs below that, so you can't just blitz one line, while not making thins unduly expensive.) So you might garrison mining outposts with a battalion made of three infantry companies and a logistics element, while the 1st Armored Brigade would have three mechanized infantry companies, six armored companies, three artillery batteries, three companies of cavalry scouts, and so on.
Obviously, you'd have various types of transport to deal with this. Maybe 'personnel', 'light' and 'heavy'. 'Heavy' covers things like naval units and titans, while 'light' is anything up to tanks.
I hope that's coherent enough.
-
I disagree. A customizable titan could be anything from a Commander unit from the Supreme Commander series, to an Experimental Land Battleship/Mobile Factory from the same series, or the UFO from After series or XCOM 2, a Jaeger/BattleMech from any anime or a giant Mech Warrior.
I'm pretty sure that complaint was about combat game mechanics... not about what kind of RP it opens up.
-
Would it be possible to include non-Titan artillery units? Act as very weak Garrison units for the purposes of ground combat, but do add firepower to bombardment?
The one unit missing at the moment IMHO is an AAA unit. Within the current mechanics I would favour a meson based transportable unit which could reach near Earth orbit (out to approximately 50,000k), intercept incoming missiles and possibly have a chance of intercepting any ground units being dropped onto a planet. At the moment I don't use combat drop modules as there is no real need to. But if the chance of interception was 100 x greater or my troop ships would have to come under fire to land them and a combat drop module could insert them from say 100,000k I certainly would use them.
If you want more a complex division of ground units that could come later with a complete re-write of ground combat. I could see the unit above being viable under the current system.
-
If we're talking ground combat dreams, it would be cool to have the option for atmospheric fighters that could fight in space normally or support ground combat. But that's really more fluff and might not be worth adding.
I do like the idea of weapons eventually breaking. It doesn't necessarily have to be a tracked number of shots; it could just be a 5% or whatever chance to burn out when fired, then if you wanted more "endurance" on your beam weapons you could just add more MSP storage. It would mean one small ship with a range and speed advantage couldn't destroy a million tons of warships just by sitting out of range.
-
Also, if ground combat is getting a look at, I would love to see the "beam" weapon atmo penalty removed from Railguns and Gauss weapons.
I wanna use some Rods from God on ground based targets! ;D
-
the atmospheric penalty exists for a reason: so you can't glass a world essentially for free.
Trying to balance it by making beam weapons have ammo or reliability issues would be a severe nerf to beam weapons relative to missile ships, as their primary strategic advantage is not having to deal with such problems like missile ships do. Additionally, since NPRs do not deal with maintenance, they would not suffer any such problems. Finally, even if a reliability mechanic were implemented along with removal of the atmospheric penalty, it's likely it would not have much impact on decision making; the damage required to cripple a plausible ground force is not really that high.
-
I think if Steve makes any improvements to ground that would be hugely beneficial and fun. This is only for creative juices for you Steve but titans might be as far as you go which I am cool with as well.
The whole attack defence current game is nice but does not allow for different outcomes. I do like to think that planetary types can influence battle e.g We can finally use water field on the planet (The higher the water level the better infantry works over heavy assault. Aka more trees or river courses to defend)
Also I would like options Probe, Defend, Attack and Assault. These scale up the casualties,
Also it be nice to be attacked by the NPR on occasions, especially when it notes the first landings to attack instead of allowing the player to create a bridgehead.
Lastly using maintenance supplies, as resources if it runs out the readiness level drops. Combat uses supplies, however there is a minimal supply needed. I woulfd use the maintenance supplies so not to create new mechanics.
-
Finally, even if a reliability mechanic were implemented along with removal of the atmospheric penalty, it's likely it would not have much impact on decision making; the damage required to cripple a plausible ground force is not really that high.
That is the issue here. Being able to find or hit dug in troops, especially in a world with vegetation and terrain that can be used as cover should be extremely hard, but not impossible. Especially not if you have troops or fighters spotting them and can cooperate with combined arms.
-
Much harder todo if they are hiding in "plain sight" (urban areas) especially if you want to take the population and industrial base unharmed.
Also, what about something like attrition? Steve said he is adding some sort of independence mechanic, what if recently subjected world that was insufficiently defended would revolt and rejoin their former masters.
-
Alternatively, you could just glass the world and start anew.
-
I'm sorry if someone mentioned this earlier, it's quite a long topic, but how will the new structural shell interact with nebulae? I know you can't have engines on those constructs, but you can still tow them to their intended location, so will that be possible or will this cause some errors?
-
I'm sorry if someone mentioned this earlier, it's quite a long topic, but how will the new structural shell interact with nebulae? I know you can't have engines on those constructs, but you can still tow them to their intended location, so will that be possible or will this cause some errors?
As 1 layer of armor.
-
I'm sorry if someone mentioned this earlier, it's quite a long topic, but how will the new structural shell interact with nebulae? I know you can't have engines on those constructs, but you can still tow them to their intended location, so will that be possible or will this cause some errors?
Good question - I'll take a look at that but I suspect it will act as 1 armour.
-
re: particle lance
looks swag, i often prefer particle beams. Maybe too swag. My first impulse is to say size should be 3x. The superior armor penetration is super nasty...
Maybe the Brazilians will end up buying some to put on their ships ;)
Although, a question: does it count as a spinal weapon or not?
-
re: particle lance
looks swag, i often prefer particle beams. Maybe too swag. My first impulse is to say size should be 3x. The superior armor penetration is super nasty...
Maybe the Brazilians will end up buying some to put on their ships ;)
Although, a question: does it count as a spinal weapon or not?
Not at the moment. I will see how effective it is during play testing.
-
The Particle Lance is intended as a powerful anti-ship weapon that requires a large investment in a particular tech line, lacks the flexibility of lasers or railguns and provides a different armour penetrating option to mesons, although mesons are still superior against shields. Mainly though it is to boost the Particle Beam as a serious weapon choice
Seems promising !
-
I saw particle lance and immediately though Nova Cannon from W40K, I desire this weapon immediately.
-
Will Advanced Particle Beam tech progress trigger the Particle Lance?
-
I think its meant to work like the spinal laser, so it draws from the normal particle beam tech.
-
Will Advanced Particle Beam tech progress trigger the Particle Lance?
No, it's just from the normal tech progression.
-
Back in 6.43 there was a bug that if you had only orbital maintenance bases those would not reload your box launchers. If you had even one fully manned ground based maintenance facility, everything was fine. Has this bug been fixed? From what I have seen from your campaign you're not using box launchers so I don't know if you tried reloading them in one of your deep space bases.
-
Back in 6.43 there was a bug that if you had only orbital maintenance bases those would not reload your box launchers. If you had even one fully manned ground based maintenance facility, everything was fine. Has this bug been fixed? From what I have seen from your campaign you're not using box launchers so I don't know if you tried reloading them in one of your deep space bases.
Can't you load box launchers from colliers? As of the new version, we will be getting civilian ammo storage, which means you could set your maintenance base (or a miscellaneous civilian transport/storage ship) as a collier and load it like such with their mounted magazines, precluding needs for maint-loading, though if that is restricted, you could likewise make a military collier and have it be maintained by the maintenance modules.
-
You can reload the ammo of a box launch ship from colliers, but the reload timer won't tick down without being at a hangar or maintenance facility. It's a valid question.
-
So i have to just unlock the patricle lance right? Thus i could make a relativly light craft with a small 4 DMG particlelance and quick cycling?
If so that could make a nice fast gunboat against the Spoilers which makes me love this idea even more.
-
So i have to just unlock the patricle lance right? Thus i could make a relativly light craft with a small 4 DMG particlelance and quick cycling?
If so that could make a nice fast gunboat against the Spoilers which makes me love this idea even more.
Once Particle Beam Range 200,000 km and Particle Beam Strength 6 have both been researched, the Particle Lance can be researched for 30,000 RP. You will be able to, but you'll need to research your particle beam tech to those levels, first. That's a lotta RP, so expect that to come into play more mid game.
Lances at that size, though, they'll only reliably outperform particle beams against ships with 3 or less armor layers, as the smaller particle beams require less power plant or capacitor tech to cycle more quickly. The particle beams in tandem will also out-damage the lance against shields.
The lances are really most profitable in cracking apart large, decently armored ships from a large range in a single shot, which require a decent amount of power to do. In this manner, they outperform mesons, as they leave burnt-out columns in the armor of the ship, and dump all of the damage they do in excess of armor thickness into the hull of the ship. Shields look to be extremely effective against them, though, as shields take the full brunt of the shot before they start to penetrate.
A good offensive application would be some variety of long (beam) range lasers and size 1 missile pepperboxes on the shield, followed by a lance when the shield is down for massive damage.
I actually wonder if particle lances do shock damage.
-
The Particle Lance looks good to me. The first hit can inflict significant damage to ships and destroy/cripple armoured fighters at range.
Sustained damage per increment will be very poor, so it has a natural counter in shields.
They seem to have uses at all sizes - small ones for decent DPS though armour, large ones for one-shotting things (I could imagine building them with capacitor 1 to keep costs down, counting on one salvo to be enough). All in all, I expect them to be attractive without being overpowered, sufficiently different from existing weapons, and good for the game's depth.
*
The changes to the maintenance system still make me very nervous. I already find some use for disposable ships (long maintenance life, use without overhaul until obsolete or worn out, then scrap or salvage). So far it's a niche option for ships that need to stay in deep space, which is great - alternative ways to build things depending on requirements.
With the stated changes, I fear that it may be best to ingore the whole maintenance aspect and make everything disposable or hangar-based (minimising MSP usage). At that point, we may as well play with maintenance off as it no longer adds anything to the game, just encouraging one to jump through hoops to bypass the system and limiting viable options... maintenance off may well become the deeper and better-balanced option. I'd hate for that to happen, as I enjoy the logistics aspect of the game.
-
The changes to the maintenance system still make me very nervous. I already find some use for disposable ships (long maintenance life, use without overhaul until obsolete or worn out, then scrap or salvage). So far it's a niche option for ships that need to stay in deep space, which is great - alternative ways to build things depending on requirements.
With the stated changes, I fear that it may be best to ingore the whole maintenance aspect and make everything disposable or hangar-based (minimising MSP usage). At that point, we may as well play with maintenance off as it no longer adds anything to the game, just encouraging one to jump through hoops to bypass the system and limiting viable options... maintenance off may well become the deeper and better-balanced option. I'd hate for that to happen, as I enjoy the logistics aspect of the game.
I'm not quite sure how the new system is an issue at all. It actually makes maintenance EASIER to play with than before, far as I know, or at least easier to manage, while still enforcing a supply lane and logistics requirement for your vessels, especially now without having to micromanage which minerals need to make it to your ships.
Where's the issue, again?
-
Now, I hope I'm just misunderstanding something and someone can prove me wrong.
The new system makes it easier as it makes it easier to work around mineral shortages at a maintenance site, and that's a good thing.
But between increased maintenance/overhaul costs (minor) and the initial load of maintenance supplies having to be built/purchased (major), it's now attractive to build ships that need very few MSP during their entire service life.
At the moment, a maintenance storage bay that comes with 1000MSP has a cost of 15.
In 7.2, the contents alone will cost 250.
Maintenance Storage Bays already saw limited use in non-supply-vessels (they were somewhat viable in very cheap craft where engineering bays added few MSPs).
With the extreme cost increase of MSPs, we are given strong incentives to drastically lower their consumption. I can think of plenty, and have practical experience with some for my deep space fleets. Unfortunately, many of the ways to do so are fiddly, a little gamey, or attempt to bypass the maintenance system entirely,
The changes seem to aim for reduced micromanagement and giving us new interesting options. Unless we play extremely suboptimally, my concern is that they will increase micromanagement and limit viable options.
-
The only difference is that upon delivery maintenance storage bays don't come with supplies included (like magazines). Meaning that your initial cost to bring the ship to full readiness is highers, and you need to keep a higher supply reserve, or you might find your new ships stuck in port.
it doesn't effect consumption or your mission parameters, so I don't see why it would be an incentive to build ships with less MSP. But it is possible that maintenance storage bay are too costly right now.
-
MSP usage increases with maintenance clock, with plenty of engineering spaces you get by with very little for years.
It's now attractive to use excessive engineering spaces, offload MSP to new ships once things start to fall apart, and scrap the ship.
Probably never bothering with overhauls or in-orbit maintenance.
-
MSP usage increases with maintenance clock, with plenty of engineering spaces you get by with very little for years.
It's now attractive to use excessive engineering spaces, offload MSP to new ships once things start to fall apart, and scrap the ship.
Probably never bothering with overhauls or in-orbit maintenance.
I agree somewhat. In orbit maintenance cost MSP by size, not by failure rate, and as such, is worse than engineering space. And kinda exclusive with each other. There is no point in reducing failure rate if you pay by size anyway, so ships staying in orbit of maintenance facilities do not need much engineering. On the other hand, ships with a lot of it should avoid orbiting because they'll cost you a flat rate despite their low failure rate. Having to avoid maintenance facilities when optimized for long missions seems weird to me.
MSP cost of maintenance when in orbit should maybe depend on ship failure rate? It wouldn't solve the maintenance storage issue, but it would make orbital maintenance less counter intuitive in that crafts designed for reliability should cost less to maintain, be it in orbit or in space.
To solve the maintenance storage issue, adding stacking penalties to engineering modules when above a certain rate compared to ship size would probably help. Using more engineering space should be design-costly and valuable mostly long term.
I disagree with you about overhaul though. If you do it early enough (before things start breaking too much), even a craft with lots of engineering could benefit from it.
EDIT: unrelated, about particle lances:
I feel being bigger should maybe increase range of the beam, rather than just damage. Right now, it's just a gun with twice the damage for twice the size, but doesn't really offer new tactical opportunities compared to particle beams. Being x1. 5 range x1. 5 damage could possibly be more interesting. Just my opinion.
-
@Iranon, the maintenance clock mechanic hasn't been changed. Everything works just as before. Only instead of ships in orbit using raw minerals as % of build cost, now you are using supplies as % of build cost (which are built with minerals); and that your cargo hold don't come full on delivery, you just need to load them.
The goal of # is reduced micro (having to move\track of multiple raw material vs supplies) and increased realism that in 99.99% would have no effect on gameplay.
-
@Iranon, the maintenance clock mechanic hasn't been changed. Everything works just as before. Only instead of ships in orbit using raw minerals as % of build cost, now you are using supplies as % of build cost (which are built with minerals); and that your cargo hold don't come full on delivery, you just need to load them.
The goal of # is reduced micro (having to move\track of multiple raw material vs supplies) and increased realism that in 99. 99% would have no effect on gameplay.
True. The maintenance load not being there initially weights heavily against storing more and towards using more engineering, though. Maintenance storage in itself is cheap, but it's load isn't, compared to the alternative.
-
True. The maintenance load not being there initially weights heavily against storing more and towards using more engineering, though.
Yes, you wont be able to pay 7.5 Neutronium for Maintenance storage bay and get:
Duranium 50
Neutronium 12.5
Tritanium 25
Boronide 25
Mercassium 25
Sorium 12.5
Uridium 25
Corundium 25
Gallicite 50
worth of supplies.
Maintenance storage in itself is cheap, but it's load isn't, compared to the alternative.
What you are arguing is that maintenance storage bay aren't cost effective now, and it better invest in the alternatives. Maybe, but i doubt that they will be as effective in combat.
EDIT: btw, do you guys use overhuals?
-
EDIT: unrelated, about particle lances:
I feel being bigger should maybe increase range of the beam, rather than just damage. Right now, it's just a gun with twice the damage for twice the size, but doesn't really offer new tactical opportunities compared to particle beams. Being x1. 5 range x1. 5 damage could possibly be more interesting. Just my opinion.
You missed something important about them. That being their damage profile and increased damage. Specifically, the particle lance will have twice the power of a normal particle beam, but it will be the only armor-mitigated weapon that pierces armor as many layers equal to it's damage, and dumps the remainder into the hull. And it has the highest armor penetration of this sort at range, too. So if you're using a strength 10 particle lance against strength 6 armor, a single shot will dump 4 points of damage into the hull and leave a straight hole in the armor, while two size 5 particle lances of the same size will fail to penetrate until two shots overlap sufficiently well.
-
yep, this is the equivalent of "tanks" vs "tank destroyers", one has higher damage while the other high penetration, both are used to exploit different tactical opportunists. Assuming that you know how much armor each enemy got.
Speaking of, what do I need to do to get that damn armor info in tactical?!
-
Shoot them with different powered warheads as far as I can figure. There is a notification when you get penetration, so if you score a strength four warhead hit and dont get atmosphere streaming, the game automatically deduces for you that they have at least two-thickness armor. Etc.
Somebody else may have more detailed knowledge of how that works.
-
To solve the maintenance storage issue, adding stacking penalties to engineering modules when above a certain rate compared to ship size would probably help. Using more engineering space should be design-costly and valuable mostly long term.
Long-deployment ships don't feel overpowered for their main non-gamey use at the moment, so that suggestion isn't without its problems.
Excessive engineering, hangars for everything, offloading engines to commercial tugboats, a few others that escape me at the moment...
there are multiple ways to decrease the maintenance burden and increased number of civilian components will add some more. At the moment, they fall under "interesting option, probably not for general use" rather than "favoured over conventional ships".
Do we really want to cripple them all "because you're supposed to play the game in a specific way, dammit!" ?
@Iranon, the maintenance clock mechanic hasn't been changed. Everything works just as before. Only instead of ships in orbit using raw minerals as % of build cost, now you are using supplies as % of build cost (which are built with minerals); and that your cargo hold don't come full on delivery, you just need to load them.
The goal of # is reduced micro (having to move\track of multiple raw material vs supplies) and increased realism that in 99.99% would have no effect on gameplay.
Did I ever claim the clock mechanic changed?
Fomerly, the value of maintenance facilities was to keep the clock down, MSPs themselves were cheap. The value of MSPs has increased greatly, and ships consume most of their MSP towards the end of their maintenance life, so now it's a terrible idea to actually use your full maintenance life.
At best, we're now incentivised to have our maintenance life be multiple times our deployment time. At worst, we're incentivised to ignore/break/play around the entire maintenance system because maintaining things became a lot more expensive.
The goal may well be to reduce micro and add realism... but that will only happen if players stick to old habits even though they're now horrifically inefficient.
-
Now, I hope I'm just misunderstanding something and someone can prove me wrong.
The new system makes it easier as it makes it easier to work around mineral shortages at a maintenance site, and that's a good thing.
But between increased maintenance/overhaul costs (minor) and the initial load of maintenance supplies having to be built/purchased (major), it's now attractive to build ships that need very few MSP during their entire service life.
At the moment, a maintenance storage bay that comes with 1000MSP has a cost of 15.
In 7.2, the contents alone will cost 250.
Maintenance Storage Bays already saw limited use in non-supply-vessels (they were somewhat viable in very cheap craft where engineering bays added few MSPs).
With the extreme cost increase of MSPs, we are given strong incentives to drastically lower their consumption. I can think of plenty, and have practical experience with some for my deep space fleets. Unfortunately, many of the ways to do so are fiddly, a little gamey, or attempt to bypass the maintenance system entirely,
The changes seem to aim for reduced micromanagement and giving us new interesting options. Unless we play extremely suboptimally, my concern is that they will increase micromanagement and limit viable options.
The problem is that in the current version (v7.1) it is cheaper to build a ship with maintenance storage bays and then empty them than to build the equivalent value of MSP, which makes no sense. Because MSP are much more important in v7.2, I had to remove that anomaly.
-
Long-deployment ships don't feel overpowered for their main non-gamey use at the moment, so that suggestion isn't without its problems.
Excessive engineering, hangars for everything, offloading engines to commercial tugboats, a few others that escape me at the moment...
there are multiple ways to decrease the maintenance burden and increased number of civilian components will add some more. At the moment, they fall under "interesting option, probably not for general use" rather than "favoured over conventional ships".
Do we really want to cripple them all "because you're supposed to play the game in a specific way, dammit!" ?
Did I ever claim the clock mechanic changed?
Fomerly, the value of maintenance facilities was to keep the clock down, MSPs themselves were cheap. The value of MSPs has increased greatly, and ships consume most of their MSP towards the end of their maintenance life, so now it's a terrible idea to actually use your full maintenance life.
At best, we're now incentivised to have our maintenance life be multiple times our deployment time. At worst, we're incentivised to ignore/break/play around the entire maintenance system because maintaining things became a lot more expensive.
The goal may well be to reduce micro and add realism... but that will only happen if players stick to old habits even though they're now horrifically inefficient.
MSP are the same cost as before. Maintenance works the same way as before (except you can now have maintenance facilities in deep space). Ships use about 25% more MSP for maintenance and overhauls, plus they need to load their MSP at launch in the same way as fuel. However, unlike in v7.2, they can use their onboard MSP for maintenance if the naval base at which they are stationed runs out of supplies. None of these factors is influencing how I build my warships in my current campaign.
So far in my current campaign I have found that maintenance is more important than before and I am more aware of it, but that managing it is much easier. For a couple of nations I have built fighter-size maintenance vessels that can shuttle MSP around bases (because SY were tied up and couldn't build supply ships). Tankers are becoming replenishment ships with both fuel and supplies. Forward bases are easier because you only have to worry about shipping in maintenance facilities and supplies. Ensuring MSP for the future is much more important. I am finding that maintenance facilities should be building MSP by default (treat them like fuel refineries) and occasionally supported by construction factories if a lot of ships are being overhauled at once.
With maintenance logistics becoming much important and with more options in terms of commercial support, I have started building more specialised support ships. Here are two classes currently under construction by the Commonwealth, one to support survey ships and one to support warships, plus one of the fighter-sized ships I mentioned.
**************************************************************************************
Amethyst class Survey Support 36,000 tons 172 Crew 1346 BP TCS 720 TH 1440 EM 0
2000 km/s JR 2-25(C) Armour 2-97 Shields 0-0 Sensors 1/11/0/0 Damage Control Rating 1 PPV 0
MSP 5023 Max Repair 37 MSP
Intended Deployment Time: 3 months Spare Berths 1
Magazine 200 Cryogenic Berths 400
JC36K Commercial Jump Drive Max Ship Size 36000 tons Distance 25k km Squadron Size 2
Rolls Royce HE-240 Commercial Magneto-plasma Drive (6) Power 240 Fuel Use 1.48% Signature 240 Exp 3%
Fuel Capacity 8,250,000 Litres Range 2787.2 billion km (16129 days at full power)
CIWS-160 (2x6) Range 1000 km TS: 16000 km/s ROF 5 Base 50% To Hit
Ryan Techsystems RTN-25 Navigation Sensor (1) GPS 2520 Range 25.3m km Resolution 120
EM-11 Passive Detection Sensor (1) Sensitivity 11 Detect Sig Strength 1000: 11m km
**************************************************************************************
Reliant class Replenishment Ship 37,200 tons 256 Crew 2007 BP TCS 744 TH 2400 EM 0
3225 km/s Armour 1-99 Shields 0-0 Sensors 1/8/0/0 Damage Control Rating 1 PPV 0
MSP 6034 Max Repair 100 MSP
Intended Deployment Time: 3 months Spare Berths 0
Magazine 1600
Rolls Royce Commercial Magneto-plasma Drive (6) Power 400 Fuel Use 5.3% Signature 400 Exp 5%
Fuel Capacity 10,000,000 Litres Range 912.7 billion km (3275 days at full power)
Perseus Anti-ship Missile (400) Speed: 32,000 km/s End: 65.3m Range: 125.3m km WH: 6 Size: 4 TH: 106/64/32
Navigation Sensor (1) GPS 1920 Range 10.5m km Resolution 120
EM-8 Passive Detection Sensor (1) Sensitivity 8 Detect Sig Strength 1000: 8m km
**************************************************************************************
Phoebe class Maintenance Vessel 435 tons 4 Crew 48 BP TCS 8.7 TH 32 EM 0
3678 km/s Armour 1-5 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 0 PPV 0
Maint Life 17.48 Years MSP 1000 AFR 87% IFR 1.2% 1YR 6 5YR 93 Max Repair 10 MSP
Intended Deployment Time: 3 months Spare Berths 2
Shuttle Engine (2) Power 16 Fuel Use 59.4% Signature 16 Exp 10%
Fuel Capacity 50,000 Litres Range 34.8 billion km (109 days at full power)
**************************************************************************************
-
You missed something important about them. That being their damage profile and increased damage. Specifically, the particle lance will have twice the power of a normal particle beam, but it will be the only armor-mitigated weapon that pierces armor as many layers equal to it's damage, and dumps the remainder into the hull. And it has the highest armor penetration of this sort at range, too. So if you're using a strength 10 particle lance against strength 6 armor, a single shot will dump 4 points of damage into the hull and leave a straight hole in the armor, while two size 5 particle lances of the same size will fail to penetrate until two shots overlap sufficiently well.
Missed that, thanks. Yes, it makes them much more interesting! I will have to try them.
-
I'm backing Steve on this one. At the moment, it's next to impossible to run the logistics system to its full potential, at least on the attention span I have. My current flagship game is full of interesting maintainence ships that I'm not using because I don't want to figure out which minerals to take. Being able to just ship MSP is going to mean I'll actually use them.
Also, Steve, what's with this 7.32 stuff? What happened to 7.2?
And when do we get it?
-
It seems like a very sensible change.
-
Again: Standardising on MSP instead of mineral isn't the problem, and it's a good thing. Cost and necessity is the problem.
MSP were always too expensive to bother with and I never built any. Maintenance Facilties themselves were also iffy, many reasonable ships were better off avoiding them. Maintenance Storage Bays were actually costed reasonably - just play around how they compare to additional engineering bays in the ship design window. Yes, being able to put them on civilian supply ships now would be nice... but that's worthless when they become over 15 times as expensive.
Unless I gravely misunderstand something, forward maintenance will still not be worthwhile... and that's because no maintenance will be worthwhile. Hangars (mostly PDC, the occasional towed hangar pod for flexibility and systems that lack convenient bodies) for anything expensive that doesn't need to be out most of the time, odd designs to minimise MSP use for those that do, and aggressive scrapping will be more efficient.
I think I'm starting to repeat myself, and not really convincing anyone. Would it be more productive if I shut up for now, and post my experience and how they match with my concerns after the new version is out?
-
Is there a reason why in 7.2 when a ship is built it will come with zero MSP? This seems to add an extra micro layer by having to load them before setting off. If we have enough MSP on the planet where a ship is built can they not simply pull out of the yard fully loaded the same way fuel already works?
-
I think I'm starting to repeat myself, and not really convincing anyone. Would it be more productive if I shut up for now, and post my experience and how they match with my concerns after the new version is out?
I think the problem is that you're arguing that this change encourages players to utilize loopholes and exploits - which is a pointless endeavour because
A) it's a single player game and who someone plays it is entirely up to them,
B) you can already toggle maintenance completely off and,
C) any- and everyone can use Space Master mode to "cheat" as much as they want for whatever reason they want.
I'm sorry if I come across harsh but you're not the first one to misunderstand the nature of Aurora and try to treat it as a competitive multiplayer game that lives or dies on being perfectly balanced. There is no balance in Aurora and there shouldn't be. If you find yourself constantly min-maxing everything in your game and using a bunch of exploits and tricks to gain advantage, you should step back and evaluate the entertainment value that you're getting. The AI is not capable of defeating a human player in the first place.
-
I think the problem is that you're arguing that this change encourages players to utilize loopholes and exploits - which is a pointless endeavour because
A) it's a single player game and who someone plays it is entirely up to them,
B) you can already toggle maintenance completely off and,
C) any- and everyone can use Space Master mode to "cheat" as much as they want for whatever reason they want.
I'm sorry if I come across harsh but you're not the first one to misunderstand the nature of Aurora and try to treat it as a competitive multiplayer game that lives or dies on being perfectly balanced. There is no balance in Aurora and there shouldn't be. If you find yourself constantly min-maxing everything in your game and using a bunch of exploits and tricks to gain advantage, you should step back and evaluate the entertainment value that you're getting. The AI is not capable of defeating a human player in the first place.
Well, to match their playstyle, they could very well jack up the occurrence ratios and difficulty ratings of AIs.
-
Is there a reason why in 7.2 when a ship is built it will come with zero MSP? This seems to add an extra micro layer by having to load them before setting off. If we have enough MSP on the planet where a ship is built can they not simply pull out of the yard fully loaded the same way fuel already works?
Because if you add a maintenance module, you are currently getting a large amount of MSP that costs far less than if you produced them. Free MSP in ships is the equivalent of building a really large fuel tanker and getting a free load of fuel. Why bother building fuel refineries and fuel harvesters when it would be cheaper to build tankers with free fuel?
And yes, if there are available MSP on the colony where the ship is built, those MSP will be added automatically in the same way as fuel.
-
I like to prod at and test the limits of game mechanics, competitive game or sandbox. This kind of thing probably troubles me more than most because my preference even in sandbox games is either "experiment and learn" or "play hard, set high challenges"... Aurora so far is able to satisfy both. Incidentally, the first may include exploring cohesive themes, not unlike a roleplaying approach.
One thing I found very cool so far is that making use of quirks (call them loopholes or exploits if you want) is situationally useful and absolutely not required to play an efficient game.
If using hangars to cut down on running costs is an exploit, the game is broken because exploiting is the norm. If we are strongly encouraged to systematically circumvent a core mechanic (maintenance) by using something that's fair in itself (hangars), the game is also broken.
I don't think the argument of "it's a sandbox, you can cheat anyway, who cares if players have to consciously hold back to make the game work as designed" holds water. Of course these games can be great fun when not playing your hardest, perhaps more so than approaching them with a challenge mindset. But if we need to wilfully ignore how things actually work for the mechanics to hold, the glorious depth becomes fake depth imo.
-
I like to prod at and test the limits of game mechanics, competitive game or sandbox. This kind of thing probably troubles me more than most because my preference even in sandbox games is either "experiment and learn" or "play hard, set high challenges"... Aurora so far is able to satisfy both. Incidentally, the first may include exploring cohesive themes, not unlike a roleplaying approach.
One thing I found very cool so far is that making use of quirks (call them loopholes or exploits if you want) is situationally useful and absolutely not required to play an efficient game.
If using hangars to cut down on running costs is an exploit, the game is broken because exploiting is the norm. If we are strongly encouraged to systematically circumvent a core mechanic (maintenance) by using something that's fair in itself (hangars), the game is also broken.
I don't think the argument of "it's a sandbox, you can cheat anyway, who cares if players have to consciously hold back to make the game work as designed" holds water. Of course these games can be great fun when not playing your hardest, perhaps more so than approaching them with a challenge mindset. But if we need to wilfully ignore how things actually work for the mechanics to hold, the glorious depth becomes fake depth imo.
I'm very confused by this. You're suggesting that this is going to significantly move the balance away from the regular maintainence cycle and more towards 'life of the ship' designs? Maintenance is going to become very slightly more expensive, and this is going to break the game somehow? 'Life of the ship' has its place, certainly, but it's going to become at best maybe 10% more cost-effective than it is now. Pretty much the same numbers apply to hangars. Why is that 10% going to turn the current 'glorious depth' into 'fake depth'?
Let's put some numbers on this. A ship parked in orbit requires cost/minerals equal to those required to build it every 16 years. Counting only MSP used during the overhaul itself, the same numbers apply to a ship that is deployed and overhauled regularly. (Thsi is counterintuitive, but correct. Say that the vessel is deployed for 3 years, then overhauled for one year. During this time, it will spend three years using no MSP from the base, and then one year during which it spends 25% of the cost in MSP cost. Averaged, that's the same as remaining in orbit.) Obviously, it will use MSP to repair any failures it may experience during its service life, but that number varies a lot depending on how it is used. How much extra would it cost to build a life-of-ship design, over one designed to be regularly serviced? How much does a PDC hangar cost to build? Yes, it lasts forever, but you can't assume that you won't need to build bigger ones regularly. Unless the ship is absurdly expensive, payoff will be on the order of 10 years. And crew training means you need to send your ships out fairly frequently anyway. I don't see this being an obvious hole in the game that players have to deliberately ignore.
-
I'm astounded that the current debate about the change is mostly complaints about or defence of Steve finally closing the free maintenence exploit rather than the actual mechanics change, it was inevitable really but amongst all the things needing work I can see why it wasn't fixed untill steve actually noticed the problem.
I'm sure testing will find out if maybe MSP is too expencive now, and changes will be made, steve was willing to do such with fuel refineries quite a long time after the engine changes which made it required.
As far as the mechanics change, I had in my last game in 7.1 finally gotten around to making my first ever minor maintenence bases, each was set up in systems that had the required minerals available to be mass driven to the base. A few times I discovered that a new class of ship sent there required a new resource, often that needed to be shipped in, from my perspective the new system is less micromanagement because those bases always had small MSP stockpiles too. However similar setups in 7.2 will be inefficient if I don't take advantage of the MSP production abilities of the maintenence facilities, meaning I'll probably still put such bases in systems with all require minerals anyway.
-
If we are strongly encouraged to systematically circumvent a core mechanic (maintenance) by using something that's fair in itself (hangars), the game is also broken.
I think that this is the real issue here.
In 7.1 there's a very limited amount of player overhead in maintenance (you park your ships where you have abundant minerals and ensure you have enough maintenance facilities). In 7.2 that's changing, and the player is going to be actively concerning himself with maintenance much like he does fuel. That's fine, except that people will now be naturally encouraged to look for more efficient uses of their MSP, just like how people concern themselves with fuel efficiency. That's when the hangar becomes problematic.
The difficulty isn't really with the changes to maintenance it's the lack of change for hangars.
-
@Iranon, you might be right that aggressive scrapping will be more efficient. If so, this is a balance issue that needs to be addressed. If you can show the math, then it would be easier to see how it can be addressed.
@Veneke , no its not.
In 7.1 you park your ship in orbit of planet with sufficient maintenance facilities. These ships do not suffer maintenance failures nor run their maintenance clocks, instead they consume minerals from the planets stockpile as percentage of their Build Cost.
In 7.2 you park your ship in orbit of planet with sufficient maintenance facilities. These ships do not suffer maintenance failures nor run their maintenance clocks, instead they consume supplies from the planets stockpile as percentage of their Build Cost.
Supplies are produced by maintenance facilities from minerals. So in your example, where you an have abundance of minerals on that planet, those things will be handled under the hood without you noticing any changes. Except having some additional option that offer more flexibility in how to deal with MSP.
EDIT: Also there is no change as to how ship maintenance failure\clock work, from previous versions.
-
I think that this is the real issue here.
In 7.1 there's a very limited amount of player overhead in maintenance (you park your ships where you have abundant minerals and ensure you have enough maintenance facilities). In 7.2 that's changing, and the player is going to be actively concerning himself with maintenance much like he does fuel. That's fine, except that people will now be naturally encouraged to look for more efficient uses of their MSP, just like how people concern themselves with fuel efficiency. That's when the hangar becomes problematic.
The difficulty isn't really with the changes to maintenance it's the lack of change for hangars.
My understanding of Iranon's core concern (based on a post 20-30 up-thread) is the following statement (which may or may not be true): "A ship that is 10 years old will consume MSP when parked more rapidly than a ship that is 1 year old. This is a change from the previous behavior."
If true, then I can see a cause for concern about unintended consequences/balance issues - it will change the calculation of when ships should be overhauled by making ships with a long time on the clock significantly more expensive to operate. Arguably this is more realistic - maintenance costs go up with age. If not true, then as someone said - it sounds like it's more a simplification and closing of a loophole.
John
-
I'm astounded that the current debate about the change is mostly complaints about or defence of Steve finally closing the free maintenence exploit rather than the actual mechanics change, it was inevitable really but amongst all the things needing work I can see why it wasn't fixed untill steve actually noticed the problem.
I saw it coming miles away. Its change, a lot of people don't like change. When change happens, they will argue the change no matter how it would affect whats changing.
Now I'm all for the current changes because they do look mostly balanced to me. The only thing I am 50/50 on is the Particle lance, to me, it just looks like a fill in for a spinal particle beam with a small twist (and multiple per ship).
-
My understanding of Iranon's core concern (based on a post 20-30 up-thread) is the following statement (which may or may not be true): "A ship that is 10 years old will consume MSP when parked more rapidly than a ship that is 1 year old. This is a change from the previous behavior."
If true, then I can see a cause for concern about unintended consequences/balance issues - it will change the calculation of when ships should be overhauled by making ships with a long time on the clock significantly more expensive to operate. Arguably this is more realistic - maintenance costs go up with age. If not true, then as someone said - it sounds like it's more a simplification and closing of a loophole.
John
It's not true. It will require the same number of MSP as it does now. When parked, consumption is only based on build cost.
-
When parked, consumption is only based on build cost.
Although, to be fair, that part has changed. For example, ships with huge engines will consume less Gallicite in the current system.
-
Although, to be fair, that part has changed. For example, ships with huge engines will consume less Gallicite in the current system.
True, but pretty much a rounding error. The point is that older ships are no more expensive to maintain at dock than new ships, regardless of how much time is on their clocks.
Edit: I did some looking at payoff on hangaring ships vs keeping them in maintenance facilities. For my current game, which has expensive ships per size, the payoff looks to be about 3 years. But you have to spend about 20% more in terms of PDCs, which is going to be a reasonably significant dent in your economy. A check of a few early ships from the ship design board puts payoff at a typical starting tech at about 10 years. That's pretty clearly not worth it, given the growth you'd have to forgo to build the PDCs. More tech means shorter payoffs.
It might make some sense to cut the cost of MSPs slightly, but it's not a huge gamebreaker.
-
My understanding of Iranon's core concern (based on a post 20-30 up-thread) is the following statement (which may or may not be true): "A ship that is 10 years old will consume MSP when parked more rapidly than a ship that is 1 year old. This is a change from the previous behavior.
That's not how I understand it. Cost should be constant in orbit and gets progressively higher in deep space, same as before.
I saw it coming miles away. Its change, a lot of people don't like change. When change happens, they will argue the change no matter how it would affect whats changing
As perhaps the most vocal sceptic atm: I welcome changes. Both to refine things, and introduce interesting new options.
However: If a core mechanic is changed signicantly and it breaks something/causes significant balance issues/heavily rewards fiddly unintuitive things, the likely net result is a version that's inferior to the predecessor no matter how many cool new toys we get. Quite normal to happen a few times in sufficiently complex games that see major revisions.
The bad: I currently believe this to be the case. The good: fixing this after the fact should not be hard.
the formerly odd situation that needed to be addressed: Built maintenance points were very expensive compared to the complimentary load you received with ships (especially when maintenance storage bays are involved). Steve decided that the complimentary load was the sole problem and got rid of it. My experience points to pricing of regular MSP being part of the problem.
I experimented quite extensively with various ways to cut down on maintenance requirements, and many are viable even when cheap supply ships made them less beneficial.
For consistency's sake, I welcome the change of "no free MSP" (the alternative would be overly complicated - e.g. engineering bays would not have a fixed cost to account for how many MSP one adds). But I think balance requires this to come with a significant cost decrease rather than the slight increase we got.
-
I thought about this more, and there are more reasons why hangar maintenance isn't gamebreaking even at the level of my game. Quite simply, it's lack of flexibility. Maintenance facilities can be built in a central location, and shipped out to any planet with enough people to man them. A maintenance fleet can do the same, without needing the people. MSPs can be delivered. There's no limit on how many ships a given base can support except the MSP supply. But if I want to set up a forward maintenance base using hangars, I have to prefab and ship out a hangar for each ship, then assemble them. And, when I've finished with that base, I have a bunch of hangars that I can't move elsewhere. It's akin to the forward drydock problem, but much, much worse. Nobody is going to use this anywhere except at home base, so any deployments will still require normal maintenance. And if your fleet is deployed a lot, then there's not much change from the current situation. This is particularly true if you use fleet training.
I could see using this as a way to simulate a mothball fleet, where some of your older ships that you aren't currently using sit in hangars. But I don't see a compelling case for doing this in all cases.
For consistency's sake, I welcome the change of "no free MSP" (the alternative would be overly complicated - e.g. engineering bays would not have a fixed cost to account for how many MSP one adds). But I think balance requires this to come with a significant cost decrease rather than the slight increase we got.
Why? The fact that you've been exploiting a loophole (which not everyone does) doesn't mean that we should change the game to keep the numbers where they were with it. I play without it, and while I do wish maintenance was less expensive, it's ultimately of the same order as wishing that my ships were faster and more durable. Steve seems to do the same.
-
urrr, i dont think these changes are to 'fix' maintenance. MSP-based maintenance make deep space maintenance bases workable without being a bastardized hybrid mechanic.
if you think that MSP are too expensive, that should be a pretty straightforward math argument: the new prices are posted in the change log thread. I think everyone is open to being convinced if you can show your work.
EDIT:
Although I have doubts about Sorium being used for MSP. It's relatively easy to go into a sorium crunch early game, and if you accidentally drain all your reserves with refineries then now your MSP production is boned as well. Little fuel is one thing but god help you with no MSP.
Also, i'm a little worried bout having to fiddle the MSP production on and off regularly owing to overproduction. Perhaps there should be a semi-auto setting where you can enter in a desired reserve level for MSP. This could be extended to Fuel/refineries as well...
-
urrr, i dont think these changes are to 'fix' maintenance. MSP-based maintenance make deep space maintenance bases workable without being a bastardized hybrid mechanic.
if you think that MSP are too expensive, that should be a pretty straightforward math argument: the new prices are posted in the change log thread. I think everyone is open to being convinced if you can show your work.
The work is actually pretty simple. If you either run overhauls or keep the ship at base, maintenance is equal to the ship's cost after 16 years. This is actually quite generous compared to real life. In other words, if your ships last an average of 16 years each, you'll spend about as much on maintenance as you do on military shipbuilding.
(This isn't quite true, as you're presumably spending more on military shipbuilding each year. If the military shipbuilding expenditure grows by 10% per year, maintenance turns out to be about 50% of the military shipbuilding budget. If it's 5% growth, it's about 75%.)
EDIT:
Although I have doubts about Sorium being used for MSP. It's relatively easy to go into a sorium crunch early game, and if you accidentally drain all your reserves with refineries then now your MSP production is boned as well. Little fuel is one thing but god help you with no MSP.
That's a good point.
Also, i'm a little worried bout having to fiddle the MSP production on and off regularly owing to overproduction. Perhaps there should be a semi-auto setting where you can enter in a desired reserve level for MSP. This could be extended to Fuel/refineries as well...
I'd want two levels, Cap and Reserve. Cap would work the way you describe, with production stopping if they reach it. Reserve would work like mineral reserves, and make it easier to move supplies between bases without worrying about taking all of the supplies/fuel from a base. It would probably only apply to supply ships/tankers. And I'd support extending both to fuel as well.
-
I'd want two levels, Cap and Reserve. Cap would work the way you describe, with production stopping if they reach it. Reserve would work like mineral reserves, and make it easier to move supplies between bases without worrying about taking all of the supplies/fuel from a base. It would probably only apply to supply ships/tankers. And I'd support extending both to fuel as well.
And if levels are under the reserve amount, a civilian shipping line would ship whats required out there (because maintenance storage is now a commercial component) whether it be fuel, minerals, or MSP (if they have the required ship type {tanker, freighter, supply ship}). Maybe it could work with missile stockpiles as well since another addition was a commercial missile mag.
-
And if levels are under the reserve amount, a civilian shipping line would ship whats required out there (because maintenance storage is now a commercial component) whether it be fuel, minerals, or MSP (if they have the required ship type {tanker, freighter, supply ship}). Maybe it could work with missile stockpiles as well since another addition was a commercial missile mag.
I'm not sure how well that would work. The thing is that all current civilian ships have uses that do not depend on government contracts. Realistically, no shipping line is going to buy a ship that is only profitable if you decide to give them contracts without being certain that you will give them those contracts, and all I certainly don't see any possible civilian use for missile transports. (IRL, the companies that do this are able to get a reasonable idea of demand before they invest. Aurora doesn't support that level of detail.) Setting it up so you automatically buy civilian fuel if you're below the reserve level is good, and I like the idea of being able to contract civilian freighters to carry minerals.
I would like to see the cap/reserve system extended to missiles, but I have a feeling that won't be possible. Fuel and MSP are generic goods, and missiles aren't, which makes the programming challenge much harder.
-
True, but pretty much a rounding error. The point is that older ships are no more expensive to maintain at dock than new ships, regardless of how much time is on their clocks.
Its little bit more than 5% -> 6.25%, but you misunderstood. I was not referring to the quantity but the makeup of MSP, previously it was 5% of the mineral cost of the ship design, now its 6.25% of a fixed number. So if before, you built a ship which was a huge engine block, it would cost you a lot of Gallicite to maintain, but now it doesn't meter what the make up of the ship 1 MSP is constructed the same.
Regardless, I don't think its problem, the new system is superior by FAR, IMO.
-
If a cylinder in your engine breaks, do you replace the cylinder or the entire engine? If your windshield cracks, do you replace the windshield (or repair it depending on the severity of the crack) or replace the frame the window was sitting in? Same thing for future space engines, if a small part breaks (or need regular replacement) it shouldn't cost the amount of the entire component to fix a small part of it. Hence why for larger components it gets more efficient to maintain.
-
If a cylinder in your engine breaks, do you replace the cylinder or the entire engine? If your windshield cracks, do you replace the windshield (or repair it depending on the severity of the crack) or replace the frame the window was sitting in? Same thing for future space engines, if a small part breaks (or need regular replacement) it shouldn't cost the amount of the entire component to fix a small part of it. Hence why for larger components it gets more efficient to maintain.
They don't. His point (which I got at the time, and ignored as irrelevant to what I was trying to point out) is that the distribution of minerals required for maintenance has shifted somewhat. Previously, if you had a very fast fleet, maintenance required lots of Gallicite. Now, a fleet costing 50,000 BP requires the same amount of Gallicite if it's really fast or made of orbital defense platforms with no engines.
Under the new system, maintenance cost is only based on build cost, regardless of the size or other attributes of the ship. Part of me doesn't like that, as I tend to run expensive ships, but it's reasonably realistic.
Its little bit more than 5% -> 6.25%, but you misunderstood. I was not referring to the quantity but the makeup of MSP, previously it was 5% of the mineral cost of the ship design, now its 6.25% of a fixed number. So if before, you built a ship which was a huge engine block, it would cost you a lot of Gallicite to maintain, but now it doesn't meter what the make up of the ship 1 MSP is constructed the same.
Regardless, I don't think its problem, the new system is superior by FAR, IMO.
I did get that, but it was not relevant to what I was trying to say. In my defense, I was on my phone at the time, so typing was much more difficult.
-
My understanding of Iranon's core concern (based on a post 20-30 up-thread) is the following statement (which may or may not be true): "A ship that is 10 years old will consume MSP when parked more rapidly than a ship that is 1 year old. This is a change from the previous behavior."
John
Ships with more time on their clock are already more likely to break down (in deep space). However, ships in orbit of maintenance facilities use MSP at a constant rate regardless of clock time. This isn't a change. This is how maintenance has always worked. There are no changes to the actual maintenance mechanics, just the replacement of minerals with MSP (and a small increase in the overall rate of use regardless of the time on the clock).
-
Why? The fact that you've been exploiting a loophole (which not everyone does) doesn't mean that we should change the game to keep the numbers where they were with it. I play without it, and while I do wish maintenance was less expensive, it's ultimately of the same order as wishing that my ships were faster and more durable. Steve seems to do the same.
Yes, I haven't been exploiting that loophole (beyond normal ship production) and only realised it was a major problem when I produced a supply ship that started with a lot of MSP :)
-
Continuing the current theme of maintenance issues, could we get a tech that reduces maintenance costs? Something along the lines of the shipyard cost/time tech, with similar benefits and costs.
-
Although I have doubts about Sorium being used for MSP. It's relatively easy to go into a sorium crunch early game, and if you accidentally drain all your reserves with refineries then now your MSP production is boned as well. Little fuel is one thing but god help you with no MSP.
Actually, that's a good point. Probably not a good idea for Sorium to be necessary for both fuel and MSP. I've removed the Sorium. New minerals for 1 MSP.
Duranium: 0.05
Neutronium: 0.025
Tritanium: 0.025
Boronide: 0.025
Mercassium: 0.025
Uridium: 0.025
Corundium: 0.025
Gallicite: 0.05
-
Yes, I haven't been exploiting that loophole (beyond normal ship production) and only realised it was a major problem when I produced a supply ship that started with a lot of MSP :)
For clarification, I haven't consciously exploited a loophole (e.g. building supply pods, unloading, scrapping). But I've made plenty of design studies comparing storage bays to additional engineering spaces.
The former were useful only on very low-tech ships (commercial engines, base-tech weapons) that already had a decent number of engineering bays. The ability to put them on dedicated supply vessels, which can make repeated supply runs and now qualify for commercial ships, counts for something... which is why they are useful in the old system when you use "respectable" designs rather than dirt-cheap ones. But that is dwarfed by the planned cost increase.
-
I have updated the post about MSP. Below is the new version.
Maintenance Supply Points
In addition to being constructed normally by construction factories, maintenance supply points (MSP) can also be produced by system body based maintenance facilities. This production can be turned on and off in the same way as fuel refineries
A new tech line has been added (Maintenance Production Rate) for the rate at which a single maintenance facility can produce MSP. The default is 30 MSP per year, which is three times faster than a construction factory with base technology of 10 BP. Each MSP has the same cost in terms of minerals and wealth regardless whether it is produced by construction factories or maintenance facilities.
The bottom half of the mining / maintenance tab has been replaced as minerals are no longer directly involved in maintenance (they are used to build MSP instead).
(http://www.pentarch.org/steve/Screenshots/MaintFacilitiesV2.PNG)
-
I suppose the higher rate of production is to entice people to use more maintenance facilities, and not just have the amount corresponding to their larger ship, right? On the other hand, the mineral cost makes it more interesting to produce MSP where you have all the minerals, and ship it to fleet bases, which can be placed anywhere. Should offer more interesting decisions, I like it.
-
That screenshot doesn't show the Tritanium cost (and thus the displayed financial expense is greater than the total mineral cost). In trying to chase that down, I notice that the Change Log thread still shows the new version of MSP costs as including Sorium.
-
That screenshot doesn't show the Tritanium cost (and thus the displayed financial expense is greater than the total mineral cost). In trying to chase that down, I notice that the Change Log thread still shows the new version of MSP costs as including Sorium.
Both fixed now - thanks.
-
Would it make sense to add a new ship component for short range transportation of colonists? The component would be significantly smaller than the cryo beds and have less loading time, but it would have a maximum transit duration before life support systems started to fail, and the on-board colonist would start to perish.
The reason why I suggest this is that it imo. doesn't make much sense RP wise to put colonists in cryo beds if they're only transiting for say 0-30 days.
-
That would make no sense. For short trips, cryo stasis is a weightsaving measure because you can stack them like sardines.
Cryo transport needs only 250kg per colonist.
-
Beam fire controls being cheaper will be interesting; the expense did influence my design choices- unless the roll was so important that cost was no object whatsoever I simply did not build anything less than a battleship with a "capable" beam fire control; "sniper" destroyers kept ballooning to battleship size in the design screen.
-
That would make no sense. For short trips, cryo stasis is a weightsaving measure because you can stack them like sardines.
Cryo transport needs only 250kg per colonist.
And a modern Jumbo jet (with maximum travel times of 18 hours ) has an empty weight of 325 kg per passenger (maximum density seating) including propulsion, lift and other support systems.
Without using any TN materials. If you look at the weight of only the passenger accommodations isolated it's probably less then 250kg.
The point is that for travels below a month in time it would probably cheaper to not use cryo stasis, and much faster to load/unload, but for longer trips the savings in food and other stuff probably makes cryo more worthwhile.
It's mostly for RP as written. How much sense does it make to have colonists enter cryo stasis for a trip to the moon ( 77 seconds travel time @ 5000km/s )? That's like the travel time between two stops at your average subway!
-
You want to create passenger shuttle, with a
Luxury Passenger Accommodation, that would resemble airplane flight of up to 12hour trips. (can we please have mini bars?!)
Personally, I don't see the utility in that and since we don't have a away to simulate deployment times except with military crews, can't you use your imagination instead?
-
Seems like a not-that-great increase in complexity imo. I'd rather the colony ships stay at the 'load people on board and they are now cargo' level of abstraction. This game is microey enough as it is, without bloody colonists dying in droves because I used the wrong type of storage bay and didn't notice because I didn't want to go through fifty menus to confirm the kinds of bays they had.
-
(. . . ), can't you use your imagination instead?
Come on, every suggestion can be met by this argument. If you have enough imagination you could just play Aurora in MS Excel.
-
And a modern Jumbo jet (with maximum travel times of 18 hours ) has an empty weight of 325 kg per passenger (maximum density seating) including propulsion, lift and other support systems.
Without using any TN materials. If you look at the weight of only the passenger accommodations isolated it's probably less then 250kg.
The point is that for travels below a month in time it would probably cheaper to not use cryo stasis, and much faster to load/unload, but for longer trips the savings in food and other stuff probably makes cryo more worthwhile.
A month? Seriously? Have you ever been in maximum-density seating on a jet? Normally, they only use those kind of seats for trips of an hour or two. Trying to put people in them for a month would be a complete non-starter.
As for 'isolated passenger accommodations', airliners aren't that simple. Are we looking at the weight of the seats (and lavatories and such) themselves, independent of the structure? The best way to find that number would probably be to compare empty weights of freighter and passenger versions, but even then, it's not really the point. In Aurora, that 250 kg is going to include a lot of things which would count against the structures group in an airliner. (Also, the passenger himself.)
Come on, every suggestion can be met by this argument. If you have enough imagination you could just play Aurora in MS Excel.
But you're proposing a system that only works in very specific conditions. A system to cover Earth-Moon runs only, which can't be used for others, seems pointless and unnecessarily complicated. Sure, it would be nice if we could get an Earth-Moon subway, but the scale of the game (a normal cryo module holds 10,000 people, and limitations on commercial engines mean you couldn't build these on the 1000-passenger scale) mean you couldn't materially improve the loading time. Also, there's the fact that it would be a perfect newbie trap, and we'd get loads of threads about 'all my colonists just died, why?'.
-
But you're proposing a system that only works in very specific conditions. A system to cover Earth-Moon runs only, which can't be used for others, seems pointless and unnecessarily complicated. Sure, it would be nice if we could get an Earth-Moon subway, but the scale of the game (a normal cryo module holds 10,000 people, and limitations on commercial engines mean you couldn't build these on the 1000-passenger scale) mean you couldn't materially improve the loading time. Also, there's the fact that it would be a perfect newbie trap, and we'd get loads of threads about 'all my colonists just died, why?'.
5000km/s*18 hours = 324 million km, gets you a little bit further then "Earth-moon runs only", doesn't it?
Anyways, the way to do it ( if it should be done ), is to have a second type of colony ships which load/unload many times faster and has a limited range of 1 or a few days travel time above which it won't be used (for civilian runs).
It would also be much cheaper and give you much greater capacity over shorter colony runs + require no extra tech research. ( which is the main reasons to implement something like this ).
For example in the current fiction in Colonial Wars just mass evacuating everyone from Earth to for example Mars could be an option to consider if this kind of modules were available.
Lack of capacity/loading times isn't really a realistic argument against this either IMO seeing how we have airports with our non TN tech today that handles 50-100 million PAX per year = an entire sizable Aurora colony.
-
Well...just my 2c but the relative ease+profit of colonizing mars/luna right now (and all the mechanics wrapped up with that) is probably my least favorite part of Aurora. I'm not for something that makes short range colonization even more amazing.
-
Well...just my 2c but the relative ease+profit of colonizing mars/luna right now (and all the mechanics wrapped up with that) is probably my least favorite part of Aurora. I'm not for something that makes short range colonization even more amazing.
Then the game should have realistic systems in place like most kind of nations not being allowed to force move population, and civilian colony ships working by demand and supply meaning unless you supply jobs and accommodations on mars/luna no one is interested in moving there.
My point is the difficult/expensive part of the equation should not be moving people, but moving their houses and jobs ;D
-
Anyways, the way to do it ( if it should be done ), is to have a second type of colony ships which load/unload many times faster and has a limited range of 1 or a few days travel time above which it won't be used (for civilian runs).
Once colonization effort and space industry advanced enough, such shuttles should be a mundane thing. However, if we start simulating every shuttle the game will grind to a halt. We already upped the size of civilian designs and added other means to restrict them. So, unless you want to abstract this, you'd have to imagine that such things are handled by civs and those colony ships, represent colony fleets (I do something similar with factory -> industry).
EDIT:
With that in-mind, does the ability to track each civilian ship add anything to your gameplay? What if they were replaced with trade-lines? performance wise it would be better, economically it should be at least the same, as the only time you'd actually generated civics is if you or an enemy threatens the tradeline (based its prosperity, and who\what runs on it).. Although that transition might not be simple to implement with turns ..
-
5000km/s*18 hours = 324 million km, gets you a little bit further then "Earth-moon runs only", doesn't it?
5000 km/s is quite fast for the sort of early-game situations where you're going to be looking at short-range colonization. In the sort of case where you're seriously colonizing Mars (as opposed to doing it for free money), it's going to be days away.
It would also be much cheaper and give you much greater capacity over shorter colony runs + require no extra tech research. ( which is the main reasons to implement something like this ).
I will agree that it might be nice for Conventional starts to have something that's between the Luxury Passenger module and the Cryo module.
For example in the current fiction in Colonial Wars just mass evacuating everyone from Earth to for example Mars could be an option to consider if this kind of modules were available.
Infrastructure would bottleneck that very quickly. Actually, you'd be better off shipping 25 million to Mars, then taking the infrastructure the lines haul there back to Earth.
Lack of capacity/loading times isn't really a realistic argument against this either IMO seeing how we have airports with our non TN tech today that handles 50-100 million PAX per year = an entire sizable Aurora colony.
A big airliner carries ~400 people. An Aurora cryo module starts at 10,000. I can't see a ship with less than, say, 40,000 being efficient. So that's 100 times the size of an airliner, which takes at least half an hour to load and unload. TN tech isn't really going to help without adding lots of complexity. Sure, we could divide up into ~400 passenger sections, but this is where the square-cube law bites you. I can't see getting good access to more than about 4 wide-body equivalents on a section, maybe 6 at the outside. Past that, you're going to start interfering with each other. So either it has to be 18 times as long as an airliner and only 3 times as wide (which is absurdly skinny), or you can't unload at airliner speeds, or you can't keep it as simple as you want it to be.
-
An Aurora cryo module starts at 10,000. I can't see a ship with less than, say, 40,000 being efficient. [/b]
Numbers from the hat! There is no logical reason for that on several minutes up to half day commercial trips, even within the game rules that would be excessive. The real reason is the game focus on military aspects, hence there is no way to enforce "cargo expiration", and those Cryo components average use is much longer than that.
-
Maybe the passengers just sit unfrozen in their cryo coffins for short trips.
-
Numbers from the hat! There is no logical reason for that on several minutes up to half day commercial trips, even within the game rules that would be excessive. The real reason is the game focus on military aspects, hence there is no way to enforce "cargo expiration", and those Cryo components average use is much longer than that.
The numbers are based on the minimum size of commercial engine components and the other 'minimum gauge' components like bridges and engineering spaces. Unless this proposal goes to the point of re-working all of commercial shipping, you're going to see passenger numbers that dwarf old ocean liners and troopships, much less airliners. That means you will have trouble getting people on and off efficiently. My point is that this doesn't fit well into existing game rules, not that it's totally logically absurd. The best way to solve this problem (although we really don't need to make colonizing the moon easier) is to give civilian colony ships the ability to carry more people on very short hauls.
To expand slightly on this, I used a spreadsheet to look at the optimum size of ships with a single nuke-pulse Size 25 commercial engine. It turns out that it's one cryo module or one cargo bay. The optimum speed gets slower as the cargo module gets cheaper, so it's likely a cheaper passenger module would end up with two modules on a single engine, and at least twice the passenger capacity of the cryo colony ship.
Edit:
The airport analogy bears some thinking on. A modern airport is a very sophisticated system for moving people in and out of aircraft. The biggest modern airports (or seaports) are the equivalent of a high-level spaceport in Aurora, which is not the sort of thing you're likely to see on a new colony. After all, a primitive moonbase is unlikely to play host to several dozen boarding tubes in exactly the right configuration for your fancy new high-density colonist transporter.
-
While using ships to ship cargo in bulk is most efficient way, last I checked its not the popular method of intercontinental transport. Certainly not for flights that would take less time than boarding your proposed ship. Anyway, my point was that his suggestion make sense, but just doesn't fit well within the scope of Aurora and its mechanics.
-
While using ships to ship cargo in bulk is most efficient way, last I checked its not the popular method of intercontinental transport. Certainly not for flights that would take less time than boarding your proposed ship. Anyway, my point was that his suggestion make sense, but just doesn't fit well within the scope of Aurora and its mechanics.
In broad terms, I agree. I was trying to point out that within the framework we have, this doesn't work well, even though the idea has some merit in an ideal world.
-
Perhaps a compromise might be making luxury passenger transport modules scale in size based on a ships deployment time, since default is 3 months, maybe reducing time lowers the module size up to a set minimum. It would need balancing. There's the downside that it might therefore make sense that longer flights would need larger modules.
-
Perhaps a compromise might be making luxury passenger transport modules scale in size based on a ships deployment time, since default is 3 months, maybe reducing time lowers the module size up to a set minimum. It would need balancing. There's the downside that it might therefore make sense that longer flights would need larger modules.
There can be no compromise!
Below 3 months makes the design military, making it mildly pointless to use it as a passenger ship, as the maintenance costs suddenly make it worthlessly more expensive than the per-moved-tonnage fuel costs of larger colony ships.
-
I am not sure whether this feature is of real interest or we got nothing better to discuss... But for what it worth this is how i see it:
* You want smaller and cheaper passenger component for short intra system flights. Currently, there is no way todo it without making Cryo obsolete. Otherwise, you'd need to find away to restrict its usefulness by time.
* Such component makes most sense on extremely short fights, while Aurora turns can extend as far 30days. For which Cryo chambers are far more efficient as they require non of the living quarter necessities, just stack them high.
* Thus your are either going to be forced to crawl or have your fast passenger shuttlets parked in orbit ~29 days out 30. And create some special rules.
* If civs were to use it, this will increase traffic requirements, which the opposite of the direction I observed in latest versions. You'd to update their creation\AI code, deal with pathfinding, which would be limited by their cargo range, and you'd need to make sure your intra-system liners don't become stranded in your home system. Also loading unloading order might need to be updated.. etc
So yeah, I don't think you can fit well within the scope of Aurora mechanics, nor that such a limited use feature worth Steves time. We already have Cryo chambers for either long term colonization operations or basic low-cost fares; And Luxury cambers for those seeking comfort like private sleeping cabins, minibars, sexy flight attendants, and entertainment. I am going to use my imagination\GM to fill in the rest.
-
I really approve of the Wh40kyzation coming in here. The multiple Titans, and that Lance beam, which seems exactly like Warhammer lances with their extreme armor piercing, but low dpm. Very interesting, and finally introduces some things that I have since poorly tried to simulate in some past games via 'renaming and pretending'. :)
-
I really approve of the Wh40kyzation coming in here. The multiple Titans, and that Lance beam, which seems exactly like Warhammer lances with their extreme armor piercing, but low dpm. Very interesting, and finally introduces some things that I have since poorly tried to simulate in some past games via 'renaming and pretending'. :)
I am creating a WH40K Imperium for my campaign so the 'Lance' is not a coincidence :)
-
I am creating a WH40K Imperium for my campaign so the 'Lance' is not a coincidence :)
I have recently had a Tau game in 7.1 (because their best ship is a large carrier, so I can test carriers against carriers), and plan to redo this later, so something better for their version of lances, ion cannons, is welcome.
I read Mark also plays an Imperium game, and I wanted to make a scenario save file themed that way for a while. Could it be the influence of the upcoming Battlefleet Gothic Armada game, that turns some Aurora players towards this mood currently?
https://www.youtube.com/watch?v=zw5V2O7jQJU (https://www.youtube.com/watch?v=zw5V2O7jQJU)
Looks great so far in models, weapon effects, and gameplay modes. If only the ships would feel a bit heavier. I am already itching to calculate the g-forces that must afflict these kilometers long behemoths on the far swinging ends when doing these crazy fast turns shown there. Material properties put a sharp limit on maneuver at this scale, not to mention the people working there, and battleships are already described as being pretty much about the largest propelled built possible with current material, so their maneuver is weak.(some even larger ships like the little larger Planetkiller on the other way are described as having been built partly inside the warp, where physics don't matter much, so they became possible...)
Also: Starcraft-UI. Stealing back from the thieves, classic. ;D
-
I am not sure whether this feature is of real interest or we got nothing better to discuss. . . But for what it worth this is how i see it:
* You want smaller and cheaper passenger component for short intra system flights. Currently, there is no way todo it without making Cryo obsolete. Otherwise, you'd need to find away to restrict its usefulness by time.
* Such component makes most sense on extremely short fights, while Aurora turns can extend as far 30days. For which Cryo chambers are far more efficient as they require non of the living quarter necessities, just stack them high.
* Thus your are either going to be forced to crawl or have your fast passenger shuttlets parked in orbit ~29 days out 30. And create some special rules.
* If civs were to use it, this will increase traffic requirements, which the opposite of the direction I observed in latest versions. You'd to update their creation\AI code, deal with pathfinding, which would be limited by their cargo range, and you'd need to make sure your intra-system liners don't become stranded in your home system. Also loading unloading order might need to be updated. . etc
So yeah, I don't think you can fit well within the scope of Aurora mechanics, nor that such a limited use feature worth Steves time. We already have Cryo chambers for either long term colonization operations or basic low-cost fares; And Luxury cambers for those seeking comfort like private sleeping cabins, minibars, sexy flight attendants, and entertainment. I am going to use my imagination\GM to fill in the rest.
Lots of good points against my suggestion here (and in the other posts), and I agree that the addition I suggested might be not add enough to the gameplay to justify a rather complex coding job for Steve.
-
I suggest that an "Land on assigned mothership" default order is added to the list of possible default actions.
This would make it possible to send out e. g. fighters to do a job (e. g. surveying a system) and then have them automatically return to their mothership when the job is done.
-
I suggest that an "Land on assigned mothership" default order is added to the list of possible default actions.
This would make it possible to send out e. g. fighters to do a job (e. g. surveying a system) and then have them automatically return to their mothership when the job is done.
2 things. 1) it really only takes 3 extra clicks to make a fighter squad land at their mothership. 2) A suggestion for a new feature goes in the suggestion page. This is for discussing the usefulness/uses of new changes and suggestions for tweaking them.
-
2 things. 1) it really only takes 3 extra clicks to make a fighter squad land at their mothership. 2) A suggestion for a new feature goes in the suggestion page. This is for discussing the usefulness/uses of new changes and suggestions for tweaking them.
Roger that. I've created a separate topic for my suggestion; http://aurora2.pentarch.org/index.php?topic=8423.0
-
Roger that. I've created a separate topic for my suggestion; http://aurora2.pentarch.org/index.php?topic=8423.0
Aaaand the next bit of feedback is "please put suggestions (and bug reports) in the appropriate official thread, rather than starting a new thread" :) Steve likes them all in one place. There's a "Where should I post" thread in FAQ for details.
John
-
But its not a good way to flash out suggestions over time, and we can always post a link to it in the main thread.
-
But its not a good way to flash out suggestions over time, and we can always post a link to it in the main thread.
My rule of thumb is that if it's a fairly simple change, it goes in the main suggestion thread. If I'm proposing a fundamental overhaul of some game mechanic and the suggestion is going to be three pages of text and provoke a 200-post discussion, it gets its own thread. This one definitely should have gone in the main suggestion thread.
-
My rule of thumb is that if it's a fairly simple change, it goes in the main suggestion thread. If I'm proposing a fundamental overhaul of some game mechanic and the suggestion is going to be three pages of text and provoke a 200-post discussion, it gets its own thread. This one definitely should have gone in the main suggestion thread.
Exactly.
And if you do put it in a side thread, please add a reference post (with a link) to the main thread. Again, this is Steve's request - he uses the main threads as "filing cabinets", and once he's read a particular post (so that it is no longer flagged as new), he has trouble finding side-thread posts when he's reviewing things before a release (potentially months later). Having more side threads only makes things worse.
John
-
2) Titans are transported in the Titan Bay, a special type of module for ships similar to a troop transport bay.
5) Titans do not recover hit points in the same way that ground units recover readiness. Instead they are automatically repaired in Titan Bays using maintenance supplies at a rate of 1 HP per day (1 HP costs 1 MSP), as long as MSP are available.
Does this mean Titans can only be repaired within the ships that transport them? It would be odd not to be able to repair them when they are on a planet with MSP and not involved in combat, or atleast on a planets where Titans can be built.
-
I think, PDC can contain Titan Bay modules .
-
Unless Steve says otherwise, PDCs will be able to have Titan Bay modules, since they can have hangars as well.
-
Please Steve make a disable checkbox for Titans!
-
Please Steve make a disable checkbox for Titans!
When first mentioned, I thought "well....I won't be building those", but now that you mention it, I don't want them appearing in my games in NPR hands either. So I have to 2nd this request for a "Disallow Titans" checkbox.
-
What's the issue with the NPR using them?
-
What's the issue with the NPR using them?
Its more of a thing of people not wanting big stomping robots decimating the surface of worlds across the sectors. I also think its a case of the balance of how many the NPRs will build. Either they will make too many and cripple their economy/industry, or they will build too few and be steamrolled by other NPRs/Players who have a good amount.
-
At the moment, NPRs don't have them. If I add them for NPRs, I will add the disable option as well.
-
Its more of a thing of people not wanting big stomping robots decimating the surface of worlds across the sectors.
This. Aurora is largely a "hard SF" game engine (IMO). Giant mecha, which are one of the least efficient/realistic types of ground combat machinery, seriously break my hard SF immersion. But I can see the appeal for other gamers who want to get their Battletech/Warhammer 40,000/Gundam fix.
-
The balance definitely makes sense, but I wonder if there is anything in the hard crunch revealed so far that requires them to be bipedal mecha. Could they be refluffed for specific settings as heavy AFVs/bolos/ogres/etc. ? Admittedly, I suppose there are some issues with bolos as well, hard-SF-wise, but they make more sense than walking death bots for harder settings.
-
The balance definitely makes sense, but I wonder if there is anything in the hard crunch revealed so far that requires them to be bipedal mecha. Could they be refluffed for specific settings as heavy AFVs/bolos/ogres/etc. ? Admittedly, I suppose there are some issues with bolos as well, hard-SF-wise, but they make more sense than walking death bots for harder settings.
I would imagine that is what the rename function will do as it already does for ground units and space. So you decide you have a civilization that delved down the route of biotech and now want to have a mutated giant anteater that breaths fire? No problem just rename your heavy assault brigade to "Dragon corps" The sheer genius of Aurora is the fact it has almost zero GUI and as such it can be bent into whatever situation you desire as in reality all the actual pew pews only happen in your head, the game just gives you numbers on the screen.
-
Giant mecha, which are one of the least efficient/realistic types of ground combat machinery, seriously break my hard SF immersion.
Ever watch the anime Heavy Object? Watch that (and don't point out the point made in the series, I know). And also, they aren't as inefficient as you think. Their main advavntage over other platforms is mobility. They are true all terrain. Whereas tanks and other military vehicles are off road vehicles, they still need valid paths and stable ground to move around in any faction. One of the easiest ways to take out a tank is to get it stuck. Also, mechs can perform some evasive action (depending on the size).
But overall, given the "Titans" renameability, they don't have to be big, stomping mechs. They can be big, rolling battle fortresses like the Fatman of the Supreme Commander series or the Cocoon of MGS:PW.
-
Ever watch the anime Heavy Object? Watch that (and don't point out the point made in the series, I know). And also, they aren't as inefficient as you think. Their main advavntage over other platforms is mobility. They are true all terrain. Whereas tanks and other military vehicles are off road vehicles, they still need valid paths and stable ground to move around in any faction. One of the easiest ways to take out a tank is to get it stuck. Also, mechs can perform some evasive action (depending on the size).
Seriously? Mobility? Let's see. One of the main limits on tank mobility is ground pressure. Now, which has lower ground pressure, a tank or a typical mecha? Also, tanks don't have to have massively complex actuator systems, which makes them cheaper. If I was making an anime, I could have tanks jumping around and dodging and such, too.
I'm in favor of Titans, although I think they'll probably end up renamed something like 'Armored Divisions' in my game, because I really want more flexibility in ground combat.
-
Titans sound really cheesy. Just my $0.02.
-
Titans sound really cheesy. Just my $0.02.
They are cheesy, but also essential for a WH40k theme campaign :)
BTW once the C# version is finally done, I will probably create a 'Great Crusade' option, which will allow other human populations to be discovered. Rather than a species that matches the environment, this would allow humans as potential option if the world fell within human tolerance, or perhaps introduce some terraforming as part of system generation.
-
Mechs or titans would be be a natural progression from combat suits. It starts out as a small combat suit for soldiers and get bigger and bigger. A Mech is a more natural movement if integrated as a suit rather than a tank, with articulated arms and legs, it can step over object where a tank cannot, if function like a suit it can be used in a mountain environment where tanks cannot. A tank needs a crew of three and mech needs a crew of one, and if operates like a suit would be more combat effective in target acquisition and get the round of sooner, however target accuracy may go to the tank.
There are a lot benefits a tank has over a mech, but versatility is not one of them. So where money is not a problem and the ability to only deploy a small number of units upon landing on a planet, with varied and different terrains that have not been pathed, my option would be to send in mechs rather than tanks, as a heavy weapons platform.
However I think plasma weapons attached to power suited soldiers would probably make both the mech and tank obsolete.
-
However I think plasma weapons attached to power suited soldiers would probably make both the mech and tank obsolete.
Ways to make plasma weapons obsolete it to create an EM field and/or create armor in such a way as to distribute the energy over an area.
-
This. Aurora is largely a "hard SF" game engine (IMO). Giant mecha, which are one of the least efficient/realistic types of ground combat machinery, seriously break my hard SF immersion. But I can see the appeal for other gamers who want to get their Battletech/Warhammer 40,000/Gundam fix.
I always fluff my Heavy Assault battalions as mecha, there is nothing really saying otherwise. xD
Likewise there is nothing in the game that says the titans are giant mecha, and the names will have to be changed before release anyway to avoid GW coming down on Steve's head.
Your titan could be this
(http://greatercaprica.weebly.com/uploads/6/7/7/8/6778730/_583810511.jpg)
as easily as it could be this
(http://pre12.deviantart.net/29a7/th/pre/f/2012/011/6/c/giant_mech___uef_acu_rnder_by_avitus12-d4m00bg.jpg)
-
As a more fantastic orientated player, I of course like the addition of Titans very much, but I can also see why this can't be liked by everyone, so the ability to disable them for NPR is sensible.
BTW once the C# version is finally done, I will probably create a 'Great Crusade' option, which will allow other human populations to be discovered. Rather than a species that matches the environment, this would allow humans as potential option if the world fell within human tolerance, or perhaps introduce some terraforming as part of system generation.
That is an attractive addition too. I've been wanting to fake such games before, and just recently again as I started to watch a new(+old) Anime ("Legend of Galactic Heroes" from the 80s), where basically humanity is all there is in Milky Way.
-
This. Aurora is largely a "hard SF" game engine (IMO). Giant mecha, which are one of the least efficient/realistic types of ground combat machinery, seriously break my hard SF immersion. But I can see the appeal for other gamers who want to get their Battletech/Warhammer 40,000/Gundam fix.
Unless I've missed something, these won't be a random anomaly with hardcoded graphics. They can be whatever your mind wants them to be.
-
They are cheesy, but also essential for a WH40k theme campaign :)
BTW once the C# version is finally done, I will probably create a 'Great Crusade' option, which will allow other human populations to be discovered. Rather than a species that matches the environment, this would allow humans as potential option if the world fell within human tolerance, or perhaps introduce some terraforming as part of system generation.
I really hope the word option there means you can have a thanks but no thanks button!
40k is the last thing I want in my Aurora games!
-
I really hope the word option there means you can have a thanks but no thanks button!
40k is the last thing I want in my Aurora games!
Yes, definitely optional :)
-
Yes, definitely optional :)
Per request, I've split out a "Further Discussion on Titan Plausibility" thread, and added anything on Titans after this post to it. I figured this was a good break point since once Steve said it's optional, those who don't like it can just turn it off.
Please put any further discussion on Titans in the other thread.
Thanks,
John
-
Hi Steve,
I follow you since 2010. . . it was a long journey and I am glad seeing that now thanks to few unexpected let's play on youtube many are seeing the truth. The truth is yours is a great game.
I am excited seeing all the progress you have made so far and always keen in trying all the new balances/improvements you slowly add to the game. I know very well what is behind all your choices, because you told many times. You do Aurora following your thoughts and how you like to play, because first of all this is an hobby and you want this to remain an hobby.
I have waited 6 years before trying to make a suggestion, just because I wanted to see where your free spirit would have guide us and this has paid off till now.
Now that you are actually rewriting and adapting the code on a new platform could be good to have a sensible review on the diplomacy, but if something can be done on the 7. 2 version will be great anyway. IMHO even if the game offer a lot of micromanagement it does lack in diplomacy options. I like to play Aurora making up stories and Role playing with my heroes till the inevitable death and I would like to do so even while fighting our enemies.
I know I am asking a lot, but the possibilities to make Federations, not only alliances; or some sort of cold war status where could happen to have a permanent war with border frictions not necessary causing an intergalactic war is always something in my mind while I play. It is already a great game and I will survive even if it remains like that, but overhaul the diplomacy will be probably appreciated from the community. The question now is: are you on the same page or you still thinking to keep this part on a side and remain focused on the core harpoon style game?
i know it is very reductive, because yours is a much deeper title than harpoon; I was just trying to give my words an understandable meaning.
-
I agree that Diplomacy needs a major overhaul and it should be a lot easier to do in the C# version. The concept of battles over certain systems rather than all-out war should be possible.
-
Don't know how complicated you want to go with diplomacy, but some of the ideas of Europa Universalis are - nice - ;)
-
I agree that Diplomacy needs a major overhaul and it should be a lot easier to do in the C# version. The concept of battles over certain systems rather than all-out war should be possible.
Have you decided on a way to do it yet? Something like every other 4X where the AI agrees to an immediate cease-fire after losing XX% of its assets, or a more involved system with cores, claims and wargoals?
-
Some concept of claiming uninhabited systems would be nice as a conflict driver if several empires could claim the same system. Could also lead to the limited war in/for the claimed system, until someone escalates it further.
-
Some concept of claiming uninhabited systems would be nice as a conflict driver if several empires could claim the same system. Could also lead to the limited war in/for the claimed system, until someone escalates it further.
This is generally the road I would go down, with NPRs claiming certain systems or maybe even just planets and not extending the war beyond that system unless further provoked.
-
That would be really fun. As it is, first contact tends to end in them finding my planet and bombing it to hell before I can do anything. I enjoy solo starts, but I tend to need an unjustifiably large space navy in order to survive them literally bee-lining for me as soon as they spot me.
I mean, its a sound survival strategy on their part, but a rather extreme one.
-
I was reading the Chat thread on TN Ground Combat, and it occured to me to wonder why Titans aren't vulnerable to meson fire? If they were, it would completely break them, so there has to be a reason; but unlike other ground units they are a relatively huge single target, so the usual 'dispersal' argument doesn't work.
-
I was reading the Chat thread on TN Ground Combat, and it occured to me to wonder why Titans aren't vulnerable to meson fire? If they were, it would completely break them, so there has to be a reason; but unlike other ground units they are a relatively huge single target, so the usual 'dispersal' argument doesn't work.
To come full circle in the historical sense* (based on a comment/suggestion in the plausibility thread that I think was in response to this): Space Empires (at least since IV) handles this by using the same design screen and principles for all platforms. So ships, satellites, bases, etc. AND ground combat "troops" all have hulls onto which you can stick arbitrary number of components. So one solution would be to do the same thing to ground units (or at least Titans) that was done to fighters: have a design screen with components that one uses to specialize. Basically, a Titan would be a fighter that moves on the ground rather than flying in space. I personally am not keen on this idea since it would throw a whole lot more micromanagement into the ground combat part of Aurora, but it's very much in line with Steve's design philosophy so I'm putting it out there.
John
* - I say full circle because I'm 99% certain that SE draws VERY heavily on StarFire. I'd never thought of it before, but a lot of Steve's drive for physics consistency between platform types is already there, especially if one were to mod it to have a uniform set of equations behind the component abilities for the various platforms.
-
im sorry? but i have only any question form me and all my community -
When will the approximate release date version 7.2 ?
7.2 grant too fine changes in gameplay..
-
im sorry? but i have only any question form me and all my community -
When will the approximate release date version 7.2 ?
7.2 grant too fine changes in gameplay..
SoonTM
-
SoonTM
Ahh thanks !!! :) :) :)
-
Last I saw, Steve won't be working much on things for the next three weeks? Employment and all that.
-
SoonTM
Actually I suspect it's more likely
Not SoonTM
-
Generally updates come out when you least expect it.
-
Just like the Spanish Inquisition, Steve's chief weapon is surprise, fear and surprise
his TWO chief weapons fear, surprise, and ruthless efficiency!
er Among his chief weapons are: fear, surprise, ruthless efficiency, and a near fanatical devotion to Poker!
um, I'll come in again...
-
Also remember that for a long time 7.1 was due out "soon" then it was suddenly here, thus "soon" became been and gone in the past. Ergo "soon" has already happened and as such no matter how long we wait for 7.2 it will actually end up as a negative amount of time until "soon" is here.
-
Quantum Soon
-
I always preferred the dream weavers.
-
Probably it will correlate somewhat to his progress reports. I would assume anyways.
-
Just like the Spanish Inquisition, Steve's chief weapon is surprise, fear and surprise
his TWO chief weapons fear, surprise, and ruthless efficiency!
er Among his chief weapons are: fear, surprise, ruthless efficiency, and a near fanatical devotion to Poker!
um, I'll come in again...
:)
-
im sorry? but i have only any question form me and all my community -
When will the approximate release date version 7.2 ?
7.2 grant too fine changes in gameplay..
It will be a while :)
The next version will now likely be v8.0 and will be a C# release. I haven't made much progress lately due to work (and being too tired in the evenings for anything requiring serious concentration :) ). I do have a week off at the start of June so should make some more progress then. Even so it is going to be many months before a new release. In fact, I would be very happy if it was this year but you never know.
-
That's actually pretty good to hear, at the start you said it wasn't likely C aurora would even be finished, now you're confident it'll basically be the next release. That's pretty good. Though some fixes to game breaking bugs might be nice to see before 8 comes out, but I'm sure 8 will have entirely new exciting bugs to experience.
As an aside, could I get the designer mode/ database password? I figure it might be interesting to see what I can customise before it breaks.
-
Oh swapping languages i see.
Should this have an effect on removing restrictions on window sizes?
-
I noticed Steve posted this over in C# Aurora:
"I'm using this post as a placeholder to post any shipbuilding changes. So far the changes are:
1) You can't refit a damaged ship."
This one struck me as odd, because heavily damaged ships were often the ones refit historically, because they were already going to be in drydock for an extended period, and the parts that were going to be replaced were often already going to be removed. If you imagine a ship with a destroyed weapon system going in for a refit, one shouldn't have to replace the old weapon system only to rip it out and put a new one in its place.
-
Is there going to be a final VB6 release with all of the changes that've been announced so that we have something to fiddle around with while we wait for C#?
-
Is there going to be a final VB6 release with all of the changes that've been announced so that we have something to fiddle around with while we wait for C#?
Most likely no as I think he is doing the changes in the C# code now as he rewrites it.
-
Is there going to be a final VB6 release with all of the changes that've been announced so that we have something to fiddle around with while we wait for C#?
The next release will be the C# version, which will include the v7.2 changes.
-
I noticed Steve posted this over in C# Aurora:
"I'm using this post as a placeholder to post any shipbuilding changes. So far the changes are:
1) You can't refit a damaged ship."
This one struck me as odd, because heavily damaged ships were often the ones refit historically, because they were already going to be in drydock for an extended period, and the parts that were going to be replaced were often already going to be removed. If you imagine a ship with a destroyed weapon system going in for a refit, one shouldn't have to replace the old weapon system only to rip it out and put a new one in its place.
I was trying to avoid the current exploit where you can repair a large amount of damage by undergoing a small refit. However, you have a good point about not repairing something you plan to replace anyway. Perhaps it might be better to allow the refit but not repair any damage to components that remain in the new ship. Alternatively I could have a Refit & Repair task which combines the two.
-
I was trying to avoid the current exploit where you can repair a large amount of damage by undergoing a small refit. However, you have a good point about not repairing something you plan to replace anyway. Perhaps it might be better to allow the refit but not repair any damage to components that remain in the new ship. Alternatively I could have a Refit & Repair task which combines the two.
Just set it up so that it charges you for the repair when you refit. It's theoretically possible to refit without repairs, but it's very rarely done.
-
It would be fine in my book if it charged for repairing everything but the refit parts, and the new parts cost.
-
I was trying to avoid the current exploit where you can repair a large amount of damage by undergoing a small refit. However, you have a good point about not repairing something you plan to replace anyway. Perhaps it might be better to allow the refit but not repair any damage to components that remain in the new ship. Alternatively I could have a Refit & Repair task which combines the two.
I've come across a similar situation. Apparently what happens is that the damage becomes untouchable by Damage Control, but the components are still destroyed.
I'd imagine it'd make hull repairs cheaper, but currently, you still need to repair component damage, I figure.
That's just one incident for me, though, I'd figure needs more testing. As is, a "Refit + Repair cost for damaged components which don't get ripped out by refit" seems the best path.
-
Ok, this is a strange question, but now with you porting it to C#, and the xamarin libraries being free, is there any chance that you would, say, let someone here create a port to mobile, or do it yourself, perhaps set it up so that the platforms run off the same codebase?
I doubt that it would be as easy as just changing the GUI depending on build target, most likely far more complex then that as the WPF based code jsut wont work on mobile. But a man can dream
-
Ok, this is a strange question, but now with you porting it to C#, and the xamarin libraries being free, is there any chance that you would, say, let someone here create a port to mobile, or do it yourself, perhaps set it up so that the platforms run off the same codebase?
I doubt that it would be as easy as just changing the GUI depending on build target, most likely far more complex then that as the WPF based code jsut wont work on mobile. But a man can dream
Something I've long thought would be an interesting little game.
Elite, freelancer, all these space trading/exploration games.
Imagine if you had 1 on your phone, where ships are designed similar to Aurora. And it had a workable online play, so combat and ship movement played out in real time. (have tech start at a mid fusion tech area. So a trip to mars might take a couple hours, and the outer solar systen a few days.)
Make it so that as players explore, the "gov't" will make assignments for colonies and supply and demand, so players can then manage the growth of colonies personally by say, shipping colonists or infrastructure around.
With regards to war and combat, have it be that there are a handful of civs that are fighting with it defaulting to a stalemate without player intervention and stuff.
Could be an interesting idea. Maybe I'll write up a full blown topic about it.
-
I'm not sure most mobile devices would handle even C# aurora too well, but I imagine it should be possible to have a host server running Aurora with automatic turn processing while players using a browser or mobile could access the database and control individual empires.
That would be great :D .
I doubt Visual Basic is flexible enough to do it.
-
I'm not sure most mobile devices would handle even C# aurora too well, but I imagine it should be possible to have a host server running Aurora with automatic turn processing while players using a browser or mobile could access the database and control individual empires.
That would be great :D .
I doubt Visual Basic is flexible enough to do it.
VB6 No. But VB.NET most certainly could. You'd probably be limited to Windows devices though.
-
I don't think windows mobile can even run VB.NET.
I just think it could be a nifty side project to have aurora mobile with the C# aurora as well, along with support for remotely stored DBs.
Hell my phone has almost as much RAM as my PC. Yes, aurora is processor intensive but since its turn based (Or whatever you want to call auroras turn system, there's nothing quite like it anywhere) its not a big deal, just means you'll wait longer to process things.
Hell, I'd be more then happy to buy a mobile version of it, if it ever happens
-
I was actually considering the possibility of multiplayer, a server runs the game while letting you use a client version to queue up commands for your empire. I'm sure someone could do a terribly buggy version of this using memory and database hacking when C# drops. Didn't someone make a utility that allowed a spreadsheet to access database information for sorting or organising I other ways? Could even have been possible to do something like that with VB aurora, hell people have made multi client dwarf fortress or KSP somewhat workable, old aurora should work pretty well as everything's in the database as long as you only have a single turn process thread running and come up with a good method of resolving commands coming in from multiple sources.
-
Although I think I know the answer I want to ask just in case. Is there any possible way to get the source code for a port to Android/iOS? I am a developer and would love to play this game on mobile. Not sure how it would work out on smaller screen space but would be something interesting to look into.
Steve
-
I was actually considering the possibility of multiplayer, a server runs the game while letting you use a client version to queue up commands for your empire. I'm sure someone could do a terribly buggy version of this using memory and database hacking when C# drops. Didn't someone make a utility that allowed a spreadsheet to access database information for sorting or organising I other ways? Could even have been possible to do something like that with VB aurora, hell people have made multi client dwarf fortress or KSP somewhat workable, old aurora should work pretty well as everything's in the database as long as you only have a single turn process thread running and come up with a good method of resolving commands coming in from multiple sources.
I had been actually thinking of something along those lines too. Basically, each player would be a "task group" with all task group commands available. They'd make their commands, and the server would update at a set interval executing the commands of each player and their TG.
Things like player personal funds could be tracked externally to aurora.
But it would be terribly inefficient.
Also for travel, I totally forgot about ye olde hyperdrives. TBH I don't even know how they worked, and i can't get old versions of aurora to run properly to mess with them.
-
You could build a super-crappy multiplayer right now if you make a program that takes screenshots of the various reports in-game and accepts commands command-line style like "build earth infrastructure 100 100", then manipulates the game through mouse clicking emulation and such. I've done not-dissimilar things in the past.
-
Tbh the biggest bottleneck is the server. Which would be playing the game in sm mode at intervals... and with a lot of stuff going on, a 5 sec incriment can often take more than 5s
-
This game is in general not remotely suited to multiplayer right now.
-
I was trying to avoid the current exploit where you can repair a large amount of damage by undergoing a small refit. However, you have a good point about not repairing something you plan to replace anyway. Perhaps it might be better to allow the refit but not repair any damage to components that remain in the new ship. Alternatively I could have a Refit & Repair task which combines the two.
I would be tempted to go with the refit not repairing any damage to components that remain in the new ship. In the case of changing the amount of armor as part of the refit, go ahead and do the repair, because I don't think an elegant alternative. Not repairing leaves the option for someone to take a wounded vessel right back out if the situation is critical enough, just with the latest weapon systems, which seems... dramatically interesting. :-)
-
How about Refitting + adding repair costs to components that you do repair and not replace?
-
Though Steve is working on Aurora C# now, I still wondering about some min-maxing in game mechanic.
Currently my design become beehive-like missile launcher in space, solely focusing on missile alpha strike and rely on AMM as their only defence. This design works extremely well in battle, but become less and less interesting, as I can easily lock on NPR AMM ship and got them in first wave, then got others in the second.
Beam weapon is little more than crap. Steve once said he don't want some ship sail through AMM spam with impunity, but Beam ship have to, or several enemy beam ship could beat crap out of what's left of them. It's like bring a knife into gunfight.
-
Though Steve is working on Aurora C# now, I still wondering about some min-maxing in game mechanic.
Currently my design become beehive-like missile launcher in space, solely focusing on missile alpha strike and rely on AMM as their only defence. This design works extremely well in battle, but become less and less interesting, as I can easily lock on NPR AMM ship and got them in first wave, then got others in the second.
Beam weapon is little more than crap. Steve once said he don't want some ship sail through AMM spam with impunity, but Beam ship have to, or several enemy beam ship could beat crap out of what's left of them. It's like bring a knife into gunfight.
Which is why the proper use for beams is on fighter swarms too small to be picked up by enemy active search sensors. With ridiculous amounts of thermal reduction for added stealth.
-
Which is why the proper use for beams is on fighter swarms too small to be picked up by enemy active search sensors. With ridiculous amounts of thermal reduction for added stealth.
It's impossible. NPR AMM sensor will pick up them on ~80m range. Then you can see the great old AMM spam.
If there would be any remake on beam weapon, I want to see some old-style battleship duel at ~100m or 200m range. But it will require remake on lock-on and hitting mechanic, and avoid focusing all firepower on one target. Some player put most sensors on one ship, it will be very bad to got it toasted in one salvo.
Maybe Steve could introduce random distribution on beam weapon hit. Beam weapon could lock on and fire at a battlegroup rather than a single ship , like what happens when you shoot bird flock with shotgun. And shield will be very valuable in this scenario, as we can't simply focusing all firepower on one ship to overcome it. But to avoid impenetratable shield, it may not recharge in battle, or only recharge when turned off.
I also want another two feature. It's annoying to assign hundreds of missile launcher on my ship, so I want "missile turret" to pack these launchers up. Build ship components with factory is a well-known trick to speed up ship building, I even use excel to optimize it, but I still hope we can simply build a "pack" including all components needed.
-
I also want another two feature. It's annoying to assign hundreds of missile launcher on my ship, so I want "missile turret" to pack these launchers up. Build ship components with factory is a well-known trick to speed up ship building, I even use excel to optimize it, but I still hope we can simply build a "pack" including all components needed.
That would be a good idea. I find that very annoying as well and a detriment to large fleet engagements as time goes on.
Would you mind sharing that excel sheet with us, I'm sure plenty of people would use it.
-
That would be a good idea. I find that very annoying as well and a detriment to large fleet engagements as time goes on.
Would you mind sharing that excel sheet with us, I'm sure plenty of people would use it.
Just use cost percent of each component to calculate how many factories should you assign for them, so that they will finish on the same day.
For example, your ship have 30% engine, 20% weapon, 10% sensor, other 40% are small components and armor that can't or not worth to build in factory. So I use 0.3/(0.3+0.2+0.1)=50% factory to build engine, 0.2/(0.3+0.2+0.1)=33% factory for weapon, 17% for sensor. If you simply assign all factory to engine than turn to other components, when they finish producting one kind of component, they stopped working until next time increment. It could save about 20 days for every batch.
But I'm not sure this 20 days worth it or not.
-
Thought I would check. Will Auto-fire and/or Auto-assignment rank limits/priorities be fixed?
-
Thought I would check. Will Auto-fire and/or Auto-assignment rank limits/priorities be fixed?
I believe Steve said that auto-fire will be replaced by something at some point.
-
Thought I would check. Will Auto-fire and/or Auto-assignment rank limits/priorities be fixed?
I'll be rewriting the auto-assignment and auto-fire from scratch.
-
While it's nice to get ships to use a lot more commanders in general, task force structure, as it has been in VB6 aurora, was at least sorta useful for staffing commanders there and emulating some sort of regional military structure.
Is it within consideration to implement some kind of regional position for commanders that at least superficially emulates task force commanders? Less for usefulness, more for the feeling that having 8 levels of military promotions somewhat means something, in one way or another.
-
While it's nice to get ships to use a lot more commanders in general, task force structure, as it has been in VB6 aurora, was at least sorta useful for staffing commanders there and emulating some sort of regional military structure.
Is it within consideration to implement some kind of regional position for commanders that at least superficially emulates task force commanders? Less for usefulness, more for the feeling that having 8 levels of military promotions somewhat means something, in one way or another.
C# Aurora has a hierarchy of 'admin commands' to which you can assign higher-ranked commanders.
-
Hey, @Steve Walmsley , a thought just came across my head: You know how you mentioned tidal locking being a factor in colony costs, right?
How does this apply to moons and the like, who are listed as tidally locked to their respective planet, but are not tidally locked to the sun in a manner that the restriction elaborates on?
-
Hey, @Steve Walmsley , a thought just came across my head: You know how you mentioned tidal locking being a factor in colony costs, right?
How does this apply to moons and the like, who are listed as tidally locked to their respective planet, but are not tidally locked to the sun in a manner that the restriction elaborates on?
Moons aren't affected by tidal lock when calculating colony costs - only planets
-
Another question, sorry if I asked this before:
Will hydrosphere extent limit the maximum population possible if it is frozen solid?
-
Another question, sorry if I asked this before:
Will hydrosphere extent limit the maximum population possible if it is frozen solid?
As things currently stand, yes.
It probably makes sense for a frozen hydrosphere to have less of an impact on total population, although the population would still be limited by the other factors such as temperature (limited in terms of requiring infrastructure) so it may not make much practical difference.
-
Another question, sorry if I asked this before:
Will hydrosphere extent limit the maximum population possible if it is frozen solid?
Not having it do so seems like an invitation for hilarious mishaps when you pack Hoth full of people, melt it, and then realize that it has 99.9% hydrosphere. Pack ice doesn't seem like a particularly good place to live, either, so keeping hydrosphere as a constant seems not entirely unrealistic.
-
Can we have a tech (possibly with corresponding installations) to reduce the negative affect that having too large a hydrosphere has on population limits; to simulate underwater, floating, or stilt-supported cities?
-
Can we have a tech (possibly with corresponding installations) to reduce the negative affect that having too large a hydrosphere has on population limits; to simulate underwater, floating, or stilt-supported cities?
Possibly you could say you need to use infrastructure 'X per million if over Y million pop' for terraformed planets with 0 cost otherwise but a large hydrosphere.
-
Possibly you could say you need to use infrastructure 'X per million if over Y million pop' for terraformed planets with 0 cost otherwise but a large hydrosphere.
Sounds good in my opinion. Infrastructure is up to and including domes and farms suited to keep people alive in the vacuum of a barren planet, after all. Ice with atmosphere would be suitably less problematic. Water a little difficult, but...
-
I need this in my life. It sounds so nice!
-
Do check the C# Aurora sub-forum. All the 7.2 changes are rolled in that version of Aurora. Version 7.2 of VB6 Aurora will not be released at all.
-
i love these new updates! :D