I would like to suggest a new way to exploit distant binary systems.
As we know, hyperdrive didn't really work that well and was removed. Frankly, I do not want to see it back, it would probably still be problematic. That, and having to have a new, different engine for all ships required to make the trip between the distant companions would be problematic.
I think a much more elegant and "realistic" solution would be, after researching an appropriate technology, the possibility to build in-system gates between stars. You could justify it as a technology that "replicates the natural lagrange points", only that because of the imperfect results due to it being artificial, it requires the mass of a star.
Mechanically, it would be similar to the already present gate constructors. You would build a "lagrange constructor" ship, with the appropriate module. Send it to a star. Order a "build gate to <other star in system>" command, and then wait until it is complete. That would create a one-way gate, as for the other normal type of system-to-system gates. If you want a two-way artificial lagrange point, you would send the constructor to the other side and build the gate on that side as well.
I hope that this solution would be relatively simple to implement, and once it's done it can work with the already present code for routing ships. And it would allow to finally use systems with distant stars companions.
Defining which events break up the time progression cycle
Copy of posting from here:
hxxp: aurora2. pentarch. org/index. php?topic=9835
Would be nice if we could choose which actions stop a time progression cycle early and which don't. At least for some of them I cannot understand why they stop it early.
Orbital Habitats
This is a copy of a post in the VB6 7.2 Changes List. I didn't release the updated VB6 version so this is still a change from the released VB6 Aurora.
The population capacity of orbital habitat modules has been increased from 50k to 200k. In combination with the new 'No Armour' option this significantly reduces the cost of building orbital habitats. For example, the habitat shown here supports a population of one million for a cost of 1145 BP. To support one million colonists with infrastructure on a colony cost 2.0 world with acceptable gravity would cost 400 BP, so the colony cost would have to be approaching 6.0 before the Orbital Habitat became cheaper. For low-gravity worlds it is comparable with the cost of low-gravity infrastructure and it is the only option for high gravity worlds or small bodies with low population capacities.
Sidon class Orbital Habitat 1,252,970 tons 162 Crew 1144.7 BP TCS 25059 TH 0 EM 0
1 km/s No Armour Shields 0-0 HTK 132 Sensors 1/1/0/0 DCR 1 PPV 0
MSP 0 Max Repair 200 MSP
Habitation Capacity 1,000,000
Lieutenant Commander Control Rating 1 BRG
Intended Deployment Time: 3 months
Commercial Active Sensor (1) GPS 1920 Range 27.3m km Resolution 120
This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as an Orbital Habitat for construction purposes
About Orbital Habitats:
wouldn't it make more sense to chance the "Commander" of a non-military habitat to a "Civil Admin slot" instead of a Naval Commander slot? The example habitat Steve posted today is a pure living station, so a civil commander would be better suited than a military officer.. a miltary station should still need a military commander
Just thought of this, could FACs get a minor tracking speed bonus? They are so similar to fighters, but lose the best part (from a direct fire perspective). If they could get a 2x bonus (vs the 4x for fighters).
For instance, it'd be great to have a cargo group setup to load materials from a colony once that colony hits a certain level.
This is almost more of an idle thought than a fully-weighed suggestion, but-
At present, the only hard distinctions between ship classes are as follows: Whether a ship has military or commercial drives for the purposes of using jump drives, whether a ship is military or civilian for maintenance and morale purposes, and whether a ship is a fighter or literally anything else.
That last one sticks out to me as the most 'arbitrary' of them. Whether you're a conventional empire, a fledgling TN race, or someone with mastery of the stars strong enough to challenge the [spoilers]- a fighter factory can only produce designs up to 500 tons, across the entire span of the game. Your industrial base and shipyard tech might reach the point where you have gargantuan warships as your standard combatants, but a fighter will only ever be 500 tons or less.
So, my suggestion is to add a new tech line that determines the capacity of your fighter factories. It can be an extremely expensive tech, but I feel like allowing even a bit of wiggle room in the flexibility of those factories would jive well with overall progression.
Could we have multiple tractor units per ship?
I'm trying to avoid that due to complexities of tractor chains.
Improving the way you set up and edit ship formations plus attendant FACS and fighters would be great. With the sensor changes I’m expecting more us of pickets etc but at present it is quite a lot of effort to set up and then edit. Some flex on deciding which elements will detach from the main TG at any particular point in time would be helpful.
I'm not sure how that'd interact with your rework on them, so it's all from VB, I'll admit.
Can you make it so a planet that isn't visited regularly by civilian colony ships slowly becomes more and more attractive to them?
Often when I have one homeworld and say 2 colonies at col cost 0, civilian colony ships will only fly between the homeworld and the closest colony, unless I set it to "stable" for some time. (I suspect even with your change, civilians colony ships would only fly the route that gives them the most wealth/time and forget the rest exists.) So could you make it so if the second, more distant colony hasn't seen civilian colony ships in a while, the reward for civilian colony ships would slowly ramps up until eventually they find it more interesting than the closest colony? It'd slowly go back down as colonists start being unloaded there.
I think it'd be better to make un-flown routes offer more money than make the over-used ones offer less, it'd keep their and your income about constant. You'll likely get a bit more since between the time they decide on their new target that'd bring them just one more wealth and by the time they get there, the reward would have kept going up. If you make their most-used routes less rewarding though they'll go use another, make it less rewarding and keep switching, making all the trade routes less and less rewarding, spiraling down until they're not making any money anymore at all. If there's a hard cap to ensure there's always a decent-ish minimum reward, some routes would still appear less interesting than another's minimum and never be used at all.
I'm not super sure it affects freighters because I only ever get very few of them, but it seems having more trade goods to pick from than just "colonists" helps them fly more randomly and that they might not need incentives to fly to other places.
Can we have more ways to sort and/or filter things? Mostly I'm thinking about the task group list in the task group orders window, and the class list on the class design window.
Right now, it's pretty annoying to constantly have to scroll and search through the list of task groups when I want to issue a new order. So I suggest making the TG list more of a tree, using the hierarchy set up in the Task Force Organization window. This way I could keep commercial TG's, survey TG's, and military TG's separate, without being forced to use goofy names to take advantage of the alphabetical order.
I also suggest something similar for any list of ship classes. Give us a better way to manage them than a single, linear list.
I'll repost a possible change I suggested in the C# discussion thread: that real star systems with known planets in real life generate with those planets. That is, something like Proxima Centauri will always have a 1. 25 Earth-mass planet orbiting 7. 2 MKm away from it. All the known planets would exist in a database, and the existing system generation code would be modified to generate other planets and asteroids around the real planets. So we have Prox Cen b, and then maybe some Jupiter-mass companion and asteroid belts out at 2 AU (or something).
Steve, I'm an exoplanet astronomer by day, and I'd be happy to help compile the planet information for you, suggest modifications to the system generation code, or even help modify it myself.
Please change the way you implement the wait command fro VB6. (...)More options to "wait on a specific action or state" would be nice. E.G.: wait until fleet has joined this fleet, wait until x amount of fuel is in cargo of target fleet (for transporting them from harvesters to a colony), wait until x amount of mineral(s) is at target colony, wait until x amount of installation is at target colony, etc.
I think it would be better to just have them as a regular command, three new ones... Wait in seconds, wait in hours, wait in days. You can then just inject these orders as any regular order and it is easily recognized and tracked.
Steve,
After seeing your screenshot of the named waypoints and specifically the "Fleet Exercise Area" waypoint, would it be possible to assign a waypoint (or other destination) to the Fleet Training action?
If assigned, the fleet would move to that waypoint/location and then stay within a certain distance while performing fleet training exercises?
If unassigned, the fleet would behave as currently designed.
As a secondary item, the UI might need to allow a distance to be added to the order to control how far the fleet ranges from the waypoint. I would require the distance to have a minimum (and default), perhaps the range of the longest ranged missile in the fleet or 25 million KM if no missiles are in the fleet.
Speaking of training missile warships and fighters it might make sense if they actually had to launch fighters/expend live missiles during training or at least could do so to speed up the progress.
I like to RP that each launcher need to fire at least once and Fighters fly one sortie during training to not have a SM fail chance when used in anger for real the first time.
This could also make spying on enemy training manouvers a thing if implemented well.. or maybe I'm going into unnessecary detail here
I guess in that case there should be the option to build cheaper training missilesYep, it will be great!
I guess in that case there should be the option to build cheaper training missiles
Can we get a proper fleet combat interface that allows to assign targets to fire controls on an entire fleet instead of having to cycle through each individual ship?
My idea involves fire controls getting set to a fleet fire control channel. These channels then manage all fire controls assigned to them, so you might have a "Beams" channel, a "Beam PD," a "Missile PD", or a "Missile" channel.
Assigning targets (Multiple selection allowed) to a channel means all fire controls will fire on those selected targets.
Channels could have various options, max salvos in flight, max salvos per target in flight, focus fire, spread fire, point defense availability
Target selection would be inherited if a lower formation doesn't override it. So if the channel "Missile" of 1st Fleet targets the enemy battleships, the channel "Missile" of 2nd Squadron of 1st fleet can target an escort, then the Squadron will fire at the escort until it is destroyed, then will switch to the battleships set by the Fleet wide level.
All this would make handling large battles much easier. I don't see anyone having fun assigning each fighter a target when a hundred fighters clash with another hundred.
I guess in that case there should be the option to build cheaper training missiles
Id kindof prefer a training missile item. Doesn't need to be specially designed by the player but it adds some depth if ships out on training are carrying less live ordnance due to their load of training missiles and get caught by the enemy. Making even more things just an MSP cost is a terrible cop out that isnt even worth adding imo.
All this talk about training missiles got me thinking, could we have crew experience gain make a bit more sense?
Having crew gain experience when their ships armour is hit, but not when the shields are hit always seemed a bit odd. It also seemed odd that causing damage didn't give the firing crew any experience gain.
A system where the crew can gain grade from firing training missiles (and maybe other crews could get grade from shooting them down) could be interesting and would add a bit more depth to Fleet Training. You could set up fleet exercises, have one portion of your fleet try to sink the other, that sort of thing.
It would give you something to do while you wait for your explorers to find aliens. :)
A system where the crew can gain grade from firing training missiles (and maybe other crews could get grade from shooting them down) could be interesting and would add a bit more depth to Fleet Training. You could set up fleet exercises, have one portion of your fleet try to sink the other, that sort of thing.
It would give you something to do while you wait for your explorers to find aliens. :)
That is a very interesting idea. The ability to designate part of your own forces as a 'red force' would not only permit training, but allow players to understand combat without losing ships. Perhaps ships could also be set to 'training mode'. If they take damage from friendly ships that are also in training mode, that damage vanishes when they exit training mode (using the assumption it was all simulated damage). Missiles fired in training mode would reappear in magazines (simulated fire). That could even allow allies to train against each other.
Training mode would end automatically if a hostile contact was detected.
Perhaps some stats could even be unknown or quite inaccurate before you have run weapons through actual tests ( like too hit chance vs certain speeds for example ).
Training mode would end automatically if a hostile contact was detected.
Do you mean something like the following by this?
1) The hit chance when a system is originally designed is a "nominal" value.
2) The actual value would be NominalValue*RandomMultiplier where random multiplier runs from e.g. 0.5x - 2x (uniformly on a log scale).
3) The player would originally see the nominal value in dialogs, but as the system gets exercised/tested/used in combat the value would gradually change to actual value.
4) The value would be tracked on a researched component level. So e.g. an engine might have the power and fuel consumption adjusted, and would use the same parameters in all classes in which it was used.
On the one hand, I think that's really cool and realistic from the point of view of actual systems no matching design specs (e.g. early WWII US torpedoes). OTOH it's more micromanagement. OTGH, it puts a lot more fog of war into component design - minmax players wouldn't be guaranteed that subtly tweaking a design for an extra 5% would actually give them that 5%. It would make component design more like rolling characters in D&D, with the tweak that you have to do real-life testing of the components to tell if you got a lemon and want to reroll the same design.
John
1) The hit chance when a system is originally designed is a "nominal" value.I really like this although I'd say the ranges have to be smaller.
2) The actual value would be NominalValue*RandomMultiplier where random multiplier runs from e.g. 0.5x - 2x (uniformly on a log scale).
3) The player would originally see the nominal value in dialogs, but as the system gets exercised/tested/used in combat the value would gradually change to actual value.
4) The value would be tracked on a researched component level. So e.g. an engine might have the power and fuel consumption adjusted, and would use the same parameters in all classes in which it was used.
In VB6 you can use the Combat Overview window to assign fleet wide targeting.
To simplify managing bigger empires having civilian trade also transport minerals would be an ideal addition. Maybe in terms of using the "mineral limit" values as a measurement of automating those orders. If on a colony the mineral amount is lower than the minimum this generates a demand for this mineral and the civilians take a look around which planets do have that mineral in abundance (maybe two or three times over the minimum value) and transport that to the target planet.
Traders tend to refuse to do long runs in vb6 unless there is no other option, I assume as a marginal cost thing. Could we offer premium prices to get them to do long hauls?
While the random generation routines could be worked over to make more sensible "choices" (and to include fleet graphic), my suggestion for C# Aurora would be for the color and fleet graphic choosen in the Race Details Window to only apply to how the empire is represented on its own galaxy map; and for fleet graphics and system color of other empires to "simply" be an editable setting in the Intelligence Window.
If we go down that route, I think it would be ideal to have a way to specify which planets/colonies civilian freighters are allowed to consider when they're looking for where to acquire minerals, and maybe even the ability to designate which minerals they're allowed to take from which planets/colonies.
Like a source, destination or stable preset for minerals?I'm thinking the colonies would have somewhere in the population/production window (probably in the civilian/ind tab) where you can choose what minerals can be exported from the planet by civilians (if any). This is only because the initial suggestion seemed to be that supplying the minerals for civilian transport shouldn't be done with the normal civilian contract system (to reduce micromanage, I'd assume).
Bit of an out-there suggestion this time:Further, what about it is meant to be futuristic? We could build dome or tunnel cities right now if we had the shipping to actually get to other planets. Why does it need the high-tech materials if we could do it in real life?
Remove the Duranium cost from building Infrastructure, have it purely consume time and money.
Since infrastructure can be created as a trade good, it's already possible to create it without spending resources besides time, technically. You could argue that the ability to prepare it on demand is worth the Duranium cost, but personally I always find myself wanting to take advantage of the 'free' trade good version because TNEs are a nonrenewable resource.
Further, what about it is meant to be futuristic? We could build dome or tunnel cities right now if we had the shipping to actually get to other planets. Why does it need the high-tech materials if we could do it in real life?That's a very slippery slope Barkhorn! Why should a financial center or a military academy need high-tech materials?
Maybe civilian mines could actually deliver the duranium they mine which you don't buy and use that to build infrastructure ( and some other trade goods ) with?
I disagree with the slippery slope thing, the idea of financial centers and military academies not needing them seems quasi reasonable to me, though less so. You might need high tech materials to build high tech computers in order to run adequately advanced simulations for both the purposes of the academies and the financial centers.
The suggestion that its 'backwards' seems exceedingly iffy an excuse, I mean is that really a reason to stop all colonization ever until some duranium can be obtained?
I had mostly assumed it was just a vague attempt at balance, which was somewhat undermined by the free infrastructure the civilian market produces.
Maybe civilian mines could actually deliver the duranium they mine which you don't buy and use that to build infrastructure ( and some other trade goods ) with?I mentioned something like this in the discussion thread when people were talking about economics, and I still like the idea. I think it might be nice to have civilian mines actually generate a Trans Newtonian Mineral trade good, and since this has been brought up it would certainly make sense for it to play a part in the production of Infrastructure at least.
You can already set them to do this.
No. I am taking about the minerals that you don't buy being used for trade goods -> infra generation which is built for free now.
That's a thing?
It's not "a thing" which is why I am suggesting it should be! ::)
( Because neither duranium vanishing into thin air when you don't buy it nor infrastructure being conjured out of thin air for free makes sense )
Considering that civilian mines mine all minerals, and preferentially select for high quality Duranium and Sorium deposits while not selecting low quality deposits of these minerals no matter how large nor deposits of any other materials this doesn't sound like a good idea to me. You'd have to link civilian ship production to mining of other materials as well and work out more of the civilian economical background activity.
I am a bit ambivalent about this. As someone who plays conventional start, it means I will have to devote a LOT of time building infra for new colonies...
Or avoid buying some minerals from CMC, but I'm used to just buying everything, since TN minerals are at a premium when it takes years to leave your home system. And so I generally buy every single scrap of metal they produce.
I have considered this in the past as well, plus fuelling civilian ships from civilian harvesters. It adds a lot of complexity around civilians though and it is probably not worth it. The proposal about Duranium for infrastructure does add a useful extra dimension though as it slows down civilian growth and adds meaningful decisions for players regarding the construction of infrastructure.
You'd have to link civilian ship production to mining of other materials as well and work out more of the civilian economical background activity.That would be nice though. A more robust economic model seams like it should mean the possibility for more differences in the economies of different empires, both in the same game and in different games.
Agreed. At present, I would argue that Aurora is already extremely unrealistic in terms of the level of detail and control that a single individual (the player) has over the empire. Even (especially?) autocrats have to cope with bureaucrats who don't do as they're told.It seems to me that in any game like this, where the workings of government aren't really explored, the assumption is that you're playing as either the government in general or the nation/empire in general, rather than the president/dictator/king (and in fact, in the case of the Civilization series I'm pretty sure that's explicitly stated).
I kind of like the struggling part of conventional starts. Wish that it was modeled in even more details with chemical rockets ( low fuel / inefficient ) more conventional techs, and so on
A small mod for civilian lines, I'd like a Step or Increment function added to transport of installations.For this exact case wouldn't it be easier to just build a cargo ship of your own? Civilian transport is useful but I'm not sure it's supposed to be a full replacement for building your own ships.
IE: Supply: 5xConstruction Factories Step 1
Would put 1 factory in the queue and then upon DELIVERY (not pickup) would put the next factory in the queue.
Supply: 5xConstruction Factories Step 2
Would put 2 factories in the queue and then upon DELIVERY (not pickup) would put the next 2 (or remainder) factories in the queue.
I'm tired of wrecking my civilian trade and infrastructure transport just to move some relatively low priority colony upgrades.
For this exact case wouldn't it be easier to just build a cargo ship of your own? Civilian transport is useful but I'm not sure it's supposed to be a full replacement for building your own ships.
What about allowing civilians to transport everything the player can, with the possible exception of missiles and ground troops?
In real life, the US military doesn't transport rare earth metals in from Africa, even if they are strategically important.
What about allowing civilians to transport everything the player can, with the possible exception of missiles and ground troops?
In real life, the US military doesn't transport rare earth metals in from Africa, even if they are strategically important.
Are there any plans to lift the transport restrictions on some of the buildings? There are few (like the financial centers), but they seem to be arbitrary and an annoyance ingame.
The new screenshots of the Ship view/Naval Organization are looking good. Would it be possible to have a way to identify with a glance at the Naval Org view what ships are damaged (different ship name text color or an '*')? It's currently sometimes a hassle to go back and forth between the damaged ships screen and the fleet/ship window.
Yes please, if it's not already a thing. I'd prefer different colours for the ship names. How I'm thinking it could work is have one colour for undamaged, a different colour (yellow?) if the ship only has armour damage, and then another colour (red?) if the ship has damaged internal components.
Has anyone ever heard about virtual components? No? Well, now you have. But what are they?That would be amazing. Especially for fighters and FACs where component size is so critical.
The idea came to me whilst designing new ships. What I sometimes do is SM a certain component (or maybe three to five variations) to see, if they fit my overall design and how much they affect other components which could lead to designing special components (like a new engine).
If I am happy I basically delete these virtial components and research them the proper way.
So how about a button in the tech designer which does exactly that? Insteat of giving a tech to research it creates a virtual component which can be used in ship design. However, that design can't be locked down as long as it has those components in it. Which leads to the next button in the tech designer. Transfer virtual component to research - which then after proper research converts it to a real component.
These virtual components must be clearly distinguishable, of course.
You can offer government contracts, which the civilians will fulfill, but the price you pay beyond the immediate contract cost is the disruption of the civilian economy. Decisions need both advantages and disadvantages or they aren't decisions.Doesn't this lend itself more to the approach of allowing players to take considerable control over the civilian sector at the cost of ever increasing economic inefficiencies? You can already pick economically totalitarian regimes, so that kind of approach would seem to lend itself to that.
Reposting my suggestion from 7.x as it seems more appropriate here:
Make us design ship hulls rather than ships.
That is, instead of designing a complete ship and tooling a shipyard for it we design a hull with various hull spaces, hard points and mounts where ship system appropriate for said spot can mounted. Have said hull be a racial research, then shipyards can tool for said hull. After that ship variants can be designed from said hull (and possibly researched), by adding different systems in the appropriate places and all variants can then be build in the shipyard tooled for said hull.
See for example Star Citizen and their hull variation for inspiration.
More elaborate explanation here (http://aurora2.pentarch.org/index.php?topic=9627.0)
That would be a complete conceptual rework of how ships fit together, which doesn't really sound that appealing.
Don't remember numbers but you can have one "hull" and a lot of variants of them, and every variant can be built in the same shipyard as basic model.
It would work mostly the same, except that there is a clearer and more logical approach to how ship variants work and more depht.You're talking about moving from a system entirely based around the quantity and quality of components in the ship to a system where we have to design hulls with hard-points and hull-spaces and possibly research both them and their variants. That's significantly different. The current system of "if they're similar enough the shipyard can build both" works fine.
You're talking about moving from a system entirely based around the quantity and quality of components in the ship to a system where we have to design hulls with hard-points and hull-spaces and possibly research both them and their variants. That's significantly different. The current system of "if they're similar enough the shipyard can build both" works fine.
Edit: Sorry for making this a debate in the suggestion thread, lets discus it further in the separate threat I have made for the suggestion, if anyone want to debate it further.
With conditional orders on C# - if there is a similar order to the current conditional order for Fuel Harvesters " unload 90% fuel at colony " , could the new order please include an option that the colony must be one with actual colonists or instead specify a colony by actual name and not just to a colony.
The reason being that on my current game the Fuel Harvesters at Jupiter seem to want to unload 90% of fuel at a passing comet with automated mines , rather than at Earth where my stockpile of fuel is kept.
DavidR
On the combat screen,weapons assigned to fire controls should be green while unassigned ones should be red. Same goes for missiles. Also, if a fire control is selected all of it's weapons should be highlighted.
This would make it far easier to assigns and reassign weapons on ships, as it is fairly confusing right now.
An idea for a new technology: CapacitorThat's a nice idea. I wonder how attractive it would be in reality though? You'd presumably be using up your capacitor charge on long range/low accuracy shots and then be down to slow fire as the range drops and effectiveness increases.
Instead of having a bulky reactor onboard, why not having a smaller one, but loading some batteries which "save" energy that then can be "released" when needed. This would give two basic choices of ship designs:
The Default: Your beam weapons need 46 Energy to maintain a 10 sec firing rate. So you build a reactor of power 23.
The Capacitor: Same energy demand, but instead you load up a reactor of power 11.5 and a battery which can store 230 Energy. The gain would be to have a 5 sec firing rate for the first couple of shots, which then, after the battery is used up, slow down to 20 sec firing rate (because of the smaller power reactor). The gain would also be having a lighter ship which would be faster. Whilst the beam weapons are not charged, the energy would go back into the battery.
That's a nice idea. I wonder how attractive it would be in reality though? You'd presumably be using up your capacitor charge on long range/low accuracy shots and then be down to slow fire as the range drops and effectiveness increases.That's what the AI would do certainly.
It would be an obvious choice for jump defense/assault though where the early shots are what matter most.
But what impact would it have on a Laser? Reduced range? Reduced rate of fire? Reduced damage? All of the above?
What about a turret? What about a CIWS? What about a fuel tank?
Sure. But I don't see that as a problem so much as extra work. (Of course, I'm not suggesting I do the work, so I don't see it as a problem.) You yourself just gave some good examples, and I can do more. Frankly, in the ideal world where Steve took this suggestion and ran with it (while also not adding to his own workload at all, nor the time to release, because he let his magical basement gremlins do the coding), each relevant part would have multiple partial failure states. Some examples:I think the flaw with your plan I see is that many of these changes would be very annoying for players. Any changes to the weapon ranges/fire rates/fire controls is likely to lead to more micromanagement in battle, for instance. Varying speeds and fuel efficiencies will lead to more fuel management problems. etc etc
<snip>
You'd have to have a very strong gameplay benefit to counter-balance adding more micro-management, imho.
I think the flaw with your plan I see is that many of these changes would be very annoying for players. Any changes to the weapon ranges/fire rates/fire controls is likely to lead to more micromanagement in battle, for instance. Varying speeds and fuel efficiencies will lead to more fuel management problems. etc etc
You'd have to have a very strong gameplay benefit to counter-balance adding more micro-management, imho.
Yes, this is the key to any change involving extra detail. Does it add consequential decisions which add game play benefit greater than the additional micromanagement?
Suggestion: Inverse the effect of the "Show Surveyed Bodies" checkbox on the Minerals-tab.
Reason:
Whenever the checkbox is checked it adds a white ring to every body that has been surveyed, which makes the screen very noisy.
That's why I only check it whenever I want to know which bodies still need to be surveyed.
If the effect is inversed you could simply leave it ticked and have your survey ships remove the noise from your populated systems.
Pros:
+ one option less you have to fumble around with every now and then
+ as an added bonus you have less redundant information on the screen, since the checkbox "Show Mineral Concentrations" already implies what has been surveyed.
Cons:
- people will have to get used to the inversed effect
... feel free to add more to the pros and cons if something comes to mind.
Why not have borh? A button for checking surveyed and another dor unsurveyed. That way you get les noise at the begining by seing only the surveyed ones and at the end by seing the unsurveyed bodies.
What if you could have medals you create be auto-awarded to commanders when certain conditions have been met? I. e. If a Ground Commander has been in ten separate battles they get Medal A, if a ship commander's vessel destroys a designated number of enemy ships they get Medal B, if a leader's skill rating in a certain field reaches a certain percentage they get Medal C, etc.
EDIT: And maybe have it as an event as well? That way you know when someone has been awarded one of your medals.
Would it be possible to give ships and ground units an image, similar to that of the alien race image in the Race Details screen?
There was some talk about Jump Gates in the mechanics sections today, so I'll post an idea I've had for a while.
A blockade component that would allow a ship to stop traffic through a jump gate. This would not stop ships with jump drivers. Probably have to make it time limited somehow, perhaps it requires fuel to do it or something similar.
Yes, this is the key to any change involving extra detail. Does it add consequential decisions which add game play benefit greater than the additional micromanagement?
If it's not too late, can we get either "Missile Size Points" or "Maintenance Supply Points" renamed to something else? Or at least, have their abbreviations changed so we don't have two MSPs?
My preference would be to have everything that is currently referenced in M(issile) S(ize) P(oint)s to instead be given in tons, but I could live with MRPs (Maintenance & Repair Points) or Mt (Maintenance) or RSPs (Repair Supply Points) or Quatloos or RoDTs*.
.
*Rolls of Duct Tape
4. Just rename some weapons (and tech lines) as tech progresses. Or give players an option to do so:
Example: Microwave beams from tech level 5 (or some tech level where it makes sense, like a bigger jump in efficiency) to Ion Cannon.
Particle Beams later to Neutron, Antiproton, Multi-Particle. It would be just a new name. No new functionality. The best would if players could specify those names before starting play. This would help imagination a lot making research slightly less tedious.
There's nothing stopping you from doing this on a component basis now.
Working on AI at the moment
I'd like to suggest an "Ignore Colony" button for civilians. There are a lot of times where you need to have a "colony" on a colony cost 0 planet (espionage teams and ground invasions are the main ones) for gameplay purposes but you don't actually want any people sent there.
On a similar but probably more complicated note, I'd also like to suggest allowing multiple species to share the same colony. There are a lot of weird cases in-game right now where you can end up with multiple colonies on the same planet, trying to swap installations, minerals, or ground units between them, and if you try to consolidate them (assuming they are both the same species) into a single colony you risk accidentally deleting something important that you forgot to transfer. I think the biggest issues with this would be infrastructure requirements, but I don't think that would be an insurmountable problem.
Given the changes in species traits, will we be seeing more potential change factors in gene modding? Like traits that let you increase productivity or population density?
In C# Aurora, civilians will not send colonists to any colony with 0 population. This means you need to start your own populated colonies, but prevents the above situation.
If fuel efficiency scaled with % of speed as well, to offer some benefit to operating on reduced velocity, that'd cover the latter. As long as its balanced so that its not superior to an engine built to be run at that slower speed, then it shouldn't have a significant effect on game balance.
Given the changes in species traits, will we be seeing more potential change factors in gene modding? Like traits that let you increase productivity or population density?
Multiple species can't share the same population due to different environmental requirements, which affects not just infrastructure but other factors such as manufacturing efficiency. They can also have different characteristics in C# such as production and research bonuses.
Maybe I'm missing something here, but wouldn't it be fairly trivial in theory ( mathematically at least ) to average weighted for size of population?
A 2 million pop colony with a -20% modifier + a 4 million colony with a +10% modifier becomes a 2*0.8+4*1.1 = 6 million colony with a +0% modifier.
An easier way to manage teams would be nice. At the moment I only recognize if a team has lost one of its members by looking at the commanders screen and see that there are open posts. A warning message like "team incomplete" would be nice. And then if you click on the teams-tab you can only see teams, but not who are in them. Maybe I also want to exchange someone - but that is rather difficult to accomplish because I can only see if someone is in a team when I click on his name in the commanders screen.Teams will not be present in C# aurora right?
Teams will be replaced with ground units or ship components IIRC.
Yes, that is the plan. Geology teams are already gone. Others will be replaced as I code the relevant areas.
Being able to create a corridor through nebulae for ships to move at their usual speeds would be nice.
Maybe a new order to clear away space rubble with weaponry could take of this.
It would create a space in weapon range in which ships can use their normal speeds without obstacles.
As a drawback ships with this order would be easier to detect.
Though I'm not sure if this actually makes sense...
Do ships need armor in nebulae to protect against rubble or because of pressure?
Seems to me you could push it out of the way over time. I'm not saying that should be added, but it seems excessive to declare it impossible.It would take an awfully long time to clear an area, and even if you were to do so, the dust in the nebula isn't motionless, so the area will just get filled back in by more dust.
Age of RaceLike with commander gender, this should go both ways too. Maybe my race of hyper-active marsupials only lives 10 years!
Any chance we can have age changes with Races, that way officers live longer or have alien species living longer then 100 years. A new tech line as well to enhance living age? So instead of hard coding the maximum age you can have it as a fillable field in the Species Tab
Should age correlate with training rates, for balance? If your commanders only live 10 years, you probably need a constant supply of fresh manpower, while with 150 year old commanders you would eventually end up with a huge officer pool at current rates.Age of RaceLike with commander gender, this should go both ways too. Maybe my race of hyper-active marsupials only lives 10 years!
Any chance we can have age changes with Races, that way officers live longer or have alien species living longer then 100 years. A new tech line as well to enhance living age? So instead of hard coding the maximum age you can have it as a fillable field in the Species Tab
Age of Race
A new tech line as well to enhance living age?
However, if we had beam weapons with significantly more range, the race with the longest range weapons wins, regardless of what the other side does, because they would be torn to pieces trying to close that longer range.
Missiles have great range, but require ammo and can be shot down. Beam weapons can fire forever, with no ammo and no possible defence. Their limitation is range. The five second range is convenient technobabble, but the real reason is to avoid breaking the game by making beam weapons too powerful.
Edit: unrelated but I didn't want to make another reply and have it be three in a row.If I'm correct this is all going to under the new OOB screen, anyway
On the combat assignments overview screen, there should be a third tab beyond 'setup fire controls' and 'missiles in flight' named something like 'damage report' that shows current armour, damaged subsystems, and DAC. Basically just copy the one in the individual ship screen, so I don't have to go looking for it.
If you want a long range weapon that can deliver a useful energy load your options at space ranges are basically 'use a self guiding missile' and 'use a chunk mass on a carefully aimed trajectory.'
The reasons for this are mostly to do with energy weapons generally being made of, well, high energy particles. It'd be similar to grabbing a handful of marbles and throwing them, sure, you can get some good distance as glass is dense enough to maintain momentum, but most marbles will scatter across a wide area. If you can actually hit you're better off tossing a single stone of the same weight as all those marbles put together because so much more energy is delivered at the target than with the rather more scattershot impact of the particles.
Which is where the chunk of mass comes in; if you throw something that's not likely to be overly influenced at the relevant range due to gravitational influences, the solar wind and electromagnetic fields you are more likely to hit because fewer things are going to influence the shot. And a chunk of mass, especially something made of tungsten or another high density metal that is not ferromagnetic? It's not going to care much about anything so long as it's fired cold, because there's not going to be any evaporating material shifting the trajectory of the shot either.
Sure, if you're trying to shoot enemy ships with a giant spotlight, but the entire point of a laser is that the beam is coherent. And there are more photons in a laser beam than there are marbles in a handful. The problem with any unguided weapon "at space ranges" is that space is big. Realistically a kinetic weapon would be next to useless unless fired at a very very high fraction of c because the target can simply dodge out the way. When firing a laser beam, or a kinetic weapon close to c, anything beyond a few seconds is pointless because even with the best targeting, random movements by the target can throw it off even if they can't see it coming. Personally I think the way "beam" weapons are handled in aurora currently is generally fine and I don't think it needs some great overhaul to achieve a result that would, ultimately, be overly complicated with convoluted rules and either most likely unrealistic or useless and, as steve has pointed out, would be problemtic for gameplay.
I was reminded (http://aurora2.pentarch.org/index.php?topic=9343.msg101162#msg101162 (http://aurora2.pentarch.org/index.php?topic=9343.msg101162#msg101162)) that rescuing life pods (your own, or somebody else's) usually results in wildly varying overages of life support capacity. I'd like to suggest some sort of "Equalize POWs/survivors across fleet" and "concentrate all POWs/survivors on a single ship" buttons.I believe Steve has already fixed this, so that lifeboat contents are evenly spread out in a TG. I've brought this issue up several times.
Probably based on available life support capacity, so that one's cryo-equipped rescue ship / prisoner transport properly hoards the 150 extra bodies it was designed for.
Funny you mention spotlights.
At space ranges? Even a powerful laser will have diverged considerably even in a vacuum. It might as well be a spotlight.
He's in charge of it, and can tell it where to go, but the captain is responsible for it, and unless the senior staff has issues the captain is really the last authority on the matter.
Sure, if you' Realistically a kinetic weapon would be next to useless unless fired at a very very high fraction of c because the target can simply dodge out the way.
I am not sure at the moment if I am wrong about a concept in VB6 Aurora. If so, just ignore this posting. If I am right, then at the moment a rocket that is led to a target via an active sensor, the moment the active sensor gets lost, the rocket gets lost, right? If not, again, just ignore this.
But if so, it would be nice if in C# Aurora the game would automatically create a waypoint for the rockets where the last known position of the target was, the moment the active sensor got lost. So in case the rocket itself has an active sensor it then can engage that at that waypoint and see, if there is an enemy ship nearby.
That is correct, except I think missiles with sensors will stop at the last location of their target.I am not sure at the moment if I am wrong about a concept in VB6 Aurora. If so, just ignore this posting. If I am right, then at the moment a rocket that is led to a target via an active sensor, the moment the active sensor gets lost, the rocket gets lost, right? If not, again, just ignore this.
But if so, it would be nice if in C# Aurora the game would automatically create a waypoint for the rockets where the last known position of the target was, the moment the active sensor got lost. So in case the rocket itself has an active sensor it then can engage that at that waypoint and see, if there is an enemy ship nearby.
Last time I checked, a missile WITHOUT on-board sensors would self-destruct if it lost target lock. A missile WITH on-board sensors would continue on -- no change in direction or speed -- while constantly looking for a new target.
This second action is the main benefit for missiles-with-sensors, and thus will not be extended to non-sensor-equipped missiles.
Can you make the VB6 saves work with C#?
Can you make the VB6 saves work with C#?
The answer will be "no". Steve only supports previous saves for minor version updates. C# will have completely different information in the database (and possibly a different database system as well - I don't remember); it would take WAY too much time for him to write a front-porting tool.
John
Maybe. Maybe he will write a conversion program. Or someone else with knowledge of the databases will.
Even aside from the structural changes in the code, the changes to the mechanics alone would render saves incompatible and in need of some conversion. You couldn't simply slap an old save into the new game and go, what would happen to ground units for instance?Depends on how many changes there are "under the hood". Aurora has quite a large amount of background database stuff, which might make it quite impossible to "translate" a game from VB6 to C#. Nevertheless, when C# comes out, I plan to take a look into this (and then eventually refrain from it totally because of "too complex to do"). We'll see...
Some current event log notifications are all or nothing, i. e. You hear about officers, administrators, and scientists dying/worsening in health, but most of the time they're just some random person you don't care about. What if you could set certain positions as having high priority notifications so that you can know about the positions you actually care about, i. e. "Your administrator for the position of Sector Commander of Earth Sector has just died. "Seconded. I can't even count the number times I've been confused by my ships not raising their Task Force Training until I find out my TF Commander died a year ago and I've been wasting fuel the whole time.
Thanks. That way it works.
Does that "fire missile once you're at that location" make any sense? In what circumstance can that be senseful?
It is useful for dropping sensor buoys or mines.
I should think this could stand re-naming to avoid confusion. <snip>
In fact, I'd suggest having both - 'Launch missiles' would just act as it does now, while 'launch missiles from' would pull up a sub-menu that allows you to choose whch launcher and missile you want to use.
<snip>I agree that morale limits the long term usefulness of smaller military stations. I like your abstract option 2, but maybe both stations and ships should have a "rotate crew" option that freezes morale in appropriate systems. It could consume MSP and also reduce crew effectiveness (to represent the fact that your key personnel might be off the ship). So you'd have to make a hard decision about whether you cancel shore-leave as a conflict looms.
1) a station equipped with a shuttle bay, in a system with an appropriate colony world or recreation module-equipped station, would not be subject to morale degradation, denoting the ability of said station to send its crew out on regular leave rotations; or:
2) abstract this by a little by allowing a player to opt for such stations to have a higher annual mineral upkeep in order to represent the associated cost in money and material of using (invisible) commercial shuttles to rotate out crews.
Either case should probably also require that such stations have a higher than normal crew requirement, as both the on-station personnel and those currently on shore leave would be unavailable for assignment on new construction.
Not sure how much other players would want a system like this, or how hard it would be to code; I just know it's something that has always frustrated me a little that I couldn't do, so I figured I'd post it here!
-snip-Isn't this what recreational modules are for?
However, what I haven't seen is how the morale of MILITARY stations might be addressed?
There's never been a way to actually 'rotate crews' in Aurora, and that's pretty much torpedoed the real possibility of building stationary defense bases to look after jump points (at least, not ones that weren't prohibitively huge and expensive anyway).
-snip-
Sort of, but they are very big. I think it should be possible to maintain a, say, 60kt defense station indefinitely. That's not very viable if you need to add a 100kt recreational module.-snip-Isn't this what recreational modules are for?
However, what I haven't seen is how the morale of MILITARY stations might be addressed?
There's never been a way to actually 'rotate crews' in Aurora, and that's pretty much torpedoed the real possibility of building stationary defense bases to look after jump points (at least, not ones that weren't prohibitively huge and expensive anyway).
-snip-
You could build ships with recreational modules, and have them tour your stations.Isn't this what recreational modules are for?Sort of, but they are very big. I think it should be possible to maintain a, say, 60kt defense station indefinitely. That's not very viable if you need to add a 100kt recreational module.
Which basically means you've got a 100kT+ ship moving around your defense perimeter being a target. There's a reason you don't do that in real life and instead shuffle personnel around.Could you explain your analogy to real life here? I can't really think of any strictly analogous situation. Military bases around the world are supplied by a variety of means and I would imagine that at least part of the supply chain includes 100kt ships.
Which basically means you've got a 100kT+ ship moving around your defense perimeter being a target. There's a reason you don't do that in real life and instead shuffle personnel around.Could you explain your analogy to real life here? I can't really think of any strictly analogous situation. Military bases around the world are supplied by a variety of means and I would imagine that at least part of the supply chain includes 100kt ships.
Ok, but then I don't understand how this demonstrates that you "don't do" having a 100kt ship moving around. Obviously ingame it's a bit of an abstraction and there's absolutely nothing stopping you from imagining that that's what is happening anyway.Which basically means you've got a 100kT+ ship moving around your defense perimeter being a target. There's a reason you don't do that in real life and instead shuffle personnel around.Could you explain your analogy to real life here? I can't really think of any strictly analogous situation. Military bases around the world are supplied by a variety of means and I would imagine that at least part of the supply chain includes 100kt ships.
Yes, but if you have a military base in the middle of the ocean, you don't charter a cruise ship to dock up and just let people mess around in the ship facilities for a few weeks. You sail them out to the nearest piece of civilization. If anything, you could probably just rotate leave crew onto those replenishment ships, and they'll drop them off when they return.
Which basically means you've got a 100kT+ ship moving around your defense perimeter being a target. There's a reason you don't do that in real life and instead shuffle personnel around.USO tours are basically that. And during WW2 and before it, mobile bordellos were a thing in most armies. A space station is not in combat 24/7 nor is it necessarily sitting in the "frontlines" all the time. Having a recreational ship visit it once a year or two is perfectly reasonable.
USO tours are basically that. And during WW2 and before it, mobile bordellos were a thing in most armies. A space station is not in combat 24/7 nor is it necessarily sitting in the "frontlines" all the time. Having a recreational ship visit it once a year or two is perfectly reasonable.
I'm not sure this is a fair comparison. It seems to me that Ships in Aurora tend to be quite a bit larger than real world ships. Not only that, but the largest cruise ships today are over 200k tons.Quote from: Garfunkel link=topic=9841. msg108423#msg108423 date=1527130335USO tours are basically that. And during WW2 and before it, mobile bordellos were a thing in most armies. A space station is not in combat 24/7 nor is it necessarily sitting in the "frontlines" all the time. Having a recreational ship visit it once a year or two is perfectly reasonable.No USO tour I've ever seen has consisted of the equivalent of the Queen Elizabeth 2 pulling into port for a month.
@Steve Walmsley have you tried or even played MANO (Modern Air Naval Operations) to see how they deal with the display of unit names and vectors? It can be very rapidly a mess, display wise and I think they did a few things right to de-obfuscate/unscramble display. I'm basing my observations on some screenshots, I did not play the game. But for example at a certain zoom level, individuals ships are replaced by a TF icon, and you can tooltip it. Will Aurora C# supports tooltip on the main map?
I'd love a TN Economy Info windowI don't know how flexible such a thing could be programmed; but I imagine some kind of "universal query system" with which we can create our own "analytical statistics". Especially if you play a multi fraction game, VB6 Aurora lacked quite a bit in giving you the tools to keep everything in overview.
The total empire wide production of every mineral, maybe collapsible to see the biggest production location.
The same for mineral expenditure, and maybe stockpiles.
I don't know how flexible such a thing could be programmed; but I imagine some kind of "universal query system" with which we can create our own "analytical statistics". Especially if you play a multi fraction game, VB6 Aurora lacked quite a bit in giving you the tools to keep everything in overview.
He'd also have to be careful to prevent queries from breaking the DB. Don't want to let anyone run any table drop queries.
Well there is a database for the game, so we could have a screen that display the results of SQL queries on the database, maybe let you save a few different queries so you could easily access multiple reports. That'd be about as much flexibility as you could get.That would be something... . Being able to create some queries, which will be updated after time progressions... .
I was wondering if some of the calculations needed could be pre-done in the background whilst the user is working on his move.
The problem with "follow" is that when you kill the contact you were following, the order stops and your ships stop dead in their tracks. This can be deadly if you're kiting beam ships.
From what I see STO weapons are currently limited to beam weapons only.
Could we also get STO missile launchers? Without long range missiles an enemy can always park themselves outside of beam range and bombard the planet, without being able to strike back.
Further, having a beam fire control for each STO weapon sounds quite expensive. Would it not make more sense to have the fire control as a separate vehicle, where then one can combine however many guns and fire controls into a battery as you think useful?
"Would it not make more sense to have the fire control as a separate vehicle"Used to be, but a lot of modern ground units incorporate their own tracking systems, especially SPAAGs (which beam weapons would be relatively analogous to).
That's what they do in real life usually, at least for land-based AA. Ships tend to all have their own fire control.
No missiles, because I want to avoid the complexities of ground units with ordnance, which also require long-range sensors and long-range fire controls. Beams are nice and straightforward. The fire controls are cheaper for ground units. I wanted every ground unit to be self-contained - otherwise it gets complex to track (for the player as well), so this is the same overall cost for separating fire controls without the micromanagement.My PDCs just all used to be massive missile bases, with beam armament for PD only. STO units could draw ordnance from the planetary stockpile directly, and if the sensors are the problem, one could add them to the deep space tracking installations.
My PDCs just all used to be massive missile bases, with beam armament for PD only. STO units could draw ordnance from the planetary stockpile directly, and if the sensors are the problem, one could add them to the deep space tracking installations.
I really don't want to be out ranged, and if you are behind in beam tech, you cannot compensate with your missiles
By the way, you're mistaking the purpose of STO ground units here. As Persona012345 said, their purpose is: The enemy can either glass the planet at long range (if they can get past your PD), at the cost of most of its infrastructure and population.I feel like it's worth pointing out that since in C# you'll be able to target planets with beam weapons, being outranged in beam tech is actually something to worry about. Unless I'm misremembering how things will work, an enemy with longer range beams could park a beam ship just out of your range, and destroy your STO with its weaponry, with minimal damage to population and infrastructure.
Or try to conquer it with its infrastructure still present, a fact that is hard to accomplish because planetary assault is harsh.
And if you're behind in tech, tough luck. Build more orbital missile bases.
Yes, but I think its a bit more complicated than that because of the new terrain modifier rules. On a flat grassland planet then being outranged is a major worry, but on a mountain or jungle world it will be very difficult for a ship to successfully hit your SFO.By the way, you're mistaking the purpose of STO ground units here. As Persona012345 said, their purpose is: The enemy can either glass the planet at long range (if they can get past your PD), at the cost of most of its infrastructure and population.I feel like it's worth pointing out that since in C# you'll be able to target planets with beam weapons, being outranged in beam tech is actually something to worry about. Unless I'm misremembering how things will work, an enemy with longer range beams could park a beam ship just out of your range, and destroy your STO with its weaponry, with minimal damage to population and infrastructure.
Or try to conquer it with its infrastructure still present, a fact that is hard to accomplish because planetary assault is harsh.
And if you're behind in tech, tough luck. Build more orbital missile bases.
I feel like it's worth pointing out that since in C# you'll be able to target planets with beam weapons, being outranged in beam tech is actually something to worry about. Unless I'm misremembering how things will work, an enemy with longer range beams could park a beam ship just out of your range, and destroy your STO with its weaponry, with minimal damage to population and infrastructure.
It is possible, but as stated:The fact that they aren't STO's. This matters both because of how significant roleplay is to Aurora and because STO's are mechanically different from orbital bases, such as benefiting from fortification and using ground unit officers.
1) If you want to prevent sieges, build more orbital defense stations. Especially if you are out-teched. Do not let the enemy close if at all possible. I don't get this complaint about being outranged. Before, you had PDCs. Now, you're going to have orbital bases. It is the very SAME thing. You can put on your orbital defense bases the same things you had in your PDCs. They are functionally identical. So... what exactly is the problem with orbital defense bases?
... And also, I will be blunt. If you are out-teched and out-produced by an enemy who has a lot more ships than you, things ARE supposed to be hard. The state of the rules, as they should be, seem balanced enough for me.It's not about things being hard, it's about having no response. If the enemy out-ranges me with beam weapons, and I have no missiles, there is nothing I can do. This is not the same as being out-ranged with missiles, where I at least have the ability to shoot at incoming missiles. I understand that, too an extent, weapon failure is intended to deal with this, I feel that a mechanic which involves no player interaction is not a satisfying form of defense.
Before, you had PDCs. Now, you're going to have orbital bases. It is the very SAME thing. You can put on your orbital defense bases the same things you had in your PDCs. They are functionally identical. So... what exactly is the problem with orbital defense bases?
I'm actually kind of curious about how practical orbital stations would be with shield generators instead of armor, since that would mean (I think) you could build them with industry. But building them with shipyards would be workable too; they still get hefty bonuses compared to ships.I think shield generators qualify as military, which disqualifies them from use on stations.
I know in the current version of Aurora PDC beam fire controls get a 50% range bonus, I don't remember if it was mentioned if that gets applied to the new ground based STO beam weapons? But it might help with the worries over being bombarded from out of range.
I'm actually kind of curious about how practical orbital stations would be with shield generators instead of armor, since that would mean (I think) you could build them with industry. But building them with shipyards would be workable too; they still get hefty bonuses compared to ships.I think shield generators qualify as military, which disqualifies them from use on stations.
I know in the current version of Aurora PDC beam fire controls get a 50% range bonus, I don't remember if it was mentioned if that gets applied to the new ground based STO beam weapons? But it might help with the worries over being bombarded from out of range.
Space stations can use military components, though. The discussion was whether you could use industry instead of shipyards to build defense stations, which means they'd also have a bunch of guns and missile launchers that would also be military components.http://aurora2.pentarch.org/index.php?topic=8495.msg106758#msg106758
As far as I can tell the only limitation on stations to be built by industry is "no armor"; I don't know if shields instead of armor would be practical, but it seems perfectly rules legal.
Space stations can use military components, though. The discussion was whether you could use industry instead of shipyards to build defense stations, which means they'd also have a bunch of guns and missile launchers that would also be military components.http://aurora2.pentarch.org/index.php?topic=8495.msg106758#msg106758
As far as I can tell the only limitation on stations to be built by industry is "no armor"; I don't know if shields instead of armor would be practical, but it seems perfectly rules legal.
There are two more limitations: No engines, and no military systems to qualify for being a station.
Also, in real life larger does not necessarily mean more difficult to develop, as certain things get easier if you have the necessary space available compared to cramming everything into the smallest possible compartment.But that is already in the game: A larger engine with the same total power is cheaper to develop. And cramming the same engine into a smaller housing (by increasing the power multiplier) increases cost by a lot.
But that is already in the game: A larger engine with the same total power is cheaper to develop. And cramming the same engine into a smaller housing (by increasing the power multiplier) increases cost by a lot.What I mean is that larger engines with the same power density are more expensive to develop, for example using either 8 size 10 engines or 2 size 40 engines with the same total power (same power multiplier) in the same space. Here you are trading off HTK for fuel efficiency.
I'd say the larger components are attractive enough the way they currently are, especially low power commercial engines.
Mass drivers should have the option of sending a specific number of minerals, instead of just turning them on and remembering a couple years later to stop sending all your stuff to Mars. Also, the ability to pick and choose which minerals are used.
When starting a new game allow the user to 'outlaw' or make unavailable certain technology/technological paths (such as the various weapon paths) so that if the user would like, for example, a more 'Star Wars' experience they can just get rid of missiles and the rest leaving only lasers and mesons. I imagine this could also apply to shielding / stealth tech depending on peoples tastes (since I don't think anyone will be wanting to get rid of the production paths etc) but being able to determine the weapon types, and thus the 'meta' of the military in a game could be nice.Definitely this. As long as you also had the option to remove say missiles and mesons. Because Mesons always seem cheaty and annoying.
When starting a new game allow the user to 'outlaw' or make unavailable certain technology/technological paths (such as the various weapon paths) so that if the user would like, for example, a more 'Star Wars' experience they can just get rid of missiles and the rest leaving only lasers and mesons. I imagine this could also apply to shielding / stealth tech depending on peoples tastes (since I don't think anyone will be wanting to get rid of the production paths etc) but being able to determine the weapon types, and thus the 'meta' of the military in a game could be nice.
This is possible but tricky. The simple implementation would be to flag certain techs as not available. However, those techs affect other parts of the game. For example, removing missiles would require removing techs such as warhead strength or missile agility, but that would leave ordnance factories, ordnance-related logistics installations, the missile design window, ordnance factory options in production, etc. You would also need to remove magazine techs, but they would still be an option in the Create Project window. It isn't as straightforward as ticking techs to exclude. Also, by excluding missiles, you also exclude recon probes, geo-survey probes or sensor buoys, unless you only exclude warheadsIs the simple fix just to have a No-missile checkbox that disables warhead techs and tells the NPRs to only use the beam AI schemas?
In addition, NPRs would have to be able to handle any missing parts of their normal tech, which would not be straightforward at all.
It might be possible at some point to have (for example) a non-missile version as an option for a game, with all the various missile-related elements removed. However, they are an integral part of the game so it would take a while to identify everything that would change. Maybe for a post-launch version.
When starting a new game allow the user to 'outlaw' or make unavailable certain technology/technological paths (such as the various weapon paths) so that if the user would like, for example, a more 'Star Wars' experience they can just get rid of missiles and the rest leaving only lasers and mesons. I imagine this could also apply to shielding / stealth tech depending on peoples tastes (since I don't think anyone will be wanting to get rid of the production paths etc) but being able to determine the weapon types, and thus the 'meta' of the military in a game could be nice.Well, there is torpedo tech in the SW universe; they are simply very low range, equal to the beam wepaons (one might argue, that in relation to range, the SW universe is the opposite of the Aurora universe - beams (as we have learned in TFA) can be quite long range ... . However (as we have learned in TLJ), shielding is quite strong over distance - which is the technobabble reasoning for their short range fights ... .
However (as we have learned in TLJ), shielding is quite strong over distance - which is the technobabble reasoning for their short range fights ... .Is it? Man I prefer the old EU explanation that EW got so good they're down to having to rely on their own eyes.
Quote from: TMaekler link=topic=9841. msg108837#msg108837 date=1530869769However (as we have learned in TLJ), shielding is quite strong over distance - which is the technobabble reasoning for their short range fights . . . .Is it? Man I prefer the old EU explanation that EW got so good they're down to having to rely on their own eyes.
Is the simple fix just to have a No-missile checkbox that disables warhead techs and tells the NPRs to only use the beam AI schemas?I imagine the new way NPRs will be planning out their ships and fleets prevents it from being that simple.
I would very much appreciate an option to turn off Jump Gate Constructors (whatever they will be called in the new version)
There is an option to remove all jump technology and have gates everywhere, but I would very much like to play with jump drives only.
Since jump gates are needed for the civilian traffic, wouldn't it be better to restrict it to commercial only?I thought I read somewhere that civilians now knew how to deal with jump tenders. I can't find the source though, I am afraid
When I am building ships quickly I try to use planetary industry to build some of the big ticket items so that the ship construction time is reduced. This ends up being a bit of a pain a lot of times as I am building x engines, y turrets, etc. If we could have some means of putting together several items in a package and selecting the package to be built instead of the individual items it would help. For example a recent cruiser I built had 4 engines, 3 heavy laser turrets, 4 point defense turrets and 4 different fire controls. If all of this could be combined into CA1 package it would make using the planetary industry to speed up ship construction much easier.
As a note by prefabricating much of a ships components I was able to take a 30,000 ton ship with a nominal 23 month build time and instead have it finished in 5 months. Better than 4 times as fast, which can be a big advantage in an emergency.
Brian
Would it not make more sense to have industry being able to directly support shipyards to some extend, reducing build times, instead of fiddling with component stockpiles. Change it so you are able to assign industry to ship construction, and flag shipyards to use industry support, accelerating the project as if it was building the components, without any of the micromanagement.
Problem is the component mechanic supports and enables ALOT of other game mechanics.I agree that these are valid uses of components, building them in factories to accelerate construction however is not one of them in my opinion, because it requires tedious micromanagement.
Salvaging of ship components.
Scrapping ship components ( for science and resources ).
Trading of ship components ( rp multi faction games )
Moving of ship components from an industrial planet to a separate dockyard planet.
Repairs and upgrades using ship components.
I agree that these are valid uses of components, building them in factories to accelerate construction however is not one of them in my opinion, because it requires tedious micromanagement.
My suggestion would be to allow industry to support shipyards as if you were microing them, to get the same advantage out without having to place all these orders.
I agree that these are valid uses of components, building them in factories to accelerate construction however is not one of them in my opinion, because it requires tedious micromanagement.
My suggestion would be to allow industry to support shipyards as if you were microing them, to get the same advantage out without having to place all these orders.
3 of my 5 points are impossible or pointless to do without allowing factories to produce components... So your agreement also becomes a direct contradiction to your own statement/suggestion that follows it.
Whitecold: Are you suggesting that Steve rip out the current mechanism of having factories build components that are then used by SY, or are you proposing an additional mechanism that leaves the current one in place?Well, ripping it out would solve the discrepancy as well, but my idea would be to leave it in place, and calculating the BP needed for the components which are still missing from a design, and allowing industry to support the shipyards up to that amount of BP.
Thanks,
John
Disabling increment adjustment, its really annoying.
Well, ripping it out would solve the discrepancy as well, but my idea would be to leave it in place, and calculating the BP needed for the components which are still missing from a design, and allowing industry to support the shipyards up to that amount of BP.
Quality of Life suggestion: When one does not select a name pattern for new ships, Aurora automatically counts upward. But that numbering might be off for whatever reasons. Being able to set the next free number would be great.
Or even better: give us the option to create a naming scheme for every ship class, so it not automatically is the class name + increment, but rather something which can be chosen by the user.
Options: <class name>, <number increment>, <letter increment>, <manual text>, etc.
That doesn't address the desire to build components in advance of when you intend to build the ships. Allowing industry to support shipyards actively is great, but sometimes I'm still researching and developing the tech for a new generation of ships, and won't be done for a couple years, but I got the technology to start making the new engines right now. I don't want to lose two years of production time, so I start manufacturing the engines ASAP.You should still be able to all do this! The original suggestion was to be able to build packages of components to accelerate ship construction, instead of ordering every single component individually. My suggestion is to automatically calculate BP, not requiring any packages to be ordered but directly construct components in factories as they are needed.
Other random quality of life suggestion: Instead of suggesting random new companies for naming components, have a separate panel where you can save the names of the companies you have in your game (and generate suggestions)
Then you can select the company name in a dropdown menu, as you will be likely be reusing company names.
Other random quality of life suggestion: Instead of suggesting random new companies for naming components, have a separate panel where you can save the names of the companies you have in your game (and generate suggestions)
Then you can select the company name in a dropdown menu, as you will be likely be reusing company names.
Strongly in favor of this, would hugely help me keep things straight (I might actually start using company names again).
Absolutely in favor, I would *love* to actually keep consistent companies for equipment and ordinance and so forth.
Another suggestion of mine: Remove the missile engine component, and revert to designing missile engines along with the missile itself, adding options for boost modifier/engine generation/fuel consumption there.Maybe add the ability to create missile engines in missile creation without removing missile engines as a component?
The missile engine component adds an annoying step to missile design. Unlike regular engines they are very rarely reused, every new missile usually requires a new engine. Furthermore there is no incentive to use multiple engines on a missile if you can use a single one instead, and I don't think there should be one.
Also, I'd suggest to remove the cap on missile engines to 5 MSP, especially with the new incentives to large missiles.
The missile engine only adds unnecessary complications, you should not have to use an external performance calculator to find out which engine size you need in the first place.
Other random quality of life suggestion: Instead of suggesting random new companies for naming components, have a separate panel where you can save the names of the companies you have in your game (and generate suggestions)I think that's been discussed before, could be wrong.
Then you can select the company name in a dropdown menu, as you will be likely be reusing company names.
Absolutely in favor, I would *love* to actually keep consistent companies for equipment and ordinance and so forth.
Would be interesting to have civilian companies also as additional production capacity - not only handing transport orders to them, but also building equipment... .
Absolutely in favor, I would *love* to actually keep consistent companies for equipment and ordinance and so forth.
Would be interesting to have civilian companies also as additional production capacity - not only handing transport orders to them, but also building equipment... .
I was thinking about something like this. Assuming a capitalistic society, what if you had something along the following:
Multiple companies, each with fields of interest (maybe some are like Rolls Royce and focus on engines, other are Intel like and do computers, etc).
Instead of designing a new technology, you instead put out a request to these companies. "I want a 15cm UV laser with 10sec recharge". Then after some time, these companies come back with their prototypes that each have small tweaks to your request.. Maybe the Foobar Corporation's laser does an extra point of damage but takes a little extra material to make. But Barfoo Inc has a model that can fire a little farther. Then you pick the one you want and it becomes a thing to build.
For instance, it'd be great to have a cargo group setup to load materials from a colony once that colony hits a certain level.
You can already do this one in VB6. The move order is "Load Mineral when X available"
I have considered something on these lines before (as well as civilian companies building warships for the government). Probably won't in the first version, but will consider for the future.
Civilians don´t spend fuel right now. Expanding civilian activities to much would decrease the fuel scarcity push towards colonizing new worlds or conquering them. If civilians used fuel, they would frequently end reserves without the player being able to do much about it. Maybe they should use fuel with players being able to limit their consumption?, this with a rebalancing of the typical ammounts of fuel found on default empire planets.
A Cockpit module as a smaller alternative to a Bridge. It seats a Pilot and may seat a Navigator/Sigint or a Gunner/Bombardier. This new type is not intended to replace current mid to long range 'Ship' type fighters, but gives options for smaller short to medium ranged craft.
Civilians don´t spend fuel right now. Expanding civilian activities to much would decrease the fuel scarcity push towards colonizing new worlds or conquering them. If civilians used fuel, they would frequently end reserves without the player being able to do much about it. Maybe they should use fuel with players being able to limit their consumption?, this with a rebalancing of the typical ammounts of fuel found on default empire planets.
Engaging the new rules is exactly what I was hoping for. What I was suggesting is a small ship that only has a bridge crew, limited to a pilot and possibly one other officer, like a modern two-seat fighter. It also has the natural vulnerability that a single hit to the cockpit is an instant kill, since that is the only crew on board. I fully understand if Steve doesn't go for it, but I'd love to be able to build X-wing fighters.A Cockpit module as a smaller alternative to a Bridge. It seats a Pilot and may seat a Navigator/Sigint or a Gunner/Bombardier. This new type is not intended to replace current mid to long range 'Ship' type fighters, but gives options for smaller short to medium ranged craft.
Any ship of 1000 tons or less can leave the Bridge off altogether. (Unless that's been changed and I've forgotten?) Did you mean to engage the new Command & Control (http://aurora2.pentarch.org/index.php?topic=8495.msg101818#msg101818) rules? Because at first glance this suggestion looks seriously imbalanced in that context, to the extent of undercutting stated design goals.
Civilians don´t spend fuel right now. Expanding civilian activities to much would decrease the fuel scarcity push towards colonizing new worlds or conquering them. If civilians used fuel, they would frequently end reserves without the player being able to do much about it. Maybe they should use fuel with players being able to limit their consumption?, this with a rebalancing of the typical ammounts of fuel found on default empire planets.Expanding the player hauling orders so set-and-forget automatic hauling routes can be set up would eliminate the need for civilian inter-system mineral and fuel hauling, rendering the entire question moot. It would also allow regular supply lines to the new deep-space orbitals to be created. The new fuel orders are a good start, but don't quite go far enough. This is the single biggest item on my wish list, since there is currently no actual way to do it, and it gets very micro-managy very quickly.
I also would suggest to rework transport commands; especially in the area of transferring a certain amount of industrial complexes to other planets.This is what civilian shipping orders are designed for. Hopefully the rework that is going into C# will make it more stable than VB.
What happens most of the time is, that I transfer AutoMines to new locations when a planet has gone exhaust. Which means setting up one cycle of transport and then repeating or set it to cycle move. But lets say I want to transfer 120 AMs to Planet X and 90 to Planet Y. Then I have to set up two task forces and be exact with the repetitions. But later down the line another transport task group finishes and I simply want to add those ships to transfer to Planet X also. I then have to either recreate everything after merging or set up another task group but reduce the original group. If the task group simply would have an order stack of
a) load AMs on Planet A
b) unload AMs on Planet B
c) refuel on Planet E
d) Cycle until 120 AMs have been transferred (auto reduce after every load command)
then I just could join the new ships to that task group and have an easier micromanagement.
Additionally, if the route to the target would be recalculated each time (and if Lagrande Points could be included), it would use those points when usefull, otherwise not. In VB6 if you have set up such a cycle with LGPs and they move around, the trip might become longer than necessary.
This is what civilian shipping orders are designed for. Hopefully the rework that is going into C# will make it more stable than VB.Yes. I think it would be a nice feature, if you could do what the civilians are doing, with your own ships.
I'd like to suggest automated terraforming: as soon as you install terraforming bases or move them into orbit, they should automatically add or remove gases until the planet is suitable for life. The algorithm would be simple in most cases: if the temperature cost is greater than 2.0, add greenhouse or anti-greenhouse gas until it's <= 2.0, then add or remove oxygen until that's at an acceptable level, then finish adjusting the temperature if necessary.I'm not against this as an option, but the ability to manually set gas levels has both strategic and RP value, in making a planet suitable for more than one species (who aren't necessarily all present), deciding how much work I want put in to making the planet inhabitable, and making a blockaded planet unsuitable for the enemy.
It would be one less thing to have to micromanage, and less calculation/guesswork to have to do.
Good point, I'm just not sure how that could be implemented with the current order style.This is what civilian shipping orders are designed for. Hopefully the rework that is going into C# will make it more stable than VB.Yes. I think it would be a nice feature, if you could do what the civilians are doing, with your own ships.
Terraforming would be easier (meaning less micro) if you could set a target composition of the desired atmosphere (that screen will tell you the final temperatures etc.); and once you have set the target, the TFs work towards that goal. So basically not having to do it by your own step by step, meaning gas by gas... .
Variable size for stuff like:
- Crew Quarters
- Hangar Space
- Maintenance Space
- Maintenance Storage
- Fuel Storage
etc.
Instead of having to research or having available 6 different fixes sizes, I think it would make more sense to be able to tell the program how much it should add to the ship and the overall size and material use of that module is calculated based on that size.
Why not instead have both a number for how many tanks its held in? I. E set the fuel to 1. 5 million tons in 6 tanks, with each tank taking up equal space and holding equal amounts of fuel. Perhaps even have a field for smaller tanks, if you really want too.Quote from: TMaekler link=topic=9841. msg109140#msg109140 date=1532957911Variable size for stuff like:
- Crew Quarters
- Hangar Space
- Maintenance Space
- Maintenance Storage
- Fuel Storage
etc.
Instead of having to research or having available 6 different fixes sizes, I think it would make more sense to be able to tell the program how much it should add to the ship and the overall size and material use of that module is calculated based on that size.
Larger fuel modules (for example) are more efficient in terms of cost while you may want multiple smaller modules to allow for redundancy. Otherwise life support or fuel could be lost all at once. The variation is to allow player choice. BTW I think for C# the smaller life support systems are all available without research (not at home at the moment so can't check).
That way leads to unrepresentable fractional numbers, which are best avoided. On the other hand, specifying the number of tanks and the number of liters per tank would work nicely. An HTK option like we have for magazines, representing compartmentalized or self-sealing tanks would work, too.Quote from: Steve Walmsley link=topic=9841. msg109141#msg109141 date=1532959461Why not instead have both a number for how many tanks its held in? I. E set the fuel to 1. 5 million tons in 6 tanks, with each tank taking up equal space and holding equal amounts of fuel. Perhaps even have a field for smaller tanks, if you really want too.Quote from: TMaekler link=topic=9841. msg109140#msg109140 date=1532957911Variable size for stuff like:
- Crew Quarters
- Hangar Space
- Maintenance Space
- Maintenance Storage
- Fuel Storage
etc.
Instead of having to research or having available 6 different fixes sizes, I think it would make more sense to be able to tell the program how much it should add to the ship and the overall size and material use of that module is calculated based on that size.
Larger fuel modules (for example) are more efficient in terms of cost while you may want multiple smaller modules to allow for redundancy. Otherwise life support or fuel could be lost all at once. The variation is to allow player choice. BTW I think for C# the smaller life support systems are all available without research (not at home at the moment so can't check).
Armor and crew quarters for now just nicely round any fractional numbers. I would go on and propose to overhaul the interface for designing ships, instead of clicking items many times, add to each row a number field where you can type in a number. For launchers, beams, fire controls this would simply be the amount requested, while for fuel it could be capacity, or for engineering spaces the desired maintenance time.That way leads to unrepresentable fractional numbers, which are best avoided. On the other hand, specifying the number of tanks and the number of liters per tank would work nicely. An HTK option like we have for magazines, representing compartmentalized or self-sealing tanks would work, too.Quote from: Steve Walmsley link=topic=9841. msg109141#msg109141 date=1532959461Why not instead have both a number for how many tanks its held in? I. E set the fuel to 1. 5 million tons in 6 tanks, with each tank taking up equal space and holding equal amounts of fuel. Perhaps even have a field for smaller tanks, if you really want too.Quote from: TMaekler link=topic=9841. msg109140#msg109140 date=1532957911Variable size for stuff like:
- Crew Quarters
- Hangar Space
- Maintenance Space
- Maintenance Storage
- Fuel Storage
etc.
Instead of having to research or having available 6 different fixes sizes, I think it would make more sense to be able to tell the program how much it should add to the ship and the overall size and material use of that module is calculated based on that size.
Larger fuel modules (for example) are more efficient in terms of cost while you may want multiple smaller modules to allow for redundancy. Otherwise life support or fuel could be lost all at once. The variation is to allow player choice. BTW I think for C# the smaller life support systems are all available without research (not at home at the moment so can't check).
Larger fuel modules (for example) are more efficient in terms of cost while you may want multiple smaller modules to allow for redundancy. Otherwise life support or fuel could be lost all at once. The variation is to allow player choice. BTW I think for C# the smaller life support systems are all available without research (not at home at the moment so can't check).
Desired maintenance time isn't the only consideration. For example, some of my survey/recon ships have short rated maintenance times because they don't have enough MSP to repair their sensors, but the AFR is low enough they usually get back for overhaul before they actually experience a failure.Armor and crew quarters for now just nicely round any fractional numbers. I would go on and propose to overhaul the interface for designing ships, instead of clicking items many times, add to each row a number field where you can type in a number. For launchers, beams, fire controls this would simply be the amount requested, while for fuel it could be capacity, or for engineering spaces the desired maintenance time.That way leads to unrepresentable fractional numbers, which are best avoided. On the other hand, specifying the number of tanks and the number of liters per tank would work nicely. An HTK option like we have for magazines, representing compartmentalized or self-sealing tanks would work, too.Quote from: Steve Walmsley link=topic=9841. msg109141#msg109141 date=1532959461Why not instead have both a number for how many tanks its held in? I. E set the fuel to 1. 5 million tons in 6 tanks, with each tank taking up equal space and holding equal amounts of fuel. Perhaps even have a field for smaller tanks, if you really want too.Quote from: TMaekler link=topic=9841. msg109140#msg109140 date=1532957911Variable size for stuff like:
- Crew Quarters
- Hangar Space
- Maintenance Space
- Maintenance Storage
- Fuel Storage
etc.
Instead of having to research or having available 6 different fixes sizes, I think it would make more sense to be able to tell the program how much it should add to the ship and the overall size and material use of that module is calculated based on that size.
Larger fuel modules (for example) are more efficient in terms of cost while you may want multiple smaller modules to allow for redundancy. Otherwise life support or fuel could be lost all at once. The variation is to allow player choice. BTW I think for C# the smaller life support systems are all available without research (not at home at the moment so can't check).
Desired maintenance time isn't the only consideration. For example, some of my survey/recon ships have short rated maintenance times because they don't have enough MSP to repair their sensors, but the AFR is low enough they usually get back for overhaul before they actually experience a failure.It is not about if maintenance times catches all aspects, it is about what parameter is the most convenient to control. 12 months maintenance time tells you something, 5 engineering spaces may be anything or nothing. Similar to how you want to control the number of armor layers rather than the total amount of armor.
Just a minor suggestion, "Conventional Steel" should probably be called Rolled Homogeneous Armour (RHA) as that is more specific and technical and perhaps the middle conventional armour tech can be Explosive Reactive Armour (ERA) with the top tech being Composite Armour before we get to duranium (though those two are more debatable and there's probably not too much of a problem with "composite" and "advanced composite").
As for crew requirements.
Further down the line could we have computer effeciency ylyechs which reduce the amount of crew needed, while making the ship exorbitantly expensive.
We could then make things like the Honorverses Recon Drones and Missile Pods, which don't have any crew at all but can be retargeted and flown like an Aurora ship.
I actually use Drones and missile pods, remove everything from a fighter hull and stick a big passive sensor on it , then set it deployment time to 200 months and you have an early warning drone you can deploy anywhere without getting spotted easily ( just put it some distance away from anything so nothing fly's to close. same with missile pods remove the engines from a fighter, put the deployment time to 200 again and if you deploy tractors to your ships you have a missile pod, could also make variants like Missile defense pods etc. and keeping them small you can take advantage of your fighter production resources. . :)Quote from: Frank Jager link=topic=9841. msg109255#msg109255 date=1533579807As for crew requirements.
Further down the line could we have computer effeciency ylyechs which reduce the amount of crew needed, while making the ship exorbitantly expensive.
We could then make things like the Honorverses Recon Drones and Missile Pods, which don't have any crew at all but can be retargeted and flown like an Aurora ship.
For now you can only create a missile drone. It will be fine to create a system of no crew ship that can be hacked by enemy if discovered. Then stealth technology will be even more important, because that drone can be very small, and with new sensor system that have much more sense. And also more electronic warfare :)
P. S For roleplay AGI civilisation it could be technology that make ship less depends on robots/cyborgs.
I actually use Drones and missile pods, remove everything from a fighter hull and stick a big passive sensor on it , then set it deployment time to 200 months and you have an early warning drone you can deploy anywhere without getting spotted easily ( just put it some distance away from anything so nothing fly's to close. same with missile pods remove the engines from a fighter, put the deployment time to 200 again and if you deploy tractors to your ships you have a missile pod, could also make variants like Missile defense pods etc. and keeping them small you can take advantage of your fighter production resources. . :)
I think that DSTS should require one million population per installation. As it stands you can, for very little cost, get almost complete ckverage of everythkng important. Making it so you can't just plop them on an asteroid makes sense for pickets actually useful while maintaining the home turf advantage you get from full DSTS coverage in established systems. You can still make the outposts but it would no longer be invisible or almost free to do, but intelligence becomes harder to come by and more involved without adding much micro at all.
I think that DSTS should require one million population per installation. As it stands you can, for very little cost, get almost complete ckverage of everythkng important. Making it so you can't just plop them on an asteroid makes sense for pickets actually useful while maintaining the home turf advantage you get from full DSTS coverage in established systems. You can still make the outposts but it would no longer be invisible or almost free to do, but intelligence becomes harder to come by and more involved without adding much micro at all.
I don't think this makes sense. Why not just make DSTS less effective?
I'd actually think it'd be interesting to make sensors in general less effective across the board. Mid-tier sensors can sweep half a system
Can you have higher racial training levels cause less recruits, because I don't know why you'd ever want it on anything other than 5 if it gives you the best stuff for the same amount of recruits. It wouldn't make sense for the same amount of soldiers to pass into the navy/army either if the training is more difficult. Thats why there are fewer Special Ops than regular soldiers.
Perhaps not a bad idea for the functionality of the damage reduction, actually. Instead of using max SP, use remaining SP as a function of ship size to determine damage stopped. Of course that changes shields from being a Big Ships tool to being something usable on all ships.That makes shields way too similar to armor. They would need a massive buff in efficiency to make up for the loss of protective ability at low strength, putting them in conflict with armor.
I guess I just generally like the idea of shields not competing with armor for defensive ability, but that there is some synergy between the two that makes it advantageous to put both on your ship.
What if you combine the leaking shield concept with the way it works now? Shields would deteriorate as they get hit, and as they deteriorate they absorb less and less damage per hit.I am afraid that makes them too similar to armor. Also, with leakage determined by FULL shield strength, HTK of shield generators become important. Getting a hit through that causes shock damage blowing up a shield generator would be the reason to mount redundant generators. Also, I'd rather have consistent leakers instead of a cliff edge where you either beat shield regen, and break the shield to nothing or do only superficial damage because the shield stays at close to full strength.
What if you combine the leaking shield concept with the way it works now? Shields would deteriorate as they get hit, and as they deteriorate they absorb less and less damage per hit.I am afraid that makes them too similar to armor. Also, with leakage determined by FULL shield strength, HTK of shield generators become important. Getting a hit through that causes shock damage blowing up a shield generator would be the reason to mount redundant generators. Also, I'd rather have consistent leakers instead of a cliff edge where you either beat shield regen, and break the shield to nothing or do only superficial damage because the shield stays at close to full strength.
Having a higher rate of leakers but independent of current shield strength ensures the stronger party takes some damage as well, which is what the leakers should mostly accomplish.
Why not just have two types of shield generators? The current ones and ones that have a higher strength but let some damage leak through?The buffering effect of reducing strikes means the leaky shields will be more survivable. 10 half strength hits do much less damage to armor than 5 full strength ones in armor penetration.
What do you think about the ability to equip fighters with different payload? Like you can do in real life. So one would be able to us a plane depending on the situation it would be needed for..
I think reactors probably shouldn't be possible to put into a pod, but it might be fun to put lasers, missiles, sensor, EW, or fire control pods onto fighters interchangeably. It would also be more or less consistent with modern multiroles to some extent, which also tend to do that sort of thing.That does not make much sense, a single laser is already 3HS, which is a massive investment in tonnage. A laser mount on a fighter is more a spinal mount than an underwing gunpod. Also, how would you penalize flexible mounts compared to permanent ones, and what is there left to design on a fighter but the engine?
I'd point out the lower laser size limit is totally arbitrary at the moment. I do however agree that something like that in particular souldn't be swappable for a fighter sized thing.
Also, the equalizer was a perfectly effective weapon (it let the thing destroy tanks for heck sakes), and the harrier was quite useful for the fact that it was very flexible, despite its overall low speed. It performed fine in the Falklands war for instance.
I could see lasers as they are now not being particularly swappable for fighter sized things, but that doesn't mean hardpoints shouldn't be possible period. It would be terrible if it was a system that only applied to fighter sized vessels arbitrarily, so lasers could easily just only be swappable for much larger vehicles. And then fighters have reduced multi mission capability purely off of the fact they are so small.
I'd point out the lower laser size limit is totally arbitrary at the moment. I do however agree that something like that in particular souldn't be swappable for a fighter sized thing.
Also, the equalizer was a perfectly effective weapon (it let the thing destroy tanks for heck sakes), and the harrier was quite useful for the fact that it was very flexible, despite its overall low speed. It performed fine in the Falklands war for instance.
I could see lasers as they are now not being particularly swappable for fighter sized things, but that doesn't mean hardpoints shouldn't be possible period. It would be terrible if it was a system that only applied to fighter sized vessels arbitrarily, so lasers could easily just only be swappable for much larger vehicles. And then fighters have reduced multi mission capability purely off of the fact they are so small.
I'd like to point out that any change in minimum beam weapon size will be immediately picked up as PD weapon. There it likely has a larger impact than for beam fighters.
The entire hard point system seems overly complicated, all these things need to be separately produced, stored in magazines... We already have refits to make small modifications. We could add a refit module that allows very limited refits away from a population, assuming all required components are available, the refit is cheap enough.
That way you avoid all the additional overhead of hard points, and dealing with items outside armor, and what exactly can be placed there.
As far as I am aware,this is the current thinking on fighters in relation to ground combat (where different roles are relevant): http://aurora2.pentarch.org/index.php?topic=9792.msg106084#msg106084This cover most of what I was thinking about. Happy...
Unless I've missed something this is still the idea for ground support roles. If you mean being able to swap out the missile launchers on a fighter for lasers or whatever on a whim then that is something else (not something I'd be in favour of personally).
I'd point out the lower laser size limit is totally arbitrary at the moment. I do however agree that something like that in particular souldn't be swappable for a fighter sized thing.Oh I completely agree that all the weapon sizes in Aurora are arbitrary, but the system as-it-is seems fairly balanced to me in ship-to-ship combat. Any change to weapon sizes would have far more impact on the far more important aspect of the game (ship-to-ship combat) rather than in fighter combat, and would thus be a major change.
Also, the equalizer was a perfectly effective weapon (it let the thing destroy tanks for heck sakes), and the harrier was quite useful for the fact that it was very flexible, despite its overall low speed. It performed fine in the Falklands war for instance.
The discussion on training and order delays has had me thinking again about general crew readiness for combat. It's always bugged me that you can have a ship sit on a warp point for three years doing nothing and then suddenly be all guns blazing within the space of a five second increment. That level of readiness just seems odd to me.Wow. This is such an great idea and seems fairly easy to implement. Maybe on TG/Fleet basis and not ship basis? Two thumbs up.
I know its something as a player you can just RP by not firing straight away but I'd be interested in seeing some mechanic in the game to address this although accept that for the small number of times it would have an impact it may be a bit much. As to how that could work I was thinking about 2-3 states for the crew to be at that impact delays to initial but not subsequent orders such as:
- Normal Watch: CIWS no delays, beams short delays, missile batteries longer delay, fighter launch etc longest delay - no impact
- High Alert: As above but with no delays on wider range of actions and reduced delays on fighter launch etc - 2 times rate on deployment time
- Red Alert: Basically then just use normal command delays where applicable based on crew training etc - 5 times rate on deployment
So basically if you want to travel you are on normal alert, if you are worried you go to Amber and then its a decision as to when you go to Red Alert. It clearly makes jump point defence more of a logistical challenge and might make the investment in stealth ships more interesting if it means you have a better chance of catching an enemy out. Probably one for the AI to ignore though.
The discussion on training and order delays has had me thinking again about general crew readiness for combat. It's always bugged me that you can have a ship sit on a warp point for three years doing nothing and then suddenly be all guns blazing within the space of a five second increment. That level of readiness just seems odd to me.
I know its something as a player you can just RP by not firing straight away but I'd be interested in seeing some mechanic in the game to address this although accept that for the small number of times it would have an impact it may be a bit much. As to how that could work I was thinking about 2-3 states for the crew to be at that impact delays to initial but not subsequent orders such as:
- Normal Watch: CIWS no delays, beams short delays, missile batteries longer delay, fighter launch etc longest delay - no impact
- High Alert: As above but with no delays on wider range of actions and reduced delays on fighter launch etc - 2 times rate on deployment time
- Red Alert: Basically then just use normal command delays where applicable based on crew training etc - 5 times rate on deployment
So basically if you want to travel you are on normal alert, if you are worried you go to Amber and then its a decision as to when you go to Red Alert. It clearly makes jump point defence more of a logistical challenge and might make the investment in stealth ships more interesting if it means you have a better chance of catching an enemy out. Probably one for the AI to ignore though.
You can already do that with MIRVed missiles. You pay an overhead for the missile bus and are limited to having to fire the entire hardpoint at once and at the same target, but those seem like very reasonable kinds of costs. In your example, you'd mount four size 13 boxes and each of them would load either a size 13 bombardment weapon or a size 1 bus wrapped around two size 6 shipkillers. You only get 8 shipkillers instead of the 9 you would get on a dedicated platform, and you have to fire them in pairs rather than singletons. That trades a 12 % reduction in loadout and barely perceptible reduction in targeting flexibility for the strategic flexibility of multiple loadout configurations, which does not seem like an onerous level of trade-off.As far as I am aware,this is the current thinking on fighters in relation to ground combat (where different roles are relevant): http://aurora2.pentarch.org/index.php?topic=9792.msg106084#msg106084This cover most of what I was thinking about. Happy...
Unless I've missed something this is still the idea for ground support roles. If you mean being able to swap out the missile launchers on a fighter for lasers or whatever on a whim then that is something else (not something I'd be in favour of personally).
One point which was included also in my thoughts was the ability to have fighters which can change ordonance Koadjutors for ‚normal‘ battle usage ase in VB6 aurora. At the moment everything is limited to the size of the missile launchers. So if I would want a multi combat role fighter I would have to design every missile fitting to one launcher size. What I would like to have added would be an option to load for example
a) either 9 S6 missile for space to space combat (total of 54)
b) or 4 S13 missiles for space to ground bombardment (total of 52)
when using box launchers.
So with a S6 box launcher (because they are mounted on the outside of the ship), it would also be possible to mount a lesser number of missiles which could be bigger in size, up to the sum of all box launchers x number of them (54 in the example above, 9 x 6).
MIRVS don't really provide that kind of flexibility unless you want to SM in every combo you want as needed.That's because you shouldn't be able to strap five missiles onto four hardpoints just because the total mass comes to the same number, unless you go to the trouble of building a custom system like a MIRVed warhead. You can't just wake up in the morning and decide that you want to load fifty Stingers on your missile destroyer instead of the five cruise missiles it's designed for (or eight Sidewinders on your fighter-bomber in place of the two 2000 pound bombs it's designed to carry), just because the total displacement would be the same. What you might be able to do is attach a purpose-built missile pod, but you'd still need to manufacture that pod and get it to your staging area. Effectively a fire-and-forget launch platform wrapped around a number of missiles, which in Aurora would be represented by a two-stage system with multiple warheads.
Why? There is no engineering problem with this. There are even an example of modern nuclear submarines that can carry multiple surface to air missiles packed into a single VLS designed for a ballistic missile. They even have small diametre quad packs of bombs that can go on a single hardpoint for aircraft. Sure a dedicated platform designed to fire those missiles would be much more effective, but a little penalty in mass or loadout is well worth the versatility allowed.MIRVS don't really provide that kind of flexibility unless you want to SM in every combo you want as needed.That's because you shouldn't be able to strap five missiles onto four hardpoints just because the total mass comes to the same number, unless you go to the trouble of building a custom system like a MIRVed warhead. You can't just wake up in the morning and decide that you want to load fifty Stingers on your missile destroyer instead of the five cruise missiles it's designed for (or eight Sidewinders on your fighter-bomber in place of the two 2000 pound bombs it's designed to carry), just because the total displacement would be the same. What you might be able to do is attach a purpose-built missile pod, but you'd still need to manufacture that pod and get it to your staging area. Effectively a fire-and-forget launch platform wrapped around a number of missiles, which in Aurora would be represented by a two-stage system with multiple warheads.
What you should reasonably be able to do with full flexibility is attach a smaller missile to a hardpoint designed for a larger one, and the box launcher already lets you do that out of the box (you should pardon the, pun) with no need for workarounds.
But Harrier is a terrible fighter plane and was mainly used due to its VTOL capability, that allowed "mini-carriers" to ferry them to combat zones. The plane lacks an integral gun and thus the need to carry a gun-pod like the Equalizer. So it kinda proves the point Scandinavian was making.The harrier was used for two purposes:
Even the smallest lasers (10cm Focal Size) are 150 tons. With Reduced-size you can bring it down to 100 tons but then you have to accept quadrupled recharge times. That's still 20% of your 500 ton fighter, or even a higher percentage if you're making a faster interceptor-type fighter.Which is equivalent to a large missile box launcher. Also, pretty sure there are much more extreme reduced-size options available.
To me, swapping something that is twenty percent of the mass of a fighter does not sound doable. Even the B-52, that could carry 31 tons of bombs, couldn't just swap those bombs with some other weapon, because it was purpose-built to carry bombs in its cavernous bomb bays and nothing else.Again, why not? A B-52 can carry 31 bombs, or it could carry 60 smaller bombs, or 1 giant bomb, or guided bombs, or standoff bombs with 200 mile range, or cruise missiles with nuclear tips. Hell, pretty sure they have ballistic missiles that can be fired from bombers. Nothing is stopping someone from putting 100 sidewinders in a B-52, there just isn't a reason why you would.
Hi Steve, if it's possible could NPR missile firings not reduce the game to 5 second increments? I'm sure there's a reason behind it but I don't like that it gives away what the enemy is doing.That is because the computer still has to calculate damage and weapon use, even when the player cannot see. If it didn't pause, you could have hour long turns with no feedback into what is happening. Don't worry, I'm sure C# Aurora will be quicker.
There are even an example of modern nuclear submarines that can carry multiple surface to air missiles packed into a single VLS designed for a ballistic missile. They even have small diametre quad packs of bombs that can go on a single hardpoint for aircraft. Sure a dedicated platform designed to fire those missiles would be much more effective, but a little penalty in mass or loadout is well worth the versatility allowed.Yes, there are examples of building a custom weapons package that lets multiple missiles be packed into a single larger tube. This still has to be purpose-built, it's not a minor hot works you can decide to make on the fly as you load the ordnance for deployment.
Nothing is stopping someone from putting 100 sidewinders in a B-52,For transportation, sure. But you can also do that with box launchers (they provide full magazine capacity equal to their max missile size).
I would like to suggest bomb bays, although I'm sure that has been suggested before.A system that could launch ordnance that doesn't require active targeting, such as buoys or bombs, would make excellent sense. If done right it could also be used to greatly simplify the micro around minelaying. Which is badly needed at the moment.
The SSBN's were never intended to be hot-swapped for differing munitions, the subs were pretty much built around a given missile, and would keep it pretty much until the end, not exactly modular. So naturally, there wasn't a lot of wiggle room in making them functional with another weapon system, so their tubes received a more rigorous re-design to accommodate the tomahawks and wiring to control each. Enough that they got redesignated as SSGN's, and can't easily return to SSBN duties without similar reworking.
Mk-41 VLS for US and allied warships however was built with modularity in mind. Every visit to port could see a different weapon placed in the same cell if there were reason to change it out/reload. Effectively box launchers coming in sets of 5 or 8 per module, each receiving an encased munition allowing a common interface for multiple weapon types, the wiring and adaptation of the interface to any given munition occurs inside the weapon canister—the ship only ever talks to canisters, the canisters translate/relay to the weapon/ship—, which slots neatly into the cells/"box launchers" and serves as launch tube for the weapon within.
That brings me to RIM-162 ESSM, those fit four to a canister, and required zero alteration of the Mk-41 vls hardware to accommodate. They fit into a standard canister, the canister fits the VLS. On any given voyage they will decide if they will sail with the standard set of munitions, or if they need to change it up a bit. Often the ships are not completely stocked these days, no need, but there is literally nothing stopping an arleigh burke destroyer from going to sea with 96 tomahawks or 384 ESSM, other than a desire to have a mix of munitions available at all times. The change between is literally a crane lifts one canister out, and lowers the other into place.
As far as I'm concerned, so long as there is no sharing of capacity between cells/boxes —2 size 15 box launchers cannot fit 5 size 6 missiles, only 4— , and commonality of munition within each box launcher, I don't see an issue with it. But only for box launchers. Standard launchers are an entirely different beast.
Its no great leap to assume standardised canisters are utilised to simplify training of ordnance personnel, transportation, and warehousing of munitions. So long as you obey the canister's dimensions, anything goes.
I would expect there to be some minor loss of capacity in building the separators between cells for multiple munitions, but not significant, just enough to say you can't fit 5 size 3 rounds into a size 15 launcher, but could probably get 2 size 7's into it. I would expect that the more munitions loaded, the more is lost to dividers, such that if you could just get 2 size 7's into a size 15 launcher, you'd never fit 14 size 1's as well, but maybe 10-12.
see here: https://www. alternatewars. com/BBOW/Weapons/VLS_Baselines. pdf
and here: https://en. wikipedia. org/wiki/Mark_41_Vertical_Launching_System
Maybe have a range of possible missile sizes a certain sized box launcher can accept rather than giving a player carte blanche with what can be stuffed in there.
maximumMunitions=INT(launcherSize^0.6)*2
maximumMunitionSize=INT(launcherSize*(1-0.015*(munitions-1))/munitions)
INT(15*(1-0.015*(4-1))/4)
INT(15*(1-0.015*3)/4)
INT(15*(1-0.045)/4)
INT(15*0.955/4)
INT(14.325/4)
INT(3.58125)
3
roundup(size*packing/(1-0.015*(packing-1)),0)
roundup(4*4/(1-0.015*(4-1)),0)
roundup(16/(1-0.015*(4-1)),0)
roundup(16/(1-0.045),0)
roundup(16/0.955,0)
roundup(16.754,0)
17
Size 17, so you're wasting 1 MSP to quad pack with size 4. There is no engineering problem with this...All the examples you gave and really, all the examples there exist, are just that - purpose-built engineering solutions. They already exist by the fact that any launcher will accept any missile as long as it fits. What QuakeIV and TMaekler were suggesting isn't that, it's much more because it would mean free swapping of all weapon systems with any other weapon system "on the fly". And that is not possible today, nor is it something that seems to be possible in the near future. And it shouldn't be brought into Aurora because it opens a massive can of worms with the combat model.
...for a first generation VTOL jet with no computer assisted flying, the Harrier did everything needed. It was never going to compete with land based air superiority fighters, not even catapult launched aircraft can compete with a contemporary land based aircraft. Honestly, the Harrier wasn't THAT bad...That wasn't the argument. The Harrier was used as an example by QuakeIV to justify his suggestion that multirole fighters work and are great. You merely reinforced my earlier counter-point: that the Harrier, as capable as it was to perform a wide variety of tasks from a wide variety of bases, was NOT a great plane. It would always lose out to a dedicated specialist plane. I'd rather take an A-10 or SU-25 for ground support, and an F-15 or MiG-29 for air combat, or an AH-64 or a Mi-24 to operate from an improvised landing strip. Harrier's strength was that instead of 3 different platforms, you only needed to buy one.
Which is equivalent to a large missile box launcher. Also, pretty sure there are much more extreme reduced-size options available.Box launchers, however, can get down to 50 tons. Lasers, even with the half-size reduction, which is the best there is, are still at least 100 tons. You're probably mixing it with GC that can be reduced down to 25 tons. That's still a lot more than 2% of platform mass.
Again, why not? A B-52 can carry 31 bombs, or it could carry 60 smaller bombs, or 1 giant bomb, or guided bombs, or standoff bombs with 200 mile range, or cruise missiles with nuclear tips. Hell, pretty sure they have ballistic missiles that can be fired from bombers. Nothing is stopping someone from putting 100 sidewinders in a B-52, there just isn't a reason why you would.Because a weapon system does not exist in a vacuum. B-52 bomb bays were built to accommodate very few, very specific bombs. The specs of those bombs were then built into the bombsight. Every time the USAF wanted to get the B-52 to utilize a new weapon system, it had to modify or rebuild the bomb bays as well as the bombsight, and later the targeting computer(s). That's one reason why "smart kits" were invented, allowing mechanics to just slap them on "dumb" iron bombs, which in turn enabled bombers to drop semi-smart bombs without the need to modify the plane itself. The program to get the B-52 to fire cruise missiles was a big and costly one, requiring the design of purpose-built cruise missile for them, as well as a new version of the bomber itself to support it. So only the B-52G and H models can fire the AGM-86 ALCM, not any other model of B-52.
We already have the ability to use missile launchers to shoot any type of missile as long as it fits. The ability to just swap-on-the-fly missile launchers with lasers or of violating launcher sizes as long as some arbitrary "total" isn't surpassed, goes against my sense of realism and immersion, nor does it seem like something that is really needed.
Agreed on modularity being a feature of the future. Logistics wins wars, and simplifying your logistics with a singular model versus several dedicated, if capable enough, can yield enormous gains.This is peacetime logic.
No, logistics is an immensely important part of warfare and is often the make-or-break factor in real life war. Having equipment that can do the job, albeit less well, is always preferable to not having the equipment to do the job at all. Having for example one type of multirole plane doesn't just mean that you have the equipment though, even if more can't be delivered. It also means that you only need to produce replacement components, fuel, mechanics and everything else that goes along with operating a plane, for that single type of plane and that they are compatible with every plane there. This immensely simplifies the production chain and allows you to ramp up production faster, and simplifies the logistics of delivering these things where they need to go.Agreed on modularity being a feature of the future. Logistics wins wars, and simplifying your logistics with a singular model versus several dedicated, if capable enough, can yield enormous gains.This is peacetime logic.
Quote from: Scandinavian link=topic=9841. msg109532#msg109532 date=1535266176No, logistics is an immensely important part of warfare and is often the make-or-break factor in real life war.Quote from: amram link=topic=9841. msg109531#msg109531 date=1535259978Agreed on modularity being a feature of the future. Logistics wins wars, and simplifying your logistics with a singular model versus several dedicated, if capable enough, can yield enormous gains.This is peacetime logic.
. . . snip. . .
Better equipment wins battles, better logistics wins wars. . . .
If you field more models of equipment, with a force structure that is equivalent in performance to an adversary which meets you in quantity and quality through a single model, they hold a significant advantage.If you use two models and his single model is three times as expensive in manufacturing time and supply chain complexity, he will have to outspend you by fifty per cent just to have parity in quantity and quality.
Take air combat. two forces. One has 30 fighters and 30 attack planes. The other has 60 multirole.That will never be the force structure of the two opposing sides in your hypothetical. The side that uses dedicated planes will always field a force more heavily weighed toward air superiority on day one, because once one side has established air superiority it is very hard to take it back, while flying CAS can clearly wait a few days for reinforcements to be brought up from rear echelons (if it could not, you would not be able to fly all of your fleet in the air superiority configuration during your alpha strike). At a 3:2 kill rate, they only need a 45:15 split to wipe out your whole force on the first day, at which point you will never recover the attrition game (assuming equivalent total production capabilities, and that they produce air superiority planes at a 3:1 rate to ground attack), and they are free to fly CAS with impunity.
Production benefits as well, less competition for limited resources means the quantity of the stock will be increased. Distribution, warehousing, acquisition, everything benefits.Yes, I've also read Lockheed's advertising copy.
Not sure how this forum works with regards to the difficulty of thread splitting, would you be willing to split off the debate of that particular suggestion into its own thread?
starts here: http://aurora2.pentarch.org/index.php?topic=9841.msg109413#msg109413
Fuel Report window: being able to exclude selected ships in this view would help getting rid of unnecessary clutters (I do have lots of sorium harvesters which I really don't need to see in this window). So an option box for every entry which when enabled would exclude that ship from showing in this list (with an option button at the top of course to enable showing them) would be nice.
Alternatively having a general option button in the class design window which sets this flag for the whole class might be a less micromanage alternative.
Improvement on TG/Fleet loading logic.
Currently, in VB6 Aurora, a TG ships load one by one. Once the topmost transport is full, then it starts loading the next transport and so on down the list. This isn't much of a concern with cargo freighters until very late in the game when you might have a TG of 20+ super-freighters, at which point the loading and unloading times get really noticeable. Or you don't use Cargo Handling Systems for some reason.
Snip
Improvement on TG/Fleet loading logic.
Currently, in VB6 Aurora, a TG ships load one by one. Once the topmost transport is full, then it starts loading the next transport and so on down the list. This isn't much of a concern with cargo freighters until very late in the game when you might have a TG of 20+ super-freighters, at which point the loading and unloading times get really noticeable. Or you don't use Cargo Handling Systems for some reason.
But with troop transports, this becomes noticeable way earlier. As an example, I have a TG of 8 ships, each capable of carrying a full division. I ordered the TG to load 2 divisions, a bunch of REP and GAR units and a whole load of CBs. The TG has been loading units forever and is still going strong. Because it takes about 27 days to load one CB. I forgot to check how long the individual battalions or the divisions took. Next time, I'll just create individual TGs for each troop transport, it's not a problem.
But for C#, ensuring that each ship in the Fleet/Sub-fleet loads concurrently instead of consecutively, would be an awesome improvement.
6. Several times now I attempted to create a merchant powers, small nations which relied on trade income to function. I failed every time. The coming changes to trade will help a lot, but the main issue is that shipping lines always build colony ships - even when there is nothing to colonise (small nation don't do much of it after all). Which means their income is spent on useless ships, making it much more difficult for them to grow (they can even fail completely) and creating less taxes. As such I'd love to see an option to prevent shipping lines from building a specific type of ship, so that they would build only what's profitable.I feel like this could be solved by better AI and I believe I have proposed logic that would help with this somewhere, though it's possible I just meant to post it then forgot to. In any case, with the multi-leveled AI coming in C# aurora I feel like there are plenty of possibilities to make the AI smarter when it comes to choosing what ships to build. I wouldn't even mind if it was deliberately imperfect, for example basing it's purchasing decisions heavily on prior income - IRL, markets usually take time to adapt to sudden changes after all - rather than having it be predictive, but I do think there needs to be some mechanism to push companies towards the demand rather than it being fairly arbitrary. It also might result in companies tending to specialise which might be cool to see.
6. Several times now I attempted to create a merchant powers, small nations which relied on trade income to function. I failed every time. The coming changes to trade will help a lot, but the main issue is that shipping lines always build colony ships - even when there is nothing to colonise (small nation don't do much of it after all). Which means their income is spent on useless ships, making it much more difficult for them to grow (they can even fail completely) and creating less taxes. As such I'd love to see an option to prevent shipping lines from building a specific type of ship, so that they would build only what's profitable.I feel like this could be solved by better AI and I believe I have proposed logic that would help with this somewhere, though it's possible I just meant to post it then forgot to. In any case, with the multi-leveled AI coming in C# aurora I feel like there are plenty of possibilities to make the AI smarter when it comes to choosing what ships to build. I wouldn't even mind if it was deliberately imperfect, for example basing it's purchasing decisions heavily on prior income - IRL, markets usually take time to adapt to sudden changes after all - rather than having it be predictive, but I do think there needs to be some mechanism to push companies towards the demand rather than it being fairly arbitrary. It also might result in companies tending to specialise which might be cool to see.
1. Please allow us to modify characteristics of various stellar bodies or, even better, add custom ones.A dialog where one can select several parameters as to a rough category of system that should be created would help much.
2. System generation algorithm should be modified in my opinion.
5. While I appreciate better automation of weapon to fire control assignment, there is one small addition I'd like to request. I'd like to be able to select a type of weapon, type of fire control and then tell the game how many of armed weapons I'd like to assign per fire control. This would help enormously with box launchers when I don't want to use their full power.Would make sense.
6. Several times now I attempted to create a merchant powers, small nations which relied on trade income to function. I failed every time. The coming changes to trade will help a lot, but the main issue is that shipping lines always build colony ships - even when there is nothing to colonise (small nation don't do much of it after all). Which means their income is spent on useless ships, making it much more difficult for them to grow (they can even fail completely) and creating less taxes. As such I'd love to see an option to prevent shipping lines from building a specific type of ship, so that they would build only what's profitable.I think the civilians will be better in building new ships, depending on the needs of the empire. Steve wrote about that not so long ago. Although, being able to "select" which areas are made accessable for civilians would be a) nice, and b) make it easier to simulate different kinds of societies.
3. Missile agility has to be modified. Late fusion/early anti-matter era anti-missiles have 50%-80% interception chances all due to agility which cannot be countered with intelligent missile design. One option would be to discard it completely (although the starting interception chances would have to be increased as otherwise anti-missiles would have like 20% interception chance) while another would be to allow missiles to use agility to avoid interception. The second option would be more interesting in my opinion but would require more balancing work as it should also impact point defences.For 3. I think ECM will at least alleviate the problem somewhat, as loosing 30 or 40% interception chance is quite painful, and ECCM uses up 25% of a 1 MSP countermissile.
And yes, I know there are changes coming to missiles, but agility is pure interception chance with no counter, so I don't think it will solve the issue. Flattening out the Agi tech curve would help as well, especially since shipkillers are usually not using much agi.
4. At the moment repeatable missile launchers are flat out useless, as demonstrated in Steve's own colonial campaign. A way to possibly solve the issue would be to create a new technology that would reduce the impact of miniaturised launchers, which currently receive large penalty to fire rate. Obviously such technology should not, by itself, make miniaturised launchers as fast as full sized ones, but after playing dozens of campaigns I simply cannot find use for repeatable launchers as they are very, very easily countered by turreted gauss cannons.
Admittedly simply removing gauss cannons would also solve the issue, at least in mid to late game, after railguns are no longer effective.
I feel like this could be solved by better AI
I think the problem could be far better solved by limiting all Civilian Shipping Lines to a single category of ships (so cargo only, or colony only, or luxury passengers only ((Also, please bring back Luxury Passenger Ships.)) or fuel harvester only, etc.) That way, only the types of civilians actually being used would make money and thus build more ships.
1. Please allow us to modify characteristics of various stellar bodies or, even better, add custom ones.A dialog where one can select several parameters as to a rough category of system that should be created would help much.
2. System generation algorithm should be modified in my opinion.
I think the civilians will be better in building new ships, depending on the needs of the empire. Steve wrote about that not so long ago. Although, being able to "select" which areas are made accessable for civilians would be a) nice, and b) make it easier to simulate different kinds of societies.
For 3. I think ECM will at least alleviate the problem somewhat, as loosing 30 or 40% interception chance is quite painful, and ECCM uses up 25% of a 1 MSP countermissile.
4. I think it is a serious problem. It could however be fixed with making box launchers larger.
Per msp missile size if you have 3 HS giving you 2 launchers + 1 HS magazine you can fit in 16+2 missiles at 80% efficiency. The same size in box launchers fits you 20! missiles, more than the re-loadable solution.
As for gauss cannons, one possibility to make smaller missile sizes viable would be to limit the amount of shots that can be fired on the same missile.
I'm afraid you forgot that capacity has to be divided by missiles size. 1HS magazine will give you 16 capacity allowing you to carry five missiles, for a total of seven. However I would argue that your example isn't really that good, for in that situation you could five only three times per launcher. If you build them to fire 7+ salvoes magazines are much more efficient way to store missiles than box launchers. So box launchers are already a tredeoff - lower total ammunition capacity in exchange for firing all of it at once.No, I did not. Assuming size n missiles and you invest 3*n HS into 2 launchers and n HS magazine space, you end up with the 16+2 missiles for launchers vs 20 for box launchers. I am arguing that the trade off is just way off, assuming 9 salvos vs firing the same all at once it is always better to have the box launchers.
I"m afraid you're forgetting "bonus tracking vs missiles" tech. Gauss cannons are very, very accurate and it's very rare for them to need to fire more than two shots to take down incoming shipkillers of equivalent technology level. At least I think so, can't be bothered to do the math right now.Yeah, that would also need to be nerfed to make low salvo sizes of missiles more useful. Maybe also increase the range at which missiles are engaged by final PD as their speed increases.
Was just looking back over the rules changes and the new ground units. What has struck me as odd is the need to attach large lumbering tanks to all larger units in order to fit in the HQ component. This is going to look particularly odd if you have a bunch of for example jungle trained troops who then end up with something that would not exactly be fit for such terrain. I was therefore wondering if a split version of these units could be created as an alternative such that a series of light vehicles could do the job of one large mounted unit. I expect along with this you would have to deal with partial damage to the units / loss of some but not all but would think you could have some simple rules that noted if you lost more than 25% or so of units the HQ bonus would cease to function. Hopefully that would be a lot of overhead to maintain some more balanced unit templates.
Was just looking back over the rules changes and the new ground units. What has struck me as odd is the need to attach large lumbering tanks to all larger units in order to fit in the HQ component. This is going to look particularly odd if you have a bunch of for example jungle trained troops who then end up with something that would not exactly be fit for such terrain. I was therefore wondering if a split version of these units could be created as an alternative such that a series of light vehicles could do the job of one large mounted unit. I expect along with this you would have to deal with partial damage to the units / loss of some but not all but would think you could have some simple rules that noted if you lost more than 25% or so of units the HQ bonus would cease to function. Hopefully that would be a lot of overhead to maintain some more balanced unit templates.Are you sure vehicles are required at all? In the rules post example (http://aurora2.pentarch.org/index.php?topic=8495.msg105832#msg105832) I can see infantry HQ units only one level below the highest tank-based HQ.
In VB6, civilians tend to build mining colonies on their own. While nice, I would like to have more control over, where they are allowed to do that. The game I guess has several parameters as to what would be ideal for the civis to build such a base. Maybe making these available and editable might be enough control. If not, the ideal is always body-individual rights-setting ;)If the issue is that the mines are popping up in poor places, economically soaking, I think reworking the system for determining where they open is a better solution, though I'd like to see an economic overhaul in general.
6. Several times now I attempted to create a merchant powers, small nations which relied on trade income to function. I failed every time. The coming changes to trade will help a lot, but the main issue is that shipping lines always build colony ships - even when there is nothing to colonise (small nation don't do much of it after all). Which means their income is spent on useless ships, making it much more difficult for them to grow (they can even fail completely) and creating less taxes. As such I'd love to see an option to prevent shipping lines from building a specific type of ship, so that they would build only what's profitable.With the economy as simplistic as it is, I don't think you'll manage to do much even with such a change.
Was just looking back over the rules changes and the new ground units. What has struck me as odd is the need to attach large lumbering tanks to all larger units in order to fit in the HQ component. This is going to look particularly odd if you have a bunch of for example jungle trained troops who then end up with something that would not exactly be fit for such terrain. I was therefore wondering if a split version of these units could be created as an alternative such that a series of light vehicles could do the job of one large mounted unit. I expect along with this you would have to deal with partial damage to the units / loss of some but not all but would think you could have some simple rules that noted if you lost more than 25% or so of units the HQ bonus would cease to function. Hopefully that would be a lot of overhead to maintain some more balanced unit templates.Are you sure vehicles are required at all? In the rules post example (http://aurora2.pentarch.org/index.php?topic=8495.msg105832#msg105832) I can see infantry HQ units only one level below the highest tank-based HQ.
Was just looking back over the rules changes and the new ground units. What has struck me as odd is the need to attach large lumbering tanks to all larger units in order to fit in the HQ component. This is going to look particularly odd if you have a bunch of for example jungle trained troops who then end up with something that would not exactly be fit for such terrain. I was therefore wondering if a split version of these units could be created as an alternative such that a series of light vehicles could do the job of one large mounted unit. I expect along with this you would have to deal with partial damage to the units / loss of some but not all but would think you could have some simple rules that noted if you lost more than 25% or so of units the HQ bonus would cease to function. Hopefully that would be a lot of overhead to maintain some more balanced unit templates.Are you sure vehicles are required at all? In the rules post example (http://aurora2.pentarch.org/index.php?topic=8495.msg105832#msg105832) I can see infantry HQ units only one level below the highest tank-based HQ.
They aren't needed. You can create infantry HQs.
Ah ok so if I have a large infantry formation that needs say 10000 tons of control I can meet this with infantry based hq units? Sorry was not clear to me from the original post.
I think the game would benefit significantly from a more robust economic model, including things such as tracking the wealth/prosperities of individual colonies, tracking TN minerals sent to the civilian economy as a trade good, requiring shipping lines to purchase TN minerals fur ships, requiring the civilian economy to expend TN minerals to create civilian mining complexes, more robust AI to handle this kind of thing. Any kind of economy overhaul would require a serious amount of work, however, and at this point I wouldn't want to see it delay the initial release of C#.The focus of Aurora is the unit design - and we will get a lot of that in C#. And I fully agree that Aurora does not need a delay because of economics rework. If Steve would be interested in an later economics rework, there could be a separate thread created for discussions about it.
I was wondering if the collected intelligence points of alien populations should decrease over time if no active intelligence is done? It sounded to me that the points stay at the level they once gained forever, but that sounds a bit off to me... . Although a very nice solution in general for espionage.
I see. Maybe you can save the ‚time gone‘ since last active intelligence and every new beginning has to first overcome ‚re-contact-phase‘ and then have full access to previous data. The length of that ‚re-contact-phase‘ could be like 1/10th of ‚time gone‘, capped by a maximum of 6 month.I was wondering if the collected intelligence points of alien populations should decrease over time if no active intelligence is done? It sounded to me that the points stay at the level they once gained forever, but that sounds a bit off to me... . Although a very nice solution in general for espionage.
There are pros and cons both ways. For example, it might be odd from a player perspective if you knew there were 100 factories on a planet last time you checked but now you have no idea because you dropped below the level where that information is available. Either way, it is a compromise.
I see. Maybe you can save the ‚time gone‘ since last active intelligence and every new beginning has to first overcome ‚re-contact-phase‘ and then have full access to previous data. The length of that ‚re-contact-phase‘ could be like 1/10th of ‚time gone‘, capped by a maximum of 6 month.I was wondering if the collected intelligence points of alien populations should decrease over time if no active intelligence is done? It sounded to me that the points stay at the level they once gained forever, but that sounds a bit off to me... . Although a very nice solution in general for espionage.
There are pros and cons both ways. For example, it might be odd from a player perspective if you knew there were 100 factories on a planet last time you checked but now you have no idea because you dropped below the level where that information is available. Either way, it is a compromise.
So gone for 2 years would mean 2.4 month re-contact-Phase, etc.
There are pros and cons both ways. For example, it might be odd from a player perspective if you knew there were 100 factories on a planet last time you checked but now you have no idea because you dropped below the level where that information is available. Either way, it is a compromise.
I'm not sure I like the idea of having the modules act as EM sensors. I'd rather they used the vessel's EM sensor rating instead as that avoids having to choose between having a large EM sensor to pick up foreign vessels and populations or a large number of ELINT modules to gather intelligence from great range.
There are pros and cons both ways. For example, it might be odd from a player perspective if you knew there were 100 factories on a planet last time you checked but now you have no idea because you dropped below the level where that information is available. Either way, it is a compromise.
Could it be handled the same way you do with legacy data?
"The information regarding a specific population will remain static if ELINT monitoring ends but will be updated once an ELINT ship is back in range."
Ideally if you drop below the level where it's displayed what could happens is you still see the latest known amount but with some note after it saying something like "( old data from year X month Y )"
It is to avoid the situation of detecting ELINT emissions from something that hasn't been detected any other way. By making them EM sensors too, that can't happen. Also provides a useful backup if the primary sensors go down.
I don't want ELINT to use the ship's primary sensors as that would make ELINT too powerful. Currently it is 1/10th of normal EM capability.
I don't want ELINT to use the ship's primary sensors as that would make ELINT too powerful. Currently it is 1/10th of normal EM capability.
There are pros and cons both ways. For example, it might be odd from a player perspective if you knew there were 100 factories on a planet last time you checked but now you have no idea because you dropped below the level where that information is available. Either way, it is a compromise.
Could it be handled the same way you do with legacy data?
"The information regarding a specific population will remain static if ELINT monitoring ends but will be updated once an ELINT ship is back in range."
Ideally if you drop below the level where it's displayed what could happens is you still see the latest known amount but with some note after it saying something like "( old data from year X month Y )"
Really like the ELINT plans although must admit I will miss the old teams on the ground; have had some good RP fun with them in the past. A couple more thoughts on the current rules:
- Not done any looking at the maths of relative EM emissions of a decent planet versus their typical thermal detection range but with revisions to passive sensor range I'm wondering how practical it will really be to get a ship able to collect points without being readily detected by the hostile planet. Look forward to seeing how that works on playtesting.
- Are you considering a ground installation version of this or to have it as a ground unit type? I could happily see people wanting to drop of units or an installation on an out of the way asteroid somewhere to be able to snoop on other races and would hope that also changes the interplay on thermal detection range and sensor range per the above point.
- Whilst probably not wanting to get into the world of encryption I wonder if a very high tier of points could be classed as you having cracked their communications and hence be able to obtain a chance of seeing orders issued to ships or units.
Is not Electronic a misnomer both for ELINT and EM sensors? Active sensors are FTL, and so seems to be interstellar communication.Really like the ELINT plans although must admit I will miss the old teams on the ground; have had some good RP fun with them in the past. A couple more thoughts on the current rules:
- Not done any looking at the maths of relative EM emissions of a decent planet versus their typical thermal detection range but with revisions to passive sensor range I'm wondering how practical it will really be to get a ship able to collect points without being readily detected by the hostile planet. Look forward to seeing how that works on playtesting.
- Are you considering a ground installation version of this or to have it as a ground unit type? I could happily see people wanting to drop of units or an installation on an out of the way asteroid somewhere to be able to snoop on other races and would hope that also changes the interplay on thermal detection range and sensor range per the above point.
- Whilst probably not wanting to get into the world of encryption I wonder if a very high tier of points could be classed as you having cracked their communications and hence be able to obtain a chance of seeing orders issued to ships or units.
I am considering ground and installation versions of ELINT.
I also considered having encryption and decryption research projects, but for the moment decided that was too much micromanagement. The modification based on Xenophobia is intended to simulate that races concerned about aliens would invest into more secure communications and restrict public information. If I get back into government types, I might use that instead.
Is not Electronic a misnomer both for ELINT and EM sensors? Active sensors are FTL, and so seems to be interstellar communication.That's one technobabble interpretation, but there are many others. If TN comms tech has the advantage of FTL communication speeds then advanced civilizations might ditch fibre optic entirely and move everything into TN space for the speed advantage, opening themselves up to interception. Heck, maybe the entire internet goes TN wireless, and ELINT systems are mostly listening to facebook messages, and trying to deduce useful intelligence from that.
I doubt much electronic information can be gathered from a single planet, as any advanced civilization will likely put as much as possible of their internal communications into optical fibers, or short range radios that are highly focused on satellites for uplink, and pointed at the planet from satellites to ground.
This only really leaves communications between systems to be intercepted, but at these ranges, you likely aim at the entire system, and not anything in particular in it. Also, since every unit has comm gear that can pick up interstellar communication, it does not seem like you need special antennas for picking up that kind of transmission.
I'd like to suggest some way of one sided language translation, by ELINT or otherwise. Monitoring alien communications with stealthed ships to translate their language to enhance interrogations sounds very fun.My problem is always how do you get the stealthed ships into the system? I don't think I've read anything to suggest that stealthed ships will be any better at getting past a jump picket in C#.
Is not Electronic a misnomer both for ELINT and EM sensors? Active sensors are FTL, and so seems to be interstellar communication.EM sensors pick up electromagnetic radiation produced by electrial systems. ELINT might be a misnomer (though ELINT doesn't so much refer to picking up communication signals, in this case it could be the analysis of electro-magnetic signatures to figure things out) dpending on your particular scenario, but who cares, it's not exactly uncommon to keep using a term for the same practice even if the term gets technically outdated. And this is heavily dependent ont he scenario you are RPing.
I doubt much electronic information can be gathered from a single planet, as any advanced civilization will likely put as much as possible of their internal communications into optical fibers, or short range radios that are highly focused on satellites for uplink, and pointed at the planet from satellites to ground.
This only really leaves communications between systems to be intercepted, but at these ranges, you likely aim at the entire system, and not anything in particular in it. Also, since every unit has comm gear that can pick up interstellar communication, it does not seem like you need special antennas for picking up that kind of transmission.
Even improved stealth efficiency can't get past a picket. I think it would be interesting to be able to design special jump engines that have a huge jump radius (maybe starting at around 10m km and getting higher with tech?) that can only jump one ship (no assisted transits or squadron jumps). Other downsides could be increased size, as is done with commercial drives, and a smaller maximum size. This would allow a stealth ship to jump in outside point-blank sensor range, or allow a fast, PD-equipped ship to escape more quickly. Obviously, these would be trapped in enemy territory, but that is a danger with any stealth ship design.
Currently a jump drive and a cloak are pretty much taking up an entire ship already. I think regular jump drives need a buff in HS requirement first to make room a long range, larger jump drive. Also such a drive should work both ways (jumping into a point from afar, jumping out a good distance away), to not make any jump into enemy territory a suicide mission.
This sort of Jump Drive design could also be relevant if you want piracy or raiding ( AKA Space Submarines ) to be relevant weapons. ( If they can't get around jump point pickets they are not going to reach the rear lines ).
These Jump drives would need to take up big enough space to be prohibitive for use on your main warships, but small enough to still allow you to run stealth modules and some cheap reduced sized launcher weapon systems that can quickly and efficiently destroy freighters or civilian ships.
Currently a jump drive and a cloak are pretty much taking up an entire ship already.
For "submarines" improved handling of passive detectors would also help. A missile fire control should be able to guide a homing missile close enough to a target to have a 0.25 msp sensor on top of the missile pick up the target for final acquisition.
It would save on a lot of clicking if we could issue the same orders to multiple task forces (or whatever they are now called) at the same time. Specifically I'm thinking of cases where you have multiple fighter squadrons or fac squadrons and you want them all to be heading to a new waypoint or all returning and refueling etc. I know you can save a set of orders and copy over currently but that is still quite fiddly if you want to do for a group of say 10 squadrons and you are regularly updating their orders. Was wondering is some sort of shift click to highlight multiple task forces would be possible.I guess, with the new system, you put them as subfleets in one fleet, send that to the waypoint and there split them up in subfleets again.
Only at the very first levels. ( First level is Efficiency 3 for both meaning you have 33% left for all other systems if you equip both )I still think the Jump drive needs a buff (Move it up a tech level or two) to make room for the second drive early enough if you want it available somewhere in the midgame where cloaks become available. The cloak progression line could also be flattened out, with a size reduction for less efficient cloaks. So you can build small, reduced efficiency cloaks.
At for example 5:th tech level you will have Efficiency 8 on both meaning you can make a ship with 75% left for all other systems if both are equipped. Basically you could even equip all your warships with it ( even if it would be costly it is within reach ).
At max tech levels ( Efficiency 15 ) You would need to allocate just 13% of your ship to both these systems leaving the remaining 87% free.
For balance any "Raiding" or "Scouting" Jump drive or what you want to call it would need to have a much flatter progression curve in tech, or be made so much significantly more expensive in resources that it's not feasible to equip large parts of your fleet with it.
That's a good idea, and one that I have suggested before. The tricky question is how you don't make it unbalanced ( Basically what prevents everyone from always using just passive targeting? ). It needs to have some serious downsides too besides requiring a 0.25 msp sensor in each missile.For one active sensors should outrange thermal sensors, and if you fire at an EM target, your enemy always may turn off their emissions. A further downside could be that your homing missiles pick their targets themselves, any they can detect, which may not be the one you intended. So in a fleet battle this will lead to very poor focus firing.
If you wanted to give a serious downside to self targeting missiles, gives CIWS a significant bonus to hit against sensor equipped missiles. Something about how they're lighting themselves up with the sensor package pinging off. Then you could justify buffing the effective range of missile sensors. So for your big warships, if you want to get your warheads through a heavy missile defense in a proper fleet, you guide them in from a directed fire control. But if your picking off a lone merchant ship, or a handful of troop ships in a surprise attack, the trade off of using more missiles to achieve the same effective damage may be worth it.Passive sensors don't light up, by definition of passive sensors. I also really dislike the idea of giving CIWS a bonus compared to other missile defenses. I for one only install CIWS on civilians, supply ships, my warships have dedicated firecontrol+sensor+guns arrangements for defense.
A ground forces summary screen which shows the location of all ground forces and condition in one place, sortable both by the unit groupings but also location (when you get larger forces working out which planet they are on or what's in transit and to where can be a bit of a headache).
I guess, space stations will be completly stationary, as they were in VB6 Aurora. Although it might be nice to have a station rotate around another object at a given speed... . At a cost of certain amount of fuel... .Man, I hope the Moon never runs out of fuel. Would be annoying if it fell back on Earth.
The idea with the fuel came from the base, that propulsion through TN engines happens outside of normal spacetime, and once you stop that engine, the ship stops... :-)I guess, space stations will be completly stationary, as they were in VB6 Aurora. Although it might be nice to have a station rotate around another object at a given speed... . At a cost of certain amount of fuel... .Man, I hope the Moon never runs out of fuel. Would be annoying if it fell back on Earth.
Quality of Life: Older Modules like "Geological Survey Sensors" should be excludable in the class design window, once the improved versions are available.
Actually, you can already make 'stealth' engines in Aurora. You just need to research and implement the lower thermal signature tech line on that drive.
It drives up the cost of the engine though.
To throw an extra cog in the wheels of jump drives, how about a third type approach? So have a stealth jump drive that has the huge range and single ship capacity, but allow it to only work on "stealth" drives. I am guessing it wouldn't take much to add in a new drive engine type, just make them have a low power thrust output, with larger sizes than standard military and smaller than current commercial drives.
To avoid them being put onto a commercial vessel, just make them give error flags if they are used with components such as cargo bays etc.
Actually, you can already make 'stealth' engines in Aurora. You just need to research and implement the lower thermal signature tech line on that drive.
It drives up the cost of the engine though.
He is talking about a special jump drive like the one I suggested a couple pages back, not a regular engine.
Seems more like he's mixing up engines with jump drives.
I can't find that in VB6. Any tips where I can do that?Quality of Life: Older Modules like "Geological Survey Sensors" should be excludable in the class design window, once the improved versions are available.
You can make them obsolete and they won't appear (in VB6 and C#).
I can't find that in VB6. Any tips where I can do that?Quality of Life: Older Modules like "Geological Survey Sensors" should be excludable in the class design window, once the improved versions are available.
You can make them obsolete and they won't appear (in VB6 and C#).
I had an additional idea for ground combat. Preferential targeting during combat leads to favoring monolithic unit compositions and army compositions to minimize damage, but I was thinking what about preferential targeting against optimal weapon matches during the formation targeting phase, but unweighted targeting during the actual combat phase?
This would represent commanders picking good matches for engaging formations, and it would lead to favor mixing up units, as otherwise your tanks will face mostly heavy guns, while your infantry runs into heavy machineguns. For mixed formations, there is no obvious optimal match.
The bonus could scale with commander skill, making well led armies taking better engagements.
I don't see how random encourages combined armies, I don't see any synergy effect that makes combined arms. I am looking for some way to punish all tank formations, or any other single unit type formation, and I don't see how to do it without there being some difference if some units are in the same formation or somewhere else.
This ends up having its own problems as well, either insuring that you want completely homogenous units (IE every formation having the same ratio of tanks to infantry) or else never wanting to mix different types of units on the same front line (if all of your front line forces are light vehicles, preferential targeting doesn't matter).
People keep suggesting preferential targeting and I think it's a bad idea. Random targeting is both keeping things simple and the best way to encouraged combined arms units.
I don't see how random encourages combined armies, I don't see any synergy effect that makes combined arms. I am looking for some way to punish all tank formations, or any other single unit type formation, and I don't see how to do it without there being some difference if some units are in the same formation or somewhere else.
This ends up having its own problems as well, either insuring that you want completely homogenous units (IE every formation having the same ratio of tanks to infantry) or else never wanting to mix different types of units on the same front line (if all of your front line forces are light vehicles, preferential targeting doesn't matter).
People keep suggesting preferential targeting and I think it's a bad idea. Random targeting is both keeping things simple and the best way to encouraged combined arms units.
You punish single unit formations with your own single unit formations. If someone has all tank formations, you bring nothing but anti-tank guns.No. You cannot adjust your unit composition on the fly. That leaves all the advantage to the attacker. The defender cannot know what kind of units an invader will bring, so he cannot make single unit formations, else they can be hard countered. The defender thus needs mixed units, which should be able to defeat any single unit formation that possibly attacks them to make it even worthwhile to attempt a defense.
You punish single unit formations with your own single unit formations. If someone has all tank formations, you bring nothing but anti-tank guns.No. You cannot adjust your unit composition on the fly. That leaves all the advantage to the attacker. The defender cannot know what kind of units an invader will bring, so he cannot make single unit formations, else they can be hard countered. The defender thus needs mixed units, which should be able to defeat any single unit formation that possibly attacks them to make it even worthwhile to attempt a defense.
At the moment all of our ground forces and our enemies fight to the bitter end no matter what the odds. It would be great to see a bit of a morale overlay to this that means this is not always the case. At a very simple level I was thinking that when morale drops below a certain grade then there is a check each cycle as to whether the unit will seek to do one of several things:
- Cease to attack
- Look to move from a front line position to a rear position
- In very low morale surrender to the enemy creating PoWs and the potential to capture combat units such as tanks and artillery.
This is obviously pretty simplistic and I'm sure the rules could be expanded to cover items such as:
- Units with moral failures impacting the morale of other units - potentially leading to a route
- Different modifiers on morale checks for elite units or the ability to create fanatical units that will fight to the death / robotic units that have no morale checks
- Higher morale losses when faced with overwhelming forces against you - could be a good reason not to reduce your unit size down too far to play with the mechanics.
- A system for dealing with PoWs including a similar interrogation system as with the Navy with chance to identify OOB of troops in theatre, details of weapon systems etc.
- Ability to surrender a very badly damaged unit in the hopes you might recover the PoWs at a later stage.
Hopefully this would mean no fighting to the bitter end in most circumstances.
I would love a 'Bug Button' -- something we can click to 'Add Hive Mind NPR' to our game. Whether it be Heinlein's original literary Bugs, or Starship Trooper's more B-movie sci-fi version, or Weber & White's deadly serious technologically adept Arachnid Omnivoractiy. Ideally they would exist on a continuum of such, and vary from game to game (or even within games, if one were adventurous enough to add multiple such races).
I suppose what I'm asking for is half-spoiler race, half starting NPR. To me the important part is the flavour -- massive overpopulation, massive industrial production, suicidal tactics, stunted technological growth, ground forces that are basically ten billion armoured infantry, the ability to consume other races' biomass for food, fuel, or whatever. . .
Now we have some serious logistics considerations in place I was thinking it would be good to also have some control on how this gets burned. Perhaps have three rates on use of supplies based on how intense you want to fight, ie low intensity, normal, high intensity. Low intensity would give penalties to hit but reduce the rate of supplies used, normal would be as is and high would increase chance to hit but drastically increase supplies usage as well.
I'd also suggest that the attacker would drive the rate of supplies used so if they were low intensity then the defending side would also be low intensity and if both attacked then the highest intensity selected by wither side would be the intensity of the battle.
You might use different rates if holding on for reinforcements or on the opposite side may look to up the ante to win before reinforcements arrived or if there was time pressure on the objective.
Not sure if added/suggested yet (probably was)
Preset orders for ships so you don't have to manually put the same orders for every ship, its a pain to do so.
Not sure if added/suggested yet (probably was)
Preset orders for ships so you don't have to manually put the same orders for every ship, its a pain to do so.
Do you mean weapon assignments? Orders are at the fleet level.
Do you mean weapon assignments? Orders are at the fleet level.
No I meant conditional orders such as refueling/surveying.
"Geo-Survey Preset"
Default Orders:
>Survey nearest body
Conditional Order A:
>If fuel is under 30%, refuel
A fleet consisting of 25 14.000t Asteroid Miners is detected at the same distance as a single 14.000t Asteroid Miner. I think there should be some ‚penalty‘ for large assemblies of ships in terms of detectability. EM value accumulates for a civilization. Likewise it should for larger fleets. Not in a 1 to 1 scale, but something like: 10 ships a 14.000t should be detectable like 1 ship a 28.000t.This has a big problem when going by fleet: you can simply put all of the ships in different fleets, which would then be at the same location without increasing the detectable range. If you go by ships on one exact spot, that can be easily solved by letting all of the ships get near each other instead of on the sames spot. If you go by distance on the other hand, it would be very complicated calculation when which ship would be detected. In any case, i dont see how this could realisticly be implemented.
This has a big problem when going by fleet: you can simply put all of the ships in different fleets, which would then be at the same location without increasing the detectable range. If you go by ships on one exact spot, that can be easily solved by letting all of the ships get near each other instead of on the sames spot. If you go by distance on the other hand, it would be very complicated calculation when which ship would be detected. In any case, i dint see how this could realistically be implemented.
Ground combat morale as it is currently implemented is just an amplifier, as the stronger side gains morale for successful kills, and the weaker side loses morale for taking more damage.This is a very good suggestion and something that has happened in actual military history. Morale could represent both the mental willingness to fight, as well as the general organization and cohesion of the unit, as well as their fatigue level. So repeated combat brings it down, being on defensive keeps it static, staying in the rear increases it slowly and being out of combat zone altogether makes it go up fast.
That in itself is not very interesting, as it is essentially HP all over again. It would be way more interesting if only morale losses were amplified on front line attack, or units would even take morale damage for being on front line attack regardless of opposition, to simulate the strain of assault, and troops getting successively more disorganized, and not having time to rest and get their gear sorted out and repaired.
The interesting situations this could lead to is a stronger attacker wearing itself out to the point the defender can counterattack and defeat a stronger, low morale opponent. So for a successful attack you need to be quick enough, rotate your offensive formations, or let them recover, as currently there does not seem to be much incentive where you would ever want to stall a fight as the stronger force.
Ground combat morale as it is currently implemented is just an amplifier, as the stronger side gains morale for successful kills, and the weaker side loses morale for taking more damage.
That in itself is not very interesting, as it is essentially HP all over again. It would be way more interesting if only morale losses were amplified on front line attack, or units would even take morale damage for being on front line attack regardless of opposition, to simulate the strain of assault, and troops getting successively more disorganized, and not having time to rest and get their gear sorted out and repaired.
The interesting situations this could lead to is a stronger attacker wearing itself out to the point the defender can counterattack and defeat a stronger, low morale opponent. So for a successful attack you need to be quick enough, rotate your offensive formations, or let them recover, as currently there does not seem to be much incentive where you would ever want to stall a fight as the stronger force.
Ground combat morale as it is currently implemented is just an amplifier, as the stronger side gains morale for successful kills, and the weaker side loses morale for taking more damage.
That in itself is not very interesting, as it is essentially HP all over again. It would be way more interesting if only morale losses were amplified on front line attack, or units would even take morale damage for being on front line attack regardless of opposition, to simulate the strain of assault, and troops getting successively more disorganized, and not having time to rest and get their gear sorted out and repaired.
The interesting situations this could lead to is a stronger attacker wearing itself out to the point the defender can counterattack and defeat a stronger, low morale opponent. So for a successful attack you need to be quick enough, rotate your offensive formations, or let them recover, as currently there does not seem to be much incentive where you would ever want to stall a fight as the stronger force.
Ground combat morale as it is currently implemented is just an amplifier, as the stronger side gains morale for successful kills, and the weaker side loses morale for taking more damage.This is a very good suggestion and something that has happened in actual military history. Morale could represent both the mental willingness to fight, as well as the general organization and cohesion of the unit, as well as their fatigue level. So repeated combat brings it down, being on defensive keeps it static, staying in the rear increases it slowly and being out of combat zone altogether makes it go up fast.
That in itself is not very interesting, as it is essentially HP all over again. It would be way more interesting if only morale losses were amplified on front line attack, or units would even take morale damage for being on front line attack regardless of opposition, to simulate the strain of assault, and troops getting successively more disorganized, and not having time to rest and get their gear sorted out and repaired.
The interesting situations this could lead to is a stronger attacker wearing itself out to the point the defender can counterattack and defeat a stronger, low morale opponent. So for a successful attack you need to be quick enough, rotate your offensive formations, or let them recover, as currently there does not seem to be much incentive where you would ever want to stall a fight as the stronger force.
Both versions of 'morale' have an impact on fighting ability, although the quality aspect is long-term while combat fatigue is short-term and could recover within a few days. Perhaps we should have both with different designations.Hearts of Iron 3 solved this with using Strength and Organization values for each units. Strength was literally the Hit Points of an unit - the game did not model individual soldiers or equipment - where as Organization was a catch-all for all non-physical elements of a unit. So a high-quality, well-trained unit would have a higher Organization than a low-quality, poorly-trained one. What made the system really work was the "hidden" attribute of Morale, that determined how fast Organization could be recovered after a battle. So while the military doctrines of a country might allow the training of units with high Organization values, without the investment in propaganda etc that improved Morale, the units would only fight a single battle, and then require days if not weeks to recover. Units, no matter how much Strength they had left, would be immediately routed when their Organization hit zero and if they could not path to safety, would surrender.
Anyway, some food for thought there. Personally I think that renaming Morale to Quality and adding a Cohesion value would probably be the best system for Aurora C#. The Quality will only slowly increase due to Commander Training and combat, replenishing losses would bring it down, but otherwise it would be static. Cohesion value would be static in peace time, go automatically down in combat, recover slowly when unit is part of a campaign but not at front lines, and recover fast when unit is completely out of the war zone. The benefits of this system would be that it encourages players to rotate their combat units instead of just dropping a massive DOOM STACK on a planet, which makes ground campaigns more immersive. There would be a solid mechanical reason to create a R&R ship(s) or stations, where mauled ground units could be replenished and recover their Cohesion before being sent back to the meat grinder. And Cohesion could be something that would allow flavour between races - a Psychic Hive Mind could have insanely high Cohesion values when compared to Humans.
Well, if you are going to redo the Morale system, I've a few suggestions.
I'd say that ground forces have 3 non-physical stats. These stats are Morale, Cohesion and Training.
Morale would have a linear connection with casualties; although more severe losses will cause more severe morale loss, the real threat to morale is slow attrition. Likewise, although inflicting losses on enemy forces raises morale, it does not raise it as much as taking the same losses does in damage. Units in Support and Rear Echelon positions take worse morale hits when engaged and recover less when inflicting losses. Units that have been engaged in combat during a construction increment do not recover morale. This would encourage players to cycle forces, but the time spent should be something reasonable. Morale normally doesn't exceed the Formation's maximum value, but a properly skilled CO can increase the cap and/or recovery as currently in the rules.
It should be noted that, during WW2, the Americans reckoned a soldier could remain on station for nearly 3 months at a time, while the British cycled their troops every 12 to 14 days, giving them 4 days of leave.
Cohesion would have an exponential connection with casualties; constantly bleeding a few troops every combat round will slowly decrease Cohesion, taking a large number of casualties for the formation all at once drastically impacts its Cohesion and ability to provide a united front. Likewise is the loss of an HQ unit in the formation or the CO due to a combat injury something that can cause potentially heavy hits to Cohesion, but if they've got non-generic COs under them the hit is less (on the presumption that the chain of command keeps going), while the loss of an HQ has limited effect as long as it's not the last HQ. Having more than 1 HQ in the formation is a boost for Cohesion, if one with strongly diminishing returns, as is a commander with the right skills.
Generally speaking a military unit can cope quite well with the slow loss of troops; it's something they train and prepare for because losses are inevitable in war. Losing command and coordination, as would happen if the HQ of the unit is lost or a large chunk of its personnel is killed in a short amount of time is far more devastating.Putting down Cohesion as an explicit value does mean that you can get an idea how likely it is a given unit is going to falter and enable an enemy Breakthrough. High Cohesion also translates into having a high chance of performing a Breakthrough though.
Training would take the place of the current Morale value. I would say it's much more stratified than the current system, with the levels of Conscript, Green, Trained, Regular, Veteran and Elite. GFTF's on a planet can be instructed to train formations to a certain standard, which impacts the time and wealth it takes to train. Minerals is independent and only cares for the end equipment. Conscript troops train quickly and cheaply but take severe maluses to Morale and Cohesion, Trained troops have standard Morale and Cohesion, and Elites have high Morale and Cohesion but take a long time and are expensive to train and maintain. A CO with the proper skills can get even the worst Conscript unit up to Elite eventually, but that will take a lot of time of money in comparison to just selecting Elite training in the GFTF.
Training is something that's accumulated not unlike the way crew skill levels are. And like with crew skill levels, it's something that's averaged between all members of the unit. You can absolutely shove Green troops into an Elite formation, it just means the unit becomes on the average less skilled and may lose a level of Training depending on how much the unit is expanded from current size, but likewise can you shove some Elite or Veteran troops into a much less skilled unit as a cadre to stiffen them up a bit.
I deliberately picked some tresholds so as to let you pick a few values for each level instead of having to insert a calculation system that can get... odd as skill point values become more extreme.
I've got more ideas for the ground combat system, although I'll admit I'd basically shamelessly plunder Paradox grand strategy games for ideas.
Well, if you are going to redo the Morale system, I've a few suggestions.
<SNIP>
Training would take the place of the current Morale value. I would say it's much more stratified than the current system, with the levels of Conscript, Green, Trained, Regular, Veteran and Elite.
<snip>
I deliberately picked some thresholds so as to let you pick a few values for each level instead of having to insert a calculation system that can get... odd as skill point values become more extreme.
Combat would only increase Quality (for the survivors) while Cohesion would fall based on a base rate for being in combat, modified by losses. Quality would decrease as a result of replacements being added (as morale does now), but would still move up to 100 relatively quickly (about 100 per year) and above 100 more slowly, again per the current morale rules. Rather than cohesion being higher for a 'hive mind', maybe it would just fall much more slowly.
I really HATE a stratified level system. I hate that a force that is 1 XP short of Veteran counts the same as a force 1 XP above Green. I would much rather have a scale of 50 to 150 -- probably with a significant bell curve -- than fixed 50%, 75%, 100%, 125%, 150% categories.
My computer can handle nine decimal places easily. Please give us a morale system that (theoretically) accounts for when my troops get double dessert rations versus when they don't.
Do we really need both hp and cohesion? I know they're different things, but it seems like the actual strategic impact would be minimal outside increasing micromanagement.
In the end, this is ground combat in Aurora, not a new game entirely, so I'm kind of wary of over-complicating an addition that will already be much more complicated then what it's replacing.
Well, currently ground combat is fire & forget, unlike space combat which is very micro heavy.It's more that simply moving formation in and out of the front line when they get low cohesion is tedious and pointless, without much in the way of actual decision-making in the vast majority of cases, rather than people not wanting deeper ground play. Just busy work. Unlike most aspects of space combat where actual decisions need to be made. And whilst it could be automated, that begs the question of why even implement the mechanic in the first place if you're just going to automate it.
Even in C#, it is largely fire & forget, because while you will spend more time designing your units and formations, the only real concern you have to worry about is ensuring supplies & replacement are delivered to the planet. You select front and rear formations, ground-support fighters (if any) and then let the game proceed. With the proposed change, a player would have to monitor ground combat, making it more like space combat in the amount of player attention it requires.
Having said that, I can totally understand that for some players, the ground combat is a tasteless side salad whereas the space combat is the fat t-bone slathered in gravy and spraying thousand islands sauce over the salad will not improve the dining experience for them. :D
Do we really need both hp and cohesion? I know they're different things, but it seems like the actual strategic impact would be minimal outside increasing micromanagement.
In the end, this is ground combat in Aurora, not a new game entirely, so I'm kind of wary of over-complicating an addition that will already be much more complicated then what it's replacing.
This is a valid view too. If I change Morale to Quality and add Cohesion, the actual game-play change would be moving formations in and out of the front-line to manage cohesion. While more realistic, that might get tedious fast. It could be better to have less 'realism', but smoother game play. Although Aurora should have a lot of variety and choice, it should not have micromanagement where that detracts from game play.
Well, currently ground combat is fire & forget, unlike space combat which is very micro heavy.
Even in C#, it is largely fire & forget, because while you will spend more time designing your units and formations, the only real concern you have to worry about is ensuring supplies & replacement are delivered to the planet. You select front and rear formations, ground-support fighters (if any) and then let the game proceed. With the proposed change, a player would have to monitor ground combat, making it more like space combat in the amount of player attention it requires.
Having said that, I can totally understand that for some players, the ground combat is a tasteless side salad whereas the space combat is the fat t-bone slathered in gravy and spraying thousand islands sauce over the salad will not improve the dining experience for them. :D
It could be better to have less 'realism', but smoother game play. Although Aurora should have a lot of variety and choice, it should not have micromanagement where that detracts from game play.
With all the time, work and thinking which went into the new ground combat it is much more "fleshed out" as in VB6 - which results in the point that it also deserves much more "love" from the player... it shouldn't be too micro right but should be more micro than atm...
also as I said, ground combat is something the player can avoid nearly completely if he wishes... space combat he can not...
I would point out that not all player interaction is micromanagement. It becomes micro heavy if you have to do tasks that are not meaningful decisions. Do you attack, do you retreat are important questions, which should matter.
Firing 100 missiles from box launchers in 20 5 missile salvos at 20 swarmers is currently a micro heavy task. If you need to select each ground unit individually and change it to attack, that is micro heavy, but changing a stance every few hours, that is just paying attention to what you are actually doing.
I had a few thoughts about spoilers today.
<SNIP>
A suggestion on the ground combat:I would tend to agree that some of the citizenry would volunteer if it seemed to them there was a need to.
Population could contribute some troops/strength as well. . . snip. . .
A suggestion on the ground combat:
Population could contribute some troops/strength as well, depending on the loyalty and happiness of the planet. A planet that loves its empire will have many patriotic citizens taking up arms themselves to help fend off the invaders, while a planet that already hates the ruling empire might even aid the invaders in getting captured.
The 19th century was the time when conscription ruled, and it was all about who could get the most men into the field, but since then, total manpower became less and less important compared to the amount of weapons you can afford, which is why we have many more professional armies again.
A suggestion on the ground combat:
Population could contribute some troops/strength as well, depending on the loyalty and happiness of the planet. A planet that loves its empire will have many patriotic citizens taking up arms themselves to help fend off the invaders, while a planet that already hates the ruling empire might even aid the invaders in getting captured.
The 19th century was the time when conscription ruled, and it was all about who could get the most men into the field, but since then, total manpower became less and less important compared to the amount of weapons you can afford, which is why we have many more professional armies again.
In Aurora the cost of equipment and weapons is likely only to rise, and the value of people without the proper equipment and the proper training to use it will fall.
Loyalty might matter in how easy it is to pacify a planet, but generally I'd consider the value of untrained volunteers nil, and if you do want to train a militia, you can spam large quantities of PWL equipped light infantry to fit the bill.
No matter how advanced the weapons get, conscripts will always be useful. Maybe not on the front line, but there's always room for more workers behind the lines. This is likely to only get MORE true as combat units require more and more supplies. These conscripts can be building and operating logistics infrastructure; driving trucks, paving roads, laying rail lines. They can also be building emplacements; you don't need Navy SEALS and laser guns to pour concrete.Quote from: Ranged66A suggestion on the ground combat:I would tend to agree that some of the citizenry would volunteer if it seemed to them there was a need to.
Population could contribute some troops/strength as well. . . snip. . .
A few questions come to mind if we consider the citizenry rising up to join the fight:
- Can they leave the infrastructure that supports them in hostile environments to go fight?
- Are they self armed in entirety, or to some percentage?
- If not self armed, can the soldiers arm them and if so, how many guns can they distribute? Presumably 100k soldiers do not have enough guns to arm 4 million volunteers. You have probably already lost the orbitals so good luck shipping in more guns before the fight is over.
- If they are self armed, do all civilians possess a gun or only some fraction. Does the fraction that volunteer apply only to the armed percentage, or the total population yielding both armed and unarmed volunteers
- What value, if any, might unarmed volunteers hold? Some bonus to recovery/replacement rates for lost personnel?
- Should player government and/or commander traits and/or administrator traits be used to influence the expectation/willingness to accept/seek out volunteers?
- Is there a limit to how many will be useful at any given task? Absurd example, 1 million civvies trying to do the work that was done by 100 personnel will probably get nothing done, just get in each other's way.
- Is there a tipping point? Seems reasonable that while too many would be detrimental, too few would benefit from adding some more.
- Are there any roles they might be a viable substitute? Seems plausible that for any such role, while too few and too many both don't get enough done, the optimal quantity might also not get enough done.
- Should they be affected by research as if they were a ground force unit? I would think yes, today we can buy guns far better than we could have in the 1800's, research tends to advance what we can obtain.
- Can they leave the infrastructure to venture out into the hostile atmosphere to be resistance fighters?
- If not, you won't be doing much resisting staying bottled up in the domes
- If you can leave the dome to resist, how likely are people to resist knowing the hostiles can simply vent every dome they encounter and let your supplies run out to end you.
- If its a breathable atmosphere, then resistance in any taken populated areas seems plausible. Outright combat or just a modifier to efficiencies?
- Is there really a point where the civvies would be so disloyal as to turn on you?
- The grass would have to be known, not thought, but known to be greener on the other side of the fence before they turn on you. Wealthier, benevolent, and have treated conquered planets well already? The civvies might just try to trade you in for a better life.
- xenophobia, biological/environmental compatibility, and ability to even communicate is likely to be a factor. Even if the grass is greener, do they leave the planet suitable for you, or terraform it to them and leave you restricted to infrastructure in perpetuity?
- if you know the grass is definitely greener right here, then its a choice between helping and apathy, not rebellion. If the invaders are known to mistreat the conquered, apathy is less likely, if they are known to exterminate it seems absurd, and in both cases, rebellion/assisting the invaders seems incredibly unlikely.
Perhaps none of that matters at all and it all simply hides behind abstractions, and you get 'given' a number of civilian combat units presumed to have equal traits but lesser abilities than standard soldiers, at the cost of some population loss, and what you do with them is up to you. Presumably once the battle is over any surviving volunteers auto disband and rejoin the population.
Suggestion 2: civilian mineral harvesters that go after comets/roids/moons. We already have fuel harvesters so why not!How would that differ from CMCs aside from the fact that instead of automines on a colony, there are asteroid miners on a colony?
I hope the research system is redesigned at some point. It is way to linear and not that interesting as a mechanic at the present.
Technologies which boost industry, research and economy should work very different from engineering and theoretical development. I think labs should be dedicated to a certain field but you should be able to convert them at a lower cost.
Scientist bonuses should not be immediately applicable to research projects but accumulated over time so there is a real choice between long term and short term planning. Instead of administration being a restriction on number of labs it could be a faster growth of science bonuses or some such.
I certainly don't want this to happen before C# Aurora is launched but at least that it perhaps is considered in some way down the line. The current system are a bit "gamey", you can role-play some restrictions of course, the same with industry.
I would love for industry construction to behave in a similar way where you can make long term plans or short term investment. Sort of like production lines in HoI 4 with a gearing bonus towards different projects. If you produce lots of things of a specific item you will produce that thing more and more efficiently over time... up to a certain limit based on technology or engineering skills.
To be fair, Hoi 4 is using Grit-and-grease man-powered assembly lines instead of super-hightech space-age omnifactories that use physics-defying elements
I hope the research system is redesigned at some point. It is way to linear and not that interesting as a mechanic at the present.
Technologies which boost industry, research and economy should work very different from engineering and theoretical development. I think labs should be dedicated to a certain field but you should be able to convert them at a lower cost.
Scientist bonuses should not be immediately applicable to research projects but accumulated over time so there is a real choice between long term and short term planning. Instead of administration being a restriction on number of labs it could be a faster growth of science bonuses or some such.
I certainly don't want this to happen before C# Aurora is launched but at least that it perhaps is considered in some way down the line. The current system are a bit "gamey", you can role-play some restrictions of course, the same with industry.
I would love for industry construction to behave in a similar way where you can make long term plans or short term investment. Sort of like production lines in HoI 4 with a gearing bonus towards different projects. If you produce lots of things of a specific item you will produce that thing more and more efficiently over time... up to a certain limit based on technology or engineering skills.
Yes this is something I would love as well in the far future.
I think Research and Industry construction could use similar mechanics. Basically start any new factory/lab at low efficiency (5-20%) and have them gradually, over some years build up proficiency in the area or category they work until a maximum of 100%
This means you want to make a long term plan that feels more realistic and resemble real limits rather than put 30/30 labs or 600/600 of your factories on a single project that you rush. It also means that you want to try to have some stuff building/researching in most categories in case you need something urgent from that category.
In fact I would much rather prefer if some of the leader bonuses ( which for Scientists can be massive ) is built into such a system rewarding long term planning and commitment into a tech field without getting lost because a random event decided it was time for that scientist to go.
HoI4 also have a diminishing returns built in here so that the first 10% of efficiency is gained much faster than the last 10% and that works really well to balance it out and reward very long term commitments.
Actually, if historical production schedules are anything to go by?
You are likely to see the 'mass produced' ships, the small ships, to get regular design updates and irregular complete redesigns of the types of ships. Because these ships are produced in large enough numbers that such a standardized design is desirable and it's practical to update regularly. The medium size ships? That's the point where an entire class is designed and allocated all at once. Sure the entire class is standardized, and given the time it takes to go from design to ship if the entire class doesn't get constructed at once (it won't be) you're likely to see new builds using refined designs and newer equipment while their older siblings languish with older stuff until a fleet wide update program.
But the big ships?
Big ships are bespoke. All of them. The US build ten of its Nimitz class carriers, but it took from 1968 to 2006 to build all of them. Which means that basically every time a carrier was getting build the US had the time to look at what was working, what was not and redesigning and refining the Nimitz class with every new ship. You could make a decent argument that calling it the Nimitz class is mistaken as each ship could be considered a subclass of the design by the time the keels got laid down.
There's a point in production, especially when the R&D cycle is running fast, where creating a factory for serial production optimization is not profitable, because it takes too long to build even a single item to even consider producing a second with the same setup when it's already obsolete.
With modern day computers the cost of designing a new ship is pretty much entirely just money and time. This is admittedly in no small part because there are massive databases with known materials and their behaviours that can be referred to when designing and simulating a new ship, obviating much of the need for prototypes and small scale tests that are later scrapped.You've already got the Shipyard Operations tech which makes re-tooling cheaper and faster, that does a decent job of covering the idea of learning about how to make ships out of TN material and building up such databases of parts and properties.
TN materials don't have this advantage, not early on, but as the knowledge of TN materials and their physics grows and develops this will become true of them as well. Because of this it might be more accurate to render the cost of retooling to nearly nothing except for some time and money but make research eat TN minerals. Of course, that would be a major shift in the game mechanics...
With modern day computers the cost of designing a new ship is pretty much entirely just money and time. This is admittedly in no small part because there are massive databases with known materials and their behaviours that can be referred to when designing and simulating a new ship, obviating much of the need for prototypes and small scale tests that are later scrapped.
This is more of just an RP thing, but i'd like a codex of all the individual ships that were build/destroyed with their history as well. Just to give a sort of "funeral" to ships that pioneered space travel.
This is more of just an RP thing, but i'd like a codex of all the individual ships that were build/destroyed with their history as well. Just to give a sort of "funeral" to ships that pioneered space travel.
This would be pretty good. Maybe some kind of historical records too, listing how many kills it got, how many missiles it shot down. Systems explored, bodies surveyed, jump points found... Stats for ships would be pretty neat.
This is more of just an RP thing, but i'd like a codex of all the individual ships that were build/destroyed with their history as well. Just to give a sort of "funeral" to ships that pioneered space travel.
This would be pretty good. Maybe some kind of historical records too, listing how many kills it got, how many missiles it shot down. Systems explored, bodies surveyed, jump points found... Stats for ships would be pretty neat.
Just write it down as it happens.
Have riots occur at high unrest where you lose wealth and buildings are damaged.
Have riots occur at high unrest where you lose wealth and buildings are damaged.
I'm actually considering having insurgents / rebels / partisans / freedom fighters (choose as need) appear at higher unrest levels. The fighting will cause collateral damage and they might even win and take over the population.
If they win and take over a population, could you give them all the same abilities as any other NPR, like building ships, training ground troops, and building colonies?
I would like to see the range of ship commands extended. For example the survey nearest object order, it has a range of 10 billion km which in most circumstances is ok, then you come across a system where theres planets/asteroids, sometimes hundreds of them, that are 50 billion km away, sometimes more. Maybe have this as something that is extended as you research better technology, and/or add more survey parts to a ship.
I would like to see the range of ship commands extended. For example the survey nearest object order, it has a range of 10 billion km which in most circumstances is ok, then you come across a system where theres planets/asteroids, sometimes hundreds of them, that are 50 billion km away, sometimes more. Maybe have this as something that is extended as you research better technology, and/or add more survey parts to a ship.
I'm pretty sure the 10 Terameter limit is a relic of VB6's performance issues. C# Aurora's search algorithm can likely handle much longer distances, and may even have already been modified to do so.
Since we're on surveys, would it possible to add a "survey next five planets/moons" order? Sometimes there's just too many asteroids and I want to survey planets first, so I can't give the "5 bodies" order, but "survey nearest planet or moon" is noticeably slower if you go by 5-days turns. I guess once a ship finishes its survey order, it waits for the end of the 5 days increment to generate its new survey order, while the ships with "survey next five system bodies" have a list to go through and don't waste as much time.
Since we're on surveys, would it possible to add a "survey next five planets/moons" order? Sometimes there's just too many asteroids and I want to survey planets first, so I can't give the "5 bodies" order, but "survey nearest planet or moon" is noticeably slower if you go by 5-days turns. I guess once a ship finishes its survey order, it waits for the end of the 5 days increment to generate its new survey order, while the ships with "survey next five system bodies" have a list to go through and don't waste as much time.You can circumvent this easily by using 1-day turns and Auto-Turns ON options.
Steve.... did you give any more thoughts into changing the Jump Drive requirement and size of the jump ship?
I think there are many changes in favour of smaller ships and I think this could be one good change in favour of bigger ships. It sometimes feel a bit restrictive to build bigger ships at low to mid tech levels because you also need to match them with an equal ship to jump them through jump point. It would open up some more strategic possibilities if we could use smaller jump ships to ferry larger military ships to their destinations.
I mostly end up adding the cheapest things possible to these ships so they require as little build material possible unless I can make a proper command ship out of it. But with increasing size I run out of good command equipment to put in that ship and are left with hangar space to fill them out which is cheap and versatile.
But in general I would like the option to build dedicated jump ships without having to add stuff to it just to make it bigger.
I don't know about others, but auto-turns are kinda painful for me to stop. Takes several tries everytime, and occasionally the system map window slips back behind every other window, it's not too bad if I set it to 2 minutes while NPRs are fighting and it ends up taking me 30 in-game minutes to finally manage to stop the autoturns, but with 1-day, I'd lose a lot of time.Since we're on surveys, would it possible to add a "survey next five planets/moons" order? Sometimes there's just too many asteroids and I want to survey planets first, so I can't give the "5 bodies" order, but "survey nearest planet or moon" is noticeably slower if you go by 5-days turns. I guess once a ship finishes its survey order, it waits for the end of the 5 days increment to generate its new survey order, while the ships with "survey next five system bodies" have a list to go through and don't waste as much time.You can circumvent this easily by using 1-day turns and Auto-Turns ON options.
Performance isn't the main concern. With a much higher limit, geo survey ships potentially will go sailing off into the middle of nowhere and then run out of fuel. A better option might be for me to introduce a distance option for standing orders at the fleet level or perhaps have 'survey within 10m', 'survey within 25m', etc.
If they win and take over a population, could you give them all the same abilities as any other NPR, like building ships, training ground troops, and building colonies?For roleplaying options, it might be most interesting of the SM can choose what kind of player it will become, when it happens. In a multiplayer game he can offer the new position to a potential new player who then plays them as a player - or if no interest, he can set them to NPR.
Steve, in your posting "Tactical map in background" you wrote: "C# does not have a starting menu bar in the same way as C#." I think the latter C# was meant to be VB6... .
Unrest should increase when unemployment rate is too high. People do want jobs! - Or if unemployment rises over a certain percentage, the civilian sector will begin employing those people into service industries. Takes them away from you if you later need them for production. However, if it switches around and you begin to have need of workers, and service industries do have more people empoloyed than they per game rules should have, they will (slowly) release those people which then will fill up your empty industries.This isn't a good thing because Aurora does not model commercial sector and non-TN industrial sector requiring work force. Logically, either there is a massive invisible population that produces trade goods, or those goods are actually produced by the unemployed population. This also doesn't mesh well with RP-scenarios where a nation only uses a portion of its real population for TN - for example I usually cut down 3rd world populations to simulate the general low education level as well as a balance measure.
This would mostly be for cosmetics - maybe there should be a reasonable punishment for your "service overemployments" applied. But I have no idea at the moment what could be reasonable. Maybe people get lazy and the overall productivity reduces.
I don't know about others, but auto-turns are kinda painful for me to stop. Takes several tries everytime, and occasionally the system map window slips back behind every other window, it's not too bad if I set it to 2 minutes while NPRs are fighting and it ends up taking me 30 in-game minutes to finally manage to stop the autoturns, but with 1-day, I'd lose a lot of time.Five 1-day turns might take a little longer than a single 5-day turn, but the auto-turns stop automatically when construction cycle runs, or something else that interrupts it, like a hostile contact, happens. So you won't lose out on production or research.
Plus, IIRC, it's still slower for 5 1-day autoturns than a single 5 days turn.
Any plans of adding resource silos for TN materials, which then can be attacked by the new ground forces... ? Rather then invading a planet for takeover one could then raid the planet to destroy its depots and cripple the enemy this way... .
Also would open a way for small infiltration units for sabotage or piracy...
This isn't a good thing because Aurora does not model commercial sector and non-TN industrial sector requiring work force. Logically, either there is a massive invisible population that produces trade goods, or those goods are actually produced by the unemployed population. This also doesn't mesh well with RP-scenarios where a nation only uses a portion of its real population for TN - for example I usually cut down 3rd world populations to simulate the general low education level as well as a balance measure.
Thus Steve would need to add a fourth sector to each colony - environment, service, commercial and TN-industry, and the relevant mechanism for populations to switch jobs. After all, not many nations can just command people to quit their day job at the mobile phone assembly line and instead start making missiles.
I think this is something that should be part of a larger population and economy overhaul, far down the line.
Any plans of adding resource silos for TN materials, which then can be attacked by the new ground forces... ? Rather then invading a planet for takeover one could then raid the planet to destroy its depots and cripple the enemy this way... .
Also would open a way for small infiltration units for sabotage or piracy...
I have considered this for both minerals and fuel, although it would have to be extended to missiles, ship components, etc. It would be a lot of extra work/management/UI. The question is whether that game play benefit would be worth it.
Another enhancement I have long considered is whether power to run everything should be required, from ground-based solar (distance from sun), geothermal (on high tectonic), TN reactors like those on ships, orbital solar collectors or even stations near the sun, etc. and whether power can be beamed and at what efficiency. That adds an extra layer of complexity and new infrastructure to be defended, but again it is a case of management vs game play benefit.
Any plans of adding resource silos for TN materials, which then can be attacked by the new ground forces... ? Rather then invading a planet for takeover one could then raid the planet to destroy its depots and cripple the enemy this way... .
Also would open a way for small infiltration units for sabotage or piracy...
I have considered this for both minerals and fuel, although it would have to be extended to missiles, ship components, etc. It would be a lot of extra work/management/UI. The question is whether that game play benefit would be worth it.
Another enhancement I have long considered is whether power to run everything should be required, from ground-based solar (distance from sun), geothermal (on high tectonic), TN reactors like those on ships, orbital solar collectors or even stations near the sun, etc. and whether power can be beamed and at what efficiency. That adds an extra layer of complexity and new infrastructure to be defended, but again it is a case of management vs game play benefit.
I would be happy if reactor power was required to run ship components, weapons, etc. Though it can always be surmised that the weight of reactor is already calculated when you add components, just like life support is, and the actual location of that reactor and its potential to be damaged is just abstracted away since its minor compared to the energy requirements of energy weapons. Though shields should need reactor power :pAny plans of adding resource silos for TN materials, which then can be attacked by the new ground forces... ? Rather then invading a planet for takeover one could then raid the planet to destroy its depots and cripple the enemy this way... .
Also would open a way for small infiltration units for sabotage or piracy...
I have considered this for both minerals and fuel, although it would have to be extended to missiles, ship components, etc. It would be a lot of extra work/management/UI. The question is whether that game play benefit would be worth it.
Another enhancement I have long considered is whether power to run everything should be required, from ground-based solar (distance from sun), geothermal (on high tectonic), TN reactors like those on ships, orbital solar collectors or even stations near the sun, etc. and whether power can be beamed and at what efficiency. That adds an extra layer of complexity and new infrastructure to be defended, but again it is a case of management vs game play benefit.
Suggestion: Organisational Number - Ground Combat
Not sure is there have been a suggestion on this, one thing I never liked about Ground Forces was the ability to continue to fight day after day, as long as they have supplies without rest. This mean combat instead of lasting months really on every last about a month total, no matter the size of the fights.
What I would love to see is something like an organisational number (very similar to HOI), which reduced each time the element is is combat. These numbers replenish over time, this stop the continual attack and allows combat to be a longer process then the current system. Or the very least swap out formations on the attack
The organisational number is an arbitrary number which describes a unit capabability over the length of time it fights, it is suppose to take into account combat fatigue, maintainence, continual combat degrades communications and organisational structure making commands slower.
Suggestion: Organisational Number - Ground Combat
Not sure is there have been a suggestion on this, one thing I never liked about Ground Forces was the ability to continue to fight day after day, as long as they have supplies without rest. This mean combat instead of lasting months really on every last about a month total, no matter the size of the fights.
What I would love to see is something like an organisational number (very similar to HOI), which reduced each time the element is is combat. These numbers replenish over time, this stop the continual attack and allows combat to be a longer process then the current system. Or the very least swap out formations on the attack
The organisational number is an arbitrary number which describes a unit capabability over the length of time it fights, it is suppose to take into account combat fatigue, maintainence, continual combat degrades communications and organisational structure making commands slower.
I *think* Steve mentioned that at some point because it was asked for earlier. It would be a very useful Quality of Life improvement. "Continual Capacity Expansion" opens a new sub-menu where you can write in the size.
Shipyards should be able to be detooled for either no or minimal cost, to stop you from having functionally useless shipyards that will never have a new class assigned to them due to retooling costs.
Unrest should increase when unemployment rate is too high. People do want jobs! - Or if unemployment rises over a certain percentage, the civilian sector will begin employing those people into service industries. Takes them away from you if you later need them for production. However, if it switches around and you begin to have need of workers, and service industries do have more people empoloyed than they per game rules should have, they will (slowly) release those people which then will fill up your empty industries.This isn't a good thing because Aurora does not model commercial sector and non-TN industrial sector requiring work force. Logically, either there is a massive invisible population that produces trade goods, or those goods are actually produced by the unemployed population. This also doesn't mesh well with RP-scenarios where a nation only uses a portion of its real population for TN - for example I usually cut down 3rd world populations to simulate the general low education level as well as a balance measure.
This would mostly be for cosmetics - maybe there should be a reasonable punishment for your "service overemployments" applied. But I have no idea at the moment what could be reasonable. Maybe people get lazy and the overall productivity reduces.
Thus Steve would need to add a fourth sector to each colony - environment, service, commercial and TN-industry, and the relevant mechanism for populations to switch jobs. After all, not many nations can just command people to quit their day job at the mobile phone assembly line and instead start making missiles.
I think this is something that should be part of a larger population and economy overhaul, far down the line.
Would it be possible to set a limit on the shipyards continuous capacity expansion. For example I want to build the shipyard up to 80,000 ton capacity I can either set it to continuous expansion and monitor when this is reached, or I can use several commands over time to build up to the eventual size required. If instead when I start the continuous expansion I set a limit of 80,000 and then have the shipyard stop expanding, It would be simpler and cause less micromanagement as well.Such an option would be great - and would make obsolete all prefixed value. Just imput target size and no of slipways - voila.
Brian
Even in VB6 Retooling cost is never higher than it would be for an empty shipyard. The cost is checked for empty or converting from the current tooled class. If converting is cheaper than empty, then that number is used. Otherwise empty is used.
That was more to model the the shipyard being "built for spec" the first time. In effect, the cost of retooling for your first ship is included in the cost of the shipyard itself.
In other words, working as intended :P
Has the military recruitment been talked about yet? Being able to choose if your armed forces are conscripts or volunteer-based professional military force, that sort of thing.
On the ordnance factory page, i'd love to have a button to mash that would compute a "missile census", counting the existing missiles by type as well as aggregating the loadout specs of my ships (including those building) by missile type. if displaying all that data is a pita, just getting supply and demand numbers for one type (via dropdown?) would still be pretty godlike.
It might be a good idea to make info the AI uses as inputs visible to players in general (when the info would be useful to the player), that way there is a way higher chance of noticing if its getting miscalculated (or noticing if the calculations ever break), which would hopefully lead to more reliable AI over the long term.
Hmmm, thinking about a reverse command. In the Fleet command window you can give a fleet the order to replenish missing missiles from planetary (or whatever) stockpile. Calculating, that the stockpiles wouldn't be enough, is easy for the computer. Auto-generating a production task which builds the missing missiles - would be a nice addon ;-)On the ordnance factory page, i'd love to have a button to mash that would compute a "missile census", counting the existing missiles by type as well as aggregating the loadout specs of my ships (including those building) by missile type. if displaying all that data is a pita, just getting supply and demand numbers for one type (via dropdown?) would still be pretty godlike.
The NPRs are doing all of the above in C# Aurora, so they know what missile types to build. Would be relatively easy to show to players too.
Suggestion:I would not bother too much about that. If anything terraforming should become more detailed in terms of opportunities. You should need some way to bind/extract harmful gasses, and you need something to release useful gasses to build up an atmosphere, instead of producing gas out of nothing.
Make terraforming less braindead. Right now, the terraforming system is really detailed, but it always boils down to the same actions as far as the player is concerned. Add 0.1atm oxygen, remove poisons, add greenhouse/anti-greenhouse gas, remove excess pressure. It's cool that the atmospheres are actually tracked and all, but there's no choices being made here.
I propose making terraforming actually involve some choices or trade-offs. Maybe Mercury would be better not terraformed; solar panels work better with no atmosphere in the way. Titan is better with it's cold and dense atmosphere; computation is more efficient the colder it is, thanks to Landauer's Limit, so a thick, cold atmosphere makes a great heatsink. Make us have to choose between a habitable planet or a planet that's good for supercomputers or solar panels.
There are a number of changes in C# that affect terraforming, including hydrosphere requirements, planetary capacities, speed dependent on planet size, tide-locked planets have different temperature effects, etc.. While the mechanics are similar except for evaporation/condensation, there are a lot more factors in the decision of where to terraform.That just changes what planets are worth it though, there's still basically no decisions being made during the terraforming process. Once a player has decided to terraform a world, the process is the same as it was on VB6. Some worlds might take longer, some might be quicker, but the point is that there is still going to be an optimum way to terraform. I am suggesting that there be trade-offs. For example thinning Titan's atmosphere and warming it up will make it better for human habitation, but worse for running super-computers or any industry that generates a lot of waste heat. There is a trade-off going on here that doesn't happen in either the old system or the new system. It wouldn't just be "Do I terraform this world?" but rather "Do I terraform this world, and if so, in what way?"
For example thinning Titan's atmosphere and warming it up will make it better for human habitation, but worse for running super-computers or any industry that generates a lot of waste heat. There is a trade-off going on here that doesn't happen in either the old system or the new system. It wouldn't just be "Do I terraform this world?" but rather "Do I terraform this world, and if so, in what way?"But that makes absolutely no sense. It does not matter how much more solar energy you get on Mercury without atmosphere or how much easier it is to run supercomputer on Titan if humans would still need specialized infrastructure to live there. Any savings you get on energy or cooling would be offset by the cost of having to import infra to accommodate colonists. The value of a colony cost 0 world is priceless. I do understand what you're proposing, making the details of terraforming a decision, but there already is a decision on whether to terraform a body in the first place and with the additional new rules, that decision is a bit more complicated than before.
I don't think wht you're asking for makes that much sense. I wouldn't mind a little more detail to the process, but realistically I've only ever really seen terraforming proposed as making a planet more habitable. Indeed, there's a hint in the very word,"terraforming". I haven't seen it seriously argued that it might be a good idea to turn planet earth into a giant snowball or getting rid of all the atmosphere and I don't think this would really add much to gameplay to make this decision. You'd end up just having a bunch of template planets for specific purposes and the process would be identical.There are a number of changes in C# that affect terraforming, including hydrosphere requirements, planetary capacities, speed dependent on planet size, tide-locked planets have different temperature effects, etc.. While the mechanics are similar except for evaporation/condensation, there are a lot more factors in the decision of where to terraform.That just changes what planets are worth it though, there's still basically no decisions being made during the terraforming process. Once a player has decided to terraform a world, the process is the same as it was on VB6. Some worlds might take longer, some might be quicker, but the point is that there is still going to be an optimum way to terraform. I am suggesting that there be trade-offs. For example thinning Titan's atmosphere and warming it up will make it better for human habitation, but worse for running super-computers or any industry that generates a lot of waste heat. There is a trade-off going on here that doesn't happen in either the old system or the new system. It wouldn't just be "Do I terraform this world?" but rather "Do I terraform this world, and if so, in what way?"
And since now financial centers are going to be more useless than ever. . .
EDIT: Also, why is this post getting extra spaces in places I definitely am not putting them?
Do you heavily subsidize civilian shipping lines? Do you exploit the heck out of the Earth-Luna infrastructure run? Do your games last long enough to exhaust your home system minerals, and do you then move your heavy industry to colony worlds? Do you even build imperial freighters?
I've never found Financial Centres to be useless. In fact, I have always considered them essential. They are literally the first thing I build, every game (since they don't require TN tech). Turning resource-poor, population-rich worlds into banking havens is an essential step towards galactic conquest, and a fine retirement plan for Earth / Homeworld / forge worlds.
Population growth on its own does it all for free, cheaper and eventually faster than you can build financial centers. I'd rather use my resources, workforce and factory time on something else. Oh, and of course, wealth, too. I had completely forgotten financial centers also cost wealth when typing this.
If you can't grow your research & industry faster than your population can grow I think your either not expanding industry/research as aggressively as many of us do when we play, not play the game for as long or your much more active in colonizing, or a combination of them.I always run a deficit in the first few years, being in negative wealth is the norm. I solve it with a lot of colonies and conquests. Financial centers have never helped me one bit.
If you try and play an Empire where most population is on large worlds with low pop growth ( or keep them on the core homeworld ) you can grow your industry and research many times as fast as your population grows... which does inevitably lead to wealth shortage when you rely on only population taxes.
If anything, ship production bonuses should be based on how long it takes to build a ship and how long ago the previous ship was launched in such a case. Ships with long production times tend to get far less benefit from the builder's familiarity with the design than a ship that's build in a couple of weeks on a single slip.
If anything, ship production bonuses should be based on how long it takes to build a ship and how long ago the previous ship was launched in such a case. Ships with long production times tend to get far less benefit from the builder's familiarity with the design than a ship that's build in a couple of weeks on a single slip.
I don't think this is really necessary. Ships themselves are not mass produced in assembly lines, and overall it will be just a buff to small units. They already have a massive buff that it is far easier to create small shipyards than to create massive ones. The cost of retooling already incentivises to keep building the same ships, simply increasing that cost would be the easiest way to achieve the same result instead of a complicated system to calculate when what was built.
Suggestions/questions about Boarding Combat:
Will boarding parties be able to call in fire support from friendly ships?
I also suggest that ships being boarded gain/lose functionality as different compartments change hands.
Suggestions/questions about Boarding Combat:
Will boarding parties be able to call in fire support from friendly ships?
I also suggest that ships being boarded gain/lose functionality as different compartments change hands.
I've not written boarding party combat yet but I probably won't add direct fire support. If ships could fire that accurately to help boarding parties, it would create the question of why they don't fire to knock out specific systems in normal combat.
While I won't track which system is in the hands of each combatant, I think it would be safe to say that boarding could cause collateral damage and that it would affect the performance of the ship being boarded.
While it should perhaps not be possible to hit most things specifically in combat I think that engines should be one exception since they are very big and produce the majority of the heat. Especially heat guided missiles should have a greater chance of hitting the engines and you should also have a decently good chance of targeting engines with normal weapons as well. Of course the overall chance of hitting the target should go down of you try to hit something specific... but still could be fun.Heat guided missiles being more likely than normal to hit engines and EM guided missiles being more likely than normal to hit active sensors that have been turned on, could be neat, but I don't think the game needs a system for generally being able to target various components.
While it should perhaps not be possible to hit most things specifically in combat I think that engines should be one exception since they are very big and produce the majority of the heat. Especially heat guided missiles should have a greater chance of hitting the engines and you should also have a decently good chance of targeting engines with normal weapons as well. Of course the overall chance of hitting the target should go down of you try to hit something specific... but still could be fun.Heat guided missiles being more likely than normal to hit engines and EM guided missiles being more likely than normal to hit active sensors that have been turned on, could be neat, but I don't think the game needs a system for generally being able to target various components.
For example, a formation element of 10 tanks engaged in combat is part of an armoured formation with a brigade HQ formation above it and a division HQ formation above that. The tanks will check for a vehicle-based logistics element within the division formation first, then a vehicle-based logistics element within the brigade formation and finally either type of logistic element within their own parent formation. If no logistic elements are available, the tanks will use their inherent supply, although they can only use that inherent supply for ten combat rounds, unless resupplied. If a unit does not require a full resupply (for example, it still has sufficient inherent supply for eight combat rounds), it will only draw an appropriate fraction of its normal GSP requirement (in this case 20%).
really great :) was 100% what I was asking for :)
but quick question about this Steve...
will such a logistic formation be flagged as such for the whole battle running? I mean if I have a formation with 75% logistic size - after a few battle turns the logistic units are "used up", some destroyed by combat and there is only a ratio of 55% left (so under 2/3) but the fighting is going on...
will it still be a "logistic formation" for this rule or just a weak combat formation as it was with a lot of logistic units into? (which would mean it would be better to go 90% or even 95% in the beginning to be sure)
You may also have the reverse situation in some cases, in which a combat formation loses more combat elements than logistics elements and suddenly becomes a logistics formation.really great :) was 100% what I was asking for :)
but quick question about this Steve...
will such a logistic formation be flagged as such for the whole battle running? I mean if I have a formation with 75% logistic size - after a few battle turns the logistic units are "used up", some destroyed by combat and there is only a ratio of 55% left (so under 2/3) but the fighting is going on...
will it still be a "logistic formation" for this rule or just a weak combat formation as it was with a lot of logistic units into? (which would mean it would be better to go 90% or even 95% in the beginning to be sure)
Yes, that is a problem that would have to be addressed. In practical terms though, you would probably create a very logistic heavy formation and then merge with an HQ once it was very small. I need some form of check on logistic size though or the code would start using logistic units from 'normal' formations on the assumption they were logistic formations. Another option is I simply allow the player to flag logistics formations in the same way as supporting formations.
Or make it a special modifier similar to the various training changes. It just only works for formations made up of HQs and Logistics units and nothing else. Could even make for relatively cheap units; large scale logistics dumps have historically been run by second line units IIRC.
New Game Settings
This is a placeholder for Game-level modifiers
1) Percentage modifier for Research Speed (for all races)
2) Percentage modifier for Terraforming Speed (for all races)
3) Percentage modifier for starting minerals on Sol.
4) Flag for Active Civilian Shipping Lines. When this is disabled, shipping lines will not produce ships.
5) Flag for recovering tech due to conquest. You can disable this so no new tech is gained via conquest.
6) LY entry to limit Starting NPR Locations to within a specific range of Sol: http://aurora2.pentarch.org/index.php?topic=8495.msg108824#msg108824
7) Option for Planet X in the Sol System: http://aurora2.pentarch.org/index.php?topic=8495.msg109206#msg109206
You can specify a number of Earth-based player races on the Game Setup window. You will cycle through a number of Race Creation windows equal to the number of races selected. You will still need to create any non-Earth-based races after the main game creation process.
just looking at your test-game screenshots Steve - great :)
but with the last one (ground unit) - would it be possible to add a colom to show for how many batleturns/hours/days (something like this) the selected formation (including its sub-formations when it is a division etc) has supply for?
In your screenshot, there are 4 resupply infanterie units (LG2) - but it would be great to see for how long the "1.PDR" could be fight with this...
this would help the player for his own units a lot if this screen would show how long the supply (units) would last
Having seen the lates AI reports, an idea came into my mind.
One limitation to tell large scale stories is the amount of detail work you have to do with multiple nations. So how about different levels of control?
One: Full AI Empire - the AI controls all levels of this empire
Two: High Level Human - The human player can issue general decisions (negotiate peace, go to war, explore jump point XY, settle in system / on planet ABC); but everything below that is controlled by the AI
Three: Medium Level Human - The human player can issue additional commands like construct new ships or facilities, move fleets to XYZ, etc.
Four: Human Empire - The human player controls everything
What also would be interesting: to be able to switch between modes. For example control an empire on L2 until it goes to war, then switch to L4 and control all aspects of the war, when it is done switch back to L2... .
What I hope with C# Aurora, is that I can play a reasonable multiple start with one player and multiple AIs, that will not inevitably turn into a free-for-all Armageddon :)
What I hope with C# Aurora, is that I can play a reasonable multiple start with one player and multiple AIs, that will not inevitably turn into a free-for-all Armageddon :)
Then don't include a Chinese faction...
This only works if the human is prepared to follow the same constraints as the AI in setting up his colonies and forces (creating the correct types of ground forces, forming the right operational groups, designing and building the required ship classes with the required capabilities).My main idea is to have some minor nations in a multi-nation start being AI, but also being given general alliance orders but not having to micromanage every one of them. So, yes, if that would be possible with the restrictions you mentioned, why not... . Let's see how your AI performs and reserve this idea maybe for a later release.
This only works if the human is prepared to follow the same constraints as the AI in setting up his colonies and forces (creating the correct types of ground forces, forming the right operational groups, designing and building the required ship classes with the required capabilities).My main idea is to have some minor nations in a multi-nation start being AI, but also being given general alliance orders but not having to micromanage every one of them. So, yes, if that would be possible with the restrictions you mentioned, why not... . Let's see how your AI performs and reserve this idea maybe for a later release.
Paradox and Firaxis have, in their later games, shown how extremely difficult it is to get a helper-AI to work competently. In both games, it is far more useful to have player to control everything manually and if the AI is ever given permission to handle something even temporarily, the time-savings are lost when the player takes control back and has to fix the mess that the AI has done.Distant Worlds let's you more or less set whatever part of the game you don't want to be involved in to AI control, and as far as I'm aware it works quite well.
Perhaps better would be to allow SM to force a permanent alliance between a player faction and an NPR-faction IF that faction was created by a human player and not the game itself.
Paradox and Firaxis also couldn't AI their way out of a wet paper bag. I mean, they show its not easy at the very least, but they don't necessarily show much about whats hard.
I presume the AI has some flags/internal codes to know what ship types are used for. That could be exposed in a semi-AI mode, if you design a custom ship for it, you can tell the AI what it is good for, if it cannot figure it out itself.
A quick update on NPR Research.
There have been problems in VB6 with NPRs duplicating research or not following sensible research strategies. Therefore, each NPR design theme in C# Aurora has a built-in tech progression. This consists of many tech groups, each of which contains one or more tech types. For example, a group might simply contain armour, or it may contain a group of energy weapon related tech types, including the major components for the NPR's preferred weapon plus beam fire control techs. An engine-related tech group may contain reactor, engine and fuel consumption tech types. The NPR may have the same tech group multiple times in its design theme progression.
An NPR will check the total research cost for the tech group, based on the next tech within each tech type, and then dedicate all research in its empire toward achieving that total. For example, if the tech group is engines (reactor, engine, fuel consumption) and the NPR already has ion tech, it will total Stellarator Fusion Reactor (12,000), Magneto-plasma Drive Technology (20,000) and Fuel Consumption: 0.6 Litres per Engine Power Hour (8000) for a total of 40,000 RP. Once the total is hit, it gains all the techs in that tech group. Certain tech groups will trigger a redesign for NPR ship types and/or ground forces.
Each tech group has an associated research field based on the majority field within the group. Progression will be based on either the best scientist for that field, regardless of admin rating, or the best overall scientist if that bonus exceeds 4x the specialist bonus.
This gives some advantages over players (no admin limit) and some disadvantages (less flexible). Most importantly, this should provide a much more cohesive NPR research strategy and make NPRs more challenging as they improve their technology. This code has been working since before the current campaign.
A quick update on NPR Research.
There have been problems in VB6 with NPRs duplicating research or not following sensible research strategies. Therefore, each NPR design theme in C# Aurora has a built-in tech progression. This consists of many tech groups, each of which contains one or more tech types. For example, a group might simply contain armour, or it may contain a group of energy weapon related tech types, including the major components for the NPR's preferred weapon plus beam fire control techs. An engine-related tech group may contain reactor, engine and fuel consumption tech types. The NPR may have the same tech group multiple times in its design theme progression.
An NPR will check the total research cost for the tech group, based on the next tech within each tech type, and then dedicate all research in its empire toward achieving that total. For example, if the tech group is engines (reactor, engine, fuel consumption) and the NPR already has ion tech, it will total Stellarator Fusion Reactor (12,000), Magneto-plasma Drive Technology (20,000) and Fuel Consumption: 0.6 Litres per Engine Power Hour (8000) for a total of 40,000 RP. Once the total is hit, it gains all the techs in that tech group. Certain tech groups will trigger a redesign for NPR ship types and/or ground forces.
Each tech group has an associated research field based on the majority field within the group. Progression will be based on either the best scientist for that field, regardless of admin rating, or the best overall scientist if that bonus exceeds 4x the specialist bonus.
This gives some advantages over players (no admin limit) and some disadvantages (less flexible). Most importantly, this should provide a much more cohesive NPR research strategy and make NPRs more challenging as they improve their technology. This code has been working since before the current campaign.
This sounds great. What I would like in addition is variation in the AI research assignment weights, if possible. For example, let's say one NPR's racial idea of research is 'get powerful weapons, worry about fire controls later,' and so it would end up with high-tech weapons but its BFCs (or MFCs, as appropriate) might lag behind. Or, of course, in reverse. Similarly an NPR might worry about power generation more than beam research, because its racial AI figures advanced powergen (and drives) are more useful and it's ok lagging behind with only visible light lasers while it has magneto-pulse, for example.
Having seen the lates AI reports, an idea came into my mind.
One limitation to tell large scale stories is the amount of detail work you have to do with multiple nations. So how about different levels of control?
One: Full AI Empire - the AI controls all levels of this empire
Two: High Level Human - The human player can issue general decisions (negotiate peace, go to war, explore jump point XY, settle in system / on planet ABC); but everything below that is controlled by the AI
Three: Medium Level Human - The human player can issue additional commands like construct new ships or facilities, move fleets to XYZ, etc.
Four: Human Empire - The human player controls everything
What also would be interesting: to be able to switch between modes. For example control an empire on L2 until it goes to war, then switch to L4 and control all aspects of the war, when it is done switch back to L2... .
This only works if the human is prepared to follow the same constraints as the AI in setting up his colonies and forces (creating the correct types of ground forces, forming the right operational groups, designing and building the required ship classes with the required capabilities). The C# AI will be a lot better at handling unexpected situations or even using captured ships than in VB6, but it would not be difficult for human intervention to confuse the AI, even if only temporarily.
Some more basic form of human assistant might be possible on a limited scale (in fact, you already have that to a degree with standing orders). However, I would not want to restrict the AI code in order to have an on/off option for human intervention.
What I hope with C# Aurora, is that I can play a reasonable multiple start with one player and multiple AIs, that will not inevitably turn into a free-for-all Armageddon :)
Since we're talking about SM option wishes: could you add the option to let us modify a planet's characteristics as SM? Things like size, albedo, mass, density, gravity, etc.
The UI to make such a change is straightforward but the interactions are not. The density will affect mass and gravity (and vice versa), size will also affect mass and gravity while albedo will change the temperature (and therefore potentially the atmosphere, hydrosphere, dominant terrain and colony cost).Aw I thought that'd be the problem.
Changing the atmosphere by itself is fine as the code will react to that, but changing the more basic physical characteristics is trickier. Even when generating NPR home worlds in C# Aurora, I keep generating systems until I find a suitable planet/moon and then just adjust the atmosphere. I don't mess with the planets themselves post-generation.Then would it be possible to have a new button (or whatever else is convenient)? Something like "create home system", as opposed to "create system", generating systems until it makes up something suitable for an NPR, but doesn't actually spawn an NPR? Though with how fast system generation no doubt is in C#, it might become entirely useless, unlike in VB where it can take some RL time to get an inhabitable system only because generation itself takes so long.
What I would like to see is some SM options to handle NPRs better ( and also make providing feedback easier ).
1.) A SM option to view a specific NPR, but not touch anything. Basically you can go into all the interfaces like it was a normal race, but all action buttons are grayed out.
2.) A SM option to irreversibly convert a specific NPR to become a player controlled empire instead. Disables all AI functions and you now need to play it, could be helpful if the game get stuck due to some NPR/AI bug and you really want to continue it, or if you see the NPR AI doing something incredibly stupid and you want to take control to play out the "what if" scenario.
The first option is probably quite a bit of work, but I think it could be very helpful to provide feedback and improvement suggestions if we are able to observe the AI play "in action" so to speak. It could also be really cool to see some AARs written from the NPR perspective or detailing NPR vs NPR wars. Perhaps having a fully hands off start mode where you only can observe one or multiple NPRs could help with speeding up AI development and testing.
Then would it be possible to have a new button (or whatever else is convenient)? Something like "create home system", as opposed to "create system", generating systems until it makes up something suitable for an NPR, but doesn't actually spawn an NPR? Though with how fast system generation no doubt is in C#, it might become entirely useless, unlike in VB where it can take some RL time to get an inhabitable system only because generation itself takes so long.
Didn't NPR use to have fixed starting systems in VB instead and skipping the system generation entirely, by the way?
You mentioned that you're coming up with new ideas for spoilers. I'd like to suggest space pirates. These would be NPC combat dropships that come out of nowhere, capture your commercial and civilian ships, then (like an infection) they add a combat drop capability to those captured ships. By "coming out of nowhere" I suggest they're either very stealthy (disguised as commercial ships?), or they hide out in nebulas and on the unwatched sides of jump gate to strike where you might be vulnerable.Where are they coming from? Are they spawned by your own civilization? Are they spawned by competing human factions? Are they spawned by NPRs? How will they interact with spoilers? If they are created from your own faction, then how can a player prevent their creation in the first place? How can a player eradicate them completely? Where are they getting their ships and crew and missiles and maintenance supplies and fuel? Does a space empire need to be X size before they appear? How many military ships need to be in a system to prevent their spawning? How can they scout things out? Are they completely nullified the moment a player puts down a heavily armed defensive station on a jump point?
An idea for a new Spoiler Race or a "special and rare NPR":
A race with a specially ability/tech which shields from missiles to 100% - somethink like a craft field which let's detonate missiles in a save distant
This would lead the Player to get "0 damage" results in the overview as his missiles detonate so he might miss the fact that his missiles are useless the first few times...
to balance this, the Spoiler/NPR itself is not allowed to have missile launcher itself too but would need to have fast ships...
so it would bring a race into the game which must be attacked/defended against with other weapons than missiles - and give the player a nasty suprise if he encounter them the first time... no more "missile only" battles/research... but it should be rare enough to suprise the player
the tech for these (if not coded as a Spoiler-ability but added as a ship module) is strictly non-player ... which means even if it is a ship module it can't be research by the player but it MIGHT (very rare!!) be salvaged but will not give tech or research when disassembled (just some message "the tech is too alien to get any usefull information" and the module is destroyed)
This would allowthe player to - very rare - build it into one of his ships but only these modules he has luckily found in wracks... but the same rule (no missile launchers of any kind) would also go for a player ship with these modules
a module could come in different variants (100t for a 1000t ship, 500t for a 5000t ship, 1000t for a 10000t ship etc...)
the modules I am not sure about but the possibility to meet an alien Race which is invulnerable to missiles in very rare possibilities could be really fun - especially as it would be a shock for the military and would bring them "around" to review there battleline in view of the new thread...
You mentioned that you're coming up with new ideas for spoilers. I'd like to suggest space pirates. These would be NPC combat dropships that come out of nowhere, capture your commercial and civilian ships, then (like an infection) they add a combat drop capability to those captured ships. By "coming out of nowhere" I suggest they're either very stealthy (disguised as commercial ships?), or they hide out in nebulas and on the unwatched sides of jump gate to strike where you might be vulnerable.
What I would like to see is some SM options to handle NPRs better ( and also make providing feedback easier ).
1.) A SM option to view a specific NPR, but not touch anything. Basically you can go into all the interfaces like it was a normal race, but all action buttons are grayed out.
2.) A SM option to irreversibly convert a specific NPR to become a player controlled empire instead. Disables all AI functions and you now need to play it, could be helpful if the game get stuck due to some NPR/AI bug and you really want to continue it, or if you see the NPR AI doing something incredibly stupid and you want to take control to play out the "what if" scenario.
The first option is probably quite a bit of work, but I think it could be very helpful to provide feedback and improvement suggestions if we are able to observe the AI play "in action" so to speak. It could also be really cool to see some AARs written from the NPR perspective or detailing NPR vs NPR wars. Perhaps having a fully hands off start mode where you only can observe one or multiple NPRs could help with speeding up AI development and testing.
At the moment I am using the 'designer mode' option to reveal all NPRs, although all the buttons are active. Unlike VB6 I can actually give the NPR fleets orders in some cases, although they may be overridden if the fleet is a type of operational group that is periodically reviewed by a higher level AI (the interval between reviews is dependent on operational group type and whether hostile forces are nearby). It would be a lot of work to disable everything as there are a LOT of potential buttons to press. Theoretically, it would be easier to leave designer mode as is and warn people not to touch anything because it could cause errors, although I suspect some people would not be able to resist and then I end up with bug reports that aren't real :).
Converting an NPR to a player race would not be difficult, as it would just be a case of removing the AI. There is an AI object in each NPR Race, System, Fleet, Ship and Population object (composition rather than inheritance). If I take those out and flip the Race level 'NPR' flag, the NPR will suddenly be a player race.
At the moment, Precursors and Swarm fill the pirate niche (a localised enemy with a reason to fight).
The reason there are currently no 'space pirates' in Aurora is that it is very difficult to create any form of in-game justification for them. An NPR that raids other races may be possible (and is on my list) but they need the infrastructure to support that effort, some form of safe harbour or well-protected base (which needs an economic base to build it) and an economic or political justification for that behaviour.Maybe a corporation that has grown too big, can channel some of its money in funding a pirate branch... (idea not inspired by Megacorp in any way, shape or form :) ).
At the moment, Precursors and Swarm fill the pirate niche (a localised enemy with a reason to fight).
Another idea for spoilers: a nomadic (like Swarm) 'race' that cannibalizes other resources for growth and movement, also much like the swarm. The difference is, while the swarm will eat your ships out of space (and bomb you into the Stone Age? Iono.) these guys focus primarily on landing ground troops and cannibalizing your colonies and/or mining operations. They'd have a respectable presence in space, but nothing special - perhaps a little nastier than the Precursors, but not much. But if they manage to land troops, on the ground they're truly nasty.
Of course the question would be how are these different from a particularly aggressive NPR with an advanced start, but methinks you could make their internal mechanics quite distinct. For example, instead of mining and building infrastructure to build ships and ground troops, they would instead consume infrastructure and convert it into ships and ground troops, eventually leaving a planet de-colonized (with, perhaps, some minor ruins) before moving on.
It would also give you a chance to showcase the newly reworked ground combat and organization system.
The updated Star Swarm in C# will have a significant ground-based component.
The reason there are currently no 'space pirates' in Aurora is that it is very difficult to create any form of in-game justification for them. An NPR that raids other races may be possible (and is on my list) but they need the infrastructure to support that effort, some form of safe harbour or well-protected base (which needs an economic base to build it) and an economic or political justification for that behaviour.
You mentioned that you're coming up with new ideas for spoilers. I'd like to suggest space pirates. These would be NPC combat dropships that come out of nowhere, capture your commercial and civilian ships, then (like an infection) they add a combat drop capability to those captured ships. By "coming out of nowhere" I suggest they're either very stealthy (disguised as commercial ships?), or they hide out in nebulas and on the unwatched sides of jump gate to strike where you might be vulnerable.
The reason there are currently no 'space pirates' in Aurora is that it is very difficult to create any form of in-game justification for them. An NPR that raids other races may be possible (and is on my list) but they need the infrastructure to support that effort, some form of safe harbour or well-protected base (which needs an economic base to build it) and an economic or political justification for that behaviour.
Another suggestion: can we get an option to use miles instead of kilometers, knots instead of km/s, and gallons instead of litres? The metric system implies a dystopian future and I prefer to imagine a future where the good guys win. ;)
this would add to the game:We already have this. The player can SM in a few ships and fight it out themselves, or SM an entire civilization for Aurora to run by AI rules.
- pirates for role playing and something to look at
- the need for the player to actually "patrole" his systems with is realistic - instead of just parking ships or PDC or ground-units somewhere in the systemTHE ONLY PERSON STOPPING YOU FROM PATROLLING YOUR SYSTEMS IS YOU. I already have system patrols in my game. If your empire is "just parking ships or PDC or ground-units somewhere in the system" then it is doing so because YOU chose to have it do so. Aurora reflects the level of realism you choose to put into it.
- a choice for the player if he is "taking the wealth hit" for a medium/long time in a war where he needs to order the "patrole ships" out of the system - or letting the ships to patrole and going to war with less shipsAgain, this is solved by THE PLAYER choosing to operate their empire realistically,* or by exploiting the minimum requirements forced upon them by the software. Since literally nothing is stopping you from running your empire the way you want, what you are asking for is to 'stop those other people from having their fun the wrong way.'
We already have this. The player can SM in a few ships and fight it out themselves, or SM an entire civilization for Aurora to run by AI rules.
...
*THE BEST FEATURE of Aurora is the near-total ability of the player to decide what is 'realistic' for their empire. It's almost the only reason to play.
For 'pirates' to exist they need:
1) A shipyard to build their ships
2) Maintenance facilities to support them
3) Fuel Production facilities
4) Ordnance factories if they are missile-armed
5) Some way of building or acquiring all of the above and transporting/towing them to their destination
6) Population to man all of the above.
7) An economic rationale for their activity - why not use their ships for trade instead? Why is piracy more profitable or desirable when the potential (and likely) downside is destruction of their ships and loss of their lives?
Here is how a rationell could go:
Criminals would threaten the personell of civilian or player mining colonies. They would then provide either resources / maintenance / hidden shipyards for ship construction and repair.
1) The shipyard could be hidden in an extension of a civilian mining colony or one of a players automated mining sites.
2) likewise for maintenance
3) likewise for fuel production if they can afford it and don't steal enough
4) likewise for missile production
5) towing capacities are not needed this way
6) manpower will be provided by the civilian or player facilities
7) it could be state supported piracy (a player who wants to weaken another player but not attack him openly could support pirate activity), or freedom wishes. Maybe a colony with "low morale" wants to be independend but are not granted. They could resort to piracy (or more politically correct: rebellions).
I have no problem with the idea of a threat that requires the player to actively patrol systems. However, there needs to be an in-game rationale and capability for that threat to exist. For 'pirates' to exist they need:
1) A shipyard to build their ships
2) Maintenance facilities to support them
3) Fuel Production facilities
4) Ordnance factories if they are missile-armed
5) Some way of building or acquiring all of the above and transporting/towing them to their destination
6) Population to man all of the above.
7) An economic rationale for their activity - why not use their ships for trade instead? Why is piracy more profitable or desirable when the potential (and likely) downside is destruction of their ships and loss of their lives?
It will be easier in C# Aurora to hide such facilities (due to reduced sensor ranges), but they still need to be created and moved to their destination. Also, the easiest way to destroy the 'pirates' would be to locate and destroy their support infrastructure so they would need defences for that too. I know 'Civilians' have support infrastructure we don't see but that infrastructure is not an active threat (and could be logically added if really needed).
BTW we aren't talking about a few guys in a skiff using RPGs to threaten a tanker. The 'pirates' in Aurora would be operating in deep space within the constraints of the Aurora economic model. Also, even if we draw parallels with Somali pirates, in the Aurora-verse the Western Powers would likely solve the problem by nuking the entire Somali coast.
On a somewhat related and possibly prerequisite note, an idea is perhaps some non-commercial civilian ships. Police frigates, pleasure yachts, bounty hunters, mercenaries, corporate guards, etc, some of which may be armed. They perform no actual function, just fly from place to place. They fight if hostile ships come in range, but dont go seeking enemies. They are armed with outdated tech (maybe 1-3 tech levels behind current tech, only created if the result > 0).
If they get destroyed, they cause a temporary small malus to wealth generation of colonies in nearby systems.
The function of these ships gameplay wise?
Battlefield terrain to use up attackers resources or forces them to avoid these ships (or get shot at)
Things for enemies to attack that hurts you less than a full nuclear assault on a homeworld or a lost fleet.
Raiding targets for small fleets
Hooks for potential future development such as pirates (Pirates dont build ships, they steal/buy these and use em till they break)
With regards to the pirates, I dont think pirates appearing to be civilian ships is going to work very well unless they only appear to be that way while inside sensor range. Can still be a bit noticable if they are off conventional trade routes.
I have no problem with the idea of a threat that requires the player to actively patrol systems. However, there needs to be an in-game rationale and capability for that threat to exist. For 'pirates' to exist they need:
1) A shipyard to build their ships
2) Maintenance facilities to support them
3) Fuel Production facilities
4) Ordnance factories if they are missile-armed
5) Some way of building or acquiring all of the above and transporting/towing them to their destination
6) Population to man all of the above.
7) An economic rationale for their activity - why not use their ships for trade instead? Why is piracy more profitable or desirable when the potential (and likely) downside is destruction of their ships and loss of their lives?
It will be easier in C# Aurora to hide such facilities (due to reduced sensor ranges), but they still need to be created and moved to their destination. Also, the easiest way to destroy the 'pirates' would be to locate and destroy their support infrastructure so they would need defences for that too. I know 'Civilians' have support infrastructure we don't see but that infrastructure is not an active threat (and could be logically added if really needed).
BTW we aren't talking about a few guys in a skiff using RPGs to threaten a tanker. The 'pirates' in Aurora would be operating in deep space within the constraints of the Aurora economic model. Also, even if we draw parallels with Somali pirates, in the Aurora-verse the Western Powers would likely solve the problem by nuking the entire Somali coast.
I do have some ideas about spoilers or NPRs that will fulfill a 'raiding' function, using a logical rationale for their behaviour and with an economic support structure. However, having pirates in the classical sense is difficult to envision within the logical constraints of the game.
Or, as someone said, piracy is a criminal activity, not a nation-state activity (which is covered by privateering).
Devil's advocating here: I suspect very few pirates in the classic era (covered by the ultimate reference Sid Meier's Pirates! :) ) built their own ships. Haven't done a lot of reading on it, but I suspect piracy was very much centered on non-aligned/un-incorporated population centers, which in turn is coupled to force deployment difficulty.Also, mutineers taking over a naval vessel and setting up their own protection racket. In the Auroraverse, spaceship crew is relatively small, presumably reasonably well paid and treated as skilled professionals. In the era of tall ships, crews were huge, considered not quite full-membership humans, and treated rather shabbily. So sometimes the sailors would realize that they were a long way away from anywhere that was expecting them to come back, in an era when ships could feasibly simply go missing due to some happenstance misfortune, there were a whole lot more of them on the vessel than there were officers and marines, and those officers and marines were really not doing anything to endear themselves. At which point there would be a short round of fragging (usually richly deserved; 16th and 17th century military officers were generally swine that needed gutting), a quick repainting of the vessel name and ditching of official insignia, and a freshly minted freelance vessel available for local trade, smuggling, or the odd spot of remunerated violence.
I dont think that pirates in a conventional sense make sense logistically in the Aurora universe due to the massive logistical restraints placed on the fielding of ships. Aurora pirates, if they existed, would never prey on deep space civilian freighters when it makes much more sense to prey on the cargo shuttles that supply them, meaning pirates would likely never stray too far from the surface of a planet. Pirates make much more sense as an NPR theme, one focused on breaching ships and capturing cargo, ships, and passengers then it does as swashbuckling in space.Preying on cargo shuttles doesn't make a lot of sense for a few reasons. First, you're so close to the planet that you're easily visible. Who will buy the goods they just saw you steal? Theft in deep space is much easier to hide. Second, if cargo shuttles are abstract, why wouldn't there be abstract police forces?
I have to say I’m not a fan of the space pirate thing. Does not seem an easy fit with the Aurora scheme of things. If you wanted to push patrols etc perhaps adding a system level defence requirement on top of a planet level defence requirement would be a way to do that. Points would come of mobile ships and you would need minimum levels before which merchant ships would be happy to trade. If that defence value deteriorated over a period of time rather than just drop when ships were not present then a patrol system would then become a key way of meeting this. To my mind though I don’t think that really adds anything much to the game play and is more of a faff.The problem with that is that it's just as easy to exploit as PPV currently is. In VB6, I deal with PPV by shipping non-functional, super-cheap PDC's made of nothing but the cheapest missile launchers I can build. I would just do the same thing to get by this system; super-cheap hulks made of just cheapo missile launchers.
Why have any mechanics at all then? I mean, what is the purpose of anything in the game if you can just SM or imagine it all?
I'm happy SM is a feature, but the more mechanics Aurora supports on its own, the better.
So for piracy to be realistic, the government structure of Aurora would need to change to have much less of a "hive mind" model (referring to a conversation a year or so back about how much micro-ing players should do and how much control they should have over details of the empire - hive mind is 100% centralized control/microing) for the parts of the civilization - the pirates would "swim in the populace". In this model, civilians would have exploration ships that would search for habitable worlds, and when they found them the civies would start their own colonies, with or without government assistance. Those colonies wouldn't be part of your empire unless regularly visited by your military forces, and would act against the empire's interest if the player's back is turned.
Another suggestion: can we get an option to use miles instead of kilometers, knots instead of km/s, and gallons instead of litres? The metric system implies a dystopian future and I prefer to imagine a future where the good guys win. ;)
It's only a matter of time.
The metric system will eventually replace the imperial one.
Surrender yourself, resistance is futile.
Another suggestion: can we get an option to use miles instead of kilometers, knots instead of km/s, and gallons instead of litres? The metric system implies a dystopian future and I prefer to imagine a future where the good guys win. ;)
I do really like the idea of civilians independently building colonies that the government doesn't control. I find that in my games I like to be quite deliberate in which systems I expand to, so I can place maintenance facilities, PDCs, fuel harvesters, etc., and defend the border as I move it forward. Civilians would mess up my plans by settling in any old system that had a 2.0 world, adding to the challenge by reducing my control. Maybe it's not Aurora but it would be a neat game.
Can we have an option to SM in spoiler races ..
Quote from: Seolferwulf link=topic=9841. msg111408#msg111408 date=1545365249Quote from: joeclark77 link=topic=9841. msg111407#msg111407 date=1545364043Another suggestion: can we get an option to use miles instead of kilometers, knots instead of km/s, and gallons instead of litres? The metric system implies a dystopian future and I prefer to imagine a future where the good guys win. ;)
It's only a matter of time.
The metric system will eventually replace the imperial one.
Surrender yourself, resistance is futile.
Remind me. . . whose 3x5-foot flag is on the moon?
The USA flag. Which got there using metrics, not imperials.
I was wondering if there is a system to limit the number of commanders who can hold specific ranks. I understand that I can make ranks with such prohibitively high promotion scores and just manually assign people, but I was wondering if we can automate that somehow.
I would like to request from Steve more terrifying galactic invaders. They are really needed in my opinion.
In current Aurora, they're not very high tech level. Sure, if they come very soon by chance, they are not winnable. Especially with conventional start, which I always use. But I want to feel... TERROR... when they arrive :)
I have three possible suggestions for ways to do this:
1) Choose at game start how BRUTAL they are.
2) Have them reliably better than the players when they appear. In tech level, but also with better designs. This is my least favorite options, as it would not reward at all the player who invests a lot in tech research
3) ... who said there's only one race of galactic invaders? Maybe they have a fractured "nation", with different factions or similar. And if you do repel one.... another stronger faction will come knocking later on, with a lot of new and exciting toys ;D
P.S. Precursors need better ship designs as well :)
Quote from: prophetical link=topic=9841. msg111682#msg111682 date=1546025630I was wondering if there is a system to limit the number of commanders who can hold specific ranks. I understand that I can make ranks with such prohibitively high promotion scores and just manually assign people, but I was wondering if we can automate that somehow.
It's already automated by proprotion -- either 1/3 or 1/2 the net lowest rank, but if you mean a way to ensure that your rank of 'Supreme Grand High Sky Marshal of the Galactic Battle Fleet, Survey Fleet, and Support Fleet' only ever has one person in it, then no, there isn't currently such an option. I, too, would be happy to see cap I could set to limit the maximum number of officers in a sepcific rank, so that my "Council of Twelve" would in fact have twelve members and not fifteen.
Yes, I do indeed want a GHSM of GBFSF&SF. Is that so wrong? ;)
But you did explain it well that a specific cap is what I am interested in.
Could take a page from Star Trek and have space-faring alien life forms. Space whales, etc.
Suggestion: Modify retooling costs for a shipyard based on how similar the class designs are, similarly to how class similarity is determined for building from the same yard and for refit cost. If you change tooling from one freighter to a slightly more advanced freighter, it would take less time than changing the tooling from a destroyer to a fleet carrier.
A suggestion for an improvement to conditional and standing orders:
Split it up into two screens: One is entirely called conditional orders, where you can assign triggers with actions to be taken, and save them under a custom name.
Multiple orders can be joined, to make for example a 'standard refuel and maintenance policy'
Orders here could also be customized, for example limit which specific maintenance locations are eligible, or which sites should be supplied with autominers, or colonists.
Fleets themselves would just sign up to the previously defined standing order sets. If you later on change the standing and conditional orders, it will change them for any fleet that were assigned that order set.
This would prevent a lot of repetition, and allow for future expansion of more interesting and advanced conditional behavior.
A few mostly QoL suggestions on components:
1, a 0. 02HS 'micro' fuel tank after the tiny fuel tank research. This is mostly to be used on fighters. It should find its usefulness as ship engines can be smaller than 1HS in C#. (Currently the only component <0. 1HS is the fighter crew module, which is 0. 04HS, and when it is used, the fighter tonnage will end up with xx2 or xx7 ton, which can be an eyesore for some players. )
2, larger cargo holds for research, maybe a large cargo hold = 5x standard cargo hold, and a huge one = 50x standard cargo hold.
While that sounds like a great justification flavour-wise, wouldn't it mechanically be just an increase to the 'fortification rate' of the defenders in a boarding action? If you want your ship to be better at repelling boarders, then you should either add extra crew (for low cost, low effectiveness fighters) or outright Infantry formations. A 50-ton 'Infantry' unit of crew-served anti-personnel weapons isn't much different from 1 Hull Space of 'automated turrets' and the computers & crewpower to maintain and run them.
Having defenses be different from infantry and just crew members I think would be important, like how vehicles and aircraft are different from infantry. It would need to have trade offs for why have automated defenses rather then having a garrison or vice visa.
I think marine detachments to defend your ships are fine for RP and if they are added into NPR ship design it's OK as I hope that the AI in C# might be smart enough to use them to board itself instead of just killing...
While that sounds like a great justification flavour-wise, wouldn't it mechanically be just an increase to the 'fortification rate' of the defenders in a boarding action? If you want your ship to be better at repelling boarders, then you should either add extra crew (for low cost, low effectiveness fighters) or outright Infantry formations. A 50-ton 'Infantry' unit of crew-served anti-personnel weapons isn't much different from 1 Hull Space of 'automated turrets' and the computers & crewpower to maintain and run them.The big difference I see is that those automated turrets are attached to the ship. You can't drop them on a planet or move them to a different ship.
I've added the 0.02 HS fuel tank, which costs 0.5 BP and holds 1000 litres.How about a general change of all "cargo" modules? A system where you specify the amount of space/fuel/maintenance you want - as well as the amount of subdivisions (so that not the whole fuel gets lost when the fuel module is hit/destroyed - and the game simply calculates how much HS that would take.
I've also added a Cargo Hold - Large, which is 5x larger than the standard cargo hold. Size 2500 HS, Cost 200 BP.
A suggestion for missiles in C# if not too complicated.If I recall correctly, currently in VB6 sub munitions do use their parent stage sensors. Mines do not require sensors on the sub munitions.
Since the new sensor system might make self guiding missiles a bit more interesting and viable how about allowing munition inside a large missile being able to use the active or passive sensor of the parent missile. You could add a small 0. 25 MSP electronic guidance system or something to control them. I honestly don't remember how it worked in VB6 with mines and stuff, I rarely used mines, but I'm sure the sub munition could not use the parent sensors.
This could be interesting to build hit and run type ships or engage in sort of submarine style fighting.
Hey Steve, I was hoping for some fixes to PD in C#. Currently, and I know that this doesn't effect you as much, but PD falls off pretty hard in the late game. From some number crunching, it appears that the new missiles changes don't fix this issue either. Would it be possible to get a better PD balance in the late game to compensate for this?
Hello, I would like to suggest the addition of an option to shut down individual shipyard slipways, or simply the shipyards themselves (possibly by adding new options to the industrial sector shutdown screens).
Hey Steve, I was hoping for some fixes to PD in C#. Currently, and I know that this doesn't effect you as much, but PD falls off pretty hard in the late game. From some number crunching, it appears that the new missiles changes don't fix this issue either. Would it be possible to get a better PD balance in the late game to compensate for this?
Can you provide some numbers for how it falls off?
The tracking speeds roughly keep pace with engine power, otherwise it would become easier to hit opposing ships with beam weapons. It seems to be that AMMs benefit from increased agility at higher TLs, more than PD is penalised. Also, missiles in general gain from the ramp up in max power mod after the early levels.
Increasing tracking speed would make it very easy to build beam-only fleets that are immune to missiles (which is already not that difficult). AMMs should become less effective anyway in C# Aurora due to the missile ECM changes, so I think I need to see how that works out in practice before looking at any agility reductions. I might also lower the RP costs for the power boosts to give early AMMs some help.
We've had some discussions and crunched some numbers with what we know about missiles in C#, and from what Iceranger has found it doesn't seem to impact AMMs much, if at all. I agree that increasing tracking speed as a whole would make beam fleets really good, but a buff to only PD would be very helpful. Like I've said, the tracking speed bonus vs. missiles currently doesn't do anything, so that's a big hit to non-AMM PD. Things like that, things that can only apply to PD, could make PD better as a whole.
Hello, I would like to suggest the addition of an option to shut down individual shipyard slipways, or simply the shipyards themselves (possibly by adding new options to the industrial sector shutdown screens).
You can shutdown shipyards in VB6 by towing them to a nearby moon. C# at the moment doesn't have the code to shut down anything. I'll look at various options when I get to this area. I've wondering if the ability to just shut down large sections of industry and then re-open them is a little too easy and there should be other options for handling a lack of workers.
We've had some discussions and crunched some numbers with what we know about missiles in C#, and from what Iceranger has found it doesn't seem to impact AMMs much, if at all. I agree that increasing tracking speed as a whole would make beam fleets really good, but a buff to only PD would be very helpful. Like I've said, the tracking speed bonus vs. missiles currently doesn't do anything, so that's a big hit to non-AMM PD. Things like that, things that can only apply to PD, could make PD better as a whole.
Given that AMMs need on-board ECCM now to be fully effective against ECM-equipped missiles (which are better than in VB6), I'm not sure how it doesn't impact them.
Before I make any significant changes to point defence or tracking speeds, I need to play test. A lot has changed.
The tracking speeds roughly keep pace with engine power, otherwise it would become easier to hit opposing ships with beam weapons. It seems to be that AMMs benefit from increased agility at higher TLs, more than PD is penalised. Also, missiles in general gain from the ramp up in max power mod after the early levels.
Increasing tracking speed would make it very easy to build beam-only fleets that are immune to missiles (which is already not that difficult). AMMs should become less effective anyway in C# Aurora due to the missile ECM changes, so I think I need to see how that works out in practice before looking at any agility reductions. I might also lower the RP costs for the power boosts to give early AMMs some help.
Fixing the AMM imbalance might be acheived by removing Missile Agility entirely. The increasing engine power at higher tech levels should keep missile hit chances versus ships reasonable, but missile v missile numbers would drop considerably. It also has the added benefit of no longer needing an Excel sheet or Python program to calculate (efficient) new missile designs.
Removing it might be too drastic. It also no longer gives any options to build anti-fighter/anti-FAC missiles.Fixing the AMM imbalance might be acheived by removing Missile Agility entirely. The increasing engine power at higher tech levels should keep missile hit chances versus ships reasonable, but missile v missile numbers would drop considerably. It also has the added benefit of no longer needing an Excel sheet or Python program to calculate (efficient) new missile designs.
Yes, I think might be the simplest answer, plus probably making engine boost modifiers cheaper or maybe even free to improve low-level AMMs.
Fixing the AMM imbalance might be acheived by removing Missile Agility entirely. The increasing engine power at higher tech levels should keep missile hit chances versus ships reasonable, but missile v missile numbers would drop considerably. It also has the added benefit of no longer needing an Excel sheet or Python program to calculate (efficient) new missile designs.
Yes, I think might be the simplest answer, plus probably making engine boost modifiers cheaper or maybe even free to improve low-level AMMs.
There are other factors as well. You have to build and distribute the AMMs, which is a major factor in campaigns and a downside to AMMs. On the other hand, they can engage at much longer ranges than beam weapons, so you have multiple AMMs attempts vs usually a single beam attempt, although that itself is affected by technology and design decisions re sensors, so you can't make single shot comparisons. On that basis, giving low tech AMMs extra capability beyond possibly cheaper (in research terms) engine boosts is not necessarily a good idea.
Also, with the changes in active and passive detection of fighters, reducing the ability to kill fighters with cheap missiles is probably fine.
In this situation, there are just so many competing factors, that you can't really calculate what is going to happen. You can make an educated guess (as per my gut feel that reducing or eliminating agility is probably the way to go), but it is usually easier to test and see what happens.
I'm not sure how the sensor changes hurt fighters, since the small low-res fighter sensors now are much closer in range to the large high-res sensors on a large ship.
And against missile fighters, beams on large ships are not an option. I for one would like to keep the possibility of specializing the missile against fighters instead of having one capital standard missile that is getting chucked at everything that is not a missile.
There are other factors as well. You have to build and distribute the AMMs, which is a major factor in campaigns and a downside to AMMs. On the other hand, they can engage at much longer ranges than beam weapons, so you have multiple AMMs attempts vs usually a single beam attempt, although that itself is affected by technology and design decisions re sensors, so you can't make single shot comparisons. On that basis, giving low tech AMMs extra capability beyond possibly cheaper (in research terms) engine boosts is not necessarily a good idea.
Also, with the changes in active and passive detection of fighters, reducing the ability to kill fighters with cheap missiles is probably fine.
In this situation, there are just so many competing factors, that you can't really calculate what is going to happen. You can make an educated guess (as per my gut feel that reducing or eliminating agility is probably the way to go), but it is usually easier to test and see what happens.
Steve, as a side request, is it possible for you to share a few missile design screens from C#? Any missile would be fine, preferably with different design parameters so I can check if my missile calculator is correct/accurate.
There are other factors as well. You have to build and distribute the AMMs, which is a major factor in campaigns and a downside to AMMs. On the other hand, they can engage at much longer ranges than beam weapons, so you have multiple AMMs attempts vs usually a single beam attempt, although that itself is affected by technology and design decisions re sensors, so you can't make single shot comparisons. On that basis, giving low tech AMMs extra capability beyond possibly cheaper (in research terms) engine boosts is not necessarily a good idea.
Also, with the changes in active and passive detection of fighters, reducing the ability to kill fighters with cheap missiles is probably fine.
In this situation, there are just so many competing factors, that you can't really calculate what is going to happen. You can make an educated guess (as per my gut feel that reducing or eliminating agility is probably the way to go), but it is usually easier to test and see what happens.
Steve, as a side request, is it possible for you to share a few missile design screens from C#? Any missile would be fine, preferably with different design parameters so I can check if my missile calculator is correct/accurate.
http://aurora2.pentarch.org/index.php?topic=8495.msg102804#msg102804
I highly recommend reading through the changes thread as it contains a lot of information about C#, including several different missile-related posts.
The missile calculator I was talking about had been verified based on the 2 engine parameters in the change log. If possible, I would like to verify the whole missile parameters (speed/range/accuracy and so on), so I can make sure my understanding/interpretation of the changes is correct.
I'm not sure how the sensor changes hurt fighters, since the small low-res fighter sensors now are much closer in range to the large high-res sensors on a large ship.
I'm not sure how the sensor changes hurt fighters, since the small low-res fighter sensors now are much closer in range to the large high-res sensors on a large ship.
Hey Steve, coming w/ another bug. I love the Fleet Organization screen, but it has a tendency to just disappear whole Task Forces. I've had 28 ships and 300 fighters all vanish from me trying to organize ships. I've found it to happen most often when working with carriers/nested ships. Most commonly when organizing fighters inside of a carrier into different groups while a carrier is in another group. Is it possible to get that fixed?
Hey Steve, coming w/ another bug. I love the Fleet Organization screen, but it has a tendency to just disappear whole Task Forces. I've had 28 ships and 300 fighters all vanish from me trying to organize ships. I've found it to happen most often when working with carriers/nested ships. Most commonly when organizing fighters inside of a carrier into different groups while a carrier is in another group. Is it possible to get that fixed?
Fleet Organization is completely different now so any bugs should have vanished. It is all explained in the changes log.
Have you tested it w/ fighters yet? I.e. if I have ships docked inside another ship, and I put the nested ships in a group that the mothership isn't in, and, say, detach the subfleet with the nested ships, what happens? In VB6 it tends to just delete everything.
Have you tested it w/ fighters yet? I.e. if I have ships docked inside another ship, and I put the nested ships in a group that the mothership isn't in, and, say, detach the subfleet with the nested ships, what happens? In VB6 it tends to just delete everything.
It is highly unlikely that the exact same bug would appear in a completely new and different piece of code.
Suggestion based on the new screenshots for your new test-game Steve:
on the "Class Design Screen" (and all screens like it) : new order of the check-boxes on the right side (collier, tanker, obsolete etc) to
sorted by function (Collier, Supply Ship, Tanker etc) - 1 row space - sorted by feature (consript, no armor etc) - 1 row space - sorted by display (Obsolute, Size in tonns etc)
that would make it a small QoL improvement as it would be easier to see if something is not checked which should be checked...
If possible, I'd like a way to remove ship hull classes. There was a natural bloat in VB Aurora from campaigns, both yours, Steve, and every individual player's, over time, and I found it to get slowly annoying if I would change ship classification scheme or abbreviation method from one campaign to the next to have it all cluttered up. Even worse, if I typoed the addition of a hull class, that mistake would haunt me in perpetuity - at least until I downloaded a fresh database.
I understand that at least part of the reason why we couldn't before was because NPRs need certain classes to function and you didn't want to deal with people deleting them and then complaining their games didn't work. That's completely understandable, and if it's still the case, could we at least get the ability to hide selected hull classification types from the player so they don't show up in the ship building menu?
Thanks.
If possible, I'd like a way to remove ship hull classes. There was a natural bloat in VB Aurora from campaigns, both yours, Steve, and every individual player's, over time, and I found it to get slowly annoying if I would change ship classification scheme or abbreviation method from one campaign to the next to have it all cluttered up. Even worse, if I typoed the addition of a hull class, that mistake would haunt me in perpetuity - at least until I downloaded a fresh database.
I understand that at least part of the reason why we couldn't before was because NPRs need certain classes to function and you didn't want to deal with people deleting them and then complaining their games didn't work. That's completely understandable, and if it's still the case, could we at least get the ability to hide selected hull classification types from the player so they don't show up in the ship building menu?
Thanks.
This is more a suggestion for a later release date, but could there be the option to put space stations and ships into orbit around a star or planet so they revolve around it?
An option to 'Create Home System' would be easy, as the NPRs already have that function. Yes, there are a number of fixed starting systems in VB6 for NPRs created at game start. That doesn't exist in C# - everything is created from scratch. It only take a second or two to generate and discard all the unsuitable systems until a suitable home system is generated. Every NPR starting system is unique.
An option to 'Create Home System' would be easy, as the NPRs already have that function. Yes, there are a number of fixed starting systems in VB6 for NPRs created at game start. That doesn't exist in C# - everything is created from scratch. It only take a second or two to generate and discard all the unsuitable systems until a suitable home system is generated. Every NPR starting system is unique.
A possibly simple addition to a 'Create Home System' function would be to allow the player to set some criteria and then generate and discard systems until one that meets the criteria is found. Possible simple criteria might be:
- Min/Max stars
- Min/Max planets
- Min/Max moons
- Min/Max asteroids
- Min/Max asteroid belts
- Min potential homeworlds (acceptable gravity and base temperature; atmospheric adjustments can be made by the player)
- Min/Max distance to furthest system body
This way, if wanting to do something like a multi-faction multi-planet start in a large complex system, you could easily generate systems with the desired number of homeworlds and some larger minimums to ensure a big complex system. An option to abort in case the criteria are too strict and it just keeps running without a match would be good, or even an auto-fail after some (large, I assume it will go pretty fast) number of tries.
More complex criteria would be like min. potential homeworlds around a single gas giant, min. stars w/ at least 1 homeworld orbiting (to create a binary system with a homeworld around each component), or optional tighter homeworld criteria (like for a particular species if you want multiple homeworlds for human factions, not just good enough to generate a species that matches the homeworld). I'm sure I and others could think of many criteria, but even a fairly basic set would be useful.
it isn't easy to do what you suggest. The system generation uses a lot of science to create 'realistic' systems, including separation of planets, limits to where they can form, types of worlds likely at certain distance, etc. so you can't simply choose how many home worlds you want for example. These are an early form of the rules I use for Aurora's system generation (I can't find the latest version online anywhere). It took about a year to code this for the VB6 version (a lot faster in C#).
http://sol.trisen.com/downloads/wg.pdf
it isn't easy to do what you suggest. The system generation uses a lot of science to create 'realistic' systems, including separation of planets, limits to where they can form, types of worlds likely at certain distance, etc. so you can't simply choose how many home worlds you want for example. These are an early form of the rules I use for Aurora's system generation (I can't find the latest version online anywhere). It took about a year to code this for the VB6 version (a lot faster in C#).
http://sol.trisen.com/downloads/wg.pdf
http://sol.trisen.com/downloads/wg.pdf
wow, that is such an awesome document, thank you
b) when i modified the name, i'd prefer aurora to keep the name even if i modify the specs afterwards; maybe an additional button "autogenerate" which gets enabled/disabled by the same flag storing the "customized name" state could be added for that^ This, so much this.
c) for autogenerating names, i'd love to be able to modify the naming convention; for example, i didn't much care for the power need on energy weapons, but the recharge time instead.
d) when designing ships (and at many other places relevant to combat), the component names column was too small, and the relevant information wasn't visible (especially when it came to fire controls and sensors, it got tricky to distinguish between the point defense systems and the anti-ship/long range systems produced by the same company)
. . . If we had that, naming schemes other than stock which involve one or more criteria from the design become painless to utilise, rather than an effort to remain consistent with theme/past designs due to having to manually edit the name for every design you ever make, patterned or not.
Will planetary sensor stations still be available in C#? If so, I would suggest to remove them. Having a building that essentially can give you "unlimited" passive sensor range goes contrary to the reduced ranges of the new sensor model, I think.
If I recall correctly, they are needed for an empire to be able to contact other races. I once created two races on one planet without having sensors buildings - and they couldn't see each other - so no communication. Maybe then repurposing this building into a "central radio antenna system". You have to have it once in a system to be able to communicate.
About the new "Genetically Enhanced Soldiers" I would suggest that they can only be chosen when a Genetic Modification Center is also on the planet/body.That seems unnecessary. The GMC is for mass conversion of entire civilian populations. A facility for small scale enhancements on a few thousand soldiers should be possible to fit within a GFTF.
Something else to consider is allowing players to apply subspecies mods to their ground forces, and have colony cost modify their HP (or supply/maintenance consumption). That way you could play gene tweaking as being pioneered in order to harden soldiers against extreme cold or low gravity operational environments, and then rolled out for general civilian deployment in colonist communities.While the extra possibilities of that are appealing, at the same time I'd worry about the extra complexity. I mean ground combat is already getting a lot more complicated, it would be easy to get carried away and go too far.
Something else to consider is allowing players to apply subspecies mods to their ground forces, and have colony cost modify their HP (or supply/maintenance consumption). That way you could play gene tweaking as being pioneered in order to harden soldiers against extreme cold or low gravity operational environments, and then rolled out for general civilian deployment in colonist communities.While the extra possibilities of that are appealing, at the same time I'd worry about the extra complexity. I mean ground combat is already getting a lot more complicated, it would be easy to get carried away and go too far.
If you wanted to add more genetics/biology options then I'd prefer to see something else. How about "advanced medicine" research that reduced the chance of serious illness/death events for leaders?
Or even biological warfare? W40k is full of viral bombing of planets. Hard to get the balance right. Perhaps a weapon that kills a % of the population but that had be deployed on the ground as a unit weapon rather than from a missile? Then you'd need to at least force a landing, rather than just nuke from space. I'd assume the % starts small and then increases for each extra research level.
The follow up questions would be whether soldiers are also killed, or do we assume them to have sealed battle suits anyway? And would you also create a tech line to reduce the impact? Maybe a "Viral containment unit" vehicle component so that we can have unmarked trucks full of haz-mat suited scientists and soldiers "cleaning up" infected areas.
I've been considering biological/chemical warfare for a long time and I will add it as an option at some point, including suitable installations, ship modules, etc.. The agent would have incubation, infection and mortality rates that would vary by species and could alter (or jump species) through mutation. You would need living examples of species for the best understanding and/or effectiveness. I would track infection on population, ships, etc. as there might be infections that are not immediately apparent.
CIF3 missile warheads sound like fun, melting the opponents crew members if it punches through the hull.
Maybe something to support boarding attempts?
On the subject of biologicals, please don't give the Swarm acid spit or bone guns.
CIF3 missile warheads sound like fun, melting the opponents crew members if it punches through the hull.
Maybe something to support boarding attempts?
The USA once spilled a ton or so of ClF3 while loading it for transport.
It ate the storage tank.
It ate the 1 foot thick concrete floor.
It ate the 1 foot thick layer of gravel beneath the 1 foot thick concrete floor.
It ate another 3 feet or so of dirt beneath the 1 foot thick layer of gravel below the 1 foot thick concrete floor.
The problem with ClF3 is that it's so aggressive that the only thing it won't react with is the fluorine salts of some of the structural metals, like copper and iron. You can make a layer of such salts by carefully exposing the metal to ClF3 fumes, which lets you transport it, but it comes with the disadvantage that if it's scratched off while in contact with ClF3? That's not a careful exposure, it will react, violently, and cause it to melt, exposing more of the metal as the metal-fluorine fire continues and containment failure is certain and imminent.
And having that happen in your ship might actually be more dangerous than a magazine explosion.
I'm not a chemist but wouldn't it be possible to split it into less dangerous components and store them separately?
Just add a mechanism to the warhead to mix the components on impact.
I'm not a chemist but wouldn't it be possible to split it into less dangerous components and store them separately?
Just add a mechanism to the warhead to mix the components on impact.
I'm a chemist and its components (Cl2 and F2) are also dangerous (though not as much). Additionally, the reaction to create it is likely too slow for an actual bomb, it requires heating the gasses to a high temperature for a long time and as such an impact would only produce a small amount in the time it takes for it too cool down, not to mention the gasses escaping away immediately after impact
The problem with Chemical & Biological warfare is that it starts creeping back into "kill 'em all and move in tomorrow" territory. I think the assumption about B&C is that it kills enemy populations & ground units, but does not harm installations. In that case, it needs sufficient downside (perhaps in the chance of rendering the entire planet uninhabitable, or covered in "grey goo," or creating Resident Evil-style enhanced monsters).
Brandon Sanderson to write 1. 0
Given that Steve has now dealt with the missile - fighter - ship fuel consumption consistency point I was wondering if a similar exercise could be done for fire controls so we don't have the arbitrary 4x tracking bonus for a fighter in an effort to get something to actually fit within a 500 ton limit. The fighters are using the same ship borne weapons so why have a different rule set for them?
Personally I think fire controls are currently way too large in any case and could do with being shrunk to a fraction of their starting size (from some very brief looks at Wikipedia I can see the old Mk 1 Computer that the US used weighed in at a portly 1.3 tons and subsequent systems that were not mechanical in nature got a lot smaller than that). It also strikes me as odd that I can happily build fighters with MFCs that are a fraction of 50 tons and work very well.
If taking a starting 1x range, 1x tracking to 5 tons and going from there sends shivers down the spine perhaps an alternative would be allow for smaller more expensive fire controls and then large cheaper versions as a way to keep consistent but then practically useable. The small fire control would also be a nice buff to energy weapon combatants.
Something I have pondered for a while is pressing civilian shipyards into military production during wartime perhaps should be a thing.
TOO (really too..) many questions..possibility and capability.
THIS is a "One-man-program" u r all crazy by submit overwhelming requests.
Since 2016 "C# project" began..NOW its 2019.
Wtf all wanna?
Am desire 1 thing : play. End.
Steve, don't get hit by a bus, or something similar, please!
Quote from: Sirce link=topic=9841. msg112278#msg112278 date=1548122862Steve, don't get hit by a bus, or something similar, please!
Best suggestion so far, should be on top of the C# priority list ;D
Why not combine the "resupply" order with the "refuel" order? Usually the two things are done at the same place. And if not, attempting to do both at the same place (fuel dump) won't cause any harm, just result in an "insufficient supplies" issue. It just cuts down on the micromanagement.
I'll just show myself out. Door's still over there, same as last time, yes? ;)Why not combine the "resupply" order with the "refuel" order? Usually the two things are done at the same place. And if not, attempting to do both at the same place (fuel dump) won't cause any harm, just result in an "insufficient supplies" issue. It just cuts down on the micromanagement.
http://aurora2.pentarch.org/index.php?topic=8495.msg109597#msg109597
Hi Steve. Don't know if you ever adresses this. Would you think, something of that kind would be possible to realize?To simplify managing bigger empires having civilian trade also transport minerals would be an ideal addition. Maybe in terms of using the "mineral limit" values as a measurement of automating those orders. If on a colony the mineral amount is lower than the minimum this generates a demand for this mineral and the civilians take a look around which planets do have that mineral in abundance (maybe two or three times over the minimum value) and transport that to the target planet.
If we go down that route, I think it would be ideal to have a way to specify which planets/colonies civilian freighters are allowed to consider when they're looking for where to acquire minerals, and maybe even the ability to designate which minerals they're allowed to take from which planets/colonies.
would it be possible to have civilian troop transports/a way to contract the shipping lines to move troops around various garrisons?
Also, quick question Steve, do STOs make orbital defence stations irrelevant ? Since they're hidden unless they fire and apparently possess quite a fair amount of fire power, is there any real insensitive to build them besides having missile launch capability?
Also, quick question Steve, do STOs make orbital defence stations irrelevant ? Since they're hidden unless they fire and apparently possess quite a fair amount of fire power, is there any real insensitive to build them besides having missile launch capability?
AMM stations will still be needed. They could be protected by ground-based PD, but I think a combination of ground and space-based PD will still be useful.
AMM stations will still be needed. They could be protected by ground-based PD, but I think a combination of ground and space-based PD will still be useful.
AMM stations will still be needed. They could be protected by ground-based PD, but I think a combination of ground and space-based PD will still be useful.
I can see how Space based PD could become useful in case you have either:
1.) A logistical situation that is better suited for it ( lots of tugs or hangar space to haul them around but a shortage of transports for ground units ).
2.) A production situation that is better suited for it ( minerals or factories to build them in surplus but a shortage of minerals or ground unit training ).
Wait, I thought factories could only be used to build civilian space stations in C# Aurora.
e.g. showing that there are 1200 tons of Duranium being harvested annually, but 2500 being used up anually.But there is no fixed annual consumption. If you add or remove something from the production queues, the projected consumption will change. If you increase industry somewhere, the projected consumption will change. The production queues can take years or decades to finish. Mineral accessibility can change. So the projections would easily fluctuate and need to be recalculated every production cycle. But maybe C# is so much faster than VB6 that the production cycles would still fly past.
Please no, the combat model in HoI4 is terrible for actually simulating warfare. I was a betatester for HoI2, I've sunk hundreds of hours into HoI3 (as well as HoI1 and HoI2) and I followed closely the development of HoI4 and tried it out. The planetary combat system Steve currently has is pretty good for its intended purpose and cloning any of the HoI combat models wouldn't improve it.e.g. showing that there are 1200 tons of Duranium being harvested annually, but 2500 being used up anually.But there is no fixed annual consumption. If you add or remove something from the production queues, the projected consumption will change. If you increase industry somewhere, the projected consumption will change. The production queues can take years or decades to finish. Mineral accessibility can change. So the projections would easily fluctuate and need to be recalculated every production cycle. But maybe C# is so much faster than VB6 that the production cycles would still fly past.
would it be possible to have civilian troop transports/a way to contract the shipping lines to move troops around various garrisons?
I think the transition of troop bays from military systems to commercial ones should already cover those kind of issues pretty well. After all you won't need to overhaul or maintain your slow, lumbering standard troop transports that move your garrisons around.
In general I agree that perhaps the time has come to do away with automines?
Sure its realistic, but so is auto-everything. Its frankly kindof fun to have a population associated with your labor in a sci fi universe, and maybe extraction of smaller deposits could be taken over by large mining ships instead?
i also RP and imagine that DST, CMC, and automines have small number of personnel associated with them something in the range of 25~80 people, well below the scale of a population center. like a DEW radar station for DSTs and an oil rig like setup for the mines.
i also RP and imagine that DST, CMC, and automines have small number of personnel associated with them something in the range of 25~80 people, well below the scale of a population center. like a DEW radar station for DSTs and an oil rig like setup for the mines.
Yes, this is my assumption as well.
http://aurora2.pentarch.org/index.php?topic=8495.msg110522#msg110522
Thanks, oh, and by the way you should update that post with the new workers requirements for shipyards.
Thanks, oh, and by the way you should update that post with the new workers requirements for shipyards.
Yes, good point. I will sort that.
If this goes on you're going to end up spending more time correcting previous statements than actually implementing new features XD.
A centralized wiki would probably be a better long term idea though (wasn't somebody working on that ?) But for now the change list is still a gold mine of information. By the way, ever had the time to test if the NPR actually properly made and managed it's fleets in your test campaign ? That's one thing that I've been very curious about, especially how they handle a prolonged war with that system.
A centralized wiki would probably be a better long term idea though (wasn't somebody working on that ?) But for now the change list is still a gold mine of information. By the way, ever had the time to test if the NPR actually properly made and managed it's fleets in your test campaign ? That's one thing that I've been very curious about, especially how they handle a prolonged war with that system.
http://aurorawiki.pentarch.org/index.php?title=Aurora_C
By the way, ever had the time to test if the NPR actually properly made and managed it's fleets in your test campaign ? That's one thing that I've been very curious about, especially how they handle a prolonged war with that system.
The NPR did manage its fleets well, including creating new operational groups with the correct mix of ships and building ships to fill gaps. It's combat I need to test now.
I'd like to see a General Quarters type setting for fleets/ships. This would reduce the amount of time to execute orders as the crew is ready for action. Ships could not maintain GQ for extended periods of time (more than 8 hours for example).This could include a morale penalty building up over time, with a cooldown period (and effectiveness penalty) while the crew rests. Crew training level could increase the benefits while reducing the penalties. Maybe consume crew deployment time faster while active?
. . . The simplest approach would be for each company to limit production based on the number of idle ships of each type, weighted to prefer types with fewer idlers.
There are two problems with that method:. . . The simplest approach would be for each company to limit production based on the number of idle ships of each type, weighted to prefer types with fewer idlers.
A better approach would be for each compan to build only one type of civilian craft (freighter, colony, fuel harvester, etc.). That way, companies with types with a higher demand will earn more money and build more ships. Self-regulating.
A better approach would be for each compan to build only one type of civilian craft (freighter, colony, fuel harvester, etc.). That way, companies with types with a higher demand will earn more money and build more ships. Self-regulating.
I'd like to see a General Quarters type setting for fleets/ships. This would reduce the amount of time to execute orders as the crew is ready for action. Ships could not maintain GQ for extended periods of time (more than 8 hours for example).
usage rate is a reasonable way to allocate between freight and colony, but liners are going to present some problems. they have zero idle time, ever, and while you're confined to one system (with very short transit times) their ROE is sky high. weight by usage or profit and you're going to wind up with a lot of liners and a lot of wealth production. which is actually *correct* given the economics of aurora, but amounts to an exploit since the economics are so underdeveloped.You have a solid point about Liners. They really should be limited by wealth and population. Rabid_Cog's Tourist trade good idea might work for that.
i imagine you'd see similar behavior vis a vis colony ships for players who use the infinite wealth earth-moon round trip exploit.
would it be so bad just to let the player decide which types of ships subsidy funds are spent on? make the "profits squandered" portion a bit higher, and call it a day? youd have to have the designs published before the first one is built, but among other things players can keep the population of small civ units down, which is good in a lot of ways.
the other approach is just an elaboration of StHM's one: you take the time to make sure you have shipping profits (in particular ROE) really right, and keep track of annual ROE by ship class. have newer (and larger!) designs assigned tasks preferentially, and where ROE is high you build new ships and where ROE is low you retire. this is a lot more work and i am not requesting you spend the time... but dare i say it is in the spirit of how aurora is developed and played? OCD is an ugly disease :)
How about:That's a really good idea and it would prevent the liners from shuttling 500 colonists around constantly while providing both an RP and an in-game mechanical reason for bringing in wealth, plus more traffic in a system.
New kind of trade good, "Tourists". Special in that Local production cannot satisfy local demand (so you can have both demand and supply on one planet) and requires a special module (liner berths) to transport.
There are two problems with that method:. . . The simplest approach would be for each company to limit production based on the number of idle ships of each type, weighted to prefer types with fewer idlers.
A better approach would be for each compan to build only one type of civilian craft (freighter, colony, fuel harvester, etc.). That way, companies with types with a higher demand will earn more money and build more ships. Self-regulating.
1) You need both freighters and colonizers in the early game (read: first year) when you only have one company.
2) Even if you limit to a single type per company, you will still overbuild since your idlers are still a percentage of your working ships.
What I'm proposing is closer to how real shipping companies operate, in that if they have idle assets, they don't build more. It also directly addresses the problem of idle civilian ships cluttering the game. And frankly, 5/type/company is probably too high.
It would make sense for tourists to be a trade good, but then why can't your regular freighters just stack them into cargo holds like cordwood and dump them off to any colony? :/Nothing. That's called 'economy class'.
Frankly, I'd be happier if no civilians at all were generated until one's empire had at least one 10 million pop offworld colony, but I lost that argument a long time ago.
Isn't that essentially already implemented? C# requires two populated colonies (including the capital) for freighters and colony ships to be built, and at least two populated systems for passenger liners. Or would the 10 million pop change it significantly?
Frankly, I'd be happier if no civilians at all were generated until one's empire had at least one 10 million pop offworld colony, but I lost that argument a long time ago.
Not even that. You only need to put down Infrastructure and the civilians will take care of the rest. I haven't built colony ships in years!Isn't that essentially already implemented? C# requires two populated colonies (including the capital) for freighters and colony ships to be built, and at least two populated systems for passenger liners. Or would the 10 million pop change it significantly?
Very significantly. At the moment, the instant the first colonist sets foot on "Moonbase 1" or wherever, the civilians start shipping colonists and free Infrastructure. As a result, an empire doesn't need lift capacity of its own; one small ship can do the job of creating "designated populations" wherever by dropping off 1 Infrastructure and 0.0001 million population and let the civilians do the rest.
And Aurora is balanced for that, both for resource usage and for micromanagement. There is still room for improvement, but it mostly works as is.Not even that. You only need to put down Infrastructure and the civilians will take care of the rest. I haven't built colony ships in years!Isn't that essentially already implemented? C# requires two populated colonies (including the capital) for freighters and colony ships to be built, and at least two populated systems for passenger liners. Or would the 10 million pop change it significantly?
Very significantly. At the moment, the instant the first colonist sets foot on "Moonbase 1" or wherever, the civilians start shipping colonists and free Infrastructure. As a result, an empire doesn't need lift capacity of its own; one small ship can do the job of creating "designated populations" wherever by dropping off 1 Infrastructure and 0.0001 million population and let the civilians do the rest.
Not even that. You only need to put down Infrastructure and the civilians will take care of the rest. I haven't built colony ships in years!Isn't that essentially already implemented? C# requires two populated colonies (including the capital) for freighters and colony ships to be built, and at least two populated systems for passenger liners. Or would the 10 million pop change it significantly?
Very significantly. At the moment, the instant the first colonist sets foot on "Moonbase 1" or wherever, the civilians start shipping colonists and free Infrastructure. As a result, an empire doesn't need lift capacity of its own; one small ship can do the job of creating "designated populations" wherever by dropping off 1 Infrastructure and 0.0001 million population and let the civilians do the rest.
Not even that. You only need to put down Infrastructure and the civilians will take care of the rest. I haven't built colony ships in years!Isn't that essentially already implemented? C# requires two populated colonies (including the capital) for freighters and colony ships to be built, and at least two populated systems for passenger liners. Or would the 10 million pop change it significantly?
Very significantly. At the moment, the instant the first colonist sets foot on "Moonbase 1" or wherever, the civilians start shipping colonists and free Infrastructure. As a result, an empire doesn't need lift capacity of its own; one small ship can do the job of creating "designated populations" wherever by dropping off 1 Infrastructure and 0.0001 million population and let the civilians do the rest.
C# Aurira will require a population, not just Infrastructure, at the destination to move colonists. However, it will also give us the ability to move 100 colonists instead of 10,000, so still massively easy to exploit.
IIRC, they will move low gravity infrastructure, but only to/from low gravity worlds, which is going to be 'fun' for your first LG colony, and I do believe it still counts as trade. But as you say, I'm just glad I don't have to pay for it. :)Not even that. You only need to put down Infrastructure and the civilians will take care of the rest. I haven't built colony ships in years!Isn't that essentially already implemented? C# requires two populated colonies (including the capital) for freighters and colony ships to be built, and at least two populated systems for passenger liners. Or would the 10 million pop change it significantly?
Very significantly. At the moment, the instant the first colonist sets foot on "Moonbase 1" or wherever, the civilians start shipping colonists and free Infrastructure. As a result, an empire doesn't need lift capacity of its own; one small ship can do the job of creating "designated populations" wherever by dropping off 1 Infrastructure and 0.0001 million population and let the civilians do the rest.
C# Aurira will require a population, not just Infrastructure, at the destination to move colonists. However, it will also give us the ability to move 100 colonists instead of 10,000, so still massively easy to exploit.
To be honest I don't think it is an exploit, it is a built in feature and something you want the civilians to do.... why should the state move these items and develop the colonies?!?
The state basically do the initial colonization and spend the upfront resources to do so the civilian economy take care of the rest.
As far as I know the civilians also only move regular infrastructure, if you need other types of infrastructure you need to move it on your own.
There is also a cost in having your civilians move infrastructure which is trade. I don't think you get much wealth if the civilians move infrastructure. At least it would make sense if that would be the case. Them moving the infrastructure is bonus enough in my opinion.
IIRC, they will move low gravity infrastructure, but only to/from low gravity worlds, which is going to be 'fun' for your first LG colony, and I do believe it still counts as trade. But as you say, I'm just glad I don't have to pay for it. :)
I may have misread (or misremembered) Steve's post on the matter, but it seemed that only low-grav worlds produce LGI.Quote from: SpikeTheHobbitMage link=topic=9841.msg112710#msg112710IIRC, they will move low gravity infrastructure, but only to/from low gravity worlds, which is going to be 'fun' for your first LG colony, and I do believe it still counts as trade. But as you say, I'm just glad I don't have to pay for it. :)
I really hope they only move LGI from acceptable-grav worlds, and only to Low-Grav worlds.
Or a lot of Alzairians are going to die.
I'm pretty sure that in VB6 civilians take infrastructure as a trade good and transform it into "actual" infrastructure at the destination, so that there isn't any loss on the source world. If it works the same for LGI in C#, there shouldn't be any issue of mass die-offs.Yes, that is exactly how it works. If you want installed infrastructure moved, you have to pay the shipping fees or move it yourself. On top of that, trade good infrastructure can't be converted in place. It must first be loaded onto a civilian freighter to become 'real'.
This is but a simple UI improvement suggestions.
1. Add a button to galactic map, which allows jumping straight to the currently selected system view.
2. In Task force UI, remove selecting Task forces from the dropbox(which I find greatly inconvenient, given number of various TFs you gather later in the game), and make a combo box with a full list on the left side of the TF window.
To be fair, the systems list in the system view could be similarly treated.
Quote from: procdrone link=topic=9841. msg112799#msg112799 date=1550116549This is but a simple UI improvement suggestions.
1. Add a button to galactic map, which allows jumping straight to the currently selected system view.
2. In Task force UI, remove selecting Task forces from the dropbox(which I find greatly inconvenient, given number of various TFs you gather later in the game), and make a combo box with a full list on the left side of the TF window.
To be fair, the systems list in the system view could be similarly treated.
1) You can double-click on systems (in VB6 too) to open the system view.
2) The fleet window is completely different in C# (check the changes or screenshots threads) and has a fleet hierarchy, not a dropdown.
Double clicking on a system in the galaxy view only brings up the "F9" (System Generation and Display), and not the System Map, the thing im suggesting.
Importing/exporting ships. They can only be added if the required technology was researched by that player or the player is in sm mode. There are a lot of designs I like in the design bureau but it's a bit inconvenient having to figure out what technology was used for it.that's a bit of a problem considering the research of components, I don't see a viable way to solve that.
Option to get get rid of the hull prefix on the name of individual ships? (i.e. gsv, gev).
Can we get two additional settings for Point Defence Modes?It does nothing the the player is not already capable of, saves the player a tedious task if they so choose, and would improve the AI's combat effectiveness as well as the player's by more efficiently spending their limited AMM stocks, letting gunnery take up some of the workload automatically.
Specifically minimum salvo count per increment, and a minimum salvo size.
Right now, if I setup a missile defence with say, (1v1 PD Mode 1270), then I literally spend one missile per inbound, even if there is just one inbound, and I have dozens of gauss turrets. I waste missiles, lose fights I should have won.
I could choose not to use the system at all, and manually fire on large/excess salvos so that the gauss defences can handle what remains. This is incredibly tedious and not fun, but effective and I survive larger/longer attacks.
Could we just take the tedium almost entirely out and allow specifying how many salvos must be incoming before the FC cares, or how many missiles must be in any given salvo?
If I had gauss turrets that reliably stop 9+ per salvo, and enough turrets to engage 8 salvos per increment, then I really only need missiles for salvos larger than 9, or more numerous than 8 for any given increment.
Its not OP, because nothing stops me from stacking an ungodly amount of gauss and running a single stack formation - I get missile immunity with no ammunition expenditure at all. Game the system with a very enticing civilian hull with an absurd amount of CIWS perhaps.
It just enables a more hands off approach to missile defence, letting the ships defend themselves with an efficiency closer to if you were fully hands on, minus the tedium.
A few other thoughts on the AMM piece:A round robin engagement pattern would smooth that out considerably, with the assumption that ships not ready to fire are skipped over by those who are. You'd still run dry in one ship before others, potentially much earlier if their designs aren't well suited to equal expenditure/endurance, but at least it wouldn't be one empty and others full, they'd all be depleted, and if they were the same class, very nearly all depleted together.
- I often find myself with groups of AMM ships where one two have fully expended all of their ammo whilst others in the fleet have full mags which I assume is due to some ships always selected as firing first. This isn't much of an issue in VB6 because of instant ordnance transfer but I can see it becoming a real bug in C#. If the firing order could just be switched to whichever ship has the fullest magazines I think that would go a long way to help.
- On wasted AMMs I think I have mentioned before that having a minimum engagement range for AMMs as well as the current maximum would again help with using layered missile and PD fire.
And what if I want one ship to empty its magazines first, so that it can be detached and sent back for resupply, instead of all AMM escorts running dry at the same time?
How would one ship know that it has more missiles left than another ship?They wouldn't.
Do the ship computers talk to each other automatically or does it require the crew to communicate such decisions? Could networked combat groups be a new research tech and ship module?It would essentially be crew/computers handling it as far as the lore goes. From a programming perspective, if it were me, it'd be the taskgroup object that handles the taskings, rather than ships trying to work it out amongst themselves.
And what if I want one ship to empty its magazines first, so that it can be detached and sent back for resupply, instead of all AMM escorts running dry at the same time?The priority queue has you covered.
The problem is, how much space does this take? If you take all the TN minerals that comprise a 500 ton ship, it weights far less than 500 tons.
As stated above, the components to build a fighter must weigh at least as much as the fighter.
For ships in real life, displacement equals weight. The water a ship displaces weighs as much as the ship. I don't see any reason for this to not be true in Aurora.The problem is, how much space does this take? If you take all the TN minerals that comprise a 500 ton ship, it weights far less than 500 tons.As stated above, the components to build a fighter must weigh at least as much as the fighter.
Incorrect. Aurora ships are measured by displacement, not by mass. A "500 ton fighter" is 500 tons because it displaces 500 "tons" of Luminiferous AEther.
Whether the Trans-Newtonian Elements are all there is to an Aurora unit, or if it also includes conventional materials (and if so, how much) is left to the individual player's fiction.
None of which is an argument for or against a space-based module for small craft (and/or munitions) production. I remember when gate constructors needed five standard-cargo-hold-sized components to build a jump gate, and the myriad problems that caused due to failed delivery, interrupted production, and disappearing components. About the only JGCSs that functioned reliably were those built with five internal cargo holds and which 'reloaded' their jump gate components at a proper colony after each build.
Would "portable" small craft and/or munitions production be fun? Probably. People seemed to like the Machine Shops in Starfire. Would they add signifcant gameplay decisions? Maybe. If they were 100% as efficient as a ground installation at production -- especially if they could manufacture while moving -- they'd be overpowered, even though they'd require significant organizational overhead in terms of delivering (or holding) raw materials. I'm pretty sure you'd want significant cargo hold capacity on each such unit.
I think such units should be limited to manufacturing out of their own, on-board cargo holds, requiring significant cargo-handling operations to feed. I don't want to drown the idea in micromanagement, but having just instituted a series a rule changes to fix 'instant reload' and 'instant fuel transfers' and such, it seems a foolish gap to allow full-on production out of an adjacent cargo freighter.
For ships in real life, displacement equals weight. The water a ship displaces weighs as much as the ship. I don't see any reason for this to not be true in Aurora.
For ships in real life, displacement equals weight. The water a ship displaces weighs as much as the ship. I don't see any reason for this to not be true in Aurora.The problem is, how much space does this take? If you take all the TN minerals that comprise a 500 ton ship, it weights far less than 500 tons.As stated above, the components to build a fighter must weigh at least as much as the fighter.
Incorrect. Aurora ships are measured by displacement, not by mass. A "500 ton fighter" is 500 tons because it displaces 500 "tons" of Luminiferous AEther.
Whether the Trans-Newtonian Elements are all there is to an Aurora unit, or if it also includes conventional materials (and if so, how much) is left to the individual player's fiction.
None of which is an argument for or against a space-based module for small craft (and/or munitions) production. I remember when gate constructors needed five standard-cargo-hold-sized components to build a jump gate, and the myriad problems that caused due to failed delivery, interrupted production, and disappearing components. About the only JGCSs that functioned reliably were those built with five internal cargo holds and which 'reloaded' their jump gate components at a proper colony after each build.
Would "portable" small craft and/or munitions production be fun? Probably. People seemed to like the Machine Shops in Starfire. Would they add signifcant gameplay decisions? Maybe. If they were 100% as efficient as a ground installation at production -- especially if they could manufacture while moving -- they'd be overpowered, even though they'd require significant organizational overhead in terms of delivering (or holding) raw materials. I'm pretty sure you'd want significant cargo hold capacity on each such unit.
I think such units should be limited to manufacturing out of their own, on-board cargo holds, requiring significant cargo-handling operations to feed. I don't want to drown the idea in micromanagement, but having just instituted a series a rule changes to fix 'instant reload' and 'instant fuel transfers' and such, it seems a foolish gap to allow full-on production out of an adjacent cargo freighter.
What would we be building fighters out of? TN minerals is an option, but would require either a new, smaller cargo hold or keeping a freighter with the fleet.
The problem is, how much space does this take? If you take all the TN minerals that comprise a 500 ton ship, it weights far less than 500 tons. The logical conclusion is therefore, that while we only consider the TN minerals in the cost of ship construction, the remaining ship mass is taken up by conventional metals that are abstracted away. On a planet that abstraction works, but on a starship? Where do those metals come from?
Alternatively, it can be built out of "fighter parts", a new maintenance parts-like object. These would have to be built on planet and shipped, same as a fighter. At which point, what is the real gain? Slightly increased storage efficiency at best since you need space to store the parts and space for the assembly module, and all that space could have been devoted to having a larger fighter complement ready to fly.
The real problem that I can see, however, is that if it becomes viable to construct/assemble fighters in space... why would it not be viable to construct/assemble missiles in space? And that is a far greater logistical change than building fighters in space.
One thing to keep in mind is that making something into a ship module is equivalent to creating an automated version with zero workforce requirement. For fuel refining and orbital mining modules there are particular restrictions on the bodies they can target, but you see it clearly with the terraforming and maintenance modules and VB6 construction brigades. Creating automated fighter factories may or may not be desired behavior.
Shipyards should probably remain planet locked, but a fighter factory module could be an interesting way of adding deep space production capabilities.I would perhaps think the other way. Make shipyards be able to function next to a deep space station which provides TN materials and workforce for it to perform shipbuilding. Thinking of "Deep Space Black Ops construction sites" ;-)
Perhaps a tech that limit the size of the shipyard? There's potential there. But a big problem would be balancing it so that population isn't made completely irrelevant. Shipyards are, at least in my games, the largest section of workforce a lot of the time. Perhaps the ability to house population on stations and keeping the pop requirements.
Terraforming small worlds seems like it would be too easy.
Consider the following: If there is 20% of the gravity, then the air will weigh 80% less and you will need 5x as much air in order to build up a certain level of pressure on the planet (assuming you dont go full gas giant and add enough air to significantly change the gravity of the planet).
This would make terraforming tiny worlds more realistic, in that it should probably be an exceedingly difficult thing to do.
So, divide the terraforming time by the surface gravity. 10 years / 20% surface gravity (0.2) = 50 years.
e: Fiddling with the math, assuming constant planet density the divide-by-surface-gravity balancing approach would result in a very nearly flat rate terraforming cost. Minding that in reality smaller planets are generally much lower density than larger planets which would probably cause them to spike massively in terraforming cost because lower density = higher radius = lower surface gravity = longer terraforming time if the suggestion is implemented.
graph (x axis is mass, y axis is terraforming time): https://www.desmos.com/calculator/hepyghpcyh
Additionally, it might be fun if you needed to keep some number of terraformers on the planet in order to keep it terraformed. This would raise the cost in that you can't really re-use infrastructure for that purpose. I don't have a specific idea of how to balance that one.
3 is OK, but your formula is off. While the required atmosphere mass will scale with the surface area, it will be inversely proportional to the surface gravity of the planet. On a lower-gravity world, you need more stuff above you to get a given pressure. The surface gravity is proportional to both density and radius, so if each terraformer produces a constant mass of atmosphere, you'll see the yearly atmosphere production proportional to density and inversely proportional to radius.
The gory math behind this can be found at http://aurora2.pentarch.org/index.php?topic=8107.msg91559#msg91559 (http://aurora2.pentarch.org/index.php?topic=8107.msg91559#msg91559)
The referenced link has a lot of the back and forth.
The short version: Assuming constant density, a lot of the other observables of a body are dependent on the radius. Putting all those in, the time should go like R ~ Mass^(1/3), BUT in terms of Aurora this is easier to think about as Area/surface gravity. In addition (as I just realized) if you think in terms of Area/surface gravity the density should drop out (because these are the direct observables that determine the total mass of air required to create the desired pressure) so you don't need the constant density assumption.
So I'm hoping that your plot is simply Y = constant*X^(1/3) - if you expressed it in terms of radius rather than mass you'd get linear behavior. The other thing in the thread that's important is that there's a selection effect for ~1 G planets - we won't want to terraform a 10G planet, so the surface gravity bit should be fairly (within an order of magnitude or two) uniform across interesting planets.
So if I am reading this correctly, small planets wouldn't be much easier to terraform than large ones. The moon has 7.4% of the surface area of Earth and about 17% of the gravity, so it would be 7.4% / 17% = 44% of Earth terraform time.
TBH I think I prefer having a faster terraform time for the small bodies, as most of them lack both atmosphere and water, which will be a significant task, plus they have a smaller capacity. I will play for a while with the updated rate and then make a decision.
In their present iteration, tractor beams, for all their potential, are rather .... underwhelming. You have a single 500 ton module that, attached to a ship, let's you drag around exactly one entity of arbitrary mass, with no room for building space!trains, or for using stuff like drop tanks or external launchers.
[SNIP]
Thoughts?
Or even better, power down any engine not needed to maintain vessel speed, in order of highest to lowest fuel consumption per EPH. This would allow for multiple engine types to be fitted on the same vessel, which has always seemed like a strange and artificial limit, given that most real-world vessel classes have main and aux engine of different design (sometimes even from different engine manufacturers).
Or even better, power down any engine not needed to maintain vessel speed, in order of highest to lowest fuel consumption per EPH. This would allow for multiple engine types to be fitted on the same vessel, which has always seemed like a strange and artificial limit, given that most real-world vessel classes have main and aux engine of different design (sometimes even from different engine manufacturers).
Engines only consume fuel for the current speed, not their max speed. This is true for both VB6 and C#.
Or even better, power down any engine not needed to maintain vessel speed, in order of highest to lowest fuel consumption per EPH. This would allow for multiple engine types to be fitted on the same vessel, which has always seemed like a strange and artificial limit, given that most real-world vessel classes have main and aux engine of different design (sometimes even from different engine manufacturers).
Engines only consume fuel for the current speed, not their max speed. This is true for both VB6 and C#.
But I think the suggestion was that you could potentially have two different engines on one ship and then the ability to choose if you just want to use one of them or both at the same time. This could be interesting for role-play purposes even if the AI would never use it.
You would fit one engine with a decent fuel to power ratio and one fuel guzzling engine with more power to use only when you really need it.
This is a common way to use engines in real life as well.
This is actually kind of an interesting idea, in that it would allow for ships to have both "cruising" and "combat" speeds, at an enormous increase in fuel use (particularly useful if I wanted, say, a long range cruiser squadron to escort my survey ships). However, it's also a pretty major change, and since movement and fuel use is clearly already coded it might be something better tossed out as a potential future feature.
This is actually kind of an interesting idea, in that it would allow for ships to have both "cruising" and "combat" speeds, at an enormous increase in fuel use (particularly useful if I wanted, say, a long range cruiser squadron to escort my survey ships). However, it's also a pretty major change, and since movement and fuel use is clearly already coded it might be something better tossed out as a potential future feature.
It would be a major change, given how much balance is involved in this area. Fuel consumption has to be matched against fuel production in order to create interesting decisions. If fuel is too plentiful, it is too easy and if fuel is too scarce, it would be frustrating.
If I did this at some point, then rather than mounting two or more types of engines it would probably be better to have a fuel efficiency curve built into each engine design, perhaps based on the max boost. As you increase speed, the fuel consumption per point of power rises. Having a higher max boost would lift the entire curve. This is a more real-world situation. To maintain decision-making, the top speeds would have to have higher consumption than at the moment and would probably be reserved for combat situations.
The downside is a more UI, more complexity (including for the AI) and more difficulty for the player in comprehending the potential ranges of his ships at different speeds. The question is whether the game play benefit of having cruising speed is worth the complexity.
If I did this at some point, then rather than mounting two or more types of engines it would probably be better to have a fuel efficiency curve built into each engine design, perhaps based on the max boost. As you increase speed, the fuel consumption per point of power rises. Having a higher max boost would lift the entire curve. This is a more real-world situation. To maintain decision-making, the top speeds would have to have higher consumption than at the moment and would probably be reserved for combat situations.
The downside is a more UI, more complexity (including for the AI) and more difficulty for the player in comprehending the potential ranges of his ships at different speeds. The question is whether the game play benefit of having cruising speed is worth the complexity.
This is actually kind of an interesting idea, in that it would allow for ships to have both "cruising" and "combat" speeds, at an enormous increase in fuel use (particularly useful if I wanted, say, a long range cruiser squadron to escort my survey ships). However, it's also a pretty major change, and since movement and fuel use is clearly already coded it might be something better tossed out as a potential future feature.
It would be a major change, given how much balance is involved in this area. Fuel consumption has to be matched against fuel production in order to create interesting decisions. If fuel is too plentiful, it is too easy and if fuel is too scarce, it would be frustrating.
If I did this at some point, then rather than mounting two or more types of engines it would probably be better to have a fuel efficiency curve built into each engine design, perhaps based on the max boost. As you increase speed, the fuel consumption per point of power rises. Having a higher max boost would lift the entire curve. This is a more real-world situation. To maintain decision-making, the top speeds would have to have higher consumption than at the moment and would probably be reserved for combat situations.
The downside is a more UI, more complexity (including for the AI) and more difficulty for the player in comprehending the potential ranges of his ships at different speeds. The question is whether the game play benefit of having cruising speed is worth the complexity.
Just going to say that Drop Tanks could be simulated by having a new "Ordinance" type that adds to fuel reserves of a ship when in its magazines.
Can't you already do drop tanks with tractor beams and tankers that are nothing more than gigantic fuel tanks?
The downside is a more UI, more complexity (including for the AI) and more difficulty for the player in comprehending the potential ranges of his ships at different speeds. The question is whether the game play benefit of having cruising speed is worth the complexity.
Hello again.
This is a re-post as I originally posted in the wrong place apparently. nvm :)
I assume that C# is going to implement initiative still so I'd like to make the following observation/suggestion.
At the moment, I have to set Fighter squadrons initiative to a higher setting to get them to dock with the carrier. What is somewhat irritating is that every time they dock and relaunch, the initiative gets set back to 100 again. Now I can get round this by setting the carrier initiative lower than 100; so the fighters can dock. But still, fighters are naturally agile, so it would be nice if the code could be modified so they retain their initiative after docking/launch.
I'm not sure if this is practical, because I suspect the initiative is assigned to the Task Group, and when the fighter dock the Task Group no longer exists. Hmmmm..... Perhaps, rather than defaulting to 100, fighter squadrons could default to their highest possible initiative instead upon creation.
Anyway, just a suggestion. It may be too much trouble to implement.
ZG
About components and research from that other thread in the suggestion forum.
It has been suggested a few times that perhaps there could be a way to use components in ship designs before they are actually researched. This would make designing ships a bit simpler without having to resort to SM to research them and then remove the research to research them normally after you decided on what components to use for your designs.
My suggestion is to simply be able to use components for design even if they are not researched. In the design window you should be able to toggle between having the list including both researched and not researched components or only just researched components (should be the default view).
Any ship design that have a none researched component can't obviously be used unless all components in it is properly researched.
This would make it slightly easier to design ships without resorting to SM to test out components.
Would be cool if you could do exercises with your warship using these blueprints.
Design a ship using tech you don't have or components which arent ready yet and spawn it into a system for wargames, pitting your ships against it will gain them experience and training.
Damage done to your real ships would have to be undone of course, all crew deaths being fake, etc.
To be clear, no idea on the viability, but it would be really cool to have to do actual exercises periodically. Some training missiles to shoot at your point defenses so they can practice with their actual weapons and suchnot. Would impose a realistic level of cost on doing training, like in real life.
My suggestion has to do the ground units and seeing if it is possible to have a unit type named "Commando"? The unit would be tasked with handling boarding operations (replacing infantry for that op) and have all terrain capabilities ranked moderately high. It would also be nice to have random intel on high value targets like high ranking enemy officers or other key personnel that may be on ships or a small base on a planet, so that we could quickly deploy a Commando force to either board ships or infiltrate planets by way of dropships to accomplish the mission. Basically, we would have one unit type that specializes in special operations while the infantry would be tasked for invasions and garrison operations. Creating a Commando bonus for officers would be nice as well. Just an idea in my head. Keep up the great work.Fixed unit types are gone, you can make your own custom formation that does this now.
It occurs to me that we might like to be able to assign boarding ships to automatically intercept enemy boarding ships when they come into range, counter boarding them so to speak.
Or if they cant get there in time, we should be able to board our own ships to temporarily add extra marine strength to help fend off enemy boarding action.
How long do boarding operations take to resolve anyway?
I think it would be time for us to be able to build drones... basically any "fighter" should be able to be built as a drone so no crew and no deployment rate needed. . .
Hi Steve, is there any possibility that in the future, colonies might possess unique environmental traits, particularly on those worlds that are potentially habitable (or have been terraformed)? For example a warm ocean world might be home to native sea-dwelling Megafauna, enhancing Luxury Food output. Meanwhile, a newly-terraformed Mars might suffer from severe storms due to rapid climate change, slowing production capacity by a certain percentage. Other worlds might be the home of semi-sentient beasts, viral outbreaks, aggressively hostile alien ecosystems, frequent asteroid storms, etc.
I think it would be time for us to be able to build drones... basically any "fighter" should be able to be built as a drone so no crew and no deployment rate needed. . .
I think "no deployment rate" goes too far for game balance, but I do get a little sad inside every time my "fighter" ends up with a crew of 7. I'd be happy if there was a way to set max crew for small craft, and then every 'required' crew member that wasn't present would cost some amount of wealth & minerals for 'automation'.
As for your 'unmanned' picket ships, may I suggest Conscript Crews and required officer rank of 12 (so that none are assigned) and some cybernetic technobable about how their brains were harvested to make the computer operating system?
How about "Orbital habitats" witch military purpose ? This add to game huge battlestations with hangars, manteinance modules, sensors, defensive weapons and etc.
Hi Steve, is there any possibility that in the future, colonies might possess unique environmental traits, particularly on those worlds that are potentially habitable (or have been terraformed)? For example a warm ocean world might be home to native sea-dwelling Megafauna, enhancing Luxury Food output. Meanwhile, a newly-terraformed Mars might suffer from severe storms due to rapid climate change, slowing production capacity by a certain percentage. Other worlds might be the home of semi-sentient beasts, viral outbreaks, aggressively hostile alien ecosystems, frequent asteroid storms, etc.
Also, when using the empire map will we be able to overlay our own nation's flag onto systems that we wish to designate as under our control?
You can do that in VB6, although you will have to pay maintenance on it.
You can do that in VB6, although you will have to pay maintenance on it.
Really ? "orbital habitat" and "military purpose" properties can exist same time ? And i can build this battlestation 100?++ mass as orbital without naval shipyard, on Factory ?
Say please, how ?
ahh ok, thanks.It will be even easier in C# because you can make a "modular" starbase. The main part will be commercial and houses all the commercial elements, including maintenance modules, and then you can have much smaller military parts that are tugged to the same location and provide all the military modules.
Simple in "full design info"
has both records
This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as an Orbital Habitat for construction purposes
OR
only one
This design is classed as a Military Vessel for maintenance purposes
without any words about OH construction..
Keep in mind that with an active terraforming effort dealing with a hostile biosphere is... trivial.Yeah, this is my issue with "unique" things on planets. As long as we're capable of completely modifying/removing/creating an atmosphere in years or months, there is little point in adding planetary climate/weather/vegetation/animal elements. Because it'll be a minor modifier to colony cost or pop growth or industrial efficiency only until the player has stripped whatever atmosphere existed before and replaced it with something nicer:
Would it be possible to add Ringworld Systems? These would be planets which would have extremely high population caps, but likely would not be mineable. Systems with ringworlds could be finacial bases, research hubs, shipyards, or any other population intense industry.
These would be super rare of course, and you could likely represent them on the system map by having several evenly spaced "planets" as the sections. Maybe with more sections being present on rarer/larger ringworlds.
Systems with Ringworlds would lack all other system bodies, presumably as whoever built the system used all insystem materials in the construction process.
Wrecked Ringworlds could also be a thing, though all they do is provide a huge mineral dump to whoever has the time and ships to salvage the sections.
Quote from: canius link=topic=9841. msg114149#msg114149 date=1556740561Would it be possible to add Ringworld Systems? These would be planets which would have extremely high population caps, but likely would not be mineable. Systems with ringworlds could be finacial bases, research hubs, shipyards, or any other population intense industry.
These would be super rare of course, and you could likely represent them on the system map by having several evenly spaced "planets" as the sections. Maybe with more sections being present on rarer/larger ringworlds.
Systems with Ringworlds would lack all other system bodies, presumably as whoever built the system used all insystem materials in the construction process.
Wrecked Ringworlds could also be a thing, though all they do is provide a huge mineral dump to whoever has the time and ships to salvage the sections.
To be honest. . . I think this is pretty much outside the scope of the amount of resources you could get in this game to build when you think about how massive a realistic ring world would be. We already have habitats and when you consider how expensive they are a ring world that could house thousands of trillions of people would break the game pretty much. Also, finding the resources to build one yourself would not be possible so the only viable way would be to find an already built one.
The amount of population in a typical Aurora game are simply too small for ring worlds to be used effectively, it just would be a planet with infinity population, you should also be able to mine it for resources since you will never use the entire thing anyway. Or why not simply mine it for resources instead of living there, pretty much infinity resources that way for the scope of the game.
My opinion anyway. . .
Something that has been batting around my head is how Research is too exact, too uniform, and that we can tell before we start exactly how long it will take. Hence:
Suggestion:
For each piece of research have two values for the Research Cost, one estimate (with the same values as now) and one true value. This true value could be a random multiplier (say between 0. 5x and 4x) and would also be different for each race.
What you would see on the interface would be the estimate, so you could roughly predict when a research item would finish, but not to the exact date. It would give a bit more variety in multi race starts and also between campaigns themselves. I think it would also aid roleplay, simulating (in a basic way) the uncertainties of research such as breakthroughs and setbacks, and lead to a more dynamic feel of the game.
I don't really like the idea personally that RND would be a stable, reliable thing that you can count on, it seems to me if you don't already have the technology you need to come out on top then you should indeed be seriously worried.
IMO arguments of 'but that would cause me to lose sometimes' shouldn't shape game design because that tends to result in very boring games.
I feel like you guys didn't read my post, you are attributing things to it that aren't true.
If we add random length research completion, or for that matter random ship length construction, installation construction, survey times, etc., there has to be some game play enhancement as an objective.
What decisions does this add for example? Would it actually cause more frustration than enjoyment?
3) I strongly suspect Steve has a high jigsaw affinity, but he's also a big fan of poker.
Are the escort functions from VB6 still present in C#? I was thinking about using detached light cruisers along several axis of my main fleet to extend the detection envelope and realized that I wasn't sure if that would as easy in C# as it is in VB6.
3) I strongly suspect Steve has a high jigsaw affinity, but he's also a big fan of poker.So if high Jigsaw affinity means solving complex puzzles, often with incomplete information, then I agree. If it means having complete information I don't think that would necessarily be me.
it is bit jarring that research costs are always the same from game to game and that I can know down to the day when a particular bit of tech will become available, and I can fine-tune my lab assignments on the fly.
So if high Jigsaw affinity means solving complex puzzles, often with incomplete information, then I agree. If it means having complete information I don't think that would necessarily be me.
Interesting.
I think what I mean by high Jigsaw affinity is "likes solving complex problems that have complete information". So jigsaw, Sudoku, etc. I'm personally not a big jigsaw puzzle fan, but I'm totally hooked on Sudoku and get enjoyment out of games like Civ where I'm cycling through the cities trying to eke out the last dregs of efficiency. I suspect Lego might fall into the same category, although there's an artistic component there. Interestingly enough, it occurs to me that computer programming might fall into this category too, since (at least in a Turing environment) they're deterministic. Maybe the best way to phrase it is "detail-oriented". So are you saying you're not a fan of these sorts of things?
I suspect there might be another axis floating around having to do with completeness of information, but I'm not sure how to formulate it. If your answer is "no, I don't like working through a solution for the sake of working through the solution" then .... that actually lessens the potential incongruity of you liking poker :)
John
I was reading another discussion (about the possibility of using low tech engines as a source of cheap additional HTK on immobile stations) and I had an idea about a potential new component.
Basically, Duranium/Compressed Carbon/etc "Bulkheads". Internal ship components from the same tech line as armor that did nothing except have a large amount of HTK to absorb damage. Even if their HTK and cost were identical to armor plates of the same tech level I think they might see some minor use as a counter to particle lances/shock damage/potentially mesons. Especially if the nerf to mesons and shock damage got revisted with a counter available. They could also be used on missile ships to try to prevent magazine explosions from being completely catastrophic, potentially replacing the internal armoring option that VB Aurora has for some components. I could also see using them being competitive with armor when penetrating hits are a distinct worry (Such as fighters or FACs where the armor would be spread thin relative to HS).
From a roleplay perspective they'd also allow for the design of ships where combat damage was a much more gradual thing - instead of a ship remaining mostly intact until armor was breached, and then being destroyed quickly, a ship making heavy use of bulkheads would see its combat capabilities gradually degraded by damage. Might make some thematic sense to have them give a bonus against boarding in some way (either providing a "fortification" effect for the defenders, or just overall slowing the boarding combat process for both sides).
What I don't enjoy are games where I get penalised or rewarded for things that are completely outside my control. It feels like I don't need to be there. I would rather play something where I feel I can influence the outcome.
I was reading another discussion (about the possibility of using low tech engines as a source of cheap additional HTK on immobile stations) and I had an idea about a potential new component.
Basically, Duranium/Compressed Carbon/etc "Bulkheads". Internal ship components from the same tech line as armor that did nothing except have a large amount of HTK to absorb damage. Even if their HTK and cost were identical to armor plates of the same tech level I think they might see some minor use as a counter to particle lances/shock damage/potentially mesons. Especially if the nerf to mesons and shock damage got revisted with a counter available. They could also be used on missile ships to try to prevent magazine explosions from being completely catastrophic, potentially replacing the internal armoring option that VB Aurora has for some components. I could also see using them being competitive with armor when penetrating hits are a distinct worry (Such as fighters or FACs where the armor would be spread thin relative to HS).
From a roleplay perspective they'd also allow for the design of ships where combat damage was a much more gradual thing - instead of a ship remaining mostly intact until armor was breached, and then being destroyed quickly, a ship making heavy use of bulkheads would see its combat capabilities gradually degraded by damage. Might make some thematic sense to have them give a bonus against boarding in some way (either providing a "fortification" effect for the defenders, or just overall slowing the boarding combat process for both sides).
I would rather see Component Armour return in a functional manner than add bulkheads. I'd prefer to heavily protect one engine and one fuel tank than make my vessel sort-of generally tougher but still almost as likely to be taken out by a single lucky hit.
Let them add a (very minor) speed up bonus, like 1/10th their base rating, as long as it's a project in their field of specialisation. It'll encourage keeping a stable of well trained scientists on hand rather than dropping everything on that one awesome researcher, only to panic when he dies.
Is it possible to add something like this for ship design? This is from the game Rule the Waves. Something like this in Aurora would really be awesome to see what your design looks like...
An idea:
To make area defense more viable (especially with the removal of laser warheads, which was the only practical use of it before), make it avoid range drop-off penalties. The way I'd see this most naturally happen is if you can flag BFCs for PD during design; this would give them flat accuracy across an envelope defined by the range parameter, but restrict said range and only be useful to fire at missiles.
An idea:
To make area defense more viable (especially with the removal of laser warheads, which was the only practical use of it before), make it avoid range drop-off penalties. The way I'd see this most naturally happen is if you can flag BFCs for PD during design; this would give them flat accuracy across an envelope defined by the range parameter, but restrict said range and only be useful to fire at missiles.
An idea:
To make area defense more viable (especially with the removal of laser warheads, which was the only practical use of it before), make it avoid range drop-off penalties. The way I'd see this most naturally happen is if you can flag BFCs for PD during design; this would give them flat accuracy across an envelope defined by the range parameter, but restrict said range and only be useful to fire at missiles.
I don't really like exception rules. If I can accurately hit a missile at long range, why can't I hit a larger, slower ship?
Is it possible to add something like this for ship design? This is from the game Rule the Waves. Something like this in Aurora would really be awesome to see what your design looks like...
Is it possible to add something like this for ship design? This is from the game Rule the Waves. Something like this in Aurora would really be awesome to see what your design looks like...
Are you aware that Rule the Waves 2 came out Friday? It's got aircraft now and the tech tree extends to 1950 IIRC.
John
Shhh! Steve might hear you!Is it possible to add something like this for ship design? This is from the game Rule the Waves. Something like this in Aurora would really be awesome to see what your design looks like...
Are you aware that Rule the Waves 2 came out Friday? It's got aircraft now and the tech tree extends to 1950 IIRC.
John
In all honesty I've been watching videos. I might pick it up to fill the Aurora niche until C# comes out. And while I remain a true Aurora loyalist, I have to admit the videos have been making me think how incredible Aurora would be with real time (sort of) animated combat.
An idea:
To make area defense more viable (especially with the removal of laser warheads, which was the only practical use of it before), make it avoid range drop-off penalties. The way I'd see this most naturally happen is if you can flag BFCs for PD during design; this would give them flat accuracy across an envelope defined by the range parameter, but restrict said range and only be useful to fire at missiles.
I don't really like exception rules. If I can accurately hit a missile at long range, why can't I hit a larger, slower ship?
New Cloaking Thread Here ====> http://aurora2.pentarch.org/index.php?topic=10413.0
Old Cloaking Thread Here ====> http://aurora2.pentarch.org/index.php?topic=10410.0
[Might Be Deleted]
Or what if the laser beam "sweeps" an area of space, burning up any missiles it touches, but only scorching actual armor.
An idea:
To make area defense more viable (especially with the removal of laser warheads, which was the only practical use of it before), make it avoid range drop-off penalties. The way I'd see this most naturally happen is if you can flag BFCs for PD during design; this would give them flat accuracy across an envelope defined by the range parameter, but restrict said range and only be useful to fire at missiles.
I don't really like exception rules. If I can accurately hit a missile at long range, why can't I hit a larger, slower ship?
Then I would immediately armour my missiles.
C#A
It's pronounced 'catcha'. (Or is it kasha?)
I think "C# Aurora" should be shortened to "A#"
that is all.
Too late! I have been watching RTW2 developer updates for a long time and it does look really interesting. I want to play it and I am trying my best not to give in that impulse or Aurora development will probably go on hold for a while :)
Too late! I have been watching RTW2 developer updates for a long time and it does look really interesting. I want to play it and I am trying my best not to give in that impulse or Aurora development will probably go on hold for a while :)
I strongly recommend waiting for a few bugfix releases before diving in. I used to play a lot of RTW1, and I really like the new core mechanics, but frankly there are currently quite a few issues that need to be fixed before RTW2 is truly great. For example, invasion missions are one of the new core gameplay features, but in many areas the invasion target has been placed inside a hostile minefield, leading to situations where you put in all the time and resources to invade an area and when it finally would be within your grasp, you realize that the mission is just impossible to complete. (Because there is no way to order the transports to enter an enemy minefield.) That can be very frustrating.
In addition to the pure bugs, there are also quite a few balance issues, mainly that you can pull of Kido Butai feats of air assaults, in 1925 with biplanes, which feels wrong in so many ways.
RTW1 had some issues on release too, and they all got fixed, and after the fixes they added a lot of cool new features for free too. So I fully expect that RTW2 will be a truly great game someday. It just isn't quite that today.
And absolutely none of this was motivated by trying to delay your purchase of RTW2 to get aurora C# faster. okay maybe a little.
I can't speak for the rest, but some sort of "find highest (total) accessibility asteroid, mine, load minerals into cargo, unload at nearest colony" order for asteroid miners would be wonderful.
Unfortunately, it is more complicated than that. How many systems away do you allow the fleet to go? How about an asteroid 100 AU out? How far would you go if there was only 1000 tons of the mineral? What about if it was a long way and only slightly better than the current location? How does the miner know what minerals are important to you? How about systems next to known alien systems? etc.
The AI can deal with those sort of issues for NPRs, because NPRs have strict controls on deployments, what they can and can't build and they assign values to systems and bodies on an empire-wide basis. In many cases, the 'smarter conditional orders' requests have so many caveats they aren't practical unless the player accepts restrictions on behaviour in the same ways as NPRs.
Unfortunately, it is more complicated than that. How many systems away do you allow the fleet to go? How about an asteroid 100 AU out? How far would you go if there was only 1000 tons of the mineral? What about if it was a long way and only slightly better than the current location? How does the miner know what minerals are important to you? How about systems next to known alien systems? etc.Maybe adding mineral demands in the civilian transport-transfer screen might be a solution for this. One then can let the civilians construct asteroid miners and they do the collecting and deliver to those planets.
The AI can deal with those sort of issues for NPRs, because NPRs have strict controls on deployments, what they can and can't build and they assign values to systems and bodies on an empire-wide basis. In many cases, the 'smarter conditional orders' requests have so many caveats they aren't practical unless the player accepts restrictions on behaviour in the same ways as NPRs.
Too late! I have been watching RTW2 developer updates for a long time and it does look really interesting. I want to play it and I am trying my best not to give in that impulse or Aurora development will probably go on hold for a while :)
First things first, though, two more conditional slots or so would be a blessing. As of now you can't have a grav survey ship both refuel, resupply and overhaul automatically, which is not pressing but annoying.
Quote from: JustAnotherDude link=topic=9841. msg114704#msg114704 date=1559066294First things first, though, two more conditional slots or so would be a blessing. As of now you can't have a grav survey ship both refuel, resupply and overhaul automatically, which is not pressing but annoying.
I think my earlier suggestion of letting taskgroups take standing/conditional orders from higher up the hierarchy solves this problem in a better way. Suppose you have a command hierarchy like this:
Navy HQ
-Commercial HQ
--Exploration HQ
---Geo Survey HQ
----Geosurvey TG 1
----Geosurvey TG 2
----. . .
---Grav Survey HQ
----Grav survey TG 1
----Grav survey TG 2
----. . .
Then at the Commercial HQ you'd set the refuel order, at the Exploration HQ you'd set the resupply and overhaul order, at the Geo Survey HQ you'd set the geosurvey orders, and at the Grav Survey HQ you'd set the grav survey orders. The added advantage of this system is that once you've set it up you don't have to bother with it anymore, if you've built a new geosurvey ship then all you'd have to do is assign it to the Geo Survey HQ and it'll automatically pick up the necessary orders.
Been thinking the exact same thing actually. Create generalized orders for entire HQ / Taskgroup-command which gets copied (once) for all sub-TGs. This would have the additional advantages (obvious to me) of setting your entire fleet to go somewhere or do something you want.
Another possibility would be to have an organizational branch TG (special type) that are only used for order creation and management (no ships). It would also be nice if leaders who are assigned to superior formations give partial bonuses (synergy) to lower formations in the command chain, but that would just require changing how things are now in the game, or is this perhaps already implemented without my knowledge?
TLDR: missile range should be more heavily restricted on most powerful engines instead of difference being 50m,12km/s vs 70m,10km/s it should be like more like 500k,12km/s vs 10m,10km/s
Facility idea:
Interstellar mass driver
Must be built on closest planet to system primary. Needs 2.5 mil population to be operated. Can target other interstellar mass drivers across jump points. Only 1 per system with limited annual tons of material.
Facility idea:
Interstellar mass driver
Must be built on closest planet to system primary. Needs 2.5 mil population to be operated. Can target other interstellar mass drivers across jump points. Only 1 per system with limited annual tons of material.
I would like to suggest a simple change to the way VB6 handles inexperienced fleets: instead of the fleet stopping while it acknowledges new orders, have it follow the last order given until it does so.
The new option for "Human NPRs"; could it be possible to make the chance variable? Not fixed 1/3rd but rather an option and we can choose how likely the chance for a human NPR is?
Actually fuel consumption per engine hour is a general tech that is automatically applied to all engine types. I know it would not add much to gameplay except more "realism", but I would like to have fuel consumption per engine hour dependend upon each engine class. So at first when you research a new type of engine class, it might be faster but would eventually eat much more fuel, Later on you would get the benefit of lesser fuel consumption as you research it.I once thought of this but each engine tech step needs to matter a lot less and the fuel tech needs to be really cheap compared to next engine tech to be worth to research.
I don't know if this has been suggested before but I really liked the idea of a ship's computer/ AI tech that would reduce the crew requirement: research could determine the crew quality that the computer could simulate, how many crew it can replace per ton stuff like that. Precursor ships could be translated to use these systems instead of what they do right now.
I'm really looking forward to getting to fool around in C#, whenever you decide to release it! =)
Level of Importance for Task Groups:Totally support this idea!!!!!
I usually rename my Task Groups with spaces in front of them so that the more important ones are at the top of my TG list. That on the other hand gets a bit "out of hand" when you do that with several levels of importance. Would be nice if we could add a "level of importance" to the TG and that the TG list will be sorted by that level of importance first; then name etc.
Level of Importance for Task Groups:
I usually rename my Task Groups with spaces in front of them so that the more important ones are at the top of my TG list. That on the other hand gets a bit "out of hand" when you do that with several levels of importance. Would be nice if we could add a "level of importance" to the TG and that the TG list will be sorted by that level of importance first; then name etc.
Defining which events break up the time progression cycle
Copy of posting from here:
http://aurora2.pentarch.org/index.php?topic=9835
Would be nice if we could choose which actions stop a time progression cycle early and which don't. At least for some of them I cannot understand why they stop it early.
Defining which events break up the time progression cycle
Copy of posting from here:
http://aurora2.pentarch.org/index.php?topic=9835
Would be nice if we could choose which actions stop a time progression cycle early and which don't. At least for some of them I cannot understand why they stop it early.
Not sure if this was added or not, but choosing what stops time cycles is something I am hoping for :)
I like the escape pod idea. But it should probably come with some more negative effects from not rescuing your personnel. Otherwise I think it will be too tempting to just go with the minimum time on every design. Or perhaps set 14 days as the minimum time.
I like the escape pod idea. But it should probably come with some more negative effects from not rescuing your personnel. Otherwise I think it will be too tempting to just go with the minimum time on every design. Or perhaps set 14 days as the minimum time.
I, too, love the idea of variable escape pod time that one sets when designing ships. But I strongly disagree that there should be increased penealties for not rescuing personnel or a fixed minimum duration for life pods.
Whether or not an empire rescues survivors is a *role-playing* decision for that empire, and should not be inflicted on me by game mechanics. What if my empire is a machine race, and automatically downloads all crew before ship destruction? What if my empire is a hive mind and sees zero value in rescuing drones? What if my empire suffers from military chauvinism and views 'death before dishonour' as the overriding principle (in which case, it would be nice if I could prevent my ships from having life pods at all)?
The 'penalty' for too-short a time on your life pods is that you don't get your crew back. If you want a three-day window, or a three-month window, that should be up to your empire to decide.
I, too, love the idea of variable escape pod time that one sets when designing ships. But I strongly disagree that there should be increased penealties for not rescuing personnel or a fixed minimum duration for life pods.
On the point of lifepod penalties, could this not be implemented by using a racial trait? We already have various ones so add in a new one that could be called compassion or such, the higher it is then the greater the morale penalties a population suffers from losses such as lifepods. This then easily allows folks to create races of custom opinions and keeps a scalable mechanic in place also.
I like the escape pod idea. But it should probably come with some more negative effects from not rescuing your personnel. Otherwise I think it will be too tempting to just go with the minimum time on every design. Or perhaps set 14 days as the minimum time.
I, too, love the idea of variable escape pod time that one sets when designing ships. But I strongly disagree that there should be increased penealties for not rescuing personnel or a fixed minimum duration for life pods.
Whether or not an empire rescues survivors is a *role-playing* decision for that empire, and should not be inflicted on me by game mechanics. What if my empire is a machine race, and automatically downloads all crew before ship destruction? What if my empire is a hive mind and sees zero value in rescuing drones? What if my empire suffers from military chauvinism and views 'death before dishonour' as the overriding principle (in which case, it would be nice if I could prevent my ships from having life pods at all)?
The 'penalty' for too-short a time on your life pods is that you don't get your crew back. If you want a three-day window, or a three-month window, that should be up to your empire to decide.
While we're on the subject of crews, crew rotation could be an alternative to R&R. At any stop where the crew could R&R, you could instead opt to perform a six-hour action that would muster off your existing crew and take on new crew, at the cost of resetting your vessel performance to the racial training level default (or the minimum, if the vessel class is set to use conscripts). For warships this would normally be counterproductive, but merchant vessels typically do not want to spend two weeks in port while the crew is on shore leave, and don't generally care about the things that crew grade modifies.I don't think this is much of an issue now that Steve has removed crew morale for commercial vessels. So we can RP crew rotation to be taking place among them easily enough.
On a purely cosmetic note, I think the "use conscript crew" should be changed to "use merchant crew." I have a hard time imagining a modern vessel being entrusted to an impressed crew (outside some neo-Victorian dystopia). Whereas I have no problem at all with imagining orbital miners and fuel refineries being crewed by merchant mariners.
If the AI can set its own policy, even just choosing one at random at race creation, that would make it even. If crew are valuable enough that whether or not to rescue them is a legitimate strategic choice, not just for RP, then that should be enough to keep it balanced and interesting.I like the escape pod idea. But it should probably come with some more negative effects from not rescuing your personnel. Otherwise I think it will be too tempting to just go with the minimum time on every design. Or perhaps set 14 days as the minimum time.
I, too, love the idea of variable escape pod time that one sets when designing ships. But I strongly disagree that there should be increased penealties for not rescuing personnel or a fixed minimum duration for life pods.
Whether or not an empire rescues survivors is a *role-playing* decision for that empire, and should not be inflicted on me by game mechanics. What if my empire is a machine race, and automatically downloads all crew before ship destruction? What if my empire is a hive mind and sees zero value in rescuing drones? What if my empire suffers from military chauvinism and views 'death before dishonour' as the overriding principle (in which case, it would be nice if I could prevent my ships from having life pods at all)?
The 'penalty' for too-short a time on your life pods is that you don't get your crew back. If you want a three-day window, or a three-month window, that should be up to your empire to decide.
I am also in favor of configurable life time for escape pods during ship design, but short lived escape pods, or no escape pods at all also have implications regarding capturing POW
and therefor for intelligence gathering. This could leave the AI in an big disadvantage. So some other game mechanics to offset the disadvantage may be required.
I don't think this is much of an issue now that Steve has removed crew morale for commercial vessels. So we can RP crew rotation to be taking place among them easily enough.So combined with the unlimited fuel glitch my geosurvey ships will now have unlimited endurance? :D
On the point of lifepod penalties, could this not be implemented by using a racial trait? We already have various ones so add in a new one that could be called compassion or such, the higher it is then the greater the morale penalties a population suffers from losses such as lifepods. This then easily allows folks to create races of custom opinions and keeps a scalable mechanic in place also.
.. Maybe call it "willingnes to sacrifice"? Honestly I think it would be better to just leave it to roleplay. For example, if I roleplay a honorbound warrior race... it's not a matter of compassion or such. Maybe they think that surviving a lost fight is cowardice. Maybe they think that wasting space for escape pods is stupid and inefficient. I really don't want to reduce something like this to "compassion", there can be a lot of reasons for a race not wanting to save the people in escape pods.
I'd still really just leave it to roleplay. I'm ok with having variable lenght of escape pods duration in designs if people want to.... provided we can also choose to go without escape pods at all.
That could be an interesting variable to distinguish NPRs diplomatically too... a race with high compassion could get an opinion boost if you pick up their survivors after battle (even if they're prisoners, at least they're alive) or an opinion penalty if you leave their lifepods to expire. Conversely, the stereotypical honourbound warriors might respect you more for letting their crew die a swift death rather than taking them prisoner.
I think (2) and (3) could be collapsed into an AMM PD setting toggle to 'prefer targetting further away salvoes over closer ones' which is the opposite of what Aurora does now.'Target furthest salvo' would help in most cases, and is in fact what I was initially going to ask for, but it is less efficient than 'target widest salvo'.
As someone who almost never uses AMM PD, and when I do only at 1v1, I think many of these problems can be solved -- or at least strongly mitigated -- by fine-tuning the fire control to launcher ratio on AMM ships.
Though most of all, I would like to see point defense ditch the 'salvo' concept and change to an 'all missiles within X radius' system where it wouldn't matter if I'm shooting at 24 missiles from a single BCR or 24 missiles from a dozen bombers.
While I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions. That seems a bit much.
I think (2) and (3) could be collapsed into an AMM PD setting toggle to 'prefer targetting further away salvoes over closer ones' which is the opposite of what Aurora does now.
As someone who almost never uses AMM PD, and when I do only at 1v1, I think many of these problems can be solved -- or at least strongly mitigated -- by fine-tuning the fire control to launcher ratio on AMM ships.
Though most of all, I would like to see point defense ditch the 'salvo' concept and change to an 'all missiles within X radius' system where it wouldn't matter if I'm shooting at 24 missiles from a single BCR or 24 missiles from a dozen bombers.
'Target furthest salvo' would help in most cases, and is in fact what I was initially going to ask for, but it is less efficient than 'target widest salvo'.
I must respectfully disagree. The defender's fire control to launcher ratio doesn't make any difference, nor does changing the AMM per ASM PD setting. All the attacker needs is FC and reload rate parity, a small* tube advantage, and enough magazine depth for sustained fire until the defender dies. While that should generally be the case, the problem is that the numbers are a lot lower than they should be. Even a single tube advantage becomes total superiority. How the attacker matches tubes to FC's makes no difference beyond 'every FC has at least one tube', and any mismatch in salvo size between attacker and defender is always in the attacker's favour. The only possible counters under current rules are: manual PD targeting, putting big enough sensors on AMMs to find incoming ASMs, or outrunning them. Good luck with that.TM
While I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions. That seems a bit much.
*The minimum tubes is (defender tubes * defender cth + 1), with the optimum being (defender tubes * defender cth + #FCs), so if the defender's AMMs have 50% cth, only 50%+1 tubes are needed. Even against 100% cth AMMs the attacker only needs one more tube.
Are you completely excluding beam PD from this? Personally, I have never tried to 100% stop incoming missiles with AMMs. I have only ever experimented with set ups designed to thin their numbers and have always used beam PD, shields, and armour to absorb the leakers. (Sometimes I use entire battleships to absorb the leakers. #:-] )
- - -
If Steve is going to reprogram AMM PD from 'target nearest salvo' to (optionally) 'target furthest salvo', I don't expect it would be too much trouble to also add 'target largest salvo' to the radio buttons.
- - -QuoteWhile I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions. That seems a bit much.
Oh, I didn't mean a radius from the firing ship; but rather a radius around the initial target. So if I shoot / launch AMMs at incoming Missile #578984632115, let the same FC also shoot / launch at any missiles within, say, 5,000 km of it.
Are you completely excluding beam PD from this? Personally, I have never tried to 100% stop incoming missiles with AMMs. I have only ever experimented with set ups designed to thin their numbers and have always used beam PD, shields, and armour to absorb the leakers. (Sometimes I use entire battleships to absorb the leakers. #:-] )The point is that against this exploit you need enough beam defence that missile defence didn't matter anyway. Once triggered 100% of incoming missiles leak. While the AI doesn't deliberately exploit it I have lost ships to it, though I didn't understand it at the time. The AI is defenceless against it and it also negates missile defence in hotseat games since it is simple to exploit.
- - -
If Steve is going to reprogram AMM PD from 'target nearest salvo' to (optionally) 'target furthest salvo', I don't expect it would be too much trouble to also add 'target largest salvo' to the radio buttons.
- - -QuoteWhile I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions. That seems a bit much.
Oh, I didn't mean a radius from the firing ship; but rather a radius around the initial target. So if I shoot / launch AMMs at incoming Missile #578984632115, let the same FC also shoot / launch at any missiles within, say, 5,000 km of it.
The problem is not Fire-Controls in and of itself, especially not against AMM. If you want to fire say one missile per enemy ASM the problem with Fire-Control usually crop up since you only fire on one salvo so the defender are generally wasting more fire-controls. If a salvo contain say 6 missiles and the defender only have five AMM per fire control you need tow fire-controls to engage that salvo with one missile and waste four missiles in that 5sec turn. Even if there are more missiles incoming, there are no reason that you could not target more missiles from a realistic point of view unless you want to twist and bend the technobabble to fit the narrative.If the enemy is attacking with more missiles per salvo than my AMM is set up for, I just reassign some tubes. What saturates missile PD is that it takes more than one outgoing salvo to completely kill an incoming one, so you want more FCs than the enemy has.
The thing is way worse for beam fire-controls that can easily be saturated. One problem is that five different missiles fired with the same fire-control create five different salvos as one example.
I don't think that engaging missiles coming in from different direction (in the same 5 sec turn) happen enough in an actual game that it is reasonable to bring up as a reason against engagement of missile fire-control salvos. In that case I would settle for engaging missiles with the same position if that would be a major issue and ignoring the fire-control issue.
Full size missile launcher against an equal tech level opponent is often a waste of resources since beam point defence are too effective (at least until rather late in the game when beam PD become useless, although I never play that late). The only way you can beat beam PD is by saturating the PD by gaming the system (which is possible if you want to). Thus you need reduced sized launchers rather than deep magazines of missiles so you can hopefully overpower the enemies beam PD, this is where AMM become really important.
Are you completely excluding beam PD from this? Personally, I have never tried to 100% stop incoming missiles with AMMs. I have only ever experimented with set ups designed to thin their numbers and have always used beam PD, shields, and armour to absorb the leakers. (Sometimes I use entire battleships to absorb the leakers. #:-] )The point is that against this exploit you need enough beam defence that missile defence didn't matter anyway. Once triggered 100% of incoming missiles leak. While the AI doesn't deliberately exploit it I have lost ships to it, though I didn't understand it at the time. The AI is defenceless against it and it also negates missile defence in hotseat games since it is simple to exploit.
- - -
If Steve is going to reprogram AMM PD from 'target nearest salvo' to (optionally) 'target furthest salvo', I don't expect it would be too much trouble to also add 'target largest salvo' to the radio buttons.
- - -QuoteWhile I agree that the current system is lacking, that would allow a single turret to split fire between salvos arriving from opposite directions. That seems a bit much.
Oh, I didn't mean a radius from the firing ship; but rather a radius around the initial target. So if I shoot / launch AMMs at incoming Missile #578984632115, let the same FC also shoot / launch at any missiles within, say, 5,000 km of it.
----
Adding either option should be no harder than the other. While I consider one better than the other I am in no way against adding both. :)
----
That supposedly is what missile sensors are for, but good luck mounting those on AMMs before late game in VB or at all in C# due to the new minimum sensor size.The problem is not Fire-Controls in and of itself, especially not against AMM. If you want to fire say one missile per enemy ASM the problem with Fire-Control usually crop up since you only fire on one salvo so the defender are generally wasting more fire-controls. If a salvo contain say 6 missiles and the defender only have five AMM per fire control you need tow fire-controls to engage that salvo with one missile and waste four missiles in that 5sec turn. Even if there are more missiles incoming, there are no reason that you could not target more missiles from a realistic point of view unless you want to twist and bend the technobabble to fit the narrative.If the enemy is attacking with more missiles per salvo than my AMM is set up for, I just reassign some tubes. What saturates missile PD is that it takes more than one outgoing salvo to completely kill an incoming one, so you want more FCs than the enemy has.
The thing is way worse for beam fire-controls that can easily be saturated. One problem is that five different missiles fired with the same fire-control create five different salvos as one example.
I don't think that engaging missiles coming in from different direction (in the same 5 sec turn) happen enough in an actual game that it is reasonable to bring up as a reason against engagement of missile fire-control salvos. In that case I would settle for engaging missiles with the same position if that would be a major issue and ignoring the fire-control issue.
Full size missile launcher against an equal tech level opponent is often a waste of resources since beam point defence are too effective (at least until rather late in the game when beam PD become useless, although I never play that late). The only way you can beat beam PD is by saturating the PD by gaming the system (which is possible if you want to). Thus you need reduced sized launchers rather than deep magazines of missiles so you can hopefully overpower the enemies beam PD, this is where AMM become really important.
I've never tried linking different types of ASM to the same FC since I always standardize my loads so I will need to test that. Otherwise I've never seen a missile FC create more than one salvo per tick. As long as they arrive one salvo at a time then one beam FC can keep up with them.
While I misunderstood Father Tim's objection I stand by what I said.
The exploit is that you only need about half as many launchers and a quarter the missiles that you should to defeat AMMs. Theoretically even a start-game attacker could exploit this against an end-game defender.
So how about a building which will do exactly that?
Yeah, this sounds really superfluous because of the improvements to orbital habitats and the possibility of LG infrastructure AND genetic modification.Yeah, you are right, forgotten about that. My suggestion seems only different in general gameplay. Though would be nice to know what happens if you add living space on a body and those stations got shot down. Does the population instantly disappear with them or are they left on the body and slowly die away?
The pop remains. Orbital habs are just a form of infrastructure.Yeah, this sounds really superfluous because of the improvements to orbital habitats and the possibility of LG infrastructure AND genetic modification.Though would be nice to know what happens if you add living space on a body and those stations got shot down. Does the population instantly disappear with them or are they left on the body and slowly die away?
Another option in my opinion far better one is to make AI stop shooting missiles and choose a different behaviour if lets say last 3 full salvoes shot by AI had 0% hit rate (all shot down by PD).
Make a button that deletes all missiles (and if applicable drones mines countermeasures) in a system.Such a button might be appropriate for SM mode.
This is very useful in single player scenarios where a player is already 100% sure that enemy AI cannot get past his point defence but AI is still shooting 50 missiles per minute that severely slow down the game.
Another option in my opinion far better one is to make AI stop shooting missiles and choose a different behaviour if lets say last 3 full salvoes shot by AI had 0% hit rate (all shot down by PD).
edit: this behaviour could stay until a ship by player takes a damage so there might be a change in PD or/and until AI get reinforcements and/or until some time runs out
sorry for bad english/grammar
edit2: make all/most weapon size techs severely cheaper to research with some numbers rebalance. big cannons should have a slow reload time and another tech pre-requesites to be effective for example capacitor recharge rate. some games just do it wrong where bigger cannons are better and expensive to research and its not very logical compared to real world engineering
I think that bigger cannons should be primarily about design choice (possibly inefficient big cannons or more versatile small ones or more point defence) not about tech levels.
'Skip current order' button please :)
Suppose you have a freighter or survey vessel set up to collect minerals from ten different systems and drop them off in your central mining hub, and one of those systems develops a bad case of unfriendly alien warships. Having to reconstruct the entire order queue for the freighter (and then re-reconstruct it after you've cleared out the baddies) is a lot of tedious clicking just for skipping a single pickup.'Skip current order' button please :)
Not quite sure you mean by this.
If you are in Sol, your first order is Transit to Alpha Centauri and your second order is move to Alpha Centauri-A I, how could you skip the first one?That would be theoretically fixable by checking whether the second order remains valid without the first order. Perhaps a better way to do it would be a "skip to next valid order" function (so a vessel in Sol that was set up to go to Alpha Centauri, come back, and report to Earth for overhaul would skip the whole round trip to AC and go directly to Earth for overhaul). I'm not sure how practical that is to code, though - that would depend on how easy it is to identify orders that would be valid in counterfactual scenarios.
Suppose you have a freighter or survey vessel set up to collect minerals from ten different systems and drop them off in your central mining hub, and one of those systems develops a bad case of unfriendly alien warships. Having to reconstruct the entire order queue for the freighter (and then re-reconstruct it after you've cleared out the baddies) is a lot of tedious clicking just for skipping a single pickup.'Skip current order' button please :)
Not quite sure you mean by this.QuoteIf you are in Sol, your first order is Transit to Alpha Centauri and your second order is move to Alpha Centauri-A I, how could you skip the first one?That would be theoretically fixable by checking whether the second order remains valid without the first order. Perhaps a better way to do it would be a "skip to next valid order" function (so a vessel in Sol that was set up to go to Alpha Centauri, come back, and report to Earth for overhaul would skip the whole round trip to AC and go directly to Earth for overhaul). I'm not sure how practical that is to code, though - that would depend on how easy it is to identify orders that would be valid in counterfactual scenarios.
The ability to change the assigned name of another race's ship class in the intelligence screen would be nice, since it doesn't seem like that can be done in the current version.
Planets in c# will have a max population. What about adding the ability to increase the population capacity of planets with research? Adding technologies such as urbanisation tech and/or arcologies would add an interesting dimension to planetairy development.Had asked the same a while ago. You can add pop max with space stations, so no need to add such a tech tree (yet).
What's the difference between researching Arcology tech and building Orbital Habitats in a game where both just add additional population capacity on a body?Orbital habitats are spacecraft. There's a pretty obvious and big mechanical difference.
Orbital habitats are spacecraft. There's a pretty obvious and big mechanical difference.But that doesn't actually matter.
I was suggesting urbanization tech due to the following reason: A lower tech level society cannot support the same number of people on a planet as a higher tech one, I am proposing to model that.Unless I'm misunderstanding what you mean here, this is still completely irrelevant. We're not talking about Medieval urban areas without sanitation, health services or refrigerated food transport. Once you have running water and electricity and vaccinations, there is technically no limit to population density that your society can support.
Neither does a TN-nuke care whether it's target is an orbital habitat, destruction of which might turn population growth negative, or the population itself - both cause a loss of population, one just does it more rapidly than the other.Unless I'm mistaken, the nuke hitting a habitat has no possibility of damaging installations or causing atmospheric dust. Also, there are of course going to be differences regarding sensor interaction, I think.
And because Aurora does not model any of that, adding a tech line that arbitrarily increases population density seems pointless. There already is a Construction tech line that makes Infrastructure more efficient and a Biology tech line that makes Terraforming faster.I actually think the way to implement this would simply be to allow infrastructure to increase the body's population capacity, still governed by the efficiency tech, and maybe getting less efficient the more you're using infrastructure to boost the population capacity. The specifics would be left up to player imagination, and the simplicity explains the wide range of usability.
If we go down that route, it would make more sense to say that all planets need infrastructure, and change the current infrastructure calculation to:Neither does a TN-nuke care whether it's target is an orbital habitat, destruction of which might turn population growth negative, or the population itself - both cause a loss of population, one just does it more rapidly than the other.Unless I'm mistaken, the nuke hitting a habitat has no possibility of damaging installations or causing atmospheric dust. Also, there are of course going to be differences regarding sensor interaction, I think.And because Aurora does not model any of that, adding a tech line that arbitrarily increases population density seems pointless. There already is a Construction tech line that makes Infrastructure more efficient and a Biology tech line that makes Terraforming faster.I actually think the way to implement this would simply be to allow infrastructure to increase the body's population capacity, still governed by the efficiency tech, and maybe getting less efficient the more you're using infrastructure to boost the population capacity. The specifics would be left up to player imagination, and the simplicity explains the wide range of usability.
For planets that already need infastructure, I imagine the way it would work is that once you hit the population capacity the planet would have if its colony cost was 0, you would need to add the infrastructure for the colony cost to the infrastructure for bypassing pop-cap together in order to achieve the same effect. So, if you need 200 infrastructure to raise a colony cost 0 planet's pop cap by 1 million, and the planet has a colony cost of 2, you'd need 400 infrastructure to raise that planet's pop cap by 1 millions.
This is distinctly for the future, but to build on that it would be kindof cool if you could elect to block civilian colonization by default. They could then pressure you somehow for authorization to colonize, giving you an incentive to go find some place for them to grow into.
Perhaps they could simply lobby the government in various ways, meaning they will gradually (over the course of a decade or so) proceed towards colonizing somewhere of their own (probably idiotic) choosing. This might result in nothing bad happening, or it might result in them selecting a planet that is very dangerous (perhaps claimed by aliens, though they probably shouldn't pick somewhere actually defended by said aliens). Assuming they announce the planned target at the beginning of their lobbying, it could occasionally create ticking time bomb situations that you need to resolve (by providing some not-at-full-capacity colonizaiton target at 2.0 cost or less).
All the numbers there are totally made up and I don't consider them to be particularly good for anything other than providing a general idea of what I mean.
Could we possibly edit the rules for the detection of targets smaller than the designed active sensor resolution? Right now, it scales to the square of ship resolution divided by sensor resolution, while active sensor resolution only scales with the cube root of sensor resolution. This disproportionately favours smaller resolutions to avoid ships sneaking in, and it especially becomes a problem with small, sub kiloton craft. It's already hard enough to detect them without excessively large sensors and fire controls, but the present system is such that simply reducing the size of your craft by 50-100t, which is easily done for fighters, results in the enemy having to perform a very expensive overhaul of their ships to edit resolution and avoid becoming obsolete.
May I suggest something along the lines of :
Active Sensor Range = Max Range * SQRT(Ship HS/Resolution HS)
Could we possibly edit the rules for the detection of targets smaller than the designed active sensor resolution? Right now, it scales to the square of ship resolution divided by sensor resolution, while active sensor resolution only scales with the cube root of sensor resolution. This disproportionately favours smaller resolutions to avoid ships sneaking in, and it especially becomes a problem with small, sub kiloton craft. It's already hard enough to detect them without excessively large sensors and fire controls, but the present system is such that simply reducing the size of your craft by 50-100t, which is easily done for fighters, results in the enemy having to perform a very expensive overhaul of their ships to edit resolution and avoid becoming obsolete.
May I suggest something along the lines of :
Active Sensor Range = Max Range * SQRT(Ship HS/Resolution HS)
http://aurora2.pentarch.org/index.php?topic=8495.msg102701#msg102701
To be honest I don't think that was the point. The point was that because of the new change it most often is better to use a bigger smaller res sensor than having two sensors one small res and one big res. For example there is no point in having say one 300t 5 res and one 300t 20 res when one 600t res 5 have pretty much the same range as a 300t 20 res sensor. The difference get worse the higher the resolution you have on the sensors.
If the lower end of a high res scaled differently then large res sensors would make more sense to use in general from a research point of view.
Could it be possible to make it so that double clicking on a jump point would switch the system view to the system that jump point leads to?
To be honest I don't think that was the point. The point was that because of the new change it most often is better to use a bigger smaller res sensor than having two sensors one small res and one big res. For example there is no point in having say one 300t 5 res and one 300t 20 res when one 600t res 5 have pretty much the same range as a 300t 20 res sensor. The difference get worse the higher the resolution you have on the sensors.
If the lower end of a high res scaled differently then large res sensors would make more sense to use in general from a research point of view.
Yes, I understand now. I've run the numbers for the suggestion but it massively increases sensor range vs smaller ships to the point where small resolution sensors wouldn't be needed. For example, using active sensor 21 and EM 11, the range of a 50 ton resolution sensor is 40m (23m VB6). It can detect FACs at 1.6m (900k VB6) and 250 ton fighters at 100k (57K VB6). A dedicated resolution-20 sensor would detect the FAC at 23m and a dedicated fighter sensor would detect the fighter at 14m
With the proposed change for a resolution-100 sensor the FAC would be detected at 18m and the fighters at 9m so you wouldn't need the dedicated sensors.
It is definitely true that you gain less of a range advantage on C# with higher resolution sensors, but on the other hand gaining an extra twenty or thirty percent of range (for example) can be important, especially with reduced missile ranges. You also gain far less range now by researching extra sensor tech. Sensor ranges are much more compressed so small gains are worth relatively more.
There are some things I'd like to suggest since we are on the subject.Could it be possible to make it so that double clicking on a jump point would switch the system view to the system that jump point leads to?
Double-clicking would be tricky as the first click centres the system on the object you click :)
However, I think I have come up with something better. When you right-click on the tactical map, any fleets, populations or jump points within a few pixels of where you click will appear in a list. If you select a population, the Economics window will load with the population selected. If you select a fleet, the Naval Organization window will load with the fleet selected. If you select the jump point, which appears as the name of any destination system, the tactical map will change to that system.
There are some things I'd like to suggest since we are on the subject.
Clicking on hidden objects shouldn't select them or prevent clicking on visible objects.
Hidden objects shouldn't be listed in the context menu unless they are only hidden due to overlap.
Allow dragging the tactical map to scroll it.
Yes, I understand now. I've run the numbers for the suggestion but it massively increases sensor range vs smaller ships to the point where small resolution sensors wouldn't be needed. For example, using active sensor 21 and EM 11, the range of a 50 ton resolution sensor is 40m (23m VB6). It can detect FACs at 1.6m (900k VB6) and 250 ton fighters at 100k (57K VB6). A dedicated resolution-20 sensor would detect the FAC at 23m and a dedicated fighter sensor would detect the fighter at 14m
With the proposed change for a resolution-100 sensor the FAC would be detected at 18m and the fighters at 9m so you wouldn't need the dedicated sensors.
It is definitely true that you gain less of a range advantage on C# with higher resolution sensors, but on the other hand gaining an extra twenty or thirty percent of range (for example) can be important, especially with reduced missile ranges. You also gain far less range now by researching extra sensor tech. Sensor ranges are much more compressed so small gains are worth relatively more.
If we go down that route, it would make more sense to say that all planets need infrastructureI don't really agree. As things are right now, infrastructure is used to allow population on worlds with bad temps, atmospheres, and with research, low gravity. All of these are about sustaining populations in inhospitable/otherwise unlivable circumstances. I don't think extending that to deal with overpopulation is moving that far out of where it conceptually is right now.
Without some kind of infrastructure, Earth could support maybe ten million people. You might not need pressurized domes or CO2 scrubbers, but that doesn't mean an Earth city doesn't need infrastructure.My point is that what infrastructure currently represents is clearly more specific. Also, all planets, regardless of conditions, having an evergrowing need for infastructure the moment you begin colonizing doesn't sound fun.
We're maintaining some 7 billion people and counting on Earth without TN based infrastructure right now.
I agree that the mechanics are in some ways rather odd, Mars should for example be quite capable of supporting human habitation without TN infrastructure or terraforming, although it would need to account for the harsh environmental conditions. But keep in mind that TN infrastructure isn't needed in a surprisingly wide range of cases. As long as gravity is tolerable? TN materials are not needed. As long as the atmospheric content is tolerable? TN materials not needed. As long as the temperature is tolerable? TN materials not needed.
And that offers a fairly large range of options in which standard physics based infrastructure is enough to supply all needed support, even if that includes things like vast, centrally heated cities to cope with the long and cold winters of a -5 degrees Celsius average temperature planet, the terrible, baking heat of a planet with an average 30 degrees Celsius temperature, or the vast storms of an archipelago planet fueled by the tremendous expanse of an uninterrupted world spanning ocean.
Of course, after a point you have the issue that if TN materials can do these things better and easier, people will want those used instead, in the same way that we don't fly via old-style wooden propeller airliners now even though the aircraft themselves were cheaper and used fewer rare resources than modern airliners.
I guess I wasn't clear what I meant. Sorry.There are some things I'd like to suggest since we are on the subject.
Clicking on hidden objects shouldn't select them or prevent clicking on visible objects.
Hidden objects shouldn't be listed in the context menu unless they are only hidden due to overlap.
It is your own fleets and populations so they won't be hidden. The jump point only gets added to the list if you have already explored it (no point otherwise)
I must have forgotten that change then. There are so many improvements in C# it can be tricky to keep track of them all.QuoteAllow dragging the tactical map to scroll it.
You can already click-drag the tactical and galactic maps.
In c# aurora ground surveys will be conducted not by teams as in vb but by ground forces. I would like to suggest that ground survey be something that can be automated.
Please take a look at how PD engages missile salvos. As it is right now you need too many fire-controls for small missiles salvos because if one PD turret linked to a fire-control leave even one missile the next turret will be used on that one instead of shooting on a new salvo where they would score allot more missile kills.
This should be looked at from a game balance perspective in my opinion, beam PD fire-controls already are way more expensive than missile fire-controls in general.
I would suggest that PD is put on a list where the biggest is on the top (or rather the one that have the most likely higher kills). Each control then target the largest salvo in that increment that hit also sorted into some list where the largest salvo always get put on top.
Currently you need almost somewhat like 25-50% more fire-controls even against relatively small salvos such as fighters unless there is a very high chance one turret can destroy all incoming missiles in one go. You could of course put more turrets on each fire control but turrets are pretty big. There also are problems with mixing ships with smaller turrets and larger ones, if you are unlucky the smaller turret fire first and simply waste its ammunition since the larger could have killed the salvo.
A good example of the problem is... lets say you have 10 salvos of incoming missiles of 6 missiles in each salvo. You have a quad Gauss turret to engage them and you are quite likely to kill all missiles on one turret and you have ten turrets and PD fire-controls. Lets say out of the ten salvos you would theoretically miss one or two missiles. In practice this means that you get six to twelve missiles to leak and not one or two. In this instance I rather have triple turrets and a few more fire-controls but that also is way more expensive... and very taxing on certain resources. Also given the change to maintenance then size of the ships matter allot more than before so just adding more turrets to each fire control to reduce the chance of missing a missile is weaker than before.
I think a change to this would make the weird salvo mechanic less abusable and small salvo attacks such as fighters less problematic unless you intend to destroy entire salvos with AMM.
Please take a look at how PD engages missile salvos. As it is right now you need too many fire-controls for small missiles salvos because if one PD turret linked to a fire-control leave even one missile the next turret will be used on that one instead of shooting on a new salvo where they would score allot more missile kills.
This should be looked at from a game balance perspective in my opinion, beam PD fire-controls already are way more expensive than missile fire-controls in general.
I would suggest that PD is put on a list where the biggest is on the top (or rather the one that have the most likely higher kills). Each control then target the largest salvo in that increment that hit also sorted into some list where the largest salvo always get put on top.
Currently you need almost somewhat like 25-50% more fire-controls even against relatively small salvos such as fighters unless there is a very high chance one turret can destroy all incoming missiles in one go. You could of course put more turrets on each fire control but turrets are pretty big. There also are problems with mixing ships with smaller turrets and larger ones, if you are unlucky the smaller turret fire first and simply waste its ammunition since the larger could have killed the salvo.
A good example of the problem is... lets say you have 10 salvos of incoming missiles of 6 missiles in each salvo. You have a quad Gauss turret to engage them and you are quite likely to kill all missiles on one turret and you have ten turrets and PD fire-controls. Lets say out of the ten salvos you would theoretically miss one or two missiles. In practice this means that you get six to twelve missiles to leak and not one or two. In this instance I rather have triple turrets and a few more fire-controls but that also is way more expensive... and very taxing on certain resources. Also given the change to maintenance then size of the ships matter allot more than before so just adding more turrets to each fire control to reduce the chance of missing a missile is weaker than before.
I think a change to this would make the weird salvo mechanic less abusable and small salvo attacks such as fighters less problematic unless you intend to destroy entire salvos with AMM.
I've been giving this some thought. I think I do need to improve the situation vs small salvos. However, the way the sequence of play works is a problem for the above solution. Each salvo moves one at once, rather than all together. As a salvo attacks its target, the local point defence will shoot at it, without consideration for what other salvos may arrive later in the turn. This late in development, I don't want to mess around with the sequence of play as that would be a huge task.
What might work though is to simply lift the restriction on each fire control only engaging a single target during point blank fire. Each weapon would still be only able to engage a single salvo. So you could have the same number of fire controls and have two twin turrets per fire control in the above situation, with each turret allowed to shoot a different salvo. You would still tend to have multiple fire controls anyway for redundancy, but fewer than are required now.
EDIT: I've implemented the above. Only needed to move a couple of lines of code. Also, missiles moved in descending order of speed. I've updated that to descending order of speed then by descending order of salvo size, so the largest salvos of the same type of missile will move first.
Please take a look at how PD engages missile salvos. As it is right now you need too many fire-controls for small missiles salvos because if one PD turret linked to a fire-control leave even one missile the next turret will be used on that one instead of shooting on a new salvo where they would score allot more missile kills.
This should be looked at from a game balance perspective in my opinion, beam PD fire-controls already are way more expensive than missile fire-controls in general.
I would suggest that PD is put on a list where the biggest is on the top (or rather the one that have the most likely higher kills). Each control then target the largest salvo in that increment that hit also sorted into some list where the largest salvo always get put on top.
Currently you need almost somewhat like 25-50% more fire-controls even against relatively small salvos such as fighters unless there is a very high chance one turret can destroy all incoming missiles in one go. You could of course put more turrets on each fire control but turrets are pretty big. There also are problems with mixing ships with smaller turrets and larger ones, if you are unlucky the smaller turret fire first and simply waste its ammunition since the larger could have killed the salvo.
A good example of the problem is... lets say you have 10 salvos of incoming missiles of 6 missiles in each salvo. You have a quad Gauss turret to engage them and you are quite likely to kill all missiles on one turret and you have ten turrets and PD fire-controls. Lets say out of the ten salvos you would theoretically miss one or two missiles. In practice this means that you get six to twelve missiles to leak and not one or two. In this instance I rather have triple turrets and a few more fire-controls but that also is way more expensive... and very taxing on certain resources. Also given the change to maintenance then size of the ships matter allot more than before so just adding more turrets to each fire control to reduce the chance of missing a missile is weaker than before.
I think a change to this would make the weird salvo mechanic less abusable and small salvo attacks such as fighters less problematic unless you intend to destroy entire salvos with AMM.
I've been giving this some thought. I think I do need to improve the situation vs small salvos. However, the way the sequence of play works is a problem for the above solution. Each salvo moves one at once, rather than all together. As a salvo attacks its target, the local point defence will shoot at it, without consideration for what other salvos may arrive later in the turn. This late in development, I don't want to mess around with the sequence of play as that would be a huge task.
What might work though is to simply lift the restriction on each fire control only engaging a single target during point blank fire. Each weapon would still be only able to engage a single salvo. So you could have the same number of fire controls and have two twin turrets per fire control in the above situation, with each turret allowed to shoot a different salvo. You would still tend to have multiple fire controls anyway for redundancy, but fewer than are required now.
EDIT: I've implemented the above. Only needed to move a couple of lines of code. Also, missiles moved in descending order of speed. I've updated that to descending order of speed then by descending order of salvo size, so the largest salvos of the same type of missile will move first.
Will this somehow change efficiency of CIWS? I mostly rely on them for missile defense.
Will this somehow change efficiency of CIWS? I mostly rely on them for missile defense.
I would like to suggest the ability to refit fighters and i'm not if this was mentioned if its possible in the new version to use maintenance facilities to maintain fighters.
I tend to build a group of low fuel consumption / long range patrol fighters on nearly every colony and just being able to organically upgrade them or just even maintain them without building a space station just for that would be awesome.
I would like to suggest more advanced ruin only weapons. I recommend adding advanced gauss cannons with double the fire rate and advanced particle lances with higher damage.
I think double fire gauss would be a little overpowered :)
Maybe something on the lines of advanced railguns, with an extra shot. Having said that, I haven't really looked at ruin-only weapons yet for C. I'll revisit the weapon concepts when I do.
It might be pretty cool if you were able to specify in game setup which weapon/shields and special tech-lines you want to be available freely, ruin only ( and at what chance ) or not available at all. I would for sure up the chance a bit to discover some ruin-only techs since in my experience you had to explore alot of ruins to get anything at all ( or I was just unlucky ).
Although being able to disable some techs that's normally freely available might cause some issues for the AI unless it's a player empire only setting.
I think double fire gauss would be a little overpowered :)I honestly think that you should not get directly stronger stuff from ruins just alternatives for example meson weapon type could be rather interesting to get out of ruins (well not that interesting that we are accustomed to be able to use them from the get go) as it is rather unique among the weapon types
Maybe something on the lines of advanced railguns, with an extra shot. Having said that, I haven't really looked at ruin-only weapons yet for C. I'll revisit the weapon concepts when I do.
It might be pretty cool if you were able to specify in game setup which weapon/shields and special tech-lines you want to be available freely, ruin only ( and at what chance ) or not available at all. I would for sure up the chance a bit to discover some ruin-only techs since in my experience you had to explore alot of ruins to get anything at all ( or I was just unlucky ).Possibly though right now there's not too many possibilities in tech other than couple weapon techs that could be interesting to get from the ruins while not hindering the normal gameplay. Unless of course, you were running campaing which is heavy tech restricted on purpose
Although being able to disable some techs that's normally freely available might cause some issues for the AI unless it's a player empire only setting.
If I remember right, Master of Orion 3 had a system where by each race would only see 75-80 percent of the tech tree in any one game, chosen randomly. I'm not quite sure how you would adapt that to Aurora's tech system but its food for thought. I'm all for having increased game/SM options (SM ability to seed special techs in ruins, anyone?)
I'm not personally a huge fan of ruins providing tech that couldn't be developed by some other means. I do kindof like the idea of them potentially providing a really huge boost to some particular technology though, personally. Maybe work on some ruins for a decade or so and jump five or six levels of railgun tech.
Maybe something on the lines of advanced railguns, with an extra shot. Having said that, I haven't really looked at ruin-only weapons yet for C. I'll revisit the weapon concepts when I do.
Since maximum planetary population is now a thing, why not have the effects of radiation scale with how full the planet is? Realistically, high-intensity radiation will likely remain largely localised, and even on a planet that's undergone significant bombardment, there is still likely to be a significant part of the surface that is still habitable and safe. It should probably scale such that mildly irradiating a world will have nearly no effects if the population is at 1% of capacity, but will have severe effects at 10% and will cause total collapse at 100%. A completely irradiated planet will be dangerous even if the population is at just 0.1% of capacity.
As an expansion to the intel options I was wondering whether the ability to detect levels of jump point activity and time since use through a scan of an un-stabilised jump point. I think this would add an interesting capability when it comes to tracking NPRs back to their homeworlds and vice versa for NPRs to find routes back to player systems. Longer scans might give number of jumps in recent periods or rough tonnage of jumps based on some technobabble on anlysis of disturbances in the jump point.
SUGGESTION
I suggest changing geological survey sensors to be a military system. The original rationale for them to be civilian was so that commercial companies would build geo survey designs. Aurora has changed so that civilians no longer build geo surveyers, removing the need for civilian geo sensors.
Geo sensors also break the 'sensors larger than one hull space are military systems' rule. (The counter-point to this, that geo sensors should be reduced in size and effectiveness to one hull space to remain civilian, raises the question of why grav sensors cannot likewise be reduced -- or if they can, why they are not then civilian systems.)
I'd really love if Galactic map would center on the system you have selected on system map
I'd really love if Galactic map would center on the system you have selected on system map
I'm positive that there already is some combination of Ctrl or Shift clicking (maybe dragging) that does this. I don't have Aurora handy to check, but isn't it:I think you are talking about moving and positioning the systems on the map? I'm talking about panning the map to a system when you open the map without touching the saved position of the systems.
Single click highlights the system
Double-click opens the system
Ctrl-click draws box to move systems
Maybe it's click-and-drag that moves the map? Shift-click and drag?
I think you are talking about moving and positioning the systems on the map? I'm talking about panning the map to a system when you open the map without touching the saved position of the systems.
No, I'm talking about changing where the map is centered. I know it's possible because I have done it.I started snooping around menus since all I ever saw was opening systems menu and such and there does seem to ever open but lo and behold there's a option to center the galactic map in the task force menu it doesn't seem to work unless galactic map is open already but I need it open to map the route anyway so this should do
If you're talking about switching to & auto-centering the galactic map by double-clicking on a system name on a different window. . . I think most of them do that already. Maybe they only do that if they open the galactic window, not if it's already open.
When you refit ships are the systems replaced put into storage or just lost? I tend to have front line fleets, kept up to date with the latest equipment and second line squadrons which I would want to upgrade with the items removed from the front line fleet. In VB6 it appears systems removed in refits are just lost. I would like the option to reuse systems removed in refits.
Yes, they are lost in C# too. Should be straightforward to add them to the stockpile instead.
I would like that too, we can scrap them for a few pennies worth of resources, or re-use it for 'colonial fleets units'.
For a more "random" experience in the research area, maybe going into a different direction might be interesting to think about - whilst keeping a "kind of deterministic" system as it is now.I've also been thinking how a bit of randomness should be introduced to the research area.
I personally really, really like that individual control you have over your ship designs. It's not like in most games: Destroyer Class I, Class II, etc. But that concept doesn't transfer to the underlying technologies you have to research. They are Tech I, Tech II, etc.
In todays military, if they for example want to have a new type of fighter, they compose a list of ideas, what that fighter should be able to do. Then the underlying research begins (if that is possible and in what areas new technologies or materials would have to be researched). I imagine a similar kind of system for Aurora without the actually given limits of certain weapons, ranges, etc. : You specify what kind of ship you want to have. In a second step the game then shows you a list of needed technologies for that ship type and what research duration each part would need (the duration would of course highly depend upon what you are actually capable of and the bigger the difference to your actual state of technology is, the bigger the duration will be).
You then go back and forth between design wishes and research list until you are happy with the individual research durations (maybe you didn't like the long duration of the new armor research and toned your wishes down to a "reasonable" duration) and give permission to research the modules.
That system would enable you to
a) react to certain situations individually (like in a war you realize that your laser weapons are slighty (5000km range) to short to overwhelm a certain enemy ship type, so you give a quick research order to increase the laser range and refit your ships quickly with the new weapon type; whilst in the actual system you would have to research the next (full) step of technology - which of course would bring your range 50. 000km but would also need 18 month to research instead of 3)
b) give long term research jumps a go if your political situation allows for that in peace times
c) can control technology more precisely, be a bit more in control of your research time, etc.
Again, this would be quite an overhaul - don't know if it would be worth it.
I really like your concept of uncertain research time. Rule the Waves does it in a similar manner and it's true that it forces you to use what you have rather than plan out precisely what will be researched and when, although you still control the general direction of your research. It's a pretty big change though, need to find a ratio between remaining RP and the how likely a breakthrough is and make the relation between technology level and invested RP less direct.
Perhaps rather than checking to see if a colony is stable or not, the civilian fleet should check the manufacturing efficiency of colonies first, then check to see if they are stable or not before determining where to drop infrastructure.Maybe a new option of "Promote colonization" to spend money to increase civilian sector's willingness to interact with the colony could be added
An alternate solution to moving the trade infrastructure where it needs to be would be to remove the 25 million population cap for marking a colony as stable.
After all, if my colony has 7 million people, but has 100% efficiency, it is stable. Introducing more infrastructure increases the population, which increases unemployment, which introduces instability and unhappiness.
Yeah we've had this discussion before and it kinda opens a whole can of worms. Basically, if we want to have more "realistic" immigration/emigration mechanics, then the whole civilian sector needs to be revamped and made more detailed.
Personally I’m ok with the current high level economic function vs something detailed like, say, a Paradox grand strategy game.
Aurora already models three 'motivators' that could be used to effectively govern population movement:Yeah we've had this discussion before and it kinda opens a whole can of worms. Basically, if we want to have more "realistic" immigration/emigration mechanics, then the whole civilian sector needs to be revamped and made more detailed.Personally I’m ok with the current high level economic function vs something detailed like, say, a Paradox grand strategy game.
I'd still like a tad bit more detail, so that for example if you move alot of TN factories, shipyards and facilities to a new colony it will create alot of demand which will cause shipping companies to focus on getting more people there ASAP to fill that demand instead of sending colonists seemingly towards random destinations.
Doesn't have to be anything fancy or super detailed, just the basics of unemployment/worker shortage + connection to where people want to relocate from and towards.
I propose that turret tracking speed and ship tracking speed be additive values, not "instead of" values.
Proposed maths:
33% of ship speed is base tracking speed for non-fighters, 66% for fighters.
Turrets have their stated tracking speed.
Final weapon tracking speed would be the highest value plus 75% of the other.
...
Thoughts appreciated.
what wrong with turret fighters and the classical multi-gun FAC? :'(
I feel like if work was going to be added here, it should consider a factor for ship level agility like what missiles have. A "rudder tech" tech and component line. Perhaps a speed penalty for tracking when agility is low. A tracking penalty for attacks against when agility is high. Tracking penalty for spinals when high speed goes above rudder sizing.If used Maybe call it thruster or maneuver tech ?
In a way fighters and to a lesser extent FACs are already Superior PD units in a void outside of a campaign. Due to BFC bonus for fighters and small sensor pickup for FACs; fighters been used in a few of Steve's campaigns as fleet interceptors for PD and I have used PD FACs with long range endurance engines to escort survey ships. Outside of the void and in a campaign due to maintenance, fuel, crew, and other concerns not to mention the micromanagement to effective use such an advantage would mitigate the effects on game balance. Also as with most things in Aurora it's can be managed with self control on the players behalf of course.
Game balance. If fighters/FAC both get a bonus to tracking from ship speed + can use turrets, then they would always be the best Point Defense platform, which I don't think should be the case.
The idea that ship speed contributes more to tracking the smaller the ship does make alot of sense, but for balance you need to make turrets better for larger ships too in that case or the risk is that everyone will build as small fighters as they can get away having just engine and a minimal turret for PD.
Game balance. If fighters/FAC both get a bonus to tracking from ship speed + can use turrets, then they would always be the best Point Defense platform, which I don't think should be the case.
This touches on the element my brain can't wrap around which is that linear speed translates to tracking speed. But in a fluid, turning is the death of linear speed. The titanic was famously a fast ship that couldn't turn.The whole tracking speed calculation of the game doesn't make much sense - after all, the only thing a turret should care for is the angular velocity. If something comes at you directly, it's speed should not matter at all.
I feel like if work was going to be added here, it should consider a factor for ship level agility like what missiles have. A "rudder tech" tech and component line. Perhaps a speed penalty for tracking when agility is low. A tracking penalty for attacks against when agility is high. Tracking penalty for spinals when high speed goes above rudder sizing.
I know the game also traditionally has infinite acceleration, but at least this would bring a little acceleration factor into play without the full newtonian calculations.
The whole tracking speed calculation of the game doesn't make much sense - after all, the only thing a turret should care for is the angular velocity. If something comes at you directly, it's speed should not matter at all.
This touches on the element my brain can't wrap around which is that linear speed translates to tracking speed. But in a fluid, turning is the death of linear speed. The titanic was famously a fast ship that couldn't turn.The whole tracking speed calculation of the game doesn't make much sense - after all, the only thing a turret should care for is the angular velocity. If something comes at you directly, it's speed should not matter at all.
I feel like if work was going to be added here, it should consider a factor for ship level agility like what missiles have. A "rudder tech" tech and component line. Perhaps a speed penalty for tracking when agility is low. A tracking penalty for attacks against when agility is high. Tracking penalty for spinals when high speed goes above rudder sizing.
I know the game also traditionally has infinite acceleration, but at least this would bring a little acceleration factor into play without the full newtonian calculations.
JPs make less sense to jump though. They're links between starsystems. And while starsystems shift location relative to eachother over time, the process takes thousands of years due to the vast distances involved.
Regarding gravity tolerances, instead of allowing us to set a range greater or less than the optimum gravity, can we instead have minimum and maximum acceptable gravity boxes? Higher gravity is generally far more dangerous than lower gravity. Experiments on primates have shown that while sustained 1.5 g is survivable indefinitely, 2.0 g is lethal within an hour. However, lower gravity, even microgravity, is far, far more survivable over a long period.
Humans can optimistically survive between ~0.10 g and ~1.50 g, but there's no way to set such a range with an optimum of 1.0 g.
Regarding gravity tolerances, instead of allowing us to set a range greater or less than the optimum gravity, can we instead have minimum and maximum acceptable gravity boxes? Higher gravity is generally far more dangerous than lower gravity. Experiments on primates have shown that while sustained 1.5 g is survivable indefinitely, 2.0 g is lethal within an hour. However, lower gravity, even microgravity, is far, far more survivable over a long period.
Humans can optimistically survive between ~0.10 g and ~1.50 g, but there's no way to set such a range with an optimum of 1.0 g.
Humans can optimistically survive between ~0.10 g and ~1.50 g, but there's no way to set such a range with an optimum of 1.0 g.
Regarding gravity tolerances, instead of allowing us to set a range greater or less than the optimum gravity, can we instead have minimum and maximum acceptable gravity boxes? Higher gravity is generally far more dangerous than lower gravity. Experiments on primates have shown that while sustained 1.5 g is survivable indefinitely, 2.0 g is lethal within an hour. However, lower gravity, even microgravity, is far, far more survivable over a long period.
Humans can optimistically survive between ~0.10 g and ~1.50 g, but there's no way to set such a range with an optimum of 1.0 g.
The problem with gravity is that it is a very complex question... it is one thing that a grown adult can survive but can you actually LIVE under those environment without being in the top 10% of the human population in terms of physical and psychological fitness. How about old, sick and children not to mention infants?!?!
No... I think that in terms of actually living most human settlements would need gravitational infrastructure for most gravity and the tolerances probably are very small in real terms, exactly how much is hard to say but these are much more complex questions outside the scope of the game.
I don't believe that humans will ever be able to LIVE on Mars outside a select small elite of fit relatively young people... not unless we manage to overcome gravity issues with some advanced technology in the future for all kind of people.
Regarding gravity tolerances, instead of allowing us to set a range greater or less than the optimum gravity, can we instead have minimum and maximum acceptable gravity boxes? Higher gravity is generally far more dangerous than lower gravity. Experiments on primates have shown that while sustained 1.5 g is survivable indefinitely, 2.0 g is lethal within an hour. However, lower gravity, even microgravity, is far, far more survivable over a long period.
Humans can optimistically survive between ~0.10 g and ~1.50 g, but there's no way to set such a range with an optimum of 1.0 g.
The problem with gravity is that it is a very complex question... it is one thing that a grown adult can survive but can you actually LIVE under those environment without being in the top 10% of the human population in terms of physical and psychological fitness. How about old, sick and children not to mention infants?!?!
No... I think that in terms of actually living most human settlements would need gravitational infrastructure for most gravity and the tolerances probably are very small in real terms, exactly how much is hard to say but these are much more complex questions outside the scope of the game.
I don't believe that humans will ever be able to LIVE on Mars outside a select small elite of fit relatively young people... not unless we manage to overcome gravity issues with some advanced technology in the future for all kind of people.
That 'advanced technology' can be as simple as a big spinning structure you spend a few hours a day in.
Humans can optimistically survive between ~0.10 g and ~1.50 g, but there's no way to set such a range with an optimum of 1.0 g.
True, but there is also no need for the optimum to be 1.0g. The 'grav factor' for colonization is calculated form the nearest point in the spread, so functionally there is no difference between 0.8g +or- 0.7g and 1.0g plus up to 0.5g or minus up to 0.9g.
Maybe the people who colonize on a 0.5g world will change over time like in the Expanse series. Someone who grew up in 0.5g won't at some point be able to live on earth. So you cannot settle back those people at some point.
Yes. I was just thinking that it can happen automatically if you settle in a gravity, too far from your original one, but close enough that you can.Maybe the people who colonize on a 0.5g world will change over time like in the Expanse series. Someone who grew up in 0.5g won't at some point be able to live on earth. So you cannot settle back those people at some point.
That's why we have Genetic Modification Centres to make (literal) Martians.
Yes. I was just thinking that it can happen automatically if you settle in a gravity, too far from your original one, but close enough that you can.
Yes. I was just thinking that it can happen automatically if you settle in a gravity, too far from your original one, but close enough that you can.
I always play Aurora starting in another system, not sol. It is much more easier to roleplay for me that way. But it's such a chore to creat a suitable starting system.
Can we have an option to start in a non-sol system? Game can just generate and destroy systems until it finds a suitable one in the same way as we had to do it manually in SM mode?
On the topic of NPR and SM...
Would it be possible to either convert a NPR permanently to a player controlled race
or just sharing vision of being able to see everything they see but not changing anything?
On the topic of NPR and SM...
Would it be possible to either convert a NPR permanently to a player controlled race
Already exists in VB Aurora. What you can't do is ever go back to an Aurora-controlled NPR afterwards.or just sharing vision of being able to see everything they see but not changing anything?
In VB Aurora, turn on SM mode, then set the viewing options (generally top left corner of most windows) to the NPR of your choice.
(Note that this does not work for spoiler races.)
This was mostly meant as a nebulous "some time in the future suggestion" when I mentioned it on Discord, but people seemed to like it, so here it is.
I'd like for there to be some crossover in beam weapons tech. Basically some techs would be shared between "schools" of weapons, so that having two types of beam weapons wouldn't require twice as much research.
For example, instead of Laser Focal Size, Meson Focal Size, and Microwave Focal Size, there could be one tech, "Focusing Lens Diameter" or maybe "Energy Weapon Focal Size" with the same cost to research. There would still be Laser Wavelength, Meson Focusing, etc lines, so it's not that one tech would give you all three weapons, but rather you'd need the focusing lens diameter + one weapon specific tech. Using just lasers would still be two techs, but Lasers + Mesons would be three techs instead of four, and all three would be four techs instead of six. Meanwhile Railgun and Gauss Projectile velocity could be combined into one "Projectile Launch Velocity" tech (maybe alongside either plasma or a third new weapon), but you'd still need to research Railgun size and Gauss rate of fire separately.
The goal here is to make it more practical to use multiple types of beam weapon, and also clean up the research trees a little bit.
And I think we shouldn't do any of those things.
The names Agriculture/Environment, Manufacturing, and Service describe what they do. Not only does your proposed renaming obscure their functions, but your political labels are factually wrong for my empire of Utopian Communist silicate-based rock people. And my hive-mind machine race. And my tribal warlord pirate faction.
On top of which, I point out that the term "Public School" means literally the opposite in the US as it does in the UK. Replacing a label that clearly describes function with one upon which we disagree about what it does mean, what it should mean, and what it could mean is a bad idea.
It's easier to call them what they are - workers catering to the needs of the people, and workers catering to the need of the nation. The present labels just do not fit. Even something like Civilian/Commercial Sector and Government/State Sector is better. Unless it's hard-coded in, though, allowing the player to simply rename the sectors to whatever they want may be an acceptable compromise.What the "manufacturing sector" currently represents is the empire's military-industrial complex, and if we are going for functional names, that is what I would suggest. It is incorrect to call it the government sector or state sector, as it does not include things like teachers or doctors, which in most industrial cultures are predominantly government workers.
I think the problem is less the number of techs and more the exponential growth of costs which strongly disincentivises more 'realistic' progression. I hope we see some sort of overhaul of the tech system in v1.x.
I think the problem is less the number of techs and more the exponential growth of costs which strongly disincentivises more 'realistic' progression. I hope we see some sort of overhaul of the tech system in v1.x.
Well to be honest, most people I have seen on Youtube, playing are using research labs ineffectively.
Whats the point of having 20 labs on one tech, when 10 of these only cuts a few months of the research time?
It is better to research on a broad front maybe using 2-4 labs per tech.
2 labs cuts the research time in half. Thats a good investment.
4 labs cuts the time to a quarter. Half the investment gain per lab, compared to the above.
You get the idea...
It is straight up most efficient to give as many labs to as few scientists as possible and then exactly ONE lab to all the rest so they can train.
First, though, I want Steve to build the "bug button" he promised me: http://aurora2.pentarch.org/index.php?topic=9841.msg110045#msg110045 (http://aurora2.pentarch.org/index.php?topic=9841.msg110045#msg110045)Oh, I had completely forgotten that! Yes, 100% agreed, that would be really cool feature to have.
I suggest that you change ship based maintenance facilities so that the need population to run and as such would need 50k population in order to operate just like ground based maintenance facilities.
These ship based facilities might be a bit more expensive to build but the strategic benefit and the economic benefit in the long run (as they don't need population) to run will almost always outweigh the small initial cost benefit of building ground based maintenance facilities.
Since we can now have population anywhere in space I think that making this change will improve the logistical challenge of where you can maintain your ships in a positive way.
I suggest that you change ship based maintenance facilities so that the need population to run and as such would need 50k population in order to operate just like ground based maintenance facilities.
These ship based facilities might be a bit more expensive to build but the strategic benefit and the economic benefit in the long run (as they don't need population) to run will almost always outweigh the small initial cost benefit of building ground based maintenance facilities.
Since we can now have population anywhere in space I think that making this change will improve the logistical challenge of where you can maintain your ships in a positive way.
Since Terraforming Modules / Facilities have the exact same issue -- and have had it for 15+ years -- I doubt that it will (or even should) change.
I personally think it would be pretty awesome if you had to build orbital habitat facilities into the mobile terraformers to meet their personnel requirements and keep them running. Then you could have these truly massive vehicles you have to fly around in order to transform the atmospheres of entire worlds, which kindof makes sense to me personally.
Ostensibly you might even be able to go on the cheap and overpopulate them, so if its your style you can have cheaper orbital terraformers that have to have garrisons to keep the angry populations in check.
e: If that kind of operation were necessary to terraform a world, it would certainly make naturally habitable worlds a lot more valuable than they are now.
I personally think it would be pretty awesome if you had to build orbital habitat facilities into the mobile terraformers to meet their personnel requirements and keep them running. Then you could have these truly massive vehicles you have to fly around in order to transform the atmospheres of entire worlds, which kindof makes sense to me personally.
Ostensibly you might even be able to go on the cheap and overpopulate them, so if its your style you can have cheaper orbital terraformers that have to have garrisons to keep the angry populations in check.
e: If that kind of operation were necessary to terraform a world, it would certainly make naturally habitable worlds a lot more valuable than they are now.
This is also something I would support... it should take a considerable effort to terraform really inhospitable planets.
At least I think it would make a bit more sense and be fun at the same time.
Alternatively, restrict in some meaningful way the number of "conscripts" you can press into naval service. Right now you have an unlimited pool of perfectly functional merchant mariners. If the crew requirements for those modules were made actually meaningful, it would impose a real constraint. It could be as simple as having a separate pool of merchant mariners in addition to the naval crew pool, and refill the merchant mariner pool from various economic activities, such as spaceports, shipyards, civilian mining complexes, civilian trade goods deliveries, maintenance facilities, etc.
That way you would still have the distinction between expensive naval crews and cheaper civilian crews, but to get the cheaper civilian crews you would have to maintain an actual space-based civilian society, not just a planetside society with a space navy and barely populated industrial platforms in space.
I personally think it would be pretty awesome if you had to build orbital habitat facilities into the mobile terraformers to meet their personnel requirements and keep them running. Then you could have these truly massive vehicles you have to fly around in order to transform the atmospheres of entire worlds, which kindof makes sense to me personally.
Ostensibly you might even be able to go on the cheap and overpopulate them, so if its your style you can have cheaper orbital terraformers that have to have garrisons to keep the angry populations in check.
e: If that kind of operation were necessary to terraform a world, it would certainly make naturally habitable worlds a lot more valuable than they are now.
This is also something I would support... it should take a considerable effort to terraform really inhospitable planets.
At least I think it would make a bit more sense and be fun at the same time.
I don't think habitat modules make much sense - thats been specifically removed so that large orbital stations can be conviently build by planet industry, rather than shipyards. The orbital habitat module has been made cheaper, so you can still build orbitals if you want.
However, I've always thought thhere is a weird advantage over the ship terraforming modules rather than the planet modules. Planet terraforming modules require a very large amount of employees, but the ship terraforming modules have a minimal crew requirement. Transporting ground terraforming modules requires 125 000 cargo space, but building ship modules requires only like 100 crew and 25 000 hs. Consequently, I have never used planet terraforming modules and have always used ship terraforming modules, simply because it's easier to accumulate large numbers of them.
I'm not sure this is aproblem with the ship modules but rather than planet modules - if a ship terraforming installation can operate with 100 crew and much reduced physical volume, why does the planet module need to be so bulky and so population-intensive?
I have always been a proponent of commercial ships to have a maintenance cost in terms of wealth (say 1/10t of its production cost in wealth per year). This is a cost you would pay the same way you pay other types of facilities worked by populations. So it would just be a monthly cost no matter where the ships are and a simple way of putting some restriction on your commercial fleets. If you wanted to make it a bit more complicated then just apply the cost when the ships are in actual use.
I simply don't like the fact there are NO cost after you constructed them other than using fuel.
This way you don't have to deal with maintenance logistics for your commercial fleets but you will need to pay for their crews work and running maintenance performed by their crews.
I personally think it would be pretty awesome if you had to build orbital habitat facilities into the mobile terraformers to meet their personnel requirements and keep them running. Then you could have these truly massive vehicles you have to fly around in order to transform the atmospheres of entire worlds, which kindof makes sense to me personally.
Ostensibly you might even be able to go on the cheap and overpopulate them, so if its your style you can have cheaper orbital terraformers that have to have garrisons to keep the angry populations in check.
e: If that kind of operation were necessary to terraform a world, it would certainly make naturally habitable worlds a lot more valuable than they are now.
Alternatively, restrict in some meaningful way the number of "conscripts" you can press into naval service. Right now you have an unlimited pool of perfectly functional merchant mariners. If the crew requirements for those modules were made actually meaningful, it would impose a real constraint. It could be as simple as having a separate pool of merchant mariners in addition to the naval crew pool, and refill the merchant mariner pool from various economic activities, such as spaceports, shipyards, civilian mining complexes, civilian trade goods deliveries, maintenance facilities, etc.
That way you would still have the distinction between expensive naval crews and cheaper civilian crews, but to get the cheaper civilian crews you would have to maintain an actual space-based civilian society, not just a planetside society with a space navy and barely populated industrial platforms in space.
I have always been a proponent of commercial ships to have a maintenance cost in terms of wealth (say 1/10t of its production cost in wealth per year). This is a cost you would pay the same way you pay other types of facilities worked by populations. So it would just be a monthly cost no matter where the ships are and a simple way of putting some restriction on your commercial fleets. If you wanted to make it a bit more complicated then just apply the cost when the ships are in actual use.
I simply don't like the fact there are NO cost after you constructed them other than using fuel.
This way you don't have to deal with maintenance logistics for your commercial fleets but you will need to pay for their crews work and running maintenance performed by their crews.
No. I think that's a terrible idea.
Wait, let me rephrase that.
Sure, absolutely. . . as long as government-owned 'civilian' vessels like freighters and colony ships and fuel harvesters, etc., also generate wealth over time at least equal to the proposed cost.
What I simply don't like is the ridiculous wealth and infrastructure-generation of shipping lines, or the outright theft performed by CMCs. The ridiculous profitability of the Earth-Luna run and the near-ubiquity of starting in Sol sytem distorts the 'wealth picture' of Aurora to the point where a game not using such exploits suffers. Case in point, C#'s new wealth cap added to handle the 'conventional start to TNE conversion' massive boom-bust-echo swing is not only utterly unneeded in my games, but a huge handicap. Why? Because I build imperial freighters and colony ships, never build mass drivers, ship all my minerals (and most of everything else) by imperial freighter, ruthlessly claim every mining spot, never subsidise shipping lines, and most of all because I always start in a custom system and never with an easily habitable moon in orbit of my homeworld. My empires never have enough wealth, and the only thing that stops a massive crash ten years into space is the cushion built up during converntioanl to TNE conversion.
Having broken my game with a system I don't like (the ridiculous amount of money generated by shippping lines), you now propose to double-punish my empire by (one) taking more of the wealth I never have enough of because I use imperial shipping instead of exploiting civiilians for (two) the express purpose of implementing imperial shippping costs.
- - - -
Here's my counter suggestion: Remove all wealth generation from commercial shipping, and implement costs for moving government items in commercial hulls. You want those Auto-Mines on Ithaca III? Then do it yourself or pay someone else to do it for you.
...My number one priority with terraforming modules would be to reduce the amount of workers required.
...TF modules are better in every way than TF installations. Even if the modules had twice the cost, twice the size, twice the worker requirement, and twice anything else we could think of they would STILL be the obvious choice, simply because TF installations can't be moved.
I personally think it would be pretty awesome if you had to build orbital habitat facilities into the mobile terraformers to meet their personnel requirements and keep them running. Then you could have these truly massive vehicles you have to fly around in order to transform the atmospheres of entire worlds, which kindof makes sense to me personally.
Ostensibly you might even be able to go on the cheap and overpopulate them, so if its your style you can have cheaper orbital terraformers that have to have garrisons to keep the angry populations in check.
e: If that kind of operation were necessary to terraform a world, it would certainly make naturally habitable worlds a lot more valuable than they are now.
I think that would be pretty terrible. My number one priority with terraforming modules would be to reduce the amount of workers required. Risking fifty or one hundred thousand lives over a deadly planet seems insane.
Auto-Mines give us an excellent template. I mentioned terraforming because it is the most egregious offender -- TF modules are better in every way than TF installations. Even if the modules had twice the cost, twice the size, twice the worker requirement, and twice anything else we could think of they would STILL be the obvious choice, simply because TF installations can't be moved.
C# Aurora should absolutely rationalize all installation / unmanned installation / module options along a single system. Extrapolate terraformers and fuel harvesters from the Mine / AutoMine / Asteroid Mining Module relationship.
There actually is a real issue with being able to build and use something which have no related cost to it... I don't think the cost should be enormous... just enough so you can't spam a commercial fleet and stations without ANY support cost. I don't think that freighters or fuel ships will be very expensive... I would rather target things like terraforming stations, habitats and maintenance facilities that require no population to actually have a cost.
You also would need to pay the merchant marine and do some rudimentary maintenance on ships and neither can be free.
The exact cost would be about balance.
There actually is a real issue with being able to build and use something which have no related cost to it... I don't think the cost should be enormous... just enough so you can't spam a commercial fleet and stations without ANY support cost. I don't think that freighters or fuel ships will be very expensive... I would rather target things like terraforming stations, habitats and maintenance facilities that require no population to actually have a cost.
You also would need to pay the merchant marine and do some rudimentary maintenance on ships and neither can be free.
The exact cost would be about balance.
Okay, but you're defining imperial wealth generation as 'every centicredit collected' and then complaining that salaries and supplies aren't accounted for, and I'm defining wealth as what the government has left over after paying for all thise things. Neither one of us is more right than the other.
In your view, the merchant marine & space 'infrastructure' is a net drain on imperial coffers, and therefore should cost increasing wealth as it expands.
I counter that those things can be a net gain for "the economy", and that the wealth Aurora shows us is profit after paying for those things you are complaining aren't being paid for. I say that Aurora is simply not line-item listing that it's paying for them.
- - - -
But really, your point seems to be "you can't spam a commercial fleet and stations without ANY support cost." And whether -- or to what extent -- that is true I say depends on the empire's overall financial situation. Which means it should be debated alongside that overall financial situation. Your point (as I understand it) is essentially "Aurora empires have too much wealth; here's how I would reduce it." My point is "Aurora empires only have 'too much wealth' due to exploiting commercial shippping. If epires don't do that, they in fact do not have enough wealth."
You're right, I can't spam a commercial fleet, as hard as I try, because I can't afford it without the large wealth boost of exploiting commercial shippping lines.
- - - -
To ruthlessly summarize all of the recent posts, I think it is a fundamental part of Aurora's DNA to present the player with the choice of the cheap, worker intensive installation (e.g. Mine); the expensive, low- (or no-) manpower version (e.g. AutoMine); and the restricted (perhaps less efficient) ship-mounted module (e.g. Asteroid Miner) that has the benefit of high mobility.
So while reading through the Crusade campaign and seeing the ground forces Steve designed, it just occurred to me. Would it be possible to, once a unit is designed, be able to rename the components that that unit has? It's purely aesthetic and helps with the immersion, but I figured I'd like to see "Heavy Bolter" rather then "Crew-Served Anti-Personnel" when looking at my space marine. Again, it's purely aesthetic and immersion, but I think it could help a player get into immersing themselves a bit more seeing their Leman Russ tanks have "Battle Cannon" rather then "Heavy Anti-Vehicle".
I guess another thing is they might make a lot more sense if you had worlds that needed a degree of constant upkeep to keep them terraformed. For instance, small moons leaking an atmosphere, or some very hostile world constantly releasing toxic gases and/or burning up all of the oxygen. (maybe burning the oxygen into oxygen difluoride)
This would be very much a long term suggestion, but it might be cool to add as a sortof thing where you would have a large roving fleet of terraformer ships, and then be building/setting up smaller numbers of terraformer installations to keep the planet in good condition without having to go to all of the maintenance trouble.
Will there be any changes to how troops can be attached to ships (i. e. for protection in the event of a Tyranid boarding action :^) ) as compared to Aurora as is? Would troops be attachable based on Spare Berths or will there need to be a dedicated "barracks" component, and will it come in varying sizes? If so, how many and of what capacity? Can ships be designated to have a specific attachment of shipboard troops that are automatically "built" alongside the ship?
Will there be any changes to how troops can be attached to ships (i. e. for protection in the event of a Tyranid boarding action :^) ) as compared to Aurora as is? Would troops be attachable based on Spare Berths or will there need to be a dedicated "barracks" component, and will it come in varying sizes? If so, how many and of what capacity? Can ships be designated to have a specific attachment of shipboard troops that are automatically "built" alongside the ship?
There are various sizes of troop transport bays. I'm not at home at the moment but I think they start at 100 tons. There is no facility to auto-build troops as part of the ship construction.
I'm typically not one to do any mathematics but I like to get exact numbers of troops to help paint a better image in my head. So I did some random math and 100 tons troop transport is enough for 1460 troops (rounded up) (when you use the Average Human Weight as 137 lbs).
This also means that Fighters as Transports can hold up to 5480 troops if 400 tons of it is dedicated to 100 ton troop transports.
Hope you all enjoyed my random math moment :P
Regarding Steves latest AAR update I had a thought about the spoilers.
I was surprised the swarm/tyranids didn't eat the defenseless colonists, I think any self-respecting breed of horrible space monster should have that in their work description.
Also if they took some time going about it that might provide opportunity for rescue missions including a ground assault, stuff that makes great AAR material.
Regarding Steves latest AAR update I had a thought about the spoilers.
I was surprised the swarm/tyranids didn't eat the defenseless colonists, I think any self-respecting breed of horrible space monster should have that in their work description.
Also if they took some time going about it that might provide opportunity for rescue missions including a ground assault, stuff that makes great AAR material.
Given that the 3 tons requirement for Light Personal Weapons also includes things like all the equipment necessary to not die instantly in vacuum, a high pressure environment, freeze to death in a pool of liquid nitrogen or burn the instant you get close to a lava planet all at the same time, I would be okay with the concept of a unit/component type/modifier that's exclusive to infantry that literally can't fight in environments that aren't in the species' 0 colonization cost tolerance for a lower cost.
That'd basically be your boarding defense parties. Don't try to send them into enemy ships and expect to get a happy ending, especially if their species has very different tolerances
I don't think it would. I think the rule is 3 tons for Personal Weapon (Light) Infantry, and 5 tons for Personal Weapon Infantry. PW INF is already the baseline from which all other ground forces were developed. They have no special training, no special defenses, and -- until we added Personal Weapon (Light) Infantry -- no 'lesser version'.
Now you want another lesser version of the lesser version of combatant we already have. You think Military Police are too powerful because they might -- might -- have a submachinegun?
Or are you hung up on the idea that it takes 3 tons' displacement to feed, care for, and maintain one of them? That each troop's share of the group showers, mess facilities, machine shops, training rooms, armoury, etc., should be less than that, or should be counted in the 'headquarters' or 'supply' unit type?
--- What about a 1 Ton kit for Garrison / Security Forces? With the caveat that they require external support or else suffer damage? That support could be in the form of Logistics Units, Colonies with a great than 'X' population, Colonies with a equal to or greater than 'X' population but only if the planet has a greater than 'X' Colony Suitability Cost, and being on board a ship with Troop Transport capabilities? A 1.5 Ton kit would be also be nice as a 'heavy' option, for those empires that would splurge on 'Elite' bodyguards or for officers or something like that.
--- I rather like the idea of 'cheap' defense units; that are dedicated to defense, mind you. Such units wouldn't NEED the overhead of attacking forces because they could have everything "right at home" so to speak. Likewise, security forces for Logistics Bases, Forward HQs, or Artillery Detachments (an admittedly weird proposition, but IRL countries make weird choices all the time so... yeah). These forces would be cheap for the sake of peacetime or cheap for the sake of their rear guard status. They really should have low stats, though.
--- Garrisons could have defense equal to light infantry, but have attack that was only half of it. Security units could have defenses equal to half of light infantry, with a quarter of that attack, but be even cheaper to produce than a garrison. Security and Garrison should just be 1 Ton however, to represent the absolute bare minimum, but Security would just have cheaper stuff to reflect their more 'Specialized' role. The 1.5 ton 'heavy' versions would be better and more expensive of course.
--- Another interesting idea would be dedicated Marine Garrisons for space stations, ships w/ Troop Transport abilities and such. Same idea, with the 1 Ton kit and maybe the 1.5 ton 'heavy' kit, and the same with the caveat that they require dedicated logistics support from their ships, space stations, colonies or whatever. Not sure WHY you would put Marines on a colony, but then again I do like building colonies on airless hell holes... so yeah, there's that. (sooper sekrit soviet spess koloni for built stronk tenk) Still, while Marines would mostly be a bad choice to defend a colony, they could still be support just like any troops.
Just some thoughts, cheers! ;D
If possible a Ship Mass driver Module would be grat :) make mining ships so much easyer to handle ;D
If possible a Ship Mass driver Module would be grat :) make mining ships so much easyer to handle ;D
I've been lobbying for the opposite for quite some time. I think Aurora should remove mass drivers entirely and move everything by ship so my -- and Xenoscepter's -- privateers and pirates and militia and such have much more to do. As I understand it, mass drivers were only added because the AI to handle civilian freighters wasn't up to the job of regular mineral collection.
But if Aurora is going to keep mass drivers, it desperately needs to make their packets detectable & stealable in deep space. FAC squadrons with big nets to come along behind them and scoop 'em up, or freighters with oversize doors to fly in front of them and very slightly slow down so the minerals load themselves.
Okay, but now you have the situation where a guy whose job is supposed to be fighting is worse at it than a guy whose job is cleaning the gunk out of the soup nozzles.
What we've seen so far from Steve's AARs (admittedly quite a small sample size) is that dedicated boarding troops tear through defending crew at a ratio of 80 or 100 to 1. If we make defenders any weaker, they are going to inflict zero casualties. We're already at the point where 90% of attacker's casualties are from the drop attempt rather than fighting on board.
Any of you play that old 4x game Stars! ?
The way they did mass drivers is each tech allowed you to send packets at a specific speed (and the recipient needed to be able to handle that). So maybe you could send at what was in the game warp 10. You could intercept them by going faster, or simply intercepting from the side or in front. Worked pretty well I thought.
Yes Stars! was a great game.
Their mass driver implementation was interesting.
I liked their build queue system. You could queue up a certain amount of each building as recurring each build cycle and then put extra build items behind those and all excess build points would go to the extra items once the recurring items were done.
Actually, would it be possible to make research trees for the Ground Force components? Just generic ones to increase their effectiveness, number of shots, etc? Or maybe make it so that we can design them?
So for example there'd be a few fields
Type - Anti-Personnel, Anti-Vehicle, Bombardment, Anti-Aircraft, Autocannon, or HQ (CE would stay the same)
Size - (Light, Medium, Heavy, Super-Heavy, Ultra-Heavy)
AP - (Dropdown menu from 1 to 50)
Damage - (Dropdown menu from 1 to 60)
Shots - (Dropdown menu from 1 to 6)
CIWS - (Can be blank, choose from pre-made CIWS made for ships, just resized maybe?)
FFD - (Dropdown menu from 1 to 3)
And various research could upgrade the ranges of these higher and higher. Just a suggestion I thought of while anticipating the renaming of components when a unit is designed, thought of "why not just build the components with research to make them better, and have that be designable?". It adds a lot more variety and player decision making for Ground Forces, like when you design the weapons, powerplants, defense, engines, etc for ships, just not as intense. Also helps solve the "Can't think of anything for Ultra-Heavy" problem you mention about having a while ago in (I think) a different thread.
If no on the designing the components themselves, what about just research to improve components?
This has already been addressed; planets now have a maximum population, which largely and linearly depends on surface area of the planet, with Earth having a max of 12 billion people.
I still think that having a diminishing return of mining efforts make sense from a realistic perspective. You can only have that many mines on a surface in order to access the easy deposits, adding more should not be that effective.
I still think that having a diminishing return of mining efforts make sense from a realistic perspective. You can only have that many mines on a surface in order to access the easy deposits, adding more should not be that effective.
Okay, but now we're arguing 'how many' is "that many".
Given that Aurora mines are fixed in size, "ten Aurora mine installations" can be defined as "one mine that is ten times bigger than that one over there." If we define one Aurora automine as one hydraulic excavator plus two trucks plus one ore processor, it suddenly seems perfectly reasonable to have tens (if not hundreds) of thousands of them on Earth. Given that a basic Aurora mine produces only ten tons of refined TNE per year (per mineral, yes, but I'm going to ignore that for now) it can't be that big.
- - -
Okay, sure, this implies that manned Aurora mines are insanely inefficient, but we already had that problem. Fifty thousand people is larger than the population of Fort MacMurray, the city at the heart of Canada's oilsands mining region, and the source of over one-third of all of Canada's oil production.
I always thought of it that a "mine" is not just the bits that dig into the ground, but includes a significant chunk of supporting facilities like farms to feed the miners, schools, truck factories, workshops, entertainment and whatever else you need to have a minimally self-sufficient mining town. Low production can simply be explained by TN minerals being an absolute bugger to extract, perhaps only occurring in relatively trace amounts or whatever.
On the other hand, part of the lore of Aurora is that TN materials gather in gravity wells and that deeper gravity wells both draw in more TN materials and are harder to get to, so you might well need and have the room to place more mines on larger bodies than you do on smaller ones in a manner that's greater than linear.
So for the navy, we have the ability to assign staff officers to give bonuses to fleet operations (for fleets located in the same system as the location of the staff offices, I believe), but would something similar be reasonable to implement for Ground Forces? Sort of as a general staff that functions similarly?
I am tempted to make a chain like this:^
Platoon -> Company -> Battalion -> Regiment -> Brigade -> Division -> Corps -> Army -> Group -> Theatre -> Force
Which would require 11 ranks of GF officers but I'm not sure if I want to have a HQ vehicle in an otherwise infantry formation (rifle platoon) so I might have Company as the lowest level with an HQ for a total of 10.
I am tempted to make a chain like this:^
Platoon -> Company -> Battalion -> Regiment -> Brigade -> Division -> Corps -> Army -> Group -> Theatre -> Force
Which would require 11 ranks of GF officers but I'm not sure if I want to have a HQ vehicle in an otherwise infantry formation (rifle platoon) so I might have Company as the lowest level with an HQ for a total of 10.
I was thinking about the same but without the platoon-level .. but after reading the AA-Reports from Steve I am not so sure anymore.. it would be a micro nightmare to fill up the looses/spent-supplytrucks "per hand" with hundreds of tiny units...
if there will be an order to bring "all units" back up to strength from a destinated replacement-unit I will try to go with a 10 level-OOB ... if you have to do it by hand I will stick to a 2-level-OOB I guess..
will find out when C# is out I guess ;D
HQ units can be infantry platformed as easily as they can be vehicle platformed. And the highest level of command should probably be static platforms, for realism, or super heavy units for the 'massive crawler command base' factor you so often see in science fiction.Ah thanks for reminding me! I completely forgot that HQ's do not need to be vehicles.
Its probably not going to be useful to go down below company level, that smallest HQ are 1250 ton so that would probably be a rather typical company sized formation or a really large platoon for some reason.Steve changed that. HQs are now much more modular:
You select the HQ component and then type in the required capacity. The component cost is Capacity / 2500 and the component size is Capacity / 50 with a max of 500 tons. There is no limit on cost.So if your platoon - without the HQ - is only 50 tons, then your platoon HQ will just add 1 ton on top and cost only 0.02.
Pathfinder class Transport Shuttle 451 tons 10 Crew 53.1 BP TCS 9 TH 64 EM 0It has capacity for 300 tons, meaning that it could actually be smaller and still transport our platoon at fighter-size.
7099 km/s Armour 1-5 Shields 0-0 HTK 1 Sensors 1/1/0/0 DCR 0 PPV 0
Maint Life 3.55 Years MSP 0 AFR 90% IFR 1.3% 1YR 8 5YR 115 Max Repair 40.5 MSP
Troop Capacity 300 tons
Lieutenant Commander Control Rating 1
Intended Deployment Time: 0.5 months Morale Check Required
Large Fighter Engine (1) Power 64 Fuel Use 758.95% Signature 64 Explosion 20%
Fuel Capacity 20,000 Litres Range 1.1 billion km (41 hours at full power)
Its probably not going to be useful to go down below company level, that smallest HQ are 1250 ton so that would probably be a rather typical company sized formation or a really large platoon for some reason.Steve changed that. HQs are now much more modular:
I *already* put sensors on all my ships, but I think the increased effectiveness of small sensors is going to encourage a lot of other people to do likewise.
For anything more than that, I want to play with C# Aurora first and see what it's like before starting down the EW rabbit hole.
Its probably not going to be useful to go down below company level, that smallest HQ are 1250 ton so that would probably be a rather typical company sized formation or a really large platoon for some reason.Steve changed that. HQs are now much more modular:
Ah... that I did not remember... that makes me happy... I gladly model my forces at platoon level if possible.
I just wonder how easy it will be to fill up the templates after losses if I do though.
'Number of shots' is not how many times they actually fire. Rather, it's an abstraction to how likely they are to fire a shot that is likely to destroy a target when engaged. For things like personal weapons and crew served anti personnel that's quite a lot of shots, but things like suppression fire, covering fire and recon by fire (shooting a bunch of cover to see if the enemy responds to having been 'found') are not considered.
The abstraction is not perfect, especially given the hours long length of a given turn and a number of other factors, but things like bombardment weapons have high number of shots for their weight because those are basically abstractions of area carpeting weapons of limited effectiveness against armour, while things like AA or AV weapons tend to have heavier damage and armour penetrating stats with a single shot per turn because they either generally are kept from engaging until necessary/beneficial or just don't really get a good target presented to them that often.
I was thinking about the crew system and there are a few things that always bother me about this and that was that crew basically are immortal... crew production are completely linear and make no real sense.
I think crew production should be about skill and expected service time, so each academy would instead be able to support a number of crew in your fleet rather than producing a certain number of crew every month. They should work more like your officers as they will retire at some time in the future.
This would make crew more of a strategic resource just like in reality and not something you can just replace and have a huge ready pool of if you are at or near your capacity.
If you have already used up the available pool the only way to get more is to build more Academies and not just wait to get more. If your ships are destroyed and the crew dies there will be a significant time before you manage to acquire more crew.
You could also tie max deployment rate of ships to crew service length. If you deploy a ship that has a higher deployment range than the service length of your average crew you have to provide more living space or perhaps add some other extra cost for those ships to compensate.
You could also tie it into fleet readiness levels such as crew training, as ships abstractly receive new crew over time then fleet training should drop off as time goes by if you don't periodically perform fleet training.
Your race will then determine how many crew can be trained from each academy based on the skill level, the same as now. Service length should be a variable setting and tie into the overall pool size and cost of the crew. Even crew that you are not using should cost wealth, so just tax the economy of the total crew pool with a certain type of wealth cost every month. Even if they are not assigned they need to be constantly trained and ready to be deployed if they aren't not already.
This would be an abstract way of managing replacement and retirement of crew over time, something I think the game lacks.
Military ships should require military grade personnel or suffer some horrendous penalties in terms of skill, moral and much lower deployment times than normal. The risk of something breaking on a ship with drafted untrained personnel should be significantly higher too.
But my main concern is with what I consider the worst bug in all of Aurora. Since version 2 or so officer promotion has included the 'up-or-out' philosophy of the modern U.S. military. As a result, literally every single one of my conventional starts has followed roughly the same path; by the time my empire has researched the necessary jump point theory, grav sensors, jump engine techs (& an actual functioning jump engine design) and constructs its first survey ships, 90% of officers in the fleet have been without an assignment for two-to-three tour lengths and are "deemed surplus to requirements and released from the service."
I fear the same thing happening with crews. I want the problem solved before giving C# Aurora the ability to fire any more of my personnel.
I was thinking about the crew system and there are a few things that always bother me about this and that was that crew basically are immortal... crew production are completely linear and make no real sense.
I think crew production should be about skill and expected service time, so each academy would instead be able to support a number of crew in your fleet rather than producing a certain number of crew every month. They should work more like your officers as they will retire at some time in the future.
This would make crew more of a strategic resource just like in reality and not something you can just replace and have a huge ready pool of if you are at or near your capacity.
If you have already used up the available pool the only way to get more is to build more Academies and not just wait to get more. If your ships are destroyed and the crew dies there will be a significant time before you manage to acquire more crew.
You could also tie max deployment rate of ships to crew service length. If you deploy a ship that has a higher deployment range than the service length of your average crew you have to provide more living space or perhaps add some other extra cost for those ships to compensate.
You could also tie it into fleet readiness levels such as crew training, as ships abstractly receive new crew over time then fleet training should drop off as time goes by if you don't periodically perform fleet training.
Your race will then determine how many crew can be trained from each academy based on the skill level, the same as now. Service length should be a variable setting and tie into the overall pool size and cost of the crew. Even crew that you are not using should cost wealth, so just tax the economy of the total crew pool with a certain type of wealth cost every month. Even if they are not assigned they need to be constantly trained and ready to be deployed if they aren't not already.
This would be an abstract way of managing replacement and retirement of crew over time, something I think the game lacks.
Military ships should require military grade personnel or suffer some horrendous penalties in terms of skill, moral and much lower deployment times than normal. The risk of something breaking on a ship with drafted untrained personnel should be significantly higher too.
Very interesting concept.
I watched 'The Cruel Sea' last night (excellent 1953 B&W film - recommended viewing). I have a seen it several times over the years but hadn't watched it for a while. It starts with the newly-built Flower class corvette (escort vessel of about 1000 tons) Compass Rose and her newly trained crew in 1939 as they embark on the Battle of the Atlantic. The captain is from the merchant navy, the other officers have a few weeks training and most of the crew have never been to sea before.
The concept of gearing up for war and turning civilians into professional navy officers and crew is something that would be interesting to simulate in more depth than the current mechanics. I'll give it some thought.
No.
Cloaking technology is something that is currently space only. Hiding things on planet is currently solely the province of the Fortification mechanic IIRC.
All for that kind of thing providing it doesn't impact the freedom to produce ships, see how they work out and potentially having to abandon them or see them destroyed by external forces due to designs not performing quite as intended (Or from design errors).
Experimenting with designs to see what works and coming up with interesting compositions is quite a strong draw point for me with Aurora, and general crew with any degree of competence for ships being turned into some kind of consumable resource would probably dampen the creation side of things and encourage the recycling of the same tried and true designs over and over every campaign rather than risk being faced with not having enough crew to field ships if you suddenly need them without just sitting skipping forward months/years of time.
But my main concern is with what I consider the worst bug in all of Aurora. Since version 2 or so officer promotion has included the 'up-or-out' philosophy of the modern U.S. military. As a result, literally every single one of my conventional starts has followed roughly the same path; by the time my empire has researched the necessary jump point theory, grav sensors, jump engine techs (& an actual functioning jump engine design) and constructs its first survey ships, 90% of officers in the fleet have been without an assignment for two-to-three tour lengths and are "deemed surplus to requirements and released from the service."
I fear the same thing happening with crews. I want the problem solved before giving C# Aurora the ability to fire any more of my personnel.
This has been removed from C# Aurora and there is a new promotions and retirement system:
http://aurora2.pentarch.org/index.php?topic=8495.msg104038#msg104038
I fear the same thing happening with crews. I want the problem solved before giving C# Aurora the ability to fire any more of my personnel.
All for that kind of thing providing it doesn't impact the freedom to produce ships, see how they work out and potentially having to abandon them or see them destroyed by external forces due to designs not performing quite as intended (Or from design errors).
Experimenting with designs to see what works and coming up with interesting compositions is quite a strong draw point for me with Aurora, and general crew with any degree of competence for ships being turned into some kind of consumable resource would probably dampen the creation side of things and encourage the recycling of the same tried and true designs over and over every campaign rather than risk being faced with not having enough crew to field ships if you suddenly need them without just sitting skipping forward months/years of time.
While it makes sense to me that crew should eventually 'age out' of the pool, instead of accumulating endlessly unless lost with ship destruction, I am highly nervous about the mechanism employed to do it. If it turned out that building the size of navy I want to build, featuring the types of ships I want to use, meant that my empire needed sixty extra Academies on every major colony, I would be pissed. In the fiction of my mind I expect certain ratios of installations. Varying wildly from that harms my believability.
But my main concern is with what I consider the worst bug in all of Aurora. Since version 2 or so officer promotion has included the 'up-or-out' philosophy of the modern U.S. military. As a result, literally every single one of my conventional starts has followed roughly the same path; by the time my empire has researched the necessary jump point theory, grav sensors, jump engine techs (& an actual functioning jump engine design) and constructs its first survey ships, 90% of officers in the fleet have been without an assignment for two-to-three tour lengths and are "deemed surplus to requirements and released from the service."
I fear the same thing happening with crews. I want the problem solved before giving C# Aurora the ability to fire any more of my personnel.
I was thinking about the crew system and there are a few things that always bother me about this and that was that crew basically are immortal... crew production are completely linear and make no real sense.
I think crew production should be about skill and expected service time, so each academy would instead be able to support a number of crew in your fleet rather than producing a certain number of crew every month. They should work more like your officers as they will retire at some time in the future.
This would make crew more of a strategic resource just like in reality and not something you can just replace and have a huge ready pool of if you are at or near your capacity.
If you have already used up the available pool the only way to get more is to build more Academies and not just wait to get more. If your ships are destroyed and the crew dies there will be a significant time before you manage to acquire more crew.
You could also tie max deployment rate of ships to crew service length. If you deploy a ship that has a higher deployment range than the service length of your average crew you have to provide more living space or perhaps add some other extra cost for those ships to compensate.
You could also tie it into fleet readiness levels such as crew training, as ships abstractly receive new crew over time then fleet training should drop off as time goes by if you don't periodically perform fleet training.
Your race will then determine how many crew can be trained from each academy based on the skill level, the same as now. Service length should be a variable setting and tie into the overall pool size and cost of the crew. Even crew that you are not using should cost wealth, so just tax the economy of the total crew pool with a certain type of wealth cost every month. Even if they are not assigned they need to be constantly trained and ready to be deployed if they aren't not already.
This would be an abstract way of managing replacement and retirement of crew over time, something I think the game lacks.
Military ships should require military grade personnel or suffer some horrendous penalties in terms of skill, moral and much lower deployment times than normal. The risk of something breaking on a ship with drafted untrained personnel should be significantly higher too.
Very interesting concept.
I watched 'The Cruel Sea' last night (excellent 1953 B&W film - recommended viewing). I have a seen it several times over the years but hadn't watched it for a while. It starts with the newly-built Flower class corvette (escort vessel of about 1000 tons) Compass Rose and her newly trained crew in 1939 as they embark on the Battle of the Atlantic. The captain is from the merchant navy, the other officers have a few weeks training and most of the crew have never been to sea before.
The concept of gearing up for war and turning civilians into professional navy officers and crew is something that would be interesting to simulate in more depth than the current mechanics. I'll give it some thought.
All for that kind of thing providing it doesn't impact the freedom to produce ships, see how they work out and potentially having to abandon them or see them destroyed by external forces due to designs not performing quite as intended (Or from design errors).
Experimenting with designs to see what works and coming up with interesting compositions is quite a strong draw point for me with Aurora, and general crew with any degree of competence for ships being turned into some kind of consumable resource would probably dampen the creation side of things and encourage the recycling of the same tried and true designs over and over every campaign rather than risk being faced with not having enough crew to field ships if you suddenly need them without just sitting skipping forward months/years of time.
It is an interesting concept and something I would embrace on a Sol/Earth/Human start but its details need to be carefully thought through so that non-human/non-Earth games are not shafted. Does a Hive Mind bug race need military academies?
It is an interesting concept and something I would embrace on a Sol/Earth/Human start but its details need to be carefully thought through so that non-human/non-Earth games are not shafted. Does a Hive Mind bug race need military academies?
Another thing I have pondered in Aurora C#... would it not be time to lift the restriction on minimum resolution of sensors at 1HS and allow from 1-20 MSP as well.
Given that you very well can build fighter craft that are very small it might be a good thing. Otherwise tiny little scout ships can become VERY difficult to find even with a dedicated RES 1 active sensor.
So a small craft with a 0.1 HS engine and and 0.3 sensor could probably be about 30-35t, this little craft would still be quite potent at detecting stuff but be very difficult to find in return given its size is so much smaller than the smallest possible resolution scanner in the game. And you might even make it even smaller.
Another thing I have pondered in Aurora C#... would it not be time to lift the restriction on minimum resolution of sensors at 1HS and allow from 1-20 MSP as well.
Given that you very well can build fighter craft that are very small it might be a good thing. Otherwise tiny little scout ships can become VERY difficult to find even with a dedicated RES 1 active sensor.
So a small craft with a 0.1 HS engine and and 0.3 sensor could probably be about 30-35t, this little craft would still be quite potent at detecting stuff but be very difficult to find in return given its size is so much smaller than the smallest possible resolution scanner in the game. And you might even make it even smaller.
35 tons is about 0.7 HS or equal to a size 14 missile.
Small sensors are far more effective in C# compared to VB6, especially Res-1, so it is easier to detect missiles and other small objects. As a result, I've started adding small but effective missile detection sensors to a lot more designs. Check the comparison table in this post.
http://aurora2.pentarch.org/index.php?topic=8495.msg102701#msg102701
Another thing I have pondered in Aurora C#... would it not be time to lift the restriction on minimum resolution of sensors at 1HS and allow from 1-20 MSP as well.
Given that you very well can build fighter craft that are very small it might be a good thing. Otherwise tiny little scout ships can become VERY difficult to find even with a dedicated RES 1 active sensor.
So a small craft with a 0.1 HS engine and and 0.3 sensor could probably be about 30-35t, this little craft would still be quite potent at detecting stuff but be very difficult to find in return given its size is so much smaller than the smallest possible resolution scanner in the game. And you might even make it even smaller.
35 tons is about 0.7 HS or equal to a size 14 missile.
Small sensors are far more effective in C# compared to VB6, especially Res-1, so it is easier to detect missiles and other small objects. As a result, I've started adding small but effective missile detection sensors to a lot more designs. Check the comparison table in this post.
http://aurora2.pentarch.org/index.php?topic=8495.msg102701#msg102701
I know... I have been staring at that for some time and made some tools to do the math for me.
The reason for my suggestion is that small sensors are also ALOT more efficient as well.
A 30t scout could reasonably have 0.3HS res 100 sensor and it would take a size 50 comparable sensor to detect that at the same range. Don't remember if you allowed smaller fuel tanks than 5000 but I think I remember the smallest being 1000 or so now for small ground fighters as they don't need that much fuel, could be fitted on a small scout as well for minimal size if that is the case and make the size even smaller than 30t.
A 0.3HS resolution 100 sensor with Strength 21, Sensitivity 11 have a range of roughly 21 million km against 5000t.
A resolution 1 sensor at size 50 would spot that small sensor scout at 21 million km.
I'm just looking for options to use smaller resolution active sensors as an option so these RES 1 don't need to be inflated too much to find very small scouts.
I do understand that it would also make missile detection easier, so it would be a trade off with that as a balancing issue.
Another thing I have pondered in Aurora C#... would it not be time to lift the restriction on minimum resolution of sensors at 1HS and allow from 1-20 MSP as well.
Given that you very well can build fighter craft that are very small it might be a good thing. Otherwise tiny little scout ships can become VERY difficult to find even with a dedicated RES 1 active sensor.
So a small craft with a 0.1 HS engine and and 0.3 sensor could probably be about 30-35t, this little craft would still be quite potent at detecting stuff but be very difficult to find in return given its size is so much smaller than the smallest possible resolution scanner in the game. And you might even make it even smaller.
35 tons is about 0.7 HS or equal to a size 14 missile.
Small sensors are far more effective in C# compared to VB6, especially Res-1, so it is easier to detect missiles and other small objects. As a result, I've started adding small but effective missile detection sensors to a lot more designs. Check the comparison table in this post.
http://aurora2.pentarch.org/index.php?topic=8495.msg102701#msg102701
I know... I have been staring at that for some time and made some tools to do the math for me.
The reason for my suggestion is that small sensors are also ALOT more efficient as well.
A 30t scout could reasonably have 0.3HS res 100 sensor and it would take a size 50 comparable sensor to detect that at the same range. Don't remember if you allowed smaller fuel tanks than 5000 but I think I remember the smallest being 1000 or so now for small ground fighters as they don't need that much fuel, could be fitted on a small scout as well for minimal size if that is the case and make the size even smaller than 30t.
A 0.3HS resolution 100 sensor with Strength 21, Sensitivity 11 have a range of roughly 21 million km against 5000t.
A resolution 1 sensor at size 50 would spot that small sensor scout at 21 million km.
I'm just looking for options to use smaller resolution active sensors as an option so these RES 1 don't need to be inflated too much to find very small scouts.
I do understand that it would also make missile detection easier, so it would be a trade off with that as a balancing issue.
Would be pretty interesting if there was a branch technology tech for ECM or a similar parent technology that dealt with providing additional masking for any objects that fit within some kind of payload designation. It would essentially reflect the peak capability of your current parent masking technology tech that can't be utilised on a larger scale (For simplicity sake the point where any object has some kind of crew requirement) and on objects that do benefit from the technology it loses additional ECM bonus effectiveness with each size designation step up.
Of course it would be possible to do all of this code wise as a natural part of just how sensor detection works, but I think making it a progressive technology advancement could be more interesting from a 'game' perspective and actually introduces some kind of investment drive.
Even crew that you are not using should cost wealth, so just tax the economy of the total crew pool with a certain type of wealth cost every month. Even if they are not assigned they need to be constantly trained and ready to be deployed if they aren't not already.
I watched 'The Cruel Sea' last night (excellent 1953 B&W film - recommended viewing). I have a seen it several times over the years but hadn't watched it for a while. It starts with the newly-built Flower class corvette (escort vessel of about 1000 tons) Compass Rose and her newly trained crew in 1939 as they embark on the Battle of the Atlantic. The captain is from the merchant navy, the other officers have a few weeks training and most of the crew have never been to sea before.
The concept of gearing up for war and turning civilians into professional navy officers and crew is something that would be interesting to simulate in more depth than the current mechanics. I'll give it some thought.
I watched 'The Cruel Sea' last night (excellent 1953 B&W film - recommended viewing). I have a seen it several times over the years but hadn't watched it for a while. It starts with the newly-built Flower class corvette (escort vessel of about 1000 tons) Compass Rose and her newly trained crew in 1939 as they embark on the Battle of the Atlantic. The captain is from the merchant navy, the other officers have a few weeks training and most of the crew have never been to sea before.
The concept of gearing up for war and turning civilians into professional navy officers and crew is something that would be interesting to simulate in more depth than the current mechanics. I'll give it some thought.
Have you ever read the book (author Monsarrat)? It's been decades since I've read it, but I remember it being excellent, especially in terms of giving a sense the powerlessness of the small escorts in the early war and how arbitrary submarine attacks on convoys were (in the sense of a torpedo hit being a bolt from the blue that they had no idea was coming).
John
I know... I have been staring at that for some time and made some tools to do the math for me.
The reason for my suggestion is that small sensors are also ALOT more efficient as well.
A 30t scout could reasonably have 0.3HS res 100 sensor and it would take a size 50 comparable sensor to detect that at the same range. Don't remember if you allowed smaller fuel tanks than 5000 but I think I remember the smallest being 1000 or so now for small ground fighters as they don't need that much fuel, could be fitted on a small scout as well for minimal size if that is the case and make the size even smaller than 30t.
A 0.3HS resolution 100 sensor with Strength 21, Sensitivity 11 have a range of roughly 21 million km against 5000t.
A resolution 1 sensor at size 50 would spot that small sensor scout at 21 million km. I also would need a size 15-17 EM detector to sense that scout at that range too.
I'm just looking for options to use smaller resolution active sensors as an option so these RES 1 don't need to be inflated too much to find very small scouts.
I do understand that it would also make missile detection easier, so it would be a trade off with that as a balancing issue.
I don't necessarily thing this is a problem in and of itself... I see no wrong in small scouts being very powerful as it opens the game up for more interesting scouting potential where fog of war are more pronounced.
I know... I have been staring at that for some time and made some tools to do the math for me.
The reason for my suggestion is that small sensors are also ALOT more efficient as well.
A 30t scout could reasonably have 0.3HS res 100 sensor and it would take a size 50 comparable sensor to detect that at the same range. Don't remember if you allowed smaller fuel tanks than 5000 but I think I remember the smallest being 1000 or so now for small ground fighters as they don't need that much fuel, could be fitted on a small scout as well for minimal size if that is the case and make the size even smaller than 30t.
A 0.3HS resolution 100 sensor with Strength 21, Sensitivity 11 have a range of roughly 21 million km against 5000t.
A resolution 1 sensor at size 50 would spot that small sensor scout at 21 million km. I also would need a size 15-17 EM detector to sense that scout at that range too.
I'm just looking for options to use smaller resolution active sensors as an option so these RES 1 don't need to be inflated too much to find very small scouts.
I do understand that it would also make missile detection easier, so it would be a trade off with that as a balancing issue.
I don't necessarily thing this is a problem in and of itself... I see no wrong in small scouts being very powerful as it opens the game up for more interesting scouting potential where fog of war are more pronounced.
Except even a tiny, 0.3 HS sensor with resolution 100 is still going to have a very large GPS. I'm not sure how you arrived at that number, but per my the wiki rules:
GPS = size x resolution x ASS = 0.3 x 100 x 21 = 630
So it will get detected beyond it's own range (21.80 m km) by any EM sensor with a sensitivity greater than 12.07, which is a pathetic 1.09 HS with EM sensitivity 11.
EM sensors in C# Aurora will absolutely be extremely important, since, like with Thermal sensors, their effective range actually increases if your opponents have superior sensor technology. That tiny scout of yours will get seen from well beyond it's own range by even moderately sized passive sensors, whereupon it either gets avoided, baited, or is gunned down by interceptors.
The fact is, that in C# Aurora, active sensors areloud and are very very unlikely to actually get in range of an evading enemy fleet running on passives. Ironically, this makes thermal sensors more important - when lighting up actives is suicide, EM passives become useless as no one dares to do so unless they have a definite advantage, and only thermal sensors can actually see anything.
But even so, you can still have scouts along one vector directing missile fire from fleets approaching in a completely different vector, which seems a bit cheesy, given how small scouts can get. I think some sort of range limit for fire direction might be useful, where a fleet has to be withing x range of a scout for it to actually be able to send them targeting information. Maybe some sort of transmitter and/or receiver components?
I calculated correctly with the EM I just brainfarted and used size instead of sensitivity... ;)
As for lighting up that is a none issue as you are using such sensor craft to put active sensor on an already detected enemy... and a cheap one at that. You could use multiple sensor scouts at multiple vectors and only light them up briefly before turning of the sensor and move to another position. All the while missiles are inbound.
And how do you know they are not a cheap bait for your interceptors... ;)
Given how small and cheap they are it is efficient.
I agree that passive sensor are more important as finding the enemy before you are found yourself is key.
But these really small sensor crafts will be efficient in that they are stealth when they turn the sensor off. An active only need to be on for a few seconds to get data.., you don't run around with them on all the time. Even a small escort could have many such small scouts to send out in active patrols instead or as complement to passive scouting.
Since they are smaller than 50 ton they will be really hard to engage as they are very hard to find. It will also be very cheap with stealthy engines o such small ships so they are very hard to find on thermal sensors too.
I calculated correctly with the EM I just brainfarted and used size instead of sensitivity... ;)
As for lighting up that is a none issue as you are using such sensor craft to put active sensor on an already detected enemy... and a cheap one at that. You could use multiple sensor scouts at multiple vectors and only light them up briefly before turning of the sensor and move to another position. All the while missiles are inbound. Given how small and stealthy (reduced thermal engines are easy to give these) they are it is very hard to find them once their sensor is off.
And how do you know they are not a cheap bait for your interceptors... ;)
Given how small and cheap they are it is efficient.
I agree that passive sensor are more important as finding the enemy before you are found yourself is key.
But these really small sensor crafts will be efficient in that they are stealth when they turn the sensor off. An active only need to be on for a few seconds to get data.., you don't run around with them on all the time. Even a small escort could have many such small scouts to send out in active patrols instead or as complement to passive scouting.
Since they are smaller than 50 ton they will be really hard to engage as they are very hard to find. It will also be very cheap with stealthy engines o such small ships so they are very hard to find on thermal sensors too.
You'll need so many of them that it'll be inefficient. For painting a fleet when you already know it's exact position, sure, it might be useful to have lots of tiny scouts, but they're never going to keep up with any serious battlefleet because they're going to end up with minimal speed and endurance. Which is pretty much the exact opposite of what you wan for reconnaissance or patrol activities.
Flicking on the active sensors momentarily doesn't mean that an opponent in range won't see the EM surge and investigate. A gunship with reduced-size gauss cannons and reasonably boosted engines is both very inexpensive and hard to counter without defensive assets that will end up presenting a larger target to track, and can be reasonably expected to get close enough that subsequent pulses will paint a bright red target on the scout. A moderately-sized fleet can easily carry dozens of these things. Even bog-standard railgun PD fighters can be easily re-purposed to go scout hunting in a pinch.
And how exactly do you expect to maintain continuous sensor coverage from multiple vectors on a target that will certainly be random-walking itself, and will also be able to see your sensor from maybe twice it's own range? You're assuming that these scouts can effectively surround a likely faster and more endurant enemy, and will know exactly when they are in range so they can activate their actives at the exact same time. They're also going to be completely useless against smaller vessels.
Here's how this will go. You launch fifty of these scout boats and manoeuvre them into place. Combined, they can search an area of
74,753 quadrillion square kilometres. Except that's a circle with a radius of about one AU. Oops? You are absolutely not going to be able to find a hostile vessel hidden in any moderately-sized star system by running around blind with only moments of sensor coverage. Not before it sees you first, and avoids you or guns you down.
With how much C# will increase fog-of-war, running down any long-endurance enemy ghost fleets in a system is going to be an utter nightmare. Clearing systems is going to be very, very painful for an attacker and you can never quite be sure there won't be a minefield suddenly appearing amongst your convoy routes.
For the infantry it might be cool if there was a powered and in powered infantry version. So I could build lots of cheap unpowered infantry for some things and have an elite core of powered armoires infantry (I. e 40k). Might not be the biggest thing but would be nice for rp purposes.
So, the reason I asked for lower resolution sensors was that you could more easily paint such craft from a distance and shoot them down with small AMM like missiles. In the current form the only option is more or less a beam interceptor. The smallest beam interceptor are likely to be at least about 75-100 ton or so as the smallest Gauss is 25t for the weapon itself and then you need a fire-control, engine, fuel etc.
Quote from: Ciphascain link=topic=9841. msg117263#msg117263 date=1575621020For the infantry it might be cool if there was a powered and in powered infantry version. So I could build lots of cheap unpowered infantry for some things and have an elite core of powered armoires infantry (I. e 40k). Might not be the biggest thing but would be nice for rp purposes.
Here is an excerpt from my current c# test campaign:
Research into Improved Genetic Enhancement was completed in Y2505. With the new technology available, a new type of solder, the Space Marine, was created by Terran geneticists. Equipped with new heavy powered infantry armour, trained in boarding combat and armed with a heavy bolter that had the same firepower as a crew-served anti-personnel weapon, the Space Marine was a formidable warrior. The Terminator Space Marine was even more heavily armed and carried a Storm Bolter, which had equivalent firepower to the secondary weapon of a Leman Russ battle tank. The first Space Marine formations to be trained would be Assault Forces of thirty Space Marines, six Terminator Space Marines and two command personnel. A single Thunderhawk assault transport would carry each Assault Force. As a strike cruiser had three such transports with over a hundred Space Marines in total, the force assigned to each strike cruiser would be known as a Space Marine Company.
Space Marine
Transport Size (tons) 12 Cost 2. 4 Armour 16 Hit Points 12. 8
Annual Maintenance Cost 0. 3 Resupply Cost 6
Crew-Served Anti-Personnel: Shots 6 Penetration 10 Damage 10
Boarding Combat
Improved Genetic Enhancement
Terminator Space Marine
Transport Size (tons) 20 Cost 4 Armour 16 Hit Points 12. 8
Annual Maintenance Cost 0. 5 Resupply Cost 9
Heavy Crew-Served Anti-Personnel: Shots 6 Penetration 15 Damage 10
Boarding Combat
Improved Genetic Enhancement
hxxp: aurora2. pentarch. org/index. php?board=266. 0
In all seriousness can we just say that aurora TN beams are FTL and therefore can have range beyond the distance light can travel in 5 second increments? The sensors are already FTL, so there is clearly some way to physically interact with stuff at FTL speeds.
In all seriousness can we just say that aurora TN beams are FTL and therefore can have range beyond the distance light can travel in 5 second increments? The sensors are already FTL, so there is clearly some way to physically interact with stuff at FTL speeds.
In all seriousness can we just say that aurora TN beams are FTL and therefore can have range beyond the distance light can travel in 5 second increments? The sensors are already FTL, so there is clearly some way to physically interact with stuff at FTL speeds.
The 5 second limit isn't because of light speed - that is just the convenient technobabble.
The real reason is that longer-range beams would unbalance the game. Currently, if you are out-ranged in a beam conflict, you at least have the chance to build faster ships and close the range. You'll take damage, but it isn't game over. If beam ranges become much longer, then speed becomes irrelevant and longest range wins every time.
Shields can force the main fighting to be within 5 light seconds anyways.
I don't see the problem.
Shields can force the main fighting to be within 5 light seconds anyways.
I don't see the problem.
And how well does those shields work against particle beams ( which retain full damage out to max range ) or against mesons ( which ignore shields )?
Shields can force the main fighting to be within 5 light seconds anyways.
I don't see the problem.
And how well does those shields work against particle beams ( which retain full damage out to max range ) or against mesons ( which ignore shields )?
If the particle beams are on the attack? They cap out at 1.2mkm. They can afford to force you in closer by having a vastly cheaper FC and cheaper weaponry, in tonnage terms.
If the Particle beam ship is the one needing to weather the storm to get its kill, then with you can match their 15.5kton investment into destruction on a smaller investment of just 8200 tons with an 8x FC getting you 7300 tons to spend on shielding if your need to to force them closer. That lets a 25 damage 20 RoF 800 ton particle beam, with 10 on one ship, output 250 damage at 65% odds at 700kkm, for a sustained 8.125 damage per second, and a whopping 146 shields, for the same tonnage budget.
Do note that I've ignored the cost of carrying enough MSP to ever manage a single repair of the only firecontrol on the ship, which swings things further towards the inferior tech shield heavy ship. 80,000 MSP costs you quite a bit of tonnage, its just far too messy to work out in excel.
So, you get 4x36hs shields. Which means you have 1440 hp base, at 189.7% strength for 2732hp more shielding than them, and 4.8hp/sec regen. This lets you sustain the abuse indefinitely beyond 1.1mkm, or last for 15.595 minutes at 700kkm over which you can do 11500 damage with strength 25 hits.
If they could kite you to death now, then they still can, with a narrow 300,000 window to do it in where you cannot respond. If you can get the closure to 1000km/s, you can close that gap in just 300 seconds, 5 minutes, you'll survive 15+.
Mesons get to play with ranges up to 10.08mkm, you are gonna get a little chewed up on the way in. Have HTK to spare. Spend your excess, if any, on armor. To have that range, they'll need an FC of at least 10.08mkm, a multiplier of 58, for an FC tonnage of 1450, and 10 weapons, at 1250 tons, it costs them 13950 tons.
Now, one would think that mesons bypassing shields and armor become king. Except, in c# they don't entirely bypass armor, they may be stopped by it, you can weather this storm, somewhat. 7% chance to penetrate at maximum tech, per layer of armor. At max tech, you can make the max tech warship at around 35ktons easily enough. For a 35kton warship, putting 6 layers of armor, 6 shields, 2 16HS x2.15 engines, and 14 Large fuel + 1 Normal gives a 35kt warship that can do 70kkm/s over 20bkm and still have 22ktons for mission package. Plenty of headroom to load the 15.5kton weapons package above.
So lets drop two engine tiers to plasma core engines, .16 fuel, and drop two tiers in armor. 6 layers of armor, 6 shields, 35ktons, 9 45hs x3.0 engines, and 53 Normal Fuel tanks, and I get a warship that can do 106.5kkms over 9.5bkm 10 particle beams as above. Drop the shields and raise to sit at 6 layers of armor leaves just enough mission package to carry adequate MSP and a simple sensor, very short endurance. We've a closure of 36kkm/s if they attempt to run. A lucky strike could send us packing, we can lose 2 engines before they can close in on us.
We can close the range in 260 seconds, or 7 firing cycles before we can retaliate. So I will assume they get shots every 1340kkm of range closed in, starting from 1000kkm outwards, so the first shot as closing would occur at 10.076mkm. They have a 93% chance to penetrate armor per layer and we have 6 layers, so they have a 64.7% chance of getting an internal hit per actual hit, they've got 10 weapons. The first salvo at 9.04mkm nets 0.667 hits, 7.7mkm nets 1.53 hits, 6.36 nets 2.39, 5.02 -> 3.24, 3.68 -> 4.1, 2.34 -> 4.97, 1 -> 5.83, sum total of 22.7 hits, call it 23.
We have 207HTk in just engines, comprising 69.9% of all hits. 50HTk in fuel, 44 HTK in crew, 12 in engineering. In DAC, 415-558 is particle beams, 562-565 is fire control, 610 is search sensor, 674-682 are reactors. Those comprise just 155, out of a total of 686, or 77.4% of internal hits are going to be absorbed by systems not critical to killing the opponent - though engines can really only afford one loss.
She's short legged, but can win her fight by taking 65% engine/fuel, can't go hunting, but if they come to her...
Can you overcome a min-maxed warship on the same tonnage that has tech advantage? Probably not. Can you build a tech disadvantaged warship to kill an advantaged warship? Absolutely. Can two ships of equal tech deal with their shortcomings? Certainly.
Only way the Meson holds its range advantage for same tech, is equal or greater investment into engines, or lesser tonnage. Both require you decrease weaponry, c# imposes a penalty to having few rapidly firing weapons, that 2% failure will bite you. Over 34 shots, its 50/50 that a weapon fails. The Meson wants its range, it needs to splurge on an FC, that hands the speed advantage, or the quantity advantage, or the defence advantage tot he competitor.
To get that disadvantaged in a fight between equals, one of you wasn't teching at all, or the other was handed the advantage as a handicap.
I still don't see this as the insurmountable task its been made to be.
See attached for the particle beam/meson warships specc'ed out. Keep in mind I stacked multiple FC's to consume tonnage as if it were bigger—as if the multiplier allowed such ranges, and over stocked MSP to allow replacement of the FC, which is the biggest cost in both ships.
Thinking of the mineral situation that so often causes issues:
Refactoring mining from 'full mining rating, all materials, multiply by availability' to 'total mining potential, weighted share of minerals by availability', which would produce 10 times as much of a 1.0 mineral over a 0.1 availability mineral, or 'total mining potential, weighted share of minerals by availability, fractional loss of potential according to total of ((number of minerals)-(sum of availability))', which would make body with a small number of high availability minerals very valuable over a planet with one or two high availability minerals and low availability on the others because the mining potential loss fraction is so much lower.
Although in that case you want the ability to focus efforts on mining a certain mineral as a planetary/colony policy, or a technology that lets you lower the availability penalty.
All of these would pretty majorly impact the economic side of the game though.
The main goal here is to offer a little greater control or at least different trade offs, without the oddities that you sometimes get like where you are desperately mining a low availability deposit of a material you need while the same high availability deposit of a material you don't need (right now) just produces a bigger and bigger stockpile of stuff you can't make use of.
pre-TN engine tech isn't marked by low efficiency, it's marked by their engine power. The most basic TN engine has a 40 EP to hullsize ratio, the pre-TN Conventional Engine has a 1EP to hullsize ratio.
It'll get where you want it to get, but it's going to be slow as molasses getting there.
Efficiency doesn't offer high engine power or speed, it offers lower fuel costs for the same distance for the same weight of vessel. No seriously, range of the ship doesn't change when you shove in a stronger or weaker engine with the same engine efficiency modifier as long as the weight of the ship also remains the same.
I'm aware of that but what I am after is making pre-TN ship design feel a bit more plausibel with you needing to assign more than 1-2% of the ship mass to fuel which is silly when our real rockers today use something like 90%+ and that's still not enough for SSTO.
I was thinking that a government corruption mechanic could make for some interesting gameplay/roleplaying opportunities.
Basically, the way I see it working is as a tab on your Military Academies that goes from "uncorrupt -> lightly corrupt -> corrupt -> heavily corrupt", which can be changed one pip every (say) 5 years. Uncorrupt would work as per usual, while increasing corruptness would cause your Military Academies to generate (a lot of) wealth, representing the ability of wealthy citizens to purchase ranks in the military well above their levels of competence.
The flip side of this would be an increasing percentage of leaders who spawn with substandard or possibly even negative modifiers in their abilities. To get around the fact that players will (obviously) just not use these leaders, some (all?) of these leaders will have a "political appointment" tag - all leaders with political appointment tags must be assigned to an appropriate station before you can start appointing regular leaders, and all political appointments cannot be reassigned for a minimum amount of time (probably a year or two. )
So you'll have to dedicate some percentage of labs to idiot scientists, or small, out of the way colonies to drunken administrators, or assign a commander to your gas harvester so that they're not blocking you from assigning a promising recruit to an actual ship of the line.
Political Naval Officers maybe should also come with a "must be assigned to a military vessel" tag, so you can't just throw them into your transports. . .
I believe handwavium stipulates that even pre-TN ships are constructed in orbit. But yes fuel/mass vs delta-v would still be a major problem.
Add military ship sensor software or sensor uplink tech makes all ships with same sensor component in a single squadron or fleet having % increased sensor range - efficiency. This % can be relatively low and is here to make many ships with same sensors more viable for RP purposes primarily.
So I appreciate the... “arcane” calculations (may they never be spoken) that are used for armor, but wouldn’t it be simpler to use the volume of a spherical shell instead? Armor columns would be based on internal component volume and you can calculate any number of layers and armor strength based off the starting point of the thickness of 1 layer of strength 1 armor.
(Also I won’t have to bash my head in trying to match how armor is described as working with how it actually works >.>)
Instead of the current system using the surface area of a sphere? Nope.
Your suggestion would be equally complicated, then add one more step, and all with a less-easily-visualized formula.
So I appreciate the... “arcane” calculations (may they never be spoken) that are used for armor, but wouldn’t it be simpler to use the volume of a spherical shell instead? Armor columns would be based on internal component volume and you can calculate any number of layers and armor strength based off the starting point of the thickness of 1 layer of strength 1 armor.
(Also I won’t have to bash my head in trying to match how armor is described as working with how it actually works >.>)
The armour calculation uses the surface area of a sphere. That is more realistic than using the volume of the sphere.
Phalanx IIa class Point Defence Drone 412 tons 2 Crew 69.2 BP TCS 8.24 TH 0 EM 0
1 km/s Armour 1-4 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 0 PPV 7.4
Maint Life 0 Years MSP 0 AFR 82% IFR 1.1% 1YR 29 5YR 442 Max Repair 42 MSP
Intended Deployment Time: 0.1 months Spare Berths 2
Single Gauss Cannon R3-85 Turret (1x3) Range 30 000km TS: 30000 km/s Power 0-0 RM 3 ROF 5 1 1 1 0 0 0 0 0 0 0
Fire Control S00.4 20-7500 (FTR) (1) Max Range: 40 000 km TS: 30000 km/s 75 50 25 0 0 0 0 0 0 0
Phalanx IIb class Point Defence Drone 500 tons 4 Crew 65.4 BP TCS 10 TH 0 EM 0
1 km/s Armour 1-5 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 0 PPV 8.66
Maint Life 0 Years MSP 0 AFR 100% IFR 1.4% 1YR 24 5YR 354 Max Repair 28 MSP
Intended Deployment Time: 0.1 months Spare Berths 0
Triple 10cm C1 Infrared Laser Turret (1x3) Range 30 000km TS: 30000 km/s Power 9-3 RM 1 ROF 15 3 1 1 0 0 0 0 0 0 0
Fire Control S00.4 20-7500 (FTR) (1) Max Range: 40 000 km TS: 30000 km/s 75 50 25 0 0 0 0 0 0 0
Stellarator Fusion Reactor Technology PB-1.3 (1) Total Power Output 3.12 Armour 0 Exp 25%
Rate of Fire: 6 shots every 5 seconds
Dual GC: 5HS Turret: 1.6 HS Fire Control: 0.5 HS Sensor 0.1071 HS ECCM: 0.5
Overall Size: 7.7 HS HTK: 2
Tracking Speed: 20000 km/s ECCM Level: 1
Cost: 41 Crew: 8
Materials Required: 8x Duranium 5x Corbomite 15x Vendarite 13x Uridium
Base Chance to Hit: 50%
I wouldn't mind an expansion of CIWS, but I don't think they could get any smaller then what they are now unless you are reducing the size of the Gauss cannons themselves. As far as I know the size is simply based on a twin turret with size 3 cannons using 4x turret speed with a built in fire control and an active sensor, all using (mostly) normal sized components. The only benefit is that you don't have to set up fire controls on the ship to use them and you can stick them on civilian ships. Especially with the new auto fire control system C# is going to have, it will probably always be more space effective to set up your own point defense systems on a ship set to final defensive fire, since you wont need a bunch of fire controls and active sensors for every turret.
For some perspective, in modern day navies you really don't see more then 1 or two systems on smaller ships. USN frigates and destroyers have 1-2, cruisers have 2, carriers 4. Of course those CIWS systems are considerably smaller than the Aurora version ( they would be about .125 HS). I wonder how small a twin .5 Gauss CIWS would be? More options are always a plus, I can't imagine it would be hard to add a weapon size selection to that screen. (as an aside, I think there is a bug in VB6 aurora where CIWS uses the highest turret speed tech regardless of what you select in the design.)
My apologies, I miss read some of your post. And didn’t realize the Gauss cannons where smaller then normal, but it makes sense since they only shoot at 1000km. I still think trading off accuracy for smaller ciws size would be the way to go if you wanted the options. You don’t want to make them so small that there’s no point in other PD setups vs spamming CIWS. I’m not sure what that balance would be though. I do agree that as they stand now they are too big to be used on smaller craft. But on the other hand smaller ships are just the place for finely tuned setups where you don’t want to replicate multiple fire controls and sensors per weapon system.
Reply to Gauss PD and Ciws.
I also think that multiple Gauss PD in same ship squadron firing at the same time should suffer a small % accuracy penalty increasing with numbers of Gauss PD shooting in same 5 second phase. Logic is that it is harder to coordinate for example 100 Gauss PD cannons cowering fleet to shoot at the right targets from incoming salvo / to shorten it imagine an extremely "crowded" tower defence game where each tower kills enemy in one hit and the problem is overshooting / overkill. the more towers are in one place the more overkill happens assuming they are in one place shooting at the same time and having not an instant delivery weapon - ballistics. Then Ciws would be also more viable than current gauss pd.
This is probably more a future game version suggestion than a C# release idea, but I'd love to see a special warhead type (sort of like x-ray laser warheads) that works something like microwave lasers - it does greatly reduced damage and pierces shields and armor, but only damages engines. Call them Gravitic warheads, or Disruption Warheads, something like that. For game balance reasons, it would probably be best if they couldn't cause engine explosions - maybe even if they didn't destroy engines but temporarily knock them out, though that would mean more code work to add a new mechanic.
The basic idea is that this would make beam combat both more important and less all or nothing - you could carry a bunch of size 1 short range missiles, and if the enemy tries to kite you you can launch a few dozen and hopefully take out a few engines, even through powerful point defense. And all you have to do is slow one ship and the enemy would need to decide between sacrificing the ship or keeping together and letting you enter range. At the very least, one faster and longer ranged ship would no longer be able to effortlessly slaughter a dozen inferior ones.
It would also make piracy/boarding combat more feasible, maybe even to the point that larger warships start routinely carrying small units of marines as boarding defense. Which I consider a plus. Though even if you can easily force enemy ships to a standstill, getting boarding shuttles through heavy beam weapon defenses would probably be difficult and expensive.
I was rereading the Lagrange point stabilization rules. I did not see a mention of a default order for stabilizing Lagrange points. Have you, or will you include such default orders?
Quote from: Bremen link=topic=9841. msg117751#msg117751 date=1577771727This is probably more a future game version suggestion than a C# release idea, but I'd love to see a special warhead type (sort of like x-ray laser warheads) that works something like microwave lasers - it does greatly reduced damage and pierces shields and armor, but only damages engines. Call them Gravitic warheads, or Disruption Warheads, something like that. For game balance reasons, it would probably be best if they couldn't cause engine explosions - maybe even if they didn't destroy engines but temporarily knock them out, though that would mean more code work to add a new mechanic.
The basic idea is that this would make beam combat both more important and less all or nothing - you could carry a bunch of size 1 short range missiles, and if the enemy tries to kite you you can launch a few dozen and hopefully take out a few engines, even through powerful point defense. And all you have to do is slow one ship and the enemy would need to decide between sacrificing the ship or keeping together and letting you enter range. At the very least, one faster and longer ranged ship would no longer be able to effortlessly slaughter a dozen inferior ones.
It would also make piracy/boarding combat more feasible, maybe even to the point that larger warships start routinely carrying small units of marines as boarding defense. Which I consider a plus. Though even if you can easily force enemy ships to a standstill, getting boarding shuttles through heavy beam weapon defenses would probably be difficult and expensive.
You could even make them hurt electronics such as the fire control system. They could be something like the current harm missiles or AAGRM missiles.
in regards to the MFC/BFC idea, couldn't that just be roleplayed without limiting another players game/story?
While that is true you could say that with almost any mechanic in the game. I think this is a part that would add interesting choices in design, tactics and doctrine.
Before Aurora expands in that direction, I want to see it fix the problem of 'point defense only fires on one salvo at a time, and stupidly will prioritise a one-missile salvo over a sixteen-missile salvo.'
I assume PD still only fires on one salvo at a time?
That is, if you have a single quad RoF8 100% gauss turret, and adequate tracking speed, FC range, and crew training to achieve 100% accuracy, allowing up to 32 missile kills per increment, and face 32 single missile salvos arriving simultaneously in 8 waves, for a total of 256 missiles, I suspect you are still gonna eat 248 hits, your PD being 97% idle while it happens.
Any chance in the future that is mitigated if not resolved?
I assume PD still only fires on one salvo at a time?
That is, if you have a single quad RoF8 100% gauss turret, and adequate tracking speed, FC range, and crew training to achieve 100% accuracy, allowing up to 32 missile kills per increment, and face 32 single missile salvos arriving simultaneously in 8 waves, for a total of 256 missiles, I suspect you are still gonna eat 248 hits, your PD being 97% idle while it happens.
Any chance in the future that is mitigated if not resolved?
I can't see you ever facing that situation in the game unless you create it yourself. The AI isn't going to design ships that fire hordes of single missile salvos.
I assume PD still only fires on one salvo at a time?
That is, if you have a single quad RoF8 100% gauss turret, and adequate tracking speed, FC range, and crew training to achieve 100% accuracy, allowing up to 32 missile kills per increment, and face 32 single missile salvos arriving simultaneously in 8 waves, for a total of 256 missiles, I suspect you are still gonna eat 248 hits, your PD being 97% idle while it happens.
Any chance in the future that is mitigated if not resolved?
Any chance in the future that is mitigated if not resolved?The mitigation to that is to not have all your eggs in one basket. Steve confirmed that the AI will never do that so the only case is in human-vs-human battle scenarios, in which you should diversify your PD anyway. Yeah, that gauss turret is great at taking out one big salvo, so it needs to be accompanied by another ship that is built to take out many tiny salvos. It's not even a problem in multi-faction single-player games, only in specific PvP scenarios, IMHO.
I think that might be a strong indicator to switch from quad turrets to singles.Well, yeah, the case was specifically chosen though. One could doom stack PD and not need to worry ever. We mostly exist between the extremes, perhaps that was the main failing of my example.
Which, obviously, will only mitigate your specific situation a small amount. But I'm excited to see C#'s changes in action before requesting further PD changes.
...snipped the quote...Wouldn't fighter or FAC swarms create a similar scenario? That was more the point, I really shouldn't have made it such an extreme case. They can create multiple stacked salvos that are far smaller than available PD capability, more numerous than available PD, and larger in sum, and will repeatedly attack as need and/or reloads in a hangar permit. I assume the AI will use fighters and FACs against us with missiles? Just using missile fighters against the AI would create this scenario without even trying to.
I can't see you ever facing that situation in the game unless you create it yourself. The AI isn't going to design ships that fire hordes of single missile salvos.
...snipped the quote...Its not merely somewhat improved, as is, with what we know now, its enormously improved, and I'm happy to have it either way, overjoyed that he doesn't charge for it, just releases it to us.
I'd personally be happy to just roll with the progress that was made in that regard, since it does appear to have been somewhat improved. Though I mean, the better balanced the game becomes the more common player versus player scenarios will become.
...snipped the quote...
Like guys though, really, its kindof annoying when he improves a thing and you are like 'ree but what about these other things'. I've been in more than one community like this and its actually pretty counterproductive to be that way at this point, even if it seems to you to be an innocent enough question.
AMMs already suffer vis-a-vis beam PD and if I've understood things correctly, C# is not helping them, whereas the improvements to PD will make that aspect of defence even stronger. Limiting the number of missiles an MFC can control would nerf AMM defence even further. And since PD is getting help with the salvo issue, I really wouldn't want to limit missiles in general even further until we know for sure how much the current changes, all combined together, affect the gameplay.Definitely agreed on priority, I would note I asked if it had a chance in the future, rather than now.
...snipped the quote...
The mitigation to that is to not have all your eggs in one basket. Steve confirmed that the AI will never do that so the only case is in human-vs-human battle scenarios, in which you should diversify your PD anyway. Yeah, that gauss turret is great at taking out one big salvo, so it needs to be accompanied by another ship that is built to take out many tiny salvos. It's not even a problem in multi-faction single-player games, only in specific PvP scenarios, IMHO.
Of course, in the long run I agree that having beam PD use all their capacity instead of being idle would be great but it's not a high priority thing in the current system since I assume it would require replacing the salvo system with something else.
AMM's might need some love someday to make them more viable, yes, or a wholesale hit to PD accuracy to make it less effective, or who knows what else I can't think of now. I agree its too powerful as is once you can afford to stack competent turrets in your fleet.
AMM's might need some love someday to make them more viable, yes, or a wholesale hit to PD accuracy to make it less effective, or who knows what else I can't think of now. I agree its too powerful as is once you can afford to stack competent turrets in your fleet.
I also apologize if I came as too aggressive myself. I still do think it's rather reasonable, provided you don't build quad gauss. Generally speaking, I turret at most twin gauss cannons...
Do keep in mind, AMM do have a great advantage. You can shoot at each salvo multiple times, provided your sensors allow you. It's still a costly but...
Think of it this way. At decent tech levels, mass PD is better against normal missile salvos. However, it's very inferior against massed missiles strike due to large usage of box launchers. Against a wave of 800 missiles, you're probably better off being able to shoot AMM 6-8 or so times.
So it's a tradeoff. Will you build to defend against normal missile ships? Or against massed box launchers strikes?
All in all, I think the balance is not that bad at average tech levels. It might break at extreme tech levels, I never reached it.
I was reading through all the changes notes and found the info about the AI using fuel now in C#, while still being given a leeway to travel without fuel while searching for it, which is a great change IMO.
With the new maintenance system in place, hasn't there been anything similar done to AI ship usage of MSP? In my current 7.1 campaign, I see two NPRs (now both friendly, thankfully :)) mass hundreds and hundreds of ships. They don't need maintenance and it's frankly terrifying and... discouraging.
If similar (to fuel) changes cannot be made to AI ship MSP usage, can, at least, AI ships have some sort of rules to scrap old ships to prevent huge NPR navies?
Also, I'd welcome any features involving giving more control to Civilian sector, like moving minerals between planets the same way they can transport installations for you.
Otherwise, all the C# changes I've read about so far sound absolutely great. Thank you for your work, Steve!
Does the AI currently try to stay within (or near) the limit of its maintenance facilities, even if it doesn't technically use them? That seems like the easiest implementation without making them care about actual maintenance.
Are there any plans to replace them with some other mechanic? It seems like beam fighters have no real niche as it is.
I don't think I mentioned anywhere but I removed the fighter beam fire control. All beam fire controls now have the same rules.
Are there any plans to replace them with some other mechanic? It seems like beam fighters have no real niche as it is.
We've had multiple flavours of suggestions over the years about power plants, power management, and fuel/power budget. It would be a massive changed to everything ship-related in Aurora. I'm not sure that a complex power management system, in both ship design and ship use, is where Aurora should go or needs to go - especially as Steve already removed one micromanagement aspect: shields no longer consume fuel, as well as making Fire Control/Weapon assignments easily automated.
Power management is great in a space sim game where you control a single ship. Not so much when you could have a hundred ships/fighters engaged in battle and you might need to fiddle with them. And if you only implement power management at ship design, you're going to have a lot of people demanding that it should be a part of combat too - all power to the shields and all that jazz.
Well it works pretty well in games such as Distant Worlds which have far less intricate ship design systems. They work pretty much as described above and it work fairly well and is not difficult to comprehend or design around. There you have three different speed settings which all use different amounts of energy and thus fuel. You need fuel to power the power plants and the efficiency of burning fuel is connected to the type of power plants that you have.
I don't think it would be difficult to handle if it was changed down the line, it would at least open up several new possibilities to build ships and why you do it.
Ships already have a 'power budget' -- power plants vs capacitors -- so if this expanded to include additonal components on either side of the (in)equation I wouldn't mind.
. . . But I absolutely DO NOT WANT any sort of in-combat power allocation decisions. If I'm hurling a thirty-six vessel battlefleet versus a hundred-odd bug ships of the Arachnid Omnivoracity it would be a nightmare of micro-management. Tell me at ship design that I need extra power converters or batteries or auxiliary warp reactors for my sensor suite, fine, but don't slow down my gameplay.
I'm a big fan of Star Fleet Battles, which had an extensive power management system. However, that is a tactical game and Aurora is more at operational level. I consciously left out tactical elements such as facing, weapon arcs, hiding behind terrain, power management, etc..
Adding that type of detail would be overwhelming in large battles. Also, detail is important in tactical battle games because careful management of small edges can make a difference in a balanced engagement. Conversely, many Aurora battles are decided before the first shot is fired and careful management of small edges is often irrelevant to the outcome.
One interesting effect that I miss from Aurora is the ability to run from a fight as speed are sort of arbitrary. If tied to some power systems it would be able to build ships that can run away fast but not fire its weapon or perhaps not even use their shields. Since you would have to juggle these things you are likely to be able to sprint out of danger as the enemy can't sprint as fast AND shoot their weapons at the same time. If you design a ship around max speed and weapons firing the ship would have to sacrifice allot of other operational benefits such as total weapon power, defensiveness leaving them vulnerable in other ways.
At least there would be a wider gap between moving at chasing speed and fleeing speeds that I think would add to the tactical element of the game.
So there could be some potential interesting effects from being able to do this. I do agree with too much micromanagement... it would have to be a system that is highly automatic and streamlined to work well.
Or for simplicity if you would allow for such tactics then introduce a flanking speed mode where the ship move at say +25% speed but can't use any weapon systems or active sensors and burns twice the amount of normal fuel AND run the maintenance cycle like four times the speed or something. A ship could not even use missile fire-controls thus guide missiles in flight during such speeds, missiles would simply stop until you slow down and acquire the target again to guide the missiles. Once a ship stop moving at flank speed there should be a grace period before weapon and system can be activated, much like making a combat jump. Otherwise you could flank speed at a fleeing enemy and drop out when you are right on top of them and fire your weapons.
I'm a big fan of Star Fleet Battles, which had an extensive power management system. However, that is a tactical game and Aurora is more at operational level. I consciously left out tactical elements such as facing, weapon arcs, hiding behind terrain, power management, etc..
Adding that type of detail would be overwhelming in large battles. Also, detail is important in tactical battle games because careful management of small edges can make a difference in a balanced engagement. Conversely, many Aurora battles are decided before the first shot is fired and careful management of small edges is often irrelevant to the outcome.
Some form of increased speed with a penalty or associated risk might be OK - perhaps like Orion Pirates in SFB or the engine tuners in Starfire. I'll give that some thought.
Instead of linking engine tuning to a time limit, have it trigger a higher failure rate for engines. If the failure rate of an engine was increased by a factor of 10 or 100, then there would be a serious trade off. If tuning was a flat speed boost, I am sure Steve can figure out what kind of increased failure rate for engines would be sufficient to prevent it from being abused. If the tuning level is variable, then it could be a scalar for the increase in the failure rate.
This means ships fleeing could escape but run the risk of engine failures and detonations if they run out of maintenance supplies..
It could of course also prevent weapon firing while active.
Starfire - the distant, original ancestor of Aurora - had two game play concepts that might work here.
1) Detuning: A mode that could used for all engines. In Aurora terms, this would be an on/off function at the ship level that provides a small boost to speed (perhaps 20%), reduces sensor range, impairs fire control and has an increasing risk of damage to engines.
2) Engine Tuners. A system built into engines that provides a boost to speed without penalty for a given period. The system itself requires additional space. In Aurora terms, it would be on/off at the ship level for ships with engines equipped with tuners. As the tuners add mass without power, they would either reduce normal speed or reduce available space in exchange for a short-term, tactical speed advantage.
Starfire - the distant, original ancestor of Aurora - had two game play concepts that might work here.
1) Detuning: A mode that could used for all engines. In Aurora terms, this would be an on/off function at the ship level that provides a small boost to speed (perhaps 20%), reduces sensor range, impairs fire control and has an increasing risk of damage to engines.
2) Engine Tuners. A system built into engines that provides a boost to speed without penalty for a given period. The system itself requires additional space. In Aurora terms, it would be on/off at the ship level for ships with engines equipped with tuners. As the tuners add mass without power, they would either reduce normal speed or reduce available space in exchange for a short-term, tactical speed advantage.
You do all know this mechanic already exists in-game?
It's called Maximum Engine Power Modifier.
Pros:
It's already in the game.
You can use it anytime you want for as long as you need it.
Steve doesn't have to keep pushing back the release date to program new stuff.
It doesn't damage or destroy your ships when you use it.
No need to micromanage your ships.
You can choose how much boost you want.
Cons:
It costs more to research and build.
It uses more fuel.
You actually have to make compromises when designing your ships.
Something else to bear in mind is that faster ships are harder to hit. If the penalty for using some form of 'tuner' was relatively minor, it would be used whenever a ship came under attack, which means all weapons become relatively weaker, which means shields become relatively stronger vs armour. I have to be careful here that an apparently minor change doesn't have far-ranging effects. To avoid the above, there would have to be significant penalties to fire control.
It could also make things more difficult for the AI, depending on the mechanics.
Maybe the other suggestion, to have some form of anti-engine missile warhead, would be a better option.
You do all know this mechanic already exists in-game?
It's called Maximum Engine Power Modifier.
Pros:
It's already in the game.
You can use it anytime you want for as long as you need it.
Steve doesn't have to keep pushing back the release date to program new stuff.
It doesn't damage or destroy your ships when you use it.
No need to micromanage your ships.
You can choose how much boost you want.
Cons:
It costs more to research and build.
It uses more fuel.
You actually have to make compromises when designing your ships.
That would not really be the same thing. The whole point were a way to retreat for both sides as neither can use weapons during the boosted engine usage, thus you could retreat to a safe zone where you can defend and the enemy can't follow you or they will suffer defeat.
Something else to bear in mind is that faster ships are harder to hit. If the penalty for using some form of 'tuner' was relatively minor, it would be used whenever a ship came under attack, which means all weapons become relatively weaker, which means shields become relatively stronger vs armour. I have to be careful here that an apparently minor change doesn't have far-ranging effects. To avoid the above, there would have to be significant penalties to fire control.
It could also make things more difficult for the AI, depending on the mechanics.
Maybe the other suggestion, to have some form of anti-engine missile warhead, would be a better option.
For missiles I would like two ways to mess with an opponent. A missile with a microwave type warhead and a way to target engines using passive thermal sensors that would have a chance to hit engines directly through armour. A microwave warhead could probably also work with EM sensors on missiles which then would increase the hit chance of such missiles or the chance to effect the enemy ships electrical components.
I also think that active missiles should do something beside homing in such as adding extra to hit chance depending on the time the missile are able to track the target. Something like the tracking time bonus for beam weapons.
This would make it more important with hardened sensor systems and perhaps add an armour component to the engine design. Perhaps also make reduced thermal engines harder to hit or simple the less thermal signature the harder it is to hit with such missiles.
You could also allow engines to have degrading performance from damage so can receive partial destruction as one solution. Engines could also be hit through armour with beam weapons besides chock damage. I'm pretty sure that armour engines will be very difficult with 100% certainty.
I don't really like the idea of microwave missiles. There's already a microwave beam weapon, and I don't think doubling up on the same concept adds anything. An anti-engine missile wouldn't be meant as a general purpose weapon, but instead serve the important purpose of making beam combat less all or nothing as it would provide a way to force the opponent to let you close in.
I don't really like the idea of microwave missiles. There's already a microwave beam weapon, and I don't think doubling up on the same concept adds anything. An anti-engine missile wouldn't be meant as a general purpose weapon, but instead serve the important purpose of making beam combat less all or nothing as it would provide a way to force the opponent to let you close in.
The trick here is going to be making anti-engine missiles a special situation, rather than one that would used all the time. They need to have some disadvantage as well as the anti-engine advantage.
Rather than 'special' missiles, one option would be that missiles that include a thermal sensor(even if ship-guided) are more likely to damage engines if they score internals, while missiles that include an EM sensor are more likely to damage electronics if they score internals. The larger the EM/Thermal seeker, the more likely the damage is directed at engines/electronics. That has the disadvantage that the warhead will be smaller or the range shorter, so it wouldn't be used in general. Also a very easy fix to the code, as all the components already exist.
As for anti-engine missiles... how about no? Must we have YET another thing that make missiles better than beam weapons? Yes, yes, missiles have to be produced and can be intercepted. But that aside, they're incredibly powerful already. Put in a anti-engine missile, and beam warships are now immediately completely useless. You just need ONE missile to hit, and your beam dreadnaught is dead in space.
Load your fighters with 10 boxed launcher anti engine missiles, shoot, go away because the enemy beam warships cannot do anything now.
Also, anti-engine missiles would probably just intensify the punching-down effect in my opinion, because it seems to me it would be really hard to explain why the higher tech side wouldnt just use it as well (from outside of range of the lower tech side because they have better tech) and then leave them both dead in space and out of weapon range, to be picked off at the leisure of the higher tech side.
Also, anti-engine missiles would probably just intensify the punching-down effect in my opinion, because it seems to me it would be really hard to explain why the higher tech side wouldnt just use it as well (from outside of range of the lower tech side because they have better tech) and then leave them both dead in space and out of weapon range, to be picked off at the leisure of the higher tech side.
That's the thing, though, anti-engine missiles would counter kiting even if both sides have them (the same is not true of engine tuners). If you're trying to hold the range open, and one of your ships loses half its engines, you have to choose between letting the enemy close or sacrificing that ship. If you're trying to approach the enemy and one of your ships loses half its engines, you can just let the slower ship fall out of formation.
That would not really be the same thing. The whole point were a way to retreat for both sides as neither can use weapons during the boosted engine usage, thus you could retreat to a safe zone where you can defend and the enemy can't follow you or they will suffer defeat.
The purpose of anti-engine missiles is to make beam warships much more effective, not less. In the current game, a dozen of your beam dreadnoughts would be massacred by a single beam destroyer that was faster with a longer range, which makes them very unfeasible to use. Add a bunch of very short range, very hard to shoot down anti-engine missiles with a range of 2-3m km, and now suddenly those dreadnoughts can force an enemy into their range.
That would not really be the same thing. The whole point were a way to retreat for both sides as neither can use weapons during the boosted engine usage, thus you could retreat to a safe zone where you can defend and the enemy can't follow you or they will suffer defeat.
This is why I raised this very problem in my first proposal to this and said that weapon fire controls would not work for a minute or so after the boost is turned off, much like when you do a combat jump through a jump point. You also could be sitting completely still in space for that time before you can start moving again and be rather vulnerable.
For retreating this would be a way to move where you have reserves or some reinforcement arriving.
This would also make it more reliable to split up your forces as it would be easier for a weaker part to retreat towards a stronger part, even for beam combat purposes.
I really think it would make the tactical game more interesting and less decisive as it would give both sides a possibility to disengage if they have roughly equal tech and speeds, that at least is true in a multi-faction campaign. If you have two rather different opponents with tech levels there might not be much difference but that is the same now as well.
Given that the beam dreadnoughts are given to be larger and slower to begin with, they would be both more vulnerable to anti engine missiles and lower in numbers, meaning presumably they would require less anti engine missiles to disable. I still think it would fundamentally favor the faster people regardless.
e: Ideally you would build your dreadnoughts with the same engine percentage as the enemy, so given equal tech the smaller ships wouldn't really be faster anyhow.
This is why I raised this very problem in my first proposal to this and said that weapon fire controls would not work for a minute or so after the boost is turned off, much like when you do a combat jump through a jump point. You also could be sitting completely still in space for that time before you can start moving again and be rather vulnerable.
While that is a possible use, the opposite is also true. If you have technological equivalent fleets, a beam weapon fleet is very often the one that is built to be faster. This is by design, after all you need to get in range to shoot.
And so, say you have two fleets. A missile fleet, and a beam fleet. Supposing the missile fleet can surpass the beam fleet point defense (because if not, of course the point is moot), an anti-engine missile like you propose would mean that the missile fleet can escape 100% of the times. Just load a wave of anti engine missiles, disable the enemy ships' engines, leave the system.
It's a get out of jail free card.
Mind you, I would be much less against this if beam weapons were not capped at 1.5 million km range... but as it is, if you take speed away from beam warships, they're literally just expensive junk.
I don't really like the idea of microwave missiles. There's already a microwave beam weapon, and I don't think doubling up on the same concept adds anything. An anti-engine missile wouldn't be meant as a general purpose weapon, but instead serve the important purpose of making beam combat less all or nothing as it would provide a way to force the opponent to let you close in.
The trick here is going to be making anti-engine missiles a special situation, rather than one that would used all the time. They need to have some disadvantage as well as the anti-engine advantage.
Rather than 'special' missiles, one option would be that missiles that include a thermal sensor(even if ship-guided) are more likely to damage engines if they score internals, while missiles that include an EM sensor are more likely to damage electronics if they score internals. The larger the EM/Thermal seeker, the more likely the damage is directed at engines/electronics. That has the disadvantage that the warhead will be smaller or the range shorter, so it wouldn't be used in general. Also a very easy fix to the code, as all the components already exist.
This seems like it would make it completely impossible to ever engage a ship with beam weapons if they didn't want to, since you couldn't catch them, for what it's worth. Basically the current situation but making it so that a faster beam ship couldn't even force a missile ship into range once it was out of missiles, since the missile ship could just turn on its tuners if the beam ship was almost in range, and the beam ship wouldn't be able to engage even if it did use its tuners.
In most of my multi-faction games beam combat are so dangerous that sides only engage in them if they are very certain to win and it become very one sided. They almost never engage if numbers are even close to similar as they tend to be very one sided eventually with one side being totally wiped out and you never want to be that side.
The disengagement boosters would also help escape from missile fights. Its possible to fight at a distance where either side can choose to run away and then the incoming damage is potentially very significantly degraded. The best way to disengage presently is to turn around and run away such that the missiles run out of range before they can reach you. Thats also a big part of why missile engagements are less decisive. Boosters would probably mainly enhance that aspect.
The disengagement boosters would also help escape from missile fights. Its possible to fight at a distance where either side can choose to run away and then the incoming damage is potentially very significantly degraded. The best way to disengage presently is to turn around and run away such that the missiles run out of range before they can reach you. Thats also a big part of why missile engagements are less decisive. Boosters would probably mainly enhance that aspect.
True, they'd have some effect on missiles (though if it locked your weapons off for a minute after disengaging, the threat of being hit by missiles when your anti-missile defenses couldn't fire would be a major one), but much less of an effect than they'd have on beams. It's a non-symmetrical change that favors missiles, and that's still a relative boost to missile ships.
You'd also have to keep the tuners running much longer during a missile engagement, greatly increasing the chance of burning out your engines.
The issue that needs to be resolved is not a lack of a retreat option, but the all or nothing going nature of most beam fights. Steve even said it in the latest update to Crusade, his entire fleet could have been lost to a single ship and there was nothing he could have done about it, which isn't really interesting or fun. Any mechanic or change that resolved this issue is good, in my books.
The issue is less on the side of things being too hard, but things being too easy. Players will, very consistently, be faster then the enemy because they understand that speed is, in the context of a beam fight, the most important mechanic. Players also tend to be farther ahead down the tech line. This makes wars trivial because you literally need one offensive ship and point defense and you're good. Literally one gun is a it takes. Having a speed and range advantage should be a big deal but it shouldn't be the only relevant variables, it makes both ship design and fighting boring.
I'm against disengagement in general. At least this type of disengagement, a sudden "speed boost" that lets you escape. I'm all in favor of playing with sensors and such.
Disengagement by speed or climate interference was a thing in battles in the past. The more high tech a conflict, in space, the less disengagement makes sense.
You say it offers more tactical options. I say that it makes decisions less important. Because well, you can always "flee" albeit at a cost.
I would suggest not thinking of WW2 fights. Nowadays, with radars, satellites and the like, Similar "tech" nations would no really be able to retreat once committed, not in air nor in naval warfare.
I feel that this would be a meta-change to try to tailor the game in order to make wars last longer, while they should not.
I remember reading one of those declarations by the pentagon, I think it was, that nowadays a non-nuclear war between powerful nations (say China-Russia) would be over in a matter of hours, because in that period of time one of the two would lose the capabilities to strike the other, and be reduced to trying to defend with ground troops.
The issue is less on the side of things being too hard, but things being too easy. Players will, very consistently, be faster then the enemy because they understand that speed is, in the context of a beam fight, the most important mechanic. Players also tend to be farther ahead down the tech line. This makes wars trivial because you literally need one offensive ship and point defense and you're good. Literally one gun is a it takes. Having a speed and range advantage should be a big deal but it shouldn't be the only relevant variables, it makes both ship design and fighting boring.
Let's say that ships that stand still have full range of fire controls while ships that move get a 0.5 modifier if moving at full speed. That would still make range important but would still make older ship dangerous if enough in numbers.
Let's say that ships that stand still have full range of fire controls while ships that move get a 0.5 modifier if moving at full speed. That would still make range important but would still make older ship dangerous if enough in numbers.
That won't work, the faster, longer ranged ship would boost out of the others range, come to a stop and fire, boost on, repeat. Only if there was some cool down to this effect, the range advantage you need to have would increase. But then the side with lower range would see the other stop, and could just turn away and avoid the attack, turning the battle into a micromanagement dance.
I don't understand, do you mean if boosting then you can still shoot but at a halved range?
How many times do one have to repeat that it HAS to be together with a block timer of fire-control once you end the boost of at least a few minutes like a combat jump... perhaps even more. Then it would work just fine. I hope that this is clear by now... ;) ...there need to be a timer on the change from moving to standing still as well... perhaps the same penalty.
Using boost in this way would not work at all... dancing in and out would not work that well either as the one who stand still would get too many opportunities to fire without return fire most of the time. If you have the advantage you would just run into a good firing position and try to hold that distance. But then at least both side would be able to fire and the weaker side could still defend themselves and do damage and if numerous enough could potentially overwhelm a technological superior opponent that then would have to retreat.
There would still be a benefit to the technologically superior or faster fleet as they have more tactical options available.
The result is simply that moving cost you accuracy... a slower fleet can run away but the faster fleet will have to run the gauntlet into a good firing position and the slower fleet could defend itself. A fleet with lower range could still fight the enemy or try to run away, if the enemy follows they are both out of range... so the fleet with lower range can still win the fight if it has stronger beam offensive power but lower range and slower engines, but the other side could always retreat when needed.
It would be a more fair system for everyone involved. A fleet would only be invincible ones their range are close to double that of the other fleet which is a gap I certainly could live with.
If boosting ships had half the range, the faster/longer range ships could still slaughter the slower/shorter ranged ships unopposed. Let's look at the scenario in detail:
Side A has a tech advantage - their ships are slightly faster and their fire controls have a slightly better range. Side B is one tech tier lower, but we'll say they have twice as many ships - any exchange of fire will still favor them.
Side A approaches, but sits outside Side B's range and starts firing. Side B has two choices - tune their engines or don't tune. If they don't tune, they'll eventually be destroyed, so they really have one choice. They turn on their engine tuners and either approach or flee - it doesn't matter.
Side A turns on their tuners as well and now starts maintaining half the range they previously were - they can still fire and Side B still can't. Side B turns off their engine tuners and starts waiting for whatever period for their fire controls to recover - Side A flies back out of Side B's range and then turns off their engine tuners. When they recover they can resume firing but Side B can't.
No matter what Side B does in this scenario, the same problem continues - they can't fire back, and they can't escape.
In the scenario where engine tuning disables weapons entirely, then instead we get a situation where Side B still can't ever fire on Side A, but may be able to escape. Which sounds good except I think the net result of it being far more difficult to ever force a beam engagement is to never almost build beam ships, since the current role of beam ships is basically "force your enemy into combat once they're out of missiles".
it also would mean that you need a considerable advantage in technology to become invincible in beam combat and that a technologically inferior fleet could win if they have enough ships in many situations. It would make combat between beam ships behave more like combat between missile ships of different technological standards.
it also would mean that you need a considerable advantage in technology to become invincible in beam combat and that a technologically inferior fleet could win if they have enough ships in many situations. It would make combat between beam ships behave more like combat between missile ships of different technological standards.
It wouldn't do this for the reasons I already covered, whether it involved engine tuning or not. Just fly to a point that's inside your range but outside theirs and stop; if they fly towards you, they're now getting the reduced range penalty too. It wouldn't change anything about beam combat other than adding extra micromanagement.
But that is pointless as that is the same as simply avoiding to fight as the other side could just move out of range and sit in return... so it would be pointless. The AI would never do it and the AI could simply move outside your range indefinitely until you tire of doing it and in a multi-faction human campaign you would not do it as it is simply pointless.
Either you commit to engage or you don't and try to run away using boost. If the enemy still can catch you then you are in bad luck and the tech gap simply is too big.
Bremen beat me to it, these changes don't do anything but add micro. Same goes for boost, if the slower fleet kicks on boost but can't fight, its not helping at all, and if boost becomes key to beam combat, everyone will just bring boost. So if your boost is fast enough to outpace the otherwise superior enemy, they'll just kick on their superior boost and now its back to the same problem, except nobody can fire their guns without chilling dead in the water for a while. I guess its good for running away?
I'm still not entire sure why we're trying to create a complex system to resolve a problem that has already been solved. The beam knife fighting problem of minor advantages being an all or nothing win was already solved with the implementation of missiles, you are supposed to use combined arms. A modern guns only warship would be shredded it it tried to face down a faster opponent with longer range on its guns, and the solution was cruise missiles. Beams are supposed to be secondary batteries, and the risk to using them instead of your missile armament is being at that disadvantage to your enemy.
The only thing I can think of that doesn't involve ridiculous amounts of micromanagement, while also stopping the worst of beam kiting, is have it based on direction. if you opponent is within a given angle from your rear (based on your movement that turn) then you suffer a range malus for firing into your engine wake or something technical like that. Superior opponents will retain their speed advantage, but can't fire as far directly backwards. This means you can't just fly directly away from the enemy and use the full range advantage, you need to either go oblique, or turn into them, both of which give an inferior enemy a chance to close. If your speed or range advantage is so overwhelming that they still cannot deal with it, that's fine, such a massive tech difference should cause problems.
Edit: On retrospect, I'm not even sure that'll help, you'd just make larger laps of leaving then closing the range. I still think the solution to this problem is "Bring missiles"
But that is pointless as that is the same as simply avoiding to fight as the other side could just move out of range and sit in return... so it would be pointless. The AI would never do it and the AI could simply move outside your range indefinitely until you tire of doing it and in a multi-faction human campaign you would not do it as it is simply pointless.
Either you commit to engage or you don't and try to run away using boost. If the enemy still can catch you then you are in bad luck and the tech gap simply is too big.
That was discussing the situation without boosting. You said it meant an inferior tech but numerically superior force could actually win and I was pointing out that it didn't do that at all. The enemy force can't move outside of your range, because once they do their weapons have the same .5x range modifier, so you move to .5x your range which is outside .5x their range and you're able to fire unopposed. Then if they stop moving, before their range goes back to normal you can move back out to 1x. If they move after that, you repeat everything, if not you eventually get back to 1x range modifier too and they're dead.
I've already pointed out why I think your separate suggestion for engine tuning is also a bad idea, but for different reasons.
Yes... you are partially right... but there would be no need to do that... you would move into a decent range and be at a disadvantage for a while and after that you would get advantage in accuracy (as your fire-control range is better). Now it is a mettle of whose fleet is stronger. Once either side feel they are loosing they can try to disengage and retreat. This would produce partial destruction of a fleet rather than one fleet always ending up destroyed every time.
Boosting would be necessary for both sides having a chance to flee in combat situation where the difference in tech is not too great. It might not work all the time but it will at times do so.
So.. yes... it would give a power boost to the one who are defending in beam combat. I don't see a direct problem with that.
I'm not sure how well disengagement would work, now that I think on it. Assuming both beam only forces have boost, if the inferior group flipped on boost and turned tail for a jump point, the superior force can just flip on their boost and head for the same jump point, likely reach it first (depends on the speed advantage and the range before the retreat was called), and drop back to regular drives and intercept. If the range was great enough that the inferior defender can make it before the attacker, then they could have achieved the exact same retreat in a version of the game where boost never existed.
The only reason we don't see this happen currently is the superior force can engage, instead of bypassing them to sit at the jump point.
Yes... you are partially right... but there would be no need to do that... you would move into a decent range and be at a disadvantage for a while and after that you would get advantage in accuracy (as your fire-control range is better). Now it is a mettle of whose fleet is stronger. Once either side feel they are loosing they can try to disengage and retreat. This would produce partial destruction of a fleet rather than one fleet always ending up destroyed every time.
Boosting would be necessary for both sides having a chance to flee in combat situation where the difference in tech is not too great. It might not work all the time but it will at times do so.
So.. yes... it would give a power boost to the one who are defending in beam combat. I don't see a direct problem with that.
I mean, yeah, a fleet could voluntarily move into range and fight it out instead of winning without ever being shot at. This is also true in the current version of the rules. But in both the current version and your proposed changes it wouldn't happen, since the fleet with the range and speed advantage wouldn't voluntarily give up its advantage.
As for boosting, yes, I get that you want a fleet to be able to disengage if it's losing beam combat. But the problem with that is that if either side can disengage from beam combat whenever they want, the result will be beam combat never happening, because one side is always going to be at a disadvantage, and the result of that is going to be both sides only being pure missile combatants because there's no way to force beam combat. At this point we're just repeating ourselves.
I'm not sure how well disengagement would work, now that I think on it. Assuming both beam only forces have boost, if the inferior group flipped on boost and turned tail for a jump point, the superior force can just flip on their boost and head for the same jump point, likely reach it first (depends on the speed advantage and the range before the retreat was called), and drop back to regular drives and intercept. If the range was great enough that the inferior defender can make it before the attacker, then they could have achieved the exact same retreat in a version of the game where boost never existed.
The only reason we don't see this happen currently is the superior force can engage, instead of bypassing them to sit at the jump point.
No... that no shot scenario will never occur as you will have to get in range if you want to fight unless you have twice the range. It would not work as you believe it would as there is a timer on when you can fire at full efficiency after moving. If the slower fleet can't flee there is no point if them moving unless you move out of their range while being still, but that is akin to not wanting to fight and would be a pointless move to make if you want to attack.
No... that no shot scenario will never occur as you will have to get in range if you want to fight unless you have twice the range. It would not work as you believe it would as there is a timer on when you can fire at full efficiency after moving. If the slower fleet can't flee there is no point if them moving unless you move out of their range while being still, but that is akin to not wanting to fight and would be a pointless move to make if you want to attack.
Umm, no, you are completely wrong there, and I've repeatedly tried to explain why. Ok, let me try again.
Fleet A moves at 5,000 km/s and has a range of 200,000 km. Fleet B moves at 6,000 km/s and has a range of 240,000km. Whenever they move a fleet has its range cut by 50% for 60 seconds (or whatever, these numbers only matter for the example).
Fleet B moves to a range of 201,000km and stops. Fleet A now has three choices:
A) Remain stationary. After 60 seconds, Fleet B starts shooting them and they die.
B) Approach Fleet B. Fleet B uses its superior speed to hold them at a range of 101,000 km and shoots them until they die.
C) Retreat from Fleet B. Fleet B uses its superior speed to close to a range of 101,000 km and shoots them until they die. If Fleet A stops at any point, Fleet B shoots them for 40 seconds, then backs away to 201,000 km and stops as well - at this point this whole scenario repeats, but with Fleet A already damaged.
This is the scenario without boosting. Boosting is a different discussion, and has its own isssues. But even with boosting, there's no way for the slower and shorter ranged fleet to ever get to fire.
maybe, we can split off the discussion about merits and flaws of a boosting/tuning/afterburner/whatacallit to a seperate thread?
also suggestion would it be possible to assign FAC's (Sub 1000 ton ships) to squadrons?
maybe, we can split off the discussion about merits and flaws of a boosting/tuning/afterburner/whatacallit to a seperate thread?
maybe, we can split off the discussion about merits and flaws of a boosting/tuning/afterburner/whatacallit to a seperate thread?
also suggestion would it be possible to assign FAC's (Sub 1000 ton ships) to squadrons?
Squadrons don't exist in the VB6 sense. The new naval organisation in C# will allow you to create 'sub-fleets' that include any type of ship.
The problem here is that you assume that fleet A wants to escape... in this scenario then I agree that fleet B will win as it is superiors in all three categories of speed, firepower AND range... they should win.
If fleet A have twice the firepower it can just stop and wait for fleet B to fly into their max range and start firing on it as it approaches, once they get to 101.000km they don't run... they keep fighting and will win as they still have superior firepower, even if fleet B get to fire at full range after 60 seconds. This is the point...
If they are inferior they can still make a stand and do SOME damage to the enemy fleet.
The faster fleet can still disengage as it is faster when it realise it is weaker in fire-power. But even if fleet B is stronger in fire-power then fleet A might still do SOME damage to fleet B and so the reinforcement that is coming will force fleet B to retreat instead of fleet B destroying that one too without breaking a sweat.
If fleet B moves outside of fleet B at 201.000km and stop then fleet A moves to 241.000km and stops and you can repeat that indefinitely which simply is ludicrous to do... either you commit or you don't. Sure fleet B can start following fleet but A can stop at any point and B will come under fire or have to move outside that 200.000km before A can fire. Sooo... you either commit to the fight or you don't... going back and forth will not really yield any result that way. The C scenario is the only one that can result in the quicker fleet doing damage without any in return if the time is not enough for B to fire a few times.
In my opinion a slower fleet don't have to be able to force a fight, forcing the enemy to leave is enough. At some point that faster fleet will have to fight as sometimes you will need to defend a fixed point.
I still think the solution to this problem is "Bring missiles"
In all seriousness can we just say that aurora TN beams are FTL and therefore can have range beyond the distance light can travel in 5 second increments? The sensors are already FTL, so there is clearly some way to physically interact with stuff at FTL speeds.
The 5 second limit isn't because of light speed - that is just the convenient technobabble.
The real reason is that longer-range beams would unbalance the game. Currently, if you are out-ranged in a beam conflict, you at least have the chance to build faster ships and close the range. You'll take damage, but it isn't game over. If beam ranges become much longer, then speed becomes irrelevant and longest range wins every time.
I really like the idea that missiles with thermal sensors are more likely to damage engines than other systems, and that missiles with EM sensors are more likely to damage sensors, fire controls and shield generators than other systems. It provides a reason to use sensor-equipped missiles other than conservation of ammo.
Mainly because of the volatility of outcome. The fact that FACs can be built has very little to do with it, because at the end of the day if those FACs are fighting something that outranges them and even only slightly outspeeds them then they will still get annihilated with no risk to their enemy. The sheer inelasticity of that outcome is kindof the problem, and I do agree its rather a big one. I once wiped out an entire enemy fleet of like 100 ships with one trapped beam armed destroyer that was kiting them. Strictly I took some casualties, but that was because the enemy fired missiles (they massively overkilled a jump gate constructor, and then destroyed one of the two accompanying destroyers). Once they ran out of missiles they had literally a 0% chance of either destroying the remaining ship or running away. The AI did eventually try to flee but I just switched to pursuing them instead and wiped them out to the last ship, which turned out to be more or less that entire NPRs space navy. The sheer absurdity of that is not a good gameplay aspect in my opinion, there was absolutely no risk whatsoever and I wasn't even all that much faster than them to my recollection. The fact that the beams would probably break down eventually in the current version is only a minor mitigation, because being able to fire from complete safety until your lasers literally break down and run out of parts is still very excessive (in my opinion).
Another way of putting it, as soon as that NPR was caught out against even one destroyer the game was over. There was no designing for them, there was no anything. Their fleet didn't even make it back to their main planet to get more missiles before it was completely destroyed. The flight would have taken several hours, they did not have several hours.
Why is this considered a problem? If you have a speed and range advantage in a gunfight, you can destroy the enemy at your leisure. This is perfectly realistic and logical, and happened in history - an example would be the destruction of the German squadron at the battle of the Falklands in WWI.
I had been meaning to ask this early, how do sub fleets work with the new organization commands? Do sub fleets have to be part of their parent fleet to get a naval command bonus? How far do sub fleets nest?
Another way of putting it, as soon as that NPR was caught out against even one destroyer the game was over. There was no designing for them, there was no anything. Their fleet didn't even make it back to their main planet to get more missiles before it was completely destroyed. The flight would have taken several hours, they did not have several hours.That problem has already been fixed for C# we don't need another fix. Steve has confirmed that with the new AI functionality, the NPR battle fleets will be better balanced and the NPR will understand when the run quicker. Plus, as you yourself said, the new weapon breakage rule. There shouldn't be a situation where the NPR attacks you with 100 missile ships. The problem was never beams themselves, it was an AI problem.
Modern day 'smoke' would have to be pretty hightech; it not only needs to obscure the visual light spectrum, it also needs to obscure radar rangefinding. And in Aurora? Aiming isn't done by looking down the sights at the target, distances are far too great, so it's all done by long range sensors.
Which makes the question of 'how to display ECM' kinda difficult. There are three kinds of sensors in Aurora; thermal passive, electromagnetic passive, and electromagnetic active, some technobabble applied to make them not suffer light-lag. Electromagnetic active is the only aiming system used by beam weapons, and missiles without their own sensor package are pretty clearly semi-actively guided, that is to say that they follow the sensor return from the missile fire control system to their target (otherwise they wouldn't be wired to explode due to loose weapon risk when the MFC loses target lock), and missiles with their own sensor package hunt enemy ships through them instead and do so infallibly (which is quite a trick, as real life has yet to figure out how to make guided munitions not explode your own ships, aircraft, tanks and everything else when they get pointed that way. A self guiding torpedo or missile has no friends).
Defeating all these sensor types at once is difficult, but the technobabble for why they suffer no light-lag could actually provide us a system as to how that could happen. The 'smoke generator' system drags the ship in question or the electromagnetic spectrum out of the aether in such a way that all sensor systems suffer from light lag. On the one side, it's a massive 'I'm here' marker due to how it interacts with the aether and as any player of World of Warships can tell you that tends to attract torpedoes. On the other side, good luck actually hitting a target without absolutely saturating the place with gunfire. And from the inside, good luck seeing out of it, you are going to need somebody whose view is not obscured by the smoke telling you where your shots are landing.
It would be best if this took more than just some hullsize and a few more tons of material though, it's probably a system that should be eating MSP or fuel to function. Though it's fair to note that it's basically a really low quality stealth system.
The discussion seems to be coming down to answering the question: Is it good for the game that a small force that is slightly faster and has longer-range weapons can completely destroy a much larger force?
In my recent campaign update for example, a damaged Necron destroyer could potentially have wiped out the entire Expeditionary Fleet if that fleet did not have either torpedoes or fighters. However, in this case they did have both torpedoes and fighters, because I knew from previous tactical intelligence that the enemy ships were faster and had longer-ranged weapons. If I did not have those capabilities, then I would not have sent the fleet into the system in the first place.
Earlier in the campaign, I found myself in exactly that situation and lost a fleet because I couldn't get escape. In that case however, I was unprepared, had minimal tactical intelligence and was surprised by an opponent with a significant tech advantage. After that point I was extremely wary about placing my forces in a similar situation and conducted operations accordingly. I have been working on ships and technology to counter the Tyranid advantages so I can go back into combat with some chance of success.
So in general, I think if you find yourself in a bad situation in deep space against a higher tech opponent with longer-ranged weapons, you probably should be in serious trouble. However, lets look at an extreme situation. A single small ship vs a very large opposing force. Unless the tech advantage is very large, the small ship will be firing at extreme range and therefore might still struggle to overcome the shield recharge rate of the large force. Also, the large force can split up, either for most of them to escape or to attempt to surround the faster opponent.
In summary, I think there are options for a weaker, lower tech race to fight a higher tech, faster race. That is one of the challenges of the game.
Finally, having argued the above, I think there might be an option we haven't considered so far; the equivalent of 'making smoke'. Perhaps there should be some form of crude ECM that makes a ship harder to hit, but also affects its own weapons. In this situation, the lower tech force might be able to 'obscure' itself sufficiently to make it difficult for a small, higher tech force to obtain a long-range firing solution. The higher tech force would either have to move closer to gain a better firing solution, opening itself up to counter-attack if the 'smoke' is turned off, or be content with shadowing the enemy. This capability would only be useful in that type of situation and only useful for the lower tech force. My concern would how the AI handles this, but I think I could code it.
Another way of putting it, as soon as that NPR was caught out against even one destroyer the game was over. There was no designing for them, there was no anything. Their fleet didn't even make it back to their main planet to get more missiles before it was completely destroyed. The flight would have taken several hours, they did not have several hours.That problem has already been fixed for C# we don't need another fix. Steve has confirmed that with the new AI functionality, the NPR battle fleets will be better balanced and the NPR will understand when the run quicker. Plus, as you yourself said, the new weapon breakage rule. There shouldn't be a situation where the NPR attacks you with 100 missile ships. The problem was never beams themselves, it was an AI problem.
And I would disagree that the system even in VB6 is inelastic. Your given example, sure. But because there are so many possibilities for weapon range and ship speed combinations, this problem isn't one that would happen routinely unless the player intentionally builds their fleets to trap themselves.
As far as I can see it though, Steve is basically like 'you shouldn't do a beam only fleet' so I suppose the point is relatively moot. Also as Steve pointed out, both the player and AI making heavier use of shields at lower techs (alpha shields) would blur the range issue to a meaningful extent which would also undoubtedly help.
As far as I can see it though, Steve is basically like 'you shouldn't do a beam only fleet' so I suppose the point is relatively moot. Also as Steve pointed out, both the player and AI making heavier use of shields at lower techs (alpha shields) would blur the range issue to a meaningful extent which would also undoubtedly help.
I'm not saying don't do beam only fleets - I have done beam-only races myself. I am saying, if you choose a beam-only fleet then make every effort to avoid being in a situation where you are in deep space against a faster, long-ranged opponent. Create faster ships and accept being very fuel-inefficient, or defend jump points, or do what I have done in this campaign against the Tyranids and run away at the strategic level until you can make a stand somewhere or you can develop longer-range weapons. Sometimes you are just outclassed and have to play the hand you are dealt as best you can.
It's interesting how we started with "engine tuners" and went to "beam fire control ranges" and ended up with "Trans-Newtonian equivalent of destroyer laying a smoke screen" 8)
I'm definitely not against a ship module that consumes fuel or MSP and in return acts like a ECM on steroids for a little while, even if that effect works only against BFC - though in fairness sake it should probably affect MFC too but I can also see an exploit where the "smoke" is laid down just 5 seconds before non-self-guided missiles would hit and possibly cause them to self-destruct because the MFC was firing from maximum range and that just got reduced by the "smoke".
OTOH, that's not any different from the exploit of jumping back and forth through a JP or cruising back and forth across the firing range, causing the AI to waste all their missiles. So maybe it isn't a problem.
the "smoke" is laid down just 5 seconds before non-self-guided missiles would hit and possibly cause them to self-destruct because the MFC was firing from maximum range and that just got reduced by the "smoke".If smoke affect only hit chance not range, than it is not a problem. But better add cooldown for smoke generators
What if the dropoff in accuracy at/near maximum range was less sharp? At least for the earlier techs where you will have less design options available. That is you can fire at longer range but the hit chances are so low it will not normally be useful. But if you fleet is about to be annihilated by a single higher tech destroyer your sheer number of shots would at least give them a chance.
This is trying to solve one very specific problem, but I get the feeling any good solution would touch a lot of subsystems in the game and become a major coding/balancing job in comparison to the results.
As far as I can see it though, Steve is basically like 'you shouldn't do a beam only fleet' so I suppose the point is relatively moot. Also as Steve pointed out, both the player and AI making heavier use of shields at lower techs (alpha shields) would blur the range issue to a meaningful extent which would also undoubtedly help.
I'm not saying don't do beam only fleets - I have done beam-only races myself. I am saying, if you choose a beam-only fleet then make every effort to avoid being in a situation where you are in deep space against a faster, long-ranged opponent. Create faster ships and accept being very fuel-inefficient, or defend jump points, or do what I have done in this campaign against the Tyranids and run away at the strategic level until you can make a stand somewhere or you can develop longer-range weapons. Sometimes you are just outclassed and have to play the hand you are dealt as best you can.
I mean in fairness we have dudes who want to have a powerful beams-only fleet that is realistically able to beat up the big mean standoff missile boats and project a comparable if not superior presence in space. What you are saying more or less totally precludes that.
I really like the idea of more functionality on ECM, though personally I would like such option to be component designs rather than user-toggled buttons. I like the idea of not having to micro-manage, but rather gather intelligence and plan long-term.
For some future release beyond the current release aims, I think being able to design ECM components with additional options would be good.
(snip)
is everybody sure for some reason that the beam burn-out doesn't sufficiently address the "kiting problem"? a partial fix is distinctly preferable to an over-fix, from the standpoint of unintended consequences.No, nobody is sure of that. We haven't had enough testing done. Steve hasn't encountered that situation in his test games. The chance is 2% for each time the weapon fires and it also requires that the ship has insufficient MSP left - otherwise the weapon will be instantly repaired and continues firing.
if you can disrupt enemy fire while fleeing, you can disrupt enemy fire while closing.
is everybody sure for some reason that the beam burn-out doesn't sufficiently address the "kiting problem"? a partial fix is distinctly preferable to an over-fix, from the standpoint of unintended consequences.
Shields getting a buff will also help with it, though that of course has the downside that it doesn't scale with larger numbers of ships - one destroyer vs one battleship the battleship might be able the shield tank long range fire, but 10 destroyers vs 10 battleships that could no longer be true.In case of one destroyer and 10 battleships it possible to move out ship with most damaged shield (target) out of formation, so attacker should change target or move in range of fleet
is everybody sure for some reason that the beam burn-out doesn't sufficiently address the "kiting problem"? a partial fix is distinctly preferable to an over-fix, from the standpoint of unintended consequences.No, nobody is sure of that. We haven't had enough testing done. Steve hasn't encountered that situation in his test games. The chance is 2% for each time the weapon fires and it also requires that the ship has insufficient MSP left - otherwise the weapon will be instantly repaired and continues firing.
Someone better at statistics could throw numbers on a chart to illustrate the odds.
if you can disrupt enemy fire while fleeing, you can disrupt enemy fire while closing.
is everybody sure for some reason that the beam burn-out doesn't sufficiently address the "kiting problem"? a partial fix is distinctly preferable to an over-fix, from the standpoint of unintended consequences.
It addresses the most excessive examples of the situation, where one destroyer can destroy a fleet of battleships. However, from what I recall the actual MSP cost of firing works out sufficiently small that I don't think it will be a major factor. I'm also not sure if the AI has limited MSP, if you're on the defending side.
Shields getting a buff will also help with it, though that of course has the downside that it doesn't scale with larger numbers of ships - one destroyer vs one battleship the battleship might be able the shield tank long range fire, but 10 destroyers vs 10 battleships that could no longer be true.
So I think both those changes definitely help in some situations, but it will still be a potential issue with beam combat.
Armor:
Regenerating shields paired with armor I think accomplish the same effect as a 'pass or reject' type armor scheme, but the way armor works could be adjusted so that if a shot strikes a fully armored location, it won't do damage unless it would penetrate a certain fraction (say 25%) of the armor stack. That is, if a location is fully armored with 4 layers of armor, it will reject all strength 1 hits; if it's fully armored with 8 layers of armor, it'll reject all strength 2 hits, and so on.
is everybody sure for some reason that the beam burn-out doesn't sufficiently address the "kiting problem"? a partial fix is distinctly preferable to an over-fix, from the standpoint of unintended consequences.No, nobody is sure of that. We haven't had enough testing done. Steve hasn't encountered that situation in his test games. The chance is 2% for each time the weapon fires and it also requires that the ship has insufficient MSP left - otherwise the weapon will be instantly repaired and continues firing.
I like the thinking here, but you need to make sure it doesn't turn into micromanagement hell. There's real advantage in having ECM/ECCM be passive, abstracted modules, because it makes combat easier to run. This is a fleet game, not a tactics game, so you need to be cautious about the level of detail being added to individual units.I envisioned these ECM modules as not being player controlled (not even sure I would give the user the option to at all).
Alrighty! Could you edit the post in the Changes topic to reflect that? It's here: http://aurora2.pentarch.org/index.php?topic=8495.msg107701#msg107701Its 1% now after play testing.is everybody sure for some reason that the beam burn-out doesn't sufficiently address the "kiting problem"? a partial fix is distinctly preferable to an over-fix, from the standpoint of unintended consequences.No, nobody is sure of that. We haven't had enough testing done. Steve hasn't encountered that situation in his test games. The chance is 2% for each time the weapon fires and it also requires that the ship has insufficient MSP left - otherwise the weapon will be instantly repaired and continues firing.
Alrighty! Could you edit the post in the Changes topic to reflect that? It's here: http://aurora2.pentarch.org/index.php?topic=8495.msg107701#msg107701
Another thing that I have wanted on Aurora for a long time is a missile type that you can use similar to a MIRV but have no engines and whose missiles can be individually launched from a larger missile launcher but not part of the same salvo.
Let's say that you have 8 size 12 launchers on a ship and you then stuff them each with size 4 missiles using this feature you would be able to launch 3 salvos of 8 missiles each with a 5s gap.
Of course you could just make a MIRV that launches all missiles in one salvo if saturating an enemy is the meaning. But sometimes you actually might want to launch only a few missiles on each target such as against fighters, FAC or smaller scout ships. As these crafts most likely will become more prominent you can make your regular missile cruisers more versatile by being able to engage swarms of fighters at long range. There also can be an idea of having smaller AMM missiles stored in regular launchers as you might need larger more capable AMM, especially long range AMM or those fit with sensors such as ECCM and the like.
This could make certain missile ships more dynamic as they can carry more types of missiles. I think this could be quite and interesting game mechanic, at least something I have wanted in the game for a long time.
Another thing that I have wanted on Aurora for a long time is a missile type that you can use similar to a MIRV but have no engines and whose missiles can be individually launched from a larger missile launcher but not part of the same salvo.
Let's say that you have 8 size 12 launchers on a ship and you then stuff them each with size 4 missiles using this feature you would be able to launch 3 salvos of 8 missiles each with a 5s gap.
Of course you could just make a MIRV that launches all missiles in one salvo if saturating an enemy is the meaning. But sometimes you actually might want to launch only a few missiles on each target such as against fighters, FAC or smaller scout ships. As these crafts most likely will become more prominent you can make your regular missile cruisers more versatile by being able to engage swarms of fighters at long range. There also can be an idea of having smaller AMM missiles stored in regular launchers as you might need larger more capable AMM, especially long range AMM or those fit with sensors such as ECCM and the like.
This could make certain missile ships more dynamic as they can carry more types of missiles. I think this could be quite and interesting game mechanic, at least something I have wanted in the game for a long time.
That seems superfluous. If you have twelve launchers with three sub-missiles, you'll get the exact same result if you just launch all sub-missiles loaded in four launchers.
That seems like a lot of coding work for a fairly small impact. Maybe in a future version, but it's certainly not a priority right now.
I'm sure there are quite a few people on the forum who find the concept of massive fleets built around a limited number of large, powerful warships appealing. I'm also sure there are people who like the idea of Star Trek style independent long-range cruisers for exploration and expeditionary warfare. Unfortunately, though, the size of jump drives in the game makes it all but impossible to build ships with any kind of reasonable mission tonnage at low tech levels, when the game is most fun to play. Additionally, the cost of jump drives means that you always want to take maximum advantage of their capabilities, so any expeditionary group will end up comprising at least three or four vessels of a given tonnage, with one jump warship.
This is not ideal, but a simple change can rectify this. We already have self-only jump drives in the game, so why not extend that? A new technology, for about 5,000 RP, will allow jump drives to be marked as 'self-only'. This will cut their build cost and research cost by half, and their size by a third, but only allow them to jump the ship they are mounted on. An advanced version of this tech, for 20,000 RP, will cut it to a third and a fourth, respectively. Using regular jump drives will still be cheaper and more efficient when jumping squadrons of ships, so self-only drives will be strictly inferior for smaller vessels that are built in large numbers, for whom economies of scale make dedicated jump ships viable.
Just a note, if regular jump drives can jump 5 ships and self-only jump drives are 1/5 the tonnage of a regular jump drive, then they are pretty much exactly equal. Arguably slightly superior since you are splitting the tonnage among 5 ships. This isn't criticism of your idea, its just something that needs to be kept in mind when figuring out balance of the research cost of the size modifier.
The issue is, in about 50% of jumps without a gate the ship jumps alone anyway (think surveying). In 99% of jumps there is no combat on the other side of the jump and the number of ships that can jump at once is irrelevant. Frankly, I think I can count the number of jump point combat scenarios I've read about on this board on one hand. Combat jumps just aren't a significant part of the game. If self-jumps were 1/3 the size of regular jump drives, slapping one of them on each of your military ships might turn out to be the optimal route.
And if they are big enough to prevent this, they might be too big to make large, solo vessels viable. Perhaps some form of serious downside to using them in fleets? Perhaps a 'resonance' effect where each ship that jumps using a self-jump drive adds to the total jump shock time that every ship experiences? So if you jump with 1 ship, you get 10 seconds jump shock. When you jump with 10, each gets 50 seconds jump shock. When you jump with 100, each gets 30 minutes jump shock.
In fact, if you go this route, I'd make self-only drives the starting tech and have group jump a later tech you unlock.
Personally, I think this is one of those areas where you should use SpacceMaster to customize your game.But it's impossible to customzie NPR
Personally, I think this is one of those areas where you should use SpacceMaster to customize your game.But it's impossible to customzie NPR
Personally, I think this is one of those areas where you should use SpacceMaster to customize your game.
If you want a universe where every ship larger than a TIE fighter can "make the jump to Hyper" without spending one-third of their displacement on a special engine, then use SM to give your empire max jump drive efficiency tech. That's a 1-20 ratio instead of a 1-3, if memory serves? I would think your fleet could afford 5% of its hull spaces.
It might be nice to have the new early game tech have proper names, rather than “improved X tech”
For the engines you could use fission and fusion for the “lower” and “upper” tech respectively:
Fission Thermal Engine
Fusion Thermal Engine
Fission Pulse Engine
Fusion Pulse Engine
Something similar could be done for the reactors, though I can’t think of something right now.
It might be nice to have the new early game tech have proper names, rather than “improved X tech”
For the engines you could use fission and fusion for the “lower” and “upper” tech respectively:
Fission Thermal Engine
Fusion Thermal Engine
Fission Pulse Engine
Fusion Pulse Engine
Something similar could be done for the reactors, though I can’t think of something right now.
I’ve not read enough hard sci-fi to say what would be a “reasonable” tech progression (insofar as a sci-fi world based on materials which are named for the fact that they defy the laws of physics can be construed as reasonable). My main point was just that having a handful of techs called “improved whatever” and all the others have unique flavor names looked a little odd. I don’t care what the names are, exactly. And even if it stays as in it’s hardly a big deal, it just seems an easy change to increase the immersion.
Ship fatigue: With my latest campaign I have ships that are up to 50 years old, starting as a frigate of around 5000 tons, now 10-12 000 ton destroyers. Somehow there should be a penalty for "long lived" ships
Ship fatigue: With my latest campaign I have ships that are up to 50 years old, starting as a frigate of around 5000 tons, now 10-12 000 ton destroyers. Somehow there should be a penalty for "long lived" ships
It might be reasonable if you look at it as 'spaceframe fatigue', fighter jets at least have a concept of 'airframe fatigue' where the superstructure of the aircraft itself is so worn out that there isn't really a way to fix the thing without effectively building a totally new aircraft. Maybe aurora could have something along those lines. Really old ships just start experiencing major structural failures (maybe past a certain point of time a slow-burning exponential growth of maintenance failure on its components, say over the course of 5-10 years) unless you do some kind of complete re-build of the ship at a shipyard.
I thought spine mounted and internally-mounted were the same thing? The only difference is exactly how much ship you have that is not gun. They are functionally the same, after all. No turret, bigger than normal.
Given that this is a more roleplay-heavy game than a competitive one, I'm not sure if the ship fatigue thing needs to exist. There's a lot of fiction out there where ridiculously old ships still see use(Battletech comes to mind). Heck, even in the real world, there's wet-navy ships over a century old that are still in active use(one over 200 years old and still sailing (https://en.wikipedia.org/wiki/USS_Constitution), one from the Kaiser's navy of WW1 which has also been sunken and re-floated (https://en.wikipedia.org/wiki/MV_Liemba), and one over a century old and still in use for its original purpose (https://en.wikipedia.org/wiki/Russian_salvage_ship_Kommuna) come to mind), and salt water is generally far nastier than vacuum.
Hey Steve, any chance for forced deportations or evacuations of aliens whos systems you conquer? In case you just want the system, not the alien population. Could be worked into treaties as well, where one side demands the other remove a colony in X amount of time.
Hey Steve, any chance for forced deportations or evacuations of aliens whos systems you conquer? In case you just want the system, not the alien population. Could be worked into treaties as well, where one side demands the other remove a colony in X amount of time.
I guess you could transport the aliens to a new system and then transfer the colony to the NPR. I looked at the AI removing colonies when I coded the latest Diplomacy update and it was tricky to make it work with all the potential factors involved - what if there was no direct route back NPR space for example? That's why I went for transferring the populations. There is some precedent for that on Earth. Countries agree border changes and towns and cities end up in a different country.
I guess you could transport the aliens to a new system and then transfer the colony to the NPR. I looked at the AI removing colonies when I coded the latest Diplomacy update and it was tricky to make it work with all the potential factors involved - what if there was no direct route back NPR space for example? That's why I went for transferring the populations. There is some precedent for that on Earth. Countries agree border changes and towns and cities end up in a different country.
I also think it would make for an interesting synergy with the ground game. Okay you know just forced the NPR fleet out of the system without firing a shot but their former colony of 25m isn't happy with the new management and now you're going to have to garrison that world. I don't know if Steve has coded revolts, uprisings, declaring independence yet (it was mentioned in the wiki), but if so you might have just inherited a big problem in your borders.
Has the beam fighters having a hard time hitting things slower than them with very close range weapons depending on target speed and your fire control range or weapon range?This is an issue with Initiative and how new players do not understand how it works. It is a little counter-intuitive. Steve has changed the initiative system for C# a little bit: http://aurora2.pentarch.org/index.php?topic=8495.msg97342;topicseen#msg97342
I recently had a problem with my 7km speed fighters not being able to hit a moving 5km ship. I later changed them with longer ranged weapons and they could but makes no sense that the faster ships couldn't get in range. . .
What problem is this trying to fix that the game has? If you leave a ship without refitting it to a new class for a hundred years, what you have is a very useless ship puttering about. If you constantly refit it into whole new ships over time, you are going to regularly get notified about refits in excess of the cost of a new ship, which always felt to me like you started passing the point where you are replacing whole superstructure and other such things.
Much like how we have 200 year old sailing ships floating around, but if you took one of those and wanted to refit a nuclear reactor and vertical launch systems onto it, your going to pay more than the cost to just build one from scratch, and have to build an entirely new superstructure to support these modern parts.
I also don't want this stepping on my roleplaying. I've regularly played feudal style multi empire games, and its fairly common for a couple of 'pride of' style ships to end up going through many times their normal refit costs just to be a continuation of a legacy starship for nobility or the like. I don't want them doing so only to be told "but it'll break down every two weeks and you can't fix that" even when dropping 150% the price of a new ship on overhauls, and RPing it as the ship being essentially the answer to the ship of Theseus problem. I could just build a new ship with the same name, but then the history is lost, along with the point.
With the C# habitat changes, orbital habitats become viable alternatives to infrastructure when the colony cost exceeds about 6.0. However, since LG infrastructure costs thrice as much as regular infrastructure, housing population on habitats always ends up being cheaper than using LG infrastructure when the colony cost exceeds 2.0. This is somewhat problematic, since a large majority of near habitable worlds are colony cost 2.0 or thereabouts, due to oxygen pressure requirements. Add in the fact that habitats do not need a larger environment sector population, and LG infrastructure becomes almost useless in comparison
Can the cost of LG infrastructure be lowered to 4.0 BP to make it at least somewhat competitive?
I still think it is a good idea to somehow force older ships to eventually need to be scraped. . .
I still think it is a good idea to somehow force older ships to eventually need to be scraped. . .
I don't. I think it's a terrible idea. I completely disagree with the proposal to limit my fun.
As Jorgen_CAB pointed out, no one is forcing you to use centuries-old ships, or to continually refit them to be larger and larger. So don't do it. But don't take away MY ability to do so just because YOU think it's unrealistic. Don't cripple MY ships' crews' experience just because YOU imagine one-quarter of them being replaced at once. That's not how my empire works.
Aurora has never been realistic. Internally consistent, yes, but never realistic. We literally threw out Newton's Laws when we started. There is no "realistic" in our imaginary futures, only "appropriate for our fiction" and "NOT appropriate for our fiction."
My empire (this week) consists of slow-growing, incredibly long-lived tree people who build their spaceships out of 'wood' and sail on solar winds captured in gossamer-thin electron sails rigged all around their nigh-spherical hulls. Our semi-living ships are expected to last centuries, increasing in size the entire time, and our crew turnover is basically nil.
Your proposals are totally "unrealistic"
As I also said before.. you can say that about ANY mechanic in the game... eventually you are just laying in bed dreaming... ;)
As I also said before.. you can say that about ANY mechanic in the game... eventually you are just laying in bed dreaming... ;)
Yes, you have said that before. But you have offered no explanation for why adding more restrictions would make Aurora more fun. . . only suggestions that would make *MY* Aurora less fun.
I really don't see how this would be any different than manage maintenance with overhauls or minerals for building materials and so on. It also would require MUCH less micromanagement than maintenance and overhauls but add some interesting resource management into the picture.
your leaders and officers still have human lifespans so I don't get why you could not imagine this anyway.
I thought I had done that... adding experience change would have the same type of impact as maintenance needs of ships but in a different way. Will I have the ships stay out on a long mission or not, the longer ships stay out on a mission the more experience you loose at the end of their mission as they need to replace more crew.
It would have the same type of impact as maintenance have, the same type of restriction but it would be important in a different way... it would also "fix" the issue of once a ship is trained to 100% fleet training it will not stay there indefinitely as long as it looses its crew.
If it is tied to an optional feature like maintenance I don't see why it could not be added.
You would have to manage deployment of fleets as well as choose how to design them and choose how long a service length your crew usually have in your empire. Crew is a finite resource and you need to manage it carefully.
It would make leaders more important in therms of training skills etc... leaders still come and go... why should not the crew do the same.
You can imagine your crew as immortal all you want, your leaders and officers still have human lifespans so I don't get why you could not imagine this anyway. You also could turn it of in the same way you can turn maintenance off.
I really don't see how this would be any different than manage maintenance with overhauls or minerals for building materials and so on. It also would require MUCH less micromanagement than maintenance and overhauls but add some interesting resource management into the picture.
We now have effectively 'immortal' ships and because of it, the crew bonuses/grade points short of catastrophic damage to the ship won't significantly degrade. The crew/officer model is now predicated on 'mortal' crews which age up, transfer, retire, get sick, and die (I know the story tag exists but that is an option and not the default). That creates something of a gap where the conceit is that this one fortunate and ancient ship is crewed by superbly trained crewman accrued over the decades the ship has been in service but the crew model is one of mortality and rotation and I think this in some fundamental ways cheapens the crew grade training bonuses and detracts from those that might want to RP a more 'conventional' sort of space empire.
I mean, its true that the ship crew rating pretty much stays top notch after you train them up and then stays there forever, which is deeply unrealistic compared to navies that regularly have to do drills to stay reasonably sharp.
Unless you could automate training exercises though, I dont think its a fun thing to add to the game. In reality training is actually an exceedingly costly endeavour for most militaries and choosing to not keep up with training requirements is a pretty common budget decision when times are hard, that could later lead to that military getting its ass kicked. It could be a pretty fun tradeoff (in my opinion) to cut off the training due to a sorium shortage and to then actually feel the negative effects of less well prepared crews. However it would not be particularly fun (in my opinion) to constantly be having to manually re-schedule training exercises lest your fleets become useless.
Any thoughts on Tech to extend leader/species lifespans? It would push the age of retirement up higher.
Unless the new story function makes them immortal, only dying in battle and accidents.
;D
I mean, its true that the ship crew rating pretty much stays top notch after you train them up and then stays there forever, which is deeply unrealistic compared to navies that regularly have to do drills to stay reasonably sharp.
Unless you could automate training exercises though, I dont think its a fun thing to add to the game. In reality training is actually an exceedingly costly endeavour for most militaries and choosing to not keep up with training requirements is a pretty common budget decision when times are hard, that could later lead to that military getting its ass kicked. It could be a pretty fun tradeoff (in my opinion) to cut off the training due to a sorium shortage and to then actually feel the negative effects of less well prepared crews. However it would not be particularly fun (in my opinion) to constantly be having to manually re-schedule training exercises lest your fleets become useless.
I'm not sure how much of an issue that would be. If I understand correctly, fleet training can happen at any time while a ship is within the radius of its parent admin command, even while it is executing a movement order, but it needs to be assigned to the training admin command, so theoretically, it would just be a matter of copy-pasting the fleet to the training command whenever you want it on the move, or when it is garrisoned somewhere.
Maybe reassigning command could be an order of some sort? Like, "move to planet X, reassign to TRN Command, start fleet training. If hostile fleet detected, reassign to NAV Command, abandon training." or something similar.
To mitigate the effects, fleet training could decay over time, at a slow rate inversely proportional to the existent fleet training and crew grade. So it might take a year to go from 100% to 99%, another year to 95%, another year to 75%, and then it would rapidly decrease to zero, so a small amount of this decay could be acceptable.
Remembering to assign fleet to fleet training every three or four years is not that big of a chore, unless you somehow have hundreds of fleets.
On a side note, can it be made possible to control or stop population growth in certain colonies (military facilities, research outposts or mining complexes on high colony cost worlds, which typically have small populations that grow rapidly) where you don't need or want the extra population?
Biology/Genetics needs some love. A tech that increases the lifespan of a species as a whole should also boost the population growth rate since you have fewer people dying per year. Since the only real late-game limitation is population, this would be a huge boon, if properly balanced, in the mid-to-late parts of the game.
I mean, its true that the ship crew rating pretty much stays top notch after you train them up and then stays there forever, which is deeply unrealistic compared to navies that regularly have to do drills to stay reasonably sharp.
Unless you could automate training exercises though, I dont think its a fun thing to add to the game. In reality training is actually an exceedingly costly endeavour for most militaries and choosing to not keep up with training requirements is a pretty common budget decision when times are hard, that could later lead to that military getting its ass kicked. It could be a pretty fun tradeoff (in my opinion) to cut off the training due to a sorium shortage and to then actually feel the negative effects of less well prepared crews. However it would not be particularly fun (in my opinion) to constantly be having to manually re-schedule training exercises lest your fleets become useless.
Biology/Genetics needs some love. A tech that increases the lifespan of a species as a whole should also boost the population growth rate since you have fewer people dying per year. Since the only real late-game limitation is population, this would be a huge boon, if properly balanced, in the mid-to-late parts of the game.
Biology/Genetics needs some love. A tech that increases the lifespan of a species as a whole should also boost the population growth rate since you have fewer people dying per year. Since the only real late-game limitation is population, this would be a huge boon, if properly balanced, in the mid-to-late parts of the game.
No it doesn't. Greater longevity may actually slow down population growth as people wait longer to have children, stretching the distance between generations even while numbers per generation remain the same.
Population growth limitation is largely cultural in modern society, it would be entirely possible for a woman to produce a child every 4 years or even faster strictly biologically speaking and they don't for a variety of reasons. While the death rate would slow down a little, it would not actually speed population growth unless either it encourages the birth of more children per person or shortens the timespan between generations.
It would temporarily help by limiting deaths, that's true, but it won't affect the chances of survival in the long term. Even those that have been treated with such a longevity booster will eventually die. Even if humans become immortal in the sense that they won't die of old age it has been calculated that the average lifespan of people is going to be around 700 years due to accidents, misadventure and disease. That doesn't mean that there won't be eventually extremely old people far older than 700 years, but there's going to be plenty of people who end up dead before they're even 200 years old for any number of reasons.
No it doesn't. Greater longevity may actually slow down population growth as people wait longer to have children, stretching the distance between generations even while numbers per generation remain the same.
Population growth limitation is largely cultural in modern society, it would be entirely possible for a woman to produce a child every 4 years or even faster strictly biologically speaking and they don't for a variety of reasons. While the death rate would slow down a little, it would not actually speed population growth unless either it encourages the birth of more children per person or shortens the timespan between generations.
It would temporarily help by limiting deaths, that's true, but it won't affect the chances of survival in the long term. Even those that have been treated with such a longevity booster will eventually die. Even if humans become immortal in the sense that they won't die of old age it has been calculated that the average lifespan of people is going to be around 700 years due to accidents, misadventure and disease. That doesn't mean that there won't be eventually extremely old people far older than 700 years, but there's going to be plenty of people who end up dead before they're even 200 years old for any number of reasons.
Hi Steve, is there any plan for greater ability to manipulate ruins, and the various spoiler spawns? It would be a great tool to have for 'Lets play' or forum run games to be able to spawn/edit ruins and precusrors from spacemaster mode.You can already use SM mode to place random ruins on a body. You cannot determine its size or tech level but you can place it. AFAIK, SM mode does not allow spawning spoilers, only new player races or new NPRs - conventional and TN.
Also is it possible to be able to have a toggle to make the game 'locked' without the spacemaster password. i. e. you can't advance time without entering it. Would help greatly with said forum games by being able to provide the save to players without worrying about them zooming forward in time.That would indeed be useful if you use the style where the save gets passed around for people to issue orders and so on, and then you as the Space-Game-Master advances time.
No it doesn't. Greater longevity may actually slow down population growth as people wait longer to have children, stretching the distance between generations even while numbers per generation remain the same.
Population growth limitation is largely cultural in modern society, it would be entirely possible for a woman to produce a child every 4 years or even faster strictly biologically speaking and they don't for a variety of reasons. While the death rate would slow down a little, it would not actually speed population growth unless either it encourages the birth of more children per person or shortens the timespan between generations.
It would temporarily help by limiting deaths, that's true, but it won't affect the chances of survival in the long term. Even those that have been treated with such a longevity booster will eventually die. Even if humans become immortal in the sense that they won't die of old age it has been calculated that the average lifespan of people is going to be around 700 years due to accidents, misadventure and disease. That doesn't mean that there won't be eventually extremely old people far older than 700 years, but there's going to be plenty of people who end up dead before they're even 200 years old for any number of reasons.
I understand that the effects of longevity with regards to population growth are strongly dependant on how well people retain fertility with advancing age, assuming we don't automate the process of procreation at some point. Current trends indicate that demographic ageing and increasing lifespans are strongly associated with declining fertility, but I would be cautious about applying these to futuristic societies where people retain their health and virility well into their hundreds.
While it is probable that people would delay child-rearing significantly to sustain focus on their education or career, I seriously doubt that the time taken for a child to mature and achieve independence will increase beyond twenty or thirty years. The reproductive age in humans is typically considered to be 16-50, which is insufficient time to conceive more than a single generation of children. If that were to be 16-100, or 16-200, though? Certainly most people would opt not to have children well into their fifties or sixties, but it is also possible that those exact same people would choose to have children again in their eighties or nineties, and then again in their one-twenties, as their earlier children age and separate from them. The size of each subsequent generation will still repeatedly increase as the population grows, since almost the entire population is both capable of reproducing and might be willing to do so.
It's probably incorrect to attribute any such increase in the growth rate to a decline in death rate, it's a decline in death rate and an assumption that sufficiently long lifespans will prompt people to have multiple children spaced several decades apart. Which, granted, may very well be proven to be false.
If I can make a small suggestion(s), first the newly independent colony starts in communication with their former parent empire....they're kin after all.
Additionally, the diplomatic status reflect the mode of independence - if you grant it to them, they have a neutral and perhaps even a friendlier disposition (it was a peaceful break after all). If the colony broke away due to unrest, perhaps their diplomatic stance is less friendly to hostile given they had to physically break away.
Suggestion 2: Population happiness mechanics
Currently, stability modifiers are penalties only, that is, if you fail to provide infrastructure or PPV to a colony, its productivity goes down, and taking in account the new rebellion mechanics, can rebel. My suggestion is to add a positive facet to productivity by adding a happiness modifier in addition to the stability one. This would involve some things like:
-Adding installations that provide happiness. Similar to infrastructure, there could be a "x% happiness at y installations per million pop", this would add an abstraction to deal with every day government stuff, but it would also let you roleplay an evil nation that doesn't provide to its population. These could be multiple types of installation like says schools and hospitals, but I think it would fit better the kinda minimalist tone of Aurora if you had a single installation type called something like "social installations" or even "social infrastructure". These would bring the population happiness to a x%, which could add like, a x/2% bonus to productivity, I'm picturing 50% happiness turning the production modifier to 125% or something like that.
-The rest of the happiness would be tied to the trade good system. More trade goods could be added, and the remaining 50% happiness could be proportional to "% of import need fulfilled", which would add a secondary reason for us to encourage civilian shipping in our systems.
We also have the colony supply/demand values for various trade goods, so importing sufficient in a category could increase happiness and not getting enough decrease it.
And also cause problems for empires with commercial companies disabled, since you can't transfer trade goods yourself.
And also cause problems for empires with commercial companies disabled, since you can't transfer trade goods yourself.
Then we should fix that rather than let it be a reason we can't do something else.
I don't think the trade system is well suited for that task.
Even if you could transfer trade goods manually, the player has little control over the surpluses and deficits at an empire-wide level. AFAIK the only way you can influence production is by sending more colonists to a planet.
Could Fighter-Sized Crew Quarters be made 0 Tons and made Fighter Only with a hard limit on the number of modules mounted? Or maybe Fighters having a certain amount of free crew space equivalent to a fighter sized crew quarters module, but only ships designated as Fighters would have them? The size of Fighter Sized Crew modules and Tiny engineering spaces piss me off...
A typical issue with beam based fleets is that they are "all or nothing" weapons: if you are slower than the opponent and you can't dictate the engagement you are going to be destroyed and/or kited.
I don't know if it was already suggested, but I would like to see an option to give an order (or a tech) to temporarily boost engine performance for a brief period of time. This should be within reasonable percentage (eg. 20/30% boost), should not be deactivable at will (it will continue to get boosted for a specific time) and should come with an heavy cost such as an high risk of explosion of the engines or loss of all power for the ship for a time after the boost (like jump shock).
I much prefer the first option because it provide an hard choice also for the fleet that has the advantage (do we prefer continuing kiting with the risk of engine explosion or are we ready for a close quarter fight?).
Quote from: Kiruth link=topic=9841. msg118596#msg118596 date=1580913620A typical issue with beam based fleets is that they are "all or nothing" weapons: if you are slower than the opponent and you can't dictate the engagement you are going to be destroyed and/or kited.
I don't know if it was already suggested, but I would like to see an option to give an order (or a tech) to temporarily boost engine performance for a brief period of time. This should be within reasonable percentage (eg. 20/30% boost), should not be deactivable at will (it will continue to get boosted for a specific time) and should come with an heavy cost such as an high risk of explosion of the engines or loss of all power for the ship for a time after the boost (like jump shock).
I much prefer the first option because it provide an hard choice also for the fleet that has the advantage (do we prefer continuing kiting with the risk of engine explosion or are we ready for a close quarter fight?).
There was quite a heated discussion on how to "fix" this a couple of pages ago. . . you should check that out. ;)
And also cause problems for empires with commercial companies disabled, since you can't transfer trade goods yourself.
Yes. . you could simply add an order to pick up and drop of trade goods that work the same as any other transport order an allow the player to set up trade routes if they choose to do that themselves.
Basically instead of spawning civilian lines, you could build freighters and use either default orders to automate or direct orders to allow it to ship trade goods from planet to planet
I also think such a "simulation" system could be optional in the first place as not everyone would like to have it. But then again. . . the more optional system these is the more exceptions in the code there has to be and it become more complex to do.
Even if you could transfer trade goods manually
the player has little control over the surpluses and deficits at an empire-wide level. AFAIK the only way you can influence production is by sending more colonists to a planet.
Edit: All periods I write keep having spaces added after them. Can I disable this?It's an anti-spam feature because the forum software thinks you're trying to put in URL links in a sneaky way or something. It'll go away once you have 10 posts, I believe.
Could you please add this:
Newly constructed fighters will automatically assign and land onto mothership in orbit pre-selected.
A typical issue with beam based fleets is that they are "all or nothing" weapons: if you are slower than the opponent and you can't dictate the engagement you are going to be destroyed and/or kited.
I don't know if it was already suggested, but I would like to see an option to give an order (or a tech) to temporarily boost engine performance for a brief period of time. This should be within reasonable percentage (eg. 20/30% boost), should not be deactivable at will (it will continue to get boosted for a specific time) and should come with an heavy cost such as an high risk of explosion of the engines or loss of all power for the ship for a time after the boost (like jump shock).
I much prefer the first option because it provide an hard choice also for the fleet that has the advantage (do we prefer continuing kiting with the risk of engine explosion or are we ready for a close quarter fight?).
Another suggestion for a quality of life type of thing...
Would it be possible to add an supply automatic order for different things to anything produced on a world add will get picked up by the civilian transports.
As far as I remember there was a problem with adding a supply of thing that might not be available. In addition to that it often is more trouble than it is worth to keep adding more and more of something you build allot and just want shipped out to your colonies. Most often this is mines and automatic mines, but it can be other stuff as well.
A suggestion of small balance if it has not been changed already...
I think that the 15cm laser at 4HS is too small, it's general DPS is way to effective very early, especially when you consider that 15cm lasers can have really long range too they are extremely effective in general in comparison with most other lasers. They often even can compete with high damage lasers in terms of cutting through enemy ship armour through cheer DPS, almost no other laser can do this as effective as the 15cm.
10cm is 3HS
12cm is 4HS
15cm is 4HS
20cm is 6HS
25cm is 8HS
30cm is 10HS
15cm lasers should have a size of 5HS.
I also think that weapons perhaps should be able to have fractions of HS as well to balance them a bit better.
In addition to this larger weapons also often get shafted due to not being able to produce enough capacity to synchronise with the 5sec charge rate per turn. I think that capacity that is over from a previous turn should go into the weapon in the next turn (after it fired) so a weapons might fire in say 4 turns sometimes and 5 turns times. This should even out the benefit of different weapons and make it easier to select a weapon type that best fit the ship you are trying to design. Right now, certain weapons simple are not usable as they synch very badly with the capacitor tech. Take the 20cm laser that is really good at capacitor 5 but really inefficient at any other lever in comparison with a 15cm (even if the size was increased to 5HS) until capacitor 10 where it still is marginally better than a 15cm laser due to its larger size but higher damage and better capacitor tech finally make it better, but not by that much.
In the same spirit perhaps you should be able to fire weapons even more often if you can deliver enough power to do so, like a 10cm lares cold fire twice with a capacitor 6 for example.
You could then also redo how rail-guns work a bit so the capacitor sort of dictate how often they fire rather than they firing 4 shots every time they fire, which seems a bit odd when they fire four shot but only every 20sec instead of one shot every five seconds.
This obviously would effect balance between Gauss and Rail-guns so would have to be handled with great care. I think that Gauss in general are very under powered weapons in general when you compare them with rail-guns, both in therms of technology and cost as rail-guns can use the same fire-control as all other beam weapons while the Gauss require turrets and fast firing fire-controls.
Changing this would also "fix" rail-gun versus Gauss balance as early rail-guns would perhaps only fire ones or twice per turn and increase in speed later on, it would also make rail-guns semi useful for PD even later on.
I think that weapons could be shown with true fire speed rather than per 5 second turns... although the game would make a weapons sometimes fire one or two shots in a turn or more or less turns in between shots.
I don't want to change weapons very much as I am happy with the balance right now. For example, a laser firing once in a turret has a similar effect to a fixed railgun firing four times. Fixed railguns have the advantage that they function as both offensive and defensive weapons but fixed lasers have greater range. If you allow the laser to fire twice, that makes the railgun far less effective in comparison.
However, I agree about the laser size progression. I've changed the rounding on laser HS from Floor to Nearest Int, which moves the 15cm from 4 HS to 5HS. This also changes 30cm from 9 HS to 10 HS and 40cm from 12 HS to 13 HS. I considered round to a decimal place (which would make the progression 3.4, 4, 4.9, 6.3, 8, 9.8, etc.) but it just doesn't look right :) so I decided to leave it as whole HS for now.
Another suggestion for a quality of life type of thing...
Would it be possible to add an supply automatic order for different things to anything produced on a world add will get picked up by the civilian transports.
As far as I remember there was a problem with adding a supply of thing that might not be available. In addition to that it often is more trouble than it is worth to keep adding more and more of something you build allot and just want shipped out to your colonies. Most often this is mines and automatic mines, but it can be other stuff as well.
You don't have to create matching supply and demand orders. Supply won't get picked up though without matching demand.
Another suggestion for a quality of life type of thing...
Would it be possible to add an supply automatic order for different things to anything produced on a world add will get picked up by the civilian transports.
As far as I remember there was a problem with adding a supply of thing that might not be available. In addition to that it often is more trouble than it is worth to keep adding more and more of something you build allot and just want shipped out to your colonies. Most often this is mines and automatic mines, but it can be other stuff as well.
You don't have to create matching supply and demand orders. Supply won't get picked up though without matching demand.
In VB6 if you supplied something and there was nothing to load you keep getting an error message that it can't load and interrupts... it also would lower the supplied item with one even though it did not load anything.
Will this work differently in C#?
Another suggestion for a quality of life type of thing...
Would it be possible to add an supply automatic order for different things to anything produced on a world add will get picked up by the civilian transports.
As far as I remember there was a problem with adding a supply of thing that might not be available. In addition to that it often is more trouble than it is worth to keep adding more and more of something you build allot and just want shipped out to your colonies. Most often this is mines and automatic mines, but it can be other stuff as well.
You don't have to create matching supply and demand orders. Supply won't get picked up though without matching demand.
In VB6 if you supplied something and there was nothing to load you keep getting an error message that it can't load and interrupts... it also would lower the supplied item with one even though it did not load anything.
Will this work differently in C#?
In C#, you will get an event but not an interrupt. If nothing is there, the pickup code doesn't execute.
Tinkering with VB6 last night and had an RP thought/suggestion:
I have never noticed but once Commanders die/retired/KIA, are they still viewable in an inactive file or are they gone forever? If possible, I wonder if it would be possible for those Commanders to shift to a past Commander tab so their accomplishments and lives (records, medals, comments) are still viewable? I tend toward paying a lot of attention to my Commanders to the point of entering in comments on their actions and lives essentially creating a fictional story/universe as I go with these guys and when they eventually move on, I would like to go back and see who came before the present generation and what they did. Maybe even name a new colony world or warship (ex: 'TFNS Steve Walmsley') off a past Commander of renown and this function would make the record keeping for such a lot easier.
Another suggestion for a quality of life type of thing...
Would it be possible to add an supply automatic order for different things to anything produced on a world add will get picked up by the civilian transports.
As far as I remember there was a problem with adding a supply of thing that might not be available. In addition to that it often is more trouble than it is worth to keep adding more and more of something you build allot and just want shipped out to your colonies. Most often this is mines and automatic mines, but it can be other stuff as well.
You don't have to create matching supply and demand orders. Supply won't get picked up though without matching demand.
In VB6 if you supplied something and there was nothing to load you keep getting an error message that it can't load and interrupts... it also would lower the supplied item with one even though it did not load anything.
Will this work differently in C#?
In C#, you will get an event but not an interrupt. If nothing is there, the pickup code doesn't execute.
Tinkering with VB6 last night and had an RP thought/suggestion:
I have never noticed but once Commanders die/retired/KIA, are they still viewable in an inactive file or are they gone forever? If possible, I wonder if it would be possible for those Commanders to shift to a past Commander tab so their accomplishments and lives (records, medals, comments) are still viewable? I tend toward paying a lot of attention to my Commanders to the point of entering in comments on their actions and lives essentially creating a fictional story/universe as I go with these guys and when they eventually move on, I would like to go back and see who came before the present generation and what they did. Maybe even name a new colony world or warship (ex: 'TFNS Steve Walmsley') off a past Commander of renown and this function would make the record keeping for such a lot easier.
Tinkering with VB6 last night and had an RP thought/suggestion:
I have never noticed but once Commanders die/retired/KIA, are they still viewable in an inactive file or are they gone forever? If possible, I wonder if it would be possible for those Commanders to shift to a past Commander tab so their accomplishments and lives (records, medals, comments) are still viewable? I tend toward paying a lot of attention to my Commanders to the point of entering in comments on their actions and lives essentially creating a fictional story/universe as I go with these guys and when they eventually move on, I would like to go back and see who came before the present generation and what they did. Maybe even name a new colony world or warship (ex: 'TFNS Steve Walmsley') off a past Commander of renown and this function would make the record keeping for such a lot easier.
This has been in and out a couple times, and the problem is always how to differentiate between the few dozen Officers you care about and the hundreds you don't. Do they get a tickbox while alive to mark them as special? Do all dead/retired officers go to a 'pool' for a couple of years before deletion to give you time to note their details? Do you manually confirm "save or delete" for each dead/retired officer?
Tinkering with VB6 last night and had an RP thought/suggestion:
I have never noticed but once Commanders die/retired/KIA, are they still viewable in an inactive file or are they gone forever? If possible, I wonder if it would be possible for those Commanders to shift to a past Commander tab so their accomplishments and lives (records, medals, comments) are still viewable? I tend toward paying a lot of attention to my Commanders to the point of entering in comments on their actions and lives essentially creating a fictional story/universe as I go with these guys and when they eventually move on, I would like to go back and see who came before the present generation and what they did. Maybe even name a new colony world or warship (ex: 'TFNS Steve Walmsley') off a past Commander of renown and this function would make the record keeping for such a lot easier.
This has been in and out a couple times, and the problem is always how to differentiate between the few dozen Officers you care about and the hundreds you don't. Do they get a tickbox while alive to mark them as special? Do all dead/retired officers go to a 'pool' for a couple of years before deletion to give you time to note their details? Do you manually confirm "save or delete" for each dead/retired officer?
The officers wouldn't be in the same listing as the active Commanders. The suggestion is they be moved to a separate tab for 'Past Officers'. Certainly, the list would eventually after a 100 years or so be a couple hundred (or more) names long but given the amount of effort I put into them and their backstories, I wouldn't mind having that long list. Besides, if they're inactive and separate from the active list - preferably on a different page/listing altogether - they aren't really taking any processing power or cluttering up the active screen
Tinkering with VB6 last night and had an RP thought/suggestion:
I have never noticed but once Commanders die/retired/KIA, are they still viewable in an inactive file or are they gone forever? If possible, I wonder if it would be possible for those Commanders to shift to a past Commander tab so their accomplishments and lives (records, medals, comments) are still viewable? I tend toward paying a lot of attention to my Commanders to the point of entering in comments on their actions and lives essentially creating a fictional story/universe as I go with these guys and when they eventually move on, I would like to go back and see who came before the present generation and what they did. Maybe even name a new colony world or warship (ex: 'TFNS Steve Walmsley') off a past Commander of renown and this function would make the record keeping for such a lot easier.
This has been in and out a couple times, and the problem is always how to differentiate between the few dozen Officers you care about and the hundreds you don't. Do they get a tickbox while alive to mark them as special? Do all dead/retired officers go to a 'pool' for a couple of years before deletion to give you time to note their details? Do you manually confirm "save or delete" for each dead/retired officer?
The officers wouldn't be in the same listing as the active Commanders. The suggestion is they be moved to a separate tab for 'Past Officers'. Certainly, the list would eventually after a 100 years or so be a couple hundred (or more) names long but given the amount of effort I put into them and their backstories, I wouldn't mind having that long list. Besides, if they're inactive and separate from the active list - preferably on a different page/listing altogether - they aren't really taking any processing power or cluttering up the active screen
Using VB figures so C# specifics won't be exact given certain changes being made but:
Each Academy generate 5 Officers a year. So even just 5 Academies on your homeworld early on pushes out 25 Officers annually.
So in 10 years you'll be churning out 250 Officers, most of which will likely never have a position and be culled a short few years after being produced after the preset amount of time.
In 100 years you'll have produced yet another 2,500 Officers. Now your list contains probably approximately 2,200 past-officers at a minimum.
Imagine loading up that list of 2,200 names to take a stroll down memory lane.
And that's just from 5 academies.
C# has a 'story character' flag for commanders. One option is to retain those commanders in a 'KIA' list if they die.
If the idea is to track notable officers, I'd have it track those with a certain minimum promotion point value in medals. Basically, just decorated officers get tracked.
Naval officers who got promoted X timesA-hem. ;D
Ground officers who participated in X battles (since their promotions are rarer)
Scientists who have been in charge of labs for X years
Administrators who have been leading a colony for X years
It could be similar to the automatic medal process, where the players has a relatively small number of variables to adjust and then the game automatically tracks it. The "In Memoriam" system could, in fact, build on top of the medal system.
Large: 2000 MSP, 5HS
Standard: 400 MSP, 1 HS
Small: 80 MSP: 0.2 HS
Tiny: 40 MSP 0.1 HS
Fighter: 20 MSP: 0.05 HS.
25% Increase Large: 2500: 5 HS
20% Increase Standard: 480: 1 HS
15% Increase Small: 95 MSP: 0.2 HS
10% Increase Tiny: 45 MSP 0.1 HS
Base Fighter 20 MSP: 0.05 HS
Ultra Large: 5,000,000: 100 HS
Very Large: 1,000,000: 20 HS
Large: 250,000: 5 HS
Basic: 50,000: 1 HS
Small: 10,000: 0.2 HS
Tiny: 5,000: 0.1 HS
30% Ultra Large: 6,500,000: 100 HS
25% Very Large: 1,250,000: 20 HS
20% Large: 300,000: 5 HS
15% Basic: 57,500?: 1 HS
10% Small: 11,000: 0.2 HS
Tiny: 5,000: 0.1 HS
Hey Steve. So a quick question/suggestion regarding the new Mantience storage bays and other such storage components. Can it be possible to have a gradual increase in storage efficiency per size increase rather than just a flat liner increase of space directly proportion to the HS used? It's always something that has irked me somewhat in the game where space means everything.
If I can use 5 Standard Maintenance storage bays or 1 Large storage bay, there is no difference, even though thematically that's 5 separate compartments with walls and all included. Yet it gives me the exact same space as the large storage bay. It would simply be nice if there was a gradual increase in storage the larger the size you have, even nicer if it applied to everything with storage mechanics.
So rather thenCode: [Select]Large: 2000 MSP, 5HS
Standard: 400 MSP, 1 HS
Small: 80 MSP: 0.2 HS
Tiny: 40 MSP 0.1 HS
Fighter: 20 MSP: 0.05 HS.
It can be a 10%+5% increase per size (rounded nicely)Code: [Select]25% Increase Large: 2500: 5 HS
20% Increase Standard: 480: 1 HS
15% Increase Small: 95 MSP: 0.2 HS
10% Increase Tiny: 45 MSP 0.1 HS
Base Fighter 20 MSP: 0.05 HS
A similar such 'formula' if you even want to call it that could be used for Crew Quarters, Fuel Storage and everything else which fits the function. Effectively making better use of the space with and it feels slightly more realistic than everything being linear.
Current FuelCode: [Select]Ultra Large: 5,000,000: 100 HS
Very Large: 1,000,000: 20 HS
Large: 250,000: 5 HS
Basic: 50,000: 1 HS
Small: 10,000: 0.2 HS
Tiny: 5,000: 0.1 HS
Suggested FuelCode: [Select]30% Ultra Large: 6,500,000: 100 HS
25% Very Large: 1,250,000: 20 HS
20% Large: 300,000: 5 HS
15% Basic: 57,500?: 1 HS
10% Small: 11,000: 0.2 HS
Tiny: 5,000: 0.1 HS
Hi Steve, is there any plan for greater ability to manipulate ruins, and the various spoiler spawns? It would be a great tool to have for 'Lets play' or forum run games to be able to spawn/edit ruins and precusrors from spacemaster mode.
Also is it possible to be able to have a toggle to make the game 'locked' without the spacemaster password. i. e. you can't advance time without entering it. Would help greatly with said forum games by being able to provide the save to players without worrying about them zooming forward in time.
Quote from: Saros link=topic=9841. msg118445#msg118445 date=1580484964Hi Steve, is there any plan for greater ability to manipulate ruins, and the various spoiler spawns? It would be a great tool to have for 'Lets play' or forum run games to be able to spawn/edit ruins and precusrors from spacemaster mode.
Also is it possible to be able to have a toggle to make the game 'locked' without the spacemaster password. i. e. you can't advance time without entering it. Would help greatly with said forum games by being able to provide the save to players without worrying about them zooming forward in time.
Hey Steve, sorry if I missed it but did you have any 2c on these?
New Species Attributes
Each Species now has four new attributes, all of which default to 1.0 but have a low chance to be higher or lower:
1) Population Growth Rate Modifier
2) Population Density Modifier. This affect max population capacity, infrastructure capacity and orbital habitat capacity. Some species prefer more open environments while some can accept higher population densities than normal.
3) Research Rate Modifier (increases or decreases research rate)
4) Production Rate Modifier (affects factories, refineries and shipbuilding)
Player-created Species can have custom values set. Also note this is at the species level, not the empire level. Empire modifiers to Research or Production are based on technology rather than innate ability.
Your B is already in:Ah, that‘s nice... thanks.
http://aurora2.pentarch.org/index.php?topic=8495.msg100712#msg100712 (http://aurora2.pentarch.org/index.php?topic=8495.msg100712#msg100712)
In VB6 Aurora when you copied a Class Design the Class Priority wasn't copied to the new design. Intentional? Otherwise it would be nice if it was copied.
In VB6 Aurora when you copied a Class Design the Class Priority wasn't copied to the new design. Intentional? Otherwise it would be nice if it was copied.
In VB6 every field had to be copied manually in code so it was easy to miss something, or add a new field and forget to update the copy code.
In C#, you can clone an object, which will replicate every value-based member of that object. If new values are added later, they will still be copied by the older code. Anything reference-based (the address of another object rather than the object itself) is more of an issue as the reference is copied rather than the object, so that needs more care - still far better than VB6 though.
I seem to be spending a lot of time rearranging systems on the galactic map to please my aesthetic sensibilities, so could we please have a box to specify the XY coordinates of systems on the galactic map when moving them around? It's a bit of a hassle right now. Actually, since the Real Stars catalogue in the game already include the XYZ coordinates of all stars, an option to snap them to their actual positions on the map would also work.
In VB6 I don't think there is a menu entry for the "Geological Survey Report" - I only could access that window through the "System Maps" screen, the button at the top. Can we have a main menu entry for that window in C#?
...presumably if they were truly random then you would be getting stuck with some truly horrifically bad administrators at times.
Thats kind of what I mean - for a military or totalitarian hierarchy, appointing the best man for the job makes sense, but for a democratic hierarchy, you have to make do with who you've got, and the choice is not often made by the electorate to prioritize what we as players would prioritize.
No, any form of government always tries to appoint the most appropriate people to the job.
However, the governor of a 100m colony on the moon is not a civil serveant but a political figure in charge of a very large nation in modern real terms. Under most democratic government, this bloke would serve limited terms. If I am roleplaying as a democracy, I can't really imagine what the civilian administrators represent - are they elected politicians or senior civil serveants? is the governor of earth a presidential figure or the equivalent of like permanent undersecretary of some ministry?
We the player are the elected governement, the Minister for Mining & Minerals or whoever. The Civiilian Administator is responsible for carrying out our policies as efficiently as possible. Ergo, senior civil servant.
I think we might be speaking at crosspurposes here. I can imagine that the civilian adminstrator of a comet mining colony is a directly appointed civil serveant, fair enough - picking the guy with the best mining skill is a no-brainer, that colony represents a commercial not political interest and this is clearly a job best given to professionals who may serve professionally in that role for a long period of time. However, the governor of a 100m colony on the moon is not a civil serveant but a political figure in charge of a very large nation in modern real terms. Under most democratic government, this bloke would serve limited terms. If I am roleplaying as a democracy, I can't really imagine what the civilian administrators represent - are they elected politicians or senior civil serveants? is the governor of earth a presidential figure or the equivalent of like permanent undersecretary of some ministry?
As a player, I might want a governor who is going to increase construction and pop growth, and I would want that guy to serve indefinitely and get better over time. However, under a political process, the 100m electorate of the lunar colony might want to prioritize something else for their own local reasons which may appear irrational to the player (brexit? the lunar colony clearly needs shipyard bonii even though there are no shipyards, thats a campaign promise you can believe in!). And then 5 years in the future, the agenda would change, and a different set of debately releveant priorities would emerge.
Under the c# command rules, ships can have multiple officers and we have several commands over them. It might be fun to add a similiar level of complexity to civilian adminstrators, with some delineation between permanent appointed civil serveants working in professional roles, and temporary elected roles for colonies with larger population, or both on the same colony.
That would break the academy mechanic, due to conjuring civilian administrators out of thin air.
On the Research section, change "Completion Date" to "Days to Completion".
And use "Days to Completion" in ascending mode.
It is truly irritating to have the dates spread all over the board.
Is it possible to get a new game parameter to configure energy weapon breakdowns chance? Reading from the post for me they seem to be too frequent (and too costly in MSP) and I would like to somehow change this.
On the Research section, change "Completion Date" to "Days to Completion".
And use "Days to Completion" in ascending mode.
It is truly irritating to have the dates spread all over the board.
Or use Completion Date ascending, for a similar effect.
I like it and I support it, especially if we can control individual active sensors instead of all or none. Currently, all sensors are on or all sensors are off on a hull.
Bit of a niche use request, but a little check box on the production/colony management screen that allows us to mark a colony to be automatically abandoned once devoid of all population and installations would be kind of nifty. ;D
I seem to be spending a lot of time rearranging systems on the galactic map to please my aesthetic sensibilities, so could we please have a box to specify the XY coordinates of systems on the galactic map when moving them around? It's a bit of a hassle right now. Actually, since the Real Stars catalogue in the game already include the XYZ coordinates of all stars, an option to snap them to their actual positions on the map would also work.
Except the map is 2D and the coordinates are 3D :)
I'll take a look at this but probably post-release,
So I'm playing a game of 7.1, and caught myself doing the same thing over and over, that I've often done, but hardly ever think of.
When I am designing ships and technology, I create two techs for every single component design where its new to my current game or a different size/needs than prior parts have. One is just a component like any other, used like any other, to be researched and produced as regular ship components.
The other is a "prototype" part, and under a house rule, is not produced, which I instant research, so it can be used to design with, I put "prototype" in front of the name to indicate that.
This lets me fully design a ship, missile, or turret all the way to the point of being able to produce it, without having to wait for potentially months or years of research to finish before I can find out I'm a dolt and need to rework my design. I simply do not produce them until I have done the research on the parts along the way, but I gain the ability to spot the need to make changes before I have wasted the time researching them.
I'm sure many of us have been here before. You want a new warship with a turreted weapon, lets say, gauss guns for PD. You pick a type, research it. Then you make the turret, research it. Then you go to make the ship, and only one turret fits, two is so close but not quite—the crew (or reactors for other weapons) cost you too much. You could wait for the slipway to be enlarged, in which case the ship will need new/more engines or be slower because its bigger. Or you wait for a slightly smaller turret that will fit to be researched, say by reducing turret armor, or reducing the turret tracking speed by a small amount to shrink it a little bit.
Or you design a gauss gun, get the tech for it, have the tech available as a prototype component so you can design the turret, which itself is available as a prototype component, and see before any time is wasted researching components that it needs to be made a little smaller, change it, and then begin research with a workable turret.
So, the request, if we could get two things:
A new button in the research window, to generate a prototype part from a research project, which would work on any technology which generates a component - so all the racial techs and things like damage control, ecm, fuel tanks, etc. Only current research prjects should be available for prototyping—if all you have is 10cm lasers, then no prototyping 80cm advanced spinals yet, but you could prototype a 12cm laser since its the next project in the laser line of techs, and would be a currently available research project.
When the associated technology completes which yields the component that the prototype is substituting for, replace the prototype component in the design with the real one so players who are just getting started on a large construction project don't have many parts to track down and replace one by one.
So I'm playing a game of 7.1, and caught myself doing the same thing over and over, that I've often done, but hardly ever think of.
When I am designing ships and technology, I create two techs for every single component design where its new to my current game or a different size/needs than prior parts have. One is just a component like any other, used like any other, to be researched and produced as regular ship components.
The other is a "prototype" part, and under a house rule, is not produced, which I instant research, so it can be used to design with, I put "prototype" in front of the name to indicate that.
This lets me fully design a ship, missile, or turret all the way to the point of being able to produce it, without having to wait for potentially months or years of research to finish before I can find out I'm a dolt and need to rework my design. I simply do not produce them until I have done the research on the parts along the way, but I gain the ability to spot the need to make changes before I have wasted the time researching them.
I'm sure many of us have been here before. You want a new warship with a turreted weapon, lets say, gauss guns for PD. You pick a type, research it. Then you make the turret, research it. Then you go to make the ship, and only one turret fits, two is so close but not quite—the crew (or reactors for other weapons) cost you too much. You could wait for the slipway to be enlarged, in which case the ship will need new/more engines or be slower because its bigger. Or you wait for a slightly smaller turret that will fit to be researched, say by reducing turret armor, or reducing the turret tracking speed by a small amount to shrink it a little bit.
Or you design a gauss gun, get the tech for it, have the tech available as a prototype component so you can design the turret, which itself is available as a prototype component, and see before any time is wasted researching components that it needs to be made a little smaller, change it, and then begin research with a workable turret.
So, the request, if we could get two things:
A new button in the research window, to generate a prototype part from a research project, which would work on any technology which generates a component - so all the racial techs and things like damage control, ecm, fuel tanks, etc. Only current research prjects should be available for prototyping—if all you have is 10cm lasers, then no prototyping 80cm advanced spinals yet, but you could prototype a 12cm laser since its the next project in the laser line of techs, and would be a currently available research project.
When the associated technology completes which yields the component that the prototype is substituting for, replace the prototype component in the design with the real one so players who are just getting started on a large construction project don't have many parts to track down and replace one by one.
I've added prototype components (see below). Not exactly as you specify above, but it achieves most of what you suggested. I'll look separately at allowing prototype components to use tech that has not yet been researched.
http://aurora2.pentarch.org/index.php?topic=8495.msg119332#msg119332
Was going to put this in the changes discussion, but I think it goes here better. Suggestion:
Allow prototypes to be researched.
If you do this, then you can probably get away with eliminating the old "un-researched design" components. Basically, the old distinction between un-researched designs and researched components gets captured in the prototype flag. This would also ease the workflow for changing a prototype class design into a "real" design - the state of whether the ship design has a (P) is a dependent value (e.g. a Property with a non-trivial get function that looks at the rest of the state) - when the last (P) component in the design is researched the class design automagically loses its (P) and is available for retooling.
John
Was going to put this in the changes discussion, but I think it goes here better. Suggestion:
Allow prototypes to be researched.
If you do this, then you can probably get away with eliminating the old "un-researched design" components. Basically, the old distinction between un-researched designs and researched components gets captured in the prototype flag. This would also ease the workflow for changing a prototype class design into a "real" design - the state of whether the ship design has a (P) is a dependent value (e.g. a Property with a non-trivial get function that looks at the rest of the state) - when the last (P) component in the design is researched the class design automagically loses its (P) and is available for retooling.
John
Also a question... what are the target priority for missiles. Will they always target the closest missiles that have not the correct number of missiles or the ones furthest out. In general I think you would want the ones furthest out as otherwise you will tend to get bigger salvos for the PD to deal with if your AMM can't intercept everything. In general it probably is better that salvos hit sooner but at an average lower amount. Or perhaps make it a choice on the PD fire-control setting perhaps.
If not already implemented, it would be handy to have ”quick info” and ”quick orders” to a selected fleet on the system map. Like set heading & speed, activate AS/shields, fuel/ammo status, something along those lines... perhaps by right-clicking a fleet a menu will appear so we don’t clutter the map.
And for the future it would be great if we could set a destination(Ex. 10 systems away) to the captain through a quick-order. Search bar, perhaps + pathfinding routine. Perhaps only for colonies with Space Ports. So to narrow the list and exclude clutter colonies.
When your empire is 150-200+ years old, it takes awhile just finding the right fleet and the right destination.
Just some thoughts....
Was going to put this in the changes discussion, but I think it goes here better. Suggestion:
Allow prototypes to be researched.
If you do this, then you can probably get away with eliminating the old "un-researched design" components. Basically, the old distinction between un-researched designs and researched components gets captured in the prototype flag. This would also ease the workflow for changing a prototype class design into a "real" design - the state of whether the ship design has a (P) is a dependent value (e.g. a Property with a non-trivial get function that looks at the rest of the state) - when the last (P) component in the design is researched the class design automagically loses its (P) and is available for retooling.
John
Nothing automagical about that. Clearly, the design bureau has some clue about the specifications and expected results of the component design, so they put some place holders in the design and when the components were completed integrated them properly after some refinement.
Was going to put this in the changes discussion, but I think it goes here better. Suggestion:
Allow prototypes to be researched.
If you do this, then you can probably get away with eliminating the old "un-researched design" components. Basically, the old distinction between un-researched designs and researched components gets captured in the prototype flag. This would also ease the workflow for changing a prototype class design into a "real" design - the state of whether the ship design has a (P) is a dependent value (e.g. a Property with a non-trivial get function that looks at the rest of the state) - when the last (P) component in the design is researched the class design automagically loses its (P) and is available for retooling.
John
I've implemented this suggestion:
http://aurora2.pentarch.org/index.php?topic=8495.msg119347#msg119347
Also a question... what are the target priority for missiles. Will they always target the closest missiles that have not the correct number of missiles or the ones furthest out. In general I think you would want the ones furthest out as otherwise you will tend to get bigger salvos for the PD to deal with if your AMM can't intercept everything. In general it probably is better that salvos hit sooner but at an average lower amount. Or perhaps make it a choice on the PD fire-control setting perhaps.
About a month ago Steve changed PD to target the largest salvo first.
Also a question... what are the target priority for missiles. Will they always target the closest missiles that have not the correct number of missiles or the ones furthest out. In general I think you would want the ones furthest out as otherwise you will tend to get bigger salvos for the PD to deal with if your AMM can't intercept everything. In general it probably is better that salvos hit sooner but at an average lower amount. Or perhaps make it a choice on the PD fire-control setting perhaps.
About a month ago Steve changed PD to target the largest salvo first.
I got the impression that was for beam weapon final fire only but if it is all PD fire-controls then that is great. But I still would like to have a minimum distance as well as that would help allot for AMM engagement where you also have a strong beam PD present.
Viper S1 AMM
Missile Size: 1 MSP (0.05 HS) Warhead: 1 Armour: 0 Manoeuvre Rating: 41
Speed: 49000 km/s Engine Endurance: 1 minutes Range: 1.9m km
Cost Per Missile: 1.482
Chance to Hit: 1k km/s 2009% 3k km/s 656% 5k km/s 401.8% 10k km/s 200.9%
Materials Required: 0.25x Tritanium 1.232x Gallicite Fuel x33.25
Taipan S1 AMM
Missile Size: 1 MSP (0.05 HS) Warhead: 1 Armour: 0 Manoeuvre Rating: 38
Speed: 42200 km/s Engine Endurance: 6 minutes Range: 14.6m km
Cost Per Missile: 1.338
Chance to Hit: 1k km/s 1603.6% 3k km/s 532% 5k km/s 320.7% 10k km/s 160.4%
Materials Required: 0.25x Tritanium 1.088x Gallicite Fuel x283.25
If not already added, how about having Training slowly decrease over time as "crew rotate out, get rusty, or die?" However, recent battles will slow down this descent for quite a while, until it again returns back to normal.
A QoL improvement:
Can the 'Summary' tab of the Colony (F2) window {this one: http://www.pentarch.org/steve/Screenshots/Crusade/Space1889_01.PNG (http://www.pentarch.org/steve/Screenshots/Crusade/Space1889_01.PNG)} section "Manufacturing Worker Breakdown" auto-sort itself to descending order by number of workers (with "Available Workers" still at the end though)?
Allow refit of electronics on any appropriate shipyard
Crusade AAR made me thinking about updating older ships vs building new ones. In my own game in VB6 Aurora, when I create new generations of ships and retool shipyards, I loose the ability to make small upgrades on my older generation vessels (which is not realistic). To be able to keep the old ships updated with newer FCS and sensors, you need to either have to make costly refit to them to get them to a new generation standards and replace their engines and armor along the way (which is unrealistic and super inefficient), or have as many separate shipyards (that will be idle and PITA to deal with) that were tooled for this particular design that you still use.
So, I propose allowing refit of electronic modules (sensors and fire controls) on any appropriate (type and size) shipyard.
Optional: Allow other small changes to be done the same way, regardless of what design the shipyard is tooled for. Similar to how USN refitted its old 21 knot Standard type battleships in WW2 with new 5 inch DPs. BB-45 - USS Colorado, for example, was built on the East Coast in 1921, but was under refit at West Coast in 1942 where it received new 5/38 DPs.
As an example, here is Fleet Auto-RouteWill this auto route feature also in the "repeat order list"? Would be nice if a transport would recalculate the (always changing) shortest route due to Lagrange points etc.
http://aurora2.pentarch.org/index.php?topic=8495.msg106871;topicseen#msg106871
You'd also need a slipway that's large enough to fit the ship and a shipyard that can handle the components.
When you order a capital ship in for work on the electronics you aren't pulling chips from the motherboard and slotting in new chips, you are moving hundreds if not thousands of tons of sensitive equipment in and out of the armour layer, consisting of sensor panels, mechanical gears to adjust the panels, large amounts of computation equipment to process the data the sensors gather and kilometers and kilometers of cabling along with adjustments to the ship's power distribution system to deal with the different demands of the new electronics.
Hi all, long time lurker, first time poster (haha). Been reading through a lot of this, but not all, so apologies if it's been discussed. Any chance for a 'disable missile tech' option at campaign start? I love me some Star Wars, and would love for NPR's to play by the same rules - beam weapons only. Maybe have such an option also boost beam ranges and whatnot to keep the game smooth. Possible/thoguhts?
Amazing game, Steve. I've been (im)patiently awaiting C# version for a while haha.
Even in that case, I doubt the battleships could just drop by any shipyard at any time and have the guns fitted. There would need to be some scheduling and preparation work.Of course. The same applies to the situation when you need to make repairs (after combat) and replace damaged equipment. Fortunately, in Aurora, you don't need a shipyard tooled for specific design to be able to repair ships. Only big enough and of the correct type.
You'd also need a slipway that's large enough to fit the ship and a shipyard that can handle the components.That's what I said: on any appropriate shipyard, in terms of size and type.
I have a minor request : can we please remove the gender of commanders from their stats? I'm not aware of the exact algorithm Aurora uses for naming commanders, but while it does an okay-ish job with Anglo/European names, it absolutely butchers the naming conventions followed by other cultures. It's like half the women get unambiguously male names, while a quarter of the males get unambiguously female names, and it really breaks my immersion when I see that 'M' next to 'Lieutenant Katie Stanton' or 'F' next to 'Scientist Roger Mansson'.
Fixing it will require some way of cataloguing and gendering names, which I don't think is worth the effort. It's just easier to remove the classification entirely and leave the gender of commanders ambiguous/use gender-neutral language wherever it comes up.
The name files are already segregated into last names, female first names and male first names. The 'F' or 'M' is dictated solely by which file the first name is drawn from.
You can easily edit the files to remove (or move) the names you have a problem with, and then share the edited files here.
There also is a problem with agility in that it increase the chance of AMM to intercept enemy missile over time that does not scale well with the other sides ability to avoid being intercepted. So, the current agility ,echanic will make AMM intercept enemy missiles of the same technology more or less 100% every time eventually making missiles as a weapons almost useless at some point against someone with the same technology level.I find the missile calculations to be unsatisfactory in general, factors such as target aspect, size, and acceleration aren't taken to account in the game, but are far more important than target velocity for real missiles. It's really easy to throw a dart at a 70mph train and hit it from directly in front of it, it'd be much harder to throw a dart and intercept a 70mph curveball at a right angle, but both of those scenarios would be equivalent in aurora because only the target's velocity and the dart's unmaneuverability are accounted for.
For that reason I always just set the agility level to a certain level in my games when I play multi-faction games in such a way that AMM have roughly a 30-40% chance to intercept enemy missiles of the same technology level. Of course the AI are restricted to use agility like normal but I'm not too concerned about that.
I would like to see agility being redone so that it scale better in general. I still think there is a use for agility as a concept as I don't think that a missiles speed should be the only thing that govern how good it is at hitting something or avoid being hit. The problem is that speed is both a factor of hitting and avoid being hit where agility only allow you to hit more easily. In my opinion I think that both of these should do both things they just should do it differently. Let's say that speed is about 75% of the missiles defence and 25% of its ability to hit while agility is 75% ability to hit but also about 25% of the ability to avoid being hit. I mean. . . speed of the missile effect thing like the time you have to intercept it from the time you detect it and how effective area PD can be against it. Speed is a very strong attribute for the missiles defence in many respects, the chance to hit a missile and the chance for a missile to hit something should be reevaluated in the future in my opinion. Make agility the primary source for a missile to target something and speed is its main defence but both values should apply to some degree in both calculations. This would then make both values roughly equally important and balance each other out over the course of an entire game.
I'm kindof in the remove agility camp at the moment, personally.
e: Not militantly so, I dont really care that much, but I can see the argument for just doing away with it.
Wouldn't it be better that Speed is your chance to hit and Agility is your chance to avoid being hit? If both affect both, then it's just another Excel sheet where you punch in numbers and the macro tells you where the sweet spot lies. If they affect different things, then you would value them differently depending on what the purpose of that missile is - attacking other missiles, avoiding AMMs, avoiding PD, hitting planets, hitting ships, and so on.
Or am I barking up the wrong tree?
Tons | "Radius" | Speed | "Agility" |
2.75 | 0.869 | 80000 | 184.1 |
5.5 | 1.095 | 70000 | 127.9 |
11 | 1.38 | 60000 | 87 |
16.5 | 1.579 | 50000 | 63.3 |
33 | 1.99 | 40000 | 40.2 |
50 | 2.285 | 40000 | 35 |
250 | 3.908 | 30000 | 15.4 |
500 | 4.924 | 30000 | 12.2 |
750 | 5.636 | 20000 | 7.1 |
1000 | 6.204 | 20000 | 6.4 |
2000 | 7.816 | 20000 | 5.1 |
3000 | 8.947 | 20000 | 4.5 |
5000 | 10.608 | 20000 | 3.8 |
I'm kindof in the remove agility camp at the moment, personally.
e: Not militantly so, I dont really care that much, but I can see the argument for just doing away with it.
I'm kindof in the remove agility camp at the moment, personally.
e: Not militantly so, I dont really care that much, but I can see the argument for just doing away with it.
Simply removing it and rely on speed alone is not a good solution in my opinion as that makes slow long range missiles quite unfeasible to build. You need to add some agility to these so they can actually hit something. With the fuel changes in C# I'm pretty sure this will be needed. Otherwise you would have to completely rely on multi-stage missiles which is unnecessarily complicated if you need them in all long range cases.
I tend to very rarely use it because generally adding more speed has been a better use of mass in terms of increased hit chance, with only a few exceptions that I remember. I also tend to make fairly fast longer-ranged missiles anyhow (admittedly at a cost) because the time it takes for the missiles to reach the target has been very important to the pacing of the engagement. Generally I need to loiter around until the missiles reach the target before I can flee, or I want to save on ammo by only engaging targets that survived the previous salvo before launching the next one, meaning the faster each salvo resolves the faster I can launch the next one without wasting huge amounts of ammo (sensor missiles only help with this when the enemy is all stacked into the same place, but I do employ them to mitigate that somewhat).
To be honest the survivability aspect of agility was never something I looked into much. . .
So it would be nice to evaluate the difference between using agility or not. How can we do that?
Some manner of multiplayer support
Or something to make the life of a space master easier when making community games
Best possible would be a way to set up a server or have people being able to access the same save game, but perhaps only being able to see and control a particular race except their own (except the spacemaster). The game would largely played like normal (although, perhaps give the space master some ability to control what a player can see and do, during play or game setup) except the passage of time could either be controlled by the space master or by some maner of player voting. Like, have the speed be the highest possible that all agree on.
<snip>
Mod Supopport
Steve, lets have a little talk, you are apparently weirdly against open sourcing things (according to one of your latest posts. I wasn't thinking of it before but your posts made me think of it. Tough, I stil don't know why, despite the name the posts did not really explain it), and that is okay, its your game and its your decision alone what to do with it, but maybe consider having parts of the code open to enable moders and alike to work with your game? You should look at the guys doing CDDA and Dwarf Fortress, they done so quite successful and it benefited their games tremendously. If you did, I might be able to say, make a client of my own to enable other players to take control of things during a live stream of space battles. It could be really great fun, to assemble a bunch of people, have some act as generals, others a ship pilots and have them all able to act and make decisions on their own. Or whatever else, please do consider it. Sharing is caring!
Also, stay healthy! Wont want you do die from Corona before releasing C# ;p
Mod Supopport
Steve, lets have a little talk, you are apparently weirdly against open sourcing things (according to one of your latest posts. I wasn't thinking of it before but your posts made me think of it. Tough, I stil don't know why, despite the name the posts did not really explain it), and that is okay, its your game and its your decision alone what to do with it, but maybe consider having parts of the code open to enable moders and alike to work with your game? You should look at the guys doing CDDA and Dwarf Fortress, they done so quite successful and it benefited their games tremendously. If you did, I might be able to say, make a client of my own to enable other players to take control of things during a live stream of space battles. It could be really great fun, to assemble a bunch of people, have some act as generals, others a ship pilots and have them all able to act and make decisions on their own. Or whatever else, please do consider it. Sharing is caring!
Also, stay healthy! Wont want you do die from Corona before releasing C# ;p
I'm not sure how I could have made it clearer :)
As stated in the FAQ entry, I have zero interest in project managing a group of developers or trying to integrate someone else's code. I'm not interested in Aurora having the best possible code or the best possible architecture or debating what that might look like. I simply want to have fun programming and playing. I do not want to share the actual code, which represents thousands of hours of work on my part. I don't want to waste time on bug reports caused by someone else hacking around and I don't want multiple potentially competing versions of Aurora. In simple terms, I want to maintain control over my creation.
Now it might seem 'weird' to you that I am not prepared to hand over my work to everyone and that's fine. I'm not trying to defend my stance on this, I am simply stating it so there is no confusion.
And to add from Dwarf Fortress, the mods can be great fun but they are also a massive headache. A vast amount of bug reports and complaint posts on the Bay12 forum are from modded games. At least DF has thousands of experienced players who act as a filter between the sole developer and the community. Aurora doesn't. Not to mention that I can't even imagine how frustrating it is for modder A to have people complain about stuff because of modder B due to players mix'n'matching stuff that isn't compatible. We know from every modding community that players do stupid stuff like that all the time.Couple of points - In the original posters comment, he mentions the open source nature of Catalysm DDAMod SupopportI'm not sure how I could have made it clearer :)
I'm not sure how I could have made it clearer :)
As stated in the FAQ entry, I have zero interest in project managing a group of developers or trying to integrate someone else's code. I'm not interested in Aurora having the best possible code or the best possible architecture or debating what that might look like. I simply want to have fun programming and playing. I do not want to share the actual code, which represents thousands of hours of work on my part. I don't want to waste time on bug reports caused by someone else hacking around and I don't want multiple potentially competing versions of Aurora. In simple terms, I want to maintain control over my creation.
Now it might seem 'weird' to you that I am not prepared to hand over my work to everyone and that's fine. I'm not trying to defend my stance on this, I am simply stating it so there is no confusion.
Fer Cthullu's sake!
Steve is very nearly NOT releasing C# Aurora in ANY format to the public, because you all can't respect the mans property.
There will be no mod support. The source code will not be released. That's pretty clear from the MULTIPLE posts and thread that Steve created.
Imagine you had a boat, that you had built from scratch. It took several hundred hours to create. Now imagine sharing that boat with everyone, because you are proud of it. Now imagine everyone chopping that boat to pieces, changing things around to suit them. That boat that you built, suddenly doesn't look like your boat, your labor of love.
I would really, really, really like to actually be allowed to play with Aurora C#. I would like it to be released in a few weeks.
There is already a delay, caused by this community, with the repeated blatant statements that you will not respect the mans wishes, and will simply hack the source code anyway. This has led to an actual DELAY!!!
Please just respect Steve's wishes.
It isn't like its hard to figure them out.
There's a password for Space Master functions (if left blank Aurora treats this as 'no password'). You can lock each race behind its own password.
I can't remember if the current version supports locking time advance behind the SM password, but you can instruct your players that only the SM will advance time.
Now you can email the database to each player in turn (or use some sort of virtual drive and versioning support) and 'run' multiplayer Aurora.
(Note, however, that when two (or more) players start fighting each other the game is going to bog down to an epic degree. It can take days or even weeks for players A & B to finish a three-Aurora-hour fight during which players C through H can do nothing.)
Problem with that is its entirely honor based. Might work if you do it with close friends, but if you do some forum game or something its almost guaranteed someone will advance the game to know whats going to happen to get an advantage.
As for it taking a long time, well, hence the suggestion to make it multiplayer so one can do live battles and not have the battles bog down games forever.
Maybe Steve could create an option that blocks time Progression for regular players if activated?
But a feature I'd like to see for role-playing purposes is the ability to give the control of a race to the AI permanently, effectively converting it into an NPR, control of which you couldn't take back without the developer mode. This wouldn't exactly need to be a high priority feature, should Steve be interested in this, but rather if/when there's enough loose time to implement it in.
It's on the wish list, but the complexities of 'taking over' an empire that wasn't designed according to NPR AI rules are vast and daunting -- and the AI rules don't currently include "don't use missiles" or "rely heavily on boarding actions" or "only build general-purpose cruisers. "I'm not actually saying it needs to have special rules, in my opinion, the AI could take everything to a completely different direction if deemed it better. But I do understand that it isn't nearly as simple as it might sound and hence probably shouldn't be very high on the priority list.
Quote from: Father Tim link=topic=9841. msg119684#msg119684 date=1584393008It's on the wish list, but the complexities of 'taking over' an empire that wasn't designed according to NPR AI rules are vast and daunting -- and the AI rules don't currently include "don't use missiles" or "rely heavily on boarding actions" or "only build general-purpose cruisers. "I'm not actually saying it needs to have special rules, in my opinion, the AI could take everything to a completely different direction if deemed it better. But I do understand that it isn't nearly as simple as it might sound and hence probably shouldn't be very high on the priority list.
Quote from: Father Tim link=topic=9841. msg119684#msg119684 date=1584393008It's on the wish list, but the complexities of 'taking over' an empire that wasn't designed according to NPR AI rules are vast and daunting -- and the AI rules don't currently include "don't use missiles" or "rely heavily on boarding actions" or "only build general-purpose cruisers. "I'm not actually saying it needs to have special rules, in my opinion, the AI could take everything to a completely different direction if deemed it better. But I do understand that it isn't nearly as simple as it might sound and hence probably shouldn't be very high on the priority list.
It's extremely complex and therefore unlikely to happen any time soon. The AI currently decides on a doctrine and then designs and builds a fleet according to that doctrine. It knows what everything does, because it was built to a plan. It would be a lore more complex for the AI to understand everything designed by the player and then develop a doctrine of its own based on those designs.
It's extremely complex and therefore unlikely to happen any time soon. The AI currently decides on a doctrine and then designs and builds a fleet according to that doctrine. It knows what everything does, because it was built to a plan. It would be a lore more complex for the AI to understand everything designed by the player and then develop a doctrine of its own based on those designs.Quite understandable. I reckon the AI could just roll for the doctrine and ignore any potentially pre-existing designs, that would cut some corners and make it a bit less complex for the AI. That would risk losing some work, but I suppose a warning message about AI ignoring certain stuff would prevent it from being a surprise for the player. Handing the stuff for AI to handle once you've set up stuff, like colonies in multiple pre-generated systems with various installations, and so forth, would make things less prone for accidents. I do realize that it can be done through already existing tools to a degree via SM, but the ability to double-check the details before handing the keys would be handy. I'm aware that my scenario is going to be most likely a very rare in nature compared to the average playthrough and I'll make do with any tools available to the best of my abilities :)
Uh, there isn't one. There's no 'dodge bonus' or anything for Agility -- it has zero effect on defense, only on chance to hit.
Quote from: Steve WalmsleyIt's extremely complex and therefore unlikely to happen any time soon. The AI currently decides on a doctrine and then designs and builds a fleet according to that doctrine. It knows what everything does, because it was built to a plan. It would be a lore more complex for the AI to understand everything designed by the player and then develop a doctrine of its own based on those designs.Quite understandable. I reckon the AI could just roll for the doctrine and ignore any potentially pre-existing designs, that would cut some corners and make it a bit less complex for the AI. That would risk losing some work, but I suppose a warning message about AI ignoring certain stuff would prevent it from being a surprise for the player. Handing the stuff for AI to handle once you've set up stuff, like colonies in multiple pre-generated systems with various installations, and so forth, would make things less prone for accidents. I do realize that it can be done through already existing tools to a degree via SM, but the ability to double-check the details before handing the keys would be handy. I'm aware that my scenario is going to be most likely a very rare in nature compared to the average playthrough and I'll make do with any tools available to the best of my abilities :)
Quote from: Steve WalmsleyIt's extremely complex and therefore unlikely to happen any time soon. The AI currently decides on a doctrine and then designs and builds a fleet according to that doctrine. It knows what everything does, because it was built to a plan. It would be a lore more complex for the AI to understand everything designed by the player and then develop a doctrine of its own based on those designs.Quite understandable. I reckon the AI could just roll for the doctrine and ignore any potentially pre-existing designs, that would cut some corners and make it a bit less complex for the AI. That would risk losing some work, but I suppose a warning message about AI ignoring certain stuff would prevent it from being a surprise for the player. Handing the stuff for AI to handle once you've set up stuff, like colonies in multiple pre-generated systems with various installations, and so forth, would make things less prone for accidents. I do realize that it can be done through already existing tools to a degree via SM, but the ability to double-check the details before handing the keys would be handy. I'm aware that my scenario is going to be most likely a very rare in nature compared to the average playthrough and I'll make do with any tools available to the best of my abilities :)
I mean, the ai won't know what to do with the ships you give it at all, so ignoring them would presumably mean the ships are stationary and do nothing.
I think that is potentially a pretty good option. Have some ability to configure (some/all?) of the factors that go into the AI's design behavior that would have otherwise have been random.
Not sure if its been suggested or already in the game, the list over features is getting pretty long so its hard to find out but
Being able to use theoretical designs and research projects in ships design and other projects
I have before made various suggestions on ship design, but one thing that would be lovely is being able to use designs that you have made but not yet researched when designing ships and other things. Its really annoying having to guess or calculate how big a jumpdrive or cloak or whatever you need when designing a ship and getting it wrong and having to design and research a new one that fits cause you it more crew quarters than you expected or something. Instead you could make a ship that included various possible designs that are yet to be researched and then research the design.
At some point in the future it'll be nice to have a certain 'fuzziness' to active and passive sensor detection. Detection of vessels is only guaranteed till a certain percentage of the sensor range against that TCS, with the percentage detection chance per increment (probably an hour?) dropping linearly till the maximum sensor range. Effectively, at the edge of sensor ranges ships could remain undetected or they could only be tracked very sporadically. This will extend to missile fire controls and the like. ECM and ECCM will modify the detection chance per increment for both active sensors and missile fire controls, but not passive sensors.
There could also be a modifier allowing you to trade between maximum sensor range and the maximum range at which detection is guaranteed while maintaining sensor cost and GPS. I think this might quite neatly solve the fighter issue - with active sensors modified to have a very high maximum range but a very low maximum range at which detection is guaranteed, fighter squadrons will eventually be detected by shipborne active sensors at long ranges, but they won't be tracked continuously and firing missiles will be foolhardy. You'll have to dispatch a destroyer squadron or two to investigate, so you'll be encouraged to maintain escort vessels for your fleets.
Of course, the main drawback as usual will be game performance degradation. On the plus side - more choices to active sensors design, a reason to bring along escorts, more vulnerable box launcher fighter squadrons, etc.
The sensor model used to function differently. For example, you only saw a thermal signature - but you couldn't tell the ship. The consequence was extra micromanagement to send out a ship to check every contact, which got tedious fast, so I moved to the current immediate-knowledge model instead.
This would be useful if there was a manpower mechanic attached to ground combat, but there isn't. Ground units are very much depicted by their equipment, and the manpower attached to it is utterly inconsequential. A PW(L) infantryman may be rated at 3 tons in weight/shipping, but does that mean that a 60 ton Heavy Anti Vehicle Static Unit is made up of 20 men?Agreed with Hazard.
. . . As well, for "long duration missions" it will keep its speed low during patrol to conserve fuel, but increase speed as necessary to avoid detection or evade hostile ships. . .
I was wondering, could certain system bodies that are in close orbit of gas giants or near a hyperactive star have a minimum radiation level? Like, for most system bodies radiation will eventually settle down to zero, but for these, it will instead start at a base number within range of around 10-200 or so, determined by proximity to a star (below a certain orbit radius) and type of star (focusing on flare stars, neutron stars, pulsars and the like) and proximity to a gas giant (below a certain orbit radius) and the magnetic field strength of the gas giant. Radiation level will not decline below this fixed number. I'm mostly asking so we need to actually need to think twice between colonising radioactive hellholes like Io and its much calmer neighbour Callisto, which in Aurora are functionally identical. Of course really mineral rich bodies might still be worth colonising despite the efficiency hit.
Second, Covert/Submarine Patrol Order:
An Advanced order for reconnaissance craft with low signatures/stealth capability. This order will automatically assign headings and speeds, based on fuel status, its signature, its own sensor range, and known enemy sensor ranges, to scout a system for contacts. The idea here is that a ship will automatically scout a system, but avoid detection. As well, for "long duration missions" it will keep its speed low during patrol to conserve fuel, but increase speed as necessary to avoid detection or evade hostile ships. An additional thought, an area within the system could be designated for the patrol order, or boundaries set, to limit the search area.
With the C# release date literally around the corner, it's probably a bit late to ask for this, but could there be a global modifier to survey speed like with terraforming speed at game start? Sometimes it's worthwhile to play a game where exploration is deliberately slow, so much so that significant colonies and industry could already be in place before a system has been fully surveyed. You could have a giant hostile empire a literal four or five jumps away, right on your doorstep, and you wouldn't find out till you've already expanded right next to them.
I'm asking because I really love the thought of massive defensive wars and grinding campaigns through hostile territory, but most of my VB6 campaigns don't really go there because hostile empires are either too distant or they're encountered so early that the intervening space is mostly unoccupied, so wars devolve down to rushing the entire fleet to their capital before they can do the same to you, or turtling in for a long military build-up because there are no colonies that you need to worry about defending.
What with all of the global modifier suggestions and features going around, would it be possible to have a maintenance modifier that affects how much tonnage maintenance facilities support (and how many MSPs they produce)?
Can I suggest to limit possible weapons. For ships with diplomacy module just to ciws? I feel like this can be exploited if we can fit them with weapons for first strike.
Is that deduction before or after commercial engine modifier?
Can I suggest to limit possible weapons. For ships with diplomacy module just to ciws? I feel like this can be exploited if we can fit them with weapons for first strike.
Is it possible for ships to be grouped by race? For instance, in the screenshot below it would be useful for HOT, MAR, and JOV entries to be grouped together rather than going back and forth between them.
Yes, that would look better. Here is the updated version.
(http://www.pentarch.org/steve/Screenshots/Crusade/NewOrder.PNG)
Not to bother you further, Steve, but is there any chance we could specify certain colours for a known empire apart from the standard hostile/neutral/friendly? In this circumstance, contacts from Mars would be orange with orange text, contacts from Venus would be yellow with yellow text, etc. It'll make things a lot more readable, but it's fine as it is.
That might get confusing if there are a lot of races. I've tried to keep the number of colours relatively low on the map so it is easy to recognise different objects.
That might get confusing if there are a lot of races. I've tried to keep the number of colours relatively low on the map so it is easy to recognise different objects.
Fair enough. What about moving the empire designation to the front? So it'll be like this :
[MAR] 2x Huangwen 6449 tons Thermal 6 0 km/s
And not like this :
2x Huangwen 6449 tons Thermal 6 0 km/s [MAR]
That might get confusing if there are a lot of races. I've tried to keep the number of colours relatively low on the map so it is easy to recognise different objects.
Fair enough. What about moving the empire designation to the front? So it'll be like this :
[MAR] 2x Huangwen 6449 tons Thermal 6 0 km/s
And not like this :
2x Huangwen 6449 tons Thermal 6 0 km/s [MAR]
You might not have the same environmental requirements. Pretty difficult to run face-to-face consular services or round table negotiations if your air is toxic to them. Let's not make things too detailed if they don't have to be.
I'd be totally cool with a mild, scaling diplomatic penalty for different, exclusive environmental tolerances, with a much larger penalty for 'we breathe oxygen and you breathe methane', that distinction already being mechanically tracked in the game.
Sounds like an after-release sort of thing.
Why would that matter?
Why would that matter?
Because it's hard to have intricate trust-based conversations if you can't even stand in the same room and read each others' facial expressions.
Why would that matter?
Because it's hard to have intricate trust-based conversations if you can't even stand in the same room and read each others' facial expressions.
Just because we can stand in the same room, doesn't mean you can read my (species') facial experessions. Or even know which part is my face.
Gentlemen, gentlemen, please. I think we can all agree that the easiest solution here it to just kill all xeno scum. Laser fire needs no introduction.
Yes, that looks much better, both for single contacts and groupsJust my 2c on this: A small two or three pixel separation after each race (when there is more than one entry in a block) would be the final perfection of this display... :D
(http://www.pentarch.org/steve/Screenshots/Crusade/NewOrder02.PNG)
This is probably something for after the first release, but it was cool enough that I wanted to bring it up. You know how every race has a picture associated with them in the race details page? I was wondering if it would be possible to do the same thing for ships that we design, or ships that we see in the alien intel window. Basically, just have the option to attach a JPEG image to each ship class we design so that we can have a visual reference if we like.
This is probably something for after the first release, but it was cool enough that I wanted to bring it up. You know how every race has a picture associated with them in the race details page? I was wondering if it would be possible to do the same thing for ships that we design, or ships that we see in the alien intel window. Basically, just have the option to attach a JPEG image to each ship class we design so that we can have a visual reference if we like.
It's possible and I've considered it in the past. The problem is most people wouldn't have images for their ships so it would just be a blank area. It can be hard to find sci-fi ship pictures with a common theme, beyond Star Trek, Star Wars, etc.
This is probably something for after the first release, but it was cool enough that I wanted to bring it up. You know how every race has a picture associated with them in the race details page? I was wondering if it would be possible to do the same thing for ships that we design, or ships that we see in the alien intel window. Basically, just have the option to attach a JPEG image to each ship class we design so that we can have a visual reference if we like.
It's possible and I've considered it in the past. The problem is most people wouldn't have images for their ships so it would just be a blank area. It can be hard to find sci-fi ship pictures with a common theme, beyond Star Trek, Star Wars, etc.
....
Historical note: I'm 99% certain that SE4 is a "sibling" of Aurora, in that both of them got their start with StarFire. If you look at SE functionality, naming and timing (10 years after Starfire 2nd edition), it would be an amazing coincidence (hence only 99%) if SF wasn't a motivation for SE. On the other side, I'm not sure if you're aware that the underlying engine for Aurora started off as "StarFire Assistant", until Steve decided to go write his own game (Aurora).
-snipped-
John
Hi Steve!
I'm a fan, player and long-time lurker. . .
Of the aspects of the game "explore-expand-exploit-exterminate" I like more the first two and I would know if there are plans to develop the aspect of colony managing and keep colonies happy, flourishing and healthy.
I would like a slight overhaul of the technology system so we can't just build labs to produce research points. It should be tied with more factors such as general education and amount of resource spent on higher education.
I also think that even a relatively small empire should be able to match a bigger empire in terms of theoretical research, the difference should be in the amount of applied research two empires can produce. That would mean more restrictions on how much you can focus in any single technology. As it is no really realistic that you can spend labs and expect a linear return of that investment.
I also believe that scientist skill often play too much of a role in the amount of points you get.
I also would like that technologies that give automatic bonuses should scale in cost with the society they impact or if those modifiers can be added in a different way so there is an industrial or scientific cost to implement them throughout an empire. We don't get our ships automatically upgraded with new technology as soon as we discover them, the same thing should be true for the rest of society as well.
Bringing in education is a bit of a can of worms / slippery slope here because for it to make sense more and more of the entire civilian sector needs to be modeled, but otherwise I am all for something to make it less linear with empire size which ties in probably more with your next point.
The feasibility of Tall vs Wide empire strategies is a common debate in all 4x games I've engaged in discussions around, and wide is certainly being VERY favored in Aurora with everything from population growth mechanics to research rewarding spreading out rather than focusing "inward" on quality over quantity. I am also a firm believer that diminishing returns makes almost every simulation-like game better due to it's nature of being self-balancing much more so than a linear scaling is.
For sure. While it feels great to have that 65% * 4 = 3.6 times research speed when you do have it, it's also absolutely devastating to lose it, and it's a bit hard on your immersion to have a single leader over 10 million research workers able to influence the output to such a degree. Another immersion ruining factor is how an empire with billions of subjects can refocus 100% of it's research effort overnight into a totally different area, so some sort of "retooling" delay for labs switching specialization might be something worth considering. I would like the research bonuses to be gained and connected closer to the planet/lab in some way instead and have leaders able to maybe influence it in smaller and more unique/interesting ways in terms of tradeoffs. Maybe some scientists reduce credit cost instead of increase research point output, while those that increase output the greatest also increase credit costs more to mention one option, another is having them influence how many workers the labs need as a tradeoff too ( Classic efficiency vs output ).
It's a tricky one though to implement in a good way in order to not make it a huge choir and boring aspect of the game to have to upgrade 30 worlds manually each time you research a new tech. One of my favorite implementations of this was in ST:TNG:BotF (http://Star Trek: The Next Generation: Birth of the Federation) ( yes that is the proper abbreviation of the full title). This game let you assign an industrial project to upgrade labs, factories, farms or other building types that became progressively more expensive with tech before being able to enjoy the advantage and it always was such a hard choice what to prioritize and when, especially since the price of obsolete upgrades was significantly reduced so letting a system fall behind made upgrading to the old tech levels much cheaper.
Another abstracted way to achieve something similar might be to have later techs just reduce the worker requirements instead ( or at least mostly provide efficiency improvement this way ) which means that you constantly need to increase the number of factories/labs/finance centers and so on to gain benefit of the later tech levels. ( Building more buildings here is an abstraction/simplification of investments into upgrading to more advanced buildings ). This would probably make the math much harder though to judge how many buildings your population can support unless other UI improvements are made.
I'd be happy to see Research Facilities switch from an 'X points per month' basis to a 'random amount per month centered on X points' -- effectively a die roll for each production cycle. Overall research times should stay roughly the same, but this 2,000 point item might take a month longer than that 2,000 point item. I'd definitely prefer not to know that my empire will invent a new drive system on Tuesday, September 14th, 926 AL.
I would also prefer to see newly assigned labs & scientists 'ramp up' to their full bonus -- maybe 1-5% per week. I wouldn't want to penalize racial tech projects for the same team (so that Dr. P&P's labs aren't dropping back to zero for each new size of the same old engine), but I can see arguments both for and against keeping the bonus when going from Magnetic Confinement to Internal Confinement, for example.
- - - - -
A much more radical idea that tempts me is to drastically reduce the number of labs a scientist can oversee (say, to one-fifth of current, i.e. one per admin rating) and to allow multiple lab groups working on the same project to produce combined progress. (Currently, any research done on Mars is ignored on Earth, and vice versa, unless and until a project is completed.)
So instead of having one super-scientist who can oversee thirty-five labs in one place all working on the next anti-matter engines, you would instead have one scientist with seven labs on Earth, another with five labs on Mars, a third with four labs on Io, etc. I would want a small penalty (maybe only 10%) to the research produced by the additional scientists to enforce the paradigm that 'a single project under a single leader is more efficient' -- not for "realism" (I don't want to open that can of worms) but because I think there is value in that game mechanic. Probabaly also an additonal penalty for research done in a different system.
Could also steal a page from the original Master of Orion. You select an emphasis (though MoO did allow you to focus everything) but your research is benefiting all fields to some extent. And once tech progresses, you need to improve the infrastructure of your planets. Of course in MoO it was just a slider and the game even adjusted it automatically for you.
I don't mind if my empire's mines slowly ramp production from 16 to 20 upon researching a new level of tech -- even if the start of such increases 'flow' outward from the discovering colony at 'the speed of ship' -- as long as I don't have to micro-manage them.
However, I can't conceive of a situation where I wouldn't immediately pay to start/continue the process -- whether that cost be wealth, minerals, lost production, or whatever -- unless it there were enemies in my sytems and that cost meant the difference between launching new ships this production cycle or not.
In every other case it's a net increase in {whatever}, regardless of the cost you put on it. It's a decision on par with "Do I buy $5 worth of gas so I can take $50 worth of empties to the bottle depot, or do I leave them in my basement for another month?" It's never not going to be worth it.
- - - - -
It sounds like my only real decision is going to be "Do I pay extra to get increased capacity sooner?" To which the answer is going to be blatantly obvious. Empire making a profit? Do it (because we can afford it)! Empire running a deficit? Do it (because it increases taxes, and therefore imperial income)!
So if I spend 10% of a colony's wealth (per month, for a year) my installations upgrade in a year, and if I spend 100% (for six months) they upgrade in six months? I'm pretty sure I'm going to find some level of acceptable 'penalty' (maybe 25% for nine months) and "set it and forget it" on an empire-wide level.
So if I spend 10% of a colony's wealth (per month, for a year) my installations upgrade in a year, and if I spend 100% (for six months) they upgrade in six months? I'm pretty sure I'm going to find some level of acceptable 'penalty' (maybe 25% for nine months) and "set it and forget it" on an empire-wide level.
I still want to design my components and systems as much as possible. So any change to research should not affect that.
It may have already been suggested (its is a long thread) but could we have an option to display our choice of tiled background image in the system map and the galactic map (nebula variant too) that zooms in and out with the rest of the information? I have in mind a traveller rpg hex map for galactic map, hence the zooming being important.
Im still too much of a noob to suggest anything for game mechanics.
It may have already been suggested (its is a long thread) but could we have an option to display our choice of tiled background image in the system map and the galactic map (nebula variant too) that zooms in and out with the rest of the information? I have in mind a traveller rpg hex map for galactic map, hence the zooming being important.
Im still too much of a noob to suggest anything for game mechanics.
Reminded me of something I should mention. Galactic Map doesn't zoom at the moment. I never got around to adding it because it never became an issue. I'll address that after launch.
I use the zoom on the galactic map all the time. In the early game I zoom in close and then zoom outwards as I explore.
Possibly suggested before, but looking at screenshots I dont find the directional arrows layout particularly intuitive.
can I suggest a different layout like:
L. U. R
+. D. -
(http://hxxp: C:\Users\Stabliser\Desktop\buttons. png)
It would be nice if could manage some governmental infrastructure like hospital. I find that my officer have a lot of medical problem. We could have bonus by lowering the frequencies of this happening with more hospital. Having some recherche to implore life expectancy so hour officer retire at a older age could be nice too.
Moving the spinal mount discussion from the 'Update' thread, I think Spinals could be given a massive damage boost - and a massive power increase requirement. You should need to design an entire ship around a spinal, not add one because you can/want. A spinal weapon should WRECK the target, but require such a large amount of power your ship is only good for said weapon. Making them like this would add another level of complexity to the battles we love.
I would also love to see missile launchers larger then size 100. The idea of firing a missile bigger then some FAC cracks me up.
Would be kindof cool if we could build ship sized missiles.
To be honest that would just be silly and immersion breaking unless there also are mechanics added to armor them appropriately and have them partially fail from damage ( single point of dmg from a gauss can kill a FAC sized object no thanks )
Such proposals have been put forth before and the discussion got quite lively on occasion. Both in this thread and elsewhere. It's unlikely to happen anytime soon.
What you can do, now that commercial hangars are a reality in C#, is to make huge commercial carriers with slow commercial engines. No need for maintenance and they use barely any fuel as they carry your military ships to the front.
Such proposals have been put forth before and the discussion got quite lively on occasion. Both in this thread and elsewhere. It's unlikely to happen anytime soon.
What you can do, now that commercial hangars are a reality in C#, is to make huge commercial carriers with slow commercial engines. No need for maintenance and they use barely any fuel as they carry your military ships to the front.
Such proposals have been put forth before and the discussion got quite lively on occasion. Both in this thread and elsewhere. It's unlikely to happen anytime soon.
What you can do, now that commercial hangars are a reality in C#, is to make huge commercial carriers with slow commercial engines. No need for maintenance and they use barely any fuel as they carry your military ships to the front.
I don't think commercial hangar should be able to transport military vessels though.
You can transport them, but not maintain them. I'm pretty sure it freezes the morale loss, but doesn't stop the maintenance clock, thus you would need maintenance modules if you wanted to store military ships in non-military hangars.
Don't know if this was suggested, since 145 pages is a lot to go through, and while I like to imagine that Steve eagerly watches all the stuff I throw onto Youtube, I know he's probably too busy to, so I'd like to suggest an eventual expansion on diplomacy I like to call: Local Wars vs. Total Wars.
Scenario for your consideration: You have an alliance with a neighboring empire. You have three JPs leading to their systems where you are neighbors. Neither empire claims the other's systems, so there is no border conflict, just a border. You still lay mines and defensive platforms/patrol fleets at the JPs because good practices (as does the NPR), but you never expect to use them because hey, it's a comfortable peace - they're just there to keep the other guy honest.
Now, in some distant (but not TOO distant) system, you run into some really rich deposits, but your neighbor has some ships who have just shown up there as well. You each have a few light combat vessels there, but neither side is willing to concede this resource deposit (both empires claim system, neither concedes).
Now, in the current system, there are three outcomes:
1) Diplo teams manage to keep the diplo score above -100 long enough for someone to drop a colony in the system, and the AI bails out.
2) The refusals from either side to vacate, or the empires fail to yield even after colonies are set up, and leads to a reduction in diplo score until one empire declares war at -100.
3) You think you have an advantage and decide to "give them a nudge" in that system by firing a shot at their (shielded) ships to kindly ask them to "no really, go away".
the first instance is already fine, but in either of the latter instances, diplo score ends up at -100, which leads to war.
What happens then? A battle breaks out in the new system, someone wins, well done. This is fine, and is meant to happen.
But what happens at the rest of the border? Mines arm, and go after merchant traffic. Your own ships now consider the hefty trade ships in your systems valid targets, as do their ships to your merchants in their systems. Mass murder all-round everywhere, diplo score plummets to -bazillion, you're now in a total war with your once ally. Even if you don't attack them, you still have to send your diplo ships into their systems to try and bring your score up, and if they get shot at on transit, or trip up on mines, that just makes things worse. And how long is it going to take to claw back ALL the diplo points to get above -100? Especially if they send through attacks from their systems? Do we agree that this is a problem?
To give a real-world analogue, it would be like a new island full of oil appears in the middle of the Atlantic, the US and Russia both send a pair of destroyers over, one of them fires a shot that does minimal/no damage, and both countries decide "welp, time to launch all the nukes, lol!". It just doesn't make any sense!
So, I have two proposals:
1) The quick-fix: Make ship damage ONLY decrease diplo score while it is above -100. This way, your diplomats can try and work towards peace, even if you're still fighting off raids from the enemy. This lets you work towards peace as long as nobody invades anyone's colonies. It would also largely remove the necessity of a "warscore", as the value of the rep below that war threshold, plus ongoing combat and invasions, plus diplo team efforts and skills can somewhat account for that. But while easy to implement, it's so un-satisfying, and will still spike mass-slaughter among merchant shipping while the score is still below that threshold of war.
2) The better solution: Expand into a two-tier diplo system.
The way it would work is like this. Each empire has two ratings - one "global" relations rating, and one "local" relations rating within each system where there is a known presence. When combat and damage happens, that local system's diplo rep plummets and you can go about your shooting and killing in there. While there is no combat, the rep climbs back towards zero (where it stops contributing to global rep) or, if colonies are present, towards a baseline set by the global rep level. Diplo teams that can work on that empire can target that system to raise the local rep in that system (rather than just raising the "global" rep overall) and can do this from within any other system (so they don't have to work in a warzone).
The "Global" diplo rep is determined by the average diplo ratings of every system's local score.
Local rep would initially start at the global rep level (upon discovery of the presence of the other empire, so as to not alter the global rep), and tends towards whatever the current global rep is as long as presence continues to be detected. If no presence is detected after X months, or no colonies are identified in that system, then the system is eventually removed from influencing global rep.
So in the above scenario, you would have 6 systems with +1000 rep (one each either side of the JP border), and one system with -1000 rep where your fleets are having the fight over the new territory. Fleets within that system would be at war, and will fire on one another as they desire, but the "Global" diplo rating would be at like +700 points ((6000 - 1000)/7). This means that, as long as you don't engage any ships anywhere else, trade will continue to flow, and the border will remain cordial (with perhaps some minor tension).
However, if you let that conflict fester, then the local rep at each of those other systems will start trending towards the new baseline of +700 instead of +1000, which will start dragging the global score down [((6x700-1000)7)=450], which will drag the local scores down, leading into a loop that eventually brings the global score to -100, at which point total war breaks out. This way, you can't have a perpetual border conflict without any diplomatic penalties, but a single border conflict doesn't instantly get you there, and you have time for diplo teams to bring the local score for that system up if you avoid confict in that area.
The AI would also be aware of this, and would re-evaluate whether it wants to give up on that system and let diplo teams pach up relations, or whether that system is valuable enough to eventually escalate into total war.
Having a hidden third value "Desired Diplo Rep" would accomplish this by letting NPRs decide at what point are they willing to let relations fall to. For example, a low-militancy empire that is gaining a lot of wealth from trade, espeically to the point where it would go into debt without it, might not be willing to fall below the threshold where that trade is cut off, and would pull back from contested systems if the rep falls low enough to threaten a trade treaty. A highly militaristic and xenophobic empire that doesn't benefit economically from your own very much, with a much stronger military, would be much more willing to let global rep fall into total war.
I think that something like this system would give a lot more flexibility and depth to diplomacy and allow things like border conflicts to happen without plunging both empires into total war the second anyone fires a shot at anyone else. It doesn't make sense that two long-time allies would instantly go into total war over some minor damage (and not even destruction) to a corvette in some distant system far from the core worlds.
I also understand that this would mean a lot of work on diplomacy and would not expect to see this in the current release, and I fully expect Steve to be burnt out on diplomacy and be much more keen to work on literally anything else, but perhaps later on down the road something like this would be really awesome to see.
Yadda Yadda Yadda, look two up
Hi Ser, first of all: BIG FAN!
If diplomatic relations are above the hostile level (-100), then even a single point of damage through combat will reduce relations to that point.
However a period of mutual non-interaction following a small clash will probably return the diplomatic status to neutral.
1) even if you drop a colony it will not be enough for the AI to bails out and it will take for you several years before reaching a level where the AI is leaving the place and good luck with your commercial and or logistic effort in getting that colony going with all the AI sparrows around.
2) this is the most likely scenario you are going to face and honestly, I believe is quite accurate. You are pretty much trying to form Israel in Palestine. We all know how this ends.
3) it will not work as per the first mechanic and also for the one discussed at the beginning.
What may happen quite often is that you see a lone alien survey ship and it won't leave. You damage it (perhaps a single missile) and it runs away. Unless the NPR has forces waiting very close by, relations will move above the hostile threshold within a few days or weeks.This is assuming the two races haven't been allied a long time with trade intermingling everywhere. You hit a survey ship once and only do shield damage, and now all the mines and JP pickets on both sides obliterate every merchant ship, and you go from -101 to -10,000.
If you actually destroy the ship, that would take a lot longer to resolve.
What may happen quite often is that you see a lone alien survey ship and it won't leave. You damage it (perhaps a single missile) and it runs away. Unless the NPR has forces waiting very close by, relations will move above the hostile threshold within a few days or weeks.This is assuming the two races haven't been allied a long time with trade intermingling everywhere. You hit a survey ship once and only do shield damage, and now all the mines and JP pickets on both sides obliterate every merchant ship, and you go from -101 to -10,000.
If you actually destroy the ship, that would take a lot longer to resolve.
I think a border skirmish spiraling into total war should be possible, the Seven Years War happened like that after all, but not all border skirmishes should do so. The US didn't obliterate Israel in retribution for the attack on the USS Liberty.
Ideally, there'd also be some kind of way for the reverse to happen, in which a total war winds down to an uneasy peace. The player may be able to do that if they're winning, but it seems like the AI will never stop before total annihilation if they're winning.
Yes, I've said I will add a variety of additional diplomacy options post-launch, including peace treaties of some sort. I'm just pointing out what is possible at launch.
I guess what you are asking though is that in some situations (depending on NPR characteristics and current relations), there would be a protest rather than immediate combat
Thanks! It means a lot! :D
Now, it's true that I may be misreading it, so would love a clarification from Steve, but the way I read this bit:If diplomatic relations are above the hostile level (-100), then even a single point of damage through combat will reduce relations to that point.
This seems to me that ANY point of damage is enough to bring relations from +whatever to -100 instantly. This means that a fully maxed out alliance would instantly turn into total war if a single shot is exchanged between the two of you.
Since -100 is Total War, this means instant hostilities, which means mines trigger on that empire. Mines means uncontrolled damage to any civilian shipping in the area. Which means more negative diplo rep. Now you have to start digging, but the AI is at war. It wants to start attacking you. So you now have to fight off attacks, dealing more damage, causing further diplo losses.
Yes, I've said I will add a variety of additional diplomacy options post-launch, including peace treaties of some sort. I'm just pointing out what is possible at launch.
I guess what you are asking though is that in some situations (depending on NPR characteristics and current relations), there would be a protest rather than immediate combat
I think what people are asking for is a more gradual degradation of relations to be the norm, rather than it being possible to go from close allies to war overnight.
Basically if a point of contention appears between two allied empires relations could degrade over some months or even some years with civilian trade getting cut off at a fairly early point and possibility of border skirmishes only towards the end.
A game that captures this excellent is Rule the Waves where you never know exactly what will bring you over the brink of war but you can see it coming miles away and make preparations. Being able to react to the development isn't just good for a feeling of plausibility, it also opens up strategic choices like the player being able to either move forces into place, dig in and prepare for operations in enemy territory... or redouble diplomatic efforts and compromise to try and avoid conflict.
Yes, I've said I will add a variety of additional diplomacy options post-launch, including peace treaties of some sort. I'm just pointing out what is possible at launch.
I guess what you are asking though is that in some situations (depending on NPR characteristics and current relations), there would be a protest rather than immediate combat
I think what people are asking for is a more gradual degradation of relations to be the norm, rather than it being possible to go from close allies to war overnight.
Basically if a point of contention appears between two allied empires relations could degrade over some months or even some years with civilian trade getting cut off at a fairly early point and possibility of border skirmishes only towards the end.
A game that captures this excellent is Rule the Waves where you never know exactly what will bring you over the brink of war but you can see it coming miles away and make preparations. Being able to react to the development isn't just good for a feeling of plausibility, it also opens up strategic choices like the player being able to either move forces into place, dig in and prepare for operations in enemy territory... or redouble diplomatic efforts and compromise to try and avoid conflict.
The degradation happens due to tensions over territory. I am playing through that exact situation now in the test game. The powers are threatening each over Alpha Centauri and the situation is escalating. It is obvious that war is coming if someone doesn't back down.
However, tensions increasing is different than destroying a ship. Even on Earth, if a one power started sinking ships of a second, friendly power, relationships wouldn't gradually decrease. In the game, an allied NPR isn't going to suddenly open fire on you without warning. Conversely, if you start destroying ships from friendly NPRs then it is reasonable that they retaliate.
Yes, I've said I will add a variety of additional diplomacy options post-launch, including peace treaties of some sort. I'm just pointing out what is possible at launch.
I guess what you are asking though is that in some situations (depending on NPR characteristics and current relations), there would be a protest rather than immediate combat
I think what people are asking for is a more gradual degradation of relations to be the norm, rather than it being possible to go from close allies to war overnight.
Basically if a point of contention appears between two allied empires relations could degrade over some months or even some years with civilian trade getting cut off at a fairly early point and possibility of border skirmishes only towards the end.
A game that captures this excellent is Rule the Waves where you never know exactly what will bring you over the brink of war but you can see it coming miles away and make preparations. Being able to react to the development isn't just good for a feeling of plausibility, it also opens up strategic choices like the player being able to either move forces into place, dig in and prepare for operations in enemy territory... or redouble diplomatic efforts and compromise to try and avoid conflict.
The degradation happens due to tensions over territory. I am playing through that exact situation now in the test game. The powers are threatening each over Alpha Centauri and the situation is escalating. It is obvious that war is coming if someone doesn't back down.
However, tensions increasing is different than destroying a ship. Even on Earth, if a one power started sinking ships of a second, friendly power, relationships wouldn't gradually decrease. In the game, an allied NPR isn't going to suddenly open fire on you without warning. Conversely, if you start destroying ships from friendly NPRs then it is reasonable that they retaliate.
Yes, but if for some reason the UK torpedoed a US frigate in the English Channel then it could certainly lead to the immediate end of friendship and maybe even further battle/war, but what *wouldn't* happen is that the US navy immediately opens fire on and sinks every british-flagged ship on the eastern seaboard, immediately turning a single outrageous incident into a total war of annihilation.
Maybe there could be a "system-level conflict" where retaliation is immediate for attacks on a ship but conflict outside that immediate battle doesn't automatically start right away - some kind of official declaration of war from them (if sufficiently outraged and you insufficiently apologetic) or you (if you're genuinely turning on them and launching a surprise attack)? Its a very complex subject in either case
I look forward to seeing the escalation. Are you playing the obfuscated release version?
Yes, but if for some reason the UK torpedoed a US frigate in the English Channel then it could certainly lead to the immediate end of friendship and maybe even further battle/war, but what *wouldn't* happen is that the US navy immediately opens fire on and sinks every british-flagged ship on the eastern seaboard, immediately turning a single outrageous incident into a total war of annihilation.
Maybe there could be a "system-level conflict" where retaliation is immediate for attacks on a ship but conflict outside that immediate battle doesn't automatically start right away - some kind of official declaration of war from them (if sufficiently outraged and you insufficiently apologetic) or you (if you're genuinely turning on them and launching a surprise attack)? Its a very complex subject in either case
I agree with that in principle. The problem is that in the scenario above, you have two countries with an equal ability to understand this could be an accident or it could be negotiated away. Assume the US is an NPR. Should the British be able to get away with sinking a US ship occasionally without long-term relationship problems? Or should the British be able to sink a US ship and know the US will only retaliate in the same area and can therefore make preparations accordingly - like luring the US fleet into an ambush? Also in this scenario, the US has to follow rules and isn't allowed to do the same to the British without lots of warnings first.
When you are dealing with an AI, you need to make rules that do not allow the player to manipulate those rules in unrealistic ways. Even with the rules on launch, you have the option to lightly damage an NPR ship and, without immediate further contact, relations will return to non-hostile quickly. If you are lined up face to face with an NPR ready for war, then don't shoot at its ships.
Longer term, there may be other options. If the damage isn't too bad and relations are good, then maybe a warning and a relationship hit for the first incident only. I need to see the diplomacy in action a lot more though before I start adding more options or detail. It is already far more complex than VB6.
Doesn't Aurora kind of presume that faster-than-light communication doesn't exist? It occurs to me that if long-range communications is difficult or impossible, then it might be accepted by fleet command that a certain number of ships sent out are just going to disappear. Obviously things change if they can radio home immediately to let them know they're under attack.The AI currently doesn't, and I can imagine that making it do so would be pretty difficult. As it is, any non-FTL communication is purely a roleplaying choice by the player. One that I and many people personally enjoy and make quite often, since it allows for more interesting decision-making, but a roleplaying choice nevertheless.
There actually is a historical precedent. . . See the USS Liberty Incident https://en. wikipedia. org/wiki/USS_Liberty_incidentWe also have historical examples of it going the other way:
How about instead of moving directly to -100 for the first point of damage, there is instead a high multiple of the normal relationship hit for damage if not already hostile at the start of the increment?
I would also increase the 'Danger Rating' of the system where the incident occurred, so that non-military NPR shipping would avoid the area.
That way, a single ship being damaged is going to affect relations and cause an NPR pull-back in economic terms but probably not cause a war if relations are high enough. Conversely, if you destroy several ships in a surprise attack while at peace, you end up with a huge negative reaction (a Pearl Harbour reaction). Those mechanics avoid a lot of complexity but provides the basic idea proposed above. To make things fair, I would also allow an NPR to fire on player ships without being hostile if the player continues to ignore requests to leave a system.
How about instead of moving directly to -100 for the first point of damage, there is instead a high multiple of the normal relationship hit for damage if not already hostile at the start of the increment?Could you include the ability for the NPR to do a Pearl Harbour style attack as well? It just doesn't seem right if that mechanic is only an option for players.
I would also increase the 'Danger Rating' of the system where the incident occurred, so that non-military NPR shipping would avoid the area.
That way, a single ship being damaged is going to affect relations and cause an NPR pull-back in economic terms but probably not cause a war if relations are high enough. Conversely, if you destroy several ships in a surprise attack while at peace, you end up with a huge negative reaction (a Pearl Harbour reaction). Those mechanics avoid a lot of complexity but provides the basic idea proposed above. To make things fair, I would also allow an NPR to fire on player ships without being hostile if the player continues to ignore requests to leave a system.
How about instead of moving directly to -100 for the first point of damage, there is instead a high multiple of the normal relationship hit for damage if not already hostile at the start of the increment?Could you include the ability for the NPR to do a Pearl Harbour style attack as well? It just doesn't seem right if that mechanic is only an option for players.
I would also increase the 'Danger Rating' of the system where the incident occurred, so that non-military NPR shipping would avoid the area.
That way, a single ship being damaged is going to affect relations and cause an NPR pull-back in economic terms but probably not cause a war if relations are high enough. Conversely, if you destroy several ships in a surprise attack while at peace, you end up with a huge negative reaction (a Pearl Harbour reaction). Those mechanics avoid a lot of complexity but provides the basic idea proposed above. To make things fair, I would also allow an NPR to fire on player ships without being hostile if the player continues to ignore requests to leave a system.
Could you include the ability for the NPR to do a Pearl Harbour style attack as well? It just doesn't seem right if that mechanic is only an option for players.
Possibly mentioned before, but how about enabling scripts to automate some button mashing. For instance, if I wanted to create the exact same Mars NPR each time, but with colonies and ships already generated. It wouldn't introduce true modability, and is more of a QOL thing. At minimum, it would let you do the same things you could do without a script.
Or perhaps better would be a random over-reaction to a negative event.
//Dependencies
using System.Drawing;
Bitmap ribbon; //base ribbon sans device
int num_awards; //number of times medal has been awarded
Bitmap device; //particular device for number of awards
//iterate over each medal awarded, loading the ribbon bitmap and calculating the number of awards
{
//Load device bitmap. In this example, the devices are loaded into a resource file
if (num_awards = 2) device = Properties.Resources.BronzeOakLeaf
if (num_awards = 3) device = Properties.Resources.SilverOakLeaf
if (num_awards >= 4) device = Properties.Resources.GoldOakLeaf
//etc etc.....
//this is required for alpha channel transparency to work
device.MakeTransparent();
//destination for drawing the device on top of the ribbon is a rectangle
//centered in the ribbon, with width and height equal to the device
Rectangle destRectangle = new Rectangle (
(ribbon.Width - device.Width) / 2,
(ribbon.Height - device.Height) / 2,
device.Width,
device.Height
);
//source for drawing is just the entire device
Rectangle sourceRectangle = new Rectangle (0, 0, device.Width, device.Height);
//Compose device on top of ribbon bitmap
using (Graphics g = Graphics.FromImage(Ribbon))
{
g.DrawImage(device, destRectangle, sourceRectangle, GraphicsUnit.Pixel);
}
}
Hi Steve, it'd be really cool if Aurora could display a device on a ribbon for multiple awards of a medal.
This is a problem I just had to solve for my ribbon maker program. It took me quite a while to figure out how to draw a device over a ribbon correctly. I'm having a slow day at work so I wrote up this code sample just in case this is a feature you were interested in implementing later:Code: [Select]//Dependencies
using System.Drawing;
Bitmap ribbon; //base ribbon sans device
int num_awards; //number of times medal has been awarded
Bitmap device; //particular device for number of awards
//iterate over each medal awarded, loading the ribbon bitmap and calculating the number of awards
{
//Load device bitmap. In this example, the devices are loaded into a resource file
if (num_awards = 2) device = Properties.Resources.BronzeOakLeaf
if (num_awards = 3) device = Properties.Resources.SilverOakLeaf
if (num_awards >= 4) device = Properties.Resources.GoldOakLeaf
//etc etc.....
//this is required for alpha channel transparency to work
device.MakeTransparent();
//destination for drawing the device on top of the ribbon is a rectangle
//centered in the ribbon, with width and height equal to the device
Rectangle destRectangle = new Rectangle (
(ribbon.Width - device.Width) / 2,
(ribbon.Height - device.Height) / 2,
device.Width,
device.Height
);
//source for drawing is just the entire device
Rectangle sourceRectangle = new Rectangle (0, 0, device.Width, device.Height);
//Compose device on top of ribbon bitmap
using (Graphics g = Graphics.FromImage(Ribbon))
{
g.DrawImage(device, destRectangle, sourceRectangle, GraphicsUnit.Pixel);
}
}
It will be cool if the genetics modification center can be use to create better soldier (like space marine).
Would it be possible to get plasma cannonades as turretable weapons?I dont know about that, but what i would really like to see is proper torpedo mechanics. Could even be an energy weapon variant, like the photon torpedoes of Star Trek out something like this, in order to reuse the existing codes and mechanics for a minimal amount of code changes.
I would also suggest particle beams but I'm unsure how that would effect balance.
I dont know about that, but what i would really like to see is proper torpedo mechanics. Could even be an energy weapon variant, like the photon torpedoes of Star Trek out something like this, in order to reuse the existing codes and mechanics for a minimal amount of code changes.
IIRC you once shot down the idea of arranging systems like in the picture below. . .
(https://pbs.twimg.com/media/DTlyakAXUAAOeWX?format=jpg&name=medium)
If you set "Local System Generation Chance" to 100%, and "Local System Generation Spread" to 2 or 3, you'll get a map much like that one. . . Oh, and of course set "Real Stars" to OFF.
Well, you personally will still have to drag all those systems around one-by-one on the galactic map to duplicate the layout, but you'll have the interconnectedness.
Right but I was thinking real stars, I just so rarely play fake stars.
Hey steve, so after the turn time video came out, we were discussing on the discord and we started talking about how interrupts in C# will be the probably the main thing to "slow" games down,
I know you have worked on interrupts to make them better but maybe adding post release a way to turn off certain non "essential" interrupts such as civillians or haulers, effectively "speeding up"
the game, just a thought.
Thanks, that seems much better and its nice to actually see what will actually activate the interrupts, good work! Still could be useful to add the ability to turn certain ones off such as "inactive lab"
which can get quite annoying if very specific scenarios such as not enough workers for new labs etc, but overall it looks fine to me
For some reason [img] tags aren't working for me, nether are links ??? so I'll just have to paste this URL below:
hxxp: www. pentarch. org/steve/Screenshots/Crusade/1889_017. PNG
When viewing displays such as this one, where there are many different objects on and around a body with many different owners, I think it would be much easier to read at a glance if the list was sorted 1st by surface/orbital (kind of like how it is now), 2nd by ownership, then 3rd by tonnage. Visually pulling apart the HOT and MARS ships in that long list is a bit of a headache.
Hey steve, so after the turn time video came out, we were discussing on the discord and we started talking about how interrupts in C# will be the probably the main thing to "slow" games down,
I know you have worked on interrupts to make them better but maybe adding post release a way to turn off certain non "essential" interrupts such as civillians or haulers, effectively "speeding up"
the game, just a thought.
Here is the current interrupt list for players. There are no civilian interrupts. In C#, NPR interrupts do not stop automated turns; they only shorten the current increment.
Alien Communication
Breathable Atmosphere
Combat Summary
Damage Report
Fleet Message
Gas Removed
Ground Combat Update
Hostile Contact Update
Ice Sheet Melted
Illegal Order
Inactive Lab
Invalid Unload System
Jump Point Detected
Mineral Shortage
New Alien Race
New Hostile Contact
New System Discovered
No Missile Assigned
Orders Completed
Out of Ammo
Overhaul Complete
Pickup Failed
Planet Looted
Production
Ramming Attempt
Reparations
Research Completed
Ruins Exploited
Ruins Located
Ship Construction
Ship Destroyed
Ship Refit
Ship Repair
Ship Scrapped
Ship Surrender
Shipyard Modified
Successful Espionage
System Surveyed
Targeting Problem
Tech Downloaded
Terraforming Report
Transit Failure
Unit Trained
Are NPRs now capable of starting conventional and then transferring to be TN?
Not at release. I will tackle that at some point though.
Would it be possible to make this list customizable in future releases?
. . .What if though instead of randomly appearing from wormholes every once in awhile they were a large, powerful, established NPR-style race. Like when you came across one of their systems the game would generate a dozen or more systems that they own. Or when the game starts, guess it doesn't matter. But yeah the idea is just that they're an established race with actual territory. . .
Hey steve, would it be possible for the ui images be unpacked from the exe so we can change them out?
Powered Infantry Armour is available automatically at Conventional Start.
Personally, I think that it should be gated behind Trans-Newtonian Tech or at least it should need to be researched.
Please add a confirmation Dialog when closing the game, VB6 saved every turn so i just closed the game out of habbit
Quote from: jatzi link=topic=9841. msg120820#msg120820 date=1586669025. . . What if though instead of randomly appearing from wormholes every once in awhile they were a large, powerful, established NPR-style race. Like when you came across one of their systems the game would generate a dozen or more systems that they own. Or when the game starts, guess it doesn't matter. But yeah the idea is just that they're an established race with actual territory. . .
Already in.
If -- upon exploring a jump point -- Aurora generates a "big" enough NPR to have multiple systems, it 'breaks' that jump point link and generates a new, stop-gap system and puts the original NPR-bearing system on the other side of one of the new system's jump points. Aurora will do this two or three times if necessary.
Well, depending on your empire's tech level, Precursors and Swarm and even Invaders can be way less advanced or strong than the player. They generally don't scale with you.
But -- unless such a race included some weird new tech or other systems -- what you are describing IS an NPR. Or bog standard precursors, depending on whether or not they have populations.
Any NPR or spoiler that gets activated, stays activated, and expands or explores or exploits or exterminates according to its programmed behaviour. Start a game with an NPR and have that NPR stumble into the Swarm the first month, and by the time your empire finds the Swarm it will have harvested fifty systems.