Suggestions for 3.3

[schroeam]

I think the next step is to make sure that fleet admirals don't end up commanding destroyers. Several people have suggested having a max rank so how about 2 ranks above the minimum. So if you set Commander as the min rank, then the max rank will be Commodore. Min rank Captain then max rank Rear Admiral, etc.. Is two ranks appropriate or should it just be one rank?

Steve

Two works for me.

Two's good, except for governorships, headquarters, and capital ships.  Maybe three for those, if possible.

[Erik L]

I think the next step is to make sure that fleet admirals don't end up commanding destroyers. Several people have suggested having a max rank so how about 2 ranks above the minimum. So if you set Commander as the min rank, then the max rank will be Commodore. Min rank Captain then max rank Rear Admiral, etc.. Is two ranks appropriate or should it just be one rank?

Steve

Two works for me.

Two's good, except for governorships, headquarters, and capital ships.  Maybe three for those, if possible.

I don't believe governors and task group commanders are subject to rotation rules.

[schroeam]

I don't believe governors and task group commanders are subject to rotation rules.

I wasn't sure if the restriction would be global or just on the automated assignments.

[ZimRathbone]

ADF = Australian Defence Force?

 Aye

It turned out to be a relatively simple change so I have made it. When a race is created, the time is noted. If automated assignments are switched on then after a period equal to the tour length, every officer that is commanding a ship or a ground unit or is a staff officer and does not have the "Do Not Remove" flag set will be removed from their post. Then the program will carry out a reassignment of all available posts for that race in those areas. This should ensure the best officers go to the best ships and that any newly arrived officers get into suitable commands fairly quickly. When this mass assignment takes place, a note is made of the time and when the tour length has passed the whole process happens again.

I think the next step is to make sure that fleet admirals don't end up commanding destroyers. Several people have suggested having a max rank so how about 2 ranks above the minimum. So if you set Commander as the min rank, then the max rank will be Commodore. Min rank Captain then max rank Rear Admiral, etc.. Is two ranks appropriate or should it just be one rank?

Steve

Two ranks is good I think.

[Steve Walmsley]

I have changed the automated assignment to include the two rank restriction for all ships and all ground forces except HQs. I have left staff officers alone as they are based on a max rather than min rank anyway. Planetary and sector governors and task force commanders are not covered by automated assignments. The two rank restriction will only apply to automated assignments so you will be able to override it for manual assignments.

Steve

[Erik L]

I think this has been mentioned before... A way to upgrade LTA/LTI units.

Also. Not sure where it disappeared to, but when you buy civilian ships, a popup to select the task group they go into.

[Brian Neumann]

Have missiles survive for 1 second in a nebula.  This will prevent planets from being almost impossible to conquor.  A planet with 1 or more atmosphere pressure and in a nebula can only be engaged with meson's.  But Meson's don't seem to affect ground units.  This would also give missile ships a little bit of combat power, but it will be terribly short ranged for whatever tech is being used.  Almost any beam weapon will be able to out range it.  A good example is most ion engine missiles have speeds between 25-30000 km/s.  Any visable light laser has at least a matching range.  By the time that the lasers are at the same tech level they will have 3-5 times the range, and be firing much faster.

Brian

[jfelten]

Have missiles survive for 1 second in a nebula.  This will prevent planets from being almost impossible to conquor.  A planet with 1 or more atmosphere pressure and in a nebula can only be engaged with meson's.  But Meson's don't seem to affect ground units.  This would also give missile ships a little bit of combat power, but it will be terribly short ranged for whatever tech is being used.  Almost any beam weapon will be able to out range it.  A good example is most ion engine missiles have speeds between 25-30000 km/s.  Any visable light laser has at least a matching range.  By the time that the lasers are at the same tech level they will have 3-5 times the range, and be firing much faster.

Brian

Or maybe allow missiles in a nebula but reduce their speed to the maximum ship speed in a nebula?

[jfelten]

I apologize for not having all the correct terms here, but I don't have a copy of Aurora to reference as I write this.  I would like an option that when a divided TF is given the assemble order, that child TF's that are not co-located with the mother TF have an order added to join the mother TF.  

