Aurora 4x

Aurora => C# Aurora => 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: BasileusMaximos 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: BasileusMaximos 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: BasileusMaximos 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 Luken 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 Luken 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: byron 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: BasileusMaximos 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: BasileusMaximos 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: BasileusMaximos 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: BasileusMaximos 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: BasileusMaximos 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: BasileusMaximos 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: BasileusMaximos 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 Luken 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: BasileusMaximos 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: BasileusMaximos 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: BasileusMaximos 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: BasileusMaximos 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: BasileusMaximos 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: BasileusMaximos 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: BasileusMaximos 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: byron 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 Luken 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: BasileusMaximos 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: BasileusMaximos 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 Luken 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 Luken 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: byron 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: BasileusMaximos 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: BasileusMaximos 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 Luken 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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: byron 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 Luken 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 Nazi, 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: byron 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: BasileusMaximos 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: Coleslaw35 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: Coleslaw35 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: byron 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: byron 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: byron 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: byron 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: BasileusMaximos 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: BasileusMaximos 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: BasileusMaximos 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: BasileusMaximos 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: byron 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: BasileusMaximos 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: BasileusMaximos 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: byron 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: byron 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: BasileusMaximos 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: byron 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: byron 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: byron 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: byron 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 Luken 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 Luken 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: byron 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 Luken 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: byron 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 sing