Aurora 4x

C# Aurora => Development Discussions => Topic started by: sloanjh on April 02, 2016, 09:39:00 AM

Title: C# Aurora Changes Discussion
Post by: sloanjh on April 02, 2016, 09:39:00 AM
Here's a place to discuss Steve's changes (mirroring Mechanics).

And I've got one:  Steve:  I noticed that you said that hull sizes are no longer rounded to the nearest integer.  Unless you're using an underlying integral type (e.g. a specially hull-size class that is implemented in private data as an integer times a fraction like 0.001), you probably want to do some level of rounding for numbers that are very close to an integer, e.g if( fabs(size - roundedSize) < 0.001) size = roundedSize.  Otherwise I suspect that you'll run into lot of bugs from players when they try to send a 5000 ton ship through a wormhole with a 5000 ton jump ship and it doesn't work because the jump ship size is actually 4999.999999999 and/or the ship size is 5000.00000000001 due to floating point error.

Let me know if you want an example of the hull-size class I mentioned - I suspect I've only got a 50% chance of having explained it well enough to understand what I'm talking about.

John
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on April 02, 2016, 10:08:51 AM
Yes, I was thinking about the jump drive issue. In VB6 I was rounding up to the nearest HS for that reason. I like the non-rounding from a variety POV as real world ships are rarely round numbers.

Perhaps the solution is to allow ships to jump other ships that are less than 50 tons larger, as long as the jump drive is large enough. For example, a DD of 5980 tons with a 6000 ton jump drive could still jump ships of up to 6000 tons. The drawback is it might be hard to explain to new players why the DD of 5980 can handle it, but not a DD of 5940 tons.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Jaque_Thay on April 02, 2016, 11:52:02 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Retropunch on April 02, 2016, 11:55:49 AM
Quote from: Steve Walmsley link=topic=8497. msg88749#msg88749 date=1459609731
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.

This sounds like a good option.  Even for long term players, quickly being able to see what the jump rating is would make life easier.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on April 02, 2016, 12:49:44 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: rorror on April 02, 2016, 03:21:10 PM
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.

Back to the drawing table for me.. got the same problem, waited 3years for my jumper and is at 95% of construnction now..  missing 25k tons
And i am micro managing the game.. those 3years in game took over 1 week of play time. :)

Code: [Select]
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
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on April 03, 2016, 10:08:40 AM
Aaah - I hadn't been thinking in terms of two different ships "really" having the same size (because components add up slightly differently).  I was thinking purely from a computer science point of view: "thou shalt never compare two floats or doubles without using a tolerance" in terms of comparing two ships that are supposed to have exactly the same size (e.g. same components but a different order so they add up differently).  Even leaving the jump drive issue out of it, I think there will quite a few places where you end up comparing hull sizes, so I think you should either have a "compare hull sizes" function that takes a required tolerance (or has one hard-wired inside) or you should discretize hull sizes to e.g. 1 ton or 0.1 ton or 1kg increments.

The above then made me realize an important question:  "Just how many tons are there in a 1000 ton ship".  By this I mean that the calculated tonnage on the design is just an approximation - in the real world the actual size will come out different (and be different for different ships).  So in the real world jump drives would be overdesigned to account for this variation.  So I think the question here is how to model this variation in the game and how much of it to expose to the user.

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.

I really like this idea for managing it, except I would make the slosh 5% or even 1% and not advertise it to users (or if you do, point out that this is to account for slop and the extra bit shouldn't be used in designs).  So the nominal rating of a jump drive is intended to be able to jump any ship whose nominal tonnage is equal to or less than that rating, and under the covers this allows nominal tonnages that are a bit high to still be jumped.

A more complicated way to manage it (that I'm not keen on) would be to have an "actual size" data member on each ship that randomly fluctuated by e.g. 1% from the design size.  You could play the same game with engine power, jump capacity, etc.  The upside is that this would give personality to the ships (e.g. a particular ship in the days of sail being known as a fast sailer).  The downside is that it would give personality to the ships - paying attention to small variations between ships is nice for single-ship tactical actions, but impractical at the 4X level, plus it forces an extra layer of micro-management on the player in terms of making decisions about just how much they're going to over-engineer jump drives and engines.

John
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on April 03, 2016, 10:18:30 AM
On AG-Infrastructure:

1)  Great idea - makes a ton of sense (pun not-intended)

2)  I assume that AG is built into ships and hidden in the crew quarters/life support tonnage?

3)  Every time I see "AG" I think anti-gravity.

John
Title: Re: C# Aurora Changes Discussion
Post by: DroiD on April 04, 2016, 02:03:20 PM
Quote from: sloanjh link=topic=8497. msg88785#msg88785 date=1459696710
3)  Every time I see "AG" I think anti-gravity.
John
Mayby LG (Low gravity) would be less misleading? "Low gravity infrastructure" looks pretty certain and clear for me.
Title: Re: C# Aurora Changes Discussion
Post by: Father Tim on April 05, 2016, 04:17:39 PM
I'd prefer 'Low Gravity Infrastructure,' simply to emphasize that it doesn't work on high-G planets.
Title: Re: C# Aurora Changes Discussion
Post by: boggo2300 on April 05, 2016, 05:06:44 PM
AG makes me think Agriculture personally
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on April 05, 2016, 07:26:55 PM
AG makes me think Agriculture personally

Same, actually.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on April 05, 2016, 07:45:48 PM
Maybe PG for Pseudo Gravity, or better yet Paragravity.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on April 06, 2016, 02:22:59 AM
I'd be for avoiding needless complication - what you see is what you need to see, without new values that are almost the same as exisiting ones (size vs. effective size for jump purposes).
"There's a slight tolerance for your convenience . If you try to cut corners betting on this, don't complain if it doesn't work".
Title: Re: C# Aurora Changes Discussion
Post by: Bgreman on May 05, 2016, 01:14:26 PM
I was alerted that you'd started (finally! :P) working on a C# port and had to come take a look.  Looks amazing.

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.

The Aurora Viewer stuff I wrote uses LINQ and lambdas heavily.  Something I eventually wanted to do was to have actual json-serializable classes to represent all the entities I use, rather than just pulling primitives out of the DB and writing raw json.

Something I was thinking based on some of the feedback you've received about the class design window:  Rather than having to flip back and forth between available and installed components, why not just have the number of installed components appended to the treeview item.  Add with click, remove with shift-click, or even buttons on the treeview item itself.  Add or remove 5 by also holding CTRL.

For "Ships in Class" it would be nice if launch date would show for civilian ships.  The value is in the DB, it just doesn't get populated in the UI for civ-owned vessels.
Title: Re: C# Aurora Changes Discussion
Post by: razanon on May 17, 2016, 03:44:13 AM
hi friends, is there any way to test, as a demo, work done so far? thx in advance
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on May 17, 2016, 01:27:59 PM
No, its a long way from that stage :)

I am busy with work at the moment so only doing small amounts when I can. I have a week off in three weeks so will make some more progress then.
Title: Re: C# Aurora Changes Discussion
Post by: razanon on May 18, 2016, 01:46:07 AM
great news.  youre making the best 4x anyone can found on pc.  trust me! thx in advance master
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on June 03, 2016, 04:53:49 PM
Is this game going to be able to use multiple cores? Aurora gets super slow when you get enough civilians running around...
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on June 03, 2016, 08:56:11 PM
In C# it probably will.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on June 04, 2016, 04:30:41 AM
C# doesn't particularly mean that you have multithreading.  It is my understanding that he is not adding that with this update, though if memory serves he is considering moving some of the computations into different threads eventually.
Title: Re: C# Aurora Changes Discussion
Post by: Frick on June 04, 2016, 08:19:43 AM
AFAIK the slowdown is not about CPU speed and more about database/VB6 limitations. The slowdown is just as bad on a hyper clocked Skylake CPU with the game on a RAMdisk as it is on a C2D based laptop with a slow HDD.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on June 15, 2016, 12:25:37 AM
Will there be an overhaul of the OoB system? I want to be able to subordinate staff commands to other staff commands (So you can have a solar staff be subordinate to a sector staff be subordinate to the High Command staff) as well as dictate that an officer beyond a certain rank will not be assigned to a ship class (no more admiral fighter pilots).

I outlines my thoughts a little better here.

http://aurora2.pentarch.org/index.php?topic=8630.0
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on June 18, 2016, 06:47:15 AM
I probably will look at fleet organization when I start on the Fleet window ( and I will add a max rank for commanders)
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on June 20, 2016, 09:05:18 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on June 21, 2016, 09:17:30 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on June 21, 2016, 01:18:10 PM
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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on June 21, 2016, 01:37:01 PM
Maybe even having the personality traits of the officers' having a part, both positive and negative. You would of course lose the opportunity to change/add/remove personalities from officers without SM mode (or at all). For example, an Optimist would give a moral bonus while a Pessimist a slight hit, the Hard Worker would give a bonus to other skills of the officer, etc.
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on June 21, 2016, 01:44:50 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on June 21, 2016, 08:03:42 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Culise on June 21, 2016, 10:52:01 PM
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? 
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on June 22, 2016, 04:00:22 AM
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?

Is it the same database until I decide what the long-term replacement will be. I'll take a look at cleaning it up though.
Title: Re: C# Aurora Changes Discussion
Post by: bean on June 22, 2016, 01:55:02 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on June 22, 2016, 03:29:35 PM
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 realize this risks turning this into a suggestion thread, but maybe tie it in with a variety of bridge modules?

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.
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on June 22, 2016, 09:10:27 PM
I think the way the navy chain of command works right now is just fine. All of my problems with it would pretty much be fixed by adding a "max rank" setting for ships so that I stop seeing admirals on fighters. Ships which're taking enough damage to lose officers and select a new commander are pretty much on the verge of death anyway. The most I'd do to try and simulate chain of command at this level is add a "first officer" post to all ships with a bridge, who must be one rank below whoever is in command and adds 1/10th of his bonuses to the ship. I'd also add the possibility of the top position only being allowed to have one officer at any given time so that I stop having to add a new filler rank every time I end up with two sky marshals.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on June 22, 2016, 11:19:54 PM
I like both those ideas, regular bridge allow a first officer who applies a fraction of their bonuses, perhaps 50%?
Then the flag bridge giving a full crew similar to the naval command positions.
Then again you basically already get that by making a new task force and shoving them into the flag bridge vessel right?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on June 23, 2016, 03:59:02 AM
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've been on holiday with my family this week and away from my PC so not got anything done. I'm back at the weekend and will be continuing work on the mining and shipyard tabs of the economics window.
Title: Re: C# Aurora Changes Discussion
Post by: JOKER on June 23, 2016, 05:43:17 PM
Any plan in future to improve beam weapon and ECM/ECCM?
Title: Re: C# Aurora Changes Discussion
Post by: schroeam on June 23, 2016, 06:31:28 PM
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 like the different bridge ideas.  Also the idea of having an XO who could step up (apply some reduction factor to ship's rediness and morale) if the CO is killed.  Maybe also look at ground forces and having staff positions tied to the headquarters?  Just a thought.

Overall, I am very excited about the changes coming with the rewrite.  The last 10+ years have been pretty incredible with what you have done with your little hobby, and how you have let us come along for the ride. 

Thank you Steve.

Adam.
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on June 23, 2016, 07:27:37 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: schroeam on June 23, 2016, 08:37:35 PM
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.

;) Point taken:

1. Combat
1. Garrison
1. Construction
1. Ruin Excavation

There is as much room for logistics, operations, and intelligence staff officers on ground forces as there are with fleets.  Just a thought to open up the Headquarters units to multiple officers.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on June 24, 2016, 01:54:11 PM
I realize this risks turning this into a suggestion thread, but maybe tie it in with a variety of bridge modules?

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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on June 24, 2016, 02:15:21 PM
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.

Oh yeah, the game is definitely currently built around commanders for fighters. And it's fine if it stays that way; I was just saying if it were me I'd probably change that to reduce micromanagement. So instead of a commander in every fighter you'd have a carrier using a command bridge with a CAG slot, and then the CAG might have skills like "Pilot Training" that adds grade bonus to all fighters while they're docked, and a "Command" skill that works like fleet initiative for fighter squadrons. Or whatever.

The need to have multiple lower ranked officers would actually be reduced by the idea of multiple officers on each ship; you might have one captain and 1-4 commanders on your larger ships, for example (and just one commander on your frigates and destroyers).

Edit: We're in the middle of a steam sale in which I'm spending perfectly good money on new games, and now all I want to do is play more Aurora.
Title: Re: C# Aurora Changes Discussion
Post by: hubgbf on June 28, 2016, 08:34:52 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on June 28, 2016, 06:07:52 PM
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.

Yes, I think a 1 HS auxiliary control would be even better than a larger bridge.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on July 02, 2016, 12:14:36 AM
Is there anything being done to improve the games play-ability? I don't want to reduce the games scope, but I would like to see you be able to do more with less clicks and have information more readily available and clearly presented. For instance, I had to look up how much infrastructure weighed on Reddit and then had to do a calculation on how many times I could have to make my transport fleets make the trip to get the desired amount on planet. It would be better if instead I could assign a fleet to deliver x amount of something and then they make as many trips as needed.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on July 02, 2016, 12:52:23 AM
There's a setting to ask civilian shipping companies do exactly this.
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on July 02, 2016, 01:09:10 AM
To be fair it'd be pretty good if I could assign my freighters to the private sector so that I can fulfil outstanding contracts without having to pay a third party for it.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on July 02, 2016, 01:10:33 AM
Perhaps with C# it might be time for steve to add more comprehensive tooltops, an ingame Aurorapedia perhaps?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on July 02, 2016, 06:45:18 AM
Perhaps with C# it might be time for steve to add more comprehensive tooltops, an ingame Aurorapedia perhaps?

I definitely like the name Aurorapedia :)
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on July 02, 2016, 07:28:40 AM
I'm sure there's no need for the extreme detail the wiki goes into, but something that would allow basic information to be accessible would be good. Perhaps every game page should have a button linking to the pedia. First thing you see is a screenshot with labels, under that describes what the buttons do. A basic overview of what the window is used for, and links to appropriate other information.
Alternatively or additionally every button could have a tooltip with that description. Hover over buildings and you see what they cost, produce, shipping tonnage etc.
I'm thinking of shamelessly ripping off the format of Alpha Centauri's pedia. Simple drawings of buildings and tech systems etc might be good here, you can't really see that stuff anywhere else in the game and it might be nice to see.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on July 02, 2016, 12:26:24 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on July 02, 2016, 12:32:12 PM
Being able to shift click and control click to select multiple units would be nice too.
Title: Re: C# Aurora Changes Discussion
Post by: Haji on July 03, 2016, 10:48:45 AM
Since we're talking about UI upgrades here's my wishlist:

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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on July 03, 2016, 01:06:57 PM
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.

I'm already working on improved visibility of mineral consumption. On the mining tab in C# Aurora, the consumption of minerals is broken down by mineral type and consumption type (construction factories, ordnance factories, shipyard upgrades, shipyard tasks, ground unit construction, etc.) so it is a lot easier to handle mineral shortages on a local level. Something on a global scale should not be too difficult.

Quote
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.

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.

Quote
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.

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#.

Quote
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.

There is a damaged ships window in VB6 Aurora that lists all damaged ships including fleet and location. That should help, although that is every damaged ship, not just recently damaged). However, I like the idea of some type of increment summary during battles

Quote
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.

Thanks - I am enjoying working on it
Title: Re: C# Aurora Changes Discussion
Post by: Haji on July 03, 2016, 01:16:45 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on July 05, 2016, 06:47:46 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Haji on July 06, 2016, 03:58:56 PM
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.

I've been using this and for the most part it works fine. The problem with fire controls really begun only recently due to the way I play my campaigns. In one of them I had 20 classes of warships from seven different nations engaged in hostilities and all of them had both missiles and anti-missiles in box launchers sometimes in weird ratios like 14 missiles per fire control. Those were a pain to set up with the worst offender, the Ticonderoga class cruiser having 128 missiles with four fire controls and 384 anti-missiles with 8 fire controls. Those were a real joy to set up.

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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on July 06, 2016, 07:11:25 PM
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.

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!
Title: Re: C# Aurora Changes Discussion
Post by: Haji on July 06, 2016, 07:17:50 PM
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!

I kind of did. The thing is most of my campaigns are being role-played and in this case the design was conceived to deal with a certain specific enemy of overwhelming power and was simply used whenever needed. It wasn't the best ship for this particular job, but this is what this particular nation had. I mean, designing anti-FAC ships is easy if you're playing a game. Designing anti-FAC ship when you're roleplaying the game is a little more complicated.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on July 06, 2016, 08:39:18 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on July 06, 2016, 08:44:57 PM
I agree.  A system where mineral orders are automatically queued based off of production orders sounds really nice.  Adding empire ships to some kind of civilian shipping system also sounds extremely convenient for servicing this.  I would assume they would still need to refuel periodically but that wouldn't be too much of a hassle I would guess.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on July 06, 2016, 10:09:10 PM
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?

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.
Title: Re: C# Aurora Changes Discussion
Post by: ardem on July 06, 2016, 10:49:04 PM
I am not sure about this last update, around infantry in the base v in the population. I think there is some benefit just having the troops there. Either way if that is the case oribital bombardment against troops in a city should do more city damage, based on that if the new attackers invade there should be some repercussion against the attackers that did the orbital bombardment.

This might be the first time I have ever said this but 'I dislike this change' as it not fully fleshed out mechanics around population response to events. I think this add more tedium with seeing the people unrest log file without meaning anything really
Title: Re: C# Aurora Changes Discussion
Post by: Sheb on July 07, 2016, 04:50:39 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Kytuzian on July 07, 2016, 11:23:31 AM
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?

Yes, definitely this.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on July 09, 2016, 12:13:04 AM
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?

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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on July 09, 2016, 07:47:42 PM
Oh! I was wrong!
Then it definitely makes sense to add minerals to the list of things they can ship using current mechanics, yeah.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on July 10, 2016, 03:12:56 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Britich on July 10, 2016, 04:34:00 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on July 10, 2016, 05:57:09 AM
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.

You can already set reserve minerals levels in VB6 Aurora, so those won't be sent via mass driver and won't be picked up by freighters.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on July 10, 2016, 05:58:01 AM
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.

The mechanics haven't changed from VB6 Aurora. I may add rebelling and declaring independence at some point though.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on July 11, 2016, 01:42:06 AM
That new mineral use display will be very handy, I sometimes get carried away and burn through all my Duranium with shipyard expansion, it's very helpful to see where it's all going.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on July 14, 2016, 03:57:48 AM
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.

What I really would like is a Civilian economy chain that makes a bit more sense. Basically have Civilian mining outpost ship minerals which are used to produce some of the goods used to trade with, and the civilian shipping transport minerals around to civilian resource pools to try to keep a small amount of everything available everywhere (depending on demands). To facilitate some growth say 10% extra of everything you mine on populated colonies is added to the civilian markets resource pool.

This would open up so many cool options like buying/selling minerals to the civilian market (prices depending on supply and demand), or even forcefully seizing minerals or taxing them at times of war ( reducing or even reversing growth of civilian shipping and increasing unhappiness ).
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on July 31, 2016, 01:47:03 AM
About the multiple officers per ship thing, I was wondering what you would base them off. A ships should probably have standard a captain and an XO, perhaps an engineering, communications and such as well, but certain positions should only become available if you have a certain component. 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.

It would also be neat if you could designate a ship a flagship and have an extra slot for the admiral so you can model having a captain and an admiral on the same ship.
Title: Re: C# Aurora Changes Discussion
Post by: Britich on July 31, 2016, 05:15:54 AM
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.

I love this idea.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on August 01, 2016, 08:14:05 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on August 02, 2016, 11:59:52 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on August 02, 2016, 07:39:56 PM
Me, too. I think the furthest we should be going is adding a bridge-tier that allows you to have a first officers, and a component that allows a scientist or a politician to be assigned to the ship, adding his skills to the ship where it applies (maybe make it a civilian-only component). The latter would be useful on exploration vessels and on stations that have maintenance or mining/terraforming modules. As for adding whole new classes of officers? No. Absolutely not.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on August 02, 2016, 09:28:30 PM
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...

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.
Title: Re: C# Aurora Changes Discussion
Post by: TheDOC on August 13, 2016, 05:36:21 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on August 16, 2016, 10:17:29 AM
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.

That's what infrastructure is for.

But I can see a population density factor coming into play.
Title: Re: C# Aurora Changes Discussion
Post by: NuclearStudent on August 16, 2016, 01:57:39 PM
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. 

 
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on August 16, 2016, 03:32:11 PM
Yes, being able to ban civilians from even entering a system should be possible. This should also prevent CMCs from forming in that system.
Title: Re: C# Aurora Changes Discussion
Post by: Kytuzian on August 16, 2016, 07:27:20 PM
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.

In addition to banning civ ships, I'd like to be able to make my own ships prefer to route around a particular system. Mostly because in the current game of Aurora that I'm running with my friends, I want to have one of my aliens set up a colony in a system, but the most efficient way to get there is through Sol--which is not really an option because they could easily destroy the commercial ships as they pass through, and if I sent warships with them there'd be a battle every single time they pass through the system, which would slow the progress of the game to a crawl.
Title: Re: C# Aurora Changes Discussion
Post by: TheDOC on August 17, 2016, 11:36:13 AM
That's what infrastructure is for.

But I can see a population density factor coming into play.

Fact is, it happens also with very small planets. I have seen a planet with 0.11 G going up to 3 Billion in a game, and that makes no sense. As you said, a pop density factor influencing growth so that earth doesn't get to 50 Billion with many TN races at the beginning would be very appreciated.
This comes from personal experience due to running multiplayer campaigns and 15 Billion pop earth in 10 years is strange to say the least.

A bit of OT now, sorry for that:

I gotta give a thumbs up to steve for keeping up the great work he's always done and for the incredible regularity with which he works on the project.
Also, while i didn't know much about VB6, i've got a decent knowledge of C# so if there ever is the need i would be happy to help.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on August 17, 2016, 05:29:46 PM
Same, though its my understanding he isn't interested in outside help.
Title: Re: C# Aurora Changes Discussion
Post by: Profugo Barbatus on August 18, 2016, 11:09:11 AM
Quote from: BasileusMaximos link=topic=8497. msg95364#msg95364 date=1470191310
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.

Gave this a bit of thought, Why not have fighters not have officers, but have fighter squadrons have a squadron leader who's a named officer, passes their bonuses onto fighters in their squadron.  Whenever a fighter gets killed, roll a chance of the officer having been aboard that fighter.  Fighters outside of squadrons can be explained as having no lead officer due to the lack of organization implied by not being on a squadron.
Title: Re: C# Aurora Changes Discussion
Post by: NuclearStudent on August 18, 2016, 01:29:01 PM
There's a few things I like to make leader management a bit easier.

Most important, to me, is that I'd like a log that keeps track of retired/KIA officers.  I'm thinking about the Memorial feature in XCOM.  I imagine a sheet where you can see names, final ranks, and medals given. 

It would be nice if the player could set conditions for a medal to be automatically assigned.  Like, if a naval officer is on a ship and the ship destroys a ship, the naval officer gets [MEDAL_NAME_HERE].  Right now, as far as I can tell, Medals all have to be given manually, which is a lot of micro.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on August 25, 2016, 04:24:56 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: waresky on August 25, 2016, 01:21:03 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: NuclearStudent on August 25, 2016, 03:25:09 PM
Quote from: waresky link=topic=8497. msg96187#msg96187 date=1472149263
Useless. . . seriously.

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. 
Title: Re: C# Aurora Changes Discussion
Post by: Sheb on August 26, 2016, 02:01:55 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Britich on August 26, 2016, 05:20:38 AM
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.

I concur, I like to write up Battle Reports in the Galaxy Notes window, even name the battles.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on August 26, 2016, 07:06:49 AM
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.

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
Title: Re: C# Aurora Changes Discussion
Post by: waresky on August 26, 2016, 09:31:48 AM
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.

RPG its 90% of Aurora, but we need more options in others field. My 2 cents
Title: Re: C# Aurora Changes Discussion
Post by: NuclearStudent on August 26, 2016, 12:54:22 PM
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

Yes, that sounds like an absolutely good explanation of why my idea wouldn't work, as well as an excellent alternate suggestion for a better system.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on August 27, 2016, 06:30:15 AM
The C# version is only saved when the user chooses (or will be when I code that part :) ).

Therefore I could leave the officers in the game but flagged as dead. The player would decide anyone he wanted to keep in the 'Hall of Heroes' (or something on those lines). Anyone else would disappear when the game was shut down (as I wouldn't bother to save them).
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on August 27, 2016, 03:09:44 PM
Is there a chance to get some parameters which for example can tweak how much dust and radiation is removed per day? Could use a planetary SpaceMaster Parameter which says how much of the dust is removed. The Dust and Radiation in my storygame simply are reduced too quickly and I have to "re-add" them now and then to keep the grows of the population more under control as I have planned. Such a parameter would make my life as SpaceMaster a little easier... . :D
Title: Re: C# Aurora Changes Discussion
Post by: Sheb on August 27, 2016, 03:25:42 PM
Just detonate another nuke from time to time, as some poor schmuch hit an unexploded missiles while digging foundations.
Title: Re: C# Aurora Changes Discussion
Post by: Kristover on September 13, 2016, 08:59:38 PM
Love the game and looking forward to playing the C# version.

One question - I have seen in the discussion the increased functionality and easier to program in VB6.   Any plans to address NPRs not being able to conduct ground invasions on planets?  I would like to see it in future versions - having to defend planets with my ground forces from NPR invasion.

Thanks!
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on September 14, 2016, 07:16:32 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: NuclearStudent on September 14, 2016, 09:35:40 PM
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?

Steve just mentioned yes to the above up on the top of the page :)
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on September 15, 2016, 12:34:35 AM
I went back to page 2 and saw that I already answered this and he said it was a maybe. I don't see any response from Steve regarding this on this page though.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on September 15, 2016, 10:17:18 AM
The OoB/task force changes are in (http://aurora2.pentarch.org/index.php?topic=8438.msg96786#msg96786 (http://aurora2.pentarch.org/index.php?topic=8438.msg96786#msg96786)), but I don't think anything has been said about central government/civilian command structure yet?
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on September 15, 2016, 12:30:35 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on September 15, 2016, 06:53:00 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on September 18, 2016, 03:24:05 AM
Yes, I am doing something like that  :)
Title: Re: C# Aurora Changes Discussion
Post by: GeaXle on September 19, 2016, 03:00:42 PM
Hi Steve, I am really looking forward this C# version of Aurora.

I was wondering if maybe suggestion should be made here now?

Anyway, would it be possible to get an option to assign our freighter to the civies? Or that freighter order consume civilian contracts? For example, I set up loads of supply and demand contract to shuffle instalations around. But sometimes as the civilians aren't moving things fast enough, I order my freighters to move the goods and it messes up the supply and demand contract I have done. Maybe if the contract were consumed by my freighters, or if I could have a toggle that civilians will give orders to my freighter as they see fit, it would be very helpful.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on September 25, 2016, 10:09:12 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: schroeam on September 26, 2016, 10:51:05 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 26, 2016, 03:00:14 PM
This made me think of the 4 jump limit on civvies and auto-calculated fight paths.  Any chance that limit could be extended?

That limit was already removed in VB6 Aurora. It is now unlimited.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 26, 2016, 03:00:45 PM
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.

Should be possible - just need to remember to do it now :)
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on September 26, 2016, 04:31:39 PM
Oh, that would be swell!
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on September 27, 2016, 05:02:47 PM
So you can break off  sub fleets to join other fleets?

Also speaking of freighters have you touched the civilian economy at all to make it more sophisticated/helpful?

For instance, you could have it so there are civilian shipyards where the freighters get their ships from and you can contract to build some of your stuff.  Or you have mining companies which gather resources for you so you don't have to or research institutes that have a chance or researching technology for you.

Having mechanisms to control or encourage private industries would be cool to, like only giving out so many licences to build shipyards or giving one company a monopoly on a systems resources so they can develop it almost independently.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on September 28, 2016, 07:11:22 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on September 29, 2016, 01:17:02 AM
It would be interesting if you made Marines more useful by giving every unit but them very high penalties for assaulting a planet where you have no ground presence, making them vital for establishing a "beachhead".

Speaking of, does the new organization system allow you to integrate ground units?

Also, what of corps and army HQ battalions and organizations?
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on September 29, 2016, 03:51:16 AM
By the way, Steve, since you say you haven't done detections yet, I have taken multithreading in university and can throw some example code your way to show you how that is supposed to look if you like.  For turn-based stuff like aurora it should be extremely straightforward since there aren't really synchronization issues (you can just wait for all of the threads to complete without that breaking anything).
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on October 02, 2016, 05:33:57 PM
Nice change. I've always thought ordinance transfer at least shouldn't be instant (it lets you do some pretty gamey stuff with colliers) but slower fuel transfer is good too. And it's not brutally slow; taking a few days to refuel a ship isn't going to be a huge problem outside of combat scenarios.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 02, 2016, 06:06:31 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 02, 2016, 06:14:24 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on October 02, 2016, 11:08:07 PM
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
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 03, 2016, 01:34:40 AM
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.

The changes to refueling and rearming ships sounds really nice. Looks like it will be critical research and upgrades for smooth Carrier operations!
Title: Re: C# Aurora Changes Discussion
Post by: IanD on October 03, 2016, 02:40:33 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 03, 2016, 06:36:38 AM
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

I will add something on those lines. I think there is already something similar in VB6 Aurora for fleet training.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 03, 2016, 06:38:16 AM
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?

NPRs will be affected by the planned ordnance changes.

Fighters will follow the new rules for re-arming and refuelling, instead of the current mechanics. I'll create some carrier-specific rules for the rate of refuel/reload.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 03, 2016, 07:04:56 AM
I'll create some carrier-specific rules for the rate of refuel/reload.

Could be interesting to have a new hangar component for modelling refuel/reload/recover/launching so you have the tradeoff between fast turnarounds and high storage capacity when designing your Carriers.

Edit: If a separate system for Carriers is implemented it should probably be limited based on the Carrier output so you can't just get around it by making many smaller fighters (with less fuel & ammo each ). Refueling 8 x 125 ton fighters should logically take at least the same time to refuel as a single 1000 ton FAC with 8 times as much fuel in the same Carrier.
Title: Re: C# Aurora Changes Discussion
Post by: Darkminion on October 03, 2016, 10:08:00 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 03, 2016, 01:39:34 PM
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?

There won't be an equalise fuel option as it currently exists. As mentioned above though, I will create an option to have tankers constantly refuelling. Also, there is nothing to stop you adding the refuelling system to larger warships so they can refuel their escorts if needed.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 03, 2016, 02:53:29 PM
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!
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on October 03, 2016, 03:31:26 PM
Like the new rules on refuling and agree a fighter level component would be very good
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 04, 2016, 12:14:06 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 04, 2016, 02:08:49 PM
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!

The issue would be that if we create a fighter-size component, then it would fit easily on every ship and having the new rules wouldn't make much sense. Having a large refuelling system means that including the system is a decision, rather than automatic. For a fighter-size component to exist, while maintaining the desired game play effect, there would have to be some reason that it would only work with other small craft.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 04, 2016, 02:16:39 PM
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?

1) Refuelling doesn't work both ways - think about your car at the gas station, or replenishment ships at sea.
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
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 04, 2016, 02:28:34 PM
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.
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

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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 04, 2016, 03:56:43 PM
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.

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 ).
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 04, 2016, 05:08:28 PM
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.

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.

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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 04, 2016, 05:10:49 PM
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 ).

Multiple refuelling systems don't stack, so a second one is for redundancy only.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on October 04, 2016, 10:33:05 PM
Fantastic change! Instant fuel transfers have somewhat annoyed me for ages.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on October 04, 2016, 10:46:19 PM
If they don't stack, then that will strongly encourage lots of small tankers (in an attempt to get them to stack anyways).

I'm not sure if thats desirable or not.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 05, 2016, 12:03:54 AM
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.

https://www.maritime.org/doc/pdf/unrep-nwp04-01.pdf
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. 

Quote
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.)

Quote
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.
Title: Re: C# Aurora Changes Discussion
Post by: IanD on October 05, 2016, 02:55:50 AM
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.

Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on October 05, 2016, 07:45:28 AM
So given the new rules on fuel transfer are you also thinking about a similar system for ordnance?
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 05, 2016, 11:48:58 AM
So given the new rules on fuel transfer are you also thinking about a similar system for ordnance?

Yes. This is literally what he wrote:  ::)

"I will be adding some rules along the same lines regarding ordnance transfer."
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 05, 2016, 12:11:44 PM
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.

Yes, I was considering having the tankers refuel 2 or more ships at once (as part of the unrep tech line). It was the potential complexity of the mechanics that was putting me off but I think I may have a way to tackle it.

Each class or ship in a fleet would have a fuel priority set and the tanker would refuel the highest priority ships first. If the tanker could refuel two ships, it would simultaneously refuel the highest two priority ships in need of fuel (moving to other ships if it filled the tanks and time remained).

Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 05, 2016, 12:13:59 PM
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.

You will be able to add refuelling systems to any ships, not just tankers.

Re the underway replenishment. I think it adds flavour to have this restriction. In technobabble terms, the liquid-like dimension in which TN ships travel causes the same type of random turbulence that affects wet-navy ships :)
Title: Re: C# Aurora Changes Discussion
Post by: schroeam on October 05, 2016, 03:36:56 PM
In technobabble terms, the liquid-like dimension in which TN ships travel causes the same type of random turbulence that affects wet-navy ships :)

Rock those little space sailors to sleep.
Title: Re: C# Aurora Changes Discussion
Post by: JOKER on October 05, 2016, 07:27:23 PM
Do we have to add refuel system on carriers?
Title: Re: C# Aurora Changes Discussion
Post by: palu on October 05, 2016, 07:55:22 PM
Why is all the UIin the screenshots yellow on blue? Please at least give us an option for normal colors that don't make my  eyes bleed.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 06, 2016, 06:36:51 AM
Do we have to add refuel system on carriers?

Not for hangar-based refuelling. I'll let hangars automatically refuel ships within them and perhaps have some type of hanger specific tech regarding refuel rates.
Title: Re: C# Aurora Changes Discussion
Post by: Shuul on October 06, 2016, 08:16:01 AM
So this is a small buff to carriers, as we will not need large fuel systems to field fighters.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on October 07, 2016, 07:44:22 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on October 07, 2016, 08:35:32 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Shuul on October 07, 2016, 08:47:18 AM
And Steve pointed out that it seems to became 8.0
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on October 09, 2016, 08:43:32 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on October 09, 2016, 08:43:55 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 09, 2016, 09:28:39 AM
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

I'm very impressed with C# so far. Considerably more flexible than VB6. Garbage collection is very useful but I have found using LINQ with Lambda expressions to be the biggest factor. Once I load everything into collections, I can query in the same way as a database, except I can include functions within that code.

For example, the code below is creating a list of comets to display in the orders window. This one line of code pulls the comets for a specific system, retrieving either all comets or only the unsurveyed ones depending on the state of a checkbox (based on the viewing race), excludes those with an existing population, orders the selection by component and name (which is pulled from a function within the LINQ) and then puts the comets into a collection. This would take a little longer in VB :)

                    List<SystemBody> Comets = Aurora.SystemBodyList.Values.Where(x => x.ParentSystem == CurrentSystem.System && x.BodyClass == AuroraSystemBodyClass.Comet && (x.Surveys.Contains(FleetRace.RaceID) == false || chkExcludeSurveyed.CheckState == CheckState.Unchecked)).Except(PopSB).OrderBy(x => x.ParentStar.Component).ThenBy(x => x.ReturnSystemBodyName(FleetRace)).ToList();

Intellisense is very good too and being able to use Peek Definitions mid-code makes things much easier in the IDE.

BTW I was a C++ programmer for DEC a LONG time ago. I was writing VBX controls for Windows 3.1. C++ was powerful but definitely programming without a safety net :)
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 09, 2016, 09:38:22 AM
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

The harvesters are displayed when you select 'Fleets' for display. There is a separate checkbox in the display options for 'Civilians', which will list all the civilian ships in the system, not just the harvesters.

Yes, I know the targeting planets in VB6 is clumsy. I'll create a better UI for C#
Title: Re: C# Aurora Changes Discussion
Post by: snapto on October 10, 2016, 08:16:17 AM
On the fleet orders window when loading installations, would it be possible to have an indication of how much cargo capacity each installation requires (either per unit, total, or both)? It's looking great btw!
Title: Re: C# Aurora Changes Discussion
Post by: TCD on October 11, 2016, 10:20:28 AM
The new orders system does look great, especially tying it in with the fleet organisation. Much easier to use.

One request from me would be for a way to easily see/filter/mark task groups by system. I can never remember which ships are in which system, and spend a lot of time in VB6 clicking on every ship of a particular type to find the ones in a certain system. It would be super helpful if the fleet organisation part of the new orders window either showed system location or let me filter or highlight for that.

I was initially going to ask you to think about adding system in after the task group name (in a different colour or in brackets or something) but that might be too wide?
Title: Re: C# Aurora Changes Discussion
Post by: ardem on October 11, 2016, 11:15:26 PM
Steve is it at all possible to a 'remove highlighted' button, where it removed the highlighted order., with the new C# code and UI.

So many times I set orders and in the middle of the order is  the mistake, so I need to remove all to start again, which is a pain for timed based orders, and redoing all the little parts that can make up some of the larger repeat orders.
Title: Re: C# Aurora Changes Discussion
Post by: IanD on October 12, 2016, 02:27:45 AM
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.

Ian
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 12, 2016, 02:30:39 AM
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.

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?
Title: Re: C# Aurora Changes Discussion
Post by: Andrew on October 12, 2016, 04:03:39 AM
I believe the answer to that is complicated. Depending on the quality of your ESM gear you can detect the characteristics of the radar illuminating you which tells you things like the pulse rate, frequency and signal strength. From these you can determine the type of radar illuminating you and hence tell the likely platform it is based on and what it does, this is based on pre-existing knowledge of what radars are in service.
However even if you are dealing with an unknown type of radar you can tell something about it, Search radars tend to have relatively low pulse rates which helps make signal processing of large area sweeps easier but means there is a degree of positional uncertainty, targeting radars tend to be much more focussed on a small area and have higher pulse rates which helps precisely locate the target which is important for weapons like the typical Aurora missile which is dependent on external data, however if the weapon being fired has it's own guidance system then it could be fired based on the rougher fix of the search radar and then do the final targeting on its own so in that case you would not detect a targeting radar until the weapon activates its seeking head, and of course something like an IR Homing missile never illuminates its target with a targeting radar.

Edit: I am not an expert so some of the above could be wrong
Title: Re: C# Aurora Changes Discussion
Post by: AL on October 12, 2016, 04:41:23 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 12, 2016, 05:16:20 AM
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.

I think that would be helpful. At least the option to toggle low RES sensors ( 20HS or below ) separately from long range / high RES sensors (>20HS). That would allow you to keep your missile/fighter detection running without flipping on the huge emitter announcing your arrival to everyone and their grandmother in system.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 12, 2016, 09:52:32 AM
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 wrong
None of it is wrong.

I would like Steve to consider a low probability of intercept (LPI) mode for active sensors.  This would cut the range of the sensor, but cut the radiated power even more.  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.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on October 12, 2016, 03:36:13 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 12, 2016, 04:54:04 PM
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.
Quote
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.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on October 12, 2016, 06:44:57 PM
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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 13, 2016, 09:28:39 AM
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.
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.
I'm aware of that, and there are two reasons I'd like to see it changed:
1. It makes very little sense to tie radiated power into resolution.  A much more realistic way of doing this is to have radiated power simply equal (Power per HS*Sensor HS).  This would basically flip the ratios around, which is realistic.
2. Big R1s are really expensive.  It would be helpful to have a cheaper way of doing LPI. 
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on October 13, 2016, 09:59:39 AM
I think I like the current system better:
1) There's some trade-offs with space/cost efficiency and emissions
2) Acquiring an active sensor lock at very long ranges without giving yourself away is also very powerful. This should be expensive. An according tech line that works better than the current system (which is self-limiting because low emissions forces large sizes, which may force you into cloaking tech...) would be hard to balance.

Tying radiated power to resolution... my interpretation was that powerful emitters aren't the technical challenge, but that coarse-grained sensors simply allow us to make use of more power where fine-grained ones don't - they'd just pick up more clutter.
Title: Re: C# Aurora Changes Discussion
Post by: littleWolf on October 14, 2016, 03:48:43 AM
On latest screensots i see "Commonwealth" and "Japan Empire".

Aurora now have a few separate nations on one planet ?
Title: Re: C# Aurora Changes Discussion
Post by: AbuDhabi on October 14, 2016, 04:59:03 AM
You could have that already for a while. That's what the "same system truce" is for.
Title: Re: C# Aurora Changes Discussion
Post by: Scandinavian on October 16, 2016, 02:58:17 AM
Since orders in Aurora are sequential, the new refueling rules seem to imply that total time alongside during a port stay would be refueling plus cargo operations, overhauls, etc.

However, it's not clear why replenishing bunker shouldn't happen concurrently with cargo operations, replenishment of stores, minor hot works, etc. In fact, that is how most commercial vessels today operate.

A cleaner solution would be to have a general "port stay" order with options for which activities to perform, and then have those activities being performed concurrently (unless they are mutually exclusive - you probably have to do overhauls and cargo operations sequentially). No idea how much bother it would be to code, but something similar already exists for loading ground units, so I'm guessing it should be feasible.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on October 16, 2016, 05:09:10 PM
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"
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on October 16, 2016, 09:28:46 PM
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
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on October 17, 2016, 04:51:50 AM
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).
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 17, 2016, 05:33:05 AM
I think it will be quite interesting to see how the refueling and rearming changes actually turns out in practice.

But based on what has been written I for one look forward to needing several tankers and forward bases to sustain the logistics of more rapid refueling and operations of larger fleets with more fuel-hungry ships.


And I doubt there will be severe issues with tankers keeping up with underway refueling unless you got extreme situations like a single tanker for a huge fleet ( in which case you'll need more tankers anyways ) or ship designs that burn through all their fuel in less then a few days ( these belong in hangars anyways ).

As stated in the changes list you'll be able to refuel up 50k liters per hour ( 1.2 million per day ) without tech, and with a few fairly cheap tech we are likely to see a ~30% underway replenishment * a base rate of around 150k liters per hour, which allows you to get similar numbers from an underway refueling tanker. Even if you design a fuel-hungry warship it will probably not go through more then a million liters fuel in 20 days, so you could still keep a fleet of 20 such ships fully topped up with fuel from a single underway refueling tanker. And if there is an issue with falling behind you can just halt the fleet a few hours to allow the tanker to catch up (stationary using full refueling amount).


Being able to load ammo and cargo in parallel to refueling might make sense and be nice, but I don't see it as a huge issue if it can't be done. For gameplay you could probably find a middle ground where times of each action are not half but also not 100% of total downtime you want, but somewhere in-between. It's also far from given that all these actions in reality can be fully done in parallel or are always done fully in parallel.

Especially when you have bigger fleets of ships it doesn't makes sense they can all be re-armed and re-fueled at the same time even on bigger ground bases, so the final total time we end up with will probably feel in the right ballpark anyways.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on October 17, 2016, 07:14:21 AM
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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 17, 2016, 09:48:05 AM
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. 

My main worry about making operations sequential is that you might lose a lot of time in ways that don't make sense.  Let's assume we have a fleet that's carrying troops and is escorted by a tanker.  Most of the ships take only an hour or two to refuel, but the tanker takes two days, during which time the troopships are sitting idle.  Once the tanker is loaded, the troops are finally allowed off their transports, which takes another day.  Total time is 3 days, instead of the two that it should normally take.  Or  you can micromanage to avoid this, which is annoying.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on October 17, 2016, 10:50:16 AM
I don't mind non-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.
Title: Re: C# Aurora Changes Discussion
Post by: IanD on October 17, 2016, 10:57:38 AM
I would like a refuel fleet or subfleet to same fraction of full capacity order. Currently if I move a fleet to a colony/fuel dump that does not have sufficient fuel to refuel the fleet completely I order fleet to refuel then equalise fuel. This is no longer possible and will add a lot of micromanagement to replicate. I would rather have ten ships all with 60% fuel rather than some with full tanks and others empty! When you are trying to keep up with NPRs that ignore fuel it is a useful tactic especially in the early game when resources may not be plentiful.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 17, 2016, 11:22:03 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 17, 2016, 11:44:01 AM
Each ship in a fleet doing different things in parallel does make sense. I had not thought of the situation where you have dedicated very large ships that could take a very long time to complete their specialized action if they are kept in the same fleet.

Or some sort of "Split fleet while unloading/loading" command that automates the process and merge them back afterwards, but that would seem like a pretty ugly solution.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 17, 2016, 12:25:21 PM
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

What I may do is have two options for refuel priority. Either by the ship/class priority mentioned in the rule, or by lowest fuel % first. That should solve the problem without too much micromanagement.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 17, 2016, 12:27:54 PM
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).

Ships won't use fuel any faster or require more fuel. They will just require more thought in how that fuel is delivered and the delivery process will take time instead of being instant The only real difference is that if that if a ship is stranded by lack of fuel, you will need a ship equipped with a refuelling system instead of just any ship.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 17, 2016, 01:05:46 PM
I've read through the comments on the various options for simultaneous load / unload etc.

I think it is reasonable that a ship could handle more than one type of replenishment. However, that would have to be in a situation where it had simultaneous access to multiple options. For example, a replenishment ship with both fuel and ordnance could transfer both at the same time but two separate ships (tanker and collier) couldn't deliver to the same ship at the same time. I could create a situation where each replenishment ship within a fleet can order its own priorities and the replenishment ships would know what each of the others was doing (so they would work on different ships). This is not order-based though.

I haven't started looking at other types of logistics facilities yet (for ordnance, supplies, cargo, etc) so there is a lot flexibility in what I could do. For example, perhaps colony ships or freighters need shuttles to load or unload cargo at planets without some form of cargo handling facilities. A cargo station might be the equivalent to the fuel station, with a spaceport able to handle both. Perhaps even a spaceport should have some limits to simultaneous cargo handling. Maybe a space elevator becomes an option at some point, or orbital docking facilities.

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.?

I think the best option is probably to keep the major loading orders separate (cargo, colonists, troops) but allow replenishment at the same time as other orders. This could be done by including separate orders (Load Colonists vs Load Colonists & Replenish), or by giving ships options to undergo simultaneous replenishment where possible). Some facilities could handle both (spaceport) while others had to handled sequentially (cargo station, refuelling station). There is a lot of scope for different installations or modules and we would start to see real port-type facilities developing.

Thinking out loud, maybe even remove all the logistics facilities from a population entirely and make them into orbital facilities (including maintenance facilities, fuelling, cargo handling, ordnance replenishment, etc.), which would be created using the ship design process. Essentially once a ship is in space, it stays in space. Anything produced on a planetary surface would be transported into orbit by the orbital facilities or a ship with cargo shuttles ('cargo shuttles' being an abstract element of a ship component designed for orbit/ground interaction). Possibly could have a new type of ship, known as a 'space station', which only has limited armour (or no armour) but has the ability to join with other 'space stations' to form a larger ship (creating a unique class in the process). That way, you could build the orbital facilities over time. Fleets could then interact with the 'space station' (which would have capacity for various types of logistic handling).

Anyway, still considering options :)
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 17, 2016, 02:04:52 PM
I admit to not using fleets with 'all of the above' very often, but I do think it bore pointing out.  (In fact, I hadn't even made the connection to the fact that the current cargo system, IIRC, works the way I described.)  That said, allowing replenishment tasks to run alongside normal cargo/colonists/troops would be an improvement over making everything sequential.

I'd quite like making space facilities more complex.  What you outline sounds like great fun.

Random thought: it might be possible to reduce the cargo paradox by increasing loading rate when dealing with multiple orders or small fractions of full capacity.  Say that the load time is made proportional to the square root of the fraction of total capacity being used.  So if you have two freighters (1 factory-unit each) and load one with a factory and another with a mine, then you'd get each onboard in 70% of the normal time.  It's obviously gameable by sticking the ship you want to load in with a bunch of other ships, although you usually don't have that much control over where things go.  But it would be somewhat better than we have right now.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 17, 2016, 04:33:05 PM
As long as the option still allows you to make slow and painful expansion as earlier TN civilization without tech or even a pre-transnewtonian empire I'm all for advanced options in logistics.

In fact I'd much love to start off with even more detail in the "very early" game, and build small primitive spaceships that slowly explore your home system with "small" 50-100 ton ships, rather then jumping right into 5000 ton + ships built in massive orbital dockyards.

It would be awesome to have to expend much resources and industry just to get your first orbital space-stations and dockyards up and running and into orbit.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 17, 2016, 05:52:51 PM
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). If those stores were depleted, the orbital infrastructure would draw on the population below.

If there is no population below, the 'orbital' infrastructure would effectively become 'deep space infrastructure' and could still function on its own resources.

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.

Because stations can be joined together, you could build them at the capital and ship them out in pieces.

Title: Re: C# Aurora Changes Discussion
Post by: 83athom on October 17, 2016, 06:33:05 PM
THANK YOU! Oh happy days.  :D Been waiting for that for so long. Time to build Freeground Station (once the update hits).
Title: Re: C# Aurora Changes Discussion
Post by: baconholic on October 17, 2016, 11:05:00 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: bitbucket on October 18, 2016, 12:13:28 AM
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?

This problem has...annoyed me a bit too in my current game, since I have several sizeable (>25m, so civilian shipping will pick them up and ship them out) genetically modified populations on Earth. Eventually I just ended up building a huge maintenance orbital station, towing it out to Luna, shipping up fuel and minerals, and having my non-commercial ships do all their maintenance out there. -_-
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 18, 2016, 03:18:57 AM
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).

This vision does have one conceptual weakness though. It makes sense to combine the orbital shipyards with these logistics stations in space.

But where do the shipyard workers live?

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.

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.


Another conceptual change that makes sense is mass drivers would logically connect to the space station rather then the ground populations, at least for bigger gravity wells with atmospheres, where it doesn't make sense to have them on the ground. For asteroids and smaller moons without atmospheres though they should probably be on the ground.

Would these components be interchangeable and be possible to put both on the ground and in orbit?

Should there be more such components?

Alot of thought needed here I think to get a good system that makes sense.

Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on October 18, 2016, 07:37:15 AM
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.?

Not sure how your code is set up, but if you made "order" an object with an "execute" virtual method that knows what needs to happen then you could have a single "replenish" order that either had a set of check boxes internally telling it what to replenish and/or contained a nested list of "replenish fuel", "replenish ammo" etc order.

Another option would be to two separate "time remaining" counters for "regular" and "replenishment" orders.  That would also probably make unrep code up elegantly - the TG would be moving or whatever on the regular counter while the other counter would be working on other refueling ships.

John
Title: Re: C# Aurora Changes Discussion
Post by: TCD on October 18, 2016, 08:40:17 AM
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.

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.
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.   
Title: Re: C# Aurora Changes Discussion
Post by: TCD on October 18, 2016, 08:48:07 AM
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.

This would also open up raiding in much more interesting way. Suddenly the thought of a stealth raider with a few meson cannons slipping through my lines to cripple my forward supply base becomes a real fear. And that will force some very interesting tactical decisions about how close to the front to build fuel/supply depots, how much protection they need etc.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 18, 2016, 09:27:17 AM
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!

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.

Even with TN tech your "personal spaceship" would probably weight 1 ton ( similar to the car of today ). The logistics of having 10 million workers commute into orbit daily represents moving 10*250 = 2500 million tons of civilian spaceship per year from ground to orbit and back using civilian technology.

In what kind of universe can you move 2.5 billion tons of civilian ships per year from surface to orbit as a cheap and normal commute to work, but it's too expensive to move the less then half a million tons of ships they build per year a single time into orbit???

Military ships and vessels through all times have had greater capabilities and budgets then civilian vessels do. Building the Military Spaceship on the ground and moving it into orbit once complete ( even if it lacked ability to return or this was a one time liftoff ) is what would be super trivial compared to having millions of workers commute to space and back on a daily basis.

Another thing that points against personal spaceships being available in the Aurora universe is the relative small scale production of fighters that's possible. If it was cheap enough to build hundreds of millions of personal spaceship the military would have their own versions of mini-fighters for sure that can operate within the atmosphere by the thousands and are pretty cheap to make too. Due to armor and heavier weapons these would probably be closer to the 10-100 ton fighters and tanks of today, then the 250-500 ton fighters of Aurora.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 18, 2016, 10:13:25 AM
No it's NOT trivial!

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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 18, 2016, 10:22:05 AM
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?  ??? ::)

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?

And why is it so easy to commute millions of shipyard workers but no other orbital infrastructure can be allowed to require workers?

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.

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 ).



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 ).
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on October 18, 2016, 10:27:49 AM
Also, they may be housed on site for a week or so then rotated around, cutting transport issues even farther. alex, your argument seems to be centered around the idea that the shipyard workers' jobs are business jobs where they travel to and from work instead of the blue collar work that they may have to live near because of deadlines and schedules.
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 18, 2016, 11:58:48 AM
This assumes that the workers aren't living in space condos with a space back-yard with their space family.

That's what I'm asking be simulated in that case.

Building Space condos with space back-yards for 10 million workers is not going to be cheap...


This is assuming you can only use the "bus" once and it needs to be rebuilt every trip.

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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 18, 2016, 12:12:25 PM
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.
(As an aside, it should probably be possible to build PDCs that can have at least some of these components, for initial launch and secure storage.)

Quote
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.
Actually, I'd almost question the assumption that all of the workers must commute to orbit.  I'd expect that a lot of the work happens on the ground, and the resulting pieces are then launched into orbit.  We know this can be done (that's how building components in the factories works) and there's no reason to assume they'd insist on doing everything in space.

Quote
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.

Quote
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.



Quote
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.
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 18, 2016, 12:46:51 PM
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.

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 ).
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 18, 2016, 12:53:56 PM
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.

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 ).
Why?  We're discussing building interplanetary/interstellar transports in Aurora, too, so picking ships/airplanes seems only reasonable.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 18, 2016, 01:34:05 PM
Reading between the lines here, I suspect most people are happy with the concept of having logistical infrastructure in orbit. However, some rationale needs to be found for the concept that TN ships can't land, while also accounting for the question that if we can shuttle thousands of tons of components into orbit, why can't ships simply land and take-off.

One option is technobabble (and I really need to create a comprehensive TN technobabble manual) stating that TN ships designed for interplanetary and interstellar travel cannot handle gravity wells. 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. That is why TN ships are so hard to detect, yet become easy to detect once wrecked (as they move fully into our dimension).

One side-effect of the design of TN ships is that gravity wells cause extreme turbulence in the liquid dimension, so once any TN ship is assembled and under power, it cannot move too far into a gravity well without the risk of destruction. However, cheap conventional shuttles (abstracted by the use of cargo shuttle bays or cargo stations, etc) are not affected by this so they handle all the movement of cargo and personnel from the planetary surface to orbit. They also handle the transfer of ships components to orbit, where they are assembled into ships, plus any movement of workers between the surface and orbit. Also many of the workers associated with shipyards are actually on the ground, which is why they are not affected by the destruction of shipyards. These conventional shuttles are only suitable for very short journeys (a few hundred km) and are therefore not useful for journeys beyond orbital space.

Does that pass the giggle test? :)
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 18, 2016, 01:57:46 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Scandinavian on October 18, 2016, 02:10:17 PM
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.

You could, in principle, build an atmosphere-capable interplanetary vessel, but why would you want to? The reinforcements that would make it able to land would be completely dead weight once you cleared low orbit, and the situations in which you want to land the whole vessel rather than sending a special purpose landing shuttle are not numerous enough to be a design consideration.

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.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on October 18, 2016, 02:16:12 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Scandinavian on October 18, 2016, 02:20:30 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 18, 2016, 02:24:00 PM
I just noticed a problem with the technobabble.  How do PDC hangars work?  It might be best to close them off for consistency.

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...
https://en.wikipedia.org/wiki/HMS_Misoa_%28F117%29 (https://en.wikipedia.org/wiki/HMS_Misoa_%28F117%29)
(OK, it wasn't a tanker at the time, but I couldn't resist.)

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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 18, 2016, 02:58:06 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Scandinavian on October 18, 2016, 03:54:43 PM
Square-cube would hardly stop you flying small ships to the ground at relatively minimal penalty.

I don't see a problem with having a "landing module," similar to "cargo handling" modules, but conferring a "landing ability." You'd then need to have a Landing Ability score above [technology factor] x [vessel mass]^1.5 x [planetary gravity] / [PDC hangar modifier]

This would enable smaller vessels to land with relatively minimal penalty, but would make a real trade-off worth considering when you get into capital ships or commercial freighter designs: Does it only need to go hub-to-hub, or does it have to be able to set down on every barren rock (say, to set down the construction crew to build the base)?

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."
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on October 18, 2016, 03:55:13 PM
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.

I would just remove hangars from PDC. And missile launchers, and beams. Let me explain why.

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.

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. And same with beams (which btw are already mostly just worth it outside the atmosphere)

I think this model has a very high potential, and better differentiates between ground combat and space combat. Leaving the pseudo science aside, I think it's a very good model that could make the game more balanced and interesting, and less exploitable as well.

Basically, with this, PDC are for ground combat, orbital bombardment defense, and some cheap gauss PD maybe.
Anything else, that is fighters, missiles, beam batteries and serious beam or AMM PD installations have to be in space, in appropriately dimensioned starbases.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 18, 2016, 04:33:42 PM
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.

Quote
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.

Quote
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. 
Quote
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.

I will say that space station hangars should probably work more like PDC hangars than normal hangars, in that maintenance needs to be cheap.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on October 18, 2016, 04:50:16 PM
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.

Honestly, PDCs need a bit of work.
1) Hangar; Changes to hangar mechanics (either removing them or restricting what can land).

2) Shields; While the large bonuses to armor (in the form of several free layers) is great, PDCs start lagging behind ships in defence because of a lack of shields. I don't see any reason (unless technobabble)why they can't equip them.

3) Weapons; While others (Zincat) are saying just to remove weapons from PDCs, I think they need a bit of expansion. While Lasers are useless in atmosphere, I don't really see why Railguns, Gauss Cannons, or Particle Beams are locked through the same rule set as they all are kinetic weapons. And the only real way they would be viable is if you could turret them. Missiles are a part of this to as even though missiles have TN engines, they could be magnetically launched out of the atmosphere/gravity well. A small change to PDC launchers is that are a bit larger (while keeping the rof buff) to represent the extra bulk to launch them out, and make it so PDCs cant equip regular launchers to ballence it out. I assuming that the change to refuel/loading rates will also include ordinance, fixing the "unlimited" magazines when over a planet body, making a reason for PDCs to have magazines.

4) Maintenance; Remove the intended deployment time part of designing a PDC. It simplifies them a bit, and gives a reason to use them over a long deployment time ship. Possibly also make it so they require 3/4 to 1/2 the needed crew, as it would be easier to maintain/man a base than a ship. Also, have them cost more wealth (based on size/tonnage) to maintain.

5) Refiting/Decomitioning; This is the biggest drawback to PDCs currently. There is no way to change a built design to give it updated systems, or a way to scrap it to replace it with something else. While I agree that you should be able to change things that represent the general layout (barracks, engineering space, magazines), You should be able to change out external things such as sensors or weapons easily enough or update systems like fire control without a major issue.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 18, 2016, 05:18:04 PM
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.


Title: Re: C# Aurora Changes Discussion
Post by: Black on October 18, 2016, 05:32:47 PM
It would prefer solution that would keep the ability of PDCs to mount weapons and hangars. Would something like what alex_brunius be possible? I like to build various asteroid bases and forts and they are quite common in various sci-fi worlds.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 18, 2016, 05:57:13 PM
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 :)

Title: Re: C# Aurora Changes Discussion
Post by: Zincat on October 18, 2016, 08:22:48 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Ayeshteni on October 18, 2016, 09:09:52 PM
Quote from: Zincat link=topic=8497. msg98112#msg98112 date=1476840168
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?

Aye.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on October 19, 2016, 01:13:27 AM
Sounds great.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 19, 2016, 02:54:44 AM
Sounds awesome indeed! Another idea that might mesh well is to have your fighter factories produce these generic shuttles too, but instead of being treated as units they are providing the planet with "orbital lift capacity" or something like that. This capacity then is used as a constraint on total shipbuilding and everything else you want to bring up into the orbital logistics from surface. The shuttle capacity of all ships in orbit would automaticaly be included and added to the capacity.

That would give fighter factories something useful to do when you don't need them, which I found is quite often.

Probably want a new tab in Economy with a summary of all the capacity of the populations orbital station as well as things like shuttles/ lift capacity and storages in orbit.
Title: Re: C# Aurora Changes Discussion
Post by: Tree on October 19, 2016, 03:52:58 AM
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.)
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 19, 2016, 04:49:11 AM
Salivating already.  Very excited at these proposals, but could the NPR's handle it?

That is a good question :)

I think so. I will be able to add more decision-making to NPRs because the code will execute faster now. They will definitely need ground assault capabilities though.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 19, 2016, 04:58:26 AM
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.)

I was considering the TN fighters overnight. Maybe orbital shipyards can start at 250 tons, not 1000 tons, so TN fighters are built in orbit. Fighter factories would build planetary fighters and perhaps (as suggested in an earlier post) ground-to-orbit capacity.

Mass drivers may become a ship component (as that helps with deep space stations). In fact, you could build some form of mineral collection facility near a jump point to make logistics easier. Any minerals beyond the cargo capacity would be lost.

I think DSTS would be OK, as would factories. It is TN-powered flight in a gravity well that would be restricted.

NPR starting OOB is a separate issue. I'll address that though.
Title: Re: C# Aurora Changes Discussion
Post by: IanD on October 19, 2016, 05:11:38 AM
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?

That is easily solvable if you allow a slow construction in orbit without the use of shipyards, say 1/5 rate of shipyards with a limit of only one project in progress at any one time. Shipyards may not be essential for ship construction, just much more efficient.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on October 19, 2016, 05:22:45 AM
Really like the idea of having different fighters for close combat support around planets. Potentially could see these as smaller versions of the existing fighters and be designed with 5ton base size components rather than 50 ton. Same could then be done for corresponding ground units and anti fighter defences.

I like the idea of phases to a planetary assault with the need options to win air superiority pre landing troops etc.

On some of the issues around how the suggested technobabble causes issues with the logic of other areas of the game and existing use of TN materials in other units and ground facilities potentially a solution would be that not all TN materials have an issue with gravity wells. 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?
Title: Re: C# Aurora Changes Discussion
Post by: Black on October 19, 2016, 06:26:11 AM
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?

Problem with sorium being unstable in gravity well is that you would not be able to refine and store it on the planet.

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.

And about restrictions of TN-powered flight in gravity wells. If we accept this then we shouldn't be able to use missiles to attack planets, because missiles would be lost in the moment they would get too deep into gravity well.
Title: Re: C# Aurora Changes Discussion
Post by: Tree on October 19, 2016, 06:51:45 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Black on October 19, 2016, 06:58:34 AM
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.

Well for some reason I didn't realize this. This should do.
Title: Re: C# Aurora Changes Discussion
Post by: DIT_grue on October 19, 2016, 07:08:17 AM
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.

I've been using Aether. It seems to me to be an obvious recycling candidate for a near-future human scientist looking around for a name for an omni-present (or roughly so) pseudo-liquid facet of reality.


As to the general discussion, the issue I'd like to draw attention to is beachheads for planetary invasions. 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.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on October 19, 2016, 07:19:23 AM
Problem with sorium being unstable in gravity well is that you would not be able to refine and store it on the planet.



Yes, I would think that could actually be pretty interesting side effect, needing either larger orbital fuel silos (big hit and run target) or make use of low gravity planets or asteroids to bunker the fuel.

On missiles being used against planet targets I agree that reverse problem should also hold true but that could be solved by a simple two stage missile that delivers the warhead whilst the TN engine and fuel is left to blow up in the upper atmosphere.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on October 19, 2016, 07:29:06 AM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Bughunter on October 19, 2016, 08:08:58 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on October 19, 2016, 08:50:01 AM
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.

I'm sorry, but this makes no sense. You are of course  free to like how things are now, with missiles from PDCs, but if we do use technobabble at least it has to be consistent :)

I for one really like this proposal of separating "orbital" fighters, weapons and such from TN fleets/starbases/weapons. It adds in my opinion a very interesting strategic/tactical layer and it is more consistent.

I will also say that it makes more sense regarding missiles to attack planets, when considering a pseudo-science point of view. With max tech, you can design a TN missile that travels at half the speed of light. Supposing a planet with an atmosphere, an item such as this should be obliterated the moment it comes into contact with said atmosphere.

And if we instead postulate that this is not the case because the Tn missile is not really traveling in our "dimension" or something similar, there is still the problem of the impact. A 2 ton missile, for example, impacting the ground at half the speed of light. The kinetic energy released is immense. A warhead would even be unnecessary ...

Yes I know, I'm seeing things my way. But hey, I like this idea and I'm allowed to have a preference  ;D



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.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on October 19, 2016, 09:09:31 AM
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.

Agree that was why I was trying to make the distinction between raw Sorium and refined Sorium for fuel however your suggested technobabble on reaction in the engine seems to be a simpler basis on which to change the wider game elements.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 19, 2016, 09:50:59 AM
I'm entirely in favor of having specialized close-planetary forces, although I will point out that it could significantly complicate logistics if you have to stand all deep-space forces off from the planet.  My proposal would be to instead basically have two domains, deep-space and near-space. Deep-space forces are what we have now, and are greatly slowed when in gravity wells.  Not totally stopped, but reduced to a crawl, something like 1% of normal speed, and that's only when they're outside of range of TN tidal forces, so they still can't land.  Near-space forces are maybe 10% as fast as normal, but are not slowed by gravity wells.  So your deep-space ships can still dock right on top of your planet, but can't fight there, and it's possible to transfer your 'planetary fighters' between planets, just very slow.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Black on October 19, 2016, 09:54:48 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on October 19, 2016, 10:12:25 AM
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.

I'm not saying there should be a difference. Since the problem is gravity-based then TN engines would not work on either type of planets, atmosphere or no atmosphere.
I was just pointing out the system we have now would have not worked anyway on a planet with atmosphere  :) You would have ended up with a badly damaged planet just by launching missiles from a PDC.


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.

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.

Fighter factories should be renamed though. Maybe to "orbital ships factories" or something similar.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on October 19, 2016, 10:19:47 AM
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.
Think of the launchers as magnetic launch rails to fire the missiles away from the ship/gravity source before the engines ignite.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 19, 2016, 10:36:16 AM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on October 19, 2016, 10:45:26 AM
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.

Ah that. Well, I suppose Steve could easily solve/ manage that complication. For example, significantly reduce the retool time/cost for very small tonnage or similar. Or maybe even remove it alltogether and just increase the cost of fighters a little bit to account for retooling, instead of having to do it at the shipyard-level.

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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 19, 2016, 11:03:07 AM
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.

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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 19, 2016, 11:26:05 AM
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.

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).

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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on October 19, 2016, 11:38:52 AM
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.

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.

*I'm assuming that adding an extra slipways for a, say 500T dockyard would be very quick and cheap even with the current mechanics.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on October 19, 2016, 11:45:31 AM
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).

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.
Title: Re: C# Aurora Changes Discussion
Post by: Black on October 19, 2016, 11:52:46 AM
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.

Yeah I always saw Aurora as a sandbox game that allows us to recreate various sci-fi worlds or create our own. This would IMO limit that possibility quite significantly, this is also the reason that I don't really like the possibility of removal of PDC launchers and hangars.

I am of course all in for new features that will give us more possibilities for planetary warfare or anything else. But I think that symbiosis with current features is the best way even if we have to sacrifice a bit of technobabble for it.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 19, 2016, 12:09:29 PM
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. 

Quote
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.
This does raise the question of why I can't use assembly lines for craft of 600 tons, and I don't have a good answer for that.

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.
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'.

Quote
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 19, 2016, 01:25:16 PM
At the moment I am just considering options - not committing to anything definite.

I really like
a) The concept of splitting planetary and space-based movement due to the distortion in the 'Aether' caused by gravity wells
b) Moving the logistics facilities off world supported by non-TN shuttles.

I am still open on exactly how the interface works between planetary and space. I don't think missiles could be launched from the surface or against it due to the restrictions on engine (although there are complexities around a 'bomb' second stage). That opens up planetary fighters carrying 'bombs' from orbit to the surface, but it also opens up planetary fighters firing TN missiles from orbit (and then hiding again). There has to be some way to manage that element of it. We can't state that planetary fighters are unable to reach orbit, because we need shuttles to reach orbit to support the logistics option. Maybe it isn't that bad, as once ships are in beam range they could engage those fighters if they come out of the gravity well.

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.

The alternative is some form of restriction on TN weapons functioning at all within gravity wells but leads to my previous suggestion.

Anyway, still considering and open to suggestions :)
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 19, 2016, 01:57:50 PM
Another conceptual question that needs answering is: Do orbit and planet have completely separated inventories? ( minerals, components, missiles, buildings, Infrastructure ) and if so how is all this extra management handled in a smooth none frustrating way?
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on October 19, 2016, 04:17:45 PM
Ok, I'm trying to write my personal, comprehensive suggestion of how it could be. Wall of text incoming and still a work in progress, up to discussion. Obviously in the end Steve chooses, but I hope this can be useful.

First, let's list the subjects we have in play.
- TN ships (They do not strictly follow the conventional rules of time/space and physics)
- Non TN (Orbital) ships (significantly slower. Follow the normal rules of time/space and physics)
- Starbases/shipyards/orbital installations
- Planet and planetary troops/PDC
And the weapons
- Missiles (because of the TN engine)
- Other "beam" weapons (anything that does not have a TN engine, basically). For now I'm grouping them all together.

Now, I think we all agree that TN ships and starbases/shipyards/orbital installations have to be able to shoot at each others at a minimum. Else nothing works. Also, the premise for the change is that TN ships "travel in the Aether" because of their engines. And that the Aether is disturbed (in a lethal way!) by gravity wells. There are a few immediate consequences:
- TN ships can never land on a planet
- TN missiles cannot be launched at a planet, nor they can be directly launched from a planet
- "Orbital" shuttles and small ships deal with most or all of the surface-to-space operations necessary for a spacefaring civilization to work. This is actually quite well represented already by spaceports (although hyronically, not by dessign).

I think some goals and objectives should also be listed. I mean, what do we want to obtain here with these changes?
- A system that is more or less coherent and works in a logical way following technobabble
- A system that is also fun to play. It should give more options for tactics and variety, while not being an obstacle to gameplay.
- A system that is not unbalanced, because this is a game and FUN>>>everything else. If we come up with something where one option trumps everything else, there's no point and it's not fun. If a single ship in orbit can blast away any number of troops and PDCs, there's no point building any of those.

Now come the questions though, who can shoot at who? And with which weapons? If a starbase can shoot at a ship, can a PDC? If not, why not? If a TN ship can shoot at a starbase, can it shoot at a PDC/planet? If not, why not? How do we solve all this without creating new problems? In the current game, in my opinion, this is not done in any consistent way (sorry Steve :) ) A ship can shoot missiles at a planet, but railguns do not work. That does not make much sense to be honest.

So, here comes my proposed technobabble solution. It's not perfect but I think it's quite comprehensive. It has to do with the nature of the Aether (or whatever we want to call it) and Gravity
Since the Aether is basically a different, superfluid dimension in which a ship can move using a TN engine, a ship with an active TN engine is considered to be only partially in the real space. The "other half" of the ship is in the Aether. And large gravity wells are incompatible with the Aether. Strong gravity is, infact, the contrary of the Aether. You could say that anything within a large gravity well is in a "superdense" state of existance (or dimension), the very contrary of the Aether.
Basically you have the Aether (superfluid), normal space (neutral state), and large gravity wells (superdense)

Because of this, these are my proposed rules:
- A ship in the Aether (superfluid) can interact and can be interacted only by other entities NOT in a large gravity well (superdense).
- An installation in a large gravity well(superdense) well can interact and can be interacted only by other entities NOT in the Aether (superfluid).
- Anything in normal space (neutral state) can interact both with large gravity well (superdense) and Aether (superfluid)
- A TN engine can transition a ship from normal space to Aether and vice-versa, but the process takes time in which the ship is immobile and unresponsive (1 minute? time to be decided and discussed). This has nothing to do with speed. A ship can be in the Aerther and completely stopped, 0km/second, but it still "phased out". Only if the TN engine is completely shut down then the ship goes back to normal space.
- An object from a "superdense" gravity well that leaves it, like a shuttle, enters normal space (neutral space) after the same time (1 minute?). The process is basically automatic, but NOT instant.


Now, let us try to see how this pans out in all cases:
- A TN ship can shoot at starbases, orbital structures and "orbital ships" who leave the gravity well of the planet, but NOT at the planet itself because the planet is in a "superdense" state (or dimension). Even a beam from a TN ship is half submerged in the aether, so it cannot interact with a "superdense" state like a planet or a PDC or a troop.
- Likewise a planet-based weapon can shoot at orbital starbases or ships, but not at ships in the Aether, which are in the opposite state of "superfluid" and only partially in normal space.
- An orbital station or ship in normal space (outside the gravity well) can interact and shoot at both planet and TN ships, because it's in a neutral state. Only one "step" away from both "superfluid" and "superdense".
- A TN ship can shut down its engine to enter normal space. If so, it is immobile (no engine) but CAN shoot at a planet. And be shot at from any PDC/orbital ship. Doing so is a risk though because the ship is immobile and unresposive for the time aforementioned, vulnerable to either TN fleets ambushes or planetary defenses.
- Or the TN ship can, after cleaning up the orbital installations, blockade the planet safely from the Aether. It can shoot at anything that arrives or tries to leave, but it cannot shoot or be shot at from the planet defenses.
- An object that leaves the gravity well of the planet (superdense state), like an "Orbital" torpedo fighter, can attack a TN ship but only after the aforementioned "transition" time to "neutral space". It can move (because the process is not artificially induced by a Tn engine), but still very risky and not ideal. Before it can shoot, it has to survive until its state is "neutral".
- TN missiles can be shot from TN ships to orbitals, or from orbitals to TN ships. Conventional missiles (or bombs) can work either from orbitals to planet or from planet to orbitals.
- Other weapons always work (because they do not have TN engines), but since they inherit the state of the ship/installation that uses them (laser "phased in the Aether" or "Phased in the superdense"), "superfluid" cannot shoot to "superdense" and vice versa
- A TN fleet can of course carry around "orbital" fighters and the like, to use specifically against planets. Planetary assault carriers, yo! Also of course one can design specific ships whose objective is to exit Aether and duke it out with planets. Planetary assault cruisers, yo! Of course these super specialized TN ships would suffer gravely or be useless in normal engagements, because of the design differences (a planetary assault cruiser would need a TON of armor or shields, thus likely being extremely slow and having little space for weapons).

I think this solves all the problems, more or less. A TN fleet can exit Aether and shoot at planets, but this is slow and dangerous, and PDCs have the tonnage  advantage too because they don't need a lot of the necessary systems for a ship. Likewise, planetary fighters can exit the gravity well and shoot at TN ships, but they have to survive long enough to do that! A TN fleet cannot just slag a planet from the safety of the Aether, nor can planetary fighters shoot at said TN fleets without taking a great risk. And ground troops are more relevant and can be more varied as well (like Steve said, AA troops for example)

Regarding other issues, here is how I think they would pan out
- All TN ships are assembled in orbit, including TN fighters. You cannot even test a TN engine on a planet, so you have to do it in orbit
- Components can still be prefabricated on the planet. Extreme modularity is supposed here. The parts are then assembled in the Spaceyard.
- I am undecided about missiles. To be honest, I think it would fit more if they were fabricated in space as well. As in, you could make it so a TN engine cannot even EXIST in a gravity well.
- Since people live on planets, not on shipyards (consider how many MILLIONS of people are working there. So no, they live on planets), you need an adequate amount of "orbital" shuttles. The same is true for any spaceport you have, they also need shuttles. So my proposal to solve this is that you need a number (let's say X) of "Orbital ships" factories for each shipyard and each spaceport. For example, 1 of these factories for every 2000 tons of a slipway and 5 for each spaceport. These factories are considered to be always working to build and do maintenance on all the "orbital shuttles". And this abstracts the entire process. Want a new shipyard? Build 3 or whatever more factories and the like. They are, basically, similar to maintenance stations for shipyards and spaceports.
- Additional "Orbital ships" factories above the required number can be used to build "orbital" fighters and crafts.
- Minerals are stored on the planet carried by these shuttles to orbit when required. You don't want to bloat the already huge and frail Shipyards with mineral storage.
- About mass drivers, they still work. Yes, the mineral that is shot and then caught suffers the extreme shifts from "superdense" to neutral to "aether" and vice versa during the trip. But who cares? Even if a chunk of mineral is blown to shreds in the process you are still going to melt it eventually.
- The Cargo Handling component, given the changes in lore, should be renamed to "cargo transfering shuttles" or something similar. Maybe made more bulky as well.
- I think PDCs should have a maintenance cost, albeit lower than ships, for balance purposes. Filling a planet with PDCs should have some cost.


This is it, hope you liked the read. I think it's pretty consistent, it makes sense, and it also provide a decent balance between new functionalities, fun and sound strategy.

EDIT: to clarify, the process to change "state", for example turning on a Tn engine or leaving a gravity well of an orbital ship, would be much akin the jump engine we have now. A period in which the ship cannot do as it pleases, and has limitations.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on October 19, 2016, 05:32:42 PM
My thoughts on how it could be done (if drastic changes such as discussed were to come about).

- Designs with TN engines can only exist in the "aether" space but can be influenced by "real" space. This would hopefully inference a gravity well technology so you could create pocket gravities in the aether to make an area of denial for ships/missiles. Nebulas are an area where real space and aether butt against each other, so ships are still reduced speed, you cant launch fighter sized objects, no missiles, and there is a reduced sensor coverage, however thermal and EM signatures are more masked in the nebula due to the interactions of the two spaces. I'm 50/50 about whether or not you can activate shields in a nebula (or make it so one of the types of shield can while the other can't).

- The construction of TN fighters and missiles can still be done in a gravity well. However they are just lumps of useless metal until transferred to a suitable location (mothership or missile ship) via orders. This means until they are transported to space, fighters are counted as ordinance/component in a stockpile on the planet and cannot be given orders.

-The buildings can be left as they are because I've always seen them as the orbital facilities and the ground installations needed to support them (transport, etc). If they are changed so they represent only the orbitals, then they could require "support facilities" to be constructed to support their use. A slight change to the way workers are represented would be these support buildings (and similar ones like the spaceport, Sector command, etc) draw people to the "Service Industries" part of the population.

- TN weapons have a distortion affect with gravity wells, meaning that while they have full affect on things in the aether, they have a reduced affect on things in real space within a gravity (things in real space not in gravity are affected fully). TN beam weapons can be fried from real space as they exist in both realities (the weapon and target).

- TN Missiles can only be launched from a gravity (to the aether) from PDCs, but PDC designed launchers are ~20% larger. However, while TN missiles cannot be fired at a gravity well, there could be a form of bombardment missile system similar to the Plasma Torpedo (which I personally wish to come back) that can be targeted and fired from the aether at a planet (whether in the form of a large missile/bomb or a cluster of 1 damage rockets/bomblets). This could be countered by either a type of building (a generic "bombardment defense installation" you would build like a factory), or a module you can put on PDCs/Starbases/Ships (or just make it so the CIWS can fire at them).

-Ships given an order to refuel/restock/etc need to "phaze" out of the aether ("phaze in" to realspace)(I think Phaze Out should refer to entering aether and Phaze In refers to returning to real space) so will be defenseless while performing these kinds of orders. These actions can be canceled while underway, but the ship would need a small period of time before it can return to the aether (dependent on a tech level).


There anything I didn't touch on?
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on October 19, 2016, 11:25:16 PM
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.

I think things work fine as we are. We don't need a strict separation between what's in space and what's not.
Title: Re: C# Aurora Changes Discussion
Post by: Tree on October 20, 2016, 12:57:28 AM
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.

I think things work fine as we are. We don't need a strict separation between what's in space and what's not.
Yes.
Title: Re: C# Aurora Changes Discussion
Post by: Elouda on October 20, 2016, 01:16:51 AM
Agreed with the above. I wouldn't mind some additional detail here, but the whole ground/space engagement rules are taking things too far, and I think would detract from overall enjoyment.
Title: Re: C# Aurora Changes Discussion
Post by: consiefe on October 20, 2016, 02:43:22 AM
I love when a game mimics real science as much as possible but i really enjoy present depth of this game as it stands now and really against the idea of this level of complexity on how many rules the player should follow to play the game. 

I love Aurora because it has minimal limitations on the way that the player wants to play.  This is limit overload.  I agree with the posts above.
Title: Re: C# Aurora Changes Discussion
Post by: IanD on October 20, 2016, 03:18:25 AM
You are trying to model a tactical and strategic game. I agree with the above posts, its being over thought. Apply the KISS  principal. If you think you need too many workers in the shipyards look at historical data (see below for UK). Reduce the numbers in the yards, increase the "support" numbers eg the population required to feed, house entertain etc.

                                              June 1940   June 1942
New naval shipbuilding               62,400        75,900
Naval repairs and conversions   41,500         38,400
HM Dockyards                             26,400        34,900
Merchant ship repair                  44,000         58,500
Total                                          203,100       244,300

The separation of TN and "conventional" space IMO goes to far. While Aurora is Steves game when I play it I want to impose my own rational on it! Be it Star Trek, Star Wars or (usually) something else. For instance in RL visible light lasers work in atmospheres but X-Ray lasers would be severly attenuated. In Aurora they both work equally well in atmospheres  below 1 Atm. and niether can shoot out of the atmpsphere. Does this really matter to the enjoyment of the game - no!

Ian
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 20, 2016, 03:47:21 AM
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?

Title: Re: C# Aurora Changes Discussion
Post by: consiefe on October 20, 2016, 04:34:34 AM
It's much better now.  But I would love some ships to have ability to land on actual planets for RP reasons.  I really don't like limitations.  You can add an adaptation time to the gravitation force which the ship stands still during that time.   
Title: Re: C# Aurora Changes Discussion
Post by: Tree on October 20, 2016, 07:16:23 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 20, 2016, 07:29:01 AM
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.

The reason for ships to stay in space is so populations on planets and 'populations' in deep space can function in the same way with a single set of rules. The technobabble is to intended support that concept.

BTW, there are no 'landing' mechanics right now. Ships interact with the surface but the means is undefined (beyond entering a PDC hangar).
Title: Re: C# Aurora Changes Discussion
Post by: OJsDad on October 20, 2016, 08:12:41 AM
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

I've really enjoyed reading the back and forth on this subject.  Lots of good discussion.

I'm not sure you need any technobabble to explain why ships don't land.  Just look at shipping today.  Ships do everything at ports.  Cargo going to or originating further inland are transported to the ports via other means.  Having your logistics in space allows for cheaper and easier handling of ship upkeep and transfer of freight too and from the surface. 

You could also throw in safety issues with having large ships possible crashing into large metro areas.  You could even say that sorium is a toxic substance that if released in the atmosphere, would have a very high casualty rate.  Thus keeping those facilities and the ships that use very large quantities of them out of the atmosphere.  Yes, shuttles would have the fuel, but at very small amounts and being smaller craft, they have more affordable safety measures to prevent the fuel from escaping.
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 20, 2016, 10:01:48 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Inglonias on October 20, 2016, 10:12:07 AM
Quote from: Steve Walmsley link=topic=8497. msg98164#msg98164 date=1476953241
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?

I like it.  How will these orbital facilities be represented? As normal facilities are now, or do we have a "space station" that represents however many maintenance facilities or whatever we have in orbit?
Title: Re: C# Aurora Changes Discussion
Post by: TCD on October 20, 2016, 10:37:52 AM
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...

Just because we can do something in the current version doesn't mean we should be able to do it.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on October 20, 2016, 10:44:20 AM
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?
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.
Title: Re: C# Aurora Changes Discussion
Post by: bitbucket on October 20, 2016, 10:51:58 AM
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.

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, for example—limit current PDC hangars to fighter class ships (ship-based hangers in space remain unlimited) and have a "drydock" class module that only works on, say, a body with less than 0.01g which can allow any size of ship you can fit into them.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 20, 2016, 10:58:43 AM
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.

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. )
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 20, 2016, 10:59:46 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: bitbucket on October 20, 2016, 11:05:16 AM
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.

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?
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 20, 2016, 01:00:43 PM
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...

Just because we can do something in the current version doesn't mean we should be able to do it.
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: BwenGun on October 20, 2016, 01:52:47 PM
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.

Well logically space based forces should be able to wipe out unsupported ground based forces easily anyway. Even if you don't have lasers to burn down through the atmo you can just drop kinetic strikes using rocks, debris and especially dense Ensigns. The problem with kinetics would be that even if you're using relatively small, hardened KSVs they're going to do some serious collateral, and of course if launched far enough away ground based scanners would likely be able to detect and vector said relatively slow (at least in a TN military environment) projectiles and feed that data to ground based defensive lasers to shoot down. Now lasers are preferable because they're precise, and require very little in the way of resupply.

That said space based lasers run into problems against ground based due to the fact that a ship based power supply is always going to limit, to a certain extent, how much actual damage the laser can do through the atmosphere. Whereas groundbased lasers can draw from entire planetary power grids and thus can afford to be both large enough and powerful enough to punch up through the atmosphere and out into low orbit. Not to mention planets are generally speaking wonderful natural heat sinks for the operation of lasers compared to the finite heat sinks available to ships.

Though the big advantage a ship based laser will always retain over one based in a PDC is that it can always dodge. A PDC is stationary, and once its fired it's not exactly going to be difficult to find and obliterate with concentrated fire, or even by pulling the ships further out and throwing some rocks down the gravity well. Leading to some interesting strategic decisions, do you have lots of small PDCs that mount a few lasers and sufficient armour to survive a one on one engagement with an enemy ship, thus allowing you to activate them slowly in order to wear the enemy fleet down whilst retaining a few hidden points to use when the enemy finally brings the troop transports close enough to be vulnerable. But at the same time risk those same small PDCs being easily found and overrun by enemy ground forces if they are willing to land troops in the teeth of a determined ground based laser grid. Or do you build massively armoured PDCs with multiple huge lasers capable of knocking out enemy ships, shrugging off hits, and resisting ground based attack at the same time.

Past that you could also add an army unit type, mobile surface to orbit lasers, basically mobile ship killing lasers whose entire purpose is to shoot and scoot as much as possible, granting ground based forces some measure of anti-space weaponry without having to build and ship PDCs. Useful for either strengthening a worlds defences (or even as a stopgap defence before PDCs can be built), or to accompany invasion forces in order to provide some backup against enemy airpower and potentially even space forces in case the invading force manages to lose control of orbital space.

At the moment, I believe, units can stay hidden in PDCs before heading out and engaging enemy units and thus revealing themselves. It might also be an idea to potentially give units a limited ability to just naturally hide, representing the fact that any space based military would recognise that modern surface units need to be able to hide themselves from orbital forces in case they lose control of orbit to prevent those units being vaporized in short order. With perhaps a small chance every day or so that a unit will be discovered, in part or full and thus open itself to orbital fire and so lose some strength and cohesion. You could even add the option for ground forces to attempt to fade into the background and attempt to carry out a low intensity war, using small units to prevent orbital strikes taking out to many of them in one go whilst continuing the war until hopefully the navy turns up to turn the tables on an invader.

All of which would make for quite an interesting way of approaching conflict in the game. The ability to heavily fortify planets with hidden surface installations would make planetary invasions a lot more chancy, with the risk of lost or heavily damaged ships much more likely. Far more so than now, where a force capable of wiping out orbital stations and driving off the enemy defensive fleet is much more easily able to assume complete control and if necessary lob TN missiles down the gravity well to quash the obvious resistance before landing troops. Instead invasions could become a little like sieges, with space based forces probing the ground based defences, seeking to tempt the defenders into revealing a few PDCs here and there in order to knock them out before guaging when to launch the invasion, all the while hoping the defenders didn't hold back too many PDCs or Ground to Orbit laser brigades to make a mess of the descending drop pods and the ships in relatively low orbits for ground support operations.

Not to mention interesting strategic options, whereby you could pour defences into chokepoint systems with the aim of using it to draw away an enemies fleet and ground strength in order to fight a long slow siege to wear down the planets defences. Or have rapid reaction forces of mobile infantry units supported by Ground to Orbit Laser battalions in fast transports, designed to jump in with small fleets on the frontier, land on mining asteroids/early stage colony worlds. The hope being that the GOLS battalions have the punch to catch whatever relief forces an enemy sends out off-guard, and either delay the retaking of those positions by dint of forcing them to be wary and call in reinforcements. Or blow up their initial force and then force them to either cede that ground or send another force to retake it.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on October 20, 2016, 03:14:03 PM
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?

I don't think even that cutoff adds anything, though.

Honestly, I'd just say that ships can land, but they're not designed for it. Basically leave it as it is now; ships can load/unload cargo with planets, do it faster with a spaceport, and can dock in PDCs/PDCs can fire missiles at ships in space. You'll still probably need to work out cargo transfer for space stations, but I'd suggest just doing it like the fuel transfer and have it use basically the same system whether you're transferring between planets or or ships/stations.
Title: Re: C# Aurora Changes Discussion
Post by: baconholic on October 20, 2016, 04:01:52 PM
Why don't we just split up the current PDC functions into orbital weapons platform and ground base barrack/hanger.

The orbital weapons platform will simply be a wing of the space station. It will not suffer from atmospheric interference like the current PDCs do. Basically it'll be an immobile ship.

The new barrack and hanger will function as a planetary installation. Each barrack will house 1 battalion and each hanger will house 1 fighter.

To simulate atmospheric fighter combat, we can have fighters under 500 tons add their PPV during each ground combat phase. This way the assaulting force can bring a huge fleet to destroy/capture the space station orbiting the planet, but they'll still need assault carriers with <500 ton fighters in order to support the ground combat.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 21, 2016, 02:23:47 AM
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.

Alot of stuff in Aurora have math that "doesn't really work that way" in reality  ::)

Even with the TN technobabble Aurora is not really modelling economy of scale except for warship armor for example. And I'm thankful because it would be a pain to calculate and estimate for example factory output or infrastructure needs if they used a non-linear formulas instead.

My point was that if shuttles are worth the effort of adding they should be a meaningful constraint, and as such having gravity impact their efficiency in a linear way ends up closer to reality then it having zero impact does.


To be honest I feel that Steve is missing a big opportunity in Aurora to have the planets feel unique and special when he is hesitating to use their gravity, surface area and other properties in as much of the game mechanics as possible.

I think it would help alot to make the game more immersive and tell interesting stories if you didn't just terraform planet #20 in a long row of planets that in game mechanics feel identical to eachother until it also can sustain infinite population, but if you actually had to spend 5 times as long time to terraform the planet due to it's larger surface area, and in return it could sustain 4 billion instead of the 300 million the smaller moon can sustain, but as a tradeoff the large size and gravity put extra requirements on your shuttle needs.
( just example numbers )

I'm sure there are many other areas and game mechanics where the same concept could be expanded into like:

Title: Re: C# Aurora Changes Discussion
Post by: Zincat on October 21, 2016, 07:15:20 AM
OK, I've read back though and we are getting quite complex :)

Fair enough. I will admit to that  :) I liked my version, but so be it.

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?

Well, it's acceptable. However I will still say something that in my opinion is way too unbalanced. And that is PDCs. I think it's actually a serious problem, because PDC become way too convenient compared to ships, especially with lack of maintenance. And hangars. I think the problem needs to be addressed.

PDC already have the tonnage advantage compared to ships of similar size. And also they have 0 maintenance.  While ships in orbit cost a lot of minerals and have overhaul downtimes. Now, it makes sense for said maintenance to be lower than ships, but not 0. Especially on planets with no atmosphere (no protection from space) or dangerous atmospheres, there SHOULD be a constant cost in order to keep a PDC operational.

I propose a PDC maintenance perhaps half the amount of a ship in orbit. On the plus side, it should work without maintenance facilities, it's just a flat cost. Bonus points if Steve codes it so the maintenance is dependant on the atmosphere type (you know, maintenance on a corrosive pressure cooker like Venus...)

Same with hangars, as it is it makes no sense and is unbalanced. I can build a 1.000.000 ton hangar, store my whole fleet there and pay no maintenance. Why? I really think this should be changed,  like this it is unbalanced.

<snipped for legibility>

I agree on all accounts, I'd LOVE to have more diversity based on planet type  :)
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 21, 2016, 07:48:23 AM
Sounds like it should be quite simple to have PDCs require a bit of maintenance now assuming the 7.2 changes are rolled into the C# version since maintenance was changed to use MSPs instead of resources:

http://aurora2.pentarch.org/index.php?topic=8151.0

( Reading through the thread of 7.2 changes just increase the desire to play with all these glorious changes even more )
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on October 21, 2016, 07:51:50 AM
I think having PDCs cost maintenance, albeit less than ships and not requiring maintenance facilities, sounds very sensible.

Although I'm going to miss zero-cost mothballing, quite a few of my most fun battles involved reactivating thoroughly obsolete ships that I would have scrapped without this.
Title: Re: C# Aurora Changes Discussion
Post by: ryuga81 on October 21, 2016, 08:52:32 AM
Quote from: Steve Walmsley link=topic=8497. msg98164#msg98164 date=1476953241
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?

IMHO it is still too complex.  I believe we can assume all maintenance and refueling is handled by a swarm of TN drones and shuttles that haul stuff and personnel back and forth and take care of simple overhauling (but not complex damage repairs, that's done at shipyards), so even if maintenance/refueling systems are land-based (as they are in current version), actual logistics are done in space and ships do not need to "land" (except fighters, that are small enough to land).

It is only logical to consider that the planetary stock of fuel and maintenance/replacement parts is not effectively kept in orbit, but transferred on a need basis, in this case the requirement of an orbital station or ship-mounted shuttles adds a layer of unnecessary complexity. 

Building a maintenance facility, in this case, also means building drones/shuttles and whatever it takes to operate in space, and it also explains why a maintenance/refueling facility is not "targetable" in space (once a threat is revealed, all drones/shuttles are called off and scattered on the surface, so any attack has to be carried through usual orbital bombardment or planetary invasion).
Title: Re: C# Aurora Changes Discussion
Post by: Black on October 21, 2016, 10:20:03 AM
I like the possibility of crippling enemy forces by destroying their orbital infrastructure. It allows you to hurt your opponent in situations where you don't have enough ground forces to occupy the planet and without turning the planet into nuclear wasteland.

As for the PDCs they have some advantages over orbital stations or ships, but by deploying them on your planets you are risking your population and ground infrastructure in combat (at least in situations where enemy is using missiles).

Orbital stations can also be refitted and transported or towed to different locations. You cannot disassemble existing PDC to transfer it to different planet or to use it to guard a jump point or your fuel harvesters orbiting moonless gas giant.
Title: Re: C# Aurora Changes Discussion
Post by: Father Tim on October 21, 2016, 08:27:51 PM
In my Aurora, ships land on planets.  In my Aurora, ships are BUILT on planets.  Ships are loaded and unloaded on planets, usually by six muscular people and some sort of wheeled conveyance.  My Aurora is the Aurora of space westerns like Firefly/Serenity, Star Wars, and Battle Beyond the Stars.  My Aurora is also the Aurora of the Age of Sail.  My ships have 74 one-sixth size Gauss cannon and two fire controls.  My captains put them down on convenient moons to patch holes in the hull.

When they came for my planetary shipyards I said nothing, because I wasn't a shipyard worker. . .  I ruthlessly (and relentlessly) used SM mode to compensate for Aurora's new "bug" of considering shipyards orbital; instantly repairing or replacing any damage caused by space combat.  Only ground bombardment could damage my yards.  Certainly, I never attempted to tow twenty-four square miles of desert to another planet.


A logistics system that means it takes more than five seconds for Precursors to load up with another faceful of missiles?  Awesome, I love it!  The inability of ships to load fuel and cargo at the same time?  *shrug*  I'll deal with it.  To me its no different than the decision that Factories should take 50,000 cargo points instead of 45,000 or 60,000.  It just is.  And if it changes, I'll deal with that too.

But moving all my factories and logistics and whatnot into space?  No thank-you.  That's not the flavour of story I'm telling.  If it IS your flavour I wish you all the best of it.  Enjoy.  It's not something I want in my Aurora.  If there ends up a switch for "Orbital shipyards & factories vs Ground only" I'll be delighted.  For both of us.

In the mean time, if we need to move logistics into space in order to make orbital populations work, well, I'd rather not have orbital populations then.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on October 21, 2016, 11:30:59 PM
I'm all for shuttles and space elevators. Funny timing that Father Tim posted above how his ships always land on planets - my Aurora ships have never landed on planets. Shipyards couldn't be built until a spaceport and a mass driver were in place (the former to send people up and the latter for cargo and I removed the initial SY). Cargo handling system encompassed tiny shuttle craft to make it possible to load/unload on bodies without a spaceport. Shipyards are massive orbital constructs where workers operate like modern day oil rig crew and Earth orbit is jam-packed with shuttles. That's my Aurora.

So getting actual shuttle/orbital lift capacity, including SPACE ELEVATORS, is fantastic in my book.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on October 22, 2016, 10:16:50 AM
I'm the same, I've always considered ships to be orbital only and the cargo handling systems to be shuttle bays etc.

I think the simplification is fine although would still like to see some different ground units and aircraft that can be deployed in addition to just troops.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on October 23, 2016, 08:46:35 AM
When they came for my planetary shipyards I said nothing, because I wasn't a shipyard worker. . .

ROFL!!!

John
Title: Re: C# Aurora Changes Discussion
Post by: Felixg on October 24, 2016, 07:41:23 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on October 24, 2016, 07:37:03 PM
Hey Steve, would it be possible to add more secondary naming theme slots?

Currently we have our main theme and up to 4 secondary ones and we can adjust the percentages. It would be great if that would be extended - for example, when playing as the European Union, just five themes is woefully not enough and I have to swap them around every few years to get a proper representation from all EU countries. This gets even worse for United Earth scenarios.
Title: Re: C# Aurora Changes Discussion
Post by: Inglonias on October 25, 2016, 12:56:20 PM
Quote from: Felixg link=topic=8497.  msg98257#msg98257 date=1477312883
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?)
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 25, 2016, 02:00:49 PM
Hi - sorry I have been absent or a few days. I should be able to catch up with the thread tomorrow
Title: Re: C# Aurora Changes Discussion
Post by: Felixg on October 25, 2016, 11:19:09 PM
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?)

Having hangar space on PDCs as well as an additional facility for tractoring or mass driving ships up to X size similar to how hangars and jump drives work would be a good way to handle it. if it HAS to be changed for some reason.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on October 27, 2016, 01:24:25 AM
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...

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.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on October 27, 2016, 01:31:07 AM
Also, will we be able to transfer admin commands to ships? My idea of a fleet is to have multiple fleet level organizations (in this case, squadrons) under the command of a single admin (or in this case, a fleet)
Title: Re: C# Aurora Changes Discussion
Post by: bean on October 27, 2016, 10:09:50 AM
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...

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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on October 27, 2016, 11:10:57 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on October 27, 2016, 11:54:39 AM
I really think the refueling change is problematic.

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
Recap: At the moment, playing within the maintenance system is simply convenient for colonies that have all minerals, like homeworlds. We won't waste anything by building MSP we don't need. And while the heavily discounted MSP that come (for now) with maintenance storage bays are at odds with other cost, they mean staying within the  system when a need for frontier supply arises is also reasonable.
However, it's in many cases already economical to build ships that you never intend to maintain or overhaul... use up and salvage. When MSP become a real cost factor, playing around the system becomes preferable to playing within it (designate everything as a supply ship, large engineering spaces, recycle MSP)


Aim: Increase the depth of logistics. End: Encourage playing around logistics.
Title: Re: C# Aurora Changes Discussion
Post by: Tree on October 28, 2016, 01:22:10 AM
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.

And even if it worked like that, why don't they just fly next to each other, in the same bubble of warped space?
Title: Re: C# Aurora Changes Discussion
Post by: TCD on October 28, 2016, 08:35:35 AM
I really think the refueling change is problematic.

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
Recap: At the moment, playing within the maintenance system is simply convenient for colonies that have all minerals, like homeworlds. We won't waste anything by building MSP we don't need. And while the heavily discounted MSP that come (for now) with maintenance storage bays are at odds with other cost, they mean staying within the  system when a need for frontier supply arises is also reasonable.
However, it's in many cases already economical to build ships that you never intend to maintain or overhaul... use up and salvage. When MSP become a real cost factor, playing around the system becomes preferable to playing within it (designate everything as a supply ship, large engineering spaces, recycle MSP)


Aim: Increase the depth of logistics. End: Encourage playing around logistics.
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?
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on October 28, 2016, 12:00:31 PM
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.

e:  Unless you mean having tankers in the general viscinity, in which case yeah I do that all the time.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on October 28, 2016, 12:58:05 PM
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.

e:  Unless you mean having tankers in the general viscinity, in which case yeah I do that all the time.
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.

Actually, I'm having second thoughts about my vehemence, as I realise I don't have a strong view on how far a cruiser should realistically be expected to travel without refuelling. Looks like the US navy goes for about 5000-6000 nautical miles, but what would that be in Aurora terms?
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on October 28, 2016, 07:59:44 PM
@ TCD: Yes there are associated costs and restrictions for bulky ships with oversized propulsion plants. Shipyards, maintenance facilities, jump drives, sensor footprint, bigger crew...
it's a personal preference, not clearly better than more compact ships for now.

When we're encouraged to put a decent fuel load on everything though... hmm.
What is a decent fuel load? 40% of engine weight gives the best performance on a given tonnage, I usually wouldn't get close to that.
If x is our proportion of fuel in the propulsion setup and we keep the range constant, speed is proportional to (x(1-x)^2.5)^0.4... we get a nice graph for the trade-off between fuel economy and performance, naturally peaking at 2/7 (as that corresponds to 2 parts fuel out of 7 parts propulsion, i.e. 5 parts engine, i.e. 40% of engine weight).
If we give up 10% of the highest achievable speed, we cut the fuel use in half.

Note that these considerations may include tankers, e.g. if your fleet is accompanied by equally fast tankers using the same engines... it's easy to blunder into using excessive amounts of fuel for no gain.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on October 31, 2016, 11:36:30 AM
All the changes so far seem very good. I do hope that there be some changes to how hangars work, at least provide ships in hangars with a maintenance cost, don't give them a free pass. With the change to how maintenance work this should not be a huge problem to add to the game. I always feel like I cheat when I park larger ships than a FAC in a hangar, especially in PDC hangars since neither the PDC nor the ship pay any sort of maintenance.

In regards to the refueling discussed I find this to be a very interesting and fun mechanic. In general I give ships about the amount of fuel they need to do combat maneuvering inside a system. Smaller ships usually get about 10-15 billion km range, medium sized ships like destroyers get 15-20 billion range and cruisers and up 20+ billion km range.

I also rather put less engines (20-30%) on my ships in favor of more powerful ships or less fuel efficient engines on smaller ships. I rather sacrifice speed for operational versatility in my designs. I usually move task groups with an intricate web of picket and scouts so the core of any task group remain hidden from the enemy, this means that large ships need to move slow in the first place to remain undetected through their heat signatures. Big ships usually get more expensive and more fuel efficient engines, both in engine size and power to fuel efficiency. Thus larger ships are much slower than smaller ships, but since they usually move separately this is not a problem for me.

The new refueling and resupply mechanic is a welcome addition to me and I already build dedicated fleet tender ships to accompany large task forces.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on November 01, 2016, 04:07:19 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Tree on November 01, 2016, 04:30:57 AM
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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on November 01, 2016, 06:19:16 AM
I agree that we should have an eye on things that play around game concepts entirely.

Shove things into a hangar, and avoid maintenance completely.
Give things enough maintenance life until obsolete, never overhaul, maybe never maintain.
Build things with an eye towards fuel efficiency, so we don't need refueling during a mission (fast ships) or ever (slow ships).
If we just want high tactical speed - solve the fuel problem with carriers (possibly commercial in the future) or tugs.

I think it's best if extreme approaches have their niche, but don't dominate conventional designs for general use.
Current problems: Excessive PDC hangars are conceptually problematic for long games, because they eliminate running cost entirely.
Tractoring military pods is very attractive mechanically, but incredibly annoying (allows offloading engines to a commercial design, some other tricks, but chain breaks with every malfunction).

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).
Title: Re: C# Aurora Changes Discussion
Post by: TCD on November 01, 2016, 09:52:14 AM
I agree with most of what you said Iranon, especially the general theme, but to nitpick a few points which highlight what a difficult discussion this is:

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.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on November 01, 2016, 10:41:40 AM
1) I'm all for different designs for different roles. My point was that planned changes that are intended to add depth to fuel management make it attractive to simplify fuel management instead.

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.

3) I wouldn't see the point, because we already have access to cheap and slow engine that may a well use no fuel.
Engines with 0.1 or 0.15 power multiplier can run for centuries on a fuel load that wouldn't raise an eyebrow for faster ships.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on November 01, 2016, 01:23:33 PM
Fighters shouldn't lose training or crew, though.
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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on November 01, 2016, 01:25:29 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 01, 2016, 04:12:44 PM
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.

Yeah it's probably easier to make two hangars. One bigger "Mothballing hangar" that takes enough time for ships to re-activate from that it's not possible to use for Carriers/Fighters, and the normal we got now.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on November 01, 2016, 08:51:01 PM
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.

So, while you dislike the fueling/maintenance system and design ships that need as little of both as possible, I quite like building the logistics network, having maintenance stations and fuel depots everywhere. Just like I know that mechanically a single colony with 10 DSTS is the superior choice, I still prefer building ten colonies with one DSTS each.
Title: Re: C# Aurora Changes Discussion
Post by: Felixg on November 01, 2016, 11:24:44 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on November 02, 2016, 04:29:18 AM
@ 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.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on November 02, 2016, 04:44:00 AM
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.

Yes, more or less this... there are allot of radiation is space but not damaging enough to a starship in the time frame you would mothball them in a game, perhaps a few decades at most. Space function very well as an environment to mothball ships or you could just dig a big hole in an asteroid and place them there.

I would love for sensors to not be linear when that was brought up with the DSTS stations, I always restrict myself heavily on large sensor systems for that reason alone. I don't think they necessarily need to scale realistically, just not completely linear.

As long as there is a maintenance cost with hangars I'm happy. If Steve want to introduce a mothballing mechanic I don't think hangars is needed for that at all. You should just be able to mothball ships and have them re-crewed at a later stage with basic training. Now you need to retrain the ships. This would be enough of a deterrence for doing it too often. The ships should perhaps also automatically be at around 25% of its maintenance cycle when you reactivate them, so you need to perform a maintenance overhaul or risk them breaking apart when used. A simple tickbox for mothballing would suffice.

If you are a min/max player there are many mechanically abusive way to play the game. In single play you can do whatever floats your boat. If playing the mechanics is fun no one is there to stop you as is no one stopping you role playing. Aurora is more about building your own story line and imaginative world anyway.

I think that some player want certain aspect changed not because they are restrictive but because they help give more options. Sure... anyone can role-play that refueling takes time and set aside space for small cargo holds and cargo transferring equipment in their military refueling ships and then have the ship take some time to refuel. The problem is that it is too micro and takes too much effort to do this when the game cold do it automatically for you. The same goes for maintenance on ships in hangars. This is not a problem in short games but rather irritating in long games where resource imbalance become a thing.

The game has continually evolved making the logistical side of it more and more involved and realistic, I think this is just good. There are almost always ways to work around any perceived micro managing tasks it brings with it. Such as ships with millenia worth of crew and maintenance facilities or engines with more or less no fuel costs. But at least they have ship design drawbacks you need to deal with. We should not just have to imagine everything, drawn to its extreme we might as well imagine playing as well... ;)
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on November 02, 2016, 04:56:32 AM
@ 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.

In my opinion the meta gaming of missiles being superior is a not really true. It is perfectly viable to build ships in a more balanced approach and be successful. You should look at what resources you are mining and see how best you can expend those resources to build efficient ship designs. Having weapons that can destroy target without spending much resources are really effective in the long run.

There are some problems mechanically how some weapon systems works though, such as PD only able to fire at one salvo at a time and clustering up missiles in huge swarms making DP practically pointless, even AMM to some extent unless they also are fitted as box launchers and so on... there are certainly ways to break the mechanic by abusing them.

I also wish missile maneuvering capability had a greater impact than speed on how good missiles are at dodging or hitting something, make sense to me. This would make slow missiles more viable than they currently are which also would introduce a higher complexity with PD systems.
Title: Re: C# Aurora Changes Discussion
Post by: baconholic on November 02, 2016, 03:38:34 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on November 02, 2016, 03:44:05 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: schroeam on November 02, 2016, 04:12:30 PM
Mothballing was in the game circa v2 to v3. Steve pulled it out for reasons. It's buried in the Mechanics folder most likely.

My God man!!  Your memory is incredible!  Do you realize how long ago that was? 
Title: Re: C# Aurora Changes Discussion
Post by: TCD on November 02, 2016, 04:37:39 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on November 02, 2016, 04:41:27 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on November 02, 2016, 05:02:22 PM
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...
Title: Re: C# Aurora Changes Discussion
Post by: Tree on November 02, 2016, 05:11:39 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on November 03, 2016, 01:26:07 AM
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.

Its not a localized resource like minerals so having it on the system map makes sense. I'd like to see on the fly how much money I have and am making/losing.
Title: Re: C# Aurora Changes Discussion
Post by: Felixg on November 03, 2016, 04:22:06 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on November 03, 2016, 08:44:55 AM
My God man!!  Your memory is incredible!  Do you realize how long ago that was?

Would have been about 8 years or so ago. ;)
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on November 03, 2016, 08:48:13 AM
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?

Even parked, they still have a full crew and officer corps. You can move the officers off manually, but no way to move the crew. If you have sufficient maintenance facilities, you won't have ships popping.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on November 03, 2016, 10:06:51 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 03, 2016, 10:12:59 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: baconholic on November 03, 2016, 11:35:52 AM
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.

That's just one of the problem. My major concern is that they used up officers. Unless I  assign officers manually, too many ships will result in newer ships not getting any commanders and free commanders sitting unassigned.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on November 03, 2016, 11:40:54 AM
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:

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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on November 03, 2016, 01:15:49 PM
That makes sense. I guess my shorter games, with large ships, generally at similar speeds per tech level is the antithesis of what mothballing would be needed for!
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on November 03, 2016, 05:25:08 PM
I would like to see some new type of "area orders". Like for example placing a salvage ship in a system and giving it the order of salvaging automatically any new wreck that "appears" in that system. Or being able to create an order chain like this:

If Fuel Reserve in Fuel Depot XY < 200.000.000l begin transferring Fuel from Depot YZ but don't empty Depot YZ under the limit of 150.000.000l.

So basically improving automation...  ;D
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on November 03, 2016, 05:59:07 PM
Salvage nearest wreck in Default Orders would be useful indeed.
Title: Re: C# Aurora Changes Discussion
Post by: Kytuzian on November 03, 2016, 07:01:14 PM
"Salvage Nearest Wreck" is already a thing.
Title: Re: C# Aurora Changes Discussion
Post by: baconholic on November 03, 2016, 07:33:46 PM
"Salvage Nearest Wreck" is already a thing.

It generates a bunch of error when the wreck is in another system, but yes, it "works" for now.
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 04, 2016, 09:51:34 AM
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:

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 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. 
Title: Crew management
Post by: Triato on November 04, 2016, 08:34:05 PM
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.
Title: Re: Crew management
Post by: RikerPicard on November 07, 2016, 11:29:34 AM
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 love the idea of "crews" being separate entities from the "crew pool". Here's how I can see it working;

-Fighter/FAC/Commercial crew functionality unchanged

-Military vessels >1k tons have a new field under commander, called crew

-This can either show "unassigned crew" or "<officer name> crew"

-If Captain changes ships, crew moves with them taking grade rating and TF training %, no change if moving to ship of same class, moving to different class incurs TF training but not grade rating penalty based on refit cost(moving to next generation of same type less of an adjustment than say, moving from a carrier to a destroyer), in addition to current changes based on more/less crew(Crews will swap, other crew will retain current name if captained, allowing you to swap captains or assign a new one at a penalty)

-If Captain moves to fighter/FAC/commercial ship/staff/team, or dies/retires/is simply unassigned, crew becomes unassigned, grade and TF training are unchanged but suffers penalty for having no qualified commander in charge

-New Captain reduces grade and TF training % slightly

-Scrapping a ship with more than a certain level of crew grade and training % will generate a "leader" of type "crew"(with stats for size, grade, and TF training), which can be assigned to any ship with 0 of each, modifying the ratings based on new crew size and "destroying" the leader. These leaders can also be "assigned" to join junior officer pool, which has the same effect as scrapping currently does
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on November 07, 2016, 11:58:37 PM
I would like to see spinal railguns or even better more customizable beam weapons that don't rely on tech for size.

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.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 08, 2016, 06:54:52 AM
I would like to see spinal railguns
Steve 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.

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,
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.
I want my UNSC ships.
So do I, but you can make do with current mechanics (I've done it before).
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on November 08, 2016, 05:37:38 PM
You can make do, but I can see where he is coming from.  It would be a fun feature.  Obviously Steve can just not implement it and we will all be totally fine, but I at least agree that it would be nice.
Title: Re: C# Aurora Changes Discussion
Post by: ryuga81 on November 09, 2016, 08:49:54 AM
Quote from: Iranon link=topic=8497. msg98833#msg98833 date=1478191254
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:

I'd really appreciate a "mothball" command for a TG, that puts it on minimal maintenance (say 1% per year?) and requires some time (3-6 months?) to get it flying again (it would be much like shutting down industries).  Technically I believe it would be very similar to "overhaul" command, so it shouldn't be hard to implement. . .
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on November 14, 2016, 01:26:27 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 14, 2016, 07:13:08 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on November 14, 2016, 07:20:13 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 14, 2016, 07:28:09 AM
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?
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 14, 2016, 07:42:49 AM
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.

As lined out I'm not sure that the tanker will  care about fuel % level of targets when deciding what to refuel (depending on if "ship priority" changes with how much fuel they have left ):

"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"

That's the concern here I think ( sloanjh probably just mixed the 2 up ).
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 14, 2016, 09:43:06 AM
Ah. Therefore in order to refuel C and D you would either change refueling priorities mid flight or add a second tanker. Perhaps a third option would be to throw them all in a commercial super-carrier/mothership for the duration of the trip. That actually gives me an idea for a supply carrier that carries a squad of FACs to a colony as well as having a few maintenance modules on-board to supply the defense force while at the colony. That in turn gives me some other ideas for outpost defenses that I want to try out. I'm hyping myself for the update a bit too much.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 14, 2016, 12:11:16 PM
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)
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on November 14, 2016, 04:39:18 PM
No suggestion thread, but configurable color schemes would be nice :)
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 14, 2016, 04:54:04 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: ryuga81 on November 15, 2016, 05:07:52 AM
Quote from: Erik Luken link=topic=8497. msg99115#msg99115 date=1479163158
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 :/
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on November 15, 2016, 07:08:00 AM
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 :/

I hope for this as well :) Blue is kinda hard to read in my opinion.

And think of the roleplay possibilities! Wouldn't you like to set up a pink/neon green theme?!! Ok, maybe not  ;D
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 15, 2016, 08:20:34 AM
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?

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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on November 15, 2016, 08:40:13 AM
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?

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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 15, 2016, 10:33:20 AM
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.

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
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 15, 2016, 10:39:33 AM
Yeah, that's what I want to know, and it's not clear.

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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 15, 2016, 10:42:17 AM
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 ???

It makes no sense...
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 15, 2016, 11:01:20 AM
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 ???

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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on November 15, 2016, 11:10:44 AM
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 ???

It makes no sense...
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.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on November 15, 2016, 12:05:55 PM
The problem is that much (most?) of the time, this is something we shouldn't have to deal with.
If some of our high-performance ships chase down some hostiles and rejoin the main fleet, I'd expect someone to figure out that the empty ships need fuel more urgently than the full ones.
I'd expect an option along the lines of "prioritise whoever in the fleet/subfleet would run dry first at current consumption" with no further micromanagement involved.

Otherwise, it qualifies as deliberate user-unfriendliness... or more accurately, outright hostility.
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 15, 2016, 05:29:24 PM
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.
This is particularly true when you start thinking about tactical implications.  If the tanker only fuels A and B, then there's a serious imbalance in the potential range of my ships if things start happening.  Maybe I have to split my fleet and send A and B off on their own while I refuel C and D.  I'd much prefer that in general, all ships are kept as close as possible to the same endurance.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on November 16, 2016, 12:32:11 AM
It seems like people want an option that tells a tanker to attempt equalized refuelling for the fleet it's in.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 16, 2016, 02:56:30 AM
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.  ::)
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 16, 2016, 07:13:14 AM
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.  ::)

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.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on November 16, 2016, 07:16:09 AM
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?
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.

AAAARGH!!!  Yes, TWO is the preferred and expected option.  Sorry about the goof on my part - I think it can be termed catastrophic!

Alex and 83athom have it exactly correct in terms of what I was trying to point out.  As someone else said I think we need an "equalize fleet" option as well to prevent this.  Oh, and btw, let's say A, B, C, and D are all different classes, so setting a single class to the highest priority won't work based on my reading of the behavior.

As for whether this makes sense (in terms of only having two "booms"), the USN doesn't have 1/2 the ships in a TG empty and the other half full when they're relying on unrep.  They simply rotate the ships that are being refueled.  My point is that the player shouldn't have to micromanage this.

STEVE - Could I request another answer based on the correct wording that #2 is the desired behavior?

Thanks,
John
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on November 16, 2016, 07:19:01 AM
STEVE - Could I request another answer based on the correct wording that #2 is the desired behavior?

Ok - just saw the Ninja post.

So it sounds like if you leave the priorities unset it gives highest priority to lowest percentage, which is perfect.  Should we have a "min %" threshold for the fleet (e.g. 20%) that pops a ship up to the top of the priority list if it falls below when priorities ARE set? (If more than one are below presumably the lowest would go first).

John
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 16, 2016, 07:26:01 AM
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.

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  :)
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 16, 2016, 09:35:30 AM
Great! Thanks for the clarification.

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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on November 16, 2016, 10:09:40 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 16, 2016, 10:56:37 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 16, 2016, 04:55:27 PM
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.

Yeah, but that's doctrine dependent. My doctrine puts all smaller fast ships in hangars ( fighters most of the time ), and the rest of the fleet get a standard speed and engine efficiency shared from smallest to largest ships.

Good point about the freighters though, might make sense to have them at a lower prio if you should for any odd reason ever put them in the same TG as military ships.
Title: Re: C# Aurora Changes Discussion
Post by: JOKER on November 17, 2016, 02:00:09 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on November 17, 2016, 04:23:50 AM
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.

If sensors didn't scale in a linear fashion some of these problems would go away, that would probably be an easier fix. So... let resolution increase sensor strength linear but the sensor strength in itself increase range in the same way resolution between sensors scale non linear. Just my two cents worth of suggestions.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 17, 2016, 07:45:31 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on November 17, 2016, 09:10:49 AM
Regarding missile range: Scalingwith tech is interesting here.
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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 17, 2016, 11:24:05 AM
Regarding missile range: Scalingwith tech is interesting here.
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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Felixg on November 18, 2016, 05:49:31 AM
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!
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 18, 2016, 06:21:35 AM
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.


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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on November 18, 2016, 08:57:04 AM
Energy weapons are capped by fire control range. So just increasing the weapon range on it's own will do almost nothing.


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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 18, 2016, 10:21:37 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on November 18, 2016, 04:04:57 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 18, 2016, 05:38:54 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: ryuga81 on November 27, 2016, 02:16:23 PM
"A Refuelling System is 500 tons and has a cost ranging from 10 BP to 100 BP, depending on the tech level."

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!! :/
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 27, 2016, 03:50:25 PM
"A Refuelling System is 500 tons and has a cost ranging from 10 BP to 100 BP, depending on the tech level."

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).
Title: Re: C# Aurora Changes Discussion
Post by: NihilRex on November 27, 2016, 04:01:19 PM
The new system naming sounds awesome.

I like the idea of having named chains a LOT.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 27, 2016, 05:15:25 PM
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...
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on November 28, 2016, 02:45:15 AM
The whole thing is a bad idea, overcomplicated and likely annoying to use for little added depth... or even reduced depth in practice because it limits ship design. Given how fuel consumption scales, it's going to be preferable to have vessels that don't need underway refueling, or at least don't care about refueling rate. Or go all-out for short-ranged hangar-based craft, commercial hangars adding some new options.

Giving ships the necessary range without outside support was rarely the challenge. For seriously fast ships under tonnage constraints, the major benefit of tanker variants was efficiency through avoiding overhead (fire controls, ECCM, maybe additional armor).
No longer the case. Even if cheap compared to combat systems and even if we get a fighter-sized variant, moving the bulk of the refueling system is going to be expensive making it preferable to build longer-ranged fighters instead.
Title: Re: C# Aurora Changes Discussion
Post by: ryuga81 on November 28, 2016, 06:13:21 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 28, 2016, 07:14:12 AM
^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  ::)

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...
I already fit 500 ton modules in FACs. Here;
Code: [Select]
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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on November 28, 2016, 09:23:13 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Darkminion on November 28, 2016, 09:31:28 AM
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
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.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 28, 2016, 09:34:17 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 28, 2016, 10:36:56 AM
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.
There are lots of things that carriers do besides provide fuel.  Things like accommodations and weapons.  Fighter tankers will actually use more fuel than moving the carrier up (assuming normal engine ratios), and mean longer intervals between strikes.  It's not a complete victory for the tankers.
For that matter, each tanker takes up a spot on the carrier's deck that would otherwise be occupied by a fighter.  The virtual attrition at least somewhat balances the longer range.
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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on November 28, 2016, 03:40:07 PM
Quite a few examples can be found. The best one for this topic is
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.
Ha, 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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on November 28, 2016, 03:54:16 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 28, 2016, 04:27:47 PM
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.


Quote
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.
(Another use is for the early game when you need to move fuel around and it isn't worth it to build a dedicated tanker, although I suspect that will be less important with the new rules.)
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on November 28, 2016, 06:19:56 PM
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.


Alternatively, a compromise could be done if Steve can and want to code it. A 50t small fueling system can be made, BUT it only works if the ships are not moving. Call it "small stationary fuel transfer system" or something similar. If you want a logic reason for that limitation, since it's small it cannot handle the stress/complication of fuel transfer when under way. It will only work if both ships are not moving.

I could work with this compromise. I think however that just allowing 50t fuel transfer systems for every ship without limitations would not be balanced at all.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on November 28, 2016, 06:46:00 PM
It seems like you could just make the smaller ones much slower, that is to say slower than their relative size would suggest.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on November 28, 2016, 08:43:24 PM
It seems like you could just make the smaller ones much slower, that is to say slower than their relative size would suggest.

Forgive me, but this is not in agreeement with what Steve is after, I think.

It seems to me that with the refueling changes, Steve wants to introduct a new layer of complexity in the game. Basically, refueling now becomes a serious logistic concern, instead of just a "magic fuel transfer" between ships as it is now. And so, tankers and the new refueling stations become an important part of projecting power in space.

No longer you can just dump fuel on planets and refuel there, or just transfer fuel between ships. You now need a specific infrastructure in order to do that, and so you need dedicated tankers or forwards bases (the refueling stations). I personally like it, though I can understand why some may not,

But if this system is applied, and it seems to me it will be, then it is not advisable, and should not even be possible in fact, to have  a small and cheap refueling system on every ship. No matter how slow it is at transferring fuel, it would defeat the entire point of this new system of refueling. What does it matter if it is slow, if you can just slap it on every ship? You may as well just do away with it.

And this is why I think 500 tons is a good size for this system. You don't put something like this on every ship, just on ships you want to have it on. And it seems to me this is exactly what Steve wants to achieve with this change.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on November 28, 2016, 09:00:14 PM
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.  If you can get the massive warship refuelled in a few hours, then you can probably get it back into a running engagement within the same system.  If you are spending months gassing it up with a tiny fighter refuelling boom, then the fight is over by the tme you are ready to go.  Heck, it seems to me you could expect the course of the war to change in that time frame.

It would also allow you to do very very slow emergency refuelling in the field if every ship was equipped with at least a very small fuel transfer system.  It seems like that could potentially be dramatic.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 29, 2016, 06:40:05 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on November 29, 2016, 07:24:31 AM
Or the 50 ton system could be fighter only, albeit higher tech level
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on November 29, 2016, 09:21:12 AM
Or the 50 ton system could be fighter only, albeit higher tech level

I'm sorry but this, just no. How would you possibly motivate this? Why would it be fighter only?

"We have this new, shiny fuel transferring system here. And it's small. So, you know what, we're only putting it on fighters. Because large ships suck".

There is no possible realisitic and logical reason that justifies why a miniaturized refueling system would be mounted on fighters only. Why not FACs? Why not larger ships? What makes it impossible to mount it on larger ships?
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 29, 2016, 09:26:28 AM
Or the 50 ton system could be fighter only, albeit higher tech level
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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on November 29, 2016, 09:43:25 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 29, 2016, 10:03:10 AM
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. 
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 29, 2016, 10:30:07 AM
I think people are forgetting that hangars would still refuel fighters a lot faster than a 50 ton "fighter refuel only" system.
Title: Re: C# Aurora Changes Discussion
Post by: ryuga81 on November 29, 2016, 11:26:24 AM
I think people are forgetting that hangars would still refuel fighters a lot faster than a 50 ton "fighter refuel only" system.

I don't think that mounting hangars on fighters in order to refuel other fighters would be a good idea :P

We are not discussing the fact that hangars and carriers are vastly superior in logistics, 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).
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 29, 2016, 11:36:09 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on November 29, 2016, 12:05:08 PM
There are carrier bourne tankers specifically because its still useful to do in-flight refuelling without having to either land the aircraft or in general send a huge warship in advance to support the mission.

You could prevent the fuel systems from working for large warships by preventing them from transferring enough fuel to realistically refuel a large platform in a meaningful time.

As far as a warship really slowly refuelling something, why not?  It seems like that could reasonably be possible.

Title: Re: C# Aurora Changes Discussion
Post by: Iranon on November 29, 2016, 12:54:40 PM
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).
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 29, 2016, 01:12:23 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on November 29, 2016, 05:53:44 PM
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).

I'd argue the ability to use virtually no fuel for larger ships is its own problem.

Forcing people to use massively overbuilt fuel systems to refill super-effecient vessels isn't really going to fix that.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 30, 2016, 01:59:29 AM
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.

Can you mention which sci-fi you have seen them used that way in? Because that is for sure not how light carriers or escort carriers were ever used irl...

IRL the fast and big fleet CVs always were the most forward operating aggressive ones with the mission to strike behind enemy lines and hit their fleet ( for example Pearl Harbour ).

Light or Escort carriers main roles was shipping aircraft from home to the front, securing sealanes versus submarines, and acting as "backup" carriers to protect fleets and assets when there were no real carriers available (most of the time  because the big CVs were away hitting the enemy further forward ).
Title: Re: C# Aurora Changes Discussion
Post by: Black on November 30, 2016, 02:39:19 AM
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 think that specialised module to refuel fighters should be available, we can do it in real life, so I don't see a reason why it should not be available in Aurora.

Maybe if it would be possible to change fighter loadouts, for example to add additional fuel tanks for long range mission, then it would not be necessary to have fighter tankers.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 30, 2016, 03:16:43 AM
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.

That's not the usage we are looking for here. That just sounds like a variant on normal Carrier Ops ( the entire point of normal Carrier Ops is to reach an enemy that can't be reached from stationary "land" bases ).

What I mean is launching Fighters from Large Strike CVs, then refueling them on forward light/escort CVs specifically to extend the range.
Title: Re: C# Aurora Changes Discussion
Post by: Felixg on November 30, 2016, 06:00:44 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 30, 2016, 06:34:45 AM
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

Just for fun I did the math.

Assumptions: A normal refueling hose for gasoline cars have a capacity of around 1 liter per second. We want to refuel a USS Iowa class battleship from 10% to full using a single one.

Fuel Capacity of USS Iowa: 8,501,867 liters ( Source: http://www.ibiblio.org/hyperwar/USN/ref/Fuel/Fuel-BB.html (http://www.ibiblio.org/hyperwar/USN/ref/Fuel/Fuel-BB.html) )

To get it from 10% to 100% would require 7,651,680 seconds = 127,528 minutes = 2,125 hours = ~88.6 days


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! ).
Title: Re: C# Aurora Changes Discussion
Post by: ryuga81 on November 30, 2016, 09:35:17 AM
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.

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 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).
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 30, 2016, 09:48:58 AM
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
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.
However, all of that is because you deliberately selected three incompatible systems.  Since we're starting from scratch, we can design the system for compatibility, and I see no particular reason why we wouldn't.  I could sort of accept a system which only works on fighters, but I don't like it.  At very least, it should be able to use an extender hose to refuel bigger ships when stationary.

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.

Quote
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.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 30, 2016, 09:53:57 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 30, 2016, 10:02:44 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on November 30, 2016, 10:20:19 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on November 30, 2016, 10:29:00 AM
Ok, let us try to separate the two discussions here.

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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 30, 2016, 12:37:19 PM
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.

Quote
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.

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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: boggo2300 on November 30, 2016, 02:29:35 PM
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 carriers
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 30, 2016, 09:24:02 PM
The US Navy isn't the only navy with Carriers, and if memory serves, only the US, French and Chinese have Nuclear carriers
Only the US and French, actually  Liaoning is a dino-burner, and I expect the first batch of successors to be, too.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on November 30, 2016, 09:42:02 PM
Ok, let us try to separate the two discussions here.

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.
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.
However when a fleet is at rest, in orbit or at a base should there be limited ability to transfer fuel even when theres no dedicated fuel facilities in the taskgroup or location?
Title: Re: C# Aurora Changes Discussion
Post by: ryuga81 on December 01, 2016, 04:19:29 AM
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.

https://en.wikipedia.org/wiki/Brazilian_aircraft_carrier_S%C3%A3o_Paulo_%28A12%29
https://en.wikipedia.org/wiki/Italian_aircraft_carrier_Giuseppe_Garibaldi
https://en.wikipedia.org/wiki/Spanish_ship_Juan_Carlos_I
https://en.wikipedia.org/wiki/INS_Vikramaditya

None of these carriers in active service run off nuclear reactors (that is also the same assumption in Aurora, ships run on fuel, so they are the best comparison here).

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.

Yep, I was suggesting that some basic fuel transfer abilities should always be available, at least with stationary ships, for emergencies (topping up a carrier that way might take weeks, but pumping in just a little fuel to make it to safety, whether it is a jump point or a planet fortress a few bilion km away, should not be a problem)
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on December 02, 2016, 08:24:23 AM
I think the game will just become more interesting with a more restrictive system of transferring fuel, missiles and supplies to and from ships.

It simply give a new layer to the logistical problem we face during a game. I already try to mimic these problem in my game and don't allow ships to freely exchange either fuel, supplies or missiles without special equipment such as cargo handling systems and tractor beams. Makes things more interesting and feels a bit more realistic.

So basically at least one ship involved in a transfer need to have both a tractor beam and two cargo handling systems.

This also means I can't build super small tankers for my fighters and need slightly larger fuel boats to handle them... although I allow fighters to be refueled from a ship with no tractor beam and one cargo handling system.

personally I enjoy restrictions, that is what makes choices matter so much more and you always need to make compromises.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on December 02, 2016, 10:29:57 AM
A simple way would be to give ships/colonies a very low base refueling rate if they lack relevant components, then apply decent multiplier to refueling rate when stationary (automatic for colonies for obvious reasons...).
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on December 02, 2016, 11:49:44 AM
Lively debate :)

As some posters have stated, the intent of these changes is to add some additional decision-making to power projection. You will need to plan ahead in terms of the logistics involved in keeping fleets supplied and refuelled when operating away from major bases. This is very similar to the 19th century Royal Navy establishing coaling stations around the world. The Royal Navy didn't dump coal on the nearest available rock. Instead, it created the necessary infrastructure at strategic locations.

https://en.wikipedia.org/wiki/Fuelling_station

As the 20th Century progressed, underway replenishment was developed, particularly by the US Navy, and this become more effective over time. This development is now reflected in Aurora

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. 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.

Title: Re: C# Aurora Changes Discussion
Post by: bean on December 02, 2016, 05:04:18 PM
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. 
How would a 250t system work?  It's a bit big for a fighter, but you could get a useful one on an FAC, which has a much better utility/price ratio than something 1.5-2x the size.  Make it 1/3rd the pump rate to avoid abuse.  I've generally found 2000t to be one of those unpleasant gaps where you try to avoid building ships.
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on December 02, 2016, 09:42:51 PM
Quote
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>?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on December 03, 2016, 06:34:54 AM
Does this mean I can set a rule that all systems with no planets be named NX-<system number>?

Not as things stand, but it wouldn't be hard to add a player option to name certain types of systems in certain ways.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on December 03, 2016, 06:45:59 AM
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 think that comparison is that valid since the speed difference is much bigger in Aurora. In reality your having Carriers going @30-35 knots and speedboats @40-50 knots (not even twice), while in Aurora our Carriers @5000km/s can have fighters @30000km/s (6 times the speed).

If you take into account the speed of missiles where fast Aurora fighters can outrun slow missiles this becomes even more apparent. So even though operating in the same medium the engine and fuel consumption mechanics means that max power mod fighters in Aurora actually behave alot closer to real airborn F-18 fighters in comparison to their mothership and missile speeds ( Being closer to the missiles in speed then then to the Carrier ).

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.

Why not solve it with a "fighter only" dropdown or version on the refueling system which make it 10 times smaller and 10 times slower + only possible to go on fighters? (maybe FAC too).
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on December 03, 2016, 08:28:11 AM
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 (goals: pick off things from outside their beam range, strong railgun PD, be almost untouchable with ECM) and fighters that go 5000km/s (rationale: don't need performance if I can slip in under their long-range sensors).

In general, I don't think the changes to refueling will add much if any depth.
Speed is very expensive in Aurora, in other words range/fuel efficiency is dirt cheap.

The fuel use/speed relationship may not look too different from real life... but IRL it is a trade-off during operation with a few restrictions (some constant burning rate to keep things other than main propulsion online). In Aurora, high-powered ships always burn fuel like crazy, there is no economical cruising unless you tractor them or put them in a hangar.

Ships heavily optimized for fuel efficiency are quite attractive in general even if that's not our primary goal. I already find it best to invest practically nothing in fuel logistics and build frugal ships (excepting those I'm ferrying around by tractor/hangar).
Pressure to go this route will only increase with the limit to tankers; end result being more complexity that is best played around and adds little depth but some annoyances/restrictions (without unlimited emergency refuels, I'll want some fuel redundancy/reserves).
The only thing that would really lead to legitimate depth in logistics would be a complete rebalance of power to fuel efficiency to make fuel efficiency more expensive in terms of other design goals... but I don't see a simple fix without unfortunate side effects there.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on December 03, 2016, 11:20:33 AM
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

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...
Title: Re: C# Aurora Changes Discussion
Post by: ryuga81 on December 03, 2016, 11:38:06 AM

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?
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on December 03, 2016, 12:29:21 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on December 05, 2016, 03:54:23 AM
 Maybe we should take this elsewhere, but...

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...

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.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on December 05, 2016, 07:35:56 AM
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.

However, the sqaure-cube law may not be so tidy in sci-fi when you consider hyper-dense materials (like Collapsium or similar "fluff" heavy material) that may weigh 500 times as much per volume than titanium. An end level tech frigate which weighs 5x as much as its early game comparison may be a very similar size, or even smaller.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on December 05, 2016, 02:13:20 PM
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.

Not really. Consider that Aurora missiles don't go as fast as a F-18 vs ships either if you try to translate and jam the scale in 1:1.

If you define missiles as the fastest things, commercial ships as the slowest and plot where Carriers and their Fighters end up on that scale in reality vs Aurora your going to find that they end up pretty much in the same relative spots, even if their individual ratio between each-other may be more compressed in Aurora (due to the smaller total span and the need to fit in more tech level advancements).

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

And the real missiles the F-18 fires goes 2000-3000 mph top speed. Which using your the same comparison to ingame numbers would make them around the speed of light, so clearly it doesn't apply.


My point was a more general one that fighters are closer to the missile speed-range, then the ship speed-range in Aurora. Just like real fighters are closer to the missile speed ranges then the ship or speedboat speed range.

Therefor they are more logical to compare with airborne fighters then with speedboats.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3(forgot pass) on December 05, 2016, 07:08:37 PM
In my opinion, applying more fueling restrictions to players shouldn't really be done without consideration to inhibiting AI fuel or "emulated fuel" operations for the sake of fairness.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on December 07, 2016, 07:18:01 AM
I imagine that jumpships equipped with a single refueling system will probably be able to handle most 'oops' emergencies, except in the extreme early game like going too far exploring the kuiper belt. 

For any situation where you'd like to RP 'emegency refueling', I think SpaceMaster can cover it.

Although, it comes to mind that if turn processing/pathfinding is fast enough, ships might be able to calculate for themselves if their fuel levels might soon be insufficient to return to the nearest refueling base.  Only survey ships really need this functionality, anyway.

 
Title: Re: C# Aurora Changes Discussion
Post by: Happerry on December 08, 2016, 01:30:39 AM
Personal opinion with my admittedly meager experience at Aurora is that the fueling system as discussed doesn't sound fun or interesting, but does sound like an annoying chore.
Title: Re: C# Aurora Changes Discussion
Post by: Michael Sandy on December 08, 2016, 06:09:47 AM
Given that ships are expected to operate for months on their own, in other star systems with no way to communicate with home except by sending a ship, I would expect that any ship designed for extended patrols would be capable of dealing with a variety of emergencies.

Like temporarily dealing with extra crowding from rescuing the crew of a disabled ship, or temporarily providing power to another ship so they could shut down and repair their reactor, or refuel another ship, with enough fuel to get them to the nearest starbase or other facility.

Also, people are getting all fussy about interchangeable fuel between carriers and fighters and LACs when they swallow the notion that a captured 5 hs missile can be fired from a 5 hs launcher, regardless of whether said launcher is cylindrical, square, hexagonal or whatever.  There are far more incompatible things that are used interchangeably, mostly because of the rule of FUN.

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.  So it isn't NECESSARY to have the smaller system, but it allows a play style.  A fighter tanker would be 1/4 as efficient as the larger system, but it could keep up with the fighter wing without increasing the signature of the fighter wing.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on December 08, 2016, 08:14:31 AM
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  ;).
Title: Re: C# Aurora Changes Discussion
Post by: Michael Sandy on December 08, 2016, 04:52:16 PM
Doh.  I was thinking in one unit and writing in a different one.  No programming martian lander craft for me!
Title: Re: C# Aurora Changes Discussion
Post by: Retropunch on December 08, 2016, 05:26:44 PM
Quote from: Steve Walmsley link=topic=8497. msg99475#msg99475 date=1480768494
Not as things stand, but it wouldn't be hard to add a player option to name certain types of systems in certain ways.

I'd love this feature - even if it was just systems with no planets or a rather arbitrary set of circumstances.  Keeping track of everything in Aurora is one of the things that slows down fun play, and so anything to allow the player to get on with things would be greatly appreciated.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on December 13, 2016, 01:50:12 AM
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?).
Title: Re: C# Aurora Changes Discussion
Post by: hiphop38 on December 14, 2016, 04:52:19 PM
So call me a big fat Space ####, but I often like to rp my Aurora games with Slavery not only allowed, but state sponsored. Currently they only really work as big and difficult to transport construction brigades, and thus can only build installations/PDC.

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 do like the idea of the forced labor units in creating a rich dark rp environment, I just wished for a bit more options with them.
That being said, they do still work rather nicely as the transportable construction factory, sans the infrastructure/building/population, that they currently are. If I am the only bastard evil enough to even use the FLU then so be it and I'll be content with Slavery as it currently stands.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on December 14, 2016, 04:56:14 PM
An interesting thought, and one that would fit well with the 40k-ish theme of this update. The suggestion thread would have probably been a better place to post as there wasn't a change to the game dealing with them.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on December 15, 2016, 06:25:45 AM
Some kind of conscript ground nit might be handy too, but the rules governing how to create them, their effect on morale and unrest etc, should be somewhat complex.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on December 15, 2016, 06:54:19 AM
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 don't think this makes alot of sense.

Unless you envision putting the slaves in expensive suits and educating them at the top universities so you can have them work at your financial centers and research labs as well...

So I think to work well your suggestion requires alot of other core game changes, like education levels or social classes of population to separate the lowest uneducated mining crews from the top elite.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on December 15, 2016, 08:01:58 AM
I think they could be restricted to only working in factories, mines, and terraforming installations. Possibly they could also contribute into the agricultural sector, freeing up your own population for services, intellectual jobs, and industry. He did report this in suggestions, so it may have been better to comment on that instance.
Title: Re: C# Aurora Changes Discussion
Post by: NuclearStudent on December 18, 2016, 01:18:20 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on December 18, 2016, 04:36:49 PM
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;
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.
Title: Re: C# Aurora Changes Discussion
Post by: IanD on December 19, 2016, 05:06:17 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on December 19, 2016, 06:27:35 AM
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% ).
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on December 19, 2016, 07:21:33 AM
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)?
Title: Re: C# Aurora Changes Discussion
Post by: ryuga81 on December 19, 2016, 09:58:46 AM
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% ).

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 :/
Title: Re: C# Aurora Changes Discussion
Post by: ryuga81 on December 19, 2016, 10:08:13 AM
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)?

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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on December 19, 2016, 10:34:19 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on December 20, 2016, 10:09:22 AM
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.

It's unlikely, in such a technologically advanced society, that slave rebellions would be a problem. They're unarmed and utterly controlled, the lowest of the low. Even slave revolts in ancient times were generally put down without major issue, let alone for a society that can nuke them from orbit. Also, if slaves aren't productive then what are they for? Assume that the free population are the skilled workers and the slaves are the manual labourers (which creates the administrative jobs). Although a well educated alien population wouldn't suddenly become stupid and incapable of skilled work just because they were conquered for example.

I suppose there could be issues with modelling productivity (since slaves aren't nearly as motivated as a free population).
Title: Re: C# Aurora Changes Discussion
Post by: ryuga81 on December 22, 2016, 06:05:42 AM
You can disarm and utterly control them only if you repress them and make them work at gunpoint, otherwise they would be capable of rebellion, sabotage, assassinations & such.

A well educated alien population wouldn't be as eager to do intellectual/skilled work for an invader, and you wouldn't certainly trust them with strategic job positions (you wouldn't want them anywhere near your ships or weaponry, and you wouldn't let them manage your research or your wealth), so even if they are educated, you are forced to view them as slave labor for mines, factories and other dangerous places. They are "productive" only in that sense.
Title: Re: C# Aurora Changes Discussion
Post by: Triato on December 22, 2016, 11:50:09 AM
I don´t know if we can cout them as slaves, but during and after WWII many scientists worked as prisoners.
Title: Re: C# Aurora Changes Discussion
Post by: NuclearStudent on December 22, 2016, 05:32:10 PM
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 use fighter-tankers a lot. They may not be intentional, but as a somewhat careless person, the current system saves a lot of micromanagement and grief.

If this system is implemented, I would vastly prefer it to be optional, like being able to opt out of maintenance.
Title: Re: C# Aurora Changes Discussion
Post by: Hydrofoil on January 05, 2017, 06:16:30 AM
I know this is probably asked alot but any indication of when a release to your faithful fans might be made?
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on January 05, 2017, 07:20:55 AM
I hope that automated mines will be replaced or supplemented by buildable mining complexes like the civilians can make with more output and native mass drivers. I wouldn't mind them being heavier and more expensive if it meant less trips for my freighters and more efficient mineral transfer.   
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 05, 2017, 01:11:31 PM
I know this is probably asked alot but any indication of when a release to your faithful fans might be made?

Not for several months. I had hoped to get a lot of work done over Xmas but I wasn't well. I did manage to complete system generation though and I am now working on the system view window as I get the time.
Title: Re: C# Aurora Changes Discussion
Post by: ORCACommander on January 07, 2017, 05:05:20 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 07, 2017, 06:24:35 PM
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?

There is no underground infrastructure in C# Aurora. It has been replaced by low gravity infrastructure. I will be adding some tech though to expand capacity on smaller bodies.

The capacity is the same, whether infrastructure is needed or not. Capacity is not the same as life support. So if a planet can hold a billion people, that capacity can be reached by terraforming or by constructing enough infrastructure to support it.
Title: Re: C# Aurora Changes Discussion
Post by: Jon W on January 08, 2017, 08:49:14 AM
Hi Steve,

Looks awesome! Regarding todays changes to population - you say that excessive water will put a cap on surface area for population, but is the reverse true? Will a planet with no hydrosphere whatsoever have a penalty to max pop? It always seemed like even if you did add a breathable atmosphere to a rocky moon or planet, the surface of that world is still going to be a dry desert.  Maybe I've been reading the Expanse too much, but it would be cool to see water demand or water/gas mining and shipping be abstracted in some way.

Also - are there any plans to change the starting population of Earth to reflect the 7 billion current, or whatever the projected population will be in 2025? I know the current balancing is done for the starting value of 500m but I can never really parse this into a real-world explanation without some massive genocide!

Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 08, 2017, 12:06:09 PM
In regards to terraforming changes; I like it, but creating hydrospheres should probably take much longer than atmospheres. Earth's hydrosphere is 250 times or so as massive as the atmosphere after all. Biospheres would also be nice. Both hydrospheres and biospheres should affect habitability. Hydrospheres because without freely available water there's going to be a need for massive infrastructure projects to keep it available, and without biospheres maintaining a livable atmosphere might be difficult. Biospheres should also range from 'safe' to 'extremely dangerous' to indicate how hostile the biosphere as a whole is to the settlers. It should be possible to manipulate biospheres through GMCs.

In regards to refueling changes; should there not be a maximum number of ships that can be refueled at once at a given level of Spaceport/Refueling Station level? Sure, ships you can build in fighter factories probably should be exempt as they can just land, but larger ships are going to need orbital infrastructure. And are there limits on refueling speeds for hangars? I didn't see any.

Population over capacity should not only cause unrest due to overcrowding but also induce a negative population growth. And given the influence excessively large hydrospheres have on population capacity, is it possible to remove hydrospheres without water vapour in the air, or is a planet with a hydrosphere presumed to always have a lot of water vapour.
Title: Re: C# Aurora Changes Discussion
Post by: Aldaris on January 08, 2017, 02:46:01 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Bughunter on January 08, 2017, 02:50:04 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on January 08, 2017, 04:25:51 PM
I'm not sure the amount of land should affect the maximum population.  Certainly if the player has the technology to build anti-matter engines, they should be able to build as many floating cities as they want.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 08, 2017, 05:10:31 PM
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?

Yes, you will be able to add water. See the Terraforming thread in Suggestions.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 08, 2017, 05:12:23 PM
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?

Once colonies reach max pop, they will stop growing. Growth rates start slowing at one third capacity. They will only become overcrowded if you transport colonists.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on January 08, 2017, 09:26:41 PM
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.

Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on January 08, 2017, 11:32:56 PM
I was just about to watch that video. heh.
Title: Re: C# Aurora Changes Discussion
Post by: Conscript Gary on January 09, 2017, 04:32:48 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on January 09, 2017, 06:11:45 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Alucard on January 09, 2017, 11:15:07 AM
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 powerfull in combat considering the costs to research and build them.   

EDIT: Sorry, I am not sure how I missed there being EM sensors option on missiles.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 09, 2017, 11:34:02 AM
Part of the problem with squeezing more people onto the same planet has to do with planetary carrying capacity. That is, how many people the planet can support with food.


Also, regarding radar seeking missiles, missiles with EM-sensors already perform this purpose.
Title: Re: C# Aurora Changes Discussion
Post by: El Pip on January 09, 2017, 12:02:45 PM
Also, regarding radar seeking missiles, missiles with EM-sensors already perform this purpose.
Not really. Or at least only under certain circumstances.

If your targets sits nice and still, then yes you can fire missiles with an EM warhead at a waypoint next to them and, when they arrive at the waypoint, they will home on the active emission.

But if the targets are moving at any speed you have to extrapolate their course, work out where your missile will intercept them in the future, and then hope you can place a waypoint at that location accurately enough for it to all work out, assuming all those sums are correct and the target doesn't change speed or course. Realistically it's not going to happen.

A proper radar seeking missile would be fired at a target you can only detect on EM sensors (i.e. you haven't got an active sensor in range) and home on that for as long as the enemy leaves their actives on.


Edit - I just did a quick test game to double check and the above is wrong. For a missile with a Thermal sensor you can fire it at a waypoint then, when it gets there, remove the waypoint, and the missile will find a new target and kill it.

Do the same with a missile with an EM sensor will just sit their confused, looking for a new target, but not finding one.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on January 09, 2017, 12:07:32 PM
I think that would require that the missile have a full shipboard EM sensor array in order to see the target.

e:  On the other hand, I guess fire control could guide the missiles until they are in acquisition range?
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on January 09, 2017, 01:13:05 PM
EM sensors on missiles should work as radar seeking as NPRs have shot down my scout frigates that had actives running with missiles when there were no enemy active sensors in the entire system.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 09, 2017, 02:06:00 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 09, 2017, 02:43:56 PM
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.

Orbital habitats already increase the max population. The capacity limit only applies to the non-orbital population.

Also, I think I will add a modifier to max capacity on a species level so that certain species can accept higher densities (hive minds, etc.).
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 09, 2017, 03:54:54 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: schroeam on January 09, 2017, 04:11:19 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 09, 2017, 04:33:11 PM
Aestusium (based on Latin for heat)
Frigusium (based on Latin for cool)

Adam.

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 :)
Title: Re: C# Aurora Changes Discussion
Post by: theredone7 on January 09, 2017, 05:20:36 PM
Quote from: 83athom link=topic=8497. msg100110#msg100110 date=1483932401
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 09, 2017, 05:30:33 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on January 09, 2017, 07:11:53 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on January 10, 2017, 12:34:18 AM
For worlds which need infrastructure the pop cap is how many people you can fit using infrastructure. Any more than that would need orbital habital.
Greenhouse gasses, Cryolene, and Thermophine ?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 10, 2017, 04:00:44 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on January 10, 2017, 04:26:06 AM
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.

Ah ok, I understand :) I was perplexed for a moment there  ;D
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 10, 2017, 05:28:45 PM
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.

Maybe just "Reflective Aerosols" for anti-GHG? Albedo raising gas?

Dunno about GHG. "Insulative Gas" isn't really much different than safe greenhouse gas.
Title: Re: C# Aurora Changes Discussion
Post by: Desdinova on January 10, 2017, 08:38:25 PM
Quote from: Steve Walmsley link=topic=8497.  msg100135#msg100135 date=1484001191
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 :)

The '-us' part is the nominative declension of the latin word, it sounds a bit more authentic to me to drop it and just use the root, ex.   Aestium, Frigium. 

If you wanted to use Greek roots you could use Thermon gas/cryon gas.
Title: Re: C# Aurora Changes Discussion
Post by: Haji on January 11, 2017, 02:19:16 AM
Aestusium (based on Latin for heat)
Frigusium (based on Latin for cool)

Adam.
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 :)

I like the idea as well, but there is a small problem - there are currently neither tooltips nor other descriptions for the gases in game, so the new players may not realize what those are for. Safe Greenhouse Gas may be a very boring name, but at least when I started to play Aurora I knew immediately what it was for.

Title: Re: C# Aurora Changes Discussion
Post by: littleWolf on January 11, 2017, 11:54:43 AM
Siberium and Sakharium :)

Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on January 12, 2017, 02:55:38 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on January 12, 2017, 03:28:10 AM
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.

Erm. It's written in the very changes list post.

Quote from: Steve Walmsley
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.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on January 12, 2017, 09:18:30 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on January 12, 2017, 09:22:26 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on January 18, 2017, 05:27:37 AM
Erm. It's written in the very changes list post.
Alright thanks, must have missed that.
Title: Re: C# Aurora Changes Discussion
Post by: Jeltz on February 13, 2017, 09:49:23 AM
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...
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 13, 2017, 10:33:55 AM
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...

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.

Title: Re: C# Aurora Changes Discussion
Post by: 83athom on February 13, 2017, 11:17:49 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Felixg on February 14, 2017, 09:52:23 AM
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.

Be really evil, have it populate the lists as if it is one of their task groups filled with their ships.
Title: Re: C# Aurora Changes Discussion
Post by: Britich on February 15, 2017, 04:37:58 AM
The Piracy angle would be nice, a civilian freighter goes off the reservation and starts stealing goods instead of trading them and taking them to a secret colony that you can land troops on and kill everyone/capture pows.
Title: Re: C# Aurora Changes Discussion
Post by: Desdinova on February 15, 2017, 12:31:47 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Detros on February 15, 2017, 01:30:27 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on February 15, 2017, 10:33:30 PM
you can also manually add nprs, either automatically generated or by placing one on an appropriate world.
Title: Re: C# Aurora Changes Discussion
Post by: Desdinova on February 16, 2017, 02:55:17 PM
I meant to say for the early game.   With real stars on it can be 50+ star systems explored before I find a life-bearing world, and decades before my navy can take on spoilers. 
Title: Re: C# Aurora Changes Discussion
Post by: tapk on February 28, 2017, 08:42:08 PM
Is there any chance to see Aurora in different languages? I think there are a lot of Aurora fans that can translate the text to their language (I personally can translate into russian).   So will Aurora C# support localization?
Title: Re: C# Aurora Changes Discussion
Post by: IanD on March 01, 2017, 02:30:18 AM
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.

Steve, will you be able to activate the Search sensors separately from the fire control? Because if I only have search sensors on that is not threatening, however if I activate my fire control it indicates to an NPR that I am pissed off and bad things are going to happen!
Title: Re: C# Aurora Changes Discussion
Post by: Bughunter on March 01, 2017, 02:32:23 AM
A way to tell another vessel to GTFO of my system would be useful, locking a firing control on it could work I guess..
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 02, 2017, 12:33:35 PM
I'll setup sensors and fire controls so they can be activated independently. I agree that locking fire control should be a hostile(ish) act, although that means I would have to add events for ships being targeted by fire control as well. Perhaps NPRs could also use that as a "Please leave" message, without actually opening fire.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 02, 2017, 12:34:56 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 02, 2017, 12:50:39 PM
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 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.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on March 02, 2017, 03:17:42 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: albertismo on March 03, 2017, 04:57:31 AM
just out of curiosity, in c# you could use graphic libraries as opengl or other 2d? I do not mean to add 3d to Aurora, but maybe one day you can decide to add to map more 2d effect
Title: Re: C# Aurora Changes Discussion
Post by: Zerox on March 03, 2017, 09:34:29 AM
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!
Title: Re: C# Aurora Changes Discussion
Post by: Beersatron on March 03, 2017, 10:12:33 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 03, 2017, 01:39:16 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 04, 2017, 04:24:56 AM
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!

I do intend to overhaul electronic warfare at some point and I may do that for the first C# release.

Taking time at the moment as I have been moving house :). Haven't really done any work during the last month but now I am starting with the Commanders window.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 04, 2017, 04:29:58 AM
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?

That sounds like a good idea. An automated but dormant shipyard that will start to build ships if intruders are detected (and if it has the resources). And the salvagers sound like a good idea too. In fact, the players should probably be able to capture the shipyard somehow - maybe I make it an expensive shipboard module so they can capture the whole complex. If we take that a little further, that could lead to deep space shipyards (as the automated SY module would use resources in the cargo holds of the mounting ship).
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 04, 2017, 04:30:54 AM
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.

I didn't read this before I replied to the previous message :)
Title: Re: C# Aurora Changes Discussion
Post by: mrwigggles on March 04, 2017, 05:35:31 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on March 04, 2017, 06:04:29 AM
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.

I hate civilians. I would hate to be forced to bombard my own colonies until they are a slag wasteland...

Seriously, in their current iteration they are mostly a complete bother. The only thing I can tolerate somewhat are the shipping lines. And even then, they are stupid beyond belief and go get themselves blown up in places where they should not be. CMC  are instead a blight upon aurora cause I can't reliable prevent them.

Also, a TN sink would be very bad, considering that TN elements are not unlimited.

In case it was not clear, personally I would not welcome these changes  :) Sorry.

Besides they would NOT go along well with my roleplaying nations where civilians in space do not exist. All shall perish under the heel of my empire. The idea that a private citizen can go and make something of his own initiative is unthinkable. Such deviants are burned at the stake.
Title: Re: C# Aurora Changes Discussion
Post by: Coleslaw on March 04, 2017, 08:08:33 AM
I was curious as to whether a different form of manpower would come into play in the new Aurora.  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? As armies get damaged and if they don't have Reserve battalions on the same body, you can transport them back to a planet with population, a ground training facility, and a few resources (If the unit lost half of its Readiness, it would cost half the unit's resource cost to regain it, for example. )
Title: Re: C# Aurora Changes Discussion
Post by: lennson on March 04, 2017, 10:40:07 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on March 04, 2017, 01:26:00 PM
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.

That would be nice. I would have zero problems with civilians if they could be turned off, either entirely or selectively. It is being forced to play with them no matter what that is rather bad in my opinion.

I realise my previous post may have been worded too strongly. I just really dislike them as they are now, since there is no choice.

It would be even better if they could be turned off IN THE GAME, as a conscious choice while playing. Like you can "choose policies" in some other 4x games. That way one could roleplay a government that allows or disallows civilians. And, roleplay a possible change in governemnt and/or policies during the game as events unfolds.

For example, a governemnt that allows civilians enterprises at the beginning. Until a NPR race is discovered, which could lead to the nationalization of all space endeavours.
Title: Re: C# Aurora Changes Discussion
Post by: Haji on March 05, 2017, 06:09:48 AM
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. You can still build ships if you don't have crews but you'll suffer grade bonus penalties. 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).

Please note that all this description comes from my observation of the mechanics, not any 'hard' knowledge so this may all be wrong.
Title: Re: C# Aurora Changes Discussion
Post by: Coleslaw on March 05, 2017, 08:28:46 AM
Quote from: Haji link=topic=8497. msg101550#msg101550 date=1488715788
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.

I should rephrase then: As it stands, troops are trained out of just resources and time and ship crew just start appearing once you have an academy. 

Also, what if you could immediately deploy a ground force that's still in training, albeit at a large experience decrease depending on how far along the unit was in training.  There'd be a minimum time required in training for basic familiarization and equipment production, but after that minimum, they can be deployed. 
Title: Re: C# Aurora Changes Discussion
Post by: jonw on March 05, 2017, 10:53:15 AM
I really like the idea of deep-space shipyards, as I feel this kind of matches with the deep-space maintainence facilities we have.  This might not necessarily have to be a separate module - my understanding is that currently shipyards vanish if untractored in deep space, would there be some way of changing this? Modules which provide shipbuilding or fighter capabuilding if minerals are present in cargo holds? That'a a really cool idea.

I do feel that the ship modules tend to have significant advantages over ground installations.  The automated ship modules for terraforming, AM, harvesting etc feel to me like they should be hugely more expensive.  If you're abstracting a ground facility which takes 50 000 people to run into an automated version which can operate with some minimal crew, there should be some huge downside for the automation.  Could this be addressed by a seprate tech line, like automation efficiency, which scales ship module BP cost relative to the ground installation build cost?

It would be awesome if we could eventually do entirely nomadic empires like Homeworld or the BSG survivors.
Title: Re: C# Aurora Changes Discussion
Post by: Felixg on March 05, 2017, 12:50:34 PM
The huge downside is that they are much more vulnerable, a single ship with an energy weapon could cruise through and obliterate them.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on March 07, 2017, 08:09:05 AM
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.

I always though the other spoiler race was alot more fitting for a "pirate" like role.

I mean for these your already half way there with how they reclaim the wrecks of destroyed ships to grow their own numbers, right?

All that's missing is some raiding behavior so they send out ships to nearby systems and prey on commercial ships trying to destroy them and salvage the resources before you can arrive in strength. If ability to tow wrecks was introduced they could even tow home the wrecks.

Being sneaky like that and hit your weaker slower ships while avoiding military ships where possible, or luring them into traps also would fit better with their theme and weaponry I think.



The role of Precursors I always considered to be one more as gatekeepers/guardians of bodies or systems with desirable minerals, anomalies, ruins or colony sites.

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?


The huge downside is that they are much more vulnerable, a single ship with an energy weapon could cruise through and obliterate them.

Unlike an undefended fresh fringe colony with some terraforming installations that will fall to a single enemy ground battalion, and even be captured intact by them or what?

The ships are less vulnerable in fact since they have the theoretical ability to try to run away given some warning, while the colony most certainly can't.

If you want to keep either installations or ships safe you need to protect them, that's not something that is inherently a weakness of either of them IMO.
Title: Re: C# Aurora Changes Discussion
Post by: ExChairman on March 07, 2017, 08:33:36 AM
I would like a raiding race to. Like the star fire Tangries(?) that could raid ships and worlds, reducing your empires income from shipping lines, sometime maybe even capture a ship. This would give us a reason to have "police" ships or a more regular military patrols...

By the way I would like to have a automatic order for "rescuing" crew pods. Its a bit tedious to pick up a 100+ pods after a fighter battle...
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on March 07, 2017, 09:29:40 AM
RE: Class Rank Limits
Will we also be able to bar a class from having a commander at all?

---

Quote
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.

Title: Re: C# Aurora Changes Discussion
Post by: bean on March 07, 2017, 10:51:15 AM
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. 
I've long advocated having a system where you can select one of four levels of crew: conscript (current, no points), low (50% of normal crew points), normal (current, normal crew points) and picked (150% of normal crew points).  It annoys me that my newest and best ships always have the worst crew, and I'd really rather crew rotated on and off ships so you get a more even distribution of experience across the fleet.

Quote
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 07, 2017, 12:34:20 PM
RE: Class Rank Limits
Will we also be able to bar a class from having a commander at all?

Yes, I can add that.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on March 07, 2017, 01:26:14 PM
That would be rad. You could RP fighter as drones (leaving aside such minor details as the enlisted spacers in the back seat...)
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on March 08, 2017, 05:58:26 AM
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.

Yeah it would pose balancing issues with missiles for JP assault, and your absolutely right that a way to jump out would be needed too. Would make sense if normal Jump drives also could jump back out from the same position they appeared btw, and was not forced to go back to 0km distance from the JP. I didn't even think about that.

To be balanced such a raiding Jumpdrive would probably need to be banned from being missile armed too.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on March 08, 2017, 11:23:39 AM
That would seem a very arbitrary and clumsy restriction.

But piracy/raiding is an angle I would find very interesting; it's a way to get a legitimate challenge out of an inferior opponent and to generally add a lot of tactical depth because adequately protecting one's shipping is much more dynamic than just protecting planets and jump points.
Title: Re: C# Aurora Changes Discussion
Post by: Haji on March 08, 2017, 11:42:49 AM
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.

(http://aurora2.pentarch.org/index.php?action=dlattach;topic=8497.0;attach=2115)
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on March 08, 2017, 11:46:02 AM
The entire reason why the "missile problems" (too powerful compared to beams, hard to defend against with equal mass of point defense etc etc) come out so frequently is due to the current aurora model which does not really work so well. And the culprit I think is the 5-second interval limitation.

In the real world there would be no problems, because target acquisition takes just a fraction of a second. But in aurora, due to the 5-second interval limit, any missile that is launched close enough to its target will NOT be fired upon except by CIWS (which ignore every sensor mechanic, including jump point delays. Another unbalanced thing in my opinion).

Because of this, if say your missiles can make 20000km/second, they suddenly become the most powerful weapon if the target is closer than 100000km because they cannot be intercepted. I would imagine instead that they could and should be targetable by semi-automatic, AI-controlled weapon systems of a technology level many times more advanced coompared to ours.

Now I understand why the 5-second interval exists in game. It is undeniable, however, that it creates a powerful distorsion in favor of missiles in close range combat. And until the issue is somehow fixed, I think we will still be discussing often of how missiles are overpowered and unbalanced.
Title: Re: C# Aurora Changes Discussion
Post by: bean on March 08, 2017, 12:54:59 PM
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.

(http://aurora2.pentarch.org/index.php?action=dlattach;topic=8497.0;attach=2115)
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.
(In my ideal system, crews would rotate in and out, so you didn't see stuff like that.)
Title: Re: C# Aurora Changes Discussion
Post by: Haji on March 13, 2017, 01:20:51 PM
I have two requests for Aurora changes, both pertaining to the economy.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on March 13, 2017, 07:28:49 PM
I have two requests for Aurora changes, both pertaining to the economy.
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.
Remember that 7.2's changes will be implemented into C# aurora as well: http://aurora2.pentarch.org/index.php?topic=8151.0

I don't know if that top one is quite what you're asking, but civilian ship building will be modified.
Title: Re: C# Aurora Changes Discussion
Post by: Haji on March 14, 2017, 02:51:57 AM
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.
Speaking of 7.2 changes list will orbital maintenance modules build maintenance supply points?
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on March 14, 2017, 02:58:31 AM
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.

I agree that it would really be nice if shipping lines would "calculate" how many colony ships, liners and cargo ships you actually need and build those instead of just building an equal distribution of ships.

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.

To make an example: "The State notifies that there will be an important colonizing push in the next decades". Choose the appropriate combo-box option and the shipping lines will build more colony ships than other types of civilian ships.

I think it would make perfect sense too.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on March 14, 2017, 07:15:07 AM
Or allow you to straight up ban production of new trade, colony, or freighters if you wish.
Title: Re: C# Aurora Changes Discussion
Post by: Detros on March 14, 2017, 07:16:55 AM
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...
Title: Re: C# Aurora Changes Discussion
Post by: Haji on March 14, 2017, 07:23:13 AM
Or allow you to straight up ban production of new trade, colony, or freighters if you wish.

That is already coming according to the change notes but it does not solve my particular problem of having half the commercial ships orbiting useless instead of earning me some much needed profit.
Title: Re: C# Aurora Changes Discussion
Post by: bean on March 14, 2017, 12:02:40 PM
I've seen the same problem with unused shipping.  My thought is that the best solution is to have the lines look at how much money they're making from each type of ship, and bias the RNG that selects new ships based on that.  If your freighters are making twice as much per ship as your colony ships, then the RNG would buy 2/3rds freighters, 1/3rd colony ships.  If that's too extreme, then have the RNG work 50% based on profit, and 50% based on the existing distribution.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Detros on March 14, 2017, 12:13:03 PM
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.
No more "OK, I give you 100k for more freigh... why are you building more colony ships? @_@".
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on March 14, 2017, 11:09:44 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on March 15, 2017, 09:12:26 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on March 15, 2017, 10:56:42 PM
I wouldn't necessarily say it needs to "calculate" what will be needed, but if it has a bunch of colony ships sitting around doing nothing whilst it's freighters are all in constant use, they should prefer to build more freighters and ignore colony ships.And vice versa. If both are heavily used it should build a more equal spread (from that point on). If it has both sitting around doing nothing then just maybe it'd be a better idea for them to hold off on buying new ships.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on March 16, 2017, 05:12:44 AM
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  ;D
Title: Re: C# Aurora Changes Discussion
Post by: TCD on March 16, 2017, 08:27:20 AM
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  ;D
I don't really understand what you mean by statistics I'm afraid? Do you mean some sort of Empire wide performance reporting?
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on March 16, 2017, 02:12:03 PM
you know about the Production Overview, right? in the f2 screen.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on March 16, 2017, 08:35:31 PM
It seems like the AI could be reactionary.  I obviously have no idea how practical this is, but if all ships of a certain type are consistently busy, the freight lines should want to make more of them.  Conversely, if they largely aren't doing anything, then it could decide to slow production again.

Obviously depending on how things are implemented, that could be a massive pain to code, but its an idea I guess.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on March 17, 2017, 09:58:42 AM
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

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.
Title: Re: C# Aurora Changes Discussion
Post by: mrwigggles on March 19, 2017, 03:41:02 AM
I mean some working statistics like:

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.
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.

So for that to be something closer to useful, it would need to do a break out of each element at each accessibility.  How much sitting in each stockpile, depending on how things are organized internally, how much in transit. (And these two would be complicated to define with things like solarium harvesters and asteroid miners.) Consumption. Number of manned, unmanned and modules are mining these  elements. And a net estimate of time to depletion for each accessibility.
Title: Re: C# Aurora Changes Discussion
Post by: El Pip on March 19, 2017, 04:39:13 AM
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. If you have half a dozen CMCs and Asteroid Miners in a system, going through and working out annual production from each can be a chore. When spread across several systems it gets ridiculous.

Once you've identified minerals where there is a shortage then a more detailed breakdown could be useful in identifying where to put more mines or whatever. But you already have the GeoSurvey tab so it might just be duplication.

I'd also add /sector/ to the list of groups you can filter by, if you have a couple of major manufacturing centres in the Empire then putting them in different sectors would make it easier to see which has enough minerals and which might not.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on March 19, 2017, 06:25:41 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on March 23, 2017, 11:04:09 AM
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... .

Another idea for the auto-assign-routine: when the routine applies a person to, lets say Frigate 'Bloomington', and during the next turn again want's to assign it to a frigate of the same type, it would be nice if the routine then would keep it on Frigate 'Bloomington' rather than switching it to another one. Not that simple to implement, but, oh well, just suggesting it ;-)
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on March 24, 2017, 04:04:13 AM
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... .

I'd prefer if it was easier to automate mineral transfers with ships instead, such that they are possible to intercept/raid all along the lines in the future development of the game, and not just at a few strategic points that are easier to defend.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on March 24, 2017, 09:48:15 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 24, 2017, 10:59:25 AM
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.

2) I did consider that option, although it adds some micromanagement. For example, the ships being maintained would be unlikely to fit exactly into the available capacity, which means you would likely start changing the priority order to make maximum use of the capacity (or I have one ship in partial maintenance), plus there is still availability of MSP to consider. With the way I decided to handle it, all those factors get taken care of without any micromanagement. Besides, you can still order a ship into close orbit, rather than directly to the planet, which means it won't be maintained.
Title: Re: C# Aurora Changes Discussion
Post by: Titanian on March 24, 2017, 12:40:33 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on March 24, 2017, 01:22:43 PM
One option for restricting the infinite use of old ships would be to make maintaining ships take more and more wealth as the ship ages. Maybe by multiplying it by (ship's age in years) squared percent, or by (age in years/maintenance life in years)? This would have issues with FACs and fighters with very short maintenance life spans of course, but IIRC fighters in hangars don't 'age' anyway.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on March 24, 2017, 03:35:14 PM
You can keep a ship in perfect health if you maintain it properly. No need to make maintenance more demanding with the age of the ship. Aurora is already complex enough (although some might argue that it is not...  ;) )
Title: Re: C# Aurora Changes Discussion
Post by: Gyrfalcon on March 24, 2017, 04:15:28 PM
Perhaps an odd idea, but with the new maintainence rules, I think it would be great to have the ability to set ships into mothball status. This allows you to outpace your maintainece capabilities during a war, and at the end put shiosminto a reserve rather then breaking them for scrap. If you later suffer a military reversal, you will have some ships that can be reactivated relatively quickly.
Title: Re: C# Aurora Changes Discussion
Post by: El Pip on March 24, 2017, 05:40:08 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 24, 2017, 09:24:24 PM
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.

I'd say at the very least, mothballing should reset the grade points and task force training of a ship. Realistically it should probably return the crew to your pool and then take it back when unmothballed, but I don't know how much coding work that would be. I'd guess it should also take maintenance capacity and MSP to un-mothball a ship. Like, it might require 1/10th the maintenance (both in terms of capacity and MSP) while mothballed, but then when unmothballing it it's like overhauling a ship with a year on its maintenance clocks.

Honestly, though, I feel mothballing is probably a bit unnecessary right now. It's a realistic and probably useful feature, but not that useful.
Title: Re: C# Aurora Changes Discussion
Post by: mrwigggles on March 24, 2017, 09:33:59 PM
I dont think it took very long to unmothball the Ohio battleships into active service.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on March 25, 2017, 01:47:16 AM
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.

Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 25, 2017, 01:57:35 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on March 25, 2017, 03:21:12 AM
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.

I would really like for some changes in this direction. To make missiles less the "I WIN BUTTON" they are right now.

It makes for a boring situation. I do limit their usage a LOT by my own choice but still, it would be better if other weapons were more viable.


I think the main problem lies in how hard to intercept they are, and especially how there is no defense against missiles launched from within the 5-seconds range. And how it's hard to defend against boxed launchers. It is a limitation of the engine, because the shortest possible interval is 5 seconds. I understand that.

But it DOES make missiles extremely unbalanced.

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.

The problem is not really the range, but rather the 5-second interval which does not allow beam weapons to shoot at incoming missile targets multiple times. Like it should be possible to do instead. Maybe with a specifically built version, but it should be possible

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.

Title: Re: C# Aurora Changes Discussion
Post by: Iranon on March 25, 2017, 04:57:37 AM
My experience is rather different.. I find missiles strictly optional, and most of the time not worth the logistics overhead.

I also don't think box launchers are a problem... in fact, I think the current system works well in that a missile-based power needs to decide whether they want to overwhelm PD with large concentrated strikes (simple but expensive in terms of ordnance) or many simultaneous volleys (requires designing around, usually requiring sacrifices in overall capability or a high upfront cost).

Balance of point-blank missile fire vs. long-ranged beam weapons looks perfectly fine to me; I played around with it but found purpose-built ships a cool niche rather than something I'd rely on; with more conventional ships it's a legit desperation tactic but hardly impressive.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 25, 2017, 05:55:29 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on March 25, 2017, 11:15:46 AM
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.

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? 
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 25, 2017, 11:38:49 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on March 25, 2017, 12:19:24 PM
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.

Well we already have transnewtonian elements, why can't they be boosted to faster-than-light speeds with that?
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on March 25, 2017, 12:19:54 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 25, 2017, 02:02:49 PM
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.

I'm not convinced that missiles are overpowered :)

They are tactically strong but strategically weak and you soon run through missile supplies in any prolonged conflict. Also, you can build some fairly missile-proof ships already so making beam weapons more effective would tilt the balance too much the other way.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on March 25, 2017, 02:36:12 PM
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).

That would go a long way in making things better, so I'm looking forward to that :)

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.

Now you're just being evil. Can I have a time machine? Pretty please? I really want to meet new and lethal. Overwhelmingly lethal cuddly foes :)
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on March 25, 2017, 03:01:44 PM
Looking very much forward to better AI designs... giving the NPRs an advantage through game settings could compensate for some of the problems, but I found it rare to get a good challenge rather than "cakewalk", "almost impossible" or both (easy but involving numbers that'd turn the game into a full time job if you want to get on with it).
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on March 25, 2017, 05:02:31 PM
Missiles aren't overpowered. The only "unfair" advantage they have is when launched inside the 5-second window, which can even at med tech levels be pretty long distance. CIWS still works even under that situation. As Steve said, unless you've been stockpiling massively and have built the collier ships to support your battle fleet, you'll run out of missiles pretty quickly. Furthermore, they require a significant infrastructure investment.

As for balance, I personally hate it. Balance should only worry designers of competitive multiplayer games, it doesn't belong to single-player games. Aurora has good amount of detail and options, these shouldn't be neutered for the purpose of balance. You can overwhelm the AI easily enough as it is.

Thirdly, as pointed out, any mobile unit can easily dodge any non-powered projectile or beam. And for planetary or base bombardment, their purpose would practically be same as missiles, except smaller and the attacker would never run out of ammunition. The game would need to track their path during their "flight", which adds an extra layer of computing - whether that would be an issue on C# Aurora I don't know - and it would also require a defensive system of sorts. So then we need special sensors to track kinetic projectiles and beam weapons to destroy them. In the end, the game would recreate the current missile vs beam combat scenario but in a situation that is infinitely more advantageous for the attacker because they don't have to worry about missile supply.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 25, 2017, 05:39:50 PM
I have some thoughts on beam range and the balance between beams and missiles, but I don't think they're really relevant to C# changes. I could start a thread to discuss ideas in the suggestions forum if people want.

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.

A bit of a wild idea, but... I gather the NPRs use a sort of template system for designing ships, with spoilers either also using templates or just preset designs. Any chance that could be opened up to the players? We have a pretty thriving community of ship designers, after all.

I don't necessarily mean full "mod" support or anything, but if just the syntax of the templates were available and not too complex I bet there'd be lots of players willing to make doctrines/themes/what have you for NPRs that you could decide to include. Might be interesting if any NPR you encountered might have conventional ships, or might use some other player's box launcher/railgun barge designs, or some sort of missile pod carrier. Variety is the spice of life, after all :)
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on March 25, 2017, 06:55:08 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TheBawkHawk on March 25, 2017, 07:04:18 PM
Quote from: MarcAFK link=topic=8497. msg101997#msg101997 date=1490486108
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.

That would mean that energy weapon ranges would have to be cut by a fifth though, because of the lightspeed limit.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on March 25, 2017, 09:03:39 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on March 25, 2017, 09:14:43 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on March 25, 2017, 09:55:38 PM
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.

Matter of volume the fire needs to cover. In WW2 aircraft usually didn't travel faster than 180m/s, and tended to fire several rounds per second for the smaller guns. And they missed, rather often at that. I don't have the numbers on hand, but even with proximity fuses several hundred shots were fire for every hit at minimum.

Aurora spaceships move faster. In fact, a ship going at 180 000m/s is pretty slow. They are much more massive and as such also a lot larger than WW2 aircraft, but the sphere they could've changed course to is even larger by a much greater margin. And unlike WW2 shells, you have to hit, as a proximity fuse for lasers and particle beams doesn't exist, and your rail guns are dumbfire unguided weapons. And rather more importantly, even on a big ship you aren't going to be mounting a whole lot of these guns, and the best rate of fire you could theoretically get is the rail gun's 4 shots every 5 seconds.
Title: Re: C# Aurora Changes Discussion
Post by: mrwigggles on March 25, 2017, 11:49:20 PM
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. 
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on March 26, 2017, 12:35:59 AM
There's just no way you can beat a guided, self propelled projectile for anything resembling a realistic space weapon.  increasing beam weapon range - besides the realism problems - won't do much, because they will still be dunked by missiles. 

Missile v beam balance is very complicated, because there is a metagame with missile size/range/launcher size reduction.  Smaller missiles are much better at penetrating defenses, *particularly* beam defenses.  Their primary downside is typically lesser range, which means that despite better performance overall you might lose anyway if you're bombarded from beyond your ability to respond.

There's also that as of the engine rule revision, railguns have become dramatically high performers in terms of missile pd (anomalously so). which distorts efforts to compare.

I do think overall missiles are a bit too much better than beams, in that a close range missile combatant (i.e. an AMM vessel) is usually superior to a beam warship.  I also think that strategically, missiles are still better than beams;  it's much cheaper and easier (on a build point to build point basis) to replace expended missiles than it is to replace the beam warships you will lose when you are at a disadvantage in the missile fight.  Missiles do place a greater stress on Gallicite, but beam warships typically have very expensive engines anyway.  I find that beams advantage is usually tactical - when the missiles run out, the fleet with better beam performance wins the battle. 

My own personal Modest Proposal on beams v missiles is rather complicated.

1.)  Eliminate final fire PD. Beams can only be used for area PD. Any weapon type can be used in designing CIWS, possibly excepting microwaves and mesons.  Slightly extend basic beam weapon/fire control ranges, particularly at lower tech levels.
2.)  Apply principles of diminishing returns to active sensors, dramatically reducing their possible ranges.  (The ideal is that a fleet benefits from using pickets more so than scaling all sensors up to size 50, as tends to happen when optimizing.)
3.)  Reduce the basic engine power multiplier bonus of missiles.  Adjust multiplier tech for both missiles and engines so it is more of a gradual curve.  This may necessitate adjustments to the tracking speed mechanic.
4.) Make reload speed for missiles less linear with size; a TL3 size 1 standard launcher might have 20-30s reload time, whereas a size 10 might only be 60-70s.  The idea would be to make missile defenses more about capability (like beams) and less about magazine size.
5.) Missile decoys - give missiles an ecm capability to produce false missiles, which protect the real salvo. would work sort of like HTK.  Could replace missile armor.   A salvo of 10 missiles with a decoy rating of 1 would give an incoming hit a 50/50 chance of hitting a decoy rather than a missile; hits on a decoy reduce the decoy value, and striking a real missile would also eliminate its decoys.

et cetera.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 26, 2017, 01:55:46 AM
Well, if we're going for it, my modest proposal for making beams a viable alternative to missiles:

1) Halve all non-conventional engine and fire control tracking speeds, across the board. If this makes logistics a problem, also reduce cargo holds and non-mineral cargo sizes by 60% (ie, cargo hold and construction factory both change from 25,000 tons to 10,000 tons). Accuracy would be unchanged, but it would be effectively doubling beam range as targets would move through that range slower.
1b) If that's not enough, rebalance fire control ranges to be longer. Keep the cap at 1.4m km, but make it so that's reachable at about the middle to middle-late part of the tree, and after that you're just improving accuracy at 1.4m km.
2) Require all missiles to have at least one layer of armor like ships do (making smaller missiles trickier), but missile armor scale with armor tech. Edit: To clarify, the one layer of armor would be the 1 hp missiles have now, not make them harder to destroy.
3) Final Fire PD should work like AMM PD (and I think area PD?); all weapons in an increment pick a target, then roll to hit. This makes PD more random, leakers more common, and incentivizes multiple layers of PD (AMM -> Area PD -> Final Fire PD). Turns good PD into damage mitigation rather than damage negation.
4) Add some sort of E-War system or non-conventional beam weapon that has a chance to temporarily disable engines and always has a range of 1.4m km (max beam range). This eliminates the issue of "kiting" an enemy while firing beam weapons from outside their range.

It isn't really related to the change but I do really like the diminishing returns to active sensors idea.
Title: Re: C# Aurora Changes Discussion
Post by: Gyrfalcon on March 26, 2017, 02:50:49 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 26, 2017, 02:53:33 AM
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.

Fighters aren't maintained by maintenance facilities. For that matter, any ships in a hangar normally aren't either.
Title: Re: C# Aurora Changes Discussion
Post by: Gyrfalcon on March 26, 2017, 03:06:31 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 26, 2017, 06:38:23 AM
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.

Ships in hangars still won't require maintenance.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 26, 2017, 07:13:04 AM
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.

Title: Re: C# Aurora Changes Discussion
Post by: Haji on March 26, 2017, 07:53:35 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 26, 2017, 08:36:51 AM
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 am not trying to force larger munitions but rather than to reduce the advantages of smaller 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.

With regard to sensors, I am already working on some ideas but the main point is to reduce the linear effectiveness of very large sensors rather than reducing the range of smaller sensors. In fact, for lower resolutions, the ranges may go up under the proposal I am creating, which will allow earlier detection of missiles. I will post in a separate thread as I imagine there will be some debate :)
Title: Re: C# Aurora Changes Discussion
Post by: Haji on March 26, 2017, 09:09:45 AM
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.

While I would love to see a good EW system I just had a sudden thought. Maybe it would be best to simply add a nebulous "penetration aid" statistic for missiles (and maybe a technology) that reduces the interception chances of anti-missies/point defence. It would have to be quite massive (definitely more massive than agility is right now) in order to not be overpowered but as most of the problems with very high anti-missile interception chances seem to come from agility rather than speed than having a statistic to counteract said agility (to an extent) could be the best and easiest solution. Of course this would force re-balancing beam based point defence, possibly by increasing the rate at which tracking speed increases. And as a last thought in order to not be overpowered the penetration aids could only nullify bonus from agility/tracking speed bonus but could not reduce interception chances below the base chance rated by missile speed/tracking speed.

As I said just a thought and a game wide EW revamp would likely be superior to that, but also harder to code I imagine.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on March 26, 2017, 09:21:43 AM
Regardless of what happens, in this thread you can really see the rift between "the poeple who like missiles and would make them better" and "the people who like beams and would make them better"  ;D

Jokes aside. I still do think that missiles are in a much better position that beams. Inordinately so, especially against some enemies. PDCs are particularly unbalanced with missiles. Missiles PDCs are cheap, don't require much tech, use no maintenace currently, are fast to build. And can provide a huge amount of firepower.

Say, I can make a pretty cheap early defense based on missile PDCs against invaders. And it will work, if I shoot enough missiles at them to surpass their PD and have some basic engine speed technology. In my experience, I simply cannot achieve the same with beam weapons. If I want to use beam weapons against invaders, I really need a LOT of tech research, and espensive stations/ships. PDCs with fighters are a possibility, but still much lower efficiency than missile PDCs.

Since tech research is costly and takes time, if I have to choose between research for missiles and research for beams, I won't reasonably go for beams if I know invaders can show up.


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.


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.

Yes please, post this in a different thread with some numerical example. It will be a long and complicated discussion :)
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on March 26, 2017, 09:34:39 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on March 26, 2017, 12:22:48 PM
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.

Re longer-range beams, it's pretty obvious that current beam weapons propagate FTL, or they wouldn't be able to hit at range, because ships would be dodging.  I headcanon it as part of the fire-control system, and I don't think that doubling current beam ranges would break the game badly. 
I'll have to dig up some old suggestions I have on EW, but would be excited to see more of that.

Re faster-firing larger missiles, this is long overdue.  Currently, you suffer a penalty in terms of firepower equal to the square of missile size per HS of launcher, which forces down missile sizes.

One thing that might help make small missiles less effective would be to make bigger missiles inherently more resistant to damage.  Alternately, I'd suggest allowing AMMs to make proximity kills of incoming missiles, which makes big salvos relatively less powerful.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 26, 2017, 01:21:26 PM
Generally agree with everything with one exception.

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. It is true that it would give an advantage to a slower ship with a longer range beam (since the enemy needs longer to close the range), but generally beam range beyond the earliest tech is limited by fire control and damage at max fire control range is tiny due to single digit hit chances (and you mentioned making missiles interceptable inside 5 second increments). So if the enemy can close you'll probably score a few hits as they do but it wont be the unbeatable advantage that faster and longer range is, even with longer range beams.

I do think this needs some sort of fix if beam combat is going to become a major part of the game, though, not to mention kiting being a 100% auto win button is just kind of boring. That's why I suggested some sort of way to "snare" enemy ships.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on March 26, 2017, 03:10:27 PM
i find that beam ships are generally awful at long range, since they have both damage degradation and accuracy degradation, so it will be difficult to get gunned down on the way in.  For example, its rare to score any significant number of kills (or any kills at all) on a group of swarm FACs before they find their range, unless your ships are almost as fast as theirs to begin with.  Bear in mind that i mostly play at TLs 3-5.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 26, 2017, 03:17:35 PM
Yep. If you can just hold the range forever, it doesn't matter if it takes 2 hours to kill the enemy. But if it takes them 5 minutes to close from extreme range to medium range, you'll get some free hits in but it wont be a completely one sided battle simply because damage falloff is so high.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on March 26, 2017, 04:15:58 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 26, 2017, 04:36:31 PM
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.

I... what? I'm not talking about beam ranges of 50 million km or something where it might actually take hours to close the range. Right now if you have any speed advantage whatsoever you're looking at closing from their beam range to your beam range in a few minutes at most, taking maybe a few minor hits as you do so. It would if anything increase how often you get a nail biting situation like that, since right now either you can hold the range open forever or they can close to their range pretty much instantly, since beam range is so tiny compared to average ship speeds.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on March 26, 2017, 06:25:29 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Haji on March 26, 2017, 06:34:26 PM
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.

By and large I quite like the idea. The problem is with ECCM equivalent.

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).
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 26, 2017, 07:28:32 PM
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
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on March 26, 2017, 09:13:20 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: swarm_sadist on March 26, 2017, 11:39:41 PM
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.

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).
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on March 27, 2017, 03:47:55 AM
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 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.


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?

I would love to see big but crude tech guns, and I am also curious what Steve thinks of this idea.
Title: Re: C# Aurora Changes Discussion
Post by: IanD on March 27, 2017, 05:07:52 AM
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))
Title: Re: C# Aurora Changes Discussion
Post by: DIT_grue on March 27, 2017, 08:14:46 AM
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).

Sure there is - a missile's engine only has to work for as long as its endurance; anything else has to be maintainable forever. It isn't even possible to restart a missile once (you have to build in a whole new engine and there can be no coast phase at all), and I'm given to understand that in RL rocketry achieving that is an important distinction in capability and carries commensurate costs (although improved reliability is a big part of its value, which doesn't really translate).


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.

Except that with Trans-Newtonian tech (even 'Conventional' engines!) it is completely trivial. Gravity is irrelevent: all that matters is the fuel cost to move a particular distance, and it doesn't make the slightest difference how curved the space traversed to cover that distance is or isn't. You can RP otherwise if you want, but trying to justify it against game mechanics as the default assumption would be more of an uphill slog than escaping Earth's gravity well.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on March 27, 2017, 12:07:10 PM
I thought some of the main issues with missiles v beams were the five second tick which allowed the missiles to cover so much time and the simplistic damage range with the minimum of 1 causing lots of issues with making point defence too powerful.

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
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 27, 2017, 01:16:27 PM
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))

Max pop would vary by species. So species A might have of max pop of 12 billion while species B might be 18 billion. Species A will stop growing at 12b, while species B will stop growing at 18b. This means the growth in population of B could stop A growing. In addition, the growth in population of Species B will eventually cause unrest due to overcrowding in Species A (which could lead to conflict). I guess you could RP this as the species B population objecting to the growth of the species A population and demanding their leaders do something about it.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 27, 2017, 01:18:36 PM
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.


I'll take a look.
Title: Re: C# Aurora Changes Discussion
Post by: Haji on March 27, 2017, 01:30:10 PM
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

Gauss cannons already make it impossible to use repeatable launchers, as they are simply too good, effectively forcing the use of box launchers. Allowing even smaller point defence weapons would make it next to impossible to get past point defence, even before anti-missiles are included. That will not balance things, it will make missiles completely useless.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on March 27, 2017, 01:40:35 PM
I'll take a look.

And here was the numbers for ship engines (earlier in same thread):

http://aurora2.pentarch.org/index.php?topic=7448.msg75697#msg75697

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
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 27, 2017, 01:41:05 PM
And here was the numbers for ship engines (earlier in same thread):

http://aurora2.pentarch.org/index.php?topic=7448.msg75697#msg75697

I was about to ask for that link :)
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 27, 2017, 02:03:33 PM
And here was the numbers for ship engines (earlier in same thread):

http://aurora2.pentarch.org/index.php?topic=7448.msg75697#msg75697

I have run the numbers, joined up the missile and engine modifier suggestions and compared to the current version. FCM is Fuel Consumption Modifier. TBH I like your version a lot better than mine :)

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.

This would probably complement the sensor changes as they would reduce missile ranges anyway.

(http://www.pentarch.org/steve/Screenshots/FuelModel.PNG)

Title: Re: C# Aurora Changes Discussion
Post by: JOKER on March 27, 2017, 02:19:21 PM
My idea about problem 1 is that range of large beam weapon may not rely on tech. Fire control only improve hit chance, not max range.
Title: Re: C# Aurora Changes Discussion
Post by: Haji on March 27, 2017, 02:41:40 PM
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.

Edit: I misread. The fuel consumption for anti-missiles will be increased by a factor of about four, so I have no complaints.

Last but not least the anti-missiles. With your new sensor rules it will finally be easier to perform longer ranged interceptions even on low technology levels, which is important as that was the main reason box launchers were so very powerful below fusion era. However you are kind of undoing that by increasing anti-missile fuel consumption by factor of about seventeen. That's a very, very large change.

Of course it has some benefits. As I mentioned a couple of times already agility is far too powerful on medium to high tech levels and the increased fuel consumption will cut into space you have for said agility, forcing come interesting potential trade-offs. But on low levels anti-missile interception chances are usually 'meh' (20% or so), the launchers have 10 sec recycle time, which is a huge handicap, and now not only you'll have trouble putting in some agility (still weak on this level) but also you may be unable to fully utilise your fire control range. That can be problematic.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 27, 2017, 03:15:58 PM
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 point about range for fighters & gunboats is valid, although they have the option to accept a lower engine boost to compensate. With these engine rules the carrier should be able to carry more fuel for the fighters, or dedicate more space to engines.

However, in sensor terms fighters & gunboats are better off overall than before. The improved range for high resolution sensors is only for the smaller end of the scale (to make non-specialist ships less vulnerable). Once you get past size 5 for resolution-20 sensors, the range is less than before. For fighter detection, a resolution-5 sensor is worse than before once it reaches size-8.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on March 27, 2017, 03:19:09 PM
Quote
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. 

Interceptor fighters, ie fighters with AMMs and anti-missile sensors, will be *very* viable....
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 27, 2017, 06:54:25 PM
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.

You can't really look at the changes in a vacuum. For instance, greatly reducing the range of missiles, if you made no other changes, would make fighters far more effective. Missile fighters already work best as providing a range boost for more efficient shorter range missiles, and this will increase the efficiency bonus of short range missiles. Less efficient missile engines don't just mean all missiles are less efficient, it means the longer range a missile is the less efficient it becomes, and missile fighters are currently the king of short range missile combat.

The sensor change is also a mixed bag for fighters. It improves sensors with lower resolutions, but it also improves smaller sized sensors, like the kinds fighters (even dedicated sensor fighters) would mount. Using the numbers in the thread, a size 10 anti-fighter (res 5) sensor will now actually see its range go down, while a size 2 resolution 100 sensor would go up. Warships will frequently have size 10+ sensors, whereas fighters wouldn't and gunboats barely would.

Edit: Thinking about it, the sensor change combined with the reduced missile range change might well mean space superiority fighters finally become viable, since they could carry small anti fighter missiles in to intercept missile fighters before they could launch.
Title: Re: C# Aurora Changes Discussion
Post by: Haji on March 27, 2017, 07:40:54 PM
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. 

Which is possibly the biggest problem. Fighters already struggle to get through point defence designed by a human. Now the missile detection range will be higher, allowing for more anti-missiles to be fired, while fighter missiles themselves will become slower and easier to intercept. That will make fighter strikes even worse than they are now.

Of course to a certain extent this will be true for all missile based designs. The reason I'm singling out the fighters is, as I said, they have more problems putting enough missiles into space to get past enemy defences. After all a missile armed ship carries it's ordnance directly. A carrier on the other hand carries smaller craft that carry actual missiles, leading to much smaller salvoes per tonne (or per wealth/minerals).

Of course it may still turn out fine, but this is why I wrote my original post - the changes never mentioned fighters so it may have turned out as an unintended consequence. It's something that requires testing, but the only one who can test it is Steve himself.
Title: Re: C# Aurora Changes Discussion
Post by: Spotswood on March 27, 2017, 09:41:13 PM
Has the idea ever been floated to give fighters a dodge bonus which could be increased with things like chaff or other coutermeasures?
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on March 28, 2017, 01:57:14 AM
OTOH, I feel missile fighters are already somehow encouraged to defeat PD with number of salvos rather than sheer volume, so they may not be marginalised as badly as you fear.

OTOH, if this becomes a necessity we may see a considerable reduction of viable types... especially if we further discount the gamey ones.

*

Removing the discrepancy between ship and missile speed is a dangerous increase of design freedom without major changes to the underlying system. Launching platforms able to keep up with their missiles can render most conventional point defence meaningless, beam ships able to keep up with enemy missiles can shoot down an arbitrary number. There are probably other things I haven't thought of.
Already powerful but constrained niche designs , these will require less extreme tech requirements/design concessions if natural speeds of ships and missiles converge.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on March 28, 2017, 03:26:59 AM
I think the most interesting change for fighters & FAC/gunboats with a unified fuel consumption vs size formula is that engine size becomes a whole new and very important design consideration for small crafts.

A size 10 (500ton) FAC or small corvette engine will have close to identical fuel consumption to before but smaller engines will become much less efficient. Your still going to be able to have close to similar performance with the largest fighter engines, 6HS (300ton) will just have 29% higher consumption, but when going down towards 1HS (50ton) we are quickly losing out on alot of range or extra fuel needed.

This becomes an important trade off with fighter total size which you want to keep low to be able to get closer without getting detected, especially if more granularity to engine size is added such that fighters can be made extremely small using say a 0.5HS (25ton) or 1.2HS (60ton) engine.

Long range strike fighters could be going for pretty big engines for fuel efficiency similar to now, while shorter ranged Interceptors or Gauss PD fighters could opt for smaller engines to keep their size down and speed high, or get some redundancy when engaging enemy fighters thus sacrificing efficiency.



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.

Thanks for considering my suggestion!

The formula ( SQRT(10/HS) ) is pretty flexible.

If you think that the fuel consumption difference between largest capital engine and smallest AMM becomes too extreme you can adjust the exponent (SQRT = ^0.5) to be something closer to 0 instead. With ^0.4 instead consumption for a 0.5 MSP AMM engines goes from 2000% -> 1098% and consumption for a 200 HS capital ship engines goes from 22% -> 30% thus narrowing the span a bit.

And if you want to shift the 100% efficiency "base" engines in either direction you just change the 10/HS to 5/HS or what size you feel should be the base.

I trust you will be able to find some formula that you feel work well here.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on March 28, 2017, 06:34:46 AM
I'm going to say I love it but with a qualifier as I barely use fighters myself so there are implications I can only grasp from reading the dissenting points discussed here. But I think there must be some increase to missile fuel use as fuel is usually a minor part of missile design except in late tech level ultra high power missiles, or ultra long range designs.
Title: Re: C# Aurora Changes Discussion
Post by: Haji on March 28, 2017, 09:29:16 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 28, 2017, 12:56:13 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Haji on March 28, 2017, 01:07:13 PM
Ah, sorry didn't mean to sound like I was nagging you, just wanted to disagree with someone's perspective.
Title: Re: C# Aurora Changes Discussion
Post by: IanD on March 28, 2017, 01:18:03 PM
Quote
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: 358RP

Code: [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

So with the new sensor rules its back to the missile ranges of Aurora v3.0!   ;D
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 28, 2017, 05:32:06 PM
Ah, sorry didn't mean to sound like I was nagging you, just wanted to disagree with someone's perspective.

Didn't take it as nagging and happy to hear all perspectives :) Just wanted to reassure that I will reconsider if the reality doesn't match the intention.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on March 29, 2017, 01:57:39 PM
Yay for email notifications. And for the terraforming updates :)

Really loving the changes about max population, terraforming speed based on planet size and finally, at long last, water.
Water is absolutely necessary to life as we know if, so finally having that factored into colonization choices is really really nice.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Haji on March 29, 2017, 02:04:49 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on March 29, 2017, 02:18:54 PM
I'd like to point out that a low-gravity planet will require more atmosphere to get the same surface pressure.  Dividing the rate by the planetary gravity will correct for this, and will reduce the scaling of the terraforming rate from being approximately proportional to the square of radius to being linear with radius.  That helps avoid the problem of big worlds being too slow or small worlds being too fast.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on March 29, 2017, 02:41:28 PM
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!
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 29, 2017, 03:28:26 PM
I see how you can add hydrosphere, but is there any way to remove it?
Title: Re: C# Aurora Changes Discussion
Post by: Detros on March 29, 2017, 04:26:47 PM
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.
Or the other way, couldn't cooling ice-ify the water?

But yes, it seems Steve talks only about one side of the process in the changelist (http://aurora2.pentarch.org/index.php?topic=8495.msg102115).
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 29, 2017, 04:49:40 PM
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!

Yes, I agree. This is one of the things I was trying to achieve with the changes.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 29, 2017, 04:53:33 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Kelewan on March 29, 2017, 05:10:54 PM
Quote from: Steve Walmsley link=topic=8497. msg102132#msg102132 date=1490824413
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.

There would be an equilibrium between evaporation and condensation in a short time, so why not make a fix rate between water vapour and water on the planet based ob total pressure and temperature.   
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 29, 2017, 05:11:02 PM
About 0.001% of Earth's water is in the air, representing about 2% of the atmosphere on average. BTW that type of ratio is why you need so much water vapour in terraforming to create surface water (in reality you would need a lot more than I am specifying but I am trying to create a balance between game play and reality)

I will add some code to evaporate a tiny fraction of any liquid water so it can be extracted by terraforming.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 29, 2017, 05:34:23 PM
I don't mind waterforming being significantly slower. Means you can work on atmospheres first and reserve growing/shrinking oceans for when you don't have more urgent work for your terraformers (or even make it a long term task for terraforming installations)
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 29, 2017, 05:59:18 PM
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.



Title: Re: C# Aurora Changes Discussion
Post by: ardem on March 29, 2017, 07:24:03 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 29, 2017, 10:15:31 PM
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.

I believe ice is currently considered part of hydro extent. If so, that might mean that adding water vapor to a cold planet would reduce the temperature by increasing the ice shelf, which is kind of cool (though not terribly useful since there's anti greenhouse gas).
Title: Re: C# Aurora Changes Discussion
Post by: dukea42 on March 29, 2017, 11:13:44 PM
Loving this update energy!  Some thoughts for the discussion. 

1) Should terraforming have a fuel cost per module/installation?  Seems like there needs to be economic impact to represent all the effort of hauling space debris or cracking rocks to produce all this ATM. 

2) Can there be a tech line around racial radiation resistance?  Just read a few older campaigns (Kurt's 6 powers) that would have fit the roleplay theme to have a faction (try to) adapt to the nuclear winter.

3) Same campaign gave me the thought that maybe mesons should be allowed as an alternative CIWS option from the energy weapon side.   Maybe another tech line to improve 'split projectors' to improve PD effectiveness?  While there's beam vs missile tactic discussion, seems like a lot of roleplay between energy vs kinetic factions. 

4) I also wondered if there was any role left for passive thermal tech?  Seems like it should at least improve CIWS quality.   My crazier ideal is that the smaller missiles (<10 msp?) are detected via "active optical" laser based sensors (thermal tech) and boosted by thermal sensitivity.   

Sorry if it's too much random ideas at once. 
Title: Re: C# Aurora Changes Discussion
Post by: Gyrfalcon on March 30, 2017, 01:39:20 AM
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.)
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on March 30, 2017, 04:45:30 AM
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.)

Maybe have a "queue" of atmosphere changes you will make, and then display what the target values will be after entire queue is executed?

Queue could also display expected dates when changes will be finished based on current terraforming rate.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on March 30, 2017, 04:51:41 AM
other possibilities: make terraforming modules a high tech system; introduce diminishing returns on terraforming rate; cause active terraforming to introduce a negative manufacturing modifier; make terraforming facilities non-transferrable.

Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on March 30, 2017, 06:01:28 AM
I'll throw in my two cents. Make terraforming modules/mining modules require reactor power like I suggested for sensors. Then Require reactors to consume fuel.
Then Aurora just becomes a huge fuel logistics simulator.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on March 30, 2017, 06:40:30 AM
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.

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 :) ).

Just thinking aloud here on the fly:

- there are 3 main reservoirs for water: atmo, hydro, and ice caps
- ideal gas law says Pressure = constant * density * temp.  So as someone above mentioned, pressure should be proportional to temperature (in degrees kelvin :) ).
- hmmm - this (pressure scales with temperature) should actually apply to all gasses.  So maybe the terrarforming pressures should be measured in "standard" atmospheres, then the "actual" pressure should be standard pressure * (temp/300 kelvin).
- can use Earth data to calibrate numerical constants, i.e. plug 75% in for hydro and pick constants so actual Earth atmo pressure comes out (think this is mentioned above).
- below ice cap temperature, all hydro should go to water.
- need a constant conversion factor that converts from 1 atmo of water vapor to x% surface coverage.  This means you'd need to dump a LOT of water in the atmosphere to get any change in hydro (so atmo is essentially controlled by hydro %)
- 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.

John
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on March 30, 2017, 07:24:56 AM
Maybe have a "queue" of atmosphere changes you will make, and then display what the target values will be after entire queue is executed?

Queue could also display expected dates when changes will be finished based on current terraforming rate.
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).
Title: Re: C# Aurora Changes Discussion
Post by: Detros on March 30, 2017, 09:25:40 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on March 30, 2017, 10:32:47 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on March 30, 2017, 10:41:26 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on March 30, 2017, 10:48:50 AM
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.

Terraforming is a very important part of the game, especially for those who roleplay. Still, I do feel we are getting a good improvement already in this field.

I just wish we could see some bonus to wealth generation for well-terraformed planets (atmosphere, water etc) make it in for the release. Or a malus for planets without an inhabitable atmosphere/ecosystem.  :)


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

They are already going to be useful for survey ships in C# aurora. So, you probably won't have enough of them (depending on how many academies you build, of course...)
Title: Re: C# Aurora Changes Discussion
Post by: Haji on March 30, 2017, 12:35:34 PM
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 way I understand the change is not that you need 1 atmosphere worth of water vapour floating around to get 20% of hydrosphere, you merely need to generate the gases and then they will condense. If you generate 0.5 atm. worth of water vapour it will condense into 10% hydrosphere for example, although the condensation rate is fixed, so it may not happen at once and there will always be at least some vapour in the atmosphere left.

- 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.

To be honest when I consider terraforming and the need to add not only water but gases as well I always imagined chucking rocks at a given body the best way to get what you need. It can be quite cheap in terms of energy (a nuke or two to nudge an object into a new orbit especially if it's in a Lagrange point of a gas giant) and easy, just time and money consuming. Having it incorporated into the game would be nice as it would be more realistic than just conjuring everything out of thin air. Of course if we had a realistic terraforming there would be the problem of removing gases as in some cases it just appears like they end up in some black hole.

Having said that I'm essentially fine with the changes as they are. They are simple to understand, simple to implement and give you wide range of choices which means you can role-play to remove implementations you're not fine with. And since it's not overly complicated it also means it doesn't force you to play by its rules (which is why I'm against ideas that give bonuses or penalties to bodies which are well terraformed/not terraformed. If I want to play a race well adapted to domed cities I don't want to be penalised in game for that. For that matter in such cases I can just add penalties myself. But I digress).

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 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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on March 30, 2017, 12:42:18 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: ardem on March 30, 2017, 11:08:15 PM
My concern was not to add terraforming parts but look how Hyroextent was affecting max population size especially on 100% water worlds.

I just believed the terraforming was an unrealistic option, to add water vapour or take water vapour away. Both being a mix of hydrogen and oxygen, add water vapour would not change the hydroextent that much it would be relevant, even if you didput 1% water vapour into the atmosphere to make the hydroextent at 99%. Depending on temperature it would just eventually return to the sea again over a period of time. As I said the best way to effect hydroextent is making the world colder, even creating an ice age. Like our own planet did long time ago. That the best way of affecting hydro extent, or in the case of a cold planet with minimal water that is mainly ice (aka Mar) warm the planet.

Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on March 31, 2017, 04:21:40 AM
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.

I agree and identify alot with this. Much of the beauty and attraction of Aurora is it's ability to generate unique systems, stories and situations.

Thus any changes which add more uniqueness to planets or systems, or allows more lifelike flows of civilian traffic/development/industries/trade is going to rank very high on my wish list for the game. It helps greatly to become more immersed and make the stories more plausible and interesting.

Population capacity and the terraforming changes that go with it are really great from this perspective since each planet in your empire will be even more unique and memorable when their size, tidal-lock and hydro extent now all impact their potential.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on March 31, 2017, 02:52:27 PM
More detail to terraforming is always appreciated!
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on April 01, 2017, 09:54:34 AM
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.

Apologies for not responding. I understand that gravity would be a factor. However, for the sake of ease of understanding I plan to just leave it at surface area for now.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on April 01, 2017, 09:58:54 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: bitbucket on April 01, 2017, 08:32:00 PM
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.

I'm, uh, going to quote from Wikipedia here:

Quote
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.

Your formula for water vapor content is workable, but you might want to cut it by two-thirds or so.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on April 02, 2017, 01:31:35 AM
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? It would be pretty interesting to have an endgame where you have completely robotic ships. You could also make drone fighters (which honestly seem like the most plausible form of space fighter combat).

The way I see it working is that in the design menu for building a new ship component you get a slot for the AI/automation tech level you'd like to use. Obviously this would make the component more expensive.

I'm not sure whether this should increase the size of the component or not seeing as the primary reason for having it in the first place is to save space by needing less crew. Thoughts?
Title: Re: C# Aurora Changes Discussion
Post by: Detros on April 02, 2017, 04:11:08 AM
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).
Title: Re: C# Aurora Changes Discussion
Post by: Michael Sandy on April 02, 2017, 11:33:46 AM
I roleplay that Mercassium is either life support or computer support.  Mercassium is an ingredient for research facilities, so I just RP that my really long endurance fighters are actually drones.

You still have to pay, either way.  The only time it would be an issue is when something I RP as a drone fighter uses its life support to rescue life pods.
Title: Re: C# Aurora Changes Discussion
Post by: Michael Sandy on April 02, 2017, 11:37:30 AM
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.

If it showed estimated times for refueling, loading cargo, etc, that would be awesome.
Title: Re: C# Aurora Changes Discussion
Post by: Detros on April 02, 2017, 12:09:22 PM
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.

If it showed estimated times for refueling, loading cargo, etc, that would be awesome.
There already are estimates for the first command and all commands of given TG, together with distance.
If you switch to "All orders" and use several "Move to" commands it get recalculated after each of them so you can see the difference between Wolf and Wolf-Harr.
Title: Re: C# Aurora Changes Discussion
Post by: mrwigggles on April 02, 2017, 05:09:46 PM
Oooo. How about actual interception courses for ships to celestial bodies?
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on April 08, 2017, 07:40:16 PM
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.

In the context of other changes, I've already voiced concerns that disposable ships that need no maintenance for their entire service life are already quite competitive. It would be a shame if we were encouraged to play around the maintenance aspect when the aim is to make that deeper and more convenient.
Small ships now requiring significant infrastructure to maintain in numbers is a significant push in that direction.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on April 10, 2017, 01:43:48 AM
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.

I agree with these concerns.

How about something like a simple rule such that the maximum size ship that can be handled is for example 1/10:th of the total capacity?

Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on April 10, 2017, 07:01:48 AM
I like the changes to maintenence, however my concern is that the current planned numbers are very restrictive, potentially limiting fleet sizes by a large factor compared to the current game. If I had a game running I could compare the current cost vs what the same fleet would cost under the new system. I might just download an older version which has one of Steve's AAR's in the database for a comparison.
Title: Re: C# Aurora Changes Discussion
Post by: bean on April 10, 2017, 11:11:57 AM
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.
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. 
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.
Title: Re: C# Aurora Changes Discussion
Post by: Detros on April 10, 2017, 11:24:41 AM
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. 
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?
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on April 10, 2017, 02:33:59 PM
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. 
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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on April 10, 2017, 02:47:56 PM
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 agree that a 2/3 exponent is probably too harsh, which is why I then suggested .75 instead.  That gives you a higher tonnage cap than at present up until 125,000 tons.  For 250,000 tons, you need 1575 stations instead of 1250. 
Title: Re: C# Aurora Changes Discussion
Post by: TCD on April 10, 2017, 02:59:07 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Detros on April 10, 2017, 05:46:35 PM
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).
Title: Re: C# Aurora Changes Discussion
Post by: Felixg on April 10, 2017, 08:44:00 PM
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).

This is terrible logic considering that its a TN game, and ships can speed across the system in a few days, so the difference in time of moving to the end of a 600 ton FAC compared to a 6,000,000 ton super dreadnought would be absolutely negligible.

a fleet composed of dreadnoughts should be a valid play style, if someone wants to RP fielding smaller mixed fleets then that should be a choice, not a requirement.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on April 11, 2017, 02:24:07 AM
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.

The reason you need big expensive facilities is not only because of the physical size of the ship, but also because of the physical size of it's components you may need to replace, and how "deep" inside the ship and complex they are to remove/reach.

Servicing/Overhauling a battleship where you need to handle turrets of 2000 ton or engines of 2500 tons each is vastly more difficult then servicing a small fighters in a hangar where weapons are so light they can be carried almost without any assisting equipment at all.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on April 11, 2017, 03:27:25 AM
One way to handle this would be to have maintenance facilities work analogous to shipyards: tonnage limit + number of slots, possibly degressive costs for "slipway" equivalent.
Adds a bit of complexity, but might make the logistics more interesting when capital ship and FAC bases are no longer interchangeable.

I still favour the current system though, simple and elegant. Imo, it adds more depth and would feel less like a chore than the planned one.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on April 11, 2017, 03:33:06 AM
I strongly disagree with this proposal of making bigger ships require more maintenance. Both for logic reasons and for gameplay reasons.

The equivalence based on size we have with these latest changes, where a 10000 tons ships requires the same amount of maintenance as, for example, 5 2000 tons ships, is a good one. True, the bigger ships has the added complexity of some bigger components and the like. However, similarly the smaller ships will have a lot more components, and some of those will hard to maintain no matter what their size.
In fact, following this reasoning,  I'd even say the 5 smaller ships would be harder to maintain that the bigger one. Because some components will need maintenance that cannot be "compressed" just because the component is smaller.

From a gameplay balance point of view, putting a penalty on bigger ships maintenance seems to me the very thing Steve wanted to avoid. This new system is both harder and easier than before. Harder, because you need a lot more facilities than before if you have a big fleet. Easier, because you are not in a situation where it's "all or nothng" as before, when the ships were too big to be maintained in a certain place. I like this change and  adding some more limitation against bigger ships would only, in my opinion, bring us close to a situation like before.

Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on April 11, 2017, 04:22:10 AM
adding some more limitation against bigger ships would only, in my opinion, bring us close to a situation like before.

No one here wants to add any more limitations against bigger ships... Just keep a small part of the limitations big ships have in the current maintenance system in 7.1!!!

Having your massive battleships be more problematic logistics wise then several smaller screens is a good thing, not a bad thing.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on April 11, 2017, 06:10:57 AM
Having your massive battleships be more problematic logistics wise then several smaller screens is a good thing, not a bad thing.

I understand the concept, but I do not agree with your proposed method. We're in space here, we're not putting these ships in a drydock. Also, this is maintenance, not armor repair (which is done in a shipyard already).

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.

What could be done instead, IF Steve wants to keep some difficulty in maintenance of larger ships, is a non linear increase in maintenance time when the ship is larger than the sum of the maintenance facilities present at a certain location.

Say, if a ship is 30000 tons, and the place only has 20 1000 tons maintenace facilities, the effective rate of maintenance is not 20000 but 15000 or 10000. An appropriate formula would have to be proposed, one that is sensible and encourage you to use more facilities, while not being excessively punishing in case you are "below cap". Probably with a cutoff point beyond which it does not get any slower.


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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on April 11, 2017, 10:10:40 AM
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.

I may still play around with some of the parameters once I get the first test game up and running (still months away I suspect) but I want to stick with the basic principle.

Progress is mainly behind the scenes at the moment so no new screenshots are likely for a while.
Title: Re: C# Aurora Changes Discussion
Post by: bean on April 11, 2017, 10:22:28 AM
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. 

Quote
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.

Quote
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. 
Title: Re: C# Aurora Changes Discussion
Post by: bean on April 11, 2017, 10:35:14 AM
I just spotted a major loophole in the maintenance rules:
Quote
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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on April 11, 2017, 10:47:22 AM
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".

We actually do know for a fact already the the ship components are NOT modular unless we design them as such since they need to be first researched and then produced. Especially jump drives due to their size being tailored to ships.

But this gives me another interesting idea. What if the "Max Repair MSP" stat of ships could be worked into how many facilities are need to make full maintenance possible?

That way a Battleship designed with a 2500 ton engine would need lots of facilities to maintain, but a modular Battleship design with many smaller 250 ton engines instead would need 10 times less facilities for maintenance to be possible (assuming no other components have higher MSP values).

To make the suggestion more concrete: [Max Repair MSP] / 100 * [Ship Size] = "Ship Maintenance Size" which does not impact how much facilities it needs, but limits if full maintenance is possible. A 30'000 ton Battleship with a 1'000 MSP Max Repair Engine for example would have a "Ship maintenance Size" of 300'000 ton and could get 50% Effective Maintenance Rate (EMR), even if it's alone at a maintenance facility with 150'000 ton max total capacity. In doing so it would only occupy 15'000 ton capacity ( Actual ship size * EMR modifier )

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.

Not necessarily. As specified in the new solution there is a concept of partial maintenance, so it might be possible that you could do some maintenance still on Battleships with sufficient capacity for smaller ships, but not for the large one. ( As demonstrated in my example above ).
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on April 11, 2017, 12:57:13 PM
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.

I was wondering if anyone would spot this :)

I considered mentioning it but bear in mind the clock isn't effectively stopped. The quote reads "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."

Overhaul increases the 'Last Overhaul Date' at five times the normal advance of time. If you lower the maintenance facilities too far and decrease the Effective Maintenance Rate below 20%, the speed of overhaul rate will fall below the normal advance of the clock, which means that while the ship is not suffering failures, it is building up its clock. You can keep the clock stable at about 20% of the required maintenance facilities for overhaul.

it can still be useful as a holding measure if you have too many ships for the maintenance facilities but you aren't really saving on MSP very much either. Keeping ships in a permanent state of overhaul would require one fifth of the maintenance facilities and use about 80% of the normal MSP (compared to maintaining the ship normally) but you lose the flexibility to respond quickly if attacked. It could be considered a form of mothballing though.
Title: Re: C# Aurora Changes Discussion
Post by: db48x on April 12, 2017, 05:05:53 AM
As long as you're adding cool equilibrium conditions to terraforming, could you please add one to represent the loss of atmospheric water vapor by disassociation of the hydrogen from the oxygen, with the hydrogen then escaping the atmosphere over time? Presumably this would happen faster around stars that produce more UV, and on low-mass worlds. Asking for a friend.

 ;) Ok, Ok, it's not a serious request. Actually, I came in to ask why your formula doesn't seem to include the temperature. Possibly I'm missing something? Maybe temperature and pressure are always so linked that the pressure term handles it?

Title: Re: C# Aurora Changes Discussion
Post by: Titanian on April 12, 2017, 08:46:57 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on April 12, 2017, 11:47:11 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Titanian on April 12, 2017, 03:02:09 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on April 12, 2017, 03:24:36 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on April 13, 2017, 03:09:07 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on April 13, 2017, 03:24:20 AM
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.

Some things to consider though (including changes from the 7.2 change log):

- Your going to be able to increase capacity of maintenance facilities via techs now, x2 capacity from a 16000 RP tech should half their cost per capacity.
- Maintenance facilities also can be used to produce MSP, and will be 3 times more efficient at this then factories. Since MSP cost now will be more expensive and important since they represent all upkeep costs as well, your going to have to build them anyways if you don't want to dedicate part of your other industry to just building MSP.
- MSPs also will be used for other things such as repairing Titans, and are no longer received for free when ships are created.
- If Maintenance facilities still end up unreasonably expensive for what they do I think their cost will very likely be balanced/tweaked.


http://aurora2.pentarch.org/index.php?topic=8151.msg84277#msg84277
Title: Re: C# Aurora Changes Discussion
Post by: TCD on April 13, 2017, 10:04:31 AM
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.
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. 

(I also seem to remember a discussion with Steve around orbital infrastructure where he suggested that TN ships may not able to land on planets with gravity wells, which would rule out most hangar PDC cases)
Title: Re: C# Aurora Changes Discussion
Post by: Yearly reports please on April 20, 2017, 04:57:20 AM
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.

The report could contain:
Finance
Construction (Factories built etc)
Minerals mined/consumed
Fuel harvested/consumed
Ordnance
Shipbuilding
Research
Military losses
Colonization
Population growth

You get the idea.
If the game could save every year: Super!
10 years: great! 5 years: good!

This would make it feel even more like you were in control of the Empire.  Making 5 year plans etc.
And give you a good overview what the next 5 years should focus on.
Title: Re: C# Aurora Changes Discussion
Post by: JacenHan on April 20, 2017, 04:14:47 PM
That sounds like a really cool idea. I would probably prefer it to be toggle-able, and ideally, adjustable. It would also be nice if it showed the change from the last report/beginning of the game (whichever is relevant, or possibly both), to help track how much progress you've made.
Title: Re: C# Aurora Changes Discussion
Post by: MJOne on April 21, 2017, 04:11:03 AM
Thank you for feedback.  Yes toggleable was in my mind as well.
The great thing about this is that if we could have same or more simplified tracked data on the AI after creation of them and tie that to the Intelligence aspect of the game, to track their progress as well.  With factors that affect the accuracy of those reports.  The Arms race is on! 😉
Title: Re: C# Aurora Changes Discussion
Post by: Retropunch on May 05, 2017, 01:42:14 PM
Quote from: Yearly reports please link=topic=8497. msg102432#msg102432 date=1492682240
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. 

That's a really good idea - I find it sometimes difficult to know how well I've been doing from an economic stand point - especially if I'm playing a long and slow game; sometimes it can be ages till I actually realise I've been doing poorly. 

A yearly status report somewhere would be great - I'd hide it behind a button that would bring up the last report when pressed.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on May 08, 2017, 10:20:06 AM
Apologies for the lack of updates in a while. Work and home life has taken me away from Aurora for a few weeks (and also reading all nine Safehold books in a row :)). I should be back programming this week though.
Title: Re: C# Aurora Changes Discussion
Post by: OJsDad on May 08, 2017, 10:58:47 AM
(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. 
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on May 08, 2017, 03:45:49 PM
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.

Yes, completed all nine. Looking forward to the next one.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on May 08, 2017, 08:00:12 PM
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)
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on May 09, 2017, 02:08:02 AM
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)

Just finished the last book myself although been reading them over the course of a couple of years rather than a couple of weeks! After all that work the end did appear to be somewhat rushed to me. I think at the very end Weber does say he will have more stories for the main character to come so will be keeping an eye. Now if only Jonathan Lumpkin would finish his series.
Title: Re: C# Aurora Changes Discussion
Post by: hubgbf on May 09, 2017, 10:36:18 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on May 09, 2017, 11:42:54 AM
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

Not saying he won't link them, but the technologies in both universes are too dissimilar. That said, I would like to see more Dahak stories. And the Excalibur setting. And Apocalypse Troll. And even the space vampires...

frakk you Weber! Write more dammit!
Title: Re: C# Aurora Changes Discussion
Post by: OJsDad on May 09, 2017, 08:35:57 PM

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
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on May 10, 2017, 12:36:15 AM
Read this little story that Weber wrote, if you haven't already.   

http://forums.davidweber.net/viewtopic.php?f=7&t=4078&hilit=dahak

He missed Apocalypse Troll, Excalibur, Out of the Dark, and the March series in that.
Title: Re: C# Aurora Changes Discussion
Post by: bean on May 10, 2017, 09:49:38 AM
(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.
 ;D
Title: Re: C# Aurora Changes Discussion
Post by: hubgbf on May 11, 2017, 10:43:47 AM
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)
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on May 12, 2017, 06:06:15 PM
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)

I'd say Safehold tech is closer to the Honorverse tech than Dahak. Or possibly the Apocalypse Troll.

As for Safehold being the seed of the first Imperium, that couldn't be since Safeholdians originated on Terra.

One thing I do dislike about Weber is his tendency to leave things open, and then not continue on.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on May 15, 2017, 02:29:29 AM
So, the new changes to engines are now in. I rather like them, especially for reduced missile range AND reduced efficiency of size 1-10 ship engines. It really encourages having bigger engines for bigger ships and I think that's nice.

I actually kind of hope we will see something similar for reactors to be honest. I dislike the (common) usage of size 1 reactors on ships. There's basically zero disadvantages, and it reduces explosion damage if a reactor is hit. I'd really like something to discourage what I consider an exploit.

I think a case can be made for the fact that, like with engines, bigger reactors have higher efficiency, and so a higher energy output per unit of volume. This would basically solve the problem by itself, in my opinion.
Title: Re: C# Aurora Changes Discussion
Post by: Bughunter on May 15, 2017, 03:16:38 AM
I think the idea is good, but it sounds like it would also hurt small fighter/FAC beam ships.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on May 15, 2017, 03:18:11 AM
Engine changes look good for the most part. My main concern is that, with fuel efficiency now mattering for missiles, power multiplier tech becomes even less useful compared to engine type.

Generally, "balanced" research and shipbuilding becomes much weaker in the new version, inefficiencies are punished much harder. One underlying principle will be: Ignore fuel logistics as completely as you can, ruthlessly optimise for low fuel consumption instead.
The presence of the various logistics-related techs will be a trap for players who don't fully understand the mechanics.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on May 15, 2017, 07:57:40 AM
I disagree - we can't know for sure until someone crunches the numbers and even then, it depends on your empire and fleet size.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on May 15, 2017, 08:53:58 AM
Engine changes look good, I just think will need to consider impact on a couple of areas:

- How hits to kill is calculated to prevent massive engines on ships becoming very effective damage soaks, especially against mesons etc.

- 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.

- Maintenance costs and repair costs may also need a look at. Can see ships needing some very large engineering sections or additional maintenance bays to cover the off chance of a failure. Could we have different grades of failure such that only a major one needed the full repair?

Finally with the change in fuel need any chance of having a look at drop tanks for fighters and use of external pylons instead of box launchers? In both cases would think that having a mechanic that allows the reported mass of the fighter to reduce once missiles fired or tanks dropped would have a positive impact on range and give some options on fuel v striking power.
Title: Re: C# Aurora Changes Discussion
Post by: Titanian on May 15, 2017, 08:58:55 AM
- 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.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on May 15, 2017, 09:46:43 AM
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 did, and it doesn't.

*

Something else to consider:
If engine cost and HTK scaling remain as they are, huge low-power engines will become ridiculously efficient damage sinks. 5BP for 200HTK? Feel free to shoot your magazines dry against targets that consist almost entirely of these.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on May 15, 2017, 10:15:15 AM
I heartily approve of the missile part of the change. By and large, the only thing missile range matters is against other missiles (does it really matter if your missiles are 300mkm against their 200mkm instead of 150mkm against their 100mkm?), so it's not as big a change as it looks, and the overall reduction in missile ranges will make for interesting design considerations.

The changes for larger engines are interesting as well. It's going to majorly shift up my design philosophy (I usually design warships around max size engines) and promotes building very large warships. It also makes redundancy vs fuel efficiency a big consideration; a ship with one big engine will be more fuel efficient, but also be vulnerable to losing that engine.

Fighters do suffer a bit, but less than missiles; looks to me like fighters will be seeing about double fuel use compared to missiles quintupling. Combined with the sensor change I could see this turning missile fighters into a major tactical advantage.
Title: Re: C# Aurora Changes Discussion
Post by: Michael Sandy on May 15, 2017, 03:54:54 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on May 15, 2017, 05:50:20 PM
Regarding the problem of huge engines becoming damage sinks, it may be necessary to give diminishing returns on HTK as engines grow larger. Or to give engines a similar stat like what magazines have to boost their HTK.

Actually, although I understand it'd likely be too much of a bother, I'd like the ability to define an 'inner' and an 'outer' armour belt, and define per part type what is inside and what's outside. It'd make all or nothing armour schemes possible, with the bridge, magazines, engines and powerplants inside the inner armour belt, everything else outside the inner armour belt, and maybe thin armour protecting the outside. But then you'd need to figure out how to handle HTK in the outside layer.
Title: Re: C# Aurora Changes Discussion
Post by: Gyrfalcon on May 16, 2017, 01:18:41 AM
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.

That's actually what I'm wondering about. Given the (massive) increased fuel cost of small engines compared to the old system, are fighters even viable any longer? Or are you just better off using multi-stage missiles instead of carriers?
Title: Re: C# Aurora Changes Discussion
Post by: Michael Sandy on May 16, 2017, 01:44:20 AM
I think that for small fighters and ships to be viable with the new engine paradigm, DETECTION issues would have to greatly favor small fighters and ships.

If larger sensors only increase range as the square root of their power, small sensor footprint can be more advantageous.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on May 16, 2017, 04:13:37 AM
I'm fairly sure missile fghters will remain viable, but we may be pushed in a direction where they are slower than capital ships, and live and die by being too small for enemy sensors.

Fast beam fighters will be hit harder. Even in the present version, I usually prefer full-sized warships... maybe hangar-based and with 3 days of mission life, but still full-sized. Sensor footprint matters less if you need to close to beam range. In the next version, the fuel savings over fighters will be considerable.

I see a moderate conceptual shift: Compared to ships, we're encouraged to think of fighters as boats rather than aircraft.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on May 17, 2017, 01:06:05 AM
Fighters are taking a comparatively smaller hit than missiles, so if anything I think they might come out of this better than before. From a tactics point of view fighters are really more weapons systems like missiles than independent warships.

Missile fighters: Missile range (assuming the same fuel) is getting reduced by a factor of 4-5. Fighters are losing about half their range. So missile fighters will be even better at their current role, allowing missile strikes far beyond normal missile range. As for the actual mechanics of whether missile fighters can salvo without return fire, that will continue to be more dependent on sensor range than missile range, so this change probably wont alter the equation in either direction.

Beam fighters: In my experience, beam fighters' biggest weakness is enemy AMMs. This change is going to greatly reduce the range of AMMs, allowing beam fighters to close and engage much easier. The reduction in missile range will also mean their carriers are in less danger from enemy missiles. I don't know if this will make beam fighters actually excel, but I don't think it will hurt them.

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. Maybe it's time to dust off my idea for parasite warships that remain in hangers until battle starts :)
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on May 17, 2017, 05:05:19 AM
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.

The difference from engine size isn't actually THAT huge.

If you look at the max size engine it's 20k ton so assumes a 40-80k capital ship ton (depending on engine % tonnage you want). If we go with something average like 60k ton then we have a 120 times larger ship consuming slightly less then 10 times less fuel per ton ( then your 500 ton fighter with 250 ton engine will at same power modifier ).

So in the end our capital ship is consuming 12 times more fuel with the new max size engine compared to a normal fighter do.


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.



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.

This is actually the main reason I suggested to update the formula in the first place. To get more trade-offs into design of small ship / fighter engines. That it also lower missile ranges a bit and allows bigger engine are just nice bonuses.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on May 17, 2017, 05:58:56 AM
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.

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.

Maybe it's time to dust off my idea for parasite warships that remain in hangers until battle starts :)

Agreed. They're already attractive, and the mechanics changes will encourage fuel-hungry designs to be as large as practical (fuel economy changes, but other logistics changes may also play into this... 50 FACs will no longer be easier to maintain away from an empire's core than 5 warships).

If the original rationale for fast fighters on carriers was to extend range and save fuel on strategic movement... does this still exist when building a fast warship instead will reduce fuel use to 20% while retaining the high speed on the strategic level and eliminating the overhead for the carrier?
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on May 17, 2017, 06:53:03 AM
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.

IMO The 3 main mechanics which encourage "realistic" design here is cost, research cost and explosion chance.




What mechanics is it that you think promote using fighters for long endurance missions and capital ships for short ones?
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on May 17, 2017, 10:28:52 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on May 17, 2017, 11:48:14 AM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on May 17, 2017, 12:55:15 PM
@ alex_brunius:
In response to your points...

Cost: If we replace a 10000t fighter strike group with a 10000t warship of the same speed, total engine cost won't increase. Going bigger would allow installing all sorts of fluff, but as a direct replacement for the fighters it could be just as lean.

Research Cost: Size 400 may well be excessive, and that's quite an advanced tech anyway. But cutting down fuel use of the current generation by 2/3 (for which size-40 would be sufficient compared to fighter-sized engines) may be worth the expenditure. Fighters may also be forced to use excessively compact engines (requiring higher multiplier tech) to remain within 500t where warships can freely trade a little tonnage efficiency for considerably better fuel efficiency.

Explosion chance: Agreed somewhat, and there are other matters of redundancy - where a larger ship makes better use of passive defences, tiny ships make the opponent waste firepower on overkill.

*

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.
Title: Re: C# Aurora Changes Discussion
Post by: Camilo on May 17, 2017, 03:40:01 PM
Hi,

If we want to avoid the posibility of having big fighters, there could be a rule where hangars don´t just add in size.  A 1000 ton hangar can only carry 1000 tons of ships.  A ship with 2 1000 ton hangars can not carry a 1500 ton ship, it can carry 4 500 ton ships, 10 250 ton ships, 2 750 ton ships or 2 1000 ton ships.

We could have techs for biger and biger hangars with biger hangars being more efficient in their space cost.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on May 17, 2017, 11:38:25 PM
Steve, if I may pitch a small request/suggestion:
Could the population cap on tidally locked planets be turned into a soft cap? Specifically, even if it is colony cost 0 at the time, allow population above the limit with a slow-exponential growth on infrastructure cost.
This would emulate the fact that infrastructure could be built outside of the "safe zone" band around the planet, just at reduced efficiency. The temperature the folks living there would suffer would be minor atmospheric hazards compared to living on a voided atmosphere planet, I imagine, or on venus.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on May 17, 2017, 11:47:30 PM
Hey Steve, I had a good idea for how to solve the problem of civilian shipping taking obnoxious amounts of processing power for large empires.

Abstract the individual ships away.  Not completely, of course, but they don't need to be tracked perfectly 100% of the time.

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.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on May 18, 2017, 12:18:44 AM
Abstract the individual ships away.  Not completely, of course, but they don't need to be tracked perfectly 100% of the time.

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.
This abstraction becomes a problem for multiple player controlled lines, especially when the hostile nation has a DSTS anywhere in the system.
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.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on May 18, 2017, 12:45:07 AM
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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on May 18, 2017, 05:49:43 AM
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.

If you replace the entire Carrier wing with a single big ship instead you could save maybe 5% of the tonnage in fuel and thus increase performance or mission tonnage by around 10-15%, but is the increased risk in explosion chance, vulnerability and loss of stealth really worth this? I can't see how it can be the way I operate my Carriers at least.


Also remember that small size not only gives you the advantage of harder detection, but also making it much harder for enemy missile systems to lock on. A single massive ship will be targetable from significantly further away by most ASM systems then the small 250-500 ton fighters will, and thus need to achieve a range advantage in both ASM sensors, FC and missile range as well, which proper missile fighters don't need to worry about any off since they sneak in below the resolution of all ASM systems.
Title: Re: C# Aurora Changes Discussion
Post by: Silvarelion on May 18, 2017, 09:43:57 AM
If I may be so bold as to add an example to the discussion between @alex_brunius and @Iranon , attached is an abstraction I did of a heavy fighter fleet (of 16.6 ships) and a scaled up version of the same ship (16.6 times larger than the fighters). 16.6 was to keep the engine size ratios the same.  These are all using the numbers in 7.1. As you can see, the ship, with size 50 engines, has twice the range of the fighters. My understanding is that the fighter range will drop by about half in C#, meaning this ship is likely to have 4 times the range of the fighter fleet. This comparison should become even more extreme at larger engine sizes.


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.

Even with such small fuel ratios, the fleet-wide fuel savings are nothing to scoff at, and would require a distinct advantage to offset it.  For missile fighters, their near invisibility, salvo dispersion, increased missile performance and increased strike flexibility are viable, in my opinion, and a doctrine I have used in the past, and probably will again in the future.

Sensor footprint isn't a major option if we need to cross the AMM envelope.

To echo @Iranon, any beam fighter fleet I have created all end up chewed up once they cross the AMM envelope. In the case of beam ships, it seems like the extra survivability of a larger ship more than makes up for the damage dispersion (leading to overkill) of a fighter fleet. A larger ship also gives you much more flexibility on weapons loadout and doctrine (alpha strike vs sustained fire). Throw the fuel savings of a larger engine on top of that, and this becomes a viable strategy, one that I am using in my current game.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on May 18, 2017, 12:48:24 PM
Using larger beam gunships instead of fighters makes them less vulnerable to AMMs (though not by as much as you'd think), but it makes them more vulnerable to ASMs, because of overkill, longer detection ranges, and engine explosions.

Considering the reduced range of AMMs we'll probably see in this expansion, I think having parasites be very inefficient targets for ASMs may be worth the increased vulnerability to AMMs.
Title: Re: C# Aurora Changes Discussion
Post by: Silvarelion on May 18, 2017, 12:58:16 PM
For myself, anyways, I wouldn't get into beam range without first drawing out as many ASMs as I could. Certainly that kind of passive missile defense does have value, though.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on May 18, 2017, 01:02:33 PM
This abstraction becomes a problem for multiple player controlled lines, especially when the hostile nation has a DSTS anywhere in the system.
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.
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.

You can still defend your shipping lines because you'll know where the shipping lanes are.  Sure you can't do convoys, but you already can't with civilian shipping; there's no way to coordinate with them.

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.
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.
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.

But if C# does make all this discussion moot, that's fine with me too.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on May 18, 2017, 03:47:31 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on May 18, 2017, 05:03:28 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on May 18, 2017, 05:10:38 PM
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.

Stop reading my mind and stealing my suggestions while I am busy writing them  :P j/k ( although I was going to suggest 10% of normal speed for return home for free without fuel ).

Similar might be possible to do for supplies, not have the catastrophic ships blowing up when they fail but still have the cost and some penalty/punishment which the AI can handle better.

Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on May 18, 2017, 11:29:51 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: MagusXIX on May 19, 2017, 08:24:21 AM
Re: Abstracted shipping lines.

As long as commerce raiding remains fun and strategically viable. Commerce raiding is super important to me, as one of my favorite things to do in Aurora is attempt to recreate WW2 era submarines, but in space. Hell, if you can manage to make commerce raiding even more fun and viable by abstracting shipping lines, that'd be even better. So long as I can still make space submarines and they're actually useful.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on May 19, 2017, 02:14:11 PM
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?

With the rest as in the current version, I'd use them. For cheap bulky ships, the lowered crew requirements are a significant upside over similar lasers now that we don't pay twice as much for the weapon. We also get large calibres for very modest research effort.
Cheap bulky ships may be hurt considerably by the maintenance changes though, as they now clog up valuable infrastructure no matter how cheap they are to build or maintain.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on May 19, 2017, 07:56:37 PM
They already work fairly well as cheap low-tech JP defence ship weaponry and will work better in C# Aurora in that role. Slow-speed monitors with little armour and a ton of carronades will form a cheap but effective JP defence in early game. I don't care if they become useless in late game - not all weapons need to be optimised to be equally useful (or at all useful) through the game. Having your fleets weaponry evolve through time is a great concept as well.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on May 19, 2017, 10:02:34 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on May 20, 2017, 03:25:25 AM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on May 20, 2017, 05:09:48 AM
On fast ships, I want weapons that are good ton for ton rather than cheap (since moving bulk around at high speed is expensive, both in BP for engines and fuel). On fast ships I want weapons that potentially allows me to outrange opponents, but which are also good enough at short range if I can't... this applies to carronades, but imo mid-sized lasers with decent wavelength tech fit the bill better if we don't care for component cost.

Where I like carronades or large calibre but otherwise low-tech lasers is as part of slow, cheap fleet consisting mainly of anti-missile barges. For cheap, they give respectable range (I can now kite tech-inferior opponents to death despite being slow by my standards, and I can respond against faster enemies. Damage at range will be poor, but I have cheap bulky components to tank hits... may work out overall) and serious point blank firepower (useful for an alpha strike against a homeworld, or defensively in a balanced fleet: if the opponent stays away I'm happy, if they come to play they get a big ball of plasma shoved up their exhaust). Railgun flak barges with a few carronade ships to discourage beam attackers aren't very capable for their tonnage, but they're competitive by cost and excellent garrison fleets (very good PPV by cost).
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on May 20, 2017, 06:26:54 AM
I must join my voice in saying I don't like the idea of abstracted civilian shippings.

It seems cumbersome to me, not clear, and it would probably reduce a lot the cat and mouse game I practice against the ai (and the need to defend my own shipping).

Also, it's just a little bit too convenient. And likely also difficult to model in a game that makes sense.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on May 20, 2017, 07:16:16 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on May 20, 2017, 07:19:41 AM
Glad to hear it. A major strength of Aurora is that it simulates many things in a consistent manner and has gameplay elements emerge around that, instead of abstracting things away.
Title: Re: C# Aurora Changes Discussion
Post by: MagusXIX on May 20, 2017, 01:18:18 PM
If anything, in future updates I'd say shipping should be made even more important and even more vulnerable. Because Aurora uses a jumpgate system, trade/shipping is by default quite safe. In the current system, if you want to put together a task force specifically for trade interdiction you need to sneak them through jump point pickets, which is a real nightmare unless you seriously out-tech your opponent or they don't know how to properly monitor jump points. As most intelligent opponents will have pickets monitoring their most critical systems, the only cargo/transport/fuel ships you're ever likely to catch are the unimportant ones going to out-of-the-way locations.

Don't get me wrong, the logistics game in Aurora is pretty damn fun. Still, it really could use some tweaking. More critical trade goods would be a good introduction, imo. Like, if that mining colony doesn't get its food shipment, it's liable to start starving. That kind of thing. Introducing an alternative means of travel to jump points sounds good, too, although I'm not sure how doable it is. There are several games out these days that offer multiple means of FTL travel (gates, warp drives, wormhole generation, etc.) That ship may have already sailed for Aurora, though.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on May 20, 2017, 03:17:37 PM
Thank you very much, Steve, for the power generator changes. I love them.

It never made any sense to me that power production was completely linear irrespective of generator size, and it was a thing that encouraged mass spamming of size 1 generators in order to limit possible explosions.

Also, this change makes energy weapons slightly better because of more efficient tonnage usage. In my book, it's all good :)
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on May 20, 2017, 10:06:31 PM
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.

Standard transit does disable sensors and fire controls (not sure about shields), but it doesn't disable engines. So a ship that transits can (and in almost all cases, will) be departing the jump point at maximum speed before you can fire on it.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on May 21, 2017, 08:14:14 AM
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.

I think the current model works decently enough. Where I would like to see some more options is in government taxation and missions.

For example be able to temporary tax shipping lines heavier so their growth stagnate or they even are forced to sell off ships to not go into bankrupcy, or lower taxes to promote their long term growth.

Or maybe exempt new colonies from shipping tax to promote more shipping traffic.

Another mission Id like to see is the ability to "balance minerals" between two colonies or ship all minerals using civilians. For missions it could also be cool to be able to set higher rewards and have civilian shipping prioritize what runs will make them the most money.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on May 21, 2017, 08:51:39 AM
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.

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?
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on May 21, 2017, 10:04:46 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on May 21, 2017, 11:31:19 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on May 21, 2017, 11:38:58 AM
Mainly fuel efficiency and maintenance efficiency, really.
Though, a Hangar stocked Battlewagen with good maintenance life to hold faster combat ships sounds like a good way to picket jump points, at least. Many folks just like slow monitors though due to the fact they can focus most of their build points on raw firepower.
Title: Re: C# Aurora Changes Discussion
Post by: bean on May 23, 2017, 01:19:25 PM
The scaling for the power plants seems a bit steep, although I very much like the basic idea.  Having the power/size scale by a factor of 2 over a factor of 4 in size is a lot.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on May 24, 2017, 01:04:26 AM
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.

I wonder if the power plant changes are enough to make custom-tailoring reactors to each ship.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on May 24, 2017, 10:18:25 PM
If its possible, can we please have an option to have civilian shipping carry minerals?

It's odd to me that they can't carry everything player-owned ships can.
Title: Re: C# Aurora Changes Discussion
Post by: mrwigggles on May 25, 2017, 05:57:12 PM
Its probably more of an AI problem and maybe it was also a proformance consideration. Though yes, having them be able to move minerals would be grand.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on May 25, 2017, 06:55:21 PM
I was thinking just use the contract system.  If I can have them move automated mines for me, why not the products of those mines?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on May 27, 2017, 06:34:33 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on May 27, 2017, 06:43:43 AM
Keep things consistent by default, add the 5x fuel consumption multiplier for engines boosted to more than your usual power multiplier (since those are pushed to something beyond reasonable by your current tech).

This has the added benefit of keeping the power multiplier tech line competitive (already easy to shoot onself in the foot by investing in it too much in VB6; that will become much more punishing).
Title: Re: C# Aurora Changes Discussion
Post by: MagusXIX on May 27, 2017, 09:24:21 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on May 27, 2017, 09:31:43 AM
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.


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?

My opinion is that missiles do need to be "shorter range" than before. Fuel cannot be irrelevant as it was before. The new fuel formula should have solved that, but now you have found out this bit of code you did not remember about.

Personally, I would still keep the x5 modifier. I think it's a much needed modifier, for gameplay balance reason between the various weapons. I can understand some might not like that, but there's a lot of other arbitrary choices that were made in this game obviously.

I do think that "make fuel a serious consideration for missiles" is a valid and reasonable thing to do. Because it IS so in real life as well, so I don't see why fuel should be irrelevant in Aurora.
Iranon's proposed solution would only work (somewhat) at low tech level, and would be not relevant anymore afterwards. So I would keep the x5 modifier.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on May 27, 2017, 09:41:57 AM
snipped

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.
Title: Re: C# Aurora Changes Discussion
Post by: MagusXIX on May 27, 2017, 09:46:40 AM
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.)

Go ahead and make them less fuel efficient. Give'em less oomph per ton, as well, and make them cost more. I feel like the warhead should be the smallest part of any serious missile (excluding whatever whackjob thingamabob people are building in their basements) and the bulk of it should be taken up by engines (including agility) and fuel, where fuel and efficiency should be the most major design considerations.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on May 27, 2017, 10:10:36 AM
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?

The HS40 shield is 200% percent stronger per HS, so it is eight times stronger than the HS10 shield in total. If both have the same recharge technology, the HS40 will take twice as long to recharge as the HS10.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on May 27, 2017, 10:12:16 AM
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.

The recharge amount per HS is the same for both the 4x 10HS and the 1x 40HS. However, because the latter has twice the total strength, it takes twice as long to fully recharge.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on May 27, 2017, 02:17:51 PM
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?
Code: [Select]
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

Code: [Select]
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.
Hmm.
I don't suppose we can use the complexity of the situation to kick the 5 lightsecond limit of beams and make them superluminal weapons, eh?
It's a bit tricky figuring, yeah.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on May 27, 2017, 05:17:20 PM
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?

The most consistent way to handle this IMO is to remove the flat x5 modifier and replace it with a dynamic modifier based on engine power modifier instead (basically tweak engine power mod formula), scaled in such a way that at maximum power modifier (x6 which can only be reached by missile engines), they consume roughly x5 as much fuel.

This also means that fighters and other high power mod warship engines become more fuel hungry, which IMHO also is desired to get the right feeling ( real world fighters have upwards to 50% of their carried tonnage as fuel, while aurora fighters get by with 5-10% ). And I think it works well with the changes to fuel logistics as well.

Another result of this is that you will be able to design slower larger missiles that are more fuel efficient, but when the missile engines start to become the same size as fighter engines are, what conceptual difference is there really between them?



Regarding the changes to shields, do you have plans to have shield recharge require power from reactors now instead of fuel?

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.

As far as I understand Shields will have identical recharge rate, so using more smaller shields have no recharge bonus other then that they reach their lower maximum faster. In terms of absolute points of damage recharged it's identical, so your not losing performance.



Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on May 27, 2017, 05:24:24 PM
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.)

They are not anywhere near 1/1000th size, so I think your comparison fails here.

In fact our Aurora standard missile engine of 2-3 MSP have much more in common with a 50 ton (=20MSP) fighter engine, then that same fighter engine has in common with a 2500 ton capital ship engine. ( Actually if fighter engine design was a bit more flexible I could even see use for even smaller 10-20 ton fighter engines for really small single seat fighters having pretty much identical size to some missile engines ).

If missile engines should play by different rules then fighter engines do, then why should fighter engines play by the same rules that capital ship engines do? It makes no sense.



Most of what your asking for like more expensive and less efficient is also already handled by the power modifier scaling ( which makes boosted engines significantly more expensive and significantly less effective ).
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on May 27, 2017, 05:30:52 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on May 27, 2017, 10:36:49 PM
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?

If missile efficiency remains mostly the same, it seems like the result will be that missiles can easily have extremely long range but will be primarily range limited by sensors and fire controls, since very large sensors are getting a range reduction. In some ways this is quite interesting; it opens up the possibility of using detached sensor ships as spotters for your missile launchers (and interceptor craft to shoot down the enemy spotters).
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on May 28, 2017, 01:29:41 AM
I don't like the idea of artificially adding in an extra multiplier to missiles, but Honestly i think missile ranges are far too long and if making an arbitrary change results in an improvement  to gameplay I'm all for it.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Alucard on May 28, 2017, 04:29:45 AM
Quote from: Steve Walmsley link=topic=8497.  msg102771#msg102771 date=1495884873
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 would personally make small efficient missile engines very expensive.   Than a person would have to chose whether to pay an order of magnitude more for their missiles or reduced the engine efficiency. 

EDIT: As cost, I mean mainly time to produce.  That make sense as miniaturizing efficiently is complicated.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on May 28, 2017, 05:36:30 AM
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.

I think this suggestion will fix the issue. They key part here is: "by how much it's beyond your safe long term engine boost tech". Rather than linking additional missile engine fuel consumption to the absolute boost amount, it should be based on the boost amount beyond the current max tech for ship engines.

This allows complete consistency between ship and missile engines in the spectrum where they both operate. Once you move outside of the boost range possible for ships, additional fuel consumption can be added without breaking consistency.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on May 28, 2017, 06:50:29 AM
With the above in mind, I have added the following to the missile engine fuel efficiency calculation

if Boost Used > Max Boost Multiplier Tech then
      High Boost Modifier = (((Boost Used - Max Boost Multiplier Tech ) / Max Boost Multiplier Tech) * 4) + 1;

So if a race has Max Boost Tech of 2x, any missile with a Boost Level of 2x or less will use the standard boost fuel modifier calculation of Boost Level ^ 2.5.

Above a Boost Level of 2x, the linear High Boost Modifier will come into effect, reaching a maximum of 5x fuel consumption at 4x Boost Level.

Here is a comparison between VB6 and C# using MPD engines and an engine size of 1 MSP. The Max Boost Tech for this race is 2x:


VB6 Missile Engine with 2x Boost
Engine Power: 1.6      Fuel Use Per Hour: 81.51 Litres
Fuel Consumption per Engine Power Hour: 50.944 Litres
Engine Size: 1 MSP      Cost: 0.4
Thermal Signature: 1.6
Materials Required: 0.4x Gallicite
Development Cost for Project: 80RP

C# Missile Engine with 2x Boost
Engine Power 1.60      Fuel Use Per Hour 76.8 Litres
Fuel Consumption per Engine Power Hour 48.0 Litres
Size 1.00 MSP  (2.5 tons)      Cost 0.80
Development Cost 80 RP

Materials Required
Gallicite  0.80


VB6 Missile Engine with 4x Boost
Engine Power: 3.2      Fuel Use Per Hour: 922.18 Litres
Fuel Consumption per Engine Power Hour: 288.182 Litres
Engine Size: 1 MSP      Cost: 0.8
Thermal Signature: 3.2
Materials Required: 0.8x Gallicite
Development Cost for Project: 160RP

C# Missile Engine with 4x Boost
Engine Power 3.20      Fuel Use Per Hour 4344.5 Litres
Fuel Consumption per Engine Power Hour 1357.6 Litres
Size 1.00 MSP  (2.5 tons)      Cost 1.60
Development Cost 160 RP

Materials Required
Gallicite  1.60

Title: Re: C# Aurora Changes Discussion
Post by: Iranon on May 28, 2017, 06:53:49 AM
(actual power multiplier/Maximum Engine Power Multiplier tech)^2.5
or 1, whateve is smaller

would allow for a smooth progression and cap out at an additional x5.66 at maximum boost.

The only problem I see is that it increases an inherent property of Aurora propulsion scaling that I find slightly unintuitive: Even with high-power engines, the performance-optimum will be a relatively large engine and a comparatively small fuel load, as opposed to pretty much any real-life high-power engine.


EDIT: Oops, ninja'd by the man himself (sorry, slight forum weirdness).
Sounds good.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on May 28, 2017, 07:47:46 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on May 28, 2017, 10:01:30 AM
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.

It will definitely still be possible to design extremely long range missiles. The question is more do you design missiles with very long range but that need a spotter craft closer to the enemy (and disproportionately large fire controls, but since FCs have triple the range of an equivalent sensor it's doable), or do you design a missile that has range more equivalent to your internal sensors but better performance?

Actually, that raises a question about FCs. In VB6 Aurora missile fire controls have a range three times that of the equivalent sensor, but that's because sensor range scales linearly to sensor size (IE, FCs are one third the size a sensor would be). In C# sensor range no longer scales linearly, so one assumes FCs will have a shorter range increase. Might make my idea of spotter craft less practical.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on May 28, 2017, 10:08:41 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: swarm_sadist on May 28, 2017, 08:27:49 PM
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.  :'(
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on May 29, 2017, 02:33:30 AM
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.  :'(

I have to agree that something like hyperdrive would really be welcome. A lot of distant companions in binary or trinary systems ends up completely unusable. I understand however that hypperdrive was flawed, so I imagine it would have to be re-done entirely...

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.

Yes you see, my problem with long range missiles is that in VB6 Aurora you could do what I consider to be unbalanced missile designs. I am all for the concept of tradeoffs in performance, and I believe it was not so before. And I worry it will not be so in C# Aurora if range stays the same.

Where engines are concerned, a missile basically has three parameters. Speed, range and size (of the engine and of the fuel carried by the missile). Obviously, speed and range are dependent on tech level. A missile that is considered "fast" in the ion era is different from one which is "fast" in the confinement fusion era, and same is true for range depending on technology.
I consider warhead strength and agility to be not really relevant to this, because they are quite independent from missile engine considerations.

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)

I believe the game would benefit a lot from something like this, instead of having the generalist missile which is good at everything like you could do in VB6 Aurora. And in order to do this, missile fuel HAS to be more relevant than it was in VB6 Aurora.
However, unless you boost speed very much it seems to me that range will stay more or less the same as before.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on May 29, 2017, 04:20:29 AM
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)

If you look at the C# Aurora Missile Engine fuel consumption by size values a small missile (0.5 MSP engine) would have a fuel consumption of over 3 times as much fuel as a very large missile engine, thus cutting it range down to less then 1/3:ed.

While not massive cutting your range to a third is still a clearly noticeable trade off.


And if you look at higher levels of engine boost (above 3) then you can throw efficiency (and range) out of the window totally. Choosing between fast missile or long range missile worked great in VB6 Aurora, and will work even better in C# Aurora with the x5 extra consumption being applied only on consumption above "safe" maximum.

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...

That is a massive trade off, don't you agree?


However, unless you boost speed very much it seems to me that range will stay more or less the same as before.

A missile without speed is a worthless missile, easily shot down by AMM & Point Defense or even possible to outrun or dodge with faster ships or fighters.

It's a bit like arguing fuel is not a concern for warships using very low power commercial engines. Sure it isn't but those warships won't be very useful so there still is a trade off involved...
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on May 29, 2017, 11:17:19 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on May 29, 2017, 12:45:13 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on May 29, 2017, 12:50:15 PM
Quality-of-life suggestion here:

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.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on May 29, 2017, 12:52:02 PM
Quality-of-life suggestion here:

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.
Well, it's easy, really. Just treat the magazines as multiples of 20 per HS, reduced by tech level percentage.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on May 30, 2017, 12:40:29 AM
While we're at it upgraded armour type should reduce the weight per level of armour. That's really bugged me. Early component armour should be bulky and terrible.
Title: Re: C# Aurora Changes Discussion
Post by: Gyrfalcon on May 30, 2017, 01:24:49 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on May 30, 2017, 02:26:43 AM
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.

He is talking about armored components, not ship hulls.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on May 30, 2017, 02:56:03 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on May 30, 2017, 04:53:16 PM
AMMs should comfortably outrange beams of similar tech levels.

However, if we want them to be dual-purpose missiles or we invest in the sensor range for a wide anti-missile envelope (small and moderate sensors will be better at picking up missiles than before), we may not always go for the maximum possible boost.
IMO that's a good thing, opening up more viable design decisions.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on May 30, 2017, 05:43:16 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Silvarelion on May 30, 2017, 08:07:22 PM
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.

Where is this change? I don't think I've seen that announcement.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on May 31, 2017, 02:07:12 AM
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?

Sensors and fuel changes will hit both sides though, so even missile FAC/Fighters should need to have to approach closer to be able to fire as well.


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.

Yeah I think this option will be very interesting and useful when it comes to both creating hybrid AMM/Anti-FAC missiles with bigger warheads, or creating AMMs with same warhead but more fuel for bit longer range instead.

I'm all for changes which removes or lessen the impact of hard caps like size 1.0 AMMs being the standard that everyone uses and the only thing that works
Title: Re: C# Aurora Changes Discussion
Post by: bean on May 31, 2017, 09:45:29 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on May 31, 2017, 01:12:48 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on May 31, 2017, 01:48:13 PM
Missile sized engines are already being penalized in the new system, already, due to their size and the size penalty changes.

Not really.

With old model going from 5MSP engine to 0.5 MSP engine increase fuel consumption by x4.82. In new model it just increase fuel consumption by x3.16.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on May 31, 2017, 07:53:38 PM
Although missile engine designs and ship engine designs would differ, their main difference is in size, not function. 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. This is part of why the fuel consumption mechanic for missile engines was changed in Aurora C#; a flat increase in engine fuel consumption without any benefit makes no sense, especially when you've a one shot drive by definition where you can afford to squeeze a small amount of extra thrust out of the engine by trading in long term endurance and reliability.

If anything, that engine should be more efficient for its weight, either in power output or fuel consumption.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on June 01, 2017, 02:48:23 AM
Where is this change? I don't think I've seen that announcement.

Can't find it myself at the moment. Hopefully that wasn't just a dream, because I'd expect dreams about Aurora to be much more interesting.

Regarding box launchers and explosion chance:
That needs to be in the game, but we're getting too many techs that we can't do much with. I'd be in favour of simplifying while increasing choice:
for example, a single Ammunition Safety tech that allows us to make a tradeoff between compactness and safety at design time for magazines, that also affects box launchers.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on June 01, 2017, 02:17:44 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: TCD on June 02, 2017, 08:58:30 AM
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?

Presumably TH/EM sensors would have the minor advantage of not giving away your missiles position. Although I'm not sure how relevant that is with the exception of a surprise attack against an enemy without its own actives on? Does missile tracking time include passive as well as active tracking?
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on June 02, 2017, 09:24:05 AM
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).
Title: Re: C# Aurora Changes Discussion
Post by: serger on June 02, 2017, 12:15:26 PM
Well, plasma is not a gas technically, but Tsiolkovsky rocket equation doesn't mind if you tossing out plasma or very hot gas.
Title: Re: C# Aurora Changes Discussion
Post by: NihilRex on June 02, 2017, 07:01:38 PM
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...
Title: Re: C# Aurora Changes Discussion
Post by: Elouda on June 02, 2017, 07:30:12 PM
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).
Title: Re: C# Aurora Changes Discussion
Post by: NihilRex on June 02, 2017, 08:31:19 PM
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).

Well, we have no lore on how the launchers work,

If they are just vacuuming out exhaust gases and shoving in a new missile, a tube should be able to cycle rather quickly from a smaller missile.

If they are electromagnetic launchers, then it gets even easier, because the reloads can be waiting close by, and set on the rails quickly.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on June 02, 2017, 09:25:00 PM
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).
Um. Already ingame.
(https://cdn.discordapp.com/attachments/209085745166680065/320386898256199682/unknown.png)
Title: Re: C# Aurora Changes Discussion
Post by: Elouda on June 03, 2017, 01:51:44 AM
Um. Already ingame.
[image]
Except this requires you to launch all of them at once, instead of being able to fire them as desired.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on June 03, 2017, 05:31:07 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on June 03, 2017, 12:02:10 PM
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.

I think the point that was being made was that "riding the explosion" consists of letting "stuff" from the explosion hit the back of your thing-being-propulsed and letting it bounce off, transferring momentum to your thing-being-propulsed, which is morally equivalent to tossing things out the back of the thing-being-propulsed.

There is one subtlety here that might require a modification to the rocket equation : if the stuff being thrown out the back end is being thrown out at a relativistic velocity (e.g. is comprised of photons), then some of the assumptions in the classical derivation break down and you have to be careful with relativistic effects.  This might be dealt with here https://en.wikipedia.org/wiki/Relativistic_rocket (https://en.wikipedia.org/wiki/Relativistic_rocket), but I'm not sure if even that derivation deals with exhaust whose rest mass is zero (and whose velocity is the speed of light, i.e is comprised of photons). 

In any event, figuring out how to have all your fuel converted into photons all of which go straight out the back is going to be the most efficient rocket you can get, and that probably CAN be analyzed using the classic Tsiolkovsky equation using an "effective" V_exhaust  defined by delta_momentum_of_ship/delta_mass_used_to_get_that_delta_momentum.

[EDIT]  Now that I think of it, there's another aspect of efficiency:  in the photon drive case if you could arrange to consume all the fuel simultaneously then you could probably do better than the Tsiolkovsky equation, since you wouldn't be accelerating any of the fuel.  This would be hard to do in practice though. :) Also, "photon drive" gave me a better search term, so here's a discussion of the photon drive case: https://en.wikipedia.org/wiki/Photon_rocket (https://en.wikipedia.org/wiki/Photon_rocket)[/EDIT]

For chuckles and grins: I have a memory from my undergraduate days working in a relativity hydrodynamics group of someone saying "X has a saying that there's two kinds of stuff in the universe: gamma = 5/3 stuff (non-relativistic) and gamma = 4/3 stuff", where I don't remember who X is (but he was well known), and gamma is the adiabatic index.  What he meant was that when the temperature of a gas gets so high that the thermal energy is significantly higher than the rest energy (i.e. the thermal velocities are relativistic), then the thermodynamic properties change and you have to redo the derivation, BUT the difference can be absorbed into a generalization of the adiabatic index.  I suspect it's a similar effect for V_exhaust and the rocket equation.  For a better discussion of the relativistic adiabatic index, see the 1st and 2nd full paragraphs on page 4 here:
https://websites.pmc.ucsc.edu/~glatz/astr_112/lectures/notes6.pdf (https://websites.pmc.ucsc.edu/~glatz/astr_112/lectures/notes6.pdf)

John
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on June 03, 2017, 02:10:17 PM
Fair enough, though I don't think that's what was implied by the original post.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on June 03, 2017, 03:12:40 PM
@Steve Walmsley Hmm, quick question. Is there a rationale for railguns and plasma carronades having such a low tech cutoff compared to mesons, lasers, and particle beams?
Because at the max tech caps, the largest lasers are outright bigger than the largest carronades, and tailguns have a very low end point on it's tech tree.
Meanwhile a lot of the higher tech levels for mesons, particle beam range, etc are completely redundant and are significantly larger than the maximum fire control range in the whole game.
Title: Re: C# Aurora Changes Discussion
Post by: serger on June 03, 2017, 04:40:28 PM
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?..  :)
There is a momentum conservation law - you cannot change your momentum forward, if you don't toss smth back.
In a nuclear pulse propulsion drive you can have an open propulsion camera, but you still have absolutely the same principle: some part of propulsion mass must bump against your drive camera or reflector, and another part of propulsion mass will simply fly away without bumping at any of your ship hard part.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on June 03, 2017, 07:38:39 PM
@ 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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on June 03, 2017, 09:51:00 PM
@ 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.

Larger mesons have increased range, but not increased damage. There's some value there in planetary assault scenarios (where mesons can be fired both from and at planetary bases, if you're unable or unwilling to use missile bombardment) since if a ship based Meson outranges a planet based one you can pick apart planetary meson bases at will. Overall it's probably not a commonly used tech line, though.

I've often thought particle beams have a role in skirmisher type long range beam ships with shields, capable of absorbing long range beam fire while pounding their opponent with high damage at range. But the current supremacy of missile combat means I've never really tested them out.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on June 03, 2017, 11:15:22 PM
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?

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?
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on June 04, 2017, 12:02:06 AM
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?

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?
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on June 04, 2017, 01:03:16 AM
@ 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.
Hmm. Guess I was mistaken about the particle beams.
You're definitely right about the mesons though, as they max out on range far before the max size mesons are even close to useful.
That said, I would argue that railguns might have some use for alpha-strike purposes compared to lasers because of the extra damage per ton. Maybe if railguns were given size reduction tech, too?...
Still, that's no excuse to cut the max range tech on railguns, too, it's just not fair at that point.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on June 04, 2017, 01:15:29 AM
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?

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?
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.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on June 04, 2017, 12:10:26 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on June 04, 2017, 02:19:52 PM
Where do they stay if I build it in a shipyard?

In the ships crewquarters, which are added automatically?
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on June 04, 2017, 02:35:38 PM
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
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?

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.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on June 04, 2017, 06:26:19 PM
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
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?

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.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on June 04, 2017, 08:11:53 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on June 04, 2017, 10:10:51 PM
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?

If I were taking a stab at a realism reason, I'd say that most ships needed a shipyard for logistic reasons, but with an orbital habitat they effectively used the habitat itself as the logistical hub, making the habitat basically the shipyard itself.

Gameplay wise, it's because if you didn't then no one would use shipyards.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on June 04, 2017, 11:44:18 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Detros on June 05, 2017, 03:49:38 AM
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.
If you were using factories so that you don't have to retool shipyards too often use an expensive template class as the core.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on June 05, 2017, 04:09:32 AM
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
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?

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.
"Intended deployment time 3 months"

A habitat likely includes more facilities than would be included on a ship.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on June 05, 2017, 05:49:31 AM
Honestly, the cost difference wouldn't be such a big deal anyway if the habitats were just made with a lot more modules to justify it. Run 5 or 10 terraformers in the ship instead of one, and the orbital habitat starts to look more like a margin.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on June 05, 2017, 09:06:57 AM
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.

In some ways what is actually needed is for factory built stations to be unmovable. Then you could remove all the restrictions on what can be built without factories. I'm not entirely convinced that some massive orbital shipyard should be towable by a tug anyway. Stations are  probably not designed to exist in the Aurora TN fluid state that allows ships to move without momentum, so you'd have all sorts of issues when the engines started.

Instead I'd prefer that station are move like PDCs in that they are pre-built by factories but then assembled in situ by constructions ships. Even better if you can move them only by having a construction ship repack them, cargo ships move the parts and then the construction ship rebuild in the new position.

So I guess I'm arguing for a change to a system where anything intended to move in TN space, under its own power or not, needs to be built in TN space in the specialized TN environment of a shipyard. But that stationary items can be prebuilt and deployed/packed as needed by a construction ship, effectively like an orbital PDC.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on June 05, 2017, 11:39:46 AM
"Intended deployment time 3 months"

A habitat likely includes more facilities than would be included on a ship.
Then why can I still use the ship version? It honestly just feels super arbitrary.

I really like TCD's idea about construction ships; it'd give them more of a purpose and it would bring a lot of classic sci-fi possibilities to Aurora that have been sorely missing.  Specifically I'm thinking of the MAC platforms of Halo, the Halos from Halo, the Death Star (albeit without the planetkilling laser), the Citadel from Mass Effect
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on June 05, 2017, 04:40:07 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on June 05, 2017, 06:31:24 PM
There's also electrodynamic thrusters, which involve extending a long cable into the Earth's magnetic field and running power to it.  The magnetic field acts on the current in the cable and propels the spacecraft.

Currently they're used for minor changes to orbits, like stationkeeping.
Title: Re: C# Aurora Changes Discussion
Post by: serger on June 05, 2017, 06:55:55 PM
Person012345, what are you talking about?.. There was a point about propulsion drive, not a gravity maneuvre or light sail.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on June 06, 2017, 06:48:55 AM
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?

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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on June 06, 2017, 08:37:17 AM
Person012345, what are you talking about?.. There was a point about propulsion drive, not a gravity maneuvre or light sail.
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.
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".
Title: Re: C# Aurora Changes Discussion
Post by: Detros on June 06, 2017, 09:04:52 AM
Full speed ahead!
Ay, ay, sending more gravitons to the engines, capt'n.
Title: Re: C# Aurora Changes Discussion
Post by: serger on June 06, 2017, 01:22:00 PM
Person012345, I'm sorry, but you are not very accurate in description of my statements. You mixed me up with Hazard and, from the other side, it was my statement, that plasma is not technically a gas. And there are some other fine points, where I suspect, that you mixed up smth too. Therefore, I suspect that you are in some misunderstanding about my point at all.

Again.
When you are tossing nuclear tablets for NP drive - it is the same, as you are tossing fuel (chemical, or nuclear, or matter-antimatter, it doesn't matter) to the combustion chamber.
But rocket engines are not propel their ships just tossing out propulsion mass from the combustion chamber. They are propel their ships, when they tossed smth out from the nozzle:

(https://upload.wikimedia.org/wikipedia/commons/thumb/5/55/Rocket_thrust.svg/768px-Rocket_thrust.svg.png)

As you can see at the picture, main pressure asymmetry - it is an asymmetry at the back surface of nozzle, not at the inner surface of the ship. There is a reason to use nozzle, not a simple hole in the combustion chamber. Propulsion pressure tosses your ship, when it's propulsion mass is already out of your ship.

And what is a difference with NP engine?
At the first look, the difference is, that NP engine can work with outer combustion. It can have no combustion chamber at all, and it's nozzle have another (more open) form.
Indeed, NP engine also can have usual inner combustion chamber and usual form of nozzle, if you have a stuff like Duranium, that will endure such inner impact.

The difference between Nuclear Pulse engine and other propulsion engines (nuclear or chemical) is not in outer combustion.
The difference is in pulse combustion.
The same pulse, as in those old German V-1 pulse rocket engines, neglecting that V-1 used chemical fuel, not nuclear, because Germany has no nuclear drive tech. :)

As for classical Orion NP drive - it have outer combustion, yes. But there is still no principal difference. Outer combustion or inner combustion - both ways you have to combust some matter to create pressure at the back of your ship, that will be asymmetrical when bump this ship, tossing it forward. It is absolutely the same, as to say, that you are tossing smth back from the back of this ship.

And there is a principle of momentum conservation law, as it is. Tossing smth back is tossing smth forward, and no other way (and gravitational maneuvers and light sails are not exceptions - all of them are tossing smth back too: gravitational maneuver is tossing major mass, using it's own gravitation; light sail is the same as foton drive, though it looks very couterintuitive, because light sail can use a star or outer laser as a part of itself).

And if you want to have an effective drive (as Hazard wrote, when our conversation start) - you must toss smth with full close control of the process. It is - to toss smth from the back of your ship, as in the picture above. Any other known way will be ineffective from our Aurorian point of view, and from any hard-fiction point of view at all. :)
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on June 06, 2017, 02:30:40 PM
And there is a principle of momentum conservation law, as it is.
(https://cdn.discordapp.com/attachments/317001475882483712/321732552799027210/unknown.png)
Title: Re: C# Aurora Changes Discussion
Post by: serger on June 06, 2017, 02:42:41 PM
iceball3, your message is too laconic for me. I don't understand Spartan language. :)
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on June 06, 2017, 03:06:42 PM
*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.
Title: Re: C# Aurora Changes Discussion
Post by: Detros on June 06, 2017, 05:36:55 PM
Can we just get back to discussing game stuff more directly?
Title: Re: C# Aurora Changes Discussion
Post by: serger on June 06, 2017, 10:53:11 PM
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.  ::)
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on June 07, 2017, 07:31:25 AM
Can we just get back to discussing game stuff more directly?

And please remember Erick's site rules (http://aurora2.pentarch.org/index.php?topic=966.0 (http://aurora2.pentarch.org/index.php?topic=966.0)):

1. No Spam. You get one chance to spam, and then you get banned.
2. No Flames. We are all here because we like 4x games.
3. Have Fun. If you aren't having fun, we'll send over someone to smack you with a trout until you do.  ;)

So in the spirit of #3:  Have fun!

John
Title: Re: C# Aurora Changes Discussion
Post by: boggo2300 on June 07, 2017, 04:47:34 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Silvarelion on June 09, 2017, 07:53:04 PM
As someone with an allergy for fish oil I claim this would be a completely un-fun thing to have happen.

Best to maintain an unfailing and unflinching air of fun, then :P
Title: Re: C# Aurora Changes Discussion
Post by: Tuna-Fish on June 10, 2017, 01:20:49 PM
RE: new passive sensor model.

I very much like this, not the least because it immediately made heat-seeking missiles massively more usable.  This allows completely new ways of fighting. . .
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on June 10, 2017, 01:39:45 PM
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...
Title: Re: C# Aurora Changes Discussion
Post by: Felixg on June 10, 2017, 07:41:24 PM
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...

Stealthed fighters coasting around behind the enemy formation, unloading their heavy missiles once they are too close to be intercepted, or after the enemy is already engaged in energy weapons range with the motherships so they have to choose between final defense or attacking.
Title: Re: C# Aurora Changes Discussion
Post by: Gyrfalcon on June 12, 2017, 01:49:48 AM
I'm cautiously optimistic that the new changes will help push missile sizes up. Mid-game, I think you'll want most missiles to have at least .75 MSP for ECM, ECCM and a sensor package of some form.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on June 12, 2017, 02:28:42 AM
Yeah 0.25 MSP cutoff seems like a great idea. It's 25% of a size 1 Missile, which will significantly impact it's performance, but only 5-10% of most smallish/normal sized ASM ( Size 2.5 - 5 ), and negligible for larger torpedoes.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on June 12, 2017, 04:52:41 AM
Perhaps the .25 minimum could be the subject of a few tech levels to reduce required size down although not reducing to current state.

However do like these changes, especially the reduced load times on larger launchers and box launchers from the off.
Title: Re: C# Aurora Changes Discussion
Post by: Detros on June 12, 2017, 06:12:02 AM
Perhaps the .25 minimum could be the subject of a few tech levels to reduce required size down although not reducing to current state.

However do like these changes, especially the reduced load times on larger launchers and box launchers from the off.
Minimal size of missile sensor: 4-3-2.5-2-1.5-1
Minimal size of missile ECM/ECCM : 2-1.5-1-0.75-0.5-0.25
?

Or just
Minimal size of missile part (engine, warhead, fuel, armor, sensor, ECM/ECCM): 2-1.75-1.5-1-0.75-0.5-0.25
?

In all those cases you don't have that part at all or have at least listed amount of it.
Title: Re: C# Aurora Changes Discussion
Post by: Cyborg29 on June 12, 2017, 12:21:46 PM
Hello!
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
Title: Re: C# Aurora Changes Discussion
Post by: serger on June 12, 2017, 12:40:30 PM
And your hour is still an Earth hour (1/24 of Earth day), and your second is a 1/3600 of your hour.
And a light year, cm, km, AU. Km/s. Tonn.
And decimal numbering (as we have 10 fingers, not a 6 tentacles).

Sigh.
Title: Re: C# Aurora Changes Discussion
Post by: Cyborg29 on June 12, 2017, 12:50:14 PM
Well, if you put it like that, sure it sounds pointless.  I wasn't about to suggest a whole new system of measuring units however, as that would be reinventing the wheel.

What i suggested, i assumed it would be relatively simple to implement, as i think that (atleast VB6) aurora keeps track of time as seconds since the beginning of the playthrough, which could be converted into custom time formats.

(why the sarcasm?).
Title: Re: C# Aurora Changes Discussion
Post by: Detros on June 12, 2017, 02:38:37 PM
Hello!
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
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on June 12, 2017, 02:42:19 PM
Its possible to have custom date formatting but it wouldn't be straightforward. The C# DateTime data type handles a lot of date manipulation automatically (much easier than in VB6). If I added a custom calendar I would have to replicate that functionality.

Not saying I won't add it - just that it isn't a high priority at the moment.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on June 13, 2017, 12:57:44 PM
I've been giving some thought/brainstorming to the missile changes and how they'll effect tactics.

For missiles themselves, ECCM is probably the easiest to analyze. Basically it becomes worth it if your warhead size x the accuracy improvement >= .25 MSP. For the basic reasoning that having x% more missiles hit is pretty similar to having missiles do x% more damage (not exactly similar, but close). Assuming 1-2 MSP warheads, this probably means that level 1 or 2 ECCM wont be very useful; after all, you wont be sure if the enemy will have ECM. 3 becomes quite worthwhile if you expect the enemy to use ECM, and beyond that I suspect it will almost always be worthwhile.

Missile ECM is more complicated, and probably a bit of a nerf to AMMs; after all, it doesn't take much to link ECCM to fire controls, but I doubt you'll put ECCM on your anti-missiles until very high tech levels. I consider this a good thing; currently AMMs are extremely capable and often result in 100% destruction of enemy missiles, turning them into something that thins but doesn't stop incoming waves is a positive in my book. Also they currently become progressively better against equal tech missiles as you advance; giving them a scaling penalty with higher tech will help balance that out. For that reason I think missile ECM will be quite powerful; you might not be able to rely on it against beam PD, but avoiding AMMs (or forcing your opponent to add ECCM to their AMMs, which is a net gain for the larger missile) is quite valuable.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on June 13, 2017, 06:18:32 PM
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 :)

Assuming I don't sink, I will be back toward the end of June.

(http://www.pentarch.org/steve/Screenshots/Boat.jpg)
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on June 13, 2017, 06:33:16 PM
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 :)

Assuming I don't sink, I will be back toward the end of June.

(http://www.pentarch.org/steve/Screenshots/Boat.jpg)
Watch your deployment time, and don't forget to stock the magazines before leaving. ;)
Title: Re: C# Aurora Changes Discussion
Post by: Detros on June 14, 2017, 12:33:04 AM
Sneak peak of C# Aurora new tech
"New Electric Hybrid"? So it can use both fuel from sorium and some other TN element?
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on June 14, 2017, 02:01:55 AM
"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 ;)
Title: Re: C# Aurora Changes Discussion
Post by: Detros on June 14, 2017, 03:49:30 AM
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,

OK, let's calm down again.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on June 14, 2017, 11:27:10 AM
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.

In terms of logistics, I can confirm plentiful supplies of beer. Not sure on anything else :)
Title: Re: C# Aurora Changes Discussion
Post by: boggo2300 on June 14, 2017, 04:33:48 PM
English beer doesn't count Steve, it's more like custard than the nectar of life ;)
Title: Re: C# Aurora Changes Discussion
Post by: ZimRathbone on June 15, 2017, 02:11:06 AM
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 :-)

 I used to enjoy many a fine night in Hebden Bridge when I was younger 8-$
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on June 15, 2017, 05:02:38 AM
The only good beer is German beer, and all other nations should be annexed and forced to brew it. Our purity laws say so.
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on June 15, 2017, 09:04:34 AM
At least no "sex on a raft" beer...
Title: Re: C# Aurora Changes Discussion
Post by: Shuul on June 28, 2017, 02:05:07 PM
Quote
Turret Update

Hey, I thought you are on vacation! Why you make me hype again?
Title: Re: C# Aurora Changes Discussion
Post by: mtm84 on June 29, 2017, 04:05:33 AM
Something always seemed wrong with turret armor.  I always figured maybe armor tech wasn't being applied or something.  Glad to see it's fixed, it will let me come that much closer to emulating WW2 ship classes in aurora!
Title: Re: C# Aurora Changes Discussion
Post by: DreadPirateLynx on June 29, 2017, 09:56:44 PM
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.   
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on July 02, 2017, 03:59:11 AM
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.   

This area has been revamped in C# Aurora to become much easier to manage: http://aurora2.pentarch.org/index.php?topic=8455.msg96785#msg96785

However, issuing simultaneous orders to multiple fleets in different locations will not be available (at least initially). The potential orders list is created based on the position and capabilities of the selected fleet, and the order may not be possible for all fleets within the same organisation. It is still theoretically possible to handle this but it would require a lot of extra code. Given the amount of other work required for C# Aurora, this change isn't a high priority
Title: Re: C# Aurora Changes Discussion
Post by: ardem on July 10, 2017, 12:03:15 AM
This mean Multistage rockets could be much quieter on thermals, you could launch from afar at a lower velocity, then hit high gear close to impact. Actually I could see benefits now to a three stage rocket.

Quiet running -> Medium to avoid antimissile -> Final impact to avoid point defence.

Honor Harrington here we come. Although I am disappointed about laser missiles not being around but such is life.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on July 10, 2017, 02:10:59 AM
Quote from:    Steve Walmsley
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.

Hmm. I wonder if you could make an effective passively guided AMM after this change?

With all the changes to Thermal and EM emissions as well as these being serious ways to guide missiles now it really feels like we need some way for Missile Fire Controls to fire on calculated interception points of target and relying on missiles picking up their emissions once close enough.

Doing that math and geometry by hand every time while possible is going to be pretty frustrating.

This way of playing could also could support making missile design even more interesting and deep. Maybe a 0.1 MSP component to enable a search pattern or loitering if missiles find nothing at their destination as well (continuing until out of fuel), or Friendly Fire risk for passively guided missiles unless you equip a 0.1 MSP IFF component to missiles.
Title: Re: C# Aurora Changes Discussion
Post by: Tuna-Fish on July 11, 2017, 06:10:57 PM
I wouldn't want to make my AMMs heatseeking just because of the amount of passive sensors and contacts for them it would mean on the map.  I mean, C# with all work done in memory is better, but it's not magic. . .

But yeah, it seems to me that a decent thermal sensor should now be usable as missile early warning -- so long as it's up, you don't need to run on actives to make sure your PD works, you can just turn on the actives after you see missiles.
Title: Re: C# Aurora Changes Discussion
Post by: infernobirdkrpt on July 15, 2017, 11:37:31 PM
Sorry if this has been asked already but is it real time pause or more of the same from Aurora 4x?
Title: Re: C# Aurora Changes Discussion
Post by: mrwigggles on July 16, 2017, 08:57:35 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Gyrfalcon on July 17, 2017, 02:10:23 AM
It's going to be more of the same. Changing Aurora to a realtime game would be far more then changing the codebase, you'd basically be building a new game entirely.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on July 17, 2017, 02:11:30 AM
Why on earth would you say that?
Title: Re: C# Aurora Changes Discussion
Post by: Gyrfalcon on July 17, 2017, 08:40:04 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Bughunter on July 17, 2017, 11:03:17 AM
While not realtime, what maybe could be in scope for the next Aurora release (Steve willing) is better management of the pausing. Like some control over what events cause a pause with some spam control feature like "do not pause for this event type again unless X time has passed since the last one".
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on July 17, 2017, 11:24:06 AM
Uh, and what's wrong with more of the same?

I would NOT want Aurora to be some smegty real time game. It is more than fine as it is. Basically turn based, with variable length turns.


I would like a better pause control. Letting us choose what pauses the game would be nice.
Title: Re: C# Aurora Changes Discussion
Post by: MagusXIX on July 17, 2017, 05:51:48 PM
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?

Not necessarily. It all depends on how it's programmed. Real-time games still operate in 'ticks' or 'turns.' The only real difference is that real-time games tend to have very small 'ticks' (turns) of much less than a second, and continue to advance the ticks at a steady rate unless the user pauses or otherwise speeds/slows the rate at which ticks occur. In Aurora a 'tick' is 5 seconds.

I've never had the chance to look at Aurora's underlying code, but my best guess based on how it's played is that it operates in terms of ticks, where some processes are set to happen every one tick and others (like the production cycle) are set to other lengths. If this is the case, changing the back end to a pausable real-time system (kinda like a Paradox grand strategy game) shouldn't require too terribly much refactoring. If Aurora isn't set up like that, however, then I have no idea.

Another way to do real-time, which would be much harder for Aurora, would be to use an event-based system, where the code is always listening for an event to happen - like "Construction of 5,000 Infrastructure on Earth complete," at which point whatever code is written around that event would fire and run semi-asynchronously while the main body of code continues to listen for more events. This isn't a 'turn' or 'tick' based system, which has its advantages and disadvantages, and as a result I believe would be much more difficult to implement than steadily advancing turns/ticks - assuming that Aurora's code is already set up to handle things in ~5 second increments.

EDIT: Of course, either way is still an assload of work and Steve's time is almost certainly better spent on other aspects of the game at the moment.
Title: Re: C# Aurora Changes Discussion
Post by: ardem on July 17, 2017, 10:46:19 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Bughunter on July 18, 2017, 06:54:44 AM
User input & the gui would probably take more work adapting to real-time, not the backend. But as every one else seems to agree we don't really want realtime anyway. A way to skip ahead a bit during combat however would be nice.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on July 18, 2017, 10:42:47 AM
You should put this in the suggestions thread.
Title: Re: C# Aurora Changes Discussion
Post by: Seolferwulf on July 18, 2017, 01:24:23 PM
There's no need for the game to run in real time.
It's fine as it is right now.

Just imagine if you couldn't skip time when starting a new game. . .  you'd have to wait forever for the essential techs and nothing else to do while waiting.
Title: Re: C# Aurora Changes Discussion
Post by: boggo2300 on July 18, 2017, 04:29:25 PM
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.

And more importantly RTS games are usually about as strategic as a game of hockey
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on July 19, 2017, 08:45:19 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on July 19, 2017, 09:04:08 AM
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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Tuna-Fish on July 19, 2017, 12:32:16 PM
Quote from: Hazard link=topic=8497. msg103604#msg103604 date=1500471919
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on July 19, 2017, 04:00:20 PM
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.

A class wide toggle during design saves on later micromanagement.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on July 24, 2017, 07:49:56 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on July 25, 2017, 08:20:35 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on July 25, 2017, 11:21:56 AM
Its a shame, but yes.  Everyone has to use 5 second increments.  Much like how if you play Europa Universalis 4 in multiplayer, the speed is set to the slowest speed any play wants.

As for who decides when to switch to 30s; everyone.  If you've played Dominions 4, that is how increments should progress.  In Dom4, turns are simultaneous just like Aurora's increments, everyone plays at once.  In Dom4, the next turn is not started until all players have clicked "End Turn".  In Aurora, this would also allow people to set what increment they wanted every turn and the game would use the shortest one anyone selected.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on July 25, 2017, 12:51:41 PM
I think it could be workable if fleet engagements could be better automated.  If people are scratching their chin for ten minutes while setting up targets before agreeing to start the next increment then I agree that that would never be viable.

Maybe a system where you could introduce players into a single player campaign, and to let them carry out fleet battles with only the involved combatants online for the engagement?
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on July 26, 2017, 01:15:00 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on July 26, 2017, 09:34:23 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on July 26, 2017, 11:09:55 AM
Why do we need a person to be DM?  That kind of thing can be automated easily.

"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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on July 26, 2017, 11:12:07 AM
The problem with multiplayer Aurora is its variable time increment. Dominion has a fixed time increment that is always relevant on the timescale the game works on and battles are entirely automated, while with Aurora the time increment is extremely flexible and battles, which take a lot of time relatively speaking, need to be done by hand.
Title: Re: C# Aurora Changes Discussion
Post by: Triato on July 26, 2017, 12:30:11 PM
Then the game would only run the smallest time increment imputed. If a player clics a month but other clics a day, the game only advances a day and pauses again for the player who imputed one day but keeps the one who imputed a month waiting (with a chance to pause it too).

Such system should have audio alerts that lets you know if the increment you imputed has passed and/or if your increment has been interrupted by an event. That way you can surf the internet or work while waiting. (This feature would help current aurora too)
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on July 26, 2017, 03:46:00 PM
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).
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on July 26, 2017, 03:50:05 PM
Why do we need a person to be DM?  That kind of thing can be automated easily.

"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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on July 26, 2017, 09:08:55 PM
I'm saying we do not need a GM at all, not that the GM should not have this responsibility.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on July 26, 2017, 10:33:50 PM
I'm saying we do not need a GM at all, not that the GM should not have this responsibility.

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.
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on July 29, 2017, 04:13:08 AM
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?

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.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on July 29, 2017, 07:01:09 AM
While all active players are in 'exploration' mode, this kind of Dom4 multiplayer might work. But when someone goes to battle those not involved would get bored waiting 3 hours during they could do nothing. The time increment of battle compared to exploration in Aurora is too different to make people not fall asleep while others battle.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on July 29, 2017, 07:47:58 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on July 29, 2017, 11:04:59 AM
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 the most important part is: "Does Steve want to spend the time to code it up?"  Even if he does, he should wait until he gets single player mode out the door.  One of the things Steve is really good at is driving towards getting a working application going as quickly as possible.  Part of this in this context is not getting distracted by major rewrites of game mechanics - most of the changes he's making are at the margins as he recodes specific pieces of functionality.  Trying to put in inter-process or inter-computer communication would be a diversion which would only delay C# Aurora even more.  And don't forget, this is a hobby for Steve - most of the stuff he's writing is for him to use; he's simply kind enough to share it with us.

The most likely way I see significant multi-player functionality getting into Aurora is if Steve has someone he wants to play multi-player Aurora with :)  If that happens, then I expect the details of how it's implemented will be highly dependent on the logistics of how they want to play :)

John
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on July 29, 2017, 11:38:33 AM
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.
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.

What this would allow is players who were not in combat could go do something else while they wait.  If something triggers an interrupt, the host can contact the affected players and get them to handle it.  So say there's 4 players, and 2 start fighting.  The two who aren't fighting just click 30-days, and go play something else for a little while.  Meanwhile, the two in combat fight it out at 5-sec increments as long as they have to.  If the fighting spills over to a third player, an interrupt would trigger for him, stopping his 30-day increment.  The host can call him on the phone or skype or steam and get him to work out the interrupts.  Obviously I'm assuming this will only really work if all players know each other.  But I think that's a fine assumption, I don't believe many people play Dom4 or Europa Universalis 4 with strangers.  Dom4 has no matchmaking at all, and EU4 barely does.

I agree with sloanjh though.  This is all just waiting on Steve playing multiplayer with someone.  I hope it happens soon.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on July 29, 2017, 11:43:18 AM
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?

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.
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on July 29, 2017, 10:38:16 PM
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.

Having the turn automatically process when everybody clicks "ready" is more convenient and less annoying than having to wait for a third party to wake up and hit a button. The "GM" (whoever has the host computer) actually could just go to sleep this way if all he was doing was hosting the game and not actually playing. If you can't see why automating this is still an improvement no matter how small, you're either slow or being deliberately obtuse.

As for getting different increments due to a player either picking something else, having an interrupt, or fighting a battle, you could just have everybody whose increment is still pending receive a prompt (without unpausing their game) when a different increment happens asking them if they want to gain control back and do anything. If you ignore it, nothing happens and the game continues treating you as if you're waiting on your increment. That way you can step away and do something else while you wait for whoever is fighting or dealing with an interrupt to resolve whatever is going on. All you'd need to do is give the game an alarm sound that plays when minimised to force players to be aware that an interrupt is going on and they have stuff to do.
Another feature would be to force increment syncs at certain times, e.g every 6 months or at the end of every year, which would pause every player.

Even having limited play while somebody is away could be solved by having a feature for somebody to flag themselves as absent (or have the host do it) so that the game ignores all of their interrupts. This would last until the player reconnects to the server. This requires near-zero GM oversight.

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.
The need to control idiot trolls is basically the only thing that can't really be automated, and even then it can be solved by just letting the host have a button to kick players and turn their faction into an NPR. The host could actually do this for players who decide they don't want to play anymore, or similar to Dom4 have it automatically set up to cede players to NPR control if they don't submit another turn before a set time.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on July 30, 2017, 04:27:41 AM
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.

You should try to play some Paradox games like Stellaris or Hoi4 MP ( which are pretty high up on the scale of complex strategy/4x games capable of multiplayer )...

No game which features anonymity + internet MP audience is immune to idiot trolls as explained by this highly scientific theory:

(http://i.imgur.com/X1dV6.jpg)


When it comes to Aurora supporting MP I see it as two levels:


Where the former is vastly easier to support for Steve with functions to share orders/gamestates and allows fairly decent Multiplayer sessions still if you let a GM handle only combat and movement orders.


Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on July 30, 2017, 05:10:37 AM
Stellaris and Hoi4 are high up complex strategy games? Please.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on July 30, 2017, 05:27:47 AM
Stellaris and Hoi4 are high up complex strategy games? Please.

Compared to the entire spectrum of games starting at candy crush or angry birds and with aurora at the other end... Yes they most certainly are.

In many cases they have a more complex mechanics or unfriendly interface then even aurora does ( even if the UI have improved alot since their older games ).


But seriously, look at screenshots & tooltips like this and tell me this isn't a complex game again, PLEASE:

https://steamuserimages-a.akamaihd.net/ugc/254839288186262725/DBB1ADDEA0FD054128ECD77EBB919F2292978B1F/


Edit: This is entirely besides the point though, since my point was that the complexity of the game doesn't affect the amount of trolls.
Title: Re: C# Aurora Changes Discussion
Post by: Elouda on July 30, 2017, 07:11:17 AM
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. There is no public lobby, matchmaking is done on the forum or by PM, and turns sent by email. While the last point is something thats more an artifact of their age than anything else, I really don't see what a public matchmaking system would add to Aurora if it went MP, and the approach from these games is very relevant given that they're similarly complex and niche.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on July 30, 2017, 09:14:09 AM
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.

I have played a HoI Multiplayer match that took 6 months to finish... Just like you can play a casual game of Aurora in an Afternoon if you spam the advance 30 day button until you get the stuff you want.

It's more about the player and the level of detail you want to take it to, to be honest ( for either game ).

I agree with your point that public matchmaking would add little to Aurora though.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on August 06, 2017, 01:19:55 PM
Quote
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.

This needs an 'Elite Unit' checkbox for automated ground unit commander assignment, prioritizing them for getting assigned a ground unit commander with a high training bonus.
Title: Re: C# Aurora Changes Discussion
Post by: hyramgraff on August 09, 2017, 10:15:21 PM
Steve, the changes to the administrative command structure look really exciting and I can't wait to try it out.  However, I see one potential issue with the new setup: if you have multiple commanders that share the highest rank in your navy then one of them won't be able to give or receive any admin bonuses because they're not a lower rank than the head of the command tree.  In 7.1, I can assign each of the rank four commanders to lead a task force and get full benefits from both of them.

In the early phases of my games I usually have two rank four commanders at the top of my navy and it takes years for the pyramid of command to grow from 2-5-17-53 to 1-2-8-26-80.  Would it be possible to have the automatic promotion algorithm make sure that there's always only one commander at the highest rank in the command pyramid?
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on August 10, 2017, 07:44:27 AM
Steve

The admin piece looks really good. It would be helpful if there is an easy way to see who is and is not getting bonuses and where any breaks of problems with the chain of command are arising. Also are you expecting to have a similar auto assign as per the current version of Aurora and will that consider rank levels when assigning? Finally I assume you will be boosting the number of officers you get a year to help fill in all of these new positions?
Title: Re: C# Aurora Changes Discussion
Post by: bean on August 10, 2017, 04:58:53 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on August 10, 2017, 05:31:27 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: bean on August 11, 2017, 12:02:59 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on August 15, 2017, 06:05:16 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Silvarelion on August 15, 2017, 09:33:40 AM
It was my understanding that the fleet would get bonuses from both admin commands
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on August 16, 2017, 04:54:13 AM
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.

Yes, would receive bonuses from both. Each link in the chain only has to be in range of the immediately previous link. With a network of command centres, you can spread bonuses across your territory.
Title: Re: C# Aurora Changes Discussion
Post by: db48x on August 21, 2017, 09:13:40 PM
This showed up on HN the other day, and I immediately thought of Aurora: https://common-lisp.net/project/mcclim/static/media/screenshots/u68N7VD.png

It's not nearly as complex as Aurora's map, but it has a nice and simple way of drawing ownership as an area on the map.
Title: Re: C# Aurora Changes Discussion
Post by: MJOne on August 22, 2017, 12:13:28 AM
Hi

I think its too messy and very disco-like. 
I like the plain old one better, its easy to read and no unneccesary blings.

Aurora should not become graphic heavy, as it is that keeps the creator focus on the best aspect of the game, gameplay.
Title: Re: C# Aurora Changes Discussion
Post by: Felixg on August 22, 2017, 08:50:15 PM
Steve

I love the concept of titans, they are awesome, but please, change the names you have there for them.

Instead of going with names from GW who are lawsuit happy go with something like

Scout, Tactical, Strategic titans
or
Scout, Battle, War titans

Just something that isn't so immediately recognizable as 40k.
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on August 22, 2017, 09:56:20 PM
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.

Ikr. It seems really out of place when all of the other ground troops have generic names.
Title: Re: C# Aurora Changes Discussion
Post by: mrwigggles on August 23, 2017, 04:07:43 AM
What exactly is sky scrapper size ground vehicle doing that would be consider scouting?
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on August 23, 2017, 06:36:00 AM
Looking over small mountains?
Title: Re: C# Aurora Changes Discussion
Post by: dukea42 on August 23, 2017, 03:57:32 PM
Skirmish Titan? 
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on August 23, 2017, 05:21:49 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: lennson on August 23, 2017, 06:40:17 PM
More advanced ground units could play a more important role if they were expanded to have some amount of ground to space capabilities. As it is a invading ground force is rather helpless without support from space against a counter attack from space. 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.

This would be a lot more complicated than what is currently on the table but the point is there could be value to increasing the role of ground units.
Title: Re: C# Aurora Changes Discussion
Post by: Gyrfalcon on August 24, 2017, 12:23:45 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: serger on August 24, 2017, 12:48:33 AM
Auch... Please, rename it to battleoids or some another generalized name...
Title: Re: C# Aurora Changes Discussion
Post by: mtm84 on August 24, 2017, 04:42:14 AM
I'm going to be naming mine Gundams, so that's not a problem for me, but the default does seem rather out of place.
Title: Re: C# Aurora Changes Discussion
Post by: serger on August 24, 2017, 05:23:35 AM
I mean game-build (default) name, not gamer's customization.

Generally speaking, there are many such irritating interface inexactitudes in Aurora by now. Not all Aurora fighters are fighters (there are small crafts indeed - including recon and survey boats, team and rescue pinasses, fighter-tankers, etc.), not all Aurora missiles are missiles (there are ship ordnance indeed - including mines and buoys), etc., etc.

But old, established inexactitudes are not the same as new one, that is very easy to avoid.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on August 24, 2017, 10:55:44 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Profugo Barbatus on August 24, 2017, 04:19:53 PM
Quote from: Gyrfalcon link=topic=8497. msg103964#msg103964 date=1503552225
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.
Title: Re: C# Aurora Changes Discussion
Post by: DIT_grue on August 25, 2017, 01:51:30 AM
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.

The same amount of damage, spread evenly over three small Titans, will be repaired three times faster than it would if done to a single large Titan (of course, they can be expected to take three times as much damage during standard combat phases). That, plus the usual research cost and having units to cover needs in separate places, are the only reasons I can see in the present description for not going as big as possible. So something like this suggestion would be welcome.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on August 25, 2017, 06:23:35 AM
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.

I was thinking on exactly these lines :)

I will make some adjustments on this basis and I will rename accordingly.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on August 25, 2017, 08:19:52 AM
Was wondering if you could "synchronize" some of the values in regards to detection, size, etc.

So rather like this:
Code: [Select]
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

I think it would be easier (to read) if a ship design reads like this:
Code: [Select]
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

This then goes through the whole game. Not having different values for the same thing would make it a little easer to handle and read  ;)
Title: Re: C# Aurora Changes Discussion
Post by: MagusXIX on August 26, 2017, 05:10:05 PM
With regard to Titan balancing, I'd treat them a bit more like WW2 era tanks since they seem to fill a similar role (hard to kill, tons of damage, expensive to produce.) One game that already takes this concept and does a really good job of it is Hearts of Iron. HoI4 has base tank models with optional sidegrades that increase specialization at the expense of other areas like armor or sacrificing certain damage types. As tech improves, you start by upgrading the base model and then you can research into the sidegrades for the new base and upgrade those as well.

For Aurora, I'd recommend having a base Titan model (upgradeable over time) that has all-around damage/defense capabilities. It's this base model that determines the overall power level of the titan. You could then have a sidegrade that takes that base model and re-imagines it to focus around anti-Titan capabilities at the expense of everything else (taking off some small arms in favor of more cannons, for instance.) You could also have one for anti-infantry (or whatever you're calling your regular ground forces.) You could even have one with some basic ground-to-space capacities, like meson cannons that can shoot out of the atmosphere and hit things in very low orbit, or act as point defense, or possibly even some light missile capabilities. Each of these sidegrades could then be upgraded once the base model is also upgraded.

It's an Aurora analogue to the HoI idea of regular tanks, anti-infantry tanks, anti-tank tanks, and anti-air tanks. The player has to decide how much of each to build and include in their military in order to counter whatever their recon suggests they might be up against, which makes for pretty interesting gameplay provided the recon and production aspects are engaging enough.

Another alternative is to just have research branches that allow us to upgrade the various aspects of our titans as we see fit. This runs the risk of not having any sidegrades, as you'd just always produce the best available suite of upgrades instead of having specialized Titans.
Title: Re: C# Aurora Changes Discussion
Post by: MagusXIX on August 26, 2017, 05:22:16 PM
Adding that I think a Titan that's effectively a mobile-bunker would be quite interesting as well. Allow a specialized type of Titan to house infantry, who can fight from inside of it. It could work similarly to the way PDC defenses work. The titan just extends its defense to any infantry attached to it.
Title: Re: C# Aurora Changes Discussion
Post by: MagusXIX on August 26, 2017, 05:39:46 PM
After further reflection, I feel that Titans would be best introduced alongside a second attack/defense type.

The regular attack/defense values can stay in pretty much as they exist, and can represent small-arms damage.

Additionally, all units should should have a defense-piercing (armor piercing, depending on how you're abstracting out your ground forces to work with your game's setup and lore) type of attack. It's an attack that always hits regardless of a unit's defense value. A defense-piercing attack, and ground units specialized around it, allows for engaging tactics and strategy decisions that don't currently exist. For instance, Titans (and perhaps other ground units) could have an extremely high defense, making them nearly immune to regular attack values but still very vulnerable to units specialized for defense-piercing attacks.

I'd consider making all attacks from ship-quality weapons (whether from an actual ship or from a PDC or orbital platform or whatever) defense-piercing.
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on August 26, 2017, 11:26:48 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Rye123 on August 27, 2017, 03:39:35 AM
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.

I agree with this, this can bring further customisation into ground combat.

However implementing how specific ship-based weapons like lasers or missiles would work would need further details.
Title: Re: C# Aurora Changes Discussion
Post by: IanD on August 27, 2017, 05:22:09 AM
Quote
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?

Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on August 27, 2017, 06:02:35 AM
How does this affect special ruins only tech such as compressed fuel tanks and advanced lasers?

Depending on the level of ruins, you will receive a different compressed fuel storage system (small, normal, large or very large). For level 1 ruins you receive normal very large fuel storage.

At the moment advanced lasers aren't in, although you can receive spinal lasers and particle lances from ruins. Also gauss cannon turrets and all the new C# installations and components (such as refuelling stations, naval headquarters, refuelling systems & hubs, command & control systems, etc.).
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on August 27, 2017, 07:24:53 AM
However implementing how specific ship-based weapons like lasers or missiles would work would need further details.

They'd probably just work the same way those weapons do when being fired from ships, but without the atmosphere penalty.
Title: Re: C# Aurora Changes Discussion
Post by: boggo2300 on August 27, 2017, 04:39:53 PM
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
Title: Re: C# Aurora Changes Discussion
Post by: Laurence on August 28, 2017, 07:57:39 AM
I'd like to be able to rename them in some fashion... say Bolo instead of Titan.  :)
Title: Re: C# Aurora Changes Discussion
Post by: IanD on August 28, 2017, 01:41:33 PM
I'd like to be able to rename them in some fashion... say Bolo instead of Titan.  :)


Seconded!!
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on August 28, 2017, 03:49:38 PM
I'd like to be able to rename them in some fashion... say Bolo instead of Titan.  :)

You will be able to rename them, just like you can already rename any other ground unit type in VB6.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on August 31, 2017, 05:27:11 AM
I wonder if any titan-based Anti-missile capability is in order.
How well do titans fare against mesons and missiles, Steve?
I wonder, as a lot of events where a ship would have clearance to drop titans to fight other titans, or ground drops in general it sounds like they'd similarly be capable of laying out some serious anti ground bombardment and meson fire.
Sure, bombardment messes ground stuff up, but ground combat does too a bit, yeah? If a low yield missile can invalidate a titan, then it sounds like it'd be a lot more efficient than dropping another titan, unless ground units in general are made a lot smaller (or missiles made bigger).
Another concern, is that if you land titans to attempt to take/fight PDCs, could ground based mesons be turned against them to devastating effect?
I know AI does none of these things (yet), but it does concern me how much arbitrarily large meson defense networks can already go towards shattering attempts at creating a beachhead.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on August 31, 2017, 09:50:40 AM
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

Unless I'm going to play a WH40K game, the "titans" in my games will actually be atmospheric air/strike force. They will depict helicopters, ornithopters and jet planes. Since heavy assault is tanks. That fits neatly with the mechanics as well - it doesn't make sense for 'copters and fast fliers to get damaged in the same manner as ground forces.
Title: Re: C# Aurora Changes Discussion
Post by: Rye123 on August 31, 2017, 07:19:27 PM
Actually, since there are so many ideas for customising the Titans, why not just make Titans like mobile PDCs? You could add random stuff to them and it changes their mass. Do away with the 3 default Titans, and then players can create their own Titans.

So the ship design menu will have 3 options - Ship, Titan or PDC.


Then again I'm not sure if Titans will have such a big effect on the game to warrant such a change...
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on August 31, 2017, 09:28:07 PM
I like the mobile PDC idea.  This isn't in any way neccesary, but warhammer has titans that can be boarded, and they have giant fortifications all throughout the legs and divisions of troops defending the titan from boarders.  That would be cool as hell to have ingame, especially if the titans could get up to large ship scale in terms of investment.

Again, not needed, just would be really cool.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on August 31, 2017, 10:15:36 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on August 31, 2017, 11:29:42 PM
I kind of agree that Titans are not what we need right now.  The AI doesn't even do ground combat right now.  I don't really see any sense in devoting any effort into ground combat mechanics that aren't ever going to be used.

Basically, until the AI can make and use troop transports and/or dropships, this is just arguing over how many angels can dance on the head of a pin.
Title: Re: C# Aurora Changes Discussion
Post by: Rye123 on September 01, 2017, 12:50:49 AM
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.


Yeah, I agree. It's just that if we're gonna suggest all these customisation options for Titans, we may as well just all put it all in one package.

But yeah, I agree that it's not really necessary now, especially since the AI doesn't even do ground combat.
Title: Re: C# Aurora Changes Discussion
Post by: Jovus on September 01, 2017, 02:54:01 AM
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.


...


I started that off as a joke, but it would be pretty awesome.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on September 01, 2017, 08:25:14 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 01, 2017, 09:30:50 AM
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?

The problem occurs because in VB6 officers are unassigned after a fixed period of time (the tour length). That doesn't happen in C#.

In C#, an officer will only undergo auto-assignment if he is currently unassigned, or he is a junior officer moving to a ship command position, or he had to leave his old command because he was promoted. In all those cases, the new assignment cannot be similar to his previous assignment.
Title: Re: C# Aurora Changes Discussion
Post by: Titanian on September 01, 2017, 06:13:37 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on September 01, 2017, 09:22:02 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 02, 2017, 05:33:02 AM
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?

A good point about fighters and FACs. I've added an extra rule that any ship of 1000 tons or less is always the lowest rank unless it has one of the extra control stations (AUX, CIC, etc.).

The auto-assignment only places officers in positions where they have a relevant skill. For example, only officers with survey skills are assigned to survey ships, officers with production skills are assigned to salvagers or construction ships, etc.. Which bonus takes priority is based on how you assign class priorities, or you can leave it to Aurora to decide. Officers with no bonuses will not be assigned, although you can still do that manually. The experience section in C# is a lot more detailed so officers will tend to receive bonuses based on the ships they are in. If you command a mining ship, 60% of the time any skill increase will be in mining, with the other options being crew training or reaction. Also, any officer, even if not assigned, has a small chance of a skill increase, so that officer would remain unassigned until a suitable bonus appears.

Moving up should not be an issue. With the new rules, especially admin commands, you will need more high level commanders than before.

Of course, you can still promote, demote and assign commanders manually as in VB6.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 02, 2017, 05:34:12 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Tree on September 02, 2017, 06:20:01 AM
Is it already possible in C# to search for a commander by name or sort them by name? Could you add "name" as a search criterion so we could order them alphabetically like we'll be able by bonus?
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on September 02, 2017, 07:22:29 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on September 02, 2017, 12:12:46 PM
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.
...
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
Title: Re: C# Aurora Changes Discussion
Post by: Jovus on September 02, 2017, 07:31:37 PM
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

Sounds great! I'll get right on that. Expect the first proof of concept prototype in 20 years or so.
Title: Re: C# Aurora Changes Discussion
Post by: DIT_grue on September 03, 2017, 04:50:21 AM
Quote from: Steve Walmsley
Construction Ship
Primary: 4
Secondary: Construction Time
Bonus: Production

Wouldn't this prioritise the oldest (slowest) ships, rather than the newest?


Quote from: Steve Walmsley
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.

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%?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 03, 2017, 05:09:24 AM
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%?

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.

Also correct on the overcrowding modifiers. I've changed the text.

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.
Title: Re: C# Aurora Changes Discussion
Post by: swarm_sadist on September 03, 2017, 04:02:35 PM
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!!

This has been bugging me for a long time, for some odd reason.
Title: Re: C# Aurora Changes Discussion
Post by: DIT_grue on September 04, 2017, 01:23:05 AM
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.

That explains it - I just used 12months*30days/month, which was stuck in my head from habitual calculation of such things in the VB6 version. Sorry for the false alarm!
Title: Re: C# Aurora Changes Discussion
Post by: Detros on September 04, 2017, 03:45:26 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 04, 2017, 12:22:13 PM
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.

// list of all unassigned naval officers or those in junior officer positions
List<Commander> AvailableCommanders = Aurora.Commanders.Values.Where(x => x.CommanderType == AuroraCommanderType.Naval && x.CommanderRace == this && (x.CommandType == AuroraCommandType.None || x.CommandType == AuroraCommandType.ExecutiveOfficer || x.CommandType == AuroraCommandType.ChiefEngineer || x.CommandType == AuroraCommandType.TacticalOfficer || x.CommandType == AuroraCommandType.ScienceOfficer || x.CommandType == AuroraCommandType.CAG)).ToList();
if (AvailableCommanders.Count == 0) return;

// ships without a commander
List<Ship> AvailableShips = RacialShips.Where(x => x.ReturnCommander(AuroraCommandType.Ship) == null).OrderBy(x => x.Class.CommanderPriority).ThenBy(x => x.PrimaryAssignmentPriority).ThenByDescending(x => x.SecondaryAssignmentPriority).ToList();

                foreach (Ship s in AvailableShips)
                {
                    Commander c = AvailableCommanders.Where(x => x.BonusList.ContainsKey(s.PrimaryBonusType) && x.CommanderRank == s.Class.RankRequired).OrderByDescending(x => x.ReturnBonusValue(s.PrimaryBonusType)).FirstOrDefault();
                    if (c != null)
                    {
                        c.AssignCommanderToShip(s, AuroraCommandType.Ship);
                        AvailableCommanders.Remove(c);
                        if (AvailableCommanders.Count == 0) break;
                    }
                }
Title: Re: C# Aurora Changes Discussion
Post by: Detros on September 04, 2017, 02:15:47 PM
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

OK then. I thought you may be able to supply the ordering direction via parameter. It seems vanilla LINQ doesn't offer such option but it should not be too hard (https://stackoverflow.com/questions/388708/ascending-descending-in-linq-can-one-change-the-order-via-parameter) to add it.

Alternatively you can actually store the inverted value for construction ships, construction-speed instead of time-needed, so the value raises for more advanced ships.
Title: Re: C# Aurora Changes Discussion
Post by: Scandinavian on September 04, 2017, 03:05:04 PM
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).
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 04, 2017, 06:07:58 PM
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).

Yes, good idea. No additional field required in that case.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on September 05, 2017, 04:36:43 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on September 05, 2017, 08:20:52 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 05, 2017, 12:56:45 PM
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.

In the past I have considered specialised military academies, but I think I prefer the idea of assigning a 'Commandant' and then giving his skills an extra chance of being added when creating new officers (and maybe more chance of his type of commander - scientists, naval officer, etc.). That way, you could build military academies on different planets that can specialise in different areas.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on September 05, 2017, 02:28:33 PM
I like the idea of assigning commanders to academies, gives the challenge of do you put your brightest and best to train the future or send them out to the front where they will have more immediate impact.
Title: Re: C# Aurora Changes Discussion
Post by: Alucard on September 05, 2017, 07:11:13 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on September 05, 2017, 08:36:53 PM
I like the change. I might not ever use it, but it's a nice option. And it's kinda nice to have a reason to spread your training facilities around.
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on September 05, 2017, 10:58:26 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on September 06, 2017, 01:50:17 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Kelewan on September 06, 2017, 02:56:16 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: Alucard on September 06, 2017, 05:18:55 AM
Quote from: Zincat link=topic=8497.   msg104097#msg104097 date=1504680617
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.   

Well, I do have some roleplaying reasons :D I like having a wealthy capital, where all the important people are from and the rest being this poor, opressed, uneducated worlds.    Something like core and outer planets in Firefly or Caprica vs Gemenon in BSG.   

That being saied, from a sortof gameplay point of view, it is a good addition, having to think about where you put your academies.   I just don't see how Aurora would ever be a game, where this sort of competitive stuff mattered as the AI is not really such an oponent and playing multiplayer is a bit of a pain. 
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 06, 2017, 01:14:47 PM
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.

You don't have to assign a commandant. You have the option of continuing as you do now, with no downside compared to VB6, or you can spread out your academies and gain some additional benefit.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 06, 2017, 01:15:17 PM
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?

No, they can either manage a research project or an academy.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 06, 2017, 01:28:59 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 06, 2017, 01:30:48 PM
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

You have two routes with scientists. You can use someone with high research skill to gain more high skill scientists (75% of which will be a different specialisation), or you could take a low skill scientist in an area for which you need more scientists of the same type..
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on September 06, 2017, 06:09:48 PM
Very interesting change with academies. I'll definitely start building them elsewhere with that change and not just at Earth.

As for lifesupport, I hope that TG's will now be smart about picking up lifepods. As it is, the first ship in the TG will pickup all survivors, regardless of it's crew quarters situation. Meaning that unless you carefully manage the pickup, you'll end up with 1 ship terribly overcrowded and the other ships with their emergency cryopods empty.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 06, 2017, 06:40:39 PM
An easy solution would a 'redistribute personnel' order that takes all the possible berths on a fleet (discounting parasite craft) and then spreads all crewmen in the fleet across the ships in accordance to the varying ships' proportional contribution to the total berth value.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on September 06, 2017, 08:25:06 PM
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.

Title: Re: C# Aurora Changes Discussion
Post by: Detros on September 07, 2017, 03:18:20 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on September 07, 2017, 05:18:22 AM
I want to specify that the possibility to appoint an academy commander is particularly appreciated for conventional start.

I know you don't really do conventional starts Steve, but in a conventional start getting a bad streak of luck in generating scientists is really, really limiting. So I really look forward to this feature.
Title: Re: C# Aurora Changes Discussion
Post by: db48x on September 07, 2017, 05:48:18 AM
The Commandant system sounds great. It's like sending Ender out to Eris to be trained by Mazer Rackham.
Title: Re: C# Aurora Changes Discussion
Post by: Britich on September 07, 2017, 11:35:51 AM
I like to setup Academies of at least level 1 on colony worlds that are over 10-25m in population cos I tent  to try to keep my colonies <1m in population.. purely role play.. so this addition will be welcome for me.
Now I can make colonies purely for military/science/administration purposes!

Love it.
Title: Re: C# Aurora Changes Discussion
Post by: bean on September 13, 2017, 07:26:39 AM
Very excited about all of the changes.  The one thing I will point out is that while officer management is going to be much better, ships still have crews that stick with them for all time.  This is unrealistic, and somewhat annoying, as your oldest ships always will have the best crews.
Also, I'm not sure I like ships with weapons automatically needing a Rank 3 commander.  That seems too stringent, even if you've closed the FAC loophole.  Is there a way smaller warships could use Rank 2 commanders?
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on September 14, 2017, 05:08:16 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 14, 2017, 02:50:23 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Silvarelion on September 14, 2017, 02:53:12 PM
Could probably be done through a couple of extra conditional orders.

Or with some hand calculations and delay orders.
Title: Re: C# Aurora Changes Discussion
Post by: bean on September 15, 2017, 08:20:32 AM
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. 
Title: Re: C# Aurora Changes Discussion
Post by: Silvarelion on September 15, 2017, 11:57:18 AM
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.

True enough. I always just slow my tankers down to a point where they will be approximately full when they arrive. My games rarely get to the point when I really feel love I need to automate things to reduce the hassle.
Title: Re: C# Aurora Changes Discussion
Post by: Kelewan on September 17, 2017, 12:42:47 PM
Regarding

Quote
In C# Aurora, transferring ordnance is no longer instant and ships without specialised equipment cannot exchange ordnance in space.

does this impact PDC?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 17, 2017, 01:16:02 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 17, 2017, 03:18:46 PM
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.

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?
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on September 17, 2017, 03:32:39 PM
Could probably be done through a couple of extra conditional orders.
Would be nice to have for managing larger empires  ;)
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 17, 2017, 04:50:17 PM
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).
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 17, 2017, 08:29:43 PM
1) Refuelling Systems and Ordnance Transfer Systems are conventional tech so you start with them in a conventional game.

I'm not sure you should. The Spaceport isn't in conventional starts in 7.10, and given the BP (and presumed mineral) cost of a Refueling Station and an Ordnance Transfer Station these should be gated similarly.

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.

Didn't rules use to be 'every refueling system refuels at max rate'? Because it appears I either misread or that exploit was closed. If a collier or tanker cannot exceed their highest rated transfer system... well, it means that multiple refueling/ordnance transfer systems are no longer a thing, but at least you can't stack multiple tankers or colliers, or such ships carrying multiple transfer systems, to allow much greater transfer rates.

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.

That may be so, but for the cargo handling alone it's not really worth expending 3600 BP for a level 2 spaceport. I mean, 3600 for the cargo handling and unlimited resupply links is an expensive but worthwhile investment, but you can get that same result and no worry about wasting resources by keeping the spaceport limited to cargo handling alone. I mean, at 1200 BP it's already a pretty major facility, but at 3600 it's the most expensive thing in the installation construction menu and beyond a level 1 spaceport all it does is add to the cargo handling modifier.

Useful, but for a system that will require 1.5 times the Build Point cost of an Academy, Lab, Shipyard, GMC, GFTF or Sector Command that's really quite expensive and the only reason that cost increase seems to be happening is the mission creep of spaceports. That's not counting the 8 times greater amount of shipping that's needed to get a spaceport where it's needed compared to a resource transfer station either.

Easiest way to handle the expense issue is by simply removing the mission creep. Let the spaceport remain a 1200 BP cargo handling facility, the resource transfer tasks can be handled by the dedicated facilities of the same costs. It's a little more fiddly at first blush, but you're going to be juggling fuel and ordnance transfer stations anyway, and this way you don't need to worry about doubling up on transfer capacity because you also have spaceports with the same ability. The only question you need to ask is if you have the appropriate type of the transfer facility on planet.

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.

The spaceport is not available in a conventional tech start in 7.10.

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).

Eh, planets need some level of viable anti orbital attack system, and I'm not sure ground forces can provide that. A station might, but you'd need to research stealth to get a station that can provide a decent surprise to a committed enemy.

Then again, early sensors are... not that great. You might be able to do quite a bit with a station with good passive sensors and a good firing computer if you've got seeking missiles, but, well, early sensors are crap.

To be honest, PDCs seem to serve two major purposes to me when you get rid of the methods they let you cheat the maintenance system. The first is anti orbital combat ability through slinging missiles and energy weapons at enemy ships. The other major purpose is slowing down enemy occupation by forcing the enemy to siege PDC after PDC with ground forces, or by denying them the planet altogether because of the collateral damage done by orbital strikes to root out the defenders.
Title: Re: C# Aurora Changes Discussion
Post by: Profugo Barbatus on September 17, 2017, 09:43:00 PM
Hrmm, replacing PDC's with some sort of ground unit that acts as a surface to space weapons battery might be interesting.

Without PDC's, combat engineers lose their purpose.  Replacing them with a large unit (Battalion sized maybe) that instead has a fairly low damage weapon that can engage hostile ships in a radius around the planet (Could probably upgrade both damage and radius through a seperate line of weapons tech) could prove interesting though.  Individual ground units can't be targeted by ships, meaning an attacking fleets only option is to start nuking the smeg out of the world if they want to silence the guns without a heavy ground assault.  If you want to capture more than an irradiated wasteland, you'll have to commit to a planetary invasion.  Otherwise, you'll be sitting back away from the planet, less you start to get chewed up by the ground based guns.

If you do stage an invasion, the same ground guns would likely prove to be an effective way to take out any assault ships landing on the planet, weakening the attacking forces.  I can't think of a time I put more than one layer of armor on any of my combat drop boats, so a few guns could help the defender balance the odds in their favor.  As a whole, this kind of unit would prove incredibly valuable for defensive operations, and considering the C# version is already bringing us one big game changer to ground combat, a second could be included as well.

You could probably tweak exactly how they work by changing what they're shooting for different effects on gameplay.  Letting them shoot smaller missiles from the planetary stockpile would significantly buff their striking power (Let each ground unit fire X MSP per Y increments, tweaking X and Y for desired results), give fleets the opportunity to defend with PD, and put an upper cap on how long they can fend a force off by making them dependent on a consumable, but would add some more complexity to ground forces by requiring you to keep them supplied with this ordinance.

There's probably other ways to go around it, but really, I do like the idea of replacing PDC's.  Although I will miss multifaction earth starts going full WW3 with nuclear missile bases.
Title: Re: C# Aurora Changes Discussion
Post by: MJOne on September 18, 2017, 12:23:34 AM
Please don't remove the PDC's.  Aurora is not the game it is because of simplicity, but complexity.
If you cater to that line of thought of making it easy for new players, then you should remove the ship designer as well.  But you will end up with a simple aged game.  The fact that the graphics are simple but clear is great when complexity saves the game from being a simple map simulation. 

Do not let new, lower spectrum, players ruin your greatness.  What if Beethoven used the same logic when he wrote his masterpieces, would he been a household names if he made his music simple?

Name a famous basket or clay pot manufacturer.  I bet you can't.
Name a famius tech or space company.  I bet you know a few.

Complexity is the beauty and the reflection of your greatness, do not self-censor to cater to the simple people.  Please.  :-)
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on September 18, 2017, 02:08:08 AM
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).

I think the main reason they confuse new players is that their name doesn't clarify if they are orbital or ground based. At least I remember that being the main thing confusing me when starting off ( and the bugs with starting PDCs that plagued the game for quite some time ).

While I don't see much use of their ground combat or "boarding" properties, I do think there is alot of value in still having some way to respond with missiles ( and for no atmosphere also guns/lasers ) from the planet surface and force the enemy to strike the planet if they want to return fire.

That doesn't necessarily have to be through PDCs in their current form though...



It would be terribly boring IMO if fleets could just move in and sweep away all defenses around a planet with zero collateral damage to the surface, and for RP I do love the idea of surface based defense centers & missile silos as well.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 18, 2017, 03:48:40 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: backstab on September 18, 2017, 04:30:36 AM
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.

Maybe add a mobile mssile battery with a limited ammo payload and short range missile fire control
Special forces company ... for when you really need to destroy that spaceport ... or se as expensive light infantry when your about to be overrun
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on September 18, 2017, 05:17:11 AM
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 fully support making ground combat more involved with more depth and techs!

Would you consider adding water ships which combat efficiency / coverage depending on surface water coverage and atmospheric fighters as well at some point, giving some progression to conventional starts?

Water ships could work like "early tech" titans ( big AoE guns/missiles ), and it would be really cool to have another layer of defense if atmospheric fighters could intercept dropships, requiring atmospheric capable space fighters to escort them ( X-com scenario ).

Another brainstorming idea is to require logistics and supplies to be delivered to be able to sustain ground offensives/combat.
Title: Re: C# Aurora Changes Discussion
Post by: infernobirdkrpt on September 18, 2017, 03:23:06 PM
i dunno if this has been asked.  What engine is this being made on
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 18, 2017, 03:29:49 PM
i dunno if this has been asked.  What engine is this being made on

C# and Windows Forms - not that popular as a gaming platform :)
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on September 18, 2017, 03:39:07 PM
I personally like the idea of shifting PDCs to use the ground forces system. Would make troop transports and invasions more meaningful if they could set up some sort of beachhead in a few weeks instead of taking months or years to build even a small PDC. And, like Steve said, PDCs currently are a bit confusing since they're sort of a hybrid with their own rules. You can always build orbital weapons platforms if you want something similar.

And to be totally honest I usually just ignore ground troops and nuke enemies until they surrender anyways. This would make it more interesting :p

Two, maybe three types?

Anti-Air Support Battalion: Attempts to shoot down incoming missiles in a CIWS like way?
Planet to Space Meson Battery Division: Mesons simplify away the need to "design" anti-space weapons, since they just do 1 damage anyways. Give them the PDC range bonus (your max beam fire control range x1.5) and a small active sensor capability, base it on your current tech, and they're an all in one anti-space weapon with no need for custom designs.
Planet to Space Missile Battery Division: Not as sure about this one. Missiles are more complex, you'd need to design around sensor range, etc. Might be possible to just say they can launch 50 msp every x second or whatever.

Alternately, they could be based off ground force strength techs or a new tech line (Planet to Space Weapons?)
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on September 18, 2017, 03:50:37 PM
I am in favor of removing PDCs as they are now. They do indeed break a number of rules, and I have always disliked that you can basically use them as ground-based ships that are much cheaper to build and do not require maintenance. Plus they are also more difficult to destroy, despite being immobile, because you can build them with MASSIVE armor.

I also like the idea of removing the atmospheric obstacle to planetary bombardment with beam ships, while at the same time giving ground "military" short anti-ship and anti-missile capabilities. With this idea in mind, invading  or bombarding a strongly garrisoned planet becomes challenging and dangerous. Enemy ships can bombard from afar with missiles, or risk retribution when doing a beam bombardment. Incoming transports will surely take casualties because of defending troops.

At the same time, this solution relegates any serious long-range anti-ship capabilities to Orbital Defense Platforms / Bases, as should be. This is also in my opinion a lot more balanced, because as said PDCs were not really well balanced. If you want to destroy enemy fleets from afar, you'll just have to build orbital bases which cost more, require shipyards, require maintenance and the like.

All in all, I am in favor of all this. Makes ground combat / troops/ garrisoning a lot more interesting, especially compared to how it is now. If you proceed with this idea Steve, maybe a separated thread would be a good thing, to discuss the details of the new system :)
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on September 18, 2017, 04:20:32 PM
Maybe keep the atmosphere bombardment penalty for beam ships, but change it to a flat -atm damage for railguns (so larger railguns could hit through thicker atmospheres?). Would give large railgun ships a use if you wanted a dedicated bombardment ship that wouldn't run out of missiles, but would open it up to Planet to Space fire from surface troops.

(I've been reading the first book in the Human Reach series after it got recommended on this forum, and it does something similar).
Title: Re: C# Aurora Changes Discussion
Post by: Indefatigable on September 18, 2017, 10:32:19 PM
Removing PDCs will also remove a chunk of the roleplay/flavour aspect from the "ground game". 

I absolutely want to build those flaktowers and command bunkers as space ####s, or legionary forts as romans or whatever the theme might be.

Instead of totally removing them, why not make them more expensive and/or less combat efficient.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on September 19, 2017, 01:24:48 AM
I feel like it would be reasonable to simply replace that with some kind of ambiguously defined 'ground unit'.
Title: Re: C# Aurora Changes Discussion
Post by: Black on September 19, 2017, 01:49:35 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Marski on September 19, 2017, 07:26:15 PM
I also find the idea of removing PDC's altogether a bit distressing.
My playstyle dictates to fully colonize & fortify the solar system before exploring jump-points due to past experiences involving a very hostile race.

Yes, they have their issues, but they aren't as bad as you make it sound. It's a matter of perspective I suppose.
For me, PDC's being hard to kill due to massive armor simulates the PDC's being well concealed, taking advantage of geography and so on and so forth. They can force players to employ other methods such as opposed planetary invasions rather than simply sit at a distance and lob nukes at them for months.

It gives such a great depth to the game's planetary combat that I haven't seen in any other 4x game except in Aurora. Point defence bases protect missile bases. Point defence bases are taken out by small and low-signature landing shuttles with company-sized combat drop modules. Marine companies take out the point defence bases to pave way for the larger shuttles with battalion-sized combat drop modules which then proceed to take out the missile bases.

The issue of "confusing new players" can be fixed with a tutorial, or notes in the design screen or pop-up icons explaining what PDC is.

Issue regarding "Drydock" PDC designs that bypass the maintenance needs, I have a proposition.
Introduce the concept of crews automatically leaving the starship whenever its in a shuttlebay, boatbay, or hangar. The more crew the ship has, the more it takes them to exit the ship and the same amount of time it takes them to re-enter the ship. Just like in real life, eh?
It couldn't hurt to introduce "rebooting sequence" as the shuttle/ship automatically shuts down all it's modules when in shuttlebay/hangar and needs time for each and every module to start up again. More modules again mean more time.

There, now there's a legitimate risk involving keeping your ships in "drydocks"
Title: Re: C# Aurora Changes Discussion
Post by: voknaar on September 20, 2017, 07:10:47 AM
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!

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.
Title: Re: C# Aurora Changes Discussion
Post by: Marski on September 20, 2017, 07:42:50 PM
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!

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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on September 21, 2017, 08:00:15 AM
I'm all for removing the exploitative abilities of PDC's as well as making ground combat more interesting. However I think outright removing PDC's would remove some of the interesting possibilities that the new ground combat mechanics might develop.
For a start remove the potential for exploitation, make them require maintenence, which will stop them being exploited, and allow enemy PDCs to be blockaded.
Give them a deployment time. Sure you can just increase crew quarters to raise deployment but that would also increase maintenance costs.
Large ground battles in the area should damage the PDC's armour, or perhaps there should be some kind of titan that excels at damaging PDC's, or provides addittional combat effectiveness to engineers.
One problem I have with PDC's is that a well equipped PDC that's actually vulnerable to being taken out with a small ground force is still basically invincible if it can swat every shuttle out of the air before it lands.
It needs to be somewhat easier to get small forces onto the ground to contest a heavy anti ship weapons facility than currently possible.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on September 21, 2017, 08:49:14 AM
Give them a deployment time. Sure you can just increase crew quarters to raise deployment but that would also increase maintenance costs.

How would that work? Normal ships deployment time only ticks up when they are not at a population, but you can't move a PDC so it will always be either at a population ( meaning the feature is useless ), or not at a population ( meaning the PDC is useless since it can't be moved ).
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on September 22, 2017, 07:39:45 AM
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.

Wow - this isn't the way I interpreted the OP at all!  I remember thinking it was actually a kind of interesting idea for generating something other than a regular hex map, albeit a LOT more work than he made it sound (which I suspect is where was "and now, for my next trick..." sentence was about).

In any event, even if a post is a bit jerk-ish, please remember the "no hitting" rule.  We want negative feedback loops in potential flame wars, not positive.

Thanks, and have fun!
John
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on September 22, 2017, 04:42:39 PM
Should probably focus the PDC/ground combat discussion to this specific thread that Steve made:
http://aurora2.pentarch.org/index.php?topic=9679.0

We're currently discussing them in two threads.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on September 25, 2017, 08:53:23 AM
"Deployment, Overcrowding, Under-manning and Life Support Failures";

Wouldn't it be feasible that cargo hold may be retrofitted into makeshift "quarters" in cases of dire emergency? I mean it would still be a strain on resources on board a ship, but it wouldn't be as unpleasant nor as much a strain as it would be if there was no cargo hold. Would be similar to your thought on checking if the hangar is in use. Of course that is assuming both the hangar and cargo hold are internal, pressurized chambers instead of external/internal racks that pilots get into their fighters via airlocks/umbilicals and cargo is in containers attached via clamps.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on September 27, 2017, 08:05:15 AM
AH. I didn't suggest how to givs a PDC a meaningful deployment time. Well physically a PDC would be supported by maintenance supplies, obviously. But for the crew deployment I would think there would be a need to send replacement crew occasionally using a transport ship, obviously a new crew would lower your crew grade, but it is still an exploit having a seemingly immortal crew.
Title: Re: C# Aurora Changes Discussion
Post by: Roses on October 03, 2017, 07:28:08 AM
is there any hope for multiplayer? :)
Title: Re: C# Aurora Changes Discussion
Post by: Detros on October 03, 2017, 07:39:36 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: mrwigggles on October 17, 2017, 05:36:57 PM
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.

A play by post system could work, but that wouldnt work much different then a storyteller and folks telling the story teller whats happening.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on October 17, 2017, 06:07:16 PM
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.

A play by post system could work, but that wouldnt work much different then a storyteller and folks telling the story teller whats happening.
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.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on October 18, 2017, 07:43:43 AM
Multiplayer would work by just having a host running ticks continuously.
You would need players to queue up actions with some system that could correct for errors caused by interaction with other players.
Combat would have to be left entirely upto the AI, a more robust AI would be needed which could have scripted actions based on doctrine or other commands issued by the controlling player depending on the situation.
Basically an entire different game would have to be designed to interact with aurora for multiplayer to work. But it is technically possible.
A more simplified method of integration might work but there is a huge dichotomy between the need for long production cycles and short battle scenarios. At what point is a player put in direct control of his navy? 
The game takes way too long for having direct 1 to 1 interaction with fine control and micromanagement. Well. It could be done if people didn't mind a game taking literally months with time being paused and slowed down whenever theres military contact.
Theres some challenges needed to make 2 clients capable of working on one database without errors, but it could be done.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on October 18, 2017, 10:47:50 AM
As long as you play with people you personally know, the time issue is not actually a problem.  You don't need to worry about trolls purposefully going with tiny increments or anything like that.

There's no reason to ever not have direct control by the players.  Every Total War game since Shogun 2 has had multiplayer campaigns.  Battles in those simply make everyone not involved wait.  Really not that big of a deal; you can just go do something else for awhile.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on October 18, 2017, 01:02:17 PM
That's kind of the only way I see multiplayer working without completely redesigning the game; some way for multiple people to connect and have the windows for their own race open, and just agree on when and how long to do the increments for like mature responsible adults (so not random matchfinding on the internet, basically :p)

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
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 19, 2017, 02:15:06 AM
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

Yeah. That not the main reason why playing complex strategy games in multiplayer is awesome though.

The most awesome part IMHO is that feeling when your enemy manage to totally surprise/ambush you and you manage to scrape together what you have nearby and through ingenuity, improvisation and some bit of luck still somehow salvage the situation and win the day.

It's hard to explain but it's not something your going to experience vs an AI ( other then maybe the first game or so ), or ever when playing all sides yourself.



Any game with so much replayability like Aurora have could greatly benefit from some way of doing multiplayer to keep you challenged and invested so I do hope Steve gets around to it eventually sometime after C# feels solid.
Title: Re: C# Aurora Changes Discussion
Post by: MuthaF on October 19, 2017, 01:35:35 PM
Please dont remove PDCs, fix them or gimp them instead.  The new player accessibility argument sounds so . . .  fake.  I mean what player who sticks with Aurora would have ever quit the game because of THAT? I can only imagine someone chosing to NOT use them.   
I mean, missiles vs PDCs, if its okey to be practically forced to use missiles for every player, icant possibly see the issue with fully optional PDCs. . .  Its not like AI @ 10 000% is a challenge for an average human brain. . .
 ::)

PDCs are too great to be removed - its the only interesting thing about ground combat/defenses at all; fix or adjust them please. .
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on November 01, 2017, 10:40:08 PM
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.

Title: Re: C# Aurora Changes Discussion
Post by: Gyrfalcon on November 02, 2017, 08:55:07 AM
really stronk space stations that could be garrisoned by troops and besieged by other troops, among other things.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on November 02, 2017, 11:21:44 AM
They can still be garrisoned with troops.  The real difference was how they were constructed.  They were built by industry instead of shipyards.

I know you can still build orbital habitats with industry, but that's not the same.  OH's are weighed down by 250,000 tons of dead weight.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on November 02, 2017, 05:30:12 PM
..wouldn't that be pretty fitting for an asteroid fortress...?
Title: Re: C# Aurora Changes Discussion
Post by: serger on November 05, 2017, 12:54:44 PM
At this post:
http://aurora2.pentarch.org/index.php?topic=8495.msg104912#msg104912

There is no such temperature, as -1000 (nor Celsius, nor Kelvin, nor Fahrenheit).
Absolute minimum of temperature (when every molecule have zero velocity) is 0K or ~-273C.

I think it will be nice to use this minimal value in Aurora, as this game is such attractive for us, astronomy geeks, and we know about absolute zero. :)
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on November 05, 2017, 01:13:23 PM
I'm really liking the changes to biomes and fortification level.

And yes, it seems it will be a really bad idea to try to bombard a deeply fortified ground force. 1 hit every 144 for jungle mountain. Yeah, not really going to happen XD

I like it. Makes ground troops much more of a necessity in many situations.

Serger: I would assume it's done exactly because of that. Means the terrain is applicable to any kind of low temperature, no matter how low. It's just an arbitrary number.... Since planet in Aurora cannot spawn with temperatures below -273 anyway.
Title: Re: C# Aurora Changes Discussion
Post by: serger on November 05, 2017, 01:18:51 PM
But they can be terraformed with antigreenhouse gas:
http://aurora2.pentarch.org/index.php?topic=8144.msg104909#msg104909
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 05, 2017, 01:33:12 PM
But they can be terraformed with antigreenhouse gas:
http://aurora2.pentarch.org/index.php?topic=8144.msg104909#msg104909

That's a bug in VB6 Aurora that is fixed in C# Aurora. The -1000 and +100,000 are just arbitrary numbers to highlight any temperature is fine.
Title: Re: C# Aurora Changes Discussion
Post by: swarm_sadist on November 05, 2017, 05:48:17 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on November 05, 2017, 05:53:10 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 05, 2017, 06:03:30 PM
I've updated the terrain post with the impact on terraforming.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 05, 2017, 06:07:56 PM
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.

I did have Molten and Lava Field at one point. However, I decided to remove them as the conditions would be covered by the rules on extreme temperature. Glacier is a possible. Archipelago covers the few small islands terrain and the Abyssal (at the moment I don't have water specific combat on the basis that combat would be centred on land with spacecraft filling the historical role of ships.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 05, 2017, 06:17:48 PM
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.

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.

I like the idea of Urban becoming the dominant terrain type once the population hits a certain percentage of maximum.

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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 05, 2017, 06:36:06 PM
I like the idea of Urban becoming the dominant terrain type once the population hits a certain percentage of maximum.

Wouldn't it be neat if you could expand the population capacity above max by building infrastructure, and if it went a certain amount above "max" natural it would represent en entire body of skyscrapers?

You would need alot more then 12 billion population on Earth for Urban to become the dominant "terrain" for example.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on November 05, 2017, 06:53:58 PM
The more I think about it, the more I like this latest development post.

Realistically speaking, against heavily fortified planets with difficult biomes you either 1) bombard with missiles from very long range and render the planet inhabitable or 2) get a lot of boots/robots/alien appendages on the ground.

As it should be.  This is a staple of practically every sci-fi setting. Massive orbital bombardment is generally only for reducing a planet to inhospitable rubble, if you want to conquer it, you have to land on it.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on November 05, 2017, 07:28:02 PM
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.

A very strong argument can be made Temperate Forest is correct. With the increasing temperature that can change (the most plausible end result from current data seems to be much greater desertification until rain patterns stabilize, at which point the savannahs and tropical forests are liable to grow. Time until that happens; unknown). I'd rather not have Earth create an exception though, so use the single biome system.

I understand why you use it; it's much simpler than the alternative.

Also, whenever I find a planet with a Mountain base terrain I'm going to raise its temperature to 35 degrees. It means the only possible result is jungle mountains.

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.

Please don't go for the standard 'hyper focused super predators obsessed with eating man.' It's stupid. Rather, go for something that cannot meaningfully impact settlement. I mean, seriously, bears and lions and wolves and large cats are really dangerous animals, make no mistake, but wolves and bears went extinct in much of Europe for a reason, and we've got much better weapons these days.

No group of wild animals could meaningfully impact a planetary population of humans, especially when said population is armed with and/or protected by armed people that carry military weapons and information gathering tools. Microbial life is far more dangerous because it's harder to detect and easier to spread, while a rush by even a thousand heads strong herd of cattle would not do more than destroy one or two villages before heavy weapons turn them into mince.

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. Without either of those factors population centers would've been much smaller, much more numerous and more scattered.

This will be something that affects our settlement pattern on other planets too.

With farms and food processing systems that are completely or nearly completely automated and the ability to ship their produce across a continent in days and thus before it spoils there is no incentive to create an expansive network of cities across a planet based on the availability of food. Worse, with the fact that trans newtonian technology apparently comes with nearly limitless energy for free you aren't even limited anymore to things like seasons, the sun and weather patterns; all production can be done indoors in vast glass houses with machinery rolling over tracks along beds of produce.

Instead, you are liable to see cities settled on and around places rich in mineral wealth and all food shipped in or produced in hydroponics systems, where the first mines on the planet are established along with the refinement plants for those minerals. Because a ship and harbour are much easier to build than an expansive railway network and you are going to need water anyway these cities are likely to be build on rivers and close to the coasts of large bodies of water where possible.

New mines will radiate out from these new cities but not be followed by new refinement plants unless production capacity becomes enough in demand to establish new plants and doing so is cheaper in the long run when done close to the mines. This is because transportation is dirt cheap with boats, and once the infrastructure cost has been sunk dirt cheap and fast with trains.


All of which boils down to one thing; once planetary population becomes numerous enough nearly all things worth fighting for are in urban environments. It doesn't matter if this means bridges, factories, government offices or something else; you cannot meaningfully impact an enemy's combat ability without having to go through urban environments to get there even if those things aren't in an urban environment.

And that means urban environments are the dominant terrain of those planets. That's where you fight.


Of course, urban terrain as dominant terrain is going to suck horribly for the civilians. Collateral damage is going to sky rocket in comparison to... pretty much every other type of dominant terrain.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 05, 2017, 08:27:15 PM
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.

This line of thought logically must mean that the terrain of all planets regardless of population and actual countryside is urban then because as you yourself describe the portion of the population that lives in cities depends on technology.

We don't live in cities today because there is no space in the countryside, but because it's more convenient and efficient, and extrapolating the tech to TN there is no job requiring you to live on the countryside that can't be automated or remote controlled from a city.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on November 06, 2017, 12:12:28 AM
I agree with the idea that Urban is the dominant terrain for ground combat purposes. However I think some combat should still occur on the pre urbanized dominant terrain type.
Title: Re: C# Aurora Changes Discussion
Post by: serger on November 06, 2017, 12:23:21 AM
It will be just one dominant terrain type. Not that realistic but much better than now.

Have a pair of suggestions, that can simplify situation:

1.
You can separate this conception of terrain into 3 different parameters:
a. Terrain type (geophysical, not geographical) - Extreme Plane, Rift, Mixed, Extreme Mountain - set by temperature and tectonics, and dictates possible biome types.
b. Biome type - None, Dry, Moderate, Humid - dictates possible habitation types.
c. Habitation type - None, Rural, Agglomeration, Surepurban.

2.
Really, I think, you need a concept of preferable zones, not a one dominant zone.
a. Habitation preferable zone - type (1.a,1.b) with a specification of planet surface percent, that can change during terraforming.
b. Defence preferable zone - type only, because some small percent of full land area will be enough to dig million-sized army on.

So, our Earth will be described as:
Mixed terrain type.
Habitation preferable zone - Plane Moderate, ~20%, Agglomeration.
Defence preferable zone - Mountain Humid (Jungle), as our StO defences will be set on their best possible positions, not on the most common.
Title: Re: C# Aurora Changes Discussion
Post by: serger on November 06, 2017, 12:51:08 AM
On-the-run note:
Cavernouse placing for defence. Depends on tectonics?
Title: Re: C# Aurora Changes Discussion
Post by: El Pip on November 06, 2017, 01:51:32 AM
"Ground units of species with certain types of home world may gain capabilities for free (if you are from a desert planet, you would gain Desert Warfare for free, for example)."

Could this be changed to the capability being based on where the Ground Force Training Facility is, not the homeworld? I like the idea of setting up training camps on various extreme worlds to train up the 17th "Smoking Jaguars" Jungle Division or the Ice Wolves of Proxima Brigade or whatever.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 06, 2017, 06:39:43 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 06, 2017, 07:26:56 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 06, 2017, 07:35:32 AM
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.

Re terrain, fantastic to hear.  I can't wait to try it out.  How fast does terrain change during terraforming?  Creating jungle mountains on your fortress world sounds great, but unless you're actively seeding, I can't see how it could grow in less than a couple centuries.  Even with seeding, it would probably take decades.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on November 06, 2017, 07:39:04 AM
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.

... Forest is forest.

It matters more how obstructive it is than it matters what exactly it's made off.

Also, a giant fungus forest won't ever be a thing unless there's a vast supply of fuel ready to be consumed by chemo-autotrophic lifeforms. Photosynthetic life is shaped the way it is for very good reasons.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on November 06, 2017, 09:29:53 AM
I love the new biomes, but think the system could be made even better by expanding it from just combat to economic effects as well. For example, in the real world biomes like mountains make travel difficult and construction expensive, impacting wealth generation.

Three obvious additions would be:

Wealth - any rift valley biome has a small wealth modifer (-10%?). Any mountain biome has a large wealth modifier (-20%?). Forest/jungle/swamp should impose a further 10% penalty on top of that. A jungle mountain colony will be expensive to maintain.
Population growth - jungles and swamps should have a population growth penalty to represent the generally unhealthy and hazardous environment.
Occupation strength - apply the biome to-hit modifer to occupation strength. Those subjugated aliens can hide just as well in the jungle as your troops can.

Changes like that give a further interesting choice to picking colony locations. A jungle mountain colony? Sure, its great to defend, but a savanna colony will grow faster and make more money.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 06, 2017, 10:10:09 AM
I did have construction speed modifiers in my original version but then removed on the basis it would be too much. Would be happy to put such economic modifiers back in if there is general demand.

Also, when I finally get around to biological warfare, plagues, etc.. there will be some downsides to terrain types such as Jungles.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on November 06, 2017, 10:34:40 AM
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!
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 06, 2017, 10:57:13 AM
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. )
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on November 06, 2017, 11:34:49 AM
Steve; will you be tying civilian good production to biomes? Not a hard lock of course, but certain dominant terrains might be more likely to produce certain types of goods in excess or have a shortage.

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. )

Yes, let's ignore the massive efficiency gain that is not having to dig your way through soil and rock and eschew walking on the surface through thin air. Alien biomes will have to be as plausible as terrestrial ones, and one of the biggest constraints is energy efficiency.
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 06, 2017, 11:40:09 AM
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.

I'm not saying that underground life is impossible, just that I wouldn't expect complex life to occur entirely underground. 
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 06, 2017, 11:59:59 AM
From what I understand we are descendent of rodents which survived from the Dinosaurs by digging underground not that long ago...

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?

Yes, let's ignore the massive efficiency gain that is not having to dig your way through soil and rock and eschew

What says the gravity must be the same or higher then Earths? In a low gravity world the soil would be significantly less packed and easier to dig through... Especially if it's ground up by big roots or alien mycelium.

If you can't survive on the surface it doesn't matter how much more energy efficient living there would be.
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 06, 2017, 12:06:17 PM
From what I understand we are descendent of rodents which survived from the Dinosaurs by digging underground not that long ago...

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, because moving underground isn't very energy-efficient, and being big means that you need to cover a lot of territory looking for food.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 06, 2017, 12:08:47 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on November 06, 2017, 12:19:46 PM
What says intelligent life must be as large as humans?

Brain capacity requirements for sapience.

To put it very simply, below a certain size of the brain it's impossible to achieve sapience.
Title: Re: C# Aurora Changes Discussion
Post by: serger on November 06, 2017, 12:23:39 PM
I think, byron is right. There is no chance to build some good story to explain how your kinky-mln-ton terraforming fleet grows the whole planet of jungle from that just-last-year-cryohell. You cannot grow your trees 10 times faster, if you just set 10 times more terraforming stations to work. Jungles must grow for decades, and I cannot see any reason for a player to wait that decades with Aurora terraforming techs.

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.
Title: Re: C# Aurora Changes Discussion
Post by: serger on November 06, 2017, 03:17:04 PM
Well, more thoughts around of KISS principle.
Because those different preferable zones that I suggested this morning - that was stupid, but wasn't simple. :)

And I agree with Hazard eventually: there is no way to have any other dominant terrain in decisive fight (for transnewtonian civilization colony) apart from urban and suburban.
Therefore, there is no place, no relevance for detailed biome terrain types in surface battle for the colony per se.
You just cannot dig your infantry in those jungle mountains, when your (or alien) cities are placed on more clean terrain spots.
And there is no sense at all in training infantry at this dominant terrain, because there are all those terrain types at the same planet of Earth! Just place your training camp at polar ice or at equatorial jungles, as you wish. Planets are not homogeneous - nor our Earth, nor other earth-like planets, nor those numerous tidal-locked planets (without dense atmosphere) of red dwarf stars especially!

For an StO transnewtonian fight, I can see only two factors, that I can cram into some Aurora AAR without disbelieve:
1. Atmosphere density, that is already realized in VB6.
2. Urban TN-masking. That is: if you see some noticeable TN signature on a planet from a space - you cannot understand if this signature is a military target, or it's civilian car, house, factory, etc, because those civilians use TN techs too. It's difficult to separate targets - not on the wild, but on the city, on the contrary! If you detect some heat or EM noise on the wild - you just aim it and blow it with your meson cannons, it's no problem at all, because if your fire control is precise enough to kill missiles at their velocities, than you aim any bunker without any trouble, the same moment you detect it, and there's no way to hinder you with such things as mountains and trees, that are just not TN signatures and cannot mask TN military activity, correspondingly. The problem is, that if you blow each signature on a planet - you will destroy the whole colony infrastructure, that is the most valuable asset on a planet, actually. Then you can just glass this planet with the same result.

So, Aurora troopers must fight on cities. And if you have low intel on the race that you attack, than you must have a penalty with separating military targets, because your men cannot understand alien common domestic forms and signs. It's all that must be count in decisive surface combat.

But! I see great area for guerrilla/covert operations in this dominant terrain! We have an ansibles, so our spies and guerrillas can hide in difficult terrain to dispatch ships and stations orbiting this planet, eavesdrop enemy com traffic, make covert diversions against your civillians and administration, and so on. More difficult terrain - more infantry you need to clean this planet from enemy spies and guerrillas, or just defend your urban sites, especially on enemy home planet biome. And that is where those biomes are very important! Intel, exhaustion warfare and microbiological attacks. There are very important things, that can force you to glass this planet eventually, instead of having such prolonged, costly and potentially catastrophically troubles.

So, there are only 2 biome marks that have relevance:
1. Race, that have this biome as native. Earth biome = human race biome. Period.
2. Density of biome, that is set to 100% on the homeworld and is rising from 0% to 100% by terraforming efforts in colonies. (And I think that terraforming is seeding your biome, not spurting inconceivable volumes of gases from nowhere.)
Title: Re: C# Aurora Changes Discussion
Post by: serger on November 06, 2017, 03:59:11 PM
Another on-the-run note:
Xenology skills of ground and naval officers can have an effect of lowering penalty of target discrimination when firing at alien colony.
Title: Re: C# Aurora Changes Discussion
Post by: Desdinova on November 06, 2017, 04:23:03 PM
Cool update. Still any chance we might see a test game before the new year?
Title: Re: C# Aurora Changes Discussion
Post by: serger on November 06, 2017, 04:36:37 PM
And here are some other sleepy notes at ground guerrilla combat / covert ops:
BG sci + xeno = bonuses on developing bio weapons against other races.
(CP+LG+PP)/3 sci + xeno = bonuses on developing coms virus weapons against other races.
Xeno + espy = bonuses on bio attacks (weapon samples must be delivered with ships, as VB6 spy teams).
Xeno + espy + coms + intel = bonuses on hacker attacks (weapon samples can be delivered with ansible com net - no need to fly on, if you have a spy team or guerrilla unit on enemy planet already).
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on November 06, 2017, 05:27:36 PM
Quote
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.
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on November 06, 2017, 08:28:57 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on November 06, 2017, 09:00:24 PM
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'm fairly ambivalent on the biome changes for more or less that reason. I don't think they're bad (I think planets being more than just a colony rating more or less cancels out the micromanagement), but I'm not really interested in them either.
Title: Re: C# Aurora Changes Discussion
Post by: Gyrfalcon on November 07, 2017, 01:19:56 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 07, 2017, 02:07:33 AM
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...

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?

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 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.
Title: Re: C# Aurora Changes Discussion
Post by: serger on November 07, 2017, 03:08:43 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on November 07, 2017, 06:23:17 AM
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?

Force disparity and lack of options to hide. Most Aurora conflicts will be similar to what happens when a Great Power bullies a smaller one in war; an isolated location (the planet) beset by vastly superior numbers of enemy combatants of peer or greater technological prowess. Frankly, the outcome of the battle isn't in doubt; the only question is the cost.

And modern day societies tend to be very squeamish when it comes to civilians caught in the crossfire. For defenders this is actually a good thing; for an attacker not to come of as evil they have to be very careful in their engagements, while the defender has in theory at least a massive potential intelligence advantage in all those eyes and ears that could call in when the attacker is on the move.

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.

That is an option if urban food production isn't a thing. However, that isn't really an option even when all food comes from more rural areas and the planetary population density is large enough; even outlying farms will be in the reach of city based rapid reaction forces, and getting to the next objective requires urban terrain anyway. And frankly? Cities are horrible to attack; too many angles and nearly every has a window to shoot from.

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.

The European tech advantage was so large that they managed to conquer and subjugate populations several times their own homeland's with tiny armies in comparison. The main reason you don't see that in the early 21st century is because the tech advantage is too expensive to exploit while the natives have acquired effective weaponry that's almost as good at hitting the most vulnerable sections of the conquering armies while the homefront is much more aware and much less willing to sacrifice lives on wars of conquest.

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.

Actually, energy production is a major weakspot in TN civilizations. They require so much of it it's impossible to hide, and losing it would majorly impact a TN civilization's ability to supply its cities.

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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on November 07, 2017, 10:02:08 AM
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.

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.

Designing ships for effective orbital combat is another potential consideration.


Quote
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

a lot depends on the actual mounts and FC the GTO weapons get though. we'll see.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 07, 2017, 10:25:01 AM
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)

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 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 ).


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...
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on November 07, 2017, 11:01:25 AM
I wouldn't complain if mesons were moved to a spoiler/ruins only weapon...

Maybe shift to a Starfire style system where there's a weapon that pierces shields and a weapon that pierces armor, but the one that pierces both has bigger downsides?

Though honestly I kind of feel we should wait to see the system in action before we get too worried about balance concerns. In my experience mesons are less effective than ones gut instinct indicates they should be, anyways.

Also this made me realize that microwave weapons would be an "ion cannon" sort of orbital defense; they wont destroy enemy ships on their own, but by taking out the electronics they'd limit further bombardment and therefor buy time (either for the ground forces or other, more damaging ground to orbit weapons).
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on November 07, 2017, 12:08:36 PM
Well, weapons are generic for ground units, using the highest level researched out of the options.
Title: Re: C# Aurora Changes Discussion
Post by: Scandinavian on November 07, 2017, 04:53:27 PM
One interesting question is what is the dominant terrain type on Earth? At the moment I am leaning toward Temperate Forest
Urban.

Not because it has the largest acreage, but because that's the terrain you will predominantly be fighting in if you attempt to take control of the industrial capacity and raw materials and pacify the indigenous population. Alternatively Steppe/Plains, if you bypass the urban centers and simply starve them out.

Going by acreage the dominant (non-ocean) terrain type is probably desert. It's just that with a very few exceptions the deserts are strategically irrelevant. Also, they mostly don't have any assets that an invader would miss if they just paved them over with nukes from orbit.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on November 07, 2017, 06:33:21 PM
I would say temperate forest fits for earth, but otoh there's lots of volcanic activity. Many habitable worlds may not have or be currently experiencing such vulcanism and so i am not sure I would classify Earth as a 'garden' world. You could make a pretty good argument for the terrain being rough.

Maybe it should be a matrix of vulcanism, vegetation strength, environmental extremity.  In that case it would be like Rough Temperate  Forest or somesuch. 

It's hard to reconcile this system as a seperate system from what determines colony cost...

Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on November 07, 2017, 06:42:39 PM
Urban.

...but because that's the terrain you will predominantly be fighting in...
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.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on November 07, 2017, 07:46:34 PM
In the new ground combat mechanics the real points of conflict are really the GTO units imo.
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on November 08, 2017, 12:14:18 AM
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 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 ).
I think I could respond to both of these together.

First of all, so what if it creates fleet roles? Ground combat itself is still boring. In my eyes, all the biomes really do is stop me from just skipping ground combat, either in part or entirely, whenever I don't feel like justifying it, by lowering the constant viability of nuking things from orbit. The defenders advantage is only a marginal expansion in depth, for me all that does is make something boring take longer and more resources to resolve. So, as if forcing me to do something I'd rather not wasn't enough, it has to take longer as well.

Making it more fun would mean having it function and be presented the way space combat is, in another window that shows the planet's surface, with your units moving around like ships. Formations (brigades, divisons, etc) would appear on the map the way fleets do. Without actually changing ground combat itself, it's still going to be the same banality it is at present. Contrary to the prevailing view of many A4x fans: Having more numbers to keep track of doesn't fundamentally make anything more engaging.
Title: Re: C# Aurora Changes Discussion
Post by: Felixg on November 08, 2017, 11:07:07 AM
In the new ground combat mechanics the real points of conflict are really the GTO units imo.

Makes sense, and offers some cool options if Steve allows for them, having fast blockade runner style dropships to deploy forces meant to take out GTO cannons before the main invasion lands.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on November 08, 2017, 02:24:03 PM
I believe its more like how the only thing that really matters on a planet is the GTO units. Once htey are eliminated the planet is at the mercy of orbiting vessels.   So all goals on a planet revolve around attacking and defending the GTO units.  After all, if you wanted to wreck the industry or cities, you could just nuke them or drop rocks or whatever.

pretty much like how Hoth was lost when the shield generator was destroyed
Title: Re: C# Aurora Changes Discussion
Post by: ardem on November 08, 2017, 10:50:10 PM
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


Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 09, 2017, 01:12:47 AM
C# progress isn't very fast at the moment due to other commitments and I am now away for another week. Hope to get back to normal speed soon :)
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 09, 2017, 01:16:35 AM
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

To hit penalties affect all units. However, certain unit capabilities such as Mountain Warfare or Jungle Warfare are only available to Infantry units.

I haven't decided on the penalties yet, but will probably prevent attack and greatly reduce rate of fire on defence. Surrender mechanics would be possible, in which case you could gain all the defenders equipment.
Title: Re: C# Aurora Changes Discussion
Post by: Gyrfalcon on November 09, 2017, 01:58:59 AM
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...)
Title: Re: C# Aurora Changes Discussion
Post by: Father Tim on November 09, 2017, 02:42:04 PM
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.

This was specifically in contrast to Starfire's ability to arrive at a planet day 1, nuke it 'til it glows day 8, and land a billion of your own colonists day 15.
Title: Re: C# Aurora Changes Discussion
Post by: Tree on November 09, 2017, 02:56:43 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on November 09, 2017, 03:21:35 PM
In practice, nuking ground units in Aurora VB isnt very expensive in terms of collateral damage, especially since you dont need to totally destroy them.  Just damage them enough for your ground troops, which you can ship in via commercial deathtraps because whynot.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on November 09, 2017, 11:43:03 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on November 10, 2017, 05:20:42 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on November 10, 2017, 05:54:21 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on November 10, 2017, 12:33:21 PM
Eh, could work, I'd like to be able to delete entries from such a list though to deal with typoes and suchnot.
Title: Re: C# Aurora Changes Discussion
Post by: StephR on November 10, 2017, 05:31:11 PM
Hi,

A feature that I have long wanted (and think would be really great for role-playing) would be the ability to de-activate certain techs when creating a new game.  For instance, if you wanted a Babylon 5 inspired game you could perhaps make missile techs beyond a certain level inaccessible to either the player of NPRs.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on November 11, 2017, 02:29:23 AM
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?

Edit: (http://www.pentarch.org/steve/Screenshots/Projects01.PNG)

At the bottom. I'm sure I saw something about that being a list of companies you've used or something. I don't remember exactly.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 13, 2017, 10:43:48 AM
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...)

As this is a complete rewrite the old rules don't exist in the code. You can still ignore ground combat and glass the planet in the new rules.

There will be three potential ways for ships to attack ground units:

1) Direct attack against STO units that have revealed themselves by firing (fortification still applies to the 'to hit' chance). Any hit by a missile or energy weapon will kill the target. Missiles will also cause environmental and collateral damage as they are a wide area effect weapon. Digging out well-fortified STO units with missile attack is going to be very costly in terms of additional damage and probably not worth it if you plan to use the planet afterwards.

2) General missile attack against the surface. Same collateral damage as above. I haven't decided yet exactly how to apply damage to ground units but I will probably choose a formation at random (or formations up to a total size determined by the square root of the warhead strength). I will cycle though the individual units attacked with a steadily decreasing damage strength (to simulate some units being further from the detonation) and use a damage strength vs a combination of fortification and armour to determine if they are destroyed. I may also allow units to 'disperse', which will reduce their effectiveness against other ground units but make them less vulnerable to general missile attack.

3) Orbital fire support with energy weapons. Ships will be tied into a forward fire direction unit on the ground and act as additional bombardment units, with their attack strength based on the weapons used.

In addition to the above, ships will be able to use the current rules for missile strikes on population centres.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on November 13, 2017, 11:05:08 AM
Please allow energy weapons to use the general missile attack rules as well. On the receiving end the difference is minimal.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 13, 2017, 11:32:51 AM
Please allow energy weapons to use the general missile attack rules as well. On the receiving end the difference is minimal.

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. This isn't ideal as ships should really take variable damage from missiles in that situation and a direct hit with a nuke should kill the ship. However, missiles are powerful enough without adding one hit, one kill capability. I guess one option when I get to coding ship to ship combat is to double warhead strength and use a range of damage instead of fixed amount (so the new strength is the max) but it might be simpler to leave it alone.

Also, nukes in space are far less powerful than nukes in atmosphere (well, less powerful in heat/blast but more powerful in radiation terms), which means I should vary bombardment damage based on atmospheric density but that adds another complication. So the current missile rules are a balance between realism and game play.

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.

It isn't perfect but it achieves the game play objective of requiring a ground invasion to take a planet relatively intact, while giving energy weapons a meaningful role in planetary combat (in fact, a much larger role in C# Aurora than VB6 Aurora)
Title: Re: C# Aurora Changes Discussion
Post by: bean on November 13, 2017, 12:17:58 PM
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. 
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 13, 2017, 12:27:22 PM
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.

My comments were based on the results of testing nuclear weapons in space:

https://history.nasa.gov/conghand/nuclear.htm
Title: Re: C# Aurora Changes Discussion
Post by: serger on November 13, 2017, 12:57:00 PM
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.

Therefore, missile AP pattern must be more, more flat - it must sandpaper nearest half of ship's armor, not digging out a crater (and this rule is also even simpler, than VB6 WH AP pattern rule).

Also, nukes in space are far less powerful than nukes in atmosphere (well, less powerful in heat/blast but more powerful in radiation terms)

They are not, really!
Atmospheric blast wave is very weak and soft comparing to blast wave, stamped in the hull by an instantaneous absorption of x-ray wave and, correspondingly, instantaneous thermal expansion of these layers of hull. In truth, vacuum blast will be delivered to a hull sharper and less weakened by medium absorption, than atmospheric blast. Do you remember Honorverse laserhead blasts? It is the same, as a blast of nuclear near miss - it's not a slow warming up and degradation of an armor. No, it is instantaneous warming up, when outer layer (1cm or 1m layer, depends on the power of warhead and distance) of hull is just transforming instantaneously into an overheated mass - plasma, gas or simply heated armor - and then hummer inner layers with a deadly sharp shock wave.
Look at it from the other side: in vacuum, energy of nuclear blast spreads as a near-spherical wave, and therefore weakened with 2nd power of the distance, while in atmosphere this energy is quickly (comparing with air blast front expansion velocity) redistributing by air reradiation, so it spreads near-uniformly by sphere volume (of the blast sphere), and therefore weakened with 3rd power of the distance, and wasting mostly (99+%) to the mushroom cloud heating and lifting (that is spectacular, but not dangerous for most of this warhead's targets).
Vacuum is an ideal medium for nuclear blast damage! It just spreads there more sharp, less stretched in the time, less distracted at the medium (not target) heating, shaking and degrading, and so on.

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.

Well, would you like to introduce weapon overheating? It can be represented by very simple rules. For example, overheating time = const * capacitor tech.
Title: Re: C# Aurora Changes Discussion
Post by: serger on November 13, 2017, 01:10:57 PM
My comments were based on the results of testing nuclear weapons in space:

https://history.nasa.gov/conghand/nuclear.htm
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.
(And if you are not defended by that durable thick armor - than you just killed with radiation, yes.)
This test is just not for TN spacecrafts. :)
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 13, 2017, 01:14:58 PM
The loss of an entire side of armour to a depth determined by range of blast was the model I used for Newtonian Aurora:

http://aurora2.pentarch.org/index.php?topic=4329.msg43459#msg43459

This project was based on very detailed mechanics but ultimately it died due to over-complexity. I might convert some of it into a tactical combat game at some point but it won't work strategically. There has to be some trade-off between realism and playability. The current missile damage mechanics work well.

Title: Re: C# Aurora Changes Discussion
Post by: bean on November 13, 2017, 01:31:43 PM
My comments were based on the results of testing nuclear weapons in space:

https://history.nasa.gov/conghand/nuclear.htm
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. 
See http://www.projectrho.com/public_html/rocket/spacegunconvent.php#id--Nukes_In_Space (http://www.projectrho.com/public_html/rocket/spacegunconvent.php#id--Nukes_In_Space) for more details.

Re the behavior of missiles and damage pattern, we can probably reconcile it with only a bit of handwaving.  Maybe there's some sort of focusing being used (see Casaba-Howitzer in the link above) or maybe TN materials are so tough it has to get close enough to start to show near-field effects. 
Title: Re: C# Aurora Changes Discussion
Post by: serger on November 13, 2017, 03:30:47 PM
Another sugestion that can limit the overusage of energy/kinetic weapon:
Every shot triggers a roll to maintenance incident, so firing vessels will consume supply much faster and have good chances of disabling weapon, if there is no sufficient supply value.
I think it will be very nice in any case, regardless of orbital bombardment problem.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on November 13, 2017, 05:04:57 PM
I always figured Aurora nukes were contact/extreme proximity detonated; with TN armour technology and protection schemes an armour system that allows that sort of nonsense may actually possible, instead of instantly killing the spaceship from the detonation shockwave propagating through the ship's armour layer and into the ship structure anyway.

I've previously opposed the idea of increasing maintenance requirements as weapons are used, even missile launchers, but it would be a valid manner of removing the threat of free planetary bombardment glassing a planet and readying it for later colonisation. However, if the breakdown is per shot, per gun, and separately calculated, and elegantly handles multiple weapons mounted in a turret it sounds good.

Of course, this leaves a different question; right now maintenance happens effectively instantly when the maintenance roll is made unless there's not enough MSP. Perhaps maintenance speed should depend in part on DC ratings? Given it's maintenance damage control should probably be considerably more effective and thus faster fixing stuff threatened by maintenance rolls, but it's a thing.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on November 13, 2017, 05:15:40 PM
i just don't think energy weapon maintenance failres are a meaningful way of restricting anything. At most, it stops a single light ship from devastating an entire civilization, temporarily, if there's not empty missile ships to feed it MSP. It's such an edge case i think it doesn't really matter. Another aspect is that your ship with a single light laser and 1000 msp is just as deadly in the long term as a ship with 10 lasers and 900 msp.
Title: Re: C# Aurora Changes Discussion
Post by: serger on November 13, 2017, 11:24:44 PM
Well, it can be fixed by increasing maintenance consumption and/or adding a feature of increasing maintenance clock with every shot also, but it will require serious rewriting of maintenance rules and I don't like as it sounds, to be honest.

So, maybe some form of weapon overheating mechanics will be more simple and handy. Or even just add a maintenance clock to every component as a class, with a clock increase at the time of battle usage (shot, radar on, shield on, battle power of engines*, squad jump, training exercises as "all included" for these points).

(*) it will require also introducing a nonlinear dependence of speed from power / fuel consumption
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on November 13, 2017, 11:48:55 PM
If we are talking about space ships with power systems that let them fire lasers comparable in performance to nuclear weapons every few seconds, I think the civilization-destroying potential is pretty obvious, even for small ships.  Nullifying that without any input from the defending player would be kindof counterproductive to the sci-fi nature of the game.  "oh yeah, we can nuke a planet all to hell, but our lasers that have the same energy output cant do smeg" 

Maybe give planets the ability to defend themselves better?  For instance, being able to build 'shield emitter' installations you can drop onto planets to let them mitigate a certain amount of energy/kinetic weapons fire directed at the surface?

Alternatively, require the player to manufacture 'high grade reactor fuel' to run energy weapons?  That way a energy weapon ship can run out of ammo in the same way missile ships can.  Make it marginally cheaper to make energy weapon fuel to compensate for the relatively short range, and I think that might be the better option potentially.  Given that each laser shot is discharging energy on par with nukes, I think it would be reasonable to say that you would need special fuel in order to facilitate that (to shove into your reactors).

Maybe it could be antimatter or something, then when a energy weapon ship gets hit it can have chain reactions of anti matter storage pods, which would be a bit neat.  That also makes it increasingly similar to missile ships though, so maybe not.
Title: Re: C# Aurora Changes Discussion
Post by: serger on November 14, 2017, 12:13:59 AM
It's more funny now, that a small kinetic fighter can now kill a civilization, having no supply line.
But I agree, that it's a question of micomanagement requirements, not only disbeleave.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on November 14, 2017, 02:11:16 AM
Right, but I'm saying given what that fighter is supposed to be able to do, thats completely credible.
Title: Re: C# Aurora Changes Discussion
Post by: serger on November 14, 2017, 03:40:52 AM
Hmmm. Well, if this fighter will consume 1kg of bullets per shot and will spit it out with, say, 60 000 km/s (0.2c), then every hit is an equivalent of 0.04kg mass excess, that is quite near to 1Mt nuclear warhead. So, really, every small fighter can bring enough bullets to kill planetary civilization with simple orbital bombardment.
But therefore it cannot be stopped by earth-like atmosphere! When this bullet with this velocity hits an atmosphere dense enough to stop it, that will be just an equivalent of an air nuclear explosion. Then this fighter cannot dig out bunkers in this planet's surface, but it can burn cities and rural areas to the ashes. So that is area damage, not a TN missile warhead, that is durable enough to pierce any atmosphere and knock out a bunker with near hit.

Aaaaand... if you have no such atmosphere, than your surface is open for natural bombardment with high energy space particles, so there is no surface cities and rural ares here. So there is no need in some complicated rules, just 3 cases:
1. Atmo is not dense enough for surface pop and commercial infrastructure. Thus, kinetic weapon have a point hit effect only (weakened by atmo density proportionally).
2. Atmo is dense enough for surface pop and infrastructure. Kinetic bombardment is able to kill those surface pop and infrastructure very effectively, but cannot affect TN-armored objects and underground infrastructure*. And it have no residual radiation effect, because there is just not enough mass in those bullets to deliver noticeable quantities of heavy unstable isotopes or pierce an atmo with enough energy to make those isotopes from the surface materials.
3. Atmo is dense enough to prevent pop and surface (not an underground) infrastructure. Thus, kinetic bombardment is unable to kill this pop nor dig out any bunker or underground infrastructure. You have to use mesons or missiles in this case.

(*) I mean - C# underground infrastructure, not VB6 one. IIRC, there will be atmo-ralated infrastructure, not a queer gravity-related, as in VB6.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on November 14, 2017, 05:15:12 AM
So with the lack of PDCs, will ground-to-space missile/meson combat become nonexistent? It's a bit strange to think that neither can be launched from a fortified position or silo, and that shipyards will be basically the be-all necessity for proper stationary defensive platforms on top of their necessity for basically every ship.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on November 14, 2017, 06:03:19 AM
no, regular beams will be able to fire STO from ground units.
Title: Re: C# Aurora Changes Discussion
Post by: iceball3 on November 14, 2017, 02:00:27 PM
no, regular beams will be able to fire STO from ground units.
Who unfortunately will have no armor saves against orbital bombardment.  :-\
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on November 14, 2017, 02:37:59 PM
They'll have fortification bonuses, which is arguably better ;)
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on November 19, 2017, 08:59:43 PM
And you can tow bases around. I build weapon platforms on Earth and then use tugs to get them to protect Mars, as an example.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on November 20, 2017, 12:40:41 AM
I like the look of planetary terrain. I appreciate that a moon like Io will qualify as Mountain rather than Barren. 

In terms of sci-fi tropes for terrain, the only one that jumps out at me as missing are frozen-ocean and quasi-frozen-ocean planets, like Europa.

It also makes me wonder if system generation applies a tidal heating tectonics bonus or somesuch to planets.

Will the terrain system play into colonization or colony cost at all?  It might also be a good way of assigning trade goods. For example, a Jungle planet could have medicinal plants, exotic animals, w/e. 

P.S. - are 'Forested Rift Valley' etc. supposed to have a lower tectonics minimum than regular rift valleys?
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on November 25, 2017, 02:14:22 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on November 27, 2017, 04:18:25 PM
The fortifications are not just foxholes and camouflage netting. You can build pretty effective bunkers and silos, dispersed formations utilizing them and so on, through the fortification level - it's just abstracted into it. Same as with space elevators and space ports - while you cannot build a specific space elevator, it is basically built once your space port level gets high enough, so it's abstracted into it.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on November 29, 2017, 07:10:07 PM
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)

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.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on November 29, 2017, 07:59:29 PM
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)

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.
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on November 29, 2017, 08:50:32 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on November 29, 2017, 10:59:24 PM
Trojan Gate series by John Ringo.

I think they're actually referring to the Human Reach series, which featured multiple underground lasers (one to a bunker), but each did indeed have multiple emitters it could fire out of to keep the orbital ships from targeting the laser and reactor itself.

The Trojan Gate series had something similar, but there it was a bunch of mirrors around the sun that directed a concentrated beam of light (not technically a laser) to a battlestation, which then aimed it at enemies with its own mirror (to avoid speed of light delays).
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on December 10, 2017, 02:54:21 PM
Questions which have become relevant:

How large for transportation is a Cargo Shuttle Station?
Has the Fighter weight limit been decreased to 500 tons from 1000 tons?
Can Troop Transport Ships smaller than 500 tons deliver troops on planet without a drop bay or shuttles?
Will there be a dependency check for the construction/operation of shipyards and habitats for a spaceport or Cargo Shuttle Station?
Title: Re: C# Aurora Changes Discussion
Post by: TheBawkHawk on December 10, 2017, 03:27:27 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on December 11, 2017, 01:32:28 PM
Quote
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?
Title: Re: C# Aurora Changes Discussion
Post by: boggo2300 on December 11, 2017, 02:45:39 PM
Wait, does this mean there's no point in building more than one or am I misunderstanding something?

That's exactly what that means 8)
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on December 11, 2017, 04:27:01 PM
What do spaceports do that cargo shuttle stations don't, if they're going to be separate?
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on December 11, 2017, 04:35:46 PM
Cargo Shuttles do cargo transport.

Spaceports do cargo, fuel and munitions.
Title: Re: C# Aurora Changes Discussion
Post by: vorpal+5 on December 13, 2017, 04:41:53 AM
Sorry, this question again.  8) Any plausible release date estimate, like 'probably before summer 2018', or 'after summer 2018', even in beta version? I just had yesterday evening an intense and thrilling moment in VB Aurora, with fighters breaking an enemy jump point patrol* and baring the long delay in each turn increment, it was just awesome (in my head, as there is no graphics, but who needs that?  ;D )

So I'm certainly really pumped up to see Aurora C# within 6 months from now!


*: dozens of fighters emerging from the jump point, some shot down and most zipping around and firing their twin gauss canons, while the survivors of a score of lifeboats nearing their end of life support watched the battle. Imagine the men after 12 days of waiting in space in their lifeboats see the rescue finally arrive! Glorious.
Title: Re: C# Aurora Changes Discussion
Post by: ardem on December 13, 2017, 08:45:01 PM
Summer 2018 would be great that awesome, considering summer 2018 for me is in 17 days.

LOL Dumb Northerners, they are so ignorant of us Southerners, but I am happy for you to wait till your Summer 2018, but I want my release in my summer.  :D

Title: Re: C# Aurora Changes Discussion
Post by: vorpal+5 on December 14, 2017, 12:22:29 AM
Haha... Indeed for me Summer starts in June, around the 20.  :D
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on December 14, 2017, 03:30:02 AM
I started this in March 2016, so already working on it for 21 months. The main problem is limited free time. If I had a solid few weeks I could probably complete most of it.

I would say it is 70-80% done. The major areas missing are combat and AI, plus I still haven't done about half the movement orders. Almost all of the construction phase is working though and most of the major windows are done. Still several minor windows to complete.

The recent work on ground combat and the interaction with naval combat has slowed the overall process by a few months, but I think the result will be worth it. I have still have a quote a lot of work to finish in this area before starting on the above.

The next major milestone after that will be adding the game creation process and starting the first C# game. At the moment I am still using my last VB6 campaign for all the testing.

As to when it will be completed, that depends on free time and enthusiasm and both of those things are difficult to forecast :)
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on December 14, 2017, 05:40:27 AM
As to when it will be completed, that depends on free time and enthusiasm and both of those things are difficult to forecast :)

I wish there was a way for us to donate free time and enthusiasm, then you would be finished in no time :)
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on December 14, 2017, 07:37:22 AM
I would say it is 70-80% done.

So with the 80/20 rule (the last 20% taking 80% of the time) we're only about 7 years out? :) :: ducks for cover ::

John
Title: Re: C# Aurora Changes Discussion
Post by: schroeam on December 14, 2017, 09:37:30 AM
While free time is much more difficult to cultivate, allow us to provide you with a nearly unlimited supply of enthusiasm. 

Adam.
Title: Re: C# Aurora Changes Discussion
Post by: Dr. Toboggan on December 14, 2017, 06:02:18 PM
Since I don't use jump tenders or squadron transit in my games, how hard would it be to include a size modifier to make jump engines smaller if squadron size were reduced to x1? I put jump engines on all my ships, and the current system seems to penalize those who don't use tenders.
Title: Re: C# Aurora Changes Discussion
Post by: vorpal+5 on December 15, 2017, 01:43:26 AM
Combat not reworked, additional ground operations code and AI to review and improve. Mmmmh, seems definitively past summer 2018. But one can hope.  ;D
Title: Re: C# Aurora Changes Discussion
Post by: Father Tim on December 18, 2017, 07:01:15 AM
According to the documentation I found, the C# release date is the 2020 olympics.
Title: Re: C# Aurora Changes Discussion
Post by: King-Salomon on December 19, 2017, 02:04:06 PM
@ 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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on December 19, 2017, 02:29:29 PM
@ 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 :)

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.

Title: Re: C# Aurora Changes Discussion
Post by: Hazard on December 19, 2017, 02:54:38 PM
That is a very good point :)

I'll have to add some restrictions on their use or reverse my decision to consume the population.

Impose a wealth production and population growth penalty while making them draw on the available workforce. If you can do it, make the labour camps independent of planetary cost, but impose a -.5% population growth penalty that's multiplied by the Habitability rating of the planet (minimum -.5%), or whatever rating happens at about 80% max population.

This would limit their utility, even on very compatible planets you'll have difficulty hitting the population cap. Add an unrest modifier dependent on how much of the planetary population is subjugated like this to force constant and extensive garrisons for suppressing slave populations. The growth penalty might be linked to population numbers. They also come with an additional potential disadvantage; while the weapons are much lower tech, being makeshift, a planet with a lot of labour camps that rebels might raise very large formations of light infantry with poor weapons and access to a limited number of industrial facilities like mines, construction facilities and infrastructure (if necessary) with a BP cost no greater than 10% the combined labour camp cost.

A rebellion like this will be defeated with even minimal effort. They are still quite dangerous.
Title: Re: C# Aurora Changes Discussion
Post by: King-Salomon on December 19, 2017, 03:26:30 PM
Quote from: Steve Walmsley link=topic=8497. msg105684#msg105684 date=1513715369
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
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on December 19, 2017, 03:59:03 PM
I would probably have a preference for making them use workers (although they could perhaps modify the number of people working in different industries - aftr all it won't just be taken from the manufacturing workforce - and maybe not use quite as many people as they do right now) but I'd behappy with #2. #1 just seems like people will exploit it to ridiculous degrees.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on December 19, 2017, 05:48:21 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on December 19, 2017, 06:13:16 PM
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

Yes, I like that idea. That neatly solves the planetary space problem while retaining everything else I wanted to include. 5K is probably enough as there will be some population used for  environmental and service sectors. You can still have some production on a small body with minimal infrastructure.

I've edited the original post to reflect that.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on December 19, 2017, 06:25:35 PM
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.

I'll find some way to have labour camps assist with fortification. In fact, the easiest might be to allow all construction factories to assist as well. That will make large worlds easier to defend, while construction-focused ground units will be needed for military bases and other low-population worlds.
Title: Re: C# Aurora Changes Discussion
Post by: clement on December 20, 2017, 10:20:30 AM
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?

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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on December 21, 2017, 09:33:06 AM
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?

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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: TinkerPox on December 21, 2017, 12:29:44 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on December 21, 2017, 07:54:50 PM
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.
Conceptually I like this.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on December 21, 2017, 10:03:34 PM
I agree, that sounds highly amusing.  Having anti infantry mechs deployed to keep the slaves under control is awesome.
Title: Re: C# Aurora Changes Discussion
Post by: Profugo Barbatus on December 22, 2017, 12:51:41 AM
Ten million bottom-tech rebel infantry vs a thousand superheavy vehicles loaded purely with antipersonnel weapons.  The Dakkahound Rises
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on December 22, 2017, 03:58:32 AM
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'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.



Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on December 22, 2017, 04:00:14 AM
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.

Sounds like fun :)  I will add something on these lines.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on December 22, 2017, 04:08:46 AM
Might also be cool to have some surviving slave rebels spawn if the building is destroyed by combat or collateral damage? Throw a few nukes at a slave colony and have enemy ground forces distracted with uprisings and chaos.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on December 22, 2017, 05:06:42 AM
While there's no issue with the rebels lagging behind in TN tech, mostly because you don't need high TN level tech to handle slave labourers so the guards won't be equipped with it, if possible one can base their tech level on the factory/mining tech level, representing inefficient but dangerous repurposed industrial equipment.

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...
Title: Re: C# Aurora Changes Discussion
Post by: TCD on December 22, 2017, 08:35:15 AM
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 suppose Steve will need to create rules for what happens when either the player or NPCs capture camps. Maybe you have the option to close down any camps, gaining the 100k population, but costing wealth to pay for their rehabilitation? Or maybe camps are automatically destroyed in an invasion as the inhabitants take advantage of the fighting to escape.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on December 22, 2017, 09:36:34 AM
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.

I'm in a similar situations, and what I am looking to do is to go down to 3-4 workdays a week on my regular job and start working "officially" 1-3 days a week with my hobby, allowing me to earn some money on it from home but still don't be alone and without a social life, or that my hobby turns dull. Ofcourse that depends on if the situation at your day job would allow that.

The best way to earn a bit of money from Aurora would probably be to release it as early access on Steam for €5-15, and this might also let you improve the UI, Graphics, Music by spending some of the income on hiring a few more resources to work on the areas you don't like if it sells alot of copies.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on December 22, 2017, 10:20:37 AM
Releasing it on steam would be a categorically terrible idea.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on December 22, 2017, 10:46:17 AM
What about setting up a patreon like Dwarf Fortress uses?
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on December 22, 2017, 03:00:07 PM
Releasing it on steam would be a categorically terrible idea.

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?  ??? ::)
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on December 22, 2017, 03:48:12 PM
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.

I'm fairly certain if you send money to Steve, he won't object. :)
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on December 22, 2017, 03:49:51 PM
I also seem to recall Steve saying he did not want to do something like that since then it would become a job and he'd be accountable to the users. As is, it is a hobby. :)
Title: Re: C# Aurora Changes Discussion
Post by: AngrySnwMnky on December 22, 2017, 03:50:58 PM
Quote from: alex_brunius link=topic=8497. msg105722#msg105722 date=1513976407
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.   
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on December 22, 2017, 05:05:15 PM
I think the point is that Steve doesn't want to sell it.   Selling something means customers and customers are demanding.

In which case he wouldn't want to earn money from it so he wouldn't follow the advice I gave either... Whats your point here?

I'm fairly certain if you send money to Steve, he won't object. :)

I do recall sending some money to help maintain the website already some time ago, which I do consider the next best thing to spend money improving the game considering how much great input from the forums Steve puts in the game.

If I had half as well paid job as he does, and I'd know it would help him spend alot more time on the game as a result I'd probably consider sending some more as well directly to him, but I suspect neither of that would be the case here.
Title: Re: C# Aurora Changes Discussion
Post by: swarm_sadist on December 22, 2017, 10:10:57 PM
I think the point is that Steve doesn't want to sell it.   Selling something means customers and customers are demanding.

Yeah, and we are demanding enough as it is.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on December 22, 2017, 10:48:01 PM
I think the point is that Steve doesn't want to sell it.   Selling something means customers and customers are demanding.

Yes and actually the "95% of people going there" IS the problem. Steam is full of people who don't understand development under the best of circumstance, that is full time devs who are putting everything into producing a polished game. Let alone a game with 1 dev that is known to be buggy and not finely balanced and with a learning cliff as steep as dwarf fortress (maybe even moreso) but is generally let slide because the community is quite forgiving due to the casual nature of development, the relatively small and helpful crowd and a number of other things.

Steve himself has said he doesn't want to go full time and the game would get torn apart if just put out into the general audience with a price of admission like that. It would turn the community toxic as we get flooded by newbies all asking the same questions over and over and people get tired of it and it would really necessitate steve working on the game full time and spending a bunch of time and effort on tedious fine-tuning of balancing regardless of whether he wants to or not. And there would be a lot of complaints (if you think putting a disclaimer in the description will stop that you're dreaming) regardless, which may discourage interaction with the community which wouldn't be good and all this may even lead to the death of the game.

So in short, it would be a terrible idea imo. Whilst what I said above may sound like doomsaying and maybe I was a little more pessimistic in tone than I intended, ultimately I think you'll find that this would be the result and it would likely ruin or kill the game. Steam is NOT the platform for a game like this even if you were going to sell it (which steve says he doesn't want to do anyway).
Title: Re: C# Aurora Changes Discussion
Post by: Tuna-Fish on December 23, 2017, 07:30:37 AM
So, my current campaign is a bit bogged by micromanagement, and I couldn't help but think that three orders would greatly reduce the necessary amount of clicks.  In order of importance:

1.  Tractor any ships.

Available on a fleet that contains at least one ship with tractor beams when targeting any other fleet.  When the fleet arrives at the target, every ship with a tractor beam in it attempts to tractor one ship from the target (in any order).  The order succeeds and execution of order list continues if at least one ship was tractored, if no ships were tractored (or target fleet no longer exists, etc) the order list of the fleet is cleared and a message is printed.

Rationale: Moving 200 terraforming satellites is a total pain currently, as you have to do many clicks per each satellite.  With this, you could set up the target fleet, take your tug fleet, order "tractor any ships at old terraforming fleet -> release tractored ships at new terraforming fleet" and hit repeat and the entire terraforming fleet gets moved (eventually).

2.  Unload cargo.

Available for fleets with any cargo space (possibly only if something occupies that space at this point in orders?) when targeting anything with any cargo space or a colony.  Attempts to unload everything from own cargo space to target.  Succeeds if after the order there is nothing in own cargo space (even if there was nothing to start with!), fails with message and order clearing if after this there is still something loaded.

Rationale: reduces clicks when moving around various stuff.  Allows the use of a single order to guarantee that after that the cargo space is clear.  No more fleets moving minerals with a third of their capacity because you forgot to unload that one jump gate construction module!

3.  Load any ship components

Available for fleets with some cargo space when targeting a colony.  Loads the cargo space full of any ship components (regardless of type) from the colony.  Succeeds if at least one component was loaded, fails with message if none were.

Rationale: right now, moving a random assortment of ship components takes a lot of clicks.

Would there be any chance of having something like those for C# Aurora?

Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on December 23, 2017, 11:33:47 AM
In terms of Steam, selling the game, etc., I want Aurora to be a hobby, rather than a job. As soon as I start trying to sell it, then I have certain obligations to support the customer base. I try to do that now but I don't have to. From my perspective, as soon as you have to do something, it is a job or a chore. When you can choose to do it, it is a hobby. Besides, if my goal was money, there are a lot easier ways to make money than developing a niche game for a relatively tiny audience :)

I know it might seem that full-time game developer would be fun. However, I've have been a professional musician (in the 1980s) and a professional poker player (from about 2004 - 2010), two jobs which were a lot of fun initially, but after a few years I eventually got bored of both and moved on to something else. I've also been a full-time developer before (C++ in the early nineties) and again I moved on to something else. Keeping Aurora as a hobby, and only having limited time to develop and play it, is what keeps me interested. I am very concerned if I worked on it full time, I would eventually lose interest.

BTW, if anyone wants any more details on the background and inspirations for Aurora, I did an interview with Rock, Paper, Shotgun a few years ago.

https://www.rockpapershotgun.com/2013/11/21/interview-aurora-the-4x-sci-fi-dwarf-fortress/#more-177034
Title: Re: C# Aurora Changes Discussion
Post by: albertismo on December 26, 2017, 04:53:57 AM
Quote from: Steve Walmsley link=topic=8497. msg105740#msg105740 date=1514050427
there are a lot easier ways to make money
as example??  ;D
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on December 26, 2017, 11:07:14 AM
as example??  ;D

Developing a broad-appeal game for a wide audience.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on December 26, 2017, 11:51:46 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on December 26, 2017, 03:09:48 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on December 26, 2017, 03:58:59 PM
But it's better than developing a niche game for a small audience. As far as making money  goes.

Depends. That's how minecraft started out...

Very few indie games or single man games aiming for a "broad-appeal game for a wide audience" get anywhere at all. They just become very bad clones of what the AAA devs already are doing 100 times better with 500 times more resources. To succeed with an indie game you need to make something unique ( like minecraft or Aurora ).
Title: Re: C# Aurora Changes Discussion
Post by: StephR on December 27, 2017, 04:41:31 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on December 27, 2017, 05:32:28 PM
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.

That doesn't exist at the moment, but definitely could be added.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 02, 2018, 01:18:05 PM
I'd quote it directly linked to the originating comment, but there's a typo I spotted.

Quote
So a unit with 4 armour would be 50% more expensive with 6 armour.

This should probably be a unit with 6 armour would be 50% more expensive than a unit 4 armour.


Static units should probably get access to the entire arsenal. Given that they can carry/field STO defense guns weighing in at hundreds of tons per piece the guns that can be carried by super and ultra heavy vehicles should not be an issue. It also means that there's an effective response to super heavies and ultra heavies with their heaviest armour ratings that does not demand super heavies or ultra heavies of your own.

This would be balanced by static units not being useful on the offense.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 02, 2018, 02:12:25 PM
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.


"So a unit with 4 armour would be 50% more expensive with 6 armour."

It's not a typo as it is true as stated, but I agree it could be worded more clearly.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 02, 2018, 04:45:56 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 02, 2018, 06:41:49 PM
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.

Light vehicles can only carry light armour and light components (light anti-tank, light bombardment, etc.). So a lot more things can kill a light vehicle and light vehicles would struggle to damage anything heavy. A static unit can mount heavy weapons, STO and CIWS.

For example, a heavy crew-served anti-personnel weapon (AP 2, Damage 1, Shots 6) would have about a 41% chance to kill a Light Vehicle (ARM 2, HP 3) vs 14% chance to kill a Vehicle (ARM 4, HP 4). A light anti-vehicle weapon would have 50% vs the light tank and 15% vs the medium tank. Against a heavier weapon (Heavy AV for example), the light vehicle actually has a slightly better survival rate. Having said that, the lighter vehicles are cheaper so a swarm strategy might work against light or medium vehicles. I do agree I was a little generous on the to hit modifier so I will reduce those a little.

You raise a good point about the fortification vs mobility. If a unit is fortified, it should not be able to use its mobility bonus. It will certainly be the case that for some units types in some terrain, using mobility is better than being fortified.

EDIT: I have reduced the mobility to hit modifiers and updated the rules post.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 02, 2018, 08:35:53 PM
I like the change where it's fortification or mobility, personally. Looking at it another way, one could think of the chance to hit multiplier as a sort of "minimum" fortification level. So infantry would have a minimum fortification of 1.66, light vehicles 2.5, etc. This both keeps fortified units from outperforming attackers by such a devastating margin (unless you attack someone with mostly static units, which I wouldn't recommend) and helps specialize units a bit; static units perform best when fortified by engineers, whereas light vehicles are almost as good on the offense as the defense and will make excellent shock troops for an invasion, and infantry and the heavier vehicles are fairly versatile. Though the different equipment options means you'll probably want at least some variety.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 02, 2018, 11:05:50 PM
Just giving it some more thought, and I had one question: Do weapons try to specifically target the units they're best against (ie anti-vehicle weapons targeting vehicles with the ideal armor for them to penetrate?). If you haven't settled on that yet, I have some advice that might sound odd. I think the answer should be "no".

As weird as it sounds that heavy anti-tank rounds should be occasionally killing single infantry, I think in practice it works out better, because otherwise it makes it inefficient to mix unit types.

As an example, lets say I invade with a thousand vehicles, and the enemy has 100 anti infantry weapons and 100 anti-vehicle weapons. The hundred anti-vehicle weapons will fire effectively, and the hundred anti-infantry weapons will fire at low efficiency. This works out to 50% of the weapons being efficient.

If I invade with 500 vehicles and 4500 infantry, then either the enemy weapons fire randomly, or they fire on good targets. If they fire on good targets, 100% of them are being efficient. If they fire randomly, then statistically 90 out of 100 anti-infantry weapons hit infantry and 10 out of 100 anti-vehicle weapons hit vehicles; in total, 50% of the weapons are being used efficiently, same as if the invasion was only vehicles.

Obviously the numbers are pretty made up, and in practice you'll probably want mixed armies for other reasons, but I think the general theory is sound; having weapons pick the best targets will make formations of mixed unit sizes much more vulnerable than formations of a single unit size.

Edit: Though thinking about it it might make sense to have units more or less likely to be targeted based on size, to keep it from being easy to clog up targeting with lots of cheap infantry. So against 1000 size 5 troops and 100 size 50 tanks, both would be equally likely to be targeted (since each tank would be 10x as likely to be targeted as each trooper).
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 03, 2018, 05:49:35 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 03, 2018, 06:09:19 AM
If there should be preferential targeting it might be a good place to add in mobility. An AT gun on a vehicle will be much better at targeting intended target due to it's mobility then a static (towed) or infantry AT weapon.

( Although this does get a bit weird when we use vehicles with multiple weapons, mobility won't help them target both Heavy tanks and Infantry at the same time with 2 different weapon types ).
Title: Re: C# Aurora Changes Discussion
Post by: King-Salomon on January 03, 2018, 06:38:08 AM
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"
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on January 03, 2018, 06:48:46 AM
I agree it shouldn't be totally random nor totally most efficient. It should be weighted a bit towards targeting the right thing with a decentish chance of targeting the wrong type.
Title: Re: C# Aurora Changes Discussion
Post by: El Pip on January 03, 2018, 08:37:23 AM
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;

* Fortification Buster - Negates a level of enemy unit fortification
* Engineer - Increases the maximum fortification of friendly units
* Terrain specialist - Slightly offsets terrain effects
* Master Trainer - Morale gain and recovery is faster/Higher max morale
* Unit Type Specialist - Boosts a certain unit type damage (say armoured or infantry) but not the other types.
* Expert Staff Officer - Small boost to all units damage.

If you added chance to hit the 'best' target, then you'd add on a Recon Expert / Target specialism.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 03, 2018, 11:06:01 AM
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.

Yes, this is quite tricky :)

Some background first. Formations can be assigned one of five 'field positions': Front-line Defence, Front-line Attack, Support, Support Counter-Battery or Rear Echelon.

Only a formation in one of the two front-line field positions can engage an enemy with direct fire. A formation in a Support position can be assigned to a front-line formation that includes a Unit with a Forward Fire Direction component. Any bombardment weapons with the supporting formation will take part in any combat in which its assigned front-line formation is engaged. If the supporting unit has a field position of Support Counter-Battery, it will instead engage any hostile bombardment formations that attack its assigned front-line formation. An FFD component can control a formation in a Support position, a single orbiting ship or six fighters in ground attack mode. If multiple FFDs are present in a formation, then multiple supporting formations, ships or fighters can be assigned. Any formation in a Rear-Echelon position will not engage in combat (at least not voluntarily). Formations selecting Front-line Attack will engage in more intense combat rounds (as well any formations engaged against them).

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.

I am comfortable with the above. The tricky part is determining who fires at who.

Initially I considered pairing off opposing front-line formations against one another (with multiple vs 1 if numbers are not equal) and retaining those pairings over time. Those formations would then engage one another, with each formation element automatically selecting an opposing element to target. However, I ran into some issues. Firstly, ensuring the formations of the larger side are relatively equally distributed (in terms of size) against the opposing formations, in a situation where formations can be of quite disparate sizes, is not straightforward, especially if I try to retain consistency for formation hierarchy purposes (with formations in the same hierarchy generally facing the same opposing formations). Secondly, as the number of formations changes (because a front-line formation is destroyed or withdrawn, or because a support unit finds itself on the front line), the pairing would have to be re-allocated. That might even lead to situations where a player was 'gaming the system' by moving formations in and out of the front line to create more favourable match-ups.

Another option is for each formation on the side with the greater number of formations to target a random hostile formation and then those targeted formations would in turn target their attackers. However, that could leave some formations unengaged.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 03, 2018, 01:46:07 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on January 03, 2018, 02:00:08 PM
Surely it being purely random would essentially make formations redundant though since it doesn't really matter how they're organised if they're just randomly firing at the closest thing?

One way to avoid players abusing a virtual front line with pairings to constantly get the best engagements is to make any shifting of a unit back from the front line to 1. take time and 2. give a status modifier like "retreating" that causes it to take significantly more casualties than it otherwise would (eg. eliminating defensive bonuses and giving it a penalty to attack) so that there is a price to pay for pulling your units back to the support line and then sending them back into combat.
Title: Re: C# Aurora Changes Discussion
Post by: Scandinavian on January 03, 2018, 03:30:43 PM
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.

This would also have the advantage of further differentiating the different unit types: Dug-in infantry for staying power, light vehicles to prevent flanking (or hit support echelons), heavy vehicles for punching through enemy lines (assuming that attacking requires the formation to leave its fortifications), static units for fire support and orbital defense.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on January 03, 2018, 05:42:08 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 03, 2018, 05:45:47 PM
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).

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.

Quote
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.

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.

Quote
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.

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

Quote
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.

No problem at all. The reason I post my intentions is to get exactly this type of constructive criticism before I commit to anything.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 03, 2018, 05:57:33 PM
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.

You need a mixture at a strategic level for several reasons. For example, it will be cheaper to hold a front-line with infantry / static and it will be much easier to occupy conquered territory with infantry. In certain types of terrain infantry will have huge advantages on defence. However, because vehicles provide a high concentration of combat power for a given size, they will be very effective at inflicting high damage on single enemy formations (which can affect morale).

At a tactical level, I think mixed formation will be more effective as explained in my previous post, but not so much so that specialised formations are not useful as well. It will depend on the situation and the type of enemy. I intend to produce some specialised ground forces for certain enemies and different tactics will be required against different enemies.

In terms of formation hierarchies, formations in a support position can only be assigned to provide bombardment support for formations within the same hierarchy and AA units will only protect formations within the same hierarchy. Light AA protects own formation, Medium AA protects own plus any immediate subordinate formations and Heavy AA protects own plus two levels of subordinates. I know I haven't got into this level of detail yet in the rules posts.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on January 03, 2018, 07:31:23 PM
How will this system handle POW's and captured equipment?

We should probably expect absolutely gigantic numbers of POW's compared to what we get in naval warfare.  Anything that will kill a ship will also kill most of the crew instantly, but a ground unit is much more likely to be defeated but not exterminated.  For instance in real life, +100,000 German soldiers surrendered at the end of the Battle of Stalingrad.

Further, in real life captured equipment was often used in battle.  The German Pz38t was a mostly-unmodified captured Czech tank, for instance.  Will there be some system for using captured equipment?  Maybe even POW's should be usable; a not-insignificant number of Soviets captured during Operation Barbarossa were sent back to the front to fight for the Germans.

Will there be some system for capturing ships stuck in a shipyard, either for maintenance or under construction?  I am fairly certain there are a few examples of ships in WW2 getting captured by ground troops who took the port before they could get underway.  I also know the British sank much of the French fleet in port, fearing the Germans would capture it.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 03, 2018, 08:47:58 PM
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.

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.

Quote
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.

a) is exactly my point. Giving any amount of preferential targeting at all means that a unit does more damage when it engages a formation with the type of target most suited to some of its weapons. And mixed formations are obviously more likely to contain one of those targets.

Let's say a unit has 10 anti-infantry, 10 anti-light vehicle, and 10 anti-heavy tank weapons, just to make up numbers.

If it targets a unit containing only infantry, light vehicles, or heavy tanks, then those respective 10 weapons will hit at best efficiency, and the other 20 will hit at reduced efficiency. The exact numbers don't really matter here, but we can call it 10 efficient and 20 inefficient.

If it targets a unit containing half infantry and half heavy tanks, and weapon assignment was completely random, then 5 anti-infantry weapons would hit infantry, 5 anti-heavy tank weapons would hit heavy tanks, and the remaining 20 weapons would hit inefficient targets. Note that this is exactly the same as if it targeted a unit containing only one type of target.

If instead each weapon hit the preferred target 2 out of 3 times, then on average 6.66 of those anti-infantry weapons would hit infantry, 6.66 of the anti-heavy tank weapons would hit heavy tanks, and the remaining 16.66 weapons would hit inefficient targets. The end result is 13.33 "efficient" hits, which means the unit does more damage against formations with more than one type of target. The specifics of the weapons or the formation don't matter here; it also applies if the target formation has infantry, light vehicles, and heavy tanks.

So end result:

If targeting is random, attacking a formation with multiple types of targets (say, infantry, light vehicles, and heavy vehicles) is statistically the same as attacking a formation with only one type of target. This means players have no reason not to make the formations however they like (within reason). Even though intuitively it sounds weird that completely random targeting should make things worse, it's not the case.

If targeting is preferential, even by just 1%, then attacking a formation with multiple targets will inflict more damage than attacking a formation with only one type of target. The end result is that you are motivated to use single target formations whenever possible.

This isn't something you can get around by changing the numbers; it's a universal truth if the combat works like you're describing.

Quote
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

Ok, let's take what you say and imagine that it's a formation of 40 Leman Russ and 180 hellhounds... and make it vs a formation of 40 Leman Russ *and* a separate formation of 180 hellhounds.

50% of the time, the mixed formation targets the Leman Russ tanks, and 50% of the time it targets the hellhounds. On average, this means the Heavy Anti-Vehicle weapons are firing on the Leman Russ tanks half the time.

The Leman Russ and Hellhound tanks target the mixed formation 100% of the time, and when they do, one third of the time the the heavy anti-vehicle weapons fire on the hellhounds (as you note), and two thirds of the time they'll fire on the Leman Russ tanks. This means that on average they're firing on the Leman Russ (the preferred target) 66% of the time.

The end result is that the two specialized formations will kill the Leman Russ tanks 33% faster. The hellhounds will die a little slower (though if the Hellhound tanks had anti- medium vehicle weapons, the mixed formation would be losing both Leman Russ and Hellhounds faster than the specialized ones, since the Leman Russ would take 66% of the anti-heavy weapons and the Hellhounds would take 66% of the anti-medium weapons.)

If, on the other hand, weapon targeting was completely random, then the specialized formations would target the mixed formation 100% of the time, and have a 50% chance to fire on the Leman Russ tanks.. exactly the same as the mixed formation firing back at the specialized ones. It's balanced, and I think you shouldn't fix what isn't broken.

Edit: Please note that you might look at the above and think you need to give formations a preference to targeting other formations that their weapons work best against. This is a bad idea and will work even worse than what you have now; instead of splitting heavy vehicles and infantry into their own formations, it would mean you'd want to never have infantry and heavy tanks on the same planet if you could avoid it, and would make the ground combat system much worse as a whole, at least in my opinion. It would also mean that you'd generally want a formation to be limited to weapons specializing in hitting a certain target, which is really the situation now except reversed (specializing formation by weapon instead of by target)
Title: Re: C# Aurora Changes Discussion
Post by: Scandinavian on January 03, 2018, 08:55:14 PM
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.

If instead we randomize formation level targeting by formation count you incentivize spamming unled single-unit formations, so that's obviously undesirable (unless you insist that all formations must have at least one HQ element, which would make a certain amount of sense). But even aside from that, by splitting the formation the absolute probability of the enemy targeting the non-preferred element changes from 1/3N to 1/(N+1), where N is the total number of formations in the targeted echelon. 1/3N is less than 1/(N+1) for all positive integers, so this will always result in a greater probability of the non-preferred element being targeted. The total effect is more difficult to calculate because splitting the formation also affects (reduces) the probability of other formations being hit, but since those formations will ceteris paribus be composed of a mix of preferred and non-preferred targets, the fact that the probability of hitting the non-preferred target increases shows that splitting the formation is strictly favorable.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 04, 2018, 06:41:54 AM
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.

OK, you've convinced me :)

I ran the two scenarios, assuming a base hit chance of 20%. When targeting is completely random, both scenarios result in identical losses. When preferred targeting is involved, the specialised shooting at the mixed does better. Thanks for sticking with this :)

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.).

(http://www.pentarch.org/steve/Screenshots/Scenario02.PNG)
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 04, 2018, 12:34:43 PM
A follow-up to the previous post. I've been considering the combat mechanics for a few different situations:

1) How to protect support formations / rear echelon while still having a chance for them to be attacked.
2) How to provide the option to have attacking formations with more intense combat, while allowing some formations on the same side to hold position and retain their fortification bonus.
3) How should the other side respond to attacking formations?

So I think I have a relatively simple way to handle this (which changes some of what I originally intended), but I wanted to give everyone chance to poke holes in it.

1) As per the previous post, each front-line formation will randomly select a formation on the opposing side for combat. This randomisation will be weighted by the size of the opposing formation. For example, if opposing formations are 10k tons, 6k tons and 4k tons, there will be a 50%, 30% and 20% chance respectively to engage them.

2) This will not be reciprocal and, while every front-line formation will attack, there is no guarantee that every front-line formation will be attacked. I looked at a number of ways to link up opposing formations so they shoot at each other rather than both choosing different targets, but I kept running into difficulties in ensuring a fair match-up (different numbers of formations with different sizes). Over time, a random distribution should be the same effect as matching anyway and it is far simpler.

3) There are five field position options for formations: Front-line Defence, Front-line Attack, Support, Support Counter-battery and Rear Echelon.

4) Any Support formations or fighters/ships assigned to a friendly front-line formation will also attack the same opposing formation. Any Support Counter-battery formations assigned to a friendly front-line formation will attack any opposing support formation that attacks their own assign front-line formation. Rear Echelon will not be involved in direct combat but may provide air defence.

5) During the weighting for random formation selection, all opposing formations will be included as potential targets, including any formations assigned to Support roles or Rear Echelon. Any formation assigned to Front-Line Attack will be treated as 3x larger than normal. Any formations assigned to Support roles will be treated as 25% normal size, while any assigned to Rear-Echelon will be treated as 5% normal size. This means enemy forces will tend to concentrate on formations attacking them, followed by other front-line formations, but with a small chance of attacking supporting formations (RP'd as local breakthrough). Attacks against support formations become less likely with relatively large front-line forces.  Attacks against support formations also become less likely if your own all or part of your own forces are attacking.

6) Any formations assigned to Front-Line Attack will have 3x the normal number of attacks and use 5x the amount of maintenance supplies (Ground Formations will use wealth for peace-time maintenance plus maintenance supplies when in combat - exact mechanics TBD) but will lose their fortification bonus and are likely to face fire from more enemy formations than normal (including some which may also be in Front-Line Attack mode). This should allow the allocation of limited supplies to key offensive formations (such as armour), while allowing infantry to hold a more defensive, fortified position. Or, an all out attack is another option.

The major question here is around the Front-Line Attack mechanic. Does this seem OK? Any attacking formation is going to take a lot of fire but also dish it out. In fact, overall the side with more attacking formations will have more firepower than normal, although they are sacrificing the benefits of fortification to do so and running through maintenance supplies much more quickly. From the defender perspective, any formations in Front-Line Defence mode will only be firing at the normal (more efficient rate) rate, although more of them will be concentrating their fire on the attacking formations so those attacking formations will take more damage. Of course, the 'defender' in this situation can have his own formations in Front-Line Attack mechanic mode, increasing firepower at the expense of fortification.

I think the Front-Line Attack mechanic gives assaulting forces a different alternative to grinding out a siege and gives defenders some tricky decisions about whether to respond in kind or hold their positions again heavy fire, hoping the attackers run out of maintenance supplies. It also means stockpiling MSP will become very important for a successful campaign.

What I am concerned about is whether this will lead to both sides always using Front-Line Attack instead of Front-Line Defence. However, I think there are enough variables, especially on rough terrain worlds and with the high MSP requirements, to make this a real decision for both sides.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on January 04, 2018, 01:37:26 PM
I think we could possibly use a mechanic that would simulate encirclements.  The biggest advantage an attacking force has is that they can concentrate their forces more effectively; they decide where the attack will be so they can allocate all their forces there.  Defenders must defend the whole line.  The biggest disadvantage attackers have is that any unit that breaks through is at risk of becoming encircled.

Perhaps we could have a system where during combat, a unit that fails a "prevent encirclement" check could take the same penalties they would if they ran out of supplies.  This check would be easier to pass, but still not guaranteed, for defenders.

I think this could be a good way to ensure that people don't always all-in Front-line Attack.  Sometimes the bonus to fire rate will not be worth the risk of being encircled.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 04, 2018, 02:01:07 PM
Hum, front line attack alters the math of the combat a bit, though not really in a specifically unbalanced way.

It makes fortification less important; unless fortification would be reducing the hits you take by a factor of 3 or more, there's a certain advantage in it, since in the grand picture doing 3x as much damage and taking 3x as much damage results in the same losses, just quicker. If a fight were one formation vs one formation, you could think of front line attack as giving the unit a temporary fortification 3*(1/hit mod) and making the battle go quicker; a formation of static units on attack (hit modifier of 1) vs a formation of static units with fortification 3 would be inflicting the same number of hits on each other.

However, this is only true if all or most of your army is on front line attack, because those targets are weighted more heavily. If you have one formation on front line attack and the rest remaining fortified, then more attacks are going to hit the more vulnerable attacking formation and fewer the fortified positions, which is heavily disadvantageous. So with a few specific exceptions you're either going to want most of your units on front line attack or none of them.

Speaking of exceptions, there's the light vehicles. Light vehicles have a to hit modified of .4, which means on front line attack they'd be on equal footing with a formation on fortification 7.5. This means they'd make excellent candidates for front line attack, and should almost always be used this way (even if none of the rest of the army is). Normal vehicles will also benefit from being on front line attack unless well fortified on a world with a fortification bonus (equivalent of Fortification 5).

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.
Title: Re: C# Aurora Changes Discussion
Post by: King-Salomon on January 04, 2018, 02:08:39 PM
Can't say a lot about this as I can't guess how it will result in the game for real..

my biggest concern would be something almost all games of this kind have - that ground combat is only about "attrition".. that the strongest side will always win and nearly never have any looses at all... if this system would result in looses for the attacker even if he has a 3-4x advantage it would be OK for me...


about encirclements... what about this: only a random % of all units are attacking instead of 100% and random % defending units are defending.. (would be realistic too as nearly never a whole front is attacking at the same time but spearheads are build to try to break through...) a higher random % would be a big offensive, a small % a small spearhead trying to break through or test the defences...   (maybe a commander skill to get a small bonus could be integrated - or a bad commander a malus... a big breakthrough could get a bonus for the next round, a defeat a malus, weather could give unit types a bonus/malus... etcpp) 

fex:   random # before a fight attacker = 71, defender = 38  --> every unit on both sides rolls W100 ... attacking side units with 72-100 roll will participate (including these support units which are linked with them etc), commander skill might add +X to the roll, special abilities might add +X to the roll - defending side units with roll 39-100 participate... + boni ... all vehicles get -X because of strong rain...)

this would allow the side with bad luck and low % of its forces standing again a high % of the opposite forces a "encirclement" like situation were it could be easily annihilated even if it is part of the bigger army... so even the winner might having looses every planet he wants to conquer - even if he has overwhelming numbers...

in the example above the attacker - even with a great adventage in numbers in general might face a much stronger opponent in the battleround and got bloodied in the assault, next assault he might break through a thin line of defence units, annihilating the small part of the defending units completely


about MSP - would the invader be able to resupply his forces from space (if he has the orbit secured)? this would leed the defender more or less the only party who would have a MSP shortage as the invader might get resupply very easily if  his logistic is good...
would  the defender be able to use his facilities on the defending planet to create MSP and resupply his units?



Title: Re: C# Aurora Changes Discussion
Post by: sublight on January 04, 2018, 02:27:35 PM
I'm thinking the attacker shot multiplier shouldn't exceed the median maximum self fortification bonus [2x] unless some other drawback is introduced.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 04, 2018, 02:35:28 PM
The reason why mixed units are superior IRL is due to combined arms. The whole becomes greater then the sum of it's parts since they can fight together and provide mutual support.

Infantry can use some of the tanks as cover when advancing and at the same time the Tanks use the Infantry to not get ambushed.


Having some basic level of this might be a good idea as a future improvement later on ( Infantry + Direct fire Vehicles + Support/Indirect fire ).
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 04, 2018, 02:44:06 PM
Defending forces on the frontline should probably get a boost from Fortification when it comes to determining Size for targeting calculations. It is harder to break through a well constructed defensive line after all.

This could lead to another specialty, 'Infiltration Troops' that would be a an Infantry only specialty that lets them ignore the boost fortification gives.

The result of this is that fortifying your troops on the defense helps with keeping your support units intact, but attackers do have a way around the problem.


I do like the randomised targeting mechanics though; it can even become useful to put a few heavy units on the Support or Front Line Defense roles. I mean 'Ah ha, we broke through the front line and are now engaging... crap. That's a formation of superheavies.'


I do share my worries about what the attack multiplier would mean with Frontline-Attack formations. I'd rather put Frontline orders on three options instead.

1)Defense, which lets a unit benefit from Fortification bonuses and if not attacked lets them fire a much decreased number of shots at an enemy Frontline target. This would be the typical low level skirmishing you see on stalemated frontlines without a major operation in play. When both sides are on Frontline Defense battles are slow due to Fortification and low number of shots. Formations on Defense get a boost to their Size when determining which unit gets attacked depending on Fortification; represents how hard it can get to avoid engaging a prepared position the better sited and prepared it is.
2) Attack, drops Fortification bonuses but can engage enemy formations normally. Formations are neither larger nor smaller when it comes to targeting Formations.
3) Assault, drops Fortification and Mobility defense bonuses for a small boost in number of shots fired even if it also increases supply consumption. Mobility defense bonus is waved on account of it  being rather hard to hide and dodge incoming fire when you are pressing the attack and moving straight into enemy lines of fire. Formations on assault are considered much larger than normal for targeting calculations. Heavier units care less about being on an Assault footing due to their lower Mobility defense bonus, this is deliberate.
Title: Re: C# Aurora Changes Discussion
Post by: jonw on January 04, 2018, 03:35:43 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Coleslaw on January 04, 2018, 03:43:13 PM
Quote from: Steve Walmsley link=topic=8497.  msg105873#msg105873 date=1515069714
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.  ). 

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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 04, 2018, 03:48:48 PM
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?

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.

I haven't yet calculated the rate of consumption.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 04, 2018, 03:50:25 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 04, 2018, 03:51:40 PM
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?

I haven't coded the bonuses or the assignment yet :)

Would make sense to assign to formations with the appropriate unit types.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 04, 2018, 04:17:31 PM
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.

I'd go instead for establishing a supply point consumption per shot for every weapon (heavier/higher tech weapons consume more) and that every Formation maintains a stockpile of several rounds of combat. Formations draw a (tiny) amount of MSP every round to convert to supply points and replenish their stores but this is not enough to maintain continuous operations; it'd need a week or more to replenish completely emptied stores to full without logistical unit support. Logistical units increase the conversion rate, speeding up resupply, but even an all infantry unit should need a major logistical component to support indefinite combat. Logistical units directly attached to an HQ can offer logistical support for subordinate units but favour their own formation and the formations with the most depleted stocks, in that order. Frontline units that are completely dry of supply points are rotated to Support positions if able.

Please don't use consumable supply units unless supply units can be constructed by units without construction equipment out of MSP available on planet.

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.
Title: Re: C# Aurora Changes Discussion
Post by: jonw on January 04, 2018, 04:29:37 PM
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.

Yeah, thats what worries me. No sane commander would commit an invasion force without knowing at least what approximate strength of resistance there was. Of course this may not be exact - maybe something like officer intelligence determines the size of uncertainty about a number, so you're always inexact, and high levels should give more specific info? Or some ship component like orbital imaging suite?
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 04, 2018, 05:26:05 PM
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.

I like the idea of a combat engineer unit that can reduce fortification levels, but the balancing would be tricky. I assume fortification is tracked by element instead of individual unit? So a combat engineer attack would need to be balanced around reducing a 10 infantry element's fortification more than a 50 static element's.
Title: Re: C# Aurora Changes Discussion
Post by: ardem on January 04, 2018, 05:57:46 PM
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.

------------------------------------------

There is a way you can get around the stack of doom issues with combat frontage. What I mean by that is while attacking a smaller enemy you can only put in a number of unit that the frontage allows by about 3-4 sides, which only gives you a maximum of 3 to 4 unit more then the defending unit on defence. However a smart defender tries to reduce these odds with terrain, holding a mountain pass etc etc. You can keep it simple and say no more the 3 to 1 odds on the front line, or you can make it a little more complex such as below

- give all units a frontage value, Heavier units and mobile units tend to have a broader frontage, then leg infantry.
- Give the defending general a Random roll based on skill and terrain of the planet to set a maximum force multiplier x defenders highest combined frontage number based on stance
- Add the frontage for the defending units add the Force multiplier and are given a maximum frontage number for front line troops.
- Support get the same multiplier but added up separately.


To get around the player or AI that decides to make only one front line unit and 20 support, the frontage could be based on the highest frontage of any of the stances, rather then front line troops.

This would be more complex for the you steve then the player, all they need to do is check frontage and assign appropriately, if there is more then the frontage allows you random assign units to the front until the frontage can fill no more.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 04, 2018, 06:05:59 PM
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.

You will still have normal sensor readings (as in VB6) to know the approximate size of the enemy force. Just not any detail on individual unit capability.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 04, 2018, 06:19:20 PM
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.

Defender firing first shouldn't be necessary. Fortifications will give a huge advantage to a well-established defender.

Length of fight is a very good question. A lot will depend on the base chance to hit before any modifications, plus the frequency of the ground combat phases. I would like to have combat phases more frequently then the construction phase, so that there is interaction with fighters and orbital fire support. I am leaning toward 5-10% for the base chance to hit. I need to run some scenarios to see how that turns out. I want to avoid the VB6 situation where it can take weeks to eliminate a massively outclassed defender, although if that defender has fortifications in good terrain it should take a while. However, I also want to allow for longer sieges where the sides are relatively evenly matched.

One formation type I am considering is guerrilla, where they do little damage but are difficult to kill and cause unrest.
Title: Re: C# Aurora Changes Discussion
Post by: ardem on January 04, 2018, 06:22:51 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 04, 2018, 06:32:14 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 04, 2018, 06:35:44 PM
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.

I already played around with this type of concept. The issue is too much variability in formation sizes. It would have to be a certain size of frontage rather than number of formations and then it becomes hard to match everything up, plus formations may change position and then everything gets recalculated.

With a weighted random assignment based on the sizes of the defending formations, a similar outcome should be achieved. If one side has absolutely overwhelming numbers, then it should be a relatively short fight anyway.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 04, 2018, 08:29:54 PM
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.

I don't particularly have a problem with units never being forced to come out of their fortifications to attack. Though I suppose if you wanted to, you could make it so units not on attack would never hit rear echelon or support units. Then an attacker on a planet might want to set their units on attack in order to try to take out the Space to Orbit weaponry.

Alternately/additionally, units on the attack could have a chance to take territory. This could result in both reducing enemy fortification level and/or taking some fraction of the enemy's buildings and population. Then the defenders would have to eventually leave their fortifications to counter-attack if they wanted the stuff back.

If combat is at a relatively fast pace, and fortification can be lost (either in general, or when the enemy is on the attack), then that makes fortification act sort of like temporary bonus hitpoints. If you were to land 1000 infantry against 500 infantry with fortification 4, for instance, then after awhile you might have taken some territory and reduced their fortification to 1.5, but lost 600 troops doing it to their 200. At that point you'd probably want to cancel the attack and start fortifying yourself (maybe with those construction factories you captured!), or risk the enemy launching a counter attack on your weakened forces. Makes the fight a little more than just straight attrition, anyways
Title: Re: C# Aurora Changes Discussion
Post by: MagusXIX on January 04, 2018, 08:49:50 PM
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.

I see two purposes for coming out from behind defenses. Infiltration (ie espionage/sabotage) and, more rarely, when you believe you can drive the besiegers off. I feel like intelligence should play a big part in whether to attack or not, and that certainty about who would win in a fight should be something to strive for and backed by mechanics of some sort.

I see it playing out that an invading army lands (or I've occupied long enough as an attacker.) I keep my ground forces hidden in their fortifications which makes it very difficult for the enemy to get a bead on exactly what and how much I have. Is recon a thing already? If not, I'd consider it. The time to come out and attack is when your military intelligence informs you that you've got a solid chance at actually winning the sortie.

Fog of war, combined with methods to clear the fog, should solve a lot more problems than it creates, especially with regard to knowing when and where to attack. If you're simply outclassed by a besieger, then it's just not a good idea to unhide and that's okay. Make your enemy fight for every inch and hope backup arrives, or surrender.
Title: Re: C# Aurora Changes Discussion
Post by: DIT_grue on January 04, 2018, 10:00:20 PM
Open to suggestion about a mechanic where coming out to attack has a useful advantage in certain situations.

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 be any much 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...
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 04, 2018, 10:17:08 PM
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 be any much 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...

While this would seem to make sense at first glance, it kind of messes with the implicit design detail that formations can be any size, and should function identically in combat regardless of size.

It's tricky to explain, but to give an example... let's say I have a bunch of front line units and some rear echelon formations with my STO weapons and such. Assume that the front line units mean each enemy formation has a 5% chance of attacking the rear formations.

Now, obviously the more formations the enemy has the more chances they have of hitting the 5% chance. But whether it's one enemy formation or 50 enemy formations, on average their weapons will be firing on the STO units 5% of the time. The enemy might think it was better to have 10 5% chances of doing 1 damage than 1 5% chance of doing 10 damage, but overall it isn't a huge difference

But if we assume the rear echelon formations can fire back at attackers, the reverse isn't true. If I have 5 formations in the rear, and one enemy formation hits the 5%, then one of those five formations returns fire. If I have 1 giant formation in the rear, and one enemy hits the 5%, then every single unit I have in the rear echelon gets the chance to return fire.

So it's probably better that rear echelon units can never return fire. If you want troops defending them, probably best to put them on the front line; this will both let them inflict casualties every round instead of just when they're attacked, and reduce the chance of enemy attackers actually hitting the rear echelon units.
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on January 04, 2018, 10:34:42 PM
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?

Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 05, 2018, 05:45:12 AM
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?

Every class will now have a specific rank, rather than a range of ranks.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 05, 2018, 06:13:59 AM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 05, 2018, 06:53:10 AM
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 be any much 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...

While any troops attached to the support formation won't be able to fire back (for the reasons given by Bremen), they do provide some security because the attacker may attack them instead of the more valuable artillery. Target selection is based on element size, not cost, so infantry provide a cheap way of 'padding' the formation to reduce the chance that the more valuable units are attacked.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on January 05, 2018, 08:53:27 AM
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.

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?)


Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on January 05, 2018, 09:18:22 AM
A few thoughts:

- I don't see a reason to give attackers multipliers on the number of attacks v defenders. The motivation to select attack should be because the forces need to achieve the capture of the planet etc not because they get bonuses. Attackers should be at a disadvantage to dug in troops when being attacked directly so needing comparatively larger forces to do this makes sense.

- For fortified forces my view would be they simply can't attack but can just respond to attacks against them. If an attacker decides to fortify I would expect that to be because they need to wait for further forces to arrive, to conserve supplies or to leave it to the artillery in the support role to do more damage to the front line opposing forces before attacking and hence would not be attacking directly at that point.

- For those fortified forces I would have thought they need a mobilisation period depending on how well dug in they are to move from passive to active fighting. I'd expect that they would suffer penalties of some form whilst in that mobilisation period. The same would be true for those trying to dig in.

- Given the whole attacking planets piece is going to be key it would be nice to have some sort of beach head mechanics. Whether that would mean initial landing troops are in deployment phase with penalties as above for a period of time or some other mechanic would be good. Perhaps also have a state for a rear echelon unit that is beachhead and that controls supplies and rate of supplies drop. As with other rear echelon units if the opposing side breaks through they can damage the beach head and damage flow of maintenance etc. Finally on this the beachhead may limit the flow of maintenance so in large attacks you may need multiple beach heads and hence have more units initially exposed to that deployment phase in order to have enough supply lines.

- 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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 05, 2018, 09:20:43 AM
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?)

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.

This is turning out to be a trickier problem than I anticipated :)

I think leaving all front-line on same weight for targeting, regardless of attack or defence status, but allowing only attack to have a chance to damage support formations or fortifications (or perhaps morale) is probably fine. The strategic attacker can either use attack tactically to try to win more quickly, or fortify his own positions and fight a gradual war of attrition (or a combination of the two).
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 05, 2018, 09:27:19 AM
- 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.

There will be different fighter missions, including ground support, air superiority and flak-suppression.
Title: Re: C# Aurora Changes Discussion
Post by: sublight on January 05, 2018, 12:55:52 PM
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.

I still like this concept. Maybe the the huge formation issue could be migrated by adding a counter tracking the number of individual elements as [enaged/unengaged]? Attackers will naturally try to focus fire and engage say, half their tonnage, when attacking leaving the remaining defenders out of position for high-intensity participation. If they overrun (fully engage) their randomly paired defending formation then a new defender (or support) unit is selected for partial/full engagement on that front.

The defenders can then sit and take it, order one or more units to abandon their fortifications and sortie out against the attackers to even the odds, or else order one or more attacked units to withdraw under fire.

For example say you build a new a new Guard Armored Regiment and then immediately scrap all other conventional forces to reclaim the manpower once it finishes fortifying. I find that both threatening and a mistakenly easy target and order my Guard Infantry regiment to attack. My 6882 tons engages 3441+tons (~38.5%) of the Armored regiment. Say, [22x Leman, 7x Hellhound, 4x Hydra... and the Macherious]. While you could leave everything fortified perhaps you dislike seeing the Macherious command tank as an early target, so you order the armored regiment to abandon their fortification and fully engage. In the next round I then might order all my fortified conventional forces to up and charge the now unfortified line in hopes they could turn the battle. Conversely if I had attacked with everything first then my overwhelming numbers of crappy conventionally forces would likely have just as fully engaged the Armored regiment while leaving them their full fortification bonuses.


In this case being the first to attack is advantageous
Title: Re: C# Aurora Changes Discussion
Post by: TCD on January 05, 2018, 01:17:55 PM
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.

In effect the formations become just for rp colour and logistical/transportation reasons, the game treats them as a single army for combat.
 

 
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 05, 2018, 02:32:40 PM
If you want to make it so two forces both set on defense wont fight, the easy way to do that is to just make it so units on defense only fire on units on attack (units on attack would engage both units on defense and attack). Then eliminate/massively reduce the supply penalty for attack, but give attackers a chance to take territory and damage rear echelon units, and it should be decently balanced. No worries about different formation sizes (however the attacker would still want either every front line formation on attack or none of them, lest they be defeated in detail).

This throws a wrench into the battle, though, in that attackers could land on a planet and just begin to fortify. If attackers permanently lose their fortification bonus, this wouldn't gain them much (they'd still have to attack eventually), but if attackers retain their fortification bonus but just don't use it on the attack, it means the attacker would want to wait to fortify before attacking, so they could retreat to the fortifications if the battle doesn't go well.

You could add another layer to that by allowing bombardment units to still hit units on defense, so that if both sides choose defend then their artillery will still pound positions, but that wouldn't work with the support approach you were going for before where support formations can be assigned a front line formation and will fire on anyone that engages them. However, this risks making defense too hard since it would allow the enemy to land ground forces, not attack, and just keep bombarding the defending troops (including from orbit) until they gave up and launched their own assault.

Overall, it's a bit of a more complex scenario but one with potential balance issues.


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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 05, 2018, 02:58:10 PM
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.

I think the above is on the lies of where I am heading. Defence/fortification on both sides is an attrition fight. I've starting coding on the basis that only formations on attack (normal weight) can potentially select Support Formations (25% weight) and Rear Echelon (5%). In addition, when units are killed by an attacking formation they take double morale penalty and attacking formations gain double morale bonus when killing the enemy. So Attacking is a way to wear down the enemy support structure (morale and support formations) and boost your own formations into high quality more quickly.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 05, 2018, 04:54:08 PM
Just taking a stab at an idea:

When attacking, units have a chance to overrun positions. This is represented by reducing fortification levels when that fortification protects a unit.

When an attack is made against a unit, the hit chance is rolled, then it's compared against armor and hp. If the attack would be a kill (IE it penetrates armor and successfully rolls vs the enemy hitpoints), then the target's fortification level is rolled as normal. If the unit would die, it dies. If the fortification level saves the unit, it loses a level of fortification. If both sides are defending I think this probably shouldn't happen, to give an advantage to attacking (it obviously wont happen to a unit when it's attacking since it wont have any fortification to roll anyways).

(Since I assume fortification is tracked by element, this would be averaged out; ie if an element has 100 infantry at fortification 3, and fortification saves 1 soldier from an attack, the fortification is reduced by .01, to 2.99)

Units on attack maintain (but don't use) their current fortification value, so you can attack with a unit for awhile then send it back to its previous fortifications. However, units on attack don't gain fortification, while units on the defense will gradually rebuild up to their maximum self fortification value. There's a balance there; units on defense increase their fortification, units on attack reduce enemy fortification.

In other words, fortification works kind of like extra lives. Or if you play D&D, the mirror image spell. This means that when an invasion force first arrives, the defenders have a very large advantage, but if the attackers strike hard and fast they'll wear down the advantage. It also means fortification will never get completely "worn down" to 1; the lower it gets, the more losses you'll take but the less often the fortifications will get lowered. It also keeps construction units relevant in combat, by slowly rebuilding the "extra lives".
Title: Re: C# Aurora Changes Discussion
Post by: King-Salomon on January 06, 2018, 05:12:47 AM
not sure if it is even possible to solve the land combat satisfying at all in a 4X game... :(

I don't know any 4x game with an even "acceptable" ground combat mechanic... just look at what Stellaris is trying to chance in 2.0...

it's always "the bigger army wins, most likely with no casualties at all"...

there is a point why ground combat is very basic in the games like Endless Space, Stellaris, etcpp

...

If you want to make the enormous chances and detailed parts you want to integrate in C# really work, I am afraid a whole new "land combat" is needed - much more detailed - something like the space combat were you move and order individuel troops/formations to do tasks.. attacks... etcpp ... a simplyfied ground combat as now with this much detail in formation design, stats etc is not going to work I am afraid.. if there would be an easy solution, I am thinking the big AAA games would have used it as the "ground combat" part is an enormous problem for all the 4X games -.-

but to add a detailed ground combat would be a whole game for itself - not sure if it would be worth..

---

what I am thinking... maybe making the chances to ground combat in 2 steps...

step 1 including the stuff with formations, design etc as planed atm but with more or less a "ground combat" as in VB6 without too much chances - not optimal but workable - to not delay C# more than nessassary

Step 2 after the first C# version is done, integrating a better ground combat mechanic in the first 1-2 patches...

this would a) not delay C# too much and b) would give Steve and the community time to make a concept of ground combat wich might work without time pressure

...

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
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 06, 2018, 08:08:11 AM
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

Part of the reason for the more detailed ground design process is to give players more investment in, and attachment to, their ground forces. Other reasons includes creating more interesting invasion mechanics at a strategic level, replacing PDCs, having more interesting planetary environments and making planets harder to conquer. It isn't primarily about detailed combat mechanics at the same level as naval combat. They mechanics need to give the player some consequential decisions during combat and be heavily influenced by the player's strategic design choices. There is quite of lot of detail during combat resolution, with the various factors influencing the to hit role, but most of that happens after the player makes his decision.

Title: Re: C# Aurora Changes Discussion
Post by: Froggiest1982 on January 07, 2018, 02:36:37 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 07, 2018, 02:26:27 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on January 07, 2018, 02:37:19 PM
Are the logistics units themselves used up, or the MSP they carry?

I think it should only be the MSP being used up, so I can resupply them with cargo holds or maintenance storage bays instead of the comparatively-heavy troop transport module.  It also doesn't make much sense RP-wise for the units themselves to be used up.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 07, 2018, 02:45:00 PM
I've been working on a new component for fighters (the fighter combat pod), which would be used by fighters on ground combat missions. A fighter with the appropriate order would fly to a planet (facing any defences en route) and enter low-level ground combat mode (which makes it immune to STO units but vulnerable to AA units during the ground combat phase). The pod is designed in the Create Research Project window and replicates some of the functions of the ground combat components, such as bombardment or anti-air. Anti-air in this case effectively allows the fighter to dogfight hostile fighters near the planetary surface. Each pod would fulfil one function so you would need to design different fighters to fulfil different missions (air superiority, ground support, anti-tank).

My initial thought to was to make the pods one use only but much smaller than the equivalent ground combat component (20% size), so the fighter would have a significant impact and then return to reload. However, that raised some issues.

1) If it is one use only, that means stepping through the increments necessary to get the fighters to and from the planet (past the planetary defences), which means ground combat involves a lot more micromanagement.
2) Depending on the interval of ground combat phases (and I am thinking hours not days), with the necessary micromanagement the fighter could actually return and reload for every combat phase, which would make it very powerful in situations without planetary defences.

So, I think the fighters will have to have modules similar to those of ground units, which allows them to stay in the fight until shot down or they choose to pull out. Effectively energy weapons rather than bombs. I would like to have some limitation though on their endurance though so I have a couple of ideas:

1) They also use MSP when firing so would be limited to how much MSP they carry
2) Being in low level combat uses fuel (although less than in space) so once their fuel runs low they would need to return home.

In either or both of these cases, the fighters would stay in combat for a while, which removes a lot of the micromanagement but still create the flavour of sending carrier-based fighters to support the ground battle.

How does that sound?
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 07, 2018, 03:50:12 PM
I'm still of the opinion that fighters should use the same weapons in both space combat and ground combat, to be honest, or else they're really two separate things (as you're pretty much never going to want a fighter with both types of weapons).

Of those two options, though, I'd definitely go with the fuel. Exact amount of fuel use would probably depend on how slow ground combat is compared to space combat.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 07, 2018, 04:01:19 PM
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.

If you want to do it like this either let ground units or ships use MSP to create logistics units or just have all MSP usage in a ground combat round tallied and subtracted from the total planetary stockpile of the faction, fractional MSP lost on chance basis.

Consumable logistics units are otherwise really inconvenient.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 07, 2018, 04:42:11 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on January 07, 2018, 04:57:05 PM
Re logistics I was thinking you would have a unit with a rated msp per combat tick and then a separate tracking of the actual Msp. You would then require sufficient logi units to deliver supplies and as support or rear echelon units they would be open to attack.

On the fighters I like the idea of fuel limiting endurance. Could you possibly have the combat pod as a missile design rather than a new component so as to allow you to stock your carriers with different options for your fighters rather than building lots of different fighters. The fighter specific component would then be the weapons bay to hold combat pod.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on January 07, 2018, 05:20:17 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: vorpal+5 on January 07, 2018, 11:47:00 PM
I would tend to agree that somehow, logistic units could also be formed up by using MSP either from ships or planets. It can be an order with some delay and a cost in fuel and or wealth, compared to having the logistic unit prebuild as a ground unit (or industry project?). Because it might feel silly or frustrating to having tons of MSPs around but no logistic units.

As for fighters, lets not forget that an atmospheric-capable fighter vs a exclusively spaceborne one is probably no something build in the same way, in particular if the atmosphere is dense/corrosive, and also because wings are more convenient in atmosphere compared to space  ;). So having to dedicate some space on a fighter to allow for atmospheric fighting is ok for me. But this goes beyond just a weaponized pod.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 08, 2018, 07:56:56 AM
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.

Something I would like to see when it comes to logistics is variable rates of consumption.

Real Grounds units are not going to consume at 100% their full rate until they have 0 left and then go from 100% efficiency to X% (very low) efficiency overnight / in a single update tick.

Ideally they should see a gradual reduction since when supply go below say X% of max capacity they can carry with them and no deliveries are in sight they will start to conserve their remaining stock to last longer. This means you can start to see an upcoming supply shortage well in advance and preempt it, and at first the penalty will not be so big, units will just consume a bit less and fight a slight bit worse. But if left ignored it will grow worse and worse, similar to how dept can ruin your economy gradually if ignored or how life support failures gradually can spiral out of control.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on January 08, 2018, 09:50:49 AM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 08, 2018, 10:47:46 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on January 08, 2018, 11:42:44 AM
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.

Bombers aren't the main way of carrying nukes any more. ICBM's are and fighters can't shoot them down so it doesn't explain the focus on high quality strike fighters and ASFs.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on January 08, 2018, 12:10:29 PM
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.

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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 08, 2018, 12:14:08 PM
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.

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.

Every fighter generation since the invention of flight has, in some manner, vastly outperformed the preceding generation of fighters. To the point that you see silly kill/death ratios even in simulations and training flights. Because of this it's much cheaper (not to mention much better for morale) to buy high quality aircraft from the current generation than anything else for the same duties.
Title: Re: C# Aurora Changes Discussion
Post by: Scandinavian on January 08, 2018, 12:47:27 PM
Some thoughts and observations on combat aircraft:
- It should be possible to base (and resupply) them on planets, with the appropriate infrastructure (starports, landing fields, etc.).
- It should be possible for attacking ground forces to construct and/or capture such infrastructure.
- I am a fan of the planes having to return to rearm after every run unless adequate groundside infrastructure is in place, provided the associated micromanagement is adequately automated (which should not be an insurmountable challenge).
- Aircraft should be more expensive than equivalent killing power in artillery and AA elements.
- Aircraft should be assigned to a forward fire control unit in order to function in a ground attack capacity, except perhaps against vehicles that are not dug in. In practice, even total air dominance without a groundside element has proven practically worthless against a properly dug in opponent (see, e.g., NATO's 1999 war to partition Serbia).
- As long as air power is restricted to killing aircraft and moving vehicles or running CAS in support of a forward fire control element, I see no problem with air power being the king of battle. Blasting moving vehicles and flying CAS is what air power is great at.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on January 08, 2018, 01:45:49 PM
I also like the idea of using fuel to limit fighter deployment. I see no justifiable reason that explain why fighters can only be equipped with bombs, so I think using fuel makes a lot of sense.

In fact, I think you could argue that fighters in an atmosphere would have a higher fuel consumption than in space? You have to overcome gravity and friction after all. Or is the argument that in an atmosphere you fly at a small fraction of your total speed? (What would it actually mean to have an atmospheric fighter that flies at 20,000 km/s?)
Title: Re: C# Aurora Changes Discussion
Post by: ardem on January 08, 2018, 05:37:02 PM
Steve what is the fortification creation time, my feeling is is should be an exponential time. What I mean by that you get to the first 1/4 of maximum really quickly (a week), next 1/2 a little longer and the last 1/4 a long time (years) this shows the different type of fortifications. Such a trench to concrete facilities.

Also the destruction should be quite quickly though, I hate to see maximum fortification achieved by attacker within a month, or destruction of the fortification go, then in the next tick it ramps up again, it should be related to how long real world fortifications take.


I think to help you with the space fighter craft situation, you should make it easy on yourself and the players. If you want fighter involved in land based air combat, you must have a spaceport or landing facility. You must assign fighters to that facility and you must assign them to attack or defence. If you do all this, you can make it tick just like all the other ground forces. then when you finished they get assigned to space again.

As far as weapons, I think you a ground combat pod, which is not very big, (10-50t) that uses MSP resources for attack and defence. Fighter on defence only go into attack if opposing fighter attack and not subject to ground fire, else they go into a repair stage. Attack fighters are subject to ground fire and opposing fighters.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on January 08, 2018, 06:53:59 PM
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.

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.

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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 09, 2018, 03:32:39 AM
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.

If USA devoted 10% of GDP to the task, properly adapted the airplanes for mass production and had a few years time to convert factories ( as during WW2 ) then I have no doubt at all it could be done. Some technical solutions dependent on very rare or expensive materials (stealth for example) might need to be redesigned or use replacement material to cope, but other then that there are no problems at all what so ever.

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.


So let's correlate Automobile production of the 1930s and today and compare the increase.
From about 4 million cars per year peak before WW2 to about 40 million cars per year today, that is roughly x10 increase in output, despite the fact that a car today is a technological and electronic marvel of twice the weight and using some cutting edge consumer electronics.

Another way to look at those numbers is how much money all those cars production is worth.

At a production of 40 million cars per year today if we assume the average car costs $35k that's $1400 billion worth of production capacity per year. Let's as an experiment say all that was invested into producing F-35s instead and we assume that due to economies of scale cost per plane would drop to 20% of current ( which is a conservative estimation based on what mathematical production models suggests would happen when you increase investments by that amount). This means each F-35 would cost $17 million fly-away cost and that $1400000 million can then buy you 82'000 airplanes PER YEAR.

USA could if they wanted produce even more airplanes per year using modern technology then what was done during WW2, if there was a need to do such a thing.

If there is a need for such a thing however, and how the American public would react if you told them the money they paid for a new car is going into a fighter plane instead... that is a totally separate discussion!
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 09, 2018, 07:23:49 AM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 09, 2018, 07:27:18 AM
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.

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..

Title: Re: C# Aurora Changes Discussion
Post by: The_frog on January 09, 2018, 07:48:34 AM
Quote
Open to suggestion about a mechanic where coming out to attack has a useful advantage in certain situations.

I have been reading up on this idea and I can see some similarities between a sally action and a boarding action.  (speed and morale)

There are a few scenarios in which a sally action can prove beneficial:

-During the initial stages of an invasion in which the attacker has not had the opportunity to dig in: combat has not yet become a siege but the defending party could initiate a sally action to disrupt enemy actions, delaying opponents in order to give the defenders more time to dig themselves in.  Could be interesting if a planet has to prepare its defenses from a surprise attack.  Like with effort to set up the Atlantic Wall, fortifying a planet should be a timely and costly affair.  That said, digging out forces from a fortified position requires the attacker to have a larger army. 

-When the invasion force has landed and actually managed to surrounded the defending party, sally actions can be used to achieve a few other objectives as well.  One of them is sabotage.  Due to the abstract nature of the game a sally action can mean a great many things.  Elite troops might even have technology capable of entering the enemy camps undetected through a secret gate, a tunnel system or even teleportation.  From my standpoint I do not find it impossible for the defenders to be able to reach the attackers siege equipment or a forward command post.  The overall damage of a sally action might by comparatively minor but when successful should provide a proportionally large hit on enemy morale.  Another reason to sally forth is to act as a distraction for allied forces; a costly affair for the defenders but when the defenders have allies outside a besieged strongpoint, drawing in attacker could give their allies the opportunity to launch an attack against the attacker's flank or rear.

-Another scenario consists of two 'equal' forces.  Each party has managed to dig themselves in and neither party has the strength to dislodge the other from their respective fortifications.  the role of defender and attacker switches constantly.  Think WW I trenchwarfare.  Sally action in this situation can range from sabotage misssons, all the way up to mass charges across open grounds.  Sabotage missions deal little damage, but affect morale, while charges provides a change to break through. , but the attacker risks losing many troops in the process, while the defenders risk a breakdown of moral; their troops panicing and abandoning their defences.

It might also be an idea to add special strategic actions to commanders, granting benefits to forces with experienced commanders. 

I have to saw that I like the changes to the army structure and I wonder if a similar abstract system can be implemented on planets: depending on the planet's size and available resources you build a number of nameable slots, which you can fill with structures like factories or farms.  Perhaps with enough time, resources and technology you can keep on building, increasing the size of a planet, changing it into a superstructure.  I imagine an empire stripping entire systems to expand their home planet.
Title: Re: C# Aurora Changes Discussion
Post by: Dungeonfrog on January 09, 2018, 07:53:03 AM
My session ended while I was typing apparantly.  Here's the fixed verison.

Quote
Open to suggestion about a mechanic where coming out to attack has a useful advantage in certain situations.

I have been reading up on this idea and I can see some similarities between a sally action and a boarding action. 

There are a few scenarios in which a sally action can prove beneficial:

-During the initial stages of an invasion in which the attacker has not had the opportunity to dig in: combat has not yet become a siege but the defending party could initiate a sally action to disrupt enemy actions, delaying opponents in order to give the defenders more time to dig themselves in.  Could be interesting if a planet has to prepare its defenses from a surprise attack.  Like with effort to set up the Atlantic Wall, fortifying a planet should be a timely and costly affair.  That said, digging out forces from a fortified position requires the attacker to have a larger army. 

-When the invasion force has landed and actually managed to surround the defending party, sally actions can be used to achieve a few other objectives as well.  One of them is sabotage.  Due to the abstract nature of the game a sally action can mean a great many things.  Elite troops might even have technology capable of entering the enemy camps undetected through a secret gate, a tunnel system or even teleportation.  From my standpoint I do not find it impossible for the defenders to be able to reach the attackers siege equipment or a forward command post.  The overall damage of a sally action might by comparatively minor but when successful should provide a proportionally large hit on enemy morale.  Another reason to sally forth is to act as a distraction for allied forces; a costly affair for the defenders but when the defenders have allies outside a besieged strongpoint, drawing in attacker could give their allies the opportunity to launch an attack against the attacker's flank or rear.

-Another scenario consists of two 'equal' forces.  Each party has managed to dig themselves in and neither party has the strength to dislodge the other from their respective fortifications.  The role of defender and attacker switches constantly.  Think WW I trench warfare.  Sally action in this situation can range from sabotage missions, all the way up to mass charges across open grounds.  Sabotage missions deal little damage, but affect morale, while charges provides a change to break through. , but the attacker risks losing many troops in the process, while the defenders risk a breakdown of moral; their troops panicking and abandoning their defenses.

It might also be an idea to add special strategic actions to commanders, granting benefits to forces with experienced commanders. 

I have to say that I like the changes to the army structure and I wonder if a similar abstract system can be implemented on planets: depending on the planet's size and available resources you build a number of nameable slots, which you can fill with structures like factories or farms.  Perhaps with enough time, resources and technology you can keep on building, increasing the size of a planet, changing it into a superstructure.  I imagine an empire stripping entire systems to expand their home planet.
Title: Re: C# Aurora Changes Discussion
Post by: Scandinavian on January 09, 2018, 08:06:16 AM
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.

Less flippantly, it seems more reasonable to have logistics units provide a certain supply point throughput and storage. So a logistics unit might be able to shift up to 20 MSP per day (either between the planetary stockpile and the logistics unit or from the logistics unit to maintained formations, or some combination), and store up to 150 MSP (roughly two weeks' worth of steady-state throughput).

This way, an invasion force would have to deploy logistics units to carry the initial batch of MSPs and to distribute supplies, but as soon as a landing pad or starport could be established (or captured), you could start bringing in supplies by conventional means (though you may of course want to still use logistics units in order to avail yourself of drop pods, if your supply ships face harsh STO fire).

MSP stockpiles outside starports/landing pads or logistics units should of course be subject to capture just like facilities (while logistics units would protect the MSPs they store).
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 09, 2018, 09:29:42 AM
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.

1) Yes, Maintenance Supply Points should absolutely be subject to load/unload times. Shuttle Bay systems should probably be enough to cover how that happens.

2) This then comes down to how detailed you want the supply system to be. Do you want 'there has to be a source of supplies on planet,' 'supplies trickle down' or something in between?

I can understand not wanting to say 'dump some MSP, problem solved.' It's boring and gives attackers an advantage they probably should not have in ease of supply.

So I propose the following; all formations require Logistics units in their on planet command structure to function; Logistics Units store some amount of MSP; Logistics Units may have an upper limit to how many MSP they can move per ground combat round to units, lack of supply causes units to forfeit their shots; Logistics Units certainly have an upper limit to how many MSPs they can draw from an MSP stockpile in a ground combat round; there is an order for ships that is 'Supply Ground Forces', this tells ships/fighters to hang around in orbit/land and permit Logistics Units to draw from them as if they were an MSP stockpile; for orbital ships they cannot move more MSP then their shuttle bays allow.

Also; formations with Logistics units should be Support/Rear Echelon only but weighted to be more likely to be attacked in case of a breakthrough in the lines. They are after all unarmed, often thin skinned and close to the front, which makes them excellent targets.
Title: Re: C# Aurora Changes Discussion
Post by: King-Salomon on January 09, 2018, 10:44:48 AM
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.

I like the logistic support units - what I don't like is that they would be "consumed" -.- other than that the system would be great...

why not use something like this:

- Units have MSP needs (like ships) in combat and a small stockpile (more if designed with more), logistic troops have a larger special equipment with larger stockpile (unit design)
- after each combat phase, units in combat get there MSP reduced, logistic units have automated order (to reduce micromanagement) to restock the units if they have enough supply themself AND one unit can only resupply X units or X# of MSP max
- if the MSP of a supply unit is empty, they are useless but still in existence, can die, have to be transported etc but can restock their supply at a place with MSP stored for them (or after the planet is conquered from the new stockpile)


so a logistic supply unit would be like some kind of "tanker or supply ship" but for ground units - but basicly the same system as with ships with an automated resupply order

Problem: the whole MSP for each unit would have to be protocoled somewhere - with so many new ground units etc I am not sure if all the new data would kill the better performance from C#

PS: also MSP loading/unloading should need time, it's always better to use the same "logical system" as much as possible

Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on January 09, 2018, 11:50:18 AM
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.

We already have multi-roles in real life.  It's completely unbelievable to me that we would lose that capability.  Watch some gameplay footage of DCS, you'll see that even aircraft from the 70's and 80's could carry all manner of guided and unguided weaponry.

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.

Even WW2-era fighters could carry bombs.  As I said before, while the P51D was designed to escort bombers at high altitude, it was still able to carry 1000lbs of bombs.  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.
Title: Re: C# Aurora Changes Discussion
Post by: boggo2300 on January 09, 2018, 02:53:13 PM
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.

The Mossie was heavily modified to get into that state,  it had been converted to what would now be a strike aircraft at that stage, it's original design was an unarmed light bomber, and the Photo Reconnaissance, Light Bomber, Strike, and Night Fighter variants were all modified enough to fulfil their specific roles and were built into the different types from construction, though in 1940-43 by necessity there was a lot of using aircraft for not their intended purpose by the RAF,  they had no other option.

Sorry if it seems I'm nitpicking but I'll take any opportunity to bang on about the wooden wonder!
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 09, 2018, 03:49:33 PM
My opposition to fighters needing dedicated space or ground weapons is a gameplay one; no one is ever going to equip both, so you'd have fighters being either space fighters or ground fighters. Which is fine, but at that point you might as well just make them a ground unit.

I like the idea of fighters being able to fight both in space and on the ground because it makes an interesting new role for them.
Title: Re: C# Aurora Changes Discussion
Post by: Scandinavian on January 09, 2018, 06:26:22 PM
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.

Multirole combat aircraft will always be situational weapons at best; the contemporary tendency toward all-in-one designs owes more to inter-service politics than to it being a sensible design paradigm.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on January 09, 2018, 07:20:14 PM
If C# Aurora really does run 1000x faster than VB6 Aurora, then we'll see players building some absolutely gargantuan empires.  If you're using carriers, you'll be building tens of thousands of fighters.  At those numbers, it starts looking more attractive from a logistics standpoint to go with multi-roles, even if those fighters are sub-optimal at both anti-space and anti-ground operations.

How I would do it is I would have ~3 sizes of ground combat module, representing different size ordnance hardpoints/bomb-bays.  The smallest would be for light weapons, the largest would be for heavy weapons.  This way you could have a primarily anti-space fighter that also carries the smallest ground combat module so it can be pressed into close-air-support service.  Or you could have a primarily anti-ground fighter with a couple of the heavy ground combat modules and a gauss cannon.  This would be meant primarily for close-air-support, but could at least shoot back if it got intercepted.
Title: Re: C# Aurora Changes Discussion
Post by: JacenHan on January 09, 2018, 09:12:12 PM
Speaking of having tons of fighters, I can't remember anything about how fighters will work with the new naval organization system. Have there been any changes to make fighter management simpler, or is it pretty much the same?
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on January 11, 2018, 06:32:14 AM
Of course there should still be dedicated single role aircraft. They tried to make the F35 as multirole as possible and look how that turned out.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on January 11, 2018, 11:21:31 AM
The failings of one multi-role do not disprove the utility of all multi-roles.

The F18 is a very successful multi-role.

And my idea does not preclude single role fighters either.  There's nothing stopping you from building a "fighter" like the Ju87 Stuka.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 11, 2018, 12:46:10 PM
In reality the reason for why you make something a jack of all trades but master of none are usually economics. If you specialize everything you might end up in a situation where a large part of your resources are completely useless or in the wrong place at the wrong time. There are also the thing about good enough.

In the game and especially in the new C# version multi-role ships and other things seem to have improved allot due to most things being based on more sensible logarithmic scales rather than linear scales. This aside having a decent fighting platform today might be a thousand times more important than a perfect platform tomorrow.

This does not mean that specialized platforms, be it aircraft, vehicles or ships, is not important as well. In most cases you will want to use both kinds in a decent mix. Ships in general tend to be way more economically viable in the long run when built as multi-purpose in some form, especially when you look at research, shipyard infrastructure, upgrade costs and general logistics. That is why the larger you build your ships the more multi-purpose you generally want them to be. Carriers in general are very cost effective because the hangar modules never need to be upgraded so upgrading these ships are generally less complex.

Military aircraft in the real world have been multi-role in varying degrees for a very long time. The F-35 is just an extreme example of a multi-role and its failure or success have yet to be proven as far I know, but it surely seem to be too expensive but only the future will answer that question.
Title: Re: C# Aurora Changes Discussion
Post by: King-Salomon on January 11, 2018, 01:19:51 PM
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..)

(other than that you could also say "a submarine should be able to be used as a fighter in aircombat... a sub and a aircraft are a whole different thing, the first is build for water the later for air... as are fighter and space-fighters which are for vakuum and don't need to be aerodynamic - even if Star Wars might see it in an other light...)

For Ground-combat I would like to see only 1 fighter type - no sense to add the complex situation even more ... the game will not gain much with 3-10 different fighter-classes...
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 11, 2018, 01:36:25 PM
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..)

We've had this debate before, but a) such a decision should be made based on gameplay, not what seems fitting for the real world, and b) it's not even true, since in game TNE tech does suffer from drag, so a space fighter could plausibly designed in an aerodynamic shape anyways. And the sheer speed and thrust of TNE tech means TNE aircraft probably wouldn't even use wings.

Personally I'm fine with either dedicated ground and space fighters or true hybrids that can fill both roles, but if we go with the hybrids I think they should be true hybrids, capable of firing the same weapons in both space and ground, or there isn't much point (it just adds extra micromanagement needing carriers in addition to troop transports to move aircraft). I'm partial to the suggestion of missile fighters using special munitions for ground combat, sort of like carrier based aircraft in WW2 could be armed with torpedoes for going after ships or bombs for going after land targets, and then just giving beam fighters a way to fire their beam weapons similarly to if they were engaged in orbital bombardment but doing it as actual direct combat.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 11, 2018, 02:00:29 PM
Also important; with enough thrust anything can be made to fly. If it's not controllable enough you need to better place your thrusters.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 11, 2018, 02:06:14 PM
In my opinion it does not make much sense to build 2-300t support air-craft for planetary combat. You would like to have much smaller platforms that can operate much closer to the ground and they would need to be a bit more specifically tailored for each planet they intend to fight on. Every planet will be unique in some way and modifying and developing smaller aircraft for these purposes seem much more realistic.

Planets have terrain in a way space don't so having more platforms such as 20-40 fighters for every space fighter is a very different type of proposition, you can't even compare these things.

Space to ground "ships" should mainly be assault and transport type ships and could be used to transport ground troops long distances on the planet. But I don't really see them used as combat platforms, that seem like a waste of resources to have them designed for that purpose. This does not mean they could be used as low orbit bombardment platforms using some kind of beam weapon and be more like support artillery. That way you don't have to risk your more valuable assault ships in such positions

I would not even put 2-300t spaceships in the same category as a 10-30t atmosphere drone or fighter craft.

There can also be many pseudoscience reason for why regular TNE space drives don't work close to large massive objects such as a planet, forcing such craft to use two different types of engines if you want them to be dual purpose. Or... TNE engines are usable but not for any type of maneuvering so all they can do is basically take a ship up and down from the ground to orbit where around 500t is the practical limit. Maneuvering them close to a planet is just not feasible so they are not reliable for anything but transport and space to ground artillery.

The limiting factor of TNE engine could, as I said, have more to do with gravity and mass and less with an actual atmosphere. I would gather that most atmosphere flying crafts are some combination of VTOL and Anti-gravity and not JET planes. The VTOL are most likely using its own propellant (or mix) so they are equally usable in space as they are in an atmosphere, so assuming some sort of plasma drives would make sense.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on January 11, 2018, 05:53:26 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Scandinavian on January 11, 2018, 06:55:40 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 11, 2018, 07:01:22 PM
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.

This is not a drawback it is the strength of what it means to be multi-purpose... do you really want four or five different cars so you can use the one you need for the moment?
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 11, 2018, 07:12:10 PM
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.

So exactly like Cars then which use a mainly aluminium alloy light weight chassis today instead of steel, and electronics which is 1000 times more powerful today then what was used to put a man on the moon some decades after WW2.

For reference this is an example image of the wiring in a modern car:
https://blog.caranddriver.com/wp-content/uploads/2016/05/Zap-Zone-2017-Bentley-Bentayga-inline1-626x352.jpg

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


Actually to further my example using the actual amount of money I listed you would need less then 10% of USAs current GDP to buy the amount of F-35s you claim would be impossible...

And During WW2 USA spent about 1/3:ed each on Airforce, Navy and Army, which means if they spent 41% of it on war they spent about 14% of it on the airforce, which main expense would be, you guessed it, buying airplanes.

The money and wealth available in rich world powers like USA/China is staggering, if an entire nation the size of USA could rally behind a common goal like was done in WW2... Then truly staggering things could be accomplished which may seem "impossible" for us in our consumer / narcissistic focused economy of today. ( Although colonizing the solar system would be a way better goal to rally behind then building hundreds of thousands of fighter jets ).


Even if the analogy worked, contemporary automobile design is a case study in the drawbacks of multipurpose design.

Automobile design being a case study in drawbacks of multipurpose design and being overspecced seem to support my analogy that cars of today have developed just as much as airplanes, if not more. People that argue against airplanes like the multirole F-35 use exactly the same arguments!
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on January 11, 2018, 11:40:17 PM
Are there going to be extra officer positions for ground forces like there are for ships? Will there be smaller and larger organization of ground forces available (companies, armies, etc).
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on January 12, 2018, 05:35:56 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 13, 2018, 03:27:12 AM
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.

It might not be reality but most of it is based on logical conclusion on some pseudo scientific rules and everything needs to be consistent somehow. At least things need to be consistent with itself to make sense.

A choice always need to be useful or there are no real choice to make. The binary nature of most games, Aurora included many times make this a hard proposition or obstacle to overcome.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on January 13, 2018, 04:08:26 AM
Multirole fighters have been real and desirable for a long time.  They are effective and are used by any nation that is able to build large numbers of aircraft in general.  I fully agree with the decision to add general purpose missile pods.  Also, aurora drive systems seem to not require wings at all, at most you'd want the design to be semi aerodynamic but even then there is no way that strike fighters would be flying so low as to actually enter the atmosphere, even if they appear to be 'on' the planet.  The damned things are capable of flying at such incredible speeds that the tiny extra distance to dip into the atmosphere is totally irrelevant to them.  They would probably just make the planet uninhabitable with the shockwaves from their passing.

Also regarding the f-35, I do agree that its a bit dumb to try to instantly go for a super multipurpose stealth fighter, thats not going to be viable for a while yet imo.  The f-35 is supposed to be the first multirole stealth fighter that can also be mass produced.  What?  And then they wanted to try to have four variants with totally different propulsion systems have interchangeable parts.  Thats frakking retarded, VTOL, VSTOL, and conventional aircraft will always have significantly different internal configurations.  It was an idiotic pipe dream.  I'd point out though that the government isn't yet under the thumb of the defense industry really, it was just optimism frakking everyone over.  "hey lets develop a weapon that has absolutely every positive characteristic we want!"  "sure!"  This has happened before in human history, many times.

e: Editied to reflect what i was acutally intending to say, in my defense its like 2am here.
Title: Re: C# Aurora Changes Discussion
Post by: Viridia on January 13, 2018, 04:30:40 AM
@Steve Walmsley; quick question, but will the upgrades to ground force strength (if the old research options are being kept), allow for the ground units weapons/stats to increase/be upgraded, like one of your example Leman Russ designs being replaced with a Mk II? Also, are there any plans to introduce a heavy infantry unit, like an Astartes/Clan Elemental?

In all other respects, please keep it up. This is undoubtedly one of the few games I've been most excited for in my life.
Title: Re: C# Aurora Changes Discussion
Post by: Profugo Barbatus on January 13, 2018, 05:18:23 AM
I don't think we've seen every option yet on the list, but I'd be incredibly surprised if the Infantry didn't have the option of a Powered Armor, and you could always give them a heavy weapon and just not RP it as a crew served weapon, to accurately represent the firepower of a group of Toads or some Space Marines.

I would really love to see a complete list of the options that exist so far, if only to get an idea of what sort of forces I could accurately create.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 13, 2018, 06:22:39 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Lamandier on January 13, 2018, 06:53:47 AM
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.

He's not wrong. IMO y'all have been getting way, way, way too into minutiae and non-game-related arguments in this thread for the past few weeks. It's great that Steve is expanding and fleshing out the ground combat, but this is not a ground combat-centric game.

Frankly, there's a part of me that, at this point, wishes Steve would scrap the ground combat revamp altogether if only to end this ridiculously nitpicky discussion. (But only a part.)
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on January 13, 2018, 07:14:52 AM
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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 13, 2018, 07:37:57 AM
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!
Title: Re: C# Aurora Changes Discussion
Post by: Lamandier on January 13, 2018, 09:13:57 AM
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!

I mean, at this point people are arguing about things that have nothing to do with Aurora's development, but okay.

So sorry I interrupted your quest to be right on the internet. ;)
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on January 13, 2018, 09:32:07 AM
Two things:

1)  The discussion seems to be getting a little testy.  Please remember the rules: http://aurora2.pentarch.org/index.php?topic=966.0 (http://aurora2.pentarch.org/index.php?topic=966.0)  Don't make me get Erik involved :)

2)  Given the number of people who feel that the whole ground combat discussion etc has grown too big for this thread, I've made a new "C# Ground Combat" thread and stickied it.  Please put any further posts on ground combat, multi-role fighters etc. into that thread.

Thanks and Have Fun!

John
Title: Re: C# Aurora Changes Discussion
Post by: Borealis4x on January 14, 2018, 02:25:53 AM
I'm a bit worried about feature creep, both for the sake of my sanity and my processor.

Will C# get some performance upgrades?
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on January 14, 2018, 02:44:58 AM
Will C# get some performance upgrades?

I believe that's the whole point of the engine redesign.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 14, 2018, 07:37:56 AM
I'm a bit worried about feature creep, both for the sake of my sanity and my processor.

Will C# get some performance upgrades?

C# will run a lot faster than VB6.
Title: Re: C# Aurora Changes Discussion
Post by: dukea42 on January 14, 2018, 09:49:41 AM
Quote from: BasileusMaximos link=topic=8497. msg106096#msg106096 date=1515918353
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
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 14, 2018, 12:57:11 PM
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

Thirded about the feature creep. So while I may try to join in on discussions from time to time, I hope Steve won't hesitate to ignore any ideas he doesn't like!
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on January 14, 2018, 01:01:08 PM
 Even too much creep of ideas that he does like would degrade the likelihood of completing the game.  That's why feature creep is becoming so disliked.  Really all we can do though is say "beware of feature creep" and hope Steve balances the ease of adding stuff before the game is all the way done vs. getting the game into a playable state before he mentally runs out of gas.
Title: Re: C# Aurora Changes Discussion
Post by: Profugo Barbatus on January 14, 2018, 10:14:17 PM
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"
Title: Re: C# Aurora Changes Discussion
Post by: Froggiest1982 on January 15, 2018, 12:39:39 AM
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 strongly agree, but! Of course, there is a but.

I have always understood Steve's choices and I have always agreed with them and I will always thank him for such beautiful product he managed to create. However, I really would like, considering that he always refused to release the master code and password to the public, that one day when he does not feel like to update or carrying on this project he would also give the possibility to someone else or the community to move forward releasing such codes. I admire him lots but I would hate to get a forever unfinished product.

For example, once Aurora C# is out, have the V6 database unlocked would be already a step forward.
Title: Re: C# Aurora Changes Discussioni
Post by: Borealis4x on January 15, 2018, 09:00:45 PM
I was actually talking about mental fatigue on the part of the player who now needs to manage all the new ground stuff in addition to the space stuff....
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on January 15, 2018, 11:18:43 PM
Really the only part of Aurora that's mandatory is ship design.  You don't absolutely have to terraform.  You don't absolutely have to do gene modifications.  You don't absolutely have to do ground combat.  You don't even need populated colonies.  So if the game is too mentally taxing for you, just ignore parts of it.  Your empire will be a little worse if you do, but it doesn't really matter.  NPR AI is pretty braindead and not really much of a challenge.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 15, 2018, 11:30:01 PM
I normally just glass enemy planets with missiles (which you can still do, to be clear). Ironically the ground combat changes are making me excited to actually go all starship troopers on the aliens instead.
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on January 16, 2018, 01:12:23 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 16, 2018, 06:44:02 AM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: bowman on January 16, 2018, 07:45:09 AM
As I'm not sure where else to put this I'll just ask here-

Could we get a button somewhere to make the grid used in the Galactic Map view visible? I know it we can already auto line up but it would help with planning out where to put all the system balls beforehand and the (at least for VB6) "a system at normal zoom is about 6 in diameter" isn't exactly a good measurement. 

Otherwise, pretty much everything happening with C# Aurora is looking pretty good to me.   Particularly the revamp of naval organization to be fully realized as a core system- with drag and drop, no less!
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on January 16, 2018, 08:27:10 AM
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.

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.
You always could just dump them into the pool, though. Don't see why that shouldn't still be an option anyway.

How long it takes and the cost would be simple enough. Just the time, facilities, and MSP necessary for a full overhaul from 0-100% on the ship's maintenance clock. Maybe more time than that, it really depends on what "balance testing" says after we get our hands on the game, but I think that's a good enough initial baseline. It wouldn't require any different facilities to those required in normal maintenance and overhauls imo. There's no reason to make more parts of the game for it, it could just be part of the normal maintenance mechanics.
The resources they'd consume in mothballs is tricky, but you could just throw an arbitrary number out and just tweak it as we play the game more and decide what seems fair. For my own arbitrary number I'd say either 1% of the regular MSP for maintenance, or 0%.

No parts would need to be replaced, it'd just be the old ship at full readiness. For missile boats and carriers that'd probably end up being just fine. For melee beam brawlers it would probably be a little more questionable as far as how worthwhile they are to keep in reserve, at least if they become obsolete during that time. iirc most of the ships pulled out of reserve in the Starfire novel "Crusade" were light/escort carriers anyway.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on January 16, 2018, 09:01:43 AM
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.
You always could just dump them into the pool, though. Don't see why that shouldn't still be an option anyway.
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.

I think that there are still definite balance issues for mothballing missile boats and carriers which don't really become obselete. In reality I think almost everyone would keep the bulk of their fleet in mothballs from construction onward, unless during an active war. Why wouldn't you? That might be a positive thing, making surprise attacks (and a recommissioning race against time) a more dramatic part of the game, but I think it should be acknowledged that it would be a major change to the game.
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on January 16, 2018, 10:51:09 AM
Mothballing would definitely be a large change to the game, I won't be disputing that. I don't think it'd be a negative one, though, especially with how much more harsh maintenance seems to be in C#.

Hell, think about how many other things are large changes to the game. The sensor, engine, and missile nerfs have already done plenty to alter the game, let alone just the new ground changes and the removal of PDCs.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 16, 2018, 02:35:46 PM
Some simple mothballing functionality would be nice. The ship would only cost roughly 1/5 regular maintenance and take up roughly 1/5 of a normal ship for maximum hull size.

The downside should be that it takes five times to start up the ship from a regular overhaul and you would have to start it up with fresh crew.

Seems fair to me.
Title: Re: C# Aurora Changes Discussion
Post by: ZimRathbone on January 16, 2018, 05:05:39 PM
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.

Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 16, 2018, 06:20:43 PM
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.

Yes, I know it did exist before but I don't think this would be a problem due to exactly what you say. It wold be a huge amount of waste of resources to build huge amount of ships only to mothball them unless you know there will be a war in a decent short time frame. The cost to refit old designs will be very expensive and time consuming.

But mothballing part of a standing fleet as a reserve could be a good strategic option. You actually might want to mothball older designs rather than refit them. Even older fleets can become decent platforms with only a few rudimentary refits or even as is. A missile frigate can be quite useful with just new modern missiles and a refit to their targeting system.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 17, 2018, 02:21:07 AM
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.

It could also be good if possible to set up fighter patrols from carriers so you can dock, wait for a specified time and then start over the patrol pattern.

Thanks for all your hard work!
Title: Re: C# Aurora Changes Discussion
Post by: Dr. Toboggan on January 17, 2018, 09:46:19 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 17, 2018, 10:41:33 AM
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.

There are two problems with this.

1. It only works one time, after an order recycle it ignores the delay setting.

2. You often want to set wait periods in more than one place during long patrol orders for different reasons.

You can set up a long patrol now but it will have to be as one order. As soon as you hit recycle it does not remember the order delay. It would also be good if you could specify it with a drop down selection menu in seconds, minutes, hours or days. It would also be good it the delay is viewable in the order window so you can easily see it. The best way would be if you inserted it as if it was a separate delay order into the queue

It is quite fiddly to do it right now.
Title: Re: C# Aurora Changes Discussion
Post by: waresky on January 18, 2018, 09:43:13 AM
WHY...am repeat : WHY all wanna change something? Please let STEVE finish job..THEN,NEXT,next Era,post requests. OMFG its really boring..EVERY frakking day someone wanna change some. Jesus...
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on January 18, 2018, 11:16:19 AM
Now is the time to change something.  He's gotta rewrite the whole game anyway, why not rewrite it better?
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on January 18, 2018, 06:51:00 PM
Feature creep is a very real threat still, since the game hasn't entered a playable state yet.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on January 18, 2018, 07:13:27 PM
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
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 19, 2018, 05:09:52 AM
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

I think the Ground Combat changes will probably delay completion by 3-4 months, more due to deciding exactly how to implement them than the actual coding. The ground combat design is mainly done now and a decent chunk of the coding is done. I still need to code the interactions between ground units and naval units (including new movement orders) and the logistics. As mentioned above though, this is a relatively isolated area so doesn't impact the rest of the game too much. On the plus side, ground combat was a very basic area compared to the rest of the game and I think the changes will make it much more interesting and immersive (from an RP perspective as much as a mechanics perspective)

I'm taking a break from ground combat at the moment to code the New Game window, with the intention of starting some test games. There are still some significant areas missing, including combat, AI, default/conditional orders, about half the movement orders and many of the minor windows. However, almost all the construction phase code is done (research, terraforming, production, maintenance, etc.) and most of the common movement orders, so I hope to start the first of those test games in the next month or two and then code the rest while playing.

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.

I am well past the point now where I think there is a question of whether C# Aurora will eventually be finished. This isn't similar to early abortive attempts at Newtonian Aurora and Aurora 2. I have invested almost two years into this project (from March 2016) so I am pretty determined to complete it :).  I can't say when yet but the prospect of getting a new campaign running is my main motivation.
Title: Re: C# Aurora Changes Discussion
Post by: Profugo Barbatus on January 19, 2018, 07:17:44 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on January 19, 2018, 07:27:40 AM
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?

Quote
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.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on January 19, 2018, 09:28:42 AM
How will this work though? Can we seize territory in ground combat, ideally also set fixed claims when we want peaceful coexistence?
Title: Re: C# Aurora Changes Discussion
Post by: TurielD on January 19, 2018, 11:18:34 AM
Quote from: Steve Walmsley link=topic=8497. msg106222#msg106222 date=1516360192
I think the Ground Combat changes will probably delay completion by 3-4 months,

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.

Quote
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.

Congratulations! Do you have a Coding Cave in your new house?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 19, 2018, 11:21:30 AM
How will this work though? Can we seize territory in ground combat, ideally also set fixed claims when we want peaceful coexistence?

If another race grows its population, that is restricting your ability to grow. In effect the planetary environment has a limited capacity to support a population, regardless of their nationality.

On Earth, overall population growth is slowing even though there are considerable difference by region.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 19, 2018, 11:45:25 AM
Aurora is a 4X game, one explores, expands, exploits and exterminates.

Clearly, the proper response to having another nation swallow all your population capacity on a planet is to exterminate that other nation.
Title: Re: C# Aurora Changes Discussion
Post by: waresky on January 19, 2018, 11:54:17 AM
Aurora is a 4X game, one explores, expands, exploits and exterminates.

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..:)
Title: Re: C# Aurora Changes Discussion
Post by: mtm84 on January 20, 2018, 11:03:14 AM
From 2004 ive "exterminate" only 2 Sentients Race. Abducted 4 and "swallow in mine" another one. Not so easy..:)

Nothing enhanced radiation warheads can't fix.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on January 20, 2018, 11:09:16 AM
I've been playing on and off since 2010, and I have only ever seen 2 NPR's that weren't spoilers.  And I only fought one, and they kicked my ass easily.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 20, 2018, 05:29:11 PM
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?

Yes, I have always had a room for gaming. Back in the 80s it was known as the 'war games' room, as it was used for board war gaming (Avalon Hill, SPI, etc.). These days, the shelves are still full of war games and books, but its generally known as 'the office' as its mainly PC gaming :).

That has been true for twelve different houses now and will continue for number thirteen. Moving is a well-oiled routine :)
Title: Re: C# Aurora Changes Discussion
Post by: boggo2300 on January 21, 2018, 03:12:43 PM
twelve different houses now and will continue for number thirteen. Moving is a well-oiled routine :)

Another similarity between Steve and Doc Holliday,  continually gettin' run outta town (though I believe Hollidays game was Faro rather than Poker)
Title: Re: C# Aurora Changes Discussion
Post by: Profugo Barbatus on January 23, 2018, 11:41:48 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Froggiest1982 on January 25, 2018, 04:12:46 PM
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.

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
Title: Re: C# Aurora Changes Discussion
Post by: Felius on January 25, 2018, 05:29:55 PM
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:

Quote
Shield Generators

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.
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?

Quote
Commander Careers

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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Graham on January 25, 2018, 06:16:36 PM
Quote from: Felius link=topic=8497. msg106334#msg106334 date=1516922995
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?

That is strength before multiplying as I understand, meaning a size 40 shield gives twice as much total strength as 4 size 10 shields.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on January 25, 2018, 08:04:28 PM
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.

It doesn't matter if its counter intuitive because it will be behind the scenes. 
Title: Re: C# Aurora Changes Discussion
Post by: Profugo Barbatus on January 26, 2018, 12:36:56 AM
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

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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 26, 2018, 03:47:42 AM
Quote
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.

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 )
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 26, 2018, 04:49:33 AM
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.

No... what you can do is remove technologies that was learned from an invasion using SM mode.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 26, 2018, 07:34:33 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 26, 2018, 09:11:47 AM
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.


Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 26, 2018, 09:41:21 AM
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.

It is negligible in the context of the game, where even 1 terraforming plant at the basic tech level operated by 50 000 people can add or remove 1 000 ppm per year, and the game doesn't model the effects of such vast shifts in atmospheric composition when it comes to ecology, societal impact and climate beyond abstracting it away as 'requires X Infrastructure per million inhabitants beyond pressure/temperature/gravity range.'

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.

At which point it becomes fairly trivial to develop basic terraforming technology and construct a terraforming facility well before it becomes relevant to the game's poisonous atmosphere mechanics, and probably well before the planet becomes uninhabitable due to excessively high temperatures unless the planet's temperature was already on the higher end of the species' habitability range.

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's increasing and keeps increasing because due to the growing global population and the growing energy demand per person for the purposes of production and mobility we continue burning more fossil fuels in absolute numbers. It may be shrinking per capita, but I doubt it.

The thing about fossil fuels is that they are really convenient ways to store and transport large quantities of energy, not least of which due to their reliability which can't be matched by solar and wind power.


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.

If it wasn't for how easy terraforming is in comparison to reality I'd agree.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 26, 2018, 09:57:52 AM
So the criteria for this to be relevant would be custom difficulty setting for terraforming speed? Sounds good and I agree.
Title: Re: C# Aurora Changes Discussion
Post by: SpaceCowboy on January 26, 2018, 01:28:08 PM
Hey Steve,

I just saw the placeholder post in the "Changes List" for changes to the Solar System, and it got me thinking: would it be possible to add in known exoplanets to Aurora, in the same way the Solar System is the same every game? Several of the nearby real stars that pop up in games have confirmed planetary companions.

Even more cool would be to have the known planets plus some random generation of smaller planets that we would not be able to detect using current methods.  As an example, Pollux could have real-life planet Pollux b in orbit out at 1. 6 AU, and then Aurora could generate a couple of imaginary terrestrial planets (or whatever) interior to that.
Title: Re: C# Aurora Changes Discussion
Post by: waresky on January 26, 2018, 04:33:18 PM
Everyone talk about physics,weapons...but : TAXES? Politics? 1 tax level by EVERY single planets,no difference?No settings allowed?..its really annoying.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on January 26, 2018, 04:49:17 PM
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.

I really love the idea of ethics and ethics drift.  I think it should be an optional system, like maintenance is, but it would be really cool if there was more internal politics.
Title: Re: C# Aurora Changes Discussion
Post by: Froggiest1982 on January 26, 2018, 09:59:55 PM
Everyone talk about physics,weapons...but : TAXES? Politics? 1 tax level by EVERY single planets,no difference?No settings allowed?..its really annoying.

Verissimo

I second this
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 27, 2018, 12:22:21 AM
I kind of like that Aurora doesn't worry about a deep political or economic model. Its focus is on other areas.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on January 27, 2018, 04:59:27 AM
I mean, I have never seen a particularly deep economic model thus far.  People just point to eve, wherein you shoot rocks and then queue production orders and trade on a global marketplace in ways unlike anything present in reality, then screech about how thats an awesome economy, despite the main driving force of said economy being e-peen lengthening conflicts rather than anything of substance.

Point is, its hardly like there are too many deep economy games.  I personally think there are approximately zero of them.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 27, 2018, 05:45:48 AM
Then you poorly understand the nature of an economy.

EVE's economy is pretty deep for a game. In reality the economy runs because people have a demand for their survival; most of the money made in the world goes towards food, shelter and the means to acquire food and shelter. EVE's different, because the players don't need food and shelter to survive, and the purpose of the game is to entertain.

And that's what EVE's economy revolves around, entertainment and the means to be entertained. And yes, that means you shoot big rocks in space, move the results to facilities to be processed, process those results to intermediate products, move those products to shipyards and then have those shipyards crank out ships by the dozens. And all of those things are often done by different people who determine their share of the wealth by demanding either part of the raw materials or a fungible good in exchange, to wit, money.

Many find that entertaining enough, and others then use those same ships to fight battles with either NPCs or with other players in e-peen lengthening conflicts. Because it's a game and that's what's amusing to the people participating in the economy.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on January 27, 2018, 06:33:00 AM
Yeah, just because the supply, demand and desired uses don't match real world norms doesn't mean the economy isn't realistic or functional. I won't make a comment on eve specifically because I don't know enough about how it works.

That being said, Eve isn't the same kind of game nor is the marketplace the same kind of economy that would be needed in this kind of game. The obvious example to point to as a template would be something like Victoria II, but that has a lot of problems.

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.
Title: Re: C# Aurora Changes Discussion
Post by: waresky on January 27, 2018, 09:00:42 AM
..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.

This point of view IS aceptable. But TAX level (for Steve i mean) are so hard to implementing?
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 27, 2018, 12:54:23 PM
For the kind of game that Aurora is I also think that the economy of the game can't be too complex nor can the social part of the game.

We can easily RP any social unrest we like so that is not a huge deal for me.

I do however think that the civilian economy could be expanded some and have a bigger impact on the overall economic growth than it does.

The game also assume that 100% of all taxes can be directly used by the state for military and colonial development which sort of feels weird. I often feel that I don't understand what Industry and Wealth generating buildings are suppose to be in terms of state or civilian. They seem to model mostly what is civilian enterprises, civilian part of the economy definitely have it as well.

I don't think any of this should be part of an initial release of C# Aurora but at some point a look on the overall economic model and population involvement in what the government does might be interesting.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on January 27, 2018, 03:01:09 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 27, 2018, 03:19:01 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 27, 2018, 03:20:33 PM
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.

Don't get me wrong... I would not mind seeing some more empire and social interaction into the game. I just think that each of these areas would need a vast amount of dedicated work and research into how it would function. So if it was ever done it should be the sole focus for a specific update of the game.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 27, 2018, 03:33:26 PM
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.

Personally I don't like the taxing model most games are representing and especially not tying it to unrest.

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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 27, 2018, 05:42:05 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 27, 2018, 06:00:05 PM
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.

True... but sometimes it's also better to do nothing or do it properly. Depend on how many other things that could enjoy a "small" overhaul.

I suppose only Steve can answer what those priorities will be.

I would not be opposed to a small change either though.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on January 28, 2018, 02:53:26 AM
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. 

Bear in mind that 'wealth' doesn't necessarily mean taxes.  money is fake, after all.  the important part, societally, is workforce mobilization & allocation - and wealth can represent any means of doing that.

If there's one thing i'd like for wealth, it'd be a mechanic to reduce wealth stockpiling... either a straight up 'inflation penalty' that reduces your generation or stockpile, or an efficiency bonus that gives you a small boost while eating up wealth beyond a certain point (say, 2x gdp)


Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 28, 2018, 03:47:14 AM
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. 

I don't really see how that can be used as an argument against something since exactly the same can be said for any other game element in Aurora 4x.

How much weapons should you have on your ship? As much as you can get away with...
How much research should you put into engines? As much as you can get away with...

If there is never any decision making in setting taxes and it's all no-brainer, then there isn't any in the rest of the game either IMO. It all depends on your viewpoint and goals with the game. All games will always have one "optimal" best / most efficient way to play them, but I don't think many of us enjoy playing Aurora 4X that way, so I don't think it would be a big risk.


Also keep in mind that the wealth is not going to have the same value for you in all situations. In some situations where your going negative it might be worth some temporary unrest that some extra soldiers moved home can handle, to break even until things stabilize, but if your running a big surplus and your soldiers are badly needed elsewhere the reverse might be true.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on January 28, 2018, 04:27:45 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: waresky on January 28, 2018, 05:11:37 AM
"..money is fake.." ehehe...but no-money = death sure.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 28, 2018, 05:34:02 AM
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.

Yes... i agree this is a huge risk factor when introducing such a mechanics. I think that wealth in the game are not directly correlated with money either but more of a general state of what you can do with more intangible means and the overall state the population are in in relation to it.

Increased tax could in this context mean less wealth, especially if you presume the taxed money is mainly squandered on useless stuff as an example.

In most games taxes are just a means for a player to min/max.... you are always going to use as high tax as you can so worlds don't rebel. Things really don't work like that in reality. Politicians want to stay in office, players are never in risk of getting ousted from their position so they can do whatever they want. Politicians need to explain what they do with the money, players don't. Games rarely punish players like that. Why not assume the player always get the most efficient tax possible and leave it at that.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on January 28, 2018, 08:16:30 AM
Currently, we have the ability to subsidise civilians and to seize civilian ships (in a somewhat flawed manner). Unless we get a nuanced tax system that adds depth on its own, with more colony-bound civilian activity, it probably won't add much.



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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on January 28, 2018, 08:30:52 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 28, 2018, 12:41:43 PM

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.

I think that missile fire controls should be capped at a certain number of total missiles it can guide and a maximum it can handle firing in one 5 second period. Should be two parameters and can be increased with technology.

Anti-missile beam fire should not care about salvos either, just shoot at as many missiles it can.

I think the term salvos should go away.

It is unrealistic to assume that a relatively small ship with 100 box launched missiles can fire them all within a 5 second window, there would most likely be many reasons for why this is not really possible from a realistic perspective. These kind of mechanics also make beam weapon anti-missile systems completely irrelevant.

Creating a ship that fire missiles in the way you describe is an exploit you can just forbid. Multi-player games usually need lots of house rules anyway.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on January 28, 2018, 12:52:57 PM
I'm actually kind of curious what the emergent gameplay would be of having a missile fire control only able to control one salvo at a time (IIRC this is how it worked in the Honorverse). On the other hand, it would make high fire rate launchers almost useless.

As far as missile point defense, I've always kind of wished PD was more proportional instead of all or nothing (frequently PD will shoot down either all missiles or very few). The best way I can think to handle this, at least for beam PD, would be to have PD weapons work like anti-missiles and pick their targets before firing. So that if, say, you have 100 missiles coming at you, and 200 PD guns each with 50% chance to hit, then two guns would fire on each missile and you would expect 25% of the missiles (.5^2) to still hit. Maybe something similar with anti-missiles targeting individual missiles instead of salvos.
Title: Re: C# Aurora Changes Discussion
Post by: Felixg on January 28, 2018, 01:40:34 PM
On the topic of game modifiers.

Can we please get a maintenance % modifier as well? Perhaps break it up to Ships/Stations/Ground or something that way those of us that want it can have maintenance free space stations?
Title: Re: C# Aurora Changes Discussion
Post by: Froggiest1982 on January 28, 2018, 04:49:52 PM
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.

Well you have just been served sir, have a look at the latest change discussion start new game

 ;)
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 28, 2018, 04:53:26 PM
Actually, this might be resolvable if we aren't dependent on a population/colony presence for Overhauling, or a point where so many Engineering spaces are dedicated to the station/ship that it doesn't run up a maintenance clock even if it is otherwise subject to the failure rates.

Also would be nice; a smaller maintenance storage bay that can be shoved onto Fighters for ground supply reasons. The current one is 5HS/250 tons, or half the weight of a Fighter.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 28, 2018, 06:34:55 PM
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).

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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on January 29, 2018, 11:52:07 AM
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.
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.

I should note that this mechanic means that the standard tactic of parking a single garrison battalion on every colony world to deal with overcrowding unrest would now be a high risk strategy. A few unlucky RNG rolls could see the potential loss of your colony. Imho that would be pretty great, a sensible representation of the overcrowding>riot>massacre>mass uprising path that is common throughout history, and a cause of much fun as you have to scramble to bring in extra troops in time.
Title: Re: C# Aurora Changes Discussion
Post by: Scandinavian on January 29, 2018, 03:01:34 PM
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.

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.
Except economies don't work like that.

In an industrial economy, the maximum growth path is the path where the economy is at all times subject to the maximum level of aggregate demand consistent with maintaining social cohesion and a habitable ecology. The level of taxation doesn't really enter into this, unless you're approaching the extreme ends of the spectrum (either a command economy where all economic activity is managed by the central bureaucracy, or full-fledged feudalism where the state fails to direct economic activity at all). The complications involved in managing an industrial economy are not straightforward trade-offs between long-term growth and short-term policy objectives. All the real challenges of modern economies are in the realm of political economics - i.e. how to organize large-scale economic planning without creating too many opportunities for personal advantage at the expense of the overall system.

None of which is really in scope for a space naval warfare game.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on January 29, 2018, 03:26:48 PM
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.

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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Drgong on January 29, 2018, 05:25:25 PM
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.   
Title: Re: C# Aurora Changes Discussion
Post by: Graham on January 29, 2018, 07:50:12 PM
Economics is extremely complicated and people argue over how it works all the time, let alone how to reasonably implement it into a game while also making it enjoyable and non repetitive.  I do not believe it will be easy to model it in Aurora, and i would rather we did not try, as anything we end up with is likely to be tedious or nonsensical.
Also I don't think it's worth Steve's time, although that is of course up to him.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on January 30, 2018, 05:48:59 AM
Tax vs. happiness is an old standby of strategy games that doesn't really make much sense in Aurora. We currently have no way of increasing our citizens' happiness with civil projects and happiness isn't a prominent gameplay mechanic.

I'd be interested in having the economic model expanded with more attention given to the private sector, but doing that properly would interlock with other parts of the game in rather tricky ways.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on January 30, 2018, 05:56:38 AM
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.
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.

This is sort of the problem with trying to hamfist such a system into aurora. Especially since I don't see much gameplay benefit here.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on January 30, 2018, 06:04:16 AM
None of which is really in scope for a space naval warfare game.

I disagree entirely with your idea that Aurora is a game only about Space Naval warfare!


Maybe the parts I enjoy about Aurora have about as much to do with Warfare as the Star Trek episodes that inspired my interest in Space? Perhaps my Aurora is a Story based game about Leadership/Character development, Terraforming, Research, Colony development, Exploration, Roleplaying/Diplomacy mainly.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 30, 2018, 08:23:14 AM
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.

Actually, taxes don't disappear out of an economy, at least if we're not talking about a kleptocratic government. Quite the opposite; taxes are reinvested in the economy, often as a part of various government services (most of the world's educational efforts, law enforcement organisations, health care efforts, infrastructure construction and maintenance as well as environmental and safety regulations are funded from taxes, along with a slew of other things), the knock on effects of which massively impact the overall productivity and efficiency of an economy.

I mean, people often accuse the government of being slow and inefficient, and there's something to that, but there's nothing that makes for profit organisations sit down and play nice when the consumers band their efforts together and tell big businesses 'we will pay this much and nothing more.' And a properly run government can and will do exactly that, for things with an inelastic demand like medicine you need or die, and for the remainder it will levy its power to ensure that neither the producer nor the consumer can abuse things like information inequality.
Title: Re: C# Aurora Changes Discussion
Post by: Drgong on January 30, 2018, 03:24:06 PM
Yes it s not as simple as anyone makes it out to be.    Government spending (In the EU at least) has been shown to cause economic increases in the quarter it is spent, then a small negative growth factor over the next two years.   This is due to public sector spending being not very efficient, for various factors (including citizens do not want their government to be tight with money when they are spending it on services they use!).   In addition, the TYPE of taxes has a lot of impact on economic growth (Kneller, Bleaney and Gemmell are the main researchers in this area) with for example, property taxes having much less of a economic impact then income taxes.

But the other thing to recall is that the impact of taxes is normally overstated by EVERYONE.   For example, interest rates and maintaining 1-2% inflation is a much bigger driver for long term growth  (and tax revenue) then the actual tax rates.  Economies get killed when inflation gets too high, or deflation, or if you have high interest rates.  (of course, too low interest rates results in inflation.) 

Also, most of the time tax reform also changes the underlying nature of the base, for example, Both JFK and Reagan cut US tax rates and saw huge economic growth, but much of that is attributed by eliminating tons of tax loopholes and thus made the economy less distorted.

But I really do not want Aurora to become a economy simulator....
Title: Re: C# Aurora Changes Discussion
Post by: Froggiest1982 on January 30, 2018, 09:28:37 PM
I am reading everybody's comment and...wow @waresky you have opened the pandora's vase, I almost feel sorry to have second your thoughts!!!  :D :D :D

Anyway, I believe that Aurora's economy works beautifully and I still like that most of my Martian economy is run by selling illegal drugs; also, generally, altogether there is nothing wrong with it but (I know everything before the word ’but’ is bs usually) I still would like to recover or balance my debt when you are fighting expensive wars with your shipyards pissing 20 1000t FACs at the time or those 5 dreadnaughts you commissioned during a delusions of grandeur moment are just about to be completed with your expenses skyrocket by 30% or 40% in one go.

I think we should find a solution that can integrate with the 20% increase economy research and the financial centres build. What about an administration building that decrease expenses? Could work by levels same as the naval academy, deep space sensor, spaceport, etc and that could also be a trait in civilian administrators able to enhance that. So this will give me the opportunity of using the administrator with 40% fewer expenses or fleet maintenance, giving even more control over our economy working not only in expanding it.

So you have your level 2 Administration building which gives you a 3% fewer maintenance costs (Level 1 1%, Level 2 3%, Level 3 5.5% etc. the formula is 1+1.5 per level with a max of 10% maybe? so 5 levels I don't know) then you have your Administrator ability which boost that up too, something like 1% extra for each 10% ability? Obviously, I leave the balance up to Steve based on what he does already with terraforming etc.

I think the above will work well because the goal of an economy it is not only to grow but also saving where and when possible, some people does it well some other poorly.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on January 31, 2018, 02:49:56 AM
While we are on to the subject I would like NOTHING to be free of charge in the game for the player. Commercial ships might not cost you maintenance but please at least have them cost a small sum of wealth per month to run. Make it about 1/3 - 1/5 of what such a normal ship should cost in regular maintenance on average.

This way they are at least not free once built and you will have to consider at least some cost for crew and the maintenance the private industry or crew will perform on them once in a while. It will not make it a problem for you to consider maintenance since it is abstracted, you just have to consider them at least having a small cost.

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.
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on January 31, 2018, 07:30:51 AM
Probably a controversial suggestion, but I think all factory types (including finance centres) should just be removed from the game and rolled into one thing. A colony's industrial capacity is then expanded the same way shipyard capacity is. You'd set  the ratios for how much of the world's manufacturing output goes to what sectors (including capacity expansion, and maybe even commercial goods production), and then you'd modify those ratios through a retooling process (with one free and instant retooling, same with shipyards)
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.
Aside from how a planet's industry expands, the process of actually building other things shouldn't really change at all.

The idea mostly comes from my general love of conventional infrastructure. I think this would achieve the goal of simplifying colony development without actually removing any depth from the game. You'd still have separate installation, ordnance, fighter and money printing ratios, so nothing is lost depth-wise.

Edit: Oh and also can the portrait/flag for all of the spoilers please be set to default integers so that they're the same every game and I don't have to worry about getting Serbian Ewok Star Swarm. I'm aware that you can at least change their portraits if you do an SM custom race start, but if you do a standard Earth start I don't believe that's possible. And you still can't change their flags without moving files around.
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on January 31, 2018, 08:01:18 AM
Quote
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.

I agree with this - i increasingly don't like how once you have built fuel harvesters the fuel is free, not even costing you workers.

Quote
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.
Title: Re: C# Aurora Changes Discussion
Post by: waresky on January 31, 2018, 09:50:38 AM
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

"..It is isn't as simple as more tax = more money, because high tax can limit growth,
You can easily check ITALIAN situation : "Official" tax level : 47% (puah..fake) REAL (Commercialist groups and big financial groups research) speack another language : 68% (68% !!!!!)REAl Tax level. The Italy situation r controvertial : +2000 € Billion national LOAN...BUT..ppl money (bank) reserve are MORE than Nat.Loan debt. ..so, European Central Bank let in peace Italian governmt about loan AND tax level.

Its a really absurd situation.

Italian PIL : more than 1000 € Billions / Years revenue..but we spend : 70% PIL in Social expenditure and others.

So TAX rules are ridicolous.

Lucky..AURORA isnt Italy...lucky.

Otherwise Italian lifestyle,automotive,luxury products,meat and Wine are absolutely State-Of-The-Art...lucky for us.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on January 31, 2018, 09:56:22 AM
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.

Title: Re: C# Aurora Changes Discussion
Post by: Hazard on January 31, 2018, 10:31:54 AM
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.

It's also true of every other planet/moon system so long as both places are sufficiently habitable.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on January 31, 2018, 02:50:47 PM
A suggestion for "auto assigning people to positions". In VB6 Aurora some positions are not auto assigned - but it would be nice if they would (like planetary governors). However I think there is no automation because the game can't choose as to what special abilities should be taken into account for an auto assignment because colonies can vary much in preference. So maybe in C# Aurora we could assign preferences to planetary positions and the game then auto chooses according to the preference (which can be defined per planetary position).
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on January 31, 2018, 07:13:40 PM
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.

I guess you'd completely remove the ability to transport pieces of an existing industrial complex. Planets with no industrial complex present by default should have "conventional industry" that's ever-present and totally free, but it's extremely inefficient (1/10th your racial rates, like it is now) and has an output based on pop-size and colony cost. Leftover manufacturing pops when you finally do actually build the correct TN facilities, would work in the conventional sector.
To still let you jumpstart colonies, you could build industrial equipment that can be moved and consumed at new holdings. Building and consuming it at the place it was constructed should be less efficient than just expanding capacity normally though, to emphasise the fact it's prefab equipment packaged specifically for interplanetary transport.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on February 01, 2018, 04:48:22 AM
Another suggestion in regards to "ranks". In my last VB6 Aurora games I always had to create a bunch of 1st level rank positions so that the higher ranks get filled because if I don't do this too many people are deemed surplus but some of the higher rank ships were not filled because there were no higher rank people (all in auto assign mode). This is due to the fixed rules how many higher ranks get filled through promotions (1/3rd on lower ranks, 1/2 on higher ranks).

I would suggest a promotion system which promotes on "demand". If all my ships would need
120 Leutenant
25 Lt. Commander
18 Commander
24 Captains
5 Fleet Captains
3 Admirals
2 Grand Admirals
then the game should promote people according to these demands so all necessary positions can be filled.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on February 01, 2018, 04:55:19 AM
Suggestion for automation of tasks: one annoying task in VB6 Aurora is the Geological Survey through teams, because if you want to do it by ships you have to manually create transfer commands each time the team finished its task. So some kind of "command": Wait at actual position until geoteam finishes task, then load up the team and fly to the next planet would be nice (in essence you do the whole command list once at the beginning for the whole range of planets you want to geo-analyse).
Alternatively another command which automatically drops off and picks up an assigned team and then auto assigns the next possible target would also be nice... .
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on February 01, 2018, 05:25:49 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on February 01, 2018, 08:19:13 AM
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.

Aurora is a military/government simulator, so it makes sense that the Personnel Bureau regularly shakes up commands. This is actually a deliberate thing; it keeps commanders from getting too much influence in a given military formation.


As for command ratios and the like, it'd be convenient if the automated system kept a tally of all positions for all ranks currently available and the ones currently under construction and used that to determine how many officers you need. But this would be a programming thing that Steve might find inconvenient.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on February 01, 2018, 12:17:06 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on February 01, 2018, 04:44:52 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on February 01, 2018, 05:36:37 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on February 01, 2018, 05:44:32 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Froggiest1982 on February 02, 2018, 12:30:01 AM
I dunno, I mean I do actually like to keep at close look at my officers every now and then and I also use a lot the not end tour tick, usually for newcomers if they have 500 or more promotion points then I do tick them to avoid any regrettable loss.

In the first 50 years or so, I also tick all ground officers and civilian administrators (you never have enough of these suckers :-) ).

I understand the need of an automatism for some, but I won't use it; I need to know my people if you know what I mean.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on February 02, 2018, 07:28:13 PM
Technically this is a suggestion, though it's related to the last change so I'm putting it here. Sicne Salacia is finally be updated to dwarf planet status perhaps it's moon Actaea could be added, as well as giving Makemake it's moon M2.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on February 03, 2018, 09:37:41 AM
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.

In purely civilian context that might happen, but at least in bigger companies there is career paths and nobody is a captain of a single ship forever.
Title: Re: C# Aurora Changes Discussion
Post by: waresky on February 03, 2018, 01:25:04 PM
ECONOMY..found :

From 2300 A.D. (site secure)

http://www.oocities.org/area51/9292/2300/economics.htm

Please...@Steve check this rare PEARL...
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on February 03, 2018, 07:42:41 PM
I'd like you to reconsider the removal of missile series. It's a more painful micromanagement hassle to have to do the same thing manually by class than if I could, for example, have a Size 6 LRM family, a Size 6 MRM family, and a Size 6 SRM family. Under the old system I can upgrade my missiles without actually having to do anything to all of my ships that use them.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on February 04, 2018, 09:32:49 AM
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.  :)
Title: Re: C# Aurora Changes Discussion
Post by: swarm_sadist on February 04, 2018, 05:07:25 PM
ECONOMY..found :

From 2300 A.D. (site secure)

http://www.oocities.org/area51/9292/2300/economics.htm

Please...@Steve check this rare PEARL...

Searching randomly through that archive yielded me a site dedicated to Angel fanfiction, what looked like someone's MySpace page, and someone who just photoshops naked women onto cat bodies...

How did you find ^^^THAT^^^ page in there?

EDIT: AH, never mind. Keep to the 2300 section.
Title: Re: C# Aurora Changes Discussion
Post by: Froggiest1982 on February 04, 2018, 10:27:14 PM
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.  :)

It will be good, meanwhile, I sorted in this way: Order to load mineral Gallicite in your case then load all minerals.
Aurora will process your request filling Gallicite first and then will process orders to load minerals following the stockpile queue.
Keeping in mind the above, you can already use your custom load queue pretty much everywhere saving the order and reusing it once needed for other TF.
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.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on February 05, 2018, 06:53:11 AM
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.

Sure, it was just a suggestion for C# Aurora. I am going through what bugs me the most in VB6 Aurora and make some QOL suggestions ;-)
Title: Re: C# Aurora Changes Discussion
Post by: the obelisk on February 06, 2018, 03:15:56 PM
If we're still on the subject of a hypothetical Economy overhaul, maybe there could be a system where different populations have some kind of wealth/prosperity value that gets drained by stuff like taxes and trade good shortages but boosted by things like government spending in the population (probably mostly in terms of installations, but maybe to a lesser extent military units and ships stationed at the population, representing them spending money on stuff when they have shore leave or whatever), civilian mine activity, exports, etc.   It would probably effect the rate of civilian mine foundation and expansion in the system, the construction of civilian ships, and maybe the production of trade goods.   It might make civilian shipping lines worth protecting/targeting, since disrupted shipping could cause economic problems.

Also, I was thinking that maybe transnewtonian minerals could become a new type of trade good (not as each individual mineral, but just in general) gets generated by civilian mines sending minerals into the civilian economy.
Title: Re: C# Aurora Changes Discussion
Post by: JacenHan on February 08, 2018, 09:04:41 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 10, 2018, 09:52:29 AM
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.

Good idea. I have made that change.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on February 12, 2018, 12:51:20 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 12, 2018, 01:48:02 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on February 13, 2018, 02:52:07 AM
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 think it wouldn't hurt to have a bit of indirect control like tax hard to prevent growth or tax low to promote it, and subsidize or tariff certain locations to promote shipping to certain destinations and discourage others. Or if they were a bit better connected with supply/demand (first delivery of a missing goods is worth alot, and colonists want to move where there are job opportunities).
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on February 13, 2018, 04:22:16 AM
I'd actually rather like to be able to offer civilian shipping higher rates in order to get them to go to out-of-the-way places.  Of course, I'd also like to be able to use them to ship minerals, which apparantly is specifically not desirable, so who knows whether its a good idea or not.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on February 13, 2018, 09:57:32 AM
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... .
Title: Re: C# Aurora Changes Discussion
Post by: Hydrofoil on February 16, 2018, 07:50:00 AM
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... .

This requires a level of economic simulation and tracking that just isnt in the game at this time.
Title: Re: C# Aurora Changes Discussion
Post by: serger on February 17, 2018, 03:48:59 AM
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).
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 17, 2018, 04:21:47 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: serger on February 17, 2018, 04:27:13 AM
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.
The best case, as for me - if first one will be deleted/filtered too.
Title: Re: C# Aurora Changes Discussion
Post by: ChildServices on February 17, 2018, 11:23:46 PM
Can we name each admin rank? Adm7 might be Proconsul or Governor and Adm1 might only be a Quaestor.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 19, 2018, 04:19:43 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: snapto on February 19, 2018, 06:47:59 AM
Quote from: Steve Walmsley link=topic=8497. msg106673#msg106673 date=1519035583
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.

I could kiss you.   On the mouth.   Repeatedly.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on February 19, 2018, 08:46:40 AM
Lagrange point auto pathing?

Oh thank you so much.

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.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on February 19, 2018, 09:40:39 AM
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.

Which opens the idea of a new technology which allows (at very high cost) to create artificial Lagrande points...  :o
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on February 19, 2018, 11:04:24 AM
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.

This is wonderful news.
But since you did name lagrange points, something very high on my wish list would be some way to actually use bynary-or-more systems with distant companions. The old hyperdrive was removed, maybe artificial lagrange points like TMaeklar said....

You know, just posting this since you are rewriting stuff   :P
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on February 19, 2018, 01:49:55 PM
Which opens the idea of a new technology which allows (at very high cost) to create artificial Lagrande points...  :o

No, let's not. That's not how the Lagrange calculations work.The reason it works in setting is because gas giants are so huge they affect local gravity enough to make local jumps possible.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on February 20, 2018, 06:32:05 AM
Maybe it could be an extension of the jump gate technology rather then artificial lagrande points. Whatever background techno babble as reasoning is needed  ;D
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on February 20, 2018, 07:29:52 PM
Yeah, it would be really neat if with the right infrastructure you could span one of those super huge systems.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on February 21, 2018, 07:30:24 AM
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 :)
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 21, 2018, 07:42:53 AM
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 :)

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
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on February 21, 2018, 09:40:02 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on February 21, 2018, 09:55:55 AM
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?

Only colony ships actually. You don't have to put infrastructure on the Moon or Mars. It just means the first 'volunteers' die in droves.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 21, 2018, 10:20:49 AM
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?

1) To create more of a sense of achievement in establishing the first colony, rather than dropping off infrastructure and waiting for the civilians to take over.
2) To slow down the initial shipping line build up.
3) (less important but useful) To make the conditions under which ships appear to be very clear.

The 'civilians in space' is less of a rationale, particularly as it appears that might be the more likely option in real life :)
Title: Re: C# Aurora Changes Discussion
Post by: LoSboccacc on February 21, 2018, 11:13:39 AM
> To create more of a sense of achievement in establishing the first colony


microtransaction and loot boxes confirmed
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on February 21, 2018, 12:18:28 PM
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

Thanks Steve.  I went ahead and made a new thread (for "v0.x" suggestions) for you, stickied it, and added some posting guidelines with the hope of keeping the signal/noise high for you when you browse it.

Best,
John
Title: Re: C# Aurora Changes Discussion
Post by: ardem on February 21, 2018, 10:36:26 PM
I could kiss you.   On the mouth.   Repeatedly.
I am Second in line to kiss steve! Especially with the new path finding code.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on February 22, 2018, 02:04:07 PM
I mean, you realise the currently released version has auto-lagrange point stuff right?
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on February 22, 2018, 11:16:01 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 23, 2018, 04:42:47 AM
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?

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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 23, 2018, 10:29:21 AM
I mean, you realise the currently released version has auto-lagrange point stuff right?

Yes, it does :)

Although in VB6, the program calculates the closest target item (system body, jump point, etc.) and then checks if the shortest route is via a Lagrange point. in C#, the program calculates the closest target item, taking into account any potential routes via a Lagrange point.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on February 23, 2018, 11:53:57 AM
Oh okay, so somewhat upgraded then.  Nice.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on February 23, 2018, 02:23:13 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 24, 2018, 05:07:56 AM
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.

Yes, will be interesting to see in which direction people go. I always like to have an engine on my asteroid miners, terraformers and harvesters so they can be self-mobile if needed. With the potential construction factory route they will be cheaper and easier to build, but immobile and very fragile.
Title: Re: C# Aurora Changes Discussion
Post by: clement on February 24, 2018, 08:26:40 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 24, 2018, 08:37:19 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on February 24, 2018, 09:18:30 AM
Good question :)

At the moment no, although you could do it in a shipyard that was large enough.

In the same vein, could you decommission a space station without a shipyard?

And shipyards large enough to build a space station, even a civilian yard, would be rather expensive, might as well use it to build space stations. Retooling won't be cheap either, if you need to swap between terraformers, miners and fuel stations.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 24, 2018, 10:27:13 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on February 24, 2018, 10:45:16 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 24, 2018, 11:08:03 AM
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.

Space stations in the same location will combine their maintenance capabilities and will draw MSP from any space stations designed as supply ships, so you wouldn't need a single station with all the required capabilities. You could have separate stations providing fuel and ordnance, etc. while another handles repairs in a large commercial hangar. Defensive military bases in the same location would be supported by the space stations with maintenance capabilities. So you can establish a station 'cluster' in deep space, rather than building and expanding a single huge station. More flexible too as you can easily add and take away individual elements. If I add deep space shipyards, they will be separate but manned by any colonists in the space stations.
Title: Re: C# Aurora Changes Discussion
Post by: Tuna-Fish on February 26, 2018, 03:28:25 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 26, 2018, 03:43:35 PM
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)
Title: Re: C# Aurora Changes Discussion
Post by: Erik L on February 26, 2018, 03:55:30 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Conscript Gary on February 26, 2018, 03:58:33 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 26, 2018, 04:16:20 PM
Do those colors match the Galactic map notations for the same? My preference would be to have consistent colors between the two.

The galactic map colours are for habitability of planets rather than type of population. The colours do match the Economics window, which displays populations greater than zero in light green and mining colonies in dark green. I've made a further improvement, which is to show the total population or, if the pop is zero, the number of the primary installation. In order of priority these are automated mines (including asteroid miners), then terraformers (including orbital), then tracking stations. This is also the same way the Economics window functions.

(http://www.pentarch.org/steve/Screenshots/AutoRoute06.PNG)
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 26, 2018, 04:19:56 PM
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.

There aren't stored with the fleet at the moment, but that seems like a sensible idea. Civilians will use the danger rating but not the alien control function. NPR movement AI isn't written yet but they will make use of some of the functions.

EDIT: Fleets now have two stored values, Avoid Danger and Avoid Alien Systems. These are set on the Movement Orders tab (using the appropriate check boxes) and will affect the algorithm used in Auto Route and for the Standing and Conditional Orders.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 26, 2018, 05:21:02 PM
I've updated the rules posts with the Auto Route changes above
Title: Re: C# Aurora Changes Discussion
Post by: snapto on February 26, 2018, 06:25:27 PM
Just curious, looking at the latest screenshots, I didn't see anywhere to add movement order templates.   Will this be going away given the new auto-move feature?  I commonly used a template to move fuel harvesters to a given location.  If templates do go away, would it be possible to add harvesters to the important installation display list?  These changes are looking great!
Title: Re: C# Aurora Changes Discussion
Post by: JacenHan on February 26, 2018, 06:30:36 PM
"Order Templates" is right below"Autoroute by system", so the options might appear only when that is selected.
Title: Re: C# Aurora Changes Discussion
Post by: snapto on February 26, 2018, 07:33:29 PM
Quote from: JacenHan link=topic=8497. msg106885#msg106885 date=1519691436
"Order Templates" is right below"Autoroute by system", so the options might appear only when that is selected.

Ah, excellent.   Good eyes!
Title: Re: C# Aurora Changes Discussion
Post by: clement on February 27, 2018, 09:32:00 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on February 27, 2018, 10:15:16 AM
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.

Longer term I will probably replace the simple on/off with an option for setting the acceptable diplomatic status (none, neutral, friendly, etc.).
Title: Re: C# Aurora Changes Discussion
Post by: TheDeadlyShoe on February 27, 2018, 12:15:05 PM
*strokes chin*

if the waypoint system is being extended like this, you could also mark Mining and Sorium Mining waypoints
Title: Re: C# Aurora Changes Discussion
Post by: PlasmaXJ on March 01, 2018, 12:44:05 PM
I can't wait to play this version!
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on March 01, 2018, 06:50:14 PM
Finally intelligent civilian!
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on March 02, 2018, 02:11:55 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 02, 2018, 02:51:29 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on March 02, 2018, 04:18:17 AM
It runs (like Standing Orders) during increments that are longer than one hour.

Ah, it's completely fine then.
Title: Re: C# Aurora Changes Discussion
Post by: Kelewan on March 02, 2018, 04:32:50 AM
@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. 

Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 02, 2018, 06:19:55 AM
@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.

The list can change depending on whether trade goods are being moved, how many freighters are inbound, changing population, treaty signings, danger ratings, warship movements, etc.. Also, the colonies being checked are depending on a search algorithm based on proximity to the freighters and each other, rather than directly.

I could potentially recreate the twin lists each increment and generate all the potential paths and then use those paths for the freighters, but I am probably creating a lot of  paths I won't use.

Besides, this test was an absolute worst case with 400 ships simultaneously requiring assignment in a large universe and it still only took one second. Even in much larger games, the normal time would be much shorter as only a few ships would require new orders in any given increment. it probably isn't worth the effort to try to achieve even better performance.

Title: Re: C# Aurora Changes Discussion
Post by: Hazard on March 02, 2018, 07:32:23 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 02, 2018, 07:38:04 AM
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.

Already unlimited in C#.
Title: Re: C# Aurora Changes Discussion
Post by: Conscript Gary on March 04, 2018, 04:33:07 PM
Quote
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 04, 2018, 05:11:51 PM
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.

Yes, it is taken into account. Civilian freighters will only pick up installations or trade goods if they can fill their holds. Otherwise, they look somewhere else.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 06, 2018, 05:18:01 PM
Another milestone. I've been trying to ensure that the complete game save is 100% accurate, so I don't encounter any major hidden bugs. That isn't so easy with almost two hundred tables, a lot of fields per table (172 for the Race table for example) and some tables with tens of thousands of rows.

However, recently I discovered this amazingly useful free utility (see link) that allows me to do a complete comparison on two SQLite databases, down to the contents of each field in record in each table. With that I have been able to squish a number of previously undetected bugs and finally get a 100% accurate save.

https://www.codeproject.com/Articles/220018/SQLite-Compare-Utility?fid=1636941&fr=26#xx0xx

The level of confidence I now have in the save process is a major step forward to running the first test game.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on March 07, 2018, 04:21:54 AM
Sounds like your approaching something that's playable soon. Awesome!  ;D
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 07, 2018, 09:31:42 AM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on March 07, 2018, 12:27:14 PM
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 suppose mechanics-wise the question would be whether you create a two step process (ie a system becomes damaged first, and then destroyed on a further hit) or if it is simply a chance of either damage state on each hit? Maybe instead of straight out damaged/destroyed you could assign a % damaged value, with the component stopping working at 50%+ and being destroyed at 100%? You could also tie that directly into the HTK mechanism, so that larger components are both somewhat resilient to being damaged and also more resilient to being destroyed.

In that case small systems are likely to always be destroyed beyond repair. You might then want to change the way Damage Control works, perhaps allow it replace destroyed systems below a certain HTK size?

Sorry, I realise this is getting complicated fast!
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on March 07, 2018, 06:44:53 PM
I think you misunderstand what he means by "damaged" and "destroyed".

"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.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on March 08, 2018, 06:00:56 AM
+1 for consistency - have MSP transfer take time too.

The on-board repairing is not IMHO overpowered at all - it requires DC module (or multiple) to bring down the time requirements to something reasonable in combat environment, it eats up MSPs like fat kid candy, and can't fix armour. As it is, it pretty well simulates the jury-rigging and such stuff that happens on ships, and you always see in sci-fi combat.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on March 08, 2018, 08:23:51 AM
I think you misunderstand what he means by "damaged" and "destroyed".

"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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on March 08, 2018, 11:01:58 AM
Oh, then I agree.  I think it should be something like some pen-and-paper roleplaying games do.  In Star Wars D20, you lose consciousness when your health hits zero.  You die when it hits negative 10.  Maybe something like that could be done for each part, and even tie it into repair time.  An engine with 10 health could lose efficiency every time it takes a hit, down to 1.  Then at 0 it shuts off totally.  Then it can continue losing health down to -10, at which point it is totally destroyed.  Anything above -10 can be repaired by the crew, and is repaired one point at a time.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on March 09, 2018, 02:24:14 AM
Maybe MSP loading could use either Cargo Shuttle bays or Ordnance Transfer logic ( renamed to Military logistics systems or something like that instead ).

It would feel quite odd and fiddly for it to require a fourth separate system so we have refueling, cargo, missiles and MSP all transferred differently


And hey your Ordnance Transfer logic already is capable of transferring "rate at 40 MSP per hour"  ::) ;D *runs and hides*
Title: Re: C# Aurora Changes Discussion
Post by: JacenHan on March 09, 2018, 10:41:57 AM
I think it would be reasonable for engineering spaces to act as the MSP transfer component, since every vessel with MSP will have at least one. That way, you can have non-instant transfers and the player doesn't have another type of component to worry about when designing ships.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on March 09, 2018, 01:41:48 PM
Things shouldn't be too fiddly or too expensive; reusing existing components seems reasonable.

Expanding logistics is turned on its head if it is too onerous and hence encourages playing around logistics entirely:
Design for fuel efficiency, no fuel logistics beyond the bare minimum.
Long-lived disposable designs instead of maintenance.
And so on. Doing things "as intended" should have upsides.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 10, 2018, 05:09:15 AM
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?

Title: Re: C# Aurora Changes Discussion
Post by: Zincat on March 10, 2018, 05:49:39 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on March 10, 2018, 06:19:38 AM
Area Defence Mode: no
Final Defence Mode: yes

It's the difference between being a possible third-party in a missile exchange, and being the actual target.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 10, 2018, 06:42:25 AM
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?

What about AMM ships - do you want some control over which ones fire?
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on March 10, 2018, 07:23:54 AM
Makes sense to me to have the option. Agree on control in area def mode and always on in final fire mode.
Title: Re: C# Aurora Changes Discussion
Post by: King-Salomon on March 10, 2018, 08:58:30 AM
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?

Depends... if the system is computer controlled all the time, the computers should be able to start a "last second emergency defence" (maybe with reduced efficiency? - could also be a new tech?)

If the system is not fully computer controlled all the time (or the system is shut down like in maintenance, resupply etc) I wouldn't think it would be realistic...

an area defence I wouldn't think realistic - just a "panic emergency" reaction to defend the ship itself - and only with PD not missile launcher...

would be a bad day for a ship captain to let the computer shot down friendly shuttles because it thinks they are hostile missiles...

---

I would like to get the "auto defence" in a simple and cheap tech were the player/race may include it in a fire controll system for PD - or if he thinks he does not need it, let it out  (that of course a much more complicated system as just say "yes" -.- )
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on March 10, 2018, 09:13:39 AM
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?

Yes, although if a PD ship is facing hostile/neutral missiles entering his defense envelope there should probably be an interrupt in the update sequence because a player may want to start shooting. Final Defense Mode should be an exception; the ship's clearly made anyway so you might as well unload with everything you've got to not die, you are not going to be giving your position away with weapons' fire.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on March 10, 2018, 10:17:00 AM
What about AMM ships - do you want some control over which ones fire?

Leaving interface complexity problems aside for the moment, I would think the following is most realistic:

1)  Have a "Weapons Free?" selector with three possible states: "Yes", "No", "Defensive Only".  "Yes" presumably corresponds to "open fire" on; "No" to "open fire" off.
2)  Have a different selector for beams and missiles.
3)  The granularity of the selector could be at the fleet, TG, ship, or FC level (or all of these levels to allow global policies with local overrides).
4)  For area defensive fire when aliens are present, more nuance could be added to "Defensive only", with "My race", "My allies", "Neutral", and "Any" levels (where each level includes defending the ones above this, i.e. Neutral would defend my race, allies, and neutral).  I think it's fine to use Aurora's knowledge of who the missiles are targeting, since it should be fairly obvious in most cases (ignoring exploits like waypoints).  These sub-levels probably don't need to be actual Weapons Free? states - it's probably enough to have a separate state at the TG, fleet, and/or empire level.

My inclination would be to have the weapons free settings at the TG, ship, and FC level.  I don't think this would hurt interface complexity, since the "open fire" setting is already at the FC level.  You might also want to nuance the "Yes" state of weapons free to "Only within range" vs. "Do it, d**n it!" and/or have a %max range setting for it so e.g. in a few clicks the player could order all the ships in a TG to open missile fire when their targets have closed to 70% of the missiles' range.  If you combined this with general auto-targeting orders like "engage enemy class X first" and "Y missiles/target" it might help a lot with the micromanagement in combat. 

If you go down this road (of "engage class X first"), I would let the AI (and possibly players) figure out the exact class of enemies with very little sensor input.  The reason for letting the AI know this would be to allow the AI to build up threat profiles to avoid the "big armored missile sponge blob" exploit - if a ship class has been observed to have tons of armor and no missiles, it would presumably be dropped near the bottom of the threat engagement list (and possibly only engaged by beams at very close range and/or simply avoided/evaded) in favor of engaging thin-skinned missile combatants.  Since AI is so hard to write, I don't think it's unfair to give the AI some help in figuring these things out.

John
Title: Re: C# Aurora Changes Discussion
Post by: Rook on March 10, 2018, 12:12:00 PM
Not sure on the level of complexity here. . . 

Point-defense Final Fire: I agree, yes.  Always "On".

PD Area Defense: I suppose default, off.  As already suggested (and a pretty great idea): fleet-wide orders to have Area defense engage any/all hostile missiles, and/or fighters, with-in range, automatically.

Veteran players may have experienced situations where an Area Defense engaging missiles automatically is a bad thing, but I couldn't think of such a situation.  However, I will defer to the veterans on how that setting should be handled.  In lieu of an any situation where it is undesired, I don't see why Area Defense shouldn't automatically engage.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on March 11, 2018, 04:10:11 AM
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.

The only situation I can envision in which I might want to choose who will shoot is when there's overkill: I have 250 AMM ships, and there's 3 incoming missiles. Obviously in this case, I don't want 250 ships to shoot at 3 missiles... Likewise, I probably don't want to shoot 10 times at the same incoming volley, if I have a technological advantage that allows for that.

An on/off switch might make sense, in this case. Or perhaps, a new fire control operation mode. You could have a "point defence autofire" mode which always shoot at every incoming threat until its down.



A note on what Garfunkel said. Being a third party in a  missiles conflict... While I completely understand, I believe it's a rather sticky issue. Because a third party, once missiles are flying, does not actually KNOW whether or not the missiles are going to hit its ships. What if it's all a ruse and both the other contendants are actually targeting your ships? What if the missiles are only pretending to go for the other ships, and are going to change target at the last second and hit your ships?  If you are at the location, and there's missiles flying, should you shoot? Would you shoot?

I still think that "beam" weapons assigned to point defence should just shoot down missiles who come too close. If we want to model the "third neutral party" situation better, I think an empire-level switch would be better. You are able to select, maybe in the diplomacy screen, which other races are "friendly" and which are "hostile". Unless you change that classification, friendly ships/missiles are not going to appear in the contact list, nor are going to be targeted by point defence,. If you want to open hostilities, you go to the diplomacy screen, set a race as "hostile", and suddenly all the contacts are going to be available, and missiles will be auto-targeted.
An IFF system, so to speak. Ships and missiles of nations considered "friendly" are not valid targets, unless you change their identification.
Title: Re: C# Aurora Changes Discussion
Post by: hyramgraff on March 11, 2018, 03:26:05 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 11, 2018, 06:42:30 PM
If your ship has good shields and you're facing a small salvo then letting the shields absorb the damage is a viable option.

Also, if you have decent energy weapon point defence or gauss you may not want to expend missiles against smaller salvos.

I think probably Auto-fire is fine for Final Fire, while on/off is necessary for area fire and AMMs.
Title: Re: C# Aurora Changes Discussion
Post by: Viridia on March 11, 2018, 06:51:10 PM
It would be nice if designating missiles as AMM's in the design stage was an option. In a recent game I was using size 2 launchers, but due to the missile size, these weren't being fired even with the anti-missile fire controls set to engaging incoming targets. Energy weapons too I've found a pain using as point defence, because they seem to suffer from the same issue. Having all of them set to on by default would be great, and fits with how most militaries would work anyway.
Title: templates
Post by: eponymous on March 12, 2018, 09:27:26 AM
steve:

the way you described damage templates over in the "changes" thread makes it sound unnecessarily complicated.   i have no idea how much processing time is wasted, because im not at all a programmer, but nested loops will apply the damage correctly

"G" is the penetration coefficient (you referred to it as gradient)

apply the first G points to the hit location H, then loops:

increase W (the current width of the crater)
repeat G times:
     apply damage from column (H-W) right until (H)
     apply damage from (H+W) left until H

gotta break when you run out of damage, gotta do the usual mod thing to apply the damage to an armor column that is actually on the ship.   if you want to replicate the bug that the crater stops getting wider after a certain damage level that isnt hard but it's on you :)


     
Title: Re: C# Aurora Changes Discussion
Post by: TCD on March 12, 2018, 09:30:14 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 12, 2018, 11:34:52 AM
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.

C# Fire controls currently are green when off and orange when active.
Title: Re: C# Aurora Changes Discussion
Post by: King-Salomon on March 13, 2018, 03:47:22 PM
@ 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
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 13, 2018, 05:45:32 PM
@ 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.

2) Display order is based on the Sort options at the bottom.

3) Good idea. I'll add that.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on March 14, 2018, 04:11:57 AM
1) If you click on a line, the whole line is highlighted.

Still lacks a bit for overview if you need to click. It might make sense to have spreedsheet standard slightly alternating background color for lines like this:
http://www.ksosoft.com/images/spreadsheet-auto-contraction.png
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on March 14, 2018, 10:57:27 AM
My Reaction when seeing battle results appear in the changes list:

(http://www.reactiongifs.com/r/swih.gif)
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 14, 2018, 11:10:30 AM
Just for interest...

 I am just starting to look at the code for missiles detecting their own targets. I was aware that the new sensor changes would make missile sensors much more effective (which is why I added the rule about 0.25 MSP minimum). However, seeing it in action will be quite different than the theory.

For example, assume we have a race with active sensor tech of 21 and EM tech of 11. A VB6 active sensor with resolution 100 and size of MSP 0.25 (or 0.0125 HS), with active strength of 0.26, could detect ships of 5000 tons at 285,000 kilometres. The same missile sensor in C# Aurora will detect 5000 ton ships at 4,430,000 kilometres.

If we change the above active sensor for a Thermal sensor of the same size (and assume Thermal Tech 11), it will have a thermal sensitivity of 0.14. The Commonwealth Tribal M class destroyer (standard laser-armed design of 6365 tons) has a thermal signature of 650. The VB6 version of the sensor would detect the ship at 90,000 kilometres. In C#, the range will be 2,370,000 kilometres. That range gap will drop though for more powerful active sensors and for larger target ships. The C# passive advantage is more pronounced for small sensor and small signatures.

Finally, lets change the above active sensor for an EM sensor of the same size, which will have an EM strength of 0.14. Now lets assume we want to use that missile for a HARM attack on a ship with an active sensor using the same tech. Lets say size 3, resolution 100. In VB6, the missile sensor will detect the ship-based sensor emission at 882,000 kilometres. In C#, the range will be 7,424,621 kilometres. That range advantage will drop though for more powerful active sensors or more powerful emissions

Even so, there is a lot more scope for passive attacks and mines will probably become effective in other places beside jump points.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on March 14, 2018, 02:17:59 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 14, 2018, 02:46:46 PM
That's a big change and it's definitely going to have tactical ramifications. For instance, in addition to mines being more potent, I also think sensor drones and buoys might suddenly be more practical.

Since I've seen the point raised that fighter strikes are going to be extremely difficult to spot, it also raises the possibility of launching a spread of resolution 4 tracking missiles at where you think inbound fighters might be, especially if you spot them coming with a scout ship or a sensor drone.

I'm going to go with my response to most of the other balance changes - Awesome! Emergent tactics are a lot of fun, and if it leads to anything too overpowered it can always be rebalanced later.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on March 14, 2018, 07:11:39 PM
Oh hey sensor missiles, brilliant!

Might be really unpleasant to make use of potentially though, in terms of finicky clicks to get waypoints laid out and such.
Title: Re: C# Aurora Changes Discussion
Post by: Shiwanabe on March 14, 2018, 08:06:46 PM
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.

While this is a valid concern, a GPS of .26 wouldn't take into account the Resolution of the active sensor.

Currently we don't know if Steve will be applying it as a straight multiplier (ala VB6) or raising it to the 1/1.5 as it is in the active range equation.
So, here's a quick table of both options and the detection ranges. (Assuming Steve isn't going to use a root in the GPS equation)

GPSEM 1EM 5EM 10EM 20EM 50EM 100EM 200EM 500EM 1000EM 2000
RES26.251,281,0002,865,0004,051,0005,729,0009,058,00012,810,00018,120,00028,650,00040,510,00057,290,000
RES^(1/1.5)5.655594,6001,330,0001,881,0002,659,0004,204,0005,946,0008,408,00013,300,00018,810,00026,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.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on March 14, 2018, 09:53:29 PM
I don't like the entire concept of the streamlining of combat readouts, but I'm willing to give it a try. My gut reaction is negative though, I kind of like reading a long ass scroll detailing every weapon and every hit. This summary just feels kind of sterile to me. Maybe it'll feel better when playing it though, when more familiar with the actual designs involved.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 15, 2018, 03:33:14 AM

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.

I'll add the crew casualties.

This is the rule post on missile engines:

http://aurora2.pentarch.org/index.php?topic=8495.msg102804#msg102804
Title: Re: C# Aurora Changes Discussion
Post by: JacenHan on March 15, 2018, 12:22:25 PM
Doesn't the VB6 class intelligence window show the type of weapons an enemy ship has after they use them?
Title: Re: C# Aurora Changes Discussion
Post by: tobijon on March 15, 2018, 01:20:48 PM
only for energy weapons i think
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on March 16, 2018, 12:57:18 PM
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
Title: Re: C# Aurora Changes Discussion
Post by: Shiwanabe on March 16, 2018, 03:39:16 PM
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

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.

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.

I wasn't hoping to know what shot me. I was only hoping that there would be a line per incoming type. From a realism perspective I can understand how difficult it would be to tell which hit did what, but it's still something that would be nice to know. ;)

The other idea would be to inform the defender of how many holes in their armor belt there are. (ie; giving the damage summary a line about how many penetrating hits occurred.)
To use the first damage summary as an example:
Code: [Select]
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

Ah, thank you. I think I remember seeing that but didn't see it when I did a quick pass over the thread. My apologies.

It looks like a very elegant way of dealing with it and doesn't even feel like a 'missile only' type of solution.

The break point for keeping the old range seems to be at about 66% of the old speed/power multiplier, so ~33% lower accuracy. Very interesting.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on March 17, 2018, 01:24:42 PM
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.

John
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 17, 2018, 01:50:55 PM
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.

The rationale was that the attacker needs to see if any hits penetrate. The defender sees the specific internal damage, which is more useful than the number of hits penetrating. I can add the penetrating hits number as well.
Title: Re: C# Aurora Changes Discussion
Post by: Froggiest1982 on March 17, 2018, 04:57:53 PM
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!
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 17, 2018, 05:50:01 PM
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!

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.

Title: Re: C# Aurora Changes Discussion
Post by: Hazard on March 17, 2018, 06:17:17 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on March 17, 2018, 10:29:20 PM
I'm really excited about ground unit CIWS, that replaces a lot of the functionality lost to PDCs going away, now I can have hordes of missile defense bases on earth again.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 18, 2018, 05:36:38 AM
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?

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.
Title: Re: C# Aurora Changes Discussion
Post by: Titanian on March 18, 2018, 10:30:20 AM
Quote from: Steve Walmsley
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?

I'd prefer the first case, and expect the second case from your description.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on March 18, 2018, 11:07:58 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 18, 2018, 12:15:35 PM
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.

In VB6 missile salvos move in decreasing order of speed. Point defence operates as those salvos arrive at their targets. Ships with Final Fire will protect whoever is getting attacked, potentially sacrificing their own defence if a salvo attacking them is moving later in the phase. Ships can be set to Final Fire (self-only) to prevent that happening. Generally, this isn't a major issue because incoming salvos in the same wave are often concentrated on a single target. if multiple targets are attacked in the same wave, that leans fewer missiles per target, making it more likely ships can handle their own defence.

I can add some more options, but this can get complex really fast. For example, if this is automated, will an Arleigh Burke shoot at one missile heading for the carrier or twenty missiles heading for it. If it would protect itself, what does the balance of missiles have to be before that equation changes? Does it depend on the performance of the missiles, or the existing damage to the CV or DD? How about what other escorts ships are doing? Do you even know which enemy missiles are heading for which target. If not, what do you do in that situation?

I am happy to implement any additional, straightforward point defence rules. It's just tricky to make them 'straightforward' :)
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on March 18, 2018, 12:17:13 PM
I'm pretty happy with it as it stands, yeah. If for no other reason then that it's not clear to a defender what the missiles' targets are.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 18, 2018, 01:17:59 PM
I've moved on to coding missile combat. In this example, the French missile cruiser Clemenceau is launching against a US destroyer. The launch summary includes the range and the estimated chance to hit (although that can change while the missiles are in-flight).

(http://www.pentarch.org/steve/Screenshots/MissileCombat001.PNG)

(http://www.pentarch.org/steve/Screenshots/MissileCombat002.PNG)

The destroyer does not have any active sensors that can detect the missiles. However, there are four deep space tracking stations on the planet. With the new passive sensor model, they can detect the French missiles from launch.

(http://www.pentarch.org/steve/Screenshots/MissileCombat003.PNG)

First salvo arrives, scoring eight hits, two of which penetrate the armour. I've added the number of penetrating hits to the defender summary. 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..

(http://www.pentarch.org/steve/Screenshots/MissileCombat004.PNG)

(http://www.pentarch.org/steve/Screenshots/MissileCombat005.PNG)

(http://www.pentarch.org/steve/Screenshots/MissileCombat006.PNG)

Four more salvos arrive.

(http://www.pentarch.org/steve/Screenshots/MissileCombat007.PNG)

(http://www.pentarch.org/steve/Screenshots/MissileCombat008.PNG)

(http://www.pentarch.org/steve/Screenshots/MissileCombat009.PNG)

(http://www.pentarch.org/steve/Screenshots/MissileCombat010.PNG)

The sixth salvo is sufficient to destroy the ship.

(http://www.pentarch.org/steve/Screenshots/MissileCombat012.PNG)

(http://www.pentarch.org/steve/Screenshots/MissileCombat014.PNG)

I'll show some point defence examples when I finish the code in that area.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on March 18, 2018, 02:13:02 PM
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 an amazing improvement in my opinion. Very glad to hear that. I can imagine a lot of possible uses for this  :)
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on March 18, 2018, 03:32:29 PM
Even if it is clear, having that carrier eat the missile and intercepting those 20 missiles aimed at the Arleigh Burke might be the better option if that carrier can take the blow but not the half a dozen salvos following in trail and numbering a dozen missiles each.

As Steve noted, this can get very complex, very fast.

EDIT: Steve, please consider writing salvos with the number of missiles in them. It would seem to me to best fit behind the signature.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on March 18, 2018, 06:08:47 PM
Could we also have an ETA when firing missiles?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 18, 2018, 06:14:18 PM
EDIT: Steve, please consider writing salvos with the number of missiles in them. It would seem to me to best fit behind the signature.

Yes, that's a bug - need to see how many missiles :)
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on March 19, 2018, 08:04:54 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on March 19, 2018, 11:28:57 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: boggo2300 on March 19, 2018, 03:23:42 PM
That is going to be very helpful. We need to push for 16k-Monitors :D Can someone write an email to Elon?

Why so he can over promise and under deliver again?

Bezos would be a much better choice if you actually want a 16k monitor
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 19, 2018, 05:13:09 PM
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.

If there are shield hits, they will be listed separately.
Title: Re: C# Aurora Changes Discussion
Post by: Froggiest1982 on March 20, 2018, 07:06:14 PM
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...
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 21, 2018, 06:09:15 AM
Hi @Steve Walmsley, sorry I do live in New Zealand so I have a different season calendar! My spring starts end of September...

Ah! Very good point. I would be disappointed if I wasn't well into a test campaign by your spring :)
Title: Re: C# Aurora Changes Discussion
Post by: the obelisk on March 21, 2018, 01:04:49 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 21, 2018, 01:46:10 PM
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?

Two ground units on different system bodies will be able to shoot at one another (when I write that code).

For now, ground weapons will be non-turreted. I might look at that in the future.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on March 21, 2018, 04:06:20 PM
It should probably be possible to place single mounted cannons into ground based turrets. Not least of which because while ships can haul the whole ship around if necessary to track a target and land a blow, a ground cannon can't shift around the planet to do the same.
Title: Re: C# Aurora Changes Discussion
Post by: Bughunter on March 22, 2018, 07:22:28 AM
a ground cannon can't shift around the planet to do the same.

I find your lack of faith disturbing..

(https://upload.wikimedia.org/wikipedia/en/f/f9/Death_star1.png)
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on March 22, 2018, 07:41:00 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: SerBeardian on March 23, 2018, 04:58:02 AM
Quote from: MarcAFK link=topic=8497. msg107352#msg107352 date=1521765660
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.

Steve already mentioned that's a bug he needs to fix.
Title: Re: C# Aurora Changes Discussion
Post by: mtm84 on March 24, 2018, 05:25:19 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 24, 2018, 07:15:58 AM
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?

Yes, you can have armour for infantry.

The occupation strength (used for both occupation and unrest) is equal to the square root of the size of each ground unit at the population. So 1000 Size 5 infantry would have 2236 strength, while 50 Size 100 tanks would have 500 strength. So infantry is better at occupying and pacifying than tanks. A new commander Occupation bonus will boost this for each formation as a whole.

The resistance of a population is based on the average of determination, militancy and xenophobia. The required occupation strength is equal to Resistance * Population Amount * Occupation Status Mod.
Title: Re: C# Aurora Changes Discussion
Post by: Coleslaw on March 24, 2018, 09:32:42 AM
Quote from: Steve Walmsley link=topic=8497. msg107366#msg107366 date=1521893758
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 24, 2018, 11:08:50 AM
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.

There is nothing like that at the moment, but I don't see any reason why there couldn't be a flag for each formation that specifies the most important bonus type for automated assignment purposes.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on March 24, 2018, 02:34:48 PM
This could be handled by slightly expanding the special training/equipment mechanics for formations, granting a modest boost in a skill area like normal against a small increase in cost, and setting the preferred commander skill to a different one than normal.
Title: Re: C# Aurora Changes Discussion
Post by: Shiwanabe on March 24, 2018, 06:57:26 PM
Those magazine changes look interesting. I'm not sure of all the effects it'll have, but I already know I'm going to be making more than one size of magazine now.  ;D
Title: Re: C# Aurora Changes Discussion
Post by: Triato on March 25, 2018, 02:12:54 PM
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.

I am liking the new aurora so much that I feel very picky writing this comment.  Hope it helps,  but it doesn't really matter if it is not implemented.

Thanks Steve
Title: Re: C# Aurora Changes Discussion
Post by: King-Salomon on March 25, 2018, 02:20:04 PM
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.

well, I was thinking the same - maybe a special "spying modul" would explain it - which is (hopefully undetected) searching for sound-waves/transmisions in the aether...

hmm.. a new tech with a new modul for special ships.. there I go, making it more complicated that it has to -.-
Title: Re: C# Aurora Changes Discussion
Post by: Shiwanabe on March 25, 2018, 05:45:59 PM
Quote from: Steve Walmsley link=topic=8495.msg107378#msg107378
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.

This looks mostly good, there's just one thing bugging me.

I've recently been running a game with maxed tech and I've only used res 1 sensors. At that tech level you're looking at such long ranges on them and such small signatures on ships due to cloaking that this assumption will fail completely.

I suspect this kicks in a few levels lower, but it's also far above what most people are likely to see with VB Aurora.

Quote from: Steve Walmsley link=topic=8495.msg107378#msg107378
Note that missiles are automatically assigned to launchers.

Looking at your last example it shoved the Vortex Torpedo into all the launchers. This means it's not grabbing the biggest stack, so what are the rules this goes through?

 
Quote from: Steve Walmsley link=topic=8495.msg107378#msg107378
Communication Attempts

Oh boy. This is definitely going to be a change. No clue how this will play out, but with current diplomacy you'd likely run into problems due to having had a ship detected in one of 'their' systems for this process.

And I do agree with other people's comments on the 'willingness' requirement. If you're intercepting enough communications you'll get there eventually, it'll just take a lot longer.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on March 25, 2018, 06:32:31 PM
I'll echo the others; it should be possible to get an effective translation going without a willing partner. I would reckon you'd need to detect a planetary population's EM signature at a good enough resolution to get a chance at deciphering their language though, which would mean more than just knowing there's a planet spewing EM radiation into the ether, you'd need to get close enough depending on your EM sensor strength to actually start working away at figuring out how their television channels and radio systems work.
Title: Re: C# Aurora Changes Discussion
Post by: Conscript Gary on March 26, 2018, 06:41:33 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: the obelisk on March 27, 2018, 02:56:53 PM
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.

Requiring ships with specialized modules for the purposes of translation seems incredibly tedious, particularly given that first contact is likely to be one of your ships encountering one of theirs in an unpopulated system.  In all likelihood you'd HAVE to track down one of their colonies, or wait for them to track down one of yours, because the alternative is a needle-in-the-haystack game of trying to run your translation ship into theirs.  I'll admit I have some bias on the issue because I don't think flat out replacing Espionage and Diplomacy teams with ship modules is a good idea, but this seems to needlessly complicate NPR interaction without making the experience more enjoyable or engaging.
Title: Re: C# Aurora Changes Discussion
Post by: IanD on March 27, 2018, 03:07:34 PM
Steve wrote "Communication Attempts

There are two additional constraints on attempting communication with alien races in C# Aurora.

1) Translation checks will only take place effort can only take place if both sides have a status of "Attempting Communication". In other words, you can't translate their language if they refuse to talk to you." ...... Unless you have occupied a colony?


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.

Ian
Title: Re: C# Aurora Changes Discussion
Post by: the obelisk on March 27, 2018, 03:09:17 PM
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.

The Rosetta stone helped with translation because it said the same thing in multiple languages, and several were already understood.  If you've got access to a colony, though (or even if you can pick up its EM emissions, really), you should definitely be able to make translation attempts.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on March 27, 2018, 06:14:42 PM
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.

It'll take a while, especially to grasp the grammar, but it'll get you the writing system fairly quickly simply because you can start stringing words/symbols together when you know the meaning of them and then use those to form a crude translation system.


Well, there's a few caveats, one of which is that you need a species whose primary sense is the same as yours, but that's a really simple start.
Title: Re: C# Aurora Changes Discussion
Post by: the obelisk on March 27, 2018, 08:46:44 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on March 28, 2018, 03:44:31 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on March 28, 2018, 05:12:10 AM
Consider letting such a module to have a (small) chance of intercepting changes in orders for fleets, letting players see where a ship is moving to and/or what it's carrying.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on April 07, 2018, 01:45:37 PM
Can I suggest the weapon failure rate use recharge time as a multiplier? As it is it makes larger weapons much more efficient in terms of failure rate, and it makes sense that a small, rapid firing laser would have more mean shots to failure than a giant spinal one that fires once a minute. A multiplier would make it so they both at least suffer the same average number of failures in 10 minutes of sustained fire.

Also, is the failure chance modified by crew grade and/or officer skills? Might be a nice bonus for highly trained crews.
Title: Re: C# Aurora Changes Discussion
Post by: linkxsc on April 07, 2018, 02:28:13 PM
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.

Perhaps have bonuses to their ability to translate based on the EM sensors of the ship the module is built into?
Title: Re: C# Aurora Changes Discussion
Post by: mtm84 on April 08, 2018, 02:53:11 AM
it makes larger weapons much more efficient in terms of failure rate

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.
Title: Re: C# Aurora Changes Discussion
Post by: Draco_Argentum on April 08, 2018, 06:18:05 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on April 08, 2018, 06:59:31 AM
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 may modify this once I get into play test. This is an average though so some systems may have more eligible worlds and other may have none. Overall, the intention is to make ground survey less common and therefore more interesting. That was my intention with teams, but you can literally resurvey every rock under the VB6 mechanic.
Title: Re: C# Aurora Changes Discussion
Post by: sublight on April 08, 2018, 09:13:59 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on April 08, 2018, 09:40:18 AM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on April 08, 2018, 12:22:36 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Zincat on April 08, 2018, 12:36:14 PM
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.

I think this would be a good solution. 1.1 average target per system is way too low in my opinion. I would raise that at least to 3-4 potential targets per system (in systems with a decent amount of planets). But most of those should be minimal or low potential anyway.
It is completely fine instead if High and Excellent worlds are very rare.

You could change it to something like: for worlds 4000 km diameter and more,
None 60%, Minimal 20%, Low 13%, Good 5%, High 1.5%, Excellent 0.5%
If the numbers are still too low, lower the min diameter to 3000 km or similar. Potential high value targets should be very rare, but there should be SOME possibilities to find a bit of minerals if one want to expend the resources and time needed to do ground survey.
Title: Re: C# Aurora Changes Discussion
Post by: King-Salomon on April 08, 2018, 03:01:55 PM
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.

1) I like this :)

2) an other question about this:

Quote from: Steve Walmsley
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 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 :)
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on April 08, 2018, 05:06:39 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on April 08, 2018, 05:16:43 PM
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 :)

Ground surveys will start automatically.

Each geological survey component is worth 0.1 per day. Assume a basic unit design is a geological survey vehicle with two components, allowing 0.2 per day and a size of 218 tons. If there a formation type of 'Geosurvey Expedition' with twenty such vehicles, plus some supporting troops and a HQ, that would be about 5000 tons transport capacity. A survey of an Earth-sized planet would need about five months.

You are correct about the ability to survey and restore and I understand that isn't very realistic. However, by following that strategy, you could well be missing out on higher accessibility and extra mineral types while you wait. Generally, it is accessibility and variety of minerals that is the most important factor on larger worlds, rather than total supply.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on April 08, 2018, 08:36:24 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on April 09, 2018, 02:32:11 AM
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.

Giant weapons don't help too much because each weapon can only destroy a single installation per shot (including infrastructure), plus you still have to build and maintain the mounting ship.

However, ships only using their larger weapons for planetary bombardment (i.e. not PD weapons) is what I am aiming for.
Title: Re: C# Aurora Changes Discussion
Post by: Draco_Argentum on April 09, 2018, 02:40:14 AM
Quote from: Steve Walmsley link=topic=8497. msg107721#msg107721 date=1523198418
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.

True, a 4X where two of the Xs are pointless because you already have everything you need wouldn't be very good.  The new system is also much better than the current survey everything setup.

What if dwarf planet size bodies had no chance of excellent and reduced odds of good and high? I just think the dwarf planets and big moons are cool basically.  Not a big deal either way though.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on April 09, 2018, 03:19:32 AM
Quote
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.

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?
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on April 09, 2018, 04:29:58 AM
Regarding weapon failure rates; I think it would not be bad if the system was a little more granular. For example, with 4 levels.
The first level, Glitch, is a very minor failure that takes a minute to resolve and costs no maintenance points. Glitches can propagate to the fire control system, which can be particularly devastating for point defense arrays.
The second level, Minor Maintenance, means the weapon fails to fire and loses all charge and must be repaired with half the maintenance points, which takes about 5 minutes.
The third level, Major Maintenance, means the weapon fails to fire, loses all charge and must be repaired at full cost through the damage control teams. Minimum repair time is 15 minutes.
The fourth level, Catastrophic, means the weapon misfires. It dumps half the damage of a point blank shot in the ship's armour and the remainder runs through the ship, hitting the weapon first.

Regarding ground surveys; it's probably fine to have any celestial object large enough to end up round under the influence of its own gravity be a candidate for the ground survey algorithm. It should probably be a much lower chance of finding anything as well as the size and richness of the deposit, of course.

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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on April 09, 2018, 04:48:26 AM
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.

The way I read it only being able to destroy one target only applies to beam weapon fire (which does very low pop damage), not to nukes:

Quote from: C# Aurora Changes List
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.
Title: Re: C# Aurora Changes Discussion
Post by: Azarea on April 09, 2018, 05:36:38 AM
Any chance the treshhold and chances for mineral surveys can be made a tweakable during game setup? Then people can tweak them after their own preferences/playstyles.
Title: Re: C# Aurora Changes Discussion
Post by: db48x on April 09, 2018, 09:38:34 AM
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.

I think some atmospheric effects would be nice to have.

An atmosphere magnifies the effects of a nuclear explosion (or any large explosion at all, but especially nuclear because the atmosphere absorbs all those x-rays, making the fireball and pressure waves larger). On an airless world a nuclear explosion could overkill a facility while doing very little to anything nearby.

The same atmosphere will also absorb energy from a laser, weakening and defocusing it. Naturally this depends on the depth of the atmosphere, its density, and (to a lesser extent) its composition. Seems like there could be a lot of fun to be had there; the player might want to keep some old lasers around, since the the atmosphere around their latest target might as well be opaque to their new fusion-pumped x-ray doom lasers of doom.
Title: Re: C# Aurora Changes Discussion
Post by: TheBawkHawk on April 09, 2018, 01:41:37 PM
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?

Why not have nukes kill a certain percentage of the population? Just some numbers off the top of my head, the casualties would be calculated as (population*damage)*(0.001 +/- up to 0.0005) with minimum casualties being ~1k per point of damage. So if you're bombarding a colony of 100 million, each damage point is going to kill 50k to 150k civilians. After some bombardment, lets say you got the colony down to ten million population, then each point of damage is going to do 5k to 15k casualties. Exact numbers and formula are of course subject to change.

I think a system that uses percentage based casualties would solve the issue of colonies being super easy to wipe out with nukes, while also making it a little more realistic with you being able to fire at the largest targets before having to eventually move on to the smaller ones.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on April 09, 2018, 04:04:41 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on April 09, 2018, 05:40:41 PM
Colonisation patterns are likely to be very similar to habitation in the American Midwest and in Siberia. Mostly due to a variety of factors, all of which are to do with food and water.

To put it quite simply, without food and water it doesn't matter how rich a place is in resources. This means that without a way to acquire enough food in an area that can be worked by 1 individual it doesn't matter what else is in the ground there's not going to be any colonisation or exploitation of that area. You'd simply starve to death. We've seen mining towns sidestep this issue by digging up resources and exchanging them for food.

However, this presumes that food keeps well enough to store long enough to transport it to where it needs to go. While generally speaking cereals and other staple foods can be moved in relative bulk without needing to worry much about freshness, meat and vegetables are more vulnerable to rot and decay. Without a way to store those for travel populations won't urbanise much. There's quite frankly no way to move a number of important sources of vitamins across more than 20 to 40 kilometers of distance (especially on bad roads) without causing issues in local diets, greatly increasing the spread of disease. Combine this with pre-modern poor hygiene in cities and you'll see why cities before the industrial revolution had a net negative growth and needed a constant supply of peasants moving in just to maintain their size.

This is the main factor why Europe, for example, has such a large number of relatively modest sized cities for its population, and why there's a town every 10 kilometer; that was effectively a day trip for the average farmer.


This changes in the modern era. Massively.

People go where there's food, money and people, in that order. With modern storage, refrigeration and mass transportation techniques vast quantities of food can be moved at speed across large distances. Rome in the glory days of the Roman Empire had roughly 1 million people, and that required a constant supply of grain and produce from the Empire (mostly the very fertile Nile flood plains), brought in by boat. These days we can supply vastly more food across larger distances, by truck, by plane, by ship, and most important for food, by train. Trains do two things; they move fast (about 60 to 80 kilometers per hour even for cargo), they move a lot (20 truck load equivalents is small for cargo trains), they move them efficiently, they move them across large distances and they move them refrigerated or frozen when needed.

I would anticipate that colonisation of planets in the modern space era would be based on the question of where are the money making resources (mostly metals and oil), which will be the focal points of the original colony. If there's a lot of such resources on planet a town will spring up, otherwise you will see something similar to a lot of long abandoned small towns that were originally founded to exploit local ore seams. This town will originally be supplied from space when it comes to food and everything else; if the planet is sufficiently earthlike or can otherwise be tamed local farms with expansive fields are likely to establish themselves. If not hydroponic farming is the most likely due to small footprint.

As the planet draws in more settlers to exploit local resources an infrastructure network will start to establish itself. It will start with limited air traffic, as air traffic doesn't need a lot of support beyond a way to determine where you are and where you are going, and with a space capable planet backing up the new colony there'll be a basic GPS satellite constellation in place very soon, or even just a single stationary orbit satellite acting as a beacon. Once populations grow large enough further infrastructure will start to establish itself; either with sea travel, because small ships and the harbours to service them are cheap, or by rail for more landlocked areas.

If large scale traditional farming is an option you are likely to see massive, mostly automated and extensively mechanized farms with their own dedicated storage and transfer hubs for the preferred method of transportation, be it by ship or by rail, to move food to the cities. Population of those working those farms is likely too small to finance a service and manufacturing industry to support the farm locally, and with modern transportation not needed. It likely has a dedicated airstrip to service most of its transportation needs except for bulk cargo transfer. Outside the first places people started to settle large concentrations of population are unlikely; all food and other resources are easily moved to the cities, and that's where the money is and where the people are.


All of which is a long winded manner of saying that while planetary population densities and counts are probably going to be quite low, most of that population would, in my estimation, likely to concentrated on a very small portion of the planet, and very vulnerable to orbital bombardment. Be it directly or as collateral damage.
Title: Re: C# Aurora Changes Discussion
Post by: DEEPenergy on April 09, 2018, 05:51:54 PM
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. 

However, if you're going to go that route, I think it would be smart to look at the effects of radiation on population as well.   As it stands right now, SM adding 10,000 radiation to an Earth with 300,000,000 population is only able to reduce that population by about 7,000,000 over a 30 day period, while the amount of missile damage required to reach 10,000 radiation would be enough to kill everyone several times over through sheer population damage (1250 size-8 missiles, which is a massive amount of destruction, would only increase the radiation to 10000 yet kill over 1,000,000,000 civilians with the new rules).   The way I see it radiation should have a much more devastating effect on populations, able to very quickly push them into negative population growth and eventual extinction.   This also opens some avenues of meaningful choices if you're going to attack a population with missiles.   Should I go all out with bombardment, destroying all traces of the population and industry but pacifying it more immediately in the short term? Or destroy less of the installations and and be force to babysit the planet while you rely on radiation to destroy the population over a longer period of time (weeks?/months?)? Or come in with a massive high radiation bomb that does minimal damage to the installations on the surface and gradually kills the population, but turns the surface into an irradiated hellscape? 
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on April 09, 2018, 08:23:48 PM
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. 

This sounds good to me. Maybe just come up with a population density figure based on current population/maximum population, and use it as a multiplier for civilian casualties. Possibly with some lower number as a minimum, but I think it might be interesting if there were almost always a few survivors (huddled in caves, bomb shelters, or basements) from anything but the most apocalyptic of bombardments.

If radiation effects also got increased they might not stay that way for long, of course.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on April 10, 2018, 02:27:20 AM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on April 10, 2018, 03:25:47 AM
It's not so much about small populations actually. I guess what I am after mostly is some diminishing returns.

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?
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on April 10, 2018, 04:06:29 AM
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 ).
Title: Re: C# Aurora Changes Discussion
Post by: lennson on April 10, 2018, 01:51:47 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Jovus on April 10, 2018, 01:55:46 PM
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.

I like this idea, but higher, not lower. On an industrial scale, in order to rebuild a city you don't pick through and salvage things; you bring a fleet of bulldozers and clear it all away.

Which means we'd then need to think about how to make it so ruins weren't just ignored instead of being rebuilt, either. Maybe having ruins on the planet (of the bombed-out kind, rather than precursor kind) would increase unrest.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on April 10, 2018, 02:00:07 PM
Lower mineral cost, similar wealth cost.

Otherwise you just get punished for nuking a place into submission beyond the long term radiation and dust problems as well as the loss of taxes and industrial capacity.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on April 10, 2018, 04:43:21 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on April 10, 2018, 06:02:58 PM
I would actually be pretty happy if it was almost impossible to completely wipe out a population through direct bombardment. It would make sense to me to have a strict percentage system that meant you would inflict massive casualties initially, but towards the end you'd stop bombardment and let radiation and temperature or lack of infrastructure kill off the remaining population. Or else you'd be killing 5, 4, 3, 2, 1 people per nuke.
Title: Re: C# Aurora Changes Discussion
Post by: Bughunter on April 12, 2018, 07:28:32 AM
If the game went this route, maybe ground units with construction equipment could passively restore damaged buildings?

And even find some research points or similar if they belong to another less advanced race :)
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on April 12, 2018, 11:28:24 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on April 12, 2018, 12:08:23 PM
Destroyed facilities should not remain as ruins that can be rebuilt. That's not how it works. It is much faster, easier and cheaper to bulldoze the wreckage away, recycle some of it, and build fresh. That is how every bombed out, burned out, fought out city was reconstructed after WW2 - exceptions were only made for few historically important buildings like cathedrals and so on.

Also, ground combat does even in C# will not operate on a small enough level that ruins should change fortification value of ground units, since there is only one planetary terrain.
Title: Re: C# Aurora Changes Discussion
Post by: Kytuzian on April 12, 2018, 03:24:27 PM
If the ruins thing happens, couldn't it just be merged with the existing mechanics for ruins that you find on planets? You could then clear them with construction brigades (or whatever is replacing them, I forget what is/if this is happening), and have a chance to recover technology/installations. It could then work so that when you encounter ruins on other planets, instead of a generic tech level, the destroyed alien race has specific technologies rolled up for it (probably not too hard, if there's a list of technologies for every tier, you could simply choose a tier then pick randomly from it). This could also let you find ruins for alien races that aren't actually extinct, which I think would be cool.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on April 12, 2018, 04:14:05 PM
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.

This is part of the world mechanics; planets that are very close to their maximum population level become urban worlds, representing that the bulk of the fighting occurs in and around the cities rather than further away from habitation. Although not as good mountainous and jungle worlds for bonuses IIRC, it's still fairly substantial.
Title: Re: C# Aurora Changes Discussion
Post by: mtm84 on April 13, 2018, 02:52:56 AM
Personally I think there should be a distinction in planetary damage between normal missile warheads and enhanced radiation warheads.  Or change the direct damage done to be partially based on warhead strength and partially based on radiation damage.  So there could be a set amount of population killed per warhead strength, and then an additional percentage killed based on radiation strength.

I guess I always considered it unlikely that we would be using actual nukes in normal ship to ship combat vs exotic types of high explosive warheads.  Ticking the enhanced radiation box makes it clear that you are going for something more WMD vs. conventional.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on April 13, 2018, 04:50:51 AM
The game already does that.

A missile in the game has a nuclear warhead. It does not explode directly in contact with the target in space combat; it's a close proximity detonation that, due to the way the damage model works, might well be a Casaba howitzer style weapon projecting a jet of nuclear powered plasma at the target.

In a bombardment role the nuke does multiple things, it explodes on or near a target, doing blast damage, it stirs up a lot of dust and smoke, which affects how much sunlight the planet surface gets, and it creates a quantity of radioactive materials, which impact the planetary population's health. What you do when you tick the enhanced radiation warhead box is instruct your designers to prioritise the production of radioactive materials (and thus long term impact of the nuke) over the blast damage (and thus the short term impact). Nuclear bombs like this are called 'salted' nukes.

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.
Title: Re: C# Aurora Changes Discussion
Post by: mtm84 on April 13, 2018, 04:03:24 PM
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.

Respectfully disagree.  First, using handwavium, I believe there could be "conventional" explosives made with TN materials that would approach fission levels of energy density.  Second, I do not believe that radiation effects in space would have as much of an effect due to a combination of the inverse square law and space ships already being hardened against naturally occurring space radiation hazards.  In my opinion even a nuke would need to have direct contact with a ship to do damage.  And technically this is how its modeled in the game right now, though I suspect that's more for ease of programming. 

I'm probably in the minority on this topic.  My main point was that I feel there should be a bigger gap in how many people a radiation enhanced warhead kills vs a "normal" warhead on impact, beyond the normal planetary dust and radiation damage mechanics.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on April 13, 2018, 08:34:41 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on April 14, 2018, 05:52:31 AM
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.

This is assuming just a plain ol' nuclear bomb with no special design. Which to be fair is probably what is intended to be represented by the damage template, but it's certainly not the only way a nuclear device in space could work.
Title: Re: C# Aurora Changes Discussion
Post by: zmionash on April 15, 2018, 03:42:02 AM
Hello, where can I download this version of the game or is it in development? Has it solved the 1366x768 resolution problem?  Thanks  :)
Title: Re: C# Aurora Changes Discussion
Post by: tobijon on April 15, 2018, 03:55:01 AM
C# aurora has not been released yet
Title: Re: C# Aurora Changes Discussion
Post by: zmionash on April 15, 2018, 04:16:58 AM
thanks for the reply.  Do we know approximate dates and degree of readiness ?
Title: Re: C# Aurora Changes Discussion
Post by: tobijon on April 15, 2018, 04:21:24 AM
right now a lot of features have been implemented, and all of the changes to the last version have been recorded in the C# Aurora Changes List thread. This will also give you an idea of how far along it is. most of the basic features are there but the AI isnt and it will still take the rest of the year or so before release (though this is hard to tell).
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on April 15, 2018, 04:22:08 AM
"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.'
Title: Re: C# Aurora Changes Discussion
Post by: waresky on April 15, 2018, 07:41:16 AM
"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.'

1998..SA first.(?)
2004 Aurora 3.2?...
2020 #C Aurora 1.0

Ehehe Steve surprise us every time
Title: Re: C# Aurora Changes Discussion
Post by: Llamageddon on April 16, 2018, 01:07:27 PM
He should just change the name to Aurora 2020.  Sounds quite sci-fi too.  :D
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on April 17, 2018, 01:07:51 AM
Weapon failure at a fixed 2% has some interesting implications.
It's inconsequential on things like box launchers and large-calibre/low-tech beams.
Compactness becomes expensive in combat: half the weapons with twice the RoF will suffer twice the wear and tear.

Generally, cost-effectiveness for a given role becomes more important than overall capability; I see the biggest implication for point defence.
Long-ranged area defence features sophisticated weapons and low chances to hit, this may become much less viable.
Lower-tech final fire PD than available doesn't only save a few BP, it greatly conserves MSP in operation.

Generally, overengineered solutions become much more of a liability. Some restraint is encouraged rather than building the most sophisticated weapons available, with the obvoius implications on research priorities.

Some things (failure rate, weapon cost scaling with tech) may need looking at and testing, but on the whole I like the concept. It should make beam fights less one-sided.
Title: Re: C# Aurora Changes Discussion
Post by: Dr. Toboggan on April 25, 2018, 03:41:55 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on April 26, 2018, 08:02:49 AM
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?

You can have the same (or different) windows open for two different empires in SM Mode.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on August 01, 2018, 01:01:37 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on August 01, 2018, 03:18:22 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Britich on August 01, 2018, 04:50:26 AM
I too would like to know the time frame using averages to get a crew to 100%, also as combat takes place and crew is lost and replaced will the percentage go down?

Finally, will the ships in training move around like they do in VB6?
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on August 01, 2018, 07:37:06 AM
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.

My understanding is that this is actually how the US Navy does it (or at least did it during the cold war); that (non forward-based) ships would train in home waters then deploy overseas.  For example, ships assigned to 6th fleet would train in 2nd fleet's area of responsibility off the east coast, while in the Pacific ships would deploy on "WestPac" (Western Pacific) to 7th fleet after training in 3rd fleet's area.

My understanding of the cycle in those days was 1/3 of the time training up (in home waters), 1/3 of the time deployed, then 1/3 of the time in repair/refit then back to training.  It seems like they've moved things around in the last few years due to the shrinking size of the fleet and increased operational requirements - I read an article recently (in Proceedings, I think) that said that the USN doesn't have the budget to actually train when in home waters.  In terms of the new training rules, this would correspond to sitting in orbit around the base rather than checking the training box.

John
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on August 01, 2018, 11:56:15 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on August 01, 2018, 12:22:21 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on August 01, 2018, 03:01:16 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: boggo2300 on August 01, 2018, 04:48:32 PM
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.

I'd like to put out there that maybe that fleet training to 100% is actually still too fast...
Title: Re: C# Aurora Changes Discussion
Post by: Profugo Barbatus on August 01, 2018, 06:44:04 PM
Yea, I always took it as 100% training being the fleet and the ships are reacting perfectly in sync, they are at absolute peak performance, nothing is out of step at all. Below that, mistakes are occuring due to miscommunication and misunderstanding or simple lack of practice, which affect performance.

Frankly, only needing two years to get to what is practically an elite fleet is pretty impressive. But fair, considering casualties and replacement ships will quickly dilute that pool in prolonged conflicts.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on August 02, 2018, 09:47:32 AM
Does the training quality degrade over time, when a ship is not in active practice?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on August 02, 2018, 10:10:04 AM
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.

Title: Re: C# Aurora Changes Discussion
Post by: OAM47 on August 02, 2018, 10:36:23 AM
Speaking of officers and bonuses and stuff, I really like the changes so far.  Just one question/concern.  Has the number of starting officers/the rate officers are generated been increased to deal with the fact that there are now more positions (XO, science officer, etc) to assign them to? I'm feeling at the existing rate it might be too easy to run out of officers even with only a few ships and such.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on August 02, 2018, 02:51:04 PM
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.
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.

It also means that it's possible to use an otherwise barren system as "training grounds", ie ship is built on Earth, then flies off to a neighbouring system, joins the Training Admin there that's built on some god-forsaken rock, until deemed operationally fit. I can see myself using such methods with a multi-race Sol start to hide Fleet details and for RP purposes. "Captain, you are ordered to report at the Antares Fleet Training Command in six days!"

I was going to wail about that Planet X addition, since I personally think that the science behind it is too iffy but then I noticed it's an optional thing, so I won't :D More options is always better though. I guess it could be used for a nifty "Aliens in Sol" scenario, where a sentient race has developed on a moon of a Superjovian out there, and only TN tech allows them to interact with humanity.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on August 06, 2018, 05:09:25 PM
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 think this mechanic is fine and degrading it seems bit unnecessary and micro heavy. The biggest problem I have is that it removes the reaction time entirely. Given that we also have bonuses from crew grade and officers I think 100% training should only lower it by a certain amount. Still giving crew grade and officers an effect. Also I think that there should always be a slight delay to orders, zero is not a good level in my opinion.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on August 07, 2018, 01:18:28 AM
I tend to agree that non-zero reaction times are somewhat preferable.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on August 07, 2018, 10:20:49 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on August 07, 2018, 10:56:04 AM
For normal playing I agree it would be too much micro. However, I think degrading crew when mothballed should be a thing...
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on August 07, 2018, 12:57:08 PM

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.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on August 08, 2018, 02:00:18 AM

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.

Trying to change ranges in a beam fight where you have order delays is very painful. I have bad memories of getting too close to swarm queen once and getting a large chunk of my fleet trashed before being able to pull range. Delays in giving a fire order to actually firing can be similarly painful.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on August 08, 2018, 04:42:10 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: waresky on August 08, 2018, 05:35:26 AM
2009.zzz...2010....2011....2012....2013....2014....2015...2016....2017...2018...20xx...2120!! Aurora C# ALPHA Day.

:D
:P
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on August 08, 2018, 07:33:04 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on August 08, 2018, 11:41:35 AM
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

This I agree with... if there is an issue with order delay that should be fixed not the delay itself. There should never be a case where zero delay is a must to play the game.

In my opinion having some delay always being the case seem more interesting overall and also mean that crew grade and officers competence always will matter.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on August 08, 2018, 02:49:46 PM
Agreed.

But that would require that Aurora "remembers" the old order even after you remove or change it. Not sure if things are set-up in a way that would make it easy for Steve to implement such a feature.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on August 08, 2018, 03:04:57 PM
I think the main issue is the full stop between orders.  Staying at the same speed and heading until able to react to the next order would be a bit more believable, achieve more or less the same thing and hopefully be easier to implement.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on August 10, 2018, 01:23:21 AM
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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on August 10, 2018, 01:45:50 AM
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.
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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on August 10, 2018, 10:57:34 AM
If anything, you might only expect momentary confusion in that case if the next planned target was already destroyed.
Title: Re: C# Aurora Changes Discussion
Post by: the obelisk on August 10, 2018, 11:30:09 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on August 10, 2018, 02:41:13 PM
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.

I agree... the biggest problem is when your fleet train things like FAC or other patrol ships with very short maintenance cycles or deployment times. The best thing would be that ships in a training command gain no training as long as they are anchored at a maintenance facility.

It would be nice if I could train my low deployment ships without huge micromanagement.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on August 10, 2018, 03:58:55 PM
What happens to the maintenance of fighters and other parasites during training? The hardware surely has to be used for real, but continuously charging double maintenance with their ridiculously low deployment times is likely prohibitively expensive.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on August 10, 2018, 07:08:54 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on August 11, 2018, 04:46:44 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on August 12, 2018, 12:27:13 AM
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.

The ships moving around the system in some erratic pattern are also a nice touch to bring in the training aspect. And I agree that one should not have to micro fleet training. You should give the order once, and stop when you feel it is well enough. Overhauls/shore leave should be handled by the system itself.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on September 08, 2018, 08:09:58 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on September 08, 2018, 08:56:12 PM
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
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 09, 2018, 06:26:27 AM
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.

Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on September 09, 2018, 09:38:43 AM
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.

Yep.  Just wanted to throw it out there so you could think about 2nd order stuff.

John
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on September 10, 2018, 04:00:25 AM
Perhaps the AI should be a little less proactive in condemning the ships from a neutral power entering their system, unless it does something exploitative or spends too much time there, is a warship (based on their intelligence anyway) or whatever, maybe only if the ship has a transponder turned on will it be treated neutrally?
Certain actions should be detectable with sensors, geo and grav scans by passive sensors, unloading cargo and other stuff by active sensors, doing this in a claimed system would cause hostility, though you might get away with it if the claimant is out of range (the same can happen to you though). It should be possible to see what intelligence like this has been gathered on any particular ship, if not in the event log.
Also, maybe there should be a default order for creating system patrol vessels, which can hang around jump points or patrol between locations and will follow neutral vessels that have their transponder switched on, ping them with actives (if you want) while keeping at a specified range.
Oh. One last thing, even if ELINT isn't detectable, it would be pretty obvious that a ship hanging around not doing anything specifically is doing spying of some kind, though there's a problem with my proposed neutral allowance of vessels in your space, passive systems and even ELINT itself could just be crammed into every freighter you have passing through their space gathering useful intelligence.
I guess inspection boarding would be needed in this case, once again being something dependent on having the transponder switched on, which is a convenient way of declaring "this ship is civilian and I submit to all laws and customs while inside your space"
And therefore if a ship class is detected to be equipped with military systems, or maybe even carrying military systems, troops or whatever that would cause a diplomatic incident (the magnitude depending on how much stuff the ship is equipped with as well as your relations and general trustworthiness) and finally the mark that ship class as military and ban it from their systems.
Some races might be really lenient on offenses like this and let you get away with an incident every few years without serious damage to relations, whereas others might just close off their border to you completely.
There needs to be a little more flexability with neutrality rather than it just being a state between war and friendly, friendly just being neutral but with significantly more trust.
Title: Re: C# Aurora Changes Discussion
Post by: Father Tim on September 10, 2018, 08:12:14 AM
My empires' ships always fly around with their transponders on, unless we're actively at war.  It's just polite.  I strongly object to the 'transponder = civilian' interpretation, and to NPRs getting angry at me for my 16,000 ton warship that is squawking "I'm a 16,000 ton warship" actually turning out to be a 16,000 ton warship.
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on September 10, 2018, 09:42:53 AM
Well with the transponder on your 16,000 ton warship is already saying "i'm a 16,000 ton warship. I'm suggesting that a ship without it's transponder on should be treated like it's potentially a 16,000 ton warship, suspiciously :p
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 10, 2018, 05:30:24 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 10, 2018, 05:42:28 PM
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.

(http://www.pentarch.org/steve/Screenshots/hqdefault.jpg)
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on September 11, 2018, 06:05:51 AM
Are transponders a thing again in C#?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 11, 2018, 06:45:37 AM
Are transponders a thing again in C#?

Yes, C# has transponders.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on September 11, 2018, 10:37:17 AM
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... .
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 11, 2018, 11:13:32 AM
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... .

The same as VB6.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on September 15, 2018, 09:23:39 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: King-Salomon on September 15, 2018, 09:35:43 AM
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?

Had just the same question myself   ??? ???
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 15, 2018, 09:45:51 AM
Units can be moved very easily between formations in the same location, so you can build a logistics-dedicated formation and transfer supply vehicles from that formation into the formations that require them. For C# Aurora, there are no 'fixed' formations. You can combine formations, move units between them, detach units to form a new independent formation, etc.. You design formation templates for building purposes but they are flexible once built.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 15, 2018, 02:27:35 PM
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?

I'm already theorycrafting a little when it comes to how I'd integrate supply units. Infantry supply units are probably of limited utility outside of smallish drop formations to supply them while the rest of the army unloads, or when you are using large blob formations where the 12 size you lose to the light vehicle unit type is sufficiently a drawback when it means you can squeeze in a few more troops and thus guns.
Title: Re: C# Aurora Changes Discussion
Post by: DEEPenergy on September 15, 2018, 02:43:57 PM
I would also enjoy logistics modules on static units, as an abstracted way to represent a large cache of supplies, or supplies parachuted in by plane.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on September 15, 2018, 04:52:12 PM
Given how units work I think that's actually better represented by infantry. Unit size is chassis size + equipment size, and infantry is the only unit with a base size of 0. The only advantage static logistics would have would be slightly more hp, and since cost is based on size you can already have 2.2 1 hp infantry logistics for the same size and cost as a hypothetical 1 3 hp static logistics.

You can always just think of infantry logistics as a supply stash and a guy with a checklist, especially since it doesn't actually have a gun. A light vehicle logistics would therefor be the same stash with a truck to deliver the supplies with. In this case the idea of a buried bunker or otherwise protected supply depot would be handled by fortification value, including the difference between the maximum self fortification (3) and the maximum fortification (6) being the construction units building something like a buried bunker for the supplies.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 15, 2018, 06:55:28 PM
The issue is more with the mechanics of supply: Infantry supply can only supply inside the formation and not up or down the formation. A big Static supply unit would not be subject to that rule.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 15, 2018, 07:04:25 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 16, 2018, 05:29:43 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 16, 2018, 06:17:01 AM
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.

The key sentence is "However, if units with logistics modules are available, ground units can draw supply to both fight the current combat round and replenish supplies used in previous combat rounds." So supply is drawn each round if available. If there has previously been a break in supply, then after the current round is supplied, more supplies are drawn to replenish the inherent supply.

I'm not going to add a static module. The distinction between light vehicle and infantry is that the light vehicles can supply over distance (from superior units further back from the front line), while infantry can only supply locally. Static would be in a worse situation than infantry and cost more.

GSP costs are for the base value of the component. It isn't affected by racial strength modifiers.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on September 16, 2018, 08:57:22 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 16, 2018, 09:11:16 AM
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

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.
Title: Re: C# Aurora Changes Discussion
Post by: hyramgraff on September 16, 2018, 09:29:14 AM
Eventually, I decided that having consumable vehicles was a lot more straightforward ...

To me, it sounds like the technobabble explanation is that the supply trucks that carry the bullets have an edible chassis.  Instead of having to use a truck to ship the MREs they managed to make the truck out of the MREs.   ;) :D
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on September 16, 2018, 09:48:57 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 16, 2018, 11:20:49 AM
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.

Yes, that is a good way of looking at it. Although I do like the edible trucks idea :)
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on September 16, 2018, 12:30:50 PM
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 ::

John
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 16, 2018, 01:24:57 PM
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 ::

LOL, its been a while since the Commercial Freight Network :)
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 16, 2018, 04:00:31 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 16, 2018, 04:59:35 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 16, 2018, 05:24:19 PM
However, as those will be front-line units it also opens your supply units to direct attack. It is a trade-off.

A solid point.

Still, that only matters for frontline formations. If the backline is still a thing this is absolutely something you can do with Bombardment units. If they're getting shot at something has gone drastically wrong after all.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on September 16, 2018, 11:08:59 PM
I'm personally fine with just assuming used up trucks get picked up as the loaded ones are being dropped off, personally.  From this games perspective the real meat of logistics will be getting things onto the planet to begin with, so I don't hugely mind it being kindof abstracted.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on September 17, 2018, 12:57:25 AM
Alternately, think of the 20% overhead as fuel and spare parts for the trucks delivering the supplies from the back line, as opposed to a more efficient but more vulnerable setup where the supply depots are located up front with the troops.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on September 17, 2018, 01:53:30 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 17, 2018, 04:22:45 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on September 17, 2018, 08:05:55 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 17, 2018, 09:25:43 AM
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

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 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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 17, 2018, 12:07:44 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 17, 2018, 12:54:21 PM
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.

Front line size is based on total size of the units deployed in front line formations.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on September 17, 2018, 05:56:16 PM
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.

Makes sense - realized it on the way to work after posting.

John
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on September 17, 2018, 06:06:30 PM
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
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 17, 2018, 06:13:21 PM
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

I hadn't considered that, but it does make sense.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 18, 2018, 04:25:08 AM
I note that Light Bombardment units are not able to provide support from any position other than the Frontline.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Titanian on September 18, 2018, 05:40:06 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on September 18, 2018, 06:25:03 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on September 18, 2018, 06:27:35 AM
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.

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.

John
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on September 18, 2018, 10:17:02 AM
I note that Light Bombardment units are not able to provide support from any position other than the Frontline.

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'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.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on September 18, 2018, 10:46:53 AM
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.

John
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
Title: Re: C# Aurora Changes Discussion
Post by: hubgbf on September 18, 2018, 11:21:11 AM
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 ?

Or you build into a central reserve, and you can ask aurora to create or complete a template from this central pool ?
If you add a few predesigned templates, and series like missiles, you can spare the life of most of the poor souls who did not want to use so much detail.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 18, 2018, 12:15:54 PM
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
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 18, 2018, 12:22:39 PM
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

Here is a comparison between an infantry mortar team and a vehicle-mounted autocannon using the same tech level. An autocannon requires a light vehicle, so it is almost four times more expensive than the light bombardment.

Mortar Team
Transport Size (tons)  20     Cost  0.4     Armour  10     Hit Points  10
Annual Maintenance Cost  0.05     Resupply Cost  3
Light Bombardment:      Shots 3      Penetration 10      Damage 10

Autocannon-equipped Vehicle
Transport Size (tons)  36     Cost  1.44     Armour  20     Hit Points  30
Annual Maintenance Cost  0.18     Resupply Cost  7.5
Light Autocannon:      Shots 3      Penetration 12      Damage 20
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 18, 2018, 12:25:07 PM
I note that Light Bombardment units are not able to provide support from any position other than the Frontline.

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'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.

Yes, they are supposed to be short-range mortars.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 18, 2018, 12:40:58 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 18, 2018, 12:46:05 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on September 18, 2018, 01:05:46 PM
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.
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 18, 2018, 01:09:45 PM
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.

That is a good point re crew served. I have changed the code so that light bombardment units in a Support field position can provide supporting fire against hostile front line formations. However, unlike medium bombardment, they cannot fire at enemy formations in support or rear echelon positions. So they have the advantage of indirect fire, but cannot perform counter-battery fire.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 18, 2018, 02:00:43 PM
Hmmm.

I'd need to check the numbers, but I think that in that case choosing between Light Vehicle Light Bombardment and Infantry Light Bombardment is a question of if you want your LB units to have some armour against counter battery fire or if you will accept the greater losses for something like 30% more guns on target. Until you get armoured and power armoured infantry, in which case you want them. They're IIRC the same size as Infantry but as well armoured as Light Vehicles, so at that point? Unless they're ruinously more expensive it's worth the trade off.

Heavy Bombardment sees something similar between Heavy Vehicles and Static. Static units are notably smaller per component and can massively stack their Fortification, but Heavy Vehicles just have better armour. I expect this will come down to whether or not the local terrain supports fortification bonuses or not.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 18, 2018, 02:12:08 PM
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 should probably make breakthrough above a certain percentage of the opposing formation, with different percentages required for vehicles and infantry base types.

Transports would be complicated. Perhaps something for a future update.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on September 18, 2018, 05:31:28 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on September 19, 2018, 12:24:47 AM
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.

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.
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.
I would very much like to see mixed formations, Infantry supported Tank formations on the attack, and not just a split Tanks are offense, static/infantry is defense.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 19, 2018, 05:27:06 AM
Tanks can fight without infantry support.

If they're fighting on a large, flat plain.

Anywhere else, or anywhere where infantry can fire a few shots of AT weapons and then run and fade?

Tanks need infantry support, because otherwise they're going to get torn apart.
Title: Re: C# Aurora Changes Discussion
Post by: hubgbf on September 20, 2018, 03:02:31 AM
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

Thanks Steve for your answer.

If I understand the complete mecanism, there will be template for low level formation, i.e. equivalent to current battalion, but we will still have to attach them to form brigades and division, build them separately, then combine them, and if a battalion is lost, we have to build another one and assign it to its brigade.

Did I understand well?

Having a template system on the division level will help for those midly interested in such low level management.
Your future AAR will be fascinating.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on September 22, 2018, 03:00:08 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on September 22, 2018, 03:13:15 PM
Does your own supporting artillery/aircraft also require forward directors?
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on September 22, 2018, 04:36:16 PM
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?
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 22, 2018, 05:44:22 PM
Also, you have AA ground unit components.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on September 22, 2018, 09:33:27 PM
I can already see myself building Assault Carriers just for planetary invasions. A flying brick with heavy shields so it can take STO fire from the planet while launching supporting fighters.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 23, 2018, 06:43:44 AM
Does your own supporting artillery/aircraft also require forward directors?

Fighters and orbital bombardment support (which I cover in another rules post), will both require FFD. 1 per orbital bombardment ship and 1 for every 6 ground support fighters. I am leaning against having FFD for artillery support, as that might be too much micromanagement.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 23, 2018, 06:49:06 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on September 23, 2018, 04:17:34 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 23, 2018, 04:29:24 PM
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'll post the rules separately. There are Provide Ground Support and Provide Ground CAP movement orders. The latter is used for fighters intended to shoot down other fighters (effectively a dogfight over the battlefield). These fighters do not attack ground units but can attack hostile fighters and can be attacked by heavy AA ground units.

Yes, I will probably add the same rule for independent AA as the one for independent artillery.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on September 23, 2018, 04:29:38 PM
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.

That sound like a pretty good solution... this also mean you can launch a surprise attack with fighter from ground to space even during ground invasions. With STO and versatility of fighter crafts we might see some cool new designs of ships in general, especially anti-fighter type weapons on the ships.

Assault carriers will certainly become a much more interesting and IMPORTANT ship type in C#.... that I like very much. Also... you now might need to think more about beam combat in general for your ships if you want to invade enemy planets, as a general concept I mean.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 23, 2018, 05:18:15 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on September 23, 2018, 06:05:12 PM
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.

But that also mean you are out of beam bombardment range of the planet yourself which I think will be a good force multiplier for ground combat. Having your drop ships a long way from the enemy planet also means they will have to face allot more ground fire before they touch ground, not to mention enemy fighters trying to intercept them. Ground fighters can also make high atmosphere attacks and launch missile attack at a fleet in stand off mode, so they might not be safe there and closer to the planet they can target such fighters to whittle them down.

A seriously defended world might need a tough fleet able to get into bombardment range and close enough that the forces actually can land unharmed for the most part.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 23, 2018, 06:55:53 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on September 24, 2018, 03:42:53 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 24, 2018, 04:20:51 AM
Planets kind of have the same problem as Japanese occupied islands had in WW2. When you can no longer command the seas or space, your enemy can concentrate far more firepower than you can. The Japanese, late in the war, saw at island after island that their island based aircraft were swatted from the skies by US carrier aircraft flying in considerably larger numbers. Although it won't necessarily be cheap, CIWS should still need maintenance and/or GSP for munitions, and they can't catch every missile. You can swamp them as a result, and all you need is enough of them to ruin the industrial base of the planet.

After that, the planet is effectively neutralized as a threat, as there's no way it can produce new stuff. If you plug up the jump points all you've got is an annoyance that can't do much. And if you've got a bunch of large, heavily shielded and armoured flying bricks with a couple of decent beam weapons you can plink away at the planet at a cost of MSP and fuel while the defender has to choose to risk their STO guns or to let them keep shooting.


There's simply an opportunity cost that renders ships a superior investment when it comes to defenses, so planetary defenses are unlikely to be very heavy compared to a peer's navy. The fortifications aren't there to render a planet unassailable, that's a pipe dream, but to render them too much of a resource sink to bother while the navy's still a factor in the system's defense.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on September 24, 2018, 04:52:04 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: DocSpit on September 24, 2018, 06:33:54 PM
Hmm, depending on how ground based beam emplacements work, I have to wonder if we won't see a generation of fast assault landing craft designed to effectively outmaneuver those emplacements by moving faster than they're tracking speed will allow. 

Get in fast, drop pods, get gone, "have fun storming the castle!"
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 24, 2018, 07:07:21 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: DocSpit on September 24, 2018, 07:42:22 PM
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. 
Title: Re: C# Aurora Changes Discussion
Post by: Kytuzian on September 24, 2018, 07:44:27 PM
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.

Espionage teams have been removed from the game. Not sure how to link to the exact post but you can just search the last page of the change list thread, it's in the post about the new ELINT system.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on September 25, 2018, 01:36:16 AM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Iranon on September 25, 2018, 01:50:37 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on September 25, 2018, 03:11:33 AM
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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 25, 2018, 04:07:08 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on September 25, 2018, 04:11:15 AM
In my opinion it will be about a good mix of speed, ECM and armour for bringing troops to the ground.

If you build your Assault carriers properly they would enter into the combat zone and drop off the invading drop ship roughly half way and retreat back out to safety. Your drops ships would use high enough speed to avoid most slow firing heavy weapons and good enough armour to withstand the shooting of the smaller faster weapons. You will likely suffer some losses but that should be expected against a well fortified world.

I hope we will see things like missile silos/bases that can be used from the ground against ships in space as well as ground to space cannons. But there should be some advantages to bases in space as to having them on the ground or you will never build military space stations around populated planets.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on September 25, 2018, 04:17:42 AM
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.

If and when (I believe he will at some point) Steve add a transport capability to infantry such fighter types can stay in support as a mechanised tool for manoeuvring infantry and pretty much everything on the planet. I mean the strategic and even tactical possibilities on the planet should be quite obvious to everyone. These ships should not just be about moving troops to the ground, they should be used in combat as well on the planet as support elements.

The same with planet bound vehicles for moving slower units such as infantry and static forces around.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on September 25, 2018, 05:38:14 AM
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.

A quick calculation: Tracking speed usually corresponds to 20% of space dedicated to engine at x1 speed modifier. So 40% engine at 2.5 modifier gives you 5x tracking speed, leaving 20% hit chance. With ECM 2 you are down to 0% , and STO don't have ECCM to counter.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on September 25, 2018, 07:40:27 AM
I think the new system looks very good on paper. Just needs testing to make sure of the details.

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.
Title: Re: C# Aurora Changes Discussion
Post by: TCD on September 25, 2018, 08:06:30 AM
I think the new system looks very good on paper. Just needs testing to make sure of the details.

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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on September 25, 2018, 02:06:02 PM
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.
And it should only be possible at the beginning of a fight. Not multiple times when there are already boots on the ground.

These new ground options are really nice. Will give supply runs to a sieged planet quite an importance. Although I was wondering, since there are no more PDCs will it still be possible to build bunkers? Also for minerals, fuel, etc?
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on September 25, 2018, 03:52:54 PM
You can't steal anything from a colony until it has surrendered to you. So fuel and minerals are safe. While you can't build bunkers, your defending units will fortify themselves and the planetary fortification bonus will help there too. Depending on the planet. Your construction units can even improve that fortification level.

it will be easier to consolidate defense on a particular strategic system
Yes, 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.

Oh and your point about weighing the risks of leaving your supply route vulnerable as you bypass a fortress world gives me the idea of creating hidden fighter bases on asteroids / dwarf planets that are out of the direct lines between JPs. Put few tracking stations there, few maintenance facilities and a bunch of fighters. Rotate squadrons between the hideout and the populated planet to combat deployment time overrun if necessary. If the enemy attacks the planet, hit them from behind. If the enemy bypasses the fortress, raid their ammo/supply/fuel ships.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on September 25, 2018, 04:55:01 PM
It should be quite easy to find good planets or rocks that give you good fortification bonuses so you can turn them into hard to conquer military bases. These can hold a few fighter squadrons to harass enemy forces... invading them will take time and energy and will allow you time to react and perhaps even come to the bases rescue in time.

There are many interesting new twist and turns with the new systems in C# Aurora... it will become really interesting what we can do and how it will all turn out.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on September 25, 2018, 06:27:36 PM
There are such things like entertainment modules. Sure, they're 100 000 tons IIRC, but that's a shore leave facility you can plop down anywhere in C# Aurora. Combine it with civilian magazines, some maintenance modules, the Ordnance and Fuel Hubs and some Shuttle Bays and you've got an approximately 500 000 ton minimum civilian station that you can anchor in deep space for optimal back line raiding. Combine it with a stealthy high efficiency carrier to move your high thermal and electronic signature fighters around and finding that station will be a massive bother if the system's large enough.
Title: Re: C# Aurora Changes Discussion
Post by: space dwarf on September 27, 2018, 03:59:19 PM
With regards to the latest change - I find it strange that there's no factor of area denial with ground-based anti-air units.  I'd have imagined that just the inclusion of them actively firing on fighters in the battlefield would somewhat reduce the effectiveness of their ground bombardment due to occasional evasion at the least.
Title: Re: C# Aurora Changes Discussion
Post by: 83athom on September 27, 2018, 08:01:25 PM
On the ELINT addition... I'm already piecing together a stealth prowler with a large sensor to spy on unsuspecting populations.  ;D
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 06, 2018, 12:55:50 PM
I've been thinking about the ground combat some more and decided to make a couple of changes. The first is that during front-line combat, rather than each element attacking a hostile element, it is now each individual unit in a formation attacking a random hostile unit within the hostile formation (still based on relative size). This is for a couple of reasons. I don't want to discourage small elements within a formation (such as infantry MG, AA or AT) and as things stand small elements would be eliminated when a large element attacked. On the other hand, i don't want huge overkill for the attacker in that situation. Also, it seems more reasonable that a formation is based on combined arms and that tanks and infantry would attack together, not separately.

The second change is for breakthroughs. I've added a more complex version because I wanted it to be more meaningful and potentially more likely, plus provide a reason to value high morale, vehicle-focused formations on front-line attack.

The relevant new section of the rules is below. I've also updated the original post: http://aurora2.pentarch.org/index.php?topic=8495.msg109786#msg109786

****************************************************************************

Once a front line formation (or a light bombardment element in the Support position) has been matched against a hostile formation, each friendly individual unit (a soldier or vehicle) in that formation engages a random element in the hostile formation, with the randomisation based on the relative size of the hostile formation elements. The targeting on an individual unit level represents that the different elements in a front line formation will generally be attacking in conjunction (infantry supporting tanks, etc.).

Once all front line attacks have been concluded, each unit in each element providing supporting bombardment will engage either the hostile formation being targeted by the friendly formation they are supporting, or one of the hostile formation's own supporting elements (counter-battery fire). If the hostile formation is targeted, each unit in the supporting artillery element engages a random element in the hostile formation, with the randomisation based on the relative size of the hostile formation elements (the same as front-line vs front-line). If a hostile supporting element is targeted, all fire is directed against that element. This represents the difference between providing supporting fire in a combined arms front-line battle and targeting specific hostile artillery for counter-battery fire. The decision to target the hostile front-line formation vs hostile support elements is based on the relative sizes.

Supporting medium artillery will choose between hostile forces in Front-Line or Support field positions (and will ignore any elements in Rear Echelon field position for purposes of relative size), while heavy artillery can select targets in any field position. In other words, if the enemy has supporting heavy artillery in a rear echelon position, you will only be able to target those elements with your own heavy artillery (or ground support fighters, or orbital bombardment support).

Once all the initial combat is complete, there is a chance for a breakthrough. Each defending formation is checked according to the following procedure:
The breakthrough rules mean that defending formations that suffer casualties may allow attacking formations to penetrate their lines and conduct a second attack. This is more likely under the following circumstances: A single defending formation is attacked by multiple attacking formations, the defender suffers a high casualty percentage in a single ground combat round (potentially because the formation is small in size), the defender suffers disproportionate casualties to elements with larger unit classes, the defender is low morale, the attacker is primarily vehicle-based, the attacker is on front-line attack, the attacker is high morale.

****************************************************************************
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on October 06, 2018, 04:51:11 PM
Security troops for artillery is pretty much useless now, especially for heavy artillery.

Also, you want armour for your artillery that's better than their damage rating, to prevent getting counter bombarded into oblivion.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on October 06, 2018, 06:02:56 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Barkhorn on October 07, 2018, 01:29:08 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 07, 2018, 03:37:29 PM
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.

That was a mistake by me in the rules post due to copy-paste syndrome. I've fixed it.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 07, 2018, 03:54:35 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Adseria on October 08, 2018, 07:11:10 AM
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.

Maybe this could be affected my the new planet sizes. A larger planet would allow more troops to fight side-by-side.

Oh, and maybe terrain, too; if there's a lot of water or mountains, it would make it more difficult for large bodies of troops to move around.
Title: Re: C# Aurora Changes Discussion
Post by: space dwarf on October 08, 2018, 12:05:21 PM
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
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 08, 2018, 01:32:21 PM
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

No, not negative bonus. In the case above, the bonuses would be reduced by 90%.

I didn't want to penalise players for not (micro) managing at this level to the extent that no commander would be preferable.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on October 08, 2018, 06:21:15 PM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on October 09, 2018, 01:41:52 AM
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?

Isn't this more a fact about the fighters finding the AA before the fighters get into effective fire range of the AA so they can attack them safely. The lower chance for finding and hitting them is the fighters scouting force being extra careful so they don't end up in the effective zone of too much AA. It certainly is allot harder to shoot something that shoots back, especially if it is really dangerous. Some AA might also be quite mobile, especially in Aurora type military, which make matters even harder.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on October 09, 2018, 04:24:37 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on October 09, 2018, 04:32:30 AM
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.

Sure... that is technical tactical operations and it goes both ways... it is a hide and seek games, sensors and ECM/ECCM systems goes both ways. The mechanics are suppose to be an abstraction of that. In reality it is rather dangerous to use air power against a decently similar equipped opponent air defences. The mechanic is sort of abstracting those problems.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on October 09, 2018, 05:29:35 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on October 09, 2018, 05:52:32 AM
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.

In Aurora anti-gravity hover craft and transport capacity is probably quite advanced so I see no reason why AA are using such transport to displace AA positions quite rapidly. We also need to understand that real life is never that simple. There are probably many ways that ground units can cloak themselves or even their true position by technological means. There are no reason to think that cloaking technologies are very potent and easy to use to mask energy signatures from the ground or to distort enemy sensors from the exact position a given fire is coming from.

All of this is science fiction and even in real life it is not so simple. Air-defences use multiple layers of defence, some are known and can repel fake attacks while more serious threats can be engaged using more mobile or hidden sources when the real attack comes. There are generally not a huge problem of letting an enemy know some of the AA positions as long as you can keep some of the hidden and mobile. Air-defences is also generally used with an air-force of your own which make the AA suppression that much more complicated.

This is all very hypothetical, but in real life air defences is a serious threat to air-power unless you have overwhelming air-power forces. In Aurora with this mechanic you will quite easily suppress enemy AA if you have a significant advantage in air-power, we don't need to make it easier.
Title: Re: C# Aurora Changes Discussion
Post by: Adseria on October 09, 2018, 07:27:07 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on October 09, 2018, 07:33:57 AM
The air roles are looking very interesting but this now also has me hankering for mission specific combat pods. Ie a HARM type for the AA suppression, Ground attack and air to air as well as a general purpose pod. GP would be as is then the specific pods would give good bonuses to specific role but significant penalties to being caught out of role. Given travel and reload times on carriers I'd hope this gave some interesting options in how you loaded your fighters and how you might go through different phases of use in any battle.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on October 09, 2018, 07:35:14 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 09, 2018, 09:06:01 AM
I have to agree with the concerns about potential of massed fighters doing Flak suppression and then S&D might be too powerful.

For example let's say Ground AA ends up balanced such that at same tech level it can get a 3:1 ratio kill:loss ratio vs fighters. Then that means that any attacking power that can accumulate 6 times worth of industry more fighters ( 50% hit chance when doing Flak Suppression ) than the defender can accumulate AA can wipe out the defenders more or less completely before any attacking ground forces need to set foot on the planet.

This is unless the changes with accidents and supply somehow make it prohibitively expensive to operate such large amounts of fighters vs the ground forces.


The Flak Suppression mission also seems to assume the defenders AA always will want to engage the fighters. That might not be the case if the AA is vastly inferior or outnumbered and just want to stay hidden for a later invasion or in case they are needed to defend other ground forces.
Title: Re: C# Aurora Changes Discussion
Post by: Adseria on October 09, 2018, 10:09:12 AM
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.

I didn't say they couldn't be moved. But can they be moved faster than the speed of light? Because I'm betting that's how fast a laser blast moves. And I don't imagine the difference between space and atmosphere would reduce the effectiveness of sensors much. After all, ships have no trouble detecting populations from millions of km away. Detecting a missile or laser blast from low orbit shouldn't be that different.

And sure, you could cloak the unit firing the AA weapon. But you can't cloak starship weapons, so why would you be able to cloak surface-based weapons?

And tell me, how many spaceships do the enemies of the US and these "weaker countries" have?
Title: Re: C# Aurora Changes Discussion
Post by: Titanian on October 09, 2018, 11:20:45 AM
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.
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!
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on October 09, 2018, 11:51:05 AM
But that isn't really a concern because NPRs will not do that and if a human player wants to exploit and game the system, they are free to do so in a single-player game. After all, if you're going to the trouble of creating thousand single-soldier formations just to protect your AA from NPR fighters, you might as well just use SM to manipulate the battle in the first place - it's much faster and far less work.

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.

Just as an example, Serbia managed to preserve the vast majority of its ground forces, as well as keep her air defence network working, throughout the 1999 Kosovo war. Despite the fact that they were facing the largest and most technologically advanced air power in the world. One reason was that NATO really wanted to avoid casualties, but the Serbs also did many things right. So while sensors get immensely better in Aurora-future, there is no reason to assume that the defensive measures and tricks would remain stagnant.

Basically, I want to avoid a situation where one player can send a bunch of fighters against a planet, divide them on generic ground attack and SEAD missions and them leave them for six months.
Title: Re: C# Aurora Changes Discussion
Post by: Adseria on October 09, 2018, 11:54:56 AM
Fair enough.

I mean, I still disagree. But I see that I'm not going to convince anyone.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on October 09, 2018, 12:10:12 PM
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.
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 09, 2018, 12:45:01 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: space dwarf on October 09, 2018, 02:12:16 PM
Quote from: Steve Walmsley link=topic=8497. msg110260#msg110260 date=1539107101
Quote from: Person012345 link=topic=8497. msg110257#msg110257 date=1539105012
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.

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"?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 09, 2018, 03:28:43 PM
Quote from: Steve Walmsley link=topic=8497. msg110260#msg110260 date=1539107101
Quote from: Person012345 link=topic=8497. msg110257#msg110257 date=1539105012
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: Profugo Barbatus on October 10, 2018, 10:46:44 PM
Steve, the ground combat bombardment rules state each weapon fires once per combat round. Do weapons that fire multiple times in a single shot get multiple shots in ground combat?

It also specifies that accuracy is modified by crew grade and the officers, but does the weapon innate accuracy factor in at all? Otherwise, reduced size, massive rate of fire gauss cannons are going to act as orbital machine guns, slaughtering everything.

either way, the 3 hour window adds a lot of potential for massive reduced size weapon loadouts. In a 3 hour window, you can reload pretty much anything. I could see combat supply ships packing 80cm reduced rate lasers to obliterate enemy forces while dropping supplies.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on October 11, 2018, 03:47:41 AM
Or... if balanced properly the reduced sized weapons are suppose to be the most efficient bombardment weapons so there now is a choice with using them versus normal sized weapons for space combat.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on October 11, 2018, 05:41:59 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on October 11, 2018, 06:48:45 AM
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.

For the same reason you assign fire-directors for artillery batteries etc... ships are likely assigned to support certain formation during missions and stuff. It has to do with fire-priorities and how you govern the hierarchy of fire-direction. The more channels you need to go through the longer it will take. It usually is easier to assign batteries to certain prioritized missions and sometimes they will be diverted for opportunity fire elsewhere but such fire usually take much longer to coordinate.

At some level someone will decide what is important and not important to support.

We should also not assume that beam weapons are effective at all angles of attack either, especially if there is an atmosphere... but these are abstracted things.

Perfect coordination from one place is probably an utopia very hard to achieve in reality where there are many strong willed people contending for priority and differing opinions.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on October 11, 2018, 06:58:03 AM
Quote from: Steve Walmsley link=topic=8497. msg110260#msg110260 date=1539107101
Quote from: Person012345 link=topic=8497. msg110257#msg110257 date=1539105012
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.

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.

Would it be possible to have both CAP and Intercept missions for fighters?

Intercept missions would try to target fighters on ground support missions while CAP would randomly target any fighter or even slightly favor fighters on intercept missions.

It would create some interesting dynamics as in real life.
Title: Re: C# Aurora Changes Discussion
Post by: davidb86 on October 11, 2018, 10:31:11 AM
Quote
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).


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

Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 11, 2018, 11:43:56 AM
Quote
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).


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

Yes - text mistake on my part. Above is how the code is actually written.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on October 11, 2018, 01:59:47 PM
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.

It being possible to design purpose built bombardment ships for added efficiency (reduced fire rate, loads of small guns, etc) similarly doesn't bother me. If you go to the trouble it should pay off a bit.
Title: Re: C# Aurora Changes Discussion
Post by: Conscript Gary on October 11, 2018, 03:17:53 PM
So, let's sum up to see if I'm following this right as far as the interaction between ground forces, fighters, and ships goes.


And


And just to round out the trio


That's the current state of it, yeah? As well, ground combat only happens once every three hours, and ships with the bombardment support can only participate if they didn't perform naval fire in the preceding increment- does that mean the entire 3-hour combat round? Either way, the jump between ships firing once every three hours with ground direction or 2,160 times (assuming adequate supply for breakdown) during indiscriminate bombardment is rather large.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on October 11, 2018, 04:16:57 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on October 11, 2018, 04:20:34 PM
IIRC, fighting STO units is like fighting ships, and on the ship timescale rather than the ground combat timescale.

With the ground bombardment mechanics the way they are, that... might not work out well.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 11, 2018, 04:54:17 PM
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 haven't finished with the ground combat rules posts yet. I will try to cover all of the above.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on October 11, 2018, 11:25:09 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 12, 2018, 03:56:50 AM
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 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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 12, 2018, 04:03:42 AM
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.

It's not that the code is running off without me :). Where we are now with the ground combat is pretty much where I wanted to be when I started on this on this area a year ago. There is still some coding to do but the framework is firmly in place. It is has taken a while to build the complexity I wanted and to integrate that with an already complex game, although I have added a lot of other areas in the last year and had several months without much free time, so hasn't just been ground combat.

I accept ground combat has probably added at least six months to development time. However, I don't have a deadline to work to, or any time pressure beyond my own great desire to play the game (I haven't played Aurora in the last 2.5 years) and I believe it is worth spending the time to get this right. Besides, my sales numbers will be unaffected by any delay :). 

I don't want to place arbitrary boundaries on myself regarding what the game should or should not cover. Personally I am going to have great fun designing and employing the various ground forces that Aurora will now support, plus naval forces will be faced with entirely new missions added to those that exist in VB6 Aurora.

Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on October 12, 2018, 04:09:28 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 12, 2018, 04:19:39 AM
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.

Yeah that's what I meant. I don't know exactly the numbers of targets inside a "formation" will be here, since it seems the system is quite flexible and open, but logic and reason states that at some point a large Battleship should be able to overkill anything if it has too many guns.

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 don't agree at all that it makes sense to be able to target fast moving fighters if there are administrative or other delays involved which allow orbital support to fire only once every 3 or 6 hours ( not sure which it was ).
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on October 12, 2018, 05:36:51 AM
So, Steve, the next update after C# will then include planetary naval forces?  ;D
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 12, 2018, 05:38:52 AM
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 :)
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 12, 2018, 06:10:05 AM
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*
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 12, 2018, 06:38:01 AM
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*

:)
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on October 12, 2018, 12:45:25 PM
I like that NPRs are now using fuel, even if they can cheat if necessary. And I don't fault you Steve for leaving in that "loophole", coding AI to worry about deployment ranges is a formidable challenge - Paradox for the longest time allowed AI opponents ships to operate with unlimited ranges because they couldn't get the AI to play smart with the same constraints that a player had.
Title: Re: C# Aurora Changes Discussion
Post by: Peroox on October 12, 2018, 01:59:55 PM
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 ?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 12, 2018, 02:14:29 PM
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 ?

They will be slower in the sense that if there is no fuel source available, they will remain stationary. When moving toward fuel though they will move at full speed. 

I did consider having them move at 20% but decided it was probably better for game play to have them at full speed. You can still infer from their movements if they are low on fuel, but you don't know if they are completely empty.
Title: Re: C# Aurora Changes Discussion
Post by: Shuul on October 13, 2018, 04:25:12 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on October 13, 2018, 09:11:21 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on October 13, 2018, 09:32:44 AM
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.

If Steve could write human-level AI I would agree.  I don't think that will happen in the near future, though, so I think that 100% speed is appropriate.  To put it a different way, I think that if the speed were cut when out of fuel, it increases the possibility of the (human) player to game the (stupid) AI.  For example, if there's a hole in the AI's "uh-oh, I'm about to run out of fuel" logic, then the player could get the AI to chase him until dry, then have a significant speed advantage over the AI ships.  What SHOULD happen in all cases is the "uh-oh-need to get fuel" logic should result in the AI ships breaking off before (not after) bingo status and never need to invoke the "oops" case.

STEVE - if you don't already, you might want to have a special mode (maybe invoked by designer mode password, but not entering designer mode) where Aurora will log events for you when the AI is doing something stupid that it shouldn't.  In this case, it would warn you when an NPR fleet ran dry.  That way you could tell how serious a problem it is while you're actually playing (rather than testing) your game :)

John
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 13, 2018, 09:57:52 AM
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.

Direct fire on STOs will use normal planetary bombardment rules for environmental damage, which is much higher if missiles are used. Orbital bombardment support will be factored into collateral damage from ground combat, which will overly penalise larger weapons. I need to work out the exact balance.

Multi-weapon turrets or multi-shot weapons (like railguns) will have those multiple shots for orbital bombardment support.
Title: Re: C# Aurora Changes Discussion
Post by: sloanjh on October 13, 2018, 11:54:38 AM
I like that fortification decreases detection signature.

John
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on October 13, 2018, 04:28:35 PM
I like that fortification decreases detection signature.

John

Same here. It's also another advantage to using construction units to boost your fortification level way up... luring your attacker into an ambush with superior ground units :)
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on October 13, 2018, 10:02:28 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Person012345 on October 14, 2018, 02:38:02 AM
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.

What? Why does it put an upper limit? This only matters if you care that the enemy knows you occupy a planet. I can't imagine you'll have gigantic armies stationed on random strategically unimportant planets that the enemy isn't going to be investigating anyway. The only time it seems like it might be relevant is hidden strike bases, but I never envisioned those as being immensely heavily fortified bastions personally.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on October 14, 2018, 04:22:26 AM
Because a heavily garrisoned desert world will have a much greater signature than the same garrison on a world with a higher dominant terrain multiplier. Your best defense against orbital assault is the enemy being uncertain about how much you've got there in the way of forces, and it being difficult to dislodge you. With this, desert worlds and other worlds with low dominant terrain modifiers and fortification bonuses, ground units are far more likely to be spotted, far more likely to return a large signature and just as important, far more likely to get hit in any subsequent bombardment, be it fire directed or general.


It makes it harder for a defender not to get outmatched in the ground combat, because the attacker holds greater information to the point it likely has an information advantage, while it already has the orbital advantage and a concentration of force advantage potential because he can move more freely than the defender. After all, if the defenders held that advantage they would not be defending this world and be cut off from reinforcements.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on October 14, 2018, 05:27:23 AM
I don't think ground force signature changes how likely you are to detect them. They're size 1, so a resolution 1 sensor will still detect them at a decent range, whether there's one or a million.

What the fortification bonus does is make it harder to determine how many ground forces are on the planet; 6000 troops with a fortification of 6 look the same to attackers as 1000 troops with a fortification level of 1. Though thinking about it doesn't this mean troops with no fortification show up as having infinite strength? Might be best to keep the formula but treat it as Fortification level + 1.

That said, yes, the terrain rules mean it is much easier to defend a mountainous planet than a desert, because the fortification bonus can be huge. It doesn't really change the intel the attacker gets about you (if the planet has a fortification multiplier of 2, they can just multiply the signature they get by 2 and get the same number they would on a planet with no fortification multiplier).

In fact, I'd suggest Steve eliminate the dominant terrain fortification multiplier. The attacker knows what that multiplier is so they can just compensate for that when coming up with their intelligence analysis.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 14, 2018, 05:41:42 AM
Minimum fortification strength is 1, which means you are not fortified.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 14, 2018, 06:15:14 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on October 14, 2018, 06:31:09 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 14, 2018, 06:50:35 AM
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.

Yes, that was exactly my problem :)

It stemmed from the discussion on HCAP vs LAV and I just kept going back to it.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on October 14, 2018, 07:28:27 AM
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.

Somehow that feels quite counterintuitive to one expects hitpoints to work. I would be very worried about troubles introduced at larger size difference, as armor roughly scales with HP, so you now end up with p^4 scaling in survivability. I'd expect HAV or similar to still preform reasonably well against the largest vehicles, but like that they could  become impervious against anything but themselves.
Would not increasing the amount of HP on vehicles do the job? Give 50HP instead of 30HP to light vehicles? (And add some more HP down the line for vehicles)
The only real gap seems to be at anti-infantry where multishot weapons exist compared to light anti armor.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 14, 2018, 07:43:04 AM
Here are the new vs old values when attacking a heavy vehicle. This assumes equal tech.

All shots assumes all shots to kill the same target. In reality, this is on the low side because multi-shot weapons could target something else if they kill the first target and have shots remaining.

(http://www.pentarch.org/steve/Screenshots/GCAttack001.PNG)
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on October 14, 2018, 09:35:39 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 14, 2018, 09:55:06 AM
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.

There are some other considerations, beyond looking at the % chance to kill for the two weapons. For example:

HAV shots use 36 supply vs 16 supply for MAV. HAV require large vehicles, whereas MAV can be mounted on Medium. If you do go HAV and decide you need heavy armour too, that makes the HAV more than double the price of the MAV. Medium vehicles are harder to hit than heavy vehicles when attacking. HAV will do considerably more collateral damage. You are over-killing with HAV if you face anything smaller than heavy vehicles, etc..

I am trying to make this a choice based on a number of different factors, so that different choices are better in different situations.

Title: Re: C# Aurora Changes Discussion
Post by: Bremen on October 14, 2018, 12:02:25 PM
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.

It's worth pointing out that while Statics with MAV might only be 35% better than statics with HAVs against medium vehicles, they're also 35% better against light vehicles, infantry, and other statics; they can also take 35% more hits.

Is that worth being 75% less effective against heavy, super, and ultra heavy? Honestly, probably not IMHO, but it's not that far off either. And if you happen to know your opponent likes medium vehicles then you'd definitely want to build them instead.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on October 14, 2018, 01:38:06 PM
I must say I really like this change since it make different weapons really useful if in their right environment and allot harder to just say one weapon are more powerful than the next because it all depends now. Some weapons might cost huge amount of supplies but if used against the right target it will be worth it over less capable weapons from before.

This change... I think will make optimal efficiency depend on the situation rather than certain things always the best choice.

Balance is of course still a work in progress I assume, but the linear approach to Damage/HP was a bit problematic from a balance perspective.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on October 14, 2018, 04:44:48 PM
Heavy Bombardment does surprisingly well against heavy armour, even better than an MAV weapon, if we go by size of the weapon.

Of course, like the HAV it guzzles supplies in comparison, but Heavy Bombardment does a pretty good job against anything lighter as well simply by firing more often.
Title: Re: C# Aurora Changes Discussion
Post by: Conscript Gary on October 20, 2018, 03:26:51 AM
It's past 1 in the morning so I can't offer a point-by-point breakdown this time, but I very much like the STO weapon rules so far. The possibilities are deliciously wide open.
Title: Re: C# Aurora Changes Discussion
Post by: hyramgraff on October 20, 2018, 10:58:18 AM
I'm surprised that a Military Academy doesn't require any population to run.  I would expect a facility that generates 1000 ship crew per year to need some civilian support for that many students.

On the other hand, having new scientists being trained on a remote airless rock would make for interesting RP.  If you want to keep the population requirement as is, would you consider making a ship module that functions as the equivalent of a Military Academy?  That would also allow for interesting RP (like recreating Ender's Game).
Title: Re: C# Aurora Changes Discussion
Post by: sublight on October 21, 2018, 09:27:39 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: alex_brunius on October 21, 2018, 12:11:14 PM
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.

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.
Title: Re: C# Aurora Changes Discussion
Post by: TinkerPox on October 21, 2018, 08:12:04 PM
Quote from: alex_brunius link=topic=8497. msg110543#msg110543 date=1540141874
Quote from: sublight link=topic=8497. msg110542#msg110542 date=1540132059
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.

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 will say that the military can easily run their own academies themselves.  However I know that some save alot of money by hiring civilians for laundry, food, mail, tailor, etc.
Title: Re: C# Aurora Changes Discussion
Post by: Rabid_Cog on October 22, 2018, 04:39:32 AM
Remember that Steve stated that worker consumption only refers to workers that would need seperate life-support infrastructure. With that in mind, the logical conclusion is that even if there are civilian teachers/cooks/cleaners/maintenance workers/etc. they are being housed in the Academy itself and supported as part of the upkeep cost of the Academy. An Academy simply does not need an extensive civilian population living around it to perform supporting work for it to function, which is different than 'Has no workers'.

The only place this abstraction falls apart is in the case where a race has 0 total population (where is the Academy pulling its people from?) but in such a case, wealth shortages would probably sink you anyway so who cares? Its a sufficiently edge case not to matter too much in the grand scheme of things.

If we want to be technical about it, an Academy WOULD need a population accessable by trade route. And while having a new trade good "Students" could be funny, I dont think it would add much to the game.
Title: Re: C# Aurora Changes Discussion
Post by: Panopticon on October 22, 2018, 12:11:05 PM
A "student" trade good sounds pretty amusing actually, could lead to getting students from allied empires as part of trade, which seems cool.
Title: Re: C# Aurora Changes Discussion
Post by: tobijon on October 22, 2018, 12:20:29 PM
what also would be possible is to simply increase the demand for transport of people to a planet with an academy, rather than making a new resource using the old one for more.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on October 26, 2018, 11:36:35 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 26, 2018, 12:31:39 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on October 26, 2018, 12:38:02 PM
Oh my bad, I didn't realise that was the change. Never mind then!
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on October 26, 2018, 12:41:29 PM
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.

Quote
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

Is this right? I'm almost positive I remember getting some mining from CI in my pre-TNE games.
Title: Re: C# Aurora Changes Discussion
Post by: Kelewan on October 26, 2018, 01:36:45 PM
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.

Quote
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

Is this right? I'm almost positive I remember getting some mining from CI in my pre-TNE games.

Yes there was mining output from CI in my pre-TNE  games. If I remember correctly it was also 0.1 like construction. Don't remember  fighter factories
or ordnance factories as I never build any fighters or missiles before converting my industrie
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 26, 2018, 01:57:55 PM
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.

Quote
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

Is this right? I'm almost positive I remember getting some mining from CI in my pre-TNE games.

Yes, you right - it was 10% mining :)

C# is setup so that everything is configurable from the DB. I thought I had done the same when I checked the VB6 database, but it turned out that Access DB was already modified for C# and VB6 used hard-coded values. It looks like VB6 has 10% construction, 10% mining and 5% refinery, so this is a boost.

Even so, I will leave it as the new values and update the post.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 27, 2018, 01:25:11 PM
A quick view of the in-progress Race Summary window. You can edit some of the species information in SM Mode. I also plan to add some options around mixing commander name themes.

The technology column is for non-race-specific technology that wasn't automatically provided provided prior to game start. This will only show the best technology in each category.

This is from the first test game, which is about 3.5 years in at the moment. One of the aims for this window is a simple screenshot that can show the progress of a race. I'll add more information as needed.

(http://www.pentarch.org/steve/Screenshots/RaceSummary001.PNG)
Title: Re: C# Aurora Changes Discussion
Post by: DEEPenergy on October 27, 2018, 02:41:37 PM
Hey Steve, it looks great. Super pumped for the test campaign. About how fast is it running compared to VB6 Aurora?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 27, 2018, 05:19:43 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: jonw on October 27, 2018, 05:52:48 PM
That bruce boxleitner picture always makes me want to dig out my box set...
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 27, 2018, 06:15:37 PM
That bruce boxleitner picture always makes me want to dig out my box set...

Yes, that was a great series :)

And I also have the box set :)
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 28, 2018, 06:15:40 AM
Just for interest, here is the test game underway on both monitors - you may have to scroll horizontally to see it. There is a button on the events window that will adjust it to the height of your monitor.

Erik, if this image is too large and causing loading issues, feel free to remove it.

(http://www.pentarch.org/steve/Screenshots/GameInPlay001.PNG)
Title: Re: C# Aurora Changes Discussion
Post by: Bremen on October 28, 2018, 02:23:49 PM
Amusingly, Aurora is my primary reason for wanting a second monitor :P
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 29, 2018, 09:29:05 AM
I've decided to allow medium weapons on light vehicles and heavy weapons on medium vehicles. Super-heavy weapons will still require super-heavy vehicles.

In the test campaign, I have reached the point (9 years in) where the various houses are designing their first ground forces. As I started to do research for the planned forces, I quickly realised there are plenty of examples where heavier weapons are mounted on lighter vehicles, creating greater firepower at lower cost, but with greater vulnerability.

As an example of the forces being created, below is the initial ground formation for House Reichmann. This is the smallest of the various house formations and is intended to function as part of battalion or regimental-size formation. House Reichmann is aiming for a mobile, capable offensive force and will have dedicated Panzer formations as well.

(http://www.pentarch.org/steve/Screenshots/Panzergrenadier002.PNG)

In contrast, here is a much simpler infantry-focused formation from House Aurelius, intended to be one of ten cohorts in a full Legion.

(http://www.pentarch.org/steve/Screenshots/Panzergrenadier004.PNG)

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)

House Ragnar is infantry-led but uses the low-cost Thralls to soak up damage while the Berserkers do most of the offensive damage.

(http://www.pentarch.org/steve/Screenshots/Panzergrenadier006.PNG)

Finally, the House Varenne Regiment of Foot is primarily a defensive formation with limited heavy weapons. It is intended to hold the line while heavy armoured cavalry forces (yet to be designed) launch the decisive attack.

(http://www.pentarch.org/steve/Screenshots/Panzergrenadier007.PNG)
Title: Re: C# Aurora Changes Discussion
Post by: clement on October 29, 2018, 12:35:50 PM

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)

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.

Title: Re: C# Aurora Changes Discussion
Post by: Kurt on October 29, 2018, 01:52:32 PM
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.

That is quite the improvement.  I'm not going to mention how long each of my five-day increments take, but suffice it to say that its isn't a fraction of a second. 

Kurt
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on October 29, 2018, 02:38:28 PM
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.

Yes, I haven't added code yet to blank the panels when a new race is selected. I missed that one when doing the screenshots. There is a lot of tidying up on those lines going on at the moment.

First ships under construction now so progress is still relatively fast.
Title: Re: C# Aurora Changes Discussion
Post by: Vroom on October 30, 2018, 02:33:38 AM
Steve, could you please add female names into the Roman names database.
Title: Re: C# Aurora Changes Discussion
Post by: Froggiest1982 on November 02, 2018, 04:14:25 PM
"Linked Windows
C# Aurora has a option to link all the open windows, so that when you change the current Race in one window, all the other windows change to the same race."

Massive quality of life improvement for those who likes Roleplay with multiple races!
Title: Re: C# Aurora Changes Discussion
Post by: Profugo Barbatus on November 03, 2018, 01:46:24 AM
Linked windows, me and my multi empire games thank you Steve.
Title: Re: C# Aurora Changes Discussion
Post by: Wise PingWin on November 07, 2018, 02:07:38 AM
Quote from: Vroom link=topic=8497. msg110717#msg110717 date=1540884818
Steve, 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.
Title: Re: C# Aurora Changes Discussion
Post by: Hamof on November 07, 2018, 02:03:44 PM
I feel like there should be lines between the mineral columns, might look better that way. Possibly also between the mineral amount and the mineral accessibility.
Title: Re: C# Aurora Changes Discussion
Post by: space dwarf on November 08, 2018, 11:14:34 AM
Quote from: Vroom link=topic=8497. msg110717#msg110717 date=1540884818
Steve, 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.

then add those feminised family names, silly
Title: Re: C# Aurora Changes Discussion
Post by: Kelewan on November 09, 2018, 05:48:21 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 09, 2018, 06:41:29 AM
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.

A max colony cost is calculated for each comet, as well as it's normal colony cost. You can flip between them on the system view (there is a checkbox to change).

I've set it so the standing order for unload colonists ignores comets, which is what effectively happens now anyway. That prevents other potential issues with colony ships chasing comets. The decisions about considering potential max colony cost and whether to use the comet will only sit with the player.
Title: Re: C# Aurora Changes Discussion
Post by: Hazard on November 09, 2018, 09:19:57 AM
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?
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 09, 2018, 10:40:24 AM
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?

If I decide to add eccentric orbits for planets, I will add something on those lines.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on November 09, 2018, 12:11:34 PM
Quite interesting. I thought all comets were basically unstable piles of rubble barely held together. Guess I was wrong and they are more solid.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on November 09, 2018, 04:35:42 PM
The Rosetta mission assumed that, then it's harpoons bounced off the hard surface of the comet.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on November 09, 2018, 06:23:52 PM
Cool beans.

Turns out Vangelis made an album:
list=PLMftvPCnRjqnk-CVVlZZrAD6j9P6VK3ue
More Aurora background music :D
Title: Re: C# Aurora Changes Discussion
Post by: MarcAFK on November 11, 2018, 06:35:14 AM
Harpoon? Should have tried a shaped charge like Hayabusa.
Title: Re: C# Aurora Changes Discussion
Post by: Jorgen_CAB on November 13, 2018, 05:14:58 PM

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.

Sorry to bring up an old comment but I was looking through the thread and I had some feedback in this issue. As pointed out agility has an almost exponential effect on AMM efficiency since Agility don't do anything for missile defense and speed is what mostly define missile defense aside from ECM now as well in a different way.

But... when we look at missiles in real life there is a similar war going on between agile or speed as defense for missiles. I don't think any of them has won that fight yet as both have merits.

My suggestion would be to make agility on offensive missiles act as defense against enemy missiles but serve no purpose against beam attacks. The reasoning being that the agility is not quick enough to avoid a laser or Gauss shot at close range.

So... speed and Agility would be two separate defensive mechanisms and don't directly add to a missiles chance to intercept or hit something.

Now you could add agility to everything and use the same rules for missiles and ships. The heavier an object is the more space is needed for each point of agility thus a small missile need very little internal speed for agility and a large 10.000t ship need allot more space for internal integrity to conduct evasive maneuvers against missiles but you could potentially add some Agility to ships to reduce the chance to hit them... especially useful on slower ships.

This would also fix the current problem and add some more interesting things to equip things like fighters and ships with. It will also not make agility overpowered at intercepting missiles as you gain technology as you also use it to avoid missiles.

For offensive missiles agility will be useful to avoid enemy missiles but will do nothing against Beam PD, so you can't go nuts on it which will still make AMM slightly more efficient in the use of Agility.

You can also make small Interceptor fighters really good at dodging incoming missiles which can be interesting in a anti-fighter or space superiority role.

You could just make it something simple such as 5p Agility in the AMM versus 3p Agility on the ASM means 3/5 = 60% chance of avoiding a hit if the missile hit due to speed. Of course the balance would then be how easy it is to hit through speed or how to balance it.
Title: Re: C# Aurora Changes Discussion
Post by: Polestar on November 17, 2018, 02:29:30 PM
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".

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.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on November 18, 2018, 12:32:57 AM
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".

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.
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.
I agree it is a shame that you end up running against this limit. It seriously affects your choice of PD, since many missiles cross the engagement range in 1 to 2 pulses, you end up going for Gauss in final defense.
Title: Re: C# Aurora Changes Discussion
Post by: QuakeIV on November 18, 2018, 04:43:04 PM
It's been discussed in the past.  Laser maximum range is the distance light travels in a single pulse, and the solutions to that were all dismissed as too complicated or not good enough.  It's still kind of beyond me why we can't just say TN lasers work like TN sensors and are instantaneous, which is why they cost TN resources to build, but such is life.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on November 18, 2018, 06:49:11 PM
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.
Title: Re: C# Aurora Changes Discussion
Post by: tobijon on November 19, 2018, 03:55:47 AM
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
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on November 19, 2018, 06:47:33 AM
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
You should try and program that and see, how many problems occour, when you change "one simple system" ;-)
Title: Re: C# Aurora Changes Discussion
Post by: chrislocke2000 on November 19, 2018, 07:20:07 AM
There are a few areas of game play where the five second tick causes frustrations, off the top of my head the ones I can think of are:

- Missiles launching and impacting before AMMs can detect and launch
- Missiles moving through the PD engagement envelope of picket ships / fighters without giving those ships the chance to fire
- Fighter dog fights generally just coming down to he who has the highest initiative decides on if they want the engagement (similar for ships but generally don't have the glaring differences in distance v weapon range as you do for fighters).

None of these cause huge issues but it would be nice to have a tweak in game mechanics to help address some of this. I also think the missile issues will be less of a problem in C# as I believe that missiles will generally be a bit slower than current V7.1.
Title: Re: C# Aurora Changes Discussion
Post by: Agoelia on November 19, 2018, 07:23:40 AM
Quote from: Garfunkel link=topic=8497. msg111075#msg111075 date=1542588551
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.


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. 
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 19, 2018, 07:25:34 AM
- 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).
Title: Re: C# Aurora Changes Discussion
Post by: TMaekler on November 19, 2018, 08:45:27 AM
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.
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).

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?
Title: Re: C# Aurora Changes Discussion
Post by: Kelewan on November 19, 2018, 08:47:39 AM
Quote from: Garfunkel link=topic=8497. msg111075#msg111075 date=1542588551
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.

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.

The 5 Second Intervalls and Beam weapon range is a complicate problem, and there are some aspects that get mixed up and put together that make the discussion like a gordian knot.


Update: TMaekler was faster answering while i was still writing. But I think it is important to keep the other aspects in mind
Title: Re: C# Aurora Changes Discussion
Post by: Steve Walmsley on November 19, 2018, 11:28:21 AM
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.
Title: Re: C# Aurora Changes Discussion
Post by: Garfunkel on November 19, 2018, 12:53:38 PM
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:
A) Steve does not code additional tracking for beam weapons, meaning that beam max range drops to ~300,000 km
OR
B) Steve codes a beam weapon object that the game will track and possibly display on the map

Others have already elaborated all the issues with option B and option A would nerf beam weaponry even further versus missiles.

I wouldn't mind going down to 1-sec pulses for more fidelity but the current system works "well enough" for its purposes.
Title: Re: C# Aurora Changes Discussion
Post by: Whitecold on November 19, 2018, 01:00:14 PM
    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.

    The 5-second limit however does not apply for most of the game. That is 1.5M km, and early 4x range fire controls maybe use 10% of that. More to the point, nothing about the 5 second interval says that lasers/mesons/etc can only fire once per increment. Gauss cannons already do that, so there is no reason you can't have a 2, 3 or 4 second firing interval, which would result in more shots in some increments and less in others, as currently area Beam defense is rendered useless by 5 second increments. Similarly, there is a massive jump in beam damage output going from 10s to 5s fire rate, which happens at an arbitrary point in cap tech research, it would be much smoother to allow every upgrade in capacitors result in actually faster firing weapons.
    Most missiles spend only a single 5 second in range, allowing only a single shot, which means you may as well use final defense.

    The 5-second increment can be still kept, but instead each ship knows both its position last increment and the new position. The range for any shots fired can now be calculated by linear interpolation during that increment. So if you fire at 1st second and 4th second at a missile closing in at 30km/s, the first shot might be at 120kkm, the second at 30km/s.
    Title: Re: C# Aurora Changes Discussion
    Post by: tobijon on November 19, 2018, 03:04:41 PM
    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
    You 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
    Title: Re: C# Aurora Changes Discussion
    Post by: davidb86 on November 19, 2018, 03:13:06 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Barkhorn on November 19, 2018, 05:52:56 PM
    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.
    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).

    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?
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: sloanjh on November 19, 2018, 06:53:19 PM
    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.

    Ummm actually I just went back and looked and I don't see the quoted string in tobijon's 04:55:47 AM post (I don't see one at all at 03:55:47), so the quote in question doesn't appear to reflect tobijon's posts.

    That being said, let's all remember site rule #3 http://aurora2.pentarch.org/index.php?topic=966.0 and have fun - we don't want Erik to get out the trout!!!!

    John
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on November 20, 2018, 01:58:52 AM
    Or as mentioned earlier you could just say that the TN beam weapons work faster than light just like the TN sensors and literally nothing else changes.

    (https://media.giphy.com/media/xT0xeJpnrWC4XWblEk/giphy.gif)
    Title: Re: C# Aurora Changes Discussion
    Post by: TMaekler on November 20, 2018, 06:37:19 AM
    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
    You 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
    Sorry for you feeling misquoted. I intended no harm.
    Title: Re: C# Aurora Changes Discussion
    Post by: TMaekler on November 20, 2018, 06:38:04 AM
    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
    Title: Re: C# Aurora Changes Discussion
    Post by: davidb86 on November 20, 2018, 08:34:00 AM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: tobijon on November 20, 2018, 11:01:03 AM
    I was referring to  "one simple system" (the bit in quotation marks), people don't get to tell me what I think, which is what he did. I understand how complicated coding is and the issues with significant changes like going from 5 to 1 second
    Title: Re: C# Aurora Changes Discussion
    Post by: Whitecold on November 20, 2018, 12:15:13 PM
    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...
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on November 20, 2018, 03:07:20 PM
    If Steve wants to say that five light seconds is about the limit in terms of beams, then changing the minimum time increment size doesn't stop him from doing that...
    Title: Re: C# Aurora Changes Discussion
    Post by: Peroox on November 20, 2018, 04:40:25 PM
    With a lot of micro managment is already very easy to evade shoot from projetile on larger range than 5s. Just need to change speed/movement path every 5s to be sure that enemy will hit nothing. In normal Aurora ships have infinite acceleration and also don't need to care about fly direction so there is no way to be sure that enemy will be in a given position after next increment.
    Title: Re: C# Aurora Changes Discussion
    Post by: sloanjh on November 21, 2018, 12:01:38 PM
    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?

    That's the post to which I was referring in my previous response - I do see it.  On my machine it shows a timestamp of 04:55:47 AM, not 03:55:47 AM though.  I suspect this is a timezone thing - I'm on US eastern time; based on the discrepancy in timestamp I'd guess you're in central.  As tobijon just pointed out, the quoted string he was referring to is "one simple system".  I don't see those words in the post you copied; instead I see "shouldn't be too hard".  This is what I was trying to say in my previous response; apologies that I didn't make myself clear enough.

    If you ARE seeing the words "one simple system" in a post by tobijon, then that means you're correct and there's a discrepancy in what different users are seeing, in which case please let us know.  Otherwise TMaekler has apologized for the misquote, so I think the issue can be put to bed.

    Thanks,
    John
    Title: Re: C# Aurora Changes Discussion
    Post by: davidb86 on November 21, 2018, 12:10:56 PM
    No I saw the accurate forum quote of the post.  In tmaekler's reply while I saw the words "one simple system" in quotes, I did not think that was a quote of tobijon, but a generic "Air Quote" which captured the flavor of tobijon's "shouldn't be too hard" which every suggestion for aurora always seems to indicate. 

    You are correct that I am in the Central time zone, and now that you have pointed out, i understand what tobijon was trying to say.
    Title: Re: C# Aurora Changes Discussion
    Post by: TMaekler on November 23, 2018, 07:18:44 AM
    I am just now reading the posts along my "quote". Think I can clear up the misunderstanding here.

    My "one simple system" wasn't intended to be a quote from tobijon, it was me describing the "5-second-increment-system" as "one simple system". So I wasn't quoting him; just taking a shortcut so I don't have to write a lot of stuff to explain what I mean, and subtextually saying, that it is not a simple system (coming from a programmers background myself). So sorry for shortening it too much and thereby becoming misunderstandable.
    Title: Re: C# Aurora Changes Discussion
    Post by: tobijon on November 23, 2018, 11:07:22 AM
    but that's just the thing, despite that you're still assuming that I considered it a simple system which I don't, and if you read what I said I wasn't advocating changing it.
    Title: Re: C# Aurora Changes Discussion
    Post by: Deutschbag on November 26, 2018, 12:25:58 PM
    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.

    I forget if unrest has been addressed before -- but perhaps this excess wealth being funneled into consumer goods could be modeled in some way with regards to unrest. Reducing civil unrest or so on, in proportion to the amount of money being diverted into public spending.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on November 26, 2018, 01:40:09 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Froggiest1982 on November 26, 2018, 03:39:25 PM
    Referring to the below, I understand the concept which is fair enough. However, could that be confined to Conventional Races only? A sort of mechanic that disappears after you discover the trans-Newtonian minerals or probably another particular tech such as Jump Gates. Even if the player can manage that sort of things (but still annoying moving forward when cash is meaningful) I am more afraid on the AI management. Thoughts?

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on November 26, 2018, 03:58:25 PM
    I thought NPRs do not have to worry about wealth at all.
    Title: Re: C# Aurora Changes Discussion
    Post by: tobijon on November 26, 2018, 04:05:08 PM
    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.

    yes, but entropy is on your side for that one  :)


    On the wealth mechanic: wouldn't it also be better for there to be more things that cost money, like terraforming for example, wouldn't that be kind of expensive?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on November 26, 2018, 04:41:55 PM
    Generally speaking, wealth is usually irrelevant for conventional races and very relevant for TN races. I don't want the conventional period to take away meaningful decisions from the subsequent early TN period. In those rare situations where a TN race has a large excess of wealth, whether that maximum is 2x or 10x is only going to make a significant difference if that race suddenly changes from low to high expenditure relative to annual income, which is unlikely. 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.

    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on November 26, 2018, 05:26:07 PM
    While we are on the subject of wealth... perhaps add a cost of commercial ships in state service in terms of a small wealth cost symbolizing the cost of sallaries and maintenance needed for these ships. I think everything need to have some cost, commercial ships should not get a pass.
    Title: Re: C# Aurora Changes Discussion
    Post by: King-Salomon on November 27, 2018, 03:28:51 AM
    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...
    with the converting of the factories the wealth is starting to come in and can be saved for later (something like a boost for the whole economy with the invention of TN-tech)

    a (mostly) conventional society would struggle to save wealth - invest in ground forces etc but it would not be impossible - especially if they start building financial center to pay for the land forces they want to deploy in the conventional years...

    a converted economy would save some wealth at the beginning (but not as much as atm) but would have to react to rising wealth useage through ships/armys after some years...

    having a hard cap at the gamestart I am not sure about... building financial centers at the starting phase is a strategy too - one that wouldn't be reasonable with a wealth-cap...
    Title: Re: C# Aurora Changes Discussion
    Post by: alex_brunius on November 27, 2018, 06:20:19 AM
    About wealth... Maybe a wealth surplus could slightly increase growth rate or there could be an option to automatically subsidize Commercial Shipping Companies with the surplus?

    Or another option is it gives a small boost to production/mining/research output ( Say a 20% wealth surplus boost performance by 2%? )

    That way it wouldn't feel like a total waste, but still as a not optimal way to spend the wealth.
    Title: Re: C# Aurora Changes Discussion
    Post by: chrislocke2000 on November 27, 2018, 07:32:33 AM
    The wealth cap looks to me to be a reasonble solution to the problem. A couple of points:

    - Perhaps when reserching improved wealth this could add to the maximum cap or there could be a separate research line for this.
    - I like the idea of running a budget surplus that means you get higher growth rates / production bonuses as a way to entice even conventional starts to be careful with money.
    - Perhaps finance centres could also add a quantum to the maximum cap to give another reason to build more of them
    - When it comes to war reperations I'd be frustrated if these got considered in the cap. I guess the whole point of these is to address the rebalancing of significant expenditure for the war so would be annoying if a chunk of money received just disappeared. In a recent campaign it's these payments that have actually been keeping my economy going.

    Title: Re: C# Aurora Changes Discussion
    Post by: Rabid_Cog on November 27, 2018, 08:22:14 AM
    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*. We can safely assume its not just money, but rather represents the entire industrial capacity of your empire, all the non-TN manufacturing, services, etc. A "Finance Center" is not actually a New York Stock Exchange, but rather a commercial district where small business can flourish and provide goods and services to the public as well for state consumption. It would also reasonably include all TN minerals not in state hands (both % from your mines as well as CMC's that you dont buy).

    If we see Wealth as "Industrial Capacity", it makes sense that you can't save it up. If there is a company that can build toilet seats for 4 spacecraft in a year and you build 0 spacecraft in a year, it does not follow that you can now build 8 spacecraft's worth of toilets the following year, you can most likely build 0 as the company has gone bankrupt due to having no income for a year.

    You can conserve resources to some extent, building up stockpiles, but there is a very low limit to how much of that is feasable. The economy only functions if it flows.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on November 27, 2018, 08:33:16 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: alex_brunius on November 27, 2018, 08:51:18 AM
    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.

    This is another good point. It doesn't make sense that Conventional Industry would be cheaper to run just because their output is lower...
    It's supposed to represent less efficient factories after all, and it seems you nailed down one of the root causes of the early wealth buildup.

    ( Unrelated: I have the same issue with conventional tech rocket engines being cheap to run on fuel just because their thrust output is so low )
    Title: Re: C# Aurora Changes Discussion
    Post by: TMaekler on November 28, 2018, 08:35:11 AM
    In regards to the Maximum Wealth Balance:
    When I started my conventional games, I always did that with a 50% financial efficiency. That way not so much wealth (but still enough) accumulated. I therefore had to begin constructing financial centers at some point to not be overwhelmed by running costs later... found that solution quite ok.
    It also opens the option to lay waste of a civilization by bombing away their financial centers... .
    Title: Re: C# Aurora Changes Discussion
    Post by: bean on November 29, 2018, 11:46:59 AM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on November 29, 2018, 01:37:52 PM
    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.

    Ships in overhaul are stationary and the to-hit chance will reflect that.
    Title: Re: C# Aurora Changes Discussion
    Post by: bean on November 30, 2018, 07:18:18 AM
    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.

    Quote
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on November 30, 2018, 10:38:46 AM
    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.

    Quote
    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.

    Not in C# Aurora. It is just an expensive target. It wasn't very realistic in VB6 that a ship undergoing overhaul in 'dry dock' was combat capable. I'll add that information to the rules post.

    Also, when a ship speed is checked for any reason, a ship in overhaul will be 0 km/s.
    Title: Re: C# Aurora Changes Discussion
    Post by: the obelisk on December 03, 2018, 12:06:47 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on December 23, 2018, 02:34:31 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 23, 2018, 04:43:57 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on December 23, 2018, 05:16:00 PM
    Okay, that's much less bad than I feared it would be.

    Of course, this just means that general bombardment is really not viable against heavily fortified targets. This is something we've already known for a while, that the best orbital bombardment targets are heavily armoured vehicles because they just can't hide. On the other hand, they're heavily armoured, so you'd use very different weapons against them, instead going for the biggest spinal weapons if you're talking energy weapons.

    Otherwise the shot will likely bounce on the armour. I anticipate that as ground armour levels escalate and ground gun strength stagnates (relatively speaking) that ships will end up taking up the role of super heavy bombardment/super heavy anti vehicle weapons.


    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 24, 2018, 02:36:37 AM
    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.

    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 :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Whitecold on December 24, 2018, 03:41:53 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: alex_brunius on December 24, 2018, 04:13:14 AM
    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.

    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.


    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'm fairly confident that it's diluted by size, just consider that the no go areas around either site ( where radiation is lethal/unhealthy ) as a percentage of total available surface area on the planet is subject to change based on how large the planet would be. As long as early deaths by radiation is abstracted into the initial damage instead longer term casualties after people know where radiation should be very limited if we can assume they will seek to avoid radiated areas.

    I also assume it would depend quite a bit on the severity of weather, climate and fauna on the planet, because those are known to spread around or concentrate radiation making it less predictable.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 24, 2018, 04:26:46 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 24, 2018, 04:39:59 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on December 24, 2018, 05:19:25 AM
    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 :)

    Well, yes? I mean, your colleagues would probably know better than me, but you're basically dealing with a chemical contaminant that'll concentrate at the location of the spill. While that can be a large area, compared to a planet it's rather small.

    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.

    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.

    Most battles you are likely to face in Aurora appear to me to be regiment sized or smaller against roughly equal sizes. With modern day coordination and transport technology you can decide a battle in about that time unless at least one side really digs or avoids confrontation and the terrain favours that approach.

    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.

    There is and there isn't.

    What you are dealing with in space combat is an island hopping campaign, even if those islands are asteroids and planets. This means that when you are waging a war and are considering targets you have to sincerely ask the question of 'do I actually need to take this place, or can I skip it?' Because if you can isolate a target, any target, and it can only function as a forward operating/deployment base when supplied, any target that is not supplied is not helping the enemy war effort, and you only need to take such targets if you want to make use of the facilities yourself. Or they've got Deep Space Tracking facilities that you want to blind.

    You always want to attack a place with civilians because that's a work force that could be turned towards supplying the enemy with troops and ships, but asteroid based military personnel only repair station #21 is a place you can forget about once you clear out any defending ships. Any guns it has simply don't have the range to be dangerous.

    That, if anything, is the best argument I can see for the ability to launch sensor equipped missiles from ground launchers, as a properly equipped long range space denial ground unit paired with a few deep space tracking stations can effectively constrain enemy movement by occasionally dropping a few warheads on poorly escorted supply ships, effectively forcing an enemy to engage or keep eating losses.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on December 25, 2018, 06:51:07 AM
    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.

    I think that time and the intensity of combat should be related to the size of the of the forces and the size of the infrastructure being defended.

    A large army defending a highly populated world with vast cities doted over a vast planet with favorable terrain should take months if not years to subdue even with relatively superior forces.

    If you invade a small asteroid defended with a strong force but in a relatively small area and in a confined space the combat should be over relatively quickly even if the forces are relatively large, quicker if they are small.

    There is a huge difference in the logistical and administration of large formations that need to coordinate combat effort over a vast planetary area.

    If you have say one division that defend on a "normal" planet and you have a population of a couple of million people it would be vastly different than if you have 20 divisions defending a planet with 2 billion inhabitants even if the invading forces are roughly the same in strength relative the defenses. The latter is way more complicated and require a much more maneuvering and going from house to house to root out enemy resistance, not to mention civilian resistance cells constantly harassing your supply lines etc...

    So... some sort of modifier to the to hit and also supply use for wars the simply require more time an lower intensity seem appropriate. This would mean that some battles might be quick and very costly in supplies while others take ages but also drain supplies much slower as well. You can also have different rates at which supply is consumed for different types of conflicts. For example the more population there is the more supply need to be consumed in relation to the intensity, signifying the resistance of the civilians as an example.

    There can be other considerations as well which I have not thought about.

    But at least in my opinion only having ONE unified intensity on conflict is not really suitable or practical for all types of conflicts. It is simply not practical to have all forces engaged in conflicts all the time and varying intensity could reflect this quite well.
    Title: Re: C# Aurora Changes Discussion
    Post by: King-Salomon on December 25, 2018, 08:04:08 AM
    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.

    Yes that would be my main concern too - it should pay off to invest the capital & time to train ground units and to invade a planet/body instead of just "bomb it to stone age and flatten it into a disc" ... if someone wants to go the "cheap&quick" way OK... but if someone wants to pay for it in time&money he should be able to benefit from his trouble (if all goes well and not too catastrophic) - investing in ground troops wouldn't make any sense if using them would get the same nuclear hellhouse as a planetary bombardment from the beginning...
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on December 25, 2018, 08:23:23 AM
    It doesn't seem like orbital bombardment is that effective and since firing weapons now also cost supplies as they break down once in a while there will always be a cost for doing so.

    I guess the question will be how important it is to destroy or capture a specific installation. Do you dare leaving it even if it is isolated. If the enemy manage to resupply it might be a big problem for you, perhaps even a catastrophe to your strategic objectives.

    So... garrison bases with cheap infantry who can hold their own against orbital bombardment for a long time might not be a huge investment in comparison, especially not if you have enough STO weapons to make orbital bombardment without forces to suppress the STO properly very costly.

    You can also hide fighters at ground bases and these certainly could be a problem if you leave these bases able to harass your supply lines.

    Garrisons and ground to space weapons should mainly be a way to deter the enemy, not to directly make places impossible to invade. Just enough to make it take time and effort not to bypass them and give enough time and respite for a defensive force to be formed and engage the now more known enemy and its forces.

    Forcing an opponent to waste resources and time on either ground or bombardment effort are going to impact their ability to conduct space dominance operations. This should see an increasing difficulty in invading as oppose to defending areas of space. So attacking should need allot more energy and resources than defending.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Marski on December 25, 2018, 09:50:33 AM
    A genocidial race would just vaporize it all with nuclear bombardment, thought. And worry about the mess later.
    Title: Re: C# Aurora Changes Discussion
    Post by: King-Salomon on December 25, 2018, 10:05:55 AM
    "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."

    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...

    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
    Title: Re: C# Aurora Changes Discussion
    Post by: Barkhorn on December 25, 2018, 11:48:57 AM

    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.
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Kurt on December 25, 2018, 04:05:32 PM
    A genocidial race would just vaporize it all with nuclear bombardment, thought. And worry about the mess later.

    The Republic's spokesperson officially denies that cobalt-encased enhanced radiation weapons were recently used against Dregluk cities.  She then stated, however, "They deserve it, though."

    Kurt
    Title: Re: C# Aurora Changes Discussion
    Post by: Scandinavian on December 25, 2018, 09:01:53 PM
    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...

    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
    That depends entirely on the nature of the target and the weapons.

    For conventional weapons (and we can probably include orbital direct-fire weapons in this), engagements basically come in four varieties: Undirected counterforce bombardments, ground-directed fire support, terror bombing, and assassination.

    Undirected counterforce bombardment against even minimally prepared ground forces is a way of punctuating your press releases and diplomatic communiques with explosions, not a serious military tool. The entire air campaign against Serbia during the wars of Yugoslav dissolution knocked out a mere handful of tanks, and this result is not atypical.

    Ground-directed fire support is extremely effective at killing opposing forces, particularly vehicles and particularly on the defensive. The clearest demonstration of this recently was 2013-14 in Kobane, where the USAF chewed through a short brigade of Islamic State's only solid combat troops and all the expensive American hardware the Iraqi army left behind when it bugged out of Mosul. For offensive exploitation, however, you need infantry that is willing to take casualties, because you need someone moving forward to provide fire direction. This was one of the problems the IDF had in 2006, and a major reason Hezbollah humiliated their expeditionary force.

    Terror bombing kills a lot of civilians and causes a great deal of expensive property damage, but not really enough to materially degrade the ability of the population to sustain a war effort. Even weeks of sustained carpet bombing with chemical and conventional weapons was insufficient to wipe out Fallujah, Mosul, or Raqqah, which still had to be taken through ground assault. (This is not a USAF problem either; the Russian air force could not bomb Grozny or East Aleppo into submission either, despite pounding most of the buildings to rubble.) Similarly, studies of the carpet bombing campaigns of the second world war tend to conclude that they cost more to conduct than it did to repair the damage done by them.

    Finally, assassination is perfectly feasible, but depends heavily on the quality of one's targeting intelligence. We've seen both extremely precise targeting of militia leaders, and the occasional wedding or funeral getting blown up. Either way, it's not really in scope for Aurora - it doesn't have a sufficiently sophisticated political model to properly simulate (counter-)insurgency warfare.

    Once you break out the nuclear warheads, the feasibility of undirected counterforce bombardment and terror bombing increases, but it's still not a simple exercise to glass a major planetary population. Assuming one point of missile warhead strength equals 10 kt (making Little Boy somewhere between 1.5 and 2 points), and a typical early to mid game warhead is 15 points, you'd need ten to fifteen of those to blanket a mid-sized city like Berlin with blasts that will reliably knock over sturdily constructed buildings. If we assume that one warhead point is about 100 kt, you'll still need six impacts (though if you're satisfied with killing the people and leaving about half the buildings standing, you can make do with three). And Berlin is not even in the top 100 cities of the world.

    To comprehensively demolish the industry of a homeworld, you'd need somewhere between one and ten thousand strength 15 impacts, depending on your assumptions about how warhead strength translates, and the distribution of industry across the population. This can be done, but it's not a trivial expenditure of ordnance for an early- to mid-game empire. And to wipe out the population, including dispersed rural communities, you would need far more (though the collapse of industrial society resulting from tearing out the major industrial centers may well take care of that for you).

    And counterforce bombardment remains non-trivial, particularly against dispersed or well prepared infantry and static units. You'll often have to literally dig them out of fortified positions, which means putting multiple impacts on top of them with fairly high precision. It can be done, but again, not a trivial exercise.

    The rules outlined upthread seem to capture these realities reasonably well. If you're willing to simply pave over the planet, you can with reasonable ease nuke it hard enough that it becomes worthless to the defender (which means any ground forces holding it are simply eating maintenance while providing no value in return). But if you want to eliminate a troop concentration, then you need to invest the planet with at least some ground forces to provide fire direction. And if you want to take the planet mostly intact, you need to do it on the ground, with relatively light troops and minimal orbital fire support.
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on December 26, 2018, 12:15:45 AM
    I thought a power 1 blast was equal to a megaton?  I could be off but that was my vague understanding.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on December 26, 2018, 04:34:09 AM
    Terror bombing of population is a different thing than destroying military installations that obviously will be fortified and hidden on a planet surface. If a military base is on an atmosphere free (or low atmosphere) moon/planet or similar then nuclear blasts will not really be that effective either.

    If then said defenses have a good deal of STO weapons you can not bombard the defenses indiscriminately either for fear of getting shot back, ships tend to be allot more fragile than ground based defenses.

    In certain scenarios indiscriminate bombarding might be the best option if you don't care for capturing some installation, but if you want to assure everything is destroyed you still might need troops on the ground.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on December 26, 2018, 04:42:38 AM
    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.

    If you presume that planetary infrastructure also can be built with lots of new materials for many different reasons just like civilian ships then destroying the infrastructure will become more than difficult, not to mention military installations and fortresses.
    Title: Re: C# Aurora Changes Discussion
    Post by: King-Salomon on December 26, 2018, 04:57:55 AM
    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... so 100-200 should be plenty to destroy 98% of earths industry in a single strike and make the planet lifeless...

    I guess that a comparison of "damage" is not as easy as it seems when you compair damage to starships in the game... but that is OK, it IS a game and it cannot be 100% logical in all aspects..

    also it is a difference if you see in-game missiles as "strategic ICBM" or tactical nuclear weapons...
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 26, 2018, 06:43:52 AM
    There is no direct equivalent for missile damage points. I've deliberately avoided having kilotons or megatons (or some form of Megajoule equivalent for beam weapons) to aid in the suspension of disbelief. Being too precise can raise logical questions that we don't really need to answer.

    However, I would say that 1 point is definitely on the low end for known nuclear yields. Several smaller bombs are generally more useful than one large bomb of the same total yield, unless you need to destroy a target that is hardened against nuclear attack.
    Title: Re: C# Aurora Changes Discussion
    Post by: Scandinavian on December 26, 2018, 07:18:50 AM
    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.

    The largest missile payload ever known to have been deployed on a missile is 25 MT Soviet R-36 (NATO designation SS-9 Mod 2). The largest known US missile payload is the 9 MT Titan II. Both well short of 100 MT, let alone several hundred.

    The largest warhead presently known or credibly speculated in service is either the Chinese Dong Feng 5A, a variable-yield warhead that can be dialed up to 3 MT, or the NATO Trident MIRV system at 8 times half a megaton.

    (All figures from MissileMap: https://nuclearsecrecy.com/missilemap/ )

    Depending on your Conventional Start configuration, how many Tridents you think it would take to wipe out industrial civilization, and whether terror bombing suffers targeting penalties for rubble like collateral damage does, you can get these numbers to confess to anywhere between 10 kT or 2 MT per missile warhead point (I have the math if people are interested, but have cut it for length). But as Steve just noted, none of this stuff scales neatly anyway, so while we can sort of estimate the yield of different Aurora warhead strengths, those estimates may depend on the use case and in any case are not necessarily going to let you fit a nice function of yield as a function of warhead size.

    Which does raise the interesting question of whether rubble applies to terror bombing the same way it does to collateral damage. That is not clear from the relevant rules post.
    Title: Re: C# Aurora Changes Discussion
    Post by: iceball3 on December 27, 2018, 01:47:50 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on December 27, 2018, 04:14:31 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Whitecold on December 27, 2018, 05:42:34 AM
    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.

    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 27, 2018, 06:28:59 AM
    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.

    I will add some different colour options at some point. Here are screenshots of an early attempt:

    http://aurora2.pentarch.org/index.php?topic=8455.msg94287#msg94287
    Title: Re: C# Aurora Changes Discussion
    Post by: Scandinavian on December 27, 2018, 08:04:16 AM
    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.

    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?
    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.

    Undirected energy weapons fire at basic riflemen should be highly use-impaired. You're blind-firing 10-50 cm lasers at largely civilian areas, hoping to hit individual soldiers. If you are going to try to kill those forces without committing ground troops, you will need to get into the genocide for fun and profit business, whether you do so with nukes or with enough direct-fire weapons that the locals will not realize they weren't actually nuked.
    Title: Re: C# Aurora Changes Discussion
    Post by: Coleslaw on December 27, 2018, 08:05:12 PM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 27, 2018, 08:32:25 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on December 27, 2018, 10:31:02 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Scandinavian on December 28, 2018, 01:33:00 AM
    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.
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: mtm84 on December 28, 2018, 02:51:01 AM
    So the question is, how long would it take to build up such a force in the first place?
    Title: Re: C# Aurora Changes Discussion
    Post by: Zincat on December 28, 2018, 03:15:29 AM
    So the question is, how long would it take to build up such a force in the first place?

    But that is the entire point, right?

    In VB6 aurora conquering planets was a non-issue. In reality, conquering a homeworlds should be extraordinarily hard. So, either you bomb the planet into nothingness, losing all infrastructure and population, or you actually gear up for a costly invasion. And note that the bombing will require a HUGE amountof missiles too, due to PD. Once again, costly.

    Conquering a homeworld of some other race, with all the benefit it gives you, from the population to the infrastructure, SHOULD be a monumental task.
    Title: Re: C# Aurora Changes Discussion
    Post by: Conscript Gary on December 28, 2018, 04:33:49 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 28, 2018, 06:54:32 AM
    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.

    Rather than fighting the STOs, I suspect it is probably easier to accept some losses to land a large invasion force that will take out the STOs on the ground. The Empire Strikes Back scenario.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 28, 2018, 06:58:16 AM
    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.

    There are currently six orbital bases with a total of 45 twin laser turrets (about the same as on the ground) and 87 AMM launchers. Total cost of bases was 12,000 BP + missiles. Total cost of STOs was 14,400 BP.

    With current construction rates, the bases take about 2 years on average while each 'planetary defence regiment' of 14 25cm lasers, 8 twin 10cm lasers plus supporting infantry and AA will take about 7 years to build (faster if ground construction tech improves). the NPR has 12 ground construction complexes and is currently building nine new planetary defence regiments (2520 BP), one armoured regiment (1086 BP) and two infantry regiments (373 BP). The concentration on the defence regiments is because the NPR has founded quite a few colonies and wants the PDRs for garrisons, although it can create seven infantry regiments in the same time as one PDR.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on December 28, 2018, 08:07:05 AM
    One of the future considerations for ground invasions will be what sort of unit you want to deploy in the first wave.

    While partially dependent on the defending forces, the main issue to me appears to be whether you want to deploy in large numbers to soak incoming fire, or with much armour to shed it.
    Title: Re: C# Aurora Changes Discussion
    Post by: Shuul on December 28, 2018, 11:23:46 AM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 28, 2018, 11:41:56 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Shuul on December 28, 2018, 11:51:45 AM
    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 :(
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 28, 2018, 11:54:17 AM
    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 :(

    You could still use multiple warheads and ECM to create large dangerous missiles. The problem with armour was it was creating missiles that was much harder to kill than their mass would suggest.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on December 28, 2018, 12:32:34 PM
    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".
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 28, 2018, 12:43:32 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on December 28, 2018, 01:18:39 PM
    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.

    I disagree about the roles encouraging smaller ships - with how Aurora works, there's no real downside to folding multiple roles into a single large ship that there wouldn't be in multiple smaller ships (IE, if you add every component from a 5000 ton escort ship and a 10000 ton carrier, you end up with a 15000 ton ship that does both just as well).

    If the problem is shock damage scales with regards to tech, wouldn't it make sense to have shock damage chances reduced by the tech level of armor it's hitting? Otherwise it's equating higher tech = bigger ships, which wouldn't necessarily be true.
    Title: Re: C# Aurora Changes Discussion
    Post by: Shuul on December 28, 2018, 01:46:52 PM
    I disagree that large ships are the current meta. I always felt handicapped with large ships, as they are expensive, slower, critical damage causes much more collateral damage, they cannot be split into few more fleets in case of a need, they need more advanced logistics to support, they need better tech to operate efficiently, they are easily detected etc.
    They defenetly do NOT need to be nerfed. Otherwise they will be not viable.
    Title: Re: C# Aurora Changes Discussion
    Post by: Whitecold on December 28, 2018, 02:10:08 PM
    About the meson change, is there no caliber dependence now? Unless there is, I still see little reason to use anything but the 10cm
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 28, 2018, 03:37:38 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Whitecold on December 28, 2018, 03:45:43 PM
    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.
    I think that will still be underwhelming compared to all other tech lines, which get more damage over their effective range.


    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".

    I think the true counterbalance to large ships is that they are hard to build, take a long time, and can only be in one place at once. The reduced sensor reach already opened up possibilities for forward scouts, and forward ships to take out enemy forward scouts, and possibly ships to take out enemy scout killers.
    Having enough platforms is an aspect that could be reinforced by making WP less easy to lock down, or add otherwise more infrastructure and ships in systems that need to be escorted and protected.
    Title: Re: C# Aurora Changes Discussion
    Post by: Iceranger on December 28, 2018, 06:54:59 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: MarcAFK on December 28, 2018, 07:16:38 PM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 28, 2018, 07:51:53 PM
    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.

    1) I don't mind about mesons attacking lightly armoured drop ships. They are vulnerable to other weapons as well. I minded them attacking the 125,000 ton transport design with 3400 armour that a hundred 20cm lasers couldn't penetrate (see the Dropping Troops thread that sparked the meson thread).
    2) There are no mesons in ground battles
    3) My other concern was the power of mesons in multi-race starts (see the Trans-Newtonian campaign for a good example). That is less of an issue now because bases can be armoured to mitigate the problem to some extent and it reduces the meson advantage over other beam weapons. The problem was that mesons were disabling ships and bases before they could even fire back. PDCs were very vulnerable in that situation but they no longer exist.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 28, 2018, 07:54:50 PM
    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?

    I did consider having the larger meson calibres have more than one point of damage, with each point penetrating (or damaging armour) separately. I was just concerned that by adding multiple shots I was offsetting the armour changes. The idea of higher armour damage but only a single penetrating shot is interesting though. If play test shows mesons are now too weak, that might be a good compromise.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on December 30, 2018, 09:14:31 AM
    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?

    And regarding surrender rules; I would say that non-combatant ships (civilian ships with not even self defense equipment) should surrender on boarding, armed merchant ships (ships with CIWS) and troop transport ships should surrender if the battle is clearly against them, possibly after at minimum 1 combat round to account for surprise and confusion, and military ships surrender when they are being overwhelmed.

    All subject of course to the militancy and determination ratings of the race in question. A highly militant race might find non-combatant ships willing to go a couple of rounds of combat, while a high determination might find denying a ship and information to a race more valuable, especially if they're very xenophobic.

    Diplomatic relations and reputation regarding POWs may change reactions to being boarded.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 30, 2018, 09:46:59 AM
    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 :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Kurt on December 30, 2018, 09:54:32 AM
    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
    Title: Re: C# Aurora Changes Discussion
    Post by: Whitecold on December 30, 2018, 10:09:23 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 30, 2018, 10:09:52 AM
    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

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 30, 2018, 10:21:29 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on December 30, 2018, 10:26:18 AM
    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 :)

    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.

    The real trick would be how to simulate the response to there being heavy ordnance units on the ship and the boarding party's attempts to avoid them.

    Just saying they're not involved would work fine with large ships, but a landing capable dropship probably can only be accessed through the troop transport bay anyway.

    Eh, it's a difficult question that doesn't really come with easy answers. Just going with 'not involved' is fine. Trying to figure it out precisely is a head ache.

    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.

    A ship with marines should probably have those marines stationed throughout the ship anyway just as standard operating procedure.
    Title: Re: C# Aurora Changes Discussion
    Post by: Scandinavian on December 30, 2018, 10:37:07 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Whitecold on December 30, 2018, 10:39:55 AM
    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.

    I more meant before boarding actually starts. I would imagine marines being spread out already. Of course, you should not be able to spread out an entire division in the ship.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on December 30, 2018, 10:55:44 AM
    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.
    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.

    Since weapon and vehicle crews are not modelled, I agree with Hazard that Steve's choice of "not playing a part" is the best option at least for now. Boarding combat in troop ships will likely never happen, or only once in a blue moon, so it's not necessary - and if you want to model extensive boarding combat aboard a space station, 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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 30, 2018, 11:46:33 AM
    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.

    Yes, I am definitely going down the route of heavy powered armour and CAP with boarding capability. Go Space Marines! :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Ynglaur on December 30, 2018, 02:43:30 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 30, 2018, 03:09:53 PM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: King-Salomon on December 30, 2018, 03:19:59 PM
    Yes, I could do something on those lines. However, if any of those vehicle crews are killed, what happens to the vehicles?

    I would stay with the "easy" solution to ignore non-inf at the moment - it could be a point for a future update but for 1.0 I would leave it abstract
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on December 30, 2018, 11:17:25 PM
    I've been running a campaign lately where one side made use of boarding combat, and it struck me that five minutes per increment is a long time, possibly too long.

    The basic situation was a jump point assault, where the defenders had a combination of mobile ships and also weapons platforms on the jump point. The attackers jumped in and, after considerably battering down the defenses, started boarding on the weapons platforms and some disabled ships.

    It turned out that five minutes is an extremely long time in this scenario. Even with most of their weapons disabled and holes in their armor for instant boarding, the weapons platforms were able to inflict considerable damage, mostly emptying their magazines, in that time. Even though the attackers had such superiority in numbers that they were able to take every ship on the first increment of boarding combat.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: King-Salomon on December 31, 2018, 03:03:17 AM
    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...)
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on December 31, 2018, 03:29:27 AM
    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...)

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Agoelia on January 02, 2019, 10:32:45 AM
    Quote from: Steve Walmsley link=topic=8497. msg111793#msg111793 date=1546248567
    Quote from: King-Salomon link=topic=8497. msg111791#msg111791 date=1546246997
    Quote from: Bremen link=topic=8497. msg111788#msg111788 date=1546233445
    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. . . )

    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.

    Agreed, a 20 marines squad boarding a 5000 crew capital ship should interfere a little bit with the operations but the slow down would be barely noticeable.  Viceversa, an entire company dropping on a 14 crew scout vessel would render almost impossible for the boarded vessel to execute any order (not even counting that they would slaughter/surrender everyone in a few seconds)
    Title: Re: C# Aurora Changes Discussion
    Post by: Scandinavian on January 02, 2019, 12:38:47 PM
    Perhaps once the boarders have achieved hull breach, crew morale would cap at [total frontage of defenders (crew plus defending infantry)] / [total frontage of defenders and attackers)], similar to how overcrowding or overlong deployments cause diminished readiness. It could also be modeled as reducing the effective crew to a percentage of full crew complement equal to [total defender frontage] / [total attacker and defender frontage]. Or both at the same time.

    This would have the advantage of piggybacking on existing mechanics that are well established and give a set of penalties that seem appropriate to a vessel having to deal with boarders.
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on January 02, 2019, 01:20:41 PM
    I think if the whole crew is going to get transformed into ad hoc infantry units, it shouldn't get to continue doing its job as a crew at that point.
    Title: Re: C# Aurora Changes Discussion
    Post by: Barkhorn on January 02, 2019, 02:05:31 PM
    I think it would be just like a ground battle; some crew would be "Front line", and would fight the boarders but would be unable to man their stations.  Other crew members would be "rear echelon" and would still be able to man their stations, but would not meaningfully contribute to repelling boarders.  Maybe the player should get a chance to set up which stations are manned and which are abandoned to repel boarders.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on January 02, 2019, 02:21:36 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Iceranger on January 02, 2019, 02:34:13 PM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Profugo Barbatus on January 02, 2019, 04:03:45 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Whitecold on January 02, 2019, 04:40:48 PM
    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.
    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.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 02, 2019, 05:04:46 PM
    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.

    Yes, I think something on these lines is probably appropriate.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 02, 2019, 05:11:07 PM
    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?

    As a preface to this, I don't want to devote time to coding special rules very rare situation such as (in this case) a carrier being boarded, while also carrying or receiving troop-carrying parasites.

    1) You will be aware that charges are being detonated on the hull or that boarder have penetrated the hull.
    2) If a parasite leaves, it will take any troops assigned to it. If one arrives, they will join in. This isn't a special rule - this is just how the code is working now. Hangar bay destruction will affect parasites during boarding but not their assigned troops (as they are exempt during boarding combat).
    3) There is no way to send extra troops to a ship being boarded if it has no way of receiving them.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on January 02, 2019, 05:16:21 PM
    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?

    1.  I believe you get a 'ship name is repelling boarders' message if one of your units is boarded

    2.1  No.  If parasites are hangared, their crew is zero.  Those folks are now part of the mothership's crew.

    2.2  Yes, unless the yet-to-be-written "boarded" penalties ban launching parasites. 
         --     If by "troops" you mean 'reduce the defenders numbers due to reduction in overall crew numbers, I certainly think they should.  If you mean 'escaping parasites also count as 'being boarded' and now there are separate fights,' then that sounds interesting, it might be fun, but I don't see how the player could have any meaningful decisions to make to impact the outcome.

    2.3  One certainly should be able to dock a dropship's worth of marines to counter-board an endangered ship, and therefore it would make sense that landing a squadron of Fighters would boost the defenders manpower by a tiny handful. 
         (And if 'Space:Above and Beyond' taught us anything, it's that risking 8 or 9 highly-trained marine aviators (spaciators?) in ground combat is the surest means of victory.)

    3.  If the as-yet-undetermined penalties for "being boarded" reduce the ship's speed, then boarding it again should be easy enough.  As long as Steve includes the code for boarding 'drops' on friendly units, your troops can crawl through the same armour breaches the attackers did and mop 'em up from the rear.
    Title: Re: C# Aurora Changes Discussion
    Post by: MarcAFK on January 02, 2019, 05:29:48 PM
    Reguarding boarding combat, you could have a chance of the ship surrendering every increment based on crew casualties, with a 100% chance after 95% casualties. Maybe also taking into account how must strength the boarders have.
    When the fight is fairly equal theres no chance of surrender, but as the defenders (or boarders?) start to get overpowered, and if total casualties on that side hits a minimum, maybe 20% then a surrender chance starts getting checked.
    There might be a small chance of the majority of a ship surviving battle, and a large chance of at least a chunk surviving.
    This would simulate the fact that teh entire crew doesn't need to be wiped out to take a ship but rather just critical elements need to be taken, maybe teh officers, bridge, engineering, etc,
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on January 02, 2019, 05:31:35 PM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on January 02, 2019, 05:52:00 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 02, 2019, 05:56:21 PM
    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
    Title: Re: C# Aurora Changes Discussion
    Post by: DEEPenergy on January 02, 2019, 06:10:02 PM
    Hi Steve, have you decided on changes for Star Swarm yet? And if so, will you give us the spoilers? :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on January 02, 2019, 06:21:35 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 02, 2019, 06:45:21 PM
    Hi Steve, have you decided on changes for Star Swarm yet? And if so, will you give us the spoilers? :)

    Yes, all changes made and ships designed. Just coding the AI at the moment and then the ground forces :)

    I don't want to give too much away just yet but I will say the following:

    They retain the same mine and recycle ships concept, although now it is done in a different way. There are still hive ships and FAC swarms, but there are other mid-range ships as well to support them. Their weapons have also changed and they are not exactly the same as player weapons. They are now somewhere between a race and a spoiler race, as they are prepared to explore and expand, and I even considered having them as a potential starter NPR. Their backstory is that they are from a different dimension (beyond our own and the Aether) and have been attracted by the use of TN ships (like moths to a flame), which is why they are starting to appear now. There is now some influence from WH40k Tyranids.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on January 02, 2019, 09:50:04 PM
    So tempted to read that but no, must preserve as much secrecy as possible!  :)
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on January 02, 2019, 10:02:35 PM
    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.

    You can just tell the ship to stop and get 100% boarding success.
    Title: Re: C# Aurora Changes Discussion
    Post by: hyramgraff on January 02, 2019, 10:47:49 PM
    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

    I'm looking forward to reading the first AAR with attempts to repel boarders causing a firefight on the hull of a flagship.  ;D 8)
    Title: Re: C# Aurora Changes Discussion
    Post by: MarcAFK on January 03, 2019, 12:05:33 AM
    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.
    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)
    Title: Re: C# Aurora Changes Discussion
    Post by: Conscript Gary on January 03, 2019, 07:51:06 PM
    I got curious about the numbers and dug into it a bit, and the huge buff to the success rate of landing boots on the hull is really, well, huge. I don't just mean the lowered speed multiple necessary to reach a 100% success rate, but what the odds look like even in the worst case of being just as fast as the target thanks to how the dice rolls work now.
    In the old VB6 case, after rolling those twenty d10s you'd have a hefty 80% chance of having no survivors at all, and the odds of having more than a few of your marine company survive drop very quickly to nil.
    As it'll be in C#, you'll still be taking huge casualties and are likely to only end up with ten or eleven dudes on the target... but you're also dramatically more likely to get at least one dude on there. For a formation the same size as the old marine company, the chance of everybody dying in the jump is just a few thousandths of a percent thanks to rolling per-unit. If the C# dudes are boarding-capable, that chance goes down five orders of magnitude.
    A single dude probably won't be able to take the ship once inside, but the way the math works out means that if a boarding attempt reaches the point of actually releasing troops it'll basically always end up resolved as a combat between the crew and the boarders, even if trivially. This should be interesting. It also means more fractional speed advantages can provide a tangible benefit, which is nice.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on January 04, 2019, 10:01:41 AM
    That's not a bad thing, really. Nothing more anti-climatic than losing your entire Marine company to the void of space.
    Title: Re: C# Aurora Changes Discussion
    Post by: Lucifer, the Morning Star on January 04, 2019, 01:30:33 PM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on January 04, 2019, 08:02:44 PM
    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 these "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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Lucifer, the Morning Star on January 04, 2019, 11:28:42 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: King-Salomon on January 05, 2019, 02:58:32 AM
    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...
    Title: Re: C# Aurora Changes Discussion
    Post by: Whitecold on January 05, 2019, 03:15:17 AM
    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...
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on January 05, 2019, 03:37:33 AM
    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.  ;)
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 05, 2019, 07:47:36 AM
    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?

    Just at the start
    Title: Re: C# Aurora Changes Discussion
    Post by: sloanjh on January 05, 2019, 08:53:08 AM
    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.  ;)

    Ah - but it was a good bad :)  Per the comments above, it's better not to discuss in the suggestions (or bugs) thread(s) but instead to break the discussion out to a separate thread and put a link in the suggestions thread. 

    John
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on January 05, 2019, 03:47:58 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 05, 2019, 04:37:54 PM
    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.

    I'm just starting to play with missile designs for the player race in the new test campaigns. The new fuel consumption definitely makes a difference. I have juggled warhead, engine and fuel and a few times. It is a ion-tech missile with max boost of 4x normal but even with 20% fuel the range is only 31m km. I have 50% engine, 30% warhead and 20% fuel. Fuel is now a serious consideration so the cruise vs fast decision is a real one.

    Missile Size: 5.00 MSP  (12.500 Tons)     Warhead: 6    Radiation Damage: 6    Manoeuvre Rating: 10
    Speed: 24,000 km/s     Flight Time: 21 minutes    Range: 31.44m km
    Cost Per Missile: 4.50     Development Cost: 450
    Chance to Hit: 1k km/s 240%   3k km/s 80%   5k km/s 48.0%   10k km/s 24.0%
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on January 05, 2019, 04:56:22 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on January 05, 2019, 07:30:32 PM
    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!
    Title: Re: C# Aurora Changes Discussion
    Post by: alex_brunius on January 06, 2019, 05:17:58 AM
    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!

    Which in turn can be defeated by launching the MIRVs from different directions, spotting and firing at the fighters/gunboats first ( with MIRVs or other weapons ) or simply giving the final stage long enough range than your enemy dares to send forward their picket.

    Lots of interesting tactics and counter tactics.
    Title: Re: C# Aurora Changes Discussion
    Post by: Zincat on January 06, 2019, 08:31:42 AM
    RE: the alien ruins on mars.
    That's a very nice thing to know Steve, that there's some chance to find ruins in Sol system.

    Honestly I always do that. I like to play conventional start but... I'll SM an alien ruin on Mars. Usually, I reroll multiple times until it's a level 3-6 ruin. Not too big (as that could simply be too good), but not too small either.

    In my roleplaying, it's fundamental. Since it's a conventional start game, in my mind the discovery of alien ruins sends the world into a frenzy. And depending on the "RP Flavour" of the current game, it can be an "excited frenzy" or a "paranoid frenzy"...
    Title: Re: C# Aurora Changes Discussion
    Post by: Iceranger on January 06, 2019, 08:48:45 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 06, 2019, 09:54:29 AM
    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.

    Yes, that is necessary. I've added it.
    Title: Re: C# Aurora Changes Discussion
    Post by: chrislocke2000 on January 06, 2019, 10:12:37 AM
    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? 
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 06, 2019, 10:51:56 AM
    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 :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Whitecold on January 06, 2019, 11:34:08 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 06, 2019, 11:51:14 AM
    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.

    Not yet. There is an automated design for jump tender and I did make a start on this code but I ran into some issues. I've left it for now but I plan to go back and finish it at some point. The AI does have jump ships now but they are with fleets, not acting as independent tenders.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on January 09, 2019, 01:17:06 PM
    Frigusium is my new favourite word.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 09, 2019, 01:40:29 PM
    Frigusium is my new favourite word.

    Unfortunately I can't take credit :)

    http://aurora2.pentarch.org/index.php?topic=8497.msg100134#msg100134
    Title: Re: C# Aurora Changes Discussion
    Post by: Kelewan on January 10, 2019, 04:20:24 PM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 10, 2019, 05:57:56 PM
    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?

    Yes, that is a good idea. You can see it on the system view window, but probably needs to be on the pop summary as well.
    Title: Re: C# Aurora Changes Discussion
    Post by: Desdinova on January 10, 2019, 06:59:05 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: BAGrimm on January 10, 2019, 09:01:44 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Barkhorn on January 10, 2019, 09:37:47 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: MarcAFK on January 10, 2019, 10:17:21 PM
    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.
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: The Forbidden on January 11, 2019, 12:51:16 AM
    Quote from: MarcAFK link=topic=8497. msg112035#msg112035 date=1547180241
    Quote from: Barkhorn link=topic=8497. msg112034#msg112034 date=1547177867
    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.
    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.

    "All of your fuel are belong to us" XD

    I always thought the invaders were extra galactic and not from the Aether though.  Oh well, I might have just played too much AI War lately ^^.
    Title: Re: C# Aurora Changes Discussion
    Post by: The Forbidden on January 11, 2019, 12:52:59 AM
    Quote from: Barkhorn link=topic=8497. msg112034#msg112034 date=1547177867
    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.

    Yes, but once we have that, why shouldn't we have ringworlds, Dyson swarms, ect ? I think the scope of such an engineering project is far, far beyond that of which is possible in the game.  Or at least that's my opinion.
    Title: Re: C# Aurora Changes Discussion
    Post by: The Forbidden on January 11, 2019, 12:54:26 AM
    Quote from: BAGrimm link=topic=8497. msg112033#msg112033 date=1547175704
    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.

    Like making nebulas noticeably richer than other systems in TN materials ? That would nicely compensate for the slow moving ships and all.
    Title: Re: C# Aurora Changes Discussion
    Post by: Tree on January 11, 2019, 02:23:31 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 11, 2019, 03:29:59 AM
    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.

    It's not a problem at the moment since I haven't coded them yet :)

    I will add a No Nebula option when I do code them.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 11, 2019, 03:30:35 AM
    Quote from: BAGrimm link=topic=8497. msg112033#msg112033 date=1547175704
    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.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: TMaekler on January 11, 2019, 04:29:23 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on January 11, 2019, 05:02:52 AM
    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.

    Yes, in the sense that there is an 'Add Nebula' button as well as an 'Add System' button.  Otherwise, there is an increased chance that any system adjacent to a Nebula system is also a Nebula system.

    In VB6 Aurora, I mean.  As Steve mentioned above, there are no nebulae in C# Aurora yet.  #:-[
    Title: Re: C# Aurora Changes Discussion
    Post by: TCD on January 11, 2019, 12:14:26 PM
    Love the new genetic techs Steve, you clearly really want your space marines! And it suddenly makes all those previously meh bio researchers much more interesting.
    Title: Re: C# Aurora Changes Discussion
    Post by: The Forbidden on January 11, 2019, 01:14:30 PM
    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).
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 11, 2019, 01:46:26 PM
    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).

    NPRs may invade worlds, depending on the situation. NPRs do have the full range, including STOs, tanks and artillery. The swarm does have some capabilities that non-Swarm don't have.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on January 11, 2019, 03:34:42 PM
    Some musing on the genetically enhanced soldiers.

    You'll almost always want them in heavy power armor - you're paying more for the extra hp than you would pay for the extra armor, and there aren't really many situations where the hp is better (Heavy crew served anti-personnel being the most notable exception, but light bombardment is the other way around so it kind of cancels out), so it makes sense to increase the cheaper armor first.

    So I expect if you use genetically enhanced infantry, you want space marines - 2x hp 2x armor, once you have all the genetic engineered infantry tech. You'll be paying five times as much for one as for an unarmored infantry, but you'll get extremely high resistance to small arms. This makes them a natural for boarding combat, since there you'll probably be mostly worried about light personal weapons from the crew.

    Doing the math, assuming near equal tech the most efficient weapons against space marines would be light anti-vehicle or medium autocannons (both get the same kills per ton of weapon). Still decent counters are, in descending efficiency, heavy bombardment, light autocannon, Medium bombardment & Heavy Crew Served anti-personnel, and then heavy autocannon. Basically you pay 5x as much for infantry that are extremely resistant to light weapons but still take the same losses to anti-tank or heavy weapons - not a bad deal.
    Title: Re: C# Aurora Changes Discussion
    Post by: DEEPenergy on January 11, 2019, 04:10:54 PM
    That makes them pretty ideal for boarding as you get stronger troops for the same tonnage, a heavily genetically modified solider in heavy armor with an anti personnel weapon is going to devastate an unprepared crew.
    Title: Re: C# Aurora Changes Discussion
    Post by: Barkhorn on January 11, 2019, 05:25:13 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on January 11, 2019, 06:09:24 PM
    Except that you are shoving the same amount of bodies around. Sure, they're expensive, but with double the armour and HP and a good anti personnel weapon vs half armoured, standard HP and LPW equipped crewmen they stand a much better chance of successfully taking the enemy vessel.

    And remember, boarding training may render them more expensive, but it also increases their chances of landing safely.

    Those conscripts of yours won't even touch the hull.
    Title: Re: C# Aurora Changes Discussion
    Post by: BAGrimm on January 11, 2019, 07:17:31 PM
    Quote from: Steve Walmsley link=topic=8497. msg112042#msg112042 date=1547199035
    Quote from: The Forbidden link=topic=8497. msg112039#msg112039 date=1547189666
    Quote from: BAGrimm link=topic=8497.  msg112033#msg112033 date=1547175704
    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. 

    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.

    Cool, well at least it wasn't a totally crazy idea.  I have yet to run across any nebulae in my games, so this was something I was unaware of.  Thanks for the great game Steve!
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on January 11, 2019, 07:43:22 PM
    Are you playing with real stars on? You won't find nebulae if you do. Nor black holes.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on January 11, 2019, 08:29:11 PM
    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.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: The Forbidden on January 11, 2019, 08:39:41 PM
    Quote from: Bremen link=topic=8497. msg112076#msg112076 date=1547260151
    Quote from: Barkhorn link=topic=8497. msg112067#msg112067 date=1547249113
    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.

    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.

    And that's not even taking into account if you really need to capture that ship but taking it isn't guaranteed.  Plus it should be done faster.
    Title: Re: C# Aurora Changes Discussion
    Post by: BAGrimm on January 11, 2019, 09:41:27 PM
    Quote from: Garfunkel link=topic=8497. msg112074#msg112074 date=1547257402
    Are 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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on January 11, 2019, 11:24:11 PM
    Quote from: Garfunkel link=topic=8497. msg112074#msg112074 date=1547257402
    Are 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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Froggiest1982 on January 12, 2019, 12:52:06 AM
    Quote from: Garfunkel link=topic=8497. msg112074#msg112074 date=1547257402
    Are 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 agree, I personally have a preferred star system naming method, where the not important systems are named based on the number of jumps from Sol and where I set it on the map (or closest Developed System later on). So I have Sol then Nsol101, Ssol101 etc.. in this way when I have to set up routes I just need to remember the 3 or 4 critical Systems and work my way back to Zero.
    Title: Re: C# Aurora Changes Discussion
    Post by: MarcAFK on January 12, 2019, 01:08:13 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Kurt on January 12, 2019, 08:07:01 AM
    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.

    I do too, for the same reason.  In my current campaign I screwed up during the setup phase and deselected "Real Stars".  By the time I realized that it was too late to fix it, so I've run with what I picked.  The "San Francisco" system doesn't have the same ring as the Arcturus system, though. 

    Kurt
    Title: Re: C# Aurora Changes Discussion
    Post by: Jovus on January 12, 2019, 10:29:42 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on January 12, 2019, 11:08:50 AM
    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.

    Which would be 'Real Stars' off and then 'Classic Stars' for the system naming theme.*


    *I don't think there is a 'Classic Stars' system naming theme in base Aurora, but at least one person has created one for their game.
    Title: Re: C# Aurora Changes Discussion
    Post by: Tree on January 12, 2019, 11:49:18 AM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 12, 2019, 12:30:54 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on January 12, 2019, 03:23:28 PM
    Perhaps you have multiple shuttles working together to lift heavy cargo to orbit.

    Only your imagination (or the self-imposed rules of your story) are the limit here.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on January 12, 2019, 05:16:48 PM
    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?

    There's plenty of preparatory work that can be done on the ground. Having that 2500 ton engine built in the shipyard means that the shipyard has to haul up all the materials, smelt and shape them and then fit them together. If you have your construction factories do the work most of the components will be prefabricated on the ground and shipped to the shipyard, where the only thing the shipyard will need to do is put them together in the mountings.

    Or, you know, it's not an actual 2500 ton engine but a 2500 ton engine array made up of multiple 500 ton or less engines that can be hauled up, making use of part commonality and carefully calibrated exploitation of Aetheric physics to gain that wonderful fuel efficiency boost. Unfortunately, while it means that they're also rather resistant to damage as a side effect, if one of the engines goes, the rest of them also get destroyed in sympathetic detonations and other stresses that they're unable to cope with as a result of the compromises that were struck for that efficiency boost.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on January 12, 2019, 05:20:40 PM
    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.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: drejr on January 13, 2019, 01:02:40 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Desdinova on January 13, 2019, 03:28:00 AM
    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.

    I like thermogen/cryogen gas. If you want to stick to Latin roots, maybe use calor (warmth)? Calorium.
    Title: Re: C# Aurora Changes Discussion
    Post by: Lornalt on January 15, 2019, 09:28:35 AM
    Quote from: Jorgen_CAB link=topic=8497. msg112093#msg112093 date=1547335240
    Quote from: Steve Walmsley link=topic=8497. msg112089#msg112089 date=1547317854
    Quote from: Tree link=topic=8497. msg112088#msg112088 date=1547315358
    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.

    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#
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on January 15, 2019, 10:36:22 AM
    While true currently, TN economies will have both vastly more capable lift and vastly cheaper per weight lift than modern day Earth.

    TransNewtonian physics are just crazy like that. I mean, you actually have to work to create a ship slower than 100 km/s in space, even with the lowest tech TN engine. Modern day physics can't get that fast because it's an insane speed, we simply lack the engines at this time to make that viable.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on January 15, 2019, 05:44:20 PM
    Quote from: Jorgen_CAB link=topic=8497. msg112093#msg112093 date=1547335240
    Quote from: Steve Walmsley link=topic=8497. msg112089#msg112089 date=1547317854
    Quote from: Tree link=topic=8497. msg112088#msg112088 date=1547315358
    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.

    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#


    I agree with Hazard.

    While true with modern day knowledge of physics since the energy it takes to launch something from earth into orbit is very expensive. But if the cost from hauling the thing from the surface to space is a minor one this is a moot point, we are after all talking about anti-gravity, tractor beams, space lift and the use of a "magical" trans Newtonian element to break the natural laws of physics. I would imagine the cost of lifting things up into space are roughly the same as transporting something in a shipping container and we do that for very little cost all around the Earth today.
    Title: Re: C# Aurora Changes Discussion
    Post by: Vivalas on January 16, 2019, 04:25:14 PM
    The lore is interesting, but there are a few confusing bits. 

    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?

    The terraforming section also is a bit weird.   Being able to siphon conventional materials seemingly from thin air seems like a bit of a plot hole even in a world where TN elements eclipse conventional ones.   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.

    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. 
    Title: Re: C# Aurora Changes Discussion
    Post by: Tree on January 16, 2019, 04:37:46 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 16, 2019, 04:44:11 PM
    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.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on January 16, 2019, 05:00:45 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: drejr on January 16, 2019, 06:02:36 PM
    One possibility:

    In Aurora, the superfluid vacuum theory turns out to be correct. Spacetime can be be described as a liquid with very low or no viscosity.

    In the Aether, however, spacetime is condensed to the point where viscosity greatly increases, and the Aether can be described as a more conventional fluid.

    Thrust applied in the highly condensed Aether drags normal material along like a ocean-going ship's propeller - which would give very little thrust in the atmosphere in which most of the ship exists.
    Title: Re: C# Aurora Changes Discussion
    Post by: dag0net on January 16, 2019, 07:18:35 PM
    Quote from: Steve Walmsley link=topic=8497. msg112184#msg112184 date=1547678651
    It requires billions of years for them to coalesce in gravity wells.

    /me goes starmining
    Title: Re: C# Aurora Changes Discussion
    Post by: Vivalas on January 16, 2019, 10:29:11 PM
    Quote from: Steve Walmsley link=topic=8497. msg112184#msg112184 date=1547678651
    Quote from: Tree link=topic=8497. msg112183#msg112183 date=1547678266
    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.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 17, 2019, 05:02:58 AM
    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.

    It depends whether it is more or less weird that terraformers can create entire atmospheres out of vacuum :)

    Whether consumers have the equivalent of star trek replicators for non-TN goods is outside game scope (although it would explain why food production is a minor problem) and probably easier to rationalize than terraforming in VB6. However, as someone mentioned, it is fine to use your own background/lore for your own games.
    Title: Re: C# Aurora Changes Discussion
    Post by: Rabid_Cog on January 17, 2019, 02:01:28 PM
    If all you can get from the Aether is raw elements, that could serve to explain. Pure, loose elements are kinda difficult to use. Energy states are all wrong, etc. Fine for gasses, they are loose atoms anyway (or bond on their own) but for more complex substances (especially proteins) the effort and energy required to synthesize them would make it quite difficult to use anyway. The energy calculation could still favour local 'real world' extraction and production, so you dont quite reach "post scarcity" for common goods.

    Terraformer cant pull it out because it cant REACH the TN materials. There's a planet in the way. It can only reach the higher/lighter materials. Asteroid miners work the same way but they have a long pipe attached and are configured differently to target the heavier elements. Same basic principle as a planetside mine, same way a fridge compressor and a vaccuum cleaner work on the same principles.
    Title: Re: C# Aurora Changes Discussion
    Post by: TCD on January 17, 2019, 03:05:31 PM
    Steve's Great Crusade and its use of the new factory-built space stations to get around shipyard constraints has got me thinking about what creative uses that approach opens up. One immediate thought was fuel harvester bases with a single fuel tanker base to create an easy orbital gas station.

    But now I'm wondering what else you could do. I was thinking about early game carrier stations, but I think they'd have to have the new commercial hangers rather than military hangers? That means normal maintenance applies to military ships, so tricky to make it work for fighters I'd have thought. Perhaps you could create an FAC carrier station with hybrid FACs with short ranges but decent maintenance lives.

    Obviously the no armour, no shields etc is going to make your carrier stations horribly vulnerable, but you could load them up with CIWS to protect against stray missiles, and if the enemy gets beam vessels in range of your carrier you've probably lost anyway.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on January 27, 2019, 04:12:25 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: King-Salomon on January 28, 2019, 04:49:38 AM
    about the new chances of discovering potential ground survey sites:

    I had toyed with the idea for some time and was thinking that to make the effort really worthwhile I (just my thinking) would rise the chances for minimal foundings much higher - I was thinking along

    None 30%, Minimal 50%, Low 10%, Good 6%, High 3%, Excellent 1%.

    (maybe eben low 10.5% and Excellent 0.5%)

    this would rise the number of potential sites a lot - so make the ground unit worthwhile - without the findings becomming too useful ... a lot of the minimal findings etc would still be zero (or near to it) when you roleplay your empire so that you don't only survey when the minerals you found first are depleted but as soon as you have an interest in the body (as would be realistic)...

    to make thinks easier to balance it longterm: maybe it would be possible to add a gamesetting about this?  %-chance of basic ground survey ?
    Title: Re: C# Aurora Changes Discussion
    Post by: Xkill on January 29, 2019, 12:18:11 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 29, 2019, 12:27:04 PM
    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.

    Shipyards of the same total capacity will now have the same workers, which isn't the case in VB6. It is more of a case of correcting an issue, then giving smaller shipyards a boost.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 29, 2019, 12:29:09 PM
    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.

    While looking at wealth options, I realised that shipyards were very low on pop requirement compared to other installations such as factories or research. You could create 3x more BP in shipyards than in factories for the same amount of workers, so I am correcting that. SY are still generally more productive per worker but the imbalance has been reduced.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on January 29, 2019, 03:00:11 PM
    Regarding shipyards... is this not only as long as you only have one slipway on that small shipyard versus a large one in VB6.

    A small shipyard at 6000t with two slipways produce roughly the same as a 12000t shipyard but with even lower worker required.

    So, as Steve said this is rather a correction to fit the requirement and balance and make military production over civilian or economic growth a real choice to make. Military institutions now seem to be much more expensive in general which I see as a good thing in general.

    This will make extreme specialization of military ships very expensive and something only a advanced civilization with good economy can afford unless there are no external pressures.

    Although I might wonder what the benefit of more slipways will be over just building lots of shipyards, many shipyards are way more flexible... there really does not seem to be that much to gain from more slipways or have I missed something?

    If it is only an upfront cost of building a new shipyard versus new slipways I don't think that is much of an overall cost to the benefit of more yards. There probably should be a small reduction in workers needed for every slipway you add to a yard and/or bonus to retooling costs or something versus doing the same in multiple yards. At least something to make the economically worthwhile.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on January 29, 2019, 03:16:33 PM
    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).


    . . .


    "Well Sir, we could build another dozen practically obsolete four-stackers for about half price, or we could start a flight of these new, modern destroyers with the inevitable cost-overruns and increased construction time."
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on January 29, 2019, 03:20:47 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Peroox on January 29, 2019, 03:40:39 PM
    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).

    Something like in the Swords of the Stars II ?
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on January 29, 2019, 05:27:40 PM
    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.

    There need to be some economic benefits otherwise there is only drawbacks for using them other than mouse clicks...  ;)
    Title: Re: C# Aurora Changes Discussion
    Post by: Vivalas on January 29, 2019, 07:34:02 PM
    Yeah expanding a shipyard at a certain tonnage to contain more slipways should be cheaper / faster than just building a new shipyard.  This can be easily justified, because a shipyard is more than just a collection of slipways.  There is transportation to / from, management, storage and auxiliary facilities, infrastructure, auxiliary equipment, not to mention the even higher cost of a large engineering project, from contractors to training personnel to manage the new facility and more.  Extra slipways in the same shipyard an share facilities with other already existing slipways, not to mention the lack of a high start up cost to get all the basic support stuff in place.  From a gameplay perspective it would also encourage more specialization.
    Title: Re: C# Aurora Changes Discussion
    Post by: MarcAFK on February 01, 2019, 04:55:29 AM
    Running through my old campaign with the new wealth rules one thing really sticks out at me.
    Previously a major reason to colonize, was that smaller worlds have a higher population growth which is quite reasonable, but also they're more efficient with their manufacturing industry, a 100 million person coloniy has almost double the manufacturing industry as the default 500 million earth.
    I would argue that this makes sense, as the colony has major investment being made to it, its industries are more focused, and theres little bureaucratic and social inertia moving for secondary industries, such as service and financial industries, as well as leasure, recreation, etc. They're just more efficient and you're not going to waste major resources moving people who aren't immediately employable into those colonies.
    But with the new wealth mechanics now those smaller colonies also represent a significantly higher potential income, you could double your tax revenue, but you do still need to have the facilities available to take advantage of this.
    I was a bit concerned at first, but it makes sense, if the people out there are in fact focused in manufacturing in a purely efficient manner than it stands to reason there should be economic benefits to making good use of the industry sent out.
    Something else I noticed is that if I'm not mistaken construction factories produce half what they cost to run, and mines produce the same amount but cost nothing to run.
    This means as long as you have enough mines your economy is pretty safe, also when earth inevitably runs out of minerals you'll still have the income from the mines even with no useful TNE production, I could assume they're still mining valuable non TNEs for the civilian economy.
    Of course leaving those mines in place is just inefficient in respect of the wasted mining potential but its nice to know that just like CMC's on almost depleted worlds they're still useful for income.
    The more I look at the numbers the more I like the potential these changes has.
    Title: Re: C# Aurora Changes Discussion
    Post by: Iceranger on February 01, 2019, 10:08:14 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: iceball3 on February 01, 2019, 05:49:08 PM
    That said, commercial vessels are mildly balanced out by the fact that they incur no maintenance or wealth related costs through their lifespan.
    We could also pan this out to perhaps the higher wages of naval ship manufacturers due to the more intricate fail-vulnerable systems involved than commercial vessels, that and commercial vessels tend to build much faster per ton (usually, due to engine and commercial component cost densities)
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on February 01, 2019, 06:57:42 PM
    In some sense, this means military yards are cheaper to run than commercial yards, wealth wise. This sounds a bit strange to me.

    Well, they're still more expensive per ton. Just not ten times more expensive.
    Title: Re: C# Aurora Changes Discussion
    Post by: MarcAFK on February 01, 2019, 07:20:12 PM
    It seems to me like military factories should only take workers and produce wealth when in operation. Industrial buildings like factories, mines, refineries etc are assumed to be running constantly at full output and even if they aren't producing something immediately required for 'the empire' they're still contributing to the economy.
    But idle shipyards would be a major drain on resources, not a potential cash cow, you shouldn't be able to make huge wealth just by leaving a commercial shipyard on continual expansion and simply not make ships.
    Actually using that shipyard for commercial ships would understandably have a significant effect on the economy of course.
    Other factories like ordnance, GFTF, fighter factories, etc should also only take workers and produce wealth when in operation, but shipyards are an absolutely major factor.
    Also I don't know what to say about the imbalance between military and commercial manning requirements, it's strange, but it should definitely balance out if idle shipyards stop producing wealth.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on February 01, 2019, 09:12:29 PM
    To be honest I don't see the reason why population itself should generate wealth at all, I would let certain production types generate a modest amount of wealth such as factories could generate some wealth as well as production. But most facilities should basically be net loss.

    Wealth should then come from Financial Centers, Civilian trade and Civilian mining complexes and fuel harvesters.

    This would make it more clear...

    So you have to use wealth to keep most of the facilities going while Factories don't cost Wealth but give you a small amount and some production... all other facilities cost wealth to operate based on what they produce.

    Workers should then cost Wealth not giving wealth, wealth is something population consume not produce, at least that is the way I see it. You can easily disreard the civilian sector and just assume that is a zero sum games, but the working portion of the economy should cost wealth whether they are employed or not. Tha would give you an incentive to make sure as many in your population work instead of being unemployed.

    Just some example

    Financial Center = Base wealth of 50 times tech level
    Factories = 5 wealth per production point (also make conventional factories generate very little wealth)
    Everything else cost wealth based on production (can vary depending on a what it is)
    Each 10000 worker population (not civilian pop) cost 1 Wealth times the same tech level that Financial centers are modified with (people will tend to need more wealth as technology rises)

    I would also add in a small Wealth cost for operating Commercial ships based on some formula on their production cost. Something you pay like you pay everything else. Nothing should ever be completely free. This is basically the salaries for the crew and maintenance the ships need over time.

    This was just an example... I did not really look at the numbers in the current game or anything or if these are workable at all.

    This would in my opinion be a more simple system that also make lots of sense.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on February 01, 2019, 09:17:05 PM
    That might be a discussion best had in the wealth generation thread.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 02, 2019, 10:06:43 AM
    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.

    Yes, that is true. It is because of the disparity between the commercial - naval split in workers (1 vs 10) and the commercial naval split in build speed (1 vs 4) . I could change this in a few ways:

    1) Slowing down commercial building, which I don't really want to do because it seems about right,
    2) Increasing naval building rates, which I don't want to do for the same reason.
    3) Increasing the population requirement for commercial shipyards. May be too much because the changes to shipyard workers have already increased overall requirements
    4) Decreasing pop requirements for naval shipbuilding (which I just increased).
    5) A combination of 3+4 to keep the total requirements similar

    However, having said all that, I think the current situation is probably fine. Military ships have a much higher lifetime cost due to maintenance requirements while many commercial ships are improving the overall economy.
    Title: Re: C# Aurora Changes Discussion
    Post by: IanD on February 06, 2019, 02:19:49 PM
    In an old AAR conventional start I abandoned a couple of years ago waiting for V7.2 I started surveying Sol using a size 20 or 24 missile equipped with a geosurvey module launched from a PDC. Is there any way now to replicate Cape Canaveral? With the demise of PDC I cannot see one but I have not followed the entire C# discussion.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on February 06, 2019, 04:14:52 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: The Forbidden on February 06, 2019, 06:52:48 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on February 07, 2019, 02:47:41 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: The Forbidden on February 07, 2019, 06:14:38 AM
    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.

    FAC survey missile platform ? I like the idea. Though it'll probably cost more than a proper survey ship in the long run.
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on February 08, 2019, 12:32:47 AM
    I guess I could see it if a system had enemy ships passing through periodically and you wanted to launch a bunch of low observable survey missiles then bug out with the actual ship.
    Title: Re: C# Aurora Changes Discussion
    Post by: Zincat on February 08, 2019, 12:19:17 PM
    Thanks for the latest change. I have always wondered why fuel storages were so expensive. I had assumed it was a deliberate choice, and I was not happy about it.

    It's mcuh better this way  ;D
    Title: Re: C# Aurora Changes Discussion
    Post by: misanthropope on February 10, 2019, 09:15:45 AM
    if you're gimping auto-mines *and* asteroid mines, you're making asteroids considerably more player-intensive- and they're already conspicuously high on the ol' clicks-per-unit-reward metric.  i exploit asteroids in 7.1, but if i couldnt just throw capital at them, they would be nothing but a visual noise and processor slowdown.

    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on February 11, 2019, 12:14:50 PM
    What is gimping auto-mines and asteroid mines? I haven't seen Steve post any changes to them.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 11, 2019, 04:09:27 PM
    What is gimping auto-mines and asteroid mines? I haven't seen Steve post any changes to them.

    I haven't posted any changes to automated mines. Asteroid mining modules (now orbital mining modules) have gained a major advantage due to the space station changes, plus they can be used for moons as well. The new downside is the maximum diameter for mining which will take some asteroids out of reach until tech improves.
    Title: Re: C# Aurora Changes Discussion
    Post by: JacenHan on February 11, 2019, 04:59:18 PM
    I think he meant to post that in the power generation topic.
    Title: Re: C# Aurora Changes Discussion
    Post by: misanthropope on February 11, 2019, 06:31:16 PM
    sorry for sowing confusion, lost track of where each thread originated.
    Title: Re: C# Aurora Changes Discussion
    Post by: Lamandier on February 12, 2019, 09:50:52 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: The Forbidden on February 13, 2019, 03:12:01 AM
    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.

    What's next ? Apollo FTL telemetry links ? ^^

    But yeah, that's a valid point, personally I prefer one big station however, but it's just a matter of taste, as a nebulous complex of smaller structures makes more sense than one big station.
    Title: Re: C# Aurora Changes Discussion
    Post by: MarcAFK on March 02, 2019, 05:11:46 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on March 02, 2019, 05:46:50 PM
    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.

    Its reduced by 75% for Earth-size vs VB6 and reduced about 10% for Mars-size. It is faster for small planets and moons. There is the extra consideration of water now as well so the overall task will be larger if that doesn't exist.
    Title: Re: C# Aurora Changes Discussion
    Post by: MarcAFK on March 03, 2019, 06:16:25 AM
    Oh, my mistake, I always get mixed up when percentages are used that way :s.
    That's about in line with the speed I was thinking they could be reduced by, someone else suggested that perhaps adding a fuel cost to terraforming might help to prevent excessive use of terraformers, it would be interesting to have to consider the long term running costs rather than just the upfront cost of producing the terraformers, plus manning requirements.
    Title: Re: C# Aurora Changes Discussion
    Post by: TMaekler on March 04, 2019, 06:47:11 AM
    In regards to the recently changed value for manufactung / service sector percentage: maybe adding an additional race parameter which allows different races to have different needs for service might be a handy addition. Some races don't need so many entertainment centers as other - and those people could work in the military construction sector. Or a race is generally more militaristic and demands people to work more in that sector.
    Title: Re: C# Aurora Changes Discussion
    Post by: Xenotrenium on April 10, 2019, 04:08:30 PM
    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
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on April 10, 2019, 05:56:20 PM
    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

    Thanks. I've added a check to the class design code to ensure a class cross-section is never below the minimum possible value of 0.33 HS.
    Title: Re: C# Aurora Changes Discussion
    Post by: MarcAFK on April 10, 2019, 07:09:58 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: DIT_grue on April 11, 2019, 02:45:26 AM
    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.

    If you can reduce a missile's cross-section that far, you've got a bug that's going to show up a lot more often than this one. Remember when the MCR and so on were added, so that any missile 6MSP or less was detected at the same range?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on April 11, 2019, 03:25:24 AM
    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.

    Missiles can be 0.05 HS in size, but their cross-section for detection is a minimum of 0.3 HS (0.33 in C#).
    Title: Re: C# Aurora Changes Discussion
    Post by: Tree on April 11, 2019, 04:26:16 AM
    Since we're onto thirds, do 33% reduced size launchers work properly in C# ? In VB6 with for example size 3 or 4 launchers, you end up with launchers that have a crew requirement of 0, even though the 25% version has a crew requirement of 1. Kinda annoying, 33% sounds perfect to me, but using them feels like cheating because of the reduced crew size.
    Title: Re: C# Aurora Changes Discussion
    Post by: MarcAFK on April 11, 2019, 04:56:18 AM
    Is there a reason why missile detection is capped at 0.3 HS rather than being able to get down to 0.05?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on April 11, 2019, 05:03:17 AM
    Is there a reason why missile detection is capped at 0.3 HS rather than being able to get down to 0.05?

    To balance the range at which you can detect missiles with the rest of the sensor model. The other option would be a sub-resolution 1 sensor.
    Title: Re: C# Aurora Changes Discussion
    Post by: TheRowan on April 15, 2019, 02:06:40 AM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: DIT_grue on April 15, 2019, 02:21:23 AM
    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?

    This has been raised several times, and it seems the only problem is that Steve doesn't remember to say so. For example:

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on April 15, 2019, 03:27:39 AM
    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?

    Yes, that's correct.
    Title: Re: C# Aurora Changes Discussion
    Post by: Darkminion on April 17, 2019, 10:50:48 AM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on April 17, 2019, 11:41:17 AM
    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?

    Yes, like a jump gate in VB6 Aurora.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on April 17, 2019, 02:30:39 PM
    While I don't like when AI plays by different rules compared to a human, I can understand the need for that separation - JP assaults are difficult and dangerous enough as they are.
    Title: Re: C# Aurora Changes Discussion
    Post by: MarcAFK on April 17, 2019, 06:26:12 PM
    As a placeholder pending more work on the AI its completely fine.
    Already the new AI now has to deal with a ton more stuff it was getting free passes on back with VB.
    Title: Re: C# Aurora Changes Discussion
    Post by: MJOne on April 24, 2019, 02:33:07 PM
    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. . .
    Title: Re: C# Aurora Changes Discussion
    Post by: amram on April 24, 2019, 11:39:31 PM
    ^^ So much yes.

    This would allow solving things like tankers dropping fuel in very inopportune places, or requiring me to intervene personally.  Instead I could save the correct template, collect fuel/ores from ship/colony and deliver to specific colony, perhaps not even in the same system.

    That it would be case by case is a small nuisance of micro, to gain a huge savings in ongoing micro that no longer needs to occur.

    You could give those same ships a run like hell order chain that is direct path to the nearest maintenance yards, a place your likely to have warships, triggered via detected hostiles.
    Title: Re: C# Aurora Changes Discussion
    Post by: JustAnotherDude on April 30, 2019, 05:06:48 PM
    Really like the missile engine change, it'll make designing the bastards so much easier.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on April 30, 2019, 05:38:29 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on April 30, 2019, 06:20:39 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: mtm84 on May 01, 2019, 02:36:04 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on May 01, 2019, 03:42:20 AM
    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.

    That is good to hear... will we also now see the Delay order in the order queue... this I think would make it more transparent?

    It can otherwise be hard to remember where and how much of a delay you ordered.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on May 01, 2019, 03:48:12 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on May 01, 2019, 03:50:29 AM
    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.

    If it is not to complicated for you I think you should just skip max size of missile engines. Large missiles need all the help they can get so being able to get more range in larger missiles can be a good thing in my opinion.
    Title: Re: C# Aurora Changes Discussion
    Post by: chrislocke2000 on May 01, 2019, 06:28:19 AM
    On the subject of additional orders, as well as having the transit and divide TG order it would be great to have a transit and detach survey craft order. This would be a quality of life improvement where you are sending tenders to support survey craft and provide the jump capability.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on May 01, 2019, 07:54:14 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on May 02, 2019, 04:55:04 AM
    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.

    You no longer pay research costs for the engine, because of the complexities you mentioned above.

    I'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 :)
    Title: Re: C# Aurora Changes Discussion
    Post by: chrislocke2000 on May 02, 2019, 08:54:05 AM

    [/quote]

    I'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 :)
    [/quote]

    Cripes does that mean the 5th Campaign start is inbound? Hopefully a multi faction start gives more of a chance for some ground combat!
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on May 02, 2019, 09:23:36 AM
    Quote
    I'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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Whitecold on May 02, 2019, 11:30:16 AM
    Quote
    I'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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on May 02, 2019, 11:42:44 AM
    Almost a bit disappointing to see this campaign end, most of the starts look quite appealing, and leave me wanting for more.

    Yes, me too. I am enjoying the current campaign, but the Swarm grav survey ships (another new addition) are exploring in a different direction, so unless the Royal Navy shows the way, that contact is broken for several years. Building up without an immediate threat will be interesting but not useful from a testing POV. I might come back to the same general idea for another campaign in the future though.

    Creating the setup for the new campaign has highlighted a few bugs, so that has already been a useful exercise.
    Title: Re: C# Aurora Changes Discussion
    Post by: Vizzy on May 04, 2019, 04:47:07 AM
    Quote from: Steve Walmsley link=topic=8497. msg114173#msg114173 date=1556807016
    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. 

    Hi Steve

    I've had a realitively simple idea in the back of my mind for a while now but your post prompted me to post it to the suggestions thread.   It's a (realtively simple to implement, I hope) way of making races/campaigns different while also aiding roleplay.   It's done by making Research less predictable and more varied:

    Quote from: Vizzy link=topic=9841. msg114223#msg114223 date=1556962755
    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. 

    Wasn't sure how to link to the suggestion, happy to change the quote to a link if anyone wishes. 
    Title: Re: C# Aurora Changes Discussion
    Post by: MJOne on May 07, 2019, 08:29:22 AM
    To build on this idea, since the implemetation of research has not changed alot since the 90s in games, why not actually make racial design companies that have a +/- bonus for each research category affecting the values of each technology? (Design Techs)

    Companies should be generated at start

    Company ”Not So General Motors”:
    Power and propulsion +10% =
    10% more power
    10% less fuel consumption
    10% less size (can be a problem with NPR designed ships)

    Company ”Never A Straight Answer”:
    Missile and kinetic +20% =
    20% less missile cost
    20% more missile manouver rating

    Etc etc

    Company bonuses could change over time due to XYZ. (RP messages)

    Just a thought


    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on May 07, 2019, 11:21:18 PM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on May 07, 2019, 11:42:00 PM
    It would be kindof cool if you could solicit bids from corporations to supply you with equipment, then pick your most preferred option.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on May 08, 2019, 12:06:46 PM
    It would indeed but the system would have to be robust so that if I play with a non-human and/or non-capitalist faction, other possibilities are still available on how to conduct research/prototypes.
    Title: Re: C# Aurora Changes Discussion
    Post by: MJOne on May 08, 2019, 11:34:30 PM
    Quote from: Father Tim link=topic=8497. msg114310#msg114310 date=1557289278
    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?

    Well, I am not sure the best way to implement this without cheezy human players and ”stupid” AI.
    I only think that every company in the Universe designing the exact same engine with the exact same stat is silly.  But its convinient from a programming perspective.

    Improvements over time could solve bad designs.  That you have to invest alittle extra credits and materials to get a second roll on the bonus stats on an already researched design tech. 

    I just want to see variations.

    NPR companies should also be ”spyable” and perhaps even absorbed after an invasion. 
    Like operation paperclip. . . . 

    Just thinking out loud.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jovus on May 10, 2019, 10:46:01 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on May 10, 2019, 11:55:12 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on May 10, 2019, 07:51:54 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jovus on May 11, 2019, 04:41:44 AM
    IIRC, the tug jumps fine when it's not pulling the station, but not with.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on May 11, 2019, 05:32:39 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on May 13, 2019, 09:48:18 AM
    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.

    I then assume that if a 10.000t Tug with commercial engines tractors a 20.000t military ships with military engines you would need a jump ship that can jump at least 20.000t of military engines if you don't have a gate at the jump point.

    To be honest I don't remember the full rules for jumping ships. But I assume that you can jump a military ship even with a commercial jump drive just not make a combat jump with it?

    I mean there are or should not be much difference in jumping something that has its engines turned of or a base with no engines at all, so as long as the size match then any jump drive should be able to jump any ships, right?!?

    Or was it not the case that you could not jump a base with no engine at all... I think there was problems with this or did this require a military jump drive?
    Title: Re: C# Aurora Changes Discussion
    Post by: Erik L on June 15, 2019, 02:16:59 PM
    So Rakhas = Space Orks. :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on June 15, 2019, 02:27:02 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on June 15, 2019, 02:59:15 PM
    My gut feeling is they're going to be pretty easy to bombard down. Either with missiles from outside STO range or with beam weapons if their STO fire isn't too heavy. Collateral damage isn't a big threat when there's nothing on the planet, and radiation and dust will have time to settle out.

    This isn't necessarily bad, though, as they still present an interesting new challenge (and I expect they'll give us an early taste of ground combat in one of Steve's stories, which I've been hoping to see :D). Perhaps if bombarding them is too easy it might be worth adding some sort of bonus for dealing with them on the ground, like ruins or some sort of bonus tech that gets damaged by orbital bombardment.

    I assume that for them to still have ground units around (especially with no matching civilian population) they probably have an auto-factory or something pumping out high tech laser guns; might be interesting if conquering on the ground left you with a special ground force training center that slowly produced high tech infantry units. I'd say a stockpile of ground weapons instead but if I understand the system right it doesn't actually support ground troop equipment separate from actual ground units.

    So Rakhas = Space Orks. :)

    I remember the Dahak series had a planet that had regressed to primitive technology after the space empire collapsed, but built a religion around worshiping the self-repairing technology (including a planetary defense system) that was still around. I'm kind of picturing it as something like that, except with aliens instead of humans.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on June 15, 2019, 06:03:42 PM
    So Rakhas = Space Orks. :)

    :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on June 15, 2019, 06:31:16 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: JustAnotherDude on June 15, 2019, 07:05:41 PM
    Damn, I knew it would be harder to just outright destroy ground forces but that really underlines it. I'm excited for these guys, they'll give me a reason to start developing my lift capability way quicker.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on June 15, 2019, 08:53:06 PM
    Also, you need to replace the missiles

    I've just realized that I'll now have something to do with my stockpiles of old obsolete missiles. Though the radiation in particular is a good reason not to go too bombardment crazy, they'll still be decent for softening them up.
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on June 15, 2019, 09:11:07 PM
    Ah, just tow a bunch of habitats in to keep the mines running and its all good.

    e: Unless they cant maintain the mines regardless, which seems somewhat unfair.  Surely they could just jaunt down briefly in heavy radiation gear to fix things then go back up.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on June 16, 2019, 01:44:51 AM
    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.

    Except you forgot one thing. The moment temperatures drop below 25C the dominant terrain for the planet will be rerolled, and all other terrains now potentially on the table are less punishing for orbital bombardment, ranging from a Fortification 2.5 and To hit 0.25 modifiers (Forested Mountain) as a worst case reroll for the attacker, to the Fortification 1 and To Hit 1 modifiers of Steppe, Praerie and Tundra. That is the real reason you do a general bombardment; to get rid of stackable modifiers or at least mitigate them, and get your own troops in a more favourable environment. I mean, who cares it's now a -20C or worse radioactive hellhole when your troops are no longer stuck in the jungle with extreme temperature training but no jungle combat training and your enemy now has the exact opposite problem and can't stack his defensive bonuses as high.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on June 16, 2019, 05:20:38 AM
    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.

    Radiation affects production, regardless of whether you use automated mines or the population is in orbital habitats. That is true in VB6 as well. The only mining method that is unaffected is orbital miners, but they have a planetary size limitation in C#. So you can massively irradiate the planet to kill the ground troops, as long as you don't plan to use the surface of the planet afterwards.

    You can use energy weapons, but they only shoot at one soldier at once, rather than the 150 per 9-point warhead, and your base chance to hit before fortification and terrain is 7% compared to 100% for a nuke. They are much more useful in supporting ground troops than trying to pick off individual soldiers from orbit. You could theoretically do it given enough time and maintenance supplies (weapons malfunction in C#), but I doubt it will be economically viable. Again, this assumes the ground forces aren't shooting back.

    C# mechanics are designed to make ground combat a real option, even the preferred option in many cases. You can still choose to wipe out ground forces and populations from a distance but that option is much more costly than before in economic and environmental terms. With some ground forces vs naval forces, it might not even be a viable option.

    As for deliberately creating a nuclear winter to kill all the trees, that is a creative solution but you still have the environmental problems as a result. BTW Forested Mountain survives all the way down to -50C. It would be easier and cheaper to send in your own ground forces, which is all the new rules are trying to achieve.

    Finally, you reminded me that I forgot to include terrain fortification modifiers in my original example. The infantry should have been at 6.75 fortify (3x inherent * 2.25 for terrain), so only 3 infantry would have been killed per warhead, not 7. 3270 9-strength warheads would have been needed, not 1450. 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.
    Title: Re: C# Aurora Changes Discussion
    Post by: clement on June 16, 2019, 07:51:26 AM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Jovus on June 16, 2019, 08:08:36 AM
    Gotta keep those troop numbers (and morale) up somehow.
    Title: Re: C# Aurora Changes Discussion
    Post by: Rich.h on June 16, 2019, 09:02:34 AM
    How about them having access to tech locked facilities, these will be exceptionally good at what they do but only avalible via capture, similar to things like plasma torpedoes & ultra compressed fuel tanks etc. Gives yet another reason not to go crazy with the warheads from space.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on June 16, 2019, 01:46:33 PM
    *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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jovus on June 16, 2019, 02:06:20 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on June 16, 2019, 04:17:34 PM
    Infrastructure cost on low to zero colony cost planets is negligible by design. Part of it though is the simple fact that any event which increases colony cost also increases infrastructure investment requirements, which means that if colony cost swings widely enough you will see a population collapse. And colony cost can swing to 'effectively infinite.'
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on June 17, 2019, 06:19:14 AM
    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?

    LOL. I guess the fornication modifiers are linked to pop growth :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on June 17, 2019, 06:22:13 AM
    *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.

    I can see that we aren't going to reach agreement on this :)

    I think it would be best if we resumed the discussion after you have had chance to play with the game. And no, I don't know when that will be :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Person012345 on June 17, 2019, 10:05:55 AM
    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?
    It's just what happens when the slaaneshi worshippers arrive.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on June 17, 2019, 11:26:45 AM
    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.
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Shuul on June 17, 2019, 02:29:44 PM
    Can anyone clarify a bit to me if missiles will have more or less range/utility in C#? I never used missiles except short range torpedoes and bombs and they always seemed to me a bit OP compared to short ranged energy weapons. Will C# have a better balance between missiles and guns?
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on June 17, 2019, 02:50:44 PM
    Well, missiles will no longer be able to avoid point defense if they hit within a single move increment, so they won't be over powered at point blank ranges anymore.  The fuel & engine changes are *supposed* to make it much more of a choice between speed & range, but we'll have to wait until we get our pseudopods on C# Aurora to know for sure.
    Title: Re: C# Aurora Changes Discussion
    Post by: Peroox on June 17, 2019, 03:12:05 PM
    Also no armored missile and some other changes in missile design (like ECM/ECCM).

    I will miss my fire plan with few specialised missile type (like salvo of armored decoy and then next salvo with high dmg missile).
    Title: Re: C# Aurora Changes Discussion
    Post by: Shuul on June 17, 2019, 06:30:11 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on June 17, 2019, 06:38:25 PM
    Big, slow missiles will be easier to shoot down.  Armoured missiles were removed because they were too good. . . at least against the computer.  Hopefully Aurora's AIs will improve to the point where we can have them back.*

    - - -

    *Because I would like missiles to function properly in nebulae (which, for the record, are also gone from 1.0 C# Aurora) -- which means non-armoured missiles are detroyed immediately upon launch, and armoured missiles have their speeds properly reduced by the nebula like ships do.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jovus on June 17, 2019, 07:11:41 PM
    I personally really like the concept of armoured missiles, but I definitely agree they really need some heavy work as far as the execution is concerned.
    Title: Re: C# Aurora Changes Discussion
    Post by: Person012345 on June 17, 2019, 11:35:11 PM
    You can of course do the MIRV thing and have big slow easy to kill missiles that break up into many small fast hard to kill missiles before they reach the PD.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on June 18, 2019, 03:26:09 AM
    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.

    Larger missiles can include ECM (the new version), which makes them harder to hit.
    Title: Re: C# Aurora Changes Discussion
    Post by: vorpal+5 on June 18, 2019, 05:50:50 AM
    Oh, I missed this part. So missiles can't be armored anymore? I liked this part!
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on June 18, 2019, 06:08:07 AM
    Oh, I missed this part. So missiles can't be armored anymore? I liked this part!

    This post is on the missile changes

    http://aurora2.pentarch.org/index.php?topic=8495.msg103096#msg103096

    Changes to missile engines, which increase fuel consumption, especially at higher multipliers

    http://aurora2.pentarch.org/index.php?topic=8495.msg102804#msg102804

    Missile Thermal detection changes - combined with the sensor changes this means missiles will often be detected on thermal before active.

    http://aurora2.pentarch.org/index.php?topic=8495.msg103478#msg103478

    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on June 18, 2019, 07:15:13 AM
    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. If nothing else it does slowly become a little cheaper as technology escalates, if through no other reason than the fact that as technology improves so does the ground side collateral damage rating increase, with the concurrent increase in planetary dust levels.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jovus on June 18, 2019, 11:21:57 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: swarm_sadist on June 18, 2019, 05:21:05 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: JustAnotherDude on June 18, 2019, 08:33:09 PM
    I think large ground battles are inevitable tbh, I don't think that being unable to pay maintenance on your ground units disbands them so they'll just sit their, waiting for your to come down and take their stuff. I think that beam based bombardment, perhaps even with STOs on nearby moons, will become a common strategy, however, as they cause much less environmental and structural damage.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on June 18, 2019, 09:57:21 PM
    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.

    On the other hand, the economic gain from taking a major colony, let alone a homeworld, is absolutely immense, so I think there's a balance there - spend massive amounts on a ground invasion and gain an intact economy, bombard it and just gain a mostly empty world, or some combination of the two.
    Title: Re: C# Aurora Changes Discussion
    Post by: Peroox on June 19, 2019, 01:26:59 PM
    If only in game will have matter of food supply or trade goods shortage, then siege are worth. That could be to complex but still wealth is something.

    If planet have low fertility then will "have to" import food via civil lanes and that's mean than attacker can make population (and army) starve. Less impact with trade goods shortage that could make unrest on higly populated word. 

    Otherwise siege could be endless if planet have all mineral with good availability, and don't even need to be Earth-like planet to be stronghold.
    Title: Re: C# Aurora Changes Discussion
    Post by: totos_totidis on June 19, 2019, 04:35:15 PM
    If a planets costs more to take than it is worth then the player will use the nuclear option.
    Title: Re: C# Aurora Changes Discussion
    Post by: amram on June 19, 2019, 07:07:43 PM
    If a planets costs more to take than it is worth then the player will use the nuclear option.

    If they are trapped on that rock, unable to ever threaten me in space, I'd just leave a buoy in orbit to remind myself that the natives are tiny bit unpleasant, and forget they even exist.  Why waste the effort to smash forces guarding something I don't care to have.

    If its worth it, then I decide if it will be nukes or boots.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on June 19, 2019, 11:31:31 PM
    Relative tech level also matters. By the time you are two or three tech levels above the local defenders your troops should be near immune to enemy ground forces while casually slaughtering them with relatively light weapons.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bughunter on June 20, 2019, 02:35:52 AM
    Maybe let them consume their TN minerals, so the longer you leave them the less there will be for you?

    Or let them occasionally "recover" some old artefacts like a bunch of ground to space missiles, or some FAC:s they could cause trouble with for whatever traffic is passing by.
    Title: Re: C# Aurora Changes Discussion
    Post by: hubgbf on June 20, 2019, 02:55:37 AM
    Or just poison the atmosphere with some terraforming modules...

    If not allowed, you can also remove oxygen, or rise the temperature.

    Cost only time. Once an ennemy own the higher orbital, you're doomed as it must be.

    Edit : work only to kill population and get an intact economy. Land troops are unaffected, which is strange after several decades.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bughunter on June 20, 2019, 03:22:14 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on June 20, 2019, 04:27:30 AM
    The main issue is that the military isn't getting new recruits to replace the soldiers who retire or injured to the extent they cannot continue. That's not that big a deal when you are talking about a couple of years, but if you are talking about 5 decades it's really odd.
    Title: Re: C# Aurora Changes Discussion
    Post by: totos_totidis on June 20, 2019, 04:34:49 AM
    Personally i do not feel comfortable leaving an uncontrolled planet in the middle of my empire. Thus my dilemma is always nukes or boots.
    Title: Re: C# Aurora Changes Discussion
    Post by: hubgbf on June 20, 2019, 07:35:37 AM
    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.

    Part of the civilians are working to grow food, and others tasks, and they have infrastructure. As an abstract mecanism, part of infrastrucutre is dedicated to these jobs, workshop and all.
    But the soldiers have only armor and some vehicules.

    Perhaps TN technology allow fabricators and near infinite recycling ?

    Anyway, imagine 20 years without getting out of your armor, just think about the smell !!!
    Title: Re: C# Aurora Changes Discussion
    Post by: Bughunter on June 20, 2019, 01:08:21 PM
    Anyway, imagine 20 years without getting out of your armor, just think about the smell !!!

    Explains green-skinned space orks then :)

    I think it would be reasonable enough to RP that they have enough resources to protect some civilians handling production, food and.. procreation if it comes to that. It would anyway be a boring gameplay option to wait them out to die of old age.
    Title: Re: C# Aurora Changes Discussion
    Post by: space dwarf on June 23, 2019, 05:14:45 PM
    Question: In a "collapse of a larger empire" scenario, wouldnt it make sense for the new spoiler race to also be replaced by your own species?
    Title: Re: C# Aurora Changes Discussion
    Post by: Hallec on June 24, 2019, 09:21:36 AM
    I just wanted to say,  I have really enjoyed playing the VB version of the game, and seriously look forward to playing the C# version.   What I've read and played so far shows a depth that may get overwhelming, but appeals to me nonetheless.   Keep up the good work, and I look forward to playing the next iteration.

    When Steve thinks it's ready!
    Title: Re: C# Aurora Changes Discussion
    Post by: TheRowan on June 24, 2019, 09:41:41 AM
    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...
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on June 24, 2019, 10:25:53 AM
    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...

    Yes, I'll make that the default display option.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on June 24, 2019, 11:17:18 AM
    And yet, many people who get a Victoria Cross didn't get promoted beyond the enlisted ranks.

    Admittedly, in no few cases that's because the VC got awarded posthumously, or the injuries suffered (physical and mental) were so severe the soldier in question was no longer fit for duty.
    Title: Re: C# Aurora Changes Discussion
    Post by: HMX1 on June 24, 2019, 04:47:37 PM
    about Missile Engines Integrated into Missile Design
    wouldn't it be more realistic if we have  a exponential curve on rocket performance  and cost
    lets say performance curve is (x^1. 3) and cost (x^1. 333)  that will alow us to have a really good ships/rocket but hey will be really expensive so
    for example

    lets set                                           nuclear thermal Engine       cost as it is now 70 Gallicite , with the same performance . . . Engine Power: 25. . . 
    but for the next tech level ::             Nuclear Pulse Engine           cost will be (X^1. 333) and performance wiil be (X^1. 3) so 250 Gallicite "300% increase " and Engine Power: 65 "260% increase" and so on
    then we reach the final tech level       Inertial Fusion Drive           it will be 2644 power and cost (58279226 Gallicite = 58m) 
     
    for comparison if i want to get the same power  in the current public game version it will cost me  1200x Gallicite with the following sittings
    ====================================================
    Engine Power: 2400     Fuel Use Per Hour: 992. 16 Litres
    Fuel Consumption per Engine Power Hour: 0. 413 Litres
    Engine Size: 50 HS    Engine HTK: 25
    Thermal Signature: 2400     Exp Chance: 15
    Cost: 1200    Crew: 75
    Materials Required: 1200x Gallicite
    Military Engine
    Development Cost for Project: 12000RP
    ===================================================

    and that is the cost of all tiers https://ibb. co/c1MZ3KH

    that will make me think about other variables ,so i will make cheap Nuclear Engine to use on my tankers and small war ships , and will use the Inertial Fusion Drive on a mega mother ship

    but there is a loophole some of you will figure it out instantly >>let me  add more cheap  nuclear Engine until i get the 2644 power that is  needed , to solve this we will have to make that game more realistic :
    different types of fuel  (and/or) much better efficiency per tech or as it is in the game Fuel Consumption per Engine Power Hour
    so yes you can add more tier 1 engines to get the same power but it will affect the amount of fuel you have to take with you in an exponential curve which will add more mass which add more need for power and so on

    about the different types of fuel suggestion
    technically we can create every element from every other element using fusion and fission and a lot of power  "Nuclear transmutation". . . so for high tech fuel you create it from lower grade fuel using some sort of  Nuclear transmutation machine in orbit around the sun "collecting energy " and imputing  any type of  mass  and output any resource you want in small amount and a very small efficiency lets say 100 t in and 1 ton out .   you could even start to make some sort of Nuclear transmutation machine fleet that get in a system orbit the sun while eating the whole solar system, finish and move on to other system " the bad aliens that have come to eat your solar system in a sci-fi movie  "
    ==========================
    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
    Title: Re: C# Aurora Changes Discussion
    Post by: nukeLEAR on June 25, 2019, 12:19:44 PM
    Quote from: HMX1 link=topic=8497. msg115080#msg115080 date=1561412857
    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

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on June 25, 2019, 12:25:37 PM
    Quote from: HMX1 link=topic=8497. msg115080#msg115080 date=1561412857
    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

    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.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on June 25, 2019, 12:28:06 PM
    about Missile Engines Integrated into Missile Design
    wouldn't it be more realistic if we have  a exponential curve on rocket performance  and cost

    There are new rules on missile engines for C# Aurora.

    http://aurora2.pentarch.org/index.php?topic=8495.msg102804#msg102804
    Title: Re: C# Aurora Changes Discussion
    Post by: Shuul on June 25, 2019, 03:33:43 PM
    Just wanted to ask if you coded Combat Air Patrol mission for fighters, as it still looks to be a placeholder for it.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on June 25, 2019, 03:46:30 PM
    Just wanted to ask if you coded Combat Air Patrol mission for fighters, as it still looks to be a placeholder for it.

    I don't think so - it is getting hard to remember what is and isn't coded. A couple of times I have started to code something and realised I already did it :)
    Title: Re: C# Aurora Changes Discussion
    Post by: nukeLEAR on June 25, 2019, 03:59:40 PM
    Quote from: Steve Walmsley link=topic=8497. msg115102#msg115102 date=1561483537
    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.

    To add to this even most Triple A super high budget games are not really multi-threaded, you will still find one core doing 90% of the heavy lifting since like Steve said most games are very linear in execution, things have to happen in order or things get frakky

    Also multi-threading makes debugging and absolute pain in the rear end, even when I was using it in a good use case for multi-threading (mass api calls)
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on June 25, 2019, 05:39:26 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on June 25, 2019, 05:50:38 PM
    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.

    Yes, that is the plan. Not coded yet though :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Ranged66 on June 26, 2019, 02:48:06 AM
    Will it be called just 'diplomacy module'? No fancy name like xenocommunication bay? Orbital embassy bay? I suck at naming but still.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on June 26, 2019, 03:22:45 AM
    Will it be called just 'diplomacy module'? No fancy name like xenocommunication bay? Orbital embassy bay? I suck at naming but still.

    I'm open to naming suggestions :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Rabid_Cog on June 26, 2019, 03:37:56 AM
    How about just "Embassy Module"? Gives the idea that the thing has to sit in the other guy's space for a time, not just visit briefly to have an effect.
    Title: Re: C# Aurora Changes Discussion
    Post by: Kelewan on June 26, 2019, 05:40:32 AM
    And have an civilian "Officer" aka Embassador on the ship and use his diplomacy bonus
    Title: Re: C# Aurora Changes Discussion
    Post by: Lamandier on June 26, 2019, 07:12:03 AM
    And have an civilian "Officer" aka Embassador on the ship and use his diplomacy bonus

    This. I love this idea; would give folks something to do with all those low-level administrators in the officer pool, and it seems more realistic. Could have it so that if there's an administrator on the ship it uses their diplomacy bonus, but if there isn't one aboard it defaults to using the commander's bonus.
    Title: Re: C# Aurora Changes Discussion
    Post by: sloanjh on June 26, 2019, 08:30:55 AM
    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
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on June 26, 2019, 08:59:35 AM
    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 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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on June 26, 2019, 12:15:37 PM
    I think the Embassy Module should work on a basis of 1 module per system. So having 2 Embassy Ships in Alpha Centauri will not help but having 1 in Alpha Centauri and 1 in Epsilon Eridani will double the positive diplomatic point increase for that alien empire. Since you then have two different points of contact to maintain good relations via positive propaganda campaigns and such. It also means player would have a reason to build multiple Embassy Ships instead of just one. The counter point would be that the additional ships require a colony - and perhaps these colonies need to be bigger and bigger.

    Something like:
    1st ship - any contact with NPR
    2nd ship - NPR colony of any size
    3rd ship - NPR colony of size X
    4th ship - NPR colony of size X+Y
    5th ship - NPR homeworld

    So it essentially gets capped at five ships per NPR. Naturally this should affect the general way diplo-points are earned and lost, so that it isn't possible to abuse the system via five ships with high diplomacy rating commanders maintaining an NPR at peace despite the player repeatedly shooting their ships and capturing their colonies.



    As for negative actions, we already have the active sensor and the attack bits from VB6, so in addition we would need:
    -discovery of spy ship in owned system (might need two levels of severity, milder for any ship with passive sensors and harsher for known ships with ELINT modules)
    -discovery of player ship in owned system
    -discovery of player ground forces on uninhabited body in owned system
    -discovery of player ground forces on inhabited body in owned system (like auto-mining colony or listening post)
    -discovery of player ship/base on gas giant in owned system (so a player harvesting a gas giant in a system NPR views their own is worse than just a player ship cruising through it as it's not only trespassing but stealing Sorium)
    -player terraforming an uninhabited body in owned system
    -player terraforming an inhabited body in owned system (this should probably be the worst possible war crime alongside completely nuking a colony)

    which leads us to a new diplomacy option - friendly terraforming! A treaty between allies (perhaps between trade and research or maybe after research) that allows empires to help terraform the colonies of their allies. Not sure how feasible this would be, coding-wise, but a notification to player via an interrupt that the Fuzzy Raccoon Alliance terraformers have arrived over NastyMcNastyPlanet might be enough, so the player can then adjust the target atmosphere to what they want. And similarly, player terraformers - on the off-chance that they are actually unemployed - would automatically work ONCE the player has sent them to the colony of an ally, so that there is no chance for the player to accidentally commit aforementioned war crime.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on June 26, 2019, 01:01:33 PM
    We already have the 'Colony pop >10 million' and 'Colony Pop >25 million' distinctions, it makes sense to me to use those.  Perhaps for a 'Consulate module' (1/4 effectiveness) and 'Embassy module' respectively.

    - - -

    Or as I will call them, "Orbital Mind Control Lasers" and "Universal Paperclips AI Drone"
    Title: Re: C# Aurora Changes Discussion
    Post by: Ranged66 on June 26, 2019, 04:59:34 PM
    Multiple owned populations on the same body are currently rather difficult and awkward to handle in Aurora. Will this be easier in C# version?
    Title: Re: C# Aurora Changes Discussion
    Post by: Conscript Gary on June 26, 2019, 10:46:44 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on June 27, 2019, 03:54:16 AM
    Multiple owned populations on the same body are currently rather difficult and awkward to handle in Aurora. Will this be easier in C# version?

    Depends what you mean by awkward. They are still separate populations but they are easy to distinguish because they can all have different names.
    Title: Re: C# Aurora Changes Discussion
    Post by: sloanjh on June 27, 2019, 08:14:12 AM
    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.

    This is exactly what I meant by "a system that can be gamed by throwing huge resources at the problem".  I think Garfunkel's proposal is a reasonable example of how to allow multiple diplomacy modules without falling prey to this problem.

    John
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on July 14, 2019, 11:35:29 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on July 14, 2019, 02:09:43 PM
    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.

    You have a System OOB on both the Tactical and Galactic map sidebars.
    Title: Re: C# Aurora Changes Discussion
    Post by: Froggiest1982 on July 14, 2019, 05:12:12 PM
    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.

    However, let's say you have established contact and have a so-called embassy ship in a system but then you withdraw it, wouldn't that be seen as at least an odd act? 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?

    Maybe there could be a penalty for lost communications after X years with x be 10 as a minimum before the penalty kicks in? Would mitigate the issue? The formula could take into account the xenophoby ratio as well and could be also progressive, therefore if you don't meet the race for 10 years then the penalty would be only very low compared to bad actions and also could keep you motivated to stay in touch with most races. At the end of the day Israel doesn't stand Palestine (and the other way round) but they still talk. I bet if one of the 2 suddenly disappears it will become shortly a big issue.

    I also do like the idea of the Ambassador role and could be a good use of some otherwise useless civilian administrators.
    Title: Re: C# Aurora Changes Discussion
    Post by: alex_brunius on July 14, 2019, 06:27:50 PM
    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?



    Title: Re: C# Aurora Changes Discussion
    Post by: Froggiest1982 on July 14, 2019, 09:58:02 PM
    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?

    What I meant is that would be quite waring if you have embassies and consulates around and you start closing them down. The other nation might think something going on. May not be a formal act of war but definitely going to impact relationships between the 2 countries.

    Regarding your example, I believe that the fact the war between the 2 Koreas has never ended then also diplomatic channels are a bit challenging due to the fact that the US is formally allied with South Korea.
    Title: Re: C# Aurora Changes Discussion
    Post by: Scandinavian on July 15, 2019, 03:31:22 AM
    But on Earth we have both intercontinental communications and a well developed system for conveying diplomatic messages and personnel unmolested through third countries, even if they are unfriendly to either or both of the parties to the diplomatic exchange.

    In Aurora, a system in between your embassy and your homeworld can very suddenly develop a really bad case of unfriendly naval forces that interdict your shipping, diplomatic or otherwise. I don't think it's reasonable for your friends on the other side of the blockade to take it as a deliberately unfriendly act that you don't run a jump point blockade to maintain your consular services.

    (Also, simply pulling consular services and embassy personnel would be considered rude but probably not a sign of unfriendly intent, unless you simultaneously started repatriating your other nationals in the country. Obviously if you start repatriating every one of your nationals you can get your hands on, the other guy is going to wonder what it is you want to protect them from. But that distinction requires a level of granularity in the simulation of the civilian economy that Aurora does not currently support.)
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on July 15, 2019, 01:16:26 PM
    Agreed with Scandinavian. And we have to remember that intricate human-to-human diplomacy has almost never been successfully modelled in a strategy game and it would be very challenging for Steve to write a system that covers all possible permutations. Withdrawing embassies could be seen as a threatening move in one situation yet a perfectly logical move in another situation. Same with pretty much any action relevant to diplomacy or trading.

    It's probably better to have a simple, robust system without too many surprises in it. Obfuscated diplomacy systems have, in the past, generally annoyed human-players more than they have turned AI-players into even semi-believable facsimiles.
    Title: Re: C# Aurora Changes Discussion
    Post by: boggo2300 on July 15, 2019, 05:11:20 PM
    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...
    Title: Re: C# Aurora Changes Discussion
    Post by: alex_brunius on July 17, 2019, 03:16:38 AM
    You do know the Korean war never ended? it's still just under a cease fire...

    The situation in the Korean border is probably the closest we have that is comparable to two Aurora races that meet for the first time without diplomacy. A very uneasy ceasefire.
    Title: Re: C# Aurora Changes Discussion
    Post by: SpikeTheHobbitMage on July 17, 2019, 11:54:44 AM
    The new Survey Site List looks good.  Ground surveys have always been a pain to deal with and this looks just like what the doctor ordered.  Thank you, Steve.

    One thing that might be helpful for larger empires would be to include a count of survey sites per system as an option in the overview or galaxy maps.

    Edit: Also, a column showing current survey points so we know which ones already have teams would be nice.
    Title: Re: C# Aurora Changes Discussion
    Post by: Whitecold on July 17, 2019, 12:18:51 PM
    Can own naming themes be deleted/overwritten? Spelling mistakes do happen
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on July 17, 2019, 02:32:50 PM
    Can own naming themes be deleted/overwritten? Spelling mistakes do happen

    Not at the moment - not hard to add though.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on July 18, 2019, 11:24:55 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on July 18, 2019, 12:06:41 PM
    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.

    I've added the asterisk.
    Title: Re: C# Aurora Changes Discussion
    Post by: hadi on July 26, 2019, 06:38:15 PM
    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 :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on July 27, 2019, 03:58:50 AM
    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 :)

    VB6 Aurora was accidentally good for screen readers rather than being a design goal :)  I just made a few extra tweaks, such as the coordinates, once I was made aware of it.

    I don't see any reason why C# should not be the same.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on July 27, 2019, 10:45:02 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on July 27, 2019, 12:34:35 PM
    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.

    Possible but there are some tricky elements. The ship loadout will make things a lot easier. Since I posted to the changes thread I added the ability to copy the ship loadout template to the class loadout template and to copy a ship loadout template to the ship loadout template of all ships of the same class in the same fleet. It is a lot more flexible than VB6.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on July 27, 2019, 01:47:53 PM
    It'd depend on ease of use I'd expect, but that's something that's only going to be revealed by playing the game.
    Title: Re: C# Aurora Changes Discussion
    Post by: the obelisk on July 27, 2019, 09:01:40 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on July 28, 2019, 04:14:12 AM
    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.

    I haven't really got going with diplomacy yet, so there are lots of options.
    Title: Re: C# Aurora Changes Discussion
    Post by: Froggiest1982 on July 28, 2019, 04:52:11 PM
    With the ability for a planet to have multiple colonies

    I think that is already coded as it was for the VB6
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on July 28, 2019, 05:08:50 PM
    It is.

    Any population that is dissimilar from any current population will create a new colony on planet.
    Title: Re: C# Aurora Changes Discussion
    Post by: the obelisk on July 29, 2019, 12:12:34 AM
    With the ability for a planet to have multiple colonies

    I think that is already coded as it was for the VB6
    Right.  I was trying to say that the multiple colonies thing could be used as is for some kind of embassy situation.
    Title: Re: C# Aurora Changes Discussion
    Post by: Akhillis on August 02, 2019, 03:06:32 AM
    I have a bad feeling I'm going to end up giving a flag bridge to practically every warship class above the size of a FAC just so that I can have an absurdly elaborate command hierarchy for my Fleet  ;D
    Title: Re: C# Aurora Changes Discussion
    Post by: Zincat on August 10, 2019, 12:02:29 PM
    The tactical map popup menu is going to be AMAZING. Thanks you very much.

    I think it will spare us a TON of clicks, and a lot of time as well. Incredible quality improvement as far as I am concerned
    Title: Re: C# Aurora Changes Discussion
    Post by: JacenHan on August 12, 2019, 02:17:55 PM
    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"?
    Title: Re: C# Aurora Changes Discussion
    Post by: davidb86 on August 12, 2019, 02:25:00 PM
    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"?

    I believe that if you used the color list and the suffix dragon, you would get Red Dragon, Blue Dragon, Green Dragon, ...  etc.  I do not think you can combine two lists.
    Title: Re: C# Aurora Changes Discussion
    Post by: JacenHan on August 12, 2019, 02:30:23 PM
    That makes more sense :P. My bad for misreading the post.
    Title: Re: C# Aurora Changes Discussion
    Post by: TheRowan on August 13, 2019, 05:51:46 AM
    This is a small change that makes things much more convenient... especially when I'm building Auxiliaries and using traditional RFA names for them.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on August 17, 2019, 09:37:00 AM
    http://aurora2.pentarch.org/index.php?topic=8495.msg115853#msg115853

    Quote
    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).

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on August 17, 2019, 11:21:53 AM
    I'm a bit concerned, to be honest. Final defensive fire was already really powerful.
    Title: Re: C# Aurora Changes Discussion
    Post by: alex_brunius on August 17, 2019, 11:25:39 AM
    I'm a bit concerned, to be honest. Final defensive fire was already really powerful.

    Yeah, agree a bit. I expect the other point defense modes to go from being mostly useless / very situational, to absolutely useless by making final fire even better.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on August 17, 2019, 01:00:23 PM
    Final defensive fire have only been very effective against regular sized missile launchers fired in decently large sized salvos.

    It was very costly to defend against small salvos and it will still be weak against large box launched salvos in the same way as before.

    It is now just going to be more difficult to use missile fire-controls or different missile loadouts to break up missiles in salvos. Now you will need to invest less in fire-controls which will not really impact ship size as much as it will ship cost. The cost of fire-controls will now be more in line with the cost of fire-controls in a missile ship.

    You still need allot of turrets so you don't waste shots which will be less gamey.
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on August 17, 2019, 09:38:50 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on August 18, 2019, 04:42:16 AM
    Frankly, the various PDFCS should not be treating every salvo separately. They should instead check salvos on the basis of 'am I authorized to engage' (ie, is the salvo hostile or friendly), 'is the target in range' (for Area Defence PD), 'is it targeting my TF' (for Final Defensive Fire) and 'is it targeting me' (for Final Defensive Fire (Self Only)). It should then generate a list of its own (or for less calculation requirements I'd expect generate a list for the TF with all Area Defence PD, TF-wide FDF and ship specific FDF(SO) PDFCS and weapons) and start shooting, treating every category list as one big salvo.

    Yes, this means that some big salvos might get lucky and not get engaged and thus turn their targets into expanding clouds of debris. That'd also happen in reality.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on August 18, 2019, 05:05:08 AM
    I'm a bit concerned, to be honest. Final defensive fire was already really powerful.

    I'll see how it goes in play-testing. All this change really does though is reduce the number of beam fire controls required for point defence ships. It doesn't make the point defence itself more effective (beyond having a little extra space for weapons that used to be for fire controls).

    It is intended to correct the problem the current system has with a lot of small fighter-launched salvos vs the same number of missiles in a smaller number of salvos.

    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on August 18, 2019, 05:26:40 AM
    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.

    No, because quad turrets were already limited to just one salvo before the change. This change means that you no longer need a fire control for each turret, except for adding redundancy overall.

    Title: Re: C# Aurora Changes Discussion
    Post by: alex_brunius on August 18, 2019, 05:28:32 AM
    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
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on August 18, 2019, 06:04:30 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: misanthropope on August 18, 2019, 09:01:55 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on August 18, 2019, 03:19:44 PM
    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.

    Yes... railguns might become a bit too powerful for PD going forward.

    I would like for range and speed of bullets/beams to have more of an impact on the accuracy on weapons as well. For example a laser should be quite effective at PD since it can engage at relatively long range (given the speed of the beam). A rail gun that fire four shots in 5 sec still need to be able to engage in a 5 sec range interval or all those four shots will never have been able to fire in the first place, this also goes for Gauss weapons.

    I get that it is an abstraction mechanic just now... but say the range tech on Gauss are not really that interesting to be honest since they do diddly squat for PD purposes.

    Also, railguns for pure PD duty can be extremely cheap since you need to invest nothing in the range of the gun for them to be effective.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: alex_brunius on August 18, 2019, 05:09:14 PM
    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.

    True. This is the issue I have with how the mechanics works as well. I also don't see why logically ( since the speed of the missile is known ) longer ranged PD like lasers could fire at range if they have range and time allowing for the cooldown, and then still perform final fire in the end.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on August 18, 2019, 06:16:13 PM
    Weapon damage is always calculated with a minimum range of 10,000 km. The same could be done with fire controls, so that maximum range made a difference to the to-hit chance for point-blank fire. However that wouldn't affect weapon design.

    Also, having longer range weapons is useful for offensive combat so I'm not sure I would ever deliberately reduce my max potential railgun range for the sake of cheaper point defence. I'll see how it works in testing.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on August 18, 2019, 07:17:45 PM
    If I was talking about a dedicated PD mount I'd want to make my railgun as small as possible with as high a rate of fire as possible and as high a tracking speed as possible. FDF isn't really about hitting the target as much as it's about filling the vector it's approaching on with as much lead as possible so it either veers off or detonates without hitting its intended victim.

    Railguns are great at being dual purpose weapons though, so you kinda want to make them also good at ship to ship or ship to surface combat.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on August 18, 2019, 07:19:08 PM
    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.

    Yes, I think so too. I hope to find out soon :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on August 18, 2019, 08:01:09 PM
    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.

    Until the AI starts building 'rail gun barges' I don't think it's the slightest bit of a problem.  Until recently, box-launcher spam and massive fighter swarms have been "outrageously effective" -- I'm tremendously pleased that this is finally getting addressed.

    As always with Aurora, if you find something 'exploity' or 'too effective', don't use it.  Personally, I am desperately looking forward to my age-of-sail fleet not having to constantly 'break character' to avoid annihilation at the hands (tentacles?) of Precursors.
    Title: Re: C# Aurora Changes Discussion
    Post by: Naismith on August 18, 2019, 10:23:54 PM
    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.
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Scandinavian on August 19, 2019, 01:08:15 AM
    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.
    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.
    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.

    The current issue with area defense is that your weapon's engagement envelope needs to be greater than two times the distance the missile travels during your weapon's reload time for it to make sense to set your weapon to area defense. This is very difficult to achieve for any kind of comparable tech levels.

    If you are allowed to make tracking time compensate for engagement range as well as tracking speed, area defense begins to make sense already at ranges greater than a single missile travel time per reload if, your sensors are good enough to fully compensate for the range penalty (because you are guaranteed one shot, which is as effective as FDF, but have a chance to get another shot as well). If your sensors are not good enough to fully compensate, as will typically be the case, the cut-off for switching from area defense to FDF grows toward 2 missile flight distances, creating a more interesting set of design and research decisions.
    Title: Re: C# Aurora Changes Discussion
    Post by: chrislocke2000 on August 19, 2019, 04:38:54 AM
    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.

    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on August 19, 2019, 05:38:08 AM
    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.

    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.

    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.

    Rather than than trying to make area mode work for energy weapons, maybe we just have to accept the concept isn't really viable. Even in modern warfare, the 'Anti-Air Picket' would be armed with AMMs rather than short-range weapons. A forward AMM picket really could make a difference.

    Re tracking bonus: If energy point defence does prove too effective with the new changes, I would probably remove the tracking bonus altogether.
    Title: Re: C# Aurora Changes Discussion
    Post by: chrislocke2000 on August 19, 2019, 06:28:47 AM

    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.


    Agree its only really of use where the x section of your forward escorts is sufficiently low compared to the fire controls of the enemy to push them to engaging your main body. I do however see a use for area defense for forward small corvettes / Facs / fighters if you can engage missiles passing through that engagement range.
    Title: Re: C# Aurora Changes Discussion
    Post by: misanthropope on August 19, 2019, 09:47:50 AM
    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. 
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on August 19, 2019, 10:54:48 AM
    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.

    I'm fairly certain the first example is how it works? Well, I've heard it doesn't work at all in VB, but I'm confident it will be multiplicative rather than additive in C# because that's how most accuracy modifiers work.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on August 19, 2019, 11:09:04 AM
    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.

    See the rules post:

    http://aurora2.pentarch.org/index.php?topic=8495.msg115708#msg115708

    It is a multiplicative addition to tracking speed, not to-hit. So if your tracking speed is 4000 km/s and the tracking bonus is 10% (which is not easy as that requires tracking for 50 seconds), your tracking speed will be 4400 km/s.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on August 19, 2019, 12:00:28 PM
    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.
    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.

    Since my first C# game will have so many factions, I'm definitely experimenting with all possible defensive techniques and in various combinations, so the more there are, the happier I'll be.  :)
    Title: Re: C# Aurora Changes Discussion
    Post by: chrislocke2000 on August 19, 2019, 04:21:12 PM
    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. 
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on August 19, 2019, 04:51:57 PM
    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.

    Yes, that was sort of an unintended consequence. However, I solved it by adding a 5-ton fighter engineering component to the next Starhawk version. Given that fighter sensors and fire controls are much smaller in C#, it isn't really a problem.

    BTW all the small engineering and fuel components are now starting techs - you no longer need to research them.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on August 19, 2019, 05:33:30 PM
    While Area Point-Defence might not be economically viable as a direct tactic it can certainly be useful as a side effect use of beam ships in general. If you have some more or less dedicated long range beam ships you might as well send them out to do Area defence work and perhaps spend some time to use some of their beam weapons in turrets. Now the ship have a purpose not just in beam combat but to swat down missiles in area defence mode.

    If we see considerable lower speed on long range missiles and larger missiles then this actually can be a viable secondary use for beam combat ships that don't have and final defensive type weapons anyway.

    So even if we are not going to build ships with the sole purpose to do area defence work it can be a secondary job for beam ships if it is more effective than using such ships in final defensive fire.

    Anyway, making it so that at least long range weapons are clearly more effective this way by changing some of the way the engagement works can in my opinion make it at least somewhat interesting.
    Title: Re: C# Aurora Changes Discussion
    Post by: Titanian on August 19, 2019, 05:57:57 PM
    Another option could be to reduce the power of engines in general, leading to lower speeds for both ships and missiles. That would give weapons a longer relative range without increasing the range of the weapons themselves, avoiding the five lightseconds problem. And I don't think lower ship speed would really hurt the game.
    Title: Re: C# Aurora Changes Discussion
    Post by: DIT_grue on August 20, 2019, 02:42:05 AM
    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.

    Huh... that seems like it might end up merging the PD modes from the other direction, as it were? (Depending on implementation, of course.) Rather than discarding Area Defence as useless, if 'closest approach' is 'zero, because it's trying to hit me' then you've ended up with Final Defensive Fire plus a risk that your weapons can't protect you because they have already shot at missiles aimed at someone else who isn't even nearby to return the favour. Which makes FDF more-or-less the midpoint on a spectrum from AD to FDF(self only), and might be a good outcome?
    Title: Re: C# Aurora Changes Discussion
    Post by: Doren on August 20, 2019, 02:54:34 PM
    Area defence PD would actually be a lot more useful if it would be able to shoot missiles that pass through but do not end their turn in PD range since that would already mean that you could protect disabled ships with your PD which could be thought as a improvement over final fire.

    There's also a situation where you could have PD ships on top of enemy missile ships (like jump point situations) and they could start launching missiles at other targets if they happen to know (maybe after a salvo or so? or pervious engagement) that they cannot actually harm the PD ships due to amount of PD but in case of final fire mode missiles would go unhindered compared to a area defence if it was more reliable to be used
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on August 21, 2019, 02:41:07 PM
    Why not just have ONE PD setting and call it a day.

    You fire on missiles at the closest point but never closer than 10.000km distance. At least then range on your Gauss will start to matter to some degree since there always is a chance you get to fire two times against incoming missile with greater range than 10.000km.

    If PD start to become too effective you can also allow missile agility a small evasion chance to even out the field. Agility will simply add to the missiles speed for tracking purposes. Now with the tracking bonus added to the game this actually make even more sense.


    I think that these things added might cancel each other out in the end so PD stays reasonable effective as the game goes on.


    If Agility add to the defence of missiles then we might also see reduced effectiveness of late AMM that otherwise become way too effective at engaging missiles for their cost. Exactly how much defence add is a balancing act, but if it make missiles better at targeting it should also make them better at evading stuff if perhaps not as effective as for targeting stuff.

    Title: Re: C# Aurora Changes Discussion
    Post by: Doren on August 21, 2019, 02:49:43 PM
    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 enemy fires some missiles at a target A and some missiles at target B. Target A has PD and is on PD duty. Target B is low value target and you do not care for protecting it. If missiles that target Target B move first Target A can exhaust it's PD capacity on missiles targeting Target B and missiles targeting Target A hit unhindered.
    Due to Area Defence rules we still try to cover Target B but from player perspective they would prefer to see Target B burn rather than Target A
    Title: Re: C# Aurora Changes Discussion
    Post by: Kristover on August 21, 2019, 08:16:19 PM
    The latest feature covered, enemy fleets surrendering under certain conditions, what happens to the ships and crews?  Do we keep the ships for scrap?  Retrofit for reuse?  breaking them down for intelligence/research purposes?  Do we capture their Commanders as prisoners?  Just curious.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on August 21, 2019, 11:42:40 PM
    All of the above are options.

    Note that Aurora already had surrendered ships. . .  but far fewer of them, and far less intelligent rules for when they would surrender.
    Title: Re: C# Aurora Changes Discussion
    Post by: Shuul on August 22, 2019, 03:27:40 AM
    In my opinion surrendering ships open many possibilities g r diplomatic negotiations. Should NPR ask to retrieve their captured ships? Can we propose to return them as a sign of good will? etc.
    Title: Re: C# Aurora Changes Discussion
    Post by: LoSboccacc on August 22, 2019, 03:35:50 AM
    couple questions

    how surrender going to work if the language is not yet decoded?

    can the crew be absorbed in the empire forming a dependent/independed pop? or dropped on an asteroid and made work on the miners?
    Title: Re: C# Aurora Changes Discussion
    Post by: Bughunter on August 22, 2019, 05:51:45 AM
    Don't remember if anything was changed around PoW handling yet, but should probably tie in with that. Return of prisoners etc. as part of peace agreements.

    But this could potentially be another major addition, if you also consider the AI needed for it.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on August 22, 2019, 06:36:03 AM
    I'm not going to make the prisoner issue over-complex. When a ship surrenders, it becomes your ship with an overhaul factor of 0.01. This is the same as capturing it via boarding combat. You can scrap it, refit it, etc..

    For the crew, I don't have any specific code yet but it would make sense to treat them in the same way as rescuing alien life pod survivors. You gain intel and the survivors become POWs, which you can drop off at a colony. In this case, they would be POWs on what was their own ship and you will need to add a crew. I'll probably create a small 'prize crew'  for free and you will need to get the ship to a colony to take on a full crew.

    There is no code for POWs at the moment beyond tracking their location, so I will look at that as part of diplomacy.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on August 22, 2019, 08:40:58 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on August 22, 2019, 09:02:47 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on August 22, 2019, 10:07:06 AM
    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.

    Fair.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bails_64 on August 22, 2019, 05:11:54 PM
    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.

    Title: Re: C# Aurora Changes Discussion
    Post by: Zincat on August 22, 2019, 05:26:16 PM
    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.

    Cause you know, not everyone wants to die. Statistically speaking it's fair to say a lot of people would surrender in a hopeless situation (unless they think they're going to be killed anyway but that's another matter)
    Happy martirs are not the majority. If given a chance to survive most will try to take it.

    And Steve did say it depends on the race's xenophobia and such. So...
    Title: Re: C# Aurora Changes Discussion
    Post by: lupin-de-mid on August 23, 2019, 05:10:05 AM
    Quote from: Bails_64 link=topic=8497.  msg115998#msg115998 date=1566511914
    .  .   they bailed out to life pods and scuttled their ship? .  .  . 

    Quote from: Zincat link=topic=8497.  msg115999#msg115999 date=1566512776
    Cause you know, not everyone wants to die.   .  .  . 

    Bold selection is my

    Crew able to leave ship before explosion.   It definitely possible to leave ship with 5 sec warning.   And destroy all valuable devices according  to self-destruction protocol
    Title: Re: C# Aurora Changes Discussion
    Post by: Rabid_Cog on August 23, 2019, 05:43:23 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: SevenOfCarina on August 23, 2019, 11:07:22 AM
    Hey Steve, it appears that armour area rounds down in both C# and VB6 Aurora. Is this intended? From the C# campaigns, 1000t ships have an armour area of 8 when it should be 8.90, and 500t fighters have 5 when it should be 5.61. All the other ship designs point to the same thing. I think it should probably round up instead, or else we get this :

    Code: [Select]
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Zincat on August 25, 2019, 06:49:11 AM
    The ability to auto refit fighters for shipyards sounds like an amazing QOL improvement. Thanks Steve
    Title: Re: C# Aurora Changes Discussion
    Post by: space dwarf on August 25, 2019, 08:49:00 AM
    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.

    OR you give away all your advanced technology away for free and die.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on August 31, 2019, 01:38:33 PM
    Quote
    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.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on August 31, 2019, 01:51:24 PM
    Quote
    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.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bughunter on August 31, 2019, 01:57:00 PM
    Maybe just call it "avoid combat" instead since that would make sense for both FFD and real non-combat units.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on August 31, 2019, 02:13:12 PM
    Quote
    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.

    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.

    Sounds to me like an argument that you want to put FFD units in heavily armoured units.

    Or create an FFD Hub component with the current costs which links FFDs with greater efficiency (i.e. an FFD without a Hub backing it only gets to direct a single gun or has a high failure chance, but an FFD with a Hub uses the current rules) and create a new FFD component with lower size and cost.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on September 01, 2019, 04:45:39 AM
    Maybe just call it "avoid combat" instead since that would make sense for both FFD and real non-combat units.

    Yes, good idea.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on September 01, 2019, 07:05:50 PM
    Multi-faction Earth starts just got more complicated with the addition of Lagrange points. Because now you can both jump instantly from the inner system to various parts of the outer system, but it's also quite feasible to traverse through the deep black.
    Title: Re: C# Aurora Changes Discussion
    Post by: amschnei on September 01, 2019, 08:39:40 PM
    Per Steve’s post Earth requires 5 years to stabilize, so it’s not really feasible as a way to get a jump on anyone.  Even Saturn takes 6 months, plenty of time to intervene militarily.
    Title: Re: C# Aurora Changes Discussion
    Post by: xenoscepter on September 02, 2019, 04:13:38 AM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on September 02, 2019, 04:17:12 AM
    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?

    It is explained in the Logistics post in the change log:

    http://aurora2.pentarch.org/index.php?topic=8495.msg109760#msg109760

    The infantry unit or vehicle is consumed and you have to build a new one.
    Title: Re: C# Aurora Changes Discussion
    Post by: DIT_grue on September 02, 2019, 04:29:03 AM
    Quote from: Steve Walmsley
    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.

    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).
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on September 02, 2019, 05:59:26 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on September 02, 2019, 06:46:37 AM
    Quote from: Steve Walmsley
    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.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on September 02, 2019, 06:47:41 AM
    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.

    If it helps, just call logistic units Ground MSPs instead of Supply Vehicles. The actual function is the same.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on September 02, 2019, 08:12:07 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on September 02, 2019, 10:52:34 AM
    Highly dispersed is the description for ground units that ended up hugging a nuke due to orbital bombardment.
    Title: Re: C# Aurora Changes Discussion
    Post by: sloanjh on September 02, 2019, 11:21:55 AM
    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.

    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.

    Not advocating one way or another (I actually lean in favor of keeping it at design time), just pointing out a bit of inconsistency in the naming.  And as we say at (software) work, names are important :)

    Ok, changed my mind after that last bit.  I'm advocating keeping the behavior the same and not changing the name.  Since names are important (think about all the conversations of jump gates vs. wormholes we've had over the years).

    John
    Title: Re: C# Aurora Changes Discussion
    Post by: sloanjh on September 02, 2019, 11:32:06 AM
    Quote from: Steve Walmsley
    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.

    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
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on September 02, 2019, 11:39:48 AM
    (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

    Aurora uses the L5 for the Lagrange point for jumping purposes, but uses the L4 and L5 for the creation of Trojan asteroids.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on September 02, 2019, 11:44:33 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: sloanjh on September 02, 2019, 12:07:45 PM
    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.

    Understood and agreed.  The question is should an infantry unit in the trenches be able to go non-combat (e.g. either voluntarily or if their morale is low) and leave the fighting to other units, or should it be an innate property of the type of unit.

    I'm in favor of keeping it the way you've implemented it; I'm just trying to bring up the alternative so a conscious choice can be made (if it hasn't been already). 

    John

    PS - While typing the above, I started thinking that the run-time decision (hah!  my software side leaked through there - I'm thinking of this as run-time vs. compile-time binding) might be a cool way to represent broken units, and that e.g. if a broken unit *is* attacked that would make a good breakthrough opportunity (note that the ground combat discussion was long enough ago that I don't remember any of the detailed mechanisms).  The downside of this is that if one of your "non-combatant" units in the front lines got hit it would also give a breakthrough opportunity, so I'm still in the "keep it the way you've got it now" camp, but the other idea has some interesting opportunities.
    Title: Re: C# Aurora Changes Discussion
    Post by: Rabid_Cog on September 02, 2019, 01:15:23 PM
    While this risks getting into the territory of the suggestion thread, the idea of certain units avoiding combat as part of their design creates another interesting potential future mechanic. That of units the specifically target these units in order to achieve breakthroughs/exploit weaknesses. Perhaps some form of special forces unit that ignores the size modifier of 'avoid combat'.

    Anyway, just saying that you can play with those mechanics in the future to create a situation where certain units prefer to engage certain other units.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on September 02, 2019, 01:43:10 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on September 02, 2019, 03:06:26 PM
    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.

    Yes, exactly. Also this is permanent at design time. A unit can't choose to swap to non-combat.

    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on September 02, 2019, 04:13:53 PM
    Now I'm wondering if it would be worth having the penalty to accuracy not imply to bombardment weapons. Then you could have light bombardment weapons (like mortars) embedded with infantry and using the avoid combat option.

    That might be overcomplicating the process, though, especially as far as documenting it/explaining it to players who aren't following C# development as avidly as us here :P
    Title: Re: C# Aurora Changes Discussion
    Post by: Borealis4x on September 02, 2019, 09:26:01 PM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Adseria on September 03, 2019, 01:08:40 AM
    Quote
    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.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on September 03, 2019, 01:57:21 AM
    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?

    What's stopping you from doing this now?  What (mechanical) game effect is such a system supposed to have?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on September 03, 2019, 03:20:56 AM
    Quote
    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.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Doren on September 05, 2019, 01:30:20 AM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on September 05, 2019, 03:30:31 AM
    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?

    Already shown in fleet data :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Iranon on September 12, 2019, 12:06:02 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on September 12, 2019, 02:24:07 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: SevenOfCarina on September 13, 2019, 11:46:23 AM
    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'd suggest that one way to balance this is to make the accuracy of kinetic weapons dependent on the projectile velocity. It sort of makes sense in a way - faster projectiles leave less time for dodging - and the remaining weapons are either lightspeed (lasers, microwaves), or really close (particle weapons, mesons, plasma?). There's already a tech for this too! Gauss cannons should probably not be affected though.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: papent on September 13, 2019, 01:34:24 PM
    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.

    you think even with the new weapon failure chances, this will still be the case?

    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.

    and with fighters even in Steve's Test game he's having a lot failures on fighter weaponry, which I think will limit the use of fighter interceptors (Beam or Missile) for use in prolonged battles or heavy combat as they will suffer from weapon failures not to mention combat losses, so why limit their effectiveness more with a limit on use of turrets.
    Title: Re: C# Aurora Changes Discussion
    Post by: Iranon on September 14, 2019, 04:10:28 AM
    Weapon failure is highly problematic in itself, without reworking a few other things.
    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.

    Cheap and bulky will be harder to maintain, but one could simply not maintain those ships. Give them a long mission life, use up and scrap/salvage.
    I hope I'm wrong, but many new mechanics scream for crude and sometimes unintuitive solutions to a given challenge, that ignore a great deal of the complexity. The current ruleset seems more robust. While I enjoy poking the mechanics with a sharp stick and it opens up interesting niches... I currently don't feel punished for "playing as intended", which I think is very important. I hope we won't lose depth despite adding complexity.
    Title: Re: C# Aurora Changes Discussion
    Post by: Rich.h on September 14, 2019, 09:37:33 AM
    So the new MSP mineral changes are a much welcome one, but it made me wonder if it is possible to reduce this aspect of micro management a little more. Does Aurora C# allow for setting a minimum/maximum/range for mineral storage that will allow for the following to take place?

    1. You decide how much of a set mineral you want on a colony
    2. Allocate a frieghter to work as a conditional order ship (with the conditional being to check mineral amounts)
    3. The freighter now checks on all the required minerals based on your settings and auto fills from a specified other colony.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on September 14, 2019, 12:10:30 PM
    If it were me I'd probably have the maintenance providers and the MSP manufacturers be separate (or just built by construction factories like ship parts), so you could just ship MSP around, as one resource is even easier than three. But as long as maintenance facilities do both then I agree the mineral change is for the best.
    Title: Re: C# Aurora Changes Discussion
    Post by: Titanian on September 14, 2019, 04:25:39 PM
    Weapon failure is highly problematic in itself, without reworking a few other things.
    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.
    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.
    The lasers are also fine: 10 lasers require 10 times the space and thus 10 times the number of ships to mount the same weapon strength, which is a lot more production cost.
    The gauss turret - I guess we will have to see how severe it becomes. Remember though that salvo sizes are not a problem for this anymore, so this only occurs if there really is just one missile approaching, or it is the only missile left of a larger salvo after other weapons have fired.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on September 15, 2019, 01:37:52 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: SevenOfCarina on September 15, 2019, 02:51:49 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: papent on September 15, 2019, 04:14:31 PM
    I think what Jorgen_CAB is stating is that a balance issue is only a balance issue if it is exploited/used and as this game is built for single-player, with an AI that is not designed to exploit such things.
    In my humble opinion anything that could be considered a balance issue is a moot point unless the AI utilize it against you because otherwise it's an exploit you willing choose to use to game the system.
    After all this game developed from an aid for a tabletop game and rule 0 The SM is always right. is still in effect.


    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.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on September 15, 2019, 04:31:23 PM
    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.

    Extreme long time deployments is in my opinion an exploit if you are playing in a human society... The size you need for extreme voyage is not realistic especially for really small ships. The larger and more crew you have on a ship the more you might increase it but it still become very unrealistic after a few years anyway unless the ship is on some special mission type thing.

    Extreme maintenance periods are also very gamey and unrealistic for something as complex as a space ship, especially if operated by actual living beings that are not perfect.

    So yes, in my opinion it is an exploit for the sake of exploiting it...

    In my opinion it works unless you intentionally exploit it which you really don't need to do.

    On the other hand I do agree with you on the point that more modern weapons system should be more efficient at PD. The range of a weapon certainly would be a huge benefit to a PD weapon for example as are the speed of the projectile fired on a Gauss weapon for example.
    Title: Re: C# Aurora Changes Discussion
    Post by: Iranon on September 16, 2019, 04:08:12 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on September 16, 2019, 05:58:34 AM
    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.

    I would agree to some point here, but that also depend in what role-play you wan't to be possible. The current system at least give you the options for some machine race or something to abuse these system. Perhaps from a mathematical perspective it is way more effective to just give ships an extreme long maintenance cycle and scrap and build new ones and ignore maintenance facilities altogether... I don't know...

    If it could be better balanced I would not be against it, but I don't see it as necessary to play the game and don't abuse it.

    As I said before... there are many more ways to abuse the game mechanics in Aurora but you don't need to do it to get a balanced game. Aurora is as far as I understand first and foremost a role-playing platform so you do whatever you feel is best for you to get the best playing experience.

    I always restrict myself and all my factions to way more restrictive rules to how things work in the game, for role-playing. As all the factions live by the same rules it is fair and balanced.

    Aurora is not a game to win, it is a game to play the way you see fit.

    It obviously does not mean that there should not be some sort of balance or that things can be changed or fixed.

    I did state in one of my answers above that I think the resource cost for technology in and if itself is gamey... you don't pay 20% higher resource cost just because a technology is 20% more efficient or better. In the real world the cost of a tank of the same mass is going to be roughly the same no matter what technology it contains since the industrial technology to develop it is there to support it as well. Any new matriel used in the new tank is now produced by industry as new technologies has been discovers, industry that would otherwise have produced the old material for the old tanks and so forth...
    So the industrial cost are going to remain roughly the same. What changes are usually the skill of labour, today the cost of labour is much more expensive since both the ones that build, operate and maintain equipment need to be more skilled. So it is often the human investment that change, you need more skilled people over time for development and research but less for actual production. Both operation and maintenance take more skilled people but often less people overall.

    If the cost of stuff remains roughly the same and instead you need to advance the industry and human capital to support it to develop it things would work better in this particular regard because the cost to maintain would be roughly the same in terms of human resource invested in it. managing the skill to maintain more advanced equipment would go hand in hand with the actual advanced equipment. Old equipment would still need to be maintained and would become more and more expensive over time in comparison with new technology. This is usually how it works in real life, older system become more and more expensive to maintain as newer more efficient technologies take over.

    Exactly how any of this would translate into Aurora I have no clue, but the system as it is are Gamey to begin with. I don't think there is an easy fix so using personal restriction to get the game to play like you want to is sufficient to a certain degree here and there.
    Title: Re: C# Aurora Changes Discussion
    Post by: Xenotrenium on October 10, 2019, 10:23:09 PM
    Posted a bug in regular Aurora that revolves around moving pdcs around as parasites

    hxxp: aurora2. pentarch. org/index. php?topic=8144. 915

    might be relevant to consider validating orders when a TG is manipulated in certain ways
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on November 05, 2019, 09:05:26 AM
    With the recent changes to the salvage mechanics when in orbit of a population, can we lug wrecks around with a tug?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on November 05, 2019, 11:50:21 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on November 05, 2019, 12:29:16 PM
    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 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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bughunter on November 05, 2019, 04:14:17 PM
    I cannot imagine anyone hauling a salvager+transports around then because moving tugs will be a lot easier. Probably also less risky if the system is not fully secured.

    While I like the improvement on micromanagement and having another option available I think it does remove some of the risk/reward tradeoff when sitting for days on a hot piece of space loot hoping no hostiles will show up before you get your freighters out. And it does make better salvage tech almost useless.
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on November 05, 2019, 09:12:51 PM
    I mean, on the flip side it makes considerably more sense so I think the tradeoff is worth it personally.  Traditional salvage might still be preferable for salvaging clusters of really distant wrecks.  I am admittedly somewhat biased, because I almost never salvaged due to how much of a pain it was compared to the payoff.  If I can just send tugs to drag stuff home and then use the colony to store the salvage, that sounds greatly preferable to me.
    Title: Re: C# Aurora Changes Discussion
    Post by: DIT_grue on November 06, 2019, 04:17:02 AM
    I don't know. It might make playing easier, but if I think about the narrative... A wrecked ship is likely to have descriptions like "shattered keel", "debris field drifting through space" and so on; the mechanical transition from 'ship' to 'wreck' strongly suggests to me that it necessarily lacks the structural integrity to be dragged around by a tug. (Sure, maybe in someone's Star Trek game they can bubble even the extreme of "pile of screws and armor shards flying in loose formation" in order to tractor it back to the nearest starbase, but not every universe is so forgiving.)

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: mandalorethe1st on November 06, 2019, 09:38:24 AM
    Quote from: papent link=topic=8497. msg116395#msg116395 date=1568582071
    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 agree.   I think adding a bonus for serial production and a handicap for first-of-class ships makes sense.   First of class warships IRL are typically 25-50% more expensive and can take extra years to produce.   I think modeling this in game would produce realistic industrial inertia, where its cheaper and easier to build old ships than to design new ones, especially when new ships offer relatively minor gains in performance.   This is why the US is still building Arleigh Burke class Destroyers.   This inertia is modeling the experience gained by the shipbuilders in reducing time and cost by streamlining the production facilities and the intangible experience gained by the people actually assembling the craft.   These little tweaks add up to substantial time savings.   The production bonus should also degrade if there is no activity.   

    In game, I would model the experience as an exponential decrease, leveling off at about the 20th ship for 3/4ths the production time.   Cost should come down as well.   
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on November 06, 2019, 09:45:52 AM
    In that case, retooling to a related ship with low refit costs should probably have minimal effect on the serial production bonus.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on November 07, 2019, 12:27:53 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Rabid_Cog on November 07, 2019, 02:01:29 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on November 07, 2019, 02:23:22 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: mandalorethe1st on November 07, 2019, 03:03:34 PM
    Quote from: Bremen link=topic=8497. msg116821#msg116821 date=1573158202
    I 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.

    Quote from: Rabid_Cog link=topic=8497. msg116820#msg116820 date=1573156889
    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 like this idea, and I think it would be easier to implement.   The same bonus should also apply to construction time.   


    Title: Re: C# Aurora Changes Discussion
    Post by: sloanjh on November 08, 2019, 08:57:37 AM
    Quote from: Bremen link=topic=8497. msg116821#msg116821 date=1573158202
    I 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.

    Historical note:  My recollection is that this (the retooling cost includes first-in-class costs) was exactly the intent when it was introduced.  My (much shakier) recollection is that the first instance was more expensive, although I could be conflating that with StarFire Assistant.

    John
    Title: Re: C# Aurora Changes Discussion
    Post by: papent on November 08, 2019, 09:40:37 AM
    Quote from: Rabid_Cog link=topic=8497. msg116820#msg116820 date=1573156889
    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 like this idea, and I think it would be easier to implement.   The same bonus should also apply to construction time.   

    I concur with this idea, and I think the same bonus should also apply to all serial productions  i.e construction, ordinance, fighters, ships, and maybe ground forces?
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on November 08, 2019, 11:45:09 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Mini on November 08, 2019, 03:32:35 PM
    I think applying a serial production bonus to anything you'll be building for the entire game is a bad idea, since it basically just makes those things cheaper by however much the bonus is. The problem of leaving 0.00001% of production maintaining a serial bonus can be solved by 1) increasing the bonus only by items completed and not time spent building, and 2) having the bonus decay over time. This will mean that under a certain threshold there will be a fluctuating equilibrium reached with the average bonus being lower than the maximum bonus, inversely proportional to how much production you are putting in. Also applying it to the population as a whole instead of a single line of production also makes more sense in Aurora (if we are talking planet-side production and not shipyards), since you won't lose the bonus if you momentarily stop production (even within a single increment) and likely works better with how the game is programmed.

    That said I think a serial production mechanic as a whole isn't that good of an idea. As Garfunkel brought up, it's something that strongly encourages trying to find exploits in, and even if you can ignore those exploits having them in the game is still a bad thing. It's also a very opaque mechanic that means that numbers all over the place to do with production start being various degrees of incorrect, and (in the case of shipyards) encourages having a large number of single slipway shipyards, increasing the amount of micromanagement and organisational clutter.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on November 08, 2019, 04:51:19 PM
    I miss 'prototype hull' and 'new class' penalties, and would like to see them come back.  I wouldn't want bonuses* for serial production, because now you're altering the established values of things.  I don't want to see unlimited 75% Frigates; I'm happy to see three expensive (say 125%, 120%, & 110%) 'class leaders'.

    If you don't want to play with penalties, switch them off and everything costs 100%.  If you do want them, you pay a little extra for new designs.  If we use bonuses, I can't see anyone turning them off and not getting their 'cheap' second dozen ships.

    .

    *The only bonus I'd like is speed.  I'd be quite happy if production of a design became faster (but definitely not cheaper) as more were completed.

    - - - -

    Disclaimer:  My empire almost always build one yard for each design.  I read much fiction on here where empires churn out two dozen freighters, retool their (only) commercial yard, build ten colony ships, retool, seven terraformers, retool, a couple tugs, retool, a dozen new-tech freighters, retool, etc.  They end up spending more on retooling than I do on building multiple custom yards.  Now that C# Aurora has ditched the per-yard overhead, it will be even more beneficial.

    I build a one-slip terraformer yard and leave it producing one ship every forty-four weeks for decades, occasionaly retooling to an upgraded-tech terraformer design.  Meanwhile, the yard next door is producing one fuel harvester every thirty-five weeks.  The freighter yard has four slips, and the colony transport yard, two.  Having six yards with one slip each that retool much less often is going to beat having one yard with 12 slips that retools every time it finishes a 'flight' of ships.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on November 08, 2019, 08:46:42 PM
    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.

    This is only if it is badly implemented...

    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.

    Or in the game it would rather be the number of percent you dedicate for each item and not factories directly.

    Stuff would not become cheaper to build, you just build them faster.

    As a balance you could just make factories slightly less productive.

    I don't mind either way as I already restrict how much industry can shift between lines every year anyway so I already simulate this effect through role-play.
    Title: Re: C# Aurora Changes Discussion
    Post by: xenoscepter on November 09, 2019, 02:35:04 AM
    Quote
    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.

     --- 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.)
    Title: Re: C# Aurora Changes Discussion
    Post by: Tikigod on November 09, 2019, 09:17:54 AM
    Quote
    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.

     --- 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.)

    Indeed, the way Hearts of Iron 4 approaches production could actually be applied very well to ship production considering how the game actually goes about producing ships on a per module basis.

    A shipyard could be made to track a history of what components it has produced overtime (with perhaps a production history reset after a very large retooling procedure, or after some years of inactivity), and then using variables such as module complexity (construction cost), shipyard building rate and number of production iterations come up with a efficiency scale and ceiling cap in that shipyard for each type of module in its production history.

    Retooling could be approached by essentially comparing the component lists needed for the new target design against the current design, retaining those modules that are shared across both designs in the shipyards production history (and reduce the existing efficiency gain by some factor) and then clear the rest of that shipyards production history once retooling is completed.

    I am not sure how retooling is approached in the VB/C# versions but doing that kind of approach would also make it more natural to calculate retooling costs based on component differences of the two designs, rather than based on overall build cost/size differences.

    This could also be applied in a more basic way to ordnance, PDC, orbital structures, fighters and so forth. Though in such cases it would probably be best to approach production history in a much more crude manner, essentially just doing a linear efficiency gain in that area with each component built and then do a efficiency wipe when producing a new design of that object type.
    Title: Re: C# Aurora Changes Discussion
    Post by: papent on November 09, 2019, 09:24:52 AM
    i imagined as working just as xenoscepter, Jorgen_CAB, and Father Tim implied.

    A: it only decrease production time not price/resources required.
    B: there's Efficiency/gearing bonus as stated by previous posters.
    Title: Re: C# Aurora Changes Discussion
    Post by: Dawa1147 on November 09, 2019, 05:43:42 PM
    I agree with the faster (but not cheaper) approach, with an option to turn it on or off similar to Fleet Maintenance. 
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on November 10, 2019, 07:11:35 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Rabid_Cog on November 11, 2019, 04:10:31 AM
    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.

    If you can manage to design your ships in this manner, you deserve every scrap of benefit you get. I've tried to do that before and it is extremely difficult to get all your ships to fit the same mold. Remember, size differences have a huge impact so you have to fill in the space with something on the base ship.
    Title: Re: C# Aurora Changes Discussion
    Post by: chrislocke2000 on November 11, 2019, 07:12:13 AM
    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.

     
    Title: Re: C# Aurora Changes Discussion
    Post by: Tikigod on November 14, 2019, 02:56:37 PM
    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.

    If you stage your ship components well so that your modules are suitable for a multiple ship designs I believe you can get around a fair bit of the added retooling time cost by stockpiling the modules you will need ahead of time as the shipyard will use pre-existing modules it needs in local stockpiles before actually attempting to construct the modules itself which I've always been led to believe takes longer.

    So whilst you're retooling you can actually be producing (Or salvaging old ships) to get a stockpile for most of the modules you'll need.
    Title: Re: C# Aurora Changes Discussion
    Post by: TMaekler on November 15, 2019, 02:17:20 AM
    Maybe the production efficiency bonus should not be added to the planetary production site, or the shipyard, but to a person? Widening the use of personnel for those installations, the installation foreman receives the production experience. Then when later another unit of the experience he gained is produced he can construct them quicker. Only for his project of course. Or if you want to build in parallel his experience is „split up“. And if he dies a new guy has to be trained... .
    Title: Re: C# Aurora Changes Discussion
    Post by: Shuul on November 24, 2019, 05:05:55 PM
    I feel like the weapons interruptions update is one of my favorite changes, thank you Steve!
    Title: Re: C# Aurora Changes Discussion
    Post by: Tikigod on November 24, 2019, 11:19:45 PM
    In regards to the weapons interrupt change, is there any chance of having a option maybe in the event window to decide if certain things like that do interrupt or not?

    There are a few fringe cases such as when you have a faster fleet that is jumping in and out of attack range as weapons recharge where retaining the interrupt can still be useful, so having the option to switch behaviours would be pretty neat.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on December 08, 2019, 05:13:43 PM
    As someone who loves playing with mines and buoys I just want to say that I love the new launch ready ordnance task. It'll make setting up minefields and sensor buoy rings so much easier.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on December 19, 2019, 07:46:04 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Dawa1147 on December 20, 2019, 04:41:05 AM
    Quote from: Jorgen_CAB link=topic=8497. msg117519#msg117519 date=1576763164
    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.

    Perhaps the Formula could be reworked to be dependant on both ship size and armor thickness/tech, with a reduced importance of size? That way shock damage resistance would scale with weapon tech, while still making bigger ships more resilient.

    As for fragile electronics, shock damage could randomly choose between both DACs, or have its damage (semi-randomly) split between them.  This would increase the odds of sensors being hit.
    Title: Re: C# Aurora Changes Discussion
    Post by: alex_brunius on December 20, 2019, 06:07:41 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on December 20, 2019, 08:40:49 AM
    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.

    Yes... both Scharnhorst and Bismark are good examples on that subject... ;)
    Title: Re: C# Aurora Changes Discussion
    Post by: Deutschbag on December 20, 2019, 09:52:35 PM
    Bismarck even managed to inflict shock damage on herself. Apparently in the opening salvo of the duel with the HMS Hood, her own cannon fire damaged her radar rangefinder.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on January 02, 2020, 03:09:16 PM
    Definitely liking the new change to civilians. Since they will now range further for trade as before, it's a nice thing to be able to restrict them in case of war.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bughunter on January 03, 2020, 03:34:25 AM
    Always good with more options. I also like the idea of negative modifiers to wealth & production mentioned in the questions thread. It could apply to any colonies in restricted systems or in systems cut off from say its sector HQ.

    Sure it is up to the player to abuse it or not, but I still think it would be nice to have a downside to restricting a system to make the decision more interesting.
    Title: Re: C# Aurora Changes Discussion
    Post by: Rich.h on January 03, 2020, 06:28:47 AM
    Just wondering with the new civillian restrictions, Steve states a system or population can be set as restricted, does this also apply to colonies that require no population, so automated mining sites and the like? I've always RP that there are no completley autonomous things in my games and these such colonies are instead just manned by a skeleton maintenance crew population, but it would add a nice bit of RP to things by allowing/restricting these also (wartime smugglers etc that ignore system blockades to make profit, then get promptley destroyed by hostile aliens).
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on January 03, 2020, 01:19:43 PM
    Steve said "colony" not "population" so I see no reason why it shouldn't apply to automated mining outposts or DSTS.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 03, 2020, 03:06:32 PM
    Steve said "colony" not "population" so I see no reason why it shouldn't apply to automated mining outposts or DSTS.

    Yes, that's correct.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on January 12, 2020, 10:46:08 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Zincat on January 12, 2020, 11:37:54 AM
    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.

    I came here just to post the same.
    Thank you thank you Steve. I had games where I had over 200 terraformers. You can imagine moving them around...
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on January 12, 2020, 12:30:16 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: JustAnotherDude on January 12, 2020, 01:33:16 PM
    Does the new rug order tractor one ship per tug, or one ship per TG?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 12, 2020, 01:38:42 PM
    Does the new rug order tractor one ship per tug, or one ship per TG?

    It tractors a single ship, so use one tug and set on repeat.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 12, 2020, 01:39:20 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Aldaris on January 13, 2020, 12:47:28 AM
    In the case of using tugs to speed up very slow but still (in principle) mobile fleets, might it be better to target the slowest ship instead of the biggest one?
    Title: Re: C# Aurora Changes Discussion
    Post by: Profugo Barbatus on January 13, 2020, 12:55:07 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on January 13, 2020, 05:27:23 AM
    That shouldn't be too difficult but even if it's not, with the new functionality of the TG window, you can quickly drag'n'drop them together and the game will automatically delete the empty TGs.
    Title: Re: C# Aurora Changes Discussion
    Post by: kks on January 13, 2020, 11:10:08 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on January 13, 2020, 11:31:08 AM
    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.

    Although you would need to have a task-group at that site to begin with to target for the release. So if there was nothing at the target location at the start of the order you would have to create an empty new task-group and then use SM to move it to the target location. Then you could issue orders to tractor stations to that task-group.

    At least that is how I remember things.
    Title: Re: C# Aurora Changes Discussion
    Post by: Tuna-Fish on January 14, 2020, 10:37:06 AM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 14, 2020, 11:17:33 AM
    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?

    That is already how it works.
    Title: Re: C# Aurora Changes Discussion
    Post by: Ranged66 on January 14, 2020, 05:25:15 PM
    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 :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 14, 2020, 06:29:27 PM
    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 :)

    I have no idea where the March 20th date came from. I've seen it occasionally on the Discord, but I have never said it. I'm also not going on leave anywhere :)

    I've ordered my first motorhome and the estimated arrival date from the manufacturer is March, so my wife and I will probably be spending part of our free time travelling around in that. That doesn't mean I will suddenly stop working on Aurora, but I will have less time for Aurora unless it rains all summer. March is therefore a convenient time to release what I have up to that point so players can start finding bugs.

    I'll probably never live it down that I ordered a French motorhome :) but here is what I am waiting for...

    https://www.rapido-motorhome.co.uk/motorhome_a-class_serie-80df_8096df.chtml
    Title: Re: C# Aurora Changes Discussion
    Post by: papent on January 14, 2020, 07:18:16 PM
    that's an awesome RV, do you have a shakedown trip preplanned for it or just going to make an Impromptu journey?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 15, 2020, 03:51:35 AM
    that's an awesome RV, do you have a shakedown trip preplanned for it or just going to make an Impromptu journey?

    Nothing specific planned yet. We live in the Isle of Man, an island that is only about 220 square miles (570 km) but is a great place for any outdoor activity and has at least twenty camp sites or other overnight motorhome sites. The island is the only entire country that is a UNESCO biosphere reserve. We plan to stay around the island for the first few weeks and get used to the van.

    Next, we will start using the ferry to the UK. The UK port is an hour from the England/Scotland border and Scotland is a great place for motorhomes. About 60% of the size of England with only a tenth of the population. Mountains, lochs, glens and huge open spaces where you can wild camp. The Motorhome has double the battery capacity of most similar vehicles, a good-size water tank and solar panels, so we can stay off grid for a few days.

    Late this year, or maybe next year, we plan to start taking longer trips to Europe. Initially, we will probably tour around France and Italy. After that, we will see what happens.

    BTW here is a 90 second video on the Isle of Man - you can see why it is a good place for a motorhome:

    If you want a longer video, this is about a 6m aerial view - no commentary, just music.
    Title: Re: C# Aurora Changes Discussion
    Post by: LoSboccacc on January 15, 2020, 04:31:17 AM
    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 weekends
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on January 15, 2020, 01:16:58 PM
    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 weekends
    Especially bank holiday weekends!  ;D
    Title: Re: C# Aurora Changes Discussion
    Post by: Bughunter on January 16, 2020, 03:06:45 AM
    He got electricity and space enough to fit his dual monitors in the RV, I don't see the problem here.
    Title: Re: C# Aurora Changes Discussion
    Post by: Shinanygnz on January 20, 2020, 02:49:35 PM
    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 weekends
    Especially bank holiday weekends!  ;D
    And particularly in Scotland
    Title: Re: C# Aurora Changes Discussion
    Post by: ZimRathbone on January 20, 2020, 11:42:12 PM
    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 weekends
    Especially bank holiday weekends!  ;D
    And particularly in Scotland

    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
    Title: Re: C# Aurora Changes Discussion
    Post by: sloanjh on January 21, 2020, 08:23:34 AM
    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 weekends
    Especially bank holiday weekends!  ;D
    And particularly in Scotland

    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 :)

    John
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 21, 2020, 09:03:36 AM
    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 :)

    Had a few days in the highlands last year with barely any sunshine at all. I still really enjoyed the trip :)
    Title: Re: C# Aurora Changes Discussion
    Post by: vorpal+5 on January 22, 2020, 12:14:33 AM
    50% rain for myself over a one week trip to Scotland.

    Isle of Skye is just incredible, I warmly recommend going there (outside of the tourist season).
    Title: Re: C# Aurora Changes Discussion
    Post by: sloanjh on January 22, 2020, 06:58:16 AM
    On the "Do Not Promote" flag:  Is this also known as "The Kirk Option"?

    John
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 22, 2020, 06:59:00 AM
    On the "Do Not Promote" flag:  Is this also known as "The Kirk Option"?

    John

    :)
    Title: Re: C# Aurora Changes Discussion
    Post by: JustAnotherDude on January 22, 2020, 12:47:42 PM
    Really liking what we're seeing with diplomacy so far! Seems much more dynamic then VB6, and the first-contact element much more interesting.
    Title: Re: C# Aurora Changes Discussion
    Post by: Alsadius on January 22, 2020, 01:42:43 PM
    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)
    Title: Re: C# Aurora Changes Discussion
    Post by: DEEPenergy on January 22, 2020, 05:10:45 PM
    Diplomacy looks really fun so far. Looking forward to being able to tell aliens to shoo and stake a claim on a system.
    Title: Re: C# Aurora Changes Discussion
    Post by: Kristover on January 22, 2020, 05:53:40 PM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 22, 2020, 06:18:50 PM
    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?

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on January 22, 2020, 07:54:29 PM
    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)

    No it matters. Given how little the diplomacy system will take up in processing time it probably won't matter, but less code to run and less actions to take is less time it takes to process.

    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.

    It would be realistic for it to stack in a limited manner though. It's not as if having dozens if not hundreds of diplomatic staff handling a large number of issues and treaty minutiae with another polity is unrealistic; it won't necessarily improve relations much faster, but it'd get things worked out and done quicker.
    Title: Re: C# Aurora Changes Discussion
    Post by: AlStar on January 22, 2020, 11:21:33 PM
    It's an interesting question - on the one hand, it makes sense that a race would only nominate its most talented diplomat to represent them; so it would makes sense for only your best and brightest to make contact with the aliens....

    On the other hand, it could also be hilarious if your Jean Luc Picard-like diplomat's positive influence was dueling with your Zapp Brannigan-like diplomat's negative influence...
    Title: Re: C# Aurora Changes Discussion
    Post by: DIT_grue on January 23, 2020, 03:44:28 AM
    Quote
    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

    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 23, 2020, 05:08:33 AM
    Quote
    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

    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?

    25 * 1
    Title: Re: C# Aurora Changes Discussion
    Post by: db48x on January 23, 2020, 06:25:23 AM
    Steve, have you considered whether crew deaths are worth diplomatic points? What about rescuing crew and returning them later?
    Title: Re: C# Aurora Changes Discussion
    Post by: sloanjh on January 23, 2020, 08:22:22 AM
    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)

    It actually does matter if you're using integer arithmetic :)

    John
    Title: Re: C# Aurora Changes Discussion
    Post by: Titanian on January 23, 2020, 09:03:17 AM
    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).
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on January 23, 2020, 09:17:17 AM
    I read it as "a population counts as a diplomacy module"
    Title: Re: C# Aurora Changes Discussion
    Post by: Kristover on January 26, 2020, 11:40:43 AM
    I like the changes outlined in both Diplo 1&2 posts on the Change Lists.  It seems to me that the system outlined will lend itself to a slow build of tensions and hostilities - unless you meet a REALLY xenophobic race - rather than an all or nothing war.  It will be interesting to see how wars are handled in a diplomatic context if less xenophobic or ruthless races will confine themselves to just 'claims' so you can fight a limited border conflict for a system or if wars of extermination will occur.

    One question right up front:  Will there be a some sort of graphical representation indicating alien claims?  Colored rings on the galactic map?  Something on the system map or in the race intelligence file?  Or a separate new diplomatic screen?
    Title: Re: C# Aurora Changes Discussion
    Post by: the obelisk on January 26, 2020, 12:46:14 PM
    Quote
    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.
    ...
    Allied Races do not receive warnings as they can freely enter the NPR territory.
    So you can colonize an allied race's territory?
    Title: Re: C# Aurora Changes Discussion
    Post by: Froggiest1982 on January 26, 2020, 02:45:38 PM
    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).

    I believe for Multi-Racial start on the same planet (I don't think you can actually extend to the system, that would be nice) there's still the flag "Truce" which will allow you to set up a minimum period where it will be not possible to actually go to war. The rule applies to NPRs as well.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on January 26, 2020, 02:57:01 PM
    So you can colonize an allied race's territory?

    I sure hope so; otherwise all those nifty extras that come from having populations on the same bodies as foreign populations will be a whole lot less useful.
    Title: Re: C# Aurora Changes Discussion
    Post by: Triato on January 26, 2020, 03:01:26 PM
    Would alien races accept a shared ownership of a system or planet? Would you be able to offer money, treaties, systems or planets in exchange for the same things with an NPR?

    The diplomacy system sounds great!
    Title: Re: C# Aurora Changes Discussion
    Post by: Rabid_Cog on January 27, 2020, 01:36:39 AM
    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
    Title: Re: C# Aurora Changes Discussion
    Post by: alex_brunius on January 27, 2020, 01:59:58 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bughunter on January 27, 2020, 05:05:43 AM
    Would be nice if a friendly race just trying to communicate generated the same unintelligible message before language has been translated so you cannot be sure what they are trying to say  :)
    Title: Re: C# Aurora Changes Discussion
    Post by: JustAnotherDude on January 27, 2020, 06:53:38 AM
    That would sort of defeat the point, wouldn't it?
    Title: Re: C# Aurora Changes Discussion
    Post by: Rabid_Cog on January 27, 2020, 08:30:37 AM
    No I think that would BE the point? You haven't translated their language, so you cannot use metagaming knowledge to deduce what the threat level is.

    I don't think it would actually give you the gibberish message, though. I think the system would just tell you that you have received an unintelligable communication from somewhere.

    My question is, are there other potential unintelligable messages you can receive such as "Hello! How are you? Welcome, friend!" so that the fact you receive such a message does not immediately make you realize that you are in another race's claimed space? Perhaps all "first contact" messages should look the same, so you can't tell the difference between a friendly greeting and a trespass warning.
    Title: Re: C# Aurora Changes Discussion
    Post by: JustAnotherDude on January 27, 2020, 08:44:32 AM
    Oh, sorry, I misunderstood the original message. We're on the same page, lmao, I totally agree with you.
    Title: Re: C# Aurora Changes Discussion
    Post by: Triato on January 27, 2020, 11:14:41 AM
    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 they haven' see you fire before they can't have signature data on your weapons. Weapon signature data could be part of the intelligence system.
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on January 27, 2020, 11:37:41 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Rabid_Cog on January 28, 2020, 01:16:31 AM
    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.

    In this particular case I feel the coding and complexity burden outweighs the gameplay/fun benefit. It's such a niche event that requires a ton for the program to keep track of and a lot of custom code. Perhaps as part of a greater "Stealth and Sensors Expansion" but not as a standalone feature. AI would struggle to deal with it too much I believe.

    Yes I know it was me that brought up the idea, but I was half-joking  :D
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on January 28, 2020, 02:44:17 AM
    "Let's see. We can't detect anything, but ships on our border with the humans keep being destroyed by stealth missiles. Nope, no idea what could be going on."

    I have to agree with the current version - if you destroy an NPR ship, even without being detected, you should take a relations penalty. They would eventually figure out what's going on.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jovus on January 28, 2020, 04:36:09 AM
    I'd be fond of a time-lag for the penalty based around whether or not you were detected, how much the NPRs know about your methods, and whether you're attacking from an obvious vector, but that seems like a lot of work for very little gain.
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on January 28, 2020, 08:07:32 AM
    I grant you its probably better for AI reasons if nothing else.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on January 28, 2020, 11:58:49 AM
    For a simple version, if the perpetrator is not identified the Diplomacy penalty could be reduced by half, or four-fifths, or something, and assigned to the 'nearest' (known) Empire.

    This way a known neighbour might cop the blame at first for a new enemy, or a stealth force can stir up trouble between two other empires.
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on January 28, 2020, 05:22:15 PM
    I do like the idea of that, but I think it does suffer from similar issues of the ai not being smart enough to deal with that, making it excessively vulnerable.
    Title: Re: C# Aurora Changes Discussion
    Post by: Kristover on January 28, 2020, 05:54:44 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 28, 2020, 06:13:11 PM
    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.

    Yes, one factor that will make this very important is that an NPR will regard a system as important because of its proximity to vital systems. The system you are in right now might be apparently useless, but if it is next door to the capital or a core system, the NPR will judge it to be valuable as a buffer, rather than because of any intrinsic value.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on January 28, 2020, 07:39:59 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Desdinova on January 28, 2020, 08:22:20 PM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on January 29, 2020, 12:45:20 AM
    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.

    The general impression I was getting is thats kindof how its supposed to work already, you just keep degrading relations until they either decide to kill you or give in.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bughunter on January 29, 2020, 02:28:56 AM
    A forced relocation option for dumping populations you don't want from recently diplomatically acquired systems would also be nice.

    Or conquered ones, for example after a peace has been agreed. Could even be part of a peace agreement that you cede the system as long as you are allowed to evacuate the population.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 29, 2020, 03:29:34 AM
    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?

    It is based on all military-engine ships that the NPR has detected and has not seen destroyed. The NPR is assessing whether you could take and hold the system long-term or threaten its territory in general, rather than whether you could take that system immediately. If the threat was assessed only on a local basis, you could simply sail the same fleet to half a dozen systems and claim them all. The NPR also doesn't take into account any bases you have as they could not threaten the system or its other territory.

    For example, NATO wouldn't give up the Baltic States if Russia stationed a large force on the border and demanded their surrender. However, If Russia had a clear overall military superiority and did the same, then I am sure there would be a few wavering Western politicians.

    There is a slight 'cheat' here as the NPR is given information on whether your ships are military or commercial engines. In fact, I will probably add that to thermal detection for everyone at some point.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 29, 2020, 03:36:33 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: sloanjh on January 29, 2020, 07:58:18 AM
    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
    Title: Re: C# Aurora Changes Discussion
    Post by: LoSboccacc on January 29, 2020, 08:24:21 AM
    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
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on January 29, 2020, 09:08:48 AM
    I must say that I think the new diplomacy rules seem very interesting, I would like to give some suggestion for you as well.

    I think that it might be important that relationship between OTHER empires also have an impact in diplomacy. So if Empire A is at war with Empire B then it will have a problem with diplomatic actions with Empire C who has positive relations and strong commercial ties with Empire B.

    I also would like if we could use diplomatic actions to negotiate or influence relationships between OTHER empires. Perhaps we have good relations with Empire B and C but they are between themselves not in a good spot... you could then use your good standing with both of them to increase the relations between them as well, perhaps tarnish your standing with both of them to some extent in the process.

    Especially the second point is what I find lacking in many game as diplomatic actions most often are a one way street while in reality it is so much more complex and dynamic. You obviously could try to sabotage relations as well, but different actions should have different consequences obviously.

    I really think you have a very good template for an interesting diplomacy system. The way that you incorporate the other elements of the game mechanic into the diplomacy is really good and makes for a much better and immersive experience, that is my immediate take away from reading it.
    Title: Re: C# Aurora Changes Discussion
    Post by: LoSboccacc on January 29, 2020, 09:22:56 AM
    would be awesome to do false flag operations with captured warship, who said Geneva convention would apply to aliens anyway
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on January 29, 2020, 09:30:29 AM
    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.

    True, but at the same time with a diplomatic envoy on station and a slow trigger it would just be one of those 'tension exists between nations due to competing claims' things. Sometimes you don't want to just start shooting, although in that case you need an internal stability and casus belli system for best modeling. At the same time, repeated 'please do not go there' messages should affect the calculus for system development and expansion of the relevant empires.

    Is there feedback beyond handover of colonies and ships evacuating a system for diplomatic messages? It'd be useful for estimating what another empire thinks of the situation and how willing they'd be to push an issue.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 29, 2020, 11:41:28 AM
    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

    Yes, good point. I've updated to use NPR and Player to avoid confusion.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 29, 2020, 11:44:00 AM
    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

    I forgot to include in Part 3 that allied or hostile NPRs will not receive the message. I did mention it for NPR vs Player in Part 2. I've updated the text.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on January 29, 2020, 05:37:28 PM
    It is based on all military-engine ships that the NPR has detected and has not seen destroyed. . .


    Oh dear. . . my 'we mostly build commercial-engined warships at low tech levels' empires are going to "live in interesting times" as certain ancient Chinese might say.
    Title: Re: C# Aurora Changes Discussion
    Post by: Draco_Argentum on January 30, 2020, 02:24:44 AM
    Is there any differentiation between "please don't colonise this system but ships can pass through" and "don't come here at all"? I'm just wondering how establishing contact works if the "please leave" option means their/our diplomacy ship has to go.
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on January 30, 2020, 02:28:58 AM
    Its kindof a good point that those should probably be separate in general.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bughunter on January 30, 2020, 02:45:57 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Zincat on January 30, 2020, 03:58:07 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 30, 2020, 07:17:56 AM
    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.

    When a race refits a ship, it is removed from the intelligence information of other races. This is a little draconian, but prevents confusion over class and armament when it is seen again. I didn't have this restriction at first, so the same ship ended up with weapon data from multiple classes. This removal will also help with insuring that NPRs do not double-count ships. The alternative was to have the ship change classes once detected again and clear the associated data, but I thought that was open to potential bugs, plus I would be checking every detected ship in every detection phase to look for class changes.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on January 30, 2020, 01:33:26 PM

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Alsadius on January 30, 2020, 03:08:35 PM
    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.

    Yeah, I think the concept of an open borders treaty is the right fix here(conditional, as always, on Steve's free time), which is why a lot of 4X games do things that way.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on January 30, 2020, 04:08:56 PM
    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.

    "Trade treaty" is basically 'non-military shipping only' access in VB Aurora, so I assume it will be the same for C# Aurora.  And once you ahve a trade treaty in place, both your and their civilians will attempt to move trade goods regardless of ownership of the origin & destination colonies.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bughunter on January 31, 2020, 03:44:13 AM
    It would be great if you could agree to allow access to only some systems and not just an all or nothing open borders treaty. It would have the same effect of course if no one is claiming that border system. And empty systems would not be valued very high unless they are right next to your core. Maybe there could be some agreement that both empires agree to not make claims on a certain system? A neutral zone. But would be tricky for the AI to value that correctly.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on January 31, 2020, 12:58:55 PM
    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.

    I've added this and updated the original post. Only ships detected in the last five years are counted. Destroyed ships will be counted, unless the NPR knows they were destroyed.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on January 31, 2020, 07:49:34 PM
    IIRC the intelligence system allows for the acquisition of information from a system that is otherwise not immediately visible, like data on the production or ship construction in systems you have no presence in or even have never physically visited. This includes data on ships, classes, and the number of ships of a given class in operation by an empire. This information probably should reset the timer on ships that haven't been seen for a while, even if that ship is strictly speaking on the other end of the empire rather than on your own border and exposed to your sensors.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on February 01, 2020, 08:50:23 AM
    I don't think that's possible in the Intelligence system:

    http://aurora2.pentarch.org/index.php?topic=8495.msg109678#msg109678

    Quote
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jovus on February 02, 2020, 08:43:10 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Kristover on February 02, 2020, 08:54:59 AM
    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. 
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 02, 2020, 09:01:42 AM
    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.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jovus on February 02, 2020, 09:01:59 AM
    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.

    I think we're thinking about it in two different ways. You're coming at it from a simulation or story point of view, which I laud. I'm considering it from a code point of view strictly.

    I'm under the impression (maybe this is different for C#) that only one race can occupy a given colony at a given time. If that restriction holds true, the new race isn't going to move about the Empire - there's nowhere they can go unless you set up new colonies for them. Further, they'll be a bit of a pain for the player, as you have to consistently make sure the correct brand of actually-identical human is ending up on the new colony you want to set up. Not a big deal for just taking back one rebellious colony, but what about ten?
    Title: Re: C# Aurora Changes Discussion
    Post by: Jovus on February 02, 2020, 09:03:01 AM
    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.

    Thanks, Steve. That underlined part shows my concern not to be an issue. Appreciate it.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 02, 2020, 09:04:20 AM
    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.

    Xenophobia, etc. are at the species level, not race (empire) level. In fact, I should probably have taken the opportunity to rename Race as Empire in C# :)

    Race Xenophobia is a weighted average of all species xenophobia  in the Empire.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on February 02, 2020, 12:21:48 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 02, 2020, 12:47:43 PM
    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.

    Yes, you can do both.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jovus on February 02, 2020, 01:34:44 PM
    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!"
    Title: Re: C# Aurora Changes Discussion
    Post by: LoSboccacc on February 03, 2020, 03:20:09 AM
    > spawned as an NPR?

    gundam campaign here we come
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 03, 2020, 04:19:28 AM
    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!"

    I will definitely look at the idea of rebellion spreading or the idea that multiple colonies could rebel together (including perhaps local civilian mining colonies), but probably not the mineral/industrial element. Historically, rebellion or revolts are often not based on whether the rebels believe they can create an economically sustainable nation, but rather a reaction to an intolerable situation without necessarily having a long-term plan.
    Title: Re: C# Aurora Changes Discussion
    Post by: Kiruth on February 03, 2020, 05:11:05 AM
    Regarding the Independece rules what would be the diplomatic  stance of the new empire? It will be acquired from the old race as everything else (eh.  the old race is at war with an NPR, so the new one will be as well) or it will be more nuanced?

    Also I expect very different relation between an ex colony and the "main" empire that has granted Independence (maybe based on unrest at the time of Indipendece) versus a colony that has declared Independence through rebellion. 
    Title: Re: C# Aurora Changes Discussion
    Post by: vorpal+5 on February 03, 2020, 05:21:39 AM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 03, 2020, 05:57:50 AM
    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?

    Yes, there will be insurgents involved. I'll cover rebellions in the next post.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on February 03, 2020, 06:27:50 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Kristover on February 03, 2020, 07:54:58 AM
    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.

    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....
    Title: Re: C# Aurora Changes Discussion
    Post by: Tikigod on February 03, 2020, 08:33:15 AM
    Quote
    The title of the new race will be based on the name of the newly-independent population.

    This is purely a flavour preference, but in the cases of natural gained independence (like rebellion) is there any chance the newly found race (Empire) generates a names for itself based on a combination of their assigned racial naming convention and main source that drove the push for independence?

    So there a colony that rebels with the main reason for dissatisfaction being lack of military protection might name itself something like "<Racial Flavour name> Militia Force".

    Whilst a colony that rebels with the main reason for dissatisfaction being overpopulation or living conditions name itself something like "<Racial Flavour name> People's Front".


    Whilst not something I'd expect in the base files, maybe even having identifiers in the naming convention that allows for manually populating specific flavour variants for naming lists would be pretty interesting to allow custom naming entries to come up with some cool variants.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 03, 2020, 09:35:00 AM
    Maybe they should all be based on different variations of the People's Front of Judea :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on February 03, 2020, 01:15:38 PM
    As long as we can rename them, when under player control, it's all good.
    Title: Re: C# Aurora Changes Discussion
    Post by: Tikigod on February 03, 2020, 05:50:24 PM
    As long as we can rename them, when under player control, it's all good.

    Personally I'd love to see colonies rebel and then make sure I release all control of them and let them become their own super power over time, which is why it would be cool for flavour reasons if break away colonies had names that reflected their origins in some way.

    Edit: Without having to micromanage every occurrence through SM or similar I mean. I am more than happy to spend a hour or more populating naming lists if those names can then be seeded into new independent colonies across each campaign I have going, but the idea of dropping everything when playing anytime a colony goes independent to rename them would get annoying pretty quickly.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on February 03, 2020, 07:13:08 PM
    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....

    Less untrue then you think. A number of revolutions in the 20th and early 21st century happened with little bloodshed because the national military basically went 'you know what, these guys are right, the boss is a terrible jerk and we'd like to be rid of him too' and promptly either helped or stood aside. This is one of the reasons why dictatorships depend on mercenaries for at least part of their military might.

    Because you can buy the loyalty of mercenaries and they mostly don't care about what the locals think so long as they get paid. Conscripts and volunteer soldiers from your own nation? They do care, because they are also people from the country the dictator is running.

    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on February 03, 2020, 11:10:51 PM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: MarcAFK on February 03, 2020, 11:56:15 PM
    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".
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on February 04, 2020, 12:46:34 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on February 04, 2020, 01:12:49 AM
    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.

    To be honest troops stationed anywhere in particular long enough become local population no matter you like it or not. Unless you are willing to continually rotate troops around or have access to foreign mercenaries that can be hired for short time frames and redeployed on occasion then the troops will become part of the population eventually.

    If the troops are from a different species things might be different though... but then you still probably would assume they have their families there with them if they are stationed there for a very long time.
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on February 04, 2020, 01:23:45 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on February 04, 2020, 07:49:58 AM
    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.

    I would agree that this rationalisation work to a certain degree. It completely depend on the situation and why a rebellion occur. A democratic nations soldiers being stationed in an otherwise democratic area that simply want independence  might very well gain the sympathy of the soldiers stationed there and they will basically react with apathy or even go over to the other side if they have families there.

    The soldiers might view the local population as otherwise friendly and see how corrupt their own government is in comparison in other circumstances. Or simply they don't want to risk their life for a cause they don't believe in.

    There can be many scenarios where no matter what you do it will not be enough as it is mainly a war of ideologies and not weapons.

    The war in Vietnam that started long before even WW2 was mainly a war of ideologies too... it was not directly won with weapons. As one example...

    From a role-play perspective you can rationalise it either way.

    If Steve want to incorporate some details you could perhaps choose the type of forces in on a planet. Are they local militia, regulars or galactic troops. How are they interacting with the locals, do they interfere with local government, policing the streets or outright suppressing the populations using harsh means. Whatever you decide to do it would then have consequence on what can happen on that planet.
    Having the force being local regular soldiers means they cost normal maintenance while having galactic troops would raise the maintenance on the troops but also make them more loyal to the central government.

    It then also would be important which planet is the empires capital as galactic troops there should cost normal maintenance.

    Then what happens on a planet should then depend on the galactic states government for and the rebellious planets government form. Is it more of a peaceful independence movement or an outright rebellion that even might lead to a big civil war including multiple colonies and systems defecting to the new faction.

    There probably are as many reason to rebellion and civil war as they are rebellion and civil wars...   ;)
    Title: Re: C# Aurora Changes Discussion
    Post by: Tikigod on February 04, 2020, 09:29:24 AM
    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".

    Ok, I'll give you that.

    But beside huge tracts of land, what have the Precursors ever done for us?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 04, 2020, 11:07:19 AM
    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".

    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: kuhaica on February 04, 2020, 12:04:51 PM
    Quote from: Steve Walmsley link=topic=8497. msg118558#msg118558 date=1580836039
    Quote from: Tikigod link=topic=8497. msg118555#msg118555 date=1580830164
    Quote from: MarcAFK link=topic=8497. msg118529#msg118529 date=1580795775
    Quote from: Father Tim link=topic=8497. msg118527#msg118527 date=1580793051
    Quote from: Hazard link=topic=8497. msg118522#msg118522 date=1580778788
    Quote from: Steve Walmsley link=topic=8497. msg118496#msg118496 date=1580744100
    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".

    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?

    Xenos? Building things.  Impossible.  It was clearly those missing scientists who built it before continuing their great journey to explore the stars for all of mankind.  Just ignore those wrecks over there. 
    Title: Re: C# Aurora Changes Discussion
    Post by: Tikigod on February 04, 2020, 12:22:51 PM
    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".

    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on February 04, 2020, 12:42:04 PM
    (https://i.kym-cdn.com/photos/images/newsfeed/001/039/387/708.gif)

    And now for something completely different.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 04, 2020, 03:23:22 PM
    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".

    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?

    They left those ruins, with all the installations and tech.
    Title: Re: C# Aurora Changes Discussion
    Post by: vorpal+5 on February 05, 2020, 12:44:41 AM
    I personally find that robotic defenders should be slightly more 'proactive', they feel too much like orbital roadblock and that's it. But IMHO obviously.
    Title: Re: C# Aurora Changes Discussion
    Post by: Profugo Barbatus on February 05, 2020, 04:47:40 PM
    I always headcanon'd that these robotic defenders are being very conservative because they can't replenish their losses, since I've never seen their forces expand. Makes sense to take a defensive posture. Sometimes its because they are expecting reinforcements from a dead empire, sometimes its because they lost their factories to decay (ruins, anyone), sometimes its just because they're not expected to have been eternal protection, depends on my RP in a game session.
    Title: Re: C# Aurora Changes Discussion
    Post by: Ektor on February 07, 2020, 06:20:58 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on February 07, 2020, 08:55:12 PM
    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.

    They don't always ask you to leave, and if you show them the jump point there's a good chance they'll follow you through and you can talk in the system next door.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on February 08, 2020, 06:55:11 AM
    If your ship doesn't have active sensors and it's small, the malus it causes is minimal.
    Title: Re: C# Aurora Changes Discussion
    Post by: vorpal+5 on February 08, 2020, 11:10:49 PM
    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
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 09, 2020, 07:05:06 AM
    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

    Yes, I'm aware of the radiation risks with some red stars. I considered having some systems with high radiation on planets closer to the star, but in a real stars game a high proportion of stars are red dwarves so it would have a big impact and it doesn't really add any significant game play decisions. Maybe if I add some technology to protect planets from solar radiation it might be an option.
    Title: Re: C# Aurora Changes Discussion
    Post by: TMaekler on February 09, 2020, 07:28:36 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 09, 2020, 08:29:37 AM
    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.

    It will try to conquer that system if relations fall far enough. Once an alien race is declared hostile, any prior territorial agreements are ignored.
    Title: Re: C# Aurora Changes Discussion
    Post by: Froggiest1982 on February 09, 2020, 02:28:05 PM
    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
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on February 09, 2020, 03:38:28 PM
    Deleting a star deletes all planets orbiting it. Deleting a planet deletes all moons orbiting it and every colony on it. So I would say that deleting a star leads to everything else orbiting that star vanishing as well.

    These new possibilities can be quite useful but are definitely a big risk of accidentally messing up your game  :o
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 09, 2020, 04:11:40 PM
    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

    The intention of the star system design functionality is to build starting star systems for RP purposes, rather than for deleting parts of systems mid-campaign. I would not recommend the latter unless you are sure about what it is in the system. The "are you sure" popups before any deletion happens warn that affected populations will be deleted. However, the specific example above wouldn't be a problem because an NPR would not be generated in a location that cannot easily reach the primary star.

    Even if an NPR or other population was on the system body, there are a lot of safeguards in place in C#. When a population is deleted, the following are also deleted; Research projects, queued research, sectors, admin commands, contacts for the pop/SY/ground forces, all fleet orders for fleets that had the pop as a destination, shipyards, shipyard tasks, commander assignments and ground forces. The NPR would still function in this scenario, even if you just deleted its capital, but it wouldn't be much of a threat.

    BTW I assume you mean Delete. Cancel means you are NOT deleting or modifying the star.
    Title: Re: C# Aurora Changes Discussion
    Post by: JacenHan on February 09, 2020, 04:13:35 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Froggiest1982 on February 09, 2020, 06:21:52 PM
    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.

    I see; I've I haven't tried that ever I think.
    Title: Re: C# Aurora Changes Discussion
    Post by: chrislocke2000 on February 10, 2020, 03:28:27 AM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 10, 2020, 04:19:40 AM
    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?

    Yes, or you can specify the minerals individually.
    Title: Re: C# Aurora Changes Discussion
    Post by: TMaekler on February 10, 2020, 05:16:15 AM
    In VB6 research was bound to a planet. If you started research on one planet, stopped it and continued it later on another planet, it didn’t use the already done research on the former planet. You had to start from scratch or finish it on the former planet. Will that change in C#?
    Title: Re: C# Aurora Changes Discussion
    Post by: Alsadius on February 11, 2020, 04:00:57 PM
    Quote
    The Add Lagrange button adds a Lagrange point to the currently selected body, even if it would not normally qualify for one.

    Is there a Remove Lagrange button as well? Or would you need to delete the body and try again?

    Edit: I see this was addressed in a subsequent post. Thanks.
    Title: Re: C# Aurora Changes Discussion
    Post by: Titanian on February 12, 2020, 06:34:54 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 12, 2020, 07:15:05 AM
    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.

    As things stand, I could add an option to remove all Trojan asteroids for a specific body or all asteroids for a specific star, but not an 'asteroid belt'. Once the asteroids are added there is no association between them. Until now, that wasn't an issue :) 

    The other option is to create some form of asteroid belt identifier, which shouldn't be too difficult.

    EDIT: Asteroids now have a belt identifier, so I will be able to delete an asteroid belt.
    Title: Re: C# Aurora Changes Discussion
    Post by: Tikigod on February 12, 2020, 05:42:43 PM
    EDIT: Asteroids now have a belt identifier, so I will be able to delete an asteroid belt.

    Awesome!  ;D ;D
    Title: Re: C# Aurora Changes Discussion
    Post by: Iranon on February 22, 2020, 04:40:57 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Ektor on February 24, 2020, 06:47:34 PM
    I just want to express how grateful I am for the new ability to add Commander themes.  I have a couple of conlangs and I'd love to use them as a base for my Aurora Empires.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on February 24, 2020, 08:15:11 PM
    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 few points you might not have considered...

    Low tech rail-guns already are extremely useful in VB6 and perhaps even more so because of the maintenance system. 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. As the failure now are 1% I don't see this to be overly prohibited in most situation even if you go with slightly higher quality.
    To be honest I don't think that the failure rate will change how battles are fought at all and how you build the ships and with which weapons... it will change your logistics as all ships will need some logistics to maintain them for long operations even more than before. To be honest I don't think that you will ever empty a ships full MSP stores in a combat unless you are very unlucky or you have very highly specialised ships with extremely small MSP storage. I would say it is a mechanic that actually give a small incentive towards more balanced designs in general as you would then have way more MSP on the ship for each weapon.

    Adding allot of engineering to ships to crank up the maintenance cycle is not going to be economically that feasible more than before, it will still take a considerable amount of space on the ship you could use for other stuff. Ships really have very limited space to work with once you consider engines, fuel, crew space and engineering. In most cases you are lucky if a ship get more than 50% actual mission tonnage on them which needs to be divided into armour, shields, weapons and sensors.

    Box launchers in hangars is not also really the problem either... it is that hangars is a very simplistic mechanic and need role-playing to compensate for it. Attaching a 2000t box launching platform in a 2000t hangar is a misuse of the system in my opinion and you should simply not do it. The intent of box launchers is not to mass use them on regular ships and like so many other mechanics in Aurora you don't have to abuse them, there are many ways to break the system if you really try.
    I think a more elaborate hangar mechanic would make more sense than changing how box launchers work as I think they seem fine in general. This is simply something you will have to role-play in the mean time.

    I do agree that particle beams really need some love... they are utterly crap... especially with the failure rate mechanic in place. They need some overhaul to become interesting.

    In my opinion the new C# give incentives to both large and small ships which really is interesting. Many things point towards small ships being more effective such as sensors as one example, you then have efficiency of component that makes larger ships far more value for your money. The new maintenance system certainly favour larger ships as a small ships takes up proportionally the same cost in facilities now.

    Extremely fuel efficient engines obviously usually means larger or more engine to tonnage ratio (if you want the same speeds)... which then leads to that you need more maintenance facilities wherever you want to station ships. Fuel efficiency have always been an issue so that is not new.

    Missile combat have always been about being able to overload the enemy point defence and that will not change. Even if PD have been made somewhat more effective then beam PD still struggle to engage really large salvos. Regular launchers have always been bad and extremely inefficient against a similar technological strong opponent who has a well rounded PD shield around their fleets and planets. Weapons failure rate will hardly make a difference in any ONE engagements, I think that will be rare. Having to buy less fire-controls is nice but not as terrible as one might think in the end as it also solves gamey ways to combat the fire-control mechanic.
    I would not be against a better salvo mechanic and I do hope that Steve will eventually come around and do a re-haul of how it works. A one that fire-controls actually controls targets, missiles and tracking data and they do have a limit to their capacity. Perhaps together with an even more and interesting electronic combat mechanic.
    But as is I don't think it will be worse than before... I think it will be better now as you don't have to abuse certain things which before was difficult as you unintentionally had to due to the salvo mechanic.
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on February 25, 2020, 12:57:58 AM
    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).
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on February 25, 2020, 01:30:12 AM
    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).

    Yes... the new maintenance system will favour quality over quantity allot more now than before. If you have a fleet of 100.000t you need to build that wherever you like to station it. So you might need to build up several places with that tonnage not just in one place, unless you have a really small empire and all your fleets will be stationed more or less in your capital. In any way... you are more likely to need more maintenance facilities in general now if you want some flexibility in where you can station your fleets. You can still maintain ships even if you over stack but that means that the maintenance clock just runs much slower and that might be something you are willing to accept now sometimes.

    As your maintenance facilities are based on a set number of tonnage it will be more important than ever to make sure you get as much out of every ship stationed there as possible, especially when you consider that maintenance also often will cost you population unless you build them in space where they are more vulnerable to enemies and more expensive.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on February 25, 2020, 06:20:25 AM
    And if you over stack enough you can't even run a ship building program, because the shipyards will be busy overhauling lest everything explode. Or explodes even while you are overhauling everything because there's just too much. I agree it's a good change though.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on February 25, 2020, 08:02:17 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 25, 2020, 08:40:04 AM
    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.

    The overhaul goes more slowly. If you are double-stacked, the overhaul takes twice as long.

    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on February 25, 2020, 10:46:09 AM
    An interesting question for you Steve... have you ever considered to extend the failure system or something like it to all components. I mean it is one thing for the maintenance cycle to advance slowly if a ship is sitting in space doing nothing. But a ship that is actively moving and using active sensors, shields and all that stuff should wear out allot faster...  I mean you sort of symbolise that when ship are training.

    At some time you might do a maintenance system based on components but still have it impact the whole ships maintenance as a whole to avoid micromanagement. With that you would run up the maintenance of ships the more they are in active use which seem quite relevant. Whenever a component is in active use there would be a small chance of a failure... for engines it could be a logarithmic scale on the speed used (perhaps more lenient in the AI though) which would then make it more economical to run the ship at a lower speed unless you need the speed. You also could have technologies and options for reliability on your engines as well for example.

    It does not have to be as complex... just something that impact your decisions on how active your ships are and a design choice if you want the ship to be more or less active during its career. A patrol ship would sacrifice some tonnage for more reliable systems as they will be active allot more while a missile boat don't need it as they only will be active if there is a need for them. The same for your fleet... if you mainly intend the fleet to be defending your space you can sacrifice some reliability but if you intend your ships to go on long voyages you will need to design them with more reliable systems.

    It kind of work like this even now... but I generally think that it often is a bit too easy to get really long maintenance cycles on ships. It would also be interesting of there are real trade off in the way you actually can use the ships in terms of your economy and strategic use of them.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on February 25, 2020, 11:57:40 AM
    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.

    Quote
    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.

    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.

    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on February 25, 2020, 09:30:12 PM
    The one thing that "might" make area fire beam weapons somewhat useful in the new version is if long range missiles tend to be rather slower now. That actually could make area fire weapons more useful despite the MSP cost for failures.
    Title: Re: C# Aurora Changes Discussion
    Post by: L0ckAndL0ad on February 27, 2020, 10:07:56 AM
    Quote from: Steve Walmsley
    Ship Achievements

    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.
    Would carriers get the achievements based on the actions of the parasite craft assigned to them?

    Off-Topic: show
    (https://www.navalaviationmuseum.org/wp-content/uploads/2019/01/hornet-scoreboard.jpg)

    (https://crashmacduff.files.wordpress.com/2015/06/174.jpg)
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on February 27, 2020, 10:33:34 AM
    Quote from: Steve Walmsley
    Ship Achievements

    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.
    Would carriers get the achievements based on the actions of the parasite craft assigned to them?

    Off-Topic: show
    (https://www.navalaviationmuseum.org/wp-content/uploads/2019/01/hornet-scoreboard.jpg)

    (https://crashmacduff.files.wordpress.com/2015/06/174.jpg)


    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on February 27, 2020, 11:41:39 AM
    I never knew that I wanted ship "scores" like that and now I wonder how I have managed to live without it!

     ;D
    Title: Re: C# Aurora Changes Discussion
    Post by: Tikigod on February 27, 2020, 12:12:37 PM
    Quote from: Steve Walmsley
    Ship Achievements

    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.
    Would carriers get the achievements based on the actions of the parasite craft assigned to them?

    Off-Topic: show
    (https://www.navalaviationmuseum.org/wp-content/uploads/2019/01/hornet-scoreboard.jpg)

    (https://crashmacduff.files.wordpress.com/2015/06/174.jpg)


    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.

    Similar to the personnel system recently discussed, any chance of having a ship service history log for looking back at notable ships and their achievements? As the change details only appear to mention currently active ships having their achievements observable.

    As part of avoiding bloat, would make sense if it only ever recorded military designated vessels and their accomplishments.
    Title: Re: C# Aurora Changes Discussion
    Post by: sloanjh on February 28, 2020, 09:52:57 AM
    Quote from: Steve Walmsley
    Ship Achievements

    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.
    Would carriers get the achievements based on the actions of the parasite craft assigned to them?

    Off-Topic: show
    (https://www.navalaviationmuseum.org/wp-content/uploads/2019/01/hornet-scoreboard.jpg)

    (https://crashmacduff.files.wordpress.com/2015/06/174.jpg)


    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.

    This brings up the question of whether you want to have fleet formations also track accomplishments of their constituent ships.  On the plus side it would give some storytelling flavor to e.g. "the famous 7th fleet".  On the minus side if the design paradigm is that fleet instances can be easily thrown away, then there might need to be a lot of support coding to make sure that people don't accidentally kill off a beloved fleet.

    John
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on February 28, 2020, 11:52:34 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Kristover on February 28, 2020, 12:21:24 PM
    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.

    This sounds a lot like what I plan to do with my C# Federation play-through where I plan each Naval HQ to be a Fleet HQ building.  I tend to write lots of notes on my Commanders and Ships and could easily see doing this for the 'Fleet HQ' if there is a similar note structure.
    Title: Re: C# Aurora Changes Discussion
    Post by: Iranon on March 02, 2020, 01:46:32 AM
    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.

    Quote
    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.

    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.

    Regarding ranges relative to closing distances: A WW2 battleship may cover its extreme weapon range in about half an hour (30kn, 30km).  A "standard" speed ship in Aurora can typically cover maximum BFC range about a minute (e.g. 4000km/s, 256000km). That's the hard limit, not the limit after which  ammo/wear considerations become prohibitive. Aurora ships can realistically be much faster than the "standard", and fast ships enjoy a larger relative speed advantage over slow ships: In Aurora, relationship between speed and required power is linear rather than cubic. A battlecruiser with twice the propulsion power of an equal-sized battleship will actually be twice as fast.
    Yes, it's possible that one ship will have speed advantage below 100km/s over another and closing from extreme to modest beam range takes meaningful time... but the mechanics don't make that likely.

    I wouldn't say it's my dominant strategy, but considerations around kiting feature quite a bit in my games.
    First, I try not to be on the wrong side of it - scary things currently tend to have superior beam range due to superior E(C)CM), but not extreme speed. Some of my most satisfying battles included finding a range where relative advantages of specific beam weapons matter, weaving in and out depending on RoF considerations, reserving some missiles for point blank fire (which I'd have preferred to see treated as a feature for the AI to use, rather than a bug to be fixed. Having this at "modest beam range" was a stroke of unintended genius).
    The fun is hampered a little by just how short short-range combat is relative to ship speed, but it's working well.

    I like the idea of a small logistics burden on beam fire, but things scale in entirely the wrong way. Beam ranges being so incredibly short compared to ship speeds is the main issue (so the fancy long-ranged weapons don't get enough time to shine), but cost of weapons and relative importance of tech lines are others. One of the greatest appeals of breakdowns is that they make things less binary - no more free victories if you have range and speed on your enemies. But it further compresses effective weapon range (effective range no longer equal to maximum range), and detracts from weapon tech itself in favour of BFC range and E(C)CM. Sophisticated beam weapons do little good if their breakdown cost exceed damage dealt to the enemy or ordnance expenditure for missiles.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on March 02, 2020, 02:56:59 AM
    I see your point now.

    However, your final conclusion is too pessimistic, I think:
    Quote
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: MarcAFK on March 05, 2020, 06:50:45 PM
    Like many other things we want extensive playtesting to determine if theres a serious balance issue. The tweak to 1% steve has already done is probably all thats needed.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jovus on March 05, 2020, 07:39:37 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: TheRowan on March 06, 2020, 08:06:26 AM
    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.

    An overly-complex mechanic in Aurora?

    That'll never catch on...
    Title: Re: C# Aurora Changes Discussion
    Post by: xenoscepter on March 08, 2020, 12:46:08 AM
    I'm super excited for Commercial Hangars, I can't wait to build some Cryo Pods and mount them to a commercial ship! And build some Mobile Drydocks!  ;D

    Also can't wait for the changes to Cryo Berths! Now I can make Cryo Rescue ships that actually work! :D

    And with the Particle Lances I can finally do some Homeworld-Style Ion Frigates! Wahoo!

    This is gonna be radical!
    Title: Re: C# Aurora Changes Discussion
    Post by: kyonkundenwa on March 10, 2020, 05:09:53 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on March 11, 2020, 01:53:48 AM
    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?

    Yes.  This is how hangars are supposed to work.

    Quote
    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?

    No.  If you wish to micro-manage your way around the game rules that's your business.

    Quote
    Will commercial hangar-equipped vessels be able to act as "jump tenders" for military-engined vessels which would fit in the hangar?

    Yes.  Otherwise the 'auxiliary carrier/tender for small craft/FAC delivery' concept doesn't work.  If you wish to expand that to 'bulk carrier for destroyer/cruiser delivery' or 'fuel efficient long-distance delivery vehicle for battelships/superdreadnoughts' or even 'Guild highliner for transport of Atriedes/Harkonnen/Corrino warships' Aurora is happy to comply.

    Quote
    If hangared transit is intended while unhangared (yet capable of being hangared) transit is not,

    It is.  Aurora is not concerned with preventing you from cheating at solitaire.  (Though cheating is the wrong word in this case.  "Altering the rules to suit your personal playstyle" is a better phrase.)

    Quote
    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.

    The "intended" behaviour is that an empire uses Hangar space to store & service parasite craft.  Possibly even to maintain/repair/reload box launchers on larger, independant ships  -- such as a 'floating' drydock or fleet repair dock.  If you want to build a civilian, jump-capable space station with a quarter-million-ton hangar space to permanently 'live' at a jump point and carry ships back and forth in place of a jump gate that works too.

    - - - - -

    Actually, thinking about the mechanics of that last one. . .  If my empire replaces jump gates with manned space stations, then the fleet orders 'move to [planet] in [system] next door' become (if a military engined-ship is present):
    Move to jump point Charlie
    join fleet Jump Station Charlie
    dock in hangar SS(J) Charlie
    jump to [system] next door
    launch [ship](s)
    leave fleet Jump Station Charlie
    move to [planet]

    And even then, I think we're changing fleets twice.  It is definitely a nightmare of micro-management. . . though I don't see allowing the fleet to skip the landing & launching steps saves much.  It's the changing of fleets that's the real problem.  Not to mention having to keep track of which side of the jump point JS Charlie is on.

    - - - - -

    Now, Aurora will allow you to plot standard transits through 'civillian' jumpships (and, I assume, jump stations) with civilian-engined ships, or through military jumpships & stations with any ships.  It's how all my empire-controlled 'civilian' shipping moves around.  Aurora assumes that you will remember you planned movement through that asset and not take it away before the shipping arrives.  Commercial shipping lines will not.  They need jump gates or their own jump-capable ships.
    Title: Re: C# Aurora Changes Discussion
    Post by: xenoscepter on March 11, 2020, 02:33:59 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on March 11, 2020, 07:08:20 AM
    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.

    I would say maybee... in order for area PD to be somewhat effective you probably would need to be able to engage about three times most of the time. Given that missile speed in general will be slower I would say that it probably would be possible.

    From the numbers that I have seen at Steves example play trhoughs it should be possible.

    Let's say you have Magneto Plasme Escort wth a speed of 5000km/s... missiles from Steves campaign had roughly 30-35.000km/s speed at that same tech level and a 12cm far ultra violet laser would have 200.000km range which would mean a 400.000km total envelope. If the escort is moing away from the missile the missile would have en effective speed of 25-30.000km(s speed and that would mean about 125-150.000km per 5s cycle in distance... so it could potentially work with some area PD as you are close to that three times to cross the envelope.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on March 14, 2020, 09:18:37 AM
    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." ?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on March 14, 2020, 09:21:20 AM
    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 hadn't anticipated that level of openness in exploration :)

    I could change transponders to two separate modes; Friendly and Everyone. I'd made the change so it wasn't so easy to follow track NPR ships.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on March 14, 2020, 09:24:15 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on March 14, 2020, 10:08:25 AM
    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.

    Done - there are now three transponder modes; off, friendly and all. I've updated the original post.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on March 14, 2020, 01:45:28 PM
    Will this also impact the diplomatic system?

    I can imagine that an NPR would respond better to knowing that there's ships of another race in their system because that race has its transponders on than by detecting those ships on the sensors. And that military ships, civilian ships and spaceline ships all have different impacts between these types and depending on if their transponders are on or not.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on March 14, 2020, 02:07:10 PM
    I'm definitely going to RP on multi-faction Sol starts that ship ships with transponders off are "rogue" and free to be attacked by everyone. But it certainly would be nice if NPR hit to relation from seeing my ships would be reduced if my ship had transponder set to ALL.

    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on March 14, 2020, 04:56:20 PM
    I suppose it would be rather cool if at some point having your transponders set to 'all' was part of existing in AI empire space without upsetting them.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on March 14, 2020, 06:27:27 PM
    Well, without upsetting them much, although it'd depend on their xenophobia and other traits I'd guess.
    Title: Re: C# Aurora Changes Discussion
    Post by: TMaekler on March 15, 2020, 01:26:11 AM
    Can you set the Transponder for each ship? Also the mode? I would guess so...
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on March 15, 2020, 04:58:12 AM
    Can you set the Transponder for each ship? Also the mode? I would guess so...

    You can in VB Aurora, so I assume so for C# Aurora.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on March 15, 2020, 05:00:32 AM
    Can you set the Transponder for each ship? Also the mode? I would guess so...

    Yes.
    Title: Re: C# Aurora Changes Discussion
    Post by: TMaekler on March 15, 2020, 05:37:44 AM
    That’s nice. I recall an older function to send out false IDs. Any plans to reactivate that?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on March 15, 2020, 06:11:37 AM
    That’s nice. I recall an older function to send out false IDs. Any plans to reactivate that?

    Not at the moment. I think dealing with that possibility would be very difficult for an AI to comprehend.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on March 15, 2020, 09:54:41 AM
    Not... really?

    I mean, there are some limitations but off the top of my head.

    Automated record keeping already tracks ships and their demonstrated traits. This could be an issue.

    Setting a transponder to a false identity if there's no sensor in range to detect the ship has the AI handle it as if the ship is the false identity, this includes diplomatic impacts. Even if the ship is acting in ways the class strictly speaking should not be capable of, the AI discards the discrepancy and does not update the false identity (to prevent a jumble of contradicting data screwing things up).

    If there is a sensor in range, the AI may register something is strange if the demonstrated thermal signal is higher than what the database says it should be capable of (as engine power and thermal signature can be dialed down), or if the EM signal is different from what it should be (shields and sensors both project known amounts of EM signal).

    If the AI register's something is strange it may send a ship to investigate with active sensors. More course resolution active sensors are less effective/slower at the edge of their range than finer resolution sensors at correcting a false identification, and grow more effective more slowly than finer resolution sensors (ie, a 50 HS resolution sensor can start with identifying at greater range than a 5 HS resolution sensor, but that 5 HS sensor will have much better chances at any comparative range).

    In case of salvage, if an empire knows who was supposedly in combat and can salvage the wrecks, there's a chance that the empire figures out that the damage done does not fit the damage profiles of what weapons it has on record that are appropriate to the combatants. It will record this separately as the correct part with a confidence value. More hits on the same salvaged ship make the confidence value higher. If it's allied with the owner of the destroyed ship it may pass this information along.

    In case of salvage, if it identified that the damage profile is incorrect it will check its database to see if it knows the correct component and any similar components. If it does, it rolls and checks the result against how confident it is it properly identified the component. Even if the roll doesn't result in accurate identification of the component, if it has records of similar components from the same empire it is more likely to accurately identify the empire responsible.

    If an empire accurately identifies which empire is actually responsible for the damage it is likely to share this information to its allies, and may share this information with a hostile empire they are not at war with but were the victim of the attack. It may share this information with neutrals, and will not share this information with enemies.

    So long as the false identity holds up any action taken by the ship with the wrongly set transponder will be pointed to whatever empire is being framed.

    If the false identity fails the perpetrating empire sees a diplomatic hit with the empire it was fooling. If the empire that was being framed finds out the empire that was framing them also takes a diplomatic hit with the framed empire. This hit is smaller if both the framed and framing empires were allies and hostile or at war with the empire that was being fooled.

    Faking the identity of a civilian ship as another civilian ship or a military ship with another military ship that is of your own empire gives a smaller diplomatic hit. Faking the identity of a civilian ship by a warship gives a bigger diplomatic hit.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on March 15, 2020, 10:17:31 AM
    I meant that a human can comprehend that deception is possible, even though all empirical evidence suggests otherwise, and act accordingly. An AI can only work with the available data.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on March 15, 2020, 03:49:36 PM
    Yeah, that'd be difficult to program, the method I offered only partially covers it.

    After all, it allows the AI to notice something's odd when it's got data, but the sort of data crunching that's necessary to come up with 'wait, this item being here is completely out of place' is very difficult. There'd be so many factors to involve.
    Title: Re: C# Aurora Changes Discussion
    Post by: L0ckAndL0ad on March 16, 2020, 10:53:59 AM
    Love the new implementation of group contacts!

    Every time I see a large group of alien ships, I have troubles. Especially when see neutral/friendly armadas of dozens of ships. It's really hard to figure out at a glance what you're dealing with. It should be much better now with this change.

    If only fleet vs fleet auto-targeting for multi-FCS ships was easy as well..
    Title: Re: C# Aurora Changes Discussion
    Post by: TMaekler on March 17, 2020, 07:22:28 AM
    Sending out a false transponder code works as long as you stay out of any sensor detection.

    If you get into the range of a thermal sensor, your engine better have the same thermal pattern as the real ship... or else you will raise a flag in the message center. "Sensor anomaly detected in ship XX. Engine thermal is different to recorded patterns."

    If you get into the range of an active sensor your hull size better fits the recorded configuration... or else you will raise a flag in the message center.
    Title: Re: C# Aurora Changes Discussion
    Post by: xenoscepter on March 17, 2020, 04:04:20 PM
    @TMaekler

     - Hey, that's pretty good! The NPRs could check across that criteria, too.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on March 26, 2020, 11:55:36 AM
    I was wondering about the reasoning for the survey speed change, or rather why you would ever want to slow it down. Then I found this: http://aurora2.pentarch.org/index.php?topic=9841.msg119997#msg119997

    and yeah, I totally get that. Most games the periphery area is vastly larger than your empire, leading to battles over empty systems.
    Title: Re: C# Aurora Changes Discussion
    Post by: Zincat on March 26, 2020, 12:38:24 PM
    It's a really great idea. Besides the obvious usefulness for war,  I often lament how most systems end up being... left behind, because there's much better alternatives. If I can choose between 20 systems to exploit, I'll pick the best one after all.

    But this change makes most systems a lot more useful. Especially because due to the lack of slowing down, games will become longer hopefully.

    So, say you slow down surveying by a factor of ten. Or twenty. It will be very slow, so you have a much higher incentive to exploit the systems you find. The "decent" system close to you ends up being useful, exploited and maybe colonized. Because a useful system right now is often better than a potential great system you may or may not find in 4 years.
    Title: Re: C# Aurora Changes Discussion
    Post by: Kristover on March 26, 2020, 01:20:28 PM
    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%.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jovus on March 26, 2020, 01:32:41 PM
    This is also a great change for those of us who like to play NPR knife-fights (3-5 systems max, start w/ 1 NPR) in order to make surveying relevant or irrelevant to taste.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on March 26, 2020, 02:17:00 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Bughunter on March 26, 2020, 02:48:36 PM
    This is a great idea and will add the possibility for a lot of variation with a small tweak. Never thought of it before, but suddenly it seems like the default survey speed is too fast.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on March 26, 2020, 03:18:12 PM
    Personally I've never found it so, but then I also thoroughly survey every system before moving on.
    Title: Re: C# Aurora Changes Discussion
    Post by: Zincat on March 26, 2020, 03:44:02 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on March 26, 2020, 03:55:44 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Kristover on March 26, 2020, 03:59:37 PM
    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.

    I don't remember there being a tech cost modifier in VB6.  Will there be a modifier in C#?
    Title: Re: C# Aurora Changes Discussion
    Post by: JustAnotherDude on March 26, 2020, 04:05:36 PM
    There is a race level research speed modifier, if I remember correctly
    Title: Re: C# Aurora Changes Discussion
    Post by: Kristover on March 26, 2020, 04:07:10 PM
    There is a race level research speed modifier, if I remember correctly

    Yeah, I just looked it up in the wiki and there is a research speed modifier.
    Title: Re: C# Aurora Changes Discussion
    Post by: Froggiest1982 on March 26, 2020, 04:40:55 PM
    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.

    Correct, that is why if you looking at reducing the speed of the survey by 50% what is the difference between having it completed in 2 or 4 days?

    So travel to Alpha Centauri 1 month plus survey 7 days or travel to Alpha Centauri 1 month plus 14 days. You do the math.

    It's a very good addition but I think you should consider keeping 5% or 10% to really slow it down.

    Steve, you should create then an NPR with a peaceful exploration mind focused on building large survey ships with multiple survey sensors in the attempt to find a new system (Federation of Start Trek kind).

    That NPR would be extremely valued ally to share Geological data with and open to the possibility of just have an ally and protect him from aggressors.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on March 26, 2020, 06:07:49 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on March 26, 2020, 06:26:32 PM
    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.

    In C# you can build asteroid mining space stations using construction factories.
    Title: Re: C# Aurora Changes Discussion
    Post by: Kelewan on March 27, 2020, 04:50:44 AM
    Quote from: Steve Walmsley

    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Dira2 on March 27, 2020, 05:04:52 AM
    Quote from: Kelewan link=topic=8497. msg120016#msg120016 date=1585302644
    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.
    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. 
    Title: Re: C# Aurora Changes Discussion
    Post by: alex_brunius on March 27, 2020, 07:56:36 AM
    Quote from: Kelewan link=topic=8497. msg120016#msg120016 date=1585302644
    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.
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on March 27, 2020, 08:11:35 AM
    Quote from: Kelewan link=topic=8497. msg120016#msg120016 date=1585302644
    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.
    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).
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on March 27, 2020, 09:16:00 AM
    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 it's not.

    If speed for a given action is (x), if it moves 50% faster it moves at a speed of 1.5(x), and will complete in 2/3rd of the time compared to the same action moving at speed (x).

    That the action completes within 2/3rd of the time when the points per unit of time accrue at twice the rate for the same action at speed (x) implies a non-linear relation between the speed of point accrual and the speed of completion of the action.


    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.

    A factor that would allow instant completion of surveys would be infinitely large, although I'm sure that there's a multiplier value where a survey missile can survey anything within a single 5 second pulse, at which point larger values are no longer relevant because the game won't implement orders without running the code and the code isn't run without pressing the next turn button.
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on March 27, 2020, 10:52:35 AM
    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.


    It's semantics - we are saying the same thing. You are defining 'progress' as how many more survey points are generated. I am defining 'progress' as time required to complete the task. I suggest we agree to disagree :)
    Title: Re: C# Aurora Changes Discussion
    Post by: Bremen on March 27, 2020, 01:19:07 PM
    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.

    In my experience research costs doubling every tier means that the longer you play the further new breakthroughs get spread out. So at early to mid game, yeah, capital ships are frequently obsolete before they finish construction, but later on that ceases to be true since the speed RP is produced doesn't keep pace with the increased costs.
    Title: Re: C# Aurora Changes Discussion
    Post by: xenoscepter on March 27, 2020, 08:03:16 PM
    Does the CIC do anything yet?

    EDIT: If not, might I suggest the Tactical Bonus affects Initiative? Perhaps also for the Fleet?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on March 28, 2020, 05:35:22 AM
    Does the CIC do anything yet?

    EDIT: If not, might I suggest the Tactical Bonus affects Initiative? Perhaps also for the Fleet?

    CIC allows you to have a tactical officer.
    Title: Re: C# Aurora Changes Discussion
    Post by: Father Tim on March 28, 2020, 02:29:06 PM
    Quote from: Steve Walmsley
    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

    Excellent!  My early, non-military-engined ships will be underestimated at first, but once the shooting starts those bug-eyed aliens will learn to respect us!
    Title: Re: C# Aurora Changes Discussion
    Post by: xenoscepter on March 28, 2020, 06:51:25 PM
    Yes, but what does that do? The effect of the Tactical Officer's bonus was TBD last time I read through the Changes List...
    Title: Re: C# Aurora Changes Discussion
    Post by: JustAnotherDude on March 28, 2020, 06:57:54 PM
    It affects your to-hit-chance I think
    Title: Re: C# Aurora Changes Discussion
    Post by: xenoscepter on March 28, 2020, 09:25:21 PM
    That sounds pretty good, thanks.
    Title: Re: C# Aurora Changes Discussion
    Post by: hadi on March 31, 2020, 05:42:13 PM
    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!
    Title: Re: C# Aurora Changes Discussion
    Post by: Frick on April 01, 2020, 08:09:12 AM
    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!

    Please provide feedback on this, would be very interested in this.
    Title: Re: C# Aurora Changes Discussion
    Post by: AlStar on April 01, 2020, 08:15:24 AM
    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
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on April 01, 2020, 08:27:21 AM
    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 :)
    Title: Re: C# Aurora Changes Discussion
    Post by: chrislocke2000 on April 01, 2020, 09:36:49 AM

    I'm six years into the campaign and I still don't have a Sensors and Control Systems scientist :)

    I have to say I'm pretty happy with that, especially for non-TN starts where relevant scientists can have a big swing factor on the game play.
    Title: Re: C# Aurora Changes Discussion
    Post by: Zincat on April 01, 2020, 10:04:07 AM
    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 had a vb6 aurora campaign where 25 years in, and with 15 military academies, I had ZERO power and propulsion scientists.
    And a bazillion of other scientists. No need to say I'm in favor of this
    Title: Re: C# Aurora Changes Discussion
    Post by: Inglonias on April 01, 2020, 11:19:01 AM
    On one hand, I can see why the availability of scientists can add character to an empire, slowing down research in a few areas due to the luck of the draw.

    On the other hand, I hate having thirty biologists and no power and production scientists a decade after I start my game.
    Title: Re: C# Aurora Changes Discussion
    Post by: Kristover on April 01, 2020, 12:27:58 PM
    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?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on April 01, 2020, 12:43:44 PM
    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?

    There is an effective peace treaty when lack of contact brings the relationship back toward neutral, but no ability to propose peace (yet).
    Title: Re: C# Aurora Changes Discussion
    Post by: Desdinova on April 01, 2020, 01:41:05 PM
    Will an NPR that loses a battle or two adopt a more defensive posture, allowing the relations to reset?
    Title: Re: C# Aurora Changes Discussion
    Post by: Steve Walmsley on April 02, 2020, 02:28:04 AM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Kaiser on April 02, 2020, 03:52:35 AM
    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.

    Steve, this is a very crucial point.
    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 (bigger ships lost could bring to higher warscore, depending on the tonnage for example).
    Also, a war exaustion implemented could be an idea. A combination of high warscore + war exaustion could push the AI or the human to ask for peace.
    Title: Re: C# Aurora Changes Discussion
    Post by: Gimlie on April 02, 2020, 04:42:12 PM
    Quote from: Kaiser link=topic=8497. msg120268#msg120268 date=1585817555
    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

    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. 
    Title: Re: C# Aurora Changes Discussion
    Post by: amschnei on April 02, 2020, 05:06:29 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Gimlie on April 02, 2020, 05:15:57 PM
    Quote from: amschnei link=topic=8497. msg120301#msg120301 date=1585865189
    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. 

    Forgive me for maybe acting too presumptuous, but Aurora as a whole is a project which many would consider too big for one person. .  From what I've seen from my few years of watching these forums, lack of manpower doesn't stop Steve from implementing complex mechanics.  That's not to say that this particular feature is good enough to warrant implementation though.
    Title: Re: C# Aurora Changes Discussion
    Post by: Froggiest1982 on April 02, 2020, 05:22:33 PM
    Quote from: Kaiser link=topic=8497. msg120268#msg120268 date=1585817555
    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

    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.

    I disagree.

    You will have to assign points to each ship but based on what? I mean probably the only real number here is the tonnage, however what about guns? Lose a defense platform of 100,000t with few lasers on it's not like losing 10 carries of 10,000t. Also my 10 1,000t FAC could struggle with a well balanced 10,000t cruiser well-armored and fully stocked or the other way round if I have done a good job designing my FACs.

    Warscore might work well for AI vs AI so to speak. In a Human vs AI, it's always a mess. First of all too many spoilers: You know exactly how much your opponent has left in terms of resources and troops simply because it goes from 0 to 100% all of the sudden after a victory, meaning they out of guns. Second, until you hit the preset cap the AI refuses to deal with you (and this works both in case they winning or losing) which is a killer. From the player perspective if you can break the 25 points why stop at that? just get 50 and then 75 etc. You can calculate your odds the AI doesn't do that if you put a limitation on their expansion. AI is winning? Concede with a juicy pace deal at the right time and you just bought yourself a bit of time

    This is also why Paradox was forced to add claims and other penalty buffers at some point. Do you see where I am going with this? Too complicated for a one-person development team.

    Also, the beauty of Aurora is the unknown. You never know exactly what the race you just encountered has. What is their capability, how big is their empire, what tech, etc? As said add a spoiler such as Warscore will make all the intel gathering pointless.
    Title: Re: C# Aurora Changes Discussion
    Post by: Froggiest1982 on April 02, 2020, 05:25:52 PM
    Considering the truce mechanics being already there, I would use the Truce timeout after peace deals though. This would help to rebuild and avoid small fast-paced wars.

    @Steve Walmsley do you think that is doable?
    Title: Re: C# Aurora Changes Discussion
    Post by: Jorgen_CAB on April 02, 2020, 05:54:12 PM
    If there are some war exhaustion mechanic for the NPR it should be some hidden mechanic as it is a "personal" value. The only value that the player should be able to see is the diplomatic score they have with said empire.

    There certainly is some merit for the NPR to have a value of how committed they are to a particular conflict. You don't want every conflict to become a total war type of scenario, neither the player nor the NPR will benefit from this as war is a huge drain on resources in Aurora. If there are multiple faction in the game and two of them is fighting for a very long time the others will benefit from this allot.

    The way that most 4x games give away statistical numbers is very detrimental to those games in general and very unrealistic on most cases. This especially is in regard to military information... the problem is how accurate the information is. In the real world you might have a rough estimation of an enemy strength, but you can never be 100% sure it is accurate. History have shown many times how enemies have been both over and under estimated by allot in terms of strength and capability.

    If you are fighting an alien species which you have never had any economic trading with and barely any diplomatic contact with you also have very little possibility to know almost anything about them, let alone their military strength or willingness to fight.

    If you have had good trading opportunities with them in their past you should have a fair estimation of their economic strength but even here it might be a bit tricky as you might net even know all of the planets and system they even have colonies in, how are you then even going to know their true industrial power?

    If you are contending with a faction of the same species then things like economy and general military strength could be reasonable to have a good grasp on. I think it depend on how intertwined said factions is and if they have colonies on the same planets and/or systems and how much they know of the enemies military ship designs.

    Anyway... information should in general be very sparse in terms of another factions economy, military or psychological state.
    Title: Re: C# Aurora Changes Discussion
    Post by: Hazard on April 02, 2020, 06:54:37 PM
    A warscore mechanic should probably consider how an NPR will evaluate a given conflict. Two major empires going head to head over a handful of mostly empty and worthless systems is unlikely to see a major military deployment and would more likely be a limited/proxy war over those systems, especially if the first engagements are inconclusive and costly. A conflict over a modestly valuable system between a major empire and a smaller empire will see a major difference in how they view the war though. For the major empire it's a nice system to have and something they're willing to take some risks for. To the smaller empire it may well be a matter of the nation's survival and they will dedicate their every effort to victory because otherwise the empire's going to die.


    As for how to value ships in a war, you've already got PPV to work with for gun ships, PPV and magazine size for missile ships, and cargo/fuel capacity for non-combat ships. Ground forces can be handled with a blunt weight estimate and colonies with their combined tonnage industrial output (all mines plus production facilities). You can even calculate war weariness into it, calculating the value of your forces and colonies at the start of the war, how much you've added to it, and how much you've lost over the course of the war. How big a deal a conflict is influences how willing your empire is to continue the war.


    Of course doing all that wouldn't be a small project by any measure.
    Title: Re: C# Aurora Changes Discussion
    Post by: QuakeIV on April 03, 2020, 04:34:46 AM
    I think warscore is a really weak mechanic and isn't suitable to aurora.  Its an attempted abstraction of complicated things happening in the background (morale, or something? who knows), and tends to do a rather poor job of describing why you suddenly surrendered, other than that temporarily losing control of somewhere the 37th time instead of the 36th was apparently the straw that broke the camels back.
    Title: Re: C# Aurora Changes Discussion
    Post by: Triato on April 03, 2020, 07:56:46 AM
    Militancy and xenofobia could be part of the formula. That way you can't know if they surrender becouse they are out of ships or becouse they are pacifists. Allied empires should also count.
    Title: Re: C# Aurora Changes Discussion
    Post by: NuclearStudent on April 13, 2020, 11:09:07 PM
    One of the reasons that warscore works in Paradox games is that it operates on known quantities of territory. I don't see that going as well in Aurora.

    War exhaustion, however, does sound like a good idea. It should be easier, in general, to know the psychology and war exhaustion of an alien race if you've been in contact for a while.
    Title: Re: C# Aurora Changes Discussion
    Post by: iceball3 on April 15, 2020, 04:59:33 AM
    I can only really see war exhaustion directly superseding an empire's decision making autonomy (as a player) if it's something like planetary unrest (but planets already rebel under sufficient unrest in aurora) or loss of crew. I don't see this ending conflicts directly though, at most they should be formed as secondary effects (loss of military academy efficiency due to sending crew to meatgrinder) as there are many wars that you obviously should not be outright surrendering regardless of the war fatigue, unless it's one where all faculties for your empire to control it's assets are voided. See: just about every spoiler race, and alien empires who would obviously force you into peace specifically for discretely parking a fleet of missile carrying ships to alpha strike your home planet.
    As is, we already know that PPV isn't representative of lost war value... It's minerals to construct a given ship, it's crew training, the inverse of it's current maintenance clock, it's commanding officers, and the opportunity cost of the slipway/shipyard size/maintenance capacity to build it and keep it going.

    As aurora is now, the diplomatic stance you have available is "ready to wage war at any moment", and adding in exhaustion mechanics that make it so you can't fire missiles you have loaded in magazines once an ephemeral diplomatic threshold is passed is honestly not a good idea, in my opinion. That said, we can make the AI find peace much more palatable if they've burned through their officer pool and have to use untrained conscripts on their vessels. Players might be kind to that idea as well. Though, naval academies would likely have to be re-balanced to have diminishing returns, and to partially scale with planetary population and "officers died in combat" fatigue maybe, as the current system feels a bit too feast-or-famine by design... I've never actually run short of officers before running short of minerals, ever.
    Title: Re: C# Aurora Changes Discussion
    Post by: Droll on June 01, 2020, 04:15:18 PM
    A war exhaustion mechanic would need to exist alongside a formal war declaration mechanic much like the aforementioned paradox examples.

    If an NPR has declared total war on you, then that means that your very existence as a species is being threatened. The loss of crew and ships in a survival scenario such as this is not really going to make your empire less willing fight.

    However consider that the enemy has declared war, expressly stating that they wish dismantle listening posts/take over an automated mining colony in a frontier system. Loss of ships and in particular crew in this scenario will have a much more significant level on war weariness as people are going to start questioning whether or not sending their sons to die for a piece of rock is justified or not. This also allows saving crew stuck in lifepods to have a more significant effect on gameplay. Saving crew and delivering them back to the empire would help mitigate such weariness - though not eliminate.
    There is also the issue of NPRs and players deciding to push beyond their initial war goals. This could/should have some sort of consequence. This could be in the form of diplomatic repercussions with other NPRs that have established contact or a spike in war exhaustion.

    Already you should begin to see the complexity that such a system invites, both gameplay and implementation wise. Unlike paradox games, aurora focuses much more on the tactical and strategic combat aspect of 4x sci-fi, whereas a greater emphasis on interstellar diplomacy exists in something like stellaris.
    Title: Re: C# Aurora Changes Discussion
    Post by: Garfunkel on June 05, 2020, 06:34:04 PM
    War Exhaustion also needs to exist on a line of non-activity versus activity. Because nobody cares about wars that don't really affect most people and happen somewhere far.
    Title: Re: C# Aurora Changes Discussion
    Post by: Borealis4x on December 20, 2020, 12:42:42 PM
    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.
    Title: Re: C# Aurora Changes Discussion
    Post by: Droll on December 20, 2020, 02:42:27 PM
    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.

    This is the old changes discussion thread that started from before the release of C# IIRC - you probably want to post this in the C# suggestion sub-forum.