I could include a 'jump size' rating in the ship design display, which would be the size of the ship for jump purposes (HS rounded up to nearest 50 tons or jump drive capacity, whichever is smaller). That would actually make it easier for new players as we would avoid the small ship, large drive issue.
I still think that group jumps should look exclusively at the rating of the jump drive. It was mildly enraging to realize that my 20kton jump ship for my 40kton warships had to have a bunch of fuel or something strapped on in order for it to do its job.
Jump Force v1 class Jump Ship 23,600 tons 676 Crew 6342.8 BP TCS 472 TH 1050 EM 0
2224 km/s JR 5-50 Armour 1-73 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 49 PPV 0
Maint Life 0.72 Years MSP 4192 AFR 234% IFR 3.3% 1YR 5854 5YR 87806 Max Repair 4812 MSP
Intended Deployment Time: 10 months Spare Berths 1
ROR J60000(5-50) Military Jump Drive Max Ship Size 60000 tons Distance 50k km Squadron Size 5
ROR 150 EP Ion Drive (10HS 1.25Fuel) (7) Power 150 Fuel Use 78.61% Signature 150 Exp 12%
Fuel Capacity 5,000,000 Litres Range 48.5 billion km (252 days at full power)
This design is classed as a Military Vessel for maintenance purposes
Possibly an easier way to explain (while still being codeable) would be that jump drives can propel things up to 1.25x the host vessel's size (up to a maximum of the jump drive's rating). That has two benefits, firstly, you can say that the jump 'bubble' created by the ship can encompass pointy out bits and compensate for hull size mismatches (avoiding the 9999.9999 ton vessel being unable to jump a 10k ton vessel or the handwavium required above to say why a 9980 ton vessel can move a 10k vessel but your 9940 ton example can't).
Secondly, you can make ever so slightly smaller ships and still make use of jump drives you've already designed (eg anything between than 8k-10k tons could make use of a 10k jump drive). This increases flexibility in ship design.
3) Every time I see "AG" I think anti-gravity.Mayby LG (Low gravity) would be less misleading? "Low gravity infrastructure" looks pretty certain and clear for me.
John
AG makes me think Agriculture personally
BTW For those familiar with C#, I have found one of the major advantages over VB6 (beyond the obvious advantages) is using LINQ and Lambda expressions to retrieve data from collections - very useful and powerful.
Wow, thanks a lot bro. That will really make the game better, at least for me.
Might I also suggest further modelling the central government? So far we have sector governors and planetary governors (and hopefully now solar governors) but it would also be cool to have an actual leader with a cabinet/advisers you can assign.
I'd like to see in addition, more ship officer positions. Science officer, Chief Engineer, First Officer, etc.I'd imagine with a few of these, you'd see new bonuses as well, such as Damage Control Bonus, MSP usage reduction, random chance that ship components are treated as 1 or so HTK tougher, crew casualty chance reduction, boarding combat bonuses (against boarders), etc.
I'd imagine with a few of these, you'd see new bonuses as well, such as Damage Control Bonus, MSP usage reduction, random chance that ship components are treated as 1 or so HTK tougher, crew casualty chance reduction, boarding combat bonuses (against boarders), etc.
Not sure what the science officer would do. Increase the science yield from salvage operations perhaps?
Just thought of another bonus the Chief Engineer could give: Life Support Tenacity Bonus. As long as the commander remains alive, the carrying capacity for life support until dangerous failures occur is higher based on their bonus. Makeshift life support systems will meanwhile last longer based on their bonus if it comes to that.
You could also set a chain of command. Captain, XO, Chief Engineer, Science Officer, CMO, etc. Then as battle loses mount, your command structure changes.Perhaps. Though, while I may not be able to talk much on the matter, due to lack of combat experience, I think there is a possibility that over-granularity of such may not be particularly important, due to the sheer in-battle insignificance of some of the buffs some commanders would give due to lack of a reasonably high percentage or just lack of applicability, that and a ship taking enough damage to lose officers may often enough already be in such a bad situation that said buffs would not quite make a difference. Adding in different bonuses would be nifty and might make extended granularity more feasible, though I think we should see the bonuses begin to exist first so we can determine if it's worth it.
I have a minor question, if you're reworking the naming lists. A handful of name lists tend to have trailing spaces (the Astronomer ship name list, for instance). They aren't exactly a tremendous issue, but they can sometimes be mildly irritating. Will these be given a quick trim while you copy them over, or will you be importing them as-is for now?
I have a minor question, if you're reworking the naming lists. A handful of name lists tend to have trailing spaces (the Astronomer ship name list, for instance). They aren't exactly a tremendous issue, but they can sometimes be mildly irritating. Will these be given a quick trim while you copy them over, or will you be importing them as-is for now?The worst is probably the Victory Ships, which I didn't properly sanitize before I posted it. That really needs to be cleaned up, and there's also some issue with some of the US Auxiliary ship lists. I forget exactly which ones.
I'd imagine with a few of these, you'd see new bonuses as well, such as Damage Control Bonus, MSP usage reduction, random chance that ship components are treated as 1 or so HTK tougher, crew casualty chance reduction, boarding combat bonuses (against boarders), etc.
Not sure what the science officer would do. Increase the science yield from salvage operations perhaps?
Just thought of another bonus the Chief Engineer could give: Life Support Tenacity Bonus. As long as the commander remains alive, the carrying capacity for life support until dangerous failures occur is higher based on their bonus. Makeshift life support systems will meanwhile last longer based on their bonus if it comes to that.
I've been considering multiple officers per ship for a while. I just never got around to it. The rewrite is the best opportunity though so I will very likely add this when I get to the Commanders window. I also like the different bridges suggestion.
I don't think ground forces staff would be very useful since ground units only really do one (two if you're not genocidal) thing. Maybe if the army had more units that did more things, e.g mining/survey brigades, it'd be a little more worthwhile.
I realize this risks turning this into a suggestion thread, but maybe tie it in with a variety of bridge modules?On the point of "no commanders for fighters", you know there is a Fighter Combat Bonus on commanders for a reason, right?
No bridge (Fighter, FAC) gets you a ship either with a single commander or none at all, depending on how in depth Steve wants to be. I'd actually suggest none, since having to assign commanders to hundreds of fighter craft always made me wonder if anyone played without automatic assignments on.
Then there could be the normal 1HS bridge, allowing for a commander, a 5 HS science/tactical/engineering/command bridge allowing for a science/tac/engineering officer or CAG, things like that, and maybe boost the flag bridge up to 25HS and have it allow for all of those and a task force command. Would add some more personality to ships as well.
On the point of "no commanders for fighters", you know there is a Fighter Combat Bonus on commanders for a reason, right?
Both that and fleet initiative rating is -very- important for fighter combat, I figure, as high-speed interception can make the range- setting for each engagement more significant.
Also, given how promotions currently work (you need 3-4 commanders in an immediately subordinate position for every single commander promoted up into the next), you'll need a lot of ships to compliment them anyway.
Also provides the opportunity to get your "ace pilot" with the impressively high Fighter Combat Bonus and fleet initiative rating to make fighter battles a bit more exciting, as they currently are.
Hi,
While talking about officers, what about a secondary bridge (or a tertiary one) ?
If the main bridge takes a hit, killing or wounding the captain, the secondary one with the XO would command the ship.
Of course there will be some delay in such change, depending on crew quality, and some maluses.
This way you gain the ability to affect an officer by bridge to a ship.
My 2 cts.
Perhaps with C# it might be time for steve to add more comprehensive tooltops, an ingame Aurorapedia perhaps?
There's a setting to ask civilian shipping companies do exactly this.But thats not reliable enough, I want to be able to do it with my own ships.
1. Create a new window which will show total amount of minerals in the entire empire, the total production of the empire and, possibly, the total resource consumption of the empire the previous year. Recently I've been playing my largest campaigns yet, with numerous production sites and even more numerous mining sites and managing the resources is becoming a real pain. In fact I was forced to send all my production to a central location, from which I teleport resources where needed, just to have a grasp of what I may need or not in the near future, for the purposes of planning expansion of my mining sector.
2. In the fleet orders tab allow us to simply select a destination for a ship rather than having us make the route ourselves. Aurora is already capable of calculating the routes but in my current campaigns I routinely have to set destinations ten-twenty jumps out. Not only is that a lot of clicks it requires me to frequently switch between orders tab and galaxy map tab to make sure I go the right route. To make matters worse my empire continues to expand and in the future I may be forced to create routes thirty - forty jumps long.
3. Simplify assignment of weapons to fire controls. I build a lot of ships with numerous box launchers and assigning them is a pain, even with the ability to copy assignments to other warships. What I'd like to see is an option to attach X loaded missile tubes to Y type of fire control. Since I usually have several missile controls of a single type, this would allow me to very easily assign however many tubes I want to them with two, three clicks instead of dozens of clicks as I have to do now.
4. At the end of the event summary please gives as a simple list of which ships were damaged/destroyed during the increment. I routinely have dozens of ships in battle so checking which one have been damaged is a pain, even when I know which ones have been targeted.
That's all I can think of right of the bat, although those are only changes to the UI rather than the game itself. Other than that thank you for the hard work, the Aurora C# looks fantastic.
You can already this do in VB6 Aurora. Use the 'Show All Pop' options. Select a population and double-click the order in the normal way. Aurora will calculate the route, including any short-cuts via Lagrange points, for any distance.
You can already assign groups of weapons in VB6 Aurora. Go into the F8 window, select all the missile tubes at once and assign with a single click. Even so, I will be looking at improving this for C#.
Thank you. I did not know that and having those options will save me tens of thousands of clicks. I'd like to add one small thing however - the show all populations helps a lot with moving ships between colonies, but it does not help much with survey vessels, as those usually go to uninhabited systems. What I'd like to see is an option to chose a destination system from all the systems your empire knows of and then optionally to select a destination within the system. But that's just nitpicking, the "show all populations" is still a great option.A way to save time is the fact that you'd only have to do that once per class design anyway. To clarify, designate the weapons to fire controls per normal for the first ship in that class you make. Then, whenever you get new ships in the class, click on the Copy Race button under Copy Assign, which is on the top right side of the Combat Overview window. Said button takes the assignment for that ship and duplicates it across all ships of the same class currently in your empire.
Thank you again for the help.
Edit:
I went ahead and checked the fire control assign and it appears I wasn't clear on what my problem was. I know you can assign multiple weapons to a single fire control quite easily. The problem is I often end up with a ship that has for example 200 missile cells and 8 fire controls. This requires me to select tubes 1-25 assign it to fire control 1, than go ahead select 26-50, assign it to fire control 2 and so on and so forth. In this example it's quite easy but in a situation when I have less common missile numbers (for example 14 cells per fire control) it can get quite annoying to do all the calculations in my head in order to ensure each fire control has proper number of missiles and it's easy to make a mistake. This is the part I'd like streamlined, preferably by being able to tell the game to assign X launchers of Y type to Z number of fire controls of W type. This would save a lot of clicks.
Of course I don't know how this would fit into upgrades you're already planning to do, so I don't know how feasible it would be to put something like that in.
A way to save time is the fact that you'd only have to do that once per class design anyway. To clarify, designate the weapons to fire controls per normal for the first ship in that class you make. Then, whenever you get new ships in the class, click on the Copy Race button under Copy Assign, which is on the top right side of the Combat Overview window. Said button takes the assignment for that ship and duplicates it across all ships of the same class currently in your empire.
My other campaign was even worse in certain respects. I had a battleship with 1000 box launchers and 10 fire controls. Seems easy, right? Well.... I was engaging the Swarm. With a lot of FACs. So I had to go assign 10 missiles to each of the fire controls, fire, then add ten more missiles to each fire control for the second salvo and so on. And to make things worse ships ended up with different amounts of ordnance used, which meant that if they fought another battle, copying assignments would be useless.In this case, it really just sounds like you need more fire controls. Or less launchers of larger size of which load from magazines. In this particular case it just seems like you tactically chose the path of greatest resistance in respects to the UI, even!
Of course those are very specific situation, and I doubt many people have such problems. Nonetheless assigning weapons to fire controls is one of the most boring and click-intensive aspects of the game so I'm really looking forward to the changes Steve have mentioned.
In this case, it really just sounds like you need more fire controls. Or less launchers of larger size of which load from magazines. In this particular case it just seems like you tactically chose the path of greatest resistance in respects to the UI, even!
This discussion of box launchers gave me a nice idea: wouldn't it be nice to be able to set orders to have "shoot X missiles at Y" when you don't want a full salvo in general?
I do not think it should be completely automatic, if just because it would complicate things severely in the sense of "why are civilians stealing minerals from the colonies that it needs to be in?Civilians can only transport facilities actually, not minerals. They also can't transport ship parts, missiles, or fighters, though that's not as big of a problem as mineral transport.
As it is, we can already manually set civilian contracts for transportation of facilities or minerals anyway, so we already have what we need, I figure.
Given the somewhat cyclical nature of mineral shipments, if you could set stockpile amounts for various worlds that would be nice.
To weasel some extra functionality out of it, perhaps anywhere that brings its mineral stocks above the 'stockpile' numbers would act as a supplier until stocks drop below the specified number again.
With the 'Occupation Strength Update' does this mean we will see actual colonies/subjugated colonies rebelling and becoming independent? or start a form of civil war?
I know there were issues with the VB6 on this one, I am guilty of just hiding those messages and plonking one unit of REP to "keep the peace" as it were.
I'd also like to be able to more easily distribute minerals around my empire. For instance, if I build something but don't have the resources for it, civilian transports will automatically be contracted to pick them up from either the system, sector, or empire in that order.
I would also like to be able to create our own, empire controlled, shipping line, where we can put our own ships into and always prioritizes empire contracts. It would be a good place for us to dump old freighters and such and make planting multiple mining colonies so much easier, especially over multiple jumps.
For instance, a science "officer" should only be attached to the ship if it has a grav or geo sensor and should be grabbed from the scientist pool rather than the officers. A ship with a habitation modual should have a civilian administrator pulled from that pool. A ship with a hangar should have a CAG.
If ships are going to have multiple officers then their should be more default ranks that encompass more than just command and flag officers. This will also mean changes to the promotion and officer recruitment rates settings to take into account the increased number of ranks that need to be filled out.
I'd have to vote against anything that is likely to increase officer micro-management. I think this is one of those things where there is a conflict between a 4x empire management and a ship or fleet based combat simulator. I love the concept of assigning junior officers to increase battle rp, but I fear what that mechanism would become when I have scores of ships to manage across an empire. I dread the thought of hundreds (or thousands) more junior officers cluttering up the game, spamming messages and eating my time.Mainly I just want junior officers so they can pilot my fighters. Nothing like your Fleet Admiral leading a bombing sortie only to get blown to pieces...
I don't know if this has been posted before but how about giving planets and celestial bodies a maximum population? I'm ok with not applying a limit to planets bigger than the earth, but an asteroid surely can't get up to big numbers such as billions.
On the topic of shipping lines, I would like to be able to ban civilians from passing through systems. It's not something that can be done with AuroraV6, but I hope it would be doable with AuroraC#. Them civvies keep giving away the locations of my secret colonies.
That's what infrastructure is for.
But I can see a population density factor coming into play.
Mainly I just want junior officers so they can pilot my fighters. Nothing like your Fleet Admiral leading a bombing sortie only to get blown to pieces. . .
Honestly, this could be fixed by making fighters not have to be piloted by any named person.
And they aren't a new class of officers I'm asking for just more default ranks of officers with an increased officer recruitment/promotion rank to support it.
Keeping track of deceased and retired officers along with their service records would bee good. It'll help me name my destroyer and frigate sized ships, as the USN does today.
I'd also like it if the layout of the systems we know about in our immediate area were as fleshed out as the Sol system, but that is probably asking too much.
Useless. . . seriously.
Yeah, keeping track of officers is a PITA. At the very least keeping a record of all officers (or at least all officers that had a ship posting) would be great.
A lot of this game is about roleplaying, so I would politely disagree with you. I think that the officer system could be good for roleplay, but it is too difficult to keep track of multitudes of officers to keep it fun.
Yeah, keeping track of officers is a PITA. At the very least keeping a record of all officers (or at least all officers that had a ship posting) would be great.
Something you should be aware of is that we've been here before: Aurora started out keeping dead or retired officers. There was a general consensus that all it resulted in was a ton of noise with very little signal (signal being the "interesting" officers that you would actually want to remember), so Steve took it out. I saw a good idea go by a year or two ago for how to put it back in: basically it would keep dead officers in a holding bin for a short time, allowing you to flag them for permanently remembering. IIRC, this idea came up while Steve was focusing on things other than Aurora, which is probably why he didn't jump on it and run with it. If he were to put it back in, it should probably be on a option so that people who did't want to mess with it could turn it completely off.
I suspect this is the long version of what waresky was trying to say :)
John
Are you going to allow for a more complex OoB, like allowing task forces to be the subordinate of other task forces so we can have a central high command?
Will it also model the central government so our capital system is not just another system in a sector?
A suggestion for C#: For storytelling reasons it might be interesting to be able to transfer minerals from one nation to another via a regular cargo transport (for example if you want to create a pirate "Subnation"). At the moment it is not possible to transfer minerals to other nations; maybe allowing transfer to nations who are allied to you would do the trick.At the very least, you could currently theoretically be able to do so by making a "mineral exchange shuttle" which you exchange ownership of, having it be a ship with cargo space and nothing else (no engines or anything), and fill up on the minerals prior to the agreement.
I realize this might be a pretty big one, but any chance if you try to drop a sub fleet into a fleet at a different location it gives you a "Order this fleet to move to target location and join the destination fleet?" popup?
Strictly a quality of life thing, so if it would be a large coding job it might work better as a feature for a future version.
This made me think of the 4 jump limit on civvies and auto-calculated fight paths. Any chance that limit could be extended?
I realize this might be a pretty big one, but any chance if you try to drop a sub fleet into a fleet at a different location it gives you a "Order this fleet to move to target location and join the destination fleet?" popup?
Strictly a quality of life thing, so if it would be a large coding job it might work better as a feature for a future version.
That limit was already removed in VB6 Aurora. It is now unlimited.I think I saw a message some time ago (in 7.1) where it told me that there is no ship within 4 jump points where the Auto-Refill (with maintenance) could be done.
Best would ofcourse be if unloading and loading were separate actions in terms of time needed, so a ship that both unloads fully and loads fully needs 2x the time of a ship that just dumps it's full cargo load and goes away.
This is how it will work.Ah, great. From reading the update I got the impression there would only be one timer but that it was moved from before loading/departing to before unloading.
On unrep fueling: To avoid micromanagement, I suspect that it would be good to have the computer do fuel management for the player. One almost certainly will want to keep one's ships "topped up" as much as possible, e.g. refuel them whenever their fuel level reaches 80-90%. This would be a BIG pain to manage by hand, even with automated orders (which only work at the TG level). In "real" life, however, this is something the individual captains would simply manage. So what I'd really like to be able to do is have Aurora by default simply keep the ships in a TG at 100% fuel levels and draw down fuel in the tanker continuously, at least until the tanker has so little fuel that its range is lower than one of the ships in the TG. At that point, I can see either continuing to draw the tanker down until some set point (at which point it departs for the nearest fuel source to get another load), or dividing fuel equally (in terms of range) amongst the ships in the TG.
This is analogous to not having to micromanage non-combat jump transits.
John
Will any of the ordnance reloading changes apply to NPRs? I assume since NPRs do not use fuel the refueling rules will not apply to them.
How will these rules affect fighters rearming and refueling on their carriers?
I'll create some carrier-specific rules for the rate of refuel/reload.
After reading the new refueling rules how will the equalize fuel option be handled? I use this option quite often as different classes of ships will often have different fuel capacities and ranges. Will it only be allowed when there are refueling capabilities in the fleet? Will it also take time?
I'd request a smaller refueling system for use on fighters and smaller ships. I've found fighter tankers really helpful for a lot of different uses (both for refueling fighters and when a new player under-specs their ship's range), and it would be a shame if they couldn't be built any more. The same setup would make it cheaper to give capital ships refueling capability.
Will it be possible to have multiple refueling systems on a ship?
Besides that, though, I really like all of the changes. Thanks!
I've thought this over more, and there are a couple of other things which will come into play:
1. Tankers will take a long time to refuel. Even a small tanker with 100 HS of fuel will take 100 hours at low tech. As time goes on, I expect that the growth in refueling rate will outpace the growth of the typical tanker, but it's going to be a problem. Allowing tanker systems to refuel the tanker itself from the planet will go a long way to solving this (particularly if tankers can have multiple fuel systems).
2. The requirements are going to be annoying for frontier planets, because of the size and cost of spaceports. I can think of three solutions:
A. Add in a new structure, of maybe factory size, which serves as a fuel/ordnance hose for maybe a single ship at a time at the normal rate, or even a reduced rate, and multiple structures only allow more ships to rearm/refuel. That way, you can set up forward fuel/weapons bases, and refuel ships at your new colonies without hauling out huge spaceports.
B. Allow refueling systems to transfer fuel to/from the planet. In this case, you'd just have to set up a station ship/tender for the new colony/forward base. It also solves Problem 1.
C. Allow very slow transfer of fuel without refueling systems while stationary, both between ships and between ship and planet. Maybe 5-10% of normal rate, or even a fixed rate of say 5,000 LPH. This is slow enough that it's not likely to be abused, but also means that when you make a mistake and need to rescue that ship, you don't have to divert a dedicated tanker.
All three do slightly different things, and could be implemented together.
3. The refueling systems could be made more interesting. What about two different small versions, one that is a military system and is intended for fighters (10% size, 10% rate, 10% cost), and another that is civilian, and doesn't work underway, for point-to-point tankers? The latter combines with 2B to serve as a secondary fuel handling system for the unrep ships. It could even transfer at different rates to/from planets and ships.
Actually, that's another question. Do refueling systems allow transfers both ways? Could you use one to pick up fuel from a ship and move it to another ship?
Perhaps, a small component with a very slow refuelling rate - not much use for full size ships but probably fine for fighters that will only have 10-20k fuel. If larger ships mount it, it would provide an emergency (very slow) refuelling system.That's more or less what I was proposing, although rereading my post, I didn't mention scaling the rate with size. Make it 1 HS, and have it be 10% of the normal rate, or something like that. In any case, that component will be very useful. If we don't have that, "I lost all of my fuel tanks" will be even more of a death sentence than it is currently.
1) Refuelling doesn't work both ways - think about your car at the gas station, or replenishment ships at sea.1. Understandable, although I'd have to check the unrep manual.
2) The new Refuelling Station is intended for colony planets
3) Yes, tankers may take a while to refuel or to unload fuel to planets (perhaps 2-3 days at early tech levels). That is comparable to the real world.
4) Delivering fuel to forward areas will be primarily done by tankers (using their refuelling systems).
5) See my previous post for an idea on a small refuelling system
Perhaps, a small component with a very slow refuelling rate - not much use for full size ships but probably fine for fighters that will only have 10-20k fuel. If larger ships mount it, it would provide an emergency (very slow) refuelling system.
That's more or less what I was proposing, although rereading my post, I didn't mention scaling the rate with size. Make it 1 HS, and have it be 10% of the normal rate, or something like that. In any case, that component will be very useful. If we don't have that, "I lost all of my fuel tanks" will be even more of a death sentence than it is currently.
1. Understandable, although I'd have to check the unrep manual.
2. 100,000 tons is awfully big for early in the game, unless they can be built in factories like orbital habs. Also, can those siphon fuel from the planet?
3. I suspect it's going to be longer than that (1 hour/fuel HS is a long time), but it's not the end of the world.
Could also be balanced by a very expensive component ( so you really don't want to put 50 off them on your tanker/big ships, or all over the entire fleet ).
I did read a US Navy unrep manual (from 1996) while creating the new rules :) The largest US navy replenishment ships can transfer 180,000 gallons per hour, dropping to around 40-50,000 for smaller ships. Section 3.2.3.That was the exact manual I was thinking of. I will point out that those numbers are per hose, and it's normal to see tankers refueling with hoses on both sides, and not unknown to see tankers using two hoses per side for bigger ships.
https://www.maritime.org/doc/pdf/unrep-nwp04-01.pdf
I decided to use litres instead of gallons (Sorium is more unstable :) ) and use the top US Navy rate as the mid-range. An Arleigh Burke holds about 580,000 Gallons, while a carrier can hold around 3.5m gallons of aviation fuel, so those correspond quite well to Aurora fuel tank sizes (using litres as gallons). A US DD will take about 3-4 hours for the best refuelling rate and around 12 hours for the slower end.I'm having a surprising amount of trouble duplicating those numbers, but I'll take your word for it. (Actually, no. I'd like sources, not because I doubt you, but because I want to know where the numbers came from for future reference.)
The Refuelling Station is a ground-based installation built in factories that is half the size of a research lab for transport purposes. The 100,000 ship-based component is a Refuelling Hub.Ah. My bad.
So given the new rules on fuel transfer are you also thinking about a similar system for ordnance?
That was the exact manual I was thinking of. I will point out that those numbers are per hose, and it's normal to see tankers refueling with hoses on both sides, and not unknown to see tankers using two hoses per side for bigger ships.
I would just like to note that the wet navies have been refuelling small ships from larger ships certainly since WW2.
Yes, it was very slow compared to purpose built replenishment vessels and only one ship at a time could be refuelled. Thus would it be possible to have a basic (low) transfer of fuel from one ship to any other as a starting tech. Sorium may not be bunker fuel but I don't think it’s as touchy as mercury fulminate!
In addition why would ships have to be stationary? They are in space, no waves or storms to batter the ships and cause disconnection! It should be similar to in-flight refuelling and current day frigates carry their own hoses, at least they did when I helped destore HMS Undaunted when a student (vacation job). That said I cannot see why the restriction on refuelling systems not stacking is in place. Surely it should depend on the sze of the refuelling vessel? Let’s face it if current airforce tankers can refuel three aircraft a time why cannot a spacecraft? It comes down to are spacecraft equivalent to wet navy ships or more like aircraft in some respects?
If they are more like aircraft then only tankers can refuel other ships, but if the model is wet navy then any ship should be able to reuel at least one other ship.
In technobabble terms, the liquid-like dimension in which TN ships travel causes the same type of random turbulence that affects wet-navy ships :)
Do we have to add refuel system on carriers?
Since I am reading more and more new stuff added to C#-Aurora, I was wondering how importable a 7.1 MDB would be? Do you have plans regarding that, Steve?Here is how version changes go. X.00 changes are full version changes, with completely different mechanics so DBs are incompatible. 0.X0 are database changes, so DBs are incompatible. 0.0X changes are minor changes, so DBs are compatible.
More generally: I don't think I've asked how your C# experience compares to VB6. Are you finding it tons more powerful/efficient? One of my friends (before I started C#, and before C++11) once told me he thought he was an order of magnitude quicker using C# over C++. I didn't believe him at the time, but once I started using it myself I was a lot more inclined to agree. From my point of view it's due to: 1) No memory management issues due to garbage collection (almost solved in C++11 by smart pointers) 2) Built in container library (.NET) from the start (solved for new projects by STL in C++11) and 3) Intellisense - it's a big win to be notified of a syntax error by having auto-complete stop working and to see the error underlined.
John
On Fleet orders screen:
You explicitly put "CIV" harvesters in the set of possible fleet "move to" locations. From this I infer that normal commercial ships (cargo/passenger) will NOT be available. If so, you might want to reconsider that: a player might want to move a fleet to the location of a commercial ship, e.g. as an escort (in which case you might want to allow a commercial ship, or body, or ... to be the "focus" of a fleet formation if you don't already) or to intercept an enemy formation that's attacking it and that isn't visible on sensors (that's one's probably pretty weak - if the commercial ship is getting attacked, it's probably going to get blown away pretty quickly).
Which reminds me of another thing I see people having trouble with all the time: targeting sensor drones and/or minelayers at a moving body like a planet. You might be able to put some sort of "extra" checkbox in for targeting missiles that differentiates between "attack" and "move to" - maybe it would be two different targeting buttons.
John
Steve, is it possible to have search sensors switch on separately from fire control sensors? This would be of great benefit in (a) letting you know you are being lit up by a fire control sensor as opposed to just a search sensor (indicating hostile intent) and (b) enables the player to light up a potentially hostile ship to show your displasure without actually firing on it. Hopefully the last could be linked to NPR dipolomacy such that they respond in kind or go away.
What about the option to turn on/off specific search sensors? Unless I missed something, we only have the option to toggle them all at once right now.
Just out of curiosity, is this something you can do in reality? I mean detect if the radar that is tracking your craft is a firecontrol or search radar?Absolutely. These days, advanced ESM systems can identify specific emitters, which they can then correlate with a library to figure out exactly which ship they're looking at. (This is because naval radars are essentially hand-built, so they vary a lot more than, say, merchant navigation radars.) Even the most basic ESM can tell apart a search radar and a fire control radar. The two have very different requirements (large area vs precise targeting), which affects what signals the designers choose, and that in turn can be picked up by the ESM system. Unfortunately, this is an area without a lot of good online sources.
Edit: I am not an expert so some of the above could be wrongNone of it is wrong.
To some extent, this can be done now by increasing the resolution, but it would be nice to have it as a more explicit design option.This can also be done by focusing more on EM sensitivity than Grav-pulse strength. That is one of the better things to do for stealth craft later on in the game. You create a stealthed active sensor with a very high sensitivity but a low pulse strength, increasing range of detection wile lowering emissions.
This can also be done by focusing more on EM sensitivity than Grav-pulse strength.I'm aware of that, but there are limits on what you can do there.
That is one of the better things to do for stealth craft later on in the game. You create a stealthed active sensor with a very high sensitivity but a low pulse strength, increasing range of detection wile lowering emissions.Actually, if you dig through the math, lowering pulse strength doesn't improve the ratio of range to counterdetection range. The EM sensitivity is applied as a multiplier to your range, so making a bigger sensor with reduced pulse strength gains you nothing over a normal sensor.
What you can do though is use big fine-grained sensors - resolution scales linearly with grav pulse strength, but range will only increase by the square root.I'm aware of that, and there are two reasons I'd like to see it changed:
At the same EM sensitivity tech, a R100 sensor can be detected at its maximum range by a size-1 passive EM sensor... for an R1 sensor, you'd need a size-10 passive.
Making ships that are far too thirsty for no tangible gain is an extremely common design mistake, now one is punished harder for it.I think that is the point of this change. Its to add a greater complexity if you want to continue to build the small designs that skimp on fuel because you could just lug around a small tanker with you.
Now it's reasonable to design ships for the utmost fuel efficiency possible for given speed requirement and tech (and aiming low with speed requirements unless essential to the role), rather than making a conscious trade-off versus build cost or compactness... because designing them so we can mostly ignore fuel logistics saves considerable investments elsewhere as well as headaches.
You probably don't want to load highly volatile fuels while loading fragile goods and using high power tools to perform maintenance. "Whatever can go wrong, will go wrong"It depends on how you design your fuel system, and where the work is going on. Modern ships routinely transfer ammo and fuel at the same time during UNREP operations, and that's while they're underway.
I don't mind sequential nature of loading orders (fuel, ammo, etc), but I was more talking about loading while also under overhaul. Honestly, you would need some powerful tools to perform overhauls on a ship with a very dense armor layer. So why would anyone risk a major accident from a minor leak from a fueling line while cutting open a ship to replace systems/armor plates. Or risk a structural failure/depressurization while simultaneously loading a group of children on a field-trip to Mars.I agree that allowing port ops while under overhaul would be silly, but that's not what Scandinavian was advocating. He was pointing out, quite rightly, that operations like fueling and cargo loading/unloading often go on at the same time IRL. There's no real equivalent of 'minor hot work' in Aurora, and his inclusion of that seems to have thrown you. I'd agree with him, and say that the best answer is to allow all operations (load/unload of cargo/colonists/troops, fueling, loading ordnance and MSP) to take place simultaneously. Restricting each ship to one operation at a time is a less good answer, but still sensible. Restricting the whole fleet to one operation at a time is silly and could be really annoying. Let's say we're setting up a new forward base. We have cargo, fuel, troops, ordnance and supplies. Each is on a different set of ships, and will take 2 days to unload. If we insist on sequential ops, then it takes 10 days, instead of the 2 it would take if we split each into its own fleet, and there's no plausible explanation for it.
If tanker is part of a fleet that it has orders to refuel (i.e. keep topped up), but doesn't have sufficient tech to keep up with fuel usage, the refueling priority should be arranged so that we don't get into a situation where a high priority ship has full tanks after a while a low priority ship in the same fleet is empty.
Suggestion for a different way to handle unrep: Calculate total fuel burned for the increment by the entire fleet, then calculate the percentage of that which is offset by unrep and apply that percentage to each ship. So if a fleet burned 50,000 units of fuel in an increment, and had unrep capacity for 40,000 units, then 80% of each ship's fuel consumption would be offset by unrep and each ship would burn fuel at 20% of its unmodified rate. Note that the interaction of this and the "refuel subfleet" might be a little complicated, so you might need to restrict or eliminate that order.
John
I'm quite wary of the refueling changes.
Making ships that are far too thirsty for no tangible gain is an extremely common design mistake, now one is punished harder for it.
Now it's reasonable to design ships for the utmost fuel efficiency possible for given speed requirement and tech (and aiming low with speed requirements unless essential to the role), rather than making a conscious trade-off versus build cost or compactness... because designing them so we can mostly ignore fuel logistics saves considerable investments elsewhere as well as headaches.
It seems a set of changes that, while mechanically complex,could easily reduce depth ("playing around it entirely is the best option" -> fewer legitimate options while the interesting ramifications end up ignored).
This talk about orbital infrastructures having their own stockpile reminded me of a bug I ran into in my current campaign. I used genetic modification center on Earth to create sub species to inhabit the Antarctica and underwater. This put multiple pops on the same system body.
The game will select a random pop from the same system body when trying to perform operations like routine ship maintenance. This will create a problem when you have orbital maintenance modules giving all the pop ability to repair ships, however they can't do it because some of them lack the minerals. Worst of all, the pop that it tries to pull resources from keep on changing, making it a micromanagement nightmare.
Does having multiple resource stockpile on the same system body have any game play benefits? They are on the same body after all, shouldn't they just share a single stockpile?
BTW a side effect of the concept of putting all logistics into space is that it makes space-based 'populations' much easier. In effect, the ground-based element of a colony becomes the supply source of the orbital infrastructure (infrastructure in this case meaning orbital dockyards, fuelling and cargo hubs, ordnance transfer facilities, barracks, etc.).
The orbital infrastructure would draw from its own stores of fuel, spares, ordnance, even minerals to produce its own spares - maybe even some form of automated orbital ordnance factories (expensive but no manning requirements).
The actual ordering mechanics may be an issue, as they aren't really flexible enough to handle multiple options at the moment, except for something like 'unload all', which is simultaneous in VB6 Aurora. Maybe could be expanded to Unload All & Replenish but still not ideal, especially for loading. Perhaps some form of package order, where you have a general catch-all loading order but you can specify numerous options within it (load fuel + cargo + colonists + troops). However, this would be a lot of additional work and I am not sure how often such a complex situation would come up. How often do you have fleets with cargo and colonists and troops, etc.?
In current Aurora there are millions of them, and I don't think it makes sense for millions of them to live in the Spacestation except for when it comes to very advanced civilizations with truly massive lategame stations.Surely shipyard workers will just commute up from the surface? With TN tech that would seem trivial. And trying to set up an shipyard without a population should be a major logistical challenge via orbital habitats. I would see deepspace stations as being mostly refueling/repair/ordnance/trade stations, with actual shipyards requiring, in most cases, a planet with a population to supply the workers, unless you make a very major effort.
So either the shipyards are also made fully automated, or all orbital facilities could need workers from some sort of special smaller pool that live in orbit on the space-station you build.
It could in that case be treated as an entirely separate layer, and all orbital facilities require population to operate as well, although much less then ground facilities.
Maybe orbital habitats should be a special sort of infrastructure building that expands your "orbital population pool", and show up as an object in orbit once finished but are built by industry on the ground.
Building on the space station idea, fleets could interact directly with the space station, instead of the population on the planet, and have the option of unloading to (or loading from) the station or using the station facilities to unload directly to the planet. A planet could have more than one station but it would probably make sense to combine them (so ships can use all the station abilities at once). Space stations could also be boarded and captured (if they are defended by troops that could mean some interesting battles), which would also potentially lead to situations where you try to defeat enemy forces without damaging the valuable space stations.
Surely shipyard workers will just commute up from the surface? With TN tech that would seem trivial. And trying to set up an shipyard without a population should be a major logistical challenge via orbital habitats. I would see deepspace stations as being mostly refueling/repair/ordnance/trade stations, with actual shipyards requiring, in most cases, a planet with a population to supply the workers, unless you make a very major effort.
No it's NOT trivial!We can solve this by waving the transnewtonian wand. Something something flow interactions, thus ships will be destroyed if they try to fly into the atmosphere. Particularly note that we can build ship components, even very large ones, on the surface, and use them in orbit. From a design standpoint, having to be able to launch from the surface is a huge constraint, and not one that will be accepted.
Remember that we are working under the assumption that it's such a big issue to move military 1000 ton+ Spaceships to the surface that they must be built in orbit and kept there.
We can solve this by waving the transnewtonian wand. Something something flow interactions, thus ships will be destroyed if they try to fly into the atmosphere. Particularly note that we can build ship components, even very large ones, on the surface, and use them in orbit. From a design standpoint, having to be able to launch from the surface is a huge constraint, and not one that will be accepted.
Orbital launch might well be done via lasers or space elevators. It's pretty obvious that energy is not the constraining problem in most of the range of Aurora, and that makes orbital launch potentially very cheap. That said, I'd expect the yard workers to run in multi-day shifts in most cases, sort of like they do on oil rigs. That, plus the assumption that the employer is bussing them in instead of them taking 'cars' cuts the required commute transport by about an order of magnitude.
So how can the 100000 ton commercial spaceships land on the new planet that has an atmosphere and high gravity to unload colonists and factories? ??? ::)Trans-newtonian physics, shuttlecraft, gravity tethers, etc
Or how does the 10000 ton capacity commercial shipyard you build ( which is bound to weight at least 2 times that amount ) get into orbit?Its constructed there.
And why is it so easy to commute millions of shipyard workers but no other orbital infrastructure can be allowed to require workers?This assumes that the workers aren't living in space condos with a space back-yard with their space family. Also orbital elevators, shuttles, etc.
Some handwavium I can accept but alot of this stuff is simply not consistent at all with very similar problems being impossible in one case and trivial in others because... reasons.Well, those reasons keep the universe from violently collapsing on itself.
Even if you bring the needs down by weekly shifts and bussing by 2 orders of magnitude we are still talking about 25 million tons of Civilian craft per year for commuting alone, to produce less then 1/50:th as much tons of ships ( assuming 10 day weeks and 100kg "bus" per worker which is extremely low ).This is assuming you can only use the "bus" once and it needs to be rebuilt every trip.
This assumes that the workers aren't living in space condos with a space back-yard with their space family.
This is assuming you can only use the "bus" once and it needs to be rebuilt every trip.
So how can the 100000 ton commercial spaceships land on the new planet that has an atmosphere and high gravity to unload colonists and factories? ??? ::)Shuttles, which Steve is looking at adding.
Or how does the 10000 ton capacity commercial shipyard you build ( which is bound to weight at least 2 times that amount ) get into orbit?In pieces, obviously. But there's overhead to having to do in-space assembly without support. The shipyard provides that support for the ship.
And why is it so easy to commute millions of shipyard workers but no other orbital infrastructure can be allowed to require workers?I don't know. Under the current setup, we don't have other orbital infrastructure, except stuff specifically designed for forward basing, where requiring ground-based crew would sort of defeat the purpose.
You can say what you want about most of Steves other game mechanics and how much handwaving is done, but they are for the most part consistent ( this is what I love about them the most and which helps immersion into the story alot too ).I'm all in favor of consistency, to be sure. And I think we're working towards a new equilibrium on that.
Even if you bring the needs down by weekly shifts and bussing by 2 orders of magnitude we are still talking about 25 million tons of Civilian craft per year for commuting alone, to produce less then 1/50:th as much tons of ships ( assuming 10 day weeks and 100kg "bus" per worker which is extremely low ).Do you have any idea what the ratio between cars and ship tonnage produced is today? Let's take Electric Boat, because they only produce one kind of ship these days (the Virginia-class submarine). They have 13,000 employees, and produce one 7800-ton ship every two years. If we assume 250 working days a year, that's (rounding shamelessly) 1.2 kg/worker/day. Yes, there's a lot of overhead included in that number. Yes, they build nuclear submarines, which means high standards. Under your numbers, that comes to 1/10th the launched mass, but I don't think it's unreasonable to assume that EB's subcontractors could lower that by another factor of 2 or 3. We're in the same ballpark.
No it doesn't. I'm trying to compare the amount of work/effort needed to transport the finished Military ship once into orbit, and the millions of workers constantly.Yes. That's a good point, except that we're clearly in a setting where launch costs for personnel and small units of cargo are very cheap compared to today. (Small refers to the size of each unit, not the total volume). We can easily put all the pieces of the military ship in orbit. The problem is that a finished one is too big to fit in our laser launcher, and thus has to be put together up there.
Do you have any idea what the ratio between cars and ship tonnage produced is today? Let's take Electric Boat, because they only produce one kind of ship these days (the Virginia-class submarine). They have 13,000 employees, and produce one 7800-ton ship every two years. If we assume 250 working days a year, that's (rounding shamelessly) 1.2 kg/worker/day. Yes, there's a lot of overhead included in that number. Yes, they build nuclear submarines, which means high standards. Under your numbers, that comes to 1/10th the launched mass, but I don't think it's unreasonable to assume that EB's subcontractors could lower that by another factor of 2 or 3. We're in the same ballpark.
Let's try another. The Boeing plant in Renton produces 42 737s each month, and employs about 11,000 people. Neglecting work done in other plants (a lot) each worker produces about (42 A/C*41430 kg)/(21 days*11,000 people) = 7.5 kg/worker/day. I'd suggest taking at least a factor of 5 out of that number, based on how much gets built elsewhere.
I still think it would be more relevant to compare the ratio of cars to APC/Tanks (other more similar ground based military vehicles), then to ships or airplanes.Why? We're discussing building interplanetary/interstellar transports in Aurora, too, so picking ships/airplanes seems only reasonable.
In a hypothetical future where everyone has a "spacecar" for orbital commuting a ship or airplane is more akin either interplanetary or interstellar transports (longer distance).
This means military "versions" of the "spacecar" could be as numerous as our APC/Tanks are in today's militaries ( thousands of them ).
Does that pass the giggle test? :)It passes the giggle test with flying colors, IMO. Add in restricted payload on the shuttles (say 500 tons) and the whole thing explains what we see reasonably well.
There is an even simpler solution: The hull of spacefaring vessels is designed to operate in weightlessness. If you try to put one down on the ground, the hull will not support its own weight.That just doesn't work with current game technobabble of the ultra-dense TN materials.
Similar to how you certainly can build an oil tanker that you can beach (and get back into the water, unharmed). Nothing in the laws of physics prohibits it. But nobody does, because there is no use case for that.You say that, but...
That just doesn't work with current game technobabble of the ultra-dense TN materials.Yes and no. There would be some design penalty, but it would be minor enough that I'd expect them to just take it.
Sure it does. Ultralight materials means you can build bigger dual-role vessels before it becomes impractical, but it doesn't abolish the square-cube scaling geometry.Square-cube would hardly stop you flying small ships to the ground at relatively minimal penalty. Unless the technobabble stopped you, that is. Don't get me wrong, you're entirely correct about real-life examples, but analogies often break down near TN systems.
Square-cube would hardly stop you flying small ships to the ground at relatively minimal penalty.
Good point re PDCs.
One option is to remove PDCs entirely, although that causes other issues with planetary bombardment vs ground forces. On the gripping hand, a counter to that is to make ground forces harder to destroy with bombardment (dispersal, hard to detect or well dug-in).
Second option is just to remove hangars from PDCs.
Not sure how hard it would be to code, or whether the use cases justify it, but it would seem to be a more plausible restriction than "no atmosphere-capable TN vessels ever."The problem with that is that it breaks the shipbuilding model rather badly. Various people are going to ask, quite reasonably, why they can't build ships with landing modules on planets with their factories instead of having to use shipyards. There are ways to deal with that (something something trans-newtonian alignment) but it's more consistent to just get rid of the problem entirely by banning all TN ships from all planets.
I would just remove hangars from PDC. And missile launchers, and beams. Let me explain why.Unless you mean 'lasers' when you say 'beams', that literally only leaves ground troop barracks by my math.
If we go with the technobabble you wrote in the last page, which by the way I really like as a pseudo-science explanation, then there is no point in having a PDC hangar, because no ships nor fighters can be based on the planet. Even fighters have a TN engine, travel at TN speed and as such are TN ships through and through. So they have to be based on ORBITAL bases. They cannot handle the atmosphere.That's what I pointed out, although it's a matter of gravity, not atmosphere. Otherwise, you'd just park the fighters on Luna.
Same for missiles, which have a TN engine and likewise travel at TN speed. So, they too should be based on orbital bases and such.Maybe. But maybe the missile is smaller and less affected by turbulence. (Unless we ban missiles from firing into planets, too, we have to allow this.) Or maybe we fit the missiles with a conventional booster to throw it clear of the atmosphere.
And same with beams (which btw are already mostly just worth it outside the atmosphere)This matches my interpretation of beam weapon physics (they have to propagate superliminally to have any chance of hitting), but that's not canon. Also, mesons.
One option is to remove PDCs entirely, although that causes other issues with planetary bombardment vs ground forces.My issue with this is that I like the idea of planetary bunkers or military bases.
Second option is just to remove hangars from PDCs.I like this one better. Alternatively you could make it so you can only land fighter sized designs in planetary hangars.
Yeah, What if you can only have max 500 ton fighters in PDC hangars? ( unless on a really low gravity body ).
It would be really cool to see an atmospheric flight module for fighters allowing them to fight/fly inside an atmosphere. Not sure how complex it would be but it could work similar to stealth/jumpdrives as a fraction of tonnage depending on tech, and they would not attack ground forces directly but support them making their normal attack ticks greatly stronger instead if you got air superiority.
Or maybe we have fighters that have 'orbital manoeuvring' instead of TN engines. So you have TN space-based fighters and a separate class of fighters that can operate in orbital space or close to the planet (essentially similar to an advanced version of modern day fighters). That fits with the 'cargo shuttles' concept of no TN engines close to planets, adds a new use for carriers, adds close air support for ground combat and even adds dogfights in planetary orbit. There is even now a reason for anti-air units or flak defences. You could also have these fighters based on PDCs. I think WH40k has a distinction between space fighters and atmospheric fighters (although in this case it is gravity well vs non-gravity well)
In fact, if we assume that TN missile engines can't handle gravity wells too, you could use these fighters to deliver ordnance to the surface. Then we start looking at potential beam weapons usage for orbital fire support too :)
This is even better. I like this possible solution very much.
It would both solve the problem of PDCs, and increase the tactical and logistical considerations of a planetary assault.
To take a planet, first you have to deal with the fleets and orbital platforms around it. Then you have to consider whether to overwhelm the planetary defenses with massive amount of troops, or to bring in support, in the form of specific ships and carriers with crafts/weapons that can affect PDCs, defenses and ground troops.
As it is right now, if you bring a large enough fleet around a planet you can just deal with anything and everything you can find on the surface. If you go through with this idea instead, a large TN fleet might blockade the planet, yes, but it cannot provide consistent ground support, nor obliterate the PDCs from orbit. This actually makes the existance of "fortress planets" feasible, planets very difficult to capture regardless of the orbital defenses.
I'm salivating at the thought of designing planetary-assault specific carriers, attack crafts and weapons systems. Bomb carrying strike crafts. Extremely agile dogfight fighters. Radar support crafts (similar to modern day AWACS). Think of all the RP possibilities :)
Same for planetary defense, if you can't or don't want to use orbital platforms or fleets, you can elect to use large amount of ground defenses, PDCs, orbital fighters. You cannot prevent the enemy from blockading you, but maybe you can gain enough time to bring in your fleets, or even avoid capture alltogether if you stack enough defenses. This would add some very interesting defense options.
Salivating already. Very excited at these proposals, but could the NPR's handle it?
If we go the way that nothing powered and TN works in a gravity well, why do my ground units need TN materials to be built? Why do my buildings?
How come TN DSTS and mass drivers work? Surely these are definitely halfway into the liquid spacetime universe too (while the other buildings just might not be), and yet in a gravity well, meaning they shouldn't function?
And if fighters are separated, will TN fighters then be produced in orbital shipyards too? That's after all where TN ships are built, since they can't go down a gravity well at all.
But then we also have the problem of NPRs starting OOBs, they often have carriers and BB/BC much more massive than their shipyards (sometimes even bigger than all their naval shipyards put together). How did they come to be if they couldn't build them on the ground and send them up?
You should keep everything as is. Atmospheric fighters are more fit of being a ground unit with special rules than proper ships, I think. (I assume it'd be possible, since marines and combat engineers are fighting GU with special rules already.)
But then we also have the problem of NPRs starting OOBs, they often have carriers and BB/BC much more massive than their shipyards (sometimes even bigger than all their naval shipyards put together). How did they come to be if they couldn't build them on the ground and send them up?
For example perhaps the technobabble is actually that only refined Sorium becomes hugely unstable in gravity and hence can't be brought into a gravity well, given this is the fuel for all TN ships it stops them landing etc but does not stop a Nutronium tank or auto mine being built and used on a planet. Also you can build anything on the planet but then need to ship up and down as already discussed?
I was thinking about PDC missile launchers and hangars some more, because I would really prefer for them to stay in the game. What about increasing size of PDC launchers and hangars and say that they are quipped with small mass driver that catapults missile or fighter from pdc. Of course that would not solve the problem with the fighters actually landing on PDC.Mass drivers are capable of catching huge mineral packets, surely if the fighter shuts its TN engines off, it could land on a PDC hangar the same way.
Mass drivers are capable of catching huge mineral packets, surely if the fighter shuts its TN engines off, it could land on a PDC hangar the same way.
The TN ships are designed for travel which primarily takes place in the other dimension (which we need a name for) that is based on liquid physics, with only a small portion of the ship existing in our own dimension.
Problem with sorium being unstable in gravity well is that you would not be able to refine and store it on the planet.
As I understand it, in the present system using a ship with troop bays but plenty of cargo handling does not mechanically disadvantage your army compared to drop pods - which are therefore almost confined to the niche of boarding operations. At minimum, the new mechanics being considered could justify pods allowing you to land your ground forces without having to establish air superiority first. But I'd like it if someone could come up with more tradeoffs, so there is a broader spread of workable options.For one thing, CDMs are a lot smaller than the transport bays (50/10 compared to 10/2[20/4]). Several things happen because of this. A) Designs using these are smaller and faster, as to capture ships or run through defenses. B) You can fit a lot more troops in for a similar size. The second thing is that you can move troops from a transport bay, to drop pods while in flight, doing the same thing as having a lot of extra cargo handling for a lot less of the mass. Thirdly, the cryo drop pods negate the "drawbacks" the normal drop pods have anyways, while still being smaller than the original bays.
You could decide the drive field instability in gravity only occurs at a certain size of drive field, which just happens to be anything larger than a missile.
And on the topic of why TN engines don't work in gravity, the technobabble seems to be that the reaction in the engine itself is unstable with a large gravity well,, not the fuel source. This is evident because 1) it is found in the ground and often on bodies with very high gravity. 2) Because everything has gravity, and if it is unstable with gravity then it could never be stable.
EDIT: In fact, now that I think about it, even just launching such a TN missile from a PDC makes no sense. Even if the TN missile would mostly be "in the other dimension" or something similar, the remaining mass in this dimension should either make it blow up as it tries to leave the atmosphere, or at least have horribly disrupting and damaging consequences on the surrounding cities/landscape.
An item streaking through the atmosphere at half the speed of light? Well, I don't want to think of the possible effects. Hope you don't have fragile things nearby. You know, cities, mountains, oceans, that kind of fragile things.
The more I think about this, the more I like the idea of restricting Tn engines of any kind to operating in space and space alone.
Imho this is opening another can of worms. If the atmosphere is the problem, then for example Moon base can launch TN fighters and missiles without any problem.
As for building fighters on planets, that's why I suggested a limit on orbital lift of 500 tons. It provides a nice explanation for the fighter cutoff, and keeps the system more or less as-is.
EDIT: In fact, now that I think about it, even just launching such a TN missile from a PDC makes no sense. Even if the TN missile would mostly be "in the other dimension" or something similar, the remaining mass in this dimension should either make it blow up as it tries to leave the atmosphere, or at least have horribly disrupting and damaging consequences on the surrounding cities/landscape.Think of the launchers as magnetic launch rails to fire the missiles away from the ship/gravity source before the engines ignite.
An item streaking through the atmosphere at half the speed of light? Well, I don't want to think of the possible effects. Hope you don't have fragile things nearby. You know, cities, mountains, oceans, that kind of fragile things.
To be honest, I think making them in space would be more consistent. There would need to be some tinkering on spaceyards, but still more advisable. To bring up a 500 ton ship you need a very much larger one, if you consider the more or less "conventional travel" of "orbital ships" and such.Depends on your tech level. If we're allowed to exceed the limits of conventional thermal rockets, then I could see a case where a ship with a 500 ton payload would be, oh, 2-300 tons dry. The big advantage of fighter factories I want to retain is that they don't need to be retooled.
Fighter factories should be renamed though. Maybe to "orbital ships factories" or something similar.
Depends on your tech level. If we're allowed to exceed the limits of conventional thermal rockets, then I could see a case where a ship with a 500 ton payload would be, oh, 2-300 tons dry. The big advantage of fighter factories I want to retain is that they don't need to be retooled.
Think of the launchers as magnetic launch rails to fire the missiles away from the ship/gravity source before the engines ignite.
That could work, but it would also mean that for the first 10-20 seconds or so of flight, those missiles would be extremely slow comparatively speaking. This would need to be modeled by the game. Anything in orbit with PD would shred them apart in that period of time, before their engine ignite. For the weapon systems that exist in the game, calculating the trajectory and hitting a 2km/sec missile just before it ignites its TN engine is trivial.This is already how ICBMs work, more or less, and while it would render missiles useless against targets in the same orbit, they could still work against targets approaching from deep space, which is, IMO, more important.
For example in Steve most recent game, when there was the surprise attacck in orbit against another nation by (I think) the USA? No maybe it was Germany? Anyway, any PDC-based missile would have been useless with this model, shot down by the fleet PD just before they ignited their engines.
Could be done but really, I think it would be both cleaner, more consistent with the technobabble AND more interesting to just go with "Any serious weapon to be used against TN fleets is based in space as well" if Steve wants to go with this dual approach of TN-flight/Orbital flight.
Could be done but really, I think it would be both cleaner, more consistent with the technobabble AND more interesting to just go with "Any serious weapon to be used against TN fleets is based in space as well" if Steve wants to go with this dual approach of TN-flight/Orbital flight.
Depends on your tech level. If we're allowed to exceed the limits of conventional thermal rockets, then I could see a case where a ship with a 500 ton payload would be, oh, 2-300 tons dry. The big advantage of fighter factories I want to retain is that they don't need to be retooled.But why shouldn't fighter factories need to be retooled? They do in real life. In fact if you take the F35 as your example it seems to take far longer to design, build and deliver a new generation of modern fighter jets than a new warship.
Yes, I will have to think carefully about the interface between planetary and space combat. For example, we have the scenario of planetary fighters moving into orbit, firing off TN missiles at approaching ships and then retreating back into the safety of the gravity well (maybe that should be allowed but also maybe not).If we want true distinction between planetary and space combat, perhaps the technobabble is that any weapon that can be used to hit TN ships has to penetrate the 'Aether' (Good suggestion!) and because of the turbulent nature of the Aether within gravity wells, TN weapons cannot be used to fire into or out of the gravity well (even beam weapons).It sounds to me as if you're suggesting something close to submarine warfare then? We can keep our fleets of TN warships safely "submerged" just off the coast, but our torpedoes are then useless against anything onshore, or we can "surface" to use our deck gun, but at that point become vulnerable to return fire.
Perhaps TN missiles are created in orbital factories too because their warheads become unstable in gravity wells. Actually better would be created in ordnance factories as now but 'assembled' in orbit (in effect immediately delivered to a magazine on an orbiting base or space station) - that solves the 'planetary fighters popping out to fire' issue.
There would have to be new types of weapons designed to be used only in 'normal space'. These would not normally be effective against TN ships as they can't penetrate the Aether, just other planetary-based PDCs, fighters, factories, etc..
An option (thinking out loud) for orbital fire support is that you could have these weapons on board a TN ship. However, it would have to emerge from the Aether to use them, making it visible and leaving it vulnerable to planet-based weapons / fighters.
Something on those lines would create a very stark distinction between planetary and space combat. Almost a WH40k type distinction. Winning the battle in space would no longer virtually guarantee winning on the surface.
It sounds to me as if you're suggesting something close to submarine warfare then? We can keep our fleets of TN warships safely "submerged" just off the coast, but our torpedoes are then useless against anything onshore, or we can "surface" to use our deck gun, but at that point become vulnerable to return fire.
I would be a very radical change to the feel of the game.
But why shouldn't fighter factories need to be retooled? They do in real life. In fact if you take the F35 as your example it seems to take far longer to design, build and deliver a new generation of modern fighter jets than a new warship.Not exactly. The difference is that fighters tend to be higher-profile than warships, and a bit more tightly integrated. And the physical tooling is a fairly minor part of that. The electronics dominate both.
And how can we justify the arbitrary cutoffs between fighters/FACs/ships anyway? It seems much more intellectually satisfying to treat all TN craft in the same way for manufacturing purposes. If you want deep-space fighters, why couldn't you build a new ("small") orbital dockyard, add 10 slipways* and build away? If you want variants with different payloads etc then you need to design them to be interchangeable, just as with larger warships.A fair point, but I would point out that there's a significant difference between the way the two types of vessels (fighters and warships) are constructed IRL. If I'm planning to mass-produce small craft, then I'm likely to use the airplane model instead of the ship model. Larger craft can't be moved like that, and aren't likely to be built in the same numbers anyway.
There would have to be new types of weapons designed to be used only in 'normal space'. These would not normally be effective against TN ships as they can't penetrate the Aether, just other planetary-based PDCs, fighters, factories, etc..TN ships will have to be able to leave the Aether to work in normal space, unless all of the dock facilities and such are also 'submerged'. Again, I'd suggest that 'surfacing' should greatly slow the ships, giving advantage to those that are not designed to 'submerge'.
An option (thinking out loud) for orbital fire support is that you could have these weapons on board a TN ship. However, it would have to emerge from the Aether to use them, making it visible and leaving it vulnerable to planet-based weapons / fighters.
Something on those lines would create a very stark distinction between planetary and space combat. Almost a WH40k type distinction. Winning the battle in space would no longer virtually guarantee winning on the surface.I'm sort of against this on aesthetic grounds, but it could make the game interesting in different ways.
I'm... honestly kind of opposed to this change. I think it's overcomplicating things for no real gain; I mean, just look at the last few pages for an example of how it complicates things.Yes.
I think things work fine as we are. We don't need a strict separation between what's in space and what's not.
If you completely ignore what happens between orbital facilities and ground ones and leave it to imagination, it's way better, yes.
So will these orbital facilities be designed like ships and orbitals currently? Will current buildings be renamed to "Orbital [Building]" while new and cheaper ones would be on the ground?
But really, I'm confused as to why we need a reason for ships to stay in space in the first place. Maybe you could still allow ships to land, refuel and replenish supplies on the ground, but it'd all take more time than in orbital stations? Kind of like a spaceport speeds up loading/unloading. I remember reading you wanted refueling to actually take some time.
Since we're into writing technobabble now, imho you should make interesting/rewarding mechanics first, and write technobabble that fits later, it's not like we're constrained by real science and engineering.
OK, I've read back though and we are getting quite complex :) I still like some of the proposed changes though so lets go back to a simpler version.
This all began because I was answering a question on replenishment at the same time as other orders and then suggested moving all logistics into orbit. The subsequent discussion went from that point because we needed a reason to keep ships in space. That reason then sparked a series of different consequences. So how about this instead:
1) We have technobabble that states ships can't land on planets, so logistics is generally in orbit (fuelling, cargo transfer, maintenance modules, etc). This will make non-planet based logistics much easier and will makes orbital space and the early game more interesting
OK, I've read back though and we are getting quite complex :) I still like some of the proposed changes though so lets go back to a simpler version.It sounds good overall, except for one nit. Currently, you can put vessels larger than 500 tons in PDC hangars. I've built PDC bases for my strategic strike command, based around FACs, and toyed with PDC 'dry docks' for ship repair.
This all began because I was answering a question on replenishment at the same time as other orders and then suggested moving all logistics into orbit. The subsequent discussion went from that point because we needed a reason to keep ships in space. That reason then sparked a series of different consequences. So how about this instead:
1) We have technobabble that states ships can't land on planets, so logistics is generally in orbit (fuelling, cargo transfer, maintenance modules, etc). This will make non-planet based logistics much easier and will makes orbital space and the early game more interesting
2) if a planet exists, the logistics facilities will draw on its resources, otherwise they will use their own.
3) If orbital facilities don't exist, ships can mount 'shuttle bays' that allow slower interaction with the planet.
4) If ships can't land on planets then, under the current technobabble, there are lots of potential consequences around fighters and missiles not being able to move from surface to orbit (and vice versa), with subsequent impact on PDC hangars, ground-based weapons, etc.. Instead, we could change the currently proposed technobabble by saying that turbulence in the fluidic Aether near gravity wells is proportional to the mass of the object moving through the Aether. Once that mass exceeds 500 tons, there is a serious chance of damage to a vessel.
Now we actually have a reason for the previously arbitrary limit of 500 tons on fighters and all the complexities around fighters and missiles go away. It becomes very similar to the current game, except that we have logistics in orbit. How does that sound?
OK, I've read back though and we are getting quite complex :) I still like some of the proposed changes though so lets go back to a simpler version.
This all began because I was answering a question on replenishment at the same time as other orders and then suggested moving all logistics into orbit. The subsequent discussion went from that point because we needed a reason to keep ships in space. That reason then sparked a series of different consequences. So how about this instead:
1) We have technobabble that states ships can't land on planets, so logistics is generally in orbit (fuelling, cargo transfer, maintenance modules, etc). This will make non-planet based logistics much easier and will makes orbital space and the early game more interesting
2) if a planet exists, the logistics facilities will draw on its resources, otherwise they will use their own.
3) If orbital facilities don't exist, ships can mount 'shuttle bays' that allow slower interaction with the planet.
4) If ships can't land on planets then, under the current technobabble, there are lots of potential consequences around fighters and missiles not being able to move from surface to orbit (and vice versa), with subsequent impact on PDC hangars, ground-based weapons, etc. . Instead, we could change the currently proposed technobabble by saying that turbulence in the fluidic Aether near gravity wells is proportional to the mass of the object moving through the Aether. Once that mass exceeds 500 tons, there is a serious chance of damage to a vessel.
Now we actually have a reason for the previously arbitrary limit of 500 tons on fighters and all the complexities around fighters and missiles go away. It becomes very similar to the current game, except that we have logistics in orbit. How does that sound?
It sounds good overall, except for one nit. Currently, you can put vessels larger than 500 tons in PDC hangars. I've built PDC bases for my strategic strike command, based around FACs, and toyed with PDC 'dry docks' for ship repair.Yes... but isn't that really a bit of an exploit? I mean, I can see the possibility of large PDC hangars on asteroids say, or small moons. That seems kind of realistic. But if we're talking about parking a 20kT warship designed mainly for zero-G in an underground hangar in Arizona...
OK, I've read back though and we are getting quite complex :) I still like some of the proposed changes though so lets go back to a simpler version.That seems like a very sensible compromise. And great to have a justification for the 500 ton limit! Really excited about the thought of capturing and re-capturing huge orbital stations. Especially if you can make NPR default to boarding as well instead of just blowing them up.
This all began because I was answering a question on replenishment at the same time as other orders and then suggested moving all logistics into orbit. The subsequent discussion went from that point because we needed a reason to keep ships in space. That reason then sparked a series of different consequences. So how about this instead:
1) We have technobabble that states ships can't land on planets, so logistics is generally in orbit (fuelling, cargo transfer, maintenance modules, etc). This will make non-planet based logistics much easier and will makes orbital space and the early game more interesting
2) if a planet exists, the logistics facilities will draw on its resources, otherwise they will use their own.
3) If orbital facilities don't exist, ships can mount 'shuttle bays' that allow slower interaction with the planet.
4) If ships can't land on planets then, under the current technobabble, there are lots of potential consequences around fighters and missiles not being able to move from surface to orbit (and vice versa), with subsequent impact on PDC hangars, ground-based weapons, etc.. Instead, we could change the currently proposed technobabble by saying that turbulence in the fluidic Aether near gravity wells is proportional to the mass of the object moving through the Aether. Once that mass exceeds 500 tons, there is a serious chance of damage to a vessel.
Now we actually have a reason for the previously arbitrary limit of 500 tons on fighters and all the complexities around fighters and missiles go away. It becomes very similar to the current game, except that we have logistics in orbit. How does that sound?
It sounds good overall, except for one nit. Currently, you can put vessels larger than 500 tons in PDC hangars. I've built PDC bases for my strategic strike command, based around FACs, and toyed with PDC 'dry docks' for ship repair.
Well, why don't we just factor in the gravity of the body in question when considering what we're trying to do? It's kind of ridiculous to treat a super-earth with 3g the same way as a 10-km asteroid with 0.00005g. Why not just impose a upper gravity limit on where you can use PDC hangars and restrict them to small bodes with microgravity that doesn't disrupt the aether enough to disable engines? You can still have your giant PDC hangers, you're just going to have to build them into asteroids instead of on earthlike planets.
Well, why don't we just factor in the gravity of the body in question when considering what we're trying to do? It's kind of ridiculous to treat a super-earth with 3g the same way as a 10-km asteroid with 0.00005g. Why not just impose a upper gravity limit on where you can use PDC hangars and restrict them to small bodes with microgravity that doesn't disrupt the aether enough to disable engines? You can still have your giant PDC hangers, you're just going to have to build them into asteroids instead of on earthlike planets.
Just for simplicity. It would be extra work without extra game play if players had to know the tonnage limit for every different system body. The same applies to terraforming (at the moment anyway) with the size of the body not affecting the amount of atmosphere required.
Yes... but isn't that really a bit of an exploit? I mean, I can see the possibility of large PDC hangars on asteroids say, or small moons. That seems kind of realistic. But if we're talking about parking a 20kT warship designed mainly for zero-G in an underground hangar in Arizona...Agreed. I was pointing out that things which are currently possible (and the ultimate in exploits here is the use of PDCs to 'mothball' ships, payoff being 3-10 years depending on tech) would be inconsistent with the new technobabble, not advocating that they be kept.
Just because we can do something in the current version doesn't mean we should be able to do it.
This would be interesting to do for shuttles/ lift capacity too, so with ×2 gravity you need twice as many shuttles ( they each manage half the cargo to orbit. )The math doesn't really work that way. It's a lot more complicated, depending on the nature of your launch system. I'd suspect that the infrastructure is going to dominate in most of Aurora, not the physical payload of the shuttles themselves.
There is also the question of how orbital to surface combat is handled. If TN beam weapons function normally in a gravity well then perhaps the current restrictions on beam weapons in atmosphere are removed, or lessened, and the combat becomes between PDCs and orbital warships, with the PDCs benefiting from better armour and perhaps more powerful beam weapons. If that is true, then there needs to be some reason that orbital warships can't simply wipe out ground forces.
Make it a simple cut-off point then; for example, on a system body with more than 0.01g, you can't dock anything bigger than fighters/FAC into PDCs?
Just for simplicity. It would be extra work without extra game play if players had to know the tonnage limit for every different system body. The same applies to terraforming (at the moment anyway) with the size of the body not affecting the amount of atmosphere required.
The math doesn't really work that way. It's a lot more complicated, depending on the nature of your launch system. I'd suspect that the infrastructure is going to dominate in most of Aurora, not the physical payload of the shuttles themselves.
OK, I've read back though and we are getting quite complex :)
4) If ships can't land on planets then, under the current technobabble, there are lots of potential consequences around fighters and missiles not being able to move from surface to orbit (and vice versa), with subsequent impact on PDC hangars, ground-based weapons, etc.. Instead, we could change the currently proposed technobabble by saying that turbulence in the fluidic Aether near gravity wells is proportional to the mass of the object moving through the Aether. Once that mass exceeds 500 tons, there is a serious chance of damage to a vessel.
Now we actually have a reason for the previously arbitrary limit of 500 tons on fighters and all the complexities around fighters and missiles go away. It becomes very similar to the current game, except that we have logistics in orbit. How does that sound?
<snipped for legibility>
OK, I've read back though and we are getting quite complex :) I still like some of the proposed changes though so lets go back to a simpler version.
This all began because I was answering a question on replenishment at the same time as other orders and then suggested moving all logistics into orbit. The subsequent discussion went from that point because we needed a reason to keep ships in space. That reason then sparked a series of different consequences. So how about this instead:
1) We have technobabble that states ships can't land on planets, so logistics is generally in orbit (fuelling, cargo transfer, maintenance modules, etc). This will make non-planet based logistics much easier and will makes orbital space and the early game more interesting
2) if a planet exists, the logistics facilities will draw on its resources, otherwise they will use their own.
3) If orbital facilities don't exist, ships can mount 'shuttle bays' that allow slower interaction with the planet.
4) If ships can't land on planets then, under the current technobabble, there are lots of potential consequences around fighters and missiles not being able to move from surface to orbit (and vice versa), with subsequent impact on PDC hangars, ground-based weapons, etc. . Instead, we could change the currently proposed technobabble by saying that turbulence in the fluidic Aether near gravity wells is proportional to the mass of the object moving through the Aether. Once that mass exceeds 500 tons, there is a serious chance of damage to a vessel.
Now we actually have a reason for the previously arbitrary limit of 500 tons on fighters and all the complexities around fighters and missiles go away. It becomes very similar to the current game, except that we have logistics in orbit. How does that sound?
When they came for my planetary shipyards I said nothing, because I wasn't a shipyard worker. . .
I am a bit late to the party, but there is no reason to remove hangars from PDCs and they should absolutely NOT be removed. If you don't like them fine, don't use them, but don't snatch the option from those of us who like using them.
From my point of view, we have Mass drivers which can launch and recover huge masses of matter from space, I always just fluff that the same equipment is used to launch and recover TN ships and is built into hangars on PDCs to accommodate ships at least as large as the base can hold.
The TN ship drops into a gravity well and the base catches it and brings it safely into berthing, then when the ship is set to depart it is launched back into space, and once its free of the gravity well all its TN wizardry reactivates.
The same can easily apply for missiles and fighters to be flung into orbit where their TN properties become active.
As I said at the start, if you don't like it, or can't make it work in your own head, don't use it. Simple as that, the rest of us will think of ways for our universes to make it work within the existing technobabel.
Edit: as for shipyards and their crews. I always figured they were completely automated, which is why it took so long to retool the darned things to make a new kind of ship rather than just having them being able to build ships up to X size in whatever berth was available.
If your universe is allergic to automation (Something Aurora annoyingly is when it comes to ships already, my ships shouldn't NEED crew with the right components dangit! xD) then we already have telecommute robotics today. the workers sit on the ground and use VR to control machine in orbit to do the manufacturing. There, they are crewed, but the crew never has to leave the surface of their world or take their spouse and 2. 5 kids and dogs to space with them.
Ideally, we would have mods for this sort of thing (I think I remember hearing that C# Aurora would be moddable, but I'm too lazy to search and could very easily be wrong)
A compromise would perhaps be that we could have maintenance bonuses for any planet that had enough mass driver capacity to "catch" the ships you wanted to maintain. Heck, maybe even a tractor beam facility or component that worked the same way as Mass Drivers, but applied to ships (perhaps Mass Drivers aren't delicate enough to handle these ships?)
Bleh, I do not like that ships have to stop to refuel even with a tanker. The explanation that TN ships are more "wet fleet like" doesn't make much sense to me an even if it did would not be enough of a justification for this. Underway refueling is a thing. It's especially disheartening making logistics more complicated when you know the AI doesn't have to worry about it at all...Did you miss the bit where there's a special unrep tech? I'd say that's reasonably realistic, as doing unrep IRL is very complicated and took a lot of work to make happen the way it does now. Your dedicated sub-fleet will work just fine.
I was hoping to make it so I had a dedicated sub-fleet with repair/ordinance/fuel ships which would allow fleets to operate far past their normal range. They'd slow them down a lot, but they would be dropped off before jumping to a sector with hostiles.
Bleh, I do not like that ships have to stop to refuel even with a tanker. The explanation that TN ships are more "wet fleet like" doesn't make much sense to me an even if it did would not be enough of a justification for this. Underway refueling is a thing. It's especially disheartening making logistics more complicated when you know the AI doesn't have to worry about it at all...Think of TN engines creating a wave of space behind them pushing them forward (like an Alcubierre drive). This makes seeing ships in space flying like a wet navy easier as the engines move a ship linearly with engine power (generalization of the speed formula).
I was hoping to make it so I had a dedicated sub-fleet with repair/ordinance/fuel ships which would allow fleets to operate far past their normal range. They'd slow them down a lot, but they would be dropped off before jumping to a sector with hostiles.That is still possible in the C# version, but with tech directly correlating with how many support ships in the sub-fleet you would need.
Think of TN engines creating a wave of space behind them pushing them forward (like an Alcubierre drive).Why? They don't work on the same principles at all. Plus we can have hundreds of ships in the same task group, close enough together to appear as a single blip on the map, without them interfering with each other, and have fighters land and take off carriers without problems.
I really think the refueling change is problematic.I'd have said the current system is more problematic- that you are encouraged to design fleets of warships with virtually no fuel tanks, followed everywhere they go by a tanker fleet. If people are encouraged to put a sensible amount of fuel onto their warships I don't think that will be a bad thing. And surely your 30% larger warships have many other hidden costs of an equally powerful but smaller warship- not least that you need 30% larger shipyards?
It's already my preference to build most ships fuel-efficient, aiming at 55% engine tonnage or so (and consequently low-power engines for most designs).
The ships are a third bigger than they need to be, but not really more expensive for all but the fastest designs (which benefit greatly from fuel savings, well worth a modest build cost increase).
The slower assets could easily carry enough fuel to last for their whole service life. The main reason they don't is that it's more efficient to offload things into overhead-free commercial hulls... but that falls apart if we introduce overhead in refueling systems (even if the components are cheap, there are going to be associated research costs).
The rewards to build your fleet so you can pretty much ignore fuel will become significant, now there's a major operational benefit in addition to the economic one.
I already voiced similar concerns for the MSP side of things.Off-Topic: show
Aim: Increase the depth of logistics. End: Encourage playing around logistics.
Generally I don't have tankers following my fleets around. Predominantly since they tend to get blown to hell with substantial percentages of my strategic fuel reserves aboard.I guess it does depend on how closely I mean follow! And also how big and how armored your tankers are. I've certainly had armored tankers mixed in with missile cruisers squadrons before, although I might leave them behind with the jump tender during a battle.
e: Unless you mean having tankers in the general viscinity, in which case yeah I do that all the time.
Would support the idea of seeing parking a ship in a hangar as cheating in terms of maintenance. Maybe parking a ship there offers a maintenance reduction to 1/4th (or a fitting reduction value) from which the ship can be unmothed. Also there would be no crew onboard during that time (at least when parked in a PDC), so any previously gained experience would go back into the personell pool. If you unmoth the ship you have to train the crew again from the beginning on - giving a good reason NOT to mothball everything.Fighters shouldn't lose training or crew, though.
Build things with an eye towards fuel efficiency, so we don't need refueling during a mission (fast ships) or ever (slow ships).A classic situation of conflicting viewpoints- why should I need to refuel during a mission? During a campaign, sure, but why during a mission? Modern naval warships have a range in the thousands of miles, so they can complete most short term "go and destroy something and return home" missions, at least in their neighborhood, and would only need to refuel for something like a picket, or multiple missions strung together. So in Aurora why shouldn't my cruisers be able to jump into a system, go destroy a planet and return to their home system without refueling? But then again, how many systems should I be able to transit through without needing a fuel tanker?
If we just want high tactical speed - solve the fuel problem with carriers (possibly commercial in the future) or tugs.I agree, but what about the people who don't want to solve fuel/maintenance problems but want to have a cool star destroyer that is so big it can fit corvettes in it? Giant alien motherships are a staple of sf...
Refueling and maintenance situation is ok-ish at the moment, but any significant inconvenience/cost increase may favour playing around the system. Fuel is pushing it already (I find it best to invest very little RP/BP in fuel logistics and limit fuel use by design concessions).I'd say you're not playing around the system in that case, you're playing with it, by taking an efficiency hit to make your life easier. I guess the question is, would you be against Steve introducing a new expensive and slow engine with infinite endurance (call it a "zero point fusion drive")? That would allow people to entirely by-pass fuel logistics but at a very upfront cost to their ships? I'd be cool with that, let people play the game as they fant to play the game, but keep things balanced, so the zero-point engine would have to be expensive and slow compared with the conventional engine alternative.
Fighters shouldn't lose training or crew, though.Good idea, deciding what type of hangar it is. Maybe two different types of hangar space - one which works like it does right now (except doing a medium amount of maintenance) so crews stay on it and will be up to speed - and another type which is a mothballing hangar which removes crew entirely and uses only a little maintenance.
Maybe FACs too.
Maybe a little box to check, decide if the ship is mothballed and sits there, useless, not costing too much or if it's ready to go at any time, and costing much more.
2) Could you elaborate where you see the problem? Those star destroyers seem fine now, and in the next version as far as I can tell.Oh, I thought you saw a problem and were calling for a change in hangars to prevent folks abusing the fuel/maintenance system? If not, my bad.
Good idea, deciding what type of hangar it is. Maybe two different types of hangar space - one which works like it does right now (except doing a medium amount of maintenance) so crews stay on it and will be up to speed - and another type which is a mothballing hangar which removes crew entirely and uses only a little maintenance.
Refueling and maintenance situation is ok-ish at the moment, but any significant inconvenience/cost increase may favour playing around the system. Fuel is pushing it already (I find it best to invest very little RP/BP in fuel logistics and limit fuel use by design concessions).I disagree. Designers of single-player games should not waste any time on how to combat player exploitation of the system, aside from ensuring basic mechanical robustness of it. There will always be exploits available and sooner or later someone will post an Excel sheet that allows everyone to min/max their ships to their hearts content. Aurora currently supports multiple different playstyles, which is something I value highly. To me, it doesn't matter if they are equally balanced or not. Furthermore, the tolerance point for micro-management is different for every player and can change even with the same player depending on his mood. So unless Steve pushes a system to levels of obsessive-compulsive behaviour - which is unlikely - there is no need to worry about whether people play around the system or not. Hell, everybody who has been playing Aurora for a while knows that missiles are clearly better, yet most of us keep building beams as well.
I have wanted the ability to mothball my ships forever. Ideally mothballing should be done in space, remove all the crew, fuel and munitions and let it sit there, in complete vacuum there should be 0 maintenance needed. Things wont corrode without atmosphere, and things wont break down if they arent being used and thus no maintenance is needed.
@ Garfunkel: To me, it's a success when you can min/max to your heart's content and find that there are reasonable trade-offs to be had rather than a clearly preferable approach.
Aurora is surprisingly good at this.
Btw, I have played Aurora for a while and don't know that missiles are clearly better. Getting the job done without expending ammunition is preferable if possible, so at least for low-intensity conflicts beams are attractive. And for one big battle... missiles would struggle against something consisting mostly of base-tech beams (ideally railguns for some measure of PD) and very low-power engines: the target is literally cheaper than the ordnance necessary to destroy it. Made worse by concerns of overkill v. point defence.
Spoilers are known, functional NPR designs are unlikely to take extreme forms that would warrant metagaming, so it's easy to fall back on a missile doctrines that's known to work... but the mechanics certainly don't support unqualified superiority of missiles. And it'd be a sad thing if they did.
Currently, there is a way to "mothball" a ship. You simply scrap the entire ship and store the parts. When time comes, you can rebuild the ship in 1-2 months, as long as your ship isn't made entirely out of armor.Mothballing was in the game circa v2 to v3. Steve pulled it out for reasons. It's buried in the Mechanics folder most likely.
That being said, I don't oppose to a mothball option in the future. Maybe add an extra 5 days wait time to reactivate the ship to account for the time to gather new crews and do boot up/system check stuff.
Mothballing was in the game circa v2 to v3. Steve pulled it out for reasons. It's buried in the Mechanics folder most likely.
Btw, I have played Aurora for a while and don't know that missiles are clearly better.Strategically they aren't. Tactically they are. It is entirely doable and fairly easy, to create missile swarms that neither spoilers nor NPRs can defend against. That's the sort of thing I mean. I certainly see the appeal in min/maxing and there is nothing wrong with it, I certainly do it every now and then. Just that Steve has a limited time available for Aurora development and I wouldn't wish him to "waste" that time in trying to find ultimate balance between various systems and playstyles, or combat exploits.
I'm interested in why people are so bothered about mothballing? What's the big attraction vs just parking them around your home planet? Is is just to save some money/minerals on maintenance?Yeah, mothballing is both a viable thing in the real world and is occasionally used as a dramatic thing in SF - can your active fleet buy you time enough so that you can bring out all those mothballed ships?
I think that your money/debt and monthly expenditure/profit should be displayed front and center and not be buried beneath menus. I didn't even knowmoney was a thing until a few hours in my second game...Huh, there's a whole "Wealth/Trade" tab in the Population and Production/F2 window, in the title of which you also see your current racial wealth and change from last turn.
Huh, there's a whole "Wealth/Trade" tab in the Population and Production/F2 window, in the title of which you also see your current racial wealth and change from last turn.
I'm interested in why people are so bothered about mothballing? What's the big attraction vs just parking them around your home planet? Is is just to save some money/minerals on maintenance?
My God man!! Your memory is incredible! Do you realize how long ago that was?
I'm interested in why people are so bothered about mothballing? What's the big attraction vs just parking them around your home planet? Is is just to save some money/minerals on maintenance?
Because systems that are not being used in space can be kept in vacuum and shouldn't randomly implode just because they were built x number of days/months/years ago. You can leave a ship in a stable orbit around the homeworld theoretically for decades without any real breakdowns because there is nothing TO break the stuff down, then bring the ships back up to operation in a couple of days or weeks by re pressurizing them and rearming/fueling them.Yes, I can see why you could mothball (although I have seen other arguments against as well), I'm more interested in why you want to mothball. In game terms you save a little bit on maintenance costs, but I've never found them crippling compared with research/industry/ship building anyway. Maybe my games just haven't got big enough for mothballing to seem necessary?
Yes, I can see why you could mothball (although I have seen other arguments against as well), I'm more interested in why you want to mothball. In game terms you save a little bit on maintenance costs, but I've never found them crippling compared with research/industry/ship building anyway. Maybe my games just haven't got big enough for mothballing to seem necessary?Yah, you really need to mothball as you get bigger/more ships at later techs. You can be paying tens of thousands to hundreds of thousands annually if you don't mothball ships.
Yah, you really need to mothball as you get bigger/more ships at later techs. You can be paying tens of thousands to hundreds of thousands annually if you don't mothball ships.
"Salvage Nearest Wreck" is already a thing.
You pay 5% of the build cost in maintenance per year (6.25% in the next version), so over 20 (16) years accumulated maintenance costs are equal to initial build cost.I ran numbers on this, and the payoff appears to be 3-10 years, depending on how expensive your ships are. More expensive ships per unit size mean faster payoff.
For expensive (for their size) ships, building hangar PDCs may make sense. This makes sense in particular for ships that were considered fast in their prime:
A battlecruiser 3 engine generations out of date may be thoroughly obsolete, but still able to make a meaningful contribution and keep up with the current battle line.
By current standards, its running costs are exorbitant compared to its capability though. Useful to take out of mothball if available and we expected a major battle, but not something we'd like to keep around all the time... without hangar PDCs, we'd have scrapped it long ago and built something else instead.
While totally cost-free mothballing may be a bit much, I like how the Great Old Ones can return to active service when there is a need.
I see sugestions are being presented here so I´ll dare to do so too.
I have a problem with crew training. When build new ship models I have to train new crews from cero (from scraped ships), I understand the ships are new and crew need to re-train, but their previous experience should still have some value. Maybe crews could be separate entities that persist and have a performance acording to their training in their original ship, if they change ships they get a penalty and if they man a ship that needs more crew, they get a bigger penalty based on the amount of novice personel needed to fully man the ship.
Maybe there can be a simpler solution. Hopefully the problem is important enough to get some atention.
Congratulations for the advance and thanks for a great game.
I would like to see spinal railgunsSteve has gone on record saying he likes the idea of more spinal type weapons but just hasn't gotten around to it.
or even better more customizable beam weapons that don't rely on tech for size.It is a very difficult things to make changes to weapons in VB (Steve has said this somewhere). However Steve has said it is much easier to add weapons in C#, so he may do this eventually. You should have put this in the suggestion thread as this is a feature request not discussing an already decided change.
They should be more like radars where the bigger you make the caliber, heatsink, and barrel the heavier the weapon becomes with tech making more powerful smaller beam weapons viable.
Or at least give us a way to give them the x2, x4, x.5 modifier,
I want my UNSC ships.So do I, but you can make do with current mechanics (I've done it before).
You pay 5% of the build cost in maintenance per year (6. 25% in the next version), so over 20 (16) years accumulated maintenance costs are equal to initial build cost.
For expensive (for their size) ships, building hangar PDCs may make sense. This makes sense in particular for ships that were considered fast in their prime:
Is there going to be a "united Earth" theme for peoples names where it is just the regular earth names from the other themes are bundled together? The Terran Federation naming theme is very strange and seems too Western.You can always create your own theme if you have the patience and ideas for names.
1) A, B have full tanks and C and D are empty.By what I see, 2 is the preferred and the expected as I thought the refueling priorities would put the lowest fuel % first. So it would alternate fueling en-route between A and B for a week total, and C and D the another week total.
2) A-D all have (roughly) half-empty tanks.
Obviously #1 is the preferred (and realistic) behavior. Reading the new rules post, it seems like we'll end up with #2. Is there a way to avoid this?
By what I see, 2 is the preferred and the expected as I thought the refueling priorities would put the lowest fuel % first. So it would alternate fueling en-route between A and B for a week total, and C and D the another week total.
On new refueling post:
Let's say I've got 4 ships (A, B, C, D) in a fleet, along with tanker T. T has enough refuel rate to refuel only two of the four while the fleet is moving. The refuel priority is set to A,B,C,D. Let's say it takes one week for any one of A-D to run their tanks dry without refueling, and that T has effectively unlimited fuel (i.e. plenty for the timescales we're talking about).
Now I give the fleet an order to move to a location that's two week's travel time away. What happens after one week (without any micromanagement of refueling priorities)? I see two possible behaviors:
1) A, B have full tanks and C and D are empty.
2) A-D all have (roughly) half-empty tanks.
Obviously #1 is the preferred (and realistic) behavior. Reading the new rules post, it seems like we'll end up with #2. Is there a way to avoid this?
Thanks,
John
You can put A, B and the tanker into a sub-fleet and only they will be refuelled (if you set tanker status to refuel sub-fleet)I'm reasonably sure he got his #1 and #2 mixed up there. At the very least, if it had been my post, I would have written it with them swapped.
No suggestion thread, but configurable color schemes would be nice :)
Yep, that white-on-blue scheme is great for system/galactic maps, but having it everywhere (especially on big lists) looks quite tiring for the eyes :/
You can put A, B and the tanker into a sub-fleet and only they will be refuelled (if you set tanker status to refuel sub-fleet)
But can you prevent individual ships from running dry before all of the fleet runs dry when the tanker (with enough fuel ) lack transfer speed to transfer fuel to all ships and there are classes with different priority present?Isn't that the point of the change? To make it harder to extend the range of a fleet of ships with inadequate fuel tanks just by bunging in a tanker? Presumably if you set all refueling priorities the same then the ships with the lowest fuel will always get priority? And if you don't have enough transfer speed then you need more, smaller, tankers etc.
It seems it would be quite micro intensive to be forced to either swap around ships into sub-fleets and back, or take frequent pauses to maximize the range of any given fleet with tanker where fuel transfer speed is the constraint?
Basically something similar to the "equalize fuel" function that ensures ships with lower fuel % get priority refueling.
Presumably if you set all refueling priorities the same then the ships with the lowest fuel will always get priority?
Yeah, that's what I want to know, and it's not clear.You need additional tankers or design the tanker with a larger capability to support a larger number of ships. This makes it so it may be more economical to build a multitude of "smaller" tankers (still pretty big) and divide them up for different task groups than it is now to build a giant fleet tanker that can support everyone.
I want the games logistical challenges to be due to lack of ship and tech capabilities, not due to lack of me wanting to micromanage stuff :P
You need additional tankers or design the tanker with a larger capability to support a larger number of ships. This makes it so it may be more economical to build a multitude of "smaller" tankers (still pretty big) and divide them up for different task groups than it is now to build a giant fleet tanker that can support everyone.
Sure. But why should the game artificially make having to little fuel transfer speed worse then it has to be by having some ships fuel run out down to 0% while your tankers focus on keeping other ships topped up at 100%fuel ???Assume that the tanker can move fuel at the same rate as fuel is used and the tanker only has 2 "boom arms" to refuel ships with, and there there are 4 ships other than the tanker that needs fuel. Logic dictates that it can keep the 2 ships topped off while the other two are using fuel. When fuel starts to get low on the other two, logic dictates for the fleet to stop and fuel up the other two to full then continuing on. This whole discussion seems to be under the assumption that the ships are being chased and if they slow don they will blow up.
It makes no sense...
Sure. But why should the game artificially make having to little fuel transfer speed worse then it has to be by having some ships fuel run out down to 0% while your tankers focus on keeping other ships topped up at 100%fuel ???Steve's changes list seems to make things pretty clear-
It makes no sense...
Assume that the tanker can move fuel at the same rate as fuel is used and the tanker only has 2 "boom arms" to refuel ships with, and there there are 4 ships other than the tanker that needs fuel. Logic dictates that it can keep the 2 ships topped off while the other two are using fuel. When fuel starts to get low on the other two, logic dictates for the fleet to stop and fuel up the other two to full then continuing on. This whole discussion seems to be under the assumption that the ships are being chased and if they slow don they will blow up.That's not generally how I'd want them to do things. Let's say I'm transferring ships A-D between locations that are 1.5x their range apart. If the tanker just fuels A and B, then you have to stop part of the way through and refuel C and D before continuing. If the tanker fuels all four equally, then you'll finish without having to stop, with 25% fuel in all four ships. Obviously, if you're going between places 2.5x apart, the time taken will be the same in both cases, either two stops to refuel 2 ships, or one stop to refuel all 4. I'm not sure of the balance between the two cases, but overall, I think I'd rather have the balanced refueling.
Steve's changes list seems to make things pretty clear-
"Each tanker class has a minimum fuel setting (in the class window) and will not refuel ships once it falls below that level. Each class & ship has a 'refuel priority', with higher numbers equalling higher priority. The tanker will refuel in descending order of ship priority, then by descending order of class priority. The tanker will automatically move to a second ship (or more) if there is sufficient time and fuel remaining in the sub-pulse."
Isn't this just the same mechanism as for commander assignment? ie, you can set everything as the same priority (with the lowest fueled ship refueled first) or you can get fancy and try to keep your battlecruisers topped up to full even if it means your carrieres run out of fuel and have to stop. Your choice.
Where in that statement do you think it's "pretty clear" that the "lowest fueled ships get refueled first" if they have same priority??
My take on it is that it could be implemented either way, which is why I'm trying to get a clarification. ::)
1) A, B have full tanks and C and D are empty.By what I see, 2 is the preferred and the expected as I thought the refueling priorities would put the lowest fuel % first. So it would alternate fueling en-route between A and B for a week total, and C and D the another week total.
2) A-D all have (roughly) half-empty tanks.
Obviously #1 is the preferred (and realistic) behavior. Reading the new rules post, it seems like we'll end up with #2. Is there a way to avoid this?
STEVE - Could I request another answer based on the correct wording that #2 is the desired behavior?
Yes, I should have made that clear. Order of fuelling is Ship Priority, then Class Priority, then lowest fuel percentage. So if all assigned priorities are equal, the ship with the least fuel will be refuelled first.
As this check is made once per sub-pulse, the tanker will keep everyone topped up equally unless the player assigns higher priorities.
Great! Thanks for the clarification.Well, if you have extremely fast smaller ships (corvettes or something like that) that you want to keep at 100% since you want them to break off from the fleet for some reason, then you would want to play with priorities. Also escorts; you would want to keep your shorter ranged military craft refueled to a higher % than a freighter that can get a hundred billion km at half tank.
Then I'll be able to just happily ignore ever setting any refueling priorities at all and tankers should default to my desired behavior of refueling the ship with lowest percentage always :)
Well, if you have extremely fast smaller ships (corvettes or something like that) that you want to keep at 100% since you want them to break off from the fleet for some reason, then you would want to play with priorities. Also escorts; you would want to keep your shorter ranged military craft refueled to a higher % than a freighter that can get a hundred billion km at half tank.Yes, as often with Aurora it sounds like a great compromise between general ease of use and complexity/depth when needed. Another possible use of priorities is for those sad occasions when things have gone bad. I may want to make sure my brand new carrier is more fully fueled than my ageing escort destroyers, just in case a stray missile/FAC takes out the tanker.
Well, if you have extremely fast smaller ships (corvettes or something like that) that you want to keep at 100% since you want them to break off from the fleet for some reason, then you would want to play with priorities. Also escorts; you would want to keep your shorter ranged military craft refueled to a higher % than a freighter that can get a hundred billion km at half tank.Yes, and I think the priority system will support that pretty well. The small, short-legged ships that basically are using the tanker as their drop tank have priority 1, the regular warships get priority 0, and the freighters get priority -1. If you really want to save your fuel for the warships, put the escorts in a separate subfleet from the freighters.
Well, if you have extremely fast smaller ships (corvettes or something like that) that you want to keep at 100% since you want them to break off from the fleet for some reason, then you would want to play with priorities. Also escorts; you would want to keep your shorter ranged military craft refueled to a higher % than a freighter that can get a hundred billion km at half tank.
I'm thinking about intra-system jump. My idea is mainly from Freespace2 and its mod Blue planet, but also from "emergency FTL" in Stellaris.
Blue planet walkthrough: https://www.youtube.com/playlist?list=PLC89WYnIXtfVb-8Avd7LAgX21tTRMKmz2 (https://www.youtube.com/playlist?list=PLC89WYnIXtfVb-8Avd7LAgX21tTRMKmz2)
A case of tactical jump: 12:50, https://www.youtube.com/watch?v=ge0mcoREdi8&list=PLC89WYnIXtfVb-8Avd7LAgX21tTRMKmz2&index=7 (https://www.youtube.com/watch?v=ge0mcoREdi8&list=PLC89WYnIXtfVb-8Avd7LAgX21tTRMKmz2&index=7)
Currently, battle scale is a bit too "large" as sufficiently advanced warship can hit other side of system with missile, and missile is tactically dominating battle (though it may have logistic problem). And at a certain tech level, sensor and missile range made it really hard to retreat and break contact from a losing battle, especially for NPR. Will intra-system jump be a solution?
However, TN engine mechanic may not handle this well. I'm not sure how to justify it.
I'm thinking about intra-system jump. My idea is mainly from Freespace2 and its mod Blue planet, but also from "emergency FTL" in Stellaris.THere used to be a hyperdrive, but it was removed due to reasons.
Currently, battle scale is a bit too "large" as sufficiently advanced warship can hit other side of system with missile, and missile is tactically dominating battle (though it may have logistic problem). And at a certain tech level, sensor and missile range made it really hard to retreat and break contact from a losing battle, especially for NPR. Will intra-system jump be a solution?The same could be said about modern naval warfare (and its history). We used to only be able to ram other ships and board, then we shot large "arrows", then cannons, then we upgraded the cannons to fire at longer ranges, then we increased there ranges tremendously again while also vastly improving their damage, then later on we got missiles (which could destroy a target from well beyond visible range), and lastly we now have the railgun which can fire a large shell without charges an extreme distance (and it is self guided). The whole point of advancing technologically is to outclass any previous technologies.
Regarding missile range: Scalingwith tech is interesting here.That's why you use multi-stage missiles. A low-speed booster, with fast penetration warhead(s) works really well since 6.0 came out.
Sensor range increases greatly if we advance a tech level across the board, because it's affected by two multiplicative lines.
Missile range doesn't increase very much, or even decreases if we make use of higher multiplier tech.
Early on, very long missile range is expensive in terms of sensors and fire control.
Later on, very long missile range is expensive in terms of missile performance.
I personally would love to see energy weapon ranges scale higher to be more competitive with missiles, even if it is only on things like spinal mounts.
Also while I am wishing it would be cool if things like railguns could be used against dirt side targets!
Energy weapons are capped by fire control range. So just increasing the weapon range on it's own will do almost nothing.There's also a simple logic to limiting it to a 5s period, based on targeting challenges. Take an Aurora ships with an inertia-free engines capable of 5000km/s speed. So in a 5s tick a ship could theoretically move to anywhere in a 25,000km diameter sphere. Even diverting 0.1% of engine power to evasive action gives a 25km diameter of sphere for the ship to sit in. I would therefore suggest that the game is actually far too generous about beam weapon to hit chances at maximum range. Now, if you had faster than light energy weapons that would be a different question.
I think it's also an issue with the speed of light at higher techs, since light can travel at most 300k km/s = 1.5m km per 5 second increment, and the game wants to have energy weapons hit within the same increment without traveling faster then the speed of light.
If energy weapon ranges and FC ranges would be drastically increased it could also mean PD weapons with long range become very OP, because they might get dozens of shots off against each missile instead of just 1-2.
There's also a simple logic to limiting it to a 5s period, based on targeting challenges. Take an Aurora ships with an inertia-free engines capable of 5000km/s speed. So in a 5s tick a ship could theoretically move to anywhere in a 25,000km diameter sphere. Even diverting 0.1% of engine power to evasive action gives a 25km diameter of sphere for the ship to sit in. I would therefore suggest that the game is actually far too generous about beam weapon to hit chances at maximum range. Now, if you had faster than light energy weapons that would be a different question.I agree with your math, but my interpretation is that this clearly proves that beam weapons already propagate at superluminal speeds somehow.
I agree with your math, but my interpretation is that this clearly proves that beam weapons already propagate at superluminal speeds somehow.Ha, yes, perhaps best not to probe too deeply on this one. Maybe the lasers fire through tiny jump gates?
Ha, yes, perhaps best not to probe too deeply on this one. Maybe the lasers fire through tiny jump gates?That's basically the only way the math works, yes. We already know that there's some superluminal propagation, which is used by the sensors. I'd assume that this is the mechanism behind beam weapons, too. It also neatly explains why projectile weapon damage falls off with range, which shouldn't really happen if the projectiles are in a vacuum.
"A Refuelling System is 500 tons and has a cost ranging from 10 BP to 100 BP, depending on the tech level."You could easily fit that to a FAC (1000 tons).
I just realized this means no more fighter tankers. Please make a fighter-sized Refuelling System (i.e. 50t transfering 1/10 of researched refueling rate) as well!! :/
You could easily fit that to a FAC (1000 tons).
No you can't "easily" fit a 500 ton system to a 1000 ton craft without significantly impacting it's performance and payload ::)
Good luck if you want it to keep up with your fighters ( that typically have 40% of their total tonnage as max power engines), and want to provide meaningful amounts of fuel as well...
^This is exactly the problem. 500 ton refueling system, 250ton fuel tank, that leaves only 25% room for engines and everything else.
No you can't "easily" fit a 500 ton system to a 1000 ton craft without significantly impacting it's performance and payload ::)I already fit 500 ton modules in FACs. Here;
Good luck if you want it to keep up with your fighters ( that typically have 40% of their total tonnage as max power engines), and want to provide meaningful amounts of fuel as well...
Corsair class Dropship 1 000 tons 12 Crew 235.8 BP TCS 20 TH 150 EM 0
10000 km/s Armour 1-8 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 0 PPV 0
Maint Life 0 Years MSP 0 AFR 200% IFR 2.8% 1YR 63 5YR 946 Max Repair 60 MSP
Intended Deployment Time: 1 months Spare Berths 3
Drop Capacity: 1 Battalion
Cameron-Gould 40-1 ICFD (5) Power 40 Fuel Use 336.02% Signature 30 Exp 20%
Fuel Capacity 180 000 Litres Range 9.6 billion km (11 days at full power)
This design is classed as a Military Vessel for maintenance purposes
Plenty of speed to keep up with fighters, replace the Drop Module with the refueling system, and you have a mobile fighter refueling point. My fighters typically only need 5,000-10,000 each, so this could extend the range of a squadron or two by a significant margin. It could use some specialized engines (one engine 5x bigger) that are not max power, but I just threw this together from my existing tech to prove a point. Personally I think you shouldn't be able to build a small thing that could keep a squadron going for a very long range, as that is the whole point of a carrier. The only reason you should be using one of these is to extend the range of a squadron by adding a refueling point. An example of how to use this would be to park this over an asteroid/moon/planet halfway to the target, and let the squadron refuel from it on their way to and from the carrier while making strike runs on an enemy.Or possibly to assist with delivery of fighters to the front line? But in my view the problem is that fighter tankers are a rather silly concept in the first place. People have got used to them, but that doesn't make them a good idea. Are there any real world or sci-fi examples? From a gameplay and balance perspective forcing people to move their carriers closer to the enemy seems like a good thing.
Or possibly to assist with delivery of fighters to the front line? But in my view the problem is that fighter tankers are a rather silly concept in the first place. People have got used to them, but that doesn't make them a good idea. Are there any real world or sci-fi examples? From a gameplay and balance perspective forcing people to move their carriers closer to the enemy seems like a good thing.Quite a few examples can be found. The best one for this topic is
Are there any real world or sci-fi examples?Yes, a multitude (https://en.wikipedia.org/wiki/List_of_tanker_aircraft).
From a gameplay and balance perspective forcing people to move their carriers closer to the enemy seems like a good thing.Well that is debatable. There are reasons you would use small refueling ships in order to boost the range of sortie without moving you carrier closer. But you would need to send the mission of the tanker first, risking that to enemy detection while it is on the way.
Quite a few examples can be found. Many of these seem to have been replaced by buddy fueling in modern carrier based strikefighters.You ninja.
Quite a few examples can be found. The best one for this topic isHa, as always on this forum I must bow to superior knowledge. I've only seen photos with big tankers refueling fighters, so appreciate the new knowledge, and withdraw my objection to a smaller fueling system.
https://en.m.wikipedia.org/wiki/Grumman_A-6_Intruder#KA-6D
And there are more listed here https://en.m.wikipedia.org/wiki/List_of_tanker_aircraft
Many of these seem to have been replaced by buddy fueling in modern carrier based strikefighters.
There are other reasons besides fighters to have a small refueling system. I'd want them to fit to my bigger ships, both so they can refuel escorts (the Iowa-class battleships were fitted with specialized equipment for this) and so that ships which lose all fuel tanks are not totally stranded until I can bring a tanker up.I can see the logic for that, but I'm not sure a fighter sized refueling system would be appropriate for that. If it was 50t say I'd be tempted to stick it on every ship I design, which seems to go against the spirit of Steve's changes. Is the real problem that 500t is too big for the basic refueling system. Perhaps 250t would be more appropriate? That would mean that large warships could justify taking a refueling system, but not frigates etc.
This also ignores another use of fighter-tankers, which is doing jobs too small to require a full tanker. I've found them incredibly helpful for new players who underestimate the fuel requirements of their fleet, because they don't take yards and can be built quickly. Even if the player is experienced, they can be useful for helping ships which get in trouble.That's a pretty neat thought, and one that never occurred to me.
I can see the logic for that, but I'm not sure a fighter sized refueling system would be appropriate for that. If it was 50t say I'd be tempted to stick it on every ship I design, which seems to go against the spirit of Steve's changes. Is the real problem that 500t is too big for the basic refueling system. Perhaps 250t would be more appropriate? That would mean that large warships could justify taking a refueling system, but not frigates etc.I want the 50t systems to make fighter tankers, and the secondary application for bigger warships is a bonus. They're supposed to be 1/10th the rate of the bigger systems, so a sufficiently big ship might get a full-sized refueling system. I'd like it if they stacked, but I can see why Steve might not do that.
That's a pretty neat thought, and one that never occurred to me.It took a while for me to figure out. I was helping a friend who had grossly under-speced his freighters, and after a couple of staging trips, the thought hit me.
It seems like you could just make the smaller ones much slower, that is to say slower than their relative size would suggest.
I disagree. I think it would generally be worth it to bring in a bigger refuelling system if you want to gas up a big warship, while also allowing you to have a much smaller system that could gas up tiny fighters within the same general timeframe.Umm... isn't that what carriers are for?
Or the 50 ton system could be fighter only, albeit higher tech level
Or the 50 ton system could be fighter only, albeit higher tech levelI'll second Zincat on this. I really, really don't like that sort of restriction on systems totally independent of logical justification. It smacks of special pleading.
I'll second Zincat on this. I really, really don't like that sort of restriction on systems totally independent of logical justification. It smacks of special pleading.Perhaps MarcAFK meant it can only refuel fighters? I think you could easily justify that, perhaps the 50t system doesn't have a long enough boom for larger ships? Or maybe just a different size of refueling nozzle. On that basis maybe the big 500t system shouldn't be able to refuel fighters either, they could either need a hanger or a specialized small craft refueling module.
Perhaps MarcAFK meant it can only refuel fighters? I think you could easily justify that, perhaps the 50t system doesn't have a long enough boom for larger ships? Or maybe just a different size of refueling nozzle. On that basis maybe the big 500t system shouldn't be able to refuel fighters either, they could either need a hanger or a specialized small craft refueling module.That makes slightly more sense, but I'm still opposed. A 50t module that has 10% (or even a bit less) of the delivery rate of the 500t one would add a fair number of options to the game which I would like to see.
I think people are forgetting that hangars would still refuel fighters a lot faster than a 50 ton "fighter refuel only" system.
but that you might often need a "range extender" for your fighters, for whatever reason (i.e. you don't want to risk your carriers, moving the entire fleet would cost too much fuel, you want to keep the bulk of your fleet somewhere else etc.), and a full fledged tanker might not be a good idea (far easier to spot).Have you ever heard of "light carriers" or "escort carriers" in sci-fi or irl? They are specifically made to be put forward of the main carriers to be a range extender without putting a lot of resources so far forward.
Have you ever heard of "light carriers" or "escort carriers" in sci-fi or irl? They are specifically made to be put forward of the main carriers to be a range extender without putting a lot of resources so far forward.Not in IRL. I don't know of a single case in which any carrier was used as a forward base for airplanes from other carriers. I'm not saying it absolutely never happened, but it's rare enough that it definitely wasn't standard. Light carriers are basically just smaller, cheaper (and, most importantly, faster-building) fleet carriers, while escort carriers were intended to serve as second-line carriers, initially to escort convoys, and later as providers of replacement aircraft and air support for amphibious landings.
Size and fuel requirements aren't necessarily that closely correlated.
I routinely build 10000t warships that can cruise for months on 0.2-1HS of fuel, that sort of thing will only become more attractive (albeit with a few more small tanks, to have some reserve and avoid complete loss of fuel from battle damage).
Have you ever heard of "light carriers" or "escort carriers" in sci-fi or irl? They are specifically made to be put forward of the main carriers to be a range extender without putting a lot of resources so far forward.
One of the Starfire books - In Death Ground have this. They used their carriers to cycle fighters from star base to replenish their life support systems and rearm them because they would not be able to reach hostile fleet on their own. But I think that it was one time thing.
I'll second Zincat on this. I really, really don't like that sort of restriction on systems totally independent of logical justification. It smacks of special pleading.
No it doesn't.
There is a reason you don't use this http://www.nmeda.com/wp-content/uploads/2012/01/gas-pump-regulations-for-people-with-disabilities.jpg to transfer fuel from one of these http://www.globalsecurity.org/military/systems/ship/images/tanker-lng-image101.jpg to this https://i.ytimg.com/vi/CXYSu1Rw394/maxresdefault.jpg
I like the current draft where refueling system is 500t. It's a good balance for such a critical system, I think.
I don't want something that is going to be stuck on every single ship just because it is small. 500t is perfect, you're not going to stick that on every ship. If it was 50t, you WOULD stick it on every ship.
No it doesn't.Yes. There are many, many reasons for that. First, we don't run on gasoline. (I'm a volunteer tour guide on the Iowa). We use DFM, which is a cousin of diesel, although we originally used bunker oil. The middle picture is a natural gas carrier, which has no unrep capabilities. The only ships powered by natural gas are LNG carriers, because they can use boil-off for fuel.
There is a reason you don't use this http://www.nmeda.com/wp-content/uploads/2012/01/gas-pump-regulations-for-people-with-disabilities.jpg to transfer fuel from one of these http://www.globalsecurity.org/military/systems/ship/images/tanker-lng-image101.jpg to this https://i.ytimg.com/vi/CXYSu1Rw394/maxresdefault.jpg
The USS Iowa actually have a fuel Endurance of between 42 and 6.5 days, so it could be kept topped up if constantly connected to a dedicated tanker with between 2 to 14 hoses depending on speed ( and assuming there was a tanker able to keep up with it! ).At the lower speeds, lots of tankers could. At high speed, the tanker would have to be a dinosaur-burning carrier.
As a matter of fact, having a warship in need of refueling, and no tanker available (i.e. because it was destroyed on the way or whatever), and absolutely no other way to refuel it is very bad. I actually believe all ships should be able to transfer fuel (albeit at a very slow rate) in case of emergency.I'd agree with this.
I mean, if a current navy carrier was stranded somewhere without fuel, for whatever reason, and there was only its escort (destroyers, whatever) available and no dedicated tankers in sight, i'm pretty sure they would find a way to refuel the carrier despite not having dedicated tanker equipment (even if it meant manually ferrying barrels around with boats).They have hoses for that contingency, IIRC. That said, current carriers are all nuclear-powered, and I can't see how one could end up stranded without fuel.
As a matter of fact, having a warship in need of refueling, and no tanker available (i.e. because it was destroyed on the way or whatever), and absolutely no other way to refuel it is very bad. I actually believe all ships should be able to transfer fuel (albeit at a very slow rate) in case of emergency.Thinking of the mechanics of such a system, presents a major weakpoint in warship design. If a warship could only take in fuel, it could be designed in a way for fuel to only flow in one direction (in), making the overall design safer from a lucky hit. However, one designed for fuel to flow in both directions is more complicated, more expensive, and creates a weakpoint.
I mean, if a current navy carrier was stranded somewhere without fuel, for whatever reason, and there was only its escort (destroyers, whatever) available and no dedicated tankers in sight, i'm pretty sure they would find a way to refuel the carrier despite not having dedicated tanker equipment (even if it meant manually ferrying barrels around with boats).Sure, lets give a floating city that runs off of nuclear reactors, with enough internal fuel to run 20 years, some fossil fuels to top it off.
Thinking of the mechanics of such a system, presents a major weakpoint in warship design. If a warship could only take in fuel, it could be designed in a way for fuel to only flow in one direction (in), making the overall design safer from a lucky hit. However, one designed for fuel to flow in both directions is more complicated, more expensive, and creates a weakpoint.That's not remotely how the systems are designed. You occasionally need to take fuel out in a way that does not involve burning it. For instance, if you need to do maintenance in a fuel tank. Or if you're going into dry dock, where they would rather not have the ship full of flammable things. Warship fuel systems are a lot more complicated than the one in your car.
Sure, lets give a floating city that runs off of nuclear reactors, with enough internal fuel to run 20 years, some fossil fuels to top it off.Let's assume that the carrier in question is an LHD. As I said, I believe they carry equipment for doing this kind of thing.
That's not remotely how the systems are designed. You occasionally need to take fuel out in a way that does not involve burning it. For instance, if you need to do maintenance in a fuel tank. Or if you're going into dry dock, where they would rather not have the ship full of flammable things. Warship fuel systems are a lot more complicated than the one in your car.Correct. However I was talking about something even more complicated that than current day warship fuel systems. First, we have to determine what state of matter refined Sorium is. Is it a gas, fluid, super-fluid, solid, plasma, or an other state we don't know about? Secondly, we have to think about the properties of TN material, such as it doesn't follow the laws of physics. Thirdly, we have to know whether or not refined Sorium can react with anything outside of the forced reactions to generate power/thrust.
Let's assume that the carrier in question is an LHD. As I said, I believe they carry equipment for doing this kind of thing.I don't equate Fleet-carriers/Supercarriers with Amphibious Assault Ships as a general basis. Yes, both are carriers. Yes they would have systems in place to transfer fuel. But, these are designed for fuel to flow in multiple directions on the basis that this is a carrier that serves as a base for an invasion assault. I know I am oversimplifying it, but I am not an expert of ship building or carrier operations.
Correct. However I was talking about something even more complicated that than current day warship fuel systems. First, we have to determine what state of matter refined Sorium is. Is it a gas, fluid, super-fluid, solid, plasma, or an other state we don't know about? Secondly, we have to think about the properties of TN material, such as it doesn't follow the laws of physics. Thirdly, we have to know whether or not refined Sorium can react with anything outside of the forced reactions to generate power/thrust.So? Steve has specifically said that refined Sorium is volatile, or at least more volatile than current naval fuels. If that's the case, they will have a way to pump it out so they can do things like work on the ship in the yard.
I don't equate Fleet-carriers/Supercarriers with Amphibious Assault Ships as a general basis. Yes, both are carriers. Yes they would have systems in place to transfer fuel. But, these are designed for fuel to flow in multiple directions on the basis that this is a carrier that serves as a base for an invasion assault. I know I am oversimplifying it, but I am not an expert of ship building or carrier operations.You missed his point. He was talking about destroyers refueling a modern carrier in an emergency. You objected that modern carriers are nuclear. I pointed out that this was probably a mistake on his part, and the scenario could be salvaged by assuming that the destroyers were transferring the fuel to an LHD. The 'they' in my statement (and I take responsibility for this being ambiguous) was all warships, destroyers or LHDs.
Ok, let us try to separate the two discussions here.Nobody's objecting to the theory that UNREP should take specialized equipment, and that the current model is overly simplistic. ryuga81 was suggesting that we allow stationary ships to very slowly transfer fuel, and I think a case can be made for that, although it's probably not worth it.
As a GAMER, I can understand how nice it would be to be able to just transfer fuel from any ship to any ship, have fuel transfering systems even on small ships and the like.
But since Aurora tries for pseudo-realism...
1) These ships are far more complex than we can imagine, since they are much more technologically advanced than us. These are not gasoline burning engines. Remember, to the caveman a simple phone would be "Incomprehensible magic". They are surely more complex than nuclear reactors, so I really HAVE to assume you can't just strap some tube between two ships and transfer some gasoline-equivalent fuel.
2) It would be one thing if we were talking of immobile ships in space. But here, we're talking of transfering fuel between two ships half-submerged into another dimension, moving at trans-newtonian speed in some sort of pseudo-dimensional bubble. And you want to connect them and transfer fuel. Once again, I have to suppose that this require some exceptionally sturdy and specialized equipment. And most assuredly, not throwing barrels of fuel from one ship to another at trans-newtonian speed...
That aside, I think the point is rather moot. I will say it again, it seems to me that Steve wants to create an additional, logistical layer for the game. One where you have to deploy tankers and refueling stations across your territory and defend them, for example. If every ship could just transfer fuel, then all of that would be pointless. And Steve would have not coded this change.
was talking about destroyers refueling a modern carrier in an emergency. You objected that modern carriers are nuclear. I pointed out that this was probably a mistake on his part, and the
The US Navy isn't the only navy with Carriers, and if memory serves, only the US, French and Chinese have Nuclear carriersOnly the US and French, actually Liaoning is a dino-burner, and I expect the first batch of successors to be, too.
Ok, let us try to separate the two discussions here.This raises an important point, there is an order of magnitude more complexity with underway refuelling, which steve's dedicated refuelling modules can accomplish and I think rightly so they are limited to certain module sizes, something you can't just cram into every ship.
As a GAMER, I can understand how nice it would be to be able to just transfer fuel from any ship to any ship, have fuel transfering systems even on small ships and the like.
But since Aurora tries for pseudo-realism...
1) These ships are far more complex than we can imagine, since they are much more technologically advanced than us. These are not gasoline burning engines. Remember, to the caveman a simple phone would be "Incomprehensible magic". They are surely more complex than nuclear reactors, so I really HAVE to assume you can't just strap some tube between two ships and transfer some gasoline-equivalent fuel.
2) It would be one thing if we were talking of immobile ships in space. But here, we're talking of transfering fuel between two ships half-submerged into another dimension, moving at trans-newtonian speed in some sort of pseudo-dimensional bubble. And you want to connect them and transfer fuel. Once again, I have to suppose that this require some exceptionally sturdy and specialized equipment. And most assuredly, not throwing barrels of fuel from one ship to another at trans-newtonian speed...
That aside, I think the point is rather moot. I will say it again, it seems to me that Steve wants to create an additional, logistical layer for the game. One where you have to deploy tankers and refueling stations across your territory and defend them, for example. If every ship could just transfer fuel, then all of that would be pointless. And Steve would have not coded this change.
Sure, lets give a floating city that runs off of nuclear reactors, with enough internal fuel to run 20 years, some fossil fuels to top it off.
ryuga81 was suggesting that we allow stationary ships to very slowly transfer fuel, and I think a case can be made for that, although it's probably not worth it.
I don't want to create a small (50 ton?) refuelling system as it would decrease the need for the type of planning and decision-making I am trying to create. However, even with a 500 ton refuelling system it would be possible to create relatively small tankers (1500 - 2000 tons perhaps) that could refuel fighters. More KC-135 than A-6. These small tankers wouldn't be useful for larger ships due to their capacity but they would serve to refuel long-range strikes while remaining hard to detect.I understand the logic, but I'm not sure that it would decrease the need for planning as much as you think. A 50t refueling system would be very slow, to the point that it would only be viable as an emergency system or to fuel fighters. And I have a hard time seeing why you couldn't build a smaller refueling system. Minimum gauge isn't going to come into play at this scale.
System Naming
In C# Aurora, you can optionally assign one of the new Naming Themes to a system. Any future exploration beyond that point will use the selected naming theme. This allows you to have different naming themes for different warp chains.
The order of name selection for new systems will therefore be:
1) Actual System Name (for known stars)
2) Next name for Naming Theme associated with the system from which the exploring ship originated (if a theme is set)
3) Next name for Racial System Theme
4) "System #" + System Number
You can still rename systems directly and will be able to use text, or select any name from any name theme.
Does this mean I can set a rule that all systems with no planets be named NX-<system number>?
The concept of in-flight refuelling is a little different. Aurora 'fighters' are not F-18s operating from the Nimitz, that can be refuelled by A-6 tankers. As they operate in the same medium as the carrier, they are more like small, missile-armed patrol boats. The existing ability to refuel these small craft in flight was more a side-effect of the abstract refuelling system than an intention to replicate tankers the size of tactical aircraft.
I don't want to create a small (50 ton?) refuelling system as it would decrease the need for the type of planning and decision-making I am trying to create.
There is no fundamental speed difference between ships and fighters.
We may have 5000km/s carriers with 30000km/s fighters... but at the same tech level we may well have full-size warships that go 30000km/s
I don't want to create a small (50 ton?) refuelling system as it would decrease the need for the type of planning and decision-making I am trying to create. However, even with a 500 ton refuelling system it would be possible to create relatively small tankers (1500 - 2000 tons perhaps) that could refuel fighters. More KC-135 than A-6. These small tankers wouldn't be useful for larger ships due to their capacity but they would serve to refuel long-range strikes while remaining hard to detect.
And what do you think about the idea of allowing some minimal emergency fuel transfer on ships without refuelling equipment?I don't like the idea, because if you are in that situation, then either something bad happened or you didn't plan ahead and were unprepared.
Nothing "fundamentally" is preventing you from building flying Carriers of 100'000 ton IRL that go just as fast as the F18s they carry either...
It's just that no one is going to do that because it's just as stupid as it would be to do in Aurora for reasons of fuel economy, range, design, cost, endurance, reliability and other tradeoffs that are pretty accurately modeled in the game...
Your example doesn't apply because nothing in Aurora goes as fast as an F-18 relative to standard ship speeds.An F-18 goes 34x as fast as a Zumwalt class destroyer (1,290 mph top speed vs 35 mph). Early-ish game "standard" speeds are around 5,000km/s. 34x that is 170,000km/s, which can't be achieved at the same tech. However in other ship doctrines, "standard" speed is more around 2,000km/s at the same tech as before and 34x of that is only 68,000km/s, which can feasibly be achievable in game. While I agree with the general statement, you have to understand that "standard" is very, very flexible. To someone else, "standard" may even be 10,000km/s at the same tech.
The square-cube law is a pretty fundamental consideration.
Your example doesn't apply because nothing in Aurora goes as fast as an F-18 relative to standard ship speeds.
PT boats would go through their considerable fuel load within hours at full speed, so a short mission life is nothing exclusive to aircraft. Aurora fighters are also heavier than those, and much heavier than period fighter aircraft. Styling fighters as aircraft may be done for RP reasons, but the mechanics don't really make it a natural fit. I think you're trying to jam a square peg into a round hole here.
An F-18 goes 34x as fast as a Zumwalt class destroyer (1,290 mph top speed vs 35 mph). Early-ish game "standard" speeds are around 5,000km/s. 34x that is 170,000km/s, which can't be achieved at the same tech
My two cents is have a 50 hs fighter system that has 5% of the capacity of a 500 hs system, for 20% of the cost.I would be open to this through technology research, and not available right away, however I think they should be 50 tons and 500 tons respectively instead of 2500 tons and 25000 tons ;).
Not as things stand, but it wouldn't be hard to add a player option to name certain types of systems in certain ways.
It also neatly explains why projectile weapon damage falls off with range, which shouldn't really happen if the projectiles are in a vacuum.I thought this was already explained for the same reason that ships need constant fuel use to keep moving - that trans newtonian materials act like they are moving through some sort of medium even in a vacuum. Since the projectiles are likely made out of the densest materials possible so that they can penetrate duranium hulls they would also be trans-newtonian (neutronium I believe?).
It could be nice to have further rules for the idea of slavery in general. Perhaps it could be made so that the slaves can be brought to a planet with minimal to no infrastructure and act as a disposable population. That way they can man installations (Each unit costs 10,000 population to create, why not have them be 10,000 of population for labor as well), such as mines or terraforming installations. (does it make me evil to want the filthy xenos I crushed under my Jackbooted heel to serve me in defeat?)
I'm leery if the proposed refueling changes. One of my prime frustrations with playing Distant Workds is that your fleets eventually get bogged down into annoying pile ups constantly waiting for fuel. That can be avoided by building enormous tanker chains, but because in DW automatic tanker supply chains can't be made, the late game bogs down into a tedium of manually ordering tankers to move around.With the change you can;
Restricted fuel would not be too bad in a classic Sol start with no other NPRs on Earth. However I found in v6.43 if there are NPRs on Earth with the player race then while you can beat them to the first jump, to beat them the second is very difficult unless you sink all your tech points into fuel economy techs. Additionally the NPR exploration ships keep going and unless they run into something unpleasant youi can not catch them.
Ian
Couldn't there be some simple range limit at least in place to keep NPRs within reasonable ranges? For example NPRs are not allowed to enter JPs further away then X% of their max range from closest friendly colony? ( X being around 30-50% ).
Can someone explain to me why slaves aren't represented in the "population" figure (as in, if you're RPing slavers why do you consider the population figure to be non-inclusive of slaves)?
I believed there was some form of limitation (it would make sense), but i'm regularly seeing survey ships from friendly NPR at the other side of the galaxy, over 80bil from their nearest colony :/Are you sure that there's not a JP link that they're using and you just haven't found yet?
Population is directly calculated as "productive" units, part of them become highly trained personnel that can work in financial centers, research labs and such, so it makes sense that forced labor slaves are considered somewhat apart, they cannot simply "join" a population and become productive citizens. One can always RP that part of the population is made of "loyal slaves" that are allowed a certain degree of freedom and basic training, apart from "rebellious/uncontrollable slaves" that are to be closely guarded/segregated in mines and factories and cannot be allowed to access populated areas.
With the change you can;
A) Create massive orbital refinery stations with dozens of refueling systems.
B) Create a modular system where tugs can pick up refueling/tanker modules.
C) Manage your tankers via sub-fleets and conditional orders.
D) Simply do things as normal but make sure to have a few systems on your tankers/supply ships.
I know this is probably asked alot but any indication of when a release to your faithful fans might be made?
Today's Changes:
for airless bodies, shouldn't the population maximum be more a function of volume instead of surface area since those require underground infrastructure?
For normal bodies how does the interact with the infrastructure mechanic?
It's mentioned in the change post that Earth's hydrosphere aids in habitability. Does this mean that 0% water-coverage will result in a colony cost? Will there be a way to affect water coverage through terraforming?
Just one thing on overpopulation, please give a thought to small asteroids/moons not constantly becoming overpopulated and filling the log with warnings about it. Would be nice to have a way to avoid without too much micromanagement. Maybe additional growth on them could automatically be transferred to the nearest planet or lowest colony cost population in the system causing the overpopulation there?
Rather than a new tech line, doesn't the Orbital Habitat Module already fill that purpose pretty perfectly? Just have their population capacity act additional to the body's limit.They act as infrastructure that you can tow into the orbit of a planet that can hold a certain amount of colonists no matter the colony cost.
Also, regarding radar seeking missiles, missiles with EM-sensors already perform this purpose.
Can we get the option of radar-seeking missiles? In my opinion, it would help to force players to rely more on passive sensors as using active would put them at risk. In the current version of the game, I find stealth ships not to be very powerful in combat considering the costs to research and build them.Not the right place to ask this. And stealth ships are pretty strong and one of the more viable options in this game.
I actually rather like the idea of orbital habitats increasing the maximum population, if that's doable. Even if you're unlikely to need to get Earth over 12 billion, increasing the max would also boost the growth rate (assuming >4 billion), which is a cool use for the habitats.
Also there's just some delicious flavor value in having a mega hive world Earth with 30 billion people due to massive orbital habitats.
I need better names for Safe Greenhouse Gas and Anti-Greenhouse Gas :)
Any suggestions welcome - either existing gases with no harmful side-effects (couldn't find any) or Aurora-style names for new gases.
Aestusium (based on Latin for heat)
Frigusium (based on Latin for cool)
Adam.
Maybe adding a tech line to represent super structures, hyper structures, city hives, floating cities, etc that provide a 20(30)(40)(etc)% bonus to maximum capacity. While I love there finally being a limit to populations, I also think that that final limit of 12 mil doesn't really take into account technological advances and such. I also took another look at the article, and it really didn't touch on population density that much. While one of the interactive charts told you the density of the country, they really didn't touch on the density of cities and regions that people are living in while still growing. I remember a video that touched on this, about how small a city could contain all currently living humans, and some cities that are flourishing have a population density multitudes greater than the total population per km those graphs gave.
Not a valid youtube URL
I recall your opposition to population caps when I made the suggestion a while back, although the reply was vague as to whether that is what you disagreed with. While I am glad that it is now in game, I too feel that you should be able to expand via researching different methods of increasing capacity, this could be dependent on the type of planet so you'd need to research different trees based on what the ideal planet is for your species. I'd also like to see a habitable surface area, which can change over time e. g. a low habitable area upon terraforming a planet which increasingly expands when the planet becomes warmer.
I will be adding tech to improve capacity.
On non-terraformed worlds, the pop cap is effectively whatever infrastructure you have (the habitable area) so there doesn't need to be a separate max cap.
Wait. I thought the planet population capacity limit would still apply no matter what, even on non terraformed worlds. Or I am misunderstanding your phrase here?
I mean, didn't we say that capacity depends on available surface? Because if it just depends on infra, I can drop one billion LG infra on ceres and have a huge population here.
I didn't express myself very well :)
There is a hard population cap, which applies regardless of the colony cost of the body. For non-habitable worlds, the effective population cap is either that supported by infrastructure, or the max capacity, whichever is lower.
When I wrote my original answer I had Earth-size worlds in mind and was assuming the infrastructure capacity would never reach the max pop capacity. For small bodies however, that is a real possibility.
I need better names for Safe Greenhouse Gas and Anti-Greenhouse Gas :)
Any suggestions welcome - either existing gases with no harmful side-effects (couldn't find any) or Aurora-style names for new gases.
Good suggestion! I like that a lot better than what I have now. I'm using this unless someone comes up with a better idea :)
Aestusium (based on Latin for heat)Good suggestion! I like that a lot better than what I have now. I'm using this unless someone comes up with a better idea :)
Frigusium (based on Latin for cool)
Adam.
So does this population cap apply separately to each population on a planet or universaly shared among all factions on a planet? It would be kind of weird if united Earth could have a max population of 12 billion but America + Russia + Japan + the Isle of Man as separate factions could have a total max population of 48 billion.
A new concept, Population Capacity, has been added to C# Aurora. This represents the maximum population that can be maintained on a single body and is primarily determined by surface area. This is the total of all populations on the same body, not per population.
Will hydosphere affect the pop cap any? Will there be a separate tech for sub-aquatic settlements, or is it just going to be unusable area?In the "Considering Terraforming Change" thread, Steve confirmed yes.
Erm. It's written in the very changes list post.Alright thanks, must have missed that.
Simple question (and hard implementation I think ;D ) : in A.C# there will be IFF systems/technologies ?
Think this for: intellegence mission spoofing codes, JP or planet mine fields creation (and mine field sweeping), elusion probing...
At the moment I have no plans for spoofing IFF. While it sounds interesting, the game play impact will likely be players checking their own list of ships every time a new task group enters the system to make sure it is definitely one of theirs.Could also be spoofing another empire's signature that correlates to a freighter that regularly trades with you. Would be interesting, but its not vital or necessary.
There will be IFF in the same way as VB6, with transponders. Minefields already know friend from foe.
At the moment I have no plans for spoofing IFF. While it sounds interesting, the game play impact will likely be players checking their own list of ships every time a new task group enters the system to make sure it is definitely one of theirs.
Pirates would be an amazing addition. On real star games my navy doesn't have a whole lot to do because of the scarcity of NPR's.Have you tried raising few percentages (difficulty / NPR spawn rate) or checking some other stuff (NPRs can find interesting things too and other FUN stuff) at the initial screen?
There will be IFF in the same way as VB6, with transponders. Minefields already know friend from foe.
At the moment I have no plans for spoofing IFF. While it sounds interesting, the game play impact will likely be players checking their own list of ships every time a new task group enters the system to make sure it is definitely one of theirs.
Precursors currently fill the role of pirates. It would be tricky to set up the economics necessary for believable pirates, but I could add other races that function with a 'raiding' mentality.
Precursors currently fill the role of pirates. It would be tricky to set up the economics necessary for believable pirates, but I could add other races that function with a 'raiding' mentality.Maybe even a system of them rebuilding wrecks, adding some of their own parts of course.
Maybe the chance for precursor shipyards that slowly produce precursor ships?
Ideally, though I know it would be a big change/not fit how the game currently handles things, it would be a chance that a system that generates with precursors automatically generates a jump point connection to a system that then spawns a shipyard, so you could go in and clear out the precursors but a year or two later have more show up if you didn't keep surveying. It would also encourage spreading your fleet around instead of keeping it in one big blob.
What about adding in some automated mines and/or stockpiles of "long forgotten minerals" in the shipyard system along with mass drivers, in the same way that there are stockpiles of missiles. They wouldn't get activated until a player or NPR woke them up? That way the shipyard would only produce what it had the actual resources to produce - keeping it from being overpowered. Maybe throw in salvagers too?
The bigger the shipyard, the greater the chance of a larger number of claimable structures on the planet once it is cleared out.
Are Precursors reusing the same code as an NPR - just pared down?
I'm loving the screenshots and changes added so far- amazing to see the game moving into a much more manageable language. I'm most excited for the performance improvements, but is there any chance there will be changes to how ECM/EW works? It's always struck me as a part of the game that could use more expansion.
Waiting anxiously for release, but please, take your time, Steve, that's your style and it's worked this far!
What about adding in some automated mines and/or stockpiles of "long forgotten minerals" in the shipyard system along with mass drivers, in the same way that there are stockpiles of missiles. They wouldn't get activated until a player or NPR woke them up? That way the shipyard would only produce what it had the actual resources to produce - keeping it from being overpowered. Maybe throw in salvagers too?
The bigger the shipyard, the greater the chance of a larger number of claimable structures on the planet once it is cleared out.
Are Precursors reusing the same code as an NPR - just pared down?
I'd been thinking some sort of mineral stockpile, but now that you mention it maybe asteroid miner modules? The Spaceyard could be an immobile base over an asteroid (though I suppose the asteroid would need special generation to have all the minerals). That's consistent with the mainly space based nature of precursors, and provides interesting possible rewards (blow it up and salvage it, or try to board it with marines and gain an immobile asteroid miner).
I always feel bad about making extravagant suggestions in the C# changes discussion thread since I don't want to make the conversion even harder, though.
Speaking of being wary of expanding the Economy.
I would love Civilians to be more autonomous, just more lively. ANd C# seems to afford that ability to manage those extra misc. ships, and habs.
I love for them to build space stations and habs on asteroids. I would love pops. to be resource sinks for TN elements. Something like 1000 pop for every 1 TN element sunk. Representing domestic markets and industry making products with them. And maybe having a sub race for every faction being their civilian force, getting quarter of the current spent RP points for their tech levels to as a rough guide for the slow transition of mundane from the cutting edge. It would need one more resource called luxury or something that every planet/hab produces and requires to a ratio of their pop but they dont consume their luxury resource produce. And having habs/colonies with cilvilian pops deprived of the required TN elements, or luxary would be tied to their moral.
Regarding civilians it would be nice to have an option to turn on or off the various things civilians can do (civilian mining, civilian shipping, etc) since they may or may not fit certain empire styles.
As it stands, troops are trained out of just resources and ship crew just appear. What if training crew and troops took population directly from the planet to train them?
You're kind of right about troops (although it takes over a year to make a battalion, which I assumed was spent more on training than production) but if I remember correctly ship crews come fro military academies. If you go to the economy>teams/academy you'll see the number of crewmen and junior officers in top right corner.
Precursors currently fill the role of pirates. It would be tricky to set up the economics necessary for believable pirates, but I could add other races that function with a 'raiding' mentality.
The huge downside is that they are much more vulnerable, a single ship with an energy weapon could cruise through and obliterate them.
Another way to promote raiding more might be to make it easier to sneak past jump points. Maybe make a Jumpdrive option for a raiding ships which makes the jumpdrive 3 times as large (prohibitive for warships) but gives it say 100 times the jump radius and limits it to self jump only?Rather a kick in the pants to beam ships, who don't need it; and it won't help raiding (as opposed to suicide runs) much unless you also have a way to jump out.
On the other hand if you have a lot of crewman you'll be able to get 'the cream of the crop' into the ships getting large grade bonuses (up to 30% or so).This isn't true. The maximum starting grade bonus is 10%. Anything above that is the result of crew training or (rarely) battle damage.
Please note that all this description comes from my observation of the mechanics, not any 'hard' knowledge so this may all be wrong.Good job on saying this. Don't take the above as criticism.
RE: Class Rank Limits
Will we also be able to bar a class from having a commander at all?
Rather a kick in the pants to beam ships, who don't need it; and it won't help raiding (as opposed to suicide runs) much unless you also have a way to jump out.
This isn't true. The maximum starting grade bonus is 10%. Anything above that is the result of crew training or (rarely) battle damage.
In version 6.43 I have an entire group of asteroid miners, who never received any TF training and who never were near any enemy and they all have grade bonus of 34% which appears to be actual cap. From what I have seen it is impossible to get a grade bonus through task force training, you can only get it through lucky roll (if you have enough crews) or through battle damage.Yes, that's due to the crew training ratings of their commanders. Those are all at least 70 years old, and apparently have had enough crew training during that time to get to the required grade points. It's weird, but plausible. They didn't build that way, I promise.
(http://aurora2.pentarch.org/index.php?action=dlattach;topic=8497.0;attach=2115)
I have two requests for Aurora changes, both pertaining to the economy.Remember that 7.2's changes will be implemented into C# aurora as well: http://aurora2.pentarch.org/index.php?topic=8151.0
First I'd like the civilian shipping lines to do a better job of choosing what to build. In several campaigns now I had lines building a lot of colony ships despite the fact that there was no colonisation to be done by them. On the other hand I could really use the income from trade, but they didn't have enough freighters. It would be nice if the lines checked if there is any colonisation going on before building those ships, possibly by checking if any planets are set as a source of colonists of not.
Second I'd like modification to the placement of the civilian mines. Currently they only look for duranium and sorium which means there can be planets with hundreds of millions of tonnes of easily accessible minerals but those are ignored if they don't have either of the two in reasonable accessibility. It would be nice if civilians built mines on any rock with large and easily accessible deposits, although if that's the case the income from the mines may require adjustment.
Those are of course minor changes, so if there is no time (or will) to implement them it's fine.
Unfortunately it says " build a more equal distribution of freighters and colony ships" which would imply the lines will keep building as many colony ships as freighters irrespective of whether or not there is any work for them.
Even better would be if we could manually "specify" which ships we prefer. It shouldn't be too hard to code, if Steve wants to. A simple combo box with "cargo", "colonists" and "both" would do the trick. Also for roleplay.RP wise it may make sense to have each shipping line with just one type of ships: one only with colony ships, one only with freighters...
Or allow you to straight up ban production of new trade, colony, or freighters if you wish.
RP wise it may make sense to have each shipping line with just one type of ships: one only with colony ships, one only with freighters...That would actually come very close to solving the problems you see with poor allocation of shipping, too. If the freight line is earning a lot more than the colony line, it will have more money to buy new freighters with, and none of that money will be squandered on colony ships or (especially) fuel harvesters.
Also, if you want more freighters, subsidise freight line. If you are planning for big colonisation task, give credits to colony line.RP wise it may make sense to have each shipping line with just one type of ships: one only with colony ships, one only with freighters...That would actually come very close to solving the problems you see with poor allocation of shipping, too. If the freight line is earning a lot more than the colony line, it will have more money to buy new freighters with, and none of that money will be squandered on colony ships or (especially) fuel harvesters.
If you outright ban colony ships then subsidise the line it should build a bunch of trade and frieghters. Eventually those colony ships will get old and not be replaced.How do you do that? Back when the shipping lines built your designs, it was possible to pull this off, but they design their own ships now, so you can't.
Has Steve written something about the statistics of C# Aurora? As simple and effective as the given system is for one player, I find managing several empires rather difficult with it. So I would appreciate a more sophisticated system for the new version ;DI don't really understand what you mean by statistics I'm afraid? Do you mean some sort of Empire wide performance reporting?
I don't really understand what you mean by statistics I'm afraid? Do you mean some sort of Empire wide performance reporting?I mean some working statistics like:
Minerals | / Actual | / Mining Year | / Mass Driver Transfer Year | / Used Year |
Neutronium | / 12.455t | / 3.445t | / 822t | / 4.115t |
I mean some working statistics like:That kind of read out would be deceptive. I assume the definition for total, is for bodies that are being mined or have mining facility on them or in orbit. That amount is only psedo useful. Accessibility is the kicker there.
Minerals / Actual / Mining Year / Mass Driver Transfer Year / Used Year Neutronium / 12.455t / 3.445t / 822t / 4.115t
Chooseable for "Single Planet" / "System" / "Empire" as well as time spans like "Last Month" / "Last Quarter" / "Last Year". Actually there are several statistics but they are not so useable in my opinion. Basically do what is available for money for all other relevant values.
While that elaborate suggestion could be useful, I think the point was a simple "Total xx mined" vs "Total xx used" comparison would make it much easier to determine if you even have a problem.Yes, it was just to illustrate my general idea - and you pointed out the problem I wanted to solve: do I have a mineral shortage problem and why? Don't I mine enough because of depletion or do I consume it too fast - and how can I adjust.
For the sake of "simplicity" it would be nice to have another ship module: Mass Driver. This module functions like the ground based module, just for ships. Placed near a wormhole it could "massdrive" incoming materials delivered by ships through the wormhole to a destination planet.
Thinking that idea one step further, having a mobile jump gate which receives "Mass Driver Packages" on one side of a wormhole and sends it to a receiving planet on the other side would be even nicer... .
The main problem with the ability to attack a supply line (in my opinion) lies with the jump point restriction and their general fork-layout. Within one system you could attack a supply line, but over several systems - generally not possible if there is no "backdoor". If there would be more interconnection between the systems you are right and such a system would widen the possible strategic options.
On the topic of maintenance two ideas:
One: wouldn't it be nice if there was a general option that all ships have to undergo maintenance - which means: civilians also. Maybe at a much slower rate than military ships - but generally private vessels have to be maintained as well. Just for realisms sake... .
Two: When the capacity of the total maintenance is lower than the total tonnage shouldn't there be a priority list which ships should be fully maintained - and only those at the end of the list would not be maintained?
1) That used to be the case in earlier versions but it was removed on the basis that the micromanagement overhead wasn't worth it for the benefit to game play.What if they would just cost some amount of wealth to maintain, without any need for maintainance facilities? Or something else that is some kind of cost, but not requiring any management from the player. Currently there is just no incentive to scrap old or unused vessels, as they cost nothing to keep around and might maaaybe get some use in the future. It just looks completely strange that the civilians scrap ships after a few years even if they are still using latest tech, while the government still has the first cargo ships ever produced in service.
There would have to be some penalty for a mothballed ship, perhaps a large lag while you re-active and crew the ships or a loss of grade/experience. If not then why wouldn't you keep most of the fleet in mothballs until you see an enemy and then instantly reactivate it.
But in principle I like that sort of idea a lot.
Are missiles going to be "balanced" or rather are other weapon types going to become more useful in more situations?
I think that railguns should have unlimited range but should be dependent on how advanced your fire control computer is to determine how far away it can shoot accurately. Speed, distance and tonnage should play a role in how accurate the shot is, so at 1 million KM it can shoot a 1000 ton vessel going <500 KM/s at 100% accuracy etc. This would be a low end computer, I believe that beam weapons should be feasible from farther away, with a super advanced fire control being able to fire at a target accurately
I'll also reiterate my idea about being able to size up beam weapon components like you can sensors with tech advancements making them more efficient, not larger.
Are missiles going to be "balanced" or rather are other weapon types going to become more useful in more situations?
I think that railguns should have unlimited range but should be dependent on how advanced your fire control computer is to determine how far away it can shoot accurately. Speed, distance and tonnage should play a role in how accurate the shot is, so at 1 million KM it can shoot a 1000 ton vessel going <500 KM/s at 100% accuracy etc. This would be a low end computer, I believe that beam weapons should be feasible from farther away, with a super advanced fire control being able to fire at a target accurately
I'll also reiterate my idea about being able to size up beam weapon components like you can sensors with tech advancements making them more efficient, not larger.
This has been suggested many times, but beam weapons range is hard locked by the speed of light. Honestly, from a realism point of view they're probably excessive as is; even with a laser shooting a dodging target when the beam takes 5 seconds to arrive is going to be effectively impossible. No level of advanced computer is going to be able to predict random movement.
Also, a very important thing which is not modeled by the game right now. Weapons like railguns have effectively an infinite range, because the bullet keeps going in the void. So, I should theorically be able to use them to hit stationary targets from infinite distance.
There is no logical nor physical reason for which I can't use a railgun to shoot your immobile sorium harvesters from the other side of the system. Same goes for your orbital stations in a a geostationary orbit, or your shipyards. Just calculate the trajectory, and I should be able to shoot them from the other side of the solar system. Or at least, from very very far away. Because, you know, they do NOT move.
The problem is that if I added this, players would want the ability for every ship to make small random course changes, or add tiny manoeuvring thrusters to shipyards, etc. so they could regularly make small positional changes. In the end (apart from planets), we would be back where we are now but with a lot more complexity. Even if we added this ability to target planets, it would also make sense to add a new range of defences designed to intercept long-range kinetic projectiles.So I get that for the purposes of the game railguns range is limited by how far the projectile can travel in 5 seconds. But does that necessarily mean that the range cannot be improve? From what I remember the maximum range of a high end railgun was something like 1 million km. Would it really be that bad to bump it up to 10 million? It still outranged by every offensive missile.
So I get that for the purposes of the game railguns range is limited by how far the projectile can travel in 5 seconds. But does that necessarily mean that the range cannot be improve? From what I remember the maximum range of a high end railgun was something like 1 million km. Would it really be that bad to bump it up to 10 million? It still outranged by every offensive missile.
What do you think about the idea of being able to scale up rail-gun components (capacitors, launch-velocity, and caliber) like you can with sensors with technology only increasing efficiency?
It is a limitation of light speed, rather than projectile speed. To cover 10m km in 5 seconds, the projectile would be travelling at almost seven times the speed of light.
The problem is that if I added this, players would want the ability for every ship to make small random course changes, or add tiny manoeuvring thrusters to shipyards, etc. so they could regularly make small positional changes. In the end (apart from planets), we would be back where we are now but with a lot more complexity. Even if we added this ability to target planets, it would also make sense to add a new range of defences designed to intercept long-range kinetic projectiles.
I understand how this might cause problems. However it is a fact that non-missile weapons are severely penalized by how the game calculates things. The two main causes are in my opinion the 5-second increment and the hard range cap of 1.5 million km on all "beam weapons".
Because of these two things, if we look at things strictly from an efficiency-related point of view, missiles are better against the AI. Simply because you can build ships that the AI cannot deal with, either because of PD saturation or range or speed or whatever. You can do that with "beam weapons " as well, but it requires a lot more effort.
Of course it is different with roleplay, and I do roleplay. I just wish that "beam weapons" would be more generically useful (as they would be in reality) without me having to resort to self-imposed rules and RP.
EDIT: if range is out of the question, then perhaps an acceptable solution could be to make "beam weapons" cheaper, either in build cost or preferrably in size (more miniaturization). Which would allow to cram more firepower on a "beam warship". I don't know, just trying to think about how more balance might be achieved.
The main issue I have with missiles is that they can take advantage of the 5 second increment to launch and hit without being detected, if the launching ship is close enough to the target. I will fix that in C# Aurora by detecting missiles at the point of launch (outside of the normal detection sequence).
I will also try to make the automated design of NPR ships more intelligent, plus I will be adding some more spoiler races to the existing three.
I will also try to make the automated design of NPR ships more intelligent, plus I will be adding some more spoiler races to the existing three.
With the speed improvements that C# has given could increments be reduced to a second for combat resolution? Maybe it would add too much additional spam to the event log though.
I don't see why you can't just model it like flak, where you are spamming shots in their general direction and trying to score hits. I can understand not wanting tracking laser projectiles, but you could just delay the application of laser damage and then say that any of the enemies movements was accounted for in the statistical models used to target the laser shots. Its not like most ships at laser range are going to be moving particularly large distances anyways, except at the super high techs.
Still don't see why lightspeed has to be taken into account for weapons made of materials that already break physics when put together right.The materiel are exotic, the particles aren't. A laser is coherent wavelength of light, of photons. Photons still obey relativity. This though means that you could make a superliminal railgun, if you made the slugs it throws out of tn materiel. Though right now, the slugs that railgun throw are 'free', presumably because they're composed out of mundane materials. And if you made the slugs out of TN materiel, you would need to account for them, in a similar fashion to missiles.
On a different topic, I realized yesterday that the new maintainence rules will heavily penalize carrier-based play because fighters are counted twice for the maintainence tonnage - once as the needed hanger space on the carrier itself, and a second time for the fighter's own tonnage.
Under the new rules, they will be, and the rules don't say anything about ships in hanger not counting towards the maximum tinnage under maintainence cap.
I'm in full agreement with points one and two and ambivalent about point 3. However I really don't like points four and five.
While most people play on relatively low technology levels I recently reached anti-matter era and the interception chances are simply too high, rising to 50% against missiles which put 60% of it's mass towards engines. This makes it so difficult to get through point defence it makes any missile above size 2 essentially useless, even with box launchers. Making interception even easier (by reducing potential missile speed) or forcing us to use larger missiles will severely impact missile usefulness for fusion era and above.
What I would like to see is less trying to force us to use larger munitions and more ways for penetrating point defence, ways that favour larger munitions. This ways the player could either try to swamp the defences with small, cheap munitions or try to evade the defences using large, expensive but very hard to intercept missiles. The best way to do this would be by modifying ECM (since ECCM is not that bulky) but I don't know how to do that. Another way may be to allow the shipkillers to use agility to avoid interception, but that would have to be carefully balanced.
The other issue I have some problem with is the reduction is sensor range. Now I agree that sensor ranges become rather ridiculous on higher technological levels, but that the thing - the initial ranges are reasonable, the final ones are not. So what I'd like to see is the modification in the way technology progresses but from what you said you intend to lower even the starting detection range, which I think is a mistake.
In addition if you're tinkering with active sensor ranges you may take a look at passive ranges as well. At the moment a couple tracking stations in a central location can see anything in the system other than either small ships or stealthed ones.
I think your point about adding penetration aids to larger missiles is a very good one and I will find a way to implement something on those lines. I will probably advance my timetable for EW changes and include those in the initial C# release.
3) I like the idea of removing the link between missile size and reload time, or at least significantly reducing the impact, as this will negate some of the advantages of smaller missiles.This never made sense to me, so I will look forward to seeing it gone. If the launcher is big, and the missile is big, the loading mechanism will be equally big and thus the reload speed will be the same. There's no real reason for small missiles to reload faster, it's all fully automated. You don't have cabin boys manually carrying ordnance.
4) Also like the idea of some type of missile frame that would favour larger missiles (more frame overhead for smaller missiles), although this might impact the effectiveness of AMMs in the anti-missile mode. I guess one option would be to allow fractional missile launcher sizes so you could use missiles of size 1.2 for example.Small missiles should have more overhead, so I'm in favour of this. Miniaturization does have a cost.
5) I am happy to remove the distinction in the power curve between missiles and normal engines. From a consistency POV, there really is no reason why a missile engine could be boosted more than a normal engine. However, I will probably just allow normal engines to be boosted more, rather than reducing missile boost. If missiles are reduced in speed too much, they become too easy for point defence to destroy (some may argue that is already too easy).I am ok with this but... I think there's a problem with the fuel model because higher speed engines for ships won't be usable if range becomes too short. Specifically to solve this, I think that bigger engines should have a more pronounced reduction in fuel consumption. Right now the difference in fuel usage between a size 1 and size 50 engine is pretty low. I think it would make sense to increase the fuel consumption reduction. The tradeoff is ALREADY there, because it's so much more risky to use fewer, bigger engines.
The simplest change is to base the sensor range on the area (or volume) covered rather than the linear range. In essence, divide the result of the above calculation by the area or volume. This will shorten ranges considerably and is much more realistic. This would require some increase in base sensor strength though or the ranges would be reduced dramatically. I will run some numbers and post on this separately.
I dont think it took very long to unmothball the Ohio battleships into active service.The what? The last battleship Ohio was decommissioned in 1922. I think you're referring to the Iowas, and it took a year or so each, and a lot of effort. Ships go out of date in mothballs pretty fast.
1) Increased beam range. I am reluctant to increase beam range significantly. The main reason is that currently faster ship plus longer-range beam vs beam opponent = instant win. if we make any major change to beam range, that will mean longer range beam (even when slower) vs beam ship = instant win, because the faster ship with shorter-range weapons will be destroyed before it can close the (increased) range.
The big reason that this is a problem is that a faster ship with a longer range beam can hold the range regardless, so longer range beams don't really make it worse.
Beam ranges affects the parts where we get "interesting" fights though, where one size has range and the other side speed.
When beam ranges are considerably longer than they are now, the longer ranged side will be heavily favoured and nail-biting situation where one side is trying to rush the other one down rare.
Note that things like Microwaves already allow a short window of one-sided combat to be quite telling if that's what you want to design for; too-long beam ranges would be more problematic than too-short ones.
With regard to the various missiles vs beams ideas:
1) Increased beam range. I am reluctant to increase beam range significantly. The main reason is that currently faster ship plus longer-range beam vs beam opponent = instant win. if we make any major change to beam range, that will mean longer range beam (even when slower) vs beam ship = instant win, because the faster ship with shorter-range weapons will be destroyed before it can close the (increased) range.
2) Reduced overall speeds for missiles and ships (and reducing tracking speeds). This also creates the above problem, but by changing speed rather than range.
3) I like the idea of removing the link between missile size and reload time, or at least significantly reducing the impact, as this will negate some of the advantages of smaller missiles.
4) Also like the idea of some type of missile frame that would favour larger missiles (more frame overhead for smaller missiles), although this might impact the effectiveness of AMMs in the anti-missile mode. I guess one option would be to allow fractional missile launcher sizes so you could use missiles of size 1.2 for example.
5) I am happy to remove the distinction in the power curve between missiles and normal engines. From a consistency POV, there really is no reason why a missile engine could be boosted more than a normal engine. However, I will probably just allow normal engines to be boosted more, rather than reducing missile boost. If missiles are reduced in speed too much, they become too easy for point defence to destroy (some may argue that is already too easy).
6) I will include missiles in whatever final version of electronic warfare I decide upon.
7) I like reducing sensor range and it is something I was already considering (one of the reasons I haven't written the detection code yet). It would make the game more tactical and provide more reason for scouts & pickets. While not impacting missiles directly, the main requirement for missile ships is to detect their opponents (as missiles can be designed with very long-range), so this would effectively reduce missile range. At the moment, active sensor range in km is equal to:
Racial Active Sensor Strength per HS * Sensor Size * Racial EM Tech * Square Root of Resolution * 10000.
The simplest change is to base the sensor range on the area (or volume) covered rather than the linear range. In essence, divide the result of the above calculation by the area or volume. This will shorten ranges considerably and is much more realistic. This would require some increase in base sensor strength though or the ranges would be reduced dramatically. I will run some numbers and post on this separately.
When it comes to missile ECM I'd offer 3 different forms of ECM; spoofs, shadows and lures.
Spoofs are the standard, current ECM systems, and work by decreasing the effective range of fire control systems to target the missile.
Shadows increase miss chances of point defense systems by creating illusions of more missiles of that type that soak up incoming point defense fire.
Lures make it more likely that a missile equipped with the lure is hit. While this sounds counter productive, this allows you to create sacrificial missile with a lot of armour and a high lure rating to seed into your salvos and to draw fire from the missiles with big warheads.
ECM systems are deliberately meant to be big, but can work together. This just means you've got some very big penetration aid missiles within your salvo. Advances in technology can decrease the size component and increase the effectiveness, eventually letting you create smaller missiles that have some ECM themselves, but really effective ECM will always require big missiles.
There are of course ECCM systems that can defend against these forms of ECM.
Sorry to keep bringing this up, but I'd really like to know what you think of this idea.
What do you think about the idea of being able to scale up rail-gun components (capacitors, launch-velocity, and caliber) like you can with sensors with technology only increasing efficiency?
As it is, only missiles have any meaningful customization option.
You can already change caliber, launch velocity, and capacitor charge rate based on tech. IIRC Steve plans on eventually adding spinal railguns as well. In the suggestion thread (since it didn't seem to belong here) I did suggest maybe being able to dedicate tonnage to extra capacitors, though. So that if, say, a laser took 8 power to fire, instead of storing 8 power you could have it be larger but store 16 power and be able to fire twice in successive increments before having to stop to recharge.
Let's say the laser takes 8 and charges 3 power per 5 seconds. Normally it would work like:
5 seconds: Fires, 0/8
10 seconds: Charges 3, 3/8
15 seconds: Charges 3, 6/8
20 seconds: Charges 2, Fires, 0/8
25 seconds: Charging, 3/8
With extra capacitor, it could look like
5 seconds: Fires, 8/16
10 seconds: Charges 3, Fires, 3/16
15 seconds: Charges 3, 6/16
20 seconds: Charges 3, Fires, 1/16
25 seconds: Charges 3, 4/16
What I mean is that instead of just having 8 (is it 8?) tiers of calibers, capacitors, and launch velocity you have 100 like you do with radar resolution and engine size. Choosing a bigger component means making a heavier gun and researching techs like calibers (should be renamed), capacitors and launch velocity (also needs to be renamed) would make smaller guns more powerful like when you research more advanced sensor technology.That wouldn't work out because unlike sensor range, the change in damage is very limited. Going from 1 damage to 2 damage to 3 damage will mean you end up having set calibre brackets that are optomized and most efficient, with all other calibres being safely ignored. Only way your idea would work is if damage became a float, or the damage had a percentage to do more (or less) damage each hit. I do, however, support being able to produce 'most' calibre sizes at very early game, with technology increasing efficiency.
By and large I quite like the idea. The problem is with ECCM equivalent.I think Steve is going to revamp the EW elements in the game. Hopefully, dedicated ECM/ECCM for use against missiles. Although making missiles use agility to dodge attacks could also work.
Right now the reason I don't use ECM on missiles is that I usually have ECCM on my ships and there is nothing stopping me from hooking them up to point defence which means ECM is at best of very limited utility (assuming superior technology) and at worst a totally wasted space (assuming equivalent technology).
Here's the thing. The anti-missiles have agility which helps interception. What that means is that as the time progresses anti-missile interception chances get steadily higher and there is no counter to that. By the time of the medium fusion era only size 2 and size 3 missiles are economical to use at all and by anti-matter era arguably only size 1 missiles are worth building. As such what we need is some way for missiles to get past defences that may be mitigated but not countered as the penaids (be they ECM, armour or something else) will essentially be nothing more than counter for ever higher agility. Hence the ECCM equivalent you propose should be really limited in use or maybe even altogheter absent (although in the latter case the ECM cannot make missile completely untargatable, as it can do now on the max level).
5) I am happy to remove the distinction in the power curve between missiles and normal engines. From a consistency POV, there really is no reason why a missile engine could be boosted more than a normal engine. However, I will probably just allow normal engines to be boosted more, rather than reducing missile boost. If missiles are reduced in speed too much, they become too easy for point defence to destroy (some may argue that is already too easy).
What do you think about the idea of being able to scale up rail-gun components (capacitors, launch-velocity, and caliber) like you can with sensors with technology only increasing efficiency?
5) I am happy to remove the distinction in the power curve between missiles and normal engines. From a consistency POV, there really is no reason why a missile engine could be boosted more than a normal engine. However, I will probably just allow normal engines to be boosted more, rather than reducing missile boost. If missiles are reduced in speed too much, they become too easy for point defence to destroy (some may argue that is already too easy).
This could be mitigated by making planet based missile PDCs less efficient, and all in a realistic way. Since escaping gravity is a costly thing, planet-based missiles could require a 2-stage design, in which the first stage is just something to escape gravity, and the second stage is the normal TN missile. This would make sense and would make planet-based missile PDCs less unbalanced.
Just to clarify as I cannot see it spelt out and I tend to have multple NPRs starting on Earth.
Max planet population of Earth = 12 Billion = (player race population x population density modifier) + (sum of all (NPR population on planet x population density modifier))
I made a suggestion for shared efficiency vs size curve between missiles and normal engines some time back here:
http://aurora2.pentarch.org/index.php?topic=7448.msg76067#msg76067
Shared efficiency vs size curve makes alot of sense and would also improve fighter design considerably as engine size would actually matter for them, as well as add the same exponential scaling from missile engines to ship engines ( and allow bigger but reasonable efficiency bonuses for above +100HS engines too if we want ).
I don't think it's a good idea to allow normal engines to use the same boost levels as missiles can however, since it would allow Point defense fighters/FAC carried in hangars to fly out and match the speed of any incoming missile, thus being able to fire effectively for as long as it takes to shoot down all the missiles even if you only have a small amount of PD ships.
With the new super fast process it struck me that switching the minimum tick to 1 sec or less would be a major rebalance and that having damage out put that was fractional to now so that it was effective v missiles but poor against ships would allow for more rapid firing but lower power weapons
I'll take a look.
I have been playing around a bit with a formula and think something like this would work good and feel balanced for engine size:
Formula: sqrt(10/HS)Code: [Select]HS Consumption
1,0 316%
1,2 289%
1,4 267%
1,6 250%
1,8 236%
2,0 224%
2,2 213%
2,4 204%
2,6 196%
2,8 189%
3,0 183%
3,5 169%
4,0 158%
4,5 149%
5,0 141%
5,5 135%
6,0 129%
7,0 120%
8,0 112%
9,0 105%
10,0 100%
11,0 95%
12,0 91%
13,0 88%
14,0 85%
15,0 82%
16,0 79%
17,0 77%
18,0 75%
19,0 73%
20,0 71%
22,0 67%
24,0 65%
26,0 62%
28,0 60%
30,0 58%
32,0 56%
34,0 54%
36,0 53%
38,0 51%
40,0 50%
45,0 47%
50,0 45%
55,0 43%
60,0 41%
65,0 39%
70,0 38%
75,0 37%
80,0 35%
85,0 34%
90,0 33%
95,0 32%
100,0 32%
Edit: I also like the idea to remove detail from the bigger engines ( who needs HS47 engines indeed?) and add it to smaller where it matters, or add more even bigger engines to strech the scale further, so both those have gone into my example above
And here was the numbers for ship engines (earlier in same thread):
http://aurora2.pentarch.org/index.php?topic=7448.msg75697#msg75697
And here was the numbers for ship engines (earlier in same thread):
http://aurora2.pentarch.org/index.php?topic=7448.msg75697#msg75697
it creates a smooth transition for both engine types, which is more realistic and consistent, provides a bonus to larger ships, makes the fuel portion of missile design more interesting (as fuel is not a major concern at the moment) and allows larger engines to be designed beyond the current 50 HS limit. I could also add a tech line to allow the larger engines
While my initial reaction was ambivalent now that I had time to think about it I'm not so sure I like the impact it will have on fighters and gunboats.
The main strength of the fighters lies in the ability to avoid detection. However you are now increasing sensor ranges for high resolutions while also forcing use of shorter range missiles which may make them completely useless. Not to mention they won't have that much range so it will be much easier to run down the carriers.
Similarly since the 100% engine is 10hs gunboats will become much shorter ranged than they are now and using motherships for them is somewhat fiddly at the moment. Now if you actually want to encourage larger ships, that's fine, but if you also want smaller vessels to be useful you should probably do some serious testing.
The main strength of the fighters lies in the ability to avoid detection. However you are now increasing sensor ranges for high resolutions while also forcing use of shorter range missiles which may make them completely useless. Not to mention they won't have that much range so it will be much easier to run down the carriers.Fighter missiles won't necessarily become shorter ranged. They will likely grow larger and slower with smaller warheads instead. Similar effects could happen for fighters; less payload tonnage in order to add more fuel. The sensor changes also mean it will be much easier to put sensor capability onto fighters and pickets.
The main strength of the fighters lies in the ability to avoid detection. However you are now increasing sensor ranges for high resolutions while also forcing use of shorter range missiles which may make them completely useless. Not to mention they won't have that much range so it will be much easier to run down the carriers.
Fighter missiles won't necessarily become shorter ranged. They will likely grow larger and slower with smaller warheads instead. Similar effects could happen for fighters; less payload tonnage in order to add more fuel.
it creates a smooth transition for both engine types, which is more realistic and consistent, provides a bonus to larger ships, makes the fuel portion of missile design more interesting (as fuel is not a major concern at the moment) and allows larger engines to be designed beyond the current 50 HS limit. I could also add a tech line to allow the larger engines.
But I think there must be some increase to missile fuel use as fuel is usually a minor part of missile design
That is true but only on lower technological levels. The thing is until Steve changes the ECM rules (or adds some form of penaids) from middle fusion era forward agility will make anti-missiles very accurate. We're talking about 50% accuracy against well designed missile. The situation flat out breaks when you reach anti-matter are and interception chances begin reaching 75%. Right now the only way to help shipkillers bypass such defences is to increase speed which requires maximum boost engines (6x) and very large engines (60% of the entire missile) leaving precious little space for anything else. Simple truth is my anti-matter era designs are shorter ranged than previous ones and have warheads only as powerful as those of early fusion were and the anti-missile still have 50% chance of intercepting them. So on that technological level, fuel management becomes a real issue for missiles.
That doesn't mean I'm opposed to the fuel consumption changes. To be honest I mostly don't care about them, as it makes little difference whether standard missile range will be 150m km (as it is in my campaigns right now) or 50m km (as will probably be the case in the C# version). I'm only worried it will impact some specialised but widely used designs, such as fighters, but Steve thinks it will be fine and since I can't go any try things myself, that is the end of it I guess.
SteveAlt Chronicle of the Vathorian Imperator - Part 3
« on: May 21, 2008, 01:37:43 PM »Code: [Select]AS-2 Jaguar Anti-Ship Missile
Missile Size: 3 MSP (0.15 HS) Warhead: 9 Armour: 0 Manoeuvre Rating: 10
Speed: 26700 km/s Endurance: 16 minutes Range: 25.0m km
Cost Per Missile: 3.5833
Chance to Hit: 1k km/s 267% 3k km/s 80% 5k km/s 53.4% 10k km/s 26.7%
Materials Required: 2.25x Tritanium 1.3333x Gallicite Fuel x625
Development Cost for Project: 358RPCode: [Select]AM-2 Bobcat II Anti-Missile Missile
Missile Size: 1 MSP (0.05 HS) Warhead: 1 Armour: 0 Manoeuvre Rating: 10
Speed: 32000 km/s Endurance: 39 minutes Range: 75.0m km
Cost Per Missile: 0.7833
Chance to Hit: 1k km/s 320% 3k km/s 100% 5k km/s 64% 10k km/s 32%
Materials Required: 0.25x Tritanium 0.5333x Gallicite Fuel x625
Development Cost for Project: 78RP
Ah, sorry didn't mean to sound like I was nagging you, just wanted to disagree with someone's perspective.
I am a bit unsure, however, on terraforming speed. I am afraid that the base speed reduction of terraforming modules (-60% !!) is too big and that it will make larger planets almost impossible to terraform in a "normal length" game.
I am a bit unsure, however, on terraforming speed. I am afraid that the base speed reduction of terraforming modules (-60% !!) is too big and that it will make larger planets almost impossible to terraform in a "normal length" game.I don't really have a problem with terraforming being a real challenge for larger worlds. IMHO terraforming should be a massive undertaking, not something you can accomplish in a half-hearted fashion over a couple of years!
One question about terraforming. I know we can add water. But can we remove water? I don't know about others, but in my games there are quite few planets without any dry land which, while not an issue from gameplay perspective (so far), can be sometimes problematic from role-playing perspective.
I see how you can add hydrosphere, but is there any way to remove it?Heating could possibly add vapour back to atmosphere, paying 1% of Hydro Extent for each 0.05 atm generated. Than you can remove that gas.
I don't really have a problem with terraforming being a real challenge for larger worlds. IMHO terraforming should be a massive undertaking, not something you can accomplish in a half-hearted fashion over a couple of years!
This really depends on how long it takes you to play. In my games I very often end up with a fleet capable of terraforming a planet in a year or so that either sits useless or begins to terraform every single rock possible simply because I need something to do with it. Because of that I ended up adding a lot of house rules to terraforming.
In addition the vast majority of planets that are potentially habitable are actually mars-sized in my games and for those terraforming will actually be faster.
One question about terraforming. I know we can add water. But can we remove water? I don't know about others, but in my games there are quite few planets without any dry land which, while not an issue from gameplay perspective (so far), can be sometimes problematic from role-playing perspective.
Well, they are a problem now :). Hydro Extent above 75% starts to reduce max population. A 100% water world has 1% of the normal max population.
It's a good point about removing water. I just need to figure out a way to remove it within the terraforming rules. On Earth, a small portion of the planet's water is in the atmosphere, so perhaps I should add evaporation as well as condensation, which will provide some water vapour to remove. I'll give it some thought.
Would making the planet colder reduce hydroextent. As the water is drawn to the polar caps to create ice. You might have a cold race or the planet might be already very warm and reducing the temp and creating ice caps will reduce the oceans?
Evaporation does not really help, however ocean dredging into the crust, with huge machinery will lower the ocean as well. Maybe activating some type of volcanic activity to spew rock and lava might be another way to create islands. I do not see evaporation as an answer as too much water vapour only ends up falling again.
Something to consider, but it would be awesome if there was a terraforming 'simulator' built into Aurora where you can plan out the proposed atmosphere and be shown what the end result would be (temperature, atmosphere density, colony cost, etc.)
I have added an evaporation cycle following condensation that will stabilise water vapour in the atmosphere of a planet with liquid water at a level of:
Atmospheric Pressure * (Hydro Extent / 100) * 0.01 atm. For Earth that would be 1 * (70/100) * 0.01 atm = 0.007 atm
That atm * 20 is the % of the planet's surface that loses water. For Earth that would be 0.14%
As the water vapour is removed from the atmosphere, it will replenish from the surface water.
Maybe have a "queue" of atmosphere changes you will make, and then display what the target values will be after entire queue is executed?Either a queue or having the option to set the final atmosphere composition and the TFs slowly insert/remove all elements at the same time (if terraforming has 0.02 atm these should of course be split up on all involved elements, not 0.02 for all at the same time).
Queue could also display expected dates when changes will be finished based on current terraforming rate.
one is able to drop asteroids/comets (whole new game mechanic that probably isn't worth it)You mine water at other planets, then use mass drivers to lob it at the body you are terraforming.
Am I the only person who thinks that with the changes Steve has already made we have more than enough terraforming detail? I'd much rather Steve moved onto other areas now.
Usually there are loads of scientists in my scientist-pool - and they don't do anything. How about adding a new team-function: Science-Team. And those can be set to research a project instead of a single scientist... :D
I'm confused about the hydro/atmo water balance. Is the 0.14% above a rate, or is it an equilibrium level? (I would vote for equilibrium level.) If it's an equilibrium level, then how does that square with what I think I read in the rules change, which is that 20% hydro requires 1 atmo of water (which seems way to high, given that Earth has 75% hydro without having 3.75 atmospheres of water vapor :) ).
- Maybe hydro system shouldn't be controlled by terraforming at all (since it takes so much material). Either you take what you get (without being able to change), or one is able to drop asteroids/comets (whole new game mechanic that probably isn't worth it), or hydro percent change costs 10s of thousands (or even millions) times as much as gases when done through terrarforming.
Am I the only person who thinks that with the changes Steve has already made we have more than enough terraforming detail? I'd much rather Steve moved onto other areas now.
I don't really have a problem with terraforming being a real challenge for larger worlds. IMHO terraforming should be a massive undertaking, not something you can accomplish in a half-hearted fashion over a couple of years!My problem with this logic has always been 'larger worlds'. The overall balance of terraforming time is a question probably best answered by having a box labeled 'racial terraforming tech multiplier' so that players can set it as they like. But saying 'no, the scaling is OK because big worlds take a long time' makes no sense when small worlds are still fast.
I don't think you're the only person, but you must also understand that the terraforming mechanics are of great importance to me, and apparently, many other people. What attracted me to Aurora was not the combat system, but the incredible detail of the star systems, allowing me to take an asteroid and turn it into an important naval base and industrial node (in theory as up until now the costs of orbital habitats and underground infrastructure was far too high). Seeing my colonies grow in various, sometimes contrived circumstances, is what kept me glued to the game, despite its many issues, for... I don't know. Six years now? Maybe even longer I think. Anyway, because of that everything that has to do with ability to colonise and change bodies to my will, allowing me to create new nations in the most unlikely of places, is of utmost importance to me. And apparently many other people judging by the response.
Also, Steve, I've brought gravity scaling up at least three times, and been ignored each time. Is there a reason for this? I ask so that I don't keep annoying you by bringing it up if you've decided that you don't want to include it for some reason.
I'm confused about the hydro/atmo water balance. Is the 0.14% above a rate, or is it an equilibrium level? (I would vote for equilibrium level.) If it's an equilibrium level, then how does that square with what I think I read in the rules change, which is that 20% hydro requires 1 atmo of water (which seems way to high, given that Earth has 75% hydro without having 3.75 atmospheres of water vapor :) ).
The water vapour added to atmosphere condenses into liquid water on the surface. It doesn't remain in the atmosphere.
Only 0.001% of water on Earth is in the atmosphere, which is about 2-3% water vapour. You would actually need far more water vapour then specified in Aurora to create surface water but I am trying to strike a balance between realism and playability.
By volume, dry air contains 78.09% nitrogen, 20.95% oxygen,[1] 0.93% argon, 0.04% carbon dioxide, and small amounts of other gases. Air also contains a variable amount of water vapor, on average around 1% at sea level, and 0.4% over the entire atmosphere. Air content and atmospheric pressure vary at different layers, and air suitable for use in photosynthesis by terrestrial plants and breathing of terrestrial animals is found only in Earth's troposphere and in artificial atmospheres.
Have you at all thought about adding in things like AI/automation options for certain ship components that makes them more effective/efficient/need less crew?Yes, racial tech in the style of fuel consumption one that instead lowers the required crew was suggested multiple times. See e.g. Reduced Crew, Focused Mines, other things (http://aurora2.pentarch.org/index.php?topic=6581.msg67273).
I would like to see an option on the Task Group menu to see how long a particular move command is expected to take. That way, if I click on Move To Wolf when I MEANT to Move To Wolf-Harrington, the time it takes might clue me in.There already are estimates for the first command and all commands of given TG, together with distance.
If it showed estimated times for refueling, loading cargo, etc, that would be awesome.
A few concerns about maintenance:
The current system reflects a consideration analogous to real life - beam and draught were a major limitation for shipbuilding, and things like large enough drydocks available for maintenance were a real cap for practical size of capital ships. One 100000t ship is a much bigger problem than 10 10000t ships. As I understand it, the interesting and not entirely unrealistic situation where modest bases can support large fleets of lesser ships/FACs but not a single capital ship will cease to exist with the planned changes.
Given that large ships get a few more toys (officer-related things, larger cap on engine size), that might not be good for balance.
A few concerns about maintenance:I'll very much second this. The infrastructure needed for a battleship is very different from the infrastructure needed to maintain a group of destroyers of the same tonnage. The easiest way to solve this is to make the max size and total tonnage separate. Let's say by a factor of 5, which should preserve much of the current balance WRT size, and also give a cap to how many ships you can park at a given base. The alternative is to have the tonnage cap scale with some factor of the total tonnage. A square root is probably too punitive, but using tonnage(thousands)^(2/3) seems to work well. It crosses with the current system at 125 modules/25,000 tons. Below that, you have a higher cap than the current system, above that, a lower cap. Tonnage^.75 only meets current system at 625 modules/125,000 tons.
The current system reflects a consideration analogous to real life - beam and draught were a major limitation for shipbuilding, and things like large enough drydocks available for maintenance were a real cap for practical size of capital ships. One 100000t ship is a much bigger problem than 10 10000t ships. As I understand it, the interesting and not entirely unrealistic situation where modest bases can support large fleets of lesser ships/FACs but not a single capital ship will cease to exist with the planned changes.
Given that large ships get a few more toys (officer-related things, larger cap on engine size), that might not be good for balance.
I'll very much second this. The infrastructure needed for a battleship is very different from the infrastructure needed to maintain a group of destroyers of the same tonnage. The easiest way to solve this is to make the max size and total tonnage separate. Let's say by a factor of 5, which should preserve much of the current balance WRT size, and also give a cap to how many ships you can park at a given base. The alternative is to have the tonnage cap scale with some factor of the total tonnage. A square root is probably too punitive, but using tonnage(thousands)^(2/3) seems to work well. It crosses with the current system at 125 modules/25,000 tons. Below that, you have a higher cap than the current system, above that, a lower cap. Tonnage^.75 only meets current system at 625 modules/125,000 tons.Do you suggest that a ship can use only one fifth of the whole pool of available maintenance at given location at max? That way a battleship may get only partially maintained (or not at all?) even when the amount of available maintenance (1000t per each module or facility) is bigger then the size of this battleship (but less than 5 times her size)? Or to which ratio is that 5:1 referring?
Thinking it over, I think I favor the first system. A ratio of 5 to 1 is a pretty reasonable estimate for support facilities, and it should come close to preserving the current balance.
Let's say by a factor of 5, which should preserve much of the current balance WRT size, and also give a cap to how many ships you can park at a given base. The alternative is to have the tonnage cap scale with some factor of the total tonnage. A square root is probably too punitive, but using tonnage(thousands)^(2/3) seems to work well. It crosses with the current system at 125 modules/25,000 tons. Below that, you have a higher cap than the current system, above that, a lower cap. Tonnage^.75 only meets current system at 625 modules/125,000 tons.You seem to have forgot that the capacity of the facilities have been increased to 1000 each. Keeping your 2/3 power makes something like t(x) = 1000x, m(x) = 1000x^(2/3). t(x) equals total capacity, m(x) equals maximum ship size. For an example of 100 facilities; the current system lets you have an infinite number of ships 20000 tons and smaller. The new calculations give a total tonnage of 100000 tons while the maximum tonnage equals ~21500. You can support 4 ships at that maximum tonnage with some space left over. For a farther end example for a "big ship" doctrine, 1250 facilities; You can supply an infinite number of ships 250000 tons and smaller currently. The new calculations give a max ship size of ~116000 tons with a total of 1250000 tons. Even doubling that to 2500 facilities wouldn't let you maintain a ship of 250000 tons again. You would need around 3900 facilities to field a 250000 tonned ship. I think we need to find out another formula.
Thinking it over, I think I favor the first system. A ratio of 5 to 1 is a pretty reasonable estimate for support facilities, and it should come close to preserving the current balance.
Do you suggest that a ship can use only one fifth of the whole pool of available maintenance at given location at max? That way a battleship may get only partially maintained (or not at all?) even when the amount of available maintenance (1000t per each module or facility) is bigger then the size of this battleship (but less than 5 times her size)? Or to which ratio is that 5:1 referring?I hadn't thought through exactly how maintenance would work if the ship was bigger than the size cap. But that is the essence of my idea.
You seem to have forgot that the capacity of the facilities have been increased to 1000 each. Keeping your 2/3 power makes something like t(x) = 1000x, m(x) = 1000x^(2/3). t(x) equals total capacity, m(x) equals maximum ship size. For an example of 100 facilities; the current system lets you have an infinite number of ships 20000 tons and smaller. The new calculations give a total tonnage of 100000 tons while the maximum tonnage equals ~21500. You can support 4 ships at that maximum tonnage with some space left over. For a farther end example for a "big ship" doctrine, 1250 facilities; You can supply an infinite number of ships 250000 tons and smaller currently. The new calculations give a max ship size of ~116000 tons with a total of 1250000 tons. Even doubling that to 2500 facilities wouldn't let you maintain a ship of 250000 tons again. You would need around 3900 facilities to field a 250000 tonned ship. I think we need to find out another formula.I hadn't forgotten that. The numbers you provide line up exactly with my calculations. Look at where my crossovers fell.
I thought there had already been extensive discussion without conclusion about what exactly "maintenance" represents. For instance, instead of dry docks you could also view maintenance facilities as launch pads for small repair drones. In that case maximum ship size is irrelevant, only the absolute number of repair drones available. Major structural repairs already need a shipyard, so not sure why maintenance would need to be done in a dockyard or hangar.Even drones would need more time to get to the furthest end of Big Ship :D . So to keep the maintenance level similar to Small Ships one would need more maintenance modules/facilities (drone pods located in more distant areas of given shipsite).
Even drones would need more time to get to the furthest end of Big Ship :D . So to keep the maintenance level similar to Small Ships one would need more maintenance modules/facilities (drone pods located in more distant areas of given shipsite).
I thought there had already been extensive discussion without conclusion about what exactly "maintenance" represents. For instance, instead of dry docks you could also view maintenance facilities as launch pads for small repair drones. In that case maximum ship size is irrelevant, only the absolute number of repair drones available. Major structural repairs already need a shipyard, so not sure why maintenance would need to be done in a dockyard or hangar.
adding some more limitation against bigger ships would only, in my opinion, bring us close to a situation like before.
Having your massive battleships be more problematic logistics wise then several smaller screens is a good thing, not a bad thing.
This is a "future" scenario, in which you can suppose EXTREME modularity in ship building. I would assume that the jump drive, say, of a battleship and a destroyer are actually pretty similar, just the battleship one has a lot more "small jump modules", thus being bigger. So I do not see a reason to add a "maximum ship size that can be maintained".Why would we assume that? The way the design system works seems to suggest the exact opposite. Jump drives are very finely engineered to their specific size, and you don't get any benefit from trying to build a jump drive that's 1 HS bigger/smaller than the existing one. A bigger ship is going to have bigger components.
That would only revert us back to the fact that you need like 150 or so maintentance facilities in order to maintain a battleship, and so you have just one or two planets who can do that, while everywhere else you cannot do any maintenance at all.So? Under the new system, you also need 150 maintenance facilities if you want to have 150,000 tons of ships supported there. Unless the typical maintenance station supported less than 1,000 tons in the old system, then you're actually going to be worse off. I usually built more than 5 of my large-size ships. If we pick an exponent like I've suggested, the crossover point is way above 150 stations, so it makes all ships except those that are really absurdly huge easier to build.
I still prefer linear and no limits, mind you. Just stating that an increase in maintenance time would be appropriate and preferrable in case a limitation of some sort has to be put in place, compared to a "hard block" which completely makes maintenance impossible if you do not have x facilities.I don't think anyone was suggesting that. There are already rules in place for dealing with total tonnages above the size of the facilities. We just apply those to individual ships that are above the cap. So a 30,000 ton ship at a facility with a size cap of 20,000 tons gets treated like a fleet totaling 30,000 tons at a facility with 20,000 tons of capacity.
I plan to stay with the new maintenance rules; partly for simplicity, partly to prevent unlimited ships being maintained by a limited set of facilities and partly to offset some of the previous limitations on larger ships. While possible to have some form of system that limits both total capacity and maximum ship size, I don't believe the additional complexity would result in a similar improvement in game play.While I agree that the current system goes too far in limiting larger ships and allowing unlimited FACs on 5 maintenance facilities, I think that a system where the maximum single-ship tonnage and total tonnage limits are the same goes too far in the opposite direction.
Overhauls will proceed at a slower rate (and use fewer MSP) if the total tonnage of the ships being maintained exceeds the Total Maintenance Capacity. However, ships undergoing overhaul will not suffer maintenance failures in this situation.I think we've just reinvented mothballing. Design a PDC with a single maintenance module, and then build it on a moon. Then send all of your extra ships to overhaul there. Obviously, the overhaul rate would be incredibly slow, but they're not suffering maintenance failures, and their clocks are effectively stopped.
This is a "future" scenario, in which you can suppose EXTREME modularity in ship building. I would assume that the jump drive, say, of a battleship and a destroyer are actually pretty similar, just the battleship one has a lot more "small jump modules", thus being bigger. So I do not see a reason to add a "maximum ship size that can be maintained".
That would only revert us back to the fact that you need like 150 or so maintentance facilities in order to maintain a battleship, and so you have just one or two planets who can do that, while everywhere else you cannot do any maintenance at all.
I just spotted a major loophole in the maintenance rules:I think we've just reinvented mothballing. Design a PDC with a single maintenance module, and then build it on a moon. Then send all of your extra ships to overhaul there. Obviously, the overhaul rate would be incredibly slow, but they're not suffering maintenance failures, and their clocks are effectively stopped.
My suggestion would be to introduce a size cap and prevent overhauling if the ship is above that cap. There are obviously other ways to solve this problem, and my bias towards some sort of size cap (there are many possible implementations) is obviously showing.
Does a ship in overhaul count as the quadruple of it's tonnage? Otherwise, there is another problem with the new maintainence rules: If my facilities can support a total tonnage of T at any time, they can actually support 4*T with proper micromanagement. By having three fleets away from the facilities but right next to, and one in overhaul, and then cycling them in short cycles into overhaul.I don't really follow this? There is a rather long time penalty for a ship to come out of overhaul early, which would prevent you moving it out of maintenance range.
If you switch them every five days, then every fleet will only take these five days to finish their overhaul, as overhauling reverses the clock at four times the normal speed. So you don't have to take them out early.That makes sense. Of course its tedious beyond belief, and clearly abusing the system though, so I'm not sure why they wouldn't just play with maintenance turned off instead?
Sorry to bring this up again in case I missed a major rules change... but with the new maintenance system, aren't we encouraged to simply build hangar PDCs instead of in-orbit maintenance?
In the current version, that is a more or less balanced option - completely eliminates ongoing costs, but is usually much more expensive upfront (at least for large numbers of small-ish ships) and limits flexibility.
In the upcoming version, it looks like maintenance facilities are going to be more expensive than equivalent hangar capacity and should be built only for the ability to overhaul, if at all.
Sorry to bring this up again in case I missed a major rules change... but with the new maintenance system, aren't we encouraged to simply build hangar PDCs instead of in-orbit maintenance?Have we had any indication that ships in hangars won't consume MSPs anyway? I can't see a yes/no answer anywhere but don't think you should assume they won't.
In the current version, that is a more or less balanced option - completely eliminates ongoing costs, but is usually much more expensive upfront (at least for large numbers of small-ish ships) and limits flexibility.
In the upcoming version, it looks like maintenance facilities are going to be more expensive than equivalent hangar capacity and should be built only for the ability to overhaul, if at all.
Great game!
I would love if we can have a forced stop of time at every new year and be presented with a yearly report that shows the progress of your Empire. If we can extract that to an excel document would be a very nice bonus.
(and also reading all nine Safehold books in a row :)).
Did you finish them yet. Their very good. A couple of the later books I thought were a little long winded at times.
But, after ready those, it's hard to find books that are as well written. Trying to push through 1634 but the writing is just awful at time.
If you can read through all nine Safehold books straight then the focus and concentration needed to finish C# Aurora should come easily to you ;D
(Is there going to be a next one? That series felt... kinda thoroughly finished)
Hi,
About Safehold, it is just the beginning:
next step : finish the church (and the inquisition in the harchong empire)
Then face the return of the archangels (and the rakurai)
So you can start the main plot : the Gbaba !
With perhaps a bonus link with the dahak trilogy...
Hubert
With perhaps a bonus link with the dahak trilogy...
Hubert
Read this little story that Weber wrote, if you haven't already.
http://forums.davidweber.net/viewtopic.php?f=7&t=4078&hilit=dahak
(and also reading all nine Safehold books in a row :)).Blast it, Steve. For once, you've even managed to come up with a good enough excuse that I can't be mad at you for it.
Read this little story that Weber wrote, if you haven't already.
http://forums.davidweber.net/viewtopic.php?f=7&t=4078&hilit=dahak
Already done, I'm a big fan, but thanks OJsDad for the link.
Erik, about technology, I don't see why both universe are not compatible.
In Safehold, there is IMHO not a lot of hard data about federation tech.
The sole real conflict would be that Gbaba are isolationnist and attacked only after the federation found them, while achuultani are actively looking for sentient to exterminate. Would safehold be the seed of the first imperium ?
Let's wait and see (not too long I hope)
- Research progression may need to be non linear if you don't want the design of such large engines to become a major hurdle to use given the way current research costs scale up with larger engines.Well, since research cost would be the only thing stopping people from always using the maximum size engines because of the huge amount of fuel they save, I would actually leave that the way it is.
I disagree - we can't know for sure until someone crunches the numbers and even then, it depends on your empire and fleet size.
I think the idea is good, but it sounds like it would also hurt small fighter/FAC beam ships.
Ayup. Right now, when I design fighters, I design a whole bunch of size 1 engines with different efficiencies. Because the fuel efficiency difference between a size 1 engines and a size 5 is really negligible. But with the new system, going for engine redundancy instead of engine size comes at a HUGE fuel cost.
It really kills the beam fighters, because there is no way you can have a fighter that is fast enough to catch a large ship that is so much more fuel efficient than it. A capital ship may use less fuel than a single fighter.
Granted, cheese like reduced sized spinal lasers on fast fighters to rip unshielded swarms apart becomes more difficult, but I think there are some real issues with having THAT much fuel efficiency difference between ships.
It really kills the beam fighters, because there is no way you can have a fighter that is fast enough to catch a large ship that is so much more fuel efficient than it. A capital ship may use less fuel than a single fighter.
Granted, cheese like reduced sized spinal lasers on fast fighters to rip unshielded swarms apart becomes more difficult, but I think there are some real issues with having THAT much fuel efficiency difference between ships.
So, the new changes to engines are now in. I rather like them, especially ... AND reduced efficiency of size 1-10 ship engines. It really encourages having bigger engines for bigger ships and I think that's nice.
From a tactics point of view fighters are really more weapons systems like missiles than independent warships.
...
The mere fact that they're fighters means that the fuel use is less likely to bother them on a strategic level since they'll remain docked in their carriers when not fighting. If anything I think the losers here will be smaller escort ships; larger engines mean that big warships will have better fuel economy.
Ofcourse you normally want to crank up the power mod on the fighters more then you capital ships as well, but that does give them a significant speed advantage, so you get something important for it in return.
Maybe it's time to dust off my idea for parasite warships that remain in hangers until battle starts :)
Which mechanics actually encourage these assumed characteristics of fighters? I think that is more player habit or roleplaying things how they play out in various SF settings. In some ways, I think we are more encouraged to use fighters designed for years of independent operations and full-sized parasite warships designed for 3-day missions.
Hey, Steve, later on the development path, will the AI shipbuilding/design doctrine and superficial (potentially forced) behaviors be changed any to reflect the new changes to logistics and fuel?
For instance, cutting down the "allowed traveling range" of AI ships with bad fuel/maintenance economy, making them use the new tech that's been rolled out, making them at least superficially use the new deep space hangars, etc.
This is assuming you're not gonna tackle AI that actually suffers from and directly handles these logistics drawbacks, of course.
Abstract the individual ships away. Not completely, of course, but they don't need to be tracked perfectly 100% of the time.This abstraction becomes a problem for multiple player controlled lines, especially when the hostile nation has a DSTS anywhere in the system.
It should be (relatively) trivial to compute how densely populated each shipping lane is, it's just distance between each destination divided by # of ships on the lane. From there we can get a figure for how quickly cargo is moved. It also can handle commerce raiding. When a foreign (or maybe only enemy?) ship approaches the route, a dice-roll, based on the lane density, can be made to decide whether any ships are there. If the roll succeeds, one or more of the ships on the line are pulled from abstraction and made concrete. This is done before they are detected; the approaching ship will need to pass the usual detection checks you would expect from Aurora. If the civilian ship survives the encounter, it is de-spawned at some point and put back in the abstraction. Possible good times for de-spawning include when either this ship or the enemy ship leave the current system, or when some suitably large distance between the ships is achieved.
This should dramatically cut down on the processor overhead caused by civilian shipping. The number of routes will never be higher than the number of ships. You do not need to do any movement calculations on the routes. The routes themselves do no detection calculations. Further, fewer things will have to do detection calculations on them or the ships on them.
On to your question: Mostly the scaling of sensor footprint and fuel use. A very simplified take on it:
The reduction of sensor footprint by using fighters for missile delivery is very beneficial. If speed is no major objective, the losses in fuel efficiency won't be too relevant, and giving them a decent mission life is more economical than putting them in an expensive, highly visible and vulnerable carrier.
For fast, high-powered beam attackers, fuel consumption is a concern even if they spend most of their time in a hangar. On stressed ships, weight is the enemy; carting around more fuel means we need even more high-powered engines to maintain speed. Also, if I'm willing to spend the resources on speed, I may also want long beam range to take little or no return fire. Speed + long-ranged weapon + associated FC usually doesn't fit into 500t.
Sensor footprint isn't a major option if we need to cross the AMM envelope.
Most of my current fighters in Aurora end up around 5-10% of their tonnage fuel, and I think similar ratios, maybe upwards to 15% max might be motivated with the changes.
Sensor footprint isn't a major option if we need to cross the AMM envelope.
This abstraction becomes a problem for multiple player controlled lines, especially when the hostile nation has a DSTS anywhere in the system.Ships would not be de-spawned until some satisfactory condition is met. Perhaps no enemies (or foreigners) in system. Perhaps de-spawn when the enemies/foreigners are a suitably large distance away, preferably far outside detection range. Or some combination of these. Ships would not de-spawn when detected, or even when anywhere near detection.
Given sufficient thermal coverage, you'll have players annoyed in frustration that their quarry just vanished due to ranges, or what have you, on top of sheer unpredictability of the target abstraction.
Even in single player, a similar issue crops up: you can't effectively defend your shipping lines if you don't know where the ships in it are.
Abstraction would be and interesting option to work on, however it remains to be seen if anyone will actually have a problem with the civilian shipping in C# due to the major performance increase.With abstraction, you don't need this arbitrary culling of ships. Look at real life, we have civilian shipping of all sizes, not just huge Panamax freighters. Abstraction will allow shipping of all sizes to still exist.
Smarter ship usage by the AI would come a long way to avoiding slow downs, already major gains was made by giving civilians more power to cull or upgrade their ship size, similar performance gains might be made by making civilians less efficient when it comes to picking up and delivering things. For instance large ships picking up multiple cargos that are near each other, individually each delivery might take longer, but as only one large ship is being used for multiple orders it's more efficient.
There is already an 'allowed travelling range' for AI carrier-based fighters so I could extend that to ships. However, I am considering adding fuel use to the AI. With the improved execution speed there should be scope for adding more complex AI behaviour. Not sure yet about AI maintenance.If you do that then you need to make sure the AI can create tugs and/or supply ship logic to go out and refuel to fetch the stranded ships if they become unlucky enough to get stranded in the first place.
If you do that then you need to make sure the AI can create tugs and/or supply ship logic to go out and refuel to fetch the stranded ships if they become unlucky enough to get stranded in the first place.
I suppose one option might be to have the AI use fuel and attempt normal refuelling and tanker ops, but to still allow AI ships to operate at maybe 25% of normal speed when out of fuel and restrict them to 'return home and fuel' orders. That creates 90% of the restrictions for full fuel use and avoids any situations that the AI would find difficult to handle.
Carronades still kinda suck, but at least their cost reflects that a little better. I still don't know if I'd really ever want to use them, even with the sensor/engine nerfs that are going to Make Beams Great Again™ and force missiles to pay for it. I think they either need double damage across the board, the ability to be turreted, or both. Maybe they could benefit from size reduction techs?
Carronades are pretty horrible weapons for JP defense barges, to be honest. The reason is that movement happens before weapons fire, so in the 5 second increment the enemy ships will move off the JP and because carronade falloff is so extreme, 1/(1+range/10,000km), even a relatively low speed ship will be taking a third or less damage from the carronades. And that shot is all you're going to get. If you want a slow ship that guards jump points, you're honestly probably best off with a bunch of box launcher missiles with very short (well, short for missiles, so still millions of km) ranges.Last I checked, standard transits cause FC, sensor, shield, and command jam, leaving the jumper helpless.
If you want to use carronades efficiently you need to be absolutely sure that they'll be firing from a range of less than 10,000 km, and that means putting them on fast ships.
Last I checked, standard transits cause FC, sensor, shield, and command jam, leaving the jumper helpless.
It's much less time for squadron jumps, but i don't think they'll be moving immediately.
That said, squadron jumpers can already appear a ways off from the point, making it hard to intercept them in reasonable carronade range.
Considering that carronades are still literally just infrared lasers, and suffer the same fire rate penalties for capacitor tech per damage, you're probably just better off padding that tonnage with microwaves, mesons, railguns, etc instead. Same effective range, more effective damage per ton for the most part, unless a carronade alpha strike would put a meaningfully big hole in whatever you're hitting in one shot.
I intend to stay with the current model for civilian shipping. I hope that the faster execution speed in C# Aurora will significantly reduce any slowdown from civilian shipping.
Carronades are pretty horrible weapons for JP defense barges, to be honest. The reason is that movement happens before weapons fire, so in the 5 second increment the enemy ships will move off the JP and because carronade falloff is so extreme, 1/(1+range/10,000km), even a relatively low speed ship will be taking a third or less damage from the carronades. And that shot is all you're going to get. If you want a slow ship that guards jump points, you're honestly probably best off with a bunch of box launcher missiles with very short (well, short for missiles, so still millions of km) ranges.Is there some meta reason we're assuming that jump point pickets have to be slow?
If you want to use carronades efficiently you need to be absolutely sure that they'll be firing from a range of less than 10,000 km, and that means putting them on fast ships.
Is there some meta reason we're assuming that jump point pickets have to be slow?
Just efficiency reasons. Fast pickets are generally a bad idea since it's expensive and no matter how fast you make them you can't be sure they'll be faster (or have better initiative) than whatever comes through.It's not that expensive if they focus on it. I've used a planet-based FAC fleet as jumpgate pickets before and whilst that's not quite the same, I can certainly imagine building relatively small, relatively fast destroyers with cheap carronades to sit on a jump point and harrass whatever comes through. That being said, I have never really used carronades before as I've come to the same conclusions most people have that they're kinda useless overall, so I'm not sure how bulky they are and how feasible that specific idea is.
Is there some meta reason we're assuming that jump point pickets have to be slow?I put forth the monitor thing. It works well enough in the specific scenario that I outlined, which for some reason got ignored. When you need to get cheap ships to guard a JP quickly, carronades are a good weapon system to put on cheap monitor hulls. You'll take out JG construction ships quickly as well as certain spoiler ships and surveyors and such. By the time you need to worry about multi task group assaults coming through, you should have a proper defence fleet waiting.
So maintain same rules for all engines and keep missile ranges as they are (and missile fuel a minor consideration) or keep the x5 modifier and make fuel a serious consideration for missiles.
Thoughts?
snipped
With the shield changes, I think I'm misunderstanding something.
If a HS10 shield is equivalent to the shields we currently have (100% of VB6 shields) and a HS40 shield is twice as strong (200% of VB6 shields), why would I ever use a HS40 shield when I could use 4x HS10 shields for twice the strength of a single HS40 shield and half the recharge time?
Recharge time is per shield module, right? So if I have 4 size 10 shield modules that each take 300s to charge, that's still just 300s to charge all 4 of them because all 4 are charging independently? Or is it 300s x 4 modules?
Recharge time aside, unless I've misread something it seems like 4x size 10 shield modules (1+1+1+1=4) is still twice as strong as 1x size 40 shield module (1 x 200% = 2.) Am I mistaken?
I think you are misunderstanding. What I understood is: If a 10HS shield has strength (say) 100 (10 strength per HS), a 40HS strength shield has double of that strength PER HS (20), so 800 strength. So you could have
4x10HS shields, total strenght 400.
1x40HS shield, total strength 800.
However, it is my understanding that the 40HS shield would recharge at half speed. So, say, if the 4x10HS shields recharge 1 point per second each, the 40 HS shield recharges 2 point per second.
So you have that the smaller shields recharge a total of 4 points per second vs the 2 per second of the larger shield
At least, that's how I undestood it. A tradeoff between strength and recharge speed.
I am currently working through the code for the various component designs (as you can probably tell from recent posts) and I have reached missile engines.
The new engine changes were intended to make all engine types (missile and ship) follow the same set of rules for size vs fuel efficiency. One impact of this change was that applying this new size modifier for fuel consumption would penalise missile engines. However, now I am in the missile engine code I have realised that the VB6 code applies a x5 modifier to fuel consumption for missile engines on top of the modifiers for size, fuel consumption tech and boost tech.
If I don't use this x5 modifier in C#, missile engines won't change very much in terms of fuel consumption vs VB6. The whole point of the changes was to have the same rules for all engines so if (for game play reasons) I wanted to keep the x5 modifier and reduce missile ranges, I need a reason for it. I think my original rationale was that missile engines were one use only and not designed for efficiency.
So maintain same rules for all engines and keep missile ranges as they are (and missile fuel a minor consideration) or keep the x5 modifier and make fuel a serious consideration for missiles.
Thoughts?
Engine Power: 8 Fuel Use Per Hour: 6.34 Litres
Fuel Consumption per Engine Power Hour: 0.792 Litres
Engine Size: 1 HS Engine HTK: 1
Thermal Signature: 8 Exp Chance: 10
Cost: 5 Crew: 1
Materials Required: 5x Gallicite
Military Engine
Development Cost for Project: 50RP
Engine Power: 2 Fuel Use Per Hour: 8 Litres
Fuel Consumption per Engine Power Hour: 4 Litres
Engine Size: 5 MSP Cost: 0.5
Thermal Signature: 2
Materials Required: 0.5x Gallicite
Development Cost for Project: 100RP
For comparative analysis. 1 HS Versus 0.5 HS Missile engine.I am currently working through the code for the various component designs (as you can probably tell from recent posts) and I have reached missile engines.
The new engine changes were intended to make all engine types (missile and ship) follow the same set of rules for size vs fuel efficiency. One impact of this change was that applying this new size modifier for fuel consumption would penalise missile engines. However, now I am in the missile engine code I have realised that the VB6 code applies a x5 modifier to fuel consumption for missile engines on top of the modifiers for size, fuel consumption tech and boost tech.
If I don't use this x5 modifier in C#, missile engines won't change very much in terms of fuel consumption vs VB6. The whole point of the changes was to have the same rules for all engines so if (for game play reasons) I wanted to keep the x5 modifier and reduce missile ranges, I need a reason for it. I think my original rationale was that missile engines were one use only and not designed for efficiency.
So maintain same rules for all engines and keep missile ranges as they are (and missile fuel a minor consideration) or keep the x5 modifier and make fuel a serious consideration for missiles.
Thoughts?
Regarding the latest shield changes: I like them with one caveat.
It is great that they no longer require fuel (can be kept on indefinitely, makes them more useful as a defense measure). It is great they are stronger the bigger they are. Once again, like for engines and generators, it makes sense that a bigger shield generator would have a bonus due to less miniaturization.
I am uncertain, however, about the fact they recharge for the same fixed amount instead of a proportional amount. Coupled with the fact that larger shields are comparatively easier to destroy, it makes me wonder what the possible usage of large shields will be.
I feel that shield regeneration is very important in a prolonged fight. I don't know if the added shield strength is going to be enough to justify going with one large shield compared to 5 smaller shields which would regenerate a lot faster, and would be harder to kill off entirely.
Missile engines should always feel different than shipboard engines. An engine is never just an engine. Missile engines operate under an entirely different set of circumstances than shipboard engines. For starters, they're much, much smaller, and the miniaturization of an engine is expensive and problematic. Try making a Ferrari engine operate at 1/1000th the size and you'll start to see what I mean. All kinds of hiccups will happen, unless you're working in some kind of theoretical vacuum.
To me, it makes sense that missile engine technology should lag slightly behind standard naval engine technology in terms of efficiency and propulsion, and they should also be dramatically more expensive, pound for pound. It's apples to oranges, really.
I say embrace the divorce of the two systems, missile engines and shipboard engines. To me they've always seemed like they should be two different techs in the same category (Power and Propulsion, obviously.)
I am currently working through the code for the various component designs (as you can probably tell from recent posts) and I have reached missile engines.
The new engine changes were intended to make all engine types (missile and ship) follow the same set of rules for size vs fuel efficiency. One impact of this change was that applying this new size modifier for fuel consumption would penalise missile engines. However, now I am in the missile engine code I have realised that the VB6 code applies a x5 modifier to fuel consumption for missile engines on top of the modifiers for size, fuel consumption tech and boost tech.
If I don't use this x5 modifier in C#, missile engines won't change very much in terms of fuel consumption vs VB6. The whole point of the changes was to have the same rules for all engines so if (for game play reasons) I wanted to keep the x5 modifier and reduce missile ranges, I need a reason for it. I think my original rationale was that missile engines were one use only and not designed for efficiency.
So maintain same rules for all engines and keep missile ranges as they are (and missile fuel a minor consideration) or keep the x5 modifier and make fuel a serious consideration for missiles.
Thoughts?
I am currently working through the code for the various component designs (as you can probably tell from recent posts) and I have reached missile engines.
The new engine changes were intended to make all engine types (missile and ship) follow the same set of rules for size vs fuel efficiency. One impact of this change was that applying this new size modifier for fuel consumption would penalise missile engines. However, now I am in the missile engine code I have realised that the VB6 code applies a x5 modifier to fuel consumption for missile engines on top of the modifiers for size, fuel consumption tech and boost tech.
If I don't use this x5 modifier in C#, missile engines won't change very much in terms of fuel consumption vs VB6. The whole point of the changes was to have the same rules for all engines so if (for game play reasons) I wanted to keep the x5 modifier and reduce missile ranges, I need a reason for it. I think my original rationale was that missile engines were one use only and not designed for efficiency.
So maintain same rules for all engines and keep missile ranges as they are (and missile fuel a minor consideration) or keep the x5 modifier and make fuel a serious consideration for missiles.
Thoughts?
Scaling missile engine fuel consumption by how much it's beyond your safe long term engine boost tech is a good idea. It gives you the option to deploy extremely fast missiles but of short range, which work well with sensor boats, or as an advanced technology option you can go for a slower missile with longer range and a smaller warhead and a sensor package as a fire and forget/seeker missile.
It's also easily justified by noting 'more power' beyond your ability to properly control leads to lower efficiency engines, solved by shoving in more fuel than can be burned. Rather like an after burner actually, it just ruins the engine and turns it into a one shot drive.
Well, earlier I was mistaken, because I almost never reach high tech levels (I play conventional starts).
As such I believed that the maximum engine power modifier would eventually reach the same boost level you can apply to missile engines, thus removing the penalty.
Instead I checked and (assuming the wiki is sort of accurate), you can only normally reach a x3 modifier on engine boost, while the missile maximum boost goes higher than that. So there will always be a penalty if you boost your missile speed to the maximum.
It still does seem to me that average-speed missiles will have the same insane range as before, though. And it's... well, too long I think. I'm just hoping the changes to sensors can somehow mitigate the problem.
Are we getting hyperdrives back? I got one 90% power anomaly on a planet 1.392 LIGHTYEARS from the primary. It took 9 years for the survey ship to reach it. :'(
Very-long-range missiles, probably relying on spotter craft, will be possible. However, compared to the current version they will pay a much higher performance penalty. Imo that's a good thing; currently there's a rather narrow band of reasonable trade-offs dictated by your tech.
In my opinion it should not be possible to design missiles that are fast (considering tech level), long ranged (once again, considering tech level) AND small. If it is possible to build such a missile, then there's a balance problem and I think in VB6 Aurora there was one.
Both for realism and for improved gameplay, I would like it if people were forced to make choices, to use tradeoffs. So you could have
- A missile that is fast and long ranged, but not small (bigger engine and more fuel carried) OR
- A missile that is fast and small (sacrifices range, does not carry much fuel) OR
- A missile that is small and long ranged (sacrifices speed for this)
However, unless you boost speed very much it seems to me that range will stay more or less the same as before.
Personally I don't like shields being decoupled from fuel usage, but only because I'm a fan of the idea of them requiring power plants, and power plants needing fuel anyway. XD.
It'd be cool to have shields actually require a power plant on the ship in order to be active, like beam weapons.Don't shields already cost boronide? Figures that the power plant would already be built in.
Quality-of-life suggestion here:Well, it's easy, really. Just treat the magazines as multiples of 20 per HS, reduced by tech level percentage.
Can the magazine design screen be a little smarter? I'm thinking that you could have the player pick the size, and the game calculates the capacity, or the player pick the capacity and the game calculates the size. Currently the player only can pick the size.
Isn't that what already happens? I could be wrong, but when I've rearmored hulls in the past, the weight dropped for the same number of layers of armor.
What this means in practice is that a max boosted (x6) missile will have twice as much speed as a missile with x3 boost, but pay for that speed by having just 4%!!! of it's maximum range...I guess that will really hit AMMs, where you will always take the 6x boost. Is this the end of the AMM barrage as a useful anti-ship weapon? It's hard to tell but it feels like this would potentially drop AMM ranges inside beam ranges for equivalent technology?
On another note, I'm a little sad about the loss of short-range missile barrages ignoring regular point defence. For purpose-built missile brawlers, this changes little because we have other ways of rendering PD irrelevant... but it was a very flavourful desperation tactic for regular missile ships in case they couldn't overcome defences.
I guess that will really hit AMMs, where you will always take the 6x boost. Is this the end of the AMM barrage as a useful anti-ship weapon? It's hard to tell but it feels like this would potentially drop AMM ranges inside beam ranges for equivalent technology?
Also worth bearing in mind you can now create missiles and launchers that are size 1.1 or 1.2, etc. so the AMM no longer has to be exactly size 1.
I don't like the changes to missile engines. The old system, where you had a flat multiplier for engine power, seemed to make more sense, and it's less likely to create odd results. Missile engines will be designed differently from ship engines. This happens in real life. Only penalizing boosted engines makes multi-stage missiles more likely, particularly with the changes to launcher ROF (which I am very much in favor of, BTW). A flat x2 to fuel burn would make the whole system make more sense.Missile sized engines are already being penalized in the new system, already, due to their size and the size penalty changes.
Missile sized engines are already being penalized in the new system, already, due to their size and the size penalty changes.
Where is this change? I don't think I've seen that announcement.
Regarding the sensor model: Have the implications for active sensors on missiles/buoys been fully considered? Tiny sensors will become hugely more powerful. If that in itself is not considered problematic... TH and EM ones will probably not be competitive at those sizes, is that fine?Why would better sensors on missiles be a problem?
This is simply because in space the best method of propulsion you've got is tossing out very hot gas out the back end of the ship.Nuclear Pulse Propulsion is theoretically better than tossing out gasses (hot or otherwise).
On the topic of launcher reload times - can we get a change to make canister\subcaliber shots worthwhile?
Id like to see a reduced reload time from my size 5.5 launcher if Im throwing 4.9sized missiles.
Im not certain what the math should look like though, because while a size 100 tube should NOT be throwing size 1 missiles like water from a fire hose, it should also not take hours to slide a AMM into a torpedo tube...
Hmmm, I'm not sure if that makes a lot of sense mechanically/realism wise...certainly not beyond some point. Maybe something like up to a 25% reduction for a missile half the size?
I'd rather have the load times stay the same regardless of what you load into it, but have the option to design missile 'canisters' that can fit multiple smaller missiles into a large tube, with some size penalty. Say 25% initially and improvable with tech to 5% or even 0% - so a size 8 launcher could take a canister with 2 size 3s, or 4 size 1.5s, etc. Shots out of a canister like this could be fired individually or all at once, and they'd also work for box launchers (the idea is inspired by the twin/quad packed self-defence missiles real VLS systems can take).
Hmmm, I'm not sure if that makes a lot of sense mechanically/realism wise...certainly not beyond some point. Maybe something like up to a 25% reduction for a missile half the size?Um. Already ingame.
I'd rather have the load times stay the same regardless of what you load into it, but have the option to design missile 'canisters' that can fit multiple smaller missiles into a large tube, with some size penalty. Say 25% initially and improvable with tech to 5% or even 0% - so a size 8 launcher could take a canister with 2 size 3s, or 4 size 1.5s, etc. Shots out of a canister like this could be fired individually or all at once, and they'd also work for box launchers (the idea is inspired by the twin/quad packed self-defence missiles real VLS systems can take).
Um. Already ingame.Except this requires you to launch all of them at once, instead of being able to fire them as desired.
[image]
Well, plasma is not a gas technically, but Tsiolkovsky rocket equation doesn't mind if you tossing out plasma or very hot gas.I don't know if that was at me, but nuclear pulse propulsion doesn't involve "tossing out" plasma either and although plasma is involved, throwing things out the back isn't what has the propulsive effect (which is what was implied by the post I was quoting). It involves throwing a nuke out the back and riding the explosion.
Well, plasma is not a gas technically, but Tsiolkovsky rocket equation doesn't mind if you tossing out plasma or very hot gas.I don't know if that was at me, but nuclear pulse propulsion doesn't involve "tossing out" plasma either and although plasma is involved, throwing things out the back isn't what has the propulsive effect (which is what was implied by the post I was quoting). It involves throwing a nuke out the back and riding the explosion.
nuclear pulse propulsion doesn't involve "tossing out" plasma either and although plasma is involved, throwing things out the back isn't what has the propulsive effect (which is what was implied by the post I was quoting). It involves throwing a nuke out the back and riding the explosion.Ermmm... do you think, that nuke is not tossing some plasma back?.. :)
@ iceball3: Railguns cease to be worthwhile when your capacitor tech can't keep up; 50cm is pushing it. Rule of thumb: RP-hungry and expensive for the capability with RoF 10, markedly inferior to lasers with similar single-shot-damage at RoF 15. 50cm railguns may be halfway competitive because they're a big bump up from 45cm.
Particle beams don't quite reach maximum fire control range, and the very high end has some theoretical applications for attempted instant-kills at very long range (more so once lances are available). Small ones may be more practical most of the time (decent DPS at range, on a budget), but there are cool and flashy things you can do with large ones.
The larger Meson sizes appear to be pointless though.
Does anyone else find it strange that orbital stations have to have an Orbital Habitat module, even if the station isn't actually meant to house any people?And where do you propose those miners stay on their 120 year or so mission?
Why do I need to have a habitat on a sorium mining platform if I want to build it with my factories? I don't need a habitat to have sorium harvesters on a ship, why do I need one on a station?
@ iceball3: Railguns cease to be worthwhile when your capacitor tech can't keep up; 50cm is pushing it. Rule of thumb: RP-hungry and expensive for the capability with RoF 10, markedly inferior to lasers with similar single-shot-damage at RoF 15. 50cm railguns may be halfway competitive because they're a big bump up from 45cm.Hmm. Guess I was mistaken about the particle beams.
Particle beams don't quite reach maximum fire control range, and the very high end has some theoretical applications for attempted instant-kills at very long range (more so once lances are available). Small ones may be more practical most of the time (decent DPS at range, on a budget), but there are cool and flashy things you can do with large ones.
The larger Meson sizes appear to be pointless though.
Does anyone else find it strange that orbital stations have to have an Orbital Habitat module, even if the station isn't actually meant to house any people?I imagine it is some manner of "City-in-the-sky" sized structural supports and compartmentalization that allows the object to be built in the first place, and with the sheer mass, the living spaces are sort of rolled up into it for the heck of it.
Why do I need to have a habitat on a sorium mining platform if I want to build it with my factories? I don't need a habitat to have sorium harvesters on a ship, why do I need one on a station?
And where do you propose those miners stay on their 120 year or so mission?Where do they stay if I build it in a shipyard?
Where do they stay if I build it in a shipyard?
New Class #4213 class Terraforming Base 25 750 tons 110 Crew 629.6 BP TCS 515 TH 0 EM 0
1 km/s Armour 1-77 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 1 PPV 0
MSP 15 Max Repair 500 MSP
Intended Deployment Time: 3 months Spare Berths 0
Terraformer: 1 module(s) producing 0.0015 atm per annum
This design is classed as a Commercial Vessel for maintenance purposes
New Class #4213 class Terraforming Base 277 700 tons 140 Crew 1140.2 BP TCS 5554 TH 0 EM 0
1 km/s Armour 1-379 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 1 PPV 0
MSP 3 Max Repair 500 MSP
Intended Deployment Time: 3 months Spare Berths 2
Habitation Capacity 50 000
Terraformer: 1 module(s) producing 0.0015 atm per annum
This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as an Orbital Habitat for construction purposes
If I need a habitat module to support the terraformer/sorium-harvester/asteroid-mine workers on the version that's made in a factory, why don't I need one on the version that's made in a shipyard? If the 110 crew of the shipyard version is enough to man a terraformer, why do I need a habitat module if I want to build it with factories?And why can't they do that if I build it in factories? Its not like the design has any fewer crew quarters if I include a habitat module. In fact, it has MORE.
This is not build-able in a factory:Code: [Select]New Class #4213 class Terraforming Base 25 750 tons 110 Crew 629.6 BP TCS 515 TH 0 EM 0
1 km/s Armour 1-77 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 1 PPV 0
MSP 15 Max Repair 500 MSP
Intended Deployment Time: 3 months Spare Berths 0
Terraformer: 1 module(s) producing 0.0015 atm per annum
This design is classed as a Commercial Vessel for maintenance purposes
This IS build-able in a factory:Code: [Select]New Class #4213 class Terraforming Base 277 700 tons 140 Crew 1140.2 BP TCS 5554 TH 0 EM 0
If I need a habitat module to support the terraformer/sorium-harvester/asteroid-mine workers on the version that's made in a factory, why don't I need one on the version that's made in a shipyard? If the 110 crew of the shipyard version is enough to man a terraformer, why do I need a habitat module if I want to build it with factories?
1 km/s Armour 1-379 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 1 PPV 0
MSP 3 Max Repair 500 MSP
Intended Deployment Time: 3 months Spare Berths 2
Habitation Capacity 50 000
Terraformer: 1 module(s) producing 0.0015 atm per annum
This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as an Orbital Habitat for construction purposes
I think the only answer is that its a way to nerf factory-produced stations. But I don't really think they NEED nerfed. The fact that they need a tug is a big enough nerf.
I imagine it is some manner of "City-in-the-sky" sized structural supports and compartmentalization that allows the object to be built in the first place, and with the sheer mass, the living spaces are sort of rolled up into it for the heck of it.
What I'm saying is, I do not understand why the addition of a habitat module allows it to be built in a factory instead of a shipyard. What about shipyards means I can get away with 110 crew instead of 50,000? The terraforming module is the same. Deployment time is the same. The habitat module is just dead weight on the factory version. Why don't I need those "city-in-the-sky" supports if I build it in a shipyard?
I don't mind having shipyards for actual ships, that's fine. Anything with an engine should have to use a shipyard, like it does currently. I just don't really see that its fair or necessary to have 250,000 tons of dead weight on a commercial station just so I can build it from factories.You can also prepare some ship parts with factories and complete it in shipyard. Much faster.
And why can't they do that if I build it in factories? Its not like the design has any fewer crew quarters if I include a habitat module. In fact, it has MORE."Intended deployment time 3 months"
This is not build-able in a factory:Code: [Select]New Class #4213 class Terraforming Base 25 750 tons 110 Crew 629.6 BP TCS 515 TH 0 EM 0
1 km/s Armour 1-77 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 1 PPV 0
MSP 15 Max Repair 500 MSP
Intended Deployment Time: 3 months Spare Berths 0
Terraformer: 1 module(s) producing 0.0015 atm per annum
This design is classed as a Commercial Vessel for maintenance purposes
This IS build-able in a factory:Code: [Select]New Class #4213 class Terraforming Base 277 700 tons 140 Crew 1140.2 BP TCS 5554 TH 0 EM 0
If I need a habitat module to support the terraformer/sorium-harvester/asteroid-mine workers on the version that's made in a factory, why don't I need one on the version that's made in a shipyard? If the 110 crew of the shipyard version is enough to man a terraformer, why do I need a habitat module if I want to build it with factories?
1 km/s Armour 1-379 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 1 PPV 0
MSP 3 Max Repair 500 MSP
Intended Deployment Time: 3 months Spare Berths 2
Habitation Capacity 50 000
Terraformer: 1 module(s) producing 0.0015 atm per annum
This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as an Orbital Habitat for construction purposes
I think the only answer is that its a way to nerf factory-produced stations. But I don't really think they NEED nerfed. The fact that they need a tug is a big enough nerf.
I don't mind having shipyards for actual ships, that's fine. Anything with an engine should have to use a shipyard, like it does currently. I just don't really see that its fair or necessary to have 250,000 tons of dead weight on a commercial station just so I can build it from factories.But that doesn't work, because you can use tugs and massive weapon stations as an alternative to warships. Even more so for carriers.
"Intended deployment time 3 months"Then why can I still use the ship version? It honestly just feels super arbitrary.
A habitat likely includes more facilities than would be included on a ship.
There is a momentum conservation law - you cannot change your momentum forward, if you don't toss smth back.Well, I would point out gravity assists which I don't believe require any "tossing" of anything - the principle is the same of course, the planet's orbit loses energy and gives it to a spacecraft, but it doesn't do this by tossing anything out of the spacecraft or bouncing things off of it, unless gravitons just have some odd physical properties - except that I clearly think your original post was NOT referring to plasma bouncing off the spacecraft from an outside source and that you're just trying to be right by rationalising. It was referring to normal rocketry and ion propulsion. I could also point out solar sails, which have the same general idea of having energetic particles bounce off the spacecraft to provide momentum, but at no point is anything expelled from the spacecraft. But I supposethat would still fit your revised statement as things are being bounced off the craft.
If I need a habitat module to support the terraformer/sorium-harvester/asteroid-mine workers on the version that's made in a factory, why don't I need one on the version that's made in a shipyard? If the 110 crew of the shipyard version is enough to man a terraformer, why do I need a habitat module if I want to build it with factories?It's because otherwise nobody would use shipyards and just use factories to build all ships. Or alternatively, building orbital stations of any size would be impossible as it is rare for shipyards to get that big.
I think the only answer is that its a way to nerf factory-produced stations. But I don't really think they NEED nerfed. The fact that they need a tug is a big enough nerf.
Person012345, what are you talking about?.. There was a point about propulsion drive, not a gravity maneuvre or light sail.First, you stated the best way to propel yourself was by "throwing hot gases out the back end of the ship". In doing so, you're clearly referring to propulsion methods which dominate the modern day, whereby you expel gas from the back of a ship and the equal and opposite reaction propels you forward. This quite the same as NPP (yes you expel an object from the ship, but this action has little to do with the propulsive effect - it's when it explodes and blasts the particles back towards you that the propulsion occurs). I also decided to throw in solar sails. Someone pointed out that plasma isn't a gas but totally counts (and fair enough) and you tried saying that technically that NPP totally counts because the particles bouncing off the back of the ship is totally the same as being expelled from the ship. Well, ok though I don't think this is what you meant. But then you also then said that you cannot change your momentum if you don't "toss something back". Assuming you're including particles bouncing off the ship, I thus pointed out gravity assists as a contradiction to your statement (unless gravitons have some odd physical properties that we have no evidence of so far). Unless I am very much mistaken, when using gravity to increase your speed, nothing needs to be "tossed out the back".
Surely, momentum conservation law is valid on close systems only, so if you want to use planet or star, then you must include them in your momentum equation.
But we are talking about NP propulsion drive (or another effective drive, not a cheap non-fiction one).
And NP propulsion drive is tossing plasma back, as I say. From the back of the ship, surely, not from the head. And it's how it works. Open drive camera - yes, but the same principle of tossing propulsion mass back, somehow or other.
And there is a principle of momentum conservation law, as it is.(https://cdn.discordapp.com/attachments/317001475882483712/321732552799027210/unknown.png)
*stuff*Ok, then if your entire point was about particles bouncing off the vehicle in the first place, then you were just wrong in the first place, since one of the more effective (though low power) ways of propelling spacecraft nowadays is ion propulsion. You can't wiggle out of it on technicalities because every way you try to justify it causes you to be wrong in some other way and the fact that you tried to is the only reason this conversation has continued. I'm done with it anyway because it's a stupid convo.
Ok, then if your entire point was about particles bouncing off the vehicle in the first place, then you were just wrong in the first place, since one of the more effective (though low power) ways of propelling spacecraft nowadays is ion propulsion. You can't wiggle out of it on technicalities because...because ion drive (and magnetoplasma too) have absolutely the same principle of tossing out some gas/plasma from the back of your ship. ::)
Can we just get back to discussing game stuff more directly?
3. Have Fun. If you aren't having fun, we'll send over someone to smack you with a trout until you do. ;)
As someone with an allergy for fish oil I claim this would be a completely un-fun thing to have happen.
New version certainly encourages smaller sensors, fighters or even buoys.
I hope the AI will be able to handle it. The less-than-linear scaling of sensor range to sensor size means that full-size ships will be very vulnerable to sneak attacks from fighters/FACs.
If all works out, we may get some interesting situations where light forces clash while trying to take pot shots at the other side's capital ships...
Perhaps the .25 minimum could be the subject of a few tech levels to reduce required size down although not reducing to current state.Minimal size of missile sensor: 4-3-2.5-2-1.5-1
However do like these changes, especially the reduced load times on larger launchers and box launchers from the off.
Hello!If there is a setting for ticks for "production week" there can as well be settings for date format. You could either leave it as default or have custom system - for simplicity just "hours in day", "days in month" and "months in year" with all months the same. Though you may then need new names for months. Eventually there may be just a function in event log exporting that outputs amount of seconds since the start instead of formatted date so players can then go and easily transform it to their time system after that, before writing their AARs.
I hope I'm posting in the right section for suggestions, and i have a (i hope) small one:
Would it be possible to include custom date and time keeping formats, that take a species' homeworld's characteristics (Year and Day) into account?
For example: in one of my current campaigns, my species' homeworld has a 20 hour day and a 282 day year. With this, a full "day" would be 20 hours instead of the standard 24 hours, and a "year" would have a duration of 282 days, instead of the fixed 360 days.
I apologise in advance if this is the wrong place to post, as I'm still new to the forum. :P
Cyborg29
I'm going on vacation for a couple of weeks so development will be temporarily on hold. On the bright side I will be hiring my own (small) ship for one week of that. My first attempt at the helm so I hope I don't encounter any Precursors :)Watch your deployment time, and don't forget to stock the magazines before leaving. ;)
Assuming I don't sink, I will be back toward the end of June.
(http://www.pentarch.org/steve/Screenshots/Boat.jpg)
Sneak peak of C# Aurora new tech"New Electric Hybrid"? So it can use both fuel from sorium and some other TN element?
"New Electric Hybrid"? So it can use both fuel from sorium and some other TN element?
Obviously it can use the power from the power-plants which are environmentally friendly since they don't use fuel at all ;)Let's then hope they don't explode. Also, doesn't using power plants for driving starve the lasers too much? Steve, have you packed enough of them so you can both drive and fire? Slowing down to fend of incoming missiles doesn't sound like the best idea,
Let's then hope they don't explode. Also, doesn't using power plants for driving starve the lasers too much? Steve, have you packed enough of them so you can both drive and fire? Slowing down to fend of incoming missiles doesn't sound like the best idea,
OK, let's calm down again.
English beer doesn't count Steve, it's more like custard than the nectar of life ;)I'll grant you that there is a lot of bad English beer (Tetley, Boddingtons, John Smith et al) but there is some very fine stuff, especially from the north - Old Peculier is my particular favourite :-)
Turret Update
I haven't read through all of the posts in this thread, so sorry if this has already been requested:
One thing that's always bothered me is the implementation of the Naval Organization tab in the Task Groups window. Don't get me wrong, I absolutely love the idea of it, and this is the only 4x space game I've ever played to even attempt anything like it, but it could still use some work. Specifically, being able to issue commands to all the ships in a branch (including sub-branches) when they're in different locations. I tend to organize my navy in an Armada->Fleet->Squadron->Individual Ships fashion, and I'm constantly separating and recombining task groups based on my needs. Being able to issue a single command to an entire armada or fleet to assemble at a specific location when individual ships are in different systems would be hugely beneficial to me. I admit that there are ways to accomplish this currently, but doing so is fairly cumbersome.
Thanks for your time and consideration.
As missiles (for now anyway), don't have thermal reduction or an option to travel below maximum speed, their thermal signature is equal to the power of their engines. Combined with the changes to passive detection, this means that missiles in C# Aurora will probably be detected by thermal sensors at much greater distances than in VB6 Aurora.
Sorry if this has been asked already but is it real time pause or more of the same from Aurora 4x?Like Sins of a Solar Empire?
Because the backend of a game where everything has to run in realtime is going to be completely different from a backend where you can expect to perform all the calculations and database work only when the turn (or in this case, time) is incremented?
Aurora is too detailed to do real time, you just could not give the game justice to get everything done in a real time fashion. Also next thing if it was real time then we see the dumbing down or automation of the game. Because of the fact you cannot control everything.
HOWEVER is there is to be any realtime, my recommendation is only for the 5 sec tick option, which instead of the current select the number of tick to happen it just is 5 sec on and 5 sec off button, this would work better in this version due to speed improvements and would make battles a little more easier. I never know how many ticks to do and the tick off button is not very responsive when you have more then you wanted ticks and need to turn it off.
Steve?Or a new option in the combat control screen? I agree that having to choose between changing your PD or your particle lance would be very nice.
Could you consider a toggle in the Class Design window to decide if the power supply goes for the energy hogs first or last? That way, if you design a ship with mixed energy weapons you can decide whether PD capacity is more important or the ability to fire back at the enemy ships.
Steve?
Could you consider a toggle in the Class Design window to decide if the power supply goes for the energy hogs first or last? That way, if you design a ship with mixed energy weapons you can decide whether PD capacity is more important or the ability to fire back at the enemy ships.
You save power for the weapons you want by not cycling the ones you don't want. I don't see much point in adding extra UI for this.
I don't know how much work it would be to implement, but a system for managing multiplayer games as some kind of administrator would be nice. A system where the relevant part of the game data could be send to all participating players and they thereby could see the state of their empire and make decisions which then are send back as a protocol file which aurora then could read and implement.I don't see how that would work with the time system as it stands? I mean, fine for monthly updates, but what happens if, say, two players out of 6 are fighting, do you make everyone go through 5 sec increments? Who decides when to move to 30s increments etc?
In general it could only work as the game works at the moment - the game is run by one person who inputs all plans & settings and lets it play for some time until he gives out information again to the different fractions as to what happens. I was more thinking in a way of automating the process of sending and collecting this information - not doing a real multiplayer. Don't think either that could be possible.Oh, more of a dungeon master mode. Yes, I could see that working. One person controls the time increments but other players can do what they like while the system is paused, along with some kind of "I'm done now" button that the DM can look for or ignore.
I don't see how that would work with the time system as it stands? I mean, fine for monthly updates, but what happens if, say, two players out of 6 are fighting, do you make everyone go through 5 sec increments? Who decides when to move to 30s increments etc?The way I'd see a multiplayer aurora working is basically the exact same as the way multiplayer currently works except that instead of having to manually send the database back and forth, the game would automatically sync everyone's game. Players time increment buttons would be disabled and only the designated GM would be allowed to advance time (for simplicity the host of the game could always be treated as the GM).
Why do we need a person to be DM? That kind of thing can be automated easily.Because this would be annoying. Aurora isn't really a game you just shove on for half an hour with some randy you've never talked to before. Everyone who commits to a game of aurora probably has some level of contact already and all players will be able to be in contact with the GM anyway, through IM or whatever. There's no reason not to have the GM control time increments.
"If all players have checked 'next increment' or X amount of real time has passed, go to next increment"
This is really simple, and is how Dominions 4 works. Dom4 is coded entirely by one guy. The hard part is the networking to pass all the players' decisions to the DM.
I'm saying we do not need a GM at all, not that the GM should not have this responsibility.Yes but that presumes that having a GM is undesirable. Why are you trying to eliminate the GM? It's the more convenient, less annoying system and can't be messed up if one guy just decides to be an obstinate dick.
I repeat, Dominions 4 does nearly this exact system automatically, without a GM. Even over the internet. And it is programmed by one guy.
Europa Universalis does variable-time multiplayer. It goes with the slowest speed any player selects. It works fine. People do not generally play EU with random people, so they don't mind waiting for someone who needs a low speed.
Yes but that presumes that having a GM is undesirable. Why are you trying to eliminate the GM? It's the more convenient, less annoying system and can't be messed up if one guy just decides to be an obstinate dick.Why is having a GM necessary? Apart from ego, maybe, I don't see it. You say it's "more convenient" and "less annoying", but why? Why is having to wait for one guy (who may or may not actually be playing) to wake up and decree that the next increment is allowed to process more convenient and less annoying?
And you KNOW there would be the.... OCD person using 5 seconds time increments ALWAYS.
And whats going to happen when someone does an overhaul of their fleet, using 3+ hours planning components and such? I certainly do quite often. Is everyone else going to go and read a book in the meanwhile?
I don't think Aurora is suitable for true multiplayer. Not at all.
And you KNOW there would be the.... OCD person using 5 seconds time increments ALWAYS.Dominions 4 allows asynchronous multiplayer if you want. It has to be set up this way when you start the game, but it can be done. In Dom4 with asynchronous multiplayer on, the players are given X amount of time (I think most people do 24 hours) to complete their turns and send them to the host. Once they're all in or the time is up, the host then goes to the next turn and the process repeats. I think they're sent via the same protocols as email. It's kinda like playing chess by mail like people used to do pre-internet.
And whats going to happen when someone does an overhaul of their fleet, using 3+ hours planning components and such? I certainly do quite often. Is everyone else going to go and read a book in the meanwhile?
I don't think Aurora is suitable for true multiplayer. Not at all.
Why is having a GM necessary? Apart from ego, maybe, I don't see it. You say it's "more convenient" and "less annoying", but why? Why is having to wait for one guy (who may or may not actually be playing) to wake up and decree that the next increment is allowed to process more convenient and less annoying?Wat. All players would have to be awake to be playing in the first place. There's no difference between having a GM or having a player in this case. It's more convenient and less annoying because you have someone who knows everything that is going on doing the turns as they need doing. Instead of a bunch of people expecting one time increment and getting something else. It also can't be ruined by some idiot troll just deciding to never click/always click 5 seconds. As mentioned above, players could get bored while waiting for battles. With a GM they can just go off and do something else whilst the GM and the involved players do the battle. Additionally, having the GM control time actually allows for limited play to continue whilst one of the players is not there. You still haven't told me why you want to eliminate the GM.
I've hosted games of Dominions 4 before and I can tell you right now that my job as "GM" pretty much ends at setting up the start conditions. I don't want to have to manually hit the "next turn" button for everyone, that's tedious and annoying. Aside from having space master to debug, and being able to boot people from the lobby, I just don't see what a GM would actually do if we had "true" multiplayer like in every single other modern game.
Wat. All players would have to be awake to be playing in the first place. There's no difference between having a GM or having a player in this case. It's more convenient and less annoying because you have someone who knows everything that is going on doing the turns as they need doing. Instead of a bunch of people expecting one time increment and getting something else. It also can't be ruined by some idiot troll just deciding to never click/always click 5 seconds. As mentioned above, players could get bored while waiting for battles. With a GM they can just go off and do something else whilst the GM and the involved players do the battle. Additionally, having the GM control time actually allows for limited play to continue whilst one of the players is not there. You still haven't told me why you want to eliminate the GM.Well obviously I want the GM gone because every single one of his functions that you mentioned is something that would be better if automated. Automating these things would be both more convenient and less annoying.
And why are you playing games with idiot trolls? Mentioning idiot trolls is an absurdly hypothetical scenario because Dominions 4 is very rarely played with idiot troll randoms off of the internet, rather than people you know and trust not to do stupid things. I'm not even sure if current A4x """multiplayer""" is played with a high concentration of idiot trolls.
Stellaris and Hoi4 are high up complex strategy games? Please.
I don't think comparing a possible 'MP Aurora' to any of the Paradox games is really the right approach - even if they are more complex than a lot of MP games, they're still 'mainstream' enough to need public matchmaking. I think a more appropriate comparison would be War in the Pacific or War in the East/West, where multiplayer games are measured in months or years.
These changes should make ground unit morale and commander ground training bonuses much more useful and add the chances of elite ground forces. It is also makes assignment of ground unit HQ commanders more interesting.
The admin command structure looks really cool. I'm excited to try it.
That said, I'm going to keep pushing for command ships (like the Blue Ridge, not just normal flagships). Looking at the way you have it laid out, the obvious suggestion is that a big module (at least 25,000 tons) should give a radius of 0, affecting only the system it's in. Or if you're willing to give it a radius of 1, that would be even better.
I probably will add some form of Admin Command module post-launch. I just want to make sure everything functions as expected before adding any further complexity.Excellent. I'll stop bugging you about it, as I don't want you holding up release.
Fleet 1 is part of Admin Command AA that is part of Admin Command B. Both have a command radius of 1.
Sol - B
1 jump
Alpha Centauri - AA
1 jump (2 jumps from Earth)
Barnard's Star - Fleet 1
Would Fleet 1 still get bonuses from both AA and B or only from AA? I think Steve's explanation says that the fleet doesn't have to be in-range of all admin commands, as long as the admin commands are in range of each other but I'm not sure.
I love the concept of titans, they are awesome, but please, change the names you have there for them.
.......
Just something that isn't so immediately recognizable as 40k.
As far as I know there is no way presently to way drop into place ground to space defenses since a PDC needs to be assembled.PDC's can be quite small, and can be assembled by construction brigades. If you bring some CB's along with your invasion, you could throw down a few ~5000 ton PDC's in a few weeks.
Well, any expansion of the ground warfare section is only good, as it's really barebones right now. That said, I think the different Titan sizes need something to differentiate them a bit more. Currently, it's a case of 'build the biggest titan you can build and only build that, as it's most space efficient. ' Perhaps some sort of triangle, where light titans do more damage to heavy titans, heavies do more damage to mediums, and mediums do more damage to lights, so that there's a reason to build and deploy mixed forces?
It'd be a bit weird for a force of light titans to be able to compete against heavy titans. Rather than trying to juggle titan vs titan, why not refocus the balance. The heavier titans become progressively less effective at their ground unit combat, as they sacrifice agility and lighter, more agile weapons for their heavy armor and heavy weapons to focus on killing other titans. So light titans would be vastly more effective at overrunning ground units, Medium titans would strike a balance between titan combat and infantry combat abilities, and heavy titans would be entirely geared towards destroying other titans, even at the risk of leaving themselves less capable at clearing out normal units. This leaves lighter titan classes with a combat niche even as the larger ones are unlocked, while still driving players to develop heavier titans to try and neutralize the enemy titans quicker.
It'd be a bit weird for a force of light titans to be able to compete against heavy titans. Rather than trying to juggle titan vs titan, why not refocus the balance. The heavier titans become progressively less effective at their ground unit combat, as they sacrifice agility and lighter, more agile weapons for their heavy armor and heavy weapons to focus on killing other titans. So light titans would be vastly more effective at overrunning ground units, Medium titans would strike a balance between titan combat and infantry combat abilities, and heavy titans would be entirely geared towards destroying other titans, even at the risk of leaving themselves less capable at clearing out normal units. This leaves lighter titan classes with a combat niche even as the larger ones are unlocked, while still driving players to develop heavier titans to try and neutralize the enemy titans quicker.
Missile Fire Control FC94-R92 (2) Range 94.8 mkm Resolution 92
Active Search Sensor AS116-R92 (1) GPS 17388 Range 116.1 mkm Resolution 92
Active Search Sensor AS57-R20 (1) GPS 2520 Range 57.0 mkm Resolution 20
Missile Fire Control FC94-R92 (2) Range 94.8 mkm Resolution 4.600 t
Active Search Sensor AS116-R92 (1) GPS 17388 Range 116.1 mkm Resolution 4.600t
Active Search Sensor AS57-R20 (1) GPS 2520 Range 57.0 mkm Resolution 1.000t
Titans should be designable like ships/PDCs. Allow certain beam weapons on titans to negate all or part of the atmosphere penalty with some research.
Recovering Technology and Ship Components from Ruins
In order to prevent unbalancing tech advancements occurring while excavating very large ruins, the maximum tech advancement you can achieve from recovering abandoned installations will be based on the tech level of the ruin race. The max development cost of any associated tech will be:
(2 ^ (Ruin Race Level + 1)) * 1000;
This means a level 1 ruin race will have tech up to 4000 RP, a level 2 race up to 8000 RP, etc. with the maximum being a level 5 race with tech up to 64,000 RP.
When standard components are selected for recovery (such as gravitational survey sensors), they will be the best available component within the above limit. If no component of the specified type is available within the limit (for example when the random selection is a 5000 RP Asteroid Mining Module for a level 1 race), nothing will be recovered.
« Last Edit: Yesterday at 11:47:20 AM by Steve Walmsley »
How does this affect special ruins only tech such as compressed fuel tanks and advanced lasers?
However implementing how specific ship-based weapons like lasers or missiles would work would need further details.
I'd like to be able to rename them in some fashion... say Bolo instead of Titan. :)
I'd like to be able to rename them in some fashion... say Bolo instead of Titan. :)
Frankly, you could scrap the Titans and it doesn't seem like the game would grow worse for it. It'll work in some games and contexts, but not really in most.
I really hope you're going to allow us to er disallow titans, last thing I'm gonna want is my NPR running around with giant robots
To be honest, I don't like most of these latest suggestions about titans.
Ground combat needs improvements compared to the current situation. That's undeniable. New units needs to be added, new mechanics too. Probably, a complete redesign/rebalance.
However, a lot of the suggestions I see in the last two pages or so aim to make titans something else. Something more complex and probably hard to code and balance. Something, plainly put, that is not just "another ground unit".
I am not saying that something like that cannot be implemented. However, that is only AFTER ground combat has been revamped and we know more of how the new ground combat is going to work. Until that happens, there's no sense in making "movable PDCs". How would they work, interacting with normal troops? Having anti missile capabilities. How would that be balanced, against normal troops?
All these changes can be discussed, weighted, implemented only after ground combat is overhauled into something that can actually support all this. Until that happens, titans should mostly be normal ground units to preserve balance and coherence across the board. The extra bombardment attack they have right now is just about the limit of what I would consider an acceptable advantage over normal troops, with the current rules.
Question on Commander Careers:
The automatic assignment in VB6 often switched officers between the same spot on identical ships or offices - which I always found to be a bit strange. Is there a way to include a routine which checks if an officer was assigned to one spot on ship A and if he is auto-assigned to the same spot on ship B that he is kept on ship A?
Since now the rank of an officer needed for the different positions is fixed and not a minimum requirement as before and not anymore mostly decided by the player on a whim, will promotion rules become more flexible? Currently, the fixed ratio of officers in ranks meant I set the required officer ranks for my ship classes to match. As this won't be possible anymore, it seems we will have to design ships in very specific ways and build the correct numbers of them to keep officers of all ranks employed evenly. Or will promotion be more 'on demand', like when a survey officer of rank two is required, but not available, promote one with fitting ability from the lower rank?
Even fighters and FACs and such now need rank 3 commanders, because they have weapons?
Since an officer immedeatly gets kicked out of his command when promoted, what happens when there is no open position for his new rank, and no spare officer for his old position?
And since the auto-assingment intervals don't happen anymore, an officer who gets promoted and put into a position where his skills are completely useless (because there is no better fitting one available in his new rank that instant) will never move to a better fitting position until his next promotion, completely wasting his abilities (which were the reason he actually got promoted) for several years?
Can we also throttle certain ranks to only have a certain number of people when auto-promotion is active? E.G restricting the top rank to 1 person at all times?
It would be easy enough for me to add a rule on that basis, although I think too many senior officers is not going to be a problem.Might not be a problem in VB6, but it sounds like in C# we're gonna have far less retiring officers than usual.
Clearly, the only appropriate solution to the problem is to build an entire separate, exceedingly-detailed game to simulate ground combat, designed to interface with Aurora both for initial setup and for results translation.Pretty much would require this. Any more in-depth ground combat would require planetary maps to be generated and operational movement of troops, introduction of supporting arms, more detailed supply system for ground forces, aerospace and naval units, and the list goes on and on. It's an exponential list :D
...
I started that off as a joke, but it would be pretty awesome.
Pretty much would require this. Any more in-depth ground combat would require planetary maps to be generated and operational movement of troops, introduction of supporting arms, more detailed supply system for ground forces, aerospace and naval units, and the list goes on and on. It's an exponential list :D
Construction Ship
Primary: 4
Secondary: Construction Time
Bonus: Production
The percentage chance of failure in any construction phase is equal to Overcrowding Modifier * 100 * (Increment Length / Year Length). That translates to a 3.1% chance per construction phase with an Overcrowding Modifier of 1.5, an 8.6% chance at 2.5 and a 34.2% chance at 5.0.
Wouldn't this prioritise the oldest (slowest) ships, rather than the newest?
It looks like you've calculated these percentages from the given figures as amount of overcrowding, not the Overcrowding Modifier (i.e. they've been squared when I don't think they should be). Also, isn't that last one 34.7%, not 34.2%?
I am using 365 day calendar years, rather than 365.25 astronomical years, although I suppose I could use the latter as Aurora now handles leap years.W00T!!
I still get 34.2% though. If Overcrowding is 5x, then modifier is 25x. I have ROI modifier of 0.01369863, assuming 432,000 seconds for the 5-day increment and 31,536,000 for year length. I am using 365 day calendar years, rather than 365.25 astronomical years, although I suppose I could use the latter as Aurora now handles leap years.
Good spot on the construction ships. One of the benefits of posting the rules is getting this type of review. I'll change it to class cost, as the more modern construction ships are likely to be more expensive.Wouldn't ordering of those construction ships in the _ascending_ order of their needed-construction-time-per-gate be enough?
Wouldn't ordering of those construction ships in the _ascending_ order of their needed-construction-time-per-gate be enough?
It would if I wrote a custom function just for construction ships. At the moment one function determines the assignment types for every class, based on its type, then the function below runs all the commander assignments at once. Quick example of how you can do so much more with C# in a few lines of code, especially using LINQ.
CODE
Why not just make the secondary priority 1/([gate construction time] + 1)? Picking vessels in descending order of the inverse is equivalent to picking them in ascending order of the construction time (prioritizing more modern construction vessels).
With all the new commander positions I was wondering if it would be possible to add a functional n tat allows you to prioritise training at your academies so as to tilt the skill sets of new commanders. Ie you set an academy to a surveying course to increase output of commanders with the required skills in sureveying at expense of non survey skills. If you added a lag or a course duration for this it may give you a trade off between fewer commanders coming through but more of the ones you need.
I was about to suggest something similar. Like a dropdown selection of focus for Academies which after X years make Y % more of one skill an Z % less of everything else. Or maybe you could put a Commander in charge of the Education and have their skill influence what comes out the other end.
I like the change to academies. Looks like I can no longer build 50 academies on the same planet XD
Besides, there would be no reason to do so. I can see wanting at least 3-4 worlds with accaddemies, so you can try to generate multiple, different types of personnel.
I like the addition of commandants, but I am a bit concerned about the minimal requirements. I like to have all my academies on my capital planet (give it a reason to be capital). The requirements could get very high :(
Though I guess I will see how it pans out when the game is out.
Will my scientists still be usable for science at a planet that they're selected to be a commandant? Maybe if the planet also has labs?
I like the change to academies. Looks like I can no longer build 50 academies on the same planet XD
Besides, there would be no reason to do so. I can see wanting at least 3-4 worlds with academies, so you can try to generate multiple, different types of personnel.
A question, Steve. You wrote:
"If the Commandant has at least 20% in any percentage-based bonus or 150 for crew training / ground unit training, all commanders graduating from the academy at that population will take two rolls for each qualifying bonus, and use the higher of the two results"
So, if I have for example a Civilian administrator with multiple skills at 20% or more (not that uncommon), do new civilian administrators roll to get each of those bonus every time? I'm asking because if so, it seems REALLY good to assign extremely skilled commanders or administrators to the Academy.
I like that academy commander influence the type of personnel.
But at the beginning of the game there are some fields of research where i have no scientist with specialization and
I was a bit concerned that, with commanders influence on the specialization, i would have problems to get
scientists with specializations i don't have.
So I did checked the chance for getting an Scientist with a specialization X
In VB6 Aurora and in Aurora C# with no academy commander chances to get a Scientist with a specialization X are 7% * 1/8 = 0. 88 %
In Aurora C# with a scientist as academy commander chances to get any scientist are 93%*14% + 7% = 20. 02%
To get a scientist with the same specialization as the commander 20. 02% * ( 25% + 75% * 1/8) = 6. 88%
and to get a scientist with a specialization x which is not the same as the commander 20. 02 % * (75% *1/8) = 1. 88 %
If the specialization of the commander had no influence on the specialization the chances to get a scientist with specialization x would be 20. 02% * 1/8 = 2. 5%
So a scientist commander will more than double the chance to get a scientist with a specialization you don't have but you will most likely end up getting more scientists with the same specialization
Yes, you get the two rolls for each qualifying skill. For many skills, it moves the chance of the new commander getting that skill at a reasonable level (say 20%) from 2% to 4%, or 3% to 6%, so while very useful it shouldn't be game-breaking. If it proves too powerful in play-testing, I could adjust to something else, like the second roll being capped at less than 100 for example.
I don't think it will prove too powerful. Quite honestly, it's a much needed change. Sometimes the game just won't give you anything you need as you suffer a horrible streak of luck and can't get any decent scientists or governors. With this, you have more tools to combat that and I feel its a really great improvement.Yes, it makes you feel you are can do something about your lack of given type of personnel at least.
Automation through scripting:
I was wondering if in C# there is a way to expand the way in which commands are given to fleets. Especially around automation of routine jobs. For example:
I have three fleets. Two contain a bunch of sorium harvesters, one over Jupiter, one over Saturn. The third fleet is one single fuel tanker.
The tanker fleet should be able to generate a move command to one of the two fleets, if the fleet has X amount of fuel harvested. It then should unload the fuel to a specified target (for example Earth) and wait there until one of the harvester fleets again is full and then generate the next unload cycle.
Could probably be done through a couple of extra conditional orders.
Or with some hand calculations and delay orders.I'd rather we got scripting/extra conditionals. That's annoying to set up (particularly if you have more than two harvester groups), planetary movement could throw it off, and it breaks completely if you add more harvesters to a fleet.
I'd rather we got scripting/extra conditionals. That's annoying to set up (particularly if you have more than two harvester groups), planetary movement could throw it off, and it breaks completely if you add more harvesters to a fleet.
In C# Aurora, transferring ordnance is no longer instant and ships without specialised equipment cannot exchange ordnance in space.
Regarding
does this impact PDC?
Interesting question. As things stands you can reload a PDC using the mechanics I laid out, because you can add a collier to the PDC fleet, or reload directly if the planet has an ordnance transfer station / spaceport. The question is whether a PDC should have some extra function beyond that.
Could probably be done through a couple of extra conditional orders.Would be nice to have for managing larger empires ;)
Given that a PDC is on planet (along with the stockpile) it seems to me that a PDC does not need access to ordnance transfer infrastructure so long as there's a stockpile on the colony, but it also exchanges ordnance at the standard rate.
Yes, this means that a PDC with a sufficiently large magazine and some Ordnance Transfer Systems can serve as a cut rate OTStation. It does, however, have one limitation; it can't gain more MSP per hour than the standard rate from the colony. Sufficiently missile heavy fleets won't be able to make effective use of this trick, but it's great for topping off fleets or as a far forward position supplying long range surveyors with probes.
However, there's a few other things that need answering with rearming and refueling. First, there's the implication that without having researched the refueling and ordnance transfer systems it's impossible to refuel or rearm fleets once they're launched. While I get that in a standard game these techs are presumed known, in a non-TN start these techs should not be known yet. As such it would probably be alright to set a baseline transfer rate equal to 3/4th of the starting underway replenishment techs.
Second, there's the implication that refueling and rearming from a tanker or collier with the 500 ton resupply systems and linking as many of those systems with a single ship, than would be possible with a Station or Hub, as those have infinite links but only 1 link with a given ship. This is rather exploitable, and easily solved by noting ships without a resupply system can not exceed the resupply rate of the highest resupply system available.
Third, while the first level of Spaceport is immensely useful, given that it halves cargo transfer time and grants the ability to provide unlimited refueling and rearming links, at 3600 BP it's kind of expensive for shortening cargo transfer times to 1/3rd the rate without a Spaceport. It might be better to drop the ordnance transfer and refueling functions from the Spaceport and return it to a 1200 BP structure that helps with cargo transfers.
This then leads to the 4th and final point. A non-TN start should not start with a Spaceport, Ordnance Transfer Station or Refueling Station as no Earth based polity would be able to haul the 100kt+ facilities into orbit without TN support, but these facilities, much like the Sector Commands, should probably be gated behind a tech. Perhaps a Basic Naval Supply Network technology that unlocks the facilities and the first level of transfer rate improvement, as well as the Underway Refueling, Underway Rearming and the Cargo Handling technologies?
1) Refuelling Systems and Ordnance Transfer Systems are conventional tech so you start with them in a conventional game.
2) Not sure what you mean here. Each collier or tanker has a set amount of transfer per sub-pulse and can't exceed that (even if it refuels multiple ships). Each ship also has a max transfer per sub-pulse limit (which is set to the max transfer rate of any ship trying to refuel or rearm it), so you gain no advantage in trying multiple refuels in a turn.
3) I want the spaceport to be a major facility. It combines two 1200 BP stations, plus the cargo handling. Plus I might give it some other ability before the game is completed.
4) The Spaceport, Ordnance Transfer Station and Refuelling Station are all ground-based facilities and also conventional tech so there is no problem with a non-TN start having them.
With regard to the PDC, I am seriously considering removing PDCs from the game. They create exceptions for a number of rules, confuse new players, add complexity to ground combat without necessarily adding a commensurate improvement in game play, and their maintenance-free status can be an exploit. I may replace them with some additional types of ground forces to improve defences planetary defences and keep all 'ships' in space. One of their major advantages is to allow maintenance-free bases on new colonies, but even that is no longer as great an advantage given the new maintenance system (you can build orbital bases that can provide their own maintenance facilities and just ship in supplies).
With regard to the PDC, I am seriously considering removing PDCs from the game. They create exceptions for a number of rules, confuse new players, add complexity to ground combat without necessarily adding a commensurate improvement in game play, and their maintenance-free status can be an exploit. I may replace them with some additional types of ground forces to improve defences planetary defences and keep all 'ships' in space. One of their major advantages is to allow maintenance-free bases on new colonies, but even that is no longer as great an advantage given the new maintenance system (you can build orbital bases that can provide their own maintenance facilities and just ship in supplies).
My intention wouldn't be to remove ground defences entirely, just replace PDCs with ground units that have non-ground capabilities and move to more detailed ground combat. For example, some form of air defence unit that functions as a CIWS for the planet. Perhaps a 'ground to orbit meson battery' unit, etc..
In this case, ground units should probably be more directly affected by racial tech. it may mean I have to move to some form of simple ground unit design where you create your own unit types. This would include CIWS techs, ground to orbit techs based on ship-weapons, ground-based attack/defence split into armour and infantry-based techs (based on weapon & armour techs), maybe the bombardment ability of Titans so as an alternative to Titans you could develop different forms of artillery. Concealment tech to make units harder to strike from orbit. 'Movement' tech could be personal armour, tracked vehicles, combat walkers, etc.
Troop transport bays and combat drop modules would be for infantry (personal armour) types - a different module would be needed for heavy armour or ground to orbit capable units.
Perhaps the type of planet could affect which units are most effective - specialist units for extreme temperature, or mountainous terrain, or mostly water planets, etc. Terrain would also determine the effectiveness of different movement types.
Another option to be considered is removing the restriction on energy weapons in atmosphere. Ground units armed with ship-type weapons would become a serious deterrent, especially given they are more dispersed than ships and harder to eliminate. I would need to add rules on destroying installations from orbit, but not sure how much of a problem that is given that most powers want to capture installations rather than destroy them.
In fact, this could lead to a paradigm where it is very hard to bombard a well-defended planet from orbit so you (still) have to nuke from a distance and risk environmental and industrial damage, or develop very fast drop pods to get troops to the surface (through defensive fire) to take out the ground-based defences (Hoth).
Anyway, just thinking out loud at the moment.
My intention wouldn't be to remove ground defences entirely, just replace PDCs with ground units that have non-ground capabilities and move to more detailed ground combat. For example, some form of air defence unit that functions as a CIWS for the planet. Perhaps a 'ground to orbit meson battery' unit, etc..
In this case, ground units should probably be more directly affected by racial tech. it may mean I have to move to some form of simple ground unit design where you create your own unit types. This would include CIWS techs, ground to orbit techs based on ship-weapons, ground-based attack/defence split into armour and infantry-based techs (based on weapon & armour techs), maybe the bombardment ability of Titans so as an alternative to Titans you could develop different forms of artillery. Concealment tech to make units harder to strike from orbit. 'Movement' tech could be personal armour, tracked vehicles, combat walkers, etc.
Troop transport bays and combat drop modules would be for infantry (personal armour) types - a different module would be needed for heavy armour or ground to orbit capable units.
Perhaps the type of planet could affect which units are most effective - specialist units for extreme temperature, or mountainous terrain, or mostly water planets, etc. Terrain would also determine the effectiveness of different movement types.
Another option to be considered is removing the restriction on energy weapons in atmosphere. Ground units armed with ship-type weapons would become a serious deterrent, especially given they are more dispersed than ships and harder to eliminate. I would need to add rules on destroying installations from orbit, but not sure how much of a problem that is given that most powers want to capture installations rather than destroy them.
In fact, this could lead to a paradigm where it is very hard to bombard a well-defended planet from orbit so you (still) have to nuke from a distance and risk environmental and industrial damage, or develop very fast drop pods to get troops to the surface (through defensive fire) to take out the ground-based defences (Hoth).
Anyway, just thinking out loud at the moment.
i dunno if this has been asked. What engine is this being made on
Steve's already made the super ultimate awesomest way to do ground combat. All without realizing it probably. In aurora there is a galactic map. A 2d space with adjustable grid lines. That was used to fit icons for worlds and their jump point connections. What if we take the grid and change the icons and make ground combat using this grid assigning troops different movement and firing patterns and so on. Make positioning and modern day maneuver warfare great again!You do realize that being sarcastic asshole doesn't really get anyone to listen to you.
PDC can be the King to be checkmated by the titan queen.
So... now that I have solved aurora's ground combat problems I'm tempted to go on to fix this world hunger issue I've been hearing about.
Give them a deployment time. Sure you can just increase crew quarters to raise deployment but that would also increase maintenance costs.
You do realize that being sarcastic asshole doesn't really get anyone to listen to you.
If you don't like a suggestion, try to atleast explain why instead of trying to undermine it in a childish way like this.
is there any hope for multiplayer? :)As noted multiple times, because of the disparity of long intervals of maintaining the empire and short ones of combat the possibilities of multiple players playing at the same time in one universe is hardly there. Currently you can either do succession games with save file going around the group or one storyteller/multiple aides way where one player collects suggestions and proceeds with the simulation. There doesn't seem to be indications any Steve is looking forward to change it and recently he is busy with changing the used programming language and multiple core systems with it. See C# Aurora Changes List (http://aurora2.pentarch.org/index.php?topic=8495.0) for more info about that.
As noted multiple times, because of the disparity of long intervals of maintaining the empire and short ones of combat the possibilities of multiple players playing at the same time in one universe is hardly there. Currently you can either do succession games with save file going around the group or one storyteller/multiple aides way where one player collects suggestions and proceeds with the simulation. There doesn't seem to be indications any Steve is looking forward to change it and recently he is busy with changing the used programming language and multiple core systems with it. See C# Aurora Changes List (http://aurora2.pentarch.org/index.php?topic=8495.0) for more info about that.The disparity of long intervals isn't a problem. You just do it like EU4 does; it goes with the lowest speed requested. This isn't the kind of game you play with random people online, you'd be playing with your friends. So they won't make you wait too long. Worst comes to worst you can just go do something else while they fight. You're right that the biggest deterrent is just that Steve has other priorities.
I'm not even sure how that could even be fun. Do you just what, frakk off and wait for players to design stuff? Caues it takes so long, they cant design stuff in real time.It would be quite a bit different. You wouldn't need a human to mindlessly follow the inputs the players command. There is no need for a Game Master.
A play by post system could work, but that wouldnt work much different then a storyteller and folks telling the story teller whats happening.
Would be a nice feature if Steve is ever interested in adding it some day, but I'll note flat out I have no idea how much work it would be to code. Maybe we could tempt him with the potential of not having to play all 12+ empires in his games by himself :p
I have to say that I am a bit disappointed with removal of PDCs. I did not use them much on colony worlds, but I like my asteroid forts and bases. I hope some form of asteroid fortifications like Theban defenses in Crusade will be eventually implemented as partial replacement of PDCs.In the game rules (as it were), they were just really stronk space stations, which you can still do.
But they can be terraformed with antigreenhouse gas:
http://aurora2.pentarch.org/index.php?topic=8144.msg104909#msg104909
A couple other terrains I can think of:
Ice Crust: Bodies with deep ice sheets kilometres deep.
Glacier: Snowball Planets, Planets in nuclear winter, like ice sheets but have a rocky crust beneath the ice.
Metallic: Planets or asteroids mostly made of iron or other heavy metals.
Molten: Tidally locked planets close to a star, Planets that have recently collided with a large body, Very Seismic planets
Abyssal: Deep water covers the planet.
Neritic: Planets covered in shallow water, with a few small islands.
1 hit every 144 shots against a fully fortified GtO weapon... yeah, that doesn't sound really favourable while it's engaging you anyway. Maybe, maybe if you have shields do tank the blows, but certainly not on an armour paradigm.
Is there any degree of consistency in dominant terrain? I mean, dominant terrain is nice and easy, if not realistic, but do battles on the same planet always have the same terrain barring terraforming shenanigans? If it doesn't a lot of the plausibility disappears. I would've liked to see, say, 6 different 'dominant terrains' on an Earth sized land, but I understand that would get needlessly complex.
I'm curious however; does the existence of a biosphere impact the chances for certain terrains? Because it should, given so many imply a biosphere. And frankly, we need a way to measure the size of a biosphere, and to change biospheres if these are our options. Because to me? It looks like the best option, defensively speaking that is, is to jack up the temperature as far as the settling species can tolerate without infrastructure support and a hydrosphere as extensive as you can get without limiting maximum population to get as much chance of generating a Jungle terrain as possible.
Oh, and another dominant terrain type; Urban, for those planets at their maximum population without hydrosphere based population limitation.
And with high enough tectonic activity, hopefully mountain jungle terrain. Because that's where the best defense values are.
I like the idea of Urban becoming the dominant terrain type once the population hits a certain percentage of maximum.
It will be just one dominant terrain type. Not that realistic but much better than now. One interesting question is what is the dominant terrain type on Earth? At the moment I am leaning toward Temperate Forest, although I could perhaps add some form of mixed terrain type with a single set of values.
There is no biosphere concept at the moment, although I will probably add indigenous lifeforms that could pose a threat to any colony. The new ground combat system will allow a wide variety of potential non-sentient foes. They would have to be cleared, or at least defended against, to ensure the safety of any colony. Any local wildlife would be adapted to the environment and have appropriate capabilities.
You would need alot more then 12 billion population on Earth for Urban to become the dominant "terrain" for example.
Not really.
Dominant Terrain doesn't really describe the dominant terrain of the planet, it describes the dominant terrain that is being fought over. Since the invention of rail travel we've been seeing a lot of consolidation of populations into cities and away from rural areas for a variety of reasons, but the two biggest factors are to do with farming automation greatly driving down staffing requirements for food production, and rail ways making it possible to bring all that food large distances.
It will be just one dominant terrain type. Not that realistic but much better than now.
Something else that occurred to me was that I am basing the terrain on current Earth. There could be a lot of alien terrain (Giant fungus forest?) or even terrain from Earth's past.
What about planets where all life evolved subterranian? Hivemind insect homeworlds and so on?What's your energy source there? Life is on the surface because the energy is there. Yes, I know about extremophiles living in deep-sea vents or geysers in Yellowstone. But the surface seems overwhelmingly likely, particularly for complex life.
Something else that occurred to me was that I am basing the terrain on current Earth. There could be a lot of alien terrain (Giant fungus forest?) or even terrain from Earth's past.
What's your energy source there? Life is on the surface because the energy is there. Yes, I know about extremophiles living in deep-sea vents or geysers in Yellowstone. But the surface seems overwhelmingly likely, particularly for complex life.Sorium!
What's your energy source there? Life is on the surface because the energy is there. Yes, I know about extremophiles living in deep-sea vents or geysers in Yellowstone. But the surface seems overwhelmingly likely, particularly for complex life.
What says that anything besides the leaves of the vegetation need to be above the surface?
With a bit of imagination and Sci-Fi storytelling leeway we could have all types of glowing rocks and vegetation with deep root networks that fuel the herbivors and tunnelers with energy. Add underground rivers carrying stuff around or deeper as well.
Or you could have a situation where the surface is so hot/cold that going subterranean is required for a more balanced temperature ( relying either on geothermal or the energy/warmth that trickles down. )
What says that anything besides the leaves of the vegetation need to be above the surface?The bit where I can get more energy from my neighbor by being taller than him. And the bit where I don't have to push stuff out of the way to grow.
Yes, let's ignore the massive efficiency gain that is not having to dig your way through soil and rock and eschew
From what I understand we are descendent of rodents which survived from the Dinosaurs by digging underground not that long ago...A lot of animals burrow to get shelter. Very few of them live exclusively underground. Those that do tend to be smaller, because moving underground isn't very energy-efficient, and being big means that you need to cover a lot of territory looking for food.
So if you want a more scientific explanation: What if that asteroid that wipes the dinosaurs out never hits Earth but intelligent life develop underground by necessity of hiding from the big beasts instead?
A lot of animals burrow to get shelter. Very few of them live exclusively underground. Those that do tend to be smaller
What says intelligent life must be as large as humans?
Generally speaking, I think that terraforming in Aurora is just a little over 1000 times stronger that it must be. When you can make habbitable planet of Mercury with two month of orbital terraforming, and it's just the beginning of your stellar expancion... it's just too much. There is no value in planets with life, no point in serching those planets, when you can just make such things from dead stones.fortunately, in aurora, if you dont like terraforming you can just not do it. Personally I find the game plays way better that way or with very limited terraforming.
Probably a controversial opinion but... The biome changes just sound like feature creep that forces players to engage in the game's fundamentally un-fun ground combat. It sounds kinda superfluous to what I view as the core game (the ship design/combat), just like the terraforming/planet changes in general.
I actually sort of agree with Serger on this. While all sorts of biomes are fun and interesting, I agree that the actual fighting will tend to occur in urban and suburban locations, because that's where the valuable targets (infrastructure, resources, population) are located. And I also agree that meson cannons should really be able to just fry everything hiding out in those jungle mountains...
or you can just leave them be to quietly starve to death while you fortify around the cities. They either surrender, or they have to attack your (heavily) fortified units that are guarding the actual valuable assets on planet.
In WW2 combat mostly happened outside of cities ( with a few notable exceptions ), and as far as I know the same has been the case for every war before or since.
Why would it be different in the future? What changed?
In reality it's the other way around. The cities can't survive isolated but are dependent on supply/food from the countryside. The units controlling the countryside can seize supply/food and attack routes to deny it being delivered to cities.
Real combat (especially of XIX-XXcc) was a mass warfare. They manned millions on the field, filled the whole lines of contact with their infantry units and artillery. Even now NATO have no such numbers of combatants and barrels - and in the Middle East we can see now this drift to city-centric main combat, while rural area is filled with guerrilla skirmishes, as I stated above. In Aurora we have even smaller units then NATO have now IRL, and they have to control the whole planet, not a separate problematic region.
And, as it was stated above, there is no need in wide rural area in Aurora. You have vast energy resources with TN techs, so you can grow food in greenhouses and bacterial tanks, not in the field. You need area just to fill it with your suburban, to make your population happy on expanse.
And if you have orbital observation force and meson cannons - than no enemy troop can survive in attack at your transport routes at this planet. Those troops can make kamikaze diversions (one troop - one diversion), but no regular warfare with area control, if they have no mesons. And if they have mesons and TN radar - they can attack any target on the planet or on the orbit at any time from any location. There is no line of contact, no rear area, and no masking outside of tech-dense urban and suburban with TN techs.
Probably a controversial opinion but... The biome changes just sound like feature creep that forces players to engage in the game's fundamentally un-fun ground combat. It sounds kinda superfluous to what I view as the core game (the ship design/combat), just like the terraforming/planet changes in general.
Yeah, if there's one gun type that needs to be incapable of operating in an atmosphere it's mesons. Otherwise all conquest will be 'nuke it until everything is dead' because the locals can resist too effectively.It's more like mesons are kinda op in general :P
Probably a controversial opinion but... The biome changes just sound like feature creep that forces players to engage in the game's fundamentally un-fun ground combat. It sounds kinda superfluous to what I view as the core game (the ship design/combat)
It's more like mesons are kinda op in general :P
I wouldn't complain if mesons were moved to a spoiler/ruins only weapon...
One interesting question is what is the dominant terrain type on Earth? At the moment I am leaning toward Temperate ForestUrban.
Urban.This is not a guarantee. You may be fighting over mines, which could be in any biome. Further, the defender would obviously try to prevent an attacker from entering their cities. The strongest anti-air and/or ground-to-orbit weapons will likely be defending the cities. This will mean dropships and troop transports must land outside the urban areas. This means defenders on the ground may end up fighting out in the wilderness. You may also see an attacker try to secure mountains or hills near urban areas to station artillery on them.
...but because that's the terrain you will predominantly be fighting in...
Ground combat creates roles and needs for your ships and different priorities for your industry. For example, armored assault ships or dropships will actually have a point if you need to do a contested orbital landing - this is in direct contrast to right now where all you actually need are commercial-grade transport barges. The biome changes are a means of differentiating ground combats by context and so serve a purpose of deepening it by making it less strategically predictable.
You acknowledge that the problem is that ground combat isn't fun, but for some reason you don't want to see it fixed?I think I could respond to both of these together.
I think biomes could be something that ( along the other changes being made ) makes ground combat more fun and engaging which solves the root issue here. ( ground combat being un-fun ).
In the new ground combat mechanics the real points of conflict are really the GTO units imo.
Hi Steve,
Love the additions to planets with more details. I know you specified the extra details are for fortification levels, however are we going to see this translate to plus and minuses for unit types attack and defence numbers.
E.G. Light Infantry has higher attack and defence when fighting on a wooded planet oppose the a barren planet, Heavy Vehicles have a higher attack on a desert planet opposed to a wooded planet. etc etc.
This would add a great amount of detail with limited coding, well you might need more for the AI armies, maybe you cheat here when AI lands you add the army types at that time, with a slightly more favourable army based on the terrain.
-----------------------------------------------
I know you going to add Supply mechanics to the Ground Battles, which is great, what are the outcomes for units running low on supplies, I am assuming a no attack mechanic, but on the defensive side will we see surrenders and if so is there a chance to capture heavy mechs from the opposition. Also can we research like in space battles when a mech is lost salvaged?
Thanks for your reply
If they're not too much trouble to code, I am always in favour of toggles to turn off sections of the rules for people who don't want to use them, but one of the stated goals of Aurora was to force the player to choose betwen the difficult task of conquering a planet with ground troops, and the easy route of nuking everything to death from orbit, at the cost of having a largely uninhabitable rock.And we didn't need a new combat system or biomes for that. We already have that choice to make right now.
And we didn't need a new combat system or biomes for that. We already have that choice to make right now.Except that's directly against the point he was addressing. the entire point of the person he's replying to is that they just want to ignore ground combat. The fact is, if he wants to ignore ground combat he'll have to find another game because one of the big goals of ground combat in aurora is that you can't just ignore it (or if you do there's going to be major repercussions). Which, by his own attestation, is not the case right now. The bioe system is being added because it's good. Ground combat is being reworked because it's needed it for a long time. The thing under discussion is whether he should be able to just completely ignore ground combat. The design intention of the game would be no.
A hopefully reasonable suggestion. Currently, when designing components, you have an option to type in a company name to incorporate into the auto generated name. It would be cool if you had a little companies window, where you could create a list of named companies that show up in a drop down in the component design screen. It would make it way easier to keep track of all of that for me.
A hopefully reasonable suggestion. Currently, when designing components, you have an option to type in a company name to incorporate into the auto generated name. It would be cool if you had a little companies window, where you could create a list of named companies that show up in a drop down in the component design screen. It would make it way easier to keep track of all of that for me.
Why not simply track all company names that have been used for previous projects and display them in the dropdown instead of having to keep track of it manually? Checkbox option to only display names from same research area, or from all research areas.I thought this was happening. Or did I just dream that?
A question for Steve - would it be hard to have a checkbox in the configuration for 'Simple Ground Combat' that simply follows the old rules and ignore fortification? That'd let people like ChildServices that don't want to deal with ground combat to be able to ignore it as before by plastering the ground units into paste with nukes while leaving something that only glows faintly at night to invade. (As opposed to the new system, where plastering a deeply entrenched army into paste would result in the world having that nuclear glow for the next 10,000 years...)
Please allow energy weapons to use the general missile attack rules as well. On the receiving end the difference is minimal.
Also, nukes in space are far less powerful than nukes in atmosphere (well, less powerful in heat/blast but more powerful in radiation terms)This isn't really true. There are two major differences. First, space is big, and thus you aren't likely to have multiple targets within the damage radius because things are spread out more. Second, spacecraft are pretty durable. There are durable things on Earth, too, but most people's perceptions of nuclear weapons are shaped by very flimsy Japanese houses getting knocked over and dramatic test footage that doesn't give a good sense of scale.
This isn't really true. There are two major differences. First, space is big, and thus you aren't likely to have multiple targets within the damage radius because things are spread out more. Second, spacecraft are pretty durable. There are durable things on Earth, too, but most people's perceptions of nuclear weapons are shaped by very flimsy Japanese houses getting knocked over and dramatic test footage that doesn't give a good sense of scale.
The principle is that missiles are area attack weapons while energy is precision. Against ships, missiles cause damage via near misses while energy is a direct hit.
Also, nukes in space are far less powerful than nukes in atmosphere (well, less powerful in heat/blast but more powerful in radiation terms)
I don't want to have a situation where a ship with a single laser can wipe out an entire civilisation from orbit without any cost, allowing your own colonists to move in the next day. The game play rationale is that while a single nuke could take a out a city, energy weapons are designed to hit specific, small targets.
My comments were based on the results of testing nuclear weapons in space:Is it comparing blasts? No. They just said, that there are no blast in the space. But it's not true, when you deliver powerfull warhead at the durable thick armor vicinity.
https://history.nasa.gov/conghand/nuclear.htm
My comments were based on the results of testing nuclear weapons in space:I'm reasonably familiar with those results. All of the energy from the weapon has to go somewhere. To a first approximation, how badly you are hurt depends on how much energy you get hit with and how durable you are. There's nothing magic about blast which makes it so much more damaging than the flood of X-rays you get in space. Spaceships are durable, but so are lots of other things (just not houses, which may, admittedly, be specifically vulnerable to blast). And space is big, so you're less likely to get multiple targets close enough together to be killed with one hit.
https://history.nasa.gov/conghand/nuclear.htm
no, regular beams will be able to fire STO from ground units.Who unfortunately will have no armor saves against orbital bombardment. :-\
They'll have fortification bonuses, which is arguably better ;)The fortification bonus does not make much sense to me. You can fortify a weapon by building bunkers, but terrain alone will only give you cover. As soon as you open fire, you will give away your position, and you should loose the entire bonus you get. You will get in the first hit, but unless you destroy the attackers in one salvo, they will return fire, and you cannot shift your positions in the few seconds before the return fire comes in.
You could imagine building a bunker system that let's you rapidly reposition STO lasers between bunkers (on maglev or whatever) without the fortified lasers actually being effective offensively on the ground. (The expectation being that laying underground railways isn't an effective attack profile)I can't remember the name of the series, but someone on the forums mentioned a book series in which a planet was defended by a single giant laser deep underground, which could cover the entire sky by bouncing the laser around a system of mirrors. The laser itself never moved, they just turned the mirrors.
It would also explain the lasers ability to potentially die in the first shot. The orbiting warship just got lucky with its game of wack a mole.
I can't remember the name of the series, but someone on the forums mentioned a book series in which a planet was defended by a single giant laser deep underground, which could cover the entire sky by bouncing the laser around a system of mirrors. The laser itself never moved, they just turned the mirrors.
Trojan Gate series by John Ringo.
Has the Fighter weight limit been decreased to 500 tons from 1000 tons?The Fighter mass limit has always been at 500 tons - FAC's have the 1000 ton limit.
Can Troop Transport Ships smaller than 500 tons deliver troops on planet without a drop bay or shuttles?If my understanding of the rules is correct, then yes we should be able to use fighters as drop ships.
Spaceports and Cargo Shuttle Stations can service any number of ships simultaneously but they do not stack. In effect they count as a single Cargo Shuttle Bay for any ship at the population.Wait, does this mean there's no point in building more than one or am I misunderstanding something?
Wait, does this mean there's no point in building more than one or am I misunderstanding something?
As to when it will be completed, that depends on free time and enthusiasm and both of those things are difficult to forecast :)
I would say it is 70-80% done.
@ Forced Labour Camps
Steve, you are writing that 100k population are "consumed" when build - is there a restriction how many you can "transport" or build at a small planet/asteroid?
With the new mechanic to have a "maximum Population" is seems a little bit strange to be able to get f. ex. 5kk "slave labourer" (50 camps) at a 50k max Asteroid?
That is a very good point :)
I'll have to add some restrictions on their use or reverse my decision to consume the population.
That is a very good point :)
There are a few options here.
1) Ignore the population limit for Forced Labour Camps. That isn't too unrealistic as even the small asteroids with a 50k pop limit are still fairly large. For example, a 20 km diameter asteroid has a 50k limit, yet the surface area is over 1250 square kilometres (about 50% larger than New York City). The limit is more about what colonists are likely to accept than a limit on physical size. Slave labour is not going to complain about conditions or overcrowding (at least not very loudly).
2) Have a limit on the number of Forced Labour Camps, based on max pop. Perhaps 1 camp for every 50k max pop
3) Change to a model where the camp is cheap but you need the workers. The problem is that manufacturing population can be very limited, especially on high colony costs worlds, so it may not be practical (this is why I consumed the pop to make the camp).
I think 1) is probably fine, while 2) is probably more realistic but require the player to ensure he doesn't waste camps by going over the limit.
I like 2) the best. . but maybe an alternative 3). .
why not say you need 5-10k population as overseers, guardians etc (inkluding there familys) for a Labour Camp - the 100k "slave workers" are consumed at construction as you said and the 5k "workers" are needed were it is transported to
so you might have 5-10 Camps at a 50k Asteroid (Not unrealistic as you mentioned in 1) but not too many as before), with a ratio of 1:20 or 1:10 workers/overseer including families (or any other ratio) which seems realistic somehow - guess it would be a ratio of 1:40 to 1:20 if you dan't count the families
not sure if that's a good idea but I lke the idea that you need to have guards, overseers etc and there families for a camp instead of dropping them on their own
Can we combine the forced labor camps with the new fortification mechanics somehow? In WW2, many beach defenses, both at Normandy and in the Pacific were built with slave labor. For example, when the Japanese conquered Wake Island, approximately 1000 American civilian contractors working at the airfield were captured. The military personnel at the airbase were all shipped off to prison camps elsewhere in the empire, but those contractors were kept on the island and forced to build defenses.
For the labor camps, is the 5 point of unrest a one time hit when construction is completed only? Is it applied repeatedly each year wherever the camp is deployed?I don't think there's any obvious reason why labour camps should cause unrest in populations they have been brought to. You just have to look at historical slavery to see that the unrest is mainly form the enslaved.
You could build camps at a conquered population where your military is deployed and actively dealing with unrest. Then you ship them somewhere else to take advantage of the productivity. It seems odd to me that the population center where the camps are deployed would have no change in unrest.
I don't think there's any obvious reason why labour camps should cause unrest in populations they have been brought to. You just have to look at historical slavery to see that the unrest is mainly form the enslaved.Conceptually I like this.
I think a better mechanic would be to keep the 5 points of one-off unrest from the construction, but to add in a very small chance each construction cycle that the labor camp as a whole rebels. If that happens the labor camp is destroyed and a enemy ground force of 100k low tech soldiers are created. (This may be too complex, but it would be great if the presence of rebel ground forces then dramatically increased the chance of other local labour camps rebelling).
If my probability skills are up to it, a 0.01% chance of rebellion every 5 day construction cycle would equal about 0.7% chance per year, or 52% chance over 100 years. I think getting an average of 100 years of work out of each labor camp seems pretty reasonable? I'd suggest that rebel ground forces on the same planet increase the chance to 2% per cycle, which is 11% per year. As in, you need to deal with an uprising pretty quickly but not immediately to prevent all your other labor camps joining in.
That would make small numbers of labor camps fairly safe even with a limited TN garrison. But If you put 100 mining camps on a single world? Yep, you have a high chance every year of a small uprising, and if you don't have enough forces to quickly suppress the small uprising then you have a high chance of a catastrophic cascading uprising and 10 millions rebels on the loose.
Steve, with your limited time available for writing C# Aurora I had a question. If someone paid you to develop Aurora (As you saw fit) as a full time job with a decent enough salary would you do it? Do you work on computers, with code of some sort for your day job?
I don't think there's any obvious reason why labour camps should cause unrest in populations they have been brought to. You just have to look at historical slavery to see that the unrest is mainly form the enslaved.
I think a better mechanic would be to keep the 5 points of one-off unrest from the construction, but to add in a very small chance each construction cycle that the labor camp as a whole rebels. If that happens the labor camp is destroyed and a enemy ground force of 100k low tech soldiers are created. (This may be too complex, but it would be great if the presence of rebel ground forces then dramatically increased the chance of other local labour camps rebelling).
If my probability skills are up to it, a 0.01% chance of rebellion every 5 day construction cycle would equal about 0.7% chance per year, or 52% chance over 100 years. I think getting an average of 100 years of work out of each labor camp seems pretty reasonable? I'd suggest that rebel ground forces on the same planet increase the chance to 2% per cycle, which is 11% per year. As in, you need to deal with an uprising pretty quickly but not immediately to prevent all your other labor camps joining in.
That would make small numbers of labor camps fairly safe even with a limited TN garrison. But If you put 100 mining camps on a single world? Yep, you have a high chance every year of a small uprising, and if you don't have enough forces to quickly suppress the small uprising then you have a high chance of a catastrophic cascading uprising and 10 millions rebels on the loose.
A rebellion should be able to convert camps to factories and mines at some ratio though, should they manage to take control of the planet. Leave them alone for long enough and you might find an unpleasant result...I imagine the rebels would be treated as a standard NPC who could take control of the planet?
I'm director of business analytics at PokerStars, which is a large online gaming company. It's a reasonably well-paid job that I really enjoy. Because we are based on an island most of the staff live relatively close together, so there is also a great social life. If I worked full-time on Aurora, I can see several issues:
1) I might get bored if that was my full-time job. I appreciate the time that I do get to spend on Aurora, but that appreciation might disappear with unlimited time.
2) I have had three previous hobbies that turned into jobs and they were never as much fun once they become my day job. That is why I haven't tried to make money from Aurora, to avoid the same situation.
3) It would be a fairly solitary existence, apart from my family. In my current job (almost 7 years now), it is all about personal interactions (well, with some analytics thrown in :) ), and I would miss that.
Releasing it on steam would be a categorically terrible idea.
It's a bit of a shame that your fans can't spend money that could be used to improve the game if you ask me.
Yes, because if you want to sell anything it's categorically a terrible idea to sell it where 95% of all customers go to buy those things? ??? ::)I think the point is that Steve doesn't want to sell it. Selling something means customers and customers are demanding.
I think the point is that Steve doesn't want to sell it. Selling something means customers and customers are demanding.
I'm fairly certain if you send money to Steve, he won't object. :)
I think the point is that Steve doesn't want to sell it. Selling something means customers and customers are demanding.
I think the point is that Steve doesn't want to sell it. Selling something means customers and customers are demanding.
there are a lot easier ways to make moneyas example?? ;D
as example?? ;D
Developing a broad-appeal game for a wide audience.
No not really... Game development in general is a horrible way to earn money just like music or arts. A top 1% or less get lucky and end up swimming in money ( minecraft/PUBG ) while the majority of developers struggle to make a living while working 12h days and weekends.
But it's better than developing a niche game for a small audience. As far as making money goes.
Has there been any discussion on possible changes to the way combat is controlled? I am specifically thinking about point defenses - it would be nice to be able to set a minimum engagement distance as well as a minimum salvo size. So for instance, set your AMMs to only fire at incoming salvos that contain at least X number of missiles and are between Y and Z million km distant.
So a unit with 4 armour would be 50% more expensive with 6 armour.
I'd quote it directly linked to the originating comment, but there's a typo I spotted.
This should probably be a unit with 6 armour would be 50% more expensive than a unit 4 armour.
Just a possible balance consideration, but light vehicles seem straight up better than static.
Now, I didn't miss that static can be fortified more. But the rules note that chance to hit is the base chance / fortification level, and in the same situation static shouldn't ever have more than twice the fortification of a light vehicle, whereas the base chance to hit the light vehicle is a quarter that of the static. So even assuming a 6 fortification static vs a 3 fortification vehicle, the vehicle has half the chance to be hit. Since it's proportional, this is true even on planets with fortification multipliers (ie on a mountain world it would just be fortification 12 static vs 6 light vehicle, and the vehicle would still have half the chance to be hit).
Unless the base chance to hit and fortification levels are supposed to be one or the other? It would make sense that a vehicle in a bunker couldn't use its speed to avoid fire, after all. I suppose it's also possible that static can use some components vehicles can't, but even in that case it would mean static are only practical when using those specific components.
Seems like the best way to address it might be to make the base size of Static units much lower, perhaps as low as 3. Since the size of the component is added to the unit and determines cost, this would make static units cheaper and easier to transport than light vehicles, but considerably more fragile (especially when not heavily fortified).
With size 3, that would make a static crew served antipersonnel gun size 15 and an equivalent vehicle size 24. All other things (such as armor) being equal, the static would cost 62.5% as much, a given transport could carry 60% more, and both would have the same firepower. However the static would take twice as much damage if both were at maximum fortification or 4x as much damage if they were not fortified at all, which seems a reasonable tradeoff. Or looking at it another way, for equal resources Static guns would have 1.6x the firepower and .8x the resilience at maximum fortification, or 1.6x the firepower and .4x the resilience with no fortification. Statistically, the advantage would get smaller with larger weapons.
At least, if I'm understanding the system right.
Edit: Looking at it I also think light vehicles might be straight up better than normal vehicles, since you're trading a 37.5% lower chance of being hit by every single attack for a 33% higher chance of surviving some hits (hp 4 instead of 3), though that's less clear and there may be other advantages to larger vehicles not clear from the post.
Weapons should generally target the units they are best at destroying; that's how they work in real life, after all. Generally speaking you don't use an AT missile on a squad of infantry, you may need that missile later in the same fight against their IFV or an actual tank after all.
Figuring out which weapon to use on which target at what time is a pretty complex thing though. Might just be easier for Steve to keep out of that mess.
I have to agree - on the other side, it would be a nice "new skill" for ground commanders to influence the ratio of the "best unit fired upon"That seems a very good idea. The new ground combat model provides a lot of opportunities for new commander skills. Looking at Steve's recent post on how the shot mechanics work the opportunities appear to be;
Weapons should generally target the units they are best at destroying; that's how they work in real life, after all. Generally speaking you don't use an AT missile on a squad of infantry, you may need that missile later in the same fight against their IFV or an actual tank after all.
Figuring out which weapon to use on which target at what time is a pretty complex thing though. Might just be easier for Steve to keep out of that mess.
So, I think a more simplistic approach would be better. During each combat phase, each formation on each side will target a random hostile formation (probably using some form of weighting based on formation size). Over time, this should result in a relatively even distribution of fire. Once a target formation is selected, each element in the attacking formation (plus elements from supporting formations) will target an element in the opposing formation. At this point, there could be some weighting toward suitable targets (in other words, you don't get to choose which enemy formation you fight but you do influence which targets in that formations are suitable for the units in your formations).
There are a few ways to handle this. For example, certain component types have preferred targets (infantry weapons target infantry for example). However, it becomes trickier for anti-vehicle. If you have Medium AV, do you want to engage any vehicle, or just medium / light or just medium / heavy. What if nothing else is available to target super-heavy, etc.? What about auto-cannon, which are useful against infantry and light vehicles?
To avoid getting over-complicated, perhaps the easiest is have three categories of target. 1) Infantry / Static. 2) Light & Medium Vehicles. 3) Heavy+ Vehicles. When a new Unit Class is designed, the player specifies the preferred target type. When a formation element containing that Unit Class chooses a target formation element, it will do so on weighted size, but any hostile formation elements with the preferred target type will count as double (perhaps triple) size. This means the formation element will devote more effort toward engaging an appropriate target but may still be forced to engage a different target due to the ebb and flow of battle.
This means that when you create a formation for a particular purpose (anti-armour for example), it may still be worth including elements that can handle different target types.
It will be possible for support or even rear-echelon formations to sometimes find themselves on the front line due to the ebb and flow of battle. Each combat phase, the total size of the support formations will be compared to the total size of the front-line formations. Once that ratio passes a certain point (yet to be determined), there will be an increasing chance that one of more support formations will be temporarily assigned as 'front-line' and subject to engagement by enemy forces. There will also be a much smaller chance for the same situation to occur with rear echelon formations. In principle, it will be necessary to maintain a sufficient mass of front-line formations (infantry will be the cheapest option), to protect the supporting and rear echelon formations.This suggests another (and more reasonable) use for Mobility: A multiplier to effective frontage, rather than as a dodge bonus to hit. The primary utility of speed on the battlefield is that it allows you to concentrate forces, not that it allows you to outrun the other guy's firing solution.
Can I reiterate that I think this creates a very unbalanced situation?
I just want to bring something up. You mention formations matching up and then determining targets. Let's say my opponent has two formations of mixed infantry and heavy tanks. And I have two formations, but one is all infantry and one is all heavily armored heavy tanks. Or maybe the infantry division is mixed lightly armored vehicles/statics to give it an equal number of heavy anti-vehicle weapons to the mixed formations; the biggest issue is mixing armor values, with HP only a secondary consideration.
My specialized formations are going to *slaughter* the mixed formations if weapons have preferential targeting. Because firing against mixed formations all weapons will fire with close to optimum efficiency (anti-infantry going after soldiers, anti-tank going after tanks, etc) whereas the weapons fired in return can't do the same thing; basically using specialized formations "forces" enemy weapons to target randomly because the target formation is picked randomly. And since I can split units off by formation the end result is that I can still use a mix of unit types, as long as each has their own formation, since it sounds like a formation can't fire anti-tank at one formation and anti-infantry at another (which, mind you, I don't think they should).
I mean, let's assume (from looking at the stats), that on average matching the opponent's armor with penetration results in 4x the efficiency as either not penetrating or over-penetrating (ie hitting a single soldier with an anti-tank gun). Obviously that number varies depending on how much/how little your penetration is off, but from my numbers 4x seems a decent average. Assuming a rough mix of weapon types, that means a formation of all the same armor value is doing about 60% more damage to a mixed formation then they are doing to it.
So this basically creates a situation where you want an entire formation to have the same armor value for all elements (and to a lesser extent the same hp when possible). If that's what you prefer to be the emergent tactic, then that's fine (it's actually much better than when I thought weapons could fire on any target, since now you can still used mixed armies as long as they aren't mixed in an individual formation), but I just wanted to note it. I know it seems unrealistic to have anti-tank weapons only randomly pick between infantry and tanks, but in the math it actually works out as more balanced, because against specialized formations weapons are targeting randomly anyways, so it also makes sense they should do it when fighting mixed formations.
Edit: Also, my apologies if all these posts are coming off as me being demanding. I'm happy with whatever system you go with (and the current system with formation based target works fine as long as you don't create mixed formations); I guess I'm just excited about the changes and going overboard with suggestions.
Can I reiterate that I think this creates a very unbalanced situation?
I just want to bring something up. You mention formations matching up and then determining targets. Let's say my opponent has two formations of mixed infantry and heavy tanks. And I have two formations, but one is all infantry and one is all heavily armored heavy tanks. Or maybe the infantry division is mixed lightly armored vehicles/statics to give it an equal number of heavy anti-vehicle weapons to the mixed formations; the biggest issue is mixing armor values, with HP only a secondary consideration.
My specialized formations are going to *slaughter* the mixed formations if weapons have preferential targeting. Because firing against mixed formations all weapons will fire with close to optimum efficiency (anti-infantry going after soldiers, anti-tank going after tanks, etc) whereas the weapons fired in return can't do the same thing; basically using specialized formations "forces" enemy weapons to target randomly because the target formation is picked randomly. And since I can split units off by formation the end result is that I can still use a mix of unit types, as long as each has their own formation, since it sounds like a formation can't fire anti-tank at one formation and anti-infantry at another (which, mind you, I don't think they should).
I mean, let's assume (from looking at the stats), that on average matching the opponent's armor with penetration results in 4x the efficiency as either not penetrating or over-penetrating (ie hitting a single soldier with an anti-tank gun). Obviously that number varies depending on how much/how little your penetration is off, but from my numbers 4x seems a decent average. Assuming a rough mix of weapon types, that means a formation of all the same armor value is doing about 60% more damage to a mixed formation then they are doing to it.
So this basically creates a situation where you want an entire formation to have the same armor value for all elements (and to a lesser extent the same hp when possible). If that's what you prefer to be the emergent tactic, then that's fine (it's actually much better than when I thought weapons could fire on any target, since now you can still used mixed armies as long as they aren't mixed in an individual formation), but I just wanted to note it. I know it seems unrealistic to have anti-tank weapons only randomly pick between infantry and tanks, but in the math it actually works out as more balanced, because against specialized formations weapons are targeting randomly anyways, so it also makes sense they should do it when fighting mixed formations.
Edit: Also, my apologies if all these posts are coming off as me being demanding. I'm happy with whatever system you go with (and the current system with formation based target works fine as long as you don't create mixed formations); I guess I'm just excited about the changes and going overboard with suggestions.
I had the very same concern reading this. I would vastly prefer for mixed formations to emerge as the most viable option. The system as described has no benefit from any interplay between the different components of a formation defensively, which is definitely not the case in RL modern combat.
The reason tanks alone don't dominate is because infantry can endlessly ambush them with their poor visibility. With infantry in support however they become vastly more powerful as the friendly infantry can hold their backs while the tanks demolish any opposition with their guns and heavy machine guns.
Could one introduce some 'awareness' mechanic which is mostly provided by infantry? If you have insufficient awareness, you gain more and more chance of running into ambushes, where you take disproportional damage, and inflict minimal damage in return. That would also in turn require to introduce a notion of a pairing again, to get units to fight each other and affect each other.
The other option would be to free targeting entirely, and let each formation engage targets in different formations, but that would defeat the point of having fixed formations in the first place.
On the flip side, tanks, IFV, APCs could increase mobility of a formation, increasing the chance of a breakthrough and engaging support or rear echelon formations.
The preferred targeting only increases the chance of targeting the ideal target - it isn't guaranteed. And that is assuming you end up targeting a formation that includes your preferred target. For example, if your heavy tank formation is fighting an infantry formation (with different types of infantry, including AT), the heavy armour formation won't be very effective because even with preferred targeted, there is no armour to target. Equally if your all-infantry formation runs into a heavy armour formation that won't be very effective either, especially if it is anti-infantry armour. If heavy armour runs into mixed, then assuming the armour and infantry in the mixed formation are equal sizes, there will be 33% chance of targeting the infantry, while the opposing armour will have an ideal target 100% of the time.
The combination of random formation selection and weighted formation element selection (based on preference) should mean sufficient randomness to have formations fighting outside their comfort zone, while giving them a decent chance of encountering a preferred enemy. I don't think we should have an entirely random selection regarding who targets who. In fact, I was wondering whether double weight to preferred targets was enough.
That is assuming that the specialised formation is a) assigned a formation that contains an element with their preferred target type and b) is assigned the preferred element during target selection (which is in no way guaranteed). The specialised formation could easily end up completely unsuited to its opponent formation. I think mixed formations are probably the safer option, but both should work. Also, bear in mind that mixed doesn't necessarily mean infantry and armour, it could mean armour designed to fight armour plus armour designed to fight infantry, or a multi-role rank designed to do both.
I don't believe it is true that specialised is best or equal armour is best. It will depend on the type of opponent encountered. For example, take the two tank designs below. The former will fare well against armour and the latter against infantry. Although the Hellhound has only two-thirds of the armour and is designed to fight infantry, it is also less than a quarter of the cost. A mixed formation of 40 Leman Russ and 180 Hellhounds would massacre infantry and, while it would be at a disadvantage against a specialised heavy armour formation (say 80x Leman Russ), it isn't that bad because the Hellhounds take the same amount to kill as the Leman Russ when attacking by Heavy AV and they cost far less. In other words, the specialised formation would actually kill less BP value than the mixed formation in a straight-up fight if they concentrated on the Hellhounds (which will happen one third of the time).
Leman Russ Annihilator
Transport Size (tons) 132 Cost 15.84 Armour 60 Hit Points 60
Preferred Target Type Heavy Vehicles
Heavy Anti-Vehicle: Shots 1 Penetration 60 Damage 60
Heavy Anti-Vehicle: Shots 1 Penetration 60 Damage 60
Hellhound Anti-Infantry Tank
Transport Size (tons) 42 Cost 3.36 Armour 40 Hit Points 40
Preferred Target Type Infantry / Static
Crew-Served Anti-Personnel: Shots 6 Penetration 10 Damage 10
Crew-Served Anti-Personnel: Shots 6 Penetration 10 Damage 10
In other words, the specialised formation would actually kill less BP value than the mixed formation in a straight-up fight if they concentrated on the Hellhounds (which will happen one third of the time).But the point is that if you split the mixed formation then (assuming formation-level targeting is randomized by transport size), the 33 % conditional probability of targeting the Hellhound element goes up to 189/321 ~ 59 %, while all other numbers remain the same, so the two specialized formations are more efficient and effective than the single joint one. Likewise, for an enemy formation that prefers to target the Hellhounds, the conditional probability of instead targeting the Russ tanks goes up from 33 % to 41 %, a smaller but still meaningful effect.
This is a situation where intuitive understanding disagrees with actual reality, unfortunately. I know you think preferential targeting not always hitting the right target should help, and it sounds like it should help, but I'm trying to show you that it really doesn't.
So, I will go with both random formation matching and random element targeting and I remove the preferred targeting option. It will be the overall strategic mix of forces that will matter, plus how the formations hierarchies are setup. I probably should also split ground forces bonuses for commanders into different types (armour, infantry, artillery, etc. ).
The MSP use for the attacking stance is interesting here - how is the MSP resupply managed? The attacking forces drop with a certain amount of MSP, and need to be replenished via ship? What determines how much MSP they drop with? Can the MSP resupply be intercepted by STO/AA? Is there a role for a military logistic element, necessary for receiving supply from orbit? How long are these battles intended to take, and how fast will the MSP consumption be?
Additionally - if we assume the player is invading an NPR, what will be known about the defending forces before the invasion? Will you be able to tell via scouting/diplomacy/espionage that there are X STO weapons and Y forations, comprising at least #Z heavy tanks?
This all sounds really cool - like designing new ship classes bt one concern might be, how will the simulation be reported to the player? My invasion force was destroyed, but why? Will the formation/damage/targetting calculations be visible to the player?
So, takeaways:
Setting your entire frontline on attack is basically always a benefit unless you have a quite high fortification level (3+ for Static, 5+ for infantry or tanks, 7.5 for light vehicles), assuming you have the supplies
Light vehicles will benefit immensely from being set on attack
It's overall a major nerf to the defensive side; they're basically robbed of most or all of the their fortification bonus if the enemy can set their army on front line attack, but can't use it themselves without losing the bonus entirely
In all honesty, if it were me designing the game I'd probably drop it; defenders need an advantage since they're going to frequently be outnumbered/outgunned. Actually, I'd probably just limit the field positions to front line and rear echelon; I feel a game as complex as Aurora doesn't need a lot of ground combat complexity as well. However, that's just my opinion, and it's not one I have strong feelings about; I don't feel anywhere near as strongly about it as I did about the preferential targeting, for instance.
Woops, forgot to login to ask this so this might've gone to the moderators as a guest post.
Will we be able to assign formations to have a preferred commander type or will the game automatically assign those commanders to the formations with the highest proportions of that type of unit?
There are two options for logistics (which will only be needed for combat). The first is a stockpile of supply points, but my current favourite is having logistics units which are built primarily with supply points and are used up during combat. However, in the latter case, the tricky part is the mechanics for exactly how they logistic units are consumed. They could be tracked exactly, or perhaps a more interesting option is for each element that fires to have a small chance of using up a logistic unit (depending on size of element and size of logistic unit). Having variable rates of consumption in the short term (although steady in the long term) would be another layer of interest to an invasion. Might also need a ship to run in supplies past the planetary defences for longer sieges, plus there is the chance of hostile fire damaging the logistic units.
You will learn about defending forces as the battle progresses. Unit class capability and names, formation names, etc. Some idea of total forces engaged. In fact, maybe I should include intelligence unit components to speed up that process.
Please don't let players attack a planet entirely devoid of information on enemy formations on planet. A rough estimate that's potentially completely off is fine, but it kind of sucks if you dump several thousand BP of troops on a planet and have it wiped out by an endless stack of doom you could not know was there.
It is a good point about equating front line attack with fortification. While I looked upon the mechanic as a way of overcoming hostile fortification, I hadn't considered that was it effectively defensive as well, by creating more shots before being destroyed. I also agree that is actually makes sense to put everything on attack, which was my main concern. I guess the usefulness would be very dependent on just how critical supplies were. Probably too many unknown factors to commit to this path.
You are probably correct that I am adding more complexity than is really necessary :). Perhaps I should change the concept of front-line attack (more attacks to try to beat back fortifications) to a more unit-specific capability. Some form of combat engineers perhaps that can reduce hostile fortification, although they will consume more supplies and attract fire while doing so.
Another simplification would be to combine Support and Support-Counter-battery to a single Support option. When a supporting formation selects the random hostile enemy element to bombard, it will select from the enemy formation on the front-line plus any enemy support formations supporting that enemy formation.
Please don't let players attack a planet entirely devoid of information on enemy formations on planet. A rough estimate that's potentially completely off is fine, but it kind of sucks if you dump several thousand BP of troops on a planet and have it wiped out by an endless stack of doom you could not know was there.
Steve can I make a suggestion that defender fires first. This would lead more into the idea that an attack tends to take more losses and needs a higher ratio of troops to take the ground.
Also will you give the option to go guerrilla, this basically take away all heavy equipment and the attacker has a much harder time, completely destroying these units. The opposing force captures the planet. But what it allows is time for reinforcements to come back and these units reconstituted with experience if they survive.
Also steve, how long do you expect to say a 10 Division v 5 Division fight to last. 1 year or like it is now like 3 months, I would like to see longer fights, to give reinforcement and supply issues, a chance to influence the battle. And can there be a small trickle to the defenders from local population for reinforcements.
It is a good point about equating front line attack with fortification. While I looked upon the mechanic as a way of overcoming hostile fortification, I hadn't considered that was it effectively defensive as well, by creating more shots before being destroyed. I also agree that is actually makes sense to put everything on attack, which was my main concern. I guess the usefulness would be very dependent on just how critical supplies were. Probably too many unknown factors to commit to this path.
You are probably correct that I am adding more complexity than is really necessary :). Perhaps I should change the concept of front-line attack (more attacks to try to beat back fortifications) to a more unit-specific capability. Some form of combat engineers perhaps that can reduce hostile fortification, although they will consume more supplies and attract fire while doing so.
Steve I think if you see my additions to my last post about frontage number it might kill two birds with on stone in regards to adding to the length of combat as well as the stack of doom beating defenders without adding length, stacks of dooms will always win, however its about adding length of time for the defender to get additional resource to the fight, before it is over.
Replying to my own points here :)
The original reason for having the Attack vs Defence option was to have some reason to come out of fortifications and attack. Is it sufficient that an attacker will be bereft of his own substantial fortifications (for a while anyway), although that wouldn't be true for two long-standing populations? If a post-invasion fight takes long enough, the attacker will settle down into his own fortifications as well. Or should there be some advantage to foregoing or giving up fortifications for some greater chance of damaging the enemy?
Perhaps attacking units (going back to the concept of Front-Line Attack vs Front-Line defence but without the extra attacks) have an chance to damage enemy fortifications, or perhaps if they cause sufficient damage they can cause enemy formations to lose morale or break (when that wouldn't be possible when fighting from their own fortifications).
Open to suggestion about a mechanic where coming out to attack has a useful advantage in certain situations.
Replying to my own points here :)
The original reason for having the Attack vs Defence option was to have some reason to come out of fortifications and attack. Is it sufficient that an attacker will be bereft of his own substantial fortifications (for a while anyway), although that wouldn't be true for two long-standing populations? If a post-invasion fight takes long enough, the attacker will settle down into his own fortifications as well. Or should there be some advantage to foregoing or giving up fortifications for some greater chance of damaging the enemy?
Perhaps attacking units (going back to the concept of Front-Line Attack vs Front-Line defence but without the extra attacks) have an chance to damage enemy fortifications, or perhaps if they cause sufficient damage they can cause enemy formations to lose morale or break (when that wouldn't be possible when fighting from their own fortifications).
Open to suggestion about a mechanic where coming out to attack has a useful advantage in certain situations.
Open to suggestion about a mechanic where coming out to attack has a useful advantage in certain situations.
Speaking of that, one minor thing that I didn't notice being explicitly mentioned (although I suspect you would have noticed when you got to it if you haven't already): if a formation is set as Support or Rear Echelon and is attacked, any element of that formation with direct combat capability ought to be able to shoot back at the attackers. Otherwise there wouldn't beanymuch point in attaching a platoon of infantry to guard your headquarters/artillery park/whatever. Whether bombardment weapons tasked to support should also be able to target formations directly assaulting them is arguably messier, but leaving it to random chance would create enough variation to tell all the different possible stories - shelling their proper target even as they're overrun, turning the guns on a small band of skirmishers while the army bleeds on the fortifications they were tasked to suppress...
Sorry if this was answered before, but I gotta ask:
Is there going to be a "maximum rank" setting like there was a minimum rank setting on the ship design screen to keep admirals from piloting shuttles?
I'll second the point that formations on the defensive are obviously not going to be penetrating enemy lines to savage their relatively vulnerable support or rear echelon forces. Some of the other suggestions are intriguing, but that one is the obvious starting point.
Speaking of that, one minor thing that I didn't notice being explicitly mentioned (although I suspect you would have noticed when you got to it if you haven't already): if a formation is set as Support or Rear Echelon and is attacked, any element of that formation with direct combat capability ought to be able to shoot back at the attackers. Otherwise there wouldn't beanymuch point in attaching a platoon of infantry to guard your headquarters/artillery park/whatever. Whether bombardment weapons tasked to support should also be able to target formations directly assaulting them is arguably messier, but leaving it to random chance would create enough variation to tell all the different possible stories - shelling their proper target even as they're overrun, turning the guns on a small band of skirmishers while the army bleeds on the fortifications they were tasked to suppress...
Thanks for the suggestions on attack vs defence. I just wanted to point out that when I talked about coming out of the fortifications, I meant both sides, not just the defender. One of the things I haven't addressed yet is whether formations can fortify while in combat. With no benefit to an attack vs defence stance, it makes sense for an attacker to fortify, because then he gains defence without sacrificing offence and will eventually reach parity with defender. It shouldn't be the case that the constant best strategy for an invading force is to fortify. This is what I am trying to avoid by providing some benefit to attacking. I can address this by making it hard to fortify in combat, which means that fortifications will generally be a defender benefit, or find some reason for an attacker not to fortify in some cases, or perhaps a combination of both.Maybe I'm missing something, but I'd just keep things simple. If you're on an attack order then you attack the enemy (using your stated targeting rules) but with no fortification bonus. If you're on defense then you get your fortification bonus but you simply don't get to attack. If both sides are set entirely on defence then no direct combat actually happens.
I agree it makes sense for only attacking formations to be able to reach defending support and rear echelon formations. It probably also makes sense to give them a chance to reduce enemy fortifications in some way.
Perhaps in terms of fortifying in combat, any formation not attacking should automatically fortify. However, the rate of fortification should be slowed when the formation suffers casualties.
Maybe I'm missing something, but I'd just keep things simple. If you're on an attack order then you attack the enemy (using your stated targeting rules) but with no fortification bonus. If you're on defense then you get your fortification bonus but you simply don't get to attack. If both sides are set entirely on defence then no direct combat actually happens.
So the reason people have to commit troops to attack is that otherwise they won't achieve anything. An invader building fortifications will help against a counter assault but do nothing otherwise.
The only extra complication with this is for your support fire rules. You'd probably want to be able to use artillery against enemy trenches even if no front line troops are attacking. Perhaps undirected support units fire on a randomly targeted front line formation but with a much lower chance to hit (75% to hit penalty?)
- Finally on the aircraft position have you given any thoughts to giving forces an air cover status and having bonuses / penalties based on air cover level. Ie covered, contested, unprotected, air superiority. Aircraft should have specific orders to attack other aircraft, defend or attack surface to air units. Clearly if you loose air cover you should be at a penalty on deployment and also should allow better intel for the force with air superiority.
Originally, I wanted a situation where both sides on defence result in a low-intensity combat but once someone attacks it becomes more intense. There are issues with that approach though as highlighted by Bremen, because it becomes too advantageous to attack. Similarly, in a situation where defence means no firing, there is no disadvantage to attacking. One option though would be defence means no firing unless attacked, in which case you get to fire back. However, that leads to creating a few huge formations so your returning of fire becomes more effective. The solution needs to be size-independent. Also, a situation where defence means a lower chance to hit is the same as a situation where attacking increases the chance to hit.
Originally, I wanted a situation where both sides on defence result in a low-intensity combat but once someone attacks it becomes more intense. There are issues with that approach though as highlighted by Bremen, because it becomes too advantageous to attack. Similarly, in a situation where defence means no firing, there is no disadvantage to attacking. One option though would be defence means no firing unless attacked, in which case you get to fire back. However, that leads to creating a few huge formations so your returning of fire becomes more effective. The solution needs to be size-independent. Also, a situation where defence means a lower chance to hit is the same as a situation where attacking increases the chance to hit.Again, thinking simplistically can you get around the formation size problem by you just removing the formation all together for combat? You could lump every formation on the same order into a single "army", process attacks and defensive fire for the whole army and then divide up the losses between the constituent formations? If you really want 2 large formations on attack and 20 small formations on attack to be exactly equal then the simplest solution is to reduce both to 1 identical army.
On the other hand, I was thinking of attack as more like a fast assault, and therefor two sides both on defense would work out more like trench warfare in WWI, with constant skirmishing. This would probably result in a simpler, more attrition based fight, but that isn't a downside to me (to me the strategy and complexity is more in the strategic layer and space battles).
An invader could set their troops on defense and settle in for the long haul; they wouldn't have any fortification at first, but would slowly build some. Or they could go for an quick assault, hoping to disable the enemy STO weapons quickly as well as take some of the territory which is the whole point of invading in the first place.
not optimal but ... ground combat with all the detail the new design mechanic opens up will be highly complicated, a system wich Steve has a lot time to invest but proofs to be "the same as before", too complicated, too one-sided, too broring or too stressful etcpp would be lost time and even more unsatisfying as it would be "lots of work with nothing gained" ... better to make it workable for the moment and plan to make it "really work with all the details" and rightly planed in C#1.1
For what it's worth I entirely agree with Steve on this.
Planetary warfare is a completely different beast then galactic warfare. In small thinking, it does not matter if you do have the best aircrafts in the world if you not able to take ports or structure on the ground with as effective troops. This option will bring an actual different thinking level while planning invasions. My guess is AI will use different formations and doctrines as well therefore just drop unit or bombard a planet will not guarantee your success like it was pretty much done with the old system where only a few units were available. @Steve Walmsley sorry to bother you, but are you also thinking to introduce some sort of exhaustion to ground units? I've seen the terrain modifiers, but I believe a sort of exhaustion factor will simulate the logistic/supply penalty of long wars with the possibility of introducing an engineer or logistic division able to mitigate such effects adding an extra layer of strategy/planning. Basically, these units will provide the required supplies to carry on daily operations. The possibility of having these units "mandatory" (not only for invasions but pretty much used as maintenance supply works for warships) will probably make it easier to program rather than a separate mechanism which I guess will be hard for you as for anybody to set up.
Thanks
There will be some form of logistic units. I've been holding off on exactly how they work because of issues around tracking supply point usage but it finally struck me how to do it. Each logistic unit (probably static base type) will use up a set amount of maintenance supply points (MSP) during creation. When combat takes place, each side will use up a certain amount of MSP (to be determined) during each combat phase, based on that type of units engaged.
Lets assume that each logistic unit includes 100 MSP. If combat consumes 230 MSP that would use up two logistic units with a 30% chance of a third unit being consumed. Over time, that will work out fine with no record-keeping needed. If no logistic units remain then combat will become far less effective (major penalty to hit, or perhaps no offensive fire at all). This will give an incentive to land a number of logistic units with the initial invasion, plus the potential for resupply runs against hostile defences.
There will be some form of logistic units. I've been holding off on exactly how they work because of issues around tracking supply point usage but it finally struck me how to do it. Each logistic unit (probably static base type) will use up a set amount of maintenance supply points (MSP) during creation. When combat takes place, each side will use up a certain amount of MSP (to be determined) during each combat phase, based on that type of units engaged.
Lets assume that each logistic unit includes 100 MSP. If combat consumes 230 MSP that would use up two logistic units with a 30% chance of a third unit being consumed. Over time, that will work out fine with no record-keeping needed. If no logistic units remain then combat will become far less effective (major penalty to hit, or perhaps no offensive fire at all). This will give an incentive to land a number of logistic units with the initial invasion, plus the potential for resupply runs against hostile defences.
I think we need a way to have the ground combat module work for all ground targets (including atmospheric fighters). In real life, practically every fighter can carry every type of ordnance.But this is actually cost-effectiveness question. Because high-tech planes are so insanely expensive, they need to be able to perform multiple roles. Even so, there still are fighter/bombers and bombers.
But this is actually cost-effectiveness question. Because high-tech planes are so insanely expensive, they need to be able to perform multiple roles. Even so, there still are fighter/bombers and bombers.
It's not that many decades ago when planes had very strict role separation - you had fighters, (ground)attack planes, light/medium/heavy bombers, dive bombers, torpedo bombers and long-range recon planes, and more. Partially it was because of technical limitations but specialized planes were usually better in their dedicated role.
The main reason IMHO why we have such a massive focus on quality today is that a single piece of equipment ( plane or submarine ) on it's own carries enough missiles/nuke warheads to totally flatten a whole country.
Imagine if a single 500 ton fighters in Aurora 4X could fire 50 nukes each of them being almost impossible to stop, individually targeted and with 75 times more firepower then it takes to wreck a capital city...
Then you hardly would mind paying 10 or even 50 times as much for superior quality since you only need a single bomber getting through and launching to inflict certain doom for your opponent.
But this is actually cost-effectiveness question. Because high-tech planes are so insanely expensive, they need to be able to perform multiple roles. Even so, there still are fighter/bombers and bombers.Of course you had, and still have specialized planes. But you'd be hard-pressed to find a single fighter from the 30's on which was unable to carry any bombs at all. The P51 for instance was designed to escort strategic bombers at high altitude. And yet even the P51 could carry up to 1000lbs of bombs.
It's not that many decades ago when planes had very strict role separation - you had fighters, (ground)attack planes, light/medium/heavy bombers, dive bombers, torpedo bombers and long-range recon planes, and more. Partially it was because of technical limitations but specialized planes were usually better in their dedicated role.
Having said that, I'd prefer if both approaches are possible - even better if one approach is better early in the game and the other gets better later as tech improves, or something like that.
The reasons for high quality and expensive aircraft are that in peace production runs are limited and because, quite frankly, you need high quality aircraft to compete or an utterly uneconomic investment in low quality aircraft.While you are correct, there is more the issue. WW2 era planes hit that sweet spot where planes were just efficient enough to be valuable in great numbers while still being simple enough to be mass-produced in gigantic numbers. No matter what, USA will never build 295,959 modern jet planes in 5 years, like they did from 1940 to 1945. John Buckley discusses this topic in great detail in his fine "Air Power in the Age of Total War" book.
No seriously, in a war those extremely expensive aircraft will drop in price because the R&D costs and the prices of the factories and machines to build those planes and their parts can be spread over many times their peace time sales number.
No matter what, USA will never build 295,959 modern jet planes in 5 years, like they did from 1940 to 1945. John Buckley discusses this topic in great detail in his fine "Air Power in the Age of Total War" book.
I think that the idea is that having logistics units means a fleet can just drop the infantry units and leave orbit without also needing an order to drop x MSP.
Instead, would it be possible to just set an MSP stockpile for a formation in the same way that you set deployment time while designing ships? Ideally it would then show you an estimate on how long the supplies would last for normal usage and combat. Then the formation's cost and transport size could increase proportionately (but without any additional units/elements in the formation), and when you landed the units they would take the MSP with them. If on a planet with an MSP stockpile ground units would then attempt to refill up to their designated stockpile size.
I think we need a way to have the ground combat module work for all ground targets (including atmospheric fighters). In real life, practically every fighter can carry every type of ordnance. The F18 Hornet can carry dumb bombs, GPS-guided bombs, laser guided bombs, unguided rockets, multiple kinds of air-to-air missiles, multiple kinds of anti-tank missiles, multiple kinds of anti-ship missiles, gun pods of varying calibers, extra fuel tanks, and ECM pods. And these are all attached shortly before take-off. You don't have to buy totally separate plane if you want to change from dropping bombs to shooting rockets.
I think instead, we should have one ground combat module that, when the fighter is launched from the mothership, must be set as to what kind of weapon it will carry. I would give fighters a higher chance to target their preferred target type as well. As a trade-off I would require the fighters to return to their carrier and rearm, draining MSP (or a new kind of supply, called "Conventional Ordnance" or something) from the carrier.
Open to suggestion about a mechanic where coming out to attack has a useful advantage in certain situations.
Open to suggestion about a mechanic where coming out to attack has a useful advantage in certain situations.
The issue with the MSP stockpile concept is getting the MSP to the planet. For cargo, colonists and troops, you need time to unload. I haven't decided whether to extend this to maintenance yet. Even so, it doesn't seem realistic to instantly dump a large stockpile of maintenance during an invasion, which is then impervious to hostile attack.Maxim 11: Everything is air-droppable at least once.
The issue with the MSP stockpile concept is getting the MSP to the planet. For cargo, colonists and troops, you need time to unload. I haven't decided whether to extend this to maintenance yet. Even so, it doesn't seem realistic to instantly dump a large stockpile of maintenance during an invasion, which is then impervious to hostile attack. The logistics units represent the challenge of establishing the required logistical support and the requirement to defend that logistic support, plus they create a significant decision regarding the division of transport lift between combat and logistical formations.
The issue with the MSP stockpile concept is getting the MSP to the planet. For cargo, colonists and troops, you need time to unload. I haven't decided whether to extend this to maintenance yet. Even so, it doesn't seem realistic to instantly dump a large stockpile of maintenance during an invasion, which is then impervious to hostile attack. The logistics units represent the challenge of establishing the required logistical support and the requirement to defend that logistic support, plus they create a significant decision regarding the division of transport lift between combat and logistical formations.
Barkhorn, There is a difference between putting two 250kg iron bombs that are released by pulling a switch with no targeting, and a guided missile that the onboard computer aims for the pilot and that has a CEP of 3 meters. I think my favourite option would be that the ground attack module starts as fairly big one and then gets smaller with tech - improved miniaturization and more destructive warheads and so on. This would encourage specialized fighters in early game while allowing efficient multi-role fighters later on. That already kinda happens with ships - at TL0-3 it is very difficult to design effective multipurpose ships but from TL4 onwards it becomes quite possible.There really isn't much difference from the pilot's perspective. The targeting software is on the weapon itself, not the aircraft. A laser-guided bomb requires no extra equipment on the aircraft; the laser can be pointed by an observer on the ground or another plane. Further, even in cases where the software IS on the plane, what difference does it make? All modern aircraft have fully-programmable multi-function displays. If I new weapon gets invented that needs to use the plane's computer, you just need to install the software. You don't have to buy a whole new plane.
I prefer the dedicated modules for a couple of reasons. Partially because I am aiming for a more WW2 / WH40k feel to ground combat, but mainly for consistency. If the fighters can have multi-purpose modules, why can't the ground units? Think of this of more like F-15 vs A-10 vs SU-25, etc..The F15 can carry bombs and ATGM's, and the A-10 can carry air-to-air missiles. Sure, the A-10 is better at ground attack and the F15 is better at air-to-air, but it's not like there's no overlap at all.
The Mosquito might be an even better example. It had nose-mounted 20mm cannons for air-to-air work, and could carry bombs, rockets, or even a torpedo.
My opposition to fighters needing dedicated space or ground weapons is a gameplay one; no one is ever going to equip both,I would question that assumption. It depends on the size and cost of the ground attack module, of course, and how the space combat capabilities of the fighter are used (or not) in ground combat. But if it basically is an additional fire control and the damage and enemy to-hit chance are determined by the weapon system and speed, then adding a space-based fire control to all the ground attack fighters becomes a relatively cheap way to boost the fleet screen around a planet, and adding a ground attack fire control to space control fighters becomes a cheap way to boost the ground force component a base strike task force.
My thinking is that there should be 2 kinds of "fighters"
one for space-fights and one for atmosphere fighting...
there would be too many and too mayor differences in design (like wings in space are just a no-go but needed in atmosphaere flying!!!), material, weapon etc for a multi-roll craft (or you say: there is a nano-tech which morphes the hull of the craft for air and space-combat at will instantly but..)
I'm going to argue that Automobiles have seen a similar development in terms of technical complexity that military airplanes have the last 80 years.Unfortunately that is not the case and thus your analogue fails. A modern jet plane is vastly more complex when compared to a WW2 plane than a modern car is compared to a 1930s car and it's not just one thing, it's literally everything, starting from materials used to build the frame and ending with the electronics. Furthermore, at the peak of WW2, USA spent 41% of its GDP for military production and that had everything included. So the premise of dedicating 10% of current GDP to only building airplanes is a pretty wild exaggeration despite sounding reasonable - even during the Vietnam era, US defence spending did not go over 10% of GDP.
Unfortunately that is not the case and thus your analogue fails. A modern jet plane is vastly more complex when compared to a WW2 plane than a modern car is compared to a 1930s car and it's not just one thing, it's literally everything, starting from materials used to build the frame and ending with the electronics. Furthermore, at the peak of WW2, USA spent 41% of its GDP for military production and that had everything included. So the premise of dedicating 10% of current GDP to only building airplanes is a pretty wild exaggeration despite sounding reasonable - even during the Vietnam era, US defence spending did not go over 10% of GDP.Even if the analogy worked, contemporary automobile design is a case study in the drawbacks of multipurpose design. Most of what people use automobiles for really does not need capacity for four passengers, a cubic meter and a half of payload, and the ability to go to 150 km per hour. The reason cars are as over-specced as they are driven by the private ownership model and an auto-uber-alles transportation policy. If cars were developed for the actual transportation use cases people put them to, the average car would be much smaller and less powerful.
Even if the analogy worked, contemporary automobile design is a case study in the drawbacks of multipurpose design. Most of what people use automobiles for really does not need capacity for four passengers, a cubic meter and a half of payload, and the ability to go to 150 km per hour. The reason cars are as over-specced as they are driven by the private ownership model and an auto-uber-alles transportation policy. If cars were developed for the actual transportation use cases people put them to, the average car would be much smaller and less powerful.
Unfortunately that is not the case and thus your analogue fails. A modern jet plane is vastly more complex when compared to a WW2 plane than a modern car is compared to a 1930s car and it's not just one thing, it's literally everything, starting from materials used to build the frame and ending with the electronics.
Furthermore, at the peak of WW2, USA spent 41% of its GDP for military production and that had everything included. So the premise of dedicating 10% of current GDP to only building airplanes is a pretty wild exaggeration despite sounding reasonable
Even if the analogy worked, contemporary automobile design is a case study in the drawbacks of multipurpose design.
Guys, Aurora isn't real life, we can't even hope to try and figure out what the "realistic" behaviour and design of components made out of fictional materials in a fictional universe with fictional properties would be. The prime consideration here should be gameplay, whether we want a multirole pod or specfic pods or both and how they should be balanced to each other should be based on what is best for gameplay and what gives us the most viable choices without creating needless BS. Not based on whether the F-35 is an overbloated project that should have been cancelled long ago but wasn't because the US government is under the thumb of Lockheed Martin and the arms industry.
Guys, Aurora isn't real life, we can't even hope to try and figure out what the "realistic" behaviour and design of components made out of fictional materials in a fictional universe with fictional properties would be. The prime consideration here should be gameplay, whether we want a multirole pod or specfic pods or both and how they should be balanced to each other should be based on what is best for gameplay and what gives us the most viable choices without creating needless BS. Not based on whether the F-35 is an overbloated project that should have been cancelled long ago but wasn't because the US government is under the thumb of Lockheed Martin and the arms industry.
You should take a look at all the successful science fiction universes. Everything that can be ( without breaking the fiction ) is based on or inspired by real places / cultures / knowledge / behavior to make us immersed in the world and make the world feel plausible and "real".
The same thing is true for all successful games.
You should take a look at all the successful science fiction universes. Everything that can be ( without breaking the fiction ) is based on or inspired by real places / cultures / knowledge / behavior to make us immersed in the world and make the world feel plausible and "real".And both multirole and dedicated role aircraft have precedent in reality. So what was your point? I'm not saying lets just go pure fantasy, my point is that much as new technologies such as guided missiles and jet engines have completely changed the way we conduct air combat today vs world war II, it's entirely justifiable when you have all these new technologies and hypothetical imaginary substances, that the things you can do with them will be different than what we can do today and multirole may no longer be competitive. Or maybe it'll be the prime way of doing things. Either system is entirely justifiable, so making arguments based on current "reality" (especially a single project that is the way it is for political reasons, not practical ones) is nonsense. What matters here is what is best for gameplay. It's not that we should ignore reality entirely, it's that we're dealing with such a hypothetical scenario that many approaches are justifiable and conceivable.
The same thing is true for all successful games.
if only to end this ridiculously nitpicky discussion. (But only a part.)
I agree. Let's all be silent instead of trying to find some interesting and engaging topics tangential to Auroras development updates to talk about. Effective now!
Will C# get some performance upgrades?
I'm a bit worried about feature creep, both for the sake of my sanity and my processor.
Will C# get some performance upgrades?
I'm a bit worried about feature creep, both for the sake of my sanity and my processor.
Will C# get some performance upgrades?
I'm a bit worried about feature creep, both for the sake of my sanity and my processor.
Will C# get some performance upgrades?
I agree about the feature creep, but on the sake of the release date. Theres a whole new game inside the 7. 2/C# change list already! It's a fine line of having the new scope to energize/inspire Steve and the limited free time it takes from getting done. ;D
With the exception of the ground combat overhaul, everything he's doing is fairly easy in context of the fact that he's literally rewriting it from more or less scratch anyways. If anything, this is probably one of the *best* times he could hope for to add or change things. Its not a matter of "not changing it, save five weeks", he's gonna spend 4 weeks writing X now, and then 3 weeks rewriting it two or three releases down the line, or 5 weeks writing X with the improvements he wants now.
If this was a thing that hadn't been running for years, if this was a thing that was paid for in any sense, I'd agree with you guys completely. But as it stands, I trust Steve will eventually release it, long cycles are somewhat the norm here for major releases anyhow. And he doesn't really have an obligation to get something out now, and make it better later, as a commercial or even crowdfunded project might. He can take as long as he wants.
I also wouldn't worry about mental exhaustion much. This is a hobby that clearly doesn't take up all his personal time, and he regularly works in spurts. We'll get a bunch of stuff over a week or two, then not much for a bit, then another little spurt. Sometimes he just takes a break for a month. He's been tinkering away at this for ten years, I don't think he's really at risk of overworking himself now all of a sudden just cuz of a release hype train kek. If anything, I'd say the recent surge of output circa ground units is just cuz "hey this is really fun to work on, and different from my normal stuff"
I would like there to be a mothballing mechanic, so that I can reserve old ships instead of just gradually phasing everything out via refits/scrapping like I do now when there's a new generation of ships. I guess the ships would become totally immobile at the maintenance location they were decommissioned at, and would unload all of their fuel, ordnance, and MSP. In exchange they'd cost either nothing or very little to maintain, maybe even only counting as 1/10th of their size towards the maintenance cap at that location.
As far as what you'd do about the crew grades of those old ships while they're in mothballs? The crews could be turned into cadres similar to low tech army units in VB6, and give their grade bonus to newer ships that get built. The old ship would lose all of its grade bonuses.
I guess the percentage of that crew grade that they'd give to the new ship would be similar to how it's passed on during refits.
It'd also make AI opponents that have been around for a long time, become something to take more care against when approaching at war. I think their reserve yards would be a pretty high priority target unless you want them to reactivate hundreds of kilotons of military hardware and surprise you with it when you finally hit them at their core worlds.
First, crew from deactivated ships is already handled; their average skill points are checked, compared to the racial skill point rating for the Academies and if higher, tossed into the crew pool, and if lower the fraction difference is tossed into the crew pool. IIRC anyway.But I don't want the crews added to the pool, I want them added directly to new ships that are built to increase their starting grades. Or to old ships, to strengthen your peace fleet during the mass mothballs that might follow a war's end. I want the grade bonus of the old ship's crew to be preserved rather than converted into more or less manpower.
The biggest issues with mothballing is how long it takes to take the ships out of the mothballs, what facilities you'd use, what parts need to be replaced and how much it costs while in mothballs.
But I don't want the crews added to the pool, I want them added directly to new ships that are built to increase their starting grades. Or to old ships, to strengthen your peace fleet during the mass mothballs that might follow a war's end. I want the grade bonus of the old ship's crew to be preserved rather than converted into more or less manpower.I'm not sure how realistic that is though. You're breaking up your veteran crew and spreading them throughout the fleet onto ships they have never been on before. Aren't you going to lose a lot of their efficiency anyway? I mean yes, they will be better than a fresh recruit but nothing like as efficient as before.
You always could just dump them into the pool, though. Don't see why that shouldn't still be an option anyway.
IIRC Mothballing did exist in the early days (it certainly was there in the SA antecedent).
Steve removed it because of the problem of a perceived exploit by building directly into mothballs, resulting in the capability of surging huge (albeit inexperienced) fleets in short order without paying the maintenance in the intervening years. This could result in very large unprotected empires, which could in a matter of months mobilise truly stupendous fleets for offence, overwhelm small empires and then mothball the lot again.
I think that this was more of a problem with the Starfire environment because of the relative ease of refitting to more modern tech, whereas Aurora refitting is a lot more restrictive, and more resource intensive.
I have one request I really would like to be added to C# Aurora that would be a very nice quality of life for RP purposes.
Make it possible to set up proper patrols with ships. With this I mean an ability to have ships sit and wait at a specific location for a number of days/seconds.
It is especially important if I want ships to stay in port for a few days to rest the crew so they can continue patrolling after visiting friends and families, this way I can set up perpetuating patrols and only remove them for maintenance. Even better if you could save patrol routs. It will also make it easier if you want to set up commercial routes and have them rest their crew as well for RP reasons. But mainly this is for setting up patrols with regular patrol ships that you don't want or need long deployment times for. It does feel a bit immersion breaking that you put like 1-2 years deployment time on a local patrol ship just because it is tedious to rest the crew after a few months.
Doesn't this already exist with the delay, repeat, and cycle orders? It's not indefinite, but you could just set the repeat counter to 999 or something.
Now is the time to change something. He's gotta rewrite the whole game anyway, why not rewrite it better?
The risk is that the complexity of porting the existing rule set to C# combined with the complexity of changing the rule set leads to a more complex overall task. Trying to combine the two goes against most modern philosophies of good software engineering practices. I personally think this has been demonstrated with the ground combat stuff: Steve was chugging along through the various functionality sectors until he got to ground combat, at which point my perception is that the progress got bogged down. Some data: the original "I am seriously considering removing PDCs" post was on Sept 17, 2017 (on page 70 out of 93 in this thread), so he's been on ground combat for four calendar months and 25% of the posts in this thread, which is probably more time than it would have taken if he'd simply transcribed PDCs and ground combat.
A more telling example of the "change while transcribing" failure mode: the Pulsar 4x project seems to have fallen prey to this it. My recollection/perception is that they started out wanting to do a straight port of Aurora to C#, but figured "why not improve the game mechanics along the way". They seemed to have bogged down about halfway through; I haven't seem much activity from them at all for the last year or two.
That being said:
1) Steve is good at this stuff (writing Aurora); he's been doing it for many years.
2) Ground combat IS an isolated system, so he can code it up and get out of it. In general, Steve seems to be doing a really good job of doing minor and isolated tweaks to systems as he codes them up (e.g. the refueling changes), so that he's doing "transcription with cleanup" as he goes, rather than "write a whole new game". In other words, I think he's mostly been striking the right balance.
3) Steve's already written one game (VB6 Aurora) and gotten it to completion, which demonstrates the tenacity and ability to complete the job, so there's a good chance he'll complete C# Aurora too.
4) (Most important) It's Steve's free time, so if he wants to spend it working out ground combat mechanics before getting a playable version of Aurora out then that's his prerogative.
So I suspect the ground combat stuff has probably slipped the schedule by a month or two, but if that's what Steve wants to do that's his choice. Hopefully this is the only sector for which he's planning a major rewrite, and he can get back to straight transcription to get a working version out. If not though, c'est la vie.
John
Hey Steve, bit of a throwback question to an old change, with the new population caps, how is this handled for multiple empires on a planet? Would earths 12 billion pop cap be split between twelve starting empires equally, or would everyone grow up to twelve for 144 billion on earth?
A new concept, Population Capacity, has been added to C# Aurora. This represents the maximum population that can be maintained on a single body and is primarily determined by surface area. This is the total of all populations on the same body, not per population.
I think the Ground Combat changes will probably delay completion by 3-4 months,
I am moving house in the next couple of weeks, so that will slow things down a little, but should be up and running again fairly quickly.
How will this work though? Can we seize territory in ground combat, ideally also set fixed claims when we want peaceful coexistence?
Aurora is a 4X game, one explores, expands, exploits and exterminates.From 2004 ive "exterminate" only 2 Sentients Race. Abducted 4 and "swallow in mine" another one. Not so easy..:)
Clearly, the proper response to having another nation swallow all your population capacity on a planet is to exterminate that other nation.
From 2004 ive "exterminate" only 2 Sentients Race. Abducted 4 and "swallow in mine" another one. Not so easy..:)
Ouch. As someone who's only been playing the game around that long, that seems like a long time. But on the 10-year timescale that you've worked on the VB8 version it's not too big a deal.
Congratulations! Do you have a Coding Cave in your new house?
twelve different houses now and will continue for number thirteen. Moving is a well-oiled routine :)
So I was thinking, with the rewrite bringing up the opportunity to add new options, and the new depth in ground combat, is there any chance of getting a toggle for research capture? I regularly avoid letting my underdog games weaker factions actually invade worlds, only to avoid the underdog suddenly just learning half the advanced tech in the game. I can see where people would want that, but in a fully RP, player controlled game, I don't really want my setup being yanked out cuz a faction stole a bunch of levels of tech I was thematically avoiding.
Shield GeneratorsDoesn't that mean that multiple smaller shields would be better than an equivalent HS of larger shields? Or is that strength before multiplying by the shield size?
Shield generators have been overhauled for C# Aurora to make them more interesting.
1) Shields no longer require fuel.
2) Shield generators can be created from 1 HS to 50 HS in size.
3) A new tech line has been added for maximum shield generator size. The starting tech is 10 HS and there are seven further steps from 12 to 50 with RP costs between 2000 RP and 120,000 RP.
3) The strength of the generator is modified by its size using the formula SQRT(HS/10). This means a 10 HS generator will have standard strength, a 1 HS generator will have 32% of normal strength and 50 HS generator will have 224% of normal strength
4) Recharge rates remain as before so a 10 HS shield will recharge at the same rate as an equivalent tech VB6 shield generator. Larger generators will recharge more slowly. For example, a 40 HS generator has 200% strength so will take twice as long to fully recharge.
5) HTK is the square root of the size, so it is easier to take out a single 50 HS generator than five 10 HS generators.
6) Cost of shields has been doubled
7) The only mineral involved in building shields is Corbomite.
In general, this means that shields become stronger than before and larger ships have an advantage when using shield generators. However, they also cost more, require more investment in research and are easier to destroy.
Commander CareersThe retirement chances not only will be rather counter-intuitive in how it works (a 20% in a year does not actually mean 20% in that year, but around 18%, while 100% means around 64%), but with that formua also means that the increment length that the player makes time go by actually does somewhat alter the chance of it happening in an equivalent period of time.
In C# Aurora, the rules for accidental death and commander health remain as they are in VB6 Aurora.
Retirements are handled differently. An naval officer will be checked for the potential for retirement from service once the length of his career exceeds the minimum retirement time for his rank. The minimum retirement point is 10 years for the lowest rank. For other ranks it is equal to 10, plus 5 years for every level of rank above the minimum. So assuming lieutenant commander was the lowest rank, minimum retirement would be 10 years after career start for a lieutenant commander, 15 years for a commander, 20 years for a captain, etc..
For ground forces commanders the minimum retirement is 20 years for the minimum rank. For other ranks it is equal to 20, plus 5 years for every level of rank above the minimum.
For scientists and administrators the minimum retirement is 40 years.
The chance of the retirement occurring is 20% for each year beyond the minimum retirement date. This is doubled if the commander has no assignment. Each increment the chance is checked using: (Increment Length / One Year) * Retirement Chance.
The VB6 concept of 'tour length' does not exist in C# Aurora, so there will no longer be mass-reassignments every couple of years. In addition, the removal of officers after six years with no command will no longer happen. Instead, C# should have a more realistic progression because of the different mechanics. Firstly, inactive or low ranked commanders will tend to retire relatively early, which will keep overall officer numbers down and open up their commands (if one exists) for new assignments. Secondly, ships can potentially have multiple officers, which creates many more assignments. Thirdly, each ship (or other officer position) can only be assigned to an officer of a specific rank. As soon as that officer is promoted, he has to leave that position, which opens it up for another officer. Finally, naval officers in non-command positions (XO, Tactical Officer, CAG, Chief Engineer, Science Officer), will be automatically assigned to any ship command position that becomes available, assuming they have suitable bonuses, opening up their previous role.
Ship commander ranks are based on the following rules:
1) Assume lowest rank if none of the following conditions exist. Otherwise use the highest applicable rank for any condition.
2) Lowest rank + 1 for any ship class equipped with any of the following: Geological or Gravitational Sensors, Auxiliary Control, Science Department, Jump Drive
3) Lowest rank + 2 for any ship equipped with any of the following: Weapons, Military Hangar Bay, Main Engineering, CIC, Flag Bridge
4) Regardless of the above, any ship of 1000 tons or less will be the lowest rank, unless it has one of the control stations (Auxiliary Control, Science Department, Main Engineering, CIC)
Additional officers on the same ship have the following rank requirements:
1) One rank lower than required ship commander rank: Executive Officer, Science Officer, Commander Air Group
2) Two ranks lower than required ship commander rank: Chief Engineer, Tactical Officer
For example, the executive officer on a warship would be lowest rank + 1 (one lower than commander requirement) while the executive officer on an unarmed geological survey ship would be the lowest rank.
Overall, the variety of positions available at different ranks, combined with the positions opening up due to retirements, promotions and assignment of junior officers to ship command, should provide a more interesting career progression.
Don't know if anyone mentioned it already, and I'm not going through the 94 pages of thread to check it out, but a couple comments from the changes:
Doesn't that mean that multiple smaller shields would be better than an equivalent HS of larger shields? Or is that strength before multiplying by the shield size?
The retirement chances not only will be rather counter-intuitive in how it works (a 20% in a year does not actually mean 20% in that year, but around 18%, while 100% means around 64%), but with that formua also means that the increment length that the player makes time go by actually does somewhat alter the chance of it happening in an equivalent period of time.
I can see and understand your frustration, but it is always possible to change this in SM mode. However, I believe Steve is working on something similar or at least I believe I've read something about it but it's now buried in a conversation. The discussion was to set up the game from beginning with the possibility of stealing or not techs and also which one of the secret techs would be available in a game to acquire, at the start or not at all.
I believe if the above will confirmed and implemented then pretty much sorts your issue. ;D
Edit: I just found the post http://aurora2.pentarch.org/index.php?topic=9761.0
Dangerous Gas: If a dangerous gas is present in the atmosphere and the concentration is above the danger level, the colony cost factor for dangerous gases will either be 2.00 or 3.00, depending on the gas. Different gases require different concentrations before becoming 'dangerous'. Halogens such as Chlorine, Bromine or Flourine are the most dangerous at 1 ppm, followed by Nitrogen Dioxide and Sulphur Dioxide at 5 ppm. Hydrogen Sulphide is 20 ppm, Carbon Monoxide and Ammonia are 50 ppm, Hydrogen, Methane (if an oxygen breather) and Oxygen (if a Methane breather) are at 500 ppm and Carbon Dioxide is at 5000 ppm (0.5% of atmosphere). Note that Carbon Dioxide was not classed as a dangerous gas in VB6 Aurora. These gases are not lethal at those concentrations but are dangerous enough that infrastructure would be required to avoid sustained exposure.
I can disable tech being learned from invasions in SM mode? I wasn't aware of this. I also don't see anything about tech capture in that discussion either. I love the talk of being more finely able to control tech rates, and other rates in the game, but it doesn't really cover my concern there.
Has the thought been considered to have Conventional Industry also work as a weak terraformer locked into producing Carbon Dioxide?
Id love to have better early gameplay and fleshed out transition between conventional - TN tech level ( with things like struggling with climate change and early conventional rockets struggling to reach beyond moon-mars or only being able to make the trip when mars is close and have to be loaded with mostly fuel )
Current carbon dioxide content of Earth's atmosphere is, after more than a century of burning fossil fuels, 0.0000407 atmosphere.
Pretty much negligible for the purposes of the game.
Not really. Since the game considers it harmful at 0.005 atmospheres (or 5000ppm), and that 407 ppm represents 0.000407 atmospheres, not 0.0000407.
It is true that right now we are in reality adding about 3 ppm / year meaning we would reach Aurora harmful levels after 1531 years, but I'm not sure how realistic the Aurora 4x model of CO2 as a greenhouse gas is, and the temperature increase is another thing to consider (melting of ice caps). If current addition rate was negligible I doubt it would be such a debate as seen currently.
Even given the current model it's not unimaginable to have an Aurora 4X fossil fuel based conventional industry 10-20 times larger then that which we have on Earth now, which would reach it in 150 or 75 years.
Something else to consider is that the rate of CO2 addition is speeding up, a 100 years ago we were adding about 10% per year compared to now, and it shows no sign of stopping, so if the exponential increase continues we are looking at a rate of 30 ppm / year not to far away into the future.
It seems like it wouldn't be such a hard thing to add, and would add a few interesting stories or scenarios you can play out.
Everyone talk about physics,weapons...but : TAXES? Politics? 1 tax level by EVERY single planets,no difference?No settings allowed?..its really annoying.At the risk of being called a casual, I think Stellaris actually has a really good take on this. I've never played the game, but I've watched a fair amount, so maybe it's not done well but the idea is sound.
Everyone talk about physics,weapons...but : TAXES? Politics? 1 tax level by EVERY single planets,no difference?No settings allowed?..its really annoying.
..omissis...
Ultimately though I think an entire in depth economic and political system would be a massive amount of work and AI coding plus tons of balancing and my view is that in the long run the benefit doesn't outweigh the cost. Even if it's revisited later on it should probably remain relatively simplified and along the lines of the current implementation, but just expanded.
We can easily RP any social unrest we like so that is not a huge deal for me.We can easily RP terraforming too, but that got it's own mechanics.
We can easily RP terraforming too, but that got it's own mechanics.
I think the more things that the program can handle, i.e. things you don't need SM or player input to do, the better.
And for a game about running an interstellar empire, there's actually not very much empire-running to do. Most of the game is just building things so you can build/destroy more things.
Some basics could probably be fairly easy to add and not require a massive amount of balancing? Stuff like:
- 3 different tax levels on population ( trade-off vs unrest )
- 3 different tax levels on civilian shipping lines ( trade-off built in already since if you take more they grow less, for example 25/50/75% income taxed )
- Unemployment vs unrest ( large percentage unemployed = a bit more unrest )
- Shipping lines colony ships prioritize destinations based on job opportunities/space available/population tax levels
I think this would give you a bit more indirect control over flows of people and growth of shipping lines, and feel like your running an empire.
Unrest should rather be tied into what taxes are spent on rather than the amount that is taxed while the amount of tax is affecting the purchasing power of the population (or in this case its economic growth). Part of the world who pay the highest taxes are the most content on them while those that pay much less are more up in the blue because they feel the money they do pay is wasted on stupid stuff or simply eroded by bureaucracy and/or corruption.
When I play Aurora I usually take these things into account and every bit of military spending (resources not going back into providing job for citizens) must be carefully planed for or people will try to replace the ruling government. Depending on the type of government some will have more of a leeway than others doing that. But this is only RP and have nothing to do with the actual mechanics as they are now.
Yeah, and that might be fine for something to be added 2-3 years down the line together with a complete overhaul and complex supply-demand, civilian market and politics.
My suggestion was for a very very basic model that could be completed either now or quickly after first release of C# Aurora, and still be a decent improvement compared to the current nothing situation.
For most games with tax rates, there's usually a no-brainer best tax rate for any given situation: as much as you can get away with without causing revolts or some other not-worth-it penalty. So there's never any decision making.
There's other things you can do with your tonnage and research points. You're always giving up something...This in stark contrast with taxes. There's nothing else you can do with spare 'tax rate'. It is almost universally in games a single-dimensional mechanic that a governor ai can run better than a player unless its lobotomized.
Let's say that you put tax rates in. More tax equals unrest. Okay, so you get ground units to reduce unrest. So.... recruiting ground units now *increases* your income instead of lowering it? What? That's...bad. And 'martial law' is optimal play no matter how you're trying to RP? It's nonsensical. And we're not even talking about how ground units have nothing better to do 95% of the time. Also, to play optimally, now you need to adjust tax rates every time any factor that affects unrest changes, to get the most money. O Joy.
And now for something completely different: The missile will always get through. That's a bit of an elephant in he living room, especially when trying to have solid evolving doctrines in a multiple-faction game. Less so in a game against the AI, because of the non-competitive nature of the game.
What I find strange is point-blank missile fire ignoring non-CIWS defence gets removed: That quirk adds depth and flavour, and is probably good for variety & balance. More powerful and less risky methods aren't touched even when other changes will increase the problems:
1) Multiple missile variants moving at the same speed are in multiple salvos when fired from one fire control. Emulating frequent Soviet practice of firing 2 almost identical missiles with different sensors gets this effect, even if we don't set out to exploit this by researching the same missile 20 times. There are of course other legit ways to have multiple variant of the same performance - e.g. different agility/warhead/fuel splits.
2a) One missile per fire control is the natural state for fighters in the style of a torpedo bomber. This is not a problem currently, but may be in the future with the changes to sensors (sensor fighters will detect larger sensor ships earlier than vice versa, making small fighters very difficult to intercept).
2b) Short-ranged missile fire controls that just aim to outrange beams are tiny and dirt cheap, again allowing an easy split into many salvos and limiting defensive beams strictly by fire control. Without the constraints (short range, high speed to outrange larger beams) of point-blank fire. Again, the change in the sensor model makes this much more effective.
3) A launching platform exactly as fast as the missile is very difficult to defend against (tested this with a 1000t FAC firing a clump of 91 size-1 missiles in 91 salvos. Scaling this up and using two-stage missiles gets rid of the extreme speed requirement for the launching platform). If this is deemed problematic, we could get a tech line for how many salvos underway a MFC can handle. OTOH, slow missiles may be easy prey to a very fast beam interceptor in area defence mode.
So I was thinking, with the rewrite bringing up the opportunity to add new options, and the new depth in ground combat, is there any chance of getting a toggle for research capture? I regularly avoid letting my underdog games weaker factions actually invade worlds, only to avoid the underdog suddenly just learning half the advanced tech in the game. I can see where people would want that, but in a fully RP, player controlled game, I don't really want my setup being yanked out cuz a faction stole a bunch of levels of tech I was thematically avoiding.
Economics is complicated :)
It is isn't as simple as more tax = more money, because high tax can limit growth, increase tax avoidance or remove incentives for investment. I am fortunate to live in a low tax economy (some might say tax haven), with maximum 20% personal tax, no capital gains tax, no inheritance tax, 0% corporation tax (except banks - 10%), yet there is no state debt and we have the same public services as most European countries. Good quality free Health Care, Education, etc.
...
Aurora 'economics' is about balancing various industrial capacities, availability of workforce, mineral supplies, fuel, maintenance and wealth. Each of those can be affected by the player in some way to maintain the balance. Wealth for example is helped by building financial centres, investing in civilian shipping, creating lots of small colonies to boost trade, pop growth (which is wealth growth) and civilian mining (which requires pop of 10m in system). Tax rates are assumed to be generating optimum revenue as per the Laffer Curve).
There's other things you can do with your tonnage and research points. You're always giving up something...This in stark contrast with taxes. There's nothing else you can do with spare 'tax rate'. It is almost universally in games a single-dimensional mechanic that a governor ai can run better than a player unless its lobotomized.I think you're right, in that what is missing is the secondary feedback loop of increased oppression leading to a loss of production. Creating a simple version of a mechanic for that without introducing new parameters is challenging. But one idea is that every time your troops reduce unrest there is a small chance of generating a hostile "rebel" battalion. So if you rely on martial law in the outer colonies then you'd actually be fighting an almost perpetual guerrilla war, with the risk of collateral damage and troop casualties loss that implies.
Let's say that you put tax rates in. More tax equals unrest. Okay, so you get ground units to reduce unrest. So.... recruiting ground units now *increases* your income instead of lowering it? What? That's...bad. And 'martial law' is optimal play no matter how you're trying to RP? It's nonsensical. And we're not even talking about how ground units have nothing better to do 95% of the time. Also, to play optimally, now you need to adjust tax rates every time any factor that affects unrest changes, to get the most money. O Joy.
I agree about the basic problem but it sounds like there are ways to give you some control over tax without destroying balance. If Civilian economy is given a bigger role then higher tax levels slowing down long term growth does make sense.Except economies don't work like that.
Basically the Economy works like a big basket of wealth ( much like Shipping lines currently do ), the more you drain out of it, the less can get re-invested and the less future growth and tax is possible.
A Short term profits vs long term growth trade-off.
I agree about the basic problem but it sounds like there are ways to give you some control over tax without destroying balance. If Civilian economy is given a bigger role then higher tax levels slowing down long term growth does make sense.If the bourgeoise store all their money under their bed or otherwise keep it where it's not being reinvested, that is a big drain on the wealth (and to some degree is anyway as capitalistic investment is inefficient). Similarly, if taxes are used on economic projects, or otherwise in ways that benefit the economy even if not directly, then they are in no way a drain. As said, it's not a zero sum game where more taxes for government means less money for the economy and the reverse is often directly observable, the economy often stagnates when there is insufficient regulation and public investment. However, there are other cases where, as steve points out, the economy could be hurt by increases in taxes, though this is only really true if the companies have somewhere to flee to (and is only really true within a capitalist framework). Aso dependent upon how the taxes are used.
Basically the Economy works like a big basket of wealth ( much like Shipping lines currently do ), the more you drain out of it, the less can get re-invested and the less future growth and tax is possible.
A Short term profits vs long term growth trade-off.
Just as a note -The problem is this is just theory and isn't borne out by reality. Again, there are circumstances where this can be true, but again, taxes aren't just draining money from the economy. Nor is lower taxes keeping the money in the economy, in fact the opposite is generally more true depending on how the money is used (and this can be observed in reality). Lower taxes don't even inherently make people happier.
In most capitalistic or mixed economies (AKA current economies of most of the world) are lowered, it allows more money to be kept for consumption or reinvestment. When taxes are raised, it lowers the amount of money that is available to spend or reinvest. It is just one factor among many that impact the economy overall (are regulations too light or too strict, how healthy is the credit markets, what are the cost of energy and other basic inputs, income inequality, and so on). You can lower rates and actually get more income, both by the increase in the economic base, and also less tax avoidance by citizens.
Since this is a game, it might be just more simple to have some sort of happiness feature, in which lower taxes means happier citizens, but less revenue, even if in real life that is not completely true.
None of which is really in scope for a space naval warfare game.
Just as a note -
In most capitalistic or mixed economies (AKA current economies of most of the world) are lowered, it allows more money to be kept for consumption or reinvestment. When taxes are raised, it lowers the amount of money that is available to spend or reinvest. It is just one factor among many that impact the economy overall (are regulations too light or too strict, how healthy is the credit markets, what are the cost of energy and other basic inputs, income inequality, and so on). You can lower rates and actually get more income, both by the increase in the economic base, and also less tax avoidance by citizens.
Since this is a game, it might be just more simple to have some sort of happiness feature, in which lower taxes means happier citizens, but less revenue, even if in real life that is not completely true.
This should go for commercial stations and every structure in space too, everything should need at least some measure of support and cost to operate.
To stop this from messing with the acceleration of colonisation, you could have every however many arbitrary units of industrial infrastructure count as a facility that can be moved by freighters.wouldn't you be able to avoid retooling costs by shuffling items around? Not much of a cost when you're talking Earth-Luna.
Economics is complicated :)
It is isn't as simple as more tax = more money, because high tax can limit growth, increase tax avoidance or remove incentives for investment. I am fortunate to live in a low tax economy (some might say tax haven), with maximum 20% personal tax, no capital gains tax, no inheritance tax, 0% corporation tax (except banks - 10%), yet there is no state debt and we have the same public services as most European countries. Good quality free Health Care, Education, etc.
There are some differences, such as you anyone moving here require a work permit and has to work for five years before qualifying for welfare, yet crime is almost non-existent (local paper front-page headline when 20 pints of milk was stolen) and I have never seen any homelessness. Unemployment rate is 0.8% (not a typo). Raising tax here might damage all the above, if people and businesses relocate.
Aurora 'economics' is about balancing various industrial capacities, availability of workforce, mineral supplies, fuel, maintenance and wealth. Each of those can be affected by the player in some way to maintain the balance. Wealth for example is helped by building financial centres, investing in civilian shipping, creating lots of small colonies to boost trade, pop growth (which is wealth growth) and civilian mining (which requires pop of 10m in system). Tax rates are assumed to be generating optimum revenue as per the Laffer Curve).
https://en.wikipedia.org/wiki/Laffer_curve
Not much of a cost when you're talking Earth-Luna.Earth-Luna is kinda special since the distance is so short. Luna grows insanely fast compared to anything else. If Luna is used as the yardstick to determine rules for economic/population/infrastructure growth, then every other colony will be stunted. Unless I misunderstood what you meant.
Earth-Luna is kinda special since the distance is so short. Luna grows insanely fast compared to anything else. If Luna is used as the yardstick to determine rules for economic/population/infrastructure growth, then every other colony will be stunted. Unless I misunderstood what you meant.
you be able to avoid retooling costs by shuffling items around? Not much of a cost when you're talking Earth-Luna.I actually didn't think about this. It's been so long since I've even played a Sol game. My current run definitely isn't one.
A question in regards to "Command & Control Rules":
In real life people usually stick to posts once they get to know the people they work with. So a ships captain would not switch every x amount of month between different ships like it happens with the auto assign actually in VB6 Aurora. Are there any plans that a person will not randomly do that in C# Aurora?
This presumes that they get to choose.It should be a setting. Both paradigms for officer assignment have their merit. If an officer stays with the same unit/ship his whole career, he'll have an amazing understanding of its capabilities. Much better than if someone new took command ever 2-4 years.
It should be a setting. Both paradigms for officer assignment have their merit. If an officer stays with the same unit/ship his whole career, he'll have an amazing understanding of its capabilities. Much better than if someone new took command ever 2-4 years.Isn't that how it works at the moment? I think you can choose the length of tour and set it as far out as you like?
Yes, but it's empire-wide if I remember correctly. I think instead it should be class-wide. Maybe even with an option to have individual ships be permanent positions while others of the same class are not.Ok, I understand. You can sort of do this for individual commanders by choosing the "do not end tour" option, but not for a whole class.
In real life people usually stick to posts once they get to know the people they work with. So a ships captain would not switch every x amount of month between different ships like it happens with the auto assign actually in VB6 Aurora. Are there any plans that a person will not randomly do that in C# Aurora?No they don't. At least in military context, captains of ships and commanders of units/posts/whatever do get rotated regularly. As the commercial designs are also under government/military control in Aurora, it makes perfect sense for their captains to rotate as well.
ECONOMY..found :
From 2300 A.D. (site secure)
http://www.oocities.org/area51/9292/2300/economics.htm
Please...@Steve check this rare PEARL...
When using transports to collect minerals Gallicite is unfortunately the last mineral to be collected if the stockpile exceeds the cargo capacity. Would be nice if there could be a changeable priority list which minerals should be loaded first. :)
I myself always not in need of one or 2 minerals so I adjust the queue using this simple trick.
I hope this helps if Steve will not fix or implement this issue.
As another minor QOL suggestion, I wonder if it would be better for the "total accessibility" box in the mining tab to be changed to display the actual total of the accessibility of the planets minerals, rather than the average. This would help show at a glance the number of total minerals that a planet could produce. I would argue that this is more useful than the average accessibility, which does not take into account the effects of having different kinds of minerals. A planet with a single mineral at 1.0 accessibility would have an average accessibility of 1.0, the highest possible, even though another planet with a lower average accessibility but more types of minerals might produce far more minerals in total, with the same number of mines.
In C# Aurora civilian shipping can be disabled. I was wondering if there could be "levels" of disabling. I personally found the cargo function pretty useful but was annoyed by the civilians building fuel freighters and civilian transports. Options to choose what civilian shipping is allowed to do (maybe as a political instrument) would be an interesting addition.
I don't want to provide too much control over civilians as the main point is that they are independent and not additional player shipping.
I don't want to provide too much control over civilians as the main point is that they are independent and not additional player shipping.
There already is some kind of control because as long as one does not issue colonist or cargo orders those ships are more or less wasted (at least the colonist transporters). I mainly wanted to "officialize" this ;-).
What might be interesting would be if the civilian shipping "monitors" what is usually transported and builds their ships accordingly. So if you don't use the civilians for colonist transports and then suddenly do, it will be slow because they don't have the capacity but will build it. And then when you stop that, they we slowly scrap them and rebuild normal transporters - fitting to the actual demands... .
Looking at new Commanders window (http://aurora2.pentarch.org/index.php?topic=8455.msg101804#msg101804).
I think it will be cool to order personal records by rowid, not datetime. Or date + rowid, both decreasing (if you want to have a possibility to insert records post factum).
It will prevent this small bug with partially reversed record order (when records have the same datetime).
I've already fixed the issue when there is a simultaneous unassign and reassign. The unassign is no longer displayed.What about two simultaneous assings (first one was made by mistake)? They can be displayed at wrong order also.
Minor milestone - a geosurvey ship just executed the first default order in C# Aurora.
Well into the default orders code now, which is one of the major areas remaining. As a side-benefit of completely rewriting the path-finding code, you will have the ability to pick a system from a list on the fleet orders window and have the game plot all the jumps for you (including using Lagrange points). I'll do the same for populations and way points.
It's of limited utility, until you start talking about large binary systems with gas giants in orbit of each star, but oh boy are Lagrange jump points useful in that case.
Minor milestone - a geosurvey ship just executed the first default order in C# Aurora.
Well into the default orders code now, which is one of the major areas remaining. As a side-benefit of completely rewriting the path-finding code, you will have the ability to pick a system from a list on the fleet orders window and have the game plot all the jumps for you (including using Lagrange points). I'll do the same for populations and way points.
Which opens the idea of a new technology which allows (at very high cost) to create artificial Lagrande points... :o
Hi Steve,
I've noticed a lot of new threads popping up in this board with minor suggestions. I've also noticed a lot of suggestions in this thread, which technically is to discuss the changes you've made.
In VB6 Aurora, you requested that people only post to a single "official" suggestions thread, since you like to have a single place to scan for old suggestions. Without such a thread, you have said you tend to forget old suggestions and/or have a lot of trouble locating them. This system seems to be breaking down for C# Aurora.
So would you like to:
1) Have people use the official thread (either the current one or a new one) in the Suggestions board for C# Aurora suggestions?
2) Start a new suggestions thread in this (C# Aurora) board?
3) Put suggestions in this thread?
4) Continue with what's been going on recently (a little of everything)?
5) Do something else?
Thanks,
John
PS - The exposition above wasn't actually for Steve; it was mostly for newcomers to the community :)
So, with the last changes, in order to start up civilian shipping lines one must have two inhabitated colonies. Which in turn means, the player has to build cargo and colony ships so that a second colony can be founded.
While I perfectly understand the reasoning, it does sound a bit painful for conventional start people like me ;D
Can I ask about the rationale behind this? Is it to simulate that nations would not allow civilians to move into space first?
So, with the last changes, in order to start up civilian shipping lines one must have two inhabitated colonies. Which in turn means, the player has to build cargo and colony ships so that a second colony can be founded.
While I perfectly understand the reasoning, it does sound a bit painful for conventional start people like me ;D
Can I ask about the rationale behind this? Is it to simulate that nations would not allow civilians to move into space first?
Hi John,
Thanks - you are correct that I am losing track of the suggestions :)
I think the best option is a specific C# Suggestions thread, so that this thread can concentrate on discussing the Changes List.
Regards,
Steve
I could kiss you. On the mouth. Repeatedly.I am Second in line to kiss steve! Especially with the new path finding code.
I look forward to watching someone's million ton fleet base explode when a few missiles slip past the defense platforms :p
Jokes aside, I think it's an awesome change. Was C# going to have the coding changed to allow for deep space production as well?
I mean, you realise the currently released version has auto-lagrange point stuff right?
Deep space maintenance / recreation, etc is possible. Not coded anything yet for factories, shipyards, etc. and probably won't for the first release. However, I have coded C# in such as a way that it will be possible to have populations away from system bodies in the future.
Good enough for me! Though I suspect if I build fleet bases I'll probably still do it in civilian shipyards so they can have a bit of armor, it's definitely a nice change for fuel harvesters and terraformers.
Will it be possible to refit a Space Station if it is at a population center that has construction capacity?
An example would be if you wanted to refit one after making improvements in CIWS technology.
Good question :)
At the moment no, although you could do it in a shipyard that was large enough.
Thinking further about the space station refits, it is probably fine if there is no refit. All space stations will be commercial and can't have engine or weapons, so there isn't much to refit apart from the example of CIWS.
I think this discussion is touching on something that always confused me in StarFire: how to handle space station growth/refits. IIRC, one could grow a space station by simply bolting an extra bit on to the design code, the theory being that space stations are modular and so you're just tacking another module on, but the exact mechanics of how to do so seemed a bit opaque.
It feels like Aurora space stations have a similar issue: how does one manage going from a small station to total station capacity that's 10x bigger, especially if it's done in e.g. 5 increments? Does one simply A) build 5 more individual stations, one for each increment? Or does one B) expand the existing station? "A" seems easiest to manage in terms of code complexity (since you're not doing any special-casing), while "B" seems easier (and more natural) to manage in terms of gameplay. "B" seems like it's fraught with the possibility of (from a coding/special case perspective) turning into "the next PDC".
I suspect the best thing to do is to roleplay a task group containing several space stations as really being a single station with multiple modules, which avoids the coding difficulties. The question then becomes if this would have any weird gameplay effects. One good side effect is that it would solve the refit problem - individual modules could be refit or de-constructed in facilities with a size capacity of a module (rather than the whole station). A potential exploit would be to have a swarm of very tiny modules.
John
PS - Don't remember the details of Aurora space stations; apologies if there are already special case circumstances in place in the way they're built that makes the above discussion moot.
Fleet Movement Auto Route
The Fleet Movement Orders section of the Naval Organization window has an option called Auto Route by System. When this option is selected, the normal movement destinations list will be replaced by a list of systems that the Fleet is capable of reaching.
Any chance of coloring the entries in this list? Maybe match the light green in the in-system target view for any systems that have bodies that have population on them, and the dark green for any systems that have any non-populated colonies.
Like this?
(http://www.pentarch.org/steve/Screenshots/AutoRoute05.PNG)
Do those colors match the Galactic map notations for the same? My preference would be to have consistent colors between the two.
Will the new Auto-route options be stored with the task group and used with standing/conditional orders? Now that we have fleets that will want to move to different systems on their own without player input, it might make sense for them to obey the same restrictions the player has set when issuing movement orders. If I have a geosurvey fleet set to move to the next system when done with the one they're currently in, I might want them to respect the danger rating of any systems they might want to pathfind through. And if I have a quick-response fleet that wants to investigate a point-of-interest waypoint I've just set, I might want them to not pathfind through alien territory to do so.
Under the hood, I'm curious if civilian and NPR traffic will make use of these flags in their pathfinding as well.
"Order Templates" is right below"Autoroute by system", so the options might appear only when that is selected.
For the Auto Route by System pathing, if the "Exclude Alien-Controlled" check box is ticked, and you have a diplomatic relationship with an Alien that allows military ships to pass through their territory, will it still avoid their systems?
To use your example, if the US and the Commonwealth had a Military Cooperation Level of Friendly or Allied, would the US Fleet path be routed through through Commonwealth systems or would it still avoid their systems?
Great new features! The progress looks really good.
Is there a cutoff limit to how often the checks for trade routes are done?
I mean, say that I am running on 5-seconds interval due to combat. Will the checks be done every 5 seconds, if there are civilian ships with no available routes? Because it would seem unnecessary to me. Even if the delay is small, it's still useless.
I don't know, having this code run at most once per hour seems a good tradeoff to me.
It runs (like Standing Orders) during increments that are longer than one hour.
@Steve regarding the Civilian Trade.
I don't know if you omitted caching in your description of the trade route selection process, but keeping two lists per trade good with all the colonies
exporting/importing that trade good could reduce the list of potential colonies you have to check a lot. Maybe even store for on each colony the next
trade colony for each export good.
Would it help to keep the path lists? It might allow longer trade routes for civilian freighters, which IIRC are limited to 4 jumps in VB6.
In C# Aurora, the cost is:
5 x Number of Installations x Systems Travelled x (Installation Type Cargo Points / 25000)
So, setting distance aside the key part of this formula is that the player pays for how many freighter runs their contract requires. If you send ten installations, each of which fits in one freighter, you pay for ten trips. If you send five installations, each of which has to be loaded in halves for transport, you pay for ten trips. Makes sense so far.
Almost every installation in the game is some multiple of 25k in size, but I'm curious how this will work out with infrastructure contracts, who are only 2500. As the formula stands, If I make a contract to move 1 unit of infrastructure I'll pay for, essentially, 10% of a trip. From the player's side of things, this makes sense. For the shipping line though, I guess what I'm driving at is this:
Will civilian freighters 'top off' their cargo holds with other trade goods when they're only transporting part of their capacity in a trip? It's a small enough thing that it's fine to not simulate, but I'm curious if that's accounted for.
Sounds like your approaching something that's playable soon. Awesome! ;D
Yes, will be starting on combat this week. Still got to do AI and there are a lot of minor areas as well, including ground combat - naval combat interaction. I have done about 90% of the movement orders, although still not made a decision on whether MSP should be instant load or treated like fuel and ordnance. Compromise may be special system needed for MSP transfer (spaceport, maintenance facilities, ship system) but transfer is instant.I think there's a great deal to be said for taking a consistent approach one way or the other. If fuel/ordnance/cargo all take take to load, why shouldn't MSP?
May also look at how easy is currently is to repair on-board systems. Could change to two damage states. Damaged and Destroyed, with only the former repairable without specialist facilities.On-board repair is a very interesting discussion indeed. I guess the biggest gameplay change would be that destroyed engines could leave a ship stranded, lots of decisions then about scuttling it, sending a tug (into hostile territory?), or maybe adding tractor beams onto fuel/ordnance tankers for just that situation.
I think you misunderstand what he means by "damaged" and "destroyed".Yes, I understood that. But if Steve is making that change then I think its worth looking into how parts change from damaged to destroyed, and whether that should be tied into the HTK system, which would seem more elegant to me.
"Damaged" parts no longer function but can be restored by the ship's maintenance crews. "Destroyed" parts no longer function but are broken so badly they have to be repaired at a specialized facility, like a shipyard or maintenance base.
Quick Question: Do you think if a fire control is set to a point defence mode it should only engage if the fire control is set to 'Open Fire'? Or should it automatically engage even if open fire is off?
Personally, I think it should always engage. The "open fire" setting is more of a control / rp thing, as in, I want to decide when my guns/missiles actually shoot.
But if I have an incoming missile, there is no possible situation in which I don't want a point defence weapon to fire. I mean, what's the point? Am I going to let it hit my ships?
Quick Question: Do you think if a fire control is set to a point defence mode it should only engage if the fire control is set to 'Open Fire'? Or should it automatically engage even if open fire is off?
Quick Question: Do you think if a fire control is set to a point defence mode it should only engage if the fire control is set to 'Open Fire'? Or should it automatically engage even if open fire is off?
What about AMM ships - do you want some control over which ones fire?
What about AMM ships - do you want some control over which ones fire?
Well AMM ships could indeed be different. Still... the only reason not to shoot in this instance is the desire to conserve AMM.
But would a normal military actually do that? "Let these missiles hit us, in the meanwhile we're conserving AMM". Is that realistic? I understand how a minmaxing PLAYER might do something like this. Because a player is detached and sees numbers on a screen, and because damage in Aurora is by nature too "fixed", and thus predictable. You can predict that these missiles will not take down your ships... But I believe a real military would not take the chance, and prefer to hit the incoming missiles.
If your ship has good shields and you're facing a small salvo then letting the shields absorb the damage is a viable option.
I don't mind as long as whatever option chose for auto-fire is really, really obvious. Trying to get defensive fire to work is already very challenging for new players (and I suspect many less new players as well). And I think its somewhat counter-intuitive that setting a fire-control to "area defensive fire" won't necessarily result in it firing.
Maybe the new interface could make some use of colour to help this? Maybe green for fire controls that have everything turned on so that they will autofire? Red for "offline" controls with no target/cease fire orders.
I could also use colour coding for weapons being correctly assigned to fire controls, something that is easy to miss with big ships.
@ components view:
while I like the new screenshot a lot, some QoL pointers I am missing:
1) it is really hard to read lines and rows without some "focus line" - would it be possible to get something like a background-color every 4-5 lines for easier reading?
2) for same or related components (Crew Quarters, Weapons etc) it would be easier to have them in a "block" instead of mixed up in the lines - guess it is "first added, first shown"? it would be much easier to have all a logical order of the components were you can see with "one look" which components are there
3) what I am missing (but its really just a minor point) is a "total TN-Mineral cost" .. I would add a line between Gallicite and Wealth with the total mineral costs
1) If you click on a line, the whole line is highlighted.
Relevant counter point; what's the detection values for noticing those missiles? On Active and Thermal sensors, since with an active strength of .26 I'm not expecting an EM sensor to detect even an active sensor missile before it's considerably too late, while missile engines have relatively notable signatures and active sensors detect everything of the right HS.
GPS | EM 1 | EM 5 | EM 10 | EM 20 | EM 50 | EM 100 | EM 200 | EM 500 | EM 1000 | EM 2000 | |
RES | 26.25 | 1,281,000 | 2,865,000 | 4,051,000 | 5,729,000 | 9,058,000 | 12,810,000 | 18,120,000 | 28,650,000 | 40,510,000 | 57,290,000 |
RES^(1/1.5) | 5.655 | 594,600 | 1,330,000 | 1,881,000 | 2,659,000 | 4,204,000 | 5,946,000 | 8,408,000 | 13,300,000 | 18,810,000 | 26,590,000 |
[Snipped quote for section break and topic change]
While this is indeed easier to see which ship damaged which target and includes most/all the relevant information on that attacking side, the defensive side is missing a lot of information that is very useful for designing future ships.
Damage report is not split by incoming damage type - Not especially relevant in this case, but very relevant if only some of the incoming fire causes shock damage
Attackers know the number of penetrating hits, defenders only know the amount of armor damage taken. - Of the 50 damage taken, 44 was stopped by armor. Was the 6 damage taken from 2 damage-3 hits? 6 damage-1 hits? (Attacker knows it was 2 damage-3 hits and 1 damage-1 hit, for 3-7 internal damage)
The other thing I notice is that crew deaths are not being reported for damage taken. Is this a change to when crew die? Or are they only being reported on ship destruction?
On an unrelated note, do missiles still use 5x as much fuel as ships? I've been looking at updating the missile calculator gdoc and I've noticed that without that 5x multiplier missile ranges would actually increase. I remember you saying things about wanting to remove the missile exceptions to fuel use, but I've also seen you saying you want to reduce missile range, so a clarification would be useful for providing an accurate opinion.
The defenders only know the amount of damage rather than the type. That was a conscious decision and it is the same in VB6. The damage per hit is already listed on the defender summary.
It seemed like the attacker saw a different number of hits reported than the defender. Is this true and was this conscious (fog of war)?
Thanks,
John
The defenders only know the amount of damage rather than the type. That was a conscious decision and it is the same in VB6. The damage per hit is already listed on the defender summary.
PS Monoceros Damage Report: Armor Damage 44 Penetrations 3 1x Lupercus-Ancus LA-6 Active Sensor 1x Tiverius-Velus 12cm Near Ultraviolet Laser Current armor 39% Maximum Speed 5,161 km/s
This is the rule post on missile engines:
http://aurora2.pentarch.org/index.php?topic=8495.msg102804#msg102804
Thankfully they both saw the total number of hits and even had it split by incoming damage amount (type?). The only bit missing was how many of those hits penetrated armor.
Ah - you're right - thanks! I was confused because the attacker report is broken into "armor hits" and "penetrating hits" while the defender is just told the total number. Which brings up the observation that it seems a bit odd that the attacker gets more information about which (or even if any) hits penetrated while the defender is only told the total, i.e. the attacker is getting finer-grain information.
Looking at last screenshot posted by Steve looks like he is moving into the combat system and considering the save issue was sorted last week with orders phase that should be pretty much almost done, probably he is using an 80% playable version already.
Looking good and awesome and maybe 2018 spring release is becoming a realistic date again!
Steve, given that ground units can have ship beam weapons would it not be reasonable to have ground populations check units equipped with that after checking units equipped with CIWS before moving to ships with defensive fire linked fire control systems?
When a missile reaches its target, a target ship will use its CIWS first. If that is insufficient, it will use any weapons linked to fire controls set to 'Final Defensive Fire' or 'Final Defensive Fire (Self Only)'. If that is still insufficient, ships or the same race or an allied race with fire controls set to 'Final Defensive Fire' will be checked in increasing order of distance from the target ship.Will ships prioritize missiles targeted at themselves? E.g. lets assume we have two ships, A and B, in a task group, and both have more missiles incoming than their pd can handle. Can I expect A's pd to shoot the missiles that target A and B's pd to shoot the missiles that target B? Or will A's pd to shoot the missiles that target A, then B's pd shoots the leftover missiles that target A, which means B gets hit by all the missiles targeted at it?
We should be able to set a priority queue for PD. I would imagine that in real life, in a US Carrier Group, the Arleigh Burkes would totally ignore their own defense if a sizeable number of missiles were headed for the carrier.
BTW not sure if I mentioned this anywhere but in C# Aurora, you can have multiple windows open of each type. So in this case I have two event windows open - one for France and one for the United States - and both will update together. You could have two Class Design windows open to compare designs, etc.
EDIT: Steve, please consider writing salvos with the number of missiles in them. It would seem to me to best fit behind the signature.
BTW not sure if I mentioned this anywhere but in C# Aurora, you can have multiple windows open of each type. So in this case I have two event windows open - one for France and one for the United States - and both will update together. You could have two Class Design windows open to compare designs, etc..
That is going to be very helpful. We need to push for 16k-Monitors :D Can someone write an email to Elon?
in the attacker missile combat log as well as showing the number of missiles in the salvo it would be good to also see number of hits before you get to armour damage and penetration. I know you can see this through number of appropriate strength explosions on the tactical map but you can't see which ships they relate to.
Spring is on Wednesday :)
Still a decent way to go. Getting into combat now but there are a lot of smaller areas not done. About a dozen movement orders still to do, finish off the ground-space interactions (I just wrote the code for ground units shooting down incoming missiles), quite a lot of minor windows missing, etc. but the major missing part is the AI. I also have a long 'to do' list for finishing off parts of the code with about 50 items on it.
Once most of that is done, I will run one or more test campaigns, which will probably take a few months.
Hi @Steve Walmsley, sorry I do live in New Zealand so I have a different season calendar! My spring starts end of September...
They would be low values to hit because of the tracking speed. It is a possibility though. I'll sort this out when I create the UI for directing ground unit beam fire.
You can't use turrets for ground unit beams?
On the subject of ground unit beams, could a ground unit with that kind of weapon shoot at targets on another colony, (assuming they're in range) or just stuff in space?
a ground cannon can't shift around the planet to do the same.
Is there some missing information in the event log combat report compared to old Aurora? It seems that at minimum the defender should know how many missiles were in a salvo, if they were being detected by sensors anyway. It's good to know how many misses there was compared to hits, also their speed, since you already detected how fast they were going.
I rely on the combat log when doing an AAR to ensure I know the details after the fact.
Couple of questions about the new ground combat. Is there still infantry armor, or did Steve take (never put in?) that out? And how will the new ground system work with planetary unrest or conquered populations? Will there be a Military Police type infantry component? Or is that kind of thing just not needed with the new way attack and defend works?
A new commander Occupation bonus will boost this for each formation as a whole.
This may have already been discussed and put in place, and if so ignore me, but will we be able to set formations to have a preferred commander type? For example, for setting all my policing formations to have a higher priority of getting a commander with a good Occupation Bonus.
I like the changes to translation mechanisms. However, one of them does not makr to much senae to me from a "realism" /immersion point of view. Rhe one I refer to is that you can not advance in traslation without a willing partner.
Ships could monitor transmitions from colonies and learn the lanfuaje rhat way wirhout being detected. They however should not be able to do so if only alien ships are present becouse rhey could comunicate via "tight" beam.
Learning a languaje from an unwilling alien popularions shold take much more time and be more difficult. A penalty system could be used for that.
Automated Weapon Assignment
C# has a more intelligent auto-assignment for weapons and fire controls. You can set up a ship with a single click and then adjust as necessary. The code assumes that
Any missile fire control with a resolution of 1 is an anti-missile fire control
Any missile fire control with a resolution greater than 1 is a 'normal' missile fire control
Any beam fire control with a tracking speed at least 2x racial speed is a point defence fire control (some leeway here for older ships)
Other beam fire controls are for offensive weapons
Weapons within the given category (missile PD, missile offensive, beam PD, beam offensive) are split equally between fire controls of the same category
More powerful beam weapons are assigned first
ECCM is assigned as available with the priority order of offensive launcher, PD launcher, offensive beam, PD beam
The assignment code will take account of damage to the ship and adjust accordingly. In most cases, the above will be sufficient (and will be used for NPR designs). For more bespoke and unusual player ships, some tweaking may be necessary.
Note that missiles are automatically assigned to launchers.
Communication Attempts
Perhaps this could tie into the ship module replacements for Espionage and Diplomacy teams that were discussed a while ago? Abstracted SIGINT is a common thread behind that thought and the idea of translating a language via eavesdropping.
Also, the new change to the armor display is neat... but I think it might be a good idea to include a hard cap on the scaling before scrolling is reintroduced, for those gargantuan edge cases that people like to make.
If you have occupied a colony you may find the equivalent of the Rosetta stone so that translation becomes a research project based on computers and books and other ephemera left lying around. Chance should probably depend on size of colony, e.g. if materials are acquired from educational establishments.
If you have access to a colony in Aurora you probably have access to the primary education centers. Just run off with all the teaching materials and look for the things that look like the language teaching books.Just being able to observe conversations gives you SOMETHING to work with (which is why if you can pick up EM transmissions, you should be able to start translation attempts), but I definitely agree that if you've got physical access to the colony it should be a bit easier.
I will add a 'Russian Trawler' module, that allows some form of espionage and some ability to learn the alien language (although slower than normal translation attempts).
This may not help diplomatically if the other race refuses communication attempts, but at least it would help understand any intelligence material that might be gathered.
it makes larger weapons much more efficient in terms of failure rate
Does anyone else think 1. 1 worlds per system is pretty low for ground surveys? As in not really worth having them. I'd make it so that dwarf planets and the largest asteroids can be ground surveyed too. Ceres and up I guess for size.
I agree that 1.1 average targets per system is low, but then again I remember many systems being practically empty. I'd suggest thinking in terms of Sol for ground survey target density.
As I understand things Sol has 7 potential targets * .25% chance for... 1.75 average team locations in Sol with a 13% chance of zero targets. That still feels kinda sparse.
On the other hand Ceres and larger would give 28 potential targets for 7 average ground surveys in Sol. Thats probably makes ground surveys too common.
I'd suggest either lowering the threshold to 2500 km diameter for Triton and larger or else lowering the Potential:None chance to ~65%. That would make 2-3 ground surveys in Sol typical. The multiple targets would encourage ground survey force creation since the force would likely be reused even on low-tech starts while still keeping surveys uncommon enough to show up as major events in an AAR.
I think for C# Aurora Steve is going for that sort of thing in general where larger systems are more efficient. And unless I'm misunderstanding you, smaller weapons already have a higher chance to fail, and higher recharge rates would push that up even without a multiplier. Though, I wouldn't mind a mechanic that reduces failure rate if you choose a lower recharge rate then your current maximum.
There is also the constraint of ensuring bodies with very good minerals are still rare. I could expand the lower end (Minimal, Low), and leave the upper end the same without too much concern.
There is also the constraint of ensuring bodies with very good minerals are still rare. I could expand the lower end (Minimal, Low), and leave the upper end the same without too much concern.
If a deposit of a mineral that didn't previously exist is generated by the ground survey, that deposit is added to the system body.
If a mineral deposit is generated by the ground survey and a deposit of that mineral already exists on the system body, the existing deposit is changed to match the amount or accessibility (or both) of the ground survey deposit if the latter is greater.
If all weapons have a 2% chance to fail on firing, then a weapon that fires every 5 seconds would fire 12 times a minute, working out to (on average) .24 maintenance failures a minute. A larger weapon with a 30 second rate of fire would fire twice, for on average .04 maintenance failures.
If instead, say, the failure rate was .2% per second rate of fire, then the rapid fire weapon would have a 1% chance each shot, and the larger laser would have a 6% chance each shot, and both would on average suffer .12 maintenance failures each minute.
I know realism isn't a strict argument, but consider it like saying a machine gun can probably fire a lot more total shots before needing servicing than a tank's cannon.
If I understand this correctly, if I survey a system body which has minerals only after it's deposit is nearly empty I would benefit more from ground survey as if I do the surveying at the beginning? In the first one the new deposits are always greater than the existing and the minerals will be "fulled up" again with the new amount. In the second one, it is possible/likely that the existing minerals outnumber the "new found" ones and there are nearly no chances at all.
Am I missing something?
3) Also - I am sure I missed the numbers somewhere, so sorry for asking - for clarification:
Let's say a "typical" survey unit has 10 "trucks" with 1 Survey point/day in total, how long would the survey last in comparison to the old "team" with 100 skill? I would like to think that a unit like this should need at least 3-4 months for a "typical planet" - maybe even more - but with what numbers are we working here atm?
4) will a unit with survey ability start working with unloading them on a planet or will there be a special order for the ground-unit to start it?
looks really good so far, thanks a lot :)
The rationale behind the weapon failure rule is to avoid a point defence ship sitting in orbit and gradually laying waste to a huge planetary population, with no cost. That same weapon defending against missile attack would need a repair about once for every 50 salvos it faced, which should be OK. Even a point-blank range energy engagement will rarely last several minutes. Combat should involve a lot of wear and tear on ships.
In VB6 Aurora, the no energy weapon in atmosphere rule was intended to prevent the destruction of populations by energy weapons. For C#, the weapon failure and lower planetary bombardment for energy weapons are intended to allow that destruction, but not easily.
Oh, I understand that rationale (though I still think it works better if failure rate is modified by RoF, since otherwise a ship with a giant spinal laser/plasma carronade can still inflict nearly infinite damage by repeatedly bombarding with it). As is it also creates an odd scenario where you specifically want to disable your smaller guns for planetary bombardment.
I think the maintenance failures for weapons is also a positive change for space combat even if it was intended for bombardment, since it prevents the technique of infinite kiting.
There is also the constraint of ensuring bodies with very good minerals are still rare. I could expand the lower end (Minimal, Low), and leave the upper end the same without too much concern.
Missile warheads inflict civilian casualties at the rate of 100,000 per point of damage. Energy weapons inflict civilian casualties at the rate of 2,000 per point of damage.
Regarding orbital bombardment; the lack of roll over for more destroyed facilities might actually be a flaw. It means that if you drop your biggest nukes on a planet you can quickly kill most or all of the population (at 100 000 per point of damage a 16 damage missile kills 1.6 million colonists) and take the colony for your own with all those nice facilities on planet ready for new workers.
A single energy weapon can destroy only one target per hit. A missile warhead is applied until all damage is used. For example, a 5-point missile warhead is counted as 100. If the first installation hit is a construction factory, that factory is destroyed and the remaining damage reduced to 80. That damage is then applied the next installation hit and so on.
In VB6 Aurora, the no energy weapon in atmosphere rule was intended to prevent the destruction of populations by energy weapons. For C#, the weapon failure and lower planetary bombardment for energy weapons are intended to allow that destruction, but not easily.
However, ships only using their larger weapons for planetary bombardment (i.e. not PD weapons) is what I am aiming for.
This sounds a bit simplistic, and like it makes it way to easy to wipe out populations entirely with nukes.
For example should the last 100,000 population of scattered survivors on a massive planet that at the start of bombardment housed billions really be possible to finish of with a single nuke?
And shouldn't there be some randomness involved here too?
I think the idea of missiles killing a percentage of a population, while also having a minimum casualty count, is a really smart way to handle inflicting casualties. You could even work in the surface area of the planet, where a small body would receive a higher percentage of their population harmed per missile strike. A colony built into a small asteroid might not be able to take more than one nuclear blast without the surface being completely consumed.
I don't have any objection in principle to reducing the effect of nukes against small populations. They would have to be fairly small though. Even smaller Earth-based population are still relatively concentrated. Australia for example, has a population of about 25m and one of the lowest population densities on Earth (229th / 241), yet the top 8 cities account for about 70% of that population and the top 20 account for 80%.
Perhaps below 10m, it would start to make a difference. Even that is probably high, because new colonies are likely to be in small areas (look at Earth-based colonization). Also, not sure how much game play benefit (in terms of consequential decision) this would add.
It's not so much about small populations actually. I guess what I am after mostly is some diminishing returns.Remember that reducing a population of 1 billion to a population of zero would require 10,000 points of nuclear damage. Would that not render the planet uninhabitable generally anyway?
The first nukes hitting the main population & industrial centers ( or forces guarding them ) would be significantly more devastating then the last nukes when everything of value already is destroyed and all that remains are some rural / mining / food production facilities in the countryside...
And that goes for both facilities and population.
I don't have anything against being able to kill of 80%+ of the population of a small new colony of 100k pop using a single nuke. My issue is being able to kill the same amount of population on a planet that recently housed billions, where the last 100k pop realistically would be the 0.00X% that was hardest to get ( extreme rural, surivors/preppers, refugees in caves/bunkers and so on ).
I'm not sure if it's even feasible to do, maybe some sort of "recently bombed" modifier lowering damage of subsequent nukes or something to model this.
The only real game benefit I see would mainly be making it harder to totally wipe out all life & facilities right away, so you could have some scenarios/stories with a small post-apocalyptic band of survivors.
Remember that reducing a population of 1 billion to a population of zero would require 10,000 points of nuclear damage. Would that not render the planet uninhabitable generally anyway?
Yeah probably. It was mostly an extreme example though to make a point. You could make the same argument with 1, 10 million or 100 million initial population ( That it would be neat if the final percentages left of population & buildings was getting gradually harder to kill ).
Destroyed installations could perhaps produce ruins which would then continue to absorb some amount of the bombardment damage and would require a large amount of damage to completely flatten. Maybe ruins could also be reconstructed at a lower cost than building things again from scratch.
Destroyed installations could perhaps produce ruins which would then continue to absorb some amount of the bombardment damage and would require a large amount of damage to completely flatten. Maybe ruins could also be reconstructed at a lower cost than building things again from scratch.
If the game went this route, maybe ground units with construction equipment could passively restore damaged buildings?
While we're discussing ruins and facilities, what if they improved ground unit defense? Historically, built-up areas have been some of the hardest to assault.
The reason you are unlikely to use standard high explosives in space is because the energy density of a fission bomb is three orders of magnitude greater than an explosive, a pure fusion bomb would even reach 4 orders of magnitude greater than an explosive. This means you can shove a whole lot more boom in a handier package, and in space, where propagating an explosion is difficult, the harsh radiation coming from a nuke works quite well.
Radiation is the ONLY effect a nuke has in space. There's no shrapnel worth mentioning, the bomb case will be atomized. And there's no atmosphere to propagate a blast wave. Radiation is all they have left. Remember, this includes the thermal pulse, so it's plenty capable of causing real damage, not just irradiating things.
Enhanced radiation warheads are supposed to be things like neutron or cobalt bombs.
"When it's done."
Steve isn't working on a schedule, this is a hobby to him. The best, rough estimates we have 'late this year at the earliest, or somewhere in 2019.'
Steve, you mentioned that it will be possible to have multiple instances of the same window open. Will this work with different empires? Or only with one?
The new training commands seem a bit off to me from a RP perspective.
Ripping up your fleet structure and reassigning a fleet to a new command seems wrong to issue an order, especially since this means you are effectively training under another CO.
With the new training structure it would be great to understand what sort of timelines that will mean for getting crew to 100% trained. How many crew points do you need to get 1% training completed?
With the new training structure it would be great to understand what sort of timelines that will mean for getting crew to 100% trained. How many crew points do you need to get 1% training completed?
You need 500 Fleet Training Points for 100% Fleet Training (instant response to movement and firing orders). This is separate to Crew Grade Points.
With the new training structure it would be great to understand what sort of timelines that will mean for getting crew to 100% trained. How many crew points do you need to get 1% training completed?
You need 500 Fleet Training Points for 100% Fleet Training (instant response to movement and firing orders). This is separate to Crew Grade Points.
Steve
Thanks for confirming. Just looking at a current game I have going that's 15 years in I have one commodore with a crew training of 275 and one captain with training of 200. Assuming I tier the admin command with the commodore in the general admin top layer and put the captain in the training admin command and that I have fresh crew with 100% morale, 6% crew grade bonus and I can use commanders and below to run the ships am I right in thinking it would take 500 / (200 + (0.1 * 275) * 1 * 1.06) = 2.075 years roughly to fully train the ships? If correct that seems like an awful long time to complete training compared to broader timescales on exploration and construction in the game.
Any thoughts on tweaking total requirements to get training times down to between a year and 18 months or so?
With the new training structure it would be great to understand what sort of timelines that will mean for getting crew to 100% trained. How many crew points do you need to get 1% training completed?
You need 500 Fleet Training Points for 100% Fleet Training (instant response to movement and firing orders). This is separate to Crew Grade Points.
Steve
Thanks for confirming. Just looking at a current game I have going that's 15 years in I have one commodore with a crew training of 275 and one captain with training of 200. Assuming I tier the admin command with the commodore in the general admin top layer and put the captain in the training admin command and that I have fresh crew with 100% morale, 6% crew grade bonus and I can use commanders and below to run the ships am I right in thinking it would take 500 / (200 + (0.1 * 275) * 1 * 1.06) = 2.075 years roughly to fully train the ships? If correct that seems like an awful long time to complete training compared to broader timescales on exploration and construction in the game.
Any thoughts on tweaking total requirements to get training times down to between a year and 18 months or so?
Your calculation is correct, although bear in mind that order delays in C# are also reduced by the fleet reaction bonus and that reaction bonus can be boosted by one or more admin commands as well.
The total training time is similar to VB6 Aurora and it should be an significant achievement for a ship to have a 100% bonus. Also, the low-level fleet training still exists in C#, which adds 30 points + grade bonus per year to all ships, regardless of admin command.
Does the training quality degrade over time, when a ship is not in active practice?
The new training commands seem a bit off to me from a RP perspective.As sloanjh said it is actually "realistic", even though at first glance it seems counter-intuitive. Most modern militaries work this way, in that there are separate Training and Operational commands. Air Forces especially have Basic training facilities from where pilots move to Training squadrons and eventually to Operational squadrons. With the new and flexible Admin commands and OOB handling, it will be super simple to just click'n'drag a Fleet to be under Training Admin for a year or two, and then drag it back to an Operational Admin.
Ripping up your fleet structure and reassigning a fleet to a new command seems wrong to issue an order, especially since this means you are effectively training under another CO.
Does the training quality degrade over time, when a ship is not in active practice?
No, although it will fall if the crew suffers casulties and absorbs replacements. It fact, it slowly increases over time to reflect skill gained from normal activity, rather than the much faster growth from intensive training.
While it would be simple to add a mechanic of falling over time, that adds micromanagement without any real gameplay benefit, plus it is interesting from a roleplay perspective to create elite ships, and that would be diminished if they slowly faded over time.
I tend to agree that non-zero reaction times are somewhat preferable.
It would be good but don’t think possible from a game play perspective given relative speeds of ships v for example beam weapon ranges. For gauss fighters you could end up never being able to get in range and for longer ranger beams it could be a real nerf as you miss chance for multiple shots.
It would be good but don’t think possible from a game play perspective given relative speeds of ships v for example beam weapon ranges. For gauss fighters you could end up never being able to get in range and for longer ranger beams it could be a real nerf as you miss chance for multiple shots.
Why... this is only reaction to new orders. This has nothing to do with initiative.
IMO the biggest issue is what happens during delay... if orders change from "keep a distance of 200k" to "keep a distance of 300k", at no time should the task group sit idle and allow a slower enemy to close the range at will.
IMO the biggest issue is what happens during delay... if orders change from "keep a distance of 200k" to "keep a distance of 300k", at no time should the task group sit idle and allow a slower enemy to close the range at will.
Agreed, a better behavior would be to continue with the previous order(s) until the delay has expired.
John
There's absolutely no reason for a task group to sit idle due to order delay, it makes sense they would continue the old order, the delay is in changing orders.Yeah. Similarly it should be possible to assign a target rotation beforehand. If you know when and how you are going to change targets, the crews can plan ahead. (Fire on x till destroyed, then y then z) Changing target priorities should have a delay, but not following a preplanned firing pattern.
It's a terrible idea in battle to just sit still while waiting for commands, unless you had specifically been told to sit still beforehand.
Fleets undergoing fleet training being unable to use maintenance facilities or Recreational locations seems odd. That would mean you'd need to remove the fleet from the training structure in order to have it recuperate when the ships and crew get too worn down during training, which seems pretty weird.
Fleets undergoing fleet training being unable to use maintenance facilities or Recreational locations seems odd. That would mean you'd need to remove the fleet from the training structure in order to have it recuperate when the ships and crew get too worn down during training, which seems pretty weird.
Fleets undergoing fleet training being unable to use maintenance facilities or Recreational locations seems odd. That would mean you'd need to remove the fleet from the training structure in order to have it recuperate when the ships and crew get too worn down during training, which seems pretty weird.
Without those rules, a training fleet in the same location as maintenance facilities and recreational facilities would effectively be training without cost.
Fleets undergoing fleet training being unable to use maintenance facilities or Recreational locations seems odd. That would mean you'd need to remove the fleet from the training structure in order to have it recuperate when the ships and crew get too worn down during training, which seems pretty weird.
Without those rules, a training fleet in the same location as maintenance facilities and recreational facilities would effectively be training without cost.
How will we train short deployment ships, say something like a month deployment or less without massive micromanagement?
Could it be possible with some order that suspend training for a certain time so ships can overhaul and rest the crew while being attached to a training command. An order only available to ships in a training command or some automatic function that have the fleet quit training to be maintained and then automatically resume training again.
From a RP perspective I don't want to give my ship unrealistic long deployment time just to avoid micromanagement with training. There are similar problems in VB Aurora but you can skirt around them to avoid the micromanagement.
I love the new intelligence system, now theres a great reason to capture and interrogate enemy officers, as well as having small passive scouts wandering around the galaxy.
I love the new intelligence system, now theres a great reason to capture and interrogate enemy officers, as well as having small passive scouts wandering around the galaxy.
This just jogged loose a thought: in the past, parking ships with sensors in an alien system has upset them, due to not liking being spied upon. So seeing one of those "small, passive scouts" in your system should give negative modifier to relations. This could be realized in several ways:
1) Technobabble that makes it easy to detect ELINT systems on a ship (all those antennae on Soviet trawlers). Then you only upset the aliens if you actually are spying on them.
2) ELINT only detectable through the normal ELINT mechanism. This would probably mean aliens would be upset by any ship. This would also open up the possibility of "inspections", which give away design specs of a ship, but demonstrate that no ELINT is there. Also the concept of diplomatic couriers, which could be assumed to have no ELINT (and would give extra negative if they were discovered to be spying) or could be approved for ELINT as part of the assumed price of diplomacy.
3) Undetectable ELINT.
Just throwing thoughts out there....
John
ELINT is passive so it would be difficult to detect. Perhaps, a really close pass by a patrol ship would be able to determine some of a ship's capabilities, although that opens a lot of other doors.
One option for players is a ship with a large ELINT array, designed to lurk far out in alien systems, monitoring their populations without being detected.
Your ship isn't squawking 'I'm a 16k ton warship', it's squawking 'I'm this ship from this registry, which you may've heard of.' There's a few critical differences in the assumptions as a result.
That said, ships with transponders on, military and not, should provoke less of a reaction than non-transponder using ships being detected. Even if the reaction is just a (polite-ish) 'get out of our territory,' instead of immediate deployment of military assets to detain whatever ship that just showed up.
Are transponders a thing again in C#?
How different will they be? I can't find a post in your changelist... .Are transponders a thing again in C#?
Yes, C# has transponders.
How different will they be? I can't find a post in your changelist... .Are transponders a thing again in C#?
Yes, C# has transponders.
And now we have proper supply elements for ground forces. What was left unsaid, was how do we replace supply units that have been consumed?
I'm kinda tempted to ask for a Large Logistics Module that's either Static only or limited to Static, Super Heavy and Ultra Heavy Vehicles. It's not the sort of thing you'd see outside of very large commands that expect heavy combat though. Does the system calculate total supply draw per combat round, per number of combat rounds or per day or something, does it check from the formation first or does it look in higher order formations first? And does it draw first from vehicle provided supply points or infantry provided supply points when you are talking of the same formation?
All this is covered in the rules post. The text continues below the first screenshot.
All this is covered in the rules post. The text continues below the first screenshot.
... I need better reading comprehension.
Still, a question remains unanswered. There's no indication as to whether supply is drawn per combat round, per day, or per other measure.
I'd have no problem with units out of supply being even more limited than only 1/4th of the units making attacks. Up to and including no units making attacks. Hey, logistics are important in warfare, and if there's one thing planetary garrisons will be good at it's stacking endless piles of supplies so it's not as if they are likely to run out if you do it right. Which makes me repeat the question, are you going to add a Large Logistics Module for Static units that has more supplies?
Also, I note that the calculation for the GSP draw of a unit is (Penetration Value * Damage Value * Shots), but the racial force strength modifiers can cause confusion in this calculation on the part of players. Ah well, at least the GSP cost is calculated ahead of time and tabulated in the unit design window.
If I think of vehicular supply as trucks full of stuff, then it seems like both the trucks and the stuff are consumed when the supplies are used, so that one must rebuild both the trucks and the stuff to replace the supplies. If this is a correct interpretation of the rules, I'm interested in the rationale for this behavior.
I can see having some attrition on the trucks due to wear and tear but 100% seems high. This brings up another thought: should the maintenance abstraction be higher/adjusted to also require GSP for units in combat, especially vehicular? And I forget if there's a ground forces training system in place, but if so it seems that should have enhanced supply requirements too....
Thanks,
John
Eventually, I decided that having consumable vehicles was a lot more straightforward ...
I would think of it like there is a global, practically inexhaustable truck pool. When you create a supply vehicle, you're really just creating the supplies, then demanding a truck come and pick it up (something we can assume is a trivial matter for an interstellar empire to organise). They can be comandeered civilian trucks, purpose built trucks, whatever, they spend most of their time existing in the aether of the society until they are required. Then, when their supplies have been exhausted they go and do things, get maintained, make their way to where they need to go by civilian means, whatever, melt back into society and may or may not be one of the future comandeered trucks.
Yes, it's a little abstract, but it makes more sense than the trucks just spontaneously combusting because they ran out of bullets or something, to my mind.
Then, when their supplies have been exhausted they go and do things, get maintained, make their way to where they need to go by civilian means, whatever, melt back into society and may or may not be one of the future comandeered trucks.
Yes, that is a good way of looking at it. Although I do like the edible trucks idea :)
So we could call it the CTN "Commercial Truck Network"? :: ducks and runs away ::Then, when their supplies have been exhausted they go and do things, get maintained, make their way to where they need to go by civilian means, whatever, melt back into society and may or may not be one of the future comandeered trucks.
Yes, that is a good way of looking at it. Although I do like the edible trucks idea :)
The 'supply trucks' are an abstraction of the logistics system. I considered having vehicles that carried supplies and could be replenished. However, that would require tracking the supplies as a separate item to the supply vehicles, building the supplies separately, adding rules/code to support that resupply process and adding the UI to support that extra detail. Eventually, I decided that having consumable vehicles was a lot more straightforward, so I made the logistics modules smaller and cheaper than originally intended to cover the cost of the vehicle.
GSP is only required for combat and the rest of the time maintenance is purely wealth-based for ground forces. although the point about training is a good one.
The 'supply trucks' are an abstraction of the logistics system. I considered having vehicles that carried supplies and could be replenished. However, that would require tracking the supplies as a separate item to the supply vehicles, building the supplies separately, adding rules/code to support that resupply process and adding the UI to support that extra detail. Eventually, I decided that having consumable vehicles was a lot more straightforward, so I made the logistics modules smaller and cheaper than originally intended to cover the cost of the vehicle.
GSP is only required for combat and the rest of the time maintenance is purely wealth-based for ground forces. although the point about training is a good one.
Still means that 12 size points worth of unit go up in smoke to provide supply when a vehicle logistical unit is consumed.
I get not wanting more coding overhead though.
Still, this means that a vehicle is 80% efficient when it comes to supplies, while an infantry supply unit is always 100% efficient.
It might be worth it in multi formation set ups, but when you are willing to sling large and unwieldy formations around building only infantry supply in your humongous formation gets you up to 25% more supply than a set up that (also) uses vehicles.
However, as those will be front-line units it also opens your supply units to direct attack. It is a trade-off.
About the new combat rules, I am a bit worried about the breakthrough mechanic. If one race uses many smaller formations they seem much more prone to getting a formation annihilated than using a few (one) massive formation. Also, how is massive overkill handled, generating 1 soldier formations to absorb a divisions firepower should also not be a thing, even if these tiny formations are very unlikely to be targeted.
The breakthrough mechanic is partially to avoid the potential exploitation of using unrealistic tiny formation elements. Even so, it is still only a second attack, not multiple attacks (so huge formation elements are not too useful). The other downside to many tiny elements is the micromanagement aspect, plus no commander support and probably no support from the rest of the hierarchy due to the lack of HQs. I need to add the various commander bonuses to the ground combat rules.
The breakthrough mechanic is partially to avoid the potential exploitation of using unrealistic tiny formation elements. Even so, it is still only a second attack, not multiple attacks (so huge formation elements are not too useful). The other downside to many tiny elements is the micromanagement aspect, plus no commander support and probably no support from the rest of the hierarchy due to the lack of HQs. I need to add the various commander bonuses to the ground combat rules.
To make sure I understand:
1) massive overkill is the disincentive to making huge formations - even with a breakthrough attack, a 10x overkill size imbalance means you waste 40-80% of your combat power (could have killed 10 (or twenty with breakthrough), instead kill 1 twice)
2) breakthrough attack (plus micro management) is the disincentive to making tiny formations - if your formations are too small your opponent will get 2x kills.
I forget: are players allowed to move units amongst the 4 postures every 3 hours? If so, perhaps they should be able to "shatter" or "group" the level of combat formations they're using at the same time. Otherwise a lot of the efficiency in the combat will be a guessing game of "at what level should I group my formations".
Thought experiment: if a monolithic corps sized unit "A" is in combat with an enemy corps that is broken into battalions "B", the "A" corps could break up into divisions at the first 3 hour mark, brigades at the second, and so on. In the mean time, "B" would be breaking into companies, platoons etc to keep in the massive overkill mode until "A" got small enough to be in the "optimal overkill" range (presumably squad vs. individual") at which point "B" would start aggregating. This doesn't sound like a great result, so....
How about a unit can "shatter" as many levels as it wants, but can only "group" one level per turn. So in the thought experiment "A" could shatter into brigades or battalions (or even some of each) after the first turn. "B" could still try to race to the bottom, but "A" would be able to follow much more quickly.
Here's another suggestion to encourage large units: give a mild power to the combat power of a formation, e.g. adjustedPower = rawPower^1.1 or rawPower^1.2. That would encourage aggregation.
John
Entirely honest question, is the size of the frontline dictated by the number of formation or the size of the units in a deployed force?
Also, I'd vote for not letting Support line units swap units around. Otherwise there's no real reason to place units on the Rear Echelon.
I will also add the various levels of ground combat bonus for superior HQs, so large formations will make better use of the available high quality commanders.
I haven't decided yet on the ability of formations to swap units while in battle or how they move between field positions. At the moment I am leaning toward moving one field position per combat round with the positions being 1) Front Line Attack, 2) Front Line Defence, 3) Support, 4) Rear Echelon. Also, only formations in rear echelon (or maybe support - need to decide) can exchange units. So if you want to reorganize during combat, you will need to pull formations out of the line to do so.
I haven't decided yet on the ability of formations to swap units while in battle or how they move between field positions. At the moment I am leaning toward moving one field position per combat round with the positions being 1) Front Line Attack, 2) Front Line Defence, 3) Support, 4) Rear Echelon. Also, only formations in rear echelon (or maybe support - need to decide) can exchange units. So if you want to reorganize during combat, you will need to pull formations out of the line to do so.
Will units in rear echelon also regain suppressed morale (due to losses) at a higher rate?
John
Will units in rear echelon also regain suppressed morale (due to losses) at a higher rate?I hadn't considered that, but it does make sense.
I note that Light Bombardment units are not able to provide support from any position other than the Frontline.I'd imagine Light bombardment is supposed to represent things like mortars, which wouldn't be firing on enemy back line artillery positions. It would be weird for them to be able to do so unless they were accompanying a force that was engaging said units at closer range. Unless they're supposed to be heavier than that.
Inconvenient that.
However, does that mean that due to the way support works they can hit enemy Rear Echelon support units when performing counter battery duty?
Not that it'd be very effective I'd expect, but still.
Something else to consider: moving units from one branch of the org chart to another, e.g. transferring a brigade from one division HQ to another should probably yield a temporary "morale" hit due to lack of having trained together. I recall this used to happen for training in ships and was eventually ripped out due to being too severe (training is a long-term thing to regain), but if it's a hit to morale (which can presumably be recovered on a much quicker timescale) it might not be so bad.Transferring formations should give some morale hit, but transferring individual troops between formations should give significant morale losses to give incentive to keep formations and not adjust them during battle
John
It seems that the land combat is becoming more complex than the spatial one.
Building and assigning units to formation will be a headache. Could we have some sort of template builder ?
You create a template, then put X ground facility to build or complete all the necessary units ?
If frontline units could also do support at the same time, that would mean they get to fight twice as often: once as support, and once by attacking/defending themselves... so I guess frontline units can't support. That means light bombardement weapons they are completely outclassed by the light autocannon:
Type: Size/Penetration/Damage/Shots
Light Bombardement: 20/10/10/3
Light Autocannon: 18/20/20/3
So the autocannon is smaller and thus cheaper, but has douple the penetration and damage
I note that Light Bombardment units are not able to provide support from any position other than the Frontline.I'd imagine Light bombardment is supposed to represent things like mortars, which wouldn't be firing on enemy back line artillery positions. It would be weird for them to be able to do so unless they were accompanying a force that was engaging said units at closer range. Unless they're supposed to be heavier than that.
Inconvenient that.
However, does that mean that due to the way support works they can hit enemy Rear Echelon support units when performing counter battery duty?
Not that it'd be very effective I'd expect, but still.
I feel the big factor missing in the entire targeting scheme so far of front line attack/defense, support and rear echelon is mobility. Static guns and infantry on foot is very unlikely to provide a breakthrough and attack rear positions, while armored or air mobile units can possibly strike deeper.
Similarly, how does fortification interact with the positions? It does not seem like you should be able to fortify much in a frontline attack stance, as it suggests being on the move, outside of well prepared positions.
Only allowing superior formations to support is also kind of restrictive, what if you want to have two artillery battallions per 3 frontline formations, and support two of them? It also makes it impossible to have independent artillery formations that are not headquarters.
I would very much like to be able to shift whole artillery formations around between formations
Would that be an option where to add APC, IFVs and other transports, by allowing infantry to have the same breakthrough attack chance as vehicles?I feel the big factor missing in the entire targeting scheme so far of front line attack/defense, support and rear echelon is mobility. Static guns and infantry on foot is very unlikely to provide a breakthrough and attack rear positions, while armored or air mobile units can possibly strike deeper.
Similarly, how does fortification interact with the positions? It does not seem like you should be able to fortify much in a frontline attack stance, as it suggests being on the move, outside of well prepared positions.
Only allowing superior formations to support is also kind of restrictive, what if you want to have two artillery battallions per 3 frontline formations, and support two of them? It also makes it impossible to have independent artillery formations that are not headquarters.
I would very much like to be able to shift whole artillery formations around between formations
If you are on front line attack you cannot fortify. I need to mention that in the rules.
Good point about the base type on attack. I have changed the rules so that static element cannot conduct a breakthrough attack, while infantry have a one third chance of conducting a breakthrough attack. It is also worth bearing in that static and infantry can fortify more effectively than vehicles, so setting them to front line attack incurs a larger effective penalty than it does for vehicles.
I initially had the option that any superior formation or any formation that was a subordinate formation of that superior formation (such as an independent artillery unit), could support the front-line formation. It quickly became apparent that meant one brigade HQ could support the formations attacked to another brigade HQ, if they had the same Divisional HQ. That didn't seem realistic so I removed it. However, I just realised what I need to do was make that "a subordinate formation of that superior formation which itself does not have any subordinate formations". I'll add that option.
EDIT: I have made the above changes to the code and the rules posts.
That doesn't mean Steve that a Light Bombardment unit on the frontline that is higher in the hierarchy than the unit it's supporting can't engage in counter battery fire with a Heavy Bombardment equipped unit in the Rear Echelon.
If it does mean that, or at least that they can't engage in support fire, well, at that point Crew Served Anti-Personnel just became by definition better due to being 8 sizes smaller and having 3 more shots per round with otherwise the same traits.
Would that be an option where to add APC, IFVs and other transports, by allowing infantry to have the same breakthrough attack chance as vehicles?
Also, destruction of formations seems like an infrequent occurrence, especially if one wants to keep their numbers manageable. Maybe mobility should already affect the effective target size to attack backline units, or is this already considered a breakthrough?
I honestly don't think special modifiers for breakthrough are necessary. The penalty for leaving fortification for infantry or (especially) static units are already pretty huge.What I mean is that even taking the offensive should be worth it. Light vehicles are likely better at exploiting a breakthrough as they tend to be faster. Also I would consider infantry invaluable in any scenario. No modern tank so far can fight without infantry support, otherwise they get just chewed up.
And it doesn't really obviously follow to me that, say, a super heavy tank would be worse at breakthroughs than a light tank. Sure, the light tank is faster, but the super heavy is better able to just roll over enemy lines. Or infantry for that matter - we're talking about breakthroughs on a strategic scale rather than a tactical one.
It seems that the land combat is becoming more complex than the spatial one.
Building and assigning units to formation will be a headache. Could we have some sort of template builder ?
You create a template, then put X ground facility to build or complete all the necessary units ?
That is how it currently works in C# Aurora.
http://aurora2.pentarch.org/index.php?topic=8495.msg105832#msg105832
I have a question about fighters in ground combat and that is about defending fighters. Will we be able to station fighters on the planets now for use in defensive ground combat support?I brought this up in the ground combat thread (it's pinned) when it was first explained. Steve said he "may add some form of airbase". I don't think I've seen anything further confirming or refuting the concept but I do still think it will be essential to have some sort of protected shelter for them if we want the air to air pods to have any use and for fighters to not be a purely offensive tool. I don't imagine people will be initiating large scale invasions, even less small scale ones, without clearing space of at least immediate threats.
Otherwise are there not a huge risk fighters will more or less always work unopposed. The aggressor are likely to destroy any stations in orbit long before ground combat even occur, or is this a premature thought?
Does your own supporting artillery/aircraft also require forward directors?
I have a question about fighters in ground combat and that is about defending fighters. Will we be able to station fighters on the planets now for use in defensive ground combat support?
Otherwise are there not a huge risk fighters will more or less always work unopposed. The aggressor are likely to destroy any stations in orbit long before ground combat even occur, or is this a premature thought?
How does the 'aircraft' ground unit template tie into AA defense? Will they work together in the same strike?
Also, for medium and heavy AA defense, would not a scheme like for bombardment units make sense, that an independent AA unit defends its headquarters and its subordinate units, to allow for medium and heavy AA formations that are attached to brigades.
I have a question about fighters in ground combat and that is about defending fighters. Will we be able to station fighters on the planets now for use in defensive ground combat support?
Otherwise are there not a huge risk fighters will more or less always work unopposed. The aggressor are likely to destroy any stations in orbit long before ground combat even occur, or is this a premature thought?
If you have maintenance facilities, you can have fighters based at a population. If you give them a support order, they can't be targeted by normal naval combat. If you want to keep them away from ground combat as well, you can put them on support of a rear-echelon formation. Fighters in active combat can be targeted by AA units, hostile fighters equipped with AA weapons and by orbital bombardment support (more on that when I post the orbital bombardment rules).
I will make it so that fighters with the ground support order are maintained normally. The attacking force can bring in its own maintenance facilities, which will allow them to 'base' fighters on the ground.
Spacecraft will still have massive travel ranges even with fighters, so you should be able to station your carriers far enough away that beam attacks are not a threat.
Of course, that does mean you need to pay some more attention when landing, but that was a thing with VB6 Aurora as well.
Or accept the practical loss of the planet and drown it in nuclear fire.
Seriously, swarms of high yields missiles fired from very long range are a valid answer to a planet that's too heavily fortified to assault. Even if it doesn't kill the enemy forces on planet it will render it sufficiently uninhabitable that if the thousands of points of missile blast damage doesn't kill every civilian the dust and radiation will.
At which point there's really no point to do anything other than keep an eye on the planet so nothing tries escaping and maybe send a heavily armoured bombardment fleet out every once in a while to crack the defenses and whittle them down over time. It's not as if there's an industrial effort left to provide replacements or tech up.
A heavily fortified planet is also likely to have substantial anti-missile defences, including planetary CIWS. It may even come down to a siege, preventing key minerals reaching the planet so that the defenders eventually run out of the materials needed to maintain their ships or build AMMs.How do planetary CIWS and orbital platforms/shipyards/ships in orbit play together? Because we ca't build ground based AMM systems at the moment, and if they are not protected by CIWS, AMM platforms will be a prime target to weaken the defenses
Well, espionage teams are already in the game. I haven't heard much about how they'll be affected in C# though. If they're kept mostly as-is, it could just be a matter of giving them the ability to temporarily disable defensive emplacements, or knock out fire control/sensor stations to make an assault easier.
That's impossible. Tracking speed is a modifier on the accuracy rolls. Even if you go 10 times as fast as the tracking speed you'll still have 1/10th the chance of getting hit compared to something right at the limit of the weapon in question IIRC.
That said, I'd expect that FACs and fighters of 500 tons and less will be common designs for getting troops on the ground, or other, fast moving craft with drop pods, but those have the disadvantage of needing to get back out, while landed ships can stay grounded and hope they aren't overrun.
It'd be nice if we could have some way of performing the sort of special operations mission against planetary defense cannons like there were against coastal defense cannons in previous wars. It doesn't fit the current system design for ground combat though.
That's impossible. Tracking speed is a modifier on the accuracy rolls. Even if you go 10 times as fast as the tracking speed you'll still have 1/10th the chance of getting hit compared to something right at the limit of the weapon in question IIRC.
This makes a pretty compelling case that you should be allowed to make independent fire control units with fire controls of your own design. A x2 or even x4 speed modifier will likely put an end to any dreams of invincibility, and turreted weapons may also be useful for point defense applications.That's impossible. Tracking speed is a modifier on the accuracy rolls. Even if you go 10 times as fast as the tracking speed you'll still have 1/10th the chance of getting hit compared to something right at the limit of the weapon in question IIRC.
Speed alone doesn't allow total invincibility, but it may when coupled with ECM.
Now I'm wondering how practical a 500ton fighter with both drop pods and weapon pods would be. Drop the troops off and then stick around providing fire support. Sort of like a Mechwarrior dropship.
I wonder if there's any chance fighters will auto-deploy ground units when transitioning from space to ground support.
Speed alone doesn't allow total invincibility, but it may when coupled with ECM.
Now I'm wondering how practical a 500ton fighter with both drop pods and weapon pods would be. Drop the troops off and then stick around providing fire support. Sort of like a Mechwarrior dropship.
I wonder if there's any chance fighters will auto-deploy ground units when transitioning from space to ground support.
Such a fighter wouldn't be very practical. You'd be better off with the cheaper troop transport bays, since 500 ton fighters can land and should be able to deploy their troops fast enough. After that you've got basically a gunship/transport hybrid like the Hind. It'd probably be more effective if you used specialized fighters for the roles in question. A big, wallowing 500 ton fighter that has devoted something like a major chunk of its mass towards doing something other than it's doing now is much easier a target than 5 100 tonish fighters with more guns and armour, or a 500 ton transport that has dedicated the mass that would be a gunship's weapons to armour instead.Speed alone doesn't allow total invincibility, but it may when coupled with ECM.
Nope, just like the speed advantage, IIRC ECM only drops the chances to hit by a percentage. You could still get hit, it's just notably less likely. Having both a speed advantage and an ECM advantage would greatly lower the chances of getting hit and destroyed though.
Nope, just like the speed advantage, IIRC ECM only drops the chances to hit by a percentage. You could still get hit, it's just notably less likely. Having both a speed advantage and an ECM advantage would greatly lower the chances of getting hit and destroyed though.ECM is subtracted, unlike pretty much every other modifier, making it quite strong, especially in regard to the new missile ECM system.
I think the new system looks very good on paper. Just needs testing to make sure of the details.Although one benefit of the switch from PDCs to STOs is that planetary defenses will be much more mobile in C#, so it will be easier to consolidate defense on a particular strategic system. I guess there will be a lot more decisions about whether you can ignore a fortress world at a choke point to raid deeper into enemy space, or if exposing supply and reinforcement lines like that will come back to bite you. It could be a big boost for fighters as they can take cover on such a planet. Much more difficult to side step a fortress world if you know its hiding squadrons of deep space bombers.
Having the choice between glassing a planet, cutting it off to wither away, or committing to a massive invasion are logical and sensible choices when it comes to heavily defended worlds. Remember that such worlds well be rare - nobody will have the resources and time to fortify and garrison each colony to the maximum.
It'd be nice if we could have some way of performing the sort of special operations mission against planetary defense cannons like there were against coastal defense cannons in previous wars. It doesn't fit the current system design for ground combat though.Would be a nice option to have infiltrator units which can land in small cloaked ships and sabotage energy grids, so planetary defenses are off. There should be of course a chance to get detected. But if they succeed, energy would be off for something between 2 to 8 hours which could give you an edge in an initial landing of your troops.
it will be easier to consolidate defense on a particular strategic systemYes, it will be, but it will still require some forethought. Since you need to use your troop transports to move the defending units to the planet/body in question first. So unless you knew days/weeks/months beforehand that the invasion is coming, you won't have time to ship much to the target body. Of course, it makes sense to fortify a vulnerable body beforehand if you are advancing towards known alien space, but if you don't know that. Then again, creating pre-positioned REFORGER/MEU style units at strategic locations that can be moved relatively quickly when needed is again a valid real-life strategy and seems it will work in C# Aurora since there will be more choke-points and corridors, instead of spider-webs when it comes to the Jump Point network.
This is a minor suggestion not worth its own post in the suggestions thread.
Could we perhaps change the names of the ground force command bonuses? Some of the acronyms for them overlap. Like GCA is for Attack, Artillery, and Anti-Air.
I'd suggest adding an armor multiplier into the breakthrough calculations somewhere. Since cost scales by armor, without it a unit with double the armor is half as likely to get a breakthrough than the same cost in lighter armored units. Plus it kind of makes sense that an elite, highly capable group of vehicles the enemy has trouble damaging would have an advantage in a breakthrough vs the same number of more basic units.
Or perhaps some way to scale the bonus based on enemy weapon effectiveness vs the armor. That way tanks would do well at breakthroughs against infantry if they didn't have any anti-vehicle weapons, but not so well if they had a bunch of bazookas.
I'd suggest adding an armor multiplier into the breakthrough calculations somewhere. Since cost scales by armor, without it a unit with double the armor is half as likely to get a breakthrough than the same cost in lighter armored units. Plus it kind of makes sense that an elite, highly capable group of vehicles the enemy has trouble damaging would have an advantage in a breakthrough vs the same number of more basic units.
Or perhaps some way to scale the bonus based on enemy weapon effectiveness vs the armor. That way tanks would do well at breakthroughs against infantry if they didn't have any anti-vehicle weapons, but not so well if they had a bunch of bazookas.
Yeah, several good wargames scale breakthrough capability based on if the defenders have sufficient overall AT penetration to get through the armor of the attacking vehicles.
It might also make sense to have some limit on how many times numerical superiority is allowed to focus fire on the same enemy formation, to prevent quantity from always winning over quality ( unless there is one and I missed it ). Realistically somewhere around 4:1 outnumbering on the ground you would probably start to run into problems with getting in each-others way, depending on how crowded the frontlines are. Alot of units concentrating to attack a single one of similar size also would be much more vulnerable to area attacks.
Does the system for commanding a formation too large for their rating allow for negative bonuses? AKA if someone with a limit of 1000 is commanding a 10,000 formation
Locating enemy AA is not difficult when flying Suppression of Enemy Air Defense missions. They'll be trying to shoot the craft down after all, which is rather noticeable at the energy levels we're talking about in Aurora.
Not getting shot out of the sky is more of a trick. Especially since part of the point is getting right into the teeth of enemy AA so they'll give their position away while you try to hit them back. So... are ECM/ECCM components going to matter in this fight, and perhaps flights flying SEAD missions should have some a greater chance of getting targeted by AA that can engage. Also, it's fairly common in modern warfare for enemy air defense units to be on the list of priority targets for artillery if their position can be identified fast enough and is close to the front lines.
Missile launchers aren't that fond of getting blown up by an artillery strike after all. So perhaps put AA units that have fired in the combat round on the list of potential counter battery targets?
The thing is?
You can do a bait and strike technique if your sensor equipment is good enough. And Aurora sensor equipment most likely is good enough as long as it's on the same tech level.
What you basically do is let a specialised bait fighter with heavy armour and ECM loiter around the expected edge of the enemy's engagement range, crossing and escaping as needed, while another fighter loaded with ordnance stays at a greater range and monitors the area for launch/attack sites. Any attack can be located and hit within 20 seconds if you do this right. Anything that can survive a bomb that would hit in that time would be big and armoured enough to be targetable for bigger ordnance now you know it's there, anything that can dodge it would need to move fast enough their escape route can be targeted because it's not going to be hidden.
There's a point in weapons, electronics, computer and camera development where it becomes impossible to hide weapons fire, and we're getting to that point in real life.
The thing is that the aircraft has the energy and range advantage. Even in Aurora that's true, as we're not talking about aircraft but about some very heavy aerospace fighters.
Don't forget that you'd probably be able to have ships in orbit too. Their sensors are going to be much more powerful than anything you can fit on a fighter.
And Jorgen, you don't need to see where the attack starts; if you see where it is and where it's going, you can easily trace it back to the source. And as for missiles, even a ship with no sensors whatsoever (and therefore relying on the default thermal sensors) can detect a missile just before it hits the ship, right? Since the minimum range is 10k km, that presumable means it's detected somewhere between 10k and 0 km. Earth's atmosphere is only 100km thick (approximately). Presumably, most combats will be taking place on similar worlds. So, your ships will always be well within range to spot missiles being fired at aircraft. And atmosphere no longer affects beam weapons, so shipboard point defence can be used to protect fighters against SAMs. Therefore, it seems likely that SAMs in the Aurora universe would be a pretty inefficient way to fight. So, AA beam weapons would probably be the major way of fighting.
Or would they? Again, passive sensors could be used to spot the gunfire, and trace it back to the source. And energy weapons are no longer affected by atmosphere, so why not use targeted orbital bombardment to knock out enemy AA?
Incidentally, Steve, I hope manual targeting of orbital bombardment will be a thing? So you can set each FC to target a different ground formation, exactly like space combat (plus maybe an option for "general targeting, where they just shoot at a random formation)? And, presumably, from that point it works like ground based artillery bombardment?
Just a suggestion.
Don't forget that you'd probably be able to have ships in orbit too. Their sensors are going to be much more powerful than anything you can fit on a fighter.
And Jorgen, you don't need to see where the attack starts; if you see where it is and where it's going, you can easily trace it back to the source. And as for missiles, even a ship with no sensors whatsoever (and therefore relying on the default thermal sensors) can detect a missile just before it hits the ship, right? Since the minimum range is 10k km, that presumable means it's detected somewhere between 10k and 0 km. Earth's atmosphere is only 100km thick (approximately). Presumably, most combats will be taking place on similar worlds. So, your ships will always be well within range to spot missiles being fired at aircraft. And atmosphere no longer affects beam weapons, so shipboard point defence can be used to protect fighters against SAMs. Therefore, it seems likely that SAMs in the Aurora universe would be a pretty inefficient way to fight. So, AA beam weapons would probably be the major way of fighting.
Or would they? Again, passive sensors could be used to spot the gunfire, and trace it back to the source. And energy weapons are no longer affected by atmosphere, so why not use targeted orbital bombardment to knock out enemy AA?
Incidentally, Steve, I hope manual targeting of orbital bombardment will be a thing? So you can set each FC to target a different ground formation, exactly like space combat (plus maybe an option for "general targeting, where they just shoot at a random formation)? And, presumably, from that point it works like ground based artillery bombardment?
Just a suggestion.
I still fail to see why ground based energy sources and ability to fool even ship sensors could not be far superior. Ships sensors would also be tailored for space not the condition to a specific planet which planet wide sensors, cloaking systems etc. would. If you don't want to believe that ground based fire can be cloaked or enemy sensors fooled that is up to you, but I don't see why it could not or that AA installations can be moved with anti-gravity devices rather quickly after use.
If ground base AA system were as impotent and useless no one would use them. Even the US use ground based AA even if they dominate the skies. Weaker countries rely more on it because it is cheaper and from a defence perspective very strong.
But you can't cloak starship weapons, so why would you be able to cloak surface-based weapons?Starship weapons cannot be hidden because there is nothing to hide them in space. On planet surface, there is. The atmosphere can distort where the laser beam came from, terrain features might enable rapid shoot'n'scoot operations. Counter-fire isn't instant even with computer assistance, because there is always delay and lag: you have to observe the AA fire, then calculate the area where its coming from, then make a decision whether to fire, then get into a firing position, and only then is your counter-fire moving at the speed of light. Fighters operating on a planet are immune to fire from STO and space ships, meaning that they are operating at low enough altitudes that terrain and curvature come into play, so the same things work for the benefit (as well as hindrance) of AA.
I think there is something seriously off with the flak suppression task: Imagine two different ground forces: Force A has a few AA units in every formation. Force B has it's AA units a lot more concentrated, with many formations having no AA at all.Presumably they will average out the same, because the fighters will kill far more AA units when they attack the AA blob than when they attack dispersed AA. I'mnot necessarily saying it's how it works now (I'm not sure) but it's how it should end up working.
Let's assume a fighter force goes on flak suppression agains these forces.
Case A: Fighters pick any formation. Formation has a few AA unit, thus gets some hits. So until the fighters have deprived many formations of their AA units, they will hit some with every attempted attack.
CaseB: Fighters pick any formation. Case B1: This formation has no AA units. Fighters get shot at, but shoot nothing in return. Case B2: Fighters pick a formation with AA units. Fighters attack these units, but since this formation consists mostly of AA units, they only kill a small part of them. This means in general, that the fighters won't have any targets most of the combat rounds, which is clearly preferable.
Something similar happens with force C and D, where force C consists of one large formation (which thus contains all AA units the force has) and force D has lots of small formations, each having max one AA unit. Fighters attacking force D will probably often have no valid targets, or cause massive overkill. This could be made more crazy by including many one-soldier formations into your army, protecting your AA from fighters!
Presumably they will average out the same, because the fighters will kill far more AA units when they attack the AA blob than when they attack dispersed AA. I'mnot necessarily saying it's how it works now (I'm not sure) but it's how it should end up working.
Quote from: Person012345 link=topic=8497. msg110257#msg110257 date=1539105012Presumably they will average out the same, because the fighters will kill far more AA units when they attack the AA blob than when they attack dispersed AA. I'mnot necessarily saying it's how it works now (I'm not sure) but it's how it should end up working.
Yes, that is true. Also, you would want to protect your formations from ground support and search and destroy, not just anti-flak, so it doesn't necessarily make sense to concentrate the AA in one place (especially light AA). Plus, if you have heavy AA it doesn't matter where they are located as they can fire on any attacking aircraft. Having said all that, you do have the option of an 'AA blob' if you believe your opponent will use anti-flak instead of ground support.
Quote from: Steve Walmsley link=topic=8497. msg110260#msg110260 date=1539107101Quote from: Person012345 link=topic=8497. msg110257#msg110257 date=1539105012Presumably they will average out the same, because the fighters will kill far more AA units when they attack the AA blob than when they attack dispersed AA. I'mnot necessarily saying it's how it works now (I'm not sure) but it's how it should end up working.
Yes, that is true. Also, you would want to protect your formations from ground support and search and destroy, not just anti-flak, so it doesn't necessarily make sense to concentrate the AA in one place (especially light AA). Plus, if you have heavy AA it doesn't matter where they are located as they can fire on any attacking aircraft. Having said all that, you do have the option of an 'AA blob' if you believe your opponent will use anti-flak instead of ground support.
You mentioned Combat Air Patrol in your changelist post. Will this be an air-air intercept mission or a general "loiter in the area of the battle and engage anything you see"?
One thing that seems a bit odd is assigning Fire control directors by ships. I would assume the ships all share their data, and any particular ship can cover almost half a hemisphere. If targets are spread out, a single director cannot provide targeting information for all of them, even if a 100kt battleship is standing ready. On the flipside, if a concentration of units is detected, a bunch of beam FACs should have no trouble firing at the same coordinates.
Quote from: Steve Walmsley link=topic=8497. msg110260#msg110260 date=1539107101Quote from: Person012345 link=topic=8497. msg110257#msg110257 date=1539105012Presumably they will average out the same, because the fighters will kill far more AA units when they attack the AA blob than when they attack dispersed AA. I'mnot necessarily saying it's how it works now (I'm not sure) but it's how it should end up working.
Yes, that is true. Also, you would want to protect your formations from ground support and search and destroy, not just anti-flak, so it doesn't necessarily make sense to concentrate the AA in one place (especially light AA). Plus, if you have heavy AA it doesn't matter where they are located as they can fire on any attacking aircraft. Having said all that, you do have the option of an 'AA blob' if you believe your opponent will use anti-flak instead of ground support.
You mentioned Combat Air Patrol in your changelist post. Will this be an air-air intercept mission or a general "loiter in the area of the battle and engage anything you see"?
I haven't written the code yet but at the moment my intention is for CAP to function in the same way as heavy AA - it will engage random hostile fighters.
Each Forward Fire Direction (FFD) component in a formation allows support from a single ship in orbit or up to six ground support fighters. If more ships and fighters are assigned to a formation than can be supported, the chance to hit is modified by:
Number of FFD / ((Fighters x 6) + Ships).
QuoteEach Forward Fire Direction (FFD) component in a formation allows support from a single ship in orbit or up to six ground support fighters. If more ships and fighters are assigned to a formation than can be supported, the chance to hit is modified by:
Number of FFD / ((Fighters x 6) + Ships).
This may have been mentioned before, but in the formula above for excess ships/fighters shouldn't it be Number of FFD / ((Fighters / 6) + Ships). Since 6 fighters is equal to one ship
That leaves the question open how counterbattery fire against STO works. The most effective phase for STO will likely be trying to down incoming transports, and against this you want to have fighters/warships that try to suppress the STOs.
A few further questions, how do beam weapons work on fighters? I assume they use ship bombardment rules, but benefit from STO immunity on mission like other fighters.
Missile interaction with ground troops and planets is also still lacking. Again for a landing it might make sense to employ them in a tactical role against STO in limited strikes.
Lastly, how do beam fighters fight other fighters on mission? Do they use regular combat, or is that translated to fighter bombardment back to anti-aircraft damage?
Can orbital bombardment also catch enemy fighters/aircraft? It does not make much sense that enemy fighters should be any less vulnerable in atmosphere if they are tracked by a FFD than they are in space.
I have some concerns that the FFD system greatly advantages a single large bombardment ship instead of using multiple smaller ships, but honestly I don't think it's a big deal. Besides, it's thematic to use the big battleships for bombardment while the smaller ships play escort.
I'd like to raise the concern that ground combat is getting out of control given that this is a space game and you still haven't gotten a complete version out.
Not trying to tell you your business, just wanted to specifically attract your attention to this in particular.
I thought a single ship could only be assigned one unit to support and as such only fire on one target each increment? If your massive battleship can overkill any target wouldn't several smaller ships be more effective instead?I interpreted it as firing at 1 formation. Otherwise any ship with multiple weapons is basically useless, very few ground units survive a shot from heavy beam weapons.
I interpreted it as firing at 1 formation. Otherwise any ship with multiple weapons is basically useless, very few ground units survive a shot from heavy beam weapons.
Can orbital bombardment also catch enemy fighters/aircraft? It does not make much sense that enemy fighters should be any less vulnerable in atmosphere if they are tracked by a FFD than they are in space.
So, Steve, the next update after C# will then include planetary naval forces? ;D
I did consider those for the ground combat, particularly submarines, but decided that was a step too far. For the moment anyway :)
I did consider those for the ground combat, particularly submarines, but decided that was a step too far. For the moment anyway :)
Submarines could be easily implemented by bringing back missile PDCs and saying that the extra defense layers are from water instead of rock...
*runs away*
Will npc ships still have the same maximum speed as those that still have fuel. In other words, fact that NPR ship is run out of fuel make him slower ?
I believe there should be a benefit to player to make enemy fleets run dry, besides their willingness to refuel.
Reduce their speed to 50-80% sounds to me like a compromise.
The orbital support looks good. Is there still a risk of collateral damage when you assign ships to orbital bombardment or does this come through more general bombardment much as in vb6.
Do multi turret weapons equate to multiple shots on the same target?
Also, with the increased use of maintenance it would be good to have some variable sized maintenance store components on top of the current 150 ton version.
I like that fortification decreases detection signature.
John
Current rules create an upper limit to how big a defense force you can stuff onto a planet though, one that grows smaller as technology improves because the sensors get better but not a ground unit's ability to hide. It turns forest, jungle, mountain and rift planets into even better defensive places and desert or ocean worlds into even more of a strategic liability.
Hum. That makes high HP units considerably tougher, which I think is probably a good change. One thing I was struck by with my own theorizing was that lots of light weapons were surprisingly effective against heavy units.
I'm interested to see how balance testing goes in the campaign.
I've been experimenting with the attack vs armour values, along the same lines as previously discussed, trying to balance the various weapons such as LAV vs HCAP. I finally realised the easiest way to handle this was to treat damage in the same way as penetration. If armour is penetrated, the damage calculation is now (weapon damage / hit points)^2. With both penetration and damage now using the same calculation, differentiation in weapons is much easier.
I've changed LAV to AP 2 Damage 3 and MAV to AP 4 Damage 4, to match the HPs of the respective light and medium vehicles.
I also adjusted light and medium bombardment weapons to AP 1 Dam 2 and AP 1.5 Dam 4 respectively.
I'll probably still adjust a little after campaign testing but i am much happier with it now.
This seems now quite harsh on the MAV compared to the HAV. Using MAV on static bases you get about 35% more units for same tonnage, meaning 35% more damage against medium armored targets. Against heavy targets you only deal one quarter of the damage of the heavy platforms, which sounds like a clear case to exclusively go for HAV.
This seems now quite harsh on the MAV compared to the HAV. Using MAV on static bases you get about 35% more units for same tonnage, meaning 35% more damage against medium armored targets. Against heavy targets you only deal one quarter of the damage of the heavy platforms, which sounds like a clear case to exclusively go for HAV.
If we assume academies train the local population then they shouldn't function on an uninhabited rock.
While it is easy enough to assume the students are performing all maintenance as part of the 'how to maintain a starship' curriculum, unless the academy consumes population when producing crew they really ought to have a worker requirement sufficiently large to represent a minimum sustainable applicant pool.
Quote from: sublight link=topic=8497. msg110542#msg110542 date=1540132059If we assume academies train the local population then they shouldn't function on an uninhabited rock.
While it is easy enough to assume the students are performing all maintenance as part of the 'how to maintain a starship' curriculum, unless the academy consumes population when producing crew they really ought to have a worker requirement sufficiently large to represent a minimum sustainable applicant pool.
I always assumed in my RP that the best of the best would travel across half the galaxy to train at Starfleet Academy or your local equivalent.
If there are alot of military state secrets being thought it could even be an advantage to have the academy on an otherwise uninhabited rock somewhere far from any large local population that could observe your fighter maneuvers or whatever your up to.
Compared to the other worker needs I don't think any significant amounts of population would be needed to run an Academy day to day, even if some probably would be needed for the logistics.
I wonder what made Steve change the efficiency of Conventional Industry? CI used to be decent enough on a conventional start, especially with multi-faction start on Earth, that it wasn't necessarily the best choice to just immediately convert all of it to factories and mines.
I wonder what made Steve change the efficiency of Conventional Industry? CI used to be decent enough on a conventional start, especially with multi-faction start on Earth, that it wasn't necessarily the best choice to just immediately convert all of it to factories and mines.
Total output is still the same (40% of an normal installation). However, now some of the output that went to ordnance, fighters and refineries goes to mining instead. The reason is that it occurred to that a conventional Empire could not build its starting installations without some form of mining capability.
In VB6 Aurora, Conventional Industry provides the same output as 0.1 construction factories, 0.1 ordnance factories, 0.1 fighter factories and 0.1 refineries
I wonder what made Steve change the efficiency of Conventional Industry? CI used to be decent enough on a conventional start, especially with multi-faction start on Earth, that it wasn't necessarily the best choice to just immediately convert all of it to factories and mines.
Total output is still the same (40% of an normal installation). However, now some of the output that went to ordnance, fighters and refineries goes to mining instead. The reason is that it occurred to that a conventional Empire could not build its starting installations without some form of mining capability.QuoteIn VB6 Aurora, Conventional Industry provides the same output as 0.1 construction factories, 0.1 ordnance factories, 0.1 fighter factories and 0.1 refineries
Is this right? I'm almost positive I remember getting some mining from CI in my pre-TNE games.
I wonder what made Steve change the efficiency of Conventional Industry? CI used to be decent enough on a conventional start, especially with multi-faction start on Earth, that it wasn't necessarily the best choice to just immediately convert all of it to factories and mines.
Total output is still the same (40% of an normal installation). However, now some of the output that went to ordnance, fighters and refineries goes to mining instead. The reason is that it occurred to that a conventional Empire could not build its starting installations without some form of mining capability.QuoteIn VB6 Aurora, Conventional Industry provides the same output as 0.1 construction factories, 0.1 ordnance factories, 0.1 fighter factories and 0.1 refineries
Is this right? I'm almost positive I remember getting some mining from CI in my pre-TNE games.
Hey Steve, it looks great. Super pumped for the test campaign. About how fast is it running compared to VB6 Aurora?
That bruce boxleitner picture always makes me want to dig out my box set...
House Fuchida is using a larger base formation, with the Japanese WW2 infantry battalion as a template. The individual Fuchida Infantryman is cheaper but less well protected than the Reichmann Panzergrenadier or the Aurelius Legionary.
(http://www.pentarch.org/steve/Screenshots/Panzergrenadier005.PNG)
Hey Steve, it looks great. Super pumped for the test campaign. About how fast is it running compared to VB6 Aurora?
Still not much going as I am still in the process of converting conventional factories. However, there are a dozen research projects, fifteen shipyard upgrades, all the commander experience, health, pop growth, orbital movement (including asteroids), all the detection phases, etc. Essentially the full construction phase for what is actually happening in this so-far limited game.
I am running 5-day increments and they are taking 0.17 seconds each, so definitely faster :)
It will be more interesting once there is shipping, civilians, multiple systems, etc.
Steve I think there may be a bug in the UI for the Fuchida screenshot. The bottom left UI panel is still showing data from the House Aurelius screenshot. There is no selection in the top left UI panel for selecting a unit type, so I think it is continuing to show the data from the previous selection instead of de-selecting or passing an empty view model to the lower left UI panel.
Other than that, these screens look great! Can't wait to see more.
Steve, could you please add female names into the Roman names database.
Quote from: Vroom link=topic=8497. msg110717#msg110717 date=1540884818Steve, could you please add female names into the Roman names database.
It's imposible :(. Weman has no personal name in Roman Empire/Republic. Only name of family.
For example: if family name is August, then daughter named Augusta.
If family has more than one daughters, then number should be added to name. Augusta I, Augusta II. . .
If mother also has name Augusta, then she becomes Augusta Senior and daughter name is Augusta Junior.
Regarding the changing colony cost of comets and planets with eccentric orbits.
I like the idea at first, but now i have some concerns depending the micromanaging overhead
and the additional game play value.
Depending on the orbit time, the population has to be moved to and away form the comet/planet constantly,
or only the minimum supported population at maximum colony cost is send to the comet/planet.
Will the maximum colony cost be shown?
Will shipping lines use the current or the maximum colony cost for sending colony ships?
What is the benefit of constant moving population over only moving the minimum population.
It is likely that with planets with sufficiently eccentric orbits to be automatic colonisation candidates that only need a seed population for civilian shipping to move populations into position. If that happens and the planet becomes sufficiently cold or hot to need infrastructure to compensate for the colony cost that will be very... unfortunate. Will it be possible to tick a box for planets like that for the colonisation and infrastructure demand calculations to consider the max colony cost instead of the current colony cost?
I understand the concerns about agility and I will do something to address it. I rarely reach AM levels in my games so it hasn't been on my radar as much as it should have. I think I may need a different mechanic to replace agility but haven't decided how to handle it. I will also look at EW for missiles.
Plus, once I start running a campaign I will see how the theory works in practice. If there are problem, I will change it.
The great win we're all looking forward to in Aurora is the C# speed-up. This gain makes certain other wins possible, and I'd like to suggest one of them: Removing the 5-second minimum combat time step, or "pulse".Could much of that not be achieved by allowing weapons to fire possible multiple times per pulse? If you have a reload of 4 seconds, you fire twice 2 first pulse, once second... all you have to track is a single number how much you are reloaded.
A lot happens in five seconds. Weapons charge up, wait, and only fire at the end of the interval. Beam weapon design is made considerably less flexible, with key tech advances being those that allow weapons to finish charging every 5*n seconds. Fast missiles teleport from medium range to hull contact in one jump, which again limits the design of non-CIWS missile defences.
I propose that the game move to a one-second (or smaller) sub-interval - a "pulse" - for combat, and that pulse occur sequentially, system-by-system (this could obviously be multithreaded) in which there is active combat, during each interval. These intervals could (if desired) remain as they are, with a 5 second interval continuing to be the minimum.
yeah but allowing beam weapons to fire more than once in a 5 second increment shouldn't be too hard, and will essentially be the same thingYou should try and program that and see, how many problems occour, when you change "one simple system" ;-)
Yes, if the shortest pulse is brought down to 1 second, then Steve has to code in tracking of beams moving second by second. If such a system is devised, then the max range of beam weapons becomes unlimited as well and the whole space combat metagame will drastically change. It would be a huge change, and probably not something that should even be attempted at the initial C# launch.
- Missiles launching and impacting before AMMs can detect and launch
I fail to see how it would increase the max range of beam weapons, let alone making it infinite.If Steve would keep the actual game mechanics and switch to 1 sec impulses, that would limit beam weapons to a max range of 300.000km (How far light could travel within 1 second). Through the 5 second impulse beam weapons can go up to a max range of 1.500.000km (5 seconds of lightspeed).
You say Steve would have to code tracking second by second, but wouldn't it be the same code that allows to track 5 seconds by 5 seconds?. I don't really understand how 1 sec is that different from 5 secs. It's just an amount of time, only smaller, and therefore allows for more granularity in movement, reload rates, combat, etc, etc. Yes, it would change the metagame, and that's precisely the point.
Quote from: Garfunkel link=topic=8497. msg111075#msg111075 date=1542588551Yes, if the shortest pulse is brought down to 1 second, then Steve has to code in tracking of beams moving second by second. If such a system is devised, then the max range of beam weapons becomes unlimited as well and the whole space combat metagame will drastically change. It would be a huge change, and probably not something that should even be attempted at the initial C# launch.
I fail to see how it would increase the max range of beam weapons, let alone making it infinite.
You say Steve would have to code tracking second by second, but wouldn't it be the same code that allows to track 5 seconds by 5 seconds?. I don't really understand how 1 sec is that different from 5 secs. It's just an amount of time, only smaller, and therefore allows for more granularity in movement, reload rates, combat, etc, etc. Yes, it would change the metagame, and that's precisely the point.
- Missiles launching and impacting before AMMs can detect and launch
This is no longer an issue in C# Aurora. Missiles are detected at launch (outside the normal detection sequence).
Range of Beam-Weapons (all non-Missile): This is mostly a balance issue and to make a meaningful choice between Beam-Weapons and Missiles .
You can't stop Beam-Weapons and Beam-Weapons have a lower logistic overhead.
If Beam-Weapons have a range comparable to missiles there would be no use for missiles.
There is a convenient limit (Min time increment) x (Speed of Light) to give a reason for the range limitation.
FTL Beam-Weapons would remove this convinient limit without giving a new limit
[/li]
[/list]
but wouldn't it be the same code that allows to track 5 seconds by 5 seconds?. I don't really understand how 1 sec is that different from 5 secs.it's because currently beam weapons are not tracked at all. So when the target is inside the range of the beam weapon, it is aimed and fired and the hit chance is rolled for and the damage is calculated and applied all in that one 5-second pulse. So going to 1 second shortest time pulse means that either:
Range of Beam-Weapons (all non-Missile): This is mostly a balance issue and to make a meaningful choice between Beam-Weapons and Missiles .
You can't stop Beam-Weapons and Beam-Weapons have a lower logistic overhead.
If Beam-Weapons have a range comparable to missiles there would be no use for missiles.
There is a convenient limit (Min time increment) x (Speed of Light) to give a reason for the range limitation.
FTL Beam-Weapons would remove this convinient limit without giving a new limit
[/li]
[/list]
Yes, this is exactly why the limit applies. If beam weapon range increases, they become too powerful and the 5-second limit is convenient technobabble. Currently, longer-range beams can be closed down by faster ships within a reasonable time. If the range noticeably increases, longer-range beams win regardless of speed.
Faster ships with longer-ranged beams win in either case.
yeah but allowing beam weapons to fire more than once in a 5 second increment shouldn't be too hard, and will essentially be the same thingYou should try and program that and see, how many problems occour, when you change "one simple system" ;-)
Except you can't react to it because it travels at light speed. You can't see the shot until it has already hit you.I fail to see how it would increase the max range of beam weapons, let alone making it infinite.If Steve would keep the actual game mechanics and switch to 1 sec impulses, that would limit beam weapons to a max range of 300.000km (How far light could travel within 1 second). Through the 5 second impulse beam weapons can go up to a max range of 1.500.000km (5 seconds of lightspeed).
You say Steve would have to code tracking second by second, but wouldn't it be the same code that allows to track 5 seconds by 5 seconds?. I don't really understand how 1 sec is that different from 5 secs. It's just an amount of time, only smaller, and therefore allows for more granularity in movement, reload rates, combat, etc, etc. Yes, it would change the metagame, and that's precisely the point.
In order to change that, Steve would have to create beam-objects that the game can track through time. Basically missiles which can only go one speed (lightspeed), don't have a "follow-target-mechanism", have different patterns of damage and cannot be engaged by AMMs. It would also mean a rewrite of hit chances of the beam weapons. If you for example shoot at a target that is 25 light seconds away - a simple evasion of one ship length would lead to missing the target - and 25 seconds to react to such a shot is reasonable within a sci-fy setting. But how would you calculate that ingame?
tobijon,
Go back and look at the posts for today. Tmaekler post was an accurate quote of what you posted Today at 03:55:47 AM. I am not sure why you are upset.
Sorry for you feeling misquoted. I intended no harm.yeah but allowing beam weapons to fire more than once in a 5 second increment shouldn't be too hard, and will essentially be the same thingYou should try and program that and see, how many problems occour, when you change "one simple system" ;-)
don't put things in quotation marks when I haven't said them, there is a reason I'm not arguing for one-second increments but the much easier to code multiple firing per increment
Except you can't react to it because it travels at light speed. You can't see the shot until it has already hit you.Tell that the instant TN sensors :D
Meaning you should be already be able to dodge, again there is nothing special about 5 seconds...Except you can't react to it because it travels at light speed. You can't see the shot until it has already hit you.Tell that the instant TN sensors :D
tobijon
Chief Petty Officer
T
Posts: 31
Thanked: 2 times
Re: C# Aurora Changes Discussion
« Reply #1927 on: Yesterday at 03:55:47 AM »
Say Thanks Quote
yeah but allowing beam weapons to fire more than once in a 5 second increment shouldn't be too hard, and will essentially be the same thing
Report to moderator Logged
The following users thanked this post: Agoelia
Above is a copy of post 1927 on page 129 of this thread.
Sloanjh or Erik,
I am concerned that apparently different users are seeing different posts, especially as it is causing hurt feelings.
Is there a way to determine why only some users see this post?
Maximum Wealth Balance
In Conventional Start games, races often build up a huge wealth reserve due to a lack of costs. This removes wealth as a consideration for many years and takes away meaningful decisions.
Therefore, in C# Aurora, a race's wealth balance can never exceed double the annual wealth. Any excess beyond that is assumed to be spent on improving the lives of its citizens.
Note, having 200 units total of xenoarcheology components does not equate to a 100% chance. It's approximately equal to ((1/72)^72)% chance of failing if I remember my math right. So pretty much zero, but not actually being zero you can just end up rolling really, really poorly.
I don't want to add more uses for wealth as that could disrupt the current balance, so a cap is a simple solution that doesn't disrupt anything.
The other option I considered was having wealth tied to TN, so that wealth was multiplied by (Starting Conventional Factories - Current Conventional Factories) / Starting Conventional Factories, but that could have other consequences I can't foresee at the moment.
I would go for a solution were the Conventional Factories are using wealth to a point were most (but not all) of the wealth is used up at the beginning...
The Conv->TN Wealth bloom seems to be coming from the low production efficiency of Conventional Industry (1/10th CF, 1/10th Mine, 1/20th Fuel Refinery, etc.) when Wealth costs are still based on output. If 50,000 workers generate 10 Wealth, but only mine 1 ton of TNE (and thus spend only 1 Wealth) due to the inefficiency of Conventional Industry, they generate 900% profits.
To me, it seems the solution is to charge Conventional Industry five-to-ten times the Wealth per ton of TNE mined, or constructed, or refined. Pre-TNE empires would no longer be generating such enormous wealth in the first place, and wouldn't need their treasuries capped.
I have some questions about how overhaul abandonment works. It makes no sense to me that a ship which is, say, a week away from finishing up an overhaul would be essentially crippled for at least two or three weeks if I choose to close it up early. The easiest way to solve this would be to have ships that are less than a month away from completing the overhaul simply start with an overhaul factor equal to the proportion of the last month of overhaul that they had completed. By that point, they should have most of the major issues dealt with anyway.
Also, how do ships in overhaul behave when shot at? I know you can't give movement orders, but are they totally crippled, or will you accidentally handicap yourself when you abandon an overhaul upon the arrival of the bad guys?
There is a difference between a ship completing an overhaul at maintenance facilities and a ship being put back together while underway. While I agree that a ship close to completing an overhaul is probably in a better situation than one half way through, I don't want to complicate a rule that is simple to understand and implement. You still have the option of waiting instead of abandoning if close to completion.Granted there's a difference in closing up, but at the same time, there's also a huge difference between a ship who will be out of yard in a week and one who is going to be there for the next six months. It's a change I'd like, but I can definitely see why you wouldn't want to implement it.
Ships in overhaul are stationary and the to-hit chance will reflect that.But I ship I just pulled out of overhaul is also stationary, and it has no shields or guns. A ship in overhaul has both, as far as I understand it.
There is a difference between a ship completing an overhaul at maintenance facilities and a ship being put back together while underway. While I agree that a ship close to completing an overhaul is probably in a better situation than one half way through, I don't want to complicate a rule that is simple to understand and implement. You still have the option of waiting instead of abandoning if close to completion.Granted there's a difference in closing up, but at the same time, there's also a huge difference between a ship who will be out of yard in a week and one who is going to be there for the next six months. It's a change I'd like, but I can definitely see why you wouldn't want to implement it.QuoteShips in overhaul are stationary and the to-hit chance will reflect that.But I ship I just pulled out of overhaul is also stationary, and it has no shields or guns. A ship in overhaul has both, as far as I understand it.
The wealth cap is fine for a stopgap solution for the sake of getting C# Aurora tested and released. For a longer term solution, we need to define exactly what wealth *is*I agree with this sentiment. I think that in the long run, a deeper economic model would be better, tracking the economic prosperity of individual colonies or populations, tracking TN minerals that exist in the civilian economy (possibly as a trade good only produced by mines(and possibly allowing the player to sell minerals to the civilian economy, to allow for something like a fully nationalised TN mining sector)), and offering the player a greater range of options in regards to how their economy operates.
As Ground Combat turns are 6 hours long and Naval Combat turns can be as short as 5 seconds, this means that a weapon in general/naval unit bombardment with a 5 second reload can fire 4 320 times during a single ground combat turn.
It would hit the wrong target some 1 450 times in that time, which is really inconvenient when you are trying to hit ground units instead of just doing a planetary destruction bombardment, but it's a thing. It would seem to me that the ground combat timescale or the undirected naval bombardment timescale need to be reconsidered.
Oh, speaking of dust level? Will size of the planet affect the impact of the dust level? It doesn't in VB6 but that's not really a problem because the atmospheric terraforming mechanics don't care about planet size. But in C# planet size does affect atmospheric terraforming. This should probably also be a thing for planetary radiation levels.
As Ground Combat turns are 6 hours long and Naval Combat turns can be as short as 5 seconds, this means that a weapon in general/naval unit bombardment with a 5 second reload can fire 4 320 times during a single ground combat turn.
It would hit the wrong target some 1 450 times in that time, which is really inconvenient when you are trying to hit ground units instead of just doing a planetary destruction bombardment, but it's a thing. It would seem to me that the ground combat timescale or the undirected naval bombardment timescale need to be reconsidered.
C# ground combat is every 3 hours, while in VB6 is it every 5 days. Naval combat is the same in both cases, so the difference has already been reduced quite a lot. However, just as in real life, there is a difference between providing fire as needed to support relatively slow ground advances and simply blasting a whole area. It is like artillery support vs carpet bombing. The difference in Aurora vs real life is that for energy weapons there is no ammunition so you can constantly carpet bomb. That is why I introduced the rules on weapon failure and the rules on dust creation for energy weapon fire.
For example, you could fire a 5-second weapon (lets assume a 10cm laser costing 20 BP) 2160 times in 3 hours, which will cause a dust level of 324 and suffer 43 weapon failures at a cost of 860 MSP. If you are firing at fully fortified infantry, you will kill about 24 of them. You will kill far fewer on a planet with rough terrain. That is also assuming the planet isn't defended with Surface-To-Orbit weapons, so you are free to carry out the bombardment.
If you do decide to go ahead, then you are going to be hitting the installations and population because that is where the infantry is likely to be. Blasting fortified defenders out of a city is not usually pleasant for the city - its meant to be inconvenient. To shift determined infantry, you will likely need to send in your own or use nuclear bombardment and accept the massive collateral damage (assuming the point defence STOs don't shoot down the missiles).
The simple fact is that ground combat and naval combat operate on different timescales. Even when naval units provide support to ground forces in real life, that is not a constant barrage but usually to eliminate particular strong points. That is what the Orbital Bombardment Support is intended to simulate. If you want to forget ground combat and try to smash the defenders from orbit, you can operate on naval timescales because you don't have to wait for the ground forces. However, you have to accept that digging out the defenders by applying massive firepower is going to cause equally massive collateral damage.
Note that if you do engage identified STO units (because they fired at you), the chance to hit will be much higher because you know exactly where they are. It will 100% base instead of 6.7%, although still subject to terrain and defender fortification. That will all take place on naval timescales (like ships attacking a shore battery). I will cover that situation in a different rules post. Plus, all of this is subject to play test and may change as a result.
That is a very good point which I hadn't considered. I wonder if radiation is affected in the same way (is it 'diluted' on large planets)? Fortunately, two of the people I recruited for my department at work are nuclear physicists who spent time in Chernobyl and Fukushima, so I will ask :)
The key question in my mind here is: Is there ever going to be a point in going through the extra effort to try and invade a military only target using land forces? How do the chances look to be able to capture the installations intact.
I have a similar question about overall combat duration of ground combat turns: If you have a 6h per turn, base 20% per hit chance.
If you assume units can kill each other when hit, that means after 30h the formations caused 100% casualties. If you assume 2% kill chance from fortification/units surviving hits, you end up at 12.5 days until you reach 100% casualties.
That is nowhere near the time scale a rescue fleet could arrive, or you could bring reserves. I feel what is missing is a mechanic that gives you varying combat intensity. Ground combat usually happens in offensives, followed by periods of reorganization and stabilization where troops are sitting in place and not fighting much.
That is a very good point which I hadn't considered. I wonder if radiation is affected in the same way (is it 'diluted' on large planets)? Fortunately, two of the people I recruited for my department at work are nuclear physicists who spent time in Chernobyl and Fukushima, so I will ask :)
I have a similar question about overall combat duration of ground combat turns: If you have a 6h per turn, base 20% per hit chance.
If you assume units can kill each other when hit, that means after 30h the formations caused 100% casualties. If you assume 2% kill chance from fortification/units surviving hits, you end up at 12.5 days until you reach 100% casualties.
That is nowhere near the time scale a rescue fleet could arrive, or you could bring reserves. I feel what is missing is a mechanic that gives you varying combat intensity. Ground combat usually happens in offensives, followed by periods of reorganization and stabilization where troops are sitting in place and not fighting much.
I suspected something like that on reading it. As long as failure chance and collateral damage is sufficiently high, and STO weapons sufficiently effective I don't think the different timescales cause a major problem either.
The only situation I can think of where it might be causing balancing issues is in the case of military only targets, like forward bases that lack civilian support or resources of value ( basically an attacker don't care about collateral damage ). But this is probable just a situation where strategy and doctrine needs to adapt such that military targets are defended by sufficient amounts of STO weapons and/or space weapons.
The key question in my mind here is: Is there ever going to be a point in going through the extra effort to try and invade a military only target using land forces? How do the chances look to be able to capture the installations intact.
I have a similar question about overall combat duration of ground combat turns: If you have a 6h per turn, base 20% per hit chance.
If you assume units can kill each other when hit, that means after 30h the formations caused 100% casualties. If you assume 2% kill chance from fortification/units surviving hits, you end up at 12.5 days until you reach 100% casualties.
That is nowhere near the time scale a rescue fleet could arrive, or you could bring reserves. I feel what is missing is a mechanic that gives you varying combat intensity. Ground combat usually happens in offensives, followed by periods of reorganization and stabilization where troops are sitting in place and not fighting much.
With one post arguing ground combat takes too long and another arguing it doesn't take long enough, I must be somewhere in the ball park :)
The are two considerations that will slow it down. Firstly, when you run out of supply, you only attack at 1/4 normal and with longer engagements, the combatants will run out of supply. I might even reduce the 25% rate depending on play test. When new supplies arrive, that simulates an offensive. The defender could hoard supplies when the attacker is out of supplies to await such an 'offensive', or take advantage while it has supplies and the other side doesn't (counter-attack).
The second consideration is that your combat example only lasts 12.5 days if one side doesn't take casualties at all (also assuming the 2% is accurate and no one runs out of supplies). With both sides taking casualties, it reduces each sides ability to harm the other so it will take a lot longer than 12.5 days if the sides are relatively even.
If one side has a large superiority and the terrain is favourable (Desert Storm), then it could be over relatively quickly. If the planet is jungle mountain and you are attacking fully fortified infantry or static weapons, that 20% chance to hit is now 0.14% (plus you have to penetrate armour and kill them). You are going to be there for months or even years and you will run out of supply at some point as well, which will slow it down even more. Plus, given the long time frame, both sides probably will reinforce.
With the variety of terrain, supply constraints and the scope for many different situations, we should have some relatively fast ground combat and some that will require many years to resolve.
The key question in my mind here is: Is there ever going to be a point in going through the extra effort to try and invade a military only target using land forces? How do the chances look to be able to capture the installations intact.
Yes, this is my main concern as well in terms of balance. I've tried to make that possible by having minimal collateral damage if you use relatively low level forces (infantry rather than heavy artillery) but I will monitor in play test and adjust that collateral damage accordingly. I considered an option for each side to accept a penalty in in general effectiveness if they wish to reduce collateral damage. Something on the lines of heavier weapons firing less frequently to simulate more careful target selection, but you can effectively do that already by moving those heavier weapons into rear echelon or not assigning artillery to support, so I probably won't bother.
"Just bombarding an installation from space should take much longer than invading it in general, sure allot of stuff will be destroyed from bombardment but you should be able to repair given enough time after such bombardment if the place is not invaded and left to recover."
Fallout is primarily created by dirt and debris being lofted into the fireball, it doesn't come from the bomb itself. Airbursts disperse minimal fallout in real life. So I would think they should not cause much fallout. Although if you're nuking futuristic fortifications, maybe you're using ground bursts?
Nuclear bombs in Aurora are likely to be fairly high altitude detonations so the fall out would be spread over a large area, and with enough nukes in a general bombardment you'll end up with a roughly equal distribution in any relevant areas anyway.
A genocidial race would just vaporize it all with nuclear bombardment, thought. And worry about the mess later.
Not sure I can follow you there... bombarding a target to dust is really quick and cheap... especially with the kind of weapons we are talking about... fighting on the ground takes much much longer...That depends entirely on the nature of the target and the weapons.
to bomb the whole of Japan back into stone age 1945 would "just" have needed days/weeks (if the US would have the number of bombs available which they did not - but in C# the attacker would have within his fleet)) but an invasion of the Japanese main islands would have resulted in fighting for a year minimum and would have been really expensive in terms of deaths and equipment...
bombarding - especially with nuclear missiles - should be really quick, really dirty and really devastating... but destroying a target from orbit should for sure be much more quickly than successfully invading it against opposition
I thought a power 1 blast was equal to a megaton? I could be off but that was my vague understanding.
I'm pretty sure that one point of damage in the game are not that powerful. A simple Gauss cannon does one point of damage and a ship with no armour will take a fair amount of damage before it is destroyed.
On the other side should a conventional missile - as started with in a non-tn-start and with silos - be a equivalent of today's atomic intercontinental missiles with more than 100 megaton each...They don't have hundreds of megaton each.
On the other side should a conventional missile - as started with in a non-tn-start and with silos - be a equivalent of today's atomic intercontinental missiles with more than 100 megaton each... so 100-200 should be plenty to destroy 98% of earths industry in a single strike and make the planet lifeless...I think you made a little typo there, meaning to write kilotons instead of megatons. Otherwise, as Scandinavian already posted, you're badly mistaken regarding modern nukes. And while 100 ICBMs launched simultaneously in Aurora are enough to make Earth lifeless - for a short while - that isn't true in real life at all, and it's not clear from your post which case you're talking about.
Hey Steve, are you planning to permit the C# Aurora to have a toggle to "black text on Windows XP Luna" color scheme for it's UI? It's an aesthetic i very strongly associate with Aurora at this point, and one I've grown very fond of, and additionally feels a bit more readable than the aurora progress report screenshot colors we've been seeing.
Frankly, the numbers for orbital bombardment seem off. I guess the intention seems to be nukes are quick and dirty, energy is clean but requires many breakdowns.Energy weapons do not cause radiation, so the environmental impact is less long-term. And energy weapons can be used for ground support fire, which has much lower collateral damage per kill and which it is my understanding that missiles cannot participate in. Also, you're assuming that we're killing very basic infantry. Once the infantry's armor rating gets a few tech upgrades, the number of effective missile attacks cuts down from 15 to 7-9 (because the 1 damage attacks tend to bounce off). If you're shooting at infantry with anti-vehicle weapons or crew-served anti-infantry, the nuke's 10 sub-attacks becomes more like 2 or 3. And if you're shooting at even light vehicles with a few tech upgrades to their armor, the nuke starts kicking up more dust than the beam per actual kill.
However, if you take the 8 dmg warhead, it generates 8 dust. To do the equivalent amount of damage, you need 5 times more shots for chance to hit, 15 times more for missing attacks, 10 times more for missing subattacks (against infantry),
for a total of 750! shots which generates 37.5 dust, something like 4.5 times more.
Am I missing something, or energy weapons are just all around worse than nukes?
So, on average, about how big is an NPR's ground army going to be? Are we talking maybe a couple dozen battalions/brigades/divisions?
So, on average, about how big is an NPR's ground army going to be? Are we talking maybe a couple dozen battalions/brigades/divisions?
Potentially, fairly big.
(from another thread) The NPR in my test game is currently defending its home world with 48x turret-mounted twin 10cm lasers and 84x 25cm lasers, plus 24,000 infantry (plus supporting CAP, AT, etc.), 800 medium tanks, 800 Light AA Teams, 200 AA tanks, 360 towed artillery, etc.. The total transport size of the current home world ground forces is 555,000 tons (111 large transport bays). It has deployed formations each with 14x 25cm lasers and 8x twin turrets to two minor colony worlds, plus more supporting ground forces. It is also currently building more STO units than it has already deployed.
It sounds doable. Once you've eliminated their deep space fleet, you need to contend with about 200 laser beams of varying sizes. To have parity in weight of fire, you need somewhere between fifty and a hundred 5,000 ton laser destroyers. (You'll have lower to-hit chance due to terrain and fortification, but each hit will kill a STO platform, while they will need a dozen or so hits to kill one of your destroyers. So you should come out ahead, though you'll want more than the minimum number of ships to keep losses at an acceptable level.) Assuming the enemy production rate is on the order of years to double the size of their ground forces, not months, you'd need maybe 20 transports with two large troop bays each (200 thousand tons of troop lift) and a million or two tons of ground forces that you can spare for an invasion, provided their home system have local system bodies within a few days' burn that you can use as staging areas.So, on average, about how big is an NPR's ground army going to be? Are we talking maybe a couple dozen battalions/brigades/divisions?
Potentially, fairly big.
(from another thread) The NPR in my test game is currently defending its home world with 48x turret-mounted twin 10cm lasers and 84x 25cm lasers, plus 24,000 infantry (plus supporting CAP, AT, etc.), 800 medium tanks, 800 Light AA Teams, 200 AA tanks, 360 towed artillery, etc.. The total transport size of the current home world ground forces is 555,000 tons (111 large transport bays). It has deployed formations each with 14x 25cm lasers and 8x twin turrets to two minor colony worlds, plus more supporting ground forces. It is also currently building more STO units than it has already deployed.
Yeah, I don't think that's going down without a massive tech disparity or glassing it with missiles.
So the question is, how long would it take to build up such a force in the first place?
It sounds doable. Once you've eliminated their deep space fleet, you need to contend with about 200 laser beams of varying sizes. To have parity in weight of fire, you need somewhere between fifty and a hundred 5,000 ton laser destroyers. (You'll have lower to-hit chance due to terrain and fortification, but each hit will kill a STO platform, while they will need a dozen or so hits to kill one of your destroyers. So you should come out ahead, though you'll want more than the minimum number of ships to keep losses at an acceptable level.) Assuming the enemy production rate is on the order of years to double the size of their ground forces, not months, you'd need maybe 20 transports with two large troop bays each (200 thousand tons of troop lift) and a million or two tons of ground forces that you can spare for an invasion, provided their home system have local system bodies within a few days' burn that you can use as staging areas.
None of those numbers seem prima facie impossible to me. Expensive, yes, but considering that you will essentially double your empire's production capacity once this homeworld is fully integrated in your greater co-prosperity sphere, it probably should be.
Still a pertinent question to ask- if a homeworld can produce such prodigious defenses that's fine and dandy, but how does that stack up in comparison to other military assets? If you can train and equip a hundred ground-based lasers in half the time it takes to build an orbital defense platform that carries ten, the numbers may need some tweaking.
Steve, I see that misses are not armoured now. But how should I proceed my size torpedos from one single amm or one shot from pd? Is there a point in really big misses now?
The new rules on EW & Sensors for missiles will make smaller missiles less effective.
The new rules on EW & Sensors for missiles will make smaller missiles less effective.
Ok, this is good to know. But anyway, is it a good idea to remove this functionality? I really liked to make extremely expensive huge cruise missiles, now they are not viable as can be shot down by one hit :(
The change to shock damage seems like a huge buff to bigger ships, in a version that's already full of smaller ones. It's not gamebreaking or anything, but I can't help but feel the meta in C# is going to be "have a few huge ships and no escorts".
It is true that larger ships have been generally increased in power vs smaller ones, but there are so many different roles in Aurora that it makes sense to have a variety of different sizes and types of ships. There are some potential pitfalls for very large ships as well, such as the magazine changes. Ultimately, though shock damage becomes increasingly overpowered as tech increases, so this is an effort to scale it with size and tech. The original intention for shock damage was to improve large missile warheads vs small ones (AMM spam), which the new rule still does with the 5% minimum.
About the meson change, is there no caliber dependence now? Unless there is, I still see little reason to use anything but the 10cm
I think that will still be underwhelming compared to all other tech lines, which get more damage over their effective range.About the meson change, is there no caliber dependence now? Unless there is, I still see little reason to use anything but the 10cm
Calibre has the same effect as VB6 and increases range. I did also consider having larger calibres generates more damage points, each of which would try to penetrate armour independently.
The change to shock damage seems like a huge buff to bigger ships, in a version that's already full of smaller ones. It's not gamebreaking or anything, but I can't help but feel the meta in C# is going to be "have a few huge ships and no escorts".
Steve, about your proposed meson change, it does not change the 2 concerns you had initially: they can still do pretty well in ground battle, and they can still engage small lightly armored orbital drop ships relatively easily. But the anti-capital ship capability of meson cannons now become not relevant.
Microwaves do extra damage to shields, while they're not intended as anti-shield weapons, this does help to break through shields so they can be effective, what about a similar mechanic for mesons?
Thick armour negates most hits of mesons, but perhaps they could do enhanced damage to armour while still doing single points against internals? Maybe affected by calibre, higher calibre doing 2 or 3 damage to armour, making mesons a superiour sandpapering weapon, or perhaps just higher calibre helping to penetrate more armour layers, lower chance of hitting each layer of armour?
Although only infantry units may participate in a boarding attempt, are non-infantry units capable of acting at all during boarding combat if a troop transport gets targeted for boarding?
Although only infantry units may participate in a boarding attempt, are non-infantry units capable of acting at all during boarding combat if a troop transport gets targeted for boarding?
They really would be unlucky - survive the boarding and realise you landed on a troop transport. :)
Theoretically, only infantry would take part. You can't really drive a tank along the corridors :)
Although only infantry units may participate in a boarding attempt, are non-infantry units capable of acting at all during boarding combat if a troop transport gets targeted for boarding?
They really would be unlucky - survive the boarding and realise you landed on a troop transport. :)
Theoretically, only infantry would take part. You can't really drive a tank along the corridors :)
No, you can't drive a tank or fire artillery, but the tank drivers, commanders, and gun loaders/operators would likely have side-arms and would be a lot more capable of resistance than civilian passengers or crew.
Kurt
One question regarding boarding combat: The defending ship will very likely be damaged to some extend, which means any troop bays may well have been damaged. Does this kill all the marines?
Logically any marines would be spread about the ship on combat stations, and should not be taken out by a single hit.
Although only infantry units may participate in a boarding attempt, are non-infantry units capable of acting at all during boarding combat if a troop transport gets targeted for boarding?
They really would be unlucky - survive the boarding and realise you landed on a troop transport. :)
Theoretically, only infantry would take part. You can't really drive a tank along the corridors :)
Good point. Normally, a hit on a transport bay would cause casualties so I have coded an exception for the case where the damage is caused by collateral damage from boarding combat.
Sure, but any members of the boarding party that enter the transport bays are probably going to get flattened by the concentrated firepower and lack a response.For lighter weapons, possibly, but then we get into the same trouble as with vehicle crew - you can probably unmount the machine gun from a technical relatively easily, but the integrated coaxial machine gun on a battle tank's turret... not so much.
One question regarding boarding combat: The defending ship will very likely be damaged to some extend, which means any troop bays may well have been damaged. Does this kill all the marines?
Logically any marines would be spread about the ship on combat stations, and should not be taken out by a single hit.
Good point. Normally, a hit on a transport bay would cause casualties so I have coded an exception for the case where the damage is caused by collateral damage from boarding combat.
The integrated coaxial machine gun can actually be taken out in just a few minutes and operated manually, albeit in an awkward fashion. At least they can in Russian tanks, I don't have hands-on experience with Western tanks. But that's nitpicking, your point is valid. And I fully agree that while it would be damn cool to have a Kelly's Heroes moment of tank-fighting inside a huge troop ship, in our reality, transports - both sea and air - are loaded to the gills and vehicles (and heavy weapons if static) are impossible to move or turn around.Sure, but any members of the boarding party that enter the transport bays are probably going to get flattened by the concentrated firepower and lack a response.For lighter weapons, possibly, but then we get into the same trouble as with vehicle crew - you can probably unmount the machine gun from a technical relatively easily, but the integrated coaxial machine gun on a battle tank's turret... not so much.
For the heavier weapons, there's no reason to think that vehicles are transported with weapons loaded, or even with their ammunition in the same place as the vehicle body. And certainly not facing the right direction, or easily able to reorient themselves. Even if they were, there's no reason to think you'd want to fire one in a confined space like a starship interior.
For example, you can give your space marines (infantry) heavier weapons (crew-served anti-personnel etc) in addition to personal weapons. I know I'm going to want to re-create some of the insane boarding combats from John Ringo's and Ian Douglas' books.
True, although I don't want to get into the detail of how many crew per vehicle, gun, etc. This is such an edge case though, it probably isn't worth coding anything detailed. Even if I just add 1 'driver' for a light vehicle, 2 for medium, 3 for large, etc and create a formation from them, I will then have to figure out how casualties affect the vehicles. I think for the sake of (relative) simplicity, non-infantry can't fight on ships.Could you abstract it by adding to the "effective crew" count of the ship based on something dead simple, like tonnage? I'm not very familiar with these mechanics, so apologies if it's a silly suggestion.
True, although I don't want to get into the detail of how many crew per vehicle, gun, etc. This is such an edge case though, it probably isn't worth coding anything detailed. Even if I just add 1 'driver' for a light vehicle, 2 for medium, 3 for large, etc and create a formation from them, I will then have to figure out how casualties affect the vehicles. I think for the sake of (relative) simplicity, non-infantry can't fight on ships.Could you abstract it by adding to the "effective crew" count of the ship based on something dead simple, like tonnage? I'm not very familiar with these mechanics, so apologies if it's a silly suggestion.
Yes, I could do something on those lines. However, if any of those vehicle crews are killed, what happens to the vehicles?
I do think that boarding shouldn't instantly remove a ship from the fight, but I can't help but think five minutes per increment is too long, especially without any mechanic that diminishes a ship's fighting ability while it's being boarded if the attackers have overwhelming force.
I do think that boarding shouldn't instantly remove a ship from the fight, but I can't help but think five minutes per increment is too long, especially without any mechanic that diminishes a ship's fighting ability while it's being boarded if the attackers have overwhelming force.
hmm.. good point...
maybe if a ship get's boarded it could get to "abandoned an overhaul-like status" which just reduces the reload-time of weapons (I guess the order "all hands prepare to repell boarders" from the ship captain MIGHT reduce the ROF a tiny little bit indead...)
Quote from: King-Salomon link=topic=8497. msg111791#msg111791 date=1546246997Quote from: Bremen link=topic=8497. msg111788#msg111788 date=1546233445I do think that boarding shouldn't instantly remove a ship from the fight, but I can't help but think five minutes per increment is too long, especially without any mechanic that diminishes a ship's fighting ability while it's being boarded if the attackers have overwhelming force.
hmm. . good point. . .
maybe if a ship get's boarded it could get to "abandoned an overhaul-like status" which just reduces the reload-time of weapons (I guess the order "all hands prepare to repell boarders" from the ship captain MIGHT reduce the ROF a tiny little bit indead. . . )
Yes, I think something on those lines is probably worthwhile. The degree of impact would depend on the weight of boarders vs defenders. I am not at home at the moment but I will take a look later.
An all or nothing approach, or converting part of the crew to a military unit for boarding combat purposes and the remainder becoming the prize crew until they get interned at some colony or another where local crew are let on board to take over would work best I think without massively complicating boarding combat.
You don't want to decide at design time on how much crew is getting converted. Frankly, given how rare boarding combat already is, and how even more rare boarding combat against units that are still well functioning is, I would not spend too much time on this.An all or nothing approach, or converting part of the crew to a military unit for boarding combat purposes and the remainder becoming the prize crew until they get interned at some colony or another where local crew are let on board to take over would work best I think without massively complicating boarding combat.
I think this could be a reasonable approach. Convert say, 75% of the ship crew immediately to the light infantry troops, the ship suffers the undercrewed penalty until combat is resolved and they revert, and if the ship is captured, they become the prize crew and represent those that surrendered or were incapacitated in the boarding attack. If the defenders are repulsed successfully, convert them back as normal and you only suffer the undercrew penalty for the casualties from that point forward.
If you wanted to get even fancier, you could make the base percentage of defensive crew lower, and add an armory module to the ship, increases the number of crew that are converted. That directly allows you to control how much of an efficiency hit you are willing to take when boarded. If you have a ten thousand man crew, you probably don't want to convert 75% of them into defensive forces and allow 10 marines to cripple the ship for five minutes, but you may want to take that risk on your 400 man beam escorts, having those flip control in your formation could be devastating. This allows additional interesting defensive boarding designs, without slowing the combat down once its kicked off.
Convert all crew, and use a formula that decreases ship effectiveness against a mass assault, and leaves ship effectiveness unaffected if the attacking force is tiny. I don't think this warrants more investment or needs an active player choice there.
The new boarding combat sounds very interesting. I have a few questions after reading the change log.
1, since there will be NPR using boarding tactics, will the player get any visual ques to identify such situation? For example, is there a way to tell whether a hostile boarding part is successfully landed? When the boarding parties are making their way through armor, will detonations be detected? Once they are inside the ship, will there be notifications before the first round of combat begins?
2, it is mentioned that the troops on parasites are fighting to defend their mothership.
2. 1, if during the boarding battle, the hanger bay/boat bay is destroyed by collateral damage (thus the docked parasite destroyed), will it affect said troops? (I guess no based on how troop transport bays are handled?)
2. 2, during the boarding battle, will the parasites be able to be launched from the mothership? Will they carry the troops away with them? (I guess no based on how troop transport bays are handled?)
2. 3, does it mean during the course of the boarding battle, ships with hanger decks/shuttle bays can be reinforced by friendly parasites carrying troops?
3, if the ship being boarded does not have a hanger bay/boat bay, will it possible for friendly ships to send reinforcements in someway? For example, small crafts dock with external docking ports?
The new boarding combat sounds very interesting. I have a few questions after reading the change log.
1, since there will be NPR using boarding tactics, will the player get any visual ques to identify such situation? For example, is there a way to tell whether a hostile boarding part is successfully landed? When the boarding parties are making their way through armor, will detonations be detected? Once they are inside the ship, will there be notifications before the first round of combat begins?
2, it is mentioned that the troops on parasites are fighting to defend their mothership.
2. 1, if during the boarding battle, the hanger bay/boat bay is destroyed by collateral damage (thus the docked parasite destroyed), will it affect said troops? (I guess no based on how troop transport bays are handled?)
2. 2, during the boarding battle, will the parasites be able to be launched from the mothership? Will they carry the troops away with them? (I guess no based on how troop transport bays are handled?)
2. 3, does it mean during the course of the boarding battle, ships with hanger decks/shuttle bays can be reinforced by friendly parasites carrying troops?
3, if the ship being boarded does not have a hanger bay/boat bay, will it possible for friendly ships to send reinforcements in someway? For example, small crafts dock with external docking ports?
Reguarding boarding combat, you could have a chance of the ship surrendering every increment based on crew casualties. . . This would simulate the fact that the entire crew doesn't need to be wiped out to take a ship but rather just critical elements need to be taken, maybe the officers, bridge, engineering, etc,
Would it be particularly difficult to code in an option to allow you to initiate a boarding attempt on one of your own ships to try and reinforce the defenders?
Would it be particularly difficult to code in an option to allow you to initiate a boarding attempt on one of your own ships to try and reinforce the defenders?
Not particularly. I think this probably should be an option. I've moved on from boarding at the moment (currently coding Star Swarm) but when I go back for round 2, probably after the next test campaign starts, I will add this and some rules for effect on ship capability and chance of surrender
Hi Steve, have you decided on changes for Star Swarm yet? And if so, will you give us the spoilers? :)
Would it be particularly difficult to code in an option to allow you to initiate a boarding attempt on one of your own ships to try and reinforce the defenders?
Not particularly. I think this probably should be an option. I've moved on from boarding at the moment (currently coding Star Swarm) but when I go back for round 2, probably after the next test campaign starts, I will add this and some rules for effect on ship capability and chance of surrender
If you are going to allow boarding reinforcements it would probably be best if you allow friendly reinforcements to arrive with much higher chances of successful deployment, simply because they will be deploying in coordination with the bridge to ensure minimum casualties when entering.
Would it be particularly difficult to code in an option to allow you to initiate a boarding attempt on one of your own ships to try and reinforce the defenders?
Not particularly. I think this probably should be an option. I've moved on from boarding at the moment (currently coding Star Swarm) but when I go back for round 2, probably after the next test campaign starts, I will add this and some rules for effect on ship capability and chance of surrender
This too, also with a high Xenophobia or something maybe they don't accept surrender and just finish the crew off.(probably still capture 5% or something for interrogation though)Reguarding boarding combat, you could have a chance of the ship surrendering every increment based on crew casualties. . . This would simulate the fact that the entire crew doesn't need to be wiped out to take a ship but rather just critical elements need to be taken, maybe the officers, bridge, engineering, etc,
It should be based on Racial Determination, or perhaps Racial Militarism. I would say 0% chance of surrender/capture if casualty percentage is less than half of RD.
In reply to the missile issue versus PD there are a few things to take into considerations, if they are equally worth investigating is another thing.
For example PD are super efficient at dealing with full size missile launchers from a cost perspective, especially now when ASM are going to be bigger in general.
On the flip side they are made almost irrelevant if you use box launchers on your ships.
The Agility as it is implemented makes it very insignificant i the early game and extremely powerful as technology progress and it is an exponential effectiveness as we also can see from the numbers presented in the thread earlier.
I still think that Agility as a mechanic is nice to but in order to make it impact more properly it could just be set to a specific value instead of removed OR simply flatten its impact considerably and have less technology steps.
When it comes to point defenses there is a fundamental "problem" between full size launchers who are very cost effective to use PD against and box launchers (on capital ships) which makes PD almost useless. Sure, I have no problem restricting the use of these weapons to fit into an acceptable balance. But I think it is worth investigating some time eventually at how the FC, salvo and missiles versus PD works going forward.
In the current version of VB6 Aurora it is prohibitively expensive to use "normal" missile strategies with full size launchers of say size 4+ against any decent PD unless you have a serious numbers advantage. The only way is to overpower PD with huge volleys of missiles OR you can confuse the PD with manipulating FC versus salvo rates which just become gamey and doesn't belong in a role-playing campaign.
I don't have any real good solution to there "problems" right now but I think they might be worth discussing at least.
For role-play I have always divided missiles into groups AMM (size 1) anti-fighter/FAC (size 3-5) anti-ship (size 5-12). In addition to this I have only allowed box launchers on ships that are suppose to act within a single system or on recon and smaller patrol ships even if they potentially can act in more than the same system. But never put box launchers on capital ships. Full size launchers was ever only used against things which are relatively bad at defending against missiles such as fighters, FAC or other smaller and often faster vessels. While capital ships with ASM always used reduced sized launchers to haul bigger volumes. If you can't penetrate enemy defenses on the first or second try there are no point in continue the bombardment (waste of time and resources). Using full size launchers with ASM always seemed to end up with one side exhausting their missiles and the other using mostly PD to fend them of unless the forces were very uneven but in that case reduced launchers would also work anyway.
That Conversation was in Suggestions, this is the Discussion thread.
There should not be too much discussion in the suggestions thread anyway, since Steve uses it to my knowledge as a log of suggestions, and too much discussions is just more work to look through and find the actual suggestions.That Conversation was in Suggestions, this is the Discussion thread.
where it belongs... as the suggestion was made some time ago and all the other posts (including mine) are more or less discussion or counter-suggestions... maybe a mod could move them here to clean the suggestion thread ... a new thread for the topic wouldn't be bad idea either...
That Conversation was in Suggestions, this is the Discussion thread.
Hey, Steve, in the new screenshots of your test campaign there is are two checkboxes: Design ground forces and Design ships. Is that like the VB6 one, where it's just starting designs, or does that keep making designs throughout the game as you get tech?
That Conversation was in Suggestions, this is the Discussion thread.
My bad... was reading that at the same time... problem when you have many windows open in your browser at the same time. ;)
Re: Cheaper engine performance techs.
Thinking about it, while it's a buff to missiles (since the player can now choose freely between the range/performance they would have had at that tech or new, shorter range/higher performance missiles), I think it buffs them in an interesting way. Previously it was almost always correct to go with maximum performance unless making a specifically long range missile, with the reduced missile fuel efficiency in the new version + this change I think there will be more room for tradeoffs between longer range, cruise-style missiles and high performance, short range "rocket" type missiles.
One of my complaints about missile vs beam balance was that the ranges were so different that they were essentially incomparable as weapons - if the enemy was shooting missiles at 100 million kilometers (not uncommon at even medium tech levels) then it didn't matter if you were twice as fast as they were - it would take hours to close to beam range, and all that mattered is if you could survive until their magazines were empty.
Now, if the choice is between missiles with a range of 50 mkm and 30,000 km/s speed, or missiles with a range of 5 mkm, 40,000 km/s speed, and 25% bigger warheads, there's more room for tactics. Possibly a sort of rock paper scissors where cruise missiles beat rockets (range) which beat beams (can overwhelm beam PD) which beat cruise missiles (beams PD shooting down the slower missiles), but also possibly more complex tactics, like trying to run down missile ships before they can unload their magazines. I look forward to seeing the results.
This will also make multi stage missiles more relevant, with multi stage missiles offering massive range advantages at slow speeds before deploying missiles with high speed and smallish warheads, vs medium range, speed and decent warheads and vs short range high speed and large warheads.
Or at least that would be my assumption as to how missile design philosophy will end up.
The long range cruiser, the medium range all rounder and the short range bruiser.
Yep, though multi-stage missiles come with their own costs (loss of efficiency for the first stage, and vulnerability to being shot down before the second one). If your opponent is making heavy use of long range cruise MIRVs, you could counter with some sort of AMM fighter or gunboat that sits between you and their fleets. Which is good, IMHO - more potential tactics to use!
Hi Steve, one small UI suggestion based on your current C# game screenshots. For the missile design window, is it possible to add the max engine boost tech to the tech list displayed top right corner? Since now the engine fuel consumption rate is a function of that too.
Steve one small point to note. On the game set up screen the warp point check point still refers to "jump gates on all warp points". I guess that should now just be "stable warp points". I suspect that eradicating the scourge of jump gates from the game will be a long and arduous process!
Just one side thought on this, with the progress made on the AI and the ability for updated orders to be provided to ships do you think you may get the position where warp point destabilisation tech may become a possibility?
Fixed the text. Theoretically, destabilisation could be added as an option but I want to have a lot more experience with the AI before I open that particular door :)
Fixed the text. Theoretically, destabilisation could be added as an option but I want to have a lot more experience with the AI before I open that particular door :)
Can the AI/civilian handle jump tenders now? I would really like to try some games without any jump gates or stabilized points at all.
Frigusium is my new favourite word.
Steve regarding the screenshots in the "The Great Crusade - Background and Starting Conditions" (http://aurora2.pentarch.org/index.php?topic=10235.msg111931#msg111931)
I expected to see the planet population capacity (http://aurora2.pentarch.org/index.php?topic=8495.msg100078#msg100078) in the "Home World" summery tab
next to or below "Population Supported by Infrastructure". Did I miss the information in the screenshots?
Or is there a dedicated Information Page when you select Sol?
Related question: What about starlifting? i.e. mining stars. This is plausible for a sufficiently large empire, even using real physics. It's a long topic I don't really want to get in to, but if you want to know how it would work, look up Isaac Arthur on Youtube.Where do you think the invaders get their ships from? To them our space is the 'weird other dimension". they're just coming here to investigate where all their sorium is going.
My point being, if its not out of the realm of possibility in real life, surely it should be possible given transnewtonian tech.
Quote from: Barkhorn link=topic=8497. msg112034#msg112034 date=1547177867Related question: What about starlifting? i. e. mining stars. This is plausible for a sufficiently large empire, even using real physics. It's a long topic I don't really want to get in to, but if you want to know how it would work, look up Isaac Arthur on Youtube.Where do you think the invaders get their ships from? To them our space is the 'weird other dimension". they're just coming here to investigate where all their sorium is going.
My point being, if its not out of the realm of possibility in real life, surely it should be possible given transnewtonian tech.
Related question: What about starlifting? i. e. mining stars. This is plausible for a sufficiently large empire, even using real physics. It's a long topic I don't really want to get in to, but if you want to know how it would work, look up Isaac Arthur on Youtube.
My point being, if its not out of the realm of possibility in real life, surely it should be possible given transnewtonian tech.
So i was just reading the C# lore that Steve posted. It occurred to me that if stars do accumulate TN materials the same as any other large mass, they would necessarily have massive quantities of these materials stored up. As was mentioned in the lore post, these materials are essentially impossible to harvest, being inside an active star and all. But what happens after, say, the star goes supernova? Do the TN materials remain focused near the center of the nova, or do they scatter during the event? Could supernova remnants be potential gold mines for TN materials? Just an idle thought that i felt needed sharing.
Could you add a "No Nebula" checkbox at game creation since we're on that topic?
I never bother with those, at best I just don't explore them, sometimes I delete them. Would kinda hate to delete also an NPR's link to me or its homeworld, though.
Quote from: BAGrimm link=topic=8497. msg112033#msg112033 date=1547175704So i was just reading the C# lore that Steve posted. It occurred to me that if stars do accumulate TN materials the same as any other large mass, they would necessarily have massive quantities of these materials stored up. As was mentioned in the lore post, these materials are essentially impossible to harvest, being inside an active star and all. But what happens after, say, the star goes supernova? Do the TN materials remain focused near the center of the nova, or do they scatter during the event? Could supernova remnants be potential gold mines for TN materials? Just an idle thought that i felt needed sharing.
Like making nebulas noticeably richer than other systems in TN materials ? That would nicely compensate for the slow moving ships and all.
Do we have any control as SM before a system generation if it will be in a nebula? If not, would like to see that as an option.Like making nebulas noticeably richer than other systems in TN materials ? That would nicely compensate for the slow moving ships and all.
That is already true for VB6 Aurora.
Do we have any control as SM before a system generation if it will be in a nebula? If not, would like to see that as an option.
Just saw the genetic enhancement for soldiers in the change list. There are a lot of possibilities with that kind of tech, this could get interesting.
Also two questions Steve :
Do NPR now invade worlds rather than nuking them from orbit ? I though I saw something about that but I can't remember where.
And second, and technically a spoiler, you said the swarm uses ground troops, as do precursors, do they have the full range of weaponry that NPRs and players do ? What I mean is, do they have STOs, artillery, vehicles, ect ? With like bio versions for the swarm in particular (kind of like starship troopers to be honest).
Quote from: The Forbidden link=topic=8497. msg112039#msg112039 date=1547189666Quote from: BAGrimm link=topic=8497. msg112033#msg112033 date=1547175704So i was just reading the C# lore that Steve posted. It occurred to me that if stars do accumulate TN materials the same as any other large mass, they would necessarily have massive quantities of these materials stored up. As was mentioned in the lore post, these materials are essentially impossible to harvest, being inside an active star and all. But what happens after, say, the star goes supernova? Do the TN materials remain focused near the center of the nova, or do they scatter during the event? Could supernova remnants be potential gold mines for TN materials? Just an idle thought that i felt needed sharing.
Like making nebulas noticeably richer than other systems in TN materials ? That would nicely compensate for the slow moving ships and all.
That is already true for VB6 Aurora.
They're only ideal for boarding if your boarding shuttles are good. I wouldn't want to lose 90% of my super expensive space marines because they missed their target vessel. I wouldn't mind losing 90% of my conscripts like that.
Quote from: Barkhorn link=topic=8497. msg112067#msg112067 date=1547249113They're only ideal for boarding if your boarding shuttles are good. I wouldn't want to lose 90% of my super expensive space marines because they missed their target vessel. I wouldn't mind losing 90% of my conscripts like that.
That's not how it works. If space marines cost 5 times as much and you need a tenth as many for a successful boarding action, it's still cheaper to lose 90% of a hundred marines than 90% of a thousand conscripts.
Are you playing with real stars on? You won't find nebulae if you do. Nor black holes.
Quote from: Garfunkel link=topic=8497. msg112074#msg112074 date=1547257402Are you playing with real stars on? You won't find nebulae if you do. Nor black holes.
I am, so that would explain it. Thanks for the info, I didn't realize real stars precluded nebulae and black holes. A shame, as they would both add intriguing obstacles for strategic considerations.
Quote from: Garfunkel link=topic=8497. msg112074#msg112074 date=1547257402Are you playing with real stars on? You won't find nebulae if you do. Nor black holes.
I am, so that would explain it. Thanks for the info, I didn't realize real stars precluded nebulae and black holes. A shame, as they would both add intriguing obstacles for strategic considerations.
They do.
Whereas -- in my opinion -- real stars adds nothing, save confusion as one tries to remember whether that was Wolf 352 or Wolf 359, Gliese 114 or Gliese 141. It appears that everyone renames discovered/settled systems by naming theme anyway.
I prefer to keep the real stars name, real star names hold sentimental value to me, even if its 'just another wolf system" . Of course the inhabited planets do get to be named by the colonists after a time.
To that end, I wish there were an option like 'restrictive real stars' so that you would get 'classic' real stars - like those visible in antiquity, or in the very first sets of star catalogues' instead of, for example, WISE 1043-089 or whatever. There should be more than enough of these 'classic' real stars for your typical game of Aurora.
Can you still build components bigger than 500 tons on the ground? The lore says ships bigger than that can't handle the aetheric currents, so how does a sub-500 tons shuttle handle taking a 2500 tons engine from my factories to the orbital yard?
Can you still build components bigger than 500 tons on the ground? The lore says ships bigger than that can't handle the aetheric currents, so how does a sub-500 tons shuttle handle taking a 2500 tons engine from my factories to the orbital yard?
Can you still build components bigger than 500 tons on the ground? The lore says ships bigger than that can't handle the aetheric currents, so how does a sub-500 tons shuttle handle taking a 2500 tons engine from my factories to the orbital yard?
Maybe the engine itself is assembled in orbit.
Linguist (of sorts) here: The -ium suffix in an element name would replace the -us declension. For example, it's uranium, not uranusium. Frigium and aestium would sound more natural.
Linguist (of sorts) here: The -ium suffix in an element name would replace the -us declension. For example, it's uranium, not uranusium. Frigium and aestium would sound more natural.
This is true. Also aestas usually refers to intense heat, either fire itself or boiling.
Maybe Greek would be more elegant: thermogen and cyrogen gasses.
Quote from: Steve Walmsley link=topic=8497. msg112089#msg112089 date=1547317854Quote from: Tree link=topic=8497. msg112088#msg112088 date=1547315358Can you still build components bigger than 500 tons on the ground? The lore says ships bigger than that can't handle the aetheric currents, so how does a sub-500 tons shuttle handle taking a 2500 tons engine from my factories to the orbital yard?
Maybe the engine itself is assembled in orbit.
I agree. . .
If we look at modern techniques at building large structures it makes sense that you build things modular and assemble them at the final destination. You do this with most structures and large vehicles/vessels today. I don't see why they would not do that in the future as well.
Modular construction is very effective and also good for upgrading, replacement, maintenance and repair etc. . .
I also think it is quite likely you have some sort of space lift capacity where you use a combination of anti-gravity and typical space lift technologies to get most stuff into orbit.
There can also be a combination of anti-gravity devices and strong tractor beams on the orbital space stations to act as space lifts or some such.
But I still think you bring up large pieces such as engines and other components broken down into modules.
Quote from: Jorgen_CAB link=topic=8497. msg112093#msg112093 date=1547335240Quote from: Steve Walmsley link=topic=8497. msg112089#msg112089 date=1547317854Quote from: Tree link=topic=8497. msg112088#msg112088 date=1547315358Can you still build components bigger than 500 tons on the ground? The lore says ships bigger than that can't handle the aetheric currents, so how does a sub-500 tons shuttle handle taking a 2500 tons engine from my factories to the orbital yard?
Maybe the engine itself is assembled in orbit.
I agree. . .
If we look at modern techniques at building large structures it makes sense that you build things modular and assemble them at the final destination. You do this with most structures and large vehicles/vessels today. I don't see why they would not do that in the future as well.
Modular construction is very effective and also good for upgrading, replacement, maintenance and repair etc. . .
I also think it is quite likely you have some sort of space lift capacity where you use a combination of anti-gravity and typical space lift technologies to get most stuff into orbit.
There can also be a combination of anti-gravity devices and strong tractor beams on the orbital space stations to act as space lifts or some such.
But I still think you bring up large pieces such as engines and other components broken down into modules.
Hi There First post after lurking forever.
One thing I have to say about this is the point that manufacturing in space is going to be cheaper in space. (500 tons in space is 500 tons you don't have to carry on earth damnit)
Simply sending the raw material up to space and building whatever up there (what do you mean I can throw this piece of metal across the room?) would be cost savings in itself.
While building in the module would make sense on earth (See Airbus 380) "now" it wouldn't make sense in space if you have all the facilities in space (see "what do you mean I can throw this block of engines over the other side of the earth")
Yup. . . said my piece and just wanna say super excited for C#
What exactly does it mean by "TNE ships travel mostly in the Aether". Are these ships visible to the naked eye? Is anything in the Aether tangible to people in normal space? Or are ships kinda all like the TARDIS where they appear larger on the inside then out?As I understand it, TN ships exists in both universes at once.
The amount of production implied by the amount of, say, iron or silicon or oil you could get in comparable masses to that of terraforming gasses would seemingly render most common goods post-scarce. Perhaps supplementary explanation is needed about terraforming to explain why they don't just use the technology to create anything they want in a factory setting.Probably why regular materials are so irrelevant. Guess it's impossible to pull TN materials through the terraformer, though.
As I understand it, TN ships exists in both universes at once.
Probably why regular materials are so irrelevant. Guess it's impossible to pull TN materials through the terraformer, though.
This is all neat and all but I would probably modify the canon in my head a bit for my own games to something I find a bit more thematic and believable.You are absolutely free to do that, it's even recommended! Loads of Aurora players have their own version of the "canon", some even change it from game to game.
It requires billions of years for them to coalesce in gravity wells.
Quote from: Tree link=topic=8497. msg112183#msg112183 date=1547678266As I understand it, TN ships exists in both universes at once.
Probably why regular materials are so irrelevant. Guess it's impossible to pull TN materials through the terraformer, though.
Yes, both universes at once and yes, TN materials are present in such trace amounts, the terraformers can't access them. It requires billions of years for them to coalesce in gravity wells.
I was referring more to conventional elements, like the ones in atmospheric gases that the terraformers harvest. You can synthesize tons of chemicals with the basic gaseous elements in the atmosphere. I suppose another part of this is there isn't much elaboration on what exactly the TNEs are and why they are special other than accessing the Aether. I don't suppose trans Newtonian elements would be any better at making say, soap, than common elements. 100% of industry on Earth today is based on conventional elements (or so we are led to believe :P), so having a giant portal into the next dimension that just poofs out the basic ingredients of literally anything you want to make seems a bit weird.
Steve, I note that the new population requirements for shipyards mean that smaller shipyards have smaller personnel draws than in VB6, but larger shipyards have notably greater impact upon your manufacturing sector.
Also, you may want to change the 'Naval Y/N' column to 'Type N(aval)/C(ivilian)' instead. It would be clearer I think.
Hazard has a point. Building large ships would be very taxing on the manufacturing sector.
It's a 250% increase in worker requirements. Sounds a bit excessive...
Seems like it would make colony specialization very important to building large ships.
Hopefully this is a small step on the path towards bringing back Prototype Hulls and First-in-Class penalties (or to put it the other way, bonuses for later units in the same class).
Most of the benefit for shipyards with many slipways is ease of use; you can just stack up more ships with fewer clicks.
I would not at all be opposed to a small per slipway cost decrease as a shipyard grows more slipways relative to having to retool multiple shipyards with the same total number of slipways of that same tonnage.
In some sense, this means military yards are cheaper to run than commercial yards, wealth wise. This sounds a bit strange to me.
Hi Steve, with your newly proposed shipyard worker number change, and the wealth generation change, I crunched some numbers, assuming base shipbuilding rate of 500, base wealth generation techs, and assume ship building rate in C# is not changed.
(https://cdn.discordapp.com/attachments/402321466839793664/540930638086144010/unknown.png)
So the starting naval yards can cover 1/12 of their max wealth cost themselves, raising to a limit of 1/2 when the yards are very large.
The starting commercial yards can cover 1/15 of their max wealth cost themselves, raising to a limit of 1/5 when the yards are very large.
In some sense, this means military yards are cheaper to run than commercial yards, wealth wise. This sounds a bit strange to me.
Not exactly. There are no ground units that can be equipped with missile launchers. However, you can design a survey missile and a small military station (structural shell instead of armour) equipped with a box launcher to simulate the ISS being used as a probe launch platform, being supplied with new missiles through an abstracted interaction of a space port/ordnance transfer facility and maintenance facilities.
Not exactly. There are no ground units that can be equipped with missile launchers. However, you can design a survey missile and a small military station (structural shell instead of armour) equipped with a box launcher to simulate the ISS being used as a probe launch platform, being supplied with new missiles through an abstracted interaction of a space port/ordnance transfer facility and maintenance facilities.
I thought the rules of structural shell was that no military systems could be put on board, essentially making it that only civilian stations could have it and be built by industry.
Not exactly. There are no ground units that can be equipped with missile launchers. However, you can design a survey missile and a small military station (structural shell instead of armour) equipped with a box launcher to simulate the ISS being used as a probe launch platform, being supplied with new missiles through an abstracted interaction of a space port/ordnance transfer facility and maintenance facilities.
I thought the rules of structural shell was that no military systems could be put on board, essentially making it that only civilian stations could have it and be built by industry.
That is, indeed, the rules of Structural Shells as posted on the C# Aurora changes list. Still, you could squeeze a single, very large missile launcher into a 1000 ton ship and fire your survey missiles at asteroids. . . GEO survey missiles, anyway. http://aurora2.pentarch.org/index.php?topic=8495.msg103096#msg103096 (http://aurora2.pentarch.org/index.php?topic=8495.msg103096#msg103096) doesn't mention GRAV survey sensors.
What is gimping auto-mines and asteroid mines? I haven't seen Steve post any changes to them.
Not exactly. There are no ground units that can be equipped with missile launchers. However, you can design a survey missile and a small military station (structural shell instead of armour) equipped with a box launcher to simulate the ISS being used as a probe launch platform, being supplied with new missiles through an abstracted interaction of a space port/ordnance transfer facility and maintenance facilities.
I thought the rules of structural shell was that no military systems could be put on board, essentially making it that only civilian stations could have it and be built by industry.
That is, indeed, the rules of Structural Shells as posted on the C# Aurora changes list. Still, you could squeeze a single, very large missile launcher into a 1000 ton ship and fire your survey missiles at asteroids. . . GEO survey missiles, anyway. http://aurora2.pentarch.org/index.php?topic=8495.msg103096#msg103096 (http://aurora2.pentarch.org/index.php?topic=8495.msg103096#msg103096) doesn't mention GRAV survey sensors.
Not exactly. There are no ground units that can be equipped with missile launchers. However, you can design a survey missile and a small military station (structural shell instead of armour) equipped with a box launcher to simulate the ISS being used as a probe launch platform, being supplied with new missiles through an abstracted interaction of a space port/ordnance transfer facility and maintenance facilities.
I thought the rules of structural shell was that no military systems could be put on board, essentially making it that only civilian stations could have it and be built by industry.
That is, indeed, the rules of Structural Shells as posted on the C# Aurora changes list. Still, you could squeeze a single, very large missile launcher into a 1000 ton ship and fire your survey missiles at asteroids. . . GEO survey missiles, anyway. http://aurora2.pentarch.org/index.php?topic=8495.msg103096#msg103096 (http://aurora2.pentarch.org/index.php?topic=8495.msg103096#msg103096) doesn't mention GRAV survey sensors.
You could also get around the no-military-systems limitation by creating a separate module for the station. In 7.1 I simulate large orbital space stations by creating a complex of complementary modules all linked by tractor beams - a large orbital habitat module or two linked to various specialized military modules for station defense/local command and control, etc.
For this specific example I would just create a 'space station'(more like a missile pod) that consists of little more than a fire control and a box launcher or two to fire your survey missiles and then bolt it onto your ISS with a tractor link.
So terraforming speed is reduced by a quarter for earth sized worlds? That doesn't go far enough in my opinion but is a start. I don't get why people say terraforming venus is impossible, really only takes a few decades with a few levels of terraforming tech and a dozen multi-million ton terraforming platforms.
Hope this is an okay place to put this.
I posted a bug for VB Aurora that might impact some C# things. There is possibly a rounding error for very low TCS on ships, making them completely undetectable on active sensors.
hxxp: aurora2. pentarch. org/index. php?topic=8144. msg113736#msg113736
Considering missiles can get down to .05 HS perhaps it would be fine if extraordinarily high tech cloaked ships could get down to a similar cross section?
Discussion over on discord seems to suggest these hyper stealth ships arent as bad as we originally thought because they still have significant thermal output.
Considering missiles can get down to .05 HS perhaps it would be fine if extraordinarily high tech cloaked ships could get down to a similar cross section?
Discussion over on discord seems to suggest these hyper stealth ships arent as bad as we originally thought because they still have significant thermal output.
Is there a reason why missile detection is capped at 0.3 HS rather than being able to get down to 0.05?
With the changes to thermal emissions, I assume the signature of a moving ship will have a minimum of its stationary signature? I. E. A large ship with small engines could not reduce its signature by travelling at speed 1 rather than remaining stationary?
I also have to ask... From your Changes post, it seems there is an exploit. Notably if the ship IS moving at very slow speed, the speed formula is used allowing to go below the minimal intended thermal signature. Is this just a bad wording in the post or is this also an error in the coding?
The minimum is the base signature, even when the ship is moving. It is coded that way but I didn't mention it in the post. I'll update it.
With the changes to thermal emissions, I assume the signature of a moving ship will have a minimum of its stationary signature? I. E. A large ship with small engines could not reduce its signature by travelling at speed 1 rather than remaining stationary?
Regarding the recent change added for Jump Point Transit Shock, how will transits through stabilized wormholes be handled? Would they be considered a standard transit?
It would be awesome if conditional orders could execute a saved order template.
Like all your templates or some ”special” template orders showed up as an choice of action when a certain condition is met.
Condition
Hostile detected in system
Action
(Saved Order Template)
Move to waypoint A
Activate Shields
Activate AS
Follow Gate X at 100 mKm
Something like this
Then we get a very powerful tool to save some micro-m.
Just a thought. . .
It would be awesome if conditional orders could execute a saved order template.
Like all your templates or some ”special” template orders showed up as an choice of action when a certain condition is met.
Condition
Hostile detected in system
Action
(Saved Order Template)
Move to waypoint A
Activate Shields
Activate AS
Follow Gate X at 100 mKm
Something like this
Then we get a very powerful tool to save some micro-m.
Just a thought. . .
While in the order topic... please pretty please remove the "Order delay" functionality for a proper "Wait on Station" order you insert into the order queue. The Order Delay only work the first time an order is executed and it is not very easy to know it you added it or not it it is not visible either.
A proper "Wait on Station" order can be very useful to set up Patrol routes... I would also like if I could get a randomised "Wait on Station" order as well. The ships would wait at a spot for a determined number of maximum and minimum seconds.
I can see many reason for why I would like to use this, especially in a multi-faction game where I run all sides... throwing in some randomness in ships movement can be an interesting way to get some unknown factors in battles between the factions.
It would be awesome if conditional orders could execute a saved order template.
Like all your templates or some ”special” template orders showed up as an choice of action when a certain condition is met.
Condition
Hostile detected in system
Action
(Saved Order Template)
Move to waypoint A
Activate Shields
Activate AS
Follow Gate X at 100 mKm
Something like this
Then we get a very powerful tool to save some micro-m.
Just a thought. . .
While in the order topic... please pretty please remove the "Order delay" functionality for a proper "Wait on Station" order you insert into the order queue. The Order Delay only work the first time an order is executed and it is not very easy to know it you added it or not it it is not visible either.
A proper "Wait on Station" order can be very useful to set up Patrol routes... I would also like if I could get a randomised "Wait on Station" order as well. The ships would wait at a spot for a determined number of maximum and minimum seconds.
I can see many reason for why I would like to use this, especially in a multi-faction game where I run all sides... throwing in some randomness in ships movement can be an interesting way to get some unknown factors in battles between the factions.
Loss of order delay is a bug in VB6 which is corrected in C#, so the problem should not arise. A wait on station would be possible although it just reverses the order of delay and execute.
With the missile engine change, is the max engine size still 5 MSP? I didn't see anything for number of engines, but maybe I missed it, or you plan on increasing the max engine size.
With the missile engine change, is the max engine size still 5 MSP? I didn't see anything for number of engines, but maybe I missed it, or you plan on increasing the max engine size.
I am calling the same code from a different place, so the sizes will appear the same in the drop downs. Adding larger sizes is no problem though.
Isn't that already a command? Or something very similar.
The missile engine change is great QoL - I assume we research the missile engine combined with the missile itself, ie the engine RP cost is combined with the missile RP cost? If I then research another missile using the same engine, do I have to pay the RP cost again? It's not a big deal since their RP costs are generally small and it can be justified with the lore that TN missile engines need to be custom-tailored to fit a specific missile.
That commander name theme change is fantastic for United Earth type factions or even just good old NATO / EU / ASEAN games.
QuoteI've been playing around with a more complex campaign setup and the lore involves some mixed-nationality factions. I have one faction with a dozen different name themes :)
Also leads to some interesting company names :)
Cripes does that mean the 5th Campaign start is inbound? Hopefully a multi faction start gives more of a chance for some ground combat!
QuoteI've been playing around with a more complex campaign setup and the lore involves some mixed-nationality factions. I have one faction with a dozen different name themes :)
Also leads to some interesting company names :)
Cripes does that mean the 5th Campaign start is inbound? Hopefully a multi faction start gives more of a chance for some ground combat!
I'm creating a five faction start in the Sol system and should probably have the prep done over the weekend.
The problem with thrown-together multi-nation starts (which the other C# multi-nation test campaigns have been) is that all the factions have (roughly) similar capabilities and similar problems, so there is a lot of repetition and a lack of variety, which isn't much fun so I get bored fast.
One alternative is a massive undertaking like Colonial Wars, which had existing systems and colonies, but that is too much work at this stage for a test campaign. The other is to make the factions sufficiently different, even though they are all starting in Sol, which is the route I am taking for the next campaign.
Almost a bit disappointing to see this campaign end, most of the starts look quite appealing, and leave me wanting for more.
The problem with thrown-together multi-nation starts (which the other C# multi-nation test campaigns have been) is that all the factions have (roughly) similar capabilities and similar problems, so there is a lot of repetition and a lack of variety, which isn't much fun so I get bored fast.
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.
So, would I be able to see these bonuses ahead of time? Or would I have to build a 200-ton engines from five different manufacturers to compare them? If the Royal Ross engine is equal or superior in every way to the Watt & Prithee, is its production somehow limited or do I get to ignore the 'bad' engine and never be forced to use it?
Quick dumb question: has the issue with ships that have no engines being counted as having military engines and so only able to use military jump drives been addressed? What with all the changes to how jump tenders work they might have been, even implicitly, but a quick search turns nothing up.
Quick dumb question: has the issue with ships that have no engines being counted as having military engines and so only able to use military jump drives been addressed? What with all the changes to how jump tenders work they might have been, even implicitly, but a quick search turns nothing up.
Ships without engines are flagged as 'no military engines' now.
Quick dumb question: has the issue with ships that have no engines being counted as having military engines and so only able to use military jump drives been addressed? What with all the changes to how jump tenders work they might have been, even implicitly, but a quick search turns nothing up.
Ships without engines are flagged as 'no military engines' now.
Question...
How does it work when a Tug is jumped while towing another ship, is this even possible?!?
Don't remember how it worked in VB Aurora.
Quick dumb question: has the issue with ships that have no engines being counted as having military engines and so only able to use military jump drives been addressed? What with all the changes to how jump tenders work they might have been, even implicitly, but a quick search turns nothing up.
Ships without engines are flagged as 'no military engines' now.
Question...
How does it work when a Tug is jumped while towing another ship, is this even possible?!?
Don't remember how it worked in VB Aurora.
If the jump point has a gate, it will work fine. Otherwise, it would depend on whether there was a sufficiently large jump engine at the jump point.
So Rakhas = Space Orks. :)
So Rakhas = Space Orks. :)
And frankly?
A bombardment of a few thousand warhead strength equivalent clears up swiftly enough to only need minor efforts for survival infrastructure. The habitability issues aren't that punishing, nor is the risk of loss of facilities because there are none on planet, just ground forces.
Also, you need to replace the missiles
And frankly?
A bombardment of a few thousand warhead strength equivalent clears up swiftly enough to only need minor efforts for survival infrastructure. The habitability issues aren't that punishing, nor is the risk of loss of facilities because there are none on planet, just ground forces.
Planetary bombardment in C# isn't the same as in VB6.
http://aurora2.pentarch.org/index.php?topic=8495.msg111435#msg111435
Lets assume you have missiles with 9 point warheads and you are firing on Martian infantry from my current game, which have 15 armour and 10 hit points. Lets assume the infantry are fortified but without construction vehicles to help (so 3 fortification, not 6). Lets pick the only near-habitable planet found so far in my campaign, which has Jungle Rift Valleys as the dominant terrain and therefore a hit modifier of 0.1875. Lets assume a force of 10,000 infantry, which would cost about 1500 BP.
Using the new orbital bombardment rules, each warhead will attack 150 infantry but only kill 6.875 of them. So it will take 1455 warheads to kill them all, which is 13,000 warhead strength. That will create 13,000 radiation and 13,000 dust. The radiation will take 130 years to clear and the dust will only need 52 years. Initial production hit will be -130%, plus the impact on population growth, temperature, etc.. Infrastructure doesn't help against radiation, so the planet is essentially useless for 100 years (and even then it will still be -30% to production). Smaller warheads don't necessarily help. You would need 3500 4-point warheads for example.
Also, you need to replace the missiles, I am assuming no ground-based point defence and that isn't a particularly large ground force. People's Republic in my current game is 120,000 infantry, plus tanks.
If the enemy is on plains or steppe, it is easier, but they may also be better dug-in or more resistant to bombardment. You can no longer simply wipe out ground forces and move in, at least not without severe environmental damage.
The radiation damage is problematic, but, well, habitats and automated mines should cover that problem. And if they don't it's time to break out the high power spinal beam cannons so you only have to deal with the dust.
I agree that that at some point, the fornication and to-hit modifiers would change, but it is still actually worse than my original example.
*snip*
While what you say is all true, the idea with full on indiscriminate bombardment like that isn't to destroy the ground forces utterly through orbital bombardment. It's nice if that happens, mind, but if the only resource of value down there is the mineral wealth of the planet there's no collateral to worry about except the temperature plunge and that can be covered with enough infrastructure.
I agree that that at some point, the fornication and to-hit modifiers would change, but it is still actually worse than my original example.
I must have missed a post in the change list, cause the game just took a new turn.
Maybe a new ship or troop module?
*snip*
Ah, I see that I was unclear.
While what you say is all true, the idea with full on indiscriminate bombardment like that isn't to destroy the ground forces utterly through orbital bombardment. It's nice if that happens, mind, but if the only resource of value down there is the mineral wealth of the planet there's no collateral to worry about except the temperature plunge and that can be covered with enough infrastructure. Especially since as the dust settles temperatures rise back up. This is of course only true for beam based bombardment, missile bombardment will also see radiation complicating the matter.
Rather, the point of a bombardment like this is to forcefully terraform the planet so its defensive modifiers drop. The Fortification and To Hit modifiers stack, so that's a pretty big deal if you are dealing with a Jungle Rift Valley (a fully fortified infantry unit in a Jungle Rift Valley has a 1.4% chance of getting hit regardless of source), but even in the worst case scenario for the new terrain (fully fortified infantry in a Mountain terrain) that gets you a 4 (1/6)th % chance of getting a hit on the enemy target, about 3 times as likely. It also means that due to the new, extreme environmental conditions that you probably trained your forces for but they did not you're not going to be suffering under penalties they will.
All of this combines to make an assault much more likely to be successful with limited casualties as a result. And if the terrain reroll gets you Barren, Chapparal, Ice Fields or anything else with a lower than 1.5 fortification modifier and a 0.75 to hit modifier you stop bombarding and go for the landings, because at that point it's close enough to equal.
It's just what happens when the slaaneshi worshippers arrive.I agree that that at some point, the fornication and to-hit modifiers would change, but it is still actually worse than my original example.
I must have missed a post in the change list, cause the game just took a new turn.
Maybe a new ship or troop module?
No need to worry about that too much, especially at this stage. Even if Hazard's tactic of instant hostile terraforming to game the terrain bonuses turns out to be 100% effective, it's still just one 'exploit' among many, nor will it ruin the game. I know I won't use it except for specific story purposes.While what you say is all true, the idea with full on indiscriminate bombardment like that isn't to destroy the ground forces utterly through orbital bombardment. It's nice if that happens, mind, but if the only resource of value down there is the mineral wealth of the planet there's no collateral to worry about except the temperature plunge and that can be covered with enough infrastructure.
Maybe the price of infrastructure should be pushed up significantly, so that the cost of mines + infrastructure to hold necessary pop at colony cost <tweaking parameter> is comparable (tho' slightly less than, because of the hassle) to the cost of automines.
so creating big missiles will be ineffective as they will be easily shot down by PD? Or do they have a bit boosted HP to compensate lose of armor? Armored torpedoes was a really neat concept.
Oh, I missed this part. So missiles can't be armored anymore? I liked this part!
No need to worry about that too much, especially at this stage. Even if Hazard's tactic of instant hostile terraforming to game the terrain bonuses turns out to be 100% effective, it's still just one 'exploit' among many, nor will it ruin the game. I know I won't use it except for specific story purposes.
I assume the new spoiler race will have some surprises up their sleeve that Steve hasn't shared with us yet.
It's not cheap either. You need to expend thousands of warhead strength equivalent in either missiles or beam weapon shots, most likely in the face of fairly hefty orbital defenses. It's really going to be a question of whether or not the effort is worth it versus just sending in the drop ship swarms with many thousands of tons of men and materiel.
I can see siege warfare, blockading and just planet hopping being good strategies to deal with fortress worlds. Let them wither on the vine. I don't see massive ground invasions being very common, they are just too costly and produce too much dust.It's not cheap either. You need to expend thousands of warhead strength equivalent in either missiles or beam weapon shots, most likely in the face of fairly hefty orbital defenses. It's really going to be a question of whether or not the effort is worth it versus just sending in the drop ship swarms with many thousands of tons of men and materiel.
Or vs just avoiding that planet, if the enemy is known to be planetbound. Maybe it's rich in minerals, but how many minerals of what types are you risking to get what's in the ground?
Which is as it should be.
I can see siege warfare, blockading and just planet hopping being good strategies to deal with fortress worlds. Let them wither on the vine. I don't see massive ground invasions being very common, they are just too costly and produce too much dust.
If a planets costs more to take than it is worth then the player will use the nuclear option.
Edit : work only to kill population and get an intact economy. Land troops are unaffected, which is strange after several decades.
Edit : work only to kill population and get an intact economy. Land troops are unaffected, which is strange after several decades.
Not that strange considering infrastructure has all you need to support a bunch of civilians in a hostile environment for decades in this universe. The military would have plenty of resources to adapt in this scenario.
Anyway, imagine 20 years without getting out of your armor, just think about the smell !!!
I love the option for automated medals... A quick question though, would it be possible to have an option to display medals in order of Promotion Point values instead of chronologically? Just to make your heroic admiral's Victoria Cross stand out from his rack of "most efficient paperclip manager" ribbons...
finally i am sorry for my bad English
and by the way i have noticed that the game uses only one core "i know c# will be much faster but when you invest in a world the game become very complex and unplayable too fast " so can the game use all possible core .
you can even use the graphic card to do some of the calculations
Quote from: HMX1 link=topic=8497. msg115080#msg115080 date=1561412857finally i am sorry for my bad English
and by the way i have noticed that the game uses only one core "i know c# will be much faster but when you invest in a world the game become very complex and unplayable too fast " so can the game use all possible core .
you can even use the graphic card to do some of the calculations
as someone who has worked with multi-threading in C#/. NET before, it is not as easy as flipping a switch to say "use all the cores"
Implementing multi-threading is no easy tasks, and even when you do use multi-threading not everything can be multi-threaded, if stuff needs to happen 1 after the other you can't multi-thread that.
Offloading processing to a GPU is even more complex and only works for very specific workloads, Aurora is not one of those.
about Missile Engines Integrated into Missile Design
wouldn't it be more realistic if we have a exponential curve on rocket performance and cost
Just wanted to ask if you coded Combat Air Patrol mission for fighters, as it still looks to be a placeholder for it.
Yes, agreed. I've done some multi-threading in non-Aurora code and it adds a lot of scope for bugs. Because Aurora is linear in nature, there aren't a lot of opportunities for handling things in parallel. Detection is one possibility, but even then data has to be shared between threads for such things as assigning IDs or names to contacts, alien ships, etc. . Also, in some situations, multi-threading is actually slower than single threading because of the thread overhead.
Given that C# Aurora is very fast compared to VB6, I haven't seen a need to take on the extra complexity when the potential performance gain isn't significant. Even if was twice as fast, that doesn't really provide a benefit if it is already fast enough.
Will the new Diplomacy rules treat 'my ship enters a new system, realizes it is inhabited, and sits on the jump point with its transponder on waiting for the aliens to come visit' as less offensive than 'my ship pulls up to alien planet and hangs around' or 'my ship visits grav survey location after grav survey location, ignoring the aliens'?
I guess what I'm asking for is to replace the single 'foreign ship in claimed system' penalty with ones that are based on the ship's activities. I'd like aliens to be less upset if my empire says hello than if it doesn't, and considerably more upset if it starts surveying their territory & worlds, and/or stabilizing local jump points.
Will it be called just 'diplomacy module'? No fancy name like xenocommunication bay? Orbital embassy bay? I suck at naming but still.
And have an civilian "Officer" aka Embassador on the ship and use his diplomacy bonus
Also on diplomacy:
1) Will the player be able to tell which aliens are trying to talk to him? This seems like something that is more likely than not to be obvious.
2) So my understanding is that, for every race you've met, relations will always drift towards the negative unless you have an embassy ship talking to them (in one of their systems?) due to their xenophobia (even if it's only "1"). So if I chance upon an alien scout in a system and we both go our separate ways and don't see each other for 10 years, when I encounter them again they'll want to go to war with me even if they've got a very low xenophobia?
3) Are there going to be any actions that the player can take that will generate positive diplomacy points? For example "upheld treaty commitments" by not entering alien systems for e.g. non-interaction treaty. If not, then it appears that the only way the player can influence things in a positive direction is to have an embassy ship, and the effect of that is capped at one ship. I was originally going to go down the road of making diplomacy modules VERY expensive and allowing more than one, but there's a lot to be said for "actions speak louder than words". Perhaps the diplomacy modifier could put a bias (e.g. +10 points towards the good) on all the other events that happen, e.g. a -50 "ship parked above homeworld" might only have a -40 impact if there's a diplomat.
The challenge I see here is setting things up so the player can positively influence things without having a system that can be gamed by throwing huge resources at the problem - perhaps a law of diminishing returns where the 2nd diplomacy ship is only 80% as effective, the 3rd 64% etc, which would sum up to a max 10x multiplier with an infinite number of ships.
John
Multiple owned populations on the same body are currently rather difficult and awkward to handle in Aurora. Will this be easier in C# version?
I'm a tiny bit wary about being able to benefit from multiple Diplomacy Modules, if only for the silly potential edge case of building a fleet of embassy ships that would outweigh an alien race's xenophobia by a factor of ten or more. So long as there's some sort of limiting factor to it.
Steve, that's not an OOB, that's a Table of Ordnance & Equipment.
The TO&E tells you what you have, the OOB tells you how it's organized. In the Naval Organization tab the OOB is on the left hand side of the screen.
That is not to say that a TO&E separated by system isn't useful, it certainly is, but it'd be nice if we could click on a system or something and get a TO&E calculated, or an OOB specific for that system, linking up and down where appropriate.
Also on diplomacy:
1) Will the player be able to tell which aliens are trying to talk to him? This seems like something that is more likely than not to be obvious.
2) So my understanding is that, for every race you've met, relations will always drift towards the negative unless you have an embassy ship talking to them (in one of their systems?) due to their xenophobia (even if it's only "1"). So if I chance upon an alien scout in a system and we both go our separate ways and don't see each other for 10 years, when I encounter them again they'll want to go to war with me even if they've got a very low xenophobia?
3) Are there going to be any actions that the player can take that will generate positive diplomacy points? For example "upheld treaty commitments" by not entering alien systems for e.g. non-interaction treaty. If not, then it appears that the only way the player can influence things in a positive direction is to have an embassy ship, and the effect of that is capped at one ship. I was originally going to go down the road of making diplomacy modules VERY expensive and allowing more than one, but there's a lot to be said for "actions speak louder than words". Perhaps the diplomacy modifier could put a bias (e.g. +10 points towards the good) on all the other events that happen, e.g. a -50 "ship parked above homeworld" might only have a -40 impact if there's a diplomat.
The challenge I see here is setting things up so the player can positively influence things without having a system that can be gamed by throwing huge resources at the problem - perhaps a law of diminishing returns where the 2nd diplomacy ship is only 80% as effective, the 3rd 64% etc, which would sum up to a max 10x multiplier with an infinite number of ships.
John
All the above is a good point. I hadn't considered the initial contact followed by a long period of separation. Maybe a better option would be to have the Xenophobia function as a modifier against negative actions. So when separated, nothing changes. When in contact, actions perceived as negative become far worse when dealing with a highly Xenophobic race.
Existing treaties already generate positive points, but I will add other ways to generate positive points.
I mean imagine if tomorrow Russia starts closing embassies in the US, how long before that start to be seen as an actual act of war?
I mean imagine if tomorrow Russia starts closing embassies in the US, how long before that start to be seen as an actual act of war?
Where did you get the idea that not having an embassy would be seen as an act of war by anyone after some unspecified time?
Imagine if North Korea did not allow an US embassy nor has an embassy of their own in USA. How long before that start to be seen as an actual act of war?
I mean imagine if tomorrow Russia starts closing embassies in the US, how long before that start to be seen as an actual act of war?
Where did you get the idea that not having an embassy would be seen as an act of war by anyone after some unspecified time?
Imagine if North Korea did not allow an US embassy nor has an embassy of their own in USA. How long before that start to be seen as an actual act of war?
You do know the Korean war never ended? it's still just under a cease fire...
Can own naming themes be deleted/overwritten? Spelling mistakes do happen
Edit: Also, a column showing current survey points so we know which ones already have teams would be nice.Or even just an asterisk marking a location on the list where a team is currently active.
Edit: Also, a column showing current survey points so we know which ones already have teams would be nice.Or even just an asterisk marking a location on the list where a team is currently active.
Thanks Steve for the list of current known sites and the list of known forces in text form, Would be very useful for us screen reader users, i hope you haven't forgotten us :)
Would it be possible to make multiple ordnance loadout orders for a class?
IIRC that's not possible in VB6 and it doesn't look possible in C# Aurora, and it would only rarely be useful, but still.
Is there a possibility that in a future update, conducting diplomacy will involve more than sitting a ship with a diplomacy module in their detection range? With the ability for a planet to have multiple colonies, and C# bringing in ground units dedicated to archaeology, it seems like the groundwork for embassies exists.
With the ability for a planet to have multiple colonies
Right. I was trying to say that the multiple colonies thing could be used as is for some kind of embassy situation.With the ability for a planet to have multiple colonies
I think that is already coded as it was for the VB6
Does the Prefix/Suffix option use all possible combinations of names? IE: If I have a name list contains only the name "Dragon", but add a prefix list with a variety of colors, would I then get a series of ships named "Red Dragon", "Yellow Dragon", etc., or just one ship named "Red Dragon"?
Final Defensive Fire Changes
In VB6 Aurora, a fire control can only fire at a single target in any increment. For C# Aurora, an exception is made for fire controls firing in automatic final defensive fire mode.
A fire control in this mode will continue to fire on incoming salvos as long as it has unfired weapons remaining. Each individual weapon or turret will only be able to engage a single salvo. This means point defence ships no longer need a large number of fire control systems, although there is still a design choice in terms of redundancy.
In VB6 Aurora, missiles moved in descending order of speed. I've updated that for C# Aurora 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 (and be engaged first by final defensive fire).
I'm a bit concerned, to be honest. Final defensive fire was already really powerful.
I'm a bit concerned, to be honest. Final defensive fire was already really powerful.
This should solve the issue of loads of small salvos overwhelming defensive fire controls problem. But does it mean that quad turrets are less impressive now since their four shots will be limited on one salvo? I would assume not really, because nobody fires bunch of identical salvos but each consisting of only 1-2 missiles.
I don't really see why using one mode of defensive fire over another is a problem. If point defense is too powerful, make it more expensive or have a lower rate of fire or something. The salvo spam stuff was always bizarre.
I don't really see why using one mode of defensive fire over another is a problem. If point defense is too powerful, make it more expensive or have a lower rate of fire or something. The salvo spam stuff was always bizarre.
The problem IMO is not that Final Fire or Point defense is too powerful ( I think it will be pretty well balanced with this change ) but that Area Defence for engaging at range is too weak / useless in comparison to Final Fire. This change makes the difference even worse since Final Fire now won't need alot of fire controls vs smaller salvos, while Area Defence still will
between the removal of one-bfc-per-volley and the implementation of tracking time bonus (both its simple existence and the particulars of how it works) i think you might want to have a serious look at railgun barges, steve. unless i am greatly mistaken they are going to be just outrageously effective against any kind of long-ranged missile attack.
The range of the weapon should matter even during final fire PD. A missile salvo travelling say 250.000km in 5 sec and a gun that can engage it at 10.000km only have a window of 0.2 sec to engage the salvo. I think that PD weapons and the mechanics should be changed and the mechanic reworked at some time. I don't think it is necessary to do it right now, just fix some of the imbalance for now.
Actually, talking of ship to ground combat, railguns IIRC are relatively low damage but fire 4 times in a single round, so they'd be very well suited to orbital bombardment of relatively poorly armoured targets like infantry heavy armies.
between the removal of one-bfc-per-volley and the implementation of tracking time bonus (both its simple existence and the particulars of how it works) i think you might want to have a serious look at railgun barges, steve. unless i am greatly mistaken they are going to be just outrageously effective against any kind of long-ranged missile attack.
One way to improve area defense might be to give it an improved tracking bonus. I know consistency is important, so my explanation why final fire doesn't get as big a boost is that the change in behavior as a missile starts it's attack run throws off the predictive algorithms.I don't really see why using one mode of defensive fire over another is a problem. If point defense is too powerful, make it more expensive or have a lower rate of fire or something. The salvo spam stuff was always bizarre.
The problem IMO is not that Final Fire or Point defense is too powerful ( I think it will be pretty well balanced with this change ) but that Area Defence for engaging at range is too weak / useless in comparison to Final Fire. This change makes the difference even worse since Final Fire now won't need alot of fire controls vs smaller salvos, while Area Defence still will
Yes, agree on that. I need to look at area defence. It doesn't really function as I originally intended.
The easiest way to make area defense make sense is to allow it to apply tracking time bonus to the distance-based to-hit modifier as well.One way to improve area defense might be to give it an improved tracking bonus. I know consistency is important, so my explanation why final fire doesn't get as big a boost is that the change in behavior as a missile starts it's attack run throws off the predictive algorithms.I don't really see why using one mode of defensive fire over another is a problem. If point defense is too powerful, make it more expensive or have a lower rate of fire or something. The salvo spam stuff was always bizarre.
The problem IMO is not that Final Fire or Point defense is too powerful ( I think it will be pretty well balanced with this change ) but that Area Defence for engaging at range is too weak / useless in comparison to Final Fire. This change makes the difference even worse since Final Fire now won't need alot of fire controls vs smaller salvos, while Area Defence still will
Yes, agree on that. I need to look at area defence. It doesn't really function as I originally intended.
I agree on the area defense issues, I don't think I have ever used it effectively in a game.
The reduced missile speeds should help on this but I don't think its going to go far enough. Generally I'd expect area defence to be useful where you can detach escorts from you main TF and have them usefully engage incoming missiles before the reach the main group. I wonder if missiles passing through an engagement envelope being fired on rather than just those that land in the engagement range would help.
Not such a fan of the tracking bonus applying to range unless this is also applied to ship to ship combat.
The main problem is tactical utility though rather than mechanics. If a ship is deployed away from the main force it becomes an easier target so the benefit of enhanced energy point defence is countered by increased vulnerability. The only way the area mode really gains over final defensive fire is if it can fire more than once, which means long-ranged turreted weapons with appropriate fire control. In that case, even though it might fire more than once, a ship designed for final defensive fire has more weapons for the same cost, so firing more than once doesn't necessarily help. Maybe some sort of 'stealth picket' could help, but again cost vs capability might still not be viable.
steve
with regards to tracking time bonus, a big part of the problem is that it has been represented as purely additive; a railgun with a natural accuracy of 15% with a 20% tracking bonus should (imo) hit at 18% whereas as currently envisioned (documented, at least) it will hit at 35%, which just *has* to make long range missiles non-viable. Im not in a position to test my suppositions or my my conclusion, but i know a guy who is.
i don't know all the A# changes let alone their interactions, but i feel the final fire BFC change alone would represent a substantial improvement to beam defense in 7.1.
steve
with regards to tracking time bonus, a big part of the problem is that it has been represented as purely additive; a railgun with a natural accuracy of 15% with a 20% tracking bonus should (imo) hit at 18% whereas as currently envisioned (documented, at least) it will hit at 35%, which just *has* to make long range missiles non-viable. Im not in a position to test my suppositions or my my conclusion, but i know a guy who is.
i don't know all the A# changes let alone their interactions, but i feel the final fire BFC change alone would represent a substantial improvement to beam defense in 7.1.
If Area Defence BFC can fire at missiles as they pass through, even if the missiles do not end up their 5-sec movement inside the firing envelope, it would make AD actually useful. Yeah, stealthy picket ships ahead of the main group thinning salvos out might not be economically viable when compared to flak-barges using final fire, but at least they would mechanically work. So if that change is both possible and easy to make, it would be interesting to have so we could play around with it.I wonder if missiles passing through an engagement envelope being fired on rather than just those that land in the engagement range would help.I think 'passing through' would probably be the best implementation of area defence. That wouldn't be too hard to implement and I could use the closest point of approach during the increment.
Interesting to see what I assume are the new mechanics on weapon failures impacting one off box launcher shots from fighters in Steve's current campaign. That feels like a slightly unintended consequence to me as feels a bit rough to now need engineering bays on all fighters to ensure that one alpha launch works. I wonder if an exception to box launchers would be reasonable.
I think 'passing through' would probably be the best implementation of area defence. That wouldn't be too hard to implement and I could use the closest point of approach during the increment.
<snip>
Rather than than trying to make area mode work for energy weapons, maybe we just have to accept the concept isn't really viable.
Why not just have ONE PD setting and call it a day.I think there might be at least one case where you might want to have separate FF vs AD though not sure if it would warrant the extra complexity.
If you are going to be doing prize crews, maybe let it draw a tiny complement from the boarding fleet/ship (because even a boarding ship is going to take a larger crew than just a dozen people) and then let the player assign a prize crew on the basis of 'level the crew counts between all ships in a task force'
Yes, that would mean that a number of crew was just drawn from the mother ship and its escorts. That's the way it goes. Or let a player assign how much 'over capacity' crew they want as well as an excess of crew quarters.
Yes, but which ship creates a prize crew if the alien ship simply surrenders? How does it get on board? Also, the ship providing the few crew members would need to visit port to replenish them.
This type of detail won't make any difference to any meaningful decision on the part of the player and it won't make any appreciable difference to the crew pool. It would only add micromanagement that would quickly become tedious. It is a lot better for game play reasons for the prize crew to manifest out of thin air. This is no different than commanders always being exactly where you need them.
To be honest, wouldn't it make more sense if they bailed out to life pods and scuttled their ship? Thinking about it, why would the enemy just surrender their warship full of advanced technology to an aggressive technologically inferior alien they don't know anything about? I don't know about you, but if I was captain in that situation I'd be blowing the sucker up if I could.
. . they bailed out to life pods and scuttled their ship? . . .
Cause you know, not everyone wants to die. . . .
Exploit class Tyazholiy Avionosnyy Kreyser 30 tons 1 Crew 3.5 BP TCS 0.6 TH 0 EM 0
1 km/s Armour 3-0 Shields 0-0 Sensors 1/1/0/0 Damage Control Rating 0 PPV 0
MSP 0 AFR 6% IFR 0.1% Max Repair 5 MSP
Intended Deployment Time: 12 months Spare Berths 1
This design is classed as a Commercial Vessel for maintenance purposes
Yes, that's a ship with zero armour area. No idea what'll happen if I try and attack it.
How many times have you left alien life pods to die?
If you surrender, you give the scary aliens a reason not to blow you up with nuclear death and take you prisoner instead of just leaving you to die.
3) When you design a ground unit class, you can designate it as a 'Non-Combat Class'. A class with this designation suffers an 80% penalty to hit and any hostile unit selecting targets treats this unit as 80% smaller. This could be used for supply vehicles, HQs, FFD units, etc. It is intended to simulate the type of unit that will actively avoid combat and is therefore much less likely to be chosen as a target. This applies regardless of field position.
Quote3) When you design a ground unit class, you can designate it as a 'Non-Combat Class'. A class with this designation suffers an 80% penalty to hit and any hostile unit selecting targets treats this unit as 80% smaller. This could be used for supply vehicles, HQs, FFD units, etc. It is intended to simulate the type of unit that will actively avoid combat and is therefore much less likely to be chosen as a target. This applies regardless of field position.
When units achieve a breakthrough, are they exempted for the reduced chance to target non-combat units? I imagine vehicle supply units, or possibly combat engineers, in a reserve position might be a choice target in a breakthrough.
I'll echo that it seems a bit odd that it would apply to FFD, though I don't see it as a balance issue, just a flavor one, so it's not a big deal.
Quote3) When you design a ground unit class, you can designate it as a 'Non-Combat Class'. A class with this designation suffers an 80% penalty to hit and any hostile unit selecting targets treats this unit as 80% smaller. This could be used for supply vehicles, HQs, FFD units, etc. It is intended to simulate the type of unit that will actively avoid combat and is therefore much less likely to be chosen as a target. This applies regardless of field position.
When units achieve a breakthrough, are they exempted for the reduced chance to target non-combat units? I imagine vehicle supply units, or possibly combat engineers, in a reserve position might be a choice target in a breakthrough.
I'll echo that it seems a bit odd that it would apply to FFD, though I don't see it as a balance issue, just a flavor one, so it's not a big deal.
FFD are quite large and therefore are being killed a lot because of the mechanics, where each individual unit targets randomly, weighted by size. I could add code to exclude units with certain types of components from being non-combat and then make FFD smaller and cheaper, but that would also mean it would be easier to have many ships supporting a single unit very cheaply. Having them as non-combat works a lot better with the other mechanics.
Maybe just call it "avoid combat" instead since that would make sense for both FFD and real non-combat units.
On the subject of ground combat, if I mount a logistics module on a light vehicle, and the logistics module is consumed, do I lose my vehicle? It would seem... weird to consume a vehicle, unless that is considered as folded into the cost. Wouldn't a motorized logistics unit be more of an upfront cost, but paid for by the fact that you can just tack more GSP onto it and truck it out to the front line?
I suppose my question then is, once I build a Supply Truck, and it's given all of it's GSP in combat... do I need to build a whole nuther truck... or can I just 'reload' it?
A new 'Stabilise Lagrange Point' order is available for planets where stabilisation is possible. The stabilisation ship remains at the associated planet while the task is carried out.
On the subject of ground combat, if I mount a logistics module on a light vehicle, and the logistics module is consumed, do I lose my vehicle? It would seem... weird to consume a vehicle, unless that is considered as folded into the cost. Wouldn't a motorized logistics unit be more of an upfront cost, but paid for by the fact that you can just tack more GSP onto it and truck it out to the front line?
I suppose my question then is, once I build a Supply Truck, and it's given all of it's GSP in combat... do I need to build a whole nuther truck... or can I just 'reload' it?
Quote from: Steve WalmsleyA new 'Stabilise Lagrange Point' order is available for planets where stabilisation is possible. The stabilisation ship remains at the associated planet while the task is carried out.
Am I misreading that, or is the ship sitting in close orbit of the planet and then the LP pops into usability a sixth of the orbit away from where the work is being done? I suppose I'll just have to be stubbornly oblivious to that inconvenient bit of action-at-a-distance in any of my games.
On a slightly different note, I'm guessing that now LPs will be shown even if there's currently only one in the system (and thus nowhere to go from it).
On the subject of ground combat, if I mount a logistics module on a light vehicle, and the logistics module is consumed, do I lose my vehicle? It would seem... weird to consume a vehicle, unless that is considered as folded into the cost. Wouldn't a motorized logistics unit be more of an upfront cost, but paid for by the fact that you can just tack more GSP onto it and truck it out to the front line?
I suppose my question then is, once I build a Supply Truck, and it's given all of it's GSP in combat... do I need to build a whole nuther truck... or can I just 'reload' it?
Like Steve said, it's lost. It's something I disagree with him on and prefer a GSP system similar to MSPs, even if I understand why he does it.
Maybe just call it "avoid combat" instead since that would make sense for both FFD and real non-combat units.
Yes, good idea.
Maybe just call it "avoid combat" instead since that would make sense for both FFD and real non-combat units.
Yes, good idea.
Hide with Pride.
Dug in.
Extensively camouflaged.
Highly dispersed.
Quote from: Steve WalmsleyA new 'Stabilise Lagrange Point' order is available for planets where stabilisation is possible. The stabilisation ship remains at the associated planet while the task is carried out.
Am I misreading that, or is the ship sitting in close orbit of the planet and then the LP pops into usability a sixth of the orbit away from where the work is being done? I suppose I'll just have to be stubbornly oblivious to that inconvenient bit of action-at-a-distance in any of my games.
On a slightly different note, I'm guessing that now LPs will be shown even if there's currently only one in the system (and thus nowhere to go from it).
Yes, going to the planet is easier. It is a fixed location and the ship will remain in orbit when the planet moves. Otherwise, the construction ship is constantly having to chase the right location in deep space.
Yes to single LPs.
(As I'm sure you know) There are actually two Lagrange points (L4 & L5) at +/- 60 degrees. I forget how it works now - does Aurora only ever give one of them (i.e. leading or trailing)? The only reason I see for adding the ability to have both to the game mechanics is, as Garfunkel pointed out, for intra-system shortcuts. Otherwise you might limit to only leading or trailing showing up (with some technobabble about the direction of the orbit breaking the symmetry). What set me down this road was "if the ship's at the planet, then which Lagrange point magically appears when you're done stabilizing" - I figure that's messier to code up than just only ever having leading or trailing.
John
Which brings up the question of whether it should be a design-time decision for the whole type or a combat-time decision for a single instance. Which in turn OTOH would lead to micro-management and is (being able to try to stay away from combat in the battle) why the multiple echelons are there.
Which brings up the question of whether it should be a design-time decision for the whole type or a combat-time decision for a single instance. Which in turn OTOH would lead to micro-management and is (being able to try to stay away from combat in the battle) why the multiple echelons are there.
I found when playing a battle that the echelons work well in an operational sense (keeping the artillery and most of the supply well back) but not as well tactically. If you have certain units such as HQs and supply with the front line forces they would still be less likely to come under attack than the infantry in the trenches. The echelons are a choice, while the 'non-combat' is based on the type of unit. A 'non-combat' unit in the front line is still much more likely to be attacked than a 'non-combat' unit in support or rear echelon, but less likely to be attacked than combat forces of similar mass.
And it's worth noting that the ability isn't reducing casualties, it's making other units more likely to be hit in their place; assuming I understand it right, if you had an entire formation set on "Avoid combat" it would work out exactly the same as if none of them were (except that they'd have massive penalties to their own fire).
So if you have 10 "avoid combat" FFD and 1000 infantry, the FFD units will still become much more vulnerable as the number of infantry units gets worn down. Essentially it's just making other units serve as bodyguards for the units you're conserving (and as a result the protected units can't effectively fire their own weapons), which makes sense to me.
1) You can no longer use the same maintenance facilities to support multiple ships, so you need far more maintenance facilities in general. For example, if you build a 20,000 ton ship, you also need 20,000 tons of extra maintenance facility capacity to support it.
I apologize if this has been addressed already, but will Aurora 4x address the civilian organization of empires as well as the military?
Can you have a federal presidential system with, say, a President, Chief of Staff, Attorney General and all their secretaries and deputy secretaries that you can customize to your hearts content like your military OoB?
Quote1) You can no longer use the same maintenance facilities to support multiple ships, so you need far more maintenance facilities in general. For example, if you build a 20,000 ton ship, you also need 20,000 tons of extra maintenance facility capacity to support it.
Will there be a way to easily sum the tonnage of all ships (that need maintenance) in orbit of a colony? I've never been much good at maths, and it would be frustrating to get the numbers wrong and find that I don't have enough facilities to support all of my ships.
Also, it would be nice if there was a display showing a breakdown of maintenance capacity (amount currently available, amount under construction and total amount) at a colony.
Each colony shows maintenance capacity and tonnage being maintained.Could we also get tonnage data of a task group to task groups view so that we could easily see required additional tonnage if we were to move the task group to another location?
Each colony shows maintenance capacity and tonnage being maintained.Could we also get tonnage data of a task group to task groups view so that we could easily see required additional tonnage if we were to move the task group to another location?
I have some concerns about the changes to final fire. Short-range beam defences are dirt cheap. In my opinion, giving them the highest priority to become immune to any likely missile threat is the easiest approach as it is. Their current weaknesses are point blank missile fire that bypasses defences (I believe the AI doesn't do this?), and being limited by fire controls against highly dispersed volleys, which favour AMMs. It seems both of these are going away.
Is this on the radar? Whether it's a problem may also be affected by things other than combat mechanics - e.g. the way the AI designs ships and missiles.
They still take up space and you no longer get free maintenance from unlimited maintenance stations if you are under a certain size. This means that having lots of relatively large but cheap PD will be heavy on your maintenance infrastructure.
They still take up space and you no longer get free maintenance from unlimited maintenance stations if you are under a certain size. This means that having lots of relatively large but cheap PD will be heavy on your maintenance infrastructure.Except that isn't really a concern because railgun stations are so cheap that you can easily afford to give them 20+ years of maintenance life and just scrap them when the time runs out. As it stands, railguns are hilariously good at beam point-defence and dominate over the other options available at low tech level. Even worse, the lowest tech railguns are the most effective, and better tech doesn't really do anything for railgun PD.
I also second the motion to make turret speed additive, but the base tracking speed should probably be retained at 100% of ship speed. I also think that fighters shouldn't be allowed to have turreted weapons - they already get 4x BFC tracking speed for free, giving them turrets would allow them to go up to 16x tracking speed, which seems unfair.
Weapon failure is highly problematic in itself, without reworking a few other things.One of the reasons for the failure mechanic is to prevent extreme kiting. Low-tech railguns will never be able to kite anything, so this is ok in my opinion.
A low-tech railgun costs almost nothing, weapon failure is irrelevant. A full-size quad Gauss turret may not even be worth firing against an individual small missile, better to tank the hit.
A high-tech laser may not be worth firing at the end of its range, causing more damage to the firing ship on average than to the opponent... but 10 capacitor-1 lasers instead of one capacitor-10 laser incur 10% of the firing costs for a given number of shots.
They still take up space and you no longer get free maintenance from unlimited maintenance stations if you are under a certain size. This means that having lots of relatively large but cheap PD will be heavy on your maintenance infrastructure.
Except that isn't really a concern because railgun stations are so cheap that you can easily afford to give them 20+ years of maintenance life and just scrap them when the time runs out. As it stands, railguns are hilariously good at beam point-defence and dominate over the other options available at low tech level. Even worse, the lowest tech railguns are the most effective, and better tech doesn't really do anything for railgun PD.
One problem here also is that your stations will put strain on the maintenance location even if they have extreme long life or you will have to place them away from that maintenance point which will be a problem unless you are at a fixed point in space... at least it is irritating micromanagement.
It also is against the spirit of the game so you probably should just NOT do it. There are many mechanics in the game that can be GAMED... this is primarily a single player game where you can do whatever you feel is OK.
If you want to go against the spirit of the games mechanics just to get a benefit I don't think Aurora is a good game, there are quite a few loopholes and ways to sort of Game the system.
One of the main problem I have with cost of resources is primarily a gaming issue. Games tend to make more advance technology cost more in resources while in reality this rarely is the case. The cost are generally in development and prototyping, once something are put in to large scale production cost always goes down to roughly the same values as older similar technologies. Sure, high tech equipment tend to make things more expensive and complicated but that is more in man ours and logistical costs, but in time even those things tend to go down in costs. In general a tank 50 years ago was as expensive as a similar tank today to actually produce after say 500 were built.
There also are a reason why there is a very strong focus today on modularity in almost all modern military platforms.
I wish games simulated this better where it is the research and development that is costly but an old ship are still going to cost almost as much to build in terms of resources as a new one.
One problem here also is that your stations will put strain on the maintenance location even if they have extreme long life or you will have to place them away from that maintenance point which will be a problem unless you are at a fixed point in space... at least it is irritating micromanagement.
It also is against the spirit of the game so you probably should just NOT do it. There are many mechanics in the game that can be GAMED... this is primarily a single player game where you can do whatever you feel is OK.
If you want to go against the spirit of the games mechanics just to get a benefit I don't think Aurora is a good game, there are quite a few loopholes and ways to sort of Game the system.
I'm pretty sure the 'move to x Mm orbit' entirely alleviates that issue.
And I disagree. This isn't something to be 'gamed', unless long deployment times are somehow an exploit; it's a clear balance issue that needs to be fixed.
I disagree - a good system is flexible, robust and balanced.
If it's strictly preferable to give ships long mission lives than to invest into the maintenance system, the system is broken.
If it's strictly preferable to make ships fuel-efficient to the point of rendering fuel logistics irrelevant, the system is broken.
Ideally, breaking the usual assumptions would be possible but not the norm - leading to higher total costs or requiring significant design concessions.
With the recent changes to the salvage mechanics when in orbit of a population, can we lug wrecks around with a tug?
That could create a whole new way of salvaging. My tugs are often idle for years, so pulling wrecks to the orbit of a "salvager" planet would be a good job for them.With the recent changes to the salvage mechanics when in orbit of a population, can we lug wrecks around with a tug?
Not at the moment, but it could be added.
That would be pretty cool to see like a production bonus for continuing to build the same design at a shipyard it starts expensive but as you reach serial production the resource costs and production time decrease to show efficiency of manufacture and the progress from experimental to staple of the fleet? but on the other hand, would it handicap the AI? as they are suppose to switch designs more often in this upcoming version, i believe.
I guess if it's coded in there's no compulsion for a player to use it if it doesn't suit their story, so more options are better.Ding ding ding! Here I completely agree. Nothing forces a player to use one method over the other. More options is better.
I think adding a bonus for serial production and a handicap for first-of-class ships makes sense.We already have the retooling for a class thing. It can take over a year to retool a shipyard. So why add a handicap on top? It already is better in some cases to build a new shipyard instead of retooling, to take advantage of the "free" first retool, and this would reinforce that behaviour.
I'd rather just have it as a bonus. Stacking 1% reduction in build cost per item built, up to a max of 5/10/15/20% limited by a tech as a simple idea. So the base price IS your first-of-class cost which reduces for each one you build. Keeps things simpler. Your first in class cost would be per shipyard or per production run then, though.
I think the retooling cost does essentially the same thing and is even simpler than that.
I'd rather just have it as a bonus. Stacking 1% reduction in build cost per item built, up to a max of 5/10/15/20% limited by a tech as a simple idea. So the base price IS your first-of-class cost which reduces for each one you build. Keeps things simpler. Your first in class cost would be per shipyard or per production run then, though..
Quote from: Bremen link=topic=8497. msg116821#msg116821 date=1573158202I think the retooling cost does essentially the same thing and is even simpler than that.
I always thought of the retooling costs as the work required to literally modify the equipment at the shipyard to make a new class. You need to make forms for the hull, jigs for equipment that are unique to classes of ships and supports for the hull before it is complete. You could include first-of-class costs in that as well, and it might be simpler.
I like this idea, and I think it would be easier to implement. The same bonus should also apply to construction time.
Quote from: Rabid_Cog link=topic=8497. msg116820#msg116820 date=1573156889I'd rather just have it as a bonus. Stacking 1% reduction in build cost per item built, up to a max of 5/10/15/20% limited by a tech as a simple idea. So the base price IS your first-of-class cost which reduces for each one you build. Keeps things simpler. Your first in class cost would be per shipyard or per production run then, though..
I like this idea, and I think it would be easier to implement. The same bonus should also apply to construction time.
Okay, I'll queue 5000 Research Labs with 1 Construction Factory. Of course I don't have the minerals to build 5000 RL but that's okay, 1 CF won't get them build anytime this millennium so that's not a problem. It WILL get maximum efficiency bonus at which point I can throw as many CF at it as I want to exploit that bonus. And if I need them for something else, I'll just leave that 1 CF there to maintain the serial production bonus.
This sort of system was used in Hearts of Iron 3 (and slightly modified in 4 I believe) and it was nothing but exploit city for multiplayer and yet another way human player was overpowered compared to the AI.
Serial production bonus CAN work with shipyards because you can't move slipways to another shipyard. But with construction/fighter/ordnance factories as well as research, fields where you can move factories and labs freely around, it wouldn't work.
It's not an end of the world issue, because naturally a player can disregard it and not abuse it - like some players do with scientists and the 0 RL project exploit - but I'm little wary of adding clear and obvious exploits to the game when the feature itself isn't really necessary.
If we take factories then you could have a gearing bonus based on some technology and time you spent building something. You just store the gearing bonus of each item line with an amount of factories applied to it. When you add factories you degrade the gearing bonus accordingly and if you remove factories it stays the same. So now you need to be careful when and if you want to really increase the number of factories for that line.
QuoteIf we take factories then you could have a gearing bonus based on some technology and time you spent building something. You just store the gearing bonus of each item line with an amount of factories applied to it. When you add factories you degrade the gearing bonus accordingly and if you remove factories it stays the same. So now you need to be careful when and if you want to really increase the number of factories for that line.
--- This is what Hearts of Iron IV did, it works quite well actually. Never played Hearts of Iron III, so I can't say anything about that. In Hearts of Iron IV, however, I have sunk a considerable amount of time into that game and can say this:
- Production is based on per factory assigned.
- Time spent on the item being produced increased Production Efficiency.
- Switching items would remove efficiency, not sure if switching to similar equipment (like Infantry Equipment 1 to Infantry Equipment 2 for example) diminished the penalty or not.
- There were several techs supporting this, with a few modifiers of note.
- Cost did NOT decrease with efficiency gain, but rather the number of units produced per line. (Speed)
--- The modifiers were Production Efficiency, Efficiency Gain Speed (basically how fast you could "tool up" a line), Efficiency Cap, and Efficiency Loss (How much you lost when switching to a different item.)
It can only affect shipyards because individual factories are not tracked and I'm assuming Steve doesn't want to put in that level of fidelity. If you don't track individual factories, you leave the system open for the sort of abuse I described above.
What's the deviation between classes so that they still qualify for faster construction? Same as for construction in general, ie 20% BP difference? Or was it 10%, can't remember now. Should it be something else? Will this lead into container/bulk type ships, ie you design a template ship that never gets built that has generic engines and sensors etc and then you build the 3-5 different varieties of it that are only different from the template by the allowed 10-20% BP. Which can lead to a situation where not only (most) of your shipyards can build (most) of your ships, but they do it (possibly much) faster.
I'm sure other people can think of more pitfalls in such a system. I don't mean that a feature needs to be balanced to boredom, but that we as a community think things through as much as possible, to make things easier for Steve.
I agree with the faster (but not cheaper) approach, with an option to turn it on or off similar to Fleet Maintenance.
I agree with the faster (but not cheaper) approach, with an option to turn it on or off similar to Fleet Maintenance.
We do already get a cheaper average ship with repeated runs once you factor in the retooling costs as every ship off the line then spreads that retooling cost. Personally I think that is enough benefit already.
I was looking at the Shock damage changes for C# and did some calculations and trying to translate that to the actual game.
I think there is a problem with allowing shock resistace to scale linear with ship size against damage.
First of. . . damage does not scale up as fast as ship sizes does and they don't scale linear in the same way ether.
Once you get to 30k+ tons on ships they become almost impervious to shock damage (depending on tech level of course). If you bring a laser that do enough damage you are more likely to punch through their armour rather than doing any shock damage. A ship at say 40000t which is not unreasonable at Magneto Plasma level technology would still be impervious to a similar tech level advanced spinal laser at point blank range (38cm laser that does 38 damage which is only 4. 75% of the ships size). If you give the ship its 15+ layers of armour it needs to withstand that at point blank range you need close to 25% of the internal space dedicated to armour alone. Creating a missile at almost any level become more or less impossible to do shock damage at even modestly big ships at most tech levels.
Most smaller ships are way more susceptible to shock damage, especially as technology rises.
I would like a shock resistance technology to make shock damage more consistent with technology increase. As such technology is integral to a ships hull you can't refit such technology and it is based on when the ship is built. You could also tie a ships resistance to some degree to ship maintenance as well. Then you could make the curve for size more consistent with weapon damage increases.
Or some such. . .
In the spirit of shock damage I also believe that components such as sensors should be much more likely to be damaged by shock damage. . . or damaged in general. I don't think that size is a good measurement of how likely a component is to be targeted for damage as some systems just are way more fragile or interlinked within a ship and thus way more likely to get damaged from incoming damage. Sensors on a real ship are the most vulnerable part of a ship, even a modern battle tank have so many sensors that even a machine gun can perform a mission kill on a heavy battle tank by degrading their sensors to the point they need to retreat, this is a huge concern on modern vehicles.
In the spirit of shock damage I also believe that components such as sensors should be much more likely to be damaged by shock damage... or damaged in general. I don't think that size is a good measurement of how likely a component is to be targeted for damage as some systems just are way more fragile or interlinked within a ship and thus way more likely to get damaged from incoming damage. Sensors on a real ship are the most vulnerable part of a ship, even a modern battle tank have so many sensors that even a machine gun can perform a mission kill on a heavy battle tank by degrading their sensors to the point they need to retreat, this is a huge concern on modern vehicles.
In the spirit of shock damage I also believe that components such as sensors should be much more likely to be damaged by shock damage... or damaged in general. I don't think that size is a good measurement of how likely a component is to be targeted for damage as some systems just are way more fragile or interlinked within a ship and thus way more likely to get damaged from incoming damage. Sensors on a real ship are the most vulnerable part of a ship, even a modern battle tank have so many sensors that even a machine gun can perform a mission kill on a heavy battle tank by degrading their sensors to the point they need to retreat, this is a huge concern on modern vehicles.
It's the same thing with WW2 warships. 300mm+ of armor doesn't help the ship a whole lot when it's rudder is jammed, when it's range finders + radars are shot to pieces, electrical power is disabled or when the parts outside the armored box is on fire / flooding due to smaller caliber fire.
It renders the vehicle effectively blind and possibly worst case even unable to navigate at all.
Steve said "colony" not "population" so I see no reason why it shouldn't apply to automated mining outposts or DSTS.
Regarding 'tractor any ship' orders: It also protects the sanity of other players. I can see myself using it very often when moving terraformers and fuel harvesters around.
Does the new rug order tractor one ship per tug, or one ship per TG?
Does releasing the tractored ship remove it from the task group (creating a new one, I assume?). If so you could set a single tug to grab ships from a task group, take it somewhere, and release, and set it to repeat orders.
Does releasing the tractored ship remove it from the task group (creating a new one, I assume?). If so you could set a single tug to grab ships from a task group, take it somewhere, and release, and set it to repeat orders.
Yes, that it how it will work.
Is it possible to set the destination to be another task group, assuming it exists? If I'm moving 50 gas harvesters to the next system over, I don't want to end up with 50 TG in that system that I need to manually merge if I can help it.
Is it possible to set the destination to be another task group, assuming it exists? If I'm moving 50 gas harvesters to the next system over, I don't want to end up with 50 TG in that system that I need to manually merge if I can help it.
If I recall correctly, that is how it works in VB Aurora. So hopefully it is possible in C#, too.
Does releasing the tractored ship remove it from the task group (creating a new one, I assume?). If so you could set a single tug to grab ships from a task group, take it somewhere, and release, and set it to repeat orders.
Yes, that it how it will work.
Is there any chance of making it work so that if the location of the order is an existing TG, it will release the ship into that TG instead of creating a new one? Or is it already how it works?
Hi Steve,
Is March 20th the date you will be going on leave? Because if it is, consider releasing at least a test build for the public before then. After all, I have no doubt that many issues will only show up once you have hundreds of people playing your new version :)
that's an awesome RV, do you have a shakedown trip preplanned for it or just going to make an Impromptu journey?
I think people is overthinking the RV thing, it's still UK, there are 130 rainy day a year and they most happen to be weekendsEspecially bank holiday weekends! ;D
And particularly in ScotlandI think people is overthinking the RV thing, it's still UK, there are 130 rainy day a year and they most happen to be weekendsEspecially bank holiday weekends! ;D
And particularly in ScotlandI think people is overthinking the RV thing, it's still UK, there are 130 rainy day a year and they most happen to be weekendsEspecially bank holiday weekends! ;D
And particularly in ScotlandI think people is overthinking the RV thing, it's still UK, there are 130 rainy day a year and they most happen to be weekendsEspecially bank holiday weekends! ;D
No. Really? /sarcasm.
My dad used to say of Scotland "sometimes there are WHOLE DAYS where it doesn't rain!"
Mind you I think we could have done with a little of that in Canberra over the holiday period. OTOH, yesterday was a different matter.
Slainthe
Mike
I spent the Summer in Glasgow one year (1994?) and it hardly rained the whole time - I thought the weather was lovely! I'm convinced that these stories of rainy Scotland are a disinformation campaign on the part of the locals with the goal of keeping European hordes from over-populating their fair country :)
On the "Do Not Promote" flag: Is this also known as "The Kirk Option"?
John
I like what I see as well, particularly the fact that REALLY Xenophobic races are going to needs a YEARS long effort to change their mind. I suppose we'll know a bit more once we see what the menu of other interactions, claims, and the like will be.
One basic question I have is that only one Diplo Module active per system/race? I can't have multiple stacked diplomatic modules accumulating points? Also will it be only one diplo mission ship at a time - I mean, I can't have three separate diplomatic ships in three different systems building points for the same race?
I'm liking that diplomacy model - seems like a good simple starting point, but one that should have a lot of options to create good gameplay.
That said, I'm going to OCD about one thing. The formula:
> Diplomacy Points = ((Diplomacy Bonus * 4) + 1) * 100 * (1 – (Target Racial Xenophobia / 100))
should clearly read instead:
> Diplomacy Points = ((Diplomacy Bonus * 4) + 1) * (100 – Target Racial Xenophobia)
(Yes, I'm aware that this is totally irrelevant, and that I'm being obnoxiously anal-retentive)
You can have multiple qualifying ships with modules but only the commander with the highest rating will be used. I decided it wouldn't be realistic that (for example) you could sent three different delegations to an alien race to make relations improve three times faster. Stacking ships to generate more points would also unbalance all the others mechanics that increase or decrease point. Modules also don't stack on the same ship.
An example of a negative impact is combat. Negative diplomatic points are suffered due to damage inflicted by an alien race using the following rules:
Each point of damage from a hit that only damages shields: 0.1
Each point of damage from a hit that causes armour damage but not internal: 0.25
Each point of damage from a hit that causes internal damage: 1.0
Each point of space-based damage to populations, ground forces or shipyards: 1.0
Each ton of ground forces destroyed in ground-based combat: 0.01
QuoteAn example of a negative impact is combat. Negative diplomatic points are suffered due to damage inflicted by an alien race using the following rules:
Each point of damage from a hit that only damages shields: 0.1
Each point of damage from a hit that causes armour damage but not internal: 0.25
Each point of damage from a hit that causes internal damage: 1.0
Each point of space-based damage to populations, ground forces or shipyards: 1.0
Each ton of ground forces destroyed in ground-based combat: 0.01
Just trying to clarify a minor point: to have a specific example, if a hit does 25 damage that brings down the last six points of shields, mostly slags armour, but two points of damage penetrate and kill internal components (but don't cause explosions)... is that 25 * 1, or pro rata such that 6 * 0.1 + 17 * 0.25 + 2 * 1 = 6.85?
I'm liking that diplomacy model - seems like a good simple starting point, but one that should have a lot of options to create good gameplay.
That said, I'm going to OCD about one thing. The formula:
> Diplomacy Points = ((Diplomacy Bonus * 4) + 1) * 100 * (1 – (Target Racial Xenophobia / 100))
should clearly read instead:
> Diplomacy Points = ((Diplomacy Bonus * 4) + 1) * (100 – Target Racial Xenophobia)
(Yes, I'm aware that this is totally irrelevant, and that I'm being obnoxiously anal-retentive)
If you have forces or a population in a system that is claimed by an NPR and you are detected and you are currently viewed as neutral or friendly, the NPR will issue a warning which will appear as an event.So you can colonize an allied race's territory?
...
Allied Races do not receive warnings as they can freely enter the NPR territory.
While in general the new diplomacy rules sound good, what will happen in starts with multiple races on e.g. earth? Would everybody need to struggle to get a diplamacy ship (or base) running to make sure the whole planet does not erupt into war instantly? Is the diplomacy module even a starting tech? Sounds a bit strange that earth diplomats suddenly refuse to talk to each other without a fancy new space embassy ;). Another thing that might be a good idea is that races starting on the same planet and having the same species should be able to communicate from the start. While this is not that important for player starts actually (space master, set fixed diplomatic rating and so on), it might be important for the cases where NPRs are created in multiples on newly discovered planets (which is a really nice feature, by the way).
So you can colonize an allied race's territory?
If an alien race suffers damage from one of your ships that it can't see (lasers/missiles from outside of detection range), do you still suffer the relationship hit?
I.e. is privateering a thing? ;D
If an alien race suffers damage from one of your ships that it can't see (lasers/missiles from outside of detection range), do you still suffer the relationship hit?
I.e. is privateering a thing? ;D
Realistically I think you should suffer full relationship hit.
It would be fairly trivial for anyone smart enough for space travel to figure out who attacked you based on attack patterns, explosion signatures, analysis of wreck/ship damage, monitoring of jump point traffic and using logic/exclusion of who could have committed the attack. Even if they can't prove it being 95-99% sure you did it would be almost the same as having proof relationship wise.
There might be some edge cases like if you can emulate the attack originating from someone else or make it looked like a rogue vessel of the own forces did it, but these are one time and edge cases enough that just having SM options available to either disable relationship changes or resetting them back should be plenty enough.
If I build a super sneaky stealthy assasination ship with custom built missiles that are only used on that ship, then I feel like I could probably get away with sniping somebody without them really knowing who did it.
I don't necessarily think that that is anything that NEEDS to get added to the game, but it seems perfectly feasible to me.
I like the changes discussed in latest Diplo 3 post - specifically I like the idea that in order to secure a claim on a world, you are best off doing a 'show of force' and that it actually means something in terms of game mechanics. I think it is a nice synergy between the diplomatic and tactical/operational part of the game. One side benefit is that I'm thinking 'galactic' reconnaissance in term of scout out adjacent systems and gathering intel on capabilities is going to be a very important component to making sure your diplomatic demands are well thought out and not a disaster in the making.
Would be nice if we could tick a box that says 'restate system claim every day/week/month/year' with a notification in the log as to whether or not it was followed. Because there's no way any nation would let go of its claims that easily, it'd just keep making the claim until the matter is resolved in negotiations. That does mean that diplomatic relations can tank quite rapidly, depending on how loudly and often the claim is stated.
I understand things like 'maximum race PPV value allowed in system' negotiations are entirely too complex for the current intended incarnation of the diplomacy system, but it could be an interesting end point for contested systems between allied races. A forced relocation option for dumping populations you don't want from recently diplomatically acquired systems would also be nice.
A forced relocation option for dumping populations you don't want from recently diplomatically acquired systems would also be nice.
How is the military strength factor determined for diplomatic claims? Is it based off the player's ships in system, or the total the NPR has currently detected? Or all player ships the NPR has encountered? Is having a fleet in-system a sufficient show of force, or do the NPRs need to actively detect them?
Would be nice if we could tick a box that says 'restate system claim every day/week/month/year' with a notification in the log as to whether or not it was followed. Because there's no way any nation would let go of its claims that easily, it'd just keep making the claim until the matter is resolved in negotiations. That does mean that diplomatic relations can tank quite rapidly, depending on how loudly and often the claim is stated.
Would be nice if we could tick a box that says 'restate system claim every day/week/month/year' with a notification in the log as to whether or not it was followed. Because there's no way any nation would let go of its claims that easily, it'd just keep making the claim until the matter is resolved in negotiations. That does mean that diplomatic relations can tank quite rapidly, depending on how loudly and often the claim is stated.
That would be a good way to start a war, but you don't need to do the above to achieve that. Just fire at a neutral ship.
If you ask the NPR to leave this week and it refuses, then it is going to refuse next week as well unless something significant has changed. By asking every week you will be damaging relations with no benefit, unless your goal is to damage relations. You should ask again when you think the NPR might make a different decision.
You use both "alien population factor" and "player factor" in the rules post. I suspect these are the same thing, but I was reading "alien" as "AI" ('cuz they're aliens to us humans). Might be a good idea to use "player" throughout to clear up the ambiguity of just who's the alien.
John
the demand success not considering relationship seems a little weird, npr at war have option to react differently to claims, up and including sending a fleet in the contested area, also they're already pissed at you so might want to be much less complacent to small claims
It is based on all military-engine ships that the NPR has detected and has not seen destroyed. . .
Will the NPR be able to identify a ship as the same one after a refit or would that inflate your threat level?
What about scrapped or destroyed out of sight ships, will they keep being counted forever? Maybe a time limit for how many years they are seen as relevant unless a refitted version is spotted. If nothing else they would eventually be too old to be any threat.
Will the NPR be able to identify a ship as the same one after a refit or would that inflate your threat level?
What about scrapped or destroyed out of sight ships, will they keep being counted forever? Maybe a time limit for how many years they are seen as relevant unless a refitted version is spotted. If nothing else they would eventually be too old to be any threat.
These are very good questions.
Regarding the "please don't colonize" vs "you can pass through" issue... isn't that a matter of specific pacts? I mean, if a nation wants a system to be exclusively theirs, I cannot ever see them granting free passage through it.
Only in case of a trade pact of some kind, and/or some other "open borders" treaty. In any other situation, I think a nation would want its "claimed" systems to be completely empty of foreign ships. Like any modern nation does.
What about Panama Canal system, or Suez Canal system, or St. Lawrence Seaway system? What about 'Huge Chunk of the Pacific Ocean between Hawai'i and California' system? I can think of many cases where two empires basically form an 'X' through a starless nexus, crappy little red dwarf, or 'interesting space terrain' system and don't want the other one to colonize or build bases there, but recognize their right to pass from A to C.
In a perfect world, I'd also love to set up trade orders at particular colonies, to be fulfilled by nations I have trade treaties with (i.e., open borders for civilian ships only, or maybe civilian+commercial), in exchange for Wealth, not just my own civilians.
The point about removing ships if they have not been detected for a long time - perhaps 5 years - is a good one. I'll add that when I get home tonight.
When 100 Alien Race Intelligence Points have accumulated, a check is made for any intelligence gained. This is the same check as in VB6 for espionage teams and can result in new technology, survey data, new system knowledge or details of an enemy ship class. I will probably add information on alien sensors, ground units and populations to that list.Nothing about numbers of ships or the existence of specific ships.
The new independence/rebellion possibilities look amazing.
Given that this spawns a new race that's a copy of the old race, if a player or NPR resubjugates a colony he will now have two (identical) races in his empire, and in order to move 'original race' colonists back to the recently resubjugated body will have to start a new colony, correct?
It seems useful to have a system of re-identification of the two races so problems can be avoided in the long run. Probably only after the resubjugated colony reaches regular imperial population status, and probably only if the two races are actually mechanically identical would be best.
The new independence/rebellion possibilities look amazing.
Given that this spawns a new race that's a copy of the old race, if a player or NPR resubjugates a colony he will now have two (identical) races in his empire, and in order to move 'original race' colonists back to the recently resubjugated body will have to start a new colony, correct?
It seems useful to have a system of re-identification of the two races so problems can be avoided in the long run. Probably only after the resubjugated colony reaches regular imperial population status, and probably only if the two races are actually mechanically identical would be best.
I mentioned something similar about communications in the suggestions page. I really like your idea of re-identification - I think it would be hard to code though given the movement of populations around the Empire which would inevitably happen. I personally would like to see the racial modifiers (xenophobia, expansionism, etc - but same environmental tolerances) change to reflect the new colonies's ideology that made them different and want to rebel in the first place and if that happens, reintegration as the original race might not be possible.
Even though they are two different empires, they are still the same species. So you can re-capture the colony, it is immediately part of your Empire again, albeit with a low political status. You may have to create a temporary colony to hold ground forces as part of an invasion, but that is no different that attacking any alien colony.
The new independence/rebellion possibilities look amazing.
Given that this spawns a new race that's a copy of the old race, if a player or NPR resubjugates a colony he will now have two (identical) races in his empire, and in order to move 'original race' colonists back to the recently resubjugated body will have to start a new colony, correct?
It seems useful to have a system of re-identification of the two races so problems can be avoided in the long run. Probably only after the resubjugated colony reaches regular imperial population status, and probably only if the two races are actually mechanically identical would be best.
I mentioned something similar about communications in the suggestions page. I really like your idea of re-identification - I think it would be hard to code though given the movement of populations around the Empire which would inevitably happen. I personally would like to see the racial modifiers (xenophobia, expansionism, etc - but same environmental tolerances) change to reflect the new colonies's ideology that made them different and want to rebel in the first place and if that happens, reintegration as the original race might not be possible.
Will we be able to decide if the new independent colony can be managed by the player or spawned as an NPR?
I guess that if you run a multi-faction campaign you might still want to control the new independent colony yourself, in some instances you might want it to be under AI control.
This may be too much of an ask at present, but I would dearly love if a colony's mineral, industrial and potential naval situation would influence likelihood of rebellion.
Even better, if several colonies relatively nearby one another (say, within two systems? or some other such limit) both run the risk of rebellion, maybe they would have a chance to pool their resources for this calculation and both end up as part of the same rebel empire. "I have neutronium and duranium, you have gallicite and shipyards. Separately we would be crushed, but together we could stand up to the tyrant!"
There is a reference to ground units being given to the independent colony. I guess that's for a volunteer secession and not a rebellion? That would feel unfair to lose your garrisoning units if the population revolts.
But then if it revolts without arming instantly troops, the rebellions will be squashed rapidly. So I guess there is a part missing here, will a rebellion generates troops hostile to the occupying power?
There is a reference to ground units being given to the independent colony. I guess that's for a volunteer secession and not a rebellion? That would feel unfair to lose your garrisoning units if the population revolts.
But then if it revolts without arming instantly troops, the rebellions will be squashed rapidly. So I guess there is a part missing here, will a rebellion generates troops hostile to the occupying power?
There is a reference to ground units being given to the independent colony. I guess that's for a volunteer secession and not a rebellion? That would feel unfair to lose your garrisoning units if the population revolts.
But then if it revolts without arming instantly troops, the rebellions will be squashed rapidly. So I guess there is a part missing here, will a rebellion generates troops hostile to the occupying power?
Historically, revolts that failed to acquire troops themselves were crushed, and it was very common for revolts that weren't crushed in a week or two to have either acquired weapons for their own, or managed to convince at least part of the local garrison to take their side. And often both.
The title of the new race will be based on the name of the newly-independent population.
As long as we can rename them, when under player control, it's all good.
Yeah, not untrue but much less true in the modern era. Ancient armies weren’t paid (they plundered) and typically didn’t have a unifying subordinate interest to the state. I suspect Aurora armies would be professional armies in the 21st century sense who might quit the field but aren’t going to turn en masse and give up their weapons and equipment to rebels. Of course, this is all RP dependent on what your flavor is....
Maybe they should all be based on different variations of the People's Front of Judea :)
Maybe they should all be based on different variations of the People's Front of Judea :)
But surely not variants of the Judean People's Front.
For a start they've left us "huge tracts of land".Maybe they should all be based on different variations of the People's Front of Judea :)
But surely not variants of the Judean People's Front.
But what have the Precursors ever done for us?
I would personally suggest that the majority of the garrison stay loyal in those cases for now (though maybe they get swamped by angry heavily armed locals). My general understanding is the sympathy of the garrison to the locals cause tends to have a lot to do with where the troops were raised from. If they were recruited from that planet they are much more likely to side with the locals than if they came from somewhere different.
If they mostly stay loyal for now, then perhaps loyalty based on where the troops came from could be added in as a feature later.
In my defense I tend to headcanon that they do the current US federal troop practice of putting soldiers families in their home bases, and then troops will rotate out into a deployment and others will rotate back in without necessarily dissolving or relocating the unit that they are a part of. In other words I tend to assume that is generally happening on a slow burn, since that tends to be necessary anyways to give people a break.
For a start they've left us "huge tracts of land".Maybe they should all be based on different variations of the People's Front of Judea :)
But surely not variants of the Judean People's Front.
But what have the Precursors ever done for us?
For a start they've left us "huge tracts of land".Maybe they should all be based on different variations of the People's Front of Judea :)
But surely not variants of the Judean People's Front.
But what have the Precursors ever done for us?
Ok, I'll give you that.
But beside huge tracts of land, what have the Precursors ever done for us?
Quote from: Tikigod link=topic=8497. msg118555#msg118555 date=1580830164Quote from: MarcAFK link=topic=8497. msg118529#msg118529 date=1580795775Quote from: Father Tim link=topic=8497. msg118527#msg118527 date=1580793051For a start they've left us "huge tracts of land".Quote from: Hazard link=topic=8497. msg118522#msg118522 date=1580778788Quote from: Steve Walmsley link=topic=8497. msg118496#msg118496 date=1580744100Maybe they should all be based on different variations of the People's Front of Judea :)
But surely not variants of the Judean People's Front.
But what have the Precursors ever done for us?
Ok, I'll give you that.
But beside huge tracts of land, what have the Precursors ever done for us?
What about the jump gates they left behind?
For a start they've left us "huge tracts of land".Maybe they should all be based on different variations of the People's Front of Judea :)
But surely not variants of the Judean People's Front.
But what have the Precursors ever done for us?
Ok, I'll give you that.
But beside huge tracts of land, what have the Precursors ever done for us?
What about the jump gates they left behind?
For a start they've left us "huge tracts of land".Maybe they should all be based on different variations of the People's Front of Judea :)
But surely not variants of the Judean People's Front.
But what have the Precursors ever done for us?
Ok, I'll give you that.
But beside huge tracts of land, what have the Precursors ever done for us?
What about the jump gates they left behind?
Well that's a given isn't it?
Right, fine.
Though beside the huge tracts of lands and the jump gates they left behind....
What have the Precursors ever done for us?
So, I'm curious about the whole diplomacy thing. You need to have a detected ship in an alien system, but you lose diplomatic points and get asked to leave if they detect your ship? How is one supposed to do diplomacy, then? There should be a way to ask for permission to stay.
About the new post on Star System Design, it made me think of 2 facts I recently read in a scientific magazine, perhaps Steve will want to use them to nudge probabilities so to stick more to the most recent views of the scientific community on star systems:
- Orange dwarf stars are much more chance to harbor planets with some life compared to red stars, because the latter produce much greater (or is it during a much longer time) deadly radiations whereas orange stars are much 'quieter' on that
- systems with multiple stars have lower chance to have planets (because accretion process is harder with multiple stars)
I won't cite my source, sorry I don't have the magazine before me, but if you don't want to trust me on these facts (which I understand) googling them should not be too difficult.
cheers
In the new diplomacy system it looks to me that an NPR never will declare a system it shares as its capitol with another race as worthy of fully conquering. For RP reasons that option might be interesting, so having an option that overrules the NPR calculations in SM mode might be worth considering.
In the cancel star option what happen if we cancel a star with a planet gravitating having a population?
Example, I jump in a System which has a second star orbiting 30LY away and the system has generated an NPR on one of the planets there.
Did you test the above yet?
thanks
I'm pretty sure we could already delete (non-primary) stars in VB6 (I've used it to get rid of annoying super-distant binary systems), so we've had the opportunity to mess up our games for a while.
The new system updates options look great, no more constant generating of systems when you are trying to find a home for a non Sol player race.
Assume the TN materials generator can still be re-run on any planets at set up stage?
The Add Lagrange button adds a Lagrange point to the currently selected body, even if it would not normally qualify for one.
Maybe an option to remove a whole ring of asteroids could be added? Removing all of those 500 asteroids you just accidentally created might be quite the chore otherwise ;). Would also help with the times where large amounts of them are created so far away from the star they won't matter anyway.
EDIT: Asteroids now have a belt identifier, so I will be able to delete an asteroid belt.
Reading through the change list, I played around with a few paper designs and made a few calculations. Overall impression: The new ruleset seems less robust in some ways. I mentioned some of the points earlier, sorry for the repetition...
For point defence weapons, which will be firing many many shots at low hit rates, cost-effectiveness will be hugely important: weapon cost is directly proportional to "ammunition expenditure". This mostly kills long-ranged weapons for area defence, except as a last resort.
Area defence with small weapons remains useful for very fast interceptors that can keep pace with enemy missiles, assuming that's still achievable.
Despite the reduction of Gauss research costs and the increased efficiency of turret gear, bottom-of-the-barrel railguns may be preferable to anything else as point defence because of breakdown costs.
Similar considerations apply to long-ranged beam combat, because we also have low hit rates here. Shooting near the limit of (balanced-research) particle beam range would be harder on the firing ship than on the target. Highest priority would be anything that improves relative hit rate - fire control range and E(C)CM rather than the weapons themselves, probably being shield-heavy (allows suffering no real damage at closer range, saving wear and tear on the guns). If we can control the range without very stressed and fuel-hungry engines, we may favour slow-firing weapons - with most lines, 5 C1 weapons will incur 1/5 of the costs per shot than 1 C5 weapon.
Encouraging holding fire when hit chances are low is a nice concept, but problematic in Aurora because of the very low beam ranges. Beam fring rates are comparable to 20th century wet navy ships, but the difference between extreme and modest range against a retreating target can be closed in seconds rather than hours. Long-range shots with most lines are penalised in terms of damage as well as accuracy, further shortening effective range if there's any meaningful cost to firing a weapon.
Changes to missile launchers strongly favours something that was first among equals anyway: Box launchers in parasites (possibly engineless or otherwise bare-bones) to get around reloading limits.
Somewhat-reduced launchers become bulkier, full-sized ones suffer most from weapon malfunctions, directly-mounted box launchers are now dangerous (and another RP sink to only mitigate the risk somewhat).
New sensor model overwhelmingly favours small ships when it comes to mutual detection range. This pretty much solves missile-vs-missile combat from the get go, if that remains relevant at all (lack of salvo restriction makes lots and lots of cheap flak even more viable. We also lose point blank missile fire - imo, that was a good desperation measure that was more likely to breathe life into an otherwise one-sided situation than to be a balance problem, and also gave CIWS some validity).
Changes to fuel logistics strongly encourage ruthlessly optimising designs for fuel efficiency, which imo was already very attractive (tonnage efficiency suffers, but not cost efficiency). Now we have a bunch of techs lines soaking up RP and some logistics concerns that we can simply evade at design time, without any major concessions.
Likewise, getting propulsion design slightly wrong will be even more costly.
Changes to maintenance, especially the way MSPs are handled, seems to encourage ignoring the system. Plentiful engineering, scrap or abandon/salvage at end of life. Used to be a viable niche choice, now it seems more efficient than playing by the system.
Also not helpful: New components encourage large ships, and as I understand it the equipment failure system still gives up when faced with large ships carrying many cheap components. This is especially relevant combined with large low-tech weapons being less affected by weapon failure.
I'm excited about ground combat, AI changes, varied NPR design themes, more fleshed-out diplomacy, performance and other quality-of-life improvements...
but many basics pertaining to ship design, one of the core strengths of the game, seem less open-ended despite added complexity, and more prone to "one right way" rather than a wide range of reasonable trade-offs with different soft counters. Furthermore, the favoured one often seems unintuitive.
A planet with say a 5000t maintenance facility could have unlimited numbers of super cheap PD satellites and ships also could carry them although you still need to pay the engine cost, but they are still effective.
A planet with say a 5000t maintenance facility could have unlimited numbers of super cheap PD satellites and ships also could carry them although you still need to pay the engine cost, but they are still effective.
I feel the need to point out thats no longer how maintenance works (and rightfully so if you ask me).
But we don't need the shipyards for the Overhaul... or was this changed in C#?
It is interesting though what happens if you Overhaul a ship at a site that is over-stacked, I will look though the change list and see if Steve mentioned that.
Encouraging holding fire when hit chances are low is a nice concept, but problematic in Aurora because of the very low beam ranges. Beam fring rates are comparable to 20th century wet navy ships, but the difference between extreme and modest range against a retreating target can be closed in seconds rather than hours. Long-range shots with most lines are penalised in terms of damage as well as accuracy, further shortening effective range if there's any meaningful cost to firing a weapon.This I do not understand. You cannot make a blanket statement like that since you don't define engines. Yeah, closing speed could be seconds. It could be hours too if one side is running away and the other side is gaining only very slowly. Maybe it'll be 20 minutes, which gives quite a number of opportunities for long-range sniping.
Ship AchievementsWould carriers get the achievements based on the actions of the parasite craft assigned to them?
All the medal conditions that potentially apply to ship commanders are recorded for the ship as well. This is maintained separately from the ship commander, so when a commander moves on to a new ship, the current ship retains its achievements, which will continue to increase under the next commander. A ship does not need a commander for the achievements to be recorded.
Quote from: Steve WalmsleyShip AchievementsWould carriers get the achievements based on the actions of the parasite craft assigned to them?
All the medal conditions that potentially apply to ship commanders are recorded for the ship as well. This is maintained separately from the ship commander, so when a commander moves on to a new ship, the current ship retains its achievements, which will continue to increase under the next commander. A ship does not need a commander for the achievements to be recorded.Off-Topic: show
Quote from: Steve WalmsleyShip AchievementsWould carriers get the achievements based on the actions of the parasite craft assigned to them?
All the medal conditions that potentially apply to ship commanders are recorded for the ship as well. This is maintained separately from the ship commander, so when a commander moves on to a new ship, the current ship retains its achievements, which will continue to increase under the next commander. A ship does not need a commander for the achievements to be recorded.Off-Topic: show
Until this email, only the parasite received the achievement :)
I've now added a separate 'Strike Group' tracker as well. The parasite still gets the credit, but the assigned mothership now gets a separate credit flagged with (SG) for strike group. Separate achievement entries are shown for the carrier itself and the strike group, even if they are the same achievement. So if a Battlestar has destroyed 10,000 tons of shipping directly and its Vipers have destroyed 20,000 tons, the achievement list for the Battlestar will show:
Military Shipping Tonnage Destroyed: 10,000 tons
Military Shipping Tonnage Destroyed (SG): 20,000 tons.
Quote from: Steve WalmsleyShip AchievementsWould carriers get the achievements based on the actions of the parasite craft assigned to them?
All the medal conditions that potentially apply to ship commanders are recorded for the ship as well. This is maintained separately from the ship commander, so when a commander moves on to a new ship, the current ship retains its achievements, which will continue to increase under the next commander. A ship does not need a commander for the achievements to be recorded.Off-Topic: show
Until this email, only the parasite received the achievement :)
I've now added a separate 'Strike Group' tracker as well. The parasite still gets the credit, but the assigned mothership now gets a separate credit flagged with (SG) for strike group. Separate achievement entries are shown for the carrier itself and the strike group, even if they are the same achievement. So if a Battlestar has destroyed 10,000 tons of shipping directly and its Vipers have destroyed 20,000 tons, the achievement list for the Battlestar will show:
Military Shipping Tonnage Destroyed: 10,000 tons
Military Shipping Tonnage Destroyed (SG): 20,000 tons.
Since fleets are not permanent structures, it's probably impossible or not practical, to maintain such tracking. For admin commands, tied as they are to Naval Headquarter buildings, it might be feasible. In that case, you could name the lowest admin-level "7th Fleet" and it's the Aurora equivalent of shore-based HQ/support element for the ships that go out in harm's way. That way it doesn't matter which ships are part of "7th Fleet" over the years, it's the admin command that racks up achievements.
Iranon, I agree that area defence with large beam weapons is now even more useless but going from 1% usability into 0.5% usability is not that big of a difference. Area defence beams were always a gimmick that barely worked at all. Adding the failure rate on top doesn't really change the picture, in my opinion.
OTOH, for planets/moons/asteroids/comets it actually becomes more valid because AFAIK ground units with STO/CIWS capability do not have a failure rate, they just consume supplies, and you don't need maintenance facilities to take care of them either. So if you were using PDCs on airless moons with long-range lasers/particle beams as area defence, that's still possible.QuoteEncouraging holding fire when hit chances are low is a nice concept, but problematic in Aurora because of the very low beam ranges. Beam fring rates are comparable to 20th century wet navy ships, but the difference between extreme and modest range against a retreating target can be closed in seconds rather than hours. Long-range shots with most lines are penalised in terms of damage as well as accuracy, further shortening effective range if there's any meaningful cost to firing a weapon.This I do not understand. You cannot make a blanket statement like that since you don't define engines. Yeah, closing speed could be seconds. It could be hours too if one side is running away and the other side is gaining only very slowly. Maybe it'll be 20 minutes, which gives quite a number of opportunities for long-range sniping.
Long-range sniping-kiting has always been iffy and this doesn't change in C# and I'm not sure why you seem to be so worried about it. Is it a dominant/favourite playstyle of yours?
As for missile launchers, you're somewhat mistaken. Because even a 5-sec AMM launcher is not going to be firing for hours AND because it is so small, will only consume very small amounts of MSP. I can't see that becoming an issue to the point where players would abandon full-size launchers in favour of box launchers. Bigger launchers are not going to be firing every 5-seconds and the slower they fire, the fewer chances there are for failure. Reduced-size launchers are not significantly bulkier than before - 0.75 remains the same, 0.5 becomes 0.6, 0.33 becomes 0.4 and 0.25 becomes 0.3 - so we would have to crunch some numbers to see how much of a difference it makes on a ship with 20 launchers or 50 launchers. Furthermore, the changes to missiles (more fuel required, no armour, ECM/ECCM) make it so that to me it seems that bigger missiles fired on a slower pace is better than smaller missiles fired more often. With the caveat that an overwhelming alpha strike reigns supreme and always will.
To me, it seems that while the sensor changes favour small ships, the engine/shield/powerplant changes favour large ships. So perhaps large Battlestars equipped with sensor-drones and box launcher-drones will be mechanically the superior option but unless the AI ruthlessly exploits that particular approach with no alternatives, something that I doubt Steve would program, it won't be a problem any more than any of the current exploit-y options.
There are so many changes in C# that I think it's impossible to accurately predict the metagame at this stage since none of us are smart enough to foresee all synergies or surprising possibilities stemming from A interacting with K interacting with Z.
sophisticated beam weapons do little good if their breakdown cost exceed damage dealt to the enemy or ordnance expenditure for missiles.Steve changed the chance from 2% to 1% so I don't think that you should be concerned. In a sense, the "breakdown" chance for missiles is 101% because you always "lose" the missile itself plus the launcher has the same breakdown chance as beam weapons. So missiles will still be an order of magnitude (at least) more expensive than beams.
As a definitely-after-release thing, I want beam weapons (and other maintainable parts) to follow a bathtub curve and have individually-tracked MTBF that is modified by field repairs.
Overly complex? Certainly. But a man can dream.
Questions about Commercial Hangars that I don't think anybody asked.
Will commercial vessels with commercial hangars be able to transit jump points when carrying military-engined vessels?
If so, will transit rules allow for miliary-engined vessels smaller than the largest capacity commercial hangar on an accompanying commercial jump-capable vessel to transit the point without being inside the hangar?
Will commercial hangar-equipped vessels be able to act as "jump tenders" for military-engined vessels which would fit in the hangar?
If hangared transit is intended while unhangared (yet capable of being hangared) transit is not,
it would create a situation where micromanagement of loading/jumping/unloading would be advantageous to the player in order to use a mechanic as is intended, which doesn't seem right.
So, since in C# Aurora our Beam FCS Systems can attack multiple salvos, and since Missile Tracking Bonus has been implemented correctly, I would assume turreted 10cm / 12cm Lasers and Mesons would work well in the Area Defense role, since they could potentially strike multiple missiles before they managed to close the defense envelope. That would also make CIWS much more useful if the Tracking Bonus also applied to them, since they have ECCM and FCS wrapped up into one making them useful for leakers.
Also, I could see CIWS being more useful anyway, since ECM / ECCM has become more powerful anyway.
Transponders
In C# Aurora, transponders will only be detected by races with a Friendly or Allied status.
Transponders
In C# Aurora, transponders will only be detected by races with a Friendly or Allied status.
This saddens me, as exploring with my transponders turned on is how I seek out First Contact and broadcast my (race's) peaceful intentions. We only turn our transponders off when we're going to war.
Will there be some new, simliar mechanic where my ship(s) can sit on a jump point and let the whole system know "Hello! Here we are; come talk to us if you'd like." ?
I would love it if you did. I very much want to have a "We're trying to be as friendly and open and non-sneaky as possible" option -- whether or not the AI considers such actions friendly.
Can you set the Transponder for each ship? Also the mode? I would guess so...
Can you set the Transponder for each ship? Also the mode? I would guess so...
That’s nice. I recall an older function to send out false IDs. Any plans to reactivate that?
I just jumped on a VB6 game to gauge how quickly it took to survey and oh boy, did I forget how quickly it went. Single low-tech survey vessel with low-level officer with survey skill finished Luna in half a day, Mars in 4.5 days. I plan on reducing survey speed to at least 50%.
Often it isn't the actual survey that is time-consuming, but the distance between planets or survey locations. Luna and Mars are small so relatively quick, but a widely scattered asteroid belt can take a while.
In order for survey to feel allot slower I think you will have to increase it by say ten times of so. As Steve said... most of the time the ships is spending moving rather than surveying.
When I start my first serious campaign I will likely crank it up to about x10 and tech cost to about x5 and run multiple factions. I usually feel that technology rush forward a bit too fast and contrary to Steve I like small steps to technology increases. I would not mind that technology had about five times more levels in between the ones we have and then it was about 10 times slower as well. I like a gradual increase in power so differences in tech is not so pronounced, it can sometimes provide very big advantages.
I have no problem with the idea that by the time your battleship get of the dockyard you already have new fresh technology that supersede that ship but the change would not be a huge one. This is pretty much how technology and ships have evolved over most of the modern time.
There is a race level research speed modifier, if I remember correctly
I just jumped on a VB6 game to gauge how quickly it took to survey and oh boy, did I forget how quickly it went. Single low-tech survey vessel with low-level officer with survey skill finished Luna in half a day, Mars in 4.5 days. I plan on reducing survey speed to at least 50%.
Often it isn't the actual survey that is time-consuming, but the distance between planets or survey locations. Luna and Mars are small so relatively quick, but a widely scattered asteroid belt can take a while.
Often it isn't the actual survey that is time-consuming, but the distance between planets or survey locations. Luna and Mars are small so relatively quick, but a widely scattered asteroid belt can take a while.
I have rarely found asteroid belts very useful, at least in vb6 Aurora. Asteroid mining ships require very large shipyards and usually shipyard capability is very limited. Of course, I always start with conventional start so I have to BUILD those shipyards.
Personally I won't obsess over asteroid belts. I will survey comets, but I'm more keen on planets and survey asteroid belts when I have free time or when they're relatively quick (close asteroids).
I don't know, it always feels like in VB6 aurora I use mayyybe one system in 10, because there's some systems that are so good that the others are not worth it. Which is why the possibiltiy of slowing down survey appeals to me, also in order to really slow down jump points survey.
Basically, if I cannot survey that fast, I'm more encouraged to work with the systems I have close by instead of choosing the perfect system 5 jumps from home. Seems interesting to me.
The game details window has an option to change survey speed in the game. 100 is the normal rate. For example, if survey speed is changed to 50, all surveys will take twice as long, whereas if survey speed is changed to 125, surveys will happen 20% faster.
Setting the value to 125 I would have expected it to be 25% faster. Is this a Typo?You get 25% more progress in the same amount of time, but that doesn't mean, that you are 25% faster.
Quote from: Kelewan link=topic=8497. msg120016#msg120016 date=1585302644Setting the value to 125 I would have expected it to be 25% faster. Is this a Typo?You get 25% more progress in the same amount of time, but that doesn't mean, that you are 25% faster.
If you need 500 points to survey and get 100 points per tick, you need 5 ticks.
If you get 125 points per tick, you need 4 ticks for 500 points, which is 20% faster than the original 5 ticks.
Quote from: Kelewan link=topic=8497. msg120016#msg120016 date=1585302644Setting the value to 125 I would have expected it to be 25% faster. Is this a Typo?You get 25% more progress in the same amount of time, but that doesn't mean, that you are 25% faster.
If you need 500 points to survey and get 100 points per tick, you need 5 ticks.
If you get 125 points per tick, you need 4 ticks for 500 points, which is 20% faster than the original 5 ticks.
If something is "100% faster" does this mean progress is gained:
A.) Twice as fast
B.) Is instant
As far as I understand it means A, since if I'm in a car or a train that is 100% faster I don't teleport to my destination.
Your and Steves interpretation would be B Which I don't think makes sense, although I'm not a native English speaker.
No, we are saying A.
As stated in the original post, with 25% more survey points, progress is 20% faster (completed in 80% of normal time). Therefore with 100% more survey points, progress is 50% faster (completed in half the time).
No, we are saying A.
As stated in the original post, with 25% more survey points, progress is 20% faster (completed in 80% of normal time). Therefore with 100% more survey points, progress is 50% faster (completed in half the time).
Instead, with 100% more survey points per unit of time, progress per unit of time is also 100% greater, and moves at twice the speed of normal. This means that the time it takes to complete the survey is half of normal.
Aurora has generally had a sense to me that when it comes to the capital ships, the tech progression system ensures that by the time your capital ships get launched they are already obsolete, with their successor class with better technology being prepared for construction already.
This is not necessarily a bad thing, but it's not necessarily the story you want to tell.
Does the CIC do anything yet?
EDIT: If not, might I suggest the Tactical Bonus affects Initiative? Perhaps also for the Fleet?
Detecting Engine Type
Thermal sensors are able to detect whether a ship moving faster than 1 km/s has military or commercial engines. This information is added to the intelligence for the associated alien class.
The thermal contact strength for a ship will be preceded by "M" or "C" if the engine type for the parent class is known.
NPRs will treat ships without detected military engines that have not demonstrated any weapon capability as 10% of the normal size when assessing their threat level
I was reading the changelog and as a screen reader user i was very happy to see the new text summary windows.
I can't wait for the release and we blind users have our screen readers, optical character recognition and other crazy programs ready to give this game a try!
I wonder if the newest change means that Steve's latest campaign has been flooded with useless scientists.
It certainly doesn't seem like the kind of thing that arises naturally out of testing AI diplomacy. ;D
I'm six years into the campaign and I still don't have a Sensors and Control Systems scientist :)
I wonder if the newest change means that Steve's latest campaign has been flooded with useless scientists.
It certainly doesn't seem like the kind of thing that arises naturally out of testing AI diplomacy. ;D
I'm six years into the campaign and I still don't have a Sensors and Control Systems scientist :)
Probably a late breaking question but looking at the diplomacy posts in the change list, has Peace Treaties been discussed yet? Diplomacy Post #1 talks about it being covered in the future but I didn't see any subsequent posts and was wondering with release coming soon, what was the mechanism for peace treaties in the event of war?
Will an NPR that loses a battle or two adopt a more defensive posture, allowing the relations to reset?
Will an NPR that loses a battle or two adopt a more defensive posture, allowing the relations to reset?
Yes, that will happen naturally as the NPR loses 'spare' fleets that can used offensively. However, I will code some war weariness or sensitivity to losses post-release.
An idea could be adding some "warscore" value once the war start, which is set at value 0 for both the parts (or the alliances) and progress toward positive or negative depending how many and which ship one of the side lose
I’m a huge Paradox fan, and their warscore mechanic generally works for them. . . but they’re a huge developer with lots of manpower and there are still legit complaints about it. Its not a mechanic that I would recommend for a one-person project.
Quote from: Kaiser link=topic=8497. msg120268#msg120268 date=1585817555An idea could be adding some "warscore" value once the war start, which is set at value 0 for both the parts (or the alliances) and progress toward positive or negative depending how many and which ship one of the side lose
Paradox generally does a good job of implementing this into their games. Warscore begins at 0 for each party and every 'victory' pushes the counter up by a value which reflects the significance of that victory. In Aurora, things like planetary occupation, civilian ship losses, and civilian population deaths could also affect the war score.
Perhaps an option to make all mineral deposits infinite with the option to choose individually whether they are infinite on planets, moons, and asteroids/comets.