What I've been doing is sending a fleet of non-jump grav survey ships along with one jump capable "mothership" in to a system to survey for warp points.  The divide option (or whatever it is called, the one that automatically splits a TF in to single ship TF's, one of which becomes the parent TF and all the rest child TF's) is super useful here as it copies the survey orders from the parent TF to the children TF's.  And although I've not timed it, it seems that splitting the grav survey ships up results in surveying a system much faster (someone please correct me if I'm wrong about this!).  But when done I want to recombine those all back in to the original parent TF.  There is an assemble button for that but it only works for child TF's that are co-located with the parent TF.  So I have to go to every child TF (single ship TF) and give each of them orders to join the parent TF once they finish their JP surveys.  That is a lot of clicking.  It is still a heck of a lot better than doing it all manually, but by adding this one additional feature it would be nearly totally automated.  

Note that I would like the join order added to the child TF's existing orders, not just replace their existing orders, since they may have a few JP's left to survey at that point.

[schroeam]

I apologize for not having all the correct terms here, but I don't have a copy of Aurora to reference as I write this.  I would like an option that when a divided TF is given the assemble order, that child TF's that are not co-located with the mother TF have an order added to join the mother TF.  

What I've been doing is sending a fleet of non-jump grav survey ships along with one jump capable "mothership" in to a system to survey for warp points.  The divide option (or whatever it is called, the one that automatically splits a TF in to single ship TF's, one of which becomes the parent TF and all the rest child TF's) is super useful here as it copies the survey orders from the parent TF to the children TF's.  And although I've not timed it, it seems that splitting the grav survey ships up results in surveying a system much faster (someone please correct me if I'm wrong about this!).  But when done I want to recombine those all back in to the original parent TF.  There is an assemble button for that but it only works for child TF's that are co-located with the parent TF.  So I have to go to every child TF (single ship TF) and give each of them orders to join the parent TF once they finish their JP surveys.  That is a lot of clicking.  It is still a heck of a lot better than doing it all manually, but by adding this one additional feature it would be nearly totally automated.  

Note that I would like the join order added to the child TF's existing orders, not just replace their existing orders, since they may have a few JP's left to survey at that point.

There are a couple different ways to do this.  You can either have the subfleets try to find the parent fleet and merge with them using conditional orders.
       Condition: Parent fleet in system
       Order: Join Parent Fleet in System
This option has a disadvantage of using valuable fuel if the fleets are 180 degrees apart in a very large system and they chase each other around.  Another option is to arrange for a rendezvous point and have the parent fleet absorb the sub fleets.  This uses the secondary default order and one set of conditional orders.
       Primary Default Order:  Survey nearest survey location (or next three)
       Secondary Default Order:  Move to Entry Jump Point
       Conditional Order for Parent Fleet:
            Condition:  Sub fleets in same location
            Order:  Incorporate sub-fleets in same location
I've generally used the second option.  This seems to work best since the jump ship will usually explore the newly discovered jump points once the survey is complete, and the sub-fleets will concentrate in one, "safe" area.  

Hope this helps.

Adam.

[Erik L]

I apologize for not having all the correct terms here, but I don't have a copy of Aurora to reference as I write this.  I would like an option that when a divided TF is given the assemble order, that child TF's that are not co-located with the mother TF have an order added to join the mother TF.  

What I've been doing is sending a fleet of non-jump grav survey ships along with one jump capable "mothership" in to a system to survey for warp points.  The divide option (or whatever it is called, the one that automatically splits a TF in to single ship TF's, one of which becomes the parent TF and all the rest child TF's) is super useful here as it copies the survey orders from the parent TF to the children TF's.  And although I've not timed it, it seems that splitting the grav survey ships up results in surveying a system much faster (someone please correct me if I'm wrong about this!).  But when done I want to recombine those all back in to the original parent TF.  There is an assemble button for that but it only works for child TF's that are co-located with the parent TF.  So I have to go to every child TF (single ship TF) and give each of them orders to join the parent TF once they finish their JP surveys.  That is a lot of clicking.  It is still a heck of a lot better than doing it all manually, but by adding this one additional feature it would be nearly totally automated.  

Note that I would like the join order added to the child TF's existing orders, not just replace their existing orders, since they may have a few JP's left to survey at that point.

Set a conditional order to rejoin parent fleet in system.

[Randy]

Just a suggestion-

  You might want to make it so that you actually have to own a ship before you can scrap it...  :lol:

[sloanjh]

I apologize for not having all the correct terms here, but I don't have a copy of Aurora to reference as I write this.  I would like an option that when a divided TF is given the assemble order, that child TF's that are not co-located with the mother TF have an order added to join the mother TF.  

What I've been doing is sending a fleet of non-jump grav survey ships along with one jump capable "mothership" in to a system to survey for warp points.  The divide option (or whatever it is called, the one that automatically splits a TF in to single ship TF's, one of which becomes the parent TF and all the rest child TF's) is super useful here as it copies the survey orders from the parent TF to the children TF's.  And although I've not timed it, it seems that splitting the grav survey ships up results in surveying a system much faster (someone please correct me if I'm wrong about this!).  But when done I want to recombine those all back in to the original parent TF.  There is an assemble button for that but it only works for child TF's that are co-located with the parent TF.  So I have to go to every child TF (single ship TF) and give each of them orders to join the parent TF once they finish their JP surveys.  That is a lot of clicking.  It is still a heck of a lot better than doing it all manually, but by adding this one additional feature it would be nearly totally automated.  

Note that I would like the join order added to the child TF's existing orders, not just replace their existing orders, since they may have a few JP's left to survey at that point.

First, yes, splitting the survey ships up results in faster surveys.  This is because the total survey time is the sum of the time it takes to survey a location ("parked survey") plus the time it takes to get to that location ("transit").  The total parked survey time over the entire system depends only the number of ships (actually survey modules) doing the surveying, since it's a fixed number of survey points.  The total transit time, however, varies depending on the path of each ship; the worst transit time is obtained by having every ship visit every survey location.

Second, I never had much luck with the "join" order for re-assembling fleets (it didn't seem to do what I wanted it to do), so I basically don't use it.  For situations like you describe, I tend to use my jump ships in "bridge mode" - I park them at the JP and let them escort other units through as the other units arrive.  Part of this is role-playing - once my civ has discovered aliens exist, it always has a powered-down (i.e. stealthy) jump ship at the JP in "overwatch mode" - if the survey ships get eaten by BEMs (as happened in Steve's current campaign), the overwatch ship will know about it and transit back to warn the civ.

In other words, my survey ships tend to trickle into a system rather than arriving all at once.  All that being said, your suggestion sounds like a good idea - I think I remember being in a similar situation and all that clicking being a pain.

John

[jfelten]

I'll try the conditional order.  I was already using both conditional orders but can give one of them up.  

Issuing the Join orders manually seemed to work perfectly for me.  It was just extra clicks.  

I understand about having a jump ship at the WP to escape with word of an emergency.  I guess I could just put zero survey instruments on the jump ship and then it would just sit at the WP while the non-jump survey ships went to work.  But I'm personally more interested in having the process as automated as possible so I can focus on other aspects of the game.  I guess at this point I'm pretending there is some system such as Starfire courier drones in use that can get word out if a giant space goat is encountered and eats the fleet.  

My real suggestion for 3.3 would be an order to give a fleet to go survey a system and it would then do so on its own in the most efficient manner without further input from me.  I assume this would also be of value to the game system for when fully automated NPR's are introduced.

[sloanjh]

I understand about having a jump ship at the WP to escape with word of an emergency.  I guess I could just put zero survey instruments on the jump ship and then it would just sit at the WP while the non-jump survey ships went to work.  But I'm personally more interested in having the process as automated as possible so I can focus on other aspects of the game.  I guess at this point I'm pretending there is some system such as Starfire courier drones in use that can get word out if a giant space goat is encountered and eats the fleet.  

LOL - I guess goats will eat anything!

I like your technobabble idea for courier drones if one doesn't want to deal with the communications tail.  I probably won't use it, though - I actually like role-playing the paranoid-explorer-thing (at least after I've discovered my first ruins).  My grav survey ships are warp-capable, and it's usually not efficient to have more than 2-3 in a system at once - they end up spending a lot of distance leap-frogging each other.  (In fact, one could probably prove that the most efficient time/ships ratio can't involve more than 3 ships in the system, since the 3rd ship wouldn't be able to avoid leap-frogging one of the others.)  So what I actually do is creep into the system, keep a ship right on the JP until habitable worlds are probed and the system looks safe (and until any non-jump-capable geo-survey ships have arrived), then make sure that I always have at least two ships doing the survey, so that if one gets ambushed the other(s) has a good chance of escaping.

My real suggestion for 3.3 would be an order to give a fleet to go survey a system and it would then do so on its own in the most efficient manner without further input from me.  I assume this would also be of value to the game system for when fully automated NPR's are introduced.

I think this was Steve's original vision for the "join" order.  I've found that survey fleets are too resource-intensive and cumbersome (from an efficiency point of view), and so my survey units tend to operate independently.

One interesting aspect of this survey doctrine is that it's not very paranoid, i.e. the ships are going to be tooling around with a large signature in a system that might have aliens.  This might give a cool role-playing opportunity, i.e. representing a peaceful civilization that's trusting in the kindness of the universe.

